RFC 2684
Multiprotocol Encapsulation over ATM Adaptation Layer 5
RFC 2684: Multiprotocol Encapsulation over ATM Adaptation Layer 5 🎀
okay bestie, this one is about getting network traffic (IP, bridged frames, the works) into ATM cells without losing anything 💅 Let's get into it ✨
The vibe check (title block) 🦋
- Network Working Group, written by D. Grossman (Motorola, Inc.) and J. Heinanen (Telia) 🫶
- Category: Standards Track
- Date: September 1999
- It obsoletes RFC 1483 💀 so 1483 is retired and this is the new one to read
Status of This Memo 📜
This document is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🙈 For the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited.
Copyright Notice ©️
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract 🌸
This memo replaces RFC 1483. It describes two encapsulation methods for carrying network interconnect traffic over AAL type 5 over ATM. The first method lets you multiplex multiple protocols over a single ATM virtual connection, and the second method assumes each protocol gets its own separate ATM virtual connection. Two options, both iconic 👑
Applicability 🧚
This spec is meant for implementations that use ATM networks to carry multiprotocol traffic among hosts, routers and bridges that are ATM end systems. So if that's your setup, this is your guide 💖
1. Introduction 🌈
ATM wide area, campus and local area networks are used to transport IP datagrams and other connectionless traffic between hosts, routers, bridges and other networking devices, so this stuff is everywhere 😭 This memo describes two ways to carry connectionless routed and bridged Protocol Data Units (PDUs) over an ATM network.
The first is the "LLC Encapsulation" method, which lets you multiplex multiple protocols over a single ATM virtual connection (VC). Each PDU's protocol type is identified by a prefixed IEEE 802.2 Logical Link Control (LLC) header. The second is the "VC Multiplexing" method, where each ATM VC carries PDUs of exactly one protocol type. If you need to transport multiple protocols, you get a separate VC for each one 🦋
Here's the ATM basics, bestie. The unit of transport in ATM is a 53 octet fixed length PDU called a cell. A cell is a 5 octet header plus a 48 byte payload 🍓 Variable length PDUs (including the ones this memo covers) must be segmented by the transmitter to fit into the 48 octet ATM cell payload, and then reassembled by the receiver. This memo uses the ATM Adaptation Layer type 5 (AAL5), as defined in ITU-T Recomendation I.363.5 [2] for exactly this job. Variable length PDUs are carried in the Payload field of the AAL5 Common Part Convergence Sublayer (CPCS) PDU ✨
This memo only covers how routed and bridged PDUs are carried directly over the AAL5 CPCS, meaning when the Service Specific Convergence Sublayer (SSCS) of AAL5 is absent. If Frame Relay Service Specific Convergence Sublayer (FR-SSCS), as defined in ITU-T Recommendation I.365.1 [3], is used over the CPCS, then routed and bridged PDUs are carried using the NLPID multiplexing method described in RFC 2427 [4]. The RFC 2427 encapsulation MUST be used in the special case that Frame Relay Network Interworking or transparent mode Service Interworking [9] are used, but it is NOT RECOMMENDED for other applications 🙅♀️ Appendix A (which is for information only) shows the format of the FR-SSCS-PDU, plus how IP and CLNP PDUs are encapsulated over FR-SSCS according to RFC 2427 💅
Quick heads up, babe: the RFC 2427 encapsulation is a MUST in the special Frame Relay interworking cases, and NOT RECOMMENDED everywhere else. Don't mix those up 💀
This memo also includes an optional encapsulation for use with Virtual Private Networks that operate over an ATM subnet 🌐
If you want to use the facilities designed for the Point-to-Point Protocol (PPP), and there's a point-to-point relationship between peer systems, then RFC 2364 applies instead of this memo 🫶
2. Conventions 🎀
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [10]. So those capital words? They're serious business 😤
3. Selection of the Multiplexing Method 🧚
Whether to use LLC encapsulation or VC-multiplexing depends on implementation and system requirements, so it's a "it depends" moment 🙈 In general, LLC encapsulation tends to require fewer VCs in a multiprotocol environment. VC multiplexing tends to reduce fragmentation overhead. For example, an IPv4 datagram containing a TCP control packet with neither IP nor TCP options fits into a single cell exactly ✨
When two ATM end systems want to exchange connectionless PDUs across an ATM Permanent Virtual Connection (PVC), the multiplexing method is picked by configuration. When ATM Switched Virtual Connections (SVCs) are to be used, ATM connection control signalling procedures negotiate the encapsulation method. [5] and [8] specify how that negotiation works 🦋
4. AAL5 PDU Format 💖
For both multiplexing methods, routed and bridged PDUs MUST be encapsulated within the Payload field of an AAL5 CPCS-PDU. Period, no exceptions 👑
ITU-T Recomendation I.363.5 [2] has the complete definition of the AAL5 PDU format and the procedures at the sender and receiver, so go there for the full tea ☕ The AAL5 message mode service, in the non-assured mode of operation, MUST be used. The corrupted delivery option MUST NOT be used. A reassembly timer MAY be used. The following description is just for information, bestie 🌸
The format of the AAL5 CPCS-PDU looks like this:
AAL5 CPCS-PDU Format
+-------------------------------+
| . |
| . |
| CPCS-PDU Payload |
| up to 2^16 - 1 octets) |
| . |
| . |
+-------------------------------+
| PAD ( 0 - 47 octets) |
+-------------------------------+ -------
| CPCS-UU (1 octet ) |
+-------------------------------+
| CPI (1 octet ) |
+-------------------------------+CPCS-PDU Trailer
| Length (2 octets) |
+-------------------------------|
| CRC (4 octets) |
+-------------------------------+ -------The Payload field holds user information, up to 2^16 - 1 octets 🍓
The PAD field pads the CPCS-PDU so it fits exactly into the ATM cells. That way, the last 48 octet cell payload created by the SAR sublayer has the CPCS-PDU Trailer right justified in the cell 🧚
The CPCS-UU (User-to-User indication) field is used to transparently transfer CPCS user to user information. This field is not used by the multiprotocol ATM encapsulation described in this memo, and it MAY be set to any value 🌈
The CPI (Common Part Indicator) field aligns the CPCS-PDU trailer to 64 bits. This field MUST be coded as 0x00 ✨
The Length field indicates the length, in octets, of the Payload field. The maximum value for the Length field is 65535 octets. A Length field coded as 0x00 is used for the abort function 💀
The CRC field is used to detect bit errors in the CPCS-PDU. A CRC-32 is used 🔥
5. LLC Encapsulation 🫧
LLC Encapsulation is needed when more than one protocol might be carried over the same VC. So the receiver can properly process the incoming AAL5 CPCS-PDU, the Payload field contains the info needed to identify the protocol of the routed or bridged PDU. In LLC Encapsulation, this information MUST be encoded in an LLC header placed in front of the carried PDU 🦋
This memo only deals with protocols that operate over LLC Type 1 (unacknowledged connectionless mode) service. The same encapsulation principle also applies to protocols operating over LLC Type 2 (connection-mode) service. In that latter case, the format and contents of the LLC header would be as described in IEEE 802.1 and IEEE 802.2 💖
Part 2 picks up right from here 🫶🌸
5.1. LLC Encapsulation for Routed Protocols ✨
okay bestie, so with LLC Encapsulation, the protocol type of routed PDUs MUST be identified by sticking an IEEE 802.2 LLC header in front of each PDU 💅. In some cases, that LLC header MUST also be followed by an IEEE 802.1a SubNetwork Attachment Point (SNAP) header 🎀. In LLC Type 1 operation, the LLC header MUST consist of three one-octet fields, like this:
+------+------+------+
| DSAP | SSAP | Ctrl |
+------+------+------+For LLC Encapsulation of routed protocols, the Control field MUST be set to 0x03, which means it's an Unnumbered Information (UI) Command PDU 🦋.
The LLC header value 0xFE-FE-03 MUST be used to flag a routed PDU in the ISO NLPID format (see [6] and Appendix B) 🌈. For NLPID-formatted routed PDUs, the AAL5 CPCS-PDU Payload field MUST look like this:
Payload Format for Routed NLPID-formatted PDUs
+-------------------------------+
| LLC 0xFE-FE-03 |
+-------------------------------+
| NLPID (1 octet) |
+-------------------------------+
| . |
| PDU |
| (up to 2^16 - 4 octets) |
| . |
+-------------------------------+The routed protocol MUST be identified by a one-octet NLPID field that lives inside Protocol Data 🧚. NLPID values are administered by ISO and ITU-T, and they're defined in ISO/IEC TR 9577 [6]. Some of the ones that currently exist are listed in Appendix C 📚.
An NLPID value of 0x00 is defined in ISO/IEC TR 9577 as the Null Network Layer or Inactive Set. Since it doesn't mean anything in this encapsulation scheme, an NLPID value of 0x00 MUST NOT be used 🙅♀️.
Okay, so even though there's an NLPID value (0xCC) that indicates IP, the NLPID format MUST NOT be used for IP 💀. Instead, IP datagrams MUST be identified by a SNAP header, which we'll get into below 🫶.
The presence of an IEEE 802.1a SNAP header is indicated by the LLC header value 0xAA-AA-03. A SNAP header looks like this:
+------+------+------+------+------+
| OUI | PID |
+------+------+------+------+------+The SNAP header is made up of a three-octet Organizationally Unique Identifier (OUI) and a two-octet Protocol Identifier (PID) 💜. The OUI is administered by IEEE, and it identifies an organization that administers the values which might be assigned to the PID. So the SNAP header uniquely identifies a routed or bridged protocol, which is honestly so iconic 👑. The OUI value 0x00-00-00 indicates that the PID is an EtherType 🍓.
The format of the AAL5 CPCS-PDU Payload field for routed non-NLPID formatted PDUs MUST be as follows:
Payload Format for Routed non-NLPID formatted PDUs
+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-00-00 |
+-------------------------------+
| EtherType (2 octets) |
+-------------------------------+
| . |
| Non-NLPID formatted PDU |
| (up to 2^16 - 9 octets) |
| . |
+-------------------------------+In the particular case of an IPv4 PDU, the EtherType value is 0x08-00, and the payload format MUST be:
Payload Format for Routed IPv4 PDUs
+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-00-00 |
+-------------------------------+
| EtherType 0x08-00 |
+-------------------------------+
| . |
| IPv4 PDU |
| (up to 2^16 - 9 octets) |
| . |
+-------------------------------+This format is consistent with what's defined in RFC 1042 [7] 🌸
5.2. LLC Encapsulation for Bridged Protocols 🌸
Okay so for bridged PDUs in LLC Encapsulation, the bridged media type gets identified in the SNAP header 🎀 The SNAP header's presence MUST be flagged by the LLC header value 0xAA-AA-03 ✨ The OUI value in that SNAP header MUST be the 802.1 organization code 0x00-80-C2 💅 The type of the bridged media MUST be given by the two octet PID, and the PID MUST also say whether the original Frame Check Sequence (FCS) is kept inside the bridged PDU 🔥 Appendix B has the list of media type (PID) values you can use for ATM encapsulation 🧚
The AAL5 CPCS-PDU Payload field carrying a bridged PDU MUST follow one of the formats below 💖 You MUST add the right number of padding octets after the PID field so that the Ethernet/802.3 LLC Data field, 802.4 Data Unit field, 802.5 Info field, FDDI Info field or 802.6 Info field (depending on which one you're carrying) starts on a four octet boundary 🫶 The bit ordering of the MAC address MUST match what it would be on the LAN or MAN, so canonical form for bridged Ethernet/IEEE 802.3 PDUs, but 802.5/FDDI format for bridged 802.5 PDUs 🦋
Payload Format for Bridged Ethernet/802.3 PDUs
+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-01 or 0x00-07 |
+-------------------------------+
| PAD 0x00-00 |
+-------------------------------+
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| LAN FCS (if PID is 0x00-01) |
+-------------------------------+Ethernet/802.3 is the physical layer that needs frames padded to a minimum size, so this is a big one 🙈 A bridge using the Bridged Ethernet/802.3 format WITH the preserved LAN FCS MUST include padding 😭 A bridge using that format WITHOUT the preserved LAN FCS MAY either include padding or leave it out, its choice ✨ And when a bridge gets a frame in this format with no LAN FCS, it MUST be able to slot in the necessary padding (if there isn't already some) before forwarding it to an Ethernet/802.3 subnetwork 💜
Payload Format for Bridged 802.4 PDUs
+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-02 or 0x00-08 |
+-------------------------------+
| PAD 0x00-00-00 |
+-------------------------------+
| Frame Control (1 octet) |
+-------------------------------+
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| LAN FCS (if PID is 0x00-02) |
+-------------------------------+ Payload Format for Bridged 802.5 PDUs
+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-03 or 0x00-09 |
+-------------------------------+
| PAD 0x00-00-XX |
+-------------------------------+
| Frame Control (1 octet) |
+-------------------------------+
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| LAN FCS (if PID is 0x00-03) |
+-------------------------------+Here's the tea on the 802.5 Access Control (AC) field: it means nothing outside the local 802.5 subnetwork, so this encapsulation just treats it as the last octet of that three octet PAD field 🍓 The sending bridge MAY set it to any value, and the receiving bridge MUST ignore it 🌈
Payload Format for Bridged FDDI PDUs
+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-04 or 0x00-0A |
+-------------------------------+
| PAD 0x00-00-00 |
+-------------------------------+
| Frame Control (1 octet) |
+-------------------------------+
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| LAN FCS (if PID is 0x00-04) |
+-------------------------------+ Payload Format for Bridged 802.6 PDUs
+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-0B |
+---------------+---------------+ ------
| Reserved | BEtag | Common
+---------------+---------------+ PDU
| BAsize | Header
+-------------------------------+ -------
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| |
| Common PDU Trailer |
| |
+-------------------------------+For bridged 802.6 PDUs, whether there's a CRC-32 or not is shown by the CIB bit in the MAC frame header 🎀 So the same PID value works either way ✨
The Common Protocol Data Unit (PDU) Header and Trailer exist so the egress bridge can pipeline toward an 802.6 subnetwork 🦋 The Common PDU Header holds the BAsize field, which has the PDU's length. If the egress 802.6 bridge can't see that field, it can't start sending the segmented PDU until it has the whole thing, worked out the length, and put it into BAsize 😭 But if the field IS available, the bridge can pull the length out of BAsize, drop it into the matching field of the first segment, and fire that segment onto the 802.6 subnetwork right away 🚀 So the bridge can start transmitting the 802.6 PDU before it has the full PDU, which is lowkey iconic 👑
Heads up: the Common PDU Header and Trailer of the encapsulated frame should not be simply copied to the outgoing 802.6 subnetwork 🙅 The reason is that the encapsulated BEtag value might clash with the previous BEtag value that bridge sent 💀
An ingress 802.6 bridge can abort an AAL5 CPCS-PDU by setting its Length field to zero 🧚 If the egress bridge has already started sending segments of that PDU to an 802.6 subnetwork and then spots that the AAL5 CPCS-PDU got aborted, it may immediately generate an EOM cell that gets the 802.6 PDU rejected at the receiving bridge 😤 That EOM cell could, for example, carry an invalid value in the Length field of the Common PDU Trailer 🫠
Payload Format for BPDUs
+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-0E |
+-------------------------------+
| |
| BPDU as defined by |
| 802.1(d) or 802.1(g) |
| |
+-------------------------------+6. VC Multiplexing ✨
VC Multiplexing binds an ATM VC to the type of network protocol riding on that VC 💜 That means nobody needs to stuff protocol identification info into the payload of every AAL5 CPCS-PDU, which cuts payload overhead and can make per-packet processing lighter 🌸 It can also be more efficient, since it can mean fewer cells are needed for PDUs of certain lengths 🍓
For ATM PVCs, the type of protocol carried over each PVC MUST be determined by configuration 🎀 For ATM SVCs, the negotiations specified in RFC 1755 [5] MUST be used 🫶
6.1. VC Multiplexing of Routed Protocols 🦋
PDUs of routed protocols MUST be carried as the ONLY content of the Payload of the AAL5 CPCS-PDU 💅 So the AAL5 CPCS-PDU Payload field ends up looking like this:
Payload Format for Routed PDUs
+-------------------------------+
| . |
| Carried PDU |
| (up to 2^16 - 1 octets) |
| . |
| . |
+-------------------------------+6.2. VC Multiplexing of Bridged Protocols
okay so bridged PDUs MUST be carried in the Payload of the AAL5 CPCS-PDU exactly like section 5.2 says 💅, except the only fields that MUST be included are the ones after the PID field 🎀. That means the AAL5 CPCS-PDU Payload field carrying a bridged PDU MUST have one of the formats below 🦋.
Payload Format for Bridged Ethernet/802.3 PDUs
+-------------------------------+
| PAD 0x00-00 |
+-------------------------------+
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| LAN FCS (VC dependent option) |
+-------------------------------+Payload Format for Bridged 802.4/802.5/FDDI PDUs
+-------------------------------+
| PAD 0x00-00-00 or 0x00-00-XX |
+-------------------------------+
| Frame Control (1 octet) |
+-------------------------------+
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| LAN FCS (VC dependent option) |
+-------------------------------+Quick aside on 802.5 🧚: the 802.5 Access Control (AC) field has no significance outside the local 802.5 subnetwork. So it can be treated as the last octet of that three octet PAD field, and in the case of 802.5 it can be set to any value (XX).
Payload Format for Bridged 802.6 PDUs
+---------------+---------------+ -------
| Reserved | BEtag | Common
+---------------+---------------+ PDU
| BAsize | Header
+-------------------------------+ -------
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| |
| Common PDU Trailer |
| |
+-------------------------------+Payload Format for BPDUs
+-------------------------------+
| |
| BPDU as defined by |
| 802.1(d) or 802.1(g) |
| |
+-------------------------------+Last bit, and it's a big one 👑: for Ethernet, 802.3, 802.4, 802.5, and FDDI PDUs, the presence or absence of the trailing LAN FCS shall be identified implicitly by the VC, since the PID field is not included. PDUs with the LAN FCS and PDUs without it are therefore considered to belong to different protocols, even if the bridged media type would be the same. Wild, right? 😭
7. Bridging in an ATM Network ✨
okay bridging over ATM is giving main character energy 🦋. A bridge with an ATM interface that links to one or more other bridges MUST be able to flood, forward, and filter bridged PDUs 💅.
Flooding means sending the PDU to every possible appropriate destination. In ATM terms that means sending the PDU through each relevant VC. You can do that by explicitly copying it to each VC, or by using a point-to-multipoint VC 🌸.
To forward a PDU, a bridge MUST be able to associate a destination MAC address with a VC 🎀. It's unreasonable, and maybe even impossible, to make bridges statically configure an association between every possible destination MAC address and a VC 🙈. So ATM bridges must provide enough information for an ATM interface to dynamically learn about foreign destinations beyond the set of ATM stations ✨.
To make that dynamic learning work, a bridged PDU MUST conform to the encapsulation described in section 5 🫶. That way the receiving ATM interface knows to look into the bridged PDU and learn the association between a foreign destination and an ATM station. Iconic 💜.
8. Virtual Private Network (VPN) identification 🔮
The encapsulation defined in this section only applies to Virtual Private Networks (VPNs) that operate over an ATM subnet 🌈.
A mechanism for globally unique identification of Virtual Private multiprotocol networks is defined in [11] 💅. The 7-octet VPN-Id is made of a 3-octet VPN-related OUI (IEEE 802-1990 Organizationally Unique Identifier), followed by a 4-octet VPN index that's allocated by the owner of the VPN-related OUI. Typically the VPN-related OUI value goes to a VPN service provider, which then hands out VPN index values to its customers 🎀.
8.1 VPN Encapsulation Header ✨
The VPN encapsulation header is laid out like this:
VPN Encapsulation Header
+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-00-5E |
+-------------------------------+
| PID 0x00-08 |
+-------------------------------+
| PAD 0x00 |
+-------------------------------+
| VPN related OUI (3 octets) |
+-------------------------------+
| VPN Index (4 octets) |
+-------------------------------+
| |
| (remainder of PDU) |
| |
+-------------------------------+When the encapsulation header is used, the remainder of the PDU MUST be structured according to the appropriate format in section 5 or 6, since the VPN encapsulation header is prepended to the PDU within an AAL5 CPCS SDU 🍓.
8.2 LLC-encapsulated routed or bridged PDUs within a VPN 💖
When an LLC-encapsulated routed or bridged PDU is sent within a VPN over ATM using AAL5, a VPN encapsulation header MUST be prepended to the appropriate routed or bridged PDU format defined in sections 5.1 and 5.2, respectively 🫶.
8.3 VC multiplexing of routed or bridged PDUs within a VPN 🌸
When a routed or bridged PDU is sent within a VPN using VC multiplexing, the VPN identifier MAY either be specified a priori, using ATM connection control signalling or administrative assignment to an ATM interface, or it MAY be indicated using an encapsulation header 🧚.
If the VPN is identified using ATM connection control signalling, every PDU carried by the ATM VC is associated with that same VPN. In this case, the payload formats of routed and bridged PDUs MUST be as defined in sections 6.1 and 6.2, respectively 💅. If a PDU shows up containing a VPN encapsulation header when the VPN has been identified using ATM signalling, the receiver MAY drop it and/or take other actions which are implementation specific 🙈. How the mechanism in ATM connection control signalling carries VPN identifiers is outside the scope of this Memo 🌈.
If a VPN identifier is administratively assigned to an ATM interface, then every PDU carried by any ATM VCs within that interface is associated with that VPN. In this case, the payload formats of routed and bridged PDUs MUST be as defined in sections 6.1 and 6.2, respectively. If a PDU is received containing a VPN encapsulation header when the VPN identifier has been administratively assigned, the receiver MAY drop it and/or take other actions which are implementation specific. How mechanisms (such as MIBs) for assigning VPN identifiers to ATM interfaces work is outside the scope of this memo 🦋.
If the VPN identifier is to be indicated using an encapsulation header, then a VPN encapsulation header MUST be prepended to the appropriate routed or bridged PDU format defined in sections 6.1 and 6.2, respectively 👑.
9. Security Considerations 🔥
Okay, this section is serious, so read it carefully bestie 💀.
This memo defines mechanisms for multiprotocol encapsulation over ATM. There is an element of trust in any encapsulation protocol: a receiver must trust that the sender has correctly identified the protocol being encapsulated. There is no way to ascertain that the sender actually used the proper protocol identification (nor would that be desirable functionality). The encapsulation mechanisms described in this memo are believed not to have any other properties that an attacker might exploit. However, architectures and protocols operating above the encapsulation layer may be subject to a variety of attacks. In particular, the bridging architecture discussed in section 7 has the same vulnerabilities as other bridging architectures 😭.
System security may be affected by the properties of the underlying ATM network. The ATM Forum has published a security framework [12] and a security specification [13] which may be relevant 🔒.
Acknowledgements 🫶
This memo replaces RFC 1483, which was developed by the IP over ATM working group and edited by Juha Heinanen (then at Telecom Finland, now at Telia). The update was developed in the IP-over-NBMA (ION) working group, and Dan Grossman (Motorola) was the editor and also contributed to the work on RFC 1483 🌟.
This material evolved from RFCs [1] and [4], from which much of the material has been adopted. Huge thanks to their authors Terry Bradley, Caralyn Brown, Andy Malis, Dave Piscitello, and C. Lawrence 💖. Other key contributors to the work included Brian Carpenter (CERN), Rao Cherukuri (IBM), Joel Halpern (then at Network Systems), Bob Hinden (Sun Microsystems, presently at Nokia), and Gary Kessler (MAN Technology) 🎀.
The material concerning VPNs was developed by Barbara Fox (Lucent) and Bernhard Petri (Siemens) 🧚.
References ✨
Okay bestie, this is the reading list 📚 Every doc below is one this spec leans on, so they're copied exactly as written:
[1] Piscitello, D. and C. Lawrence, "The Transmission of IP
Datagrams over the SMDS Service", RFC 1209, March 1991.
[2] ITU-T Recommendation I.363.5, "B-ISDN ATM Adaptation Layer (AAL)
Type 5 Specification", August 1996.
[3] ITU-T Recommendation I.365.1, "Frame Relaying Service Specific
Convergence Sublayer (SSCS), November 1993.
[4] Brown, C. and A. Malis, "Multiprotocol Interconnect over Frame
Relay", RFC 2427, September 1998.
[5] Perez M., Liaw, F., Mankin, E., Grossman, D. and A. Malis, "ATM
Signalling Support for IP over ATM", RFC 1755, February 1995.
[6] Information technology - Telecommunications and Information
Exchange Between Systems, "Protocol Identification in the
Network Layer". ISO/IEC TR 9577, October 1990.
[7] Postel, J. and J. Reynolds, "A Standard for the Transmission of
IP Datagrams over IEEE 802 Networks", STD 43, RFC 1042, February
1988.
[8] Maher, M., "IP over ATM Signalling - SIG 4.0 Update", RFC 2331,
April 1998.
[9] ITU-T Recommendation I.555, "Frame Relay Bearer Service
Interworking", September 1997.
[10] Bradner, S. "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[11] Fox, B. and B. Gleeson, "Virtual Private Networks Identifier",
RFC 2685, September 1999.
[12] The ATM Forum, "ATM Security Framework Version 1.0", af-sec-
0096.000, February 1998.
[13] The ATM Forum, "ATM Security Specification v1.0", af-sec-
0100.001, February 1999.Appendix A. Multiprotocol Encapsulation over FR-SSCS 🎀
Let's talk about FR-SSCS 💅 ITU-T Recommendation I.365.1 defines a Frame Relaying Specific Convergence Sublayer (FR-SSCS) that sits on top of the Common Part Convergence Sublayer (CPCS) of AAL type 5. Its whole job is Frame Relay/ATM interworking 🦋 The service it offers matches the Core service for Frame Relaying described in I.233, so it's giving consistency ✨
An FR-SSCS-PDU is a Q.922 Address field followed by a Q.922 Information field. The Q.922 flags and the FCS are left out, since the AAL already takes care of those functions 🫶 Here's an FR-SSCS-PDU sitting in the payload of an AAL5 CPCS-PDU:
FR-SSCS-PDU in Payload of AAL5 CPCS-PDU
+-------------------------------+ -------
| Q.922 Address Field | FR-SSCS-PDU Header
| (2-4 octets) |
+-------------------------------+ -------
| . |
| . |
| Q.922 Information field | FR-SSCS-PDU Payload
| . |
| . |
+-------------------------------+ -------
| AAL5 CPCS-PDU Trailer |
+-------------------------------+Routed and bridged PDUs get packed inside the FR-SSCS-PDU as defined in RFC 2427 🌸 The Q.922 Information field starts with a Q.922 Control field, then an optional Pad octet that lines the rest of the frame up on a convenient boundary for the sender. To say which protocol the carried PDU speaks, you prefix the PDU with an ISO/IEC TR 9577 Network Layer Protocol ID (NLPID) 🧚
For IP PDUs, the NLPID is 0xCC, and the FR-SSCS-PDU looks like this:
FR-SSCS-PDU Format for Routed IP PDUs
+-------------------------------+
| Q.922 Addr Field |
| (2 or 4 octets) |
+-------------------------------+
| 0x03 (Q.922 Control) |
+-------------------------------+
| NLPID 0xCC |
+-------------------------------+
| . |
| IP PDU |
| (up to 2^16 - 5 octets) |
| . |
+-------------------------------+Okay this one is important 🚨 According to RFC 2427, the Q.922 Address field MUST be either 2 or 4 octets. That means a 3 octet Address field MUST NOT be used. No 3-octet vibes allowed 💀
For CLNP PDUs, the NLPID is 0x81, and the FR-SSCS-PDU looks like this:
FR-SSCS-PDU Format for Routed CLNP PDUs
+-------------------------------+
| Q.922 Addr Field |
| (2 or 4 octets) |
+-------------------------------+
| 0x03 (Q.922 Control) |
+-------------------------------+
| NLPID 0x81 |
+-------------------------------+
| . |
| Rest of CLNP PDU |
| (up to 2^16 - 5 octets) |
| . |
+-------------------------------+For ISO protocols, the NLPID field is the first octet of the PDU itself, and it MUST not be repeated 🙈 That's a main character rule, no duplicates allowed 👑
The encapsulation above only applies to routed protocols that have a unique NLPID assigned 🔥 For other routed protocols, and for bridged protocols, you need another way to identify them easily. That's where NLPID value 0x80 comes in, meaning an IEEE 802.1a SubNetwork Attachment Point (SNAP) header follows 🌈
For more on multiprotocol encapsulation over FRCS, check RFC 2427 📖
Appendix B. List of Locally Assigned values of OUI 00-80-C2 🍓
Here's the table of locally assigned OUI 00-80-C2 values, split by whether the FCS is preserved or not. Look at that layout 😭
with preserved FCS w/o preserved FCS Media
------------------ ----------------- --------------
0x00-01 0x00-07 802.3/Ethernet
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 BPDUsAppendix C. Partial List of NLPIDs 🧚
Here's a partial list of NLPIDs, the protocol IDs that tell you what's inside. Lots of familiar names in here 💜
0x00 Null Network Layer or Inactive Set (not used with ATM)
0x80 SNAP
0x81 ISO CLNP
0x82 ISO ESIS
0x83 ISO ISIS
0xCC Internet IPAppendix D. Applications of multiprotocol encapsulation 🌸
Multiprotocol encapsulation is necessary, but generally not sufficient, for routing and bridging over ATM networks 💅 Since RFC 1483 (the predecessor of this memo) came out, the IETF and the ATM Forum built several system specifications to cover different parts of bridged or routed protocols, or different scenarios for them. This appendix is the highlight reel ✨
- Point-to-point connection between routers and bridges -- Multiprotocol encapsulation over ATM PVCs has been used to give a simple point-to-point link between bridges and routers across an ATM network. Some manual configuration (for example, instead of INARP) was needed in these setups.
- Classical IP over ATM -- RFC 2225 (formerly RFC 1577) gives you an environment where the ATM network acts as a logical IP subnet (LIS). ATM PVCs are supported, with address resolution done by INARP. For ATM SVCs, a new form of ARP, ATMARP, runs over the ATM network between a host (or router) and an ATMARP server. When servers get replicated for higher availability or performance, the Server Synchronization Cache Protocol (SCSP) defined in RFC 2335 is used. Classical IP over ATM defaults to the LLC/SNAP encapsulation 🎀
- LAN Emulation -- The ATM Forum LAN Emulation specification makes an ATM network, boosted by LAN Emulation Server(s), behave like a bridged LAN 🦋 Stations get their configuration info from, and register with, a LAN Emulation Configuration Server. They resolve MAC addresses to ATM addresses through a LAN Emulation Server. They can send broadcast and multicast frames, and they can send unicast frames they don't have a direct VC for to a Broadcast and Unicast Server. LANE uses the VC multiplexing encapsulation formats for Bridged Ethernet/802.3 (without LAN FCS) or Bridged 802.5 (without LAN FCS) on the Data Direct, LE Multicast Send and Multicast Forward VCCS. However, the initial PAD field described in this memo is used as an LE header, so it might not be set to all '0' 🫠
- Next Hop Resolution Protocol (NHRP) -- Sometimes the rule that Classical IP over ATM serves a single LIS holds performance back. NHRP, defined in RFC 2332, extends Classical IP to allow 'shortcuts' over an ATM network that supports several LISs 🚀
- Multiprotocol over ATM (MPOA) -- The ATM Forum Multiprotocol over ATM Specification combines LANE and NHRP into one generic bridging/routing environment 🌈
- IP Multicast -- RFC 2022 extends Classical IP to support IP multicast. A multicast address resolution server (MARS) is used, possibly together with a multicast server, to provide IP multicast behavior over ATM point-to-multipoint and/or point-to-point virtual connections 📡
- PPP over ATM -- RFC 2364 extends multiprotocol over ATM to the case where the encapsulated protocol is PPP. Both the VC based multiplexing and LLC/SNAP encapsulations are used. This approach is for when the ATM network is used as a point-to-point link and PPP functions are required 💖
Appendix E. Differences from RFC 1483 🍓
This memo replaces RFC 1483 🫶 The goal was to clean up anachronisms, clarify ambiguities that implementors found or that changes to the base standards created, and move this work forward through the IETF standards track process. A bunch of editorial improvements were made, the RFC 2119 conventions were applied, and the current RFC boilerplate was added. Here are the substantive changes. None of them is believed to obsolete implementations of RFC 1483 ✨
- usage of NLPID encapsulation is clarified in terms of the RFC 2119 conventions
- a pointer to RFC 2364 is added to cover the case of PPP over ATM
- RFC 1755 and RFC 2331 are referenced to describe how encapsulations are negotiated, rather than a long-obsolete CCITT (now ITU-T) working document and references to work then in progress
- usage of AAL5 is now a reference to ITU-T I.363.5. Options created in AAL5 since the publication of RFC 1483 are selected.
- formatting of routed NLPID-formatted PDUs (which are called "routed ISO PDUs" in RFC 1483) is clarified
- clarification is provided concerning the use of padding between the PID and MAC destination address in bridged PDUs and the bit ordering of the MAC address
- clarification is provided concerning the use of padding of Ethernet/802.3 frames
- a new encapsulation for VPNs is added
- substantive security considerations were added
- a new appendix D provides a summary of applications of multiprotocol over ATM
Authors' Addresses 💌
Dan Grossman
Motorola, Inc.
20 Cabot Blvd.
Mansfield, MA 02048
EMail: dan@dma.isg.mot.com
Juha Heinanen
Telia Finland
Myyrmaentie 2
01600 Vantaa, Finland
EMail: jh@telia.fiFull Copyright Statement 💖
Okay bestie, this is the legal bit, but it's actually important so stay with me 🫶
Copyright (C) The Internet Society (1999). All Rights Reserved. 🌈
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. ✨ So you can share it and build on it, as long as the copyright notice and this paragraph come along for the ride.
However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations. 🙈 The exceptions are when it's needed for developing Internet standards, in which case the procedures for copyrights defined in the Internet Standards process must be followed, or when it's being translated into languages other than English. 🌸
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. 💜 Forever and ever, no cap.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💀 Translation: they're giving you the doc as-is and not promising it'll do anything specific for you, so be a little careful out there.
Acknowledgement 🫶
Funding for the RFC Editor function is currently provided by the Internet Society. 🍓 So the folks keeping all these RFCs organized and published are being funded by the Internet Society right now, and that's iconic. 👑
📦 where this page comes from
- ietf: rfc2684 1999-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms