RFC 2427
Multiprotocol Interconnect over Frame Relay
🎀 Multiprotocol Interconnect over Frame Relay
okay bestie, let's start with the header 💅 this is RFC 2427, from the Network Working Group, and it's STD 55, so it's a full Internet standard 🫶 The category is Standards Track, dated September 1998. The authors are C. Brown (Consultant) and A. Malis (Ascend Communications, Inc.). It obsoletes RFC 1490 and RFC 1294 (Obsoletes: 1490, 1294). There's no Updates line in the header, so it doesn't update anything 💖
Status of This Memo ✨
so the Status of This Memo part is giving official 🧚 This document specifies an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements. For the 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 (1998). All Rights Reserved.
Abstract 🦋
This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone. It covers aspects of both Bridging and Routing, so it's a whole vibe 🫶
Systems with the ability to transfer both the encapsulation method described in this document, and others must have a priori knowledge of which virtual circuits will carry which encapsulation method 🔥 and this encapsulation must only be used over virtual circuits that have been explicitly configured for its use. no shortcuts, bestie 💀
Acknowledgments 💜
this doc could not have been finished without Terry Bradley of Avici Systems, Inc. 🙌 Comments and contributions from many sources got folded in, especially from Ray Samora of Proteon, Ken Rehbehn of Visual Networks, Fred Baker and Charles Carvalho of Cisco Systems, and Mostafa Sherif of AT&T. Special thanks to Dory Leifer of University of Michigan for their help with the fragmentation issues (though that part was deleted in the final version 😭), and to Floyd Backes and Laura Bridge of 3Com for their work on the bridging descriptions 🍓 It also could not have happened without the expertise of the IP over Large Public Data Networks and the IP over NBMA working groups of the IETF 👑
1. Conventions and Acronyms 💖
okay, the key-word bit. The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [16] 🧚
All drawings in this document are drawn with the left-most bit as the high order bit for transmission. For example, the drawings might be labeled like this:
0 1 2 3 4 5 6 7 bits
+---+---+---+---+---+---+---+---+
+---------------------------+
| flag (7E hexadecimal) |
+---------------------------+
| Q.922 Address* |
+-- --+
| |
+---------------------------+
: :
: :
+---------------------------+Drawings that would be too large to fit onto one page if each octet were presented on a single line get drawn with two octets per line. These are also drawn with the left-most bit as the high order bit for transmission. There will be a "+" to distinguish between octets, like in this example 🦋
|--- octet one ---|--- octet two ---|
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--------------------------------------------+
| Organizationally Unique |
+-- +--------------------+
| Identifier | Protocol |
+-----------------------+--------------------+
| Identifier |
+-----------------------+The following are common acronyms used throughout this document 📚
BECN - Backward Explicit Congestion Notification
BPDU - Bridge Protocol Data Unit
C/R - Command/Response bit
DCE - Data Communication Equipment
DE - Discard Eligibility bit
DTE - Data Terminal Equipment
FECN - Forward Explicit Congestion Notification
PDU - Protocol Data Unit
PTT - Postal Telephone & Telegraph
SNAP - Subnetwork Access Protocol2. Introduction 🌸
this section is for the devices that act as end stations (DTEs) on a public or private Frame Relay network. For example, the network might be provided by a common carrier or PTT. It won't go into how the stations that are part of the Frame Relay network (DCEs) behave, except to explain situations where the DTE has to react 🫶
The Frame Relay network gives you a bunch of virtual circuits, and those form the basis for connections between stations on the same network ✨ The interconnected devices make up a private Frame Relay group, which can be fully interconnected with a complete "mesh" of virtual circuits, or only partially interconnected 🕸️ Either way, each virtual circuit is uniquely identified at each Frame Relay interface by a Data Link Connection Identifier (DLCI). In most circumstances, DLCIs have strictly local significance at each Frame Relay interface 💅
The specifications in this document are meant to apply to both switched and permanent virtual circuits 🎀
3. Frame Format 🧚
All protocols must encapsulate their packets within a Q.922 Annex A frame [1]. On top of that, frames shall contain information necessary to identify the protocol carried within the protocol data unit (PDU), so the receiver can properly process the incoming packet 🔥 The format shall be as follows:
+---------------------------+
| flag (7E hexadecimal) |
+---------------------------+
| Q.922 Address* |
+-- --+
| |
+---------------------------+
| Control (UI = 0x03) |
+---------------------------+
| Pad (when required) (0x00)|
+---------------------------+
| NLPID |
+---------------------------+
| . |
| . |
| . |
| Data |
| . |
| . |
+---------------------------+
| Frame Check Sequence |
+-- . --+
| (two octets) |
+---------------------------+
| flag (7E hexadecimal) |
+---------------------------+
* Q.922 addresses, as presently defined, are two octets and
contain a 10-bit DLCI. In some networks Q.922 addresses
may optionally be increased to three or four octets.The control field is the Q.922 control field. The UI (0x03) value is used unless it is negotiated otherwise. The use of XID (0xAF or 0xBF) is permitted, and we'll get to that later 💖
The pad field lines up the data portion (beyond the encapsulation header) of the frame to a two octet boundary 🍓 If it's present, the pad is a single octet and must have a value of zero. We'll also explain when to use the pad field later in this document ✨
The Network Level Protocol ID (NLPID) field is administered by ISO and the ITU. It has values for lots of different protocols, including IP, CLNP, and IEEE Subnetwork Access Protocol (SNAP) [10] 🌈 This field tells the receiver what encapsulation or what protocol follows. Values for this field are defined in ISO/IEC TR 9577 [3]. A NLPID value of 0x00 is defined within ISO/IEC TR 9577 as the Null Network Layer or Inactive Set. Since it can't be told apart from a pad field, and it has no significance in this encapsulation scheme, a NLPID value of 0x00 is invalid under the Frame Relay encapsulation 🙈 Appendix A has a list of some of the more commonly used NLPID values 📚
There's no commonly implemented minimum maximum frame size for Frame Relay 🤷♀️ A network must, however, support at least a 262 octet maximum. Generally, the maximum will be greater than or equal to 1600 octets, but each Frame Relay provider will specify an appropriate value for its network. So a Frame Relay DTE must allow the maximum acceptable frame size to be configurable 🔥
The minimum frame size allowed for Frame Relay is five octets between the opening and closing flags, assuming a two octet Q.922 address field. This minimum goes up to six octets for a three octet Q.922 address, and seven octets for the four octet Q.922 address format 💅
4. Interconnect Issues 🦋
There are two basic types of data packets that travel within the Frame Relay network: routed packets and bridged packets. These packets have distinct formats, so they must contain an indicator that the destination can use to correctly interpret the contents of the frame. This indicator is embedded within the NLPID and SNAP header information 🫶
For protocols that don't have an NLPID already assigned, we need a way to make protocol identification easy 💜 There's an NLPID value defined that indicates the presence of a SNAP header ✨
A SNAP header is of the form:
+--------------------------------------------+
| Organizationally Unique |
+-- +--------------------+
| Identifier | Protocol |
+-----------------------+--------------------+
| Identifier |
+-----------------------+The three-octet Organizationally Unique Identifier (OUI) identifies an organization that administers the meaning of the Protocol Identifier (PID) that follows. Together they identify a distinct protocol 🌸 Note that OUI 0x00-00-00 specifies that the following PID is an Ethertype 🎀
4.1. Routed Frames ✨
Okay so some protocols have an assigned NLPID, but the NLPID numbering space is pretty limited, bestie 🥺, so not every protocol gets one. When those protocols get routed over Frame Relay, they're sent with NLPID 0x80 (which says "hey, a SNAP header is coming" 🎀) followed by SNAP. If the protocol has an Ethertype assigned, the OUI is 0x00-00-00 (meaning an Ethertype follows 💅), and the PID is the Ethertype of the protocol in use.
When a SNAP header is there like this, a one octet pad lines up the protocol data on a two octet boundary, as shown below 🦋.
Format of Routed Frames
with a SNAP Header
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | pad 0x00 |
+---------------+---------------+
| NLPID 0x80 | Organization- |
+---------------+ |
| ally Unique Identifier (OUI) |
+-------------------------------+
| Protocol Identifier (PID) |
+-------------------------------+
| |
| Protocol Data |
| |
+-------------------------------+
| FCS |
+-------------------------------+In the few cases when a protocol has an assigned NLPID (see Appendix A), 48 bits can be saved using the format below 🍓:
Format of Routed NLPID Protocol
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | NLPID |
+---------------+---------------+
| Protocol Data |
+-------------------------------+
| FCS |
+-------------------------------+When using the NLPID encapsulation format like this, the pad octet is not used 🙈.
In the case of ISO protocols, the NLPID is considered to be the first octet of the protocol data, so it's unnecessary to repeat the NLPID here ✨. That single octet serves both as the demultiplexing value and as part of the protocol data (refer to "Other Protocols over Frame Relay for more details). Other protocols, such as IP, have an NLPID defined (0xCC), but it is not part of the protocol itself 💜.
Format of Routed IP Datagram
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | NLPID 0xCC |
+---------------+---------------+
| IP Datagram |
+-------------------------------+
| FCS |
+-------------------------------+4.2. Bridged Frames ✨
okay so the second kind of Frame Relay traffic is bridged packets 🌉 these get wrapped with NLPID 0x80, which means SNAP 💅 just like other SNAP-wrapped protocols, there's one pad octet to line up the data part of the frame. the SNAP header right after the NLPID tells you what format the bridged packet is in. the OUI is the 802.1 organization code 0x00-80-C2 🫶 and the PID (the two bytes right after the OUI) defines the form of the MAC header, which sits immediately after the SNAP header. the PID also tells you whether the original FCS is kept inside the bridged frame 🔥
following the precedent in RFC 1638 [4], non-canonical MAC destination addresses are used for encapsulated IEEE 802.5 and FDDI frames, and canonical MAC destination addresses are used for everything else in this section. the vibe is consistent, bestie 🎀
the 802.1 organization has reserved these PID values for Frame Relay 👑
PID Values for OUI 0x00-80-C2
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-0B 802.6in addition, the PID value 0x00-0E, when used with OUI 0x00-80-C2, identifies Bridge Protocol Data Units (BPDUs) as defined by 802.1(d) or 802.1(g) [12] 🧚 and the PID value 0x00-0F identifies Source Routing BPDUs 🦋
so a packet bridged over Frame Relay will have one of these formats 💖
Format of Bridged Ethernet/802.3 Frame
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | pad 0x00 |
+---------------+---------------+
| NLPID 0x80 | OUI 0x00 |
+---------------+ --+
| OUI 0x80-C2 |
+-------------------------------+
| PID 0x00-01 or 0x00-07 |
+-------------------------------+
| MAC destination address |
: :
| |
+-------------------------------+
| (remainder of MAC frame) |
+-------------------------------+
| LAN FCS (if PID is 0x00-01) |
+-------------------------------+
| FCS |
+-------------------------------+
Format of Bridged 802.4 Frame
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | pad 0x00 |
+---------------+---------------+
| NLPID 0x80 | OUI 0x00 |
+---------------+ --+
| OUI 0x80-C2 |
+-------------------------------+
| PID 0x00-02 or 0x00-08 |
+---------------+---------------+
| pad 0x00 | Frame Control |
+---------------+---------------+
| MAC destination address |
: :
| |
+-------------------------------+
| (remainder of MAC frame) |
+-------------------------------+
| LAN FCS (if PID is 0x00-02) |
+-------------------------------+
| FCS |
+-------------------------------+
Format of Bridged 802.5 Frame
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | pad 0x00 |
+---------------+---------------+
| NLPID 0x80 | OUI 0x00 |
+---------------+ --+
| OUI 0x80-C2 |
+-------------------------------+
| PID 0x00-03 or 0x00-09 |
+---------------+---------------+
| pad 0x00 | Frame Control |
+---------------+---------------+
| MAC destination address |
: :
| |
+-------------------------------+
| (remainder of MAC frame) |
+-------------------------------+
| LAN FCS (if PID is 0x00-03) |
| |
+-------------------------------+
| FCS |
+-------------------------------+
Format of Bridged FDDI Frame
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | pad 0x00 |
+---------------+---------------+
| NLPID 0x80 | OUI 0x00 |
+---------------+ --+
| OUI 0x80-C2 |
+-------------------------------+
| PID 0x00-04 or 0x00-0A |
+---------------+---------------+
| pad 0x00 | Frame Control |
+---------------+---------------+
| MAC destination address |
: :
| |
+-------------------------------+
| (remainder of MAC frame) |
+-------------------------------+
| LAN FCS (if PID is 0x00-04) |
| |
+-------------------------------+
| FCS |
+-------------------------------+
Format of Bridged 802.6 Frame
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | pad 0x00 |
+---------------+---------------+
| NLPID 0x80 | OUI 0x00 |
+---------------+ --+
| OUI 0x80-C2 |
+-------------------------------+
| PID 0x00-0B |
+---------------+---------------+ -------
| Reserved | BEtag | Common
+---------------+---------------+ PDU
| BAsize | Header
+-------------------------------+ -------
| MAC destination address |
: :
| |
+-------------------------------+
| (remainder of MAC frame) |
+-------------------------------+
| |
+- Common PDU Trailer -+
| |
+-------------------------------+
| FCS |
+-------------------------------+note that in bridge 802.6 PDUs, there is only one choice for the PID value, since the presence of a CRC-32 is indicated by the CIB bit in the header of the MAC frame 🙈
the Common Protocol Data Unit (CPDU) Header and Trailer are carried along so the egress bridge can do pipelining toward an 802.6 subnetwork 🚀 specifically, the CPDU Header has the BAsize field, which holds the length of the PDU. if that field isn't available to the egress 802.6 bridge, then the bridge can't start sending the segmented PDU until it has received the entire PDU, worked out the length, and put that length into the BAsize field. but if the field is available, the egress 802.6 bridge can pull the length out of the BAsize field of the Common PDU Header, stick it into the matching field of the first segment, and send that segment onto the 802.6 subnetwork right away. so the bridge can start transmitting the 802.6 PDU before the complete PDU has arrived. main character energy ⭐
one thing to note: the Common PDU Header and Trailer of the encapsulated frame should not just be copied over to the outgoing 802.6 subnetwork, because the encapsulated BEtag value may conflict with the BEtag value that bridge sent previously 😭
here's the BPDU frame 🌈
Format of BPDU Frame
+-------------------------------+
| Q.922 Address |
+-------------------------------+
| Control 0x03 |
+-------------------------------+
| PAD 0x00 |
+-------------------------------+
| NLPID 0x80 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-0E |
+-------------------------------+
| |
| BPDU as defined by |
| 802.1(d) or 802.1(g)[12] |
| |
+-------------------------------+
| FCS |
+-------------------------------+
Format of Source Routing BPDU Frame
+-------------------------------+
| Q.922 Address |
+-------------------------------+
| Control 0x03 |
+-------------------------------+
| PAD 0x00 |
+-------------------------------+
| NLPID 0x80 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-0F |
+-------------------------------+
| |
| Source Routing BPDU |
| |
| |
+-------------------------------+
| FCS |
+-------------------------------+5. Data Link Layer Parameter Negotiation ✨
Okay bestie, so Frame Relay stations MAY choose to support the Exchange Identification (XID) from Appendix III of Q.922 [1] 💅. This XID exchange lets you negotiate three parameters when a Frame Relay circuit gets set up: maximum frame size N201, retransmission timer T200, and the maximum number of outstanding Information (I) frames K 🎀.
A station can say it's not up for acknowledged mode multiple frame operation by setting the maximum window size K to zero 🙈.
If you skip this exchange, these values MUST be statically configured by mutual agreement of the Data Link Connection (DLC) endpoints, or MUST be defaulted to the values in Section 5.9 of Q.922. The defaults are:
N201: 260 octets
K: 3 for a 16 Kbps link,
7 for a 64 Kbps link,
32 for a 384 Kbps link,
40 for a 1.536 Mbps or above link
T200: 1.5 seconds [see Q.922 for further details]If a station that supports XID gets an XID frame, it SHALL respond with an XID response 🦋. When processing an XID, if the remote maximum frame size is smaller than the local maximum, the local system SHALL reduce the maximum size it uses over this DLC to the remotely specified value. Note that this SHALL be done before generating a response XID ✨.
The diagram below shows how XID is used to specify non-use of acknowledged mode multiple frame operation 👑.
Non-use of Acknowledged Mode Multiple Frame Operation
+---------------+
| Address | (2,3 or 4 octets)
| |
+---------------+
| Control 0xAF |
+---------------+
| format 0x82 |
+---------------+
| Group ID 0x80 |
+---------------+
| Group Length | (2 octets)
| 0x00-0E |
+---------------+
| 0x05 | PI = Frame Size (transmit)
+---------------+
| 0x02 | PL = 2
+---------------+
| Maximum | (2 octets)
| Frame Size |
+---------------+
| 0x06 | PI = Frame Size (receive)
+---------------+
| 0x02 | PL = 2
+---------------+
| Maximum | (2 octets)
| Frame Size |
+---------------+
| 0x07 | PI = Window Size
+---------------+
| 0x01 | PL = 1
+---------------+
| 0x00 |
+---------------+
| 0x09 | PI = Retransmission Timer
+---------------+
| 0x01 | PL = 1
+---------------+
| 0x00 |
+---------------+
| FCS | (2 octets)
| |
+---------------+6. Address Resolution for PVCs 🧚
Quick heads-up: this document only covers address resolution as it applies to PVCs 🌸. SVC operation will be talked about in future documents.
Sometimes a Frame Relay station really wants to dynamically resolve a protocol address over PVCs 💖. That can be done with the standard Address Resolution Protocol (ARP) [6], wrapped inside a SNAP-encoded Frame Relay packet, like this:
+-----------------------+-----------------------+
| Q.922 Address |
+-----------------------+-----------------------+
| Control (UI) 0x03 | pad 0x00 |
+-----------------------+-----------------------+
| NLPID 0x80 | | SNAP Header
+-----------------------+ OUI 0x00-00-00 + Indicating
| | ARP
+-----------------------+-----------------------+
| PID 0x0806 |
+-----------------------+-----------------------+
| ARP packet |
| . |
| . |
| . |
+-----------------------+-----------------------+Here's the ARP packet's format and values 🍓:
Data:
ar$hrd 16 bits Hardware type
ar$pro 16 bits Protocol type
ar$hln 8 bits Octet length of hardware address (n)
ar$pln 8 bits Octet length of protocol address (m)
ar$op 16 bits Operation code (request or reply)
ar$sha noctets source hardware address
ar$spa moctets source protocol address
ar$tha noctets target hardware address
ar$tpa moctets target protocol address
ar$hrd - assigned to Frame Relay is 15 decimal
(0x000F) [7].
ar$pro - see assigned numbers for protocol ID number for
the protocol using ARP. (IP is 0x0800).
ar$hln - length in bytes of the address field (2, 3, or 4)
ar$pln - protocol address length is dependent on the
protocol (ar$pro) (for IP ar$pln is 4).
ar$op - 1 for request and 2 for reply.
ar$sha - Q.922 source hardware address, with C/R, FECN,
BECN, and DE set to zero.
ar$tha - Q.922 target hardware address, with C/R, FECN,
BECN, and DE set to zero.Now, the tea ☕ on DLCIs: most Frame Relay networks only give DLCIs local significance, so an end station doesn't get a specific DLCI assigned to itself 😭. That means it has no address to put into the ARP request or reply. Lucky for us, the Frame Relay network CAN hand over the right DLCIs 🙌. The solution described below works just as well for a network where DLCIs have global significance ✨.
The DLCI in the Frame Relay header gets modified as the packet travels through the network 🦋. By the time the packet reaches its destination, the DLCI has been set to whatever value, from the receiving station's point of view, matches the sending station. For example, in Figure 1 below, if station A sends a message to station B, it puts DLCI 50 in the Frame Relay header. When station B gets that message, though, the network has modified the DLCI, and it shows up to B as DLCI 70 💅.
~~~~~~~~~~~~~~~
( )
+-----+ ( ) +-----+
| |-50------(--------------------)---------70-| |
| A | ( ) | B |
| |-60-----(---------+ ) | |
+-----+ ( | ) +-----+
( | )
( | ) <---Frame Relay
~~~~~~~~~~~~~~~~ network
80
|
+-----+
| |
| C |
| |
+-----+
Figure 1Lines between stations represent data link connections (DLCs). The numbers indicate the local DLCI associated with each connection.
Here's the DLCI to Q.922 Address Table for Figure 1 📋:
DLCI to Q.922 Address Table for Figure 1
DLCI (decimal) Q.922 address (hex)
50 0x0C21
60 0x0CC1
70 0x1061
80 0x1401If you want the authoritative version of the DLCI and Q.922 [1] address correlation, go read that spec 📚. A summary is included here for convenience. The translation between DLCI and Q.922 address is based on a two byte address length using the Q.922 encoding format, which looks like this:
8 7 6 5 4 3 2 1
+------------------------+---+--+
| DLCI (high order) |C/R|EA|
+--------------+----+----+---+--+
| DLCI (lower) |FECN|BECN|DE |EA|
+--------------+----+----+---+--+For ARP and its variants, the FECN, BECN, C/R and DE bits are assumed to be 0 🌈.
When an ARP message reaches its destination, all hardware addresses will be invalid 🙈. The address in the frame header will, however, be correct. Though it does violate the purity of layering 😤, Frame Relay MAY use the address in the header as the sender hardware address. It should also be noted that the target hardware address, in both ARP request and reply, will also be invalid. This shouldn't cause problems since ARP doesn't rely on these fields, and in fact, an implementation MAY zero fill or ignore the target hardware address field entirely 💜.
Let's walk through an example of how this address replacement scheme might work, using Figure 1 🧚. If station A (protocol address pA) wanted to resolve the address of station B (protocol address pB), it would format an ARP request with these values:
ARP request from A
ar$op 1 (request)
ar$sha unknown
ar$spa pA
ar$tha undefined
ar$tpa pBStation A doesn't have a source address associated with it, so the source hardware address field isn't valid. That means that when the ARP packet is received, it MUST extract the correct address from the Frame Relay header and place it in the source hardware address field 🔥. So the ARP request from A becomes:
ARP request from A as modified by B
ar$op 1 (request)
ar$sha 0x1061 (DLCI 70) from Frame Relay header
ar$spa pA
ar$tha undefined
ar$tpa pBNow station B's ARP can store station A's protocol address and Q.922 address association correctly 🎀. Next, station B forms a reply. Lots of implementations just copy the source addresses from the ARP request into the target addresses, then fill in the source addresses with their own. In that case, the ARP response would be:
ARP response from B
ar$op 2 (response)
ar$sha unknown
ar$spa pB
ar$tha 0x1061 (DLCI 70)
ar$tpa pAAgain, the source hardware address is unknown, so when the response arrives, station A extracts the address from the Frame Relay header and puts it in the source hardware address field 💅. Therefore, the response will become:
Okay so station A now officially knows that station B has protocol address pB tied to Q.922 address 0x0C21 (DLCI 50) 💖
ARP response from B as modified by A
ar$op 2 (response)
ar$sha 0x0C21 (DLCI 50)
ar$spa pB
ar$tha 0x1061 (DLCI 70)
ar$tpa pARARP [8] works the exact same way 🦋 Still using figure 1, if we say station C is an address server, these RARP exchanges happen:
RARP request from A RARP request as modified by C
ar$op 3 (RARP request) ar$op 3 (RARP request)
ar$sha unknown ar$sha 0x1401 (DLCI 80)
ar$spa undefined ar$spa undefined
ar$tha 0x0CC1 (DLCI 60) ar$tha 0x0CC1 (DLCI 60)
ar$tpa pC ar$tpa pCStation C then looks up the protocol address for Q.922 address 0x1401 (DLCI 80) and sends back the RARP response 💅
RARP response from C RARP response as modified by A
ar$op 4 (RARP response) ar$op 4 (RARP response)
ar$sha unknown ar$sha 0x0CC1 (DLCI 60)
ar$spa pC ar$spa pC
ar$tha 0x1401 (DLCI 80) ar$tha 0x1401 (DLCI 80)
ar$tpa pA ar$tpa pASo the Frame Relay interface MUST only intervene in the processing of incoming packets. That's the whole vibe 🫶
Okay now the no-multicast situation 😭 Without suitable multicast, ARP MAY still be implemented. The move is that the end station just sends a copy of the ARP request through each relevant DLC, which fakes a broadcast. Iconic workaround, honestly ✨
The use of multicast addresses in Frame Relay, as specified by [19], is currently being looked at by Frame Relay providers. Over time, multicast addressing may become useful for sending ARP requests and other "broadcast" messages 🌈
Broadcast emulation in Frame Relay is pretty inefficient, so a new variation was made. It's called Inverse ARP [11] and it's a method for resolving a protocol address when the hardware address is already known. In Frame Relay, the known hardware address is the DLCI 🎀 Support for Inverse ARP is not REQUIRED to implement this specification, but it has proven useful for Frame Relay interface autoconfiguration. Check [11] for its description and an example of how it's used with Frame Relay 🧚
Stations MUST be able to map more than one IP address in the same IP subnet (CIDR address prefix) to a particular DLCI on a Frame Relay interface. This need comes up with stuff like remote access, where servers MUST act as ARP proxies for lots of dial-in clients. Each client gets a unique IP address while sharing bandwidth on the same DLC 🍓 Because these applications change addresses constantly, the association changes happen a lot, and they have no effect on the DLC's status as reported by Frame Relay PVC Status Signaling. Main character energy for sure 👑
Stations can learn IP-to-DLCI associations just like on any other interface that uses ARP, by processing unsolicited ("gratuitous") ARP requests that arrive on the DLC. MAY is the key word here, bestie 💜 If one station (maybe a terminal server or remote access server) wants to tell its peer on the other end of a Frame Relay DLC about a new association between an IP address and that PVC, it SHOULD send an unsolicited ARP request. The source IP address is equal to the destination IP address, and both are set to the new IP address being used on the DLC. This lets a station "announce" new client connections on a particular DLCI 📣
The receiving station MUST store the new association, and remove any old existing association from any other DLCI on the interface, if necessary 🙈
7. IP over Frame Relay ✨
Internet Protocol [9] (IP) datagrams sent over a Frame Relay network follow the encapsulation we just covered. In this context, IP could be encapsulated in two different ways 🌸
- NLPID value indicating IP
+-----------------------+-----------------------+
| Q.922 Address |
+-----------------------+-----------------------+
| Control (UI) 0x03 | NLPID 0xCC |
+-----------------------+-----------------------+
| IP packet |
| . |
| . |
| . |
+-----------------------+-----------------------+- NLPID value indicating SNAP
+-----------------------+-----------------------+
| Q.922 Address |
+-----------------------+-----------------------+
| Control (UI) 0x03 | pad 0x00 |
+-----------------------+-----------------------+
| NLPID 0x80 | | SNAP Header
+-----------------------+ OUI = 0x00-00-00 + Indicating
| | IP
+-----------------------+-----------------------+
| PID 0x0800 |
+-----------------------+-----------------------+
| IP packet |
| . |
| . |
| . |
+-----------------------+-----------------------+Both of these encapsulations are supported under the given definitions, but it's way better to pick just one method for encapsulating IP data 💅 So IP data SHALL be encapsulated using the NLPID value of 0xCC indicating IP, as shown in option 1 above. Option 1 is more efficient in transmission (48 fewer bits) and matches how IP is encapsulated in X.25. Efficiency and consistency, iykyk 🎀
8. Other Protocols over Frame Relay ✨
Just like with IP, there are alternate ways to send other protocols within the scope of this definition. To avoid conflicts, the SNAP encapsulation is only used if no NLPID value is defined for the given protocol 🧚
For example, ISO CLNP has an NLPID defined (0x81). So the NLPID field indicates ISO CLNP and the data packet follows right after it. The frame looks like this:
+---------------------------------------------+
| Q.922 Address |
+----------------------+----------------------+
| Control (UI) 0x03 | NLPID 0x81 (CLNP) |
+----------------------+----------------------+
| remainder of CLNP packet |
| . |
| . |
+---------------------------------------------+Here the NLPID is what tells you the data packet is CLNP 🦋 It's also considered part of the CLNP packet, so the NLPID SHOULD NOT be removed before being sent up to the upper layers for processing. The NLPID is not duplicated, so no double vibes 🙅♀️
Other protocols, like IPX, don't have an NLPID value defined. As mentioned above, IPX gets encapsulated using the SNAP header instead. In that case, the frame looks like this:
+---------------------------------------------+
| Q.922 Address |
+----------------------+----------------------+
| Control (UI) 0x03 | pad 0x00 |
+----------------------+----------------------+
| NLPID 0x80 (SNAP) | OUI - 0x00 00 00 |
+----------------------+ |
| |
+---------------------------------------------+
| PID 0x8137 |
+---------------------------------------------+
| IPX packet |
| . |
| . |
+---------------------------------------------+9. Bridging Model for Frame Relay ✨
okay bestie, the bridging model for Frame Relay is literally identical to remote bridging from IEEE P802.1g "Remote MAC Bridging" [13] 💅 and it's built around the concept of "Virtual Ports" 🦋 Remote bridges have LAN ports that receive and transmit MAC frames to and from the LANs they're attached to. They can also receive and transmit MAC frames through virtual ports to and from other remote bridges. A virtual port can represent an abstraction of a remote bridge's point of access to one, two, or more other remote bridges 🫶
Remote bridges are statically configured as members of a remote bridge group by management 🎀 All members of a remote bridge group are connected by one or more virtual ports. The set of remote MAC bridges in a remote bridge group gives you actual or potential MAC layer interconnection between a set of LANs and other remote bridge groups the remote bridges attach to 🌈
In a Frame Relay network there must be a full mesh of Frame Relay VCs between bridges of a remote bridge group. If the Frame Relay network is not a full mesh, the bridge network must be divided into multiple remote bridge groups 🙈
The Frame Relay VCs that interconnect the bridges of a remote bridge group can be combined or used individually to form one or more virtual bridge ports. This gives you the flexibility to treat the Frame Relay interface either as a single virtual bridge port with all VCs in a group, or as a collection of bridge ports (individual or grouped VCs) ✨
When a single virtual bridge port provides the interconnectivity for all bridges of a given remote bridge group (aka all VCs are combined into a single virtual port), the standard Spanning Tree Algorithm may be used to determine the state of the virtual port. When more than one virtual port is configured within a given remote bridge group, then an "extended" Spanning Tree Algorithm is required. That extended algorithm is defined in IEEE 802.1g [13]. The cute part is how it works: a virtual port only gets put into backup if there is a loop in the network external to the remote bridge group 😭
The simplest bridge configuration for a Frame Relay network is the LAN view, where all VCs are combined into a single virtual port. Frames, such as BPDUs, which would be broadcast on a LAN, must be flooded to each VC (or multicast if the service is developed for Frame Relay services). Flooding is performed by sending the packet to each relevant DLC associated with the Frame Relay interface. The VCs in this environment are generally invisible to the bridge. That means the bridge sends a flooded frame to the Frame Relay interface and does not "see" that the frame is being forwarded to each VC individually. If all participating bridges are fully connected (full mesh), the standard Spanning Tree Algorithm will suffice in this configuration 🧚
Typically LAN bridges learn which interface a particular end station may be reached on by associating a MAC address with a bridge port. In a Frame Relay network configured for the LAN-like single bridge port (or any set of VCs grouped together to form a single bridge port), however, the bridge must not only associated a MAC address with a bridge port, but it must also associate it with a connection identifier. For Frame Relay networks, this connection identifier is a DLCI. It is unreasonable and perhaps impossible to require bridges to statically configure an association of every possible destination MAC address with a DLC. Therefore, Frame Relay LAN-modeled bridges must provide a mechanism to allow the Frame Relay bridge port to dynamically learn the associations. To accomplish this dynamic learning, a bridged packet shall conform to the encapsulation described within section 4.2. In this way, the receiving Frame Relay interface will know to look into the bridged packet to gather the appropriate information 👑
A second Frame Relay bridging approach, the point-to-point view, treats each Frame Relay VC as a separate bridge port. Flooding and forwarding packets are significantly less complicated using the point-to-point approach, because each bridge port has only one destination. There is no need to perform artificial flooding or to associate DLCIs with destination MAC addresses. Depending upon the interconnection of the VCs, an extended Spanning Tree algorithm may be required to permit all virtual ports to remain active as long as there are no true loops in the topology external to the remote bridge group 🦋
It is also possible to combine the LAN view and the point-to-point view on a single Frame Relay interface. To do this, certain VCs are combined to form a single virtual bridge port while other VCs are independent bridge ports 💜
The following drawing illustrates the different possible bridging configurations. The dashed lines between boxes represent virtual circuits.
+-------+
-------------------| B |
/ -------| |
/ / +-------+
/ |
+-------+/ \ +-------+
| A | -------| C |
| |-----------------------| |
+-------+\ +-------+
\
\ +-------+
\ | D |
-------------------| |
+-------+Since there is less than a full mesh of VCs between the bridges in this example, the network must be divided into more than one remote bridge group. A reasonable configuration is to have bridges A, B, and C in one group, and have bridges A and D in a second. 🙈
Configuration of the first bridge group combines the VCs interconnecting the three bridges (A, B, and C) into a single virtual port. This is an example of the LAN view configuration. The second group would also be a single virtual port, which simply connects bridges A and D. In this configuration, the standard Spanning Tree Algorithm is sufficient to detect loops 🌸
An alternative configuration has three individual virtual ports in the first group, corresponding to the VCs interconnecting bridges A, B, and C. Since the application of the standard Spanning Tree Algorithm to this configuration would detect a loop in the topology, an extended Spanning Tree Algorithm would have to be used in order for all virtual ports to be kept active. Note that the second group would still consist of a single virtual port, and the standard Spanning Tree Algorithm could be used in this group 🍓
Using the same drawing, one could construct a remote bridge scenario with three bridge groups. This would be an example of the point-to-point case. Here, the VC connecting A and B, the VC connecting A and C, and the VC connecting A and D are all bridge groups with a single virtual port. 🎀
10. Security Considerations 🔐
This document defines mechanisms for identifying the multiprotocol encapsulation of datagrams over Frame Relay. There is obviously an element of trust in any encapsulation protocol: a receiver must trust that the sender has correctly identified the protocol being encapsulated. In general, there is no way for a receiver to try to ascertain that the sender did indeed use the proper protocol identification, nor would this be desired functionality. 😬
It also specifies the use of ARP and RARP with Frame Relay, and it is subject to the same security constraints that affect ARP and similar address resolution protocols. Because authentication is not a part of ARP, there are known security issues relating to its use (e.g., host impersonation). No additional security mechanisms have been added to ARP or RARP for use with Frame Relay networks. This is a real danger zone, bestie, so please take it seriously 💀🚨
11. Appendix A - NLPIDS and PIDs 🌈
List of Commonly Used NLPIDs
0x00 Null Network Layer or Inactive Set
(not used with Frame Relay)
0x08 Q.933 [2]
0x80 SNAP
0x81 ISO CLNP
0x82 ISO ESIS
0x83 ISO ISIS
0x8E IPv6
0xB0 FRF.9 Data Compression [14]
0xB1 FRF.12 Fragmentation [18]
0xCC IPv4
0xCF PPP in Frame Relay [17]List of PIDs of OUI 00-80-C2
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-0B 802.6
0x00-0D Fragments
0x00-0E BPDUs as defined by
802.1(d) or
802.1(g)[12].
0x00-0F Source Routing BPDUs12. Appendix B - Connection Oriented Procedures 🎀
okay so this appendix is basically the extra notes for using ITU Recommendation Q.933 [2] and other ITU standards to encapsulate data over frame relay 🦋 It's super similar to (sometimes identical to!) Annex E of Q.933. Annex E is the official source, and this is just repeated here for convenience, so if you're ever unsure, go check Annex E ✨
The Network Level Protocol ID (NLPID) field is administered by ISO and the ITU. It has values for lots of protocols, including IP, CLNP (ISO 8473), ITU Q.933, and ISO 8208. Here's a picture of the generic encapsulation scheme over frame relay networks. The flexibility is the best part 💅 You can use multiple alternatives to identify different protocols, whether they're being used by:
- end-to-end systems, or
- LAN to LAN bridges and routers, or
- a combination of the above
over frame relay networks.
Q.922 control
|
|
--------------------------------------------
| |
UI I Frame
| |
--------------------------------- --------------
| 0x08 | 0x81 |0xCC | 0x80 |..01.... |..10....
| | | | | |
Q.933 CLNP IP SNAP ISO 8208 ISO 8208
| | Modulo 8 Modulo 128
| |
-------------------- OUI
| | |
L2 ID L3 ID -------
| User | |
| Specified | |
| 0x70 802.3 802.6
|
---------------------------
|0x51 |0x4E | |0x4C |0x50
| | | | |
7776 Q.922 Others 802.2 User
SpecifiedFor protocols that don't have an NLPID assigned or don't have a SNAP encapsulation, the NLPID value of 0x08 (which means ITU Recommendation Q.933) should be used 🌸 The four octets after the NLPID carry both the layer 2 and layer 3 protocol identification. Most protocol code points are currently defined in the ITU Q.933 low layer compatibility information element. The "User Specified" code points are described in Frame Relay Forum FRF.3.1 [15]. There's also an escape hatch for defining non-standard protocols 🧚
Format of Other Protocols
using Q.933 NLPID
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | NLPID 0x08 |
+---------------+---------------+
| L2 Protocol ID |
| octet 1 | octet 2 |
+---------------+---------------+
| L3 Protocol ID |
| octet 1 | octet 2 |
+---------------+---------------+
| Protocol Data |
+-------------------------------+
| FCS |
+-------------------------------+
ISO 8802/2 with user specified
layer 3
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | NLPID 0x08 |
+---------------+---------------+
| 802/2 0x4C | 0x80 |
+---------------+---------------+
|User Spec. 0x70| Note 1 |
+---------------+---------------+
| DSAP | SSAP |
+---------------+---------------+
| Control (Note 2) |
+-------------------------------+
| Remainder of PDU |
+-------------------------------+
| FCS |
+-------------------------------+
Note 1: Indicates the code point for user specified
layer 3 protocol.
Note 2: Control field is two octets for I-format and
S-format frames (see 88002/2)Encapsulations using I frame (layer 2)
The Q.922 I frame is for layer 3 protocols that need an acknowledged data link layer, like ISO 8208 🍓 The C/R bit gets used for command and response indications.
Format of ISO 8208 frame
Modulo 8
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| ....Control I frame |
+---------------+---------------+
| 8208 packet (modulo 8) Note 3 |
| |
+-------------------------------+
| FCS |
+-------------------------------+
Note 3: First octet of 8208 packet also identifies the
NLPID which is "..01....".
Format of ISO 8208 frame
Modulo 128
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| ....Control I frame |
+---------------+---------------+
| 8208 packet (modulo 128) |
| Note 4 |
+-------------------------------+
| FCS |
+-------------------------------+
Note 4: First octet of 8208 packet also identifies the
NLPID which is "..10....".13. Appendix C - Modifications from RFC 1490 💜
RFC 1490 got seriously widely implemented and used 🙌 It was adopted by the Frame Relay Forum in FRF.3.1 [15] and by the ITU in Q.933 [2]. This section lists the updates made to RFC 1490 based on all that implementation and interop experience, reflecting what people are actually doing in practice.
Some wording changes were needed to clarify RFC 1490. None of them touched the technical side. They just kept the diagrams and language specific and consistent. The specifics of those changes won't be listed here. Below are the significant ones 👑
a) The requirement for stations to accept SNAP encapsulated protocols that had a NLPID available was removed. RFC 1490 said that if a protocol, like IP, had a designated NLPID value, it must be used. Later on, the document required stations to accept a SNAP encapsulated version of that same protocol. That's clearly inconsistent 🙃 A compliant station must send and accept the NLPID encapsulated version of such a protocol. It MAY accept the SNAP encapsulation, but it should not be required to, since those frames are noncompliant.
b) Fragmentation was removed. So far, there are no interoperable implementations of the fragmentation algorithm in RFC 1490. Plus, several people pointed out that the proposed mechanisms aren't enough for some frame relay applications. So fragmentation was dropped from this document and replaced by the fragmentation specified in FRF.12 [18] ✨
c) The address resolution in RFC 1490 only covered PVC environments and isn't enough for SVC environments. That's why the section title was changed to match. More SVC address resolution work will happen in the ION working group 🦋
d) An encapsulation for Source Routing BPDUs was added, and the lists in Appendix A were expanded.
e) The use of canonical and non-canonical MAC destination addresses in the bridging encapsulations was clarified 💅
f) The Inverse ARP description was moved over to the Inverse ARP specification [11].
g) A brand new security section was added 🔐
14. References 📚
[1] International Telecommunication Union, "ISDN Data Link Layer Specification for Frame Mode Bearer Services", ITU-T Recommendation Q.922, 1992.
[2] International Telecommunication Union, "Signalling Specifications for Frame Mode Switched and Permanent Virtual Connection Control and Status Monitoring", ITU-T Recommendation Q.933, 1995.
[3] Information technology - Telecommunications and Information Exchange between systems - Protocol Identification in the Network Layer, ISO/IEC TR 9577: 1992.
[4] Baker, F., and R. Bowen, "PPP Bridging Control Protocol (BCP)", RFC 1638, June 1994.
[5] International Standard, Information Processing Systems - Local Area Networks - Logical Link Control, ISO 8802-2, ANSI/IEEE, Second Edition, 1994-12-30.
[6] Plummer, D., "An Ethernet Address Resolution Protocol - or - Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, November 1982.
[7] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. See also: http://www.iana.org/numbers.html
[8] Finlayson, R., Mann, R., Mogul, J., and M. Theimer, "A Reverse Address Resolution Protocol", STD 38, RFC 903, June 1984.
[9] Postel, J., and J. Reynolds, "A Standard for the Transmission of IP Datagrams over IEEE 802 Networks", RFC 1042, February 1988.
[10] IEEE, "IEEE Standard for Local and Metropolitan Area Networks: Overview and architecture", IEEE Standard 802-1990.
[11] Bradley, T., Brown, C., and A. Malis, "Inverse Address Resolution Protocol", RFC 2390, September 1998.
[12] IEEE, "IEEE Standard for Local and Metropolitan Networks: Media Access Control (MAC) Bridges", IEEE Standard 802.1D-1990.
[13] ISO/IEC 15802-5 : 1998 (IEEE Standard 802.1G), Remote Media Access Control (MAC) Bridging, March 12, 1997.
[14] Frame Relay Forum, "Data Compression Over Frame Relay Implementation Agreement", FRF.9, January 22, 1996.
[15] Frame Relay Forum, "Multiprotocol Encapsulation Implementation Agreement", FRF.3.1, June 22, 1995.
[16] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[17] Simpson, W., "PPP in Frame Relay", RFC 1973, June 1996.
[18] Frame Relay Forum, "Frame Relay Fragmentation Implementation Agreement", FRF.12, December 1997.
[19] Frame Relay Forum, "Frame Relay PVC Multicast Service and Protocol Implementation Agreement", FRF.7, October 21, 1994.
15. Authors' Addresses 💖
Caralyn Brown
Consultant
EMail: cbrown@juno.com
Andrew Malis
Ascend Communications, Inc.
1 Robbins Road
Westford, MA 01886
Phone: (978) 952-7414
EMail: malis@ascend.com16. Full Copyright Statement ✨
Okay bestie, the legal part 🙈 but it matters, so read it with me!!
Copyright (C) The Internet Society (1998). All Rights Reserved. 💜
So the permissions are super generous. Anyone can copy this doc and share it, and they can make derivative works that comment on it, explain it, or help people implement it. Those works can be prepared, copied, published, and distributed, in whole or in part, with no restrictions of any kind 🦋. The one condition is that the above copyright notice and this paragraph stay on every copy and every derivative work.
BUT the document itself can't be modified in any way. You can't remove the copyright notice or the references to the Internet Society or other Internet organizations. There are two exceptions:
- You can do it when it's needed for developing Internet standards, but then the copyright procedures in the Internet Standards process have to be followed. 📜
- You can do it to translate the document into languages other than English. 🌍
The limited permissions above are perpetual, and the Internet Society or its successors or assigns will never revoke them. Forever and ever 🫶
Now the disclaimer, which is in all caps for a reason 💀 (the exact wording, so nobody can say we changed it):
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: it's given to you as-is, and the Internet Society and the IETF aren't promising anything extra. Periodt 💅
📦 where this page comes from
- ietf: rfc2427 1998-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms