rfc1188.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                            D. Katz
Request for Comments: 1188                                  Merit/NSFNET
Obsoletes:  RFC 1103                                        October 1990


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

Status of this Memo

   This memo defines a method of encapsulating the Internet Protocol
   (IP) datagrams and Address Resolution Protocol (ARP) requests and
   replies on Fiber Distributed Data Interface (FDDI) Networks.  This
   RFC specifies a protocol on the IAB Standards Track for the Internet
   community, and requests discussion and suggestions for improvements.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.

   This proposal is the product of the IP over FDDI Working Group of the
   Internet Engineering Task Force (IETF).  Comments on this memo should
   be submitted to the IETF IP over FDDI Working Group Chair.
   Distribution of this memo is unlimited.

Abstract

   This document specifies a method for the use of IP and ARP on FDDI
   networks.  The encapsulation method used is described, as well as
   various media-specific issues.

Acknowledgments

   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.  The author would also like to acknowledge the
   contributions of the IP Over FDDI Working Group of the IETF, members
   of ANSI ASC X3T9.5, and others in the FDDI community.

Conventions

   The following language conventions are used in the items of
   specification in this document:

      "Must," "Shall," 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.




Katz                                                            [Page 1]

RFC 1188              IP and ARP on FDDI Networks           October 1990


      "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 [1] and
   ARP requests and replies [2].

   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
   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   | F   |
        +-------------+ D S |
        |  FDDI PHY   | D M |
        +-------------+ I T |
        |  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.

   The FDDI standards define both single and dual MAC stations.  This
   document describes the use of IP and ARP on single MAC stations
   (single-attach or dual-attach) only.  Operation on dual MAC stations
   will be described in a forthcoming document.





Katz                                                            [Page 2]

RFC 1188              IP and ARP on FDDI Networks           October 1990


Packet Format

   IP datagrams and ARP requests and replies sent on FDDI networks shall
   be encapsulated within the 802.2 LLC and Sub-Network Access Protocol
   (SNAP) [12] 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 [13]).

   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 [13] (IP = 2048, ARP = 2054).

      ...--------+--------+--------+
                 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 48-bit FDDI addresses
   shall 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



Katz                                                            [Page 3]

RFC 1188              IP and ARP on FDDI Networks           October 1990


   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 [13].  The
   hardware type code assigned for Ethernet networks is 1 [13].
   Unfortunately, differing values between Ethernet and IEEE 802
   networks cause interoperability problems in bridged environments.  In
   order to not preclude interoperability with Ethernets in a bridged
   environment, ARP packets shall be transmitted with a hardware type
   code of 1.  Furthermore, ARP packets shall be accepted if received
   with hardware type codes of either 1 or 6.

   The protocol type code for IP is 2048 [13].

   The hardware address length is 6.

   The protocol address length (for IP) is 4.

   The operation code is 1 for request and 2 for reply.

   In order to not preclude interoperability in a bridged environment,
   the hardware addresses in ARP packets (ar$sha, ar$tha) must be
   carried in "canonical" bit order, with the Group bit positioned as
   the low order bit of the first octet.  As FDDI addresses are normally
   expressed with the Group bit in the high order bit position, the
   addresses must be bit-reversed within each octet.

   Although outside the scope of this document, it is recommended that
   MAC addresses be represented in canonical order in all Network Layer
   protocols carried within the information field of an FDDI frame.

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 [14]).

Multicast Support

   A method of supporting IP multicasting is specified in [15].  This



Katz                                                            [Page 4]

RFC 1188              IP and ARP on FDDI Networks           October 1990


   method shall be used in FDDI networks if IP multicasting is to be
   supported.  The use of this method may require the ability to copy
   frames addressed to any one of an arbitrary number of multicast
   (group) addresses.

   An IP multicast address is mapped to an FDDI group address by placing
   the low order 23 bits of the IP address into the low order 23 bits of
   the FDDI group address 01-00-5E-00-00-00 (in "canonical" order).
   [See 13, page 20.]

   For example, the IP multicast address:

         224.255.0.2

   maps to the FDDI group address:

         01-00-5E-7F-00-02

   in which the multicast (group) bit is the low order bit of the first
   octet (canonical order).  When bit-reversed for transmission in the
   destination MAC address field of an FDDI frame (native order), it
   becomes:

         80-00-7A-FE-00-40

   that is, with the multicast (group) bit as the high order bit of the
   first octet, that being the first bit transmitted on the medium.

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.  Hosts directly connected to FDDI networks shall not
   use trailers.

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" [16].

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



Katz                                                            [Page 5]

RFC 1188              IP and ARP on FDDI Networks           October 1990


      symbols (two octets) of preamble.  This leaves roughly 4470 octets
      for data after the LLC/SNAP header is taken into account.

      However, in order to allow future extensions to the MAC header and
      frame status fields, it is desirable to reserve additional space
      for MAC overhead.

      Therefore, the MTU of FDDI networks shall be 4352 octets.  This
      provides for 4096 octets of data and 256 octets of headers at the
      network layer and above.  Implementations must not send packets
      larger than the MTU.

      Gateway implementations must be prepared to accept packets as
      large as the MTU and fragment them when necessary.  Gateway
      implementations should be able to accept packets as large as can
      be carried within a maximum size FDDI frame and fragment them.

      Host implementations should be prepared to accept packets as large
      as the MTU; however, hosts must not send datagrams longer than 576
      octets unless they have explicit knowledge that the destination is
      prepared to accept them.  Host implementations may accept packets
      as large as can be carried within a maximum size FDDI frame.  A
      host may communicate its size preference in TCP- based
      applications via the TCP Maximum Segment Size option [17].