As per Relevance of the word implementation, we have this rfc below:
Network Working Group D.
Request for Comments: 1390 cisco Systems, Inc
STD: 36 January 1993
Transmission of IP and ARP over FDDI
Status of this
This RFC specifies an IAB standards track protocol for the
community, and requests discussion and suggestions for improvements
Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol
Distribution of this memo is unlimited
This memo defines a method of encapsulating the Internet
(IP) datagrams and Address Resolution Protocol (ARP) requests
replies on Fiber Distributed Data Interface (FDDI) Networks
This RFC is the product of the IP over FDDI Working Group of
Internet Engineering Task Force (IETF).
This memo draws heavily in both concept and text from RFC 1042 [3],
written by Jon Postel and Joyce K. Reynolds of USC/
Sciences Institute. The author would also like to acknowledge
contributions of the IP Over FDDI Working Group of the IETF,
of ANSI ASC X3T9.5, and others in the FDDI community
The following language conventions are used in the items
specification in this document
"Must," "Shall," or "Mandatory"--the item is an
requirement of the specification
"Should" or "Recommended"--the item should generally be
for all but exceptional circumstances
"May" or "Optional"--the item is truly optional and may
followed or ignored according to the needs of the implementor
Katz [Page 1]
RFC 1390 IP Over FDDI January 1993
The goal of this specification is to allow compatible
interoperable implementations for transmitting IP datagrams [1]
ARP requests and replies [2].
The Fiber Distributed Data Interface (FDDI) specifications define
family of standards for Local Area Networks (LANs) that provides
Physical Layer and Media Access Control Sublayer of the Data
Layer as defined by the ISO Open System Interconnection
Model (ISO/OSI). Documents are in various stages of
toward International Standardization for Media Access Control (MAC
[4], Physical Layer Protocol (PHY) [5], Physical Layer
Dependent (PMD) [6], and Station Management (SMT) [7]. The family
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
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.
this time, it is not necessary that the use of IP and ARP
consistent between FDDI and IEEE 802 networks, but it is the
of this memo not to preclude Data Link Layer interoperability at
time as the standards define it
It is the explicit intent of this memo to allow the
of IP and ARP between stations on FDDI networks and stations
Ethernet networks via translational bridges
The FDDI standards define both single and dual MAC stations.
document describes the use of IP and ARP on single MAC
(single-attach or dual-attach) only
Katz [Page 2]
RFC 1390 IP Over FDDI January 1993
Packet
IP datagrams and ARP requests and replies sent on FDDI networks
be encapsulated within the 802.2 LLC and Sub-Network Access
(SNAP) [12] data link layers and the FDDI MAC and physical layers
The SNAP must be used with an Organization Code indicating that
SNAP header contains the EtherType code (as listed in
Numbers [13]).
802.2 LLC Type 1 communication (which must be implemented by
conforming 802.2 stations) is used exclusively. All frames must
transmitted in standard 802.2 LLC Type 1 Unnumbered
format, with the DSAP and the SSAP fields of the 802.2 header set
the assigned global SAP value for SNAP [11]. The 24-bit
Code in the SNAP must be zero, and the remaining 16 bits are
EtherType from Assigned Numbers [13] (IP = 2048, ARP = 2054).
...--------+--------+--------+
MAC Header | FDDI
...--------+--------+--------+
+--------+--------+--------+
| DSAP=K1| SSAP=K1| Control| 802.2
+--------+--------+--------+
+--------+--------+---------+--------+--------+
|Protocol Id or Org Code =K2| EtherType | 802.2
+--------+--------+---------+--------+--------+
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
The mapping of 32-bit Internet addresses to 48-bit FDDI
shall be done via the dynamic discovery procedure of the
Resolution Protocol (ARP) [2].
Internet addresses are assigned arbitrarily on Internet networks
Each host's implementation must know its own Internet address
respond to Address Resolution requests appropriately. It must
Katz [Page 3]
RFC 1390 IP Over FDDI January 1993
use ARP to translate Internet addresses to FDDI addresses
needed
The ARP protocol has several fields that parameterize its use in
specific context [2]. These fields are
hrd 16 - bits The Hardware Type
pro 16 - bits The Protocol Type
hln 8 - bits Octets in each hardware
pln 8 - bits Octets in each protocol
op 16 - bits Operation
The hardware type code assigned for IEEE 802 networks is 6 [13].
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.
order to not preclude interoperability with Ethernets in a
environment, ARP packets shall be transmitted with a hardware
code of 1. ARP packets shall be accepted if received with a
type code of 1.
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
carried in "canonical" bit order, with the Group bit positioned
the low order bit of the first octet. As FDDI addresses are
expressed with the Group bit in the high order bit position,
addresses must be bit-reversed within each octet
Although outside the scope of this document, it is recommended
MAC addresses be represented in canonical order in all Network
protocols carried within the information field of an FDDI frame
Broadcast
The broadcast Internet address (the address on that network with
host part of all binary ones) must be mapped to the broadcast
address (of all binary ones) (see [14]).
Katz [Page 4]
RFC 1390 IP Over FDDI January 1993
Multicast
A method of supporting IP multicasting is specified in [15].
method shall be used in FDDI networks if IP multicasting is to
supported. The use of this method may require the ability to
frames addressed to any one of an arbitrary number of
(group) addresses
An IP multicast address is mapped to an FDDI group address by
the low order 23 bits of the IP address into the low order 23 bits
the FDDI group address 01-00-5E-00-00-00 (in "canonical" order).
[See 13, page 29.]
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
octet (canonical order). When bit-reversed for transmission in
destination MAC address field of an FDDI frame (native order),
becomes
80-00-7A-FE-00-40
that is, with the multicast (group) bit as the high order bit of
first octet, that being the first bit transmitted on the medium
Trailer
Some versions of Unix 4.x bsd use a different encapsulation method
order to get better network performance with the VAX virtual
architecture. Hosts directly connected to FDDI networks shall
use trailers
Byte
As described in Appendix B of the Internet Protocol
[1], the IP datagram is transmitted over FDDI networks as a series
8-bit bytes. This byte transmission order has been called "big
endian" [16].
Katz [Page 5]
RFC 1390 IP Over FDDI January 1993
MAC Layer
Packet
The FDDI MAC specification [4] defines a maximum frame size
9000 symbols (4500 octets) for all frame fields, including
symbols (two octets) of preamble. This leaves roughly 4470
for data after the LLC/SNAP header is taken into account
However, in order to allow future extensions to the MAC header
frame status fields, it is desirable to reserve additional
for MAC overhead
Therefore, the MTU of FDDI networks shall be 4352 octets.
provides for 4096 octets of data and 256 octets of headers at
network layer and above. Implementations must not send
larger than the MTU
Gateway implementations must be prepared to accept packets
large as the MTU and fragment them when necessary.
implementations should be able to accept packets as large as
be carried within a maximum size FDDI frame and fragment them
Host implementations should be prepared to accept packets as
as the MTU; however, hosts must not send datagrams longer than 576
octets unless they have explicit knowledge that the destination
prepared to accept them. Host implementations may accept
as large as can be carried within a maximum size FDDI frame.
host may communicate its size preference in TCP-based
via the TCP Maximum Segment Size option [17].
Datagrams on FDDI networks may be longer than the general
default maximum packet size of 576 octets. Hosts connected to
FDDI network should keep this in mind when sending datagrams
hosts that are not on the same local network. It may
appropriate to send smaller datagrams to avoid
fragmentation at intermediate gateways. Please see [17]
further information
There is no minimum packet size restriction on FDDI networks
In order to not preclude interoperability with Ethernet in
bridged environment, FDDI implementations must be prepared
receive (and ignore) trailing pad octets
Other MAC Layer
The FDDI MAC specification does not require that 16-bit and 48-
Katz [Page 6]
RFC 1390 IP Over FDDI January 1993
bit address stations be able to interwork fully. It does
however, require that 16-bit stations have full 48-
functionality, and that both types of stations be able to
frames sent to either size broadcast address. In order to
interoperability problems, only 48-bit addresses shall be
with IP and ARP
The FDDI MAC specification defines two classes of LLC frames
Asynchronous and Synchronous. Asynchronous frames are
controlled by a priority mechanism and two classes of token
Restricted and Unrestricted. Only the use of Unrestricted
and Asynchronous frames are required by the standard for
interoperability
All IP and ARP frames shall be transmitted as Asynchronous
frames using Unrestricted tokens, and the Priority value is
matter of local convention. Implementations should make
priority a tunable parameter for future use. It is
that implementations provide for the reception of IP and
packets in Synchronous frames, as well as Restricted
frames
After packet transmission, FDDI provides Frame Copied (C)
Address Recognized (A) indicators. The use of these indicators
a local implementation decision. Implementations may choose
perform link-level retransmission, ARP cache entry invalidation
etc., based on the values of these indicators and
information. The semantics of these indicators, especially in
presence of bridges, are not well defined as of this writing
Implementors are urged to follow the work of ANSI ASC X3T9.5
regard to this issue in order to avoid interoperability problems
IEEE 802.2
While not necessary for supporting IP and ARP, all
must support IEEE 802.2 standard Class I service in order to
compliant with 802.2. Described below is the minimum
necessary for a conformant station. Some of the functions are
related directly to the support of the SNAP SAP (e.g., responding
XID and TEST commands directed to the null or global SAP addresses),
but are part of a general LLC implementation. Implementors
consult IEEE Std. 802.2 [11] for details
802.2 Class I LLC requires the support of Unnumbered Information (UI
Commands, eXchange IDentification (XID) Commands and Responses,
TEST link (TEST) Commands and Responses. Stations need not be
to transmit XID and TEST commands, but must be able to
responses
Katz [Page 7]
RFC 1390 IP Over FDDI January 1993
Command frames are identified by having the low order bit of
SSAP address reset to zero. Response frames have the low
bit of the SSAP address set to one
The UI command has an LLC control field value of 3.
The XID command/response has an LLC control field value of 175
(decimal) if the Poll/Final bit is off or 191 (decimal) if
Poll/Final bit is on
The TEST command/response has an LLC control field value of 227
(decimal) if the Poll/Final bit is off or 243 (decimal) if
Poll/Final bit is on
Elements of
UI responses and UI commands with the Poll bit set shall
ignored. UI commands having other than the SNAP SAP in the
or SSAP fields shall not be processed as IP or ARP packets
When an XID or TEST command is received, an appropriate
must be returned. XID and TEST commands must be responded to
if the DSAP is the SNAP SAP (170 decimal), the Null SAP (0
decimal), or the Global SAP (255 decimal). XID and TEST
received with other DSAP values must not be responded to
the station supports the addressed service. Responses to XID
TEST frames shall be constructed as follows
Destination MAC: Copied from Source MAC of the
Source MAC: Set to the address of the MAC receiving
DSAP: Copied from SSAP of the
SSAP: Set to 171 decimal (SNAP SAP + Response bit) if
DSAP in the command was the SNAP SAP or the Global SAP
set to 1 decimal (Null SAP + Response bit) if the
in the command was the Null
When responding to an XID or a TEST command, the value of
Final bit in the response must be copied from the value of
Poll bit in the command
XID response frames must include an 802.2 XID Information field
129.1.0 indicating Class I (connectionless) service
TEST response frames must echo the information field received
the corresponding TEST command frame
Katz [Page 8]
RFC 1390 IP Over FDDI January 1993
Appendix on
The IEEE specifies numbers as bit strings with the least
bit first, or bit-wise little-endian order. The Internet
are documented in bit-wise big-endian order. This may cause
confusion about the proper values to use for numbers. Here are
conversions for some numbers of interest
Number IEEE Internet
Binary Binary
UI 11000000 00000011 3
SAP for SNAP 01010101 10101010 170
Global SAP 11111111 11111111 255
Null SAP 00000000 00000000 0
XID 11110101 10101111 175
XID Poll/Final 11111101 10111111 191
XID Info 129.1.0
TEST 11000111 11100011 227
TEST Poll/Final 11001111 11110011 243
Differences between this document and RFC 1188
The following is a summary of the differences between RFC 1188
this document
A reference to a future dual-MAC document has been removed
A statement of explicit intent to support FDDI/
interoperability has been added
The acceptance of ARP frames bearing hardware type code 6 (
802) has been removed
The references have been updated
The author's address has been updated
[1] Postel, J., "Internet Protocol", STD 5, RFC 791, USC/
Sciences Institute, September 1981.
[2] Plummer, D., "An Ethernet Address Resolution Protocol - or -
Converting Network Protocol Addresses to 48.bit Ethernet
for Transmission on Ethernet Hardware", RFC 826, MIT,
1982.
Katz [Page 9]
RFC 1390 IP Over FDDI January 1993
[3] Postel, J., and J. Reynolds, "A Standard for the Transmission
IP Datagrams over IEEE 802 Networks", RFC 1042, USC/
Sciences Institute, February 1988.
[4] ISO, "Fiber Distributed Data Interface (FDDI) - Media
Control", ISO 9314-2, 1989. See also ANSI X3.139-1987.
[5] ISO, "Fiber Distributed Data Interface (FDDI) - Token
Physical Layer Protocol", ISO 9314-1, 1989. See also
X3.148-1988.
[6] ISO, "Fiber Distributed Data Interface (FDDI) - Physical
Medium Dependent", ISO DIS 9314-3, 1989. See also ANSI X3.166-
199x
[7] ANSI, "FDDI Station Management", ANSI X3T9.5/84-49 Rev 7.1, 1992.
[8] IEEE, "IEEE Standards for Local Area Networks: Carrier
Multiple Access with Collision Detection (CSMA/CD) Access
and Physical Layer Specifications", IEEE, New York, New York
1985.
[9] IEEE, "IEEE Standards for Local Area Networks: Token-Passing
Access Method and Physical Layer Specification", IEEE, New York
New York, 1985.
[10] IEEE, "IEEE Standards for Local Area Networks: Token Ring
Method and Physical Layer Specifications", IEEE, New York,
York, 1985.
[11] IEEE, "IEEE Standards for Local Area Networks: Logical
Control", IEEE, New York, New York, 1985.
[12] IEEE, "Draft Standard P802.1A--Overview and Architecture", 1989.
[13] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
USC/Information Sciences Institute, July 1992.
[14] Braden, R., and J. Postel, "Requirements for Internet Gateways",
STD 4, RFC 1009, USC/Information Sciences Institute, June 1987.
[15] Deering, S., "Host Extensions for IP Multicasting", STD 5,
1112, Stanford University, August 1989.
[16] Cohen, D., "On Holy Wars and a Plea for Peace", Computer, IEEE
October 1981.
Katz [Page 10]
RFC 1390 IP Over FDDI January 1993
[17] Postel, J., "The TCP Maximum Segment Size Option and
Topics", RFC 879, USC/Information Sciences Institute,
1983.
Security
Security issues are not discussed in this memo
Author's
Dave
cisco Systems, Inc
1525 O'Brien Dr
Menlo Park, CA 94025
Phone: (415) 688-8284
EMail: dkatz@cisco.
Katz [Page 11]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
