分享
 
 
 

RFC1390 - Transmission of IP and ARP over FDDI Networks

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

Network Working Group D. Katz

Request for Comments: 1390 cisco Systems, Inc.

STD: 36 January 1993

Transmission of IP and ARP over FDDI Networks

Status of this Memo

This RFCspecifies an IAB standards track protocol 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.

Distribution of this memo is unlimited.

Abstract

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 RFCis the prodUCt of the IP over FDDI Working Group of the

Internet Engineering Task Force (IETF).

Acknowledgments

This memo draws heavily in both concept and text from RFC1042 [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.

"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.

It is the eXPlicit intent of this memo to allow the interoperability

of IP and ARP between stations on FDDI networks and stations on

Ethernet networks via translational bridges.

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.

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

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. ARP packets shall be accepted if received with a hardware

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 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

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 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 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

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].

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 [17] for

further information.

There is no minimum packet size restriction on FDDI networks.

In order to not preclude interoperability with Ethernet in a

bridged environment, FDDI implementations must be prepared to

receive (and ignore) trailing pad octets.

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, 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. In order to avoid

interoperability problems, only 48-bit addresses shall be used

with IP and ARP.

The FDDI MAC specification defines two classes of LLC 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.

All IP and ARP frames shall be transmitted as Asynchronous LLC

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, as well as Restricted Asynchronous

frames.

After packet transmission, FDDI provides Frame Copied (C) and

Address Recognized (A) indicators. The use of these indicators is

a local implementation decision. Implementations may choose to

perform link-level retransmission, ARP cache entry invalidation,

etc., based on the values of these indicators and other

information. The semantics of these indicators, especially in the

presence of bridges, are not well defined as of this writing.

Implementors are urged to follow the work of ANSI ASC X3T9.5 in

regard to this issue in order to avoid interoperability problems.

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. Described below is the minimum functionality

necessary for a conformant station. Some of the functions are not

related directly to the support of the SNAP SAP (e.g., responding to

XID and TEST commands directed to the null or global SAP addresses),

but are part of a general LLC implementation. Implementors should

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, and

TEST link (TEST) Commands and Responses. Stations need not be able

to transmit XID and TEST commands, but must be able to transmit

responses.

Encodings

Command frames are identified by having the low order bit of the

SSAP address reset to zero. Response frames have the low order

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 the

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 the

Poll/Final bit is on.

Elements of Procedure

UI responses and UI commands with the Poll bit set shall be

ignored. UI commands having other than the SNAP SAP in the DSAP

or SSAP fields shall not be processed as IP or ARP packets.

When an XID or TEST command is received, an appropriate response

must be returned. XID and TEST commands must be responded to only

if the DSAP is the SNAP SAP (170 decimal), the Null SAP (0

decimal), or the Global SAP (255 decimal). XID and TEST commands

received with other DSAP values must not be responded to unless

the station supports the addressed service. Responses to XID and

TEST frames shall be constructed as follows:

Destination MAC: Copied from Source MAC of the command

Source MAC: Set to the address of the MAC receiving the

command

DSAP: Copied from SSAP of the command

SSAP: Set to 171 decimal (SNAP SAP + Response bit) if the

DSAP in the command was the SNAP SAP or the Global SAP;

set to 1 decimal (Null SAP + Response bit) if the DSAP

in the command was the Null SAP

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.

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 as bit strings with the least significant

bit first, or bit-wise little-endian order. The Internet protocols

are documented in bit-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 Internet Internet

Binary Binary Decimal

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 RFC1188

The following is a summary of the differences between RFC1188 and

this document:

A reference to a future dual-MAC document has been removed.

A statement of explicit intent to support FDDI/Ethernet

interoperability has been added.

The acceptance of ARP frames bearing hardware type code 6 (IEEE

802) has been removed.

The references have been updated.

The author's address has been updated.

References

[1] Postel, J., "Internet Protocol", STD 5, RFC791, 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", RFC826, 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, 1989. See also ANSI X3.139-1987.

[5] ISO, "Fiber Distributed Data Interface (FDDI) - Token Ring

Physical Layer Protocol", ISO 9314-1, 1989. See also ANSI

X3.148-1988.

[6] ISO, "Fiber Distributed Data Interface (FDDI) - Physical Layer

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 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] IEEE, "Draft Standard P802.1A--Overview and Architecture", 1989.

[13] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC1340,

USC/Information Sciences Institute, July 1992.

[14] Braden, R., and J. Postel, "Requirements for Internet Gateways",

STD 4, RFC1009, USC/Information Sciences Institute, June 1987.

[15] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC

1112, Stanford University, August 1989.

[16] Cohen, D., "On Holy Wars and a Plea for Peace", Computer, IEEE,

October 1981.

[17] Postel, J., "The TCP Maximum Segment Size Option and Related

Topics", RFC879, USC/Information Sciences Institute, November

1983.

Security Considerations

Security issues are not discussed in this memo.

Author's Address

Dave Katz

cisco Systems, Inc.

1525 O'Brien Dr.

Menlo Park, CA 94025

Phone: (415) 688-8284

EMail: dkatz@cisco.com

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有