RFC 1294
Multiprotocol Interconnect over Frame Relay
RFC 1294: Multiprotocol Interconnect over Frame Relay 🎀
Network Working Group 💖
Request for Comments: 1294 ✨
Authors: T. Bradley and C. Brown (both Wellfleet Communications, Inc.), and A. Malis (BBN Communications) 🧚
Date: January 1992 📅
Track: IAB standards track protocol 👑 (see Section 1 below)
Obsoletes/Updates: The title block doesn't list anything this RFC obsoletes or updates 🌸
1. Status of this Memo ✨
This RFC is an IAB standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of the "IAB Official Protocol Standards." Distribution of this memo is unlimited 🦋
2. 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. Systems that can transfer both this encapsulation method and others MUST have a priori knowledge of which virtual circuits will carry which encapsulation method. This encapsulation MUST only be used over virtual circuits that have been explicitly configured for its use. Be careful with this one, bestie! 🌈
3. Acknowledgements 🫶
Lots of people helped make this document happen 😭 Comments and contributions from Ray Samora of Proteon, Ken Rehbehn of Netrix Corporation, Fred Baker and Charles Carvalho of Advanced Computer Communications, and Mostafa Sherif of AT&T were all incorporated. Special thanks to Dory Leifer of the University of Michigan for helping sort out the fragmentation issues. And this document could never have happened without the expertise of the IP over Large Public Data Networks working group of the IETF. Iconic team 👑
4. Conventions 📝
The items of specification in this document use the following language conventions:
- MUST, SHALL or Mandatory: the item is an absolute requirement of the specification. 💅
- SHOULD or RECOMMENDED: the item should generally be followed, except in exceptional circumstances. 🌸
- MAY or OPTIONAL: the item is truly optional. You can follow it or ignore it, depending on what the implementor needs. 🦋
5. Introduction 🧚
This discussion is for devices that act as end stations (DTEs) on a public or private Frame Relay network, like one provided by a common carrier or PTT. It won't cover the behavior of stations that are part of the Frame Relay network (DCEs), except to explain situations where the DTE MUST react. Not me explaining DCE behavior when it isn't your problem 🙈
The Frame Relay network gives you a bunch of virtual circuits, and those form the basis for connections between stations attached to the same Frame Relay network. The resulting set of interconnected devices forms a private Frame Relay group. It 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. Local only, bestie 🍓
The specifications in this document are meant to apply to both switched and permanent virtual circuits. ✨
6. Frame Format 💖
All protocols MUST encapsulate their packets within a Q.922 Annex A frame [1,2]. Frames SHALL also contain information needed 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) |
+-----------------------------+
| Optional Pad(s) (0x00) |
+-----------------------------+
| NLPID |
+-----------------------------+
| . |
| . |
| . |
| Data |
| . |
| . |
+-----------------------------+
| Frame Check Sequence |
+-- . --+
| (two octets) |
+-----------------------------+
| flag (7E hexadecimal) |
+-----------------------------+- Q.922 addresses, as currently 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's negotiated otherwise. Using XID (0xAF or 0xBF) is permitted, and we'll get to that later 🎀
The pad field is an optional field used to line up the rest of the frame on a convenient boundary for the sender. There MAY be zero or more pad octets in the pad field, and all of them MUST have a value of zero. Zero vibes only 🧘
The Network Level Protocol ID (NLPID) field is administered by ISO and CCITT. It holds values for a bunch of different protocols, including IP, CLNP, and IEEE Subnetwork Access Protocol (SNAP)[10]. This field tells the receiver what encapsulation or protocol comes next. The values are defined in ISO/IEC TR 9577 [3]. Within ISO/IEC TR 9577, an NLPID value of 0x00 is defined as the Null Network Layer or Inactive Set. It can't be told apart from a pad field, and it has no significance in this encapsulation scheme, so an NLPID value of 0x00 is invalid under the Frame Relay encapsulation. The known NLPID values are listed in the Appendix. 📚
For full interoperability with older Frame Relay encapsulation formats, a station MAY implement section 15, Backward Compatibility. It's giving legacy compatibility 🕰️
There isn't a commonly implemented 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 let the maximum acceptable frame size be configurable. Customizable, bestie 💅
The minimum frame size allowed for Frame Relay is five octets between the opening and closing flags. ✨
7. 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 indication that the destination can use to correctly interpret the contents of the frame. That indication is embedded in the NLPID and SNAP header information. Main character energy 👑
For protocols that don't have an NLPID already assigned, there needs to be a way to make identification easy. An NLPID value is defined to indicate that a SNAP header is present 🦋
A SNAP header is of the form:
+-------------------------------+
| Organizationally Unique |
+-- +---------------+
| Identifier | Protocol |
+---------------+---------------+
| Identifier |
+---------------+All stations MUST be able to accept and properly interpret both the NLPID encapsulation and the SNAP header encapsulation for a routed packet. Both, always 💖
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 means the following PID is an EtherType. 🍓
7.1. Routed Frames 🚀
Some protocols have an assigned NLPID, but the NLPID numbering space is so limited that many protocols don't have one. When packets from those protocols are routed over Frame Relay networks, they're sent using NLPID 0x80 (which means a SNAP follows), OUI 0x00-00-00 (which means an EtherType follows), and the EtherType of the protocol in use. Very specific, very intentional 🎀
Format of Routed Frames
+-------------------------------+
| Q.922 Address |
+-------------------------------+
|Control 0x03 | pad(s) 0x00 |
+-------------------------------+
| NLPID 0x80 | OUI 0x00 |
+---------------+ --+
| OUI 0x00-00 |
+-------------------------------+
| EtherType |
+-------------------------------+
| Protocol Data |
+-------------------------------+
| FCS |
+-------------------------------+In the few cases where a protocol has an assigned NLPID (see appendix), 48 bits can be saved using the format below:
Format of Routed NLPID Protocol
+-------------------------------+
| Q.922 Address |
+-------------------------------+
|Control 0x03 | NLPID |
+-------------------------------+
| Protocol Data |
+-------------------------------+
| FCS |
+-------------------------------+In the particular case of an Internet IP datagram, the NLPID is 0xCC.
Format of Routed IP Datagram
+-------------------------------+
| Q.922 Address |
+-------------------------------+
|Control 0x03 | NLPID 0xCC |
+-------------------------------+
| IP Datagram |
+-------------------------------+
| FCS |
+-------------------------------+Part 1 of 5 done, bestie! 🎀 More is coming in part 2 💜
7.2. Bridged Frames 🌸
okay so the second type of Frame Relay traffic is bridged packets 🎀 These get wrapped with NLPID value 0x80, which means SNAP, and the SNAP header that follows tells you what format the bridged packet is in 💅 The OUI is the 802.1 organization code 0x00-80-C2 🧚 Then the next two octets are the PID, and they tell you the form of the MAC header sitting right after the SNAP header. The PID also tells you whether the original FCS is preserved inside the bridged frame ✨
The 802.1 folks 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-05 0x00-0B 802.6and ALSO, the PID value 0x00-0E, when used with OUI 0x00-80-C2, means Bridged Protocol Data Units (BPDUs) 🫶
A packet bridged over Frame Relay will, therefore, have one of these formats 🦋
Format of Bridged Ethernet/802.3 Frame
+-------------------------------+
| Q.922 Address |
+-------------------------------+
|Control 0x03 | pad(s) 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(s) 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(s) 0x00 |
+-------------------------------+
| NLPID 0x80 | OUI 0x00 |
+---------------+ --+
| OUI 0x80-C2 |
+-------------------------------+
| PID 0x00-03 or 0x00-09 |
+-------------------------------+
| Access Control| 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(s) 0x00 |
+-------------------------------+
| NLPID 0x80 | OUI 0x00 |
+---------------+ --+
| OUI 0x80-C2 |
+-------------------------------+
| PID 0x00-04 or 0x00-0A |
+-------------------------------+
| Access Control| 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(s) 0x00 |
+-------------------------------+
| NLPID 0x80 | OUI 0x00 |
+---------------+ --+
| OUI 0x80-C2 |
+-------------------------------+
| PID 0x00-05 or 0x00-0B |
+-------------------------------+
| Reserved | BEtag | Common
+---------------+---------------+ PDU
| BAsize | Header
+-------------------------------+
| MAC destination address |
+-------------------------------+
| (remainder of MAC frame) |
+-------------------------------+
| |
+- Common PDU Trailer -+
| |
+-------------------------------+
| FCS |
+-------------------------------+The Common Protocol Data Unit (PDU) Header and Trailer are carried along so the egress bridge can pipeline things out to an 802.6 subnetwork 🎀 Here's the tea: the Common PDU Header has the BAsize field, and BAsize holds the length of the PDU 📏 If the egress 802.6 bridge doesn't have access to this field, it can't start transmitting the segmented PDU until it has received the whole thing, 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 it has the complete PDU, which is honestly iconic ✨
One should note that the Common PDU Header and Trailer of the encapsulated frame should 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 🙈
Here's what a BPDU frame looks like 🧚
Format of BPDU Frame
+-------------------------------+
| Q.922 Address |
+-------------------------------+
|Control 0x03 | pad(s) 0x00 |
+-------------------------------+
| NLPID 0x80 | OUI 0x00 |
+---------------+ --+
| OUI 0x80-C2 |
+-------------------------------+
| PID 0x00-0E |
+-------------------------------+ ----
| 802.1(d) Protocol Identifier | BPDU, as defined
+-------------------------------+ by 802.1(d),
| Version = 00 | BPDU Type | section 5.3
+-------------------------------+
| (remainder of BPDU) |
+-------------------------------+ ----
| FCS |
+-------------------------------+8. Data Link Layer Parameter Negotiation ✨
okay this part is giving negotiation energy 💅 Frame Relay stations may choose to support the Exchange Identification (XID) from Appendix III of Q.922 [1]. The XID exchange lets you negotiate these parameters when a Frame Relay circuit gets initialized: maximum frame size N201, retransmission timer T200, and the maximum number of outstanding 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 this exchange isn't used, 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:
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 receives 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 gets 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)
| |
+---------------+9. Fragmentation Issues ✨
okay bestie, fragmentation is how we send packets that are chunkier than the biggest frame the network can carry 📦 On Frame Relay the network might only support a max frame size as small as 262 octets 😭 That's tiny, so fragmentation and reassembly are super useful here 💅
Unlike IP fragmentation, the Frame Relay fragmentation procedure is limited to the boundary (or DTEs) of the Frame Relay network 🦋
The fragmented packet looks a lot like any other encapsulated protocol, with one big difference: it keeps the encapsulation header 🎀 So the packet gets encapsulated first (except for the address and control fields), as defined above. Then the big packet gets chopped into frames that fit the Frame Relay network, and each piece is encapsulated using the Frame Relay fragmentation format 🧩 The receiving station can put the fragments back together and then send the rebuilt packet through the same processing path as a packet that was never fragmented. Iconic, right? 👑
Fragments are encapsulated using the SNAP format with an OUI of 0x00-80-C2 and a PID of 0x00-0D 🌸 So each individual fragment looks like this:
+---------------+---------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | pad 0x00 |
+---------------+---------------+
| NLPID 0x80 | OUI 0x00 |
+---------------+---------------+
| OUI 0x80-C2 |
+---------------+---------------+
| PID 0x00-0D |
+---------------+---------------+
| sequence number |
+---------------+---------------+
|F| RSVD |offset |
+---------------+---------------+
| fragment data |
| . |
| . |
| . |
+---------------+---------------+
| FCS |
+---------------+---------------+The sequence field is a two octet identifier 🔢 It gets incremented every time a new complete message is fragmented, which lets the receiver detect lost frames. It's set to a random value at initialization, so it's not starting from zero every time 🎲
The reserved field is 4 bits long and isn't currently defined 🙈 It must be set to 0.
The final bit is a one bit field 🏁 It's set to 1 on the last fragment and set to 0 for all other fragments.
The offset field is an 11 bit value that represents the logical offset of this fragment in bytes divided by 32 📏 The first fragment must have an offset of zero.
Here's a visual of a large IP datagram getting fragmented over Frame Relay. In this example, the whole datagram gets split into two Frame Relay frames 🦋 Watch the offsets!
Frame Relay Fragmentation Example
+-----------+-----------+
| Q.922 Address |
+-----------+-----------+
| Ctrl 0x03 | pad 0x00 |
+-----------+-----------+
|NLPID 0x80 | OUI 0x00 |
+-----------+-----------+
| OUI 0x80-C2 |
+-----------+-----------+ +-----------+-----------+
| pad 0x00 |NLPID 0xCC | | PID 0x00-0D |
+-----------+-----------+ +-----------+-----------+
| | | sequence number n |
| | +-----------+-----------+
| | |0| RSVD |offset (0) |
| | +-----------+-----------+
| | | pad 0x00 |NLPID 0xCC |
| | +-----------+-----------+
| | | first m bytes of |
| large IP datagram | ... | IP datagram |
| | | |
| | +-----------+-----------+
| | | FCS |
| | +-----------+-----------+
| |
| | +-----------+-----------+
| | | Q.922 Address |
| | +-----------+-----------+
| | | Ctrl 0x03 | pad 0x00 |
+-----------+-----------+ +-----------+-----------+
|NLPID 0x80 | OUI 0x00 |
+-----------+-----------+
| OUI 0x80-C2 |
+-----------+-----------+
| PID 0x00-0D |
+-----------+-----------+
| sequence number n |
+-----------+-----------+
|1| RSVD |offset (m/32) |
+-----------+-----------+
| remainder of IP |
| datagram |
+-----------+-----------+
| FCS |
+-----------+-----------+Fragments must be sent in order, starting with a zero offset and ending with the final fragment 🚂 They must not be interrupted with other packets or information intended for the same DLC, so no sneaking in other stuff mid-train 🙅♀️ An end station must be able to re-assemble up to 2K octets, and it's suggested to support up to 8K octet re-assembly 💜
If at any time during reassembly a fragment is corrupted or a fragment is missing, the entire message is dropped 💀 The upper layer protocol is responsible for any retransmission in this case.
This fragmentation algorithm is not intended to reliably handle all possible failure conditions 😭 Just like IP fragmentation, there's a small possibility of a reassembly error and delivery of an erroneous packet. Including a higher layer checksum greatly reduces this risk 🫶 Protect yourself, bestie!
10. Address Resolution ✨
okay so sometimes a Frame Relay station needs to figure out a protocol address dynamically, and bestie, this is where ARP comes in 💅 It can be done with the standard Address Resolution Protocol (ARP) [6], wrapped up inside a SNAP encoded Frame Relay packet, and it looks like this 🎀
+-----------------------+-----------------------+
| Q.922 Address |
+-----------------------+-----------------------+
| Control (UI) 0x03 | pad(s) 0x00 |
+-----------------------+-----------------------+
| NLPID = 0x80 | | SNAP Header
+-----------------------+ OUI = 0x00-00-00 + Indicating
| | ARP
+-----------------------+-----------------------+
| PID = 0x0806 |
+-----------------------+-----------------------+
| ARP packet |
| . |
| . |
| . |
+-----------------------+-----------------------+So the ARP packet itself has these fields 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 here's the tea ☕ Because DLCIs in most Frame Relay networks only have local significance, an end station doesn't have a specific DLCI assigned to itself. So that station has no address to stuff into the ARP request or reply. Lowkey tragic, but the Frame Relay network has a trick for getting the correct DLCIs 🫶 The solution below is written for a locally addressed Frame Relay network, but it works just as well when DLCIs have global significance.
The DLCI in the Frame Relay header gets changed as it travels through the network. When 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. Check out figure 1: if station A sends a message to station B, it puts DLCI 50 in the Frame Relay header. By the time B gets it, the network has changed it, and it shows up to B as DLCI 70 🌸
~~~~~~~~~~~~~~~
( )
+-----+ ( ) +-----+
| |-50------(--------------------)---------70-| |
| A | ( ) | B |
| |-60-----(---------+ ) | |
+-----+ ( | ) +-----+
( | )
( | ) <---Frame Relay
~~~~~~~~~~~~~~~~ network
80
|
+-----+
| |
| C |
| |
+-----+
Figure 1Lines between stations are data link connections (DLCs), and the numbers are the local DLCI for each connection 💜
DLCI to Q.922 Address Table for Figure 1
DLCI (decimal) Q.922 address (hex)
50 0x0C21
60 0x0CC1
70 0x1061
80 0x1401If you already know frame relay, you'll totally get the link between DLCI and Q.922 address 🧚 For everyone else: the DLCI to Q.922 address translation uses a two byte address length with 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, every hardware address in it is invalid. The address in the frame header, though, will be correct. Frame Relay may use the header address as the sender hardware address, even though that bends the purity of layering a little bit. The target hardware address in both the ARP request and reply is also invalid. That shouldn't cause problems, since ARP doesn't rely on those fields, and an implementation may zero fill or ignore the target hardware address field entirely.
Let's walk through a full example with figure 1 🎀 Say station A (protocol address pA) wants to resolve the address of station B (protocol address pB). It formats an ARP request like this:
ARP request from A
ar$op 1 (request)
ar$sha unknown
ar$spa pA
ar$tha undefined
ar$tpa pBStation A has no source address of its own, so its source hardware address field isn't valid. That means when the ARP packet is received, the receiver must pull the correct address out of the Frame Relay header and drop it into the source hardware address field. So the ARP request from A turns into this:
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 B's ARP can store the association between station A's protocol address and its Q.922 address, correctly 🙌 Next, B forms a reply. A lot of implementations just copy the source addresses from the ARP request into the target addresses, then fill in the source addresses with their own. So B's ARP response looks like this:
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 A receives the response, it pulls the address out of the Frame Relay header and puts it in the source hardware address field. The response becomes:
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 pAAnd just like that, station A correctly recognizes that station B, with protocol address pB, is tied to Q.922 address 0x0C21 (DLCI 50) 🦋
Reverse ARP (RARP) [8] works in exactly the 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 that goes with Q.922 address 0x1401 (DLCI 80) and sends 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 pAWhat this boils down to is that the Frame Relay interface only has to intervene when it's processing incoming packets ✨
If suitable multicast isn't available, ARP can still be implemented 🍓 The end station just sends a copy of the ARP request through each relevant DLC, which simulates a broadcast.
Multicast addressing in a Frame Relay environment is still being studied by Frame Relay providers 🔥 Once the multicasting issues are sorted out, multicast addressing may become useful for sending ARP requests and other "broadcast" messages.
Broadcasting in Frame Relay is pretty inefficient, so a new address resolution variation was developed 😭 It's called Inverse ARP [11], and it's a way to resolve a protocol address when the hardware address is already known. In Frame Relay, the known hardware address is the DLCI. Inverse ARP follows the same pattern that ARP and RARP use: the source hardware address gets inserted at the receiving station.
In our example, station A can use Inverse ARP to find the protocol address of the station on its DLCI 50. The Inverse ARP request looks like this:
InARP Request from A (DLCI 50)
ar$op 8 (InARP request)
ar$sha unknown
ar$spa pA
ar$tha 0x0C21 (DLCI 50)
ar$tpa unknownWhen station B receives this packet, it swaps the source hardware address for the Q.922 address from the Frame Relay header. So the InARP request from A becomes:
ar$op 8 (InARP request)
ar$sha 0x1061
ar$spa pA
ar$tha 0x0C21
ar$tpa unknown.Station B formats an Inverse ARP response and sends it to station A, the same way it would for any ARP message 💅
11. IP over Frame Relay ✨
Okay bestie, IP datagrams riding over Frame Relay follow the exact same encapsulation we already covered 💖 and IP can be wrapped up in two different ways 🎀
1. NLPID value indicating IP
+-----------------------+-----------------------+
| Q.922 Address |
+-----------------------+-----------------------+
| Control (UI) 0x03 | NLPID = 0xCC |
+-----------------------+-----------------------+
| IP Packet . |
| . |
| . |
+-----------------------+-----------------------+2. NLPID value indicating SNAP
+-----------------------+-----------------------+
| Q.922 Address |
+-----------------------+-----------------------+
| Control (UI) 0x03 | pad(s) 0x00 |
+-----------------------+-----------------------+
| NLPID = 0x80 | | SNAP Header
+-----------------------+ OUI = 0x00-00-00 + Indicating
| | IP
+-----------------------+-----------------------+
| PID = 0x0800 |
+-----------------------+-----------------------+
| IP packet |
| . |
| . |
| . |
+-----------------------+-----------------------+Both of these are supported under the definitions, but it's way better to pick ONE method 🙌 So IP data SHALL be encapsulated using the NLPID value of 0xCC indicating IP, like option 1 above. This one is more efficient in transmission (48 fewer bits!) and it's consistent with how IP gets encapsulated over X.25 🔥
12. Other Protocols over Frame Relay 🧚
Same deal as with IP, there are alternate ways to send various protocols within this definition. To avoid conflicts, SNAP encapsulation is only used if no NLPID value is defined for the given protocol 💅
For example, ISO CLNP already 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 (0x03) | NLPID - 0x81 (CLNP) |
+---------------------------------------------+
| CLNP packet |
| . |
| . |
+---------------------------------------------+13. Bridging in a Frame Relay network 🌸
A Frame Relay interface acting as a bridge MUST be able to flood, forward, and filter packets. It's giving multitasking 😭
Flooding means sending the packet to all possible destinations. In the Frame Relay world, that means sending the packet through each relevant DLC.
To forward a packet, a bridge MUST be able to associate a destination MAC address with a DLC. Requiring bridges to statically configure an association for every possible destination MAC address is unreasonable, and honestly maybe impossible 🙈 So Frame Relay bridges MUST provide enough information to let a Frame Relay interface dynamically learn about foreign destinations beyond the set of Frame Relay stations. Main character energy for sure ✨
To make dynamic learning happen, a bridged packet SHALL conform to the encapsulation described within section 7. That way the receiving Frame Relay interface knows to look into the bridged packet and learn the association between the foreign destination and the Frame Relay station 🦋
14. For Future Study 🔮
It MAY be desirable for the two ends of a connection to be able to negotiate end-to-end configuration and service parameters. The actual protocol and parameters to be negotiated will be a topic of future RFCs. Stay tuned, bestie 🫶
15. Backward Compatibility 💜
This section is only here for completeness. It is not intended to suggest additional requirements, so no pressure 💅
Some existing Frame Relay stations use the NLPID value of 0xCE to indicate an escape to Ethernet Packet Types, as defined in the latest version of the Assigned Numbers (RFC-1060) [7]. In that case, the frame has the following format:
+-----------------------------+
| Q.922 Address |
+-- --+
| |
+-----------------------------+
| Control (UI = 0x03) |
+-----------------------------+
| Optional Pad(s) (0x00) |
+-----------------------------+
| NLPID (0xCE) |
+-----------------------------+
| Ethertype |
+- -+
| |
+-----------------------------+
| . |
| . |
| Data |
| . |
| . |
+-----------------------------+
| Frame Check Sequence |
+-- . --+
| (two octets) |
+-----------------------------+The Ethertype field is a 16-bit value used to identify the protocol type for the following PDU 🎀
In order to be fully interoperable with stations using this encoding, Frame Relay stations MAY recognize the NLPID value of 0xCE and interpret the following two-byte Ethertype. It is never necessary to generate this encapsulation format just to properly interpret its meaning. Read-only energy 👀
For example, IP encapsulated with this NLPID value looks like this:
+-----------------------+-----------------------+
|Q.922 Address |
+-----------------------+-----------------------+
|Control (UI) 0x03 | NLPID 0xCE |
+-----------------------+-----------------------+
|Ethertype [7] 0x0800 |
+-----------------------+-----------------------+
| IP Packet |
| . |
| . |
+-----------------------+-----------------------+16. Appendix 🍓
List of Known NLPIDs
0x00 Null Network Layer or Inactive Set
(not used with Frame Relay)
0x80 SNAP
0x81 ISO CLNP
0x82 ISO ESIS
0x83 ISO ISIS
0xCC Internet IP
0xCE EtherType - unofficial temporary useList 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-05 0x00-0B 802.6
0x00-0D Fragments
0x00-0E BPDUs17. References 📚
[1] International Telegraph and Telephone Consultative Committee,
"ISDN Data Link Layer Specification for Frame Mode Bearer
Services", CCITT Recommendation Q.922, 19 April 1991 .
[2] American National Standard For Telecommunications - Integrated
Services Digital Network - Core Aspects of Frame Protocol for
Use with Frame Relay Bearer Service, ANSI T1.618-1991, 18 June
1991.
[3] Information technology - Telecommunications and Information
Exchange between systems - Protocol Identification in the
Network Layer, ISO/IEC TR 9577: 1990 (E) 1990-10-15.
[4] Baker, Fred, "Point to Point Protocol Extensions for Bridging",
Point to Point Working Group, RFC-1220, April 1991.
[5] International Standard, Information Processing Systems - Local
Area Networks - Logical Link Control, ISO 8802-2: 1989 (E), IEEE
Std 802.2-1989, 1989-12-31.
[6] Plummer, David C., An Ethernet Address Resolution Protocol",
RFC-826, November 1982.
[7] Reynolds, J. and Postel, J., "Assigned Numbers", RFC-1060, ISI,
March 1990.
[8] Finlayson, Mann, Mogul, Theimer, "A Reverse Address Resolution
Protocol", RFC-903, Stanford University, June 1984.
[9] Postel, J. and Reynolds, J., "A Standard for the Transmission of
IP Datagrams over IEEE 802 Networks", RFC-1042, ISI, February
1988.
[10] IEEE, "IEEE Standard for Local and Metropolitan Area Networks:
Overview and architecture", IEEE Standards 802-1990.
[11] Bradley, T., and C. Brown, "Inverse Address Resolution
Protocol", RFC-1293, Wellfleet Communications, Inc., January
1992.18. Security Considerations 🚨
Security issues are not addressed in this memo. 😭 Not gonna lie, this is a big deal and the spec is totally silent on it, so keep your guard up 🔒
19. Authors' Addresses 🦋
Terry Bradley
Wellfleet Communications, Inc.
15 Crosby Drive
Bedford, MA 01730
Phone: (617) 275-2400
Email: tbradley@wellfleet.com
Caralyn Brown
Wellfleet Communications, Inc.
15 Crosby Drive
Bedford, MA 01730
Phone: (617) 275-2400
Email: cbrown@wellfleet.com
Andrew G. Malis
BBN Communications
150 CambridgePark Drive
Cambridge, MA 02140
Phone: (617) 873-3419
Email: malis@bbn.comThat's the whole RFC, bestie! 🌈👑 We made it through every single section 💖
📦 where this page comes from
- ietf: rfc1294 1992-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms