PPP over ISDN
How to run PPP over ISDN channels, and which framing, encoding and timer choices make different vendors interoperate.
Simpson, W., "PPP over ISDN", RFC 1618, DOI 10.17487/RFC1618, May 1994, <https://www.rfc-editor.org/info/rfc1618>.
@misc{rfc1618,
series = {Request for Comments},
number = 1618,
howpublished = {RFC 1618},
publisher = {RFC Editor},
doi = {10.17487/RFC1618},
url = {https://www.rfc-editor.org/info/rfc1618},
author = {W. Simpson},
title = {{PPP over ISDN}},
pagetotal = 7,
year = 1994,
month = may,
} RFC text
Contents
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.
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 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.
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
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
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.
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.
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
AI ELI5
On this page
§1Why PPP Fits ISDN
RFC 1548 defines the Point-to-Point Protocol (PPP) as a standard way to carry multi-protocol datagrams over point-to-point links. RFC 1618 describes its use over ISDN (Integrated Services Digital Network) switched circuits. An ISDN B-channel is by definition a point-to-point circuit, so PPP suits it well.
The ISDN Primary Rate Interface (PRI) can carry many B-channel links at once. PPP's LCP and NCP mechanisms reduce or remove hand configuration there and make it easier for different implementations to talk. The D-channel can also carry PPP packets if suitably framed, but it has limited bandwidth and often only reaches a local switch.
The RFC says PPP is not designed for multi-point or multi-access environments. It also admits there is unlikely ever to be one single worldwide ISDN, so it describes a few common implementations to promote interoperability.
An ISDN channel is a private pipe between two ends, which is exactly what PPP expects. This RFC explains how to hook the two together.
§2Physical Layer Requirements
PPP treats ISDN channels as bit or octet oriented synchronous links. The links MUST be full-duplex, but may be dedicated or circuit-switched. PPP gives the physical layer a stream of whole octets, with no provision for sub-octets, and the stream is applied mainly at the R or T reference points of the ISDN wiring model.
PPP places no limit on transmission rate beyond what the ISDN channel interface itself has. It does not require control signals, though using them when available can give more functionality and performance. Some framing techniques may need them, and that is outside this specification.
The line has to let both sides talk at the same time, like a phone call rather than a walkie-talkie. PPP does not care how fast the line is.
§2.1Bit Encoding and Automatic Detection
Encoding and scrambling are the job of the DTE/DCE equipment and are outside the scope. Still, the RFC recommends a default: the D-channel LAPD interface needs NRZ encoding at the T reference point, so NRZ is the recommended default on the B-channel there too. That lets frames move easily between B and D channels. Where encoding can be configured, NRZI is the recommended alternative to ensure a minimum density of ones on a clear B-channel. Inverted NRZ, used historically by some implementations, is deprecated.
Implementations that want to work with several encodings MAY detect them automatically, which matters most on Primary Rate Interfaces. The only reliable method is to switch between supported encodings. An LCP Configure-Request SHOULD be tried twice per mode before rotating to the next. Max-Configure MUST be set so the attempts total no more than 59 seconds before disconnect, though the usual limit of 30 seconds is preferred.
By prior configuration, other encodings may be used, but they are not recommended for auto-detection. The RFC deprecates V.120 terminal adapters, whose own rate-adaptation framing is hard to tell apart from Frame Relay and is not interoperable with bit-synchronous links. It also recommends the PPP Multi-Link Procedure instead of BONDING for using several B-channels in parallel.
Two sides must agree how to write the ones and zeros on the wire. The RFC picks a favourite, and if a side is unsure it tries each way in turn, giving each a couple of tries, until the other end answers.
§3Framing
On B-channels with no prior configuration, an implementation MUST first use bit-synchronous HDLC (from RFC 1549) for initial link establishment. This assumes that circuit-switched calls are generally host or router to host or router.
By prior configuration, octet-synchronous HDLC is recommended where the network termination equipment connects directly to the T reference point and octet boundaries are available. That equipment can drop bit-synchronous hardware, lowering part count and cost, and octet-synchronous HDLC MUST be used with NRZ bit encoding.
On D-channels, no data service is expected by default. By prior configuration, 'PPP in X.25' or 'PPP in Frame Relay' framing MAY be used. Multiple framing methods SHOULD NOT be used at once on the same ISDN channel, and PPP need not recognise or switch between framings without specific configuration.
Framing is how you wrap each message so the receiver knows where one ends and the next begins. Start with the standard wrapping unless both sides were set up for another, and do not mix wrappings on one line.
| Channel | Default | By prior configuration |
|---|---|---|
| B-channel THIS RFC | Bit-synchronous HDLC (MUST be tried first) | Octet-synchronous HDLC, with NRZ |
| D-channel | No data service expected | PPP in X.25 or PPP in Frame Relay |
§4Out-of-Band Call Signaling
Experience showed that the LLC Information Element (LLC-IE) is not reliably carried end to end, because compatible switches are rare and provider policies vary. So its transmission SHOULD NOT be relied on to decide framing or encoding. No LLC-IE values for PPP have been assigned, and other values received are not valid for PPP links and can be ignored.
As an administrative alternative, several directory numbers can point to one physical access facility, each bound to a particular service. The called party identifier has proven to be reliably provided by the local switch.
When a called party identifier is used, or if a PPP value is ever assigned and received, a call MUST be rejected if LCP has not had the administrative Open event. Receivers MUST NOT accept an incoming call only to close the circuit or ignore its packets.
The phone network's extra hints about a call are not trustworthy, so the RFC suggests giving each service its own phone number. And if you are not ready to answer, do not pick up and then hang up on the caller.
§5Configuration Details
The LCP recommended sync configuration options and the standard LCP sync defaults apply to ISDN links. The network feeding the link typically has an MRU of either 1500, or 2048 or greater, so to avoid fragmentation the network-layer MTU SHOULD NOT exceed 1500 unless a peer MRU of 2048 or greater is specifically negotiated.
Instead of a constant Restart timer, exponential backoff is recommended: the Restart Timer SHOULD start at 250 milliseconds and end at 3 seconds. Implementations with persistent dialing, such as demand dialing or redialing, SHOULD limit their persistence, for example with exponential backoff or by discarding packet queues after a failed attempt to set up the link. Discarding the transmit queue can temporarily remove the stimulus to retry.
Do not make packets bigger than the line's usual limit, and when a call fails, wait a bit longer each time before redialing instead of hammering the phone.
§6Security Considerations
The RFC states only that security issues are not discussed in the memo. Any authentication or protection of the link is therefore left to PPP itself and to the deployment, not to this document.
This RFC does not say anything about keeping the line safe from snoopers.