Network Working Group W A Simpson Internet Draft Daydreamer expires in six months September 1993 PPP over ISDN draft-ietf-pppext-isdn-02.txt Status of this Memo 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@ucdavis.edu mailing list. Distribution of this memo is unlimited. This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. Simpson expires in six months [Page i] DRAFT PPP over ISDN September 1993 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. 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." [7] 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 expires in six months [Page ii] DRAFT PPP over ISDN September 1993 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. Simpson expires in six months [Page 1] DRAFT PPP over ISDN September 1993 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. 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 Simpson expires in six months [Page 2] DRAFT PPP over ISDN September 1993 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 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 [6] 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" [4]. 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 Simpson expires in six months [Page 3] DRAFT PPP over ISDN September 1993 multilink procedure [5] 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]. The implementation MAY change to X.25 or Frame Relay framing, when those frames are detected. By prior configuration, octet-synchronous HDLC [2] is recommended where the network termination equipment interfaces directly to the T 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" [3] or "PPP in Frame Relay" [4] 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. Simpson expires in six months [Page 4] DRAFT PPP over ISDN September 1993 4. In-Band Format Detection It is possible to connect an ISDN circuit to an X.25 or Frame Relay circuit. This results in the receipt of a different type of frame. These other valid formats for PPP framing MUST be detected. First, the frames MUST be checked for a valid FCS. All of these framing methods use the same FCS. Those frames which fail the FCS test MUST be silently discarded. The PPP HDLC framing is easily distinguished from X.25 or Frame Relay frames. Initial PPP frames always start with the sequence ff-03-c0- 21. Initial X.25 frames will have a first octet which is odd (the least significant bit is 1), and which likely will have the value 1 or 3. The implementation MUST check for a valid Control octet, and SHOULD check for a supported encapsulation. If a valid X.25 frame is detected, and X.25 is supported and enabled, the implementation MUST change to the "PPP in X.25" [3] framing method. Initial Frame Relay frames have a first octet which is even (the least significant bit is 0). The implementation MUST check for a valid Control octet, and SHOULD check for a supported encapsulation. If a valid Frame Relay frame is detected, and Frame Relay is supported and enabled, the implementation MUST change to the "PPP in Frame Relay" [4] framing method. An implementation that does not support X.25 or Frame Relay framing MAY continue to send PPP HDLC framing after recognizing possible X.25 or Frame Relay frames. When the Restart Counter reaches 0, the current configuration attempt is abandoned as usual. The accidental connection of a PPP circuit to feed a multipoint network (or multicast group) MUST result in link configuration failure. An implementation that supports X.25 or Frame Relay framing can detect multiple responses to the LCP Configure-Request, with the same Identifier, coming from what appear to be multiple LAPB or LAPD addresses. Implementations SHOULD follow good error recovery practice, including logging or reporting information about the causes of link configuration failure. Examples of such information include the type and initial octets of X.25 or Frame Relay frames. Some implementations might be physically unable to either log or report such information. Simpson expires in six months [Page 5] DRAFT PPP over ISDN September 1993 5. 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. 6. 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. Simpson expires in six months [Page 6] DRAFT PPP over ISDN September 1993 Security Considerations Security issues are not discussed in this memo. References [1] Simpson, W. A., "The Point-to-Point Protocol (PPP)", work in progress. [2] Simpson, W.A., "PPP in HDLC Framing", work in progress. [3] Simpson, W.A., "PPP in X.25", work in progress. [4] Simpson, W.A., "PPP in Frame Relay", work in progress. [5] Sklower, K., "PPP MultiLink Procedure", work in progress. [6] CCITT, "Recommendation V.120: Data Communications over the Telephone Network", Blue Book, ITU 1988 [7] Stallings, W, "ISDN and Broadband ISDN - 2nd ed", Macmillan, 1992. Acknowledgments This design was inspired by the paper "Parameter Negotiation for the Multiprotocol Interconnect", Keith Sklower and Clifford Frost, University of California, Berkeley, 1992, unpublished. Other details were gleaned from "Determination of Encapsulation of Multi-protocol Datagrams in Circuit-switched Environments", Keith Sklower, University of California, Berkeley, IETF IPLPDN WG draft, July 1993. That paper credits previous work "A Subnetwork Control Protocol for ISDN Circuit-Switching", Leifer, D., Sheldon, S. and Gorsline, B.; IETF IPLPDN WG draft, March 1991; and "A Negotiation Protocol for Multiple Link-Protocol over ISDN Circuit-Switching", Muramaki, K. and Sugawara, T.; IETF IPLPDN WG draft, May 1992. 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. Special thanks to Morning Star Technologies for providing computing resources and network access support for writing this specification. Simpson expires in six months [Page 7] DRAFT PPP over ISDN September 1993 Chair's Address The working group can be contacted via the current chair: Fred Baker Advanced Computer Communications 315 Bollay Drive Santa Barbara, California, 93111 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 Simpson expires in six months [Page 8] DRAFT PPP over ISDN September 1993 Table of Contents 1. Introduction .......................................... 1 2. Physical Layer Requirements ........................... 2 3. Framing ............................................... 4 4. In-Band Format Detection .............................. 5 5. Out-of-Band signaling ................................. 6 6. Configuration Details ................................. 6 SECURITY CONSIDERATIONS ...................................... 7 REFERENCES ................................................... 7 ACKNOWLEDGEMENTS ............................................. 7 CHAIR'S ADDRESS .............................................. 8 AUTHOR'S ADDRESS ............................................. 8