GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1103

Network Working Group D. Katz Request for Comments: 1103 Merit/NSFNET

                                                             June 1989
            A Proposed Standard for the Transmission of
                  IP Datagrams over FDDI Networks

Status of this Memo

 This RFC specifies a method of encapsulating the Internet Protocol
 (IP) [1] datagrams and Address Resolution Protocol (ARP) [2] requests
 and replies on Fiber Distributed Data Interface (FDDI) Networks.
 This RFC specifies a proposed protocol standard for the Internet
 community.  Comments are welcome.  Distribution of this memo is
 unlimited.

Acknowledgment

 This memo draws heavily in both concept and text from RFC 1042 [3],
 written by Jon Postel and Joyce K. Reynolds of USC/Information
 Sciences Institute.

Conventions

 The following language conventions are used in the items of
 specification in this document:
    "Must" or "Mandatory"--the item is an absolute requirement of the
    specification.
    "Should" or "Recommended"--the item should generally be followed
    for all but exceptional circumstances.
    "May" or "Optional"--the item is truly optional and may be
    followed or ignored according to the needs of the implementor.

Introduction

 The goal of this specification is to allow compatible and
 interoperable implementations for transmitting IP datagrams and ARP
 requests and replies.
 The Fiber Distributed Data Interface (FDDI) specifications define a
 family of standards for Local Area Networks (LANs) that provides the
 Physical Layer and Media Access Control Sublayer of the Data Link
 Layer as defined by the ISO Open System Interconnection Reference
 Model (ISO/OSI).  Documents are in various stages of progression

Katz [Page 1] RFC 1103 IP Datagrams over FDDI Networks June 1989

 toward International Standardization for Media Access Control (MAC)
 [4], Physical Layer Protocol (PHY) [5], Physical Layer Medium
 Dependent (PMD) [6], and Station Management (SMT) [7].  The family of
 FDDI standards corresponds to the IEEE 802 MAC layer standards [8, 9,
 10].
 The remainder of the Data Link Service is provided by the IEEE 802.2
 Logical Link Control (LLC) service [11].  The resulting stack of
 services appears as follows:
         +-------------+
         |   IP/ARP    |
         +-------------+
         |  802.2 LLC  |
         +-------------+
         |  FDDI MAC   |
         +-------------+
         |  FDDI PHY   |
         +-------------+
         |  FDDI PMD   |
         +-------------+
 This memo describes the use of IP and ARP in this environment.  At
 this time, it is not necessary that the use of IP and ARP be
 consistent between FDDI and IEEE 802 networks, but it is the intent
 of this memo not to preclude Data Link Layer interoperability at such
 time as the standards define it.

Packet Format

 IP datagrams and ARP requests and replies sent on FDDI networks must
 be encapsulated within the 802.2 LLC and Sub-Network Access Protocol
 (SNAP) data link layers and the FDDI MAC and physical layers.  The
 SNAP must be used with an Organization Code indicating that the SNAP
 header contains the EtherType code (as listed in Assigned Numbers
 [12]).
 802.2 LLC Type 1 communication (which must be implemented by all
 conforming 802.2 stations) is used exclusively.  All frames must be
 transmitted in standard 802.2 LLC Type 1 Unnumbered Information
 format, with the DSAP and the SSAP fields of the 802.2 header set to
 the assigned global SAP value for SNAP [11].  The 24-bit Organization
 Code in the SNAP must be zero, and the remaining 16 bits are the
 EtherType from Assigned Numbers [12] (IP = 2048, ARP = 2054).

Katz [Page 2] RFC 1103 IP Datagrams over FDDI Networks June 1989

   ...--------+--------+--------+
              MAC Header        |                           FDDI 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.
   The K1 value is 170 (decimal).
   The K2 value is 0 (zero).
   The control value is 3 (Unnumbered Information).

Address Resolution

 The mapping of 32-bit Internet addresses to 16-bit or 48-bit FDDI
 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 FDDI addresses when
 needed.
 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     Octets in each hardware address
       pln    8 - bits     Octets in each protocol address
       op    16 - bits     Operation Code
 The hardware type code assigned for IEEE 802 networks is 6 [12].
 FDDI networks, although not IEEE 802 networks per se, are
 semantically equivalent and use the same type code.
 The protocol type code for IP is 2048 [12].

Katz [Page 3] RFC 1103 IP Datagrams over FDDI Networks June 1989

 The hardware address length is 2 for 16-bit FDDI addresses, or 6 for
 48-bit FDDI 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) must be mapped to the broadcast FDDI
 address (of all binary ones) (see [13]).

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 FDDI network may use
 this format between themselves.  Details of the trailer encapsulation
 method may be found in [14].  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 FDDI networks as a series of
 8-bit bytes.  This byte transmission order has been called "big-
 endian" [15].

MAC Layer Details

 Packet Size
    The FDDI MAC specification [4] defines a maximum frame size of
    9000 symbols (4500 octets) for all frame fields, including four
    symbols (two octets) of preamble.  This gives the following MAC
    layer overhead:

Katz [Page 4] RFC 1103 IP Datagrams over FDDI Networks June 1989

              Field                    Size in Octets
              Preamble                     2
              Start Delimiter              1
              Frame Control                1
              Destination Address          6 (2)
              Source Address               6 (2)
              FCS                          4
              End Delimiter/Frame Status   2
              Total                        22 (14)
              Remaining for Data           4478 (4486)
    Subtracting the 8 byte LLC/SNAP header, this gives a maximum
    packet size (MTU) of 4470 (4478) octets.  For compatibility
    purposes, the maximum packet size used with IP datagrams or ARP
    requests and replies must be consistent on a particular network.
    The overhead calculations (above) assume a standard Frame Status
    field consisting of three symbols.  Additional Implementor Defined
    frame status information, although permitted by the FDDI MAC
    specification, must not be used with IP datagrams because it
    affects 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 [16].
    Datagrams on FDDI networks may be longer than the general Internet
    default maximum packet size of 576 octets.  Hosts connected to an
    FDDI network should keep this in mind when sending datagrams to
    hosts that are not on the same local network.  It may be
    appropriate to send smaller datagrams to avoid unnecessary
    fragmentation at intermediate gateways.  Please see [16] for
    further information.
    There is no minimum packet size restriction on FDDI networks.

Other MAC Layer Issues

 The FDDI MAC specification does not require that 16-bit and 48-bit
 address stations be able to interwork fully.  It does, however,

Katz [Page 5] RFC 1103 IP Datagrams over FDDI Networks June 1989

 require that 16-bit stations have full 48-bit functionality, and that
 both types of stations be able to receive frames sent to either size
 broadcast address.  For use with IP and ARP, all communicating
 stations on a LAN must use a consistent address size.
 Implementations must discard any IP or ARP packets received with an
 unimplemented or inactive address size.  16-bit and 48-bit
 implementations may coexist on the same FDDI network; however, if
 they wish to interwork they must be considered separate IP networks
 and linked with an IP router capable of supporting 16-and 48-bit
 addresses simultaneously.
 Group (multicast) addresses are defined by the FDDI MAC specification
 but are not necessarily supported by existing hardware.  Therefore,
 this feature must not be used by IP and ARP.
 The FDDI MAC specification defines two classes of frames,
 Asynchronous and Synchronous.  Asynchronous frames are further
 controlled by a priority mechanism and two classes of token,
 Restricted and Unrestricted.  Only the use of Unrestricted tokens and
 Asynchronous frames are required by the standard for FDDI
 interoperability.  The priority mechanism is currently implemented
 locally by the transmitting station and the Priority field in
 Asynchronous frames is ignored by other stations.  This field will
 likely be interpreted by Transparent Bridges once they are defined.
 There is no default value for priority called out in the MAC
 standard.
 Therefore, all IP and ARP frames must be transmitted as Asynchronous
 frames using Unrestricted tokens, and the Priority value is a matter
 of local convention.  Implementations should make the priority a
 tunable parameter for future use.  It is recommended that
 implementations provide for the reception of IP and ARP packets in
 Synchronous frames.
 After packet transmission, FDDI provides Frame Copied (C) and Address
 Recognized (A) indicators.  There are four possible combinations of
 the indicators with the following semantics:
          (C)      (A)
          Reset    Reset   The frame was not received by any station.
          Reset    Set     The addressed station is congested.
          Set      Reset   Reserved.
          Set      Set     The addressed station received the frame.
 Implementations may use these indicators to provide some amount of
 error detection and correction:
    If the Frame Copied bit is reset but the Address Recognized bit is

Katz [Page 6] RFC 1103 IP Datagrams over FDDI Networks June 1989

    set, receiver congestion has occurred.  It is recommended, though
    not mandatory, that hosts retransmit the offending packet a small
    number of times (4) or until congestion no longer occurs.
    If the both the Address Recognized indicator and the Frame Copied
    indicator are reset, an implementation has three options: (1)
    ignore the error and throw the packet away, (2) return an ICMP
    destination unreachable message to the source, or (3) delete the
    ARP entry which was used to send this packet and send a new ARP
    request to the destination address.  The latter option is the
    preferred approach since it will allow graceful recovery from
    first hop bridge and router failures and changed hardware
    addresses.
    As of this writing there is a proposal within ANSI to set the
    Frame Copied indicator and reset the Address Recognized indicator
    when a frame is forwarded by a Transparent Bridge.  For future
    compatibility, implementations should interpret this combination
    of indicators as if the frame were successfully delivered to the
    destination (i.e., do nothing).

IEEE 802.2 Details

 While not necessary for supporting IP and ARP, all implementations
 must support IEEE 802.2 standard Class I service in order to be
 compliant with 802.2.  This requires supporting Unnumbered
 Information (UI) Commands, eXchange IDentification (XID) Commands and
 Responses, and TEST link (TEST) Commands and Responses.
 When an XID or TEST command is received, a response must be returned
 with Destination and Source addresses, and DSAP and SSAP, swapped.
 When responding to an XID or a TEST command, the value of the Final
 bit in the response must be copied from the value of the Poll bit in
 the command.
 The XID command or response has an LLC control field value of 175
 (decimal) if the Poll/Final bit is off or 191 (decimal) if the
 Poll/Final bit is on.
 The TEST command or response has an LLC control field value of 227
 (decimal) if the Poll/Final bit is off or 243 (decimal) if the
 Poll/Final bit is on.
 Command frames are identified by having the high order bit of the
 SSAP address reset to zero.  Response frames have the high order bit
 of the SSAP address set to one.

Katz [Page 7] RFC 1103 IP Datagrams over FDDI Networks June 1989

 XID response frames must include an 802.2 XID Information field of
 129.1.0 indicating Class I (connectionless) service.
 TEST response frames must echo the information field received in the
 corresponding TEST command frame.

Appendix on Numbers

 The IEEE specifies 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    C0      11000000    00000011    3
     SAP for SNAP  55      01010101    10101010    170
     XID           F5      11110101    10101111    175
     XID           FD      11111101    10111111    191
     TEST          C7      11000111    11100011    227
     TEST          CF      11001111    11110011    243
     Info          818000                          129.1.0

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]  Postel J., and J. Reynolds, "A Standard for the Transmission of
     IP Datagrams over IEEE 802 Networks", RFC1042, USC/Information
     Sciences Institute, February, 1988.
[4]  ISO, "Fiber Distributed Data Interface (FDDI) - Media Access
     Control", ISO 9314-2, 1988.  See also ANSI X3.139-1987.
[5]  ISO, "Fiber Distributed Data Interface (FDDI) - Token Ring
     Physical Layer Protocol", ISO 9314-1, 1988.  See also ANSI
     X3.148-1988.
[6]  ISO, "Fiber Distributed Data Interface (FDDI) - Physical Layer
     Medium Dependent", ISO DIS 9314-3, 1988.  See also ANSI X3.166-

Katz [Page 8] RFC 1103 IP Datagrams over FDDI Networks June 1989

     198x.
[7]  ANSI, "FDDI Station Management", ANSI X3T9.5/84-49 Rev 4.0, 1988.
[8]  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.
[9]  IEEE, "IEEE Standards for Local Area Networks: Token-Passing Bus
     Access Method and Physical Layer Specification", IEEE, New York,
     New York, 1985.
[10] IEEE, "IEEE Standards for Local Area Networks: Token Ring Access
     Method and Physical Layer Specifications", IEEE, New York, New
     York, 1985.
[11] IEEE, "IEEE Standards for Local Area Networks: Logical Link
     Control", IEEE, New York, New York, 1985.
[12] Reynolds, J.K., and J. Postel, "Assigned Numbers", RFC-1010,
     USC/Information Sciences Institute, May 1987.
[13] Braden, R., and J. Postel, "Requirements for Internet Gateways",
     RFC-1009, USC/Information Sciences Institute, June 1987.
[14] Leffler, S., and M. Karels, "Trailer Encapsulations", RFC-893,
     University of California at Berkeley, April 1984.
[15] Cohen, D., "On Holy Wars and a Plea for Peace", Computer, IEEE,
     October 1981.
[16] Postel, J., "The TCP Maximum Segment Size Option and Related
     Topics", RFC-879, USC/Information Sciences Institute, November
     1983.

Author's Address

 Dave Katz Merit/NSFNET 1075 Beal Ann Arbor, MI 48109-2112
 Phone: 1-800-66-MERIT
 Email: Dave_Katz@um.cc.umich.edu

Katz [Page 9]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1103.txt · Last modified: 1989/06/02 03:56 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki