RFC 1618

PPP over ISDN

📅 published May 1994, from ietf

1. PPP over ISDN 🎀

Okay bestie, this is RFC 1618, titled PPP over ISDN 💖 It's written by W. Simpson of Daydreamer and dates from May 1994. It's a Standards Track document, which means it's an actual spec people build against 🔥 The title block doesn't list anything it obsoletes or updates, so it's standing on its own. 💅

Status of This Memo ✨

This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🦋

Abstract 🌸

PPP ([1]) is the standard way to carry multi-protocol datagrams over point-to-point links. This doc explains how to use PPP over ISDN switched circuits 🧚

It came out of the Point-to-Point Protocol Working Group of the IETF, and comments go to the ietf-ppp@merit.edu mailing list 📬

Applicability 💜

This spec is for implementations that want to run the PPP encapsulation over ISDN point-to-point links. PPP is not designed for multi-point or multi-access environments, so don't try 🙈

"It is clear that there is never likely to be a single, monolithic, worldwide ISDN." [3] Real talk, ISDN is a whole mix of stuff. The goal here is to describe a few common implementations, out of the huge variety out there, to help everyone interoperate 🫶

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

1. Introduction ✨

PPP was built as a standard way to talk over point-to-point links 💅 It first showed up on short local lines, leased lines, and plain-old-telephone-service (POTS) using modems. As new packet services and faster lines show up, PPP is easy to deploy there too 🚀

This spec is mainly about using the PPP encapsulation over ISDN links. The ISDN B-channel is, by definition, a point-to-point circuit, so PPP is a perfect match 💖

The ISDN Primary Rate Interface (PRI) can support lots of B-channel links at once 👑 The PPP LCP and NCP mechanisms are super useful here because they cut down on hand configuration and make it way easier for different implementations to talk to each other 🫶

The ISDN D-channel can carry PPP packets too, as long as they're framed properly. It's limited on bandwidth though, and it often keeps communication to a local switch 🙈

ISDN terminology can be kind of confusing ngl 😭 So here's a quick picture of the reference points we'll use in the rest of the doc:

                   +-------+     +-------+     +-------+
               R   |       |  S  |       |  T  |       |   U
               +---+  TA   +--+--+  NT2  +--+--+  NT1  +---+
                   |       |     |       |     |       |
                   +-------+     +-------+     +-------+

Often these elements all live in one single device 🧚

2. Physical Layer Requirements 🦋

PPP treats ISDN channels as bit or octet oriented synchronous links. These links MUST be full-duplex, but they MAY be either dedicated or circuit-switched. Full-duplex is non-negotiable, bestie 💅

Interface Format

PPP shows up to the physical layer as an octet interface. There's no provision for sub-octets to be supplied or accepted, so don't even try 🙅 The octet stream is applied mainly at the R or T reference points 💜

Transmission Rate

PPP doesn't put any restrictions on transmission rate, other than whatever the particular ISDN channel interface can handle 🚀

Control Signals

PPP doesn't require control signals 🌈 When they're available, though, using them can give you more functionality and performance. The implications are discussed in [2].

Control signals MAY be required by some of the framing techniques described, and that's outside the scope of this spec 🫶

Encoding

The definition of various encodings and scrambling belongs to the DTE/DCE equipment in use, and it's outside the scope of this spec 🙌

PPP will work no matter how the bit stream is represented underneath, but lack of standards for transmission will hurt interoperability just as much as lack of data link standards 😭 The D-channel LAPD interface requires NRZ encoding at the T reference point. So as a default, it is recommended that NRZ be used over the B-channel interface at the T reference point. That way frames can move easily between the B and D channels ✨

When you can configure the encoding, NRZI is recommended as an alternative. It helps make sure there's a minimum ones density where it's needed over the clear B-channel, with caveats about the FCS [2] 🎀

Some implementations historically used Inverted NRZ (just flipping the sense of mark and space) to keep a minimum ones density with bit-synchronous HDLC. Inverted NRZ is deprecated now 💀

Automatic Detection

Implementations that want to interoperate with multiple encodings MAY choose to detect those encodings automatically. Automatic detection matters most for Primary Rate Interfaces, so you don't have to do a ton of pre-configuration 🧚 Only simple encodings are distinguished right now.

The only reliable detection method 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. That gives the peer enough time to respond 🕰️

Max-Configure MUST be set so that the cumulative attempts add up to no more than 59 seconds before disconnect. It's preferable that the usual limit of 30 seconds be observed 👑

Prior Configuration

With prior configuration, PPP MAY also be used with other encodings. Because they're hard to tell apart, it's not recommended that these encodings get automatically detected 🙈

Terminal adapters that conform to V.120 [4] can work as a simple interface to workstations. Asynchronous HDLC framing [2] is accepted at the R reference point, and the terminal adapter does the async-sync conversion. Multiple B-channels can be used in parallel 🦋

V.120 has its own framing mode for rate adaptation, though, and that's hard to tell apart from Frame Relay. It can also confuse in-band frame detection 😵 V.120 isn't interoperable with bit-synchronous links, because it doesn't do octet-stuffing to bit-stuffing conversion. So V.120 is deprecated in favor of more modern standards, like "PPP in Frame Relay" 💅

The "Bandwidth On Demand Interoperability Group" came up with a proposal called BONDING. Multiple B-channels can also be used in parallel with BONDING 🌸 But BONDING has its own initialization period, which might clash with the simple detection technique above. It also needs a lot of individual configuration in some current implementations once multiple B-channels are involved 😭 It's recommended that the PPP Multi-Link Procedure be used instead of BONDING ✨

3. Framing 🎀

For B-channels, without 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] 🧚

With prior configuration, octet-synchronous HDLC [2] is recommended where the network termination equipment connects directly to the T reference point and octet boundaries are available at framing time. This kind of equipment is likely to be highly integrated. Dropping bit-synchronous hardware can reduce the part count, which means lower cost interfaces and simpler configuration 💜 Octet-synchronous HDLC MUST be used with NRZ bit encoding.

For D-channels, no data service is expected by default. With prior configuration, "PPP in X.25" or "PPP in Frame Relay" framing MAY be used 🦋

HDLC, LAPB, LAPD, and LAPF are nominally distinguishable, but multiple framing methods SHOULD NOT be used concurrently on the same ISDN channel 🙅 PPP doesn't have to recognize alternative framing techniques, and it doesn't have to 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 😭 Compatible switches aren't deployed widely enough, and provider subscription policies are way too diverse. So transmission of the LLC-IE SHOULD NOT be relied upon for framing or encoding determination 🙅

No LLC-IE values pertaining to PPP have been assigned. Any other values received are not valid for PPP links, and they can be ignored for PPP service 💅

As an alternative administrative measure, multiple directory numbers can point to the same physical access facility, with particular services bound 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 that PPP value is received, the call MUST be rejected if the LCP hasn't had the administrative Open event yet. Receivers MUST NOT accept an incoming call just to close the circuit or ignore packets from the circuit. Not it, bestie 🙅‍♀️

5. Configuration Details 🧚

The LCP recommended sync configuration options apply to ISDN links 💖

The standard LCP sync configuration defaults also apply to ISDN links ✨

The typical network feeding the link is likely to have an 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 include exponential backoff, and discarding packet queues after a failure to complete link establishment. In some implementations, discarding the transmit queue can temporarily remove the stimulus to retry the connection 🫶

Security Considerations ✨

Okay bestie, this is the moment of truth 😭 Security issues are not discussed in this memo. Zero words on it, not even a little 💀 so don't go assuming anything is covered here 🙈

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. 🌸

Acknowledgments 🫶

This design was inspired by previous drafts of C. Frost, B. Gorsline, D. Leifer, K. Muramaki, S. Sheldon, K. Sklower, and T. Sugawara. These people really got the ball rolling, so big love to them 💖

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. Iconic contributions, every single one 👑

Special thanks to Morning Star Technologies for providing computing resources and network access support for writing this specification. They literally made this whole thing happen 🌈✨

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
📦 where this page comes from