home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 900s / rfc948.txt < prev    next >
Text File  |  1992-09-22  |  11KB  |  349 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6. ---------
  7.  
  8.  
  9.  
  10. < INC-PROJECT, WINSTON-RFC.NLS.6, >, 11-Jun-85 21:31-PDT JBP ;;;;
  11.  
  12.  
  13.  
  14.  
  15.  
  16.  
  17.  
  18.  
  19.  
  20.  
  21.  
  22.  
  23.  
  24.  
  25.  
  26.  
  27.  
  28.  
  29.  
  30.  
  31.  
  32.  
  33.  
  34.  
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63. Winston                                                         [Page 0]
  64.  
  65.  
  66.  
  67. Network Working Group                                        Ira Winston
  68. Request for Comments: 948                     University of Pennsylvania
  69.                                                                June 1985
  70.  
  71.          TWO METHODS FOR THE TRANSMISSION OF IP DATAGRAMS OVER
  72.                           IEEE 802.3 NETWORKS
  73.  
  74.  
  75. Status of this Memo
  76.  
  77.    This memo describes two methods of encapsulating Internet
  78.    Protocol (IP) [1] datagrams on an IEEE 802.3 network [2].  This RFC
  79.    suggests a proposed protocol for the ARPA-Internet community, and
  80.    requests discussion and suggestions for improvements.  Distribution
  81.    of this memo is unlimited.
  82.  
  83. Introduction
  84.  
  85.    The IEEE 802 project has defined a family of standards for Local Area
  86.    Networks (LANs) that deals with the Physical and Data Link Layers as
  87.    defined by the ISO Open System Interconnection Reference Model
  88.    (ISO/OSI).  Several Physical Layer standards (802.3, 802.4, and
  89.    802.5) [2, 3, 4] and one Data Link Layer Standard (802.2) [5] have
  90.    been defined.  The IEEE Physical Layer standards specify the ISO/OSI
  91.    Physical Layer and the Media Access Control Sublayer of the ISO/OSI
  92.    Data Link Layer.  The 802.2 Data Link Layer standard specifies the
  93.    Logical Link Control Sublayer of the ISO/OSI Data Link Layer.
  94.  
  95.    The 802.3 standard is based on the Ethernet Version 2.0 standard [6].
  96.    The Ethernet Physical Layer and the 802.3 Physical Layer are
  97.    compatible for all practical purposes however, the Ethernet Data Link
  98.    Layer and the 802.3/802.2 Data Link Layer are incompatible.
  99.  
  100.    There are many existing Ethernet network installations that transmit
  101.    IP datagrams using the Ethernet compatible standard described in [7].
  102.    IEEE 802.3 Physical Layer compatible connections can be added to
  103.    these networks using an an Ethernet Data Link Layer compatible method
  104.    for transmitting IP datagrams without violating the 802.3 standard.
  105.    Alternatively, an 802.2/802.3 Data Link Layer compatible method for
  106.    transmitting IP datagrams can be used.
  107.  
  108. Ethernet Compatible Method
  109.  
  110.    IEEE 802.3 networks must use 48-bit physical addresses and 10
  111.    megabit/second bandwidth in order to be Ethernet compatible.
  112.  
  113.    The IEEE 802.3 packet header is identical to Ethernet packet header
  114.    except for the meaning assigned to one of the fields in the header.
  115.    In an Ethernet packet header this field is used as a protocol type
  116.    field and in an 802.3 packet header the field is used as a length
  117.    field.  The maximum allowed length field value on a 10 megabit/second
  118.  
  119.  
  120. Winston                                                         [Page 1]
  121.  
  122.  
  123.  
  124. RFC 948                                                        June 1985
  125. Transmission of IP Datagrams Over IEEE 802.3 Networks
  126.  
  127.  
  128.    802.3 network is 1500.  The 802.3 standard states that packets with a
  129.    length field greater than the maximum allowed length field may be
  130.    ignored, discarded, or used in a private manner.  Therefore, the
  131.    length field can be used in a private manner as a protocol type field
  132.    as long as the protocol types being used are greater than 1500.  The
  133.    protocol type for IP, ARP and trailer encapsulation are all greater
  134.    than 1500.  Using this technique, the method for transmitting IP
  135.    datagrams on Ethernet networks described in [7] can be used to
  136.    transmit IP datagrams on IEEE 802.3 networks in an Ethernet
  137.    compatible manner.
  138.  
  139. IEEE 802.2/802.3 Compatible Method
  140.  
  141.    Frame Format
  142.  
  143.       IP datagrams are transmitted in standard 802.2/802.3 LLC Type 1
  144.       Unnumbered Information format with the DSAP and SSAP fields of the
  145.       802.2 header set to 96, the IEEE assigned global SAP value for
  146.       IP [8].  The data field contains the IP header followed
  147.       immediately by the IP data.
  148.  
  149.       IEEE 802.3 packets have minimum size restrictions based on network
  150.       bandwidth.  When necessary, the data field should be padded (with
  151.       octets of zero) to meet the 802.3 minimum frame size requirements.
  152.       This padding is not part of the IP packet and is not included in
  153.       the total length field of the IP header.
  154.  
  155.       IEEE 802.3 packets have maximum size restrictions based on the
  156.       network bandwidth.  Implementations are encouraged to support
  157.       full-length packets.
  158.  
  159.          Gateway implementations MUST be prepared to accept full-length
  160.          packets and fragment them when necessary.
  161.  
  162.          Host implementations should be prepared to accept full-length
  163.          packets, however hosts MUST NOT send datagrams longer than 576
  164.          octets unless they have explicit knowledge that the destination
  165.          is prepared to accept them.  A host may communicate its size
  166.          preference in TCP based applications via the TCP Maximum
  167.          Segment Size option [9].
  168.  
  169.       Note:  Datagrams on 802.3 networks may be longer than the general
  170.       Internet default maximum packet size of 576 octets.  Hosts
  171.       connected to an 802.3 network should keep this in mind when
  172.       sending datagrams to hosts not on the same 802.3 network.  It may
  173.  
  174.  
  175.  
  176.  
  177. Winston                                                         [Page 2]
  178.  
  179.  
  180.  
  181. RFC 948                                                        June 1985
  182. Transmission of IP Datagrams Over IEEE 802.3 Networks
  183.  
  184.  
  185.       be appropriate to send smaller datagrams to avoid unnecessary
  186.       fragmentation at intermediate gateways.  Please see [9] for
  187.       further information on this point.
  188.  
  189.    Address Mappings
  190.  
  191.       The mapping of 32-bit Internet addresses to 16-bit or 48-bit 802.3
  192.       addresses can be done in several ways.  A static table could be
  193.       used, or a dynamic discovery procedure could be used.
  194.  
  195.       Static Table
  196.  
  197.          Each host could be provided with a table of all other hosts on
  198.          the local network with both their 802.3 and Internet addresses.
  199.  
  200.       Dynamic Discovery
  201.  
  202.          Mappings between 32-bit Internet addresses and 802.3 addresses
  203.          could be accomplished through a protocol similar to the
  204.          Ethernet Address Resolution Protocol (ARP) [10].  Internet
  205.          addresses are assigned arbitrarily on some Internet networks.
  206.          Each host's implementation must know its own Internet address
  207.          and respond to 802.3 Address Resolution packets appropriately.
  208.          It should also use ARP to translate Internet addresses to 802.3
  209.          addresses when needed.
  210.  
  211.       Broadcast Address
  212.  
  213.          The broadcast Internet address (the address on that network
  214.          with a host part of all binary ones) should be mapped to the
  215.          broadcast 802.3 address (of all binary ones).
  216.  
  217.          The use of the ARP dynamic discovery procedure is strongly
  218.          recommended.
  219.  
  220.    Trailer Formats
  221.  
  222.       Some versions of Unix 4.2bsd use a different encapsulation method
  223.       in order to get better network performance with the VAX virtual
  224.       memory architecture.  Consenting systems on the same 802.3 network
  225.       may use this format between themselves.  Details of the trailer
  226.       encapsulation method may be found in [11].
  227.  
  228.  
  229.  
  230.  
  231.  
  232.  
  233.  
  234. Winston                                                         [Page 3]
  235.  
  236.  
  237.  
  238. RFC 948                                                        June 1985
  239. Transmission of IP Datagrams Over IEEE 802.3 Networks
  240.  
  241.  
  242.    Byte Order
  243.  
  244.       As described in Appendix B of the Internet Protocol specification
  245.       [1], the IP datagram is transmitted over 802.2/802.3 networks as a
  246.       series of 8-bit bytes.
  247.  
  248. Conclusion
  249.  
  250.    The two encapsulation methods presented can be mixed on the same
  251.    local area network; however, this would partition the network into
  252.    two incompatible subnetworks.  One host on a network could support
  253.    both methods and act as a gateway between the two subnetworks;
  254.    however, this would introduce a significant performance penalty and
  255.    should be avoided.
  256.  
  257.    The IEEE 802.2/802.3 compatible encapsulation method is preferable to
  258.    the Ethernet compatible method because the IEEE 802.2 and IEEE 802.3
  259.    standards have been accepted both nationally and internationally and
  260.    because the same encapsulation method could be used on other IEEE 802
  261.    Physical Layer implementations.  However, there are many existing
  262.    installations that are using IP on Ethernet and a controlled
  263.    transition from Ethernet to IEEE 802.2/802.3 is necessary.
  264.  
  265.    To this end, all new implementations should allow for a static choice
  266.    of encapsulation methods and all existing implementations should be
  267.    modified to provide this static choice as well.  During the
  268.    transition, all hosts on the same network would use the Ethernet
  269.    compatible method.  After 802.2/802.3 support has been added to all
  270.    existing implementations, the IEEE 802.2/802.3 method would be used
  271.    and the transition would be complete.
  272.  
  273. References
  274.  
  275.    [1]  Postel, J.  "Internet Protocol".  RFC-791, USC/Information
  276.         Sciences Institute, September 1981.
  277.  
  278.    [2]  The Institute of Electronics and Electronics Engineers, Inc.
  279.         "IEEE Standards for Local Area Networks: Carrier Sense Multiple
  280.         Access with Collision Detection (CSMA/CD) Access Method and
  281.         Physical Layer Specifications".  The Institute of Electronics
  282.         and Electronics Engineers, Inc., New York, New York, 1985.
  283.  
  284.    [3]  The Institute of Electronics and Electronics Engineers, Inc.
  285.         "IEEE Standards for Local Area Networks: Token-Passing Bus
  286.         Access Method and Physical Layer Specifications".  The Institute
  287.         of Electronics and Electronics Engineers, Inc., New York, New
  288.         York, 1985.
  289.  
  290.  
  291. Winston                                                         [Page 4]
  292.  
  293.  
  294.  
  295. RFC 948                                                        June 1985
  296. Transmission of IP Datagrams Over IEEE 802.3 Networks
  297.  
  298.  
  299.    [4]  The Institute of Electronics and Electronics Engineers, Inc.
  300.         "IEEE Standards for Local Area Networks: Token Ring Access
  301.         Method and Physical Layer Specifications".  The Institute of
  302.         Electronics and Electronics Engineers, Inc., New York, New York,
  303.         1985.
  304.  
  305.    [5]  The Institute of Electronics and Electronics Engineers, Inc.
  306.         "IEEE Standards for Local Area Networks: Logical Link Control".
  307.         The Institute of Electronics and Electronics Engineers, Inc.,
  308.         New York, New York, 1985.
  309.  
  310.    [6]  "The Ethernet, Physical and Data Link Layer Specifications,
  311.         Version 2.0".  Digital Equipment Corporation, Intel Corporation,
  312.         and Xerox Corporation, 1982.
  313.  
  314.    [7]  Hornig, C.  "A Standard for the Transmission of IP Datagrams
  315.         over Ethernet Networks".  RFC-894, Symbolics Cambridge Research
  316.         Center, April 1984.
  317.  
  318.    [8]  Reynolds, J., and Postel, J.  "Assigned Numbers".  RFC-943,
  319.         USC/Information Sciences Institute, April 1985.
  320.  
  321.    [9]  Postel, J.  "The TCP Maximum Segment Size Option and Related
  322.         Topics".  RFC-879, USC/Information Sciences Institute,
  323.         November 1983.
  324.  
  325.    [10] Plummer, D.  "An Ethernet Address Resolution Protocol".
  326.         RFC-826, Symbolics Cambridge Research Center, November 1982.
  327.  
  328.    [11] Leffler, S., and Karels, M.  "Trailer Encapsulations".  RFC-893,
  329.         University of California at Berkeley, April 1984.
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338.  
  339.  
  340.  
  341.  
  342.  
  343.  
  344.  
  345.  
  346.  
  347.  
  348. Winston                                                         [Page 5]
  349.