home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1100s / rfc1188.txt < prev    next >
Text File  |  1990-10-23  |  22KB  |  619 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                            D. Katz
  8. Request for Comments: 1188                                  Merit/NSFNET
  9. Obsoletes:  RFC 1103                                        October 1990
  10.  
  11.  
  12.               A Proposed Standard for the Transmission of
  13.                     IP Datagrams over FDDI Networks
  14.  
  15. Status of this Memo
  16.  
  17.    This memo defines a method of encapsulating the Internet Protocol
  18.    (IP) datagrams and Address Resolution Protocol (ARP) requests and
  19.    replies on Fiber Distributed Data Interface (FDDI) Networks.  This
  20.    RFC specifies a protocol on the IAB Standards Track for the Internet
  21.    community, and requests discussion and suggestions for improvements.
  22.    Please refer to the current edition of the "IAB Official Protocol
  23.    Standards" for the standardization state and status of this protocol.
  24.  
  25.    This proposal is the product of the IP over FDDI Working Group of the
  26.    Internet Engineering Task Force (IETF).  Comments on this memo should
  27.    be submitted to the IETF IP over FDDI Working Group Chair.
  28.    Distribution of this memo is unlimited.
  29.  
  30. Abstract
  31.  
  32.    This document specifies a method for the use of IP and ARP on FDDI
  33.    networks.  The encapsulation method used is described, as well as
  34.    various media-specific issues.
  35.  
  36. Acknowledgments
  37.  
  38.    This memo draws heavily in both concept and text from RFC 1042 [3],
  39.    written by Jon Postel and Joyce K. Reynolds of USC/Information
  40.    Sciences Institute.  The author would also like to acknowledge the
  41.    contributions of the IP Over FDDI Working Group of the IETF, members
  42.    of ANSI ASC X3T9.5, and others in the FDDI community.
  43.  
  44. Conventions
  45.  
  46.    The following language conventions are used in the items of
  47.    specification in this document:
  48.  
  49.       "Must," "Shall," or "Mandatory"--the item is an absolute
  50.       requirement of the specification.
  51.  
  52.       "Should" or "Recommended"--the item should generally be followed
  53.       for all but exceptional circumstances.
  54.  
  55.  
  56.  
  57.  
  58. Katz                                                            [Page 1]
  59.  
  60. RFC 1188              IP and ARP on FDDI Networks           October 1990
  61.  
  62.  
  63.       "May" or "Optional"--the item is truly optional and may be
  64.       followed or ignored according to the needs of the implementor.
  65.  
  66. Introduction
  67.  
  68.    The goal of this specification is to allow compatible and
  69.    interoperable implementations for transmitting IP datagrams [1] and
  70.    ARP requests and replies [2].
  71.  
  72.    The Fiber Distributed Data Interface (FDDI) specifications define a
  73.    family of standards for Local Area Networks (LANs) that provides the
  74.    Physical Layer and Media Access Control Sublayer of the Data Link
  75.    Layer as defined by the ISO Open System Interconnection Reference
  76.    Model (ISO/OSI).  Documents are in various stages of progression
  77.    toward International Standardization for Media Access Control (MAC)
  78.    [4], Physical Layer Protocol (PHY) [5], Physical Layer Medium
  79.    Dependent (PMD) [6], and Station Management (SMT) [7].  The family
  80.    of FDDI standards corresponds to the IEEE 802 MAC layer standards
  81.    [8, 9, 10].
  82.  
  83.    The remainder of the Data Link Service is provided by the IEEE 802.2
  84.    Logical Link Control (LLC) service [11].  The resulting stack of
  85.    services appears as follows:
  86.  
  87.         +-------------+
  88.         |   IP/ARP    |
  89.         +-------------+
  90.         |  802.2 LLC  |
  91.         +-------------+-----+
  92.         |  FDDI MAC   | F   |
  93.         +-------------+ D S |
  94.         |  FDDI PHY   | D M |
  95.         +-------------+ I T |
  96.         |  FDDI PMD   |     |
  97.         +-------------+-----+
  98.  
  99.    This memo describes the use of IP and ARP in this environment.  At
  100.    this time, it is not necessary that the use of IP and ARP be
  101.    consistent between FDDI and IEEE 802 networks, but it is the intent
  102.    of this memo not to preclude Data Link Layer interoperability at such
  103.    time as the standards define it.
  104.  
  105.    The FDDI standards define both single and dual MAC stations.  This
  106.    document describes the use of IP and ARP on single MAC stations
  107.    (single-attach or dual-attach) only.  Operation on dual MAC stations
  108.    will be described in a forthcoming document.
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Katz                                                            [Page 2]
  115.  
  116. RFC 1188              IP and ARP on FDDI Networks           October 1990
  117.  
  118.  
  119. Packet Format
  120.  
  121.    IP datagrams and ARP requests and replies sent on FDDI networks shall
  122.    be encapsulated within the 802.2 LLC and Sub-Network Access Protocol
  123.    (SNAP) [12] data link layers and the FDDI MAC and physical layers.
  124.    The SNAP must be used with an Organization Code indicating that the
  125.    SNAP header contains the EtherType code (as listed in Assigned
  126.    Numbers [13]).
  127.  
  128.    802.2 LLC Type 1 communication (which must be implemented by all
  129.    conforming 802.2 stations) is used exclusively.  All frames must be
  130.    transmitted in standard 802.2 LLC Type 1 Unnumbered Information
  131.    format, with the DSAP and the SSAP fields of the 802.2 header set to
  132.    the assigned global SAP value for SNAP [11].  The 24-bit Organization
  133.    Code in the SNAP must be zero, and the remaining 16 bits are the
  134.    EtherType from Assigned Numbers [13] (IP = 2048, ARP = 2054).
  135.  
  136.       ...--------+--------+--------+
  137.                  MAC Header        |                           FDDI MAC
  138.       ...--------+--------+--------+
  139.  
  140.       +--------+--------+--------+
  141.       | DSAP=K1| SSAP=K1| Control|                            802.2 LLC
  142.       +--------+--------+--------+
  143.  
  144.       +--------+--------+---------+--------+--------+
  145.       |Protocol Id or Org Code =K2|    EtherType    |        802.2 SNAP
  146.       +--------+--------+---------+--------+--------+
  147.  
  148.       The total length of the LLC Header and the SNAP header is 8
  149.       octets.
  150.  
  151.       The K1 value is 170 (decimal).
  152.  
  153.       The K2 value is 0 (zero).
  154.  
  155.       The control value is 3 (Unnumbered Information).
  156.  
  157. Address Resolution
  158.  
  159.    The mapping of 32-bit Internet addresses to 48-bit FDDI addresses
  160.    shall be done via the dynamic discovery procedure of the Address
  161.    Resolution Protocol (ARP) [2].
  162.  
  163.    Internet addresses are assigned arbitrarily on Internet networks.
  164.    Each host's implementation must know its own Internet address and
  165.    respond to Address Resolution requests appropriately.  It must also
  166.    use ARP to translate Internet addresses to FDDI addresses when
  167.  
  168.  
  169.  
  170. Katz                                                            [Page 3]
  171.  
  172. RFC 1188              IP and ARP on FDDI Networks           October 1990
  173.  
  174.  
  175.    needed.
  176.  
  177.    The ARP protocol has several fields that parameterize its use in any
  178.    specific context [2].  These fields are:
  179.  
  180.       hrd   16 - bits     The Hardware Type Code
  181.       pro   16 - bits     The Protocol Type Code
  182.       hln    8 - bits     Octets in each hardware address
  183.       pln    8 - bits     Octets in each protocol address
  184.       op    16 - bits     Operation Code
  185.  
  186.    The hardware type code assigned for IEEE 802 networks is 6 [13].  The
  187.    hardware type code assigned for Ethernet networks is 1 [13].
  188.    Unfortunately, differing values between Ethernet and IEEE 802
  189.    networks cause interoperability problems in bridged environments.  In
  190.    order to not preclude interoperability with Ethernets in a bridged
  191.    environment, ARP packets shall be transmitted with a hardware type
  192.    code of 1.  Furthermore, ARP packets shall be accepted if received
  193.    with hardware type codes of either 1 or 6.
  194.  
  195.    The protocol type code for IP is 2048 [13].
  196.  
  197.    The hardware address length is 6.
  198.  
  199.    The protocol address length (for IP) is 4.
  200.  
  201.    The operation code is 1 for request and 2 for reply.
  202.  
  203.    In order to not preclude interoperability in a bridged environment,
  204.    the hardware addresses in ARP packets (ar$sha, ar$tha) must be
  205.    carried in "canonical" bit order, with the Group bit positioned as
  206.    the low order bit of the first octet.  As FDDI addresses are normally
  207.    expressed with the Group bit in the high order bit position, the
  208.    addresses must be bit-reversed within each octet.
  209.  
  210.    Although outside the scope of this document, it is recommended that
  211.    MAC addresses be represented in canonical order in all Network Layer
  212.    protocols carried within the information field of an FDDI frame.
  213.  
  214. Broadcast Address
  215.  
  216.    The broadcast Internet address (the address on that network with a
  217.    host part of all binary ones) must be mapped to the broadcast FDDI
  218.    address (of all binary ones) (see [14]).
  219.  
  220. Multicast Support
  221.  
  222.    A method of supporting IP multicasting is specified in [15].  This
  223.  
  224.  
  225.  
  226. Katz                                                            [Page 4]
  227.  
  228. RFC 1188              IP and ARP on FDDI Networks           October 1990
  229.  
  230.  
  231.    method shall be used in FDDI networks if IP multicasting is to be
  232.    supported.  The use of this method may require the ability to copy
  233.    frames addressed to any one of an arbitrary number of multicast
  234.    (group) addresses.
  235.  
  236.    An IP multicast address is mapped to an FDDI group address by placing
  237.    the low order 23 bits of the IP address into the low order 23 bits of
  238.    the FDDI group address 01-00-5E-00-00-00 (in "canonical" order).
  239.    [See 13, page 20.]
  240.  
  241.    For example, the IP multicast address:
  242.  
  243.          224.255.0.2
  244.  
  245.    maps to the FDDI group address:
  246.  
  247.          01-00-5E-7F-00-02
  248.  
  249.    in which the multicast (group) bit is the low order bit of the first
  250.    octet (canonical order).  When bit-reversed for transmission in the
  251.    destination MAC address field of an FDDI frame (native order), it
  252.    becomes:
  253.  
  254.          80-00-7A-FE-00-40
  255.  
  256.    that is, with the multicast (group) bit as the high order bit of the
  257.    first octet, that being the first bit transmitted on the medium.
  258.  
  259. Trailer Formats
  260.  
  261.    Some versions of Unix 4.x bsd use a different encapsulation method in
  262.    order to get better network performance with the VAX virtual memory
  263.    architecture.  Hosts directly connected to FDDI networks shall not
  264.    use trailers.
  265.  
  266. Byte Order
  267.  
  268.    As described in Appendix B of the Internet Protocol specification
  269.    [1], the IP datagram is transmitted over FDDI networks as a series of
  270.    8-bit bytes.  This byte transmission order has been called "big-
  271.    endian" [16].
  272.  
  273. MAC Layer Details
  274.  
  275.    Packet Size
  276.  
  277.       The FDDI MAC specification [4] defines a maximum frame size of
  278.       9000 symbols (4500 octets) for all frame fields, including four
  279.  
  280.  
  281.  
  282. Katz                                                            [Page 5]
  283.  
  284. RFC 1188              IP and ARP on FDDI Networks           October 1990
  285.  
  286.  
  287.       symbols (two octets) of preamble.  This leaves roughly 4470 octets
  288.       for data after the LLC/SNAP header is taken into account.
  289.  
  290.       However, in order to allow future extensions to the MAC header and
  291.       frame status fields, it is desirable to reserve additional space
  292.       for MAC overhead.
  293.  
  294.       Therefore, the MTU of FDDI networks shall be 4352 octets.  This
  295.       provides for 4096 octets of data and 256 octets of headers at the
  296.       network layer and above.  Implementations must not send packets
  297.       larger than the MTU.
  298.  
  299.       Gateway implementations must be prepared to accept packets as
  300.       large as the MTU and fragment them when necessary.  Gateway
  301.       implementations should be able to accept packets as large as can
  302.       be carried within a maximum size FDDI frame and fragment them.
  303.  
  304.       Host implementations should be prepared to accept packets as large
  305.       as the MTU; however, hosts must not send datagrams longer than 576
  306.       octets unless they have explicit knowledge that the destination is
  307.       prepared to accept them.  Host implementations may accept packets
  308.       as large as can be carried within a maximum size FDDI frame.  A
  309.       host may communicate its size preference in TCP- based
  310.       applications via the TCP Maximum Segment Size option [17].
  311.  
  312.       Datagrams on FDDI networks may be longer than the general Internet
  313.       default maximum packet size of 576 octets.  Hosts connected to an
  314.       FDDI network should keep this in mind when sending datagrams to
  315.       hosts that are not on the same local network.  It may be
  316.       appropriate to send smaller datagrams to avoid unnecessary
  317.       fragmentation at intermediate gateways.  Please see [17] for
  318.       further information.
  319.  
  320.       There is no minimum packet size restriction on FDDI networks.
  321.  
  322.       In order to not preclude interoperability with Ethernet in a
  323.       bridged environment, FDDI implementations must be prepared to
  324.       receive (and ignore) trailing pad octets.
  325.  
  326.    Other MAC Layer Issues
  327.  
  328.       The FDDI MAC specification does not require that 16-bit and 48-
  329.       bit address stations be able to interwork fully.  It does,
  330.       however, require that 16-bit stations have full 48-bit
  331.       functionality, and that both types of stations be able to receive
  332.       frames sent to either size broadcast address.  In order to avoid
  333.       interoperability problems, only 48-bit addresses shall be used
  334.       with IP and ARP.
  335.  
  336.  
  337.  
  338. Katz                                                            [Page 6]
  339.  
  340. RFC 1188              IP and ARP on FDDI Networks           October 1990
  341.  
  342.  
  343.       The FDDI MAC specification defines two classes of LLC frames,
  344.       Asynchronous and Synchronous.  Asynchronous frames are further
  345.       controlled by a priority mechanism and two classes of token,
  346.       Restricted and Unrestricted.  Only the use of Unrestricted tokens
  347.       and Asynchronous frames are required by the standard for FDDI
  348.       interoperability.
  349.  
  350.       All IP and ARP frames shall be transmitted as Asynchronous LLC
  351.       frames using Unrestricted tokens, and the Priority value is a
  352.       matter of local convention.  Implementations should make the
  353.       priority a tunable parameter for future use.  It is recommended
  354.       that implementations provide for the reception of IP and ARP
  355.       packets in Synchronous frames, as well as Restricted Asynchronous
  356.       frames.
  357.  
  358.       After packet transmission, FDDI provides Frame Copied (C) and
  359.       Address Recognized (A) indicators.  The use of these indicators is
  360.       a local implementation decision.  Implementations may choose to
  361.       perform link-level retransmission, ARP cache entry invalidation,
  362.       etc., based on the values of these indicators and other
  363.       information.  The semantics of these indicators, especially in the
  364.       presence of bridges, are not well defined as of this writing.
  365.       Implementors are urged to follow the work of ANSI ASC X3T9.5 in
  366.       regard to this issue in order to avoid interoperability problems.
  367.  
  368. IEEE 802.2 Details
  369.  
  370.    While not necessary for supporting IP and ARP, all implementations
  371.    must support IEEE 802.2 standard Class I service in order to be
  372.    compliant with 802.2.  Described below is the minimum functionality
  373.    necessary for a conformant station.  Some of the functions are not
  374.    related directly to the support of the SNAP SAP (e.g., responding to
  375.    XID and TEST commands directed to the null or global SAP addresses),
  376.    but are part of a general LLC implementation.  Implementors should
  377.    consult IEEE Std. 802.2 [11] for details.
  378.  
  379.    802.2 Class I LLC requires the support of Unnumbered Information (UI)
  380.    Commands, eXchange IDentification (XID) Commands and Responses, and
  381.    TEST link (TEST) Commands and Responses.  Stations need not be able
  382.    to transmit XID and TEST commands, but must be able to transmit
  383.    responses.
  384.  
  385.    Encodings
  386.  
  387.       Command frames are identified by having the low order bit of the
  388.       SSAP address reset to zero.  Response frames have the low order
  389.       bit of the SSAP address set to one.
  390.  
  391.  
  392.  
  393.  
  394. Katz                                                            [Page 7]
  395.  
  396. RFC 1188              IP and ARP on FDDI Networks           October 1990
  397.  
  398.  
  399.       The UI command has an LLC control field value of 3.
  400.  
  401.       The XID command/response has an LLC control field value of 175
  402.       (decimal) if the Poll/Final bit is off or 191 (decimal) if the
  403.       Poll/Final bit is on.
  404.  
  405.       The TEST command/response has an LLC control field value of 227
  406.       (decimal) if the Poll/Final bit is off or 243 (decimal) if the
  407.       Poll/Final bit is on.
  408.  
  409.    Elements of Procedure
  410.  
  411.       UI responses and UI commands with the Poll bit set shall be
  412.       ignored.  UI commands having other than the SNAP SAP in the DSAP
  413.       or SSAP fields shall not be processed as IP or ARP packets.
  414.  
  415.       When an XID or TEST command is received, an appropriate response
  416.       must be returned.  XID and TEST commands must be responded to only
  417.       if the DSAP is the SNAP SAP (170 decimal), the Null SAP (0
  418.       decimal), or the Global SAP (255 decimal).  XID and TEST commands
  419.       received with other DSAP values must not be responded to unless
  420.       the station supports the addressed service.  Responses to XID and
  421.       TEST frames shall be constructed as follows:
  422.  
  423.          Destination MAC:  Copied from Source MAC of the command
  424.          Source MAC:  Set to the address of the MAC receiving the
  425.                 command
  426.          DSAP:  Copied from SSAP of the command
  427.          SSAP:  Set to 171 decimal (SNAP SAP + Response bit) if the
  428.                 DSAP in the command was the SNAP SAP or the Global SAP;
  429.                 set to 1 decimal (Null SAP + Response bit) if the DSAP
  430.                 in the command was the Null SAP
  431.  
  432.       When responding to an XID or a TEST command, the value of the
  433.       Final bit in the response must be copied from the value of the
  434.       Poll bit in the command.
  435.  
  436.       XID response frames must include an 802.2 XID Information field of
  437.       129.1.0 indicating Class I (connectionless) service.
  438.  
  439.       TEST response frames must echo the information field received in
  440.       the corresponding TEST command frame.
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Katz                                                            [Page 8]
  451.  
  452. RFC 1188              IP and ARP on FDDI Networks           October 1990
  453.  
  454.  
  455. Appendix on Numbers
  456.  
  457.    The IEEE specifies numbers as bit strings with the least significant
  458.    bit first, or bit-wise little-endian order.  The Internet protocols
  459.    are documented in bit-wise big-endian order.  This may cause some
  460.    confusion about the proper values to use for numbers.  Here are the
  461.    conversions for some numbers of interest.
  462.  
  463.        Number           IEEE        Internet    Internet
  464.                         Binary      Binary      Decimal
  465.  
  466.        UI               11000000    00000011    3
  467.        SAP for SNAP     01010101    10101010    170
  468.        Global SAP       11111111    11111111    255
  469.        Null SAP         00000000    00000000    0
  470.        XID              11110101    10101111    175
  471.        XID Poll/Final   11111101    10111111    191
  472.        XID Info                                 129.1.0
  473.        TEST             11000111    11100011    227
  474.        TEST Poll/Final  11001111    11110011    243
  475.  
  476. References
  477.  
  478.    [1] Postel, J., "Internet Protocol", RFC 791, USC/Information
  479.        Sciences Institute, September 1981.
  480.  
  481.    [2] Plummer, D., "An Ethernet Address Resolution Protocol - or -
  482.        Converting Network Protocol Addresses to 48.bit Ethernet Address
  483.        for Transmission on Ethernet Hardware", RFC 826, MIT, November
  484.        1982.
  485.  
  486.    [3] Postel, J., and Reynolds, J., "A Standard for the Transmission of
  487.        IP Datagrams over IEEE 802 Networks", RFC 1042, USC/Information
  488.        Sciences Institute, February 1988.
  489.  
  490.    [4] ISO, "Fiber Distributed Data Interface (FDDI) - Media Access
  491.        Control", ISO 9314-2, 1989.  See also ANSI X3.139-1987.
  492.  
  493.    [5] ISO, "Fiber Distributed Data Interface (FDDI) - Token Ring
  494.        Physical Layer Protocol", ISO 9314-1, 1989.  See also ANSI
  495.        X3.148-1988.
  496.  
  497.    [6] ISO, "Fiber Distributed Data Interface (FDDI) - Physical Layer
  498.        Medium Dependent", ISO DIS 9314-3, 1989.  See also ANSI X3.166-
  499.        199x.
  500.  
  501.    [7] ANSI, "FDDI Station Management", ANSI X3T9.5/84-49 Rev 6.0, 1990.
  502.  
  503.  
  504.  
  505.  
  506. Katz                                                            [Page 9]
  507.  
  508. RFC 1188              IP and ARP on FDDI Networks           October 1990
  509.  
  510.  
  511.    [8] IEEE, "IEEE Standards for Local Area Networks: Carrier Sense
  512.        Multiple Access with Collision Detection (CSMA/CD) Access Method
  513.        and Physical Layer Specifications", IEEE, New York, New York,
  514.        1985.
  515.  
  516.    [9] IEEE, "IEEE Standards for Local Area Networks: Token-Passing Bus
  517.        Access Method and Physical Layer Specification", IEEE, New York,
  518.        New York, 1985.
  519.  
  520.   [10] IEEE, "IEEE Standards for Local Area Networks: Token Ring Access
  521.        Method and Physical Layer Specifications", IEEE, New York, New
  522.        York, 1985.
  523.  
  524.   [11] IEEE, "IEEE Standards for Local Area Networks: Logical Link
  525.        Control", IEEE, New York, New York, 1985.
  526.  
  527.   [12] IEEE, "Draft Standard P802.1A--Overview and Architecture", 1989.
  528.  
  529.   [13] Reynolds, J.K., and J.  Postel, "Assigned Numbers", RFC 1060,
  530.        USC/Information Sciences Institute, March 1990.
  531.  
  532.   [14] Braden, R., and J.  Postel, "Requirements for Internet Gateways",
  533.        RFC 1009, USC/Information Sciences Institute, June 1987.
  534.  
  535.   [15] Deering, S., "Host Extensions for IP Multicasting", RFC 1112,
  536.        Stanford University, August 1989.
  537.  
  538.   [16] Cohen, D., "On Holy Wars and a Plea for Peace", Computer, IEEE,
  539.        October 1981.
  540.  
  541.   [17] Postel, J., "The TCP Maximum Segment Size Option and Related
  542.        Topics", RFC 879, USC/Information Sciences Institute, November
  543.        1983.
  544.  
  545. Security Considerations
  546.  
  547.    Security issues are not discussed in this memo.
  548.  
  549. Author's Address
  550.  
  551.    Dave Katz
  552.    Merit/NSFNET
  553.    1075 Beal Ave.
  554.    Ann Arbor, MI  48109
  555.  
  556.    Phone: (313) 763-4898
  557.  
  558.    EMail: dkatz@merit.edu
  559.  
  560.  
  561.  
  562. Katz                                                           [Page 10]
  563.  
  564. RFC 1188              IP and ARP on FDDI Networks           October 1990
  565.  
  566.  
  567.  
  568.  
  569.  
  570.  
  571.  
  572.  
  573.  
  574.  
  575.  
  576.  
  577.  
  578.  
  579.  
  580.  
  581.  
  582.  
  583.  
  584.  
  585.  
  586.  
  587.  
  588.  
  589.  
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Katz                                                           [Page 11]
  619.