rfc-1618

PPP over ISDN

W. Simpson
date1994-05 streamIETF areaint wgpppext statusPROPOSED STANDARD pages7 canonicalhttps://www.rfc-editor.org/rfc/rfc1618 doi10.17487/RFC1618
This document describes the use of PPP over Integrated Services Digital Network (ISDN) switched circuits. [STANDARDS-TRACK]

Extracted elements (24)

design-rationale §5

Exponential backoff is recommended for the Restart timer rather than a constant value to better handle ISDN circuit-switched link conditions and persistent dialing scenarios.

routing, ip

design-rationale §2

NRZ encoding is recommended as the default over the B-channel at the T reference point because the D-channel LAPD interface requires NRZ at T, allowing frames to be easily exchanged between B and D channels.

routing, ip

design-rationale §2

NRZI is recommended as an alternative encoding to ensure a minimum ones density where required over the clear B-channel. Inverted NRZ (switching sense of mark and space) is deprecated as it was a historical workaround for bit-synchronous HDLC.

routing, ip

design-rationale §3

Octet-synchronous HDLC is recommended for equipment that interfaces directly to the T reference point because it eliminates bit-synchronous hardware, reducing part count, lowering cost, and simplifying configuration.

routing, ip

design-rationale §2

The PPP Multi-Link Procedure is recommended over BONDING for aggregating multiple B-channels because BONDING has its own initialization period that may conflict with auto-detection and requires extensive per-channel configuration.

routing, ip, multipath

design-rationale §2

V.120 is deprecated in favor of more modern standards such as 'PPP in Frame Relay' because V.120 is not interoperable with bit-synchronous links (it lacks octet-to-bit-stuffing conversion), and its framing mode is difficult to distinguish from Frame Relay.

routing, ip

interoperability-note §4

As an alternative to LLC-IE, 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.

routing, ip

interoperability-note §4

LLC-IE values pertaining to PPP have not been assigned; any LLC-IE values received are not valid for PPP links and can be ignored for PPP service. The LLC-IE is not reliably transmitted end-to-end due to limited compatible switch deployment and diverse provider subscription policies.

routing, ip

interoperability-note §5

The LCP recommended sync configuration options and standard LCP sync configuration defaults apply to ISDN links without modification.

routing, ip

normative-requirement §2 SHOULD

For automatic encoding detection, LCP Configure-Request SHOULD be tried twice for each mode before switching in rotation, to ensure sufficient time for a peer response.

routing, ip

normative-requirement §3 MUST

For B-channels, in the absence of prior configuration, the implementation MUST first use bit-synchronous HDLC for initial link establishment, as opposed to other framings.

routing, ip

normative-requirement §5 SHOULD

Implementations with persistent dialing features such as demand dialing or redialing SHOULD use mechanisms to limit their persistence, such as exponential backoff and discarding packet queues after failure.

routing, ip

normative-requirement §2 MUST

Max-Configure MUST be set such that cumulative attempts result in no more than 59 seconds of time before disconnect; the usual 30-second limit is preferable.

routing, ip

normative-requirement §3 SHOULD NOT

Multiple methods of framing SHOULD NOT be used concurrently on the same ISDN channel; there is no requirement that PPP recognize or switch between framing techniques without specific configuration.

routing, ip

normative-requirement §3 MUST

Octet-synchronous HDLC MUST be used with NRZ bit encoding when octet-synchronous framing is configured.

routing, ip

normative-requirement §2 MUST

PPP ISDN channels MUST be full-duplex, but MAY be either dedicated or circuit-switched.

routing, ip

normative-requirement §4 MUST NOT

Receivers MUST NOT accept an incoming call only to close the circuit or ignore packets from the circuit; the call must be properly rejected instead.

routing, ip, security

normative-requirement §5 SHOULD NOT

The MTU at the network layer SHOULD NOT exceed 1500 to avoid fragmentation, unless a peer MRU of 2048 or greater is specifically negotiated.

routing, ip

normative-requirement §5 SHOULD

The Restart Timer SHOULD be 250 milliseconds for the initial value and 3 seconds for the final value, using exponential backoff rather than a constant value.

routing, ip

normative-requirement §4 SHOULD NOT

Transmission of the LLC Information Element SHOULD NOT be relied upon for framing or encoding determination, as it is not reliably transmitted end to end.

routing, ip

normative-requirement §4 MUST

When a called party identifier is used or a PPP LLC-IE value is received, if the LCP has not had the administrative Open event, the call MUST be rejected.

routing, ip, security

protocol-element §1

The ISDN B-channel is used as the primary bearer for PPP traffic; it is a point-to-point circuit well-suited for PPP encapsulation. The Primary Rate Interface (PRI) may support many concurrent B-channel links.

routing, ip

protocol-element §1

The ISDN D-channel can carry PPP packets when suitably framed (via 'PPP in X.25' or 'PPP in Frame Relay'), but is limited in bandwidth and often restricts links to a local switch. By default, no data service is expected on the D-channel.

routing, ip

security-consideration §Security Considerations

Security issues are not discussed in this memo. The only security-relevant normative statement is that calls must be rejected when the LCP has not had the administrative Open event, preventing unauthorized circuit acceptance.

security, routing