As per Relevance of the word datagram, we have this rfc below:
Network Working Group D.
Request for Comments: 1103 Merit/
June 1989
A Proposed Standard for the Transmission
IP Datagrams over FDDI
Status of this
This RFC specifies a method of encapsulating the Internet
(IP) [1] datagrams and Address Resolution Protocol (ARP) [2]
and replies on Fiber Distributed Data Interface (FDDI) Networks
This RFC specifies a proposed protocol standard for the
community. Comments are welcome. Distribution of this memo
unlimited
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 following language conventions are used in the items
specification in this document
"Must" or "Mandatory"--the item is an absolute requirement of
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
The goal of this specification is to allow compatible
interoperable implementations for transmitting IP datagrams and
requests and replies
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
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
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 |
+-------------+
| FDDI PHY |
+-------------+
| 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
Packet
IP datagrams and ARP requests and replies sent on FDDI networks
be encapsulated within the 802.2 LLC and Sub-Network Access
(SNAP) data link layers and the FDDI MAC and physical layers.
SNAP must be used with an Organization Code indicating that the
header contains the EtherType code (as listed in Assigned
[12]).
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 [12] (IP = 2048, ARP = 2054).
Katz [Page 2]
RFC 1103 IP Datagrams over FDDI Networks June 1989
...--------+--------+--------+
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 16-bit or 48-bit
addresses must be done via the dynamic discovery procedure of
Address 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
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 [12].
FDDI networks, although not IEEE 802 networks per se,
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
48-bit FDDI addresses
The protocol address length (for IP) is 4.
The operation code is 1 for request and 2 for reply
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 [13]).
Trailer
Some versions of Unix 4.x bsd use a different encapsulation method
order to get better network performance with the VAX virtual
architecture. Consenting systems on the same FDDI network may
this format between themselves. Details of the trailer
method may be found in [14]. However, all hosts must be able
communicate using the standard (non-trailer) method
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" [15].
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 gives the following
layer overhead
Katz [Page 4]
RFC 1103 IP Datagrams over FDDI Networks June 1989
Field Size in
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
packet size (MTU) of 4470 (4478) octets. For
purposes, the maximum packet size used with IP datagrams or
requests and replies must be consistent on a particular network
The overhead calculations (above) assume a standard Frame
field consisting of three symbols. Additional Implementor
frame status information, although permitted by the FDDI
specification, must not be used with IP datagrams because
affects the maximum packet size
Gateway implementations must be prepared to accept full-
packets and fragment them when necessary
Host implementations should be prepared to accept full-
packets; however, hosts must not send datagrams longer than 576
octets unless they have explicit knowledge that the destination
prepared to accept them. A host may communicate its
preference in TCP-based applications via the TCP Maximum
Size option [16].
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 [16]
further information
There is no minimum packet size restriction on FDDI networks
Other MAC Layer
The FDDI MAC specification does not require that 16-bit and 48-
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
both types of stations be able to receive frames sent to either
broadcast address. For use with IP and ARP, all
stations on a LAN must use a consistent address size
Implementations must discard any IP or ARP packets received with
unimplemented or inactive address size. 16-bit and 48-
implementations may coexist on the same FDDI network; however,
they wish to interwork they must be considered separate IP
and linked with an IP router capable of supporting 16-and 48-
addresses simultaneously
Group (multicast) addresses are defined by the FDDI MAC
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
controlled by a priority mechanism and two classes of token
Restricted and Unrestricted. Only the use of Unrestricted tokens
Asynchronous frames are required by the standard for
interoperability. The priority mechanism is currently
locally by the transmitting station and the Priority field
Asynchronous frames is ignored by other stations. This field
likely be interpreted by Transparent Bridges once they are defined
There is no default value for priority called out in the
standard
Therefore, all IP and ARP frames must be transmitted as
frames using Unrestricted tokens, and the Priority value is a
of local convention. Implementations should make the priority
tunable parameter for future use. It is recommended
implementations provide for the reception of IP and ARP packets
Synchronous frames
After packet transmission, FDDI provides Frame Copied (C) and
Recognized (A) indicators. There are four possible combinations
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
error detection and correction
If the Frame Copied bit is reset but the Address Recognized bit
Katz [Page 6]
RFC 1103 IP Datagrams over FDDI Networks June 1989
set, receiver congestion has occurred. It is recommended,
not mandatory, that hosts retransmit the offending packet a
number of times (4) or until congestion no longer occurs
If the both the Address Recognized indicator and the Frame
indicator are reset, an implementation has three options: (1)
ignore the error and throw the packet away, (2) return an
destination unreachable message to the source, or (3) delete
ARP entry which was used to send this packet and send a new
request to the destination address. The latter option is
preferred approach since it will allow graceful recovery
first hop bridge and router failures and changed
addresses
As of this writing there is a proposal within ANSI to set
Frame Copied indicator and reset the Address Recognized
when a frame is forwarded by a Transparent Bridge. For
compatibility, implementations should interpret this
of indicators as if the frame were successfully delivered to
destination (i.e., do nothing).
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. This requires supporting
Information (UI) Commands, eXchange IDentification (XID) Commands
Responses, and TEST link (TEST) Commands and Responses
When an XID or TEST command is received, a response must be
with Destination and Source addresses, and DSAP and SSAP, swapped
When responding to an XID or a TEST command, the value of the
bit in the response must be copied from the value of the Poll bit
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
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
Poll/Final bit is on
Command frames are identified by having the high order bit of
SSAP address reset to zero. Response frames have the high order
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
129.1.0 indicating Class I (connectionless) service
TEST response frames must echo the information field received in
corresponding TEST command frame
Appendix on
The IEEE specifies numbers in bit transmission order, or bit-
little-endian order. The Internet protocols are documented in byte
wise big-endian order. This may cause some confusion about
proper values to use for numbers. Here are the conversions for
numbers of interest
Number IEEE IEEE Internet
HEX Binary Binary
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
[1] Postel, J., "Internet Protocol", 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.
[3] Postel J., and J. Reynolds, "A Standard for the Transmission
IP Datagrams over IEEE 802 Networks", RFC1042, USC/
Sciences Institute, February, 1988.
[4] ISO, "Fiber Distributed Data Interface (FDDI) - Media
Control", ISO 9314-2, 1988. See also ANSI X3.139-1987.
[5] ISO, "Fiber Distributed Data Interface (FDDI) - Token
Physical Layer Protocol", ISO 9314-1, 1988. See also
X3.148-1988.
[6] ISO, "Fiber Distributed Data Interface (FDDI) - Physical
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
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] 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
Topics", RFC-879, USC/Information Sciences Institute,
1983.
Author's
Dave Katz Merit/NSFNET 1075 Beal Ann Arbor, MI 48109-2112
Phone: 1-800-66-
Email: Dave_Katz@um.cc.umich.
Katz [Page 9]
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
