A Standard for the Transmission of IP Datagrams over IEEE 802 Networks


postel@venera.isi.edu
Wed, 14 Oct 87 19:04:08 PDT


BAD MSG:
   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 -----



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:39:35 GMT