rfc1103.txt
来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 507 行 · 第 1/2 页
TXT
507 行
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 isKatz [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.0References [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.eduKatz [Page 9]
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?