PPP Over Asynchronous Transfer Mode Adaptation Layer 2 (AAL2)
Extracted elements (26)
A 16-bit CRC is added to each PPP payload because certain PPP-encapsulated protocols such as RTP header compression require the link layer to provide packet error detection, which is not otherwise guaranteed by AAL2.
AAL2 CPS combines segmentation, reassembly, and multiplexing in a single layer; a receiver extracts each CPS-PKT as soon as it arrives without waiting for a full multiplexed frame, reducing latency and limiting cell-loss damage to only the packets in the lost cell.
AAL2 is chosen over AAL5 for PPP transport of small payloads (e.g., compressed voice/RTP) because SSSAR+CPS incurs only 6 bytes of encapsulation overhead per PPP payload versus 8 bytes for an AAL5 trailer, and eliminates AAL5 PAD overhead through CPS-level multiplexing.
Multiple CIDs per PPP session are permitted to support a multiple-class real-time transport service, using the AAL2 layer for link fragmentation and interleaving across traffic classes (detailed in companion RFC 3337).
PPP/AAL2 is preferred over PPP/PPPMUX/AAL5 because PPPMUX still requires an AAL5 frame wrapper (adding 8 bytes trailer plus an average 24 bytes of PAD), whereas AAL2 CPS multiplexes directly and cells are fully packed as long as frames arrive before TIMER_CU expiry.
PPP over AAL2 allows co-existence of multiple SSCS types within the same AAL2 VCC; CIDs not used for PPP over AAL2 may run conventional AAL2 SSCS functions, so implementations must not assume a uniform SSCS across all CIDs on a connection.
An implementation of PPP over AAL2 MAY use one or more AAL2 Channel Identifiers (CIDs) for transport of PPP packets associated with each PPP session.
Applications implementing PPP over AAL2 MUST meet all the requirements of PPP as defined in RFC 1661.
Both endpoints of a PPP session over AAL2 MUST agree on the number, SSCS mapping, and values of AAL2 CIDs that will be used for the PPP session.
The AAL2 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 AAL2 virtual connection used for PPP MUST be full-duplex and point-to-point. It MAY be either dedicated (permanent, provisioned) or switched (set up on demand).
The values of AAL2 CIDs to be used for a PPP session MAY be obtained from static provisioning (PVC) or from Q.2630.2 signaling (SPVC or SVC).
By default, PPP over AAL2 uses 16-bit CRC encapsulation for all packets and a default Maximum-Receive-Unit (MRU) of 1500 bytes.
Multiple CIDs within an AAL2 VCC may each run different SSCS functions, allowing co-existence of PPP over AAL2 CIDs alongside conventional AAL2 CIDs on the same virtual connection.
PPP over AAL2 uses the Service Specific Segmentation and Reassembly Sublayer (SSSAR, ITU-T I.366.1) to segment PPP packets into AAL2 CPS frames for transport, with the 16-bit CRC appended before segmentation.
The link state for PPP over AAL2 can be derived from type 3 fault management packets carried in-band within a given AAL2 CID flow, supplying LCP state machine Up/Down events.
The PPP/AAL2 service interface boundary presents an octet service interface to the AAL2 layer; there is no provision for sub-octet units, and no transmission rate restrictions are imposed on ATM layer traffic descriptor parameters.
UUI code-point 26 indicates the final (or only) SSSAR frame of a PPP packet; UUI code-point 27 indicates a non-final (intermediate) fragment. All intermediate frames carry UUI=27 and the last carries UUI=26.
A receiver must be able to trust that the sender has correctly identified the encapsulated protocol and has not been spoofed or compromised, and that the ATM transport network between them has not been compromised.
PPP-level authentication does not protect against man-in-the-middle attacks; applications requiring such protection are encouraged to use authentication headers, encrypted payloads, and/or ATM-layer security services per ATM Forum af-sec-0100.002.
PPP over AAL2 sessions MUST follow the PPP link operation state machine (RFC 1661), which includes an authentication phase using PAP or CHAP before any network-layer packets are exchanged, allowing a receiver to authenticate the sender.
When PPP over AAL2 uses a subset of CIDs on a virtual connection, an endpoint cannot assume that PPP session authentication and security mechanisms also protect the non-PPP-encapsulated CIDs running on the same virtual connection.
CRC-16 is computed using generator polynomial G(x) = x^16 + x^12 + x^5 + 1, identical to Q.921 FCS. The ones complement of the CRC remainder is appended to each PPP frame, covering the Protocol ID and Information fields.
The AAL2 CPS-PKT consists of a Channel ID (CID, 8 bits), Length Indication (LI, 6 bits), User-to-User Indication (UUI, 5 bits), Header Error Control (HEC, 5 bits), and CPS-INFO payload (45 or 64 bytes * 8 bits).
The CPS-PDU carries one or more CPS-PKTs multiplexed in a single PDU payload, preceded by a Start Field (STF, 1 byte) used to locate the first CPS-PKT after cell loss, with optional PAD at the end.
The PPP over AAL2 payload encapsulation format contains: CID (8 bits), LI (6 bits), UUI (5 bits), HEC (5 bits), PPP Protocol ID (8 or 16 bits), Information field (variable), and a 16-bit CRC (CRC-16).