Internet Standards

home *** CD-ROM | disk | FTP | other *** search

/ Internet Standards / CD1.mdf / MISC / MERIT / 1991 / 91_173.TXT < prev next >

Wrap

Text File | 1991-05-20 | 36.5 KB | 1,199 lines

Large Public Data T. Bradley Networks Working Group C. Brown Internet Draft Wellfleet Communications, Inc. A. Malis BBN Communications May 17, 1991 Multiprotocol Interconnect over Frame Relay Networks 1. Status of this Memo This document proposes an encapsulation method for transporting network interconnect traffic over a Frame Relay backbone. Distribution of this document is unlimited. Comments are welcome. 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. 3. Acknowledgements Comments and contributions from many sources, especially those from Ray Samora of Proteon, Ken Rehbehn of Netrix Corporation, Fred Baker and Charles Carvalho of Advanced Computer Communications have been incorporated into this document. Special thanks to Dory Leifer of University of Michigan for his contributions to the resolution of fragmentation issues. 4. Conventions The following language conventions are used in the items of specification in this document: o Must, Shall or Mandatory -- the item is an absolute requirement of the specification. Bradley, Brown, Malis [page 1] Multiprotocol Interconnect over Frame Relay o Should or Recommended -- the item should generally be followed for all but exceptional circumstances. o May or Optional -- the item is truly optional and may be followed or ignored according to the needs of the implementor. 5. Introduction The following discussion applies to those devices which serve as end stations (DTEs) on a public or private Frame Relay network (for example, provided by a common carrier or PTT). It will not discuss the behavior of those stations that are considered a part of the Frame Relay network (DCEs). The Frame Relay network provides a number of Permanent Virtual Circuits (PVCs) that 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 which may be either fully interconnected with a complete "mesh" of PVCs, or only partially interconnected. In either case, each PVC is uniquely identified at each Frame Relay interface by a Data Link Connection Identifier (DLCI). DLCIs have strictly local significance at each Frame Relay interface, unless the Frame Relay network uses the optional Global Addressing convention. Because local addressing is more general, this proposal will concentrate on this form of addressing and discuss separately possible optimizations for the global addressing. 6. Frame Format All protocols must encapsulate their packets within a LAPF- based frame [1] as required by the Frame Relay specification[2]. Additionally, packets shall contain information necessary to identify the protocol carried within the Protocol Data Unit (PDU), thus allowing the receiver to properly process the incoming packet. The format shall be as follows: Bradley, Brown, Malis [page 2] Multiprotocol Interconnect over Frame Relay +-----------------------------+ | LAPD flag (7E hexadecimal) | +-----------------------------+ | DLCI* . | +-- . --+ | . | +-----------------------------+ | Control (UI = 0x03) | +-----------------------------+ | Optional Pad (0x05) | +-----------------------------+ | Format Identifier/ | +-- --+ | Ethertype | +-----------------------------+ | . | | . | | . | | . | | Link Protocol Data Unit | | . | | . | +-----------------------------+ | LAPD Frame Check Sequence | +-- . --+ | (two octets) | +-----------------------------+ | LAPD flag (7E hexadecimal) | +-----------------------------+ *DLCIs, as presently defined are 10-bit encoded in two octets. In some networks DLCIs may, optionally be increased to three or four octets. The Control field is either a one or two byte field directly following the Frame Relay address space (DLCI). Initially this value shall be a one byte field set to Un-numbered Information (UI - 0x03). This field is used only for compatibility with other LAPD networks and has no specific meaning within the Frame Relay PVC environment at present. The pad field is an optional octet used to align the packet. In order to detect its presence or absence, the pad field Bradley, Brown, Malis [page 3] Multiprotocol Interconnect over Frame Relay should be set to 0x05. The Format Identifier/Ethertype field is a 16-bit value used to identify the type of frame encapsulated within the PDU. This is discussed in greater detail in the Interconnect Issues section. There is no 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 1600 bytes, but each Frame Relay service provider will specify an appropriate value for its network. A Frame Relay DCE, therefore, 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. 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 and therefore, must contain an indication that the destination may use to correctly interpret the contents of the frame. This indication is embedded within the Format Identifier/Ethertype field. In order to allow most protocols to run over frame relay, there must be a mechanism to allow use of the IEEE 802.2 LLC header. The additional overhead of including this header, however, is expensive for small packets (ie telnet traffic). The Format Identifier/Ethertype (FI/E) field provides the flexibility to allow either straight ethertype or 802.2 header encapsulation. If the value of the FI/E field is greater than or equal to 0x600 it represents an Digital Equipment, Intel, Xerox (DIX) Ethertype and the PDU will immediately follow. In this case, the packet will be of the following format: Bradley, Brown, Malis [page 4] Multiprotocol Interconnect over Frame Relay +-------------------------------+ | DLCI | | +-------------------------------+ |Control = 0x03 | pad = 0x05 | +-------------------------------+ |Ethertype ( >= 0x600) | +-------------------------------+ | Protocol packet | | . | | . | | . | +-------------------------------+ In the case where a 802.2 header is necessary, the value of the FI/E field is set to 0x0400 and the Frame Relay packet will be as follows: +-------------------------------+ | DLCI | | +-------------------------------+ |Control = 0x03 | pad = 0x05 | +-------------------------------+ |Format ID 0x400 | +-------------------------------+ | 802.2 header | | . | +-------------------------------+ | Protocol packet | | . | | . | | . | +-------------------------------+ All stations must be able to accept and properly interpret both variations of the routed packet encapsulation. The second type of Frame Relay traffic is bridged packets. Bridged traffic differs from routed traffic in that the bridge does not look into the packet to determine the final destination. Instead, bridges place the MAC header immediately following the Frame Relay header information and Bradley, Brown, Malis [page 5] Multiprotocol Interconnect over Frame Relay use this to correctly forward the packet. In this case, the FI/E field indicates, not only that a bridged packet follows the Frame Relay header, but also some important information about the packet. The FI/E field is interpreted as follows for a bridged packet. +--------------------------------------+ |0 0 0 0 0 0 F Z | Origin media | +--------------------------------------+ The F bit indicates that the source preserves the FCS within the packet. If the F bit is set (one), the preserved FCS is present within the PDU. The Z bit indicates zero compression. If it is set (one) zero compression was used. RFC 1220 [11], Point to Point Protocol Extensions for Bridging, describe algorithms for use of both the Z and F bits. The Origin Media field is used to describe on what media the packet originated. Values used are also included in RFC 1220 [11] listed as MAC type. Specifically, these values are: MAC Type: 0: Reserved 1: IEEE 802.3/Ethernet 2: IEEE 802.4 3: IEEE 802.5 4: FDDI other: Assigned by the Internet Assigned Numbers Authority A packet bridged over frame relay will, therefore, have the following format. Bradley, Brown, Malis [page 6] Multiprotocol Interconnect over Frame Relay +-------------------------------+ | DLCI | | +-------------------------------+ |Control = 0x03 | pad = 0x05 | +-------------------------------+ | 0000 00FZ | Origin Media | +-------------------------------+ | MAC Header | | . | | . | +-------------------------------+ | Protocol packet | | . | | . | | . | +-------------------------------+ In an algorithm form, the format identifier/ethertype field may be interpreted in the following manner. if (format_ID >= SMALLEST_ETHERTYPE) interpret the format_ID as an ethertype else if (format_ID == 0x0400) A 802.2 header follows. else if (format_ID == 0x401) A fragmented packet; see below. else if (format_ID < 0x0400) This is a bridged frame. perform bridging algorithm else Not yet defined; Drop the frame. 8. Logical Link Control - Quality of Service All Frame Relay stations shall support the Exchange Identification (XID) Command described in the 802.2 Logical Link Control (LLC) specification [8]. Using XID, Frame Relay stations will exchange LLC service information and discover the level of LLC supported. If both stations of a connection support LLC2, they may optionally select to use LLC2 and Bradley, Brown, Malis [page 7] Multiprotocol Interconnect over Frame Relay exchange acknowledged packets. This does not imply that both sides of the connection must use LLC2, or LLC1 exclusively. As with any use of the XID information, the stations may use any combination of the supported link control types that is appropriate for the application. Frame Relay stations may optionally support the Test Command also specified in 802.2 LLC standard [8]. 9. Fragmentation Issues Fragmentation allows the exchange of logical frames that are greater than the maximum frame size supported by the underlying network. In the case of Frame Relay, the network may support a maximum as small as 262 octets. Because of this small maximum size, it is advantageous to support fragmentation and reassembly. Unlike other fragmentation procedures, the scope of Frame Relay fragmentation procedures is limited to the boundry (or DTEs) of the frame relay network. The general format of fragmented packets is the same as any other encapsulated protocol. The most significant difference being that the fragmented packet will contain the encapsulation header. That is, a packet is first properly encapsulated as defined above. Large packets are then broken up into frames appropriate for the given Frame Relay network and are encapsulated within the fragmentation format. In this way, a station receiving fragments may reassemble them and then put the reassembled packet through the same processing path as a packet that had not been fragmented. Fragments are distinguished by the Format ID field of 0x401 and an individual fragment will have the following format. Bradley, Brown, Malis [page 8] Multiprotocol Interconnect over Frame Relay +------------------+------------------+ | DLCI | DLCI | +------------------+------------------+ | Control 0x03 | Pad 0x05 | +------------------+------------------+ | Format ID 0x0401 | +------------------+------------------+ | Fragment sequence number | +------------------+------------------+ |offset |final|reserved| +------------------+------------------+ | fragment data | | . | | . | | . | +------------------+------------------+ | FCS | +------------------+------------------+ The sequence field is a two octet identifier that is incremented every time a new complete LPDU is fragmented. The sequence number allows detection of reversed or lost frames and prevents erroneous reassembly. The offset field is a 10 bit value represents the logical offset of this fragment divided by 32. The first fragment should have an offset of zero. The final bit shall be set to 1 on the last fragment and set to 0 for all other fragments. The reserved field is not currently defined and must be set to 0. Fragments must be sent in order starting with a zero offset and ending with the final fragment. These fragments must not be interrupted with other packets or information intended for the same destination. An end station must be able to re-assemble up to 2K octets and is suggested to support up to 8K octet re-assembly. Bradley, Brown, Malis [page 9] Multiprotocol Interconnect over Frame Relay 10. Address Resolution There are situations in which a Frame Relay station may wish to dynamically resolve a protocol address. Address resolution may be accomplished using the standard Address Resolution Protocol (ARP) [3] encapsulated within a Frame Relay packet as follows: Ethertype 0x0806 ARP Data: ar$hrd 16 bits Hardware type ar$pro 16 bits Protocol type ar$hln 8 bits Byte length of hardware address (n) ar$pln 8 bits Byte length of protocol address (m) ar$op 16 bits Operation code (request or reply) ar$sha nbytes source hardware address ar$spa mbytes source protocol address ar$tha nbytes target hardware address ar$tpa mbytes target protocol address ar$hrd - assigned to Frame Relay is 15 decimal (000F hexadecimal) [4]. ar$pro - see assigned numbers for protocol ID number for the protocol using ARP. (IP is 2048 decimal ). ar$hln - length in bytes of the DLCI field. Presently set to 4 to allow for the expansion to 4 byte DLCIs. 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. If the Frame Relay network provides global addressing, the hardware address fields will contain the DLCI associated with the source (ar$sha) and destination (ar$tha) Frame Relay station. These DLCIs are stored right-justified within the given field. Any unused upper bits will be set to zero. Within a locally addressed Frame Relay network, however, DLCIs do not have a one-to-one mapping. Additionally, an end Bradley, Brown, Malis [page 10] Multiprotocol Interconnect over Frame Relay station does not have an assigned DLCI to put into the ARP reply. Fortunately, the frame relay network does provide a method for obtaining the correct DLCIs. In a locally addressed network, the DLCI carried within the frame relay header is modified as it traverses the network. When the packet arrives at its destination, the DLCI is assigned to the value that, from the standpoint of the receiving station, corresponds to the sending station. For example, in figure 1 below, if station A were to send a message to station B, it would place DLCI 50 in the frame relay header. When station B received this message, however, the DLCI would have been modified by the network and would appear to B as DLCI 70. ~~~~~~~~~~~~~~~ ( ) +-----+ ( ) +-----+ | |-50------(--------------------)---------70-| | | A | ( ) | B | | |-60-----(---------+ ) | | +-----+ ( | ) +-----+ ( | ) ( | ) <---Frame Relay ~~~~~~~~~~~~~~~~ network 80 | +-----+ | | | C | | | +-----+ Figure 1 Lines between stations represent PVC connections. The numbers indicate the local DLCI associated with each connection. Unlike the global addressing case, hardware addresses within ARP messages in the locally addressed network will be invalid. The DLCI values found in the frame header will, however, be Bradley, Brown, Malis [page 11] Multiprotocol Interconnect over Frame Relay correct. Though it does violate the purity of layering, Frame Relay may use the DLCI value 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 should not cause problems since ARP does not rely on these fields and in fact, an implementation may zero fill or ignore the target hardware address field entirely. As an example of how this DLCI replacement scheme may work, refer back to figure 1. If station A (protocol address pA) wished to resolve the address of station B (protocol address pB), it would format an ARP request with the following values. ARP request from A ar$op 1 (request) ar$sha unknown ar$spa pA ar$tha trying to resolve ar$tpa pB Because station A will not have a source DLCI associated with it, the source hardware address field is not valid. Therefore, when the ARP packet is received, it must extract the correct DLCI from the frame relay header and place it in the source hardware address field. This way, the ARP request from A will become ARP request from A as modified by B ar$op 1 (request) ar$sha 70 from Frame Relay header ar$spa pA ar$tha trying to resolve ar$tpa pB Station B's ARP will then be able to store station A's protocol address and DLCI association correctly. Next, station B will form a reply message. In many implementations, ARP simply places the source addresses from the ARP request into the target addresses and then fills in the source addresses with its addresses. In this case, the ARP response would be Bradley, Brown, Malis [page 12] Multiprotocol Interconnect over Frame Relay ARP response from B ar$op 2 (response) ar$sha unknown ar$spa pB ar$tha 70 ar$tpa pA Again, the source hardware address is unknown and when the request is received, station A will extract the DLCI from the Frame Relay header and place it in the source hardware address field. Therefore, the response will become ARP response from B as modified by A ar$op 2 (response) ar$sha 50 ar$spa pB ar$tha 70 ar$tpa pA Station A will now correctly recognize station B having protocol address pB associated with DLCI 50. Reverse ARP (RARP) [5] will work in exactly the same way. Still using figure 1, if we assume station C is an address server, the following RARP exchanges will occur. 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 80 ar$spa trying to resolve ar$spa trying to resolve ar$tha 60 ar$tha 60 ar$tpa pC ar$tpa pC Station C will then look up the protocol address corresponding to DLCI 80 and send the RARP response. Bradley, Brown, Malis [page 13] Multiprotocol Interconnect over Frame Relay RARP response from C RARP response as modified by A ar$op 4 (RARP response) ar$op 4 (RARP response) ar$sha ar$sha 60 ar$spa pC ar$spa pC ar$tha 80 ar$tha 80 ar$tpa pA ar$tpa pA This means that the Frame Relay interface must only intervene in the processing of incoming packets. Additionally, a station on a locally addressed network may learn how others view it by examining the target hardware address. In other networks, the ARP request is sent to a well-known broadcast address. Frame Relay has no such broadcast address. Some service providers do provide for a multicasting capability. If this multicasting behaves in such a way that if a packet is sent via this multicast address, the destination receives tha packet with a dlci for the source address (and not the unmodified multicast address), ARP may use this feature to send requests. ARP requests will use the multicast address which contains the DLCIs of all reachable stations (or perhaps the subset of stations to which ARPs are allowed). This DLCI value must be configurable. In the case where multicast DLCIs are not available, ARP may still be implemented. In this case, it is the end station's responsibility to send a copy of the ARP request through each available PVC. In a Frame Relay network that supports the Local Management Interface (LMI), a Frame Relay end station may use LMI provided PVC information to dynamically discover its neighbors. This is accomplished using Inverse ARP (InARP) [9]. Inverse ARP associates a given hardware address (in this case a DLCI) with a requested protocol address. Using InARP, a Frame Relay station may choose to poll end stations on newly announced PVCs (announced via the LMI status messages) in order to discover new connectivity. Locally addressed networks will again need to modify the source hardware address as with ARP and RARP examples above. The inclusion of InARP support should be a configurable option. Bradley, Brown, Malis [page 14] Multiprotocol Interconnect over Frame Relay 11. IP over Frame Relay Internet Protocol [7] (IP) datagrams sent over a Frame Relay network conform to the encapsulation described previously and can use either the short ethertype or SNAP encapsulation. Therefore, the IP datagram may be in either of the following formats: SNAP encapsulation form of IP over Frame Relay +---------------------------+---------------------------+ |DLCI* (msb) |DLCI (lsb) | +---------------------------+---------------------------+ |Control (UI) 0x03 | Pad 0x05 | +---------------------------+---------------------------+ |FI/E indicating SNAP encapsulation 0x0400 | +---------------------------+---------------------------+ |DSAP 0xAA |SSAP 0xAA | +---------------------------+---------------------------+ |LLC control 3 | (three octet) SNAP | +---------------------------+---------------------------+ |protocol ID or Org code 0 | +---------------------------+---------------------------+ |Ethertype [4] 0x0800 | +---------------------------+---------------------------+ | IP Packet | | . | | . | +---------------------------+---------------------------+ Bradley, Brown, Malis [page 15] Multiprotocol Interconnect over Frame Relay Ethertype encapsulation form of IP over Frame Relay +---------------------------+---------------------------+ |DLCI* (msb) |DLCI (lsb) | +---------------------------+---------------------------+ |Control (UI) 0x03 | Pad 0x05 | +---------------------------+---------------------------+ |Ethertype [4] 0x0800 | +---------------------------+---------------------------+ | IP Packet | | . | | . | +---------------------------+---------------------------+ 12. Other Protocols over Frame Relay The IP encapsulation may serve as a model for other protocols such as ISO, AppleTalk and DECnet. ISO, for example, would likely use the format identifier field indicating the existence of a SNAP header and fill in the LSAP appropriately [4]. An ISO encapsulated frame would also obey ISO 8880-2, ISO 8880-3 and ISO 9577. For example, the frame would be as follows. +----------------------+----------------------+ | DLCI | DLCI | +----------------------+----------------------+ | Control (0x03) | Pad (0x05) | +----------------------+----------------------+ | Format ID (0x0400 ) | +----------------------+----------------------+ | IEEE 802.2 LLC1 0xfe | 0xfe | +----------------------+----------------------+ |NLPID -- ISO 9577 | +---------------------------------------------+ | ISO data packet | | . | | . | +---------------------------------------------+ Bradley, Brown, Malis [page 16] Multiprotocol Interconnect over Frame Relay 13. Bridging in a Frame Relay network A Frame Relay interface acting as a bridge must be able to flood, forward and filter packets. Flooding is performed in one of two ways within a Frame Relay environment. If the Frame Relay service provides multicast addressing as described above, a flooded packet is simply sent to the multicast address that includes all accessible end stations. If the network does not provide multicasting, the Frame Relay station must send the packet to be flooded on all available PVCs to simulate the multicast address. To forward a packet, a bridge must be able to associate a destination MAC address with a DLCI. It is unreasonable and perhaps impossible to require bridges to statically configure an association of every possible destination MAC address with a PVC. Therefore, Frame Relay bridges must provide enough information to allow a Frame Relay interface to dynamically learn about foreign destinations beyond the set of Frame Relay stations. To accomplish dynamic learning, a bridged packet shall conform to the encapsulation described within section 6 and 7 and will use the Bridged MAC Frame Format Identifier. In this way, the receiving Frame Relay interface will know to look into the bridged packet and learn the association between foreign destination and Frame Relay station. Implementors' note: A table should be constructed which will grow to include any number of destination addresses and their associated DLCIs. This association table will be visible from the Frame Relay Management Information Base (MIB) [10] and will have the form: +-----------------------------+ | destination Address | DLCI | +-----------------------------+ | x.x.x.x | xxxx | +-----------------------------+ | . | | | . | | | . | | | . | | +-----------------------------+ Bradley, Brown, Malis [page 17] Multiprotocol Interconnect over Frame Relay Using this association table, a Frame Relay interface can successfully translate the destination MAC address presented in the forwarded packet with the correct DLCI. 14. References [1] International Telegraph and Telephone Consultative Committee, "ISDN User-Network Interface - Data Link Layer Specification", CCITT Recommendation Q.921, Fascicle VI.10 IXth Plenary Assembly, Melbourne, November 1988 ("Blue Book"). [2] American National Standard Institute Telecommunications Committee, "DSS1 - Core Aspects of Frame Protocol for Use with Frame Relay Bearer Service", ANSI T1S1/90-214 [3] Plummer, David C., Network Working Group, "An Ethernet Address Resolution Protocol", RFC-826, November 1982 [4] Reynolds, J. and Postel, J., "Assigned Numbers", RFC-1060, ISI, March 1990 [5] Finlayson, Mann, Mogul, Theimer, "A Reverse Address Resolution Protocol", RFC-903, Stanford University, June 1984 [6] "Frame Relay Specification With Extensions", Revision 1.0, Document Number 001-208966, Digital Equipment Corporation, Northern Telecom, Inc., StrataCom, Inc., September 1990 [7] Postel, J. and Reynolds, J., "A Standard for the Transmission of IP Datagrams over IEEE 802 Networks", RFC-1042, ISI, February 1988 Bradley, Brown, Malis [page 18] Multiprotocol Interconnect over Frame Relay [8] American National Standard, IEEE Standards for Local Area Networks: Logical Link Control, 802.2-1985 ISO Draft International Standard 8802/2 [9] Inverse Address Resolution Protocol, Wellfleet Communications draft document [10] Frame Relay MIB Wellfleet Communications draft document [11] Baker, Fred, "Point to Point Protocol Extensions for Bridging", Point to Point Working Group. RFC-1220 April 1991 15. 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 Bradley, Brown, Malis [page 19] Multiprotocol Interconnect over Frame Relay Andrew G. Malis BBN Communications 150 CambridgePark Drive Cambridge, MA 02140 Phone: (617) 873-3419 Email: malis@bbn.com Bradley, Brown, Malis [page 20]