PPP Over AAL5
Extracted elements (31)
ACFC, ACCM, and FCS Alternatives LCP options are explicitly prohibited because AAL5 already provides its own framing and CRC; these HDLC-derived options would be meaningless or harmful when PPP runs directly over AAL5.
PPP uses AAL5 as a framing mechanism rather than ISO 3309 HDLC because ATM networks configured with point-to-point connections provide a packet delivery service with error detection, making AAL5 a natural framing layer for PPP without needing HDLC's byte-stuffing overhead.
Two encapsulation techniques (VC-multiplexed and LLC encapsulated PPP) are both mandated because VC-multiplexing is more efficient (no per-PDU header overhead) while LLC encapsulation enables multi-protocol sharing of a single VC and is required for Frame Relay/ATM interworking with RFC 1973.
Frame Relay/ATM FRF.8 interworking units are exempted from the requirement to support VC-multiplexed PPP, allowing them to remain compliant with FRF.8 when the PPP over AAL5 endpoint interoperates with an RFC 1973 endpoint.
When an ATM AAL5 PVC is in the 'Stopped' state, it is RECOMMENDED that the implementation wait for Configure-Requests rather than originating them, following the 'Stopped State' implementation option in RFC 1661 section 4.2.
An implementation connecting through a Frame Relay/ATM FRF.8 service interworking unit to an RFC 1973 endpoint MUST use LLC encapsulated PPP payloads.
An implementation MUST support LLC encapsulated PPP payloads on PVCs by mutual configuration or negotiation of both endpoints.
An implementation MUST support VC-multiplexed PPP payloads by mutual configuration or negotiation of both endpoints.
For SVC setup, an implementation MUST negotiate using the Q.2931 Annex C procedure, encoding the B-LLI information element to signal either VC-multiplexed PPP or LLC encapsulated PPP.
Implementations originating a call offering both VC-multiplexed and LLC-encapsulated PPP MUST be able to negotiate the use of LLC-encapsulated PPP.
LCP framing options MUST be actively negotiated independently by bridging converters for each AAL5 section of a multi-section PPP link, independent of LCP framing options in use by other physical layer sections.
On a PVC, if an unexpected encapsulation transition is detected after Network-layer Protocol phase, the PPP Link MUST tear down active NCPs, SHOULD generate an error message, enter the Termination state, and silently drop all received packets.
Once PPP has entered Network-layer Protocol phase, if a frame arrives using an alternate but equivalent encapsulation (encapsulation transition), then for an SVC the PPP Link MUST immediately clear the call with cause value 111 ('protocol error, unspecified').
The AAL5 layer MUST provide control signals to the PPP layer indicating when the virtual connection has become connected or disconnected, supplying the 'Up' and 'Down' events to the LCP state machine.
The ATM AAL5 virtual connection MUST be full-duplex and point-to-point; it MAY be either dedicated (permanent) or switched (on-demand).
The called implementation MUST be able to accept an incoming call that offers LLC-encapsulated PPP. It MUST reject a call setup request that only offers an encapsulation it does not support.
The Magic Number LCP configuration option is RECOMMENDED. An implementation MUST NOT request, and MUST reject, FCS Alternatives, Address-and-Control-Field-Compression (ACFC), and Asynchronous-Control-Character-Map (ACCM) options.
The Protocol Field Compression (PFC) LCP option is NOT RECOMMENDED. The MRU option MUST NOT be negotiated to a size larger than the maximum CPCS-SDU size specified in the virtual connection's traffic contract.
When originating a switched virtual circuit, the caller MUST request in the SETUP message either VC-multiplexed PPP, LLC-encapsulated PPP, or both. When offering both, they are encoded within a Broadband Repeat Indicator IE in preference order.
When using LLC encapsulation, endpoints MUST NOT send packets belonging to any protocol that has an active NCP within the PPP session as non-PPP LLC flows. They SHOULD do packet scheduling that minimizes performance impact on QoS commitments.
For LLC encapsulated SVC calls, the Q.2931 B-LLI element user information layer 2 protocol field is encoded to select LAN Logical Link Control (ISO/IEC 8802-2) in octet 6.
For VC-multiplexed SVC calls, the Q.2931 B-LLI element user information layer 3 protocol field is encoded to select ISO/IEC TR 9577 in octet 7, with extension octets specifying an IPI value of PPP (0xCF).
The AAL5 CPCS-PDU Length field (2 octets) indicates the payload length in octets, with a maximum of 65535. A Length field coded as 0x00 signals the abort function.
The CPI (Common Part Indicator) field in the AAL5 CPCS-PDU trailer aligns the trailer to 64 bits. When only the 64-bit alignment function is used, this field shall be coded as 0x00.
For PVC-based ATM networks, security is implicit in the service provider's administration of Permanent Virtual Circuits. The probability of a breach caused by mis-routed ATM cells is considered negligible.
For SVC-based ATM networks, PPP over AAL5 leverages existing PAP/CHAP authentication mechanisms, providing security parity with Internet dial-up access. Applications requiring stronger security SHOULD use authentication headers, encrypted payloads, and/or ATM-layer security services.
When using LLC-encapsulated PPP, an endpoint MUST NOT assume that PPP session authentication and related security mechanisms also secure other LLC-encapsulated flows on the same virtual connection. Each non-PPP flow is unprotected by PPP-layer authentication.
Encapsulation detection uses byte-sequence recognition: LLC-encapsulated LCP packets begin with fe-fe-03-cf-c0-21 (first 6 octets of AAL5 frame); VC-multiplexed LCP packets begin with c0-21 (first 2 octets). When an LCP Configure-Request is recognized, the PPP link enters Link Establishment phase.
A VC-multiplexed PPP frame constitutes the CPCS-PDU payload and consists of: Protocol ID (8 or 16 bits), Information, and optional Padding, as defined by RFC 1661.
LLC encapsulated PPP over AAL5 encodes the CPCS-PDU payload as: LLC header (0xFE 0xFE 0x03, 3 bytes), NLPID for PPP (0xCF, 1 byte), PPP Protocol Identifier (1 or 2 octets), and PPP information field followed by padding.
The AAL5 CPCS-PDU trailer consists of CPCS-UU (1 octet), CPI (1 octet), Length (2 octets indicating payload length up to 65535 octets), and CRC (4 octets protecting the entire CPCS-PDU). A PAD field of 0–47 octets aligns the PDU to ATM cell boundaries.