postel@VENERA.ISI.EDU (10/15/87)
Your comments please --jon. Network Working Group J. Postel Request for Comments: DRAFT J. Reynolds ISI Obsoletes: RFC-948 mmmm 1987 A Standard for the Transmission of IP Datagrams over IEEE 802 Networks Status of this Memo This RFC specifies a standard method of encapsulating the Internet Protocol (IP) [1] datagrams and Address Resolution Protocol (ARP) [2] requests and replies on IEEE 802 Networks. This RFC specifies a protocol standard for the Internet community. Distribution of this memo is unlimited. Acknowledgment This memo would not exist with out the very significant contributions of Drew Perkins of Carnegie Mellon University and Jacob Rekhter of the T.J. Watson Research Center, IBM Corporation. Introduction The goal of this specification is to have implementations for transmitting IP datagrams and ARP request and replies be compatible and interwork. To achieve this it may be necessary in a few cases to limit the use that IP datagrams make of the capabilities of a particular IEEE 802 network. This memo describes the use of IP and ARP on three types of networks. It is not necessary that the use of IP and ARP be consistent across all three types of networks, only that it be consistent within each type. The IEEE 802 specifications define a family of standards for Local Area Networks (LANs) that deal with the Physical and Data Link Layers as defined by the ISO Open System Interconnection Reference Model (ISO/OSI). Several Physical Layer standards (802.3, 802.4, and 802.5) [3,4,5] and one Data Link Layer Standard (802.2) [6] have been defined. The IEEE Physical Layer standards specify the ISO/OSI Physical Layer and the Media Access Control Sublayer of the ISO/OSI Data Link Layer. The 802.2 Data Link Layer standard specifies the Logical Link Control Sublayer of the ISO/OSI Data Link Layer. All communication is performed using 802.2 type 1 communication. The Postel & Reynolds [Page 1] RFC DRAFT IP and ARP on IEEE 802 Networks mmmm 1987 802.2 type 2 communication is not used. The 802.x networks may have 16-bit or 48-bit physical addresses. It is the goal of this memo to specify enough about the use of IP and ARP on each type of network such that: (1) all equipment using IP or ARP on 802.3 networks will interoperate, (2) all equipment using IP or ARP on 802.4 networks will interoperate, (3) all equipment using IP or ARP on 802.5 networks will interoperate. Of course, the goal of IP is interoperability between computers attached to different networks, when those networks are interconnected via an IP gateway [8]. Description IEEE 802 networks may be used as IP networks of any class (A, B, or C). These systems use two Link Service Access Point (LSAP) fields of the LLC header in much the same way the ARPANET uses the "link" field. Further, there is an extension of the LLC header called the Sub-Network Access Protocol (SNAP). IP datagrams are sent on 802 networks encapsulated within the 802.2 LLC and SNAP data link layers, and the 802.3, 802.4, or 802.5 physical networks layers. The SNAP is used with an Organization Code indicating that the following 16 bits specify the EtherType code (as listed in Assigned Numbers [7]). Note that the 802.3 standard specifies a transmission rate of from 1 to 20 megabit/second, the 802.4 standard specifies 1, 5, and 10 megabit/second, and the 802.5 standard specifies 1 and 4 megabit/second. The typical transmission rates used are 10 megabit/second (802.3) or 4 megabit/second (802.5). However, this specification for the transmission of IP Datagrams does not depend on the transmission rate. Postel & Reynolds [Page 2] RFC DRAFT IP and ARP on IEEE 802 Networks mmmm 1987 Header ...--------+--------+--------+ MAC Header | 802.{3/4/5} MAC ...--------+--------+--------+ +--------+--------+--------+ | DSAP=K1| SSAP=K1| Control| 802.2 LLC +--------+--------+--------+ +--------+--------+---------+--------+--------+ |Protocol Id or Org Code =K2| EtherType | 802.2 SNAP +--------+--------+---------+--------+--------+ The total length of the LLC Header and the SNAP header is 8-octets, making the 802.2 protocol overhead come out on a nice boundary. The K1 value is 170 (decimal). The K2 value is 0 (zero). The control value is 3 (for Unnumbered Information). Address Mappings The mapping of 32-bit Internet addresses to 16-bit or 48-bit 802 addresses must be done via the dynamic discovery procedure of the Address Resolution Protocol (ARP) [2]. Internet addresses are assigned arbitrarily on Internet networks. Each host's implementation must know its own Internet address and respond to Address Resolution requests appropriately. It must also use ARP to translate Internet addresses to 802 addresses when needed. The ARP Details The ARP protocol has several fields that parameterize its use in any specific context [2]. These fields are: hrd 16 - bits The Hardware Type Code pro 16 - bits The Protocol Type Code hln 8 - bits Bytes in each hardware address pln 8 - bits Bytes in each protocol address op 16 - bits Operation Code The hardware type code assigned for the 802 networks (of all kinds) is 6 (see [7] page 16). Postel & Reynolds [Page 3] RFC DRAFT IP and ARP on IEEE 802 Networks mmmm 1987 The protocol type code for IP is 2048 (see [7] page 14). The hardware address length is 2 (for 16-bit 802 addresses), or 6 (for 48-bit 802 addresses). The protocol address length (for IP) is 4. The operation code is 1 for request and 2 for reply. Broadcast Address The broadcast Internet address (the address on that network with a host part of all binary ones) should be mapped to the broadcast 802 address (of all binary ones) (see [8] page 14). Trailer Formats Some versions of Unix 4.x bsd use a different encapsulation method in order to get better network performance with the VAX virtual memory architecture. Consenting systems on the same 802 network may use this format between themselves. Details of the trailer encapsulation method may be found in [9]. However, all hosts must be able to communicate using the standard (non-trailer) method. Byte Order As described in Appendix B of the Internet Protocol specification [1], the IP datagram is transmitted over 802 networks as a series of 8-bit bytes. This byte transmission order has been called "big- endian" [11]. Maximum Transmission Unit The Maximum Transmission Unit (MTU) differs on the different types of 802 networks. In the following there are comments on the MTU for each type of 802 network. However, on any particular network all hosts must use the same MTU. In the following, the terms "maximum packet size" and "maximum transmission unit" are equivalent. Frame Format and MAC Level Issues For all hardware types IP datagrams and ARP requests and replies are transmitted in standard 802.2 LLC Type 1 Unnumbered Information format, control code 3, with the DSAP and the SSAP fields of the 802.2 header set to 170, the assigned global SAP value for SNAP [6]. The 24-bit Organization Code in the SNAP is zero, and the remaining 16 bits Postel & Reynolds [Page 4] RFC DRAFT IP and ARP on IEEE 802 Networks mmmm 1987 are the EtherType from Assigned Numbers [7] (IP = 2048, ARP = 2054). IEEE 802.x packets may have a minimum size restriction. When necessary, the data field should be padded (with octets of zero) to meet the 802.x minimum frame size requirements. This padding is not part of the IP datagram and is not included in the total length field of the IP header. For compatibility (and common sense) the minimum packet size used with IP datagrams is 28 octets, which is 20 (minimum IP header) + 8 (LLC+SNAP header) = 28 octets (not including the MAC header). The minimum packet size used with ARP is 24 octets, which is 20 (ARP with 2 octet hardware addresses and 4 octet protocol addresses) + 8 (LLC+SNAP header) = 24 octets (not including the MAC header). In typical situations, the packet size used with ARP is 32 octets, which is 28 (ARP with 6 octet hardware addresses and 4 octet protocol addresses) + 8 (LLC+SNAP header) = 32 octets (not including the MAC header). IEEE 802.x packets may have a maximum size restriction. Implementations are encouraged to support full-length packets. For compatibility purposes, the maximum packet size used with IP datagrams or ARP requests and replies must be consistent on a particular network. Each type of 802 network has a different specification for the maximum packet size. Gateway implementations must be prepared to accept full-length packets and fragment them when necessary. Host implementations should be prepared to accept full-length packets, however hosts must not send datagrams longer than 576 octets unless they have explicit knowledge that the destination is prepared to accept them. A host may communicate its size preference in TCP based applications via the TCP Maximum Segment Size option [10]. Datagrams on 802.x networks may be longer than the general Internet default maximum packet size of 576 octets. Hosts connected to an 802.x network should keep this in mind when sending datagrams to hosts not on the same 802.x network. It may be appropriate to send smaller datagrams to avoid unnecessary fragmentation at intermediate gateways. Please see [10] for further information. Postel & Reynolds [Page 5] RFC DRAFT IP and ARP on IEEE 802 Networks mmmm 1987 For 802.3 IEEE 802.3 networks have a minimum packet size that depends on the transmission rate. For 10 megabit/second 802.3 networks the minimum packet size is 64 octets. IEEE 802.3 networks have a maximum packet size which depends on the transmission rate. For 10 megabit/second 802.3 networks the maximum packet size is 1518 octets. The MAC header is 6 octets of source address, 6 octets of destination address, 2 octets of length, and (at the end of the packet) 4 octets of CRC, for a total of 18 octets. Note that 1518 - 18 (MAC header) - 8 (LLC+SNAP header) = 1492 for the IP datagram (including the IP header). One popular combination of 802.3 parameters is the "Ethernet" style in which networks use 48-bit physical addresses and 10 megabit/second transmission rate. For 802.4 IEEE 802.4 networks have no minimum packet size. IEEE 802.4 networks have no maximum packet size. The MAC header is 6 octets of source address, 6 octets of destination address, 2 octets of length, and (at the end of the packet) 4 octets of CRC, for a total of 18 octets. For compatibility, the maximum packet size used with IP datagrams or ARP requests and replies is 1492 octets for the IP datagram (including the IP header) plus 8 octets for the LLC+SNAP header, for a total of 1500 octets (not including the MAC header). In one combination of 802.4 parameters, 48-bit physical addresses and 10 megabit/second transmission rate are used. Postel & Reynolds [Page 6] RFC DRAFT IP and ARP on IEEE 802 Networks mmmm 1987 For 802.5 IEEE 802.5 networks have no minimum packet size. IEEE 802.5 networks have no maximum packet size. The MAC header is 6 octets of source address, 6 octets of destination address, 2 octets of length, plus another 18 octets of what ???, and (at the end of the packet) 4 octets of CRC, for a total of 36 octets. In one combination of 802.5 parameters, 48-bit physical addresses and 4 megabit/second transmission rate are used. There is a convention that IBM style 802.5 networks will not use packets larger than 8232 octets. With a MAC header of 36 octets and the LLC+SNAP header of 8 octets, the IP datagram (including IP header) may not exceed 8188 octets. Note that a MAC level bridge linking two rings may limit the size of packets forwarded to 552 octets, with a MAC header of 36 octets and the LLC+SNAP of 8 octets, the IP datagram (including the IP header) may be limited to 508 octets. This is less that the default IP MTU of 576 octets, and may cause significant performance problems due to excessive datagram fragmentation. One implementation will not support IP datagram communication across a MAC level bridge unless the bridge will allow an IP MTU of at least 1020 octets. The dynamic address discovery procedure is to do a ARP request. The IBM style 802.5 networks support two different types of broadcasts, local ring broadcasts and all rings broadcasts. To limit the number of all rings broadcasts to a minimum, it is desirable (though not required) that an ARP request first be sent as a local ring broadcast, without a Routing Information Field (RIF). If the local ring broadcast is not supported or if the local ring broadcast is unsuccessful after some reasonable time has elapsed, then send the ARP request as an all rings broadcast with an empty RIF. When an ARP request or reply is received, all implementations are required to understand at least local ring broadcasts (no RIF) and all ring broadcasts from the same ring (empty RIF). If the implementation supports IBM style source routing, then a non-empty RIF is stored for future transmissions to the host originating the ARP request or reply. If this source routing is not supported them all packets with non-empty RIFs should be gracefully ignored. Postel & Reynolds [Page 7] RFC DRAFT IP and ARP on IEEE 802 Networks mmmm 1987 It is possible that when sending an ARP request via an all rings broadcast that multiple copies of the request will arrive at the destination as a result of the request being forwarded by several MAC layer bridges. However, these "copies" will have taken different routes so the contents of the RIF will differ. An implementation of ARP in this context must determine which of these "copies" to use and to ignore the others. There are three obvious strategies: (1) take the first and ignore the rest (that is, once you have an entry in the ARP cache don't change it), (2) take the last, (that is, always up date the ARP cache with the latest ARP message), or (3) take the one with the shortest path, (that is, replace the ARP cache information with the latest ARP message data if it is a shorter route). Since there is no problem of incompatibility for interworking of different implementations if different strategies are chosen, the choice is up to each implementor. The recipient of the ARP request must send an ARP reply as a point to point message using the RIF information. Note that a MAC level bridge linking two rings may limit the size of packets forwarded to 552 octets, with a MAC header of 36 octets and the LLC+SNAP of 8 octets, the ARP request or reply may be limited to 508 octets. The RIF information should be kept distinct from the ARP table. That is, there is, in principle, the ARP table to map from IP addresses to 802 48-bit addresses, and the RIF table to map from those to 802.5 source routes, if necessary. In practical implementations it may be convenient to store the ARP and RIF information together. Storing the information together may speed up access to the information when it is used. On the other hand, in a generalized implementation for all types of 802 networks a significant amount of memory might be wasted in an ARP cache if space for the RIF information were always reserved. IP broadcasts (datagrams with a IP broadcast address) must be sent as 802.5 all ring broadcasts. Since current interface hardware allows only one group address, and since the functional addresses are not globally unique, IP and ARP do not use either of these features. Further, in the IBM style 802.5 networks there are only 31 functional addresses available for user definition. IP precedence should not be mapped to 802.5 priority. All IP and ARP packets should be sent at the default 802.5 priority. The default priority is 3. Postel & Reynolds [Page 8] RFC DRAFT IP and ARP on IEEE 802 Networks mmmm 1987 An 802.5 address not recognized report should be mapped an ICMP destination unreachable message. MAC Management Support While not necessary for supporting IP and ARP, IEEE 802.5 devices should be able to respond to EXCHANGE ID (XID) and TEST LINK (TEST) frames. When either an XID or a TEST frame is received a response must be returned. When responding to an XID or a TEST frame the sense of the poll/final bit must be preserved. That is, a frame received with the poll/final bit reset must have the response returned with the poll/final bit reset and vice versa. The XID command or response has an LLC control field value of 245 (decimal) if poll is off or 253 (decimal) if poll is on. (See Appendix on Numbers.) The TEST command or response has an LLC control field value of 199 (decimal) if poll is off or 207 (decimal) if poll is on. (See Appendix on Numbers.) A command frame is identified with high order bit of the SSAP address reset. Response frames have high order bit of the SSAP address set to one. TEST command frames are merely echoed exactly as received, after swapping the Destination Address/Source Address and DSAP/SSAP and setting the response bit. XID commands frames received should return the 802.2 XID Information field in the response as 0.128.129 indicating connectionless service (type 1) and swap the addresses and set the response bit. Interoperation with Ethernet It is possible to use the Ethernet link level protocol [12] on the same physical cable with the IEEE 802.3 link level protocol. A computer interfaced to a physical cable used in this way could potentially read both Ethernet and 802.3 packets from the network. If a computer does read both types of packets, it must keep track of which link protocol was used with each other computer on the network and use the proper link protocol when sending packets. Postel & Reynolds [Page 9] RFC DRAFT IP and ARP on IEEE 802 Networks mmmm 1987 One should note that in such an environment, link level broadcast packets will not reach all the computers attached to the network, but only those using the link level protocol used for the broadcast. Since it must be assumed that most computers will read and send using only one type of link protocol, it is recommended that if such an environment (a network with both link protocols) is necessary, an IP gateway be used as if there were two distinct networks. Note that the MTU for the Ethernet allows a 1500 octet IP datagram, with the MTU for the 802.3 network allows only a 1492 octet IP datagram. Appendix on Numbers The IEEE likes to specify numbers in bit transmission order, or bit- wise little-endian order. The Internet protocols are documented in byte-wise big-endian order. This may cause some confusion about the proper values to use for numbers. Here are the conversions for some numbers of interest. Number IEEE IEEE Internet Internet HEX Binary Binary Decimal UI Op Code 0xC0 11000000 00000011 3 SAP for SNAP 0x55 01010101 10101010 170 XID 0xAF 10101111 11110101 245 XID 0xBF 10111111 11111101 253 TEST 0xE3 11100011 11000111 199 TEST 0xF3 11110011 11001111 207 Info 0x810100 0.128.129 Postel & Reynolds [Page 10] RFC DRAFT IP and ARP on IEEE 802 Networks mmmm 1987 References [1] Postel, J., "Internet Protocol", RFC-791, USC/Information Sciences Institute, September 1981. [2] Plummer, D., "An Ethernet Address Resolution Protocol - or - Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", RFC-826, MIT, November 1982. [3] IEEE, "IEEE Standards for Local Area Networks: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications", IEEE, New York, New York, 1985. [4] IEEE, "IEEE Standards for Local Area Networks: Token-Passing Bus Access Method and Physical Layer Specification", IEEE, New York, New York, 1985. [5] IEEE, "IEEE Standards for Local Area Networks: Token Ring Access Method and Physical Layer Specifications", IEEE, New York, New York, 1985. [6] IEEE, "IEEE Standards for Local Area Networks: Logical Link Control", IEEE, New York, New York, 1985. [7] Reynolds, J.K., and J. Postel, "Assigned Numbers", RFC-1010, USC/Information Sciences Institute, May 1987. [8] Braden, R., and J. Postel, "Requirements for Internet Gateways", RFC-1009, USC/Information Sciences Institute, June 1987. [9] Leffler, S., and Karels, M., "Trailer Encapsulations", RFC- 893, University of California at Berkeley, April 1984. [10] Postel, J., "The TCP Maximum Segment Size Option and Relate Topics", RFC-879, USC/Information Sciences Institute, November 1983. [11] Cohen, D., "On Holy Wars and a Plea for Peace", Computer, IEEE, October 1981. [12] D-I-X, "The Ethernet - A Local Area Network: Data Link Layer and Physical Layer Specifications", Digital, Intel, and Xerox, November 1982. Postel & Reynolds [Page 11] ----- End Forwarded Message -----
minshall@OPAL.BERKELEY.EDU (10/19/87)
Hi. For a while I've thought that I should someday try to understand 802.x. With the proposed RFC in hand, as well as the IEEE 802.2 and 802.5 and the IBM Token Ring Network Architecture Reference, I thought this weekend would be as good a time as any. (Before beginning I should mention that I think that "token ring" is what every campus should be installing. It is precisely for that reason that I am picking on the token ring section not a little.) 802.2 - First off, even if we are only supporting type 1 (connectionless) service, we MUST to support XID (Exchange ID) and TEST in addition to UI (Unnumbered Information). Our goal is stated to be "all equipment using IP or ARP on 802.[345] networks will interoperate". However, there are variables in each of these networks: which speed they run at, and the size of the MAC-level address (16 bits or 48 bits). Probably we need to suggest that each 3-tuple (802.x, speed, address size) should interoperate on the same wire. There is a nice picture (page 3) of DSAP=K1 SSAP=K1. Unfortunately, this doesn't account for the fact that the low order bit of the SSAP distinguishes between "command" and "response". (It IS the low (ARPA) order bit, isn't it? On page 9 we seem to say something else.) On page 5, "Implementations are encouraged to support full-length packets". I would like to see this stronger. Just because the IP packet (plus MAC/LLC stuff) is N bytes is no reason to suppose that some gateway/bridge/whatever won't pad out the packet to N+1 bytes (say because N+1 is odd, and the DMA chip works on halfwords), where N+1 is still a legal packet size. Anyway, I think that maximum length packets should be mandatory. 802.5 - There is a maximum packet size for 802.5 networks. Basically, there is a timer with a DEFAULT value of 10ms (THT). "Default" means that the degrees of freedom of 802.5 (or 802.X, I suppose) networks is worse than one might naively think. 4E6*10E-3/8 = approx 5,000 bytes (with a little more to be subtracted due to hardware delays, etc.). Now, frame format. The MAC header is 2 bytes (SD and AC), 1 byte (FC), 2 addresses (4 bytes total or 12 bytes total), a CRC (4 bytes), and 2 bytes (ED and FS). If the packet is using source routing, then there are 2 bytes of "routing control", plus up to 16 bytes (2 bytes * 8 entries) of "segment numbers". Without source routing, the MAC header is 13 or 21 bytes in length; with source routing the MAC header is between 15 bytes and 39 bytes in length. (Aren't all these odd numbers wonderful!) Now I have a question. A year (or two) back, the issue of source routing was very very controversial in the halls of IEEE 802.X. Is this still the case? Unfortunately, the IEEE documents I have are demonstrably old (eg, they don't mention SNAP at all, plus the covers have become discolored). I'm not wild about embracing source routing if source routing is still controversial within the 802 committee. Note, by the way, that the PRESENCE of the Routing Information Field (RIF) in an 802.5 packet is indicated by a bit in the Source Address field (what we might think of as the ethernet source address). Sigh. We say "IP broadcasts ... must be sent as 802.5 all ring broadcasts". Again, we are up against the source routing wall: "all ring broadcasts" are a feature of source routing. (The whole idea that "source routing" is like a MAC-bridge is a bit dubious to me. I'm used to thinking of the TransLan as a MAC-bridge. The analogy is that to get the TransLan to propagate an ethernet broadcast packet, I have to change the packet to include information that says "TransLan, please forward this". And, to get the TransLan to forward a non-broadcast packet, I need to change the packet by addressing it to the bridge, and include in the packet the route the packet should take. Doesn't sound very "MAC- level" to me.) (And then add to that the fact that, according to the proposed RFC, certain of these MAC-level bridges (in quotes) constrain the conversation to packet sizes smaller than either of the two bridged networks or the two endpoints!) Appendix on Numbers - Gasp. My head hurts. However, I think (think) that the IEEE *bytes* are transmitted/displayed just like ARPA bytes. So, IEEE 0x810100 would be ARPA 129.128.0. However, I think that the XID response should be IEEE 0x818000 == ARPA 129.1.0. To add to the fun, it appears that the IEEE 802.5 (5 5 5 5 5) bit ordering is ARPA-like. So, and IEEE 802.5 0x80 is an ARPA 0x80 is an "IEEE" 0x01. Yours, Greg Minshall ps - Someday, I'd like to see us look at Type 2 (connection-oriented) service. IBM, which uses Type 2, gets fairly impressive numbers on performance of their networks. Also, someday, I'd like us to think about allowing one LLC packet carry > 1 IP/ARP packet. I even know the first place I'd put this to use: I need to ARP on an ethernet/802.3 network; I'd like to use trailers. So, I need to send out 4 separate packets. It would be nice to send one. Also, this might be nice from (and to) gateways.