doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc1103.txt b/doc/rfc/rfc1103.txt
new file mode 100644
index 0000000..b40fdd7
--- /dev/null
+++ b/doc/rfc/rfc1103.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+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]
+
\ No newline at end of file