Multiprotocol Encapsulation over ATM Adaptation Layer 5

The 802.6 Common PDU Header and Trailer are included in the ATM encapsulation to enable pipelining at the egress bridge: the BAsize field allows the bridge to extract the PDU length and begin transmitting 802.6 segments before the entire PDU has been received over ATM. Without it, the bridge would have to buffer the entire PDU to calculate and insert the length.

Two encapsulation methods are defined: LLC Encapsulation multiplexes multiple protocols over a single ATM VC by prefixing each PDU with an IEEE 802.2 LLC header; VC Based Multiplexing identifies the protocol implicitly by the VC itself, requiring one VC per protocol but with minimal overhead. VC-based is preferred where dynamic VC creation is fast and cheap (e.g., private ATM); LLC is preferred when VCs are scarce or expensive (e.g., PVC-only networks or per-VC charging).

ip

The IP-over-ATM LLC encapsulation (LLC 0xAA-AA-03 + OUI 0x00-00-00 + EtherType 0x08-00) is explicitly compatible with RFC 1042; this memo defers to RFC 1042 and states that any changes in its header format should be reflected here.

ip

When the Frame Relay Service Specific Convergence Sublayer (FR-SSCS, per I.36x.1) is used above the AAL5 CPCS, routed and bridged PDUs MUST use the NLPID multiplexing method of RFC 1294, not the LLC or VC-based encapsulations defined in this memo.

An ATM interface acting as a bridge MUST be able to flood, forward, and filter bridged PDUs. Flooding is accomplished by sending the PDU through each relevant VC, either by explicit per-VC copy or via a multicast VC.

multicast

An NLPID value of 0x00 (Null Network Layer or Inactive Set) is invalid under the ATM encapsulation scheme defined in this memo and must not be used.

For VC-based bridged protocols, the presence or absence of the trailing LAN FCS SHALL be identified implicitly by the VC (since the PID field is absent); PDUs with LAN FCS and PDUs without LAN FCS are considered different protocols and must be carried on separate VCs.

IP PDUs MUST NOT use the ISO NLPID encapsulation (NLPID 0xCC) even though an NLPID is defined for IP; IP must instead be encapsulated using the SNAP header (LLC 0xAA-AA-03 followed by OUI 0x00-00-00 and EtherType 0x08-00).

ip

Routed and bridged PDUs SHALL be encapsulated within the Payload field of the AAL5 CPCS-PDU regardless of which multiplexing method is selected.

The Common PDU Header and Trailer of an encapsulated 802.6 frame MUST NOT be simply copied to the outgoing 802.6 subnetwork, because the encapsulated BEtag value may conflict with the previous BEtag value transmitted by that bridge.

To support dynamic MAC-address-to-VC learning, a bridged PDU SHALL conform to the LLC encapsulation described in section 4, enabling the receiving ATM interface to inspect the MAC destination address and associate it with the originating ATM station.

NLPID values relevant to ATM encapsulation: 0x00 (Null/Inactive Set — invalid for ATM), 0x80 (SNAP header follows), 0x81 (ISO CLNP), 0x82 (ISO ESIS), 0x83 (ISO ISIS), 0xCC (Internet IP — valid as NLPID but must not be used with ATM; use SNAP instead).

ip, registry

OUI 0x00-80-C2 (802.1 organization) PID values for bridged media types: 0x00-01/0x00-07 (Ethernet/802.3 with/without FCS), 0x00-02/0x00-08 (802.4), 0x00-03/0x00-09 (802.5), 0x00-04/0x00-0A (FDDI), 0x00-05/0x00-0B (802.6), 0x00-0D (Fragments), 0x00-0E (BPDUs). Even-numbered PIDs preserve the original LAN FCS; odd-numbered strip it.

registry

The CPCS-PDU Trailer fields: CPCS-UU (1 octet, user-to-user, no function under this encapsulation, any value allowed); CPI (1 octet, coded 0x00 for 64-bit alignment only); Length (2 octets, length of Payload in octets; 0x00 signals abort); CRC (4 octets, protects entire CPCS-PDU except the CRC field itself).

The SNAP header is 5 octets: OUI (3 octets, identifies the organization administering the PID) and PID (2 octets, identifies a distinct routed or bridged protocol). OUI 0x00-00-00 specifies that PID is an EtherType; OUI 0x00-80-C2 (802.1) specifies a bridged media type.

Security issues are not addressed in this memo.

security

AAL5 CPCS-PDU consists of: Payload (up to 65535 octets), PAD (0–47 octets to align to ATM cell boundary), CPCS-UU (1 octet), CPI (1 octet), Length (2 octets), and CRC (4 octets). The trailer is always 8 octets, right-justified in the last 48-octet ATM cell.

Bridged 802.6 PDU (LLC encapsulation): LLC 0xAA-AA-03 + OUI 0x00-80-C2 + PID 0x00-0B + Common PDU Header (Reserved 1 octet, BEtag 1 octet, BAsize 2 octets) + MAC destination address + remainder + Common PDU Trailer. Only one PID value (no FCS variant) because 802.6 CRC presence is indicated by the CIB bit in the MAC frame header.

LLC Encapsulation for bridged PDUs: LLC 0xAA-AA-03 + OUI 0x00-80-C2 + 2-octet PID (encoding media type and FCS preservation) + PAD (for 4-octet alignment of user information field) + MAC frame contents. Ethernet/802.3 uses 2-octet PAD; 802.4, 802.5, FDDI use 3-octet PAD.

LLC Encapsulation for routed ISO PDUs: Payload begins with 3-octet LLC header 0xFE-FE-03 (DSAP=0xFE, SSAP=0xFE, Control=0x03 Unnumbered Information), followed directly by the ISO PDU whose first octet is the NLPID identifying the specific ISO protocol.

LLC Encapsulation for routed non-ISO PDUs (including IP): 3-octet LLC 0xAA-AA-03, followed by 3-octet OUI 0x00-00-00, followed by 2-octet EtherType. For IP the EtherType is 0x08-00. The PDU payload follows, up to 2^16-9 octets.

ip

VC Based Multiplexing for bridged protocols: Payload format is identical to LLC Encapsulation for bridged protocols (section 4.2) except that the LLC header, OUI, and PID fields are omitted; only the PAD and subsequent MAC frame content are included.

VC Based Multiplexing for routed protocols: the AAL5 CPCS-PDU Payload contains the carried PDU directly with no LLC/SNAP prefix, up to 2^16-1 octets. Protocol identity is conveyed entirely by the VC.