Multiprotocol Encapsulation over ATM Adaptation Layer 5
obsoletes
- rfc-1483 — Multiprotocol Encapsulation over ATM Adaptation Layer 5
Extracted elements (27)
LLC encapsulation tends to require fewer VCs in a multiprotocol environment. VC multiplexing reduces fragmentation overhead and can reduce per-packet processing; for example, an IPv4 TCP control packet with no options exactly fits one ATM cell.
The Common PDU Header and Trailer from 802.6 frames are included in the encapsulation to enable pipelining at egress bridges: the BAsize field allows the egress bridge to begin transmitting the segmented PDU to the 802.6 subnetwork before it has received the entire PDU.
ATM LAN Emulation uses the VC multiplexing encapsulation formats for Bridged Ethernet/802.3 and 802.5 (without LAN FCS), but the initial PAD field defined in this memo is used as an LE header and might not be set to all zeros.
If it is desired to use PPP facilities and a point-to-point relationship exists between peers, RFC 2364 (PPP over AAL5) applies rather than this memo. This memo does not cover PPP encapsulation.
A bridge using Bridged Ethernet/802.3 encapsulation with preserved LAN FCS MUST include Ethernet minimum-size padding. Without FCS, padding MAY be included or omitted, but the receiving bridge MUST be able to insert padding before forwarding to an Ethernet/802.3 subnetwork.
An ATM bridge interface MUST be able to flood, forward, and filter bridged PDUs. To support dynamic MAC learning, bridged PDUs sent through the ATM network MUST conform to the LLC encapsulation format in section 5.
For bridged PDUs in LLC Encapsulation, the SNAP header MUST use OUI 0x00-80-C2 (802.1 organization code) and the two-octet PID MUST specify the bridged media type and whether the original LAN FCS is preserved.
For PVCs, the protocol type carried over each VC MUST be determined by configuration. For SVCs, the encapsulation method negotiation MUST follow RFC 1755 (and RFC 2331).
IP datagrams MUST NOT use the NLPID format (even though NLPID 0xCC exists for IP). Instead, IP datagrams MUST be identified by a SNAP header with LLC 0xAA-AA-03, OUI 0x00-00-00, and EtherType 0x08-00.
Padding octets MUST be added after the PID field to align the bridged PDU's data field to a four-octet boundary. The MAC address bit ordering MUST match what it would be on the originating LAN or MAN (canonical for Ethernet, 802.5/FDDI format for 802.5).
Routed and bridged PDUs MUST be encapsulated within the Payload field of an AAL5 CPCS-PDU. The AAL5 message mode service in the non-assured mode of operation MUST be used; the corrupted delivery option MUST NOT be used.
The CPI (Common Part Indicator) field in the AAL5 CPCS-PDU Trailer MUST be coded as 0x00.
The LLC header value 0xFE-FE-03 MUST be used to identify a routed PDU in ISO NLPID format. A one-octet NLPID field follows the LLC header and MUST NOT be 0x00 (Null Network Layer).
The RFC 2427 FR-SSCS encapsulation MUST be used when Frame Relay Network Interworking or transparent mode Service Interworking are used, but is NOT RECOMMENDED for other applications over the AAL5 CPCS.
When a LLC-encapsulated routed or bridged PDU is sent within a VPN over AAL5, a VPN encapsulation header MUST be prepended to the appropriate PDU format from sections 5.1 or 5.2.
Two encapsulation methods are defined: LLC Encapsulation, which multiplexes multiple protocols over a single ATM VC using an IEEE 802.2 LLC header prefix, and VC Multiplexing, which binds a VC to a single protocol type and carries no per-PDU protocol header.
Receivers must trust that senders have correctly identified the encapsulated protocol; there is no mechanism to verify proper protocol identification. The encapsulation itself is not believed to introduce exploitable properties, but protocols above the encapsulation layer may be subject to various attacks.
The bridging architecture discussed in section 7 has the same vulnerabilities as other bridging architectures, including susceptibility to MAC flooding and spoofing. System security may also be affected by ATM network properties; the ATM Forum security framework and specification are referenced as relevant.
Bridged 802.6 LLC Encapsulation payload: LLC 0xAA-AA-03 + OUI 0x00-80-C2 + PID 0x00-0B + Common PDU Header (Reserved, BEtag, BAsize) + MAC destination address + remainder + Common PDU Trailer. CRC-32 presence is indicated by the CIB bit in the MAC frame header, so the same PID is used either way.
Bridged Ethernet/802.3 LLC Encapsulation payload: LLC 0xAA-AA-03 + OUI 0x00-80-C2 + PID 0x00-01 (with FCS) or 0x00-07 (without FCS) + PAD 0x00-00 + MAC destination address + remainder of MAC frame + optional LAN FCS.
In VC Multiplexing for bridged protocols, the payload format is identical to Section 5.2 except that the LLC, OUI, and PID fields are omitted; presence or absence of LAN FCS is indicated implicitly by the VC, not by a PID value.
In VC Multiplexing for routed protocols, the AAL5 CPCS-PDU Payload contains only the carried PDU (up to 2^16 - 1 octets) with no LLC or SNAP prefix.
Routed NLPID-formatted PDU payload: LLC 0xFE-FE-03 (3 octets) + NLPID (1 octet) + PDU (up to 2^16 - 4 octets). Routed non-NLPID (e.g., IPv4) payload: LLC 0xAA-AA-03 + OUI 0x00-00-00 + EtherType (2 octets) + PDU (up to 2^16 - 9 octets).
The AAL5 CPCS-PDU consists of a Payload field (up to 65535 octets), a PAD field (0–47 octets for cell alignment), and a fixed 8-octet Trailer: CPCS-UU (1 octet), CPI (1 octet), Length (2 octets), and CRC-32 (4 octets).
The LLC header for routed protocols in LLC Encapsulation is three one-octet fields: DSAP, SSAP, and Control. The Control field MUST be set to 0x03 (Unnumbered Information Command PDU).
The SNAP header consists of a 3-octet OUI (Organizationally Unique Identifier) followed by a 2-octet PID (Protocol Identifier). Its presence is indicated by LLC header value 0xAA-AA-03. OUI 0x00-00-00 means the PID is an EtherType.
The VPN Encapsulation Header format: LLC 0xAA-AA-03 (3 octets) + OUI 0x00-00-5E (3 octets) + PID 0x00-08 (2 octets) + PAD 0x00 (1 octet) + VPN-related OUI (3 octets) + VPN Index (4 octets), followed by the remainder of the PDU structured per section 5 or 6.