GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1618

Network Working Group W. Simpson Request for Comments: 1618 Daydreamer Category: Standards Track May 1994

                           PPP over ISDN

Status of this Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Abstract

 The Point-to-Point Protocol (PPP) [1] provides a standard method for
 transporting multi-protocol datagrams over point-to-point links.
 This document describes the use of PPP over Integrated Services
 Digital Network (ISDN) switched circuits.
 This document is the product of the Point-to-Point Protocol Working
 Group of the Internet Engineering Task Force (IETF).  Comments should
 be submitted to the ietf-ppp@merit.edu mailing list.

Applicability

 This specification is intended for those implementations which desire
 to use the PPP encapsulation over ISDN point-to-point links.  PPP is
 not designed for multi-point or multi-access environments.
 "It is clear that there is never likely to be a single, monolithic,
 worldwide ISDN." [3] The goal of this document is to describe a few
 common implementations, chosen from the current wide variety of
 alternatives, in an effort to promote interoperability.

Simpson [Page i] RFC 1618 PPP over ISDN May 1994

                         Table of Contents
   1.     Introduction ..........................................    1
   2.     Physical Layer Requirements ...........................    1
   3.     Framing ...............................................    3
   4.     Out-of-Band signaling .................................    4
   5.     Configuration Details .................................    5
   SECURITY CONSIDERATIONS ......................................    5
   REFERENCES ...................................................    5
   ACKNOWLEDGEMENTS .............................................    6
   CHAIR'S ADDRESS ..............................................    6
   AUTHOR'S ADDRESS .............................................    6

Simpson [Page ii] RFC 1618 PPP over ISDN May 1994

1. Introduction

 PPP was designed as a standard method of communicating over point-
 to-point links.  Initial deployment has been over short local lines,
 leased lines, and plain-old-telephone-service (POTS) using modems.
 As new packet services and higher speed lines are introduced, PPP is
 easily deployed in these environments as well.
 This specification is primarily concerned with the use of the PPP
 encapsulation over ISDN links.  Since the ISDN B-channel is by
 definition a point-to-point circuit, PPP is well suited to use over
 these links.
 The ISDN Primary Rate Interface (PRI) may support many concurrent B-
 channel links.  The PPP LCP and NCP mechanisms are particularly
 useful in this situation in reducing or eliminating hand
 configuration, and facilitating ease of communication between diverse
 implementations.
 The ISDN D-channel can also be used for sending PPP packets when
 suitably framed, but is limited in bandwidth and often restricts
 communication links to a local switch.
 The terminology of ISDN can be confusing.  Here is a simple graphical
 representation of the points used in subsequent descriptions:
                 +-------+     +-------+     +-------+
             R   |       |  S  |       |  T  |       |   U
             +---+  TA   +--+--+  NT2  +--+--+  NT1  +---+
                 |       |     |       |     |       |
                 +-------+     +-------+     +-------+
 These elements are frequently combined into a single device.

2. Physical Layer Requirements

 PPP treats ISDN channels as bit or octet oriented synchronous links.
 These links MUST be full-duplex, but MAY be either dedicated or
 circuit-switched.
 Interface Format
    PPP presents an octet interface to the physical layer.  There is
    no provision for sub-octets to be supplied or accepted.  The octet
    stream is applied primarily at the R or T reference points.

Simpson [Page 1] RFC 1618 PPP over ISDN May 1994

 Transmission Rate
    PPP does not impose any restrictions regarding transmission rate,
    other than that of the particular ISDN channel interface.
 Control Signals
    PPP does not require the use of control signals.  When available,
    using such signals can allow greater functionality and
    performance.  Implications are discussed in [2].
    Control signals MAY be required by some of the framing techniques
    described, and is outside the scope of this specification.
 Encoding
    The definition of various encodings and scrambling is the
    responsibility of the DTE/DCE equipment in use, and is outside the
    scope of this specification.
    While PPP will operate without regard to the underlying
    representation of the bit stream, lack of standards for
    transmission will hinder interoperability as surely as lack of
    data link standards.  The D-channel LAPD interface requires NRZ
    encoding at the T reference point.  Therefore, as a default, it is
    recommended that NRZ be used over the B-channel interface at the T
    reference point.  This will allow frames to be easily exchanged
    between the B and D channels.
    When configuration of the encoding is allowed, NRZI is recommended
    as an alternative in order to ensure a minimum ones density where
    required over the clear B-channel, with caveats regarding FCS [2].
    Historically, some implementations have used Inverted NRZ (merely
    switching the sense of mark and space), in order to ensure a
    minimum ones density with bit-synchronous HDLC.  The use of
    Inverted NRZ is deprecated.
    Automatic Detection
       Implementations which desire to interoperate with multiple
       encodings MAY choose to detect those encodings automatically.
       Automatic encoding detection is particularly important for
       Primary Rate Interfaces, to avoid extensive pre-configuration.
       Only simple encodings are currently distinguished.
       The only reliable method of detection available is to switch
       modes between the supported encodings.  Transmission of the LCP

Simpson [Page 2] RFC 1618 PPP over ISDN May 1994

       Configure-Request SHOULD be tried twice for each mode before
       switching in rotation.  This ensures that sufficient time is
       available for a response to arrive from the peer.
       Max-Configure MUST be set such that the cumulative attempts
       result in no more than 59 seconds of time before disconnect.
       It is preferable that the usual limit of 30 seconds be
       observed.
    Prior Configuration
       By prior configuration, PPP MAY also be used with other
       encodings.  Because of difficulty distinguishing them, it is
       not recommended that these encodings be automatically detected.
       Terminal adapters conforming to V.120 [4] can be used as a
       simple interface to workstations.  Asynchronous HDLC framing
       [2] is accepted at the R reference point.  The terminal adapter
       provides async-sync conversion.  Multiple B-channels can be
       used in parallel.  Unfortunately, V.120 has a framing mode of
       its own for rate adaptation, which is difficult to distinguish
       from Frame Relay, and which can confuse in-band frame
       detection.  V.120 is not interoperable with bit-synchronous
       links, since V.120 does not provide octet-stuffing to bit-
       stuffing conversion.  Therefore, V.120 is deprecated in favor
       of more modern standards, such as "PPP in Frame Relay".
       The "Bandwidth On Demand Interoperability Group" has defined a
       proposal called BONDING.  Multiple B-channels can be used in
       parallel.  BONDING has an initialization period of its own,
       which might conflict with the simple detection technique
       described above, and requires extensive individual
       configuration in some current implementations when multiple B-
       channels are involved.  It is recommended that the PPP Multi-
       Link Procedure be used instead of BONDING.

3. Framing

 For B-channels, in the absence of prior configuration, the
 implementation MUST first use bit-synchronous HDLC [2], as opposed to
 other framings, for initial link establishment.  This assumes that
 circuit-switched communications are generally [host | router] to
 [host | router].
 By prior configuration, octet-synchronous HDLC [2] is recommended
 where the network termination equipment interfaces directly to the T

Simpson [Page 3] RFC 1618 PPP over ISDN May 1994

 reference point, and octet boundaries are available at the time of
 framing.  Such equipment is likely to be highly integrated, and the
 elimination of bit-synchronous hardware can reduce the part count,
 resulting in lower cost interfaces and simpler configuration.
 Octet-synchronous HDLC MUST be used with NRZ bit encoding.
 For D-channels, by default no data service is expected.  By prior
 configuration, "PPP in X.25" or "PPP in Frame Relay" framing MAY be
 used.
 Despite the fact that HDLC, LAPB, LAPD, and LAPF are nominally
 distinguishable, multiple methods of framing SHOULD NOT be used
 concurrently on the same ISDN channel.  There is no requirement that
 PPP recognize alternative framing techniques, or switch between
 framing techniques without specific configuration.

4. Out-of-Band signaling

 Experience has shown that the LLC Information Element is not reliably
 transmitted end to end.  The deployment of compatible switches is too
 limited, and the subscription policies of the providers are too
 diverse.  Therefore, transmission of the LLC-IE SHOULD NOT be relied
 upon for framing or encoding determination.
 No LLC-IE values which pertain to PPP have been assigned.  Any other
 values which are received are not valid for PPP links, and can be
 ignored for PPP service.
 As an alternative administrative measure, multiple directory numbers
 can point to the same physical access facility, by binding particular
 services to each directory number.  The called party identifier has
 proven to be reliably provided by the local switch.
 When a called party identifier is used, or when a future LLC-IE value
 is assigned to PPP and the PPP value is received, if the LCP has not
 had the administrative Open event, the call MUST be rejected.
 Receivers MUST NOT accept an incoming call, only to close the circuit
 or ignore packets from the circuit.

Simpson [Page 4] RFC 1618 PPP over ISDN May 1994

5. Configuration Details

 The LCP recommended sync configuration options apply to ISDN links.
 The standard LCP sync configuration defaults apply to ISDN links.
 The typical network feeding the link is likely to have a MRU of
 either 1500, or 2048 or greater.  To avoid fragmentation, the
 Maximum-Transmission-Unit (MTU) at the network layer SHOULD NOT
 exceed 1500, unless a peer MRU of 2048 or greater is specifically
 negotiated.
 Instead of a constant value for the Restart timer, the exponential
 backoff method is recommended.  The Restart Timer SHOULD be 250
 milliseconds for the initial value, and 3 seconds for the final
 value.
 Implementations that include persistent dialing features, such as
 "demand dialing" or "redialing", SHOULD use mechanisms to limit their
 persistence.  Examples of such mechanisms include exponential
 backoff, and discarding packet queues after failure to complete link
 establishment.  In some implementations, discarding the transmit
 queue can temporarily remove the stimulus to retry the connection.

Security Considerations

 Security issues are not discussed in this memo.

References

 [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", RFC
       1548, Daydreamer, December 1993.
 [2]   Simpson, W., Editor, "PPP in HDLC Framing", RFC 1549, 
       Daydreamer, December 1993.
 [3]   Stallings, W, "ISDN and Broadband ISDN - 2nd ed", Macmillan,
       1992.
 [4]   CCITT Recommendations I.465 and V.120, "Data Terminal Equipment
       Communications over the Telephone Network with Provision for
       Statistical Multiplexing", CCITT Blue Book, Volume VIII,
       Fascicle VIII.1, 1988.

Simpson [Page 5] RFC 1618 PPP over ISDN May 1994

Acknowledgments

 This design was inspired by previous drafts of C. Frost, B. Gorsline,
 D. Leifer, K. Muramaki, S. Sheldon, K. Sklower, and T. Sugawara.
 Thanks to Oliver Korfmacher (NetCS) for European considerations, Dory
 Leifer (University of Michigan) for technical details and called
 party signalling, and Vernon Schryver (Silicon Graphics) regarding
 handling of link misconfiguration and timeouts.
 Special thanks to Morning Star Technologies for providing computing
 resources and network access support for writing this specification.

Chair's Address

 The working group can be contacted via the current chair:
    Fred Baker
    Advanced Computer Communications
    315 Bollay Drive
    Santa Barbara, California  93117
    EMail: fbaker@acc.com

Author's Address

 Questions about this memo can also be directed to:
    William Allen Simpson
    Daydreamer
    Computer Systems Consulting Services
    1384 Fontaine
    Madison Heights, Michigan  48071
    EMail: Bill.Simpson@um.cc.umich.edu
           bsimpson@MorningStar.com

Simpson [Page 6]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1618.txt · Last modified: 1994/05/11 01:18 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki