Network Working Group C. Brown
Request for Comments: 2427 Consultant
STD: 55 A. Malis
Obsoletes: 1490, 1294 Ascend Communications, Inc.
Category: Standards Track September 1998
Network Working Group C. Brown
Request for Comments: 2427 Consultant
STD: 55 A. Malis
Obsoletes: 1490, 1294 Ascend Communications, Inc.
Category: Standards Track September 1998
Multiprotocol Interconnect over Frame Relay
帧中继上的多协议互连
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Abstract
摘要
This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone. It covers aspects of both Bridging and Routing.
本备忘录描述了一种封装方法，用于在帧中继主干上承载网络互连流量。它涵盖桥接和路由的两个方面。
Systems with the ability to transfer both the encapsulation method described in this document, and others must have a priori knowledge of which virtual circuits will carry which encapsulation method and this encapsulation must only be used over virtual circuits that have been explicitly configured for its use.
能够传输本文档中描述的封装方法的系统和其他系统必须事先知道哪些虚拟电路将携带哪些封装方法，并且该封装只能在已明确配置为使用的虚拟电路上使用。
Acknowledgments
致谢
This document could not have been completed without the support of Terry Bradley of Avici Systems, Inc.. Comments and contributions from many sources, especially those from Ray Samora of Proteon, Ken Rehbehn of Visual Networks, Fred Baker and Charles Carvalho of Cisco Systems, and Mostafa Sherif of AT&T have been incorporated into this document. Special thanks to Dory Leifer of University of Michigan for his contributions to the resolution of fragmentation issues (though it was deleted in the final version) and Floyd Backes and Laura Bridge of 3Com for their contributions to the bridging descriptions. This document could not have been completed without the expertise of the IP over Large Public Data Networks and the IP over NBMA working groups of the IETF.
没有Avici Systems，Inc.的Terry Bradley的支持，本文件无法完成。。来自多个来源的评论和贡献，特别是来自Proteon的Ray Samora、Visual Networks的Ken Rehbehn、Cisco Systems的Fred Baker和Charles Carvalho以及AT&T的Mostafa Sherif的评论和贡献已纳入本文件。特别感谢密歇根大学的Dory Leifer为解决碎片问题的贡献（虽然它在最终版本中被删除）和Floyd Backes和劳拉的3COM桥为他们对桥接描述的贡献。如果没有大型公共数据网络IP和IETF的NBMA工作组IP的专业知识，本文件不可能完成。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [16].
本文件中出现的关键词必须、不得、必需、应、不应、应、不应、建议、可和可选时，应按照[16]中的说明进行解释。
All drawings in this document are drawn with the left-most bit as the high order bit for transmission. For example, the drawings might be labeled as:
本文件中的所有图纸均以最左边的位作为传输的高位绘制。例如，图形可能标记为：
0 1 2 3 4 5 6 7 bits
+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 bits
+---+---+---+---+---+---+---+
+---------------------------+
| flag (7E hexadecimal) |
+---------------------------+
| Q.922 Address* |
+-- --+
| |
+---------------------------+
: :
: :
+---------------------------+
+---------------------------+
| flag (7E hexadecimal) |
+---------------------------+
| Q.922 Address* |
+-- --+
| |
+---------------------------+
: :
: :
+---------------------------+
Drawings that would be too large to fit onto one page if each octet were presented on a single line are drawn with two octets per line. These are also drawn with the left-most bit as the high order bit for transmission. There will be a "+" to distinguish between octets as in the following example.
如果在一行上显示每个八位字节，则太大而无法放在一页上的图形将以每行两个八位字节绘制。这些也用最左边的位作为传输的高阶位绘制。将有一个“+”来区分八位字节，如下例所示。
|--- octet one ---|--- octet two ---|
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|--- octet one ---|--- octet two ---|
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--------------------------------------------+
| Organizationally Unique |
+-- +--------------------+
| Identifier | Protocol |
+-----------------------+--------------------+
| Identifier |
+-----------------------+
+--------------------------------------------+
| Organizationally Unique |
+-- +--------------------+
| Identifier | Protocol |
+-----------------------+--------------------+
| Identifier |
+-----------------------+
The following are common acronyms used throughout this document.
以下是本文件中常用的首字母缩略词。
BECN - Backward Explicit Congestion Notification
BPDU - Bridge Protocol Data Unit
C/R - Command/Response bit
DCE - Data Communication Equipment
BECN - Backward Explicit Congestion Notification
BPDU - Bridge Protocol Data Unit
C/R - Command/Response bit
DCE - Data Communication Equipment
DE - Discard Eligibility bit DTE - Data Terminal Equipment FECN - Forward Explicit Congestion Notification PDU - Protocol Data Unit PTT - Postal Telephone & Telegraph SNAP - Subnetwork Access Protocol
反丢弃合格位DTE-数据终端设备FECN-转发显式拥塞通知PDU-协议数据单元PTT-邮政电话和电报SNAP-子网访问协议
The following discussion applies to those devices which serve as end stations (DTEs) on a public or private Frame Relay network (for example, provided by a common carrier or PTT. It will not discuss the behavior of those stations that are considered a part of the Frame Relay network (DCEs) other than to explain situations in which the DTE must react.
以下讨论适用于在公共或专用帧中继网络（例如，由公共载波或PTT提供）上充当终端站（DTE）的那些设备。它将不讨论被视为帧中继网络（DCE）一部分的那些站的行为而不是解释DTE必须作出反应的情况。
The Frame Relay network provides a number of virtual circuits that form the basis for connections between stations attached to the same Frame Relay network. The resulting set of interconnected devices forms a private Frame Relay group which may be either fully interconnected with a complete "mesh" of virtual circuits, or only partially interconnected. In either case, each virtual circuit is uniquely identified at each Frame Relay interface by a Data Link Connection Identifier (DLCI). In most circumstances, DLCIs have strictly local significance at each Frame Relay interface.
帧中继网络提供许多虚拟电路，这些电路构成连接到同一帧中继网络的站点之间连接的基础。由此产生的互连设备集形成专用帧中继组，该组可以与虚拟电路的完整“网格”完全互连，也可以仅部分互连。在这两种情况下，每个虚拟电路在每个帧中继接口处由数据链路连接标识符（DLCI）唯一标识。在大多数情况下，DLCI在每个帧中继接口处具有严格的局部意义。
The specifications in this document are intended to apply to both switched and permanent virtual circuits.
本文件中的规范适用于交换虚拟电路和永久虚拟电路。
All protocols must encapsulate their packets within a Q.922 Annex A frame [1]. Additionally, frames shall contain information necessary to identify the protocol carried within the protocol data unit (PDU), thus allowing the receiver to properly process the incoming packet. The format shall be as follows:
所有协议必须将其数据包封装在Q.922附录a帧[1]中。此外，帧应包含识别协议数据单元（PDU）内承载的协议所需的信息，从而允许接收器正确处理传入数据包。格式如下：
+---------------------------+
| flag (7E hexadecimal) |
+---------------------------+
| Q.922 Address* |
+-- --+
| |
+---------------------------+
| Control (UI = 0x03) |
+---------------------------+
| Pad (when required) (0x00)|
+---------------------------+
| NLPID |
+---------------------------+
| . |
| . |
| . |
| Data |
| . |
| . |
+---------------------------+
| Frame Check Sequence |
+-- . --+
| (two octets) |
+---------------------------+
| flag (7E hexadecimal) |
+---------------------------+
+---------------------------+
| flag (7E hexadecimal) |
+---------------------------+
| Q.922 Address* |
+-- --+
| |
+---------------------------+
| Control (UI = 0x03) |
+---------------------------+
| Pad (when required) (0x00)|
+---------------------------+
| NLPID |
+---------------------------+
| . |
| . |
| . |
| Data |
| . |
| . |
+---------------------------+
| Frame Check Sequence |
+-- . --+
| (two octets) |
+---------------------------+
| flag (7E hexadecimal) |
+---------------------------+
* Q.922 addresses, as presently defined, are two octets and contain a 10-bit DLCI. In some networks Q.922 addresses may optionally be increased to three or four octets.
* 目前定义的Q.922地址是两个八位字节，包含一个10位DLCI。在一些网络中，Q.922地址可以选择性地增加到三个或四个八位字节。
The control field is the Q.922 control field. The UI (0x03) value is used unless it is negotiated otherwise. The use of XID (0xAF or 0xBF) is permitted and is discussed later.
控制字段为Q.922控制字段。除非另行协商，否则将使用UI（0x03）值。允许使用XID（0xAF或0xBF），稍后讨论。
The pad field is used to align the data portion (beyond the encapsulation header) of the frame to a two octet boundary. If present, the pad is a single octet and must have a value of zero. Explicit directions of when to use the pad field are discussed later in this document.
pad字段用于将帧的数据部分（封装头之外）与两个八位字节边界对齐。如果存在，则pad是一个八位字节，并且必须具有零值。本文档后面将讨论何时使用pad字段的明确说明。
The Network Level Protocol ID (NLPID) field is administered by ISO and the ITU. It contains values for many different protocols including IP, CLNP, and IEEE Subnetwork Access Protocol (SNAP)[10]. This field tells the receiver what encapsulation or what protocol follows. Values for this field are defined in ISO/IEC TR 9577 [3]. A NLPID value of 0x00 is defined within ISO/IEC TR 9577 as the Null Network Layer or Inactive Set. Since it cannot be distinguished from
网络级协议ID（NLPID）字段由ISO和ITU管理。它包含许多不同协议的值，包括IP、CLNP和IEEE子网访问协议（SNAP）[10]。此字段告诉接收器遵循什么封装或什么协议。该字段的值在ISO/IEC TR 9577[3]中定义。NLPID值0x00在ISO/IEC TR 9577中定义为空网络层或非活动集。因为它与
a pad field, and because it has no significance within the context of this encapsulation scheme, a NLPID value of 0x00 is invalid under the Frame Relay encapsulation. Appendix A contains a list of some of the more commonly used NLPID values.
pad字段，并且由于它在该封装方案的上下文中没有意义，因此在帧中继封装下，NLPID值0x00无效。附录A列出了一些更常用的NLPID值。
There is no commonly implemented minimum maximum frame size for Frame Relay. A network must, however, support at least a 262 octet maximum. Generally, the maximum will be greater than or equal to 1600 octets, but each Frame Relay provider will specify an appropriate value for its network. A Frame Relay DTE, therefore, must allow the maximum acceptable frame size to be configurable.
对于帧中继，没有通常实现的最小最大帧大小。然而，网络必须至少支持262个八位字节的最大值。通常，最大值将大于或等于1600个八位字节，但每个帧中继提供程序将为其网络指定适当的值。因此，帧中继DTE必须允许可配置的最大可接受帧大小。
The minimum frame size allowed for Frame Relay is five octets between the opening and closing flags assuming a two octet Q.922 address field. This minimum increases to six octets for three octet Q.922 address and seven octets for the four octet Q.922 address format.
帧中继允许的最小帧大小为打开和关闭标志之间的五个八位字节，假设为两个八位字节的Q.922地址字段。对于三个八位字节Q.922地址，最小值增加到六个八位字节；对于四个八位字节Q.922地址格式，最小值增加到七个八位字节。
There are two basic types of data packets that travel within the Frame Relay network: routed packets and bridged packets. These packets have distinct formats and therefore, must contain an indicator that the destination may use to correctly interpret the contents of the frame. This indicator is embedded within the NLPID and SNAP header information.
在帧中继网络中传输的数据包有两种基本类型：路由数据包和桥接数据包。这些数据包具有不同的格式，因此必须包含目的地可用于正确解释帧内容的指示符。此指示器嵌入在NLPID和快照标头信息中。
For those protocols that do not have a NLPID already assigned, it is necessary to provide a mechanism to allow easy protocol identification. There is a NLPID value defined indicating the presence of a SNAP header.
对于那些尚未分配NLPID的协议，有必要提供一种机制，以便轻松识别协议。定义了一个NLPID值，指示是否存在快照标头。
A SNAP header is of the form:
捕捉头的形式如下：
+--------------------------------------------+
| Organizationally Unique |
+-- +--------------------+
| Identifier | Protocol |
+-----------------------+--------------------+
| Identifier |
+-----------------------+
+--------------------------------------------+
| Organizationally Unique |
+-- +--------------------+
| Identifier | Protocol |
+-----------------------+--------------------+
| Identifier |
+-----------------------+
The three-octet Organizationally Unique Identifier (OUI) identifies an organization which administers the meaning of the Protocol Identifier (PID) which follows. Together they identify a distinct protocol. Note that OUI 0x00-00-00 specifies that the following PID is an Ethertype.
三个八位组的组织唯一标识符（OUI）标识管理以下协议标识符（PID）含义的组织。它们共同确定了一个不同的协议。注意，OUI 0x00-00-00指定以下PID为以太网类型。
Some protocols will have an assigned NLPID, but because the NLPID numbering space is limited, not all protocols have specific NLPID values assigned to them. When packets of such protocols are routed over Frame Relay networks, they are sent using the NLPID 0x80 (which indicates the presence of a SNAP header) followed by SNAP. If the protocol has an Ethertype assigned, the OUI is 0x00-00-00 (which indicates an Ethertype follows), and PID is the Ethertype of the protocol in use.
某些协议将具有指定的NLPID，但由于NLPID编号空间有限，并非所有协议都具有指定给它们的特定NLPID值。当通过帧中继网络路由此类协议的数据包时，它们将使用NLPID 0x80（表示存在SNAP头）和SNAP发送。如果协议分配了Ethertype，则OUI为0x00-00-00（表示随后有一个Ethertype），PID为正在使用的协议的Ethertype。
When a SNAP header is present as described above, a one octet pad is used to align the protocol data on a two octet boundary as shown below.
当如上所述存在快照头时，使用一个八位字节焊盘将协议数据对准两个八位字节边界，如下所示。
Format of Routed Frames
with a SNAP Header
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | pad 0x00 |
+---------------+---------------+
| NLPID 0x80 | Organization- |
+---------------+ |
| ally Unique Identifier (OUI) |
+-------------------------------+
| Protocol Identifier (PID) |
+-------------------------------+
| |
| Protocol Data |
| |
+-------------------------------+
| FCS |
+-------------------------------+
Format of Routed Frames
with a SNAP Header
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | pad 0x00 |
+---------------+---------------+
| NLPID 0x80 | Organization- |
+---------------+ |
| ally Unique Identifier (OUI) |
+-------------------------------+
| Protocol Identifier (PID) |
+-------------------------------+
| |
| Protocol Data |
| |
+-------------------------------+
| FCS |
+-------------------------------+
In the few cases when a protocol has an assigned NLPID (see Appendix A), 48 bits can be saved using the format below:
在协议具有指定NLPID的少数情况下（见附录a），可以使用以下格式保存48位：
Format of Routed NLPID Protocol
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | NLPID |
+---------------+---------------+
| Protocol Data |
+-------------------------------+
| FCS |
+-------------------------------+
Format of Routed NLPID Protocol
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | NLPID |
+---------------+---------------+
| Protocol Data |
+-------------------------------+
| FCS |
+-------------------------------+
When using the NLPID encapsulation format as described above, the pad octet is not used.
如上所述使用NLPID封装格式时，不使用pad八位字节。
In the case of ISO protocols, the NLPID is considered to be the first octet of the protocol data. It is unnecessary to repeat the NLPID in this case. The single octet serves both as the demultiplexing value and as part of the protocol data (refer to "Other Protocols over Frame Relay for more details). Other protocols, such as IP, have a NLPID defined (0xCC), but it is not part of the protocol itself.
在ISO协议的情况下，NLPID被认为是协议数据的第一个八位组。在这种情况下，无需重复NLPID。单个八位字节用作解复用值和协议数据的一部分（有关更多详细信息，请参阅“帧中继上的其他协议”）。其他协议（如IP）定义了NLPID（0xCC），但它不是协议本身的一部分。
Format of Routed IP Datagram
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | NLPID 0xCC |
+---------------+---------------+
| IP Datagram |
+-------------------------------+
| FCS |
+-------------------------------+
Format of Routed IP Datagram
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | NLPID 0xCC |
+---------------+---------------+
| IP Datagram |
+-------------------------------+
| FCS |
+-------------------------------+
The second type of Frame Relay traffic is bridged packets. These packets are encapsulated using the NLPID value of 0x80 indicating SNAP. As with other SNAP encapsulated protocols, there will be one pad octet to align the data portion of the encapsulated frame. The SNAP header which follows the NLPID identifies the format of the bridged packet. The OUI value used for this encapsulation is the 802.1 organization code 0x00-80-C2. The PID portion of the SNAP header (the two bytes immediately following the OUI) specifies the form of the MAC header, which immediately follows the SNAP header. Additionally, the PID indicates whether the original FCS is preserved within the bridged frame.
第二类帧中继业务是桥接数据包。这些数据包使用表示SNAP的NLPID值0x80进行封装。与其他SNAP封装协议一样，将有一个pad八位字节来对齐封装帧的数据部分。NLPID后面的SNAP报头标识桥接数据包的格式。用于此封装的OUI值是802.1组织代码0x00-80-C2。SNAP报头的PID部分（紧跟在OUI之后的两个字节）指定紧跟SNAP报头的MAC报头的形式。此外，PID指示原始FCS是否保留在桥接帧内。
Following the precedent in RFC 1638 [4], non-canonical MAC destination addresses are used for encapsulated IEEE 802.5 and FDDI frames, and canonical MAC destination addresses are used for the remaining encapsulations defined in this section.
遵循RFC 1638[4]中的先例，非规范MAC目的地地址用于封装的IEEE 802.5和FDDI帧，规范MAC目的地地址用于本节中定义的其余封装。
The 802.1 organization has reserved the following values to be used with Frame Relay:
802.1组织已保留以下值，以便与帧中继一起使用：
PID Values for OUI 0x00-80-C2
OUI 0x00-80-C2的PID值
with preserved FCS w/o preserved FCS Media
------------------ ----------------- ----------------
0x00-01 0x00-07 802.3/Ethernet
0x00-02 0x00-08 802.4
0x00-03 0x00-09 802.5
0x00-04 0x00-0A FDDI
0x00-0B 802.6
with preserved FCS w/o preserved FCS Media
------------------ ----------------- ----------------
0x00-01 0x00-07 802.3/Ethernet
0x00-02 0x00-08 802.4
0x00-03 0x00-09 802.5
0x00-04 0x00-0A FDDI
0x00-0B 802.6
In addition, the PID value 0x00-0E, when used with OUI 0x00-80-C2, identifies Bridge Protocol Data Units (BPDUs) as defined by 802.1(d) or 802.1(g) [12], and the PID value 0x00-0F identifies Source Routing BPDUs.
此外，当与OUI 0x00-80-C2一起使用时，PID值0x00-0E标识802.1（d）或802.1（g）[12]定义的网桥协议数据单元（BPDU），PID值0x00-0F标识源路由BPDU。
A packet bridged over Frame Relay will, therefore, have one of the following formats:
因此，通过帧中继桥接的数据包将具有以下格式之一：
Format of Bridged Ethernet/802.3 Frame
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | pad 0x00 |
+---------------+---------------+
| NLPID 0x80 | OUI 0x00 |
+---------------+ --+
| OUI 0x80-C2 |
+-------------------------------+
| PID 0x00-01 or 0x00-07 |
+-------------------------------+
| MAC destination address |
: :
| |
+-------------------------------+
| (remainder of MAC frame) |
+-------------------------------+
| LAN FCS (if PID is 0x00-01) |
+-------------------------------+
| FCS |
+-------------------------------+
Format of Bridged Ethernet/802.3 Frame
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | pad 0x00 |
+---------------+---------------+
| NLPID 0x80 | OUI 0x00 |
+---------------+ --+
| OUI 0x80-C2 |
+-------------------------------+
| PID 0x00-01 or 0x00-07 |
+-------------------------------+
| MAC destination address |
: :
| |
+-------------------------------+
| (remainder of MAC frame) |
+-------------------------------+
| LAN FCS (if PID is 0x00-01) |
+-------------------------------+
| FCS |
+-------------------------------+
Format of Bridged 802.4 Frame
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | pad 0x00 |
+---------------+---------------+
| NLPID 0x80 | OUI 0x00 |
+---------------+ --+
| OUI 0x80-C2 |
+-------------------------------+
| PID 0x00-02 or 0x00-08 |
+---------------+---------------+
| pad 0x00 | Frame Control |
+---------------+---------------+
| MAC destination address |
: :
| |
+-------------------------------+
| (remainder of MAC frame) |
+-------------------------------+
| LAN FCS (if PID is 0x00-02) |
+-------------------------------+
| FCS |
+-------------------------------+
Format of Bridged 802.4 Frame
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | pad 0x00 |
+---------------+---------------+
| NLPID 0x80 | OUI 0x00 |
+---------------+ --+
| OUI 0x80-C2 |
+-------------------------------+
| PID 0x00-02 or 0x00-08 |
+---------------+---------------+
| pad 0x00 | Frame Control |
+---------------+---------------+
| MAC destination address |
: :
| |
+-------------------------------+
| (remainder of MAC frame) |
+-------------------------------+
| LAN FCS (if PID is 0x00-02) |
+-------------------------------+
| FCS |
+-------------------------------+
Format of Bridged 802.5 Frame
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | pad 0x00 |
+---------------+---------------+
| NLPID 0x80 | OUI 0x00 |
+---------------+ --+
| OUI 0x80-C2 |
+-------------------------------+
| PID 0x00-03 or 0x00-09 |
+---------------+---------------+
| pad 0x00 | Frame Control |
+---------------+---------------+
| MAC destination address |
: :
| |
+-------------------------------+
| (remainder of MAC frame) |
+-------------------------------+
| LAN FCS (if PID is 0x00-03) |
| |
+-------------------------------+
| FCS |
+-------------------------------+
Format of Bridged 802.5 Frame
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | pad 0x00 |
+---------------+---------------+
| NLPID 0x80 | OUI 0x00 |
+---------------+ --+
| OUI 0x80-C2 |
+-------------------------------+
| PID 0x00-03 or 0x00-09 |
+---------------+---------------+
| pad 0x00 | Frame Control |
+---------------+---------------+
| MAC destination address |
: :
| |
+-------------------------------+
| (remainder of MAC frame) |
+-------------------------------+
| LAN FCS (if PID is 0x00-03) |
| |
+-------------------------------+
| FCS |
+-------------------------------+
Format of Bridged FDDI Frame
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | pad 0x00 |
+---------------+---------------+
| NLPID 0x80 | OUI 0x00 |
+---------------+ --+
| OUI 0x80-C2 |
+-------------------------------+
| PID 0x00-04 or 0x00-0A |
+---------------+---------------+
| pad 0x00 | Frame Control |
+---------------+---------------+
| MAC destination address |
: :
| |
+-------------------------------+
| (remainder of MAC frame) |
+-------------------------------+
| LAN FCS (if PID is 0x00-04) |
| |
+-------------------------------+
| FCS |
+-------------------------------+
Format of Bridged FDDI Frame
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | pad 0x00 |
+---------------+---------------+
| NLPID 0x80 | OUI 0x00 |
+---------------+ --+
| OUI 0x80-C2 |
+-------------------------------+
| PID 0x00-04 or 0x00-0A |
+---------------+---------------+
| pad 0x00 | Frame Control |
+---------------+---------------+
| MAC destination address |
: :
| |
+-------------------------------+
| (remainder of MAC frame) |
+-------------------------------+
| LAN FCS (if PID is 0x00-04) |
| |
+-------------------------------+
| FCS |
+-------------------------------+
Format of Bridged 802.6 Frame
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | pad 0x00 |
+---------------+---------------+
| NLPID 0x80 | OUI 0x00 |
+---------------+ --+
| OUI 0x80-C2 |
+-------------------------------+
| PID 0x00-0B |
+---------------+---------------+ -------
| Reserved | BEtag | Common
+---------------+---------------+ PDU
| BAsize | Header
+-------------------------------+ -------
| MAC destination address |
: :
| |
+-------------------------------+
| (remainder of MAC frame) |
+-------------------------------+
| |
+- Common PDU Trailer -+
| |
+-------------------------------+
| FCS |
+-------------------------------+
Format of Bridged 802.6 Frame
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | pad 0x00 |
+---------------+---------------+
| NLPID 0x80 | OUI 0x00 |
+---------------+ --+
| OUI 0x80-C2 |
+-------------------------------+
| PID 0x00-0B |
+---------------+---------------+ -------
| Reserved | BEtag | Common
+---------------+---------------+ PDU
| BAsize | Header
+-------------------------------+ -------
| MAC destination address |
: :
| |
+-------------------------------+
| (remainder of MAC frame) |
+-------------------------------+
| |
+- Common PDU Trailer -+
| |
+-------------------------------+
| FCS |
+-------------------------------+
Note that in bridge 802.6 PDUs, there is only one choice for the PID value, since the presence of a CRC-32 is indicated by the CIB bit in the header of the MAC frame.
注意，在网桥802.6 pdu中，对于PID值只有一个选择，因为存在CRC-32是由MAC帧的报头中的CIB位指示的。
The Common Protocol Data Unit (CPDU) Header and Trailer are conveyed to allow pipelining at the egress bridge to an 802.6 subnetwork. Specifically, the CPDU Header contains the BAsize field, which contains the length of the PDU. If this field is not available to the egress 802.6 bridge, then that bridge cannot begin to transmit the segmented PDU until it has received the entire PDU, calculated the length, and inserted the length into the BAsize field. If the field is available, the egress 802.6 bridge can extract the length from the BAsize field of the Common PDU Header, insert it into the corresponding field of the first segment, and immediately transmit the segment onto the 802.6 subnetwork. Thus, the bridge can begin transmitting the 802.6 PDU before it has received the complete PDU.
传输公共协议数据单元（CPDU）头和尾，以允许在出口网桥处通过管道连接到802.6子网。具体来说，CPDU头包含BAsize字段，该字段包含PDU的长度。如果该字段对出口802.6网桥不可用，则该网桥在接收到整个PDU、计算长度并将长度插入BAsize字段之前无法开始传输分段PDU。如果该字段可用，出口802.6网桥可以从公共PDU报头的BAsize字段提取长度，将其插入第一段的相应字段，并立即将该段传输到802.6子网。因此，网桥可以在接收到完整的PDU之前开始传输802.6 PDU。
One should note that the Common PDU Header and Trailer of the encapsulated frame should not be simply copied to the outgoing 802.6 subnetwork because the encapsulated BEtag value may conflict with the previous BEtag value transmitted by that bridge.
应注意，封装帧的公共PDU头和尾不应简单地复制到输出802.6子网，因为封装的BEtag值可能与该网桥传输的先前BEtag值冲突。
Format of BPDU Frame
+-------------------------------+
| Q.922 Address |
+-------------------------------+
| Control 0x03 |
+-------------------------------+
| PAD 0x00 |
+-------------------------------+
| NLPID 0x80 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-0E |
+-------------------------------+
| |
| BPDU as defined by |
| 802.1(d) or 802.1(g)[12] |
| |
+-------------------------------+
| FCS |
+-------------------------------+
Format of BPDU Frame
+-------------------------------+
| Q.922 Address |
+-------------------------------+
| Control 0x03 |
+-------------------------------+
| PAD 0x00 |
+-------------------------------+
| NLPID 0x80 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-0E |
+-------------------------------+
| |
| BPDU as defined by |
| 802.1(d) or 802.1(g)[12] |
| |
+-------------------------------+
| FCS |
+-------------------------------+
Format of Source Routing BPDU Frame
+-------------------------------+
| Q.922 Address |
+-------------------------------+
| Control 0x03 |
+-------------------------------+
| PAD 0x00 |
+-------------------------------+
| NLPID 0x80 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-0F |
+-------------------------------+
| |
| Source Routing BPDU |
| |
| |
+-------------------------------+
| FCS |
+-------------------------------+
Format of Source Routing BPDU Frame
+-------------------------------+
| Q.922 Address |
+-------------------------------+
| Control 0x03 |
+-------------------------------+
| PAD 0x00 |
+-------------------------------+
| NLPID 0x80 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-0F |
+-------------------------------+
| |
| Source Routing BPDU |
| |
| |
+-------------------------------+
| FCS |
+-------------------------------+
Frame Relay stations may choose to support the Exchange Identification (XID) specified in Appendix III of Q.922 [1]. This XID exchange allows the following parameters to be negotiated at the initialization of a Frame Relay circuit: maximum frame size N201, retransmission timer T200, and the maximum number of outstanding Information (I) frames K.
帧中继站可选择支持Q.922[1]附录III中规定的交换标识（XID）。该XID交换允许在帧中继电路的初始化时协商以下参数：最大帧大小N201、重传定时器T200和最大未完成信息数（I）帧K。
A station may indicate its unwillingness to support acknowledged mode multiple frame operation by specifying a value of zero for the maximum window size, K.
站点可以通过为最大窗口大小K指定零值来指示其不愿意支持确认模式多帧操作。
If this exchange is not used, these values must be statically configured by mutual agreement of Data Link Connection (DLC) endpoints, or must be defaulted to the values specified in Section 5.9 of Q.922:
如果未使用此交换，则必须通过数据链路连接（DLC）端点的相互协议静态配置这些值，或者必须默认为Q.922第5.9节中规定的值：
N201: 260 octets
N201:260个八位组
K: 3 for a 16 Kbps link, 7 for a 64 Kbps link, 32 for a 384 Kbps link, 40 for a 1.536 Mbps or above link
K:3表示16 Kbps链路，7表示64 Kbps链路，32表示384 Kbps链路，40表示1.536 Mbps或以上链路
T200: 1.5 seconds [see Q.922 for further details]
T200:1.5秒[详见Q.922]
If a station supporting XID receives an XID frame, it shall respond with an XID response. In processing an XID, if the remote maximum frame size is smaller than the local maximum, the local system shall reduce the maximum size it uses over this DLC to the remotely specified value. Note that this shall be done before generating a response XID.
如果支持XID的站点接收到XID帧，则其应以XID响应进行响应。在处理XID时，如果远程最大帧大小小于本地最大帧大小，则本地系统应将其在该DLC上使用的最大大小减小到远程指定的值。注意，这应在生成响应XID之前完成。
The following diagram describes the use of XID to specify non-use of acknowledged mode multiple frame operation.
下图描述了使用XID来指定不使用确认模式多帧操作。
Non-use of Acknowledged Mode Multiple Frame Operation
+---------------+
| Address | (2,3 or 4 octets)
| |
+---------------+
| Control 0xAF |
+---------------+
| format 0x82 |
+---------------+
| Group ID 0x80 |
+---------------+
| Group Length | (2 octets)
| 0x00-0E |
+---------------+
| 0x05 | PI = Frame Size (transmit)
+---------------+
| 0x02 | PL = 2
+---------------+
| Maximum | (2 octets)
| Frame Size |
+---------------+
| 0x06 | PI = Frame Size (receive)
+---------------+
| 0x02 | PL = 2
+---------------+
| Maximum | (2 octets)
| Frame Size |
+---------------+
| 0x07 | PI = Window Size
+---------------+
| 0x01 | PL = 1
+---------------+
| 0x00 |
+---------------+
| 0x09 | PI = Retransmission Timer
+---------------+
| 0x01 | PL = 1
+---------------+
| 0x00 |
+---------------+
| FCS | (2 octets)
| |
+---------------+
Non-use of Acknowledged Mode Multiple Frame Operation
+---------------+
| Address | (2,3 or 4 octets)
| |
+---------------+
| Control 0xAF |
+---------------+
| format 0x82 |
+---------------+
| Group ID 0x80 |
+---------------+
| Group Length | (2 octets)
| 0x00-0E |
+---------------+
| 0x05 | PI = Frame Size (transmit)
+---------------+
| 0x02 | PL = 2
+---------------+
| Maximum | (2 octets)
| Frame Size |
+---------------+
| 0x06 | PI = Frame Size (receive)
+---------------+
| 0x02 | PL = 2
+---------------+
| Maximum | (2 octets)
| Frame Size |
+---------------+
| 0x07 | PI = Window Size
+---------------+
| 0x01 | PL = 1
+---------------+
| 0x00 |
+---------------+
| 0x09 | PI = Retransmission Timer
+---------------+
| 0x01 | PL = 1
+---------------+
| 0x00 |
+---------------+
| FCS | (2 octets)
| |
+---------------+
This document only describes address resolution as it applies to PVCs. SVC operation will be discussed in future documents.
本文档仅描述适用于PVC的地址解析。SVC操作将在未来的文件中讨论。
There are situations in which a Frame Relay station may wish to dynamically resolve a protocol address over PVCs. This may be accomplished using the standard Address Resolution Protocol (ARP) [6] encapsulated within a SNAP encoded Frame Relay packet as follows:
在某些情况下，帧中继站可能希望通过pvc动态解析协议地址。这可以使用封装在SNAP编码帧中继包中的标准地址解析协议（ARP）[6]来实现，如下所示：
+-----------------------+-----------------------+
| Q.922 Address |
+-----------------------+-----------------------+
| Control (UI) 0x03 | pad 0x00 |
+-----------------------+-----------------------+
| NLPID 0x80 | | SNAP Header
+-----------------------+ OUI 0x00-00-00 + Indicating
| | ARP
+-----------------------+-----------------------+
| PID 0x0806 |
+-----------------------+-----------------------+
| ARP packet |
| . |
| . |
| . |
+-----------------------+-----------------------+
+-----------------------+-----------------------+
| Q.922 Address |
+-----------------------+-----------------------+
| Control (UI) 0x03 | pad 0x00 |
+-----------------------+-----------------------+
| NLPID 0x80 | | SNAP Header
+-----------------------+ OUI 0x00-00-00 + Indicating
| | ARP
+-----------------------+-----------------------+
| PID 0x0806 |
+-----------------------+-----------------------+
| ARP packet |
| . |
| . |
| . |
+-----------------------+-----------------------+
Where the ARP packet has the following format and values:
其中，ARP数据包具有以下格式和值：
Data: ar$hrd 16 bits Hardware type ar$pro 16 bits Protocol type ar$hln 8 bits Octet length of hardware address (n) ar$pln 8 bits Octet length of protocol address (m) ar$op 16 bits Operation code (request or reply) ar$sha noctets source hardware address ar$spa moctets source protocol address ar$tha noctets target hardware address ar$tpa moctets target protocol address
数据：ar$hrd 16位硬件类型ar$pro 16位协议类型ar$hln 8位八位字节硬件地址长度（n）ar$pln 8位八位字节协议地址长度（m）ar$op 16位操作代码（请求或回复）ar$sha NOCTES源硬件地址ar$spa MOCTES源协议地址ar$tha NOCTES目标硬件地址ar$tpa MOCTES目标协议地址
ar$hrd - assigned to Frame Relay is 15 decimal (0x000F) [7].
ar$hrd-分配给帧中继的是15位小数（0x000F）[7]。
ar$pro - see assigned numbers for protocol ID number for the protocol using ARP. (IP is 0x0800).
ar$pro-请参阅使用ARP协议的协议ID号的分配号。（IP为0x0800）。
ar$hln - length in bytes of the address field (2, 3, or 4)
ar$hln—地址字段的字节长度（2、3或4）
ar$pln - protocol address length is dependent on the protocol (ar$pro) (for IP ar$pln is 4).
ar$pln-协议地址长度取决于协议（ar$pro）（IP ar$pln为4）。
ar$op - 1 for request and 2 for reply.
ar$op-1用于请求，2用于回复。
ar$sha - Q.922 source hardware address, with C/R, FECN, BECN, and DE set to zero.
ar$sha-Q.922源硬件地址，C/R、FECN、BECN和DE设置为零。
ar$tha - Q.922 target hardware address, with C/R, FECN, BECN, and DE set to zero.
ar$tha-Q.922目标硬件地址，C/R、FECN、BECN和DE设置为零。
Because DLCIs within most Frame Relay networks have only local significance, an end station will not have a specific DLCI assigned to itself. Therefore, such a station does not have an address to put into the ARP request or reply. Fortunately, the Frame Relay network does provide a method for obtaining the correct DLCIs. The solution proposed for the locally addressed Frame Relay network below will work equally well for a network where DLCIs have global significance.
由于大多数帧中继网络中的DLCI仅具有本地意义，因此终端站不会为其自身分配特定的DLCI。因此，这样的站点没有一个地址放入ARP请求或应答中。幸运的是，帧中继网络确实提供了一种获得正确DLCI的方法。下面针对本地寻址帧中继网络提出的解决方案同样适用于DLCI具有全球重要性的网络。
The DLCI carried within the Frame Relay header is modified as it traverses the network. When the packet arrives at its destination, the DLCI has been set to the value that, from the standpoint of the receiving station, corresponds to the sending station. For example, in figure 1 below, if station A were to send a message to station B, it would place DLCI 50 in the Frame Relay header. When station B received this message, however, the DLCI would have been modified by the network and would appear to B as DLCI 70.
帧中继报头中携带的DLCI在穿越网络时被修改。当数据包到达其目的地时，DLCI已被设置为从接收站的角度来看与发送站相对应的值。例如，在下面的图1中，如果站点A向站点B发送消息，它将把DLCI 50放在帧中继报头中。然而，当站点B收到此消息时，DLCI将被网络修改，并在B看来是DLCI 70。
~~~~~~~~~~~~~~~
( )
+-----+ ( ) +-----+
| |-50------(--------------------)---------70-| |
| A | ( ) | B |
| |-60-----(---------+ ) | |
+-----+ ( | ) +-----+
( | )
( | ) <---Frame Relay
~~~~~~~~~~~~~~~~ network
80
|
+-----+
| |
| C |
| |
+-----+
~~~~~~~~~~~~~~~
( )
+-----+ ( ) +-----+
| |-50------(--------------------)---------70-| |
| A | ( ) | B |
| |-60-----(---------+ ) | |
+-----+ ( | ) +-----+
( | )
( | ) <---Frame Relay
~~~~~~~~~~~~~~~~ network
80
|
+-----+
| |
| C |
| |
+-----+
Figure 1
图1
Lines between stations represent data link connections (DLCs). The numbers indicate the local DLCI associated with each connection.
站之间的线表示数据链路连接（DLC）。这些数字表示与每个连接关联的本地DLCI。
DLCI to Q.922 Address Table for Figure 1
图1中Q.922地址表的DLCI
DLCI (decimal) Q.922 address (hex) 50 0x0C21 60 0x0CC1 70 0x1061 80 0x1401
DLCI（十进制）Q.922地址（十六进制）50 0x0C21 60 0x0CC1 70 0x1061 80 0x1401
For authoritative description of the correlation between DLCI and Q.922 [1] addresses, the reader should consult that specification. A summary of the correlation is included here for convenience. The translation between DLCI and Q.922 address is based on a two byte address length using the Q.922 encoding format. The format is:
对于DLCI和Q.922[1]地址之间相关性的权威性描述，读者应参考该规范。为方便起见，此处提供了相关性摘要。DLCI和Q.922地址之间的转换基于使用Q.922编码格式的两字节地址长度。格式为：
8 7 6 5 4 3 2 1
+------------------------+---+--+
| DLCI (high order) |C/R|EA|
+--------------+----+----+---+--+
| DLCI (lower) |FECN|BECN|DE |EA|
+--------------+----+----+---+--+
8 7 6 5 4 3 2 1
+------------------------+---+--+
| DLCI (high order) |C/R|EA|
+--------------+----+----+---+--+
| DLCI (lower) |FECN|BECN|DE |EA|
+--------------+----+----+---+--+
For ARP and its variants, the FECN, BECN, C/R and DE bits are assumed to be 0.
对于ARP及其变体，FECN、BECN、C/R和DE位假定为0。
When an ARP message reaches a destination, all hardware addresses will be invalid. The address found in the frame header will, however, be correct. Though it does violate the purity of layering, Frame Relay may use the address in the header as the sender hardware address. It should also be noted that the target hardware address, in both ARP request and reply, will also be invalid. This should not cause problems since ARP does not rely on these fields and in fact, an implementation may zero fill or ignore the target hardware address field entirely.
当ARP消息到达目的地时，所有硬件地址都将无效。但是，在帧头中找到的地址将是正确的。虽然它确实违反了分层的纯度，但帧中继可能会使用报头中的地址作为发送方硬件地址。还应注意，ARP请求和应答中的目标硬件地址也将无效。这应该不会引起问题，因为ARP不依赖于这些字段，事实上，实现可能会完全零填充或忽略目标硬件地址字段。
As an example of how this address replacement scheme may work, refer to figure 1. If station A (protocol address pA) wished to resolve the address of station B (protocol address pB), it would format an ARP request with the following values:
有关此地址替换方案如何工作的示例，请参阅图1。如果站点A（协议地址pA）希望解析站点B的地址（协议地址pB），它将使用以下值格式化ARP请求：
ARP request from A ar$op 1 (request) ar$sha unknown ar$spa pA ar$tha undefined ar$tpa pB
来自ar的ARP请求$op 1（请求）ar$sha未知ar$spa pA ar$tha未定义ar$tpa pB
Because station A will not have a source address associated with it, the source hardware address field is not valid. Therefore, when the ARP packet is received, it must extract the correct address from the Frame Relay header and place it in the source hardware address field. This way, the ARP request from A will become:
由于站点A没有与其关联的源地址，因此源硬件地址字段无效。因此，当接收到ARP数据包时，它必须从帧中继报头中提取正确的地址，并将其放在源硬件地址字段中。这样，来自A的ARP请求将变成：
ARP request from A as modified by B ar$op 1 (request) ar$sha 0x1061 (DLCI 70) from Frame Relay header ar$spa pA ar$tha undefined ar$tpa pB
来自A的ARP请求，经B ar$op 1（请求）ar$sha 0x1061（DLCI 70）修改，来自帧中继头ar$spa pA ar$tha未定义ar$tpa pB
Station B's ARP will then be able to store station A's protocol address and Q.922 address association correctly. Next, station B will form a reply message. Many implementations simply place the source addresses from the ARP request into the target addresses and then fills in the source addresses with its addresses. In this case, the ARP response would be:
然后，站点B的ARP将能够正确存储站点A的协议地址和Q.922地址关联。接下来，站点B将形成应答消息。许多实现只是将ARP请求中的源地址放入目标地址，然后用其地址填充源地址。在这种情况下，ARP响应将是：
ARP response from B ar$op 2 (response) ar$sha unknown ar$spa pB ar$tha 0x1061 (DLCI 70) ar$tpa pA
来自B ar$op 2（响应）ar$sha未知ar$spa pB ar$tha 0x1061（DLCI 70）ar$tpa pA的ARP响应
Again, the source hardware address is unknown and when the response is received, station A will extract the address from the Frame Relay header and place it in the source hardware address field. Therefore, the response will become:
同样，源硬件地址未知，当接收到响应时，站点A将从帧中继报头提取地址，并将其放入源硬件地址字段。因此，回应将变成：
ARP response from B as modified by A ar$op 2 (response) ar$sha 0x0C21 (DLCI 50) ar$spa pB ar$tha 0x1061 (DLCI 70) ar$tpa pA
由ar$op 2（响应）ar$sha 0x0C21（DLCI 50）ar$spa pB ar$tha 0x1061（DLCI 70）ar$tpa pA修改的来自B的ARP响应
Station A will now correctly recognize station B having protocol address pB associated with Q.922 address 0x0C21 (DLCI 50).
站点A现在将正确识别具有与Q.922地址0x0C21（DLCI 50）关联的协议地址pB的站点B。
Reverse ARP (RARP) [8] works in exactly the same way. Still using figure 1, if we assume station C is an address server, the following RARP exchanges will occur:
反向ARP（RARP）[8]的工作方式完全相同。仍然使用图1，如果我们假设站点C是地址服务器，将发生以下RARP交换：
RARP request from A RARP request as modified by C ar$op 3 (RARP request) ar$op 3 (RARP request) ar$sha unknown ar$sha 0x1401 (DLCI 80) ar$spa undefined ar$spa undefined ar$tha 0x0CC1 (DLCI 60) ar$tha 0x0CC1 (DLCI 60) ar$tpa pC ar$tpa pC
由C ar$op 3（RARP请求）ar$op 3（RARP请求）ar$sha未知ar$sha 0x1401（DLCI 80）ar$spa未定义ar$spa未定义ar$tha 0x0CC1（DLCI 60）ar$tha 0x0CC1（DLCI 60）ar$tpa pC ar$tpa pC修改的RARP请求
Station C will then look up the protocol address corresponding to Q.922 address 0x1401 (DLCI 80) and send the RARP response.
然后，站点C将查找与Q.922地址0x1401（DLCI 80）对应的协议地址，并发送RARP响应。
RARP response from C RARP response as modified by A ar$op 4 (RARP response) ar$op 4 (RARP response) ar$sha unknown ar$sha 0x0CC1 (DLCI 60) ar$spa pC ar$spa pC ar$tha 0x1401 (DLCI 80) ar$tha 0x1401 (DLCI 80) ar$tpa pA ar$tpa pA
由ar$op 4（RARP响应）ar$op 4（RARP响应）ar$sha未知ar$sha 0x0CC1（DLCI 60）ar$spa pC ar$spa pC ar$tha 0x1401（DLCI 80）ar$tha 0x1401（DLCI 80）ar$tpa pA ar$tpa pA修改的C RARP响应
This means that the Frame Relay interface must only intervene in the processing of incoming packets.
这意味着帧中继接口必须只干预传入数据包的处理。
In the absence of suitable multicast, ARP may still be implemented. To do this, the end station simply sends a copy of the ARP request through each relevant DLC, thereby simulating a broadcast.
在缺乏合适的多播的情况下，仍然可以实现ARP。为此，终端站只需通过每个相关的DLC发送ARP请求的副本，从而模拟广播。
The use of multicast addresses in a Frame Relay environment, as specified by [19], is presently being considered by Frame Relay providers. In time, multicast addressing may become useful in sending ARP requests and other "broadcast" messages.
如[19]所述，帧中继提供商目前正在考虑在帧中继环境中使用多播地址。随着时间的推移，多播寻址可能在发送ARP请求和其他“广播”消息时变得有用。
Because of the inefficiencies of emulating broadcasting in a Frame Relay environment, a new address resolution variation was developed. It is called Inverse ARP [11] and describes a method for resolving a protocol address when the hardware address is already known. In Frame Relay's case, the known hardware address is the DLCI. Support for Inverse ARP is not required to implement this specification, but it has proven useful for Frame Relay interface autoconfiguration. See [11] for its description and an example of its use with Frame Relay.
由于在帧中继环境中模拟广播的效率低下，开发了一种新的地址分辨率变体。它被称为反向ARP[11]，描述了在硬件地址已知时解析协议地址的方法。在帧中继的情况下，已知的硬件地址是DLCI。实现此规范不需要对反向ARP的支持，但它已被证明对帧中继接口自动配置非常有用。参见[11]了解其说明及其与帧中继一起使用的示例。
Stations must be able to map more than one IP address in the same IP subnet (CIDR address prefix) to a particular DLCI on a Frame Relay interface. This need arises from applications such as remote access, where servers must act as ARP proxies for many dial-in clients, each assigned a unique IP address while sharing bandwidth on the same DLC. The dynamic nature of such applications result in frequent address association changes with no affect on the DLC's status as reported by Frame Relay PVC Status Signaling.
站点必须能够将同一IP子网（CIDR地址前缀）中的多个IP地址映射到帧中继接口上的特定DLCI。这种需求源于远程访问等应用程序，其中服务器必须充当多个拨入客户端的ARP代理，每个客户端分配一个唯一的IP地址，同时在同一个DLC上共享带宽。这种应用程序的动态特性导致频繁的地址关联更改，而不会影响帧中继PVC状态信令报告的DLC状态。
As with any other interface that utilizes ARP, stations may learn the associations between IP addresses and DLCIs by processing unsolicited ("gratuitous") ARP requests that arrive on the DLC. If one station (perhaps a terminal server or remote access server) wishes to inform its peer station on the other end of a Frame Relay DLC of a new association between an IP address and that PVC, it should send an unsolicited ARP request with the source IP address equal to the destination IP address, and both set to the new IP address being used on the DLC. This allows a station to "announce" new client connections on a particular DLCI. The receiving station must store the new association, and remove any old existing association, if necessary, from any other DLCI on the interface.
与使用ARP的任何其他接口一样，站点可以通过处理到达DLC的未经请求（“无偿”）ARP请求来了解IP地址和DLCI之间的关联。如果一个站点（可能是终端服务器或远程访问服务器）希望将IP地址与该PVC之间的新关联通知帧中继DLC另一端的对等站点，则其应发送源IP地址等于目标IP地址的未经请求的ARP请求，并且都设置为DLC上正在使用的新IP地址。这允许站点“宣布”特定DLCI上的新客户端连接。接收站必须存储新关联，并在必要时从接口上的任何其他DLCI中删除任何旧的现有关联。
Internet Protocol [9] (IP) datagrams sent over a Frame Relay network conform to the encapsulation described previously. Within this context, IP could be encapsulated in two different ways.
通过帧中继网络发送的互联网协议[9]（IP）数据报符合前面描述的封装。在这种情况下，IP可以用两种不同的方式封装。
1. NLPID value indicating IP
1. 指示IP的NLPID值
+-----------------------+-----------------------+
| Q.922 Address |
+-----------------------+-----------------------+
| Control (UI) 0x03 | NLPID 0xCC |
+-----------------------+-----------------------+
| IP packet |
| . |
| . |
| . |
+-----------------------+-----------------------+
+-----------------------+-----------------------+
| Q.922 Address |
+-----------------------+-----------------------+
| Control (UI) 0x03 | NLPID 0xCC |
+-----------------------+-----------------------+
| IP packet |
| . |
| . |
| . |
+-----------------------+-----------------------+
2. NLPID value indicating SNAP
2. 指示捕捉的NLPID值
+-----------------------+-----------------------+
| Q.922 Address |
+-----------------------+-----------------------+
| Control (UI) 0x03 | pad 0x00 |
+-----------------------+-----------------------+
| NLPID 0x80 | | SNAP Header
+-----------------------+ OUI = 0x00-00-00 + Indicating
| | IP
+-----------------------+-----------------------+
| PID 0x0800 |
+-----------------------+-----------------------+
| IP packet |
| . |
| . |
| . |
+-----------------------+-----------------------+
+-----------------------+-----------------------+
| Q.922 Address |
+-----------------------+-----------------------+
| Control (UI) 0x03 | pad 0x00 |
+-----------------------+-----------------------+
| NLPID 0x80 | | SNAP Header
+-----------------------+ OUI = 0x00-00-00 + Indicating
| | IP
+-----------------------+-----------------------+
| PID 0x0800 |
+-----------------------+-----------------------+
| IP packet |
| . |
| . |
| . |
+-----------------------+-----------------------+
Although both of these encapsulations are supported under the given definitions, it is advantageous to select only one method as the appropriate mechanism for encapsulating IP data. Therefore, IP data shall be encapsulated using the NLPID value of 0xCC indicating IP as shown in option 1 above. This (option 1) is more efficient in transmission (48 fewer bits), and is consistent with the encapsulation of IP in X.25.
尽管在给定的定义下支持这两种封装，但只选择一种方法作为封装IP数据的适当机制是有利的。因此，IP数据应使用表示IP的0xCC NLPID值进行封装，如上述选项1所示。这（选项1）的传输效率更高（减少48位），并且与X.25中的IP封装一致。
As with IP encapsulation, there are alternate ways to transmit various protocols within the scope of this definition. To eliminate the conflicts, the SNAP encapsulation is only used if no NLPID value is defined for the given protocol.
与IP封装一样，在本定义的范围内，也有传输各种协议的替代方法。为了消除冲突，只有在没有为给定协议定义NLPID值时才使用快照封装。
As an example of how this works, ISO CLNP has a NLPID defined (0x81). Therefore, the NLPID field will indicate ISO CLNP and the data packet will follow immediately. The frame would be as follows:
作为如何工作的示例，ISO CLNP定义了一个NLPID（0x81）。因此，NLPID字段将指示ISO CLNP，数据包将立即跟随。框架如下：
+---------------------------------------------+
| Q.922 Address |
+----------------------+----------------------+
| Control (UI) 0x03 | NLPID 0x81 (CLNP) |
+----------------------+----------------------+
| remainder of CLNP packet |
| . |
| . |
+---------------------------------------------+
+---------------------------------------------+
| Q.922 Address |
+----------------------+----------------------+
| Control (UI) 0x03 | NLPID 0x81 (CLNP) |
+----------------------+----------------------+
| remainder of CLNP packet |
| . |
| . |
+---------------------------------------------+
In this example, the NLPID is used to identify the data packet as CLNP. It is also considered part of the CLNP packet and as such, the NLPID should not be removed before being sent to the upper layers for processing. The NLPID is not duplicated.
在本例中，NLPID用于将数据包标识为CLNP。它也被视为CLNP数据包的一部分，因此，在发送到上层进行处理之前，不应删除NLPID。NLPID不重复。
Other protocols, such as IPX, do not have a NLPID value defined. As mentioned above, IPX would be encapsulated using the SNAP header. In this case, the frame would be as follows:
其他协议（如IPX）没有定义NLPID值。如上所述，IPX将使用快照头进行封装。在这种情况下，框架如下所示：
+---------------------------------------------+
| Q.922 Address |
+----------------------+----------------------+
| Control (UI) 0x03 | pad 0x00 |
+----------------------+----------------------+
| NLPID 0x80 (SNAP) | OUI - 0x00 00 00 |
+----------------------+ |
| |
+---------------------------------------------+
| PID 0x8137 |
+---------------------------------------------+
| IPX packet |
| . |
| . |
+---------------------------------------------+
+---------------------------------------------+
| Q.922 Address |
+----------------------+----------------------+
| Control (UI) 0x03 | pad 0x00 |
+----------------------+----------------------+
| NLPID 0x80 (SNAP) | OUI - 0x00 00 00 |
+----------------------+ |
| |
+---------------------------------------------+
| PID 0x8137 |
+---------------------------------------------+
| IPX packet |
| . |
| . |
+---------------------------------------------+
The model for bridging in a Frame Relay network is identical to the model for remote bridging as described in IEEE P802.1g "Remote MAC Bridging" [13] and supports the concept of "Virtual Ports". Remote bridges with LAN ports receive and transmit MAC frames to and from the LANs to which they are attached. They may also receive and transmit MAC frames through virtual ports to and from other remote bridges. A virtual port may represent an abstraction of a remote bridge's point of access to one, two or more other remote bridges.
帧中继网络中的桥接模型与IEEE P802.1g“远程MAC桥接”[13]中描述的远程桥接模型相同，并支持“虚拟端口”的概念。带有LAN端口的远程网桥接收MAC帧，并从它们所连接的LAN发送MAC帧。它们还可以通过虚拟端口接收和发送MAC帧到其他远程网桥或从其他远程网桥发送MAC帧。虚拟端口可以表示远程网桥对一个、两个或多个其他远程网桥的访问点的抽象。
Remote Bridges are statically configured as members of a remote bridge group by management. All members of a remote bridge group are connected by one or more virtual ports. The set of remote MAC bridges in a remote bridge group provides actual or *potential* MAC layer interconnection between a set of LANs and other remote bridge groups to which the remote bridges attach.
远程网桥由管理层静态配置为远程网桥组的成员。远程网桥组的所有成员都由一个或多个虚拟端口连接。远程网桥组中的远程MAC网桥组在一组LAN和远程网桥所连接的其他远程网桥组之间提供实际的或*潜在的*MAC层互连。
In a Frame Relay network there must be a full mesh of Frame Relay VCs between bridges of a remote bridge group. If the frame relay network is not a full mesh, then the bridge network must be divided into multiple remote bridge groups.
在帧中继网络中，远程网桥组的网桥之间必须有一个完整的帧中继VCs网格。如果帧中继网络不是全网，则网桥网络必须划分为多个远程网桥组。
The frame relay VCs that interconnect the bridges of a remote bridge group may be combined or used individually to form one or more virtual bridge ports. This gives flexibility to treat the Frame Relay interface either as a single virtual bridge port, with all VCs in a group, or as a collection of bridge ports (individual or grouped VCs).
互连远程网桥组的网桥的帧中继vc可以组合或单独使用以形成一个或多个虚拟网桥端口。这使得可以灵活地将帧中继接口视为单个虚拟网桥端口（所有VCs在一个组中）或网桥端口的集合（单个或分组VCs）。
When a single virtual bridge port provides the interconnectivity for all bridges of a given remote bridge group (i.e. all VCs are combined into a single virtual port), the standard Spanning Tree Algorithm may be used to determine the state of the virtual port. When more than one virtual port is configured within a given remote bridge group then an "extended" Spanning Tree Algorithm is required. Such an extended algorithm is defined in IEEE 802.1g [13]. The operation of this algorithm is such that a virtual port is only put into backup if there is a loop in the network external to the remote bridge group.
当单个虚拟网桥端口为给定远程网桥组的所有网桥提供互连时（即，所有VCs组合成单个虚拟端口），可以使用标准生成树算法来确定虚拟端口的状态。如果在给定的远程网桥组中配置了多个虚拟端口，则需要“扩展”生成树算法。IEEE 802.1g[13]中定义了这种扩展算法。此算法的操作是，只有在远程网桥组外部的网络中存在环路时，才会将虚拟端口放入备份。
The simplest bridge configuration for a Frame Relay network is the LAN view where all VCs are combined into a single virtual port. Frames, such as BPDUs, which would be broadcast on a LAN, must be flooded to each VC (or multicast if the service is developed for Frame Relay services). Flooding is performed by sending the packet to each relevant DLC associated with the Frame Relay interface. The VCs in this environment are generally invisible to the bridge. That is, the bridge sends a flooded frame to the frame relay interface and does not "see" that the frame is being forwarded to each VC individually. If all participating bridges are fully connected (full mesh) the standard Spanning Tree Algorithm will suffice in this configuration.
帧中继网络最简单的网桥配置是LAN视图，其中所有VCs组合到一个虚拟端口中。帧，例如将在LAN上广播的BPDU，必须淹没到每个VC（如果服务是为帧中继服务开发的，则为多播）。通过将分组发送到与帧中继接口相关联的每个相关DLC来执行泛洪。这种环境中的VCs通常对桥接器不可见。也就是说，网桥向帧中继接口发送一个被淹没的帧，并且不“看到”该帧正在被单独转发到每个VC。如果所有参与的网桥都是完全连接的（全网格），那么标准生成树算法在这种配置中就足够了。
Typically LAN bridges learn which interface a particular end station may be reached on by associating a MAC address with a bridge port. In a Frame Relay network configured for the LAN-like single bridge port (or any set of VCs grouped together to form a single bridge port), however, the bridge must not only associated a MAC address with a bridge port, but it must also associate it with a connection identifier. For Frame Relay networks, this connection identifier is a DLCI. It is unreasonable and perhaps impossible to require bridges to statically configure an association of every possible destination MAC address with a DLC. Therefore, Frame Relay LAN-modeled bridges must provide a mechanism to allow the Frame Relay bridge port to dynamically learn the associations. To accomplish this dynamic learning, a bridged packet shall conform to the encapsulation described within section 4.2. In this way, the receiving Frame Relay interface will know to look into the bridged packet to gather the appropriate information.
通常，LAN网桥通过将MAC地址与网桥端口相关联来了解特定终端站可以到达的接口。然而，在为类似LAN的单个网桥端口（或组合在一起形成单个网桥端口的任何一组VCs）配置的帧中继网络中，网桥不仅必须将MAC地址与网桥端口相关联，还必须将其与连接标识符相关联。对于帧中继网络，此连接标识符是DLCI。要求网桥静态地配置每个可能的目标MAC地址与DLC的关联是不合理的，而且可能是不可能的。因此，帧中继LAN建模网桥必须提供一种机制，允许帧中继网桥端口动态地学习关联。为了完成这种动态学习，桥接数据包应符合第4.2节中描述的封装要求。这样，接收帧中继接口将知道查看桥接分组以收集适当的信息。
A second Frame Relay bridging approach, the point-to-point view, treats each Frame Relay VC as a separate bridge port. Flooding and forwarding packets are significantly less complicated using the point-to-point approach because each bridge port has only one destination. There is no need to perform artificial flooding or to associate DLCIs with destination MAC addresses. Depending upon the interconnection of the VCs, an extended Spanning Tree algorithm may be required to permit all virtual ports to remain active as long as there are no true loops in the topology external to the remote bridge group.
第二种帧中继桥接方法，即点到点视图，将每个帧中继VC视为单独的桥接端口。由于每个网桥端口只有一个目的地，所以使用点对点方法进行泛洪和转发数据包的复杂性大大降低。无需执行人工泛洪或将DLCI与目标MAC地址关联。根据VCs的互连，可能需要扩展生成树算法来允许所有虚拟端口保持活动状态，只要在远程网桥组外部的拓扑中没有真正的环路。
It is also possible to combine the LAN view and the point-to-point view on a single Frame Relay interface. To do this, certain VCs are combined to form a single virtual bridge port while other VCs are independent bridge ports.
还可以在单个帧中继接口上组合LAN视图和点对点视图。为此，某些VCs被组合成一个虚拟网桥端口，而其他VCs是独立的网桥端口。
The following drawing illustrates the different possible bridging configurations. The dashed lines between boxes represent virtual circuits.
下图说明了不同的可能桥接配置。框之间的虚线表示虚拟电路。
+-------+
-------------------| B |
/ -------| |
/ / +-------+
/ |
+-------+/ \ +-------+
| A | -------| C |
| |-----------------------| |
+-------+\ +-------+
\
\ +-------+
\ | D |
-------------------| |
+-------+
+-------+
-------------------| B |
/ -------| |
/ / +-------+
/ |
+-------+/ \ +-------+
| A | -------| C |
| |-----------------------| |
+-------+\ +-------+
\
\ +-------+
\ | D |
-------------------| |
+-------+
Since there is less than a full mesh of VCs between the bridges in this example, the network must be divided into more than one remote bridge group. A reasonable configuration is to have bridges A, B, and C in one group, and have bridges A and D in a second.
由于在本例中，网桥之间的VCs不到一个完整的网格，因此必须将网络划分为多个远程网桥组。一个合理的配置是将桥A、B和C放在一组中，并将桥A和D放在第二组中。
Configuration of the first bridge group combines the VCs interconnection the three bridges (A, B, and C) into a single virtual port. This is an example of the LAN view configuration. The second group would also be a single virtual port which simply connects bridges A and D. In this configuration the standard Spanning Tree Algorithm is sufficient to detect loops.
第一个网桥组的配置将三个网桥（A、B和C）的VCs互连组合成一个虚拟端口。这是LAN视图配置的一个示例。第二组也是一个单独的虚拟端口，它只是连接桥a和D。在这种配置中，标准生成树算法足以检测循环。
An alternative configuration has three individual virtual ports in the first group corresponding to the VCs interconnecting bridges A, B and C. Since the application of the standard Spanning Tree Algorithm to this configuration would detect a loop in the topology, an extended Spanning Tree Algorithm would have to be used in order for all virtual ports to be kept active. Note that the second group would still consist of a single virtual port and the standard Spanning Tree Algorithm could be used in this group.
备选配置在第一组中有三个单独的虚拟端口，对应于VCs互连网桥A、B和C。由于将标准生成树算法应用于此配置将检测拓扑中的环路，为了使所有虚拟端口保持活动状态，必须使用扩展生成树算法。请注意，第二组仍然由一个虚拟端口组成，在这个组中可以使用标准生成树算法。
Using the same drawing, one could construct a remote bridge scenario with three bridge groups. This would be an example of the point-to-point case. Here, the VC connecting A and B, the VC connecting A and C, and the VC connecting A and D are all bridge groups with a single virtual port.
使用相同的图形，可以构建一个包含三个桥组的远程桥场景。这将是一个点对点的例子。这里，连接A和B的VC、连接A和C的VC以及连接A和D的VC都是具有单个虚拟端口的网桥组。
This document defines mechanisms for identifying the multiprotocol encapsulation of datagrams over Frame Relay. There is obviously an element in trust in any encapsulation protocol - a receiver must trust that the sender has correctly identified the protocol being encapsulated. In general, there is no way for a receiver to try to ascertain that the sender did indeed use the proper protocol identification, nor would this be desired functionality.
本文件定义了识别帧中继上数据报的多协议封装的机制。显然，在任何封装协议中都有一个可信的元素——接收方必须相信发送方已经正确识别了被封装的协议。一般来说，接收方无法尝试确定发送方确实使用了正确的协议标识，这也不是期望的功能。
It also specifies the use of ARP and RARP with Frame Relay, and is subject to the same security constraints that affect ARP and similar address resolution protocols. Because authentication is not a part of ARP, there are known security issues relating to its use (e.g., host impersonation). No additional security mechanisms have been added to ARP or RARP for use with Frame Relay networks.
它还规定了ARP和RARP与帧中继的使用，并且受到影响ARP和类似地址解析协议的相同安全约束。由于身份验证不是ARP的一部分，因此存在与其使用相关的已知安全问题（例如，主机模拟）。ARP或RARP中未添加用于帧中继网络的其他安全机制。
List of Commonly Used NLPIDs
常用NLPID列表
0x00 Null Network Layer or Inactive Set
(not used with Frame Relay)
0x08 Q.933 [2]
0x80 SNAP
0x81 ISO CLNP
0x82 ISO ESIS
0x83 ISO ISIS
0x8E IPv6
0xB0 FRF.9 Data Compression [14]
0xB1 FRF.12 Fragmentation [18]
0xCC IPv4
0xCF PPP in Frame Relay [17]
0x00 Null Network Layer or Inactive Set
(not used with Frame Relay)
0x08 Q.933 [2]
0x80 SNAP
0x81 ISO CLNP
0x82 ISO ESIS
0x83 ISO ISIS
0x8E IPv6
0xB0 FRF.9 Data Compression [14]
0xB1 FRF.12 Fragmentation [18]
0xCC IPv4
0xCF PPP in Frame Relay [17]
List of PIDs of OUI 00-80-C2
OUI 00-80-C2的PID列表
with preserved FCS w/o preserved FCS Media
------------------ ----------------- --------------
0x00-01 0x00-07 802.3/Ethernet
0x00-02 0x00-08 802.4
0x00-03 0x00-09 802.5
0x00-04 0x00-0A FDDI
0x00-0B 802.6
0x00-0D Fragments
0x00-0E BPDUs as defined by
802.1(d) or
802.1(g)[12].
0x00-0F Source Routing BPDUs
with preserved FCS w/o preserved FCS Media
------------------ ----------------- --------------
0x00-01 0x00-07 802.3/Ethernet
0x00-02 0x00-08 802.4
0x00-03 0x00-09 802.5
0x00-04 0x00-0A FDDI
0x00-0B 802.6
0x00-0D Fragments
0x00-0E BPDUs as defined by
802.1(d) or
802.1(g)[12].
0x00-0F Source Routing BPDUs
This Appendix contains additional information and instructions for using ITU Recommendation Q.933 [2] and other ITU standards for encapsulating data over frame relay. The information contained here is similar (and in some cases identical) to that found in Annex E to ITU Q.933. The authoritative source for this information is in Annex E and is repeated here only for convenience.
本附录包含使用ITU建议Q.933[2]和其他ITU标准封装帧中继数据的附加信息和说明。此处包含的信息与ITU Q.933附录E中的信息相似（在某些情况下相同）。该信息的权威来源见附录E，此处仅为方便起见而重复。
The Network Level Protocol ID (NLPID) field is administered by ISO and the ITU. It contains values for many different protocols including IP, CLNP (ISO 8473), ITU Q.933, and ISO 8208. A figure summarizing a generic encapsulation technique over frame relay networks follows. The scheme's flexibility consists in the identification of multiple alternative to identify different protocols used either by
网络级协议ID（NLPID）字段由ISO和ITU管理。它包含许多不同协议的值，包括IP、CLNP（ISO 8473）、ITU Q.933和ISO 8208。下图总结了帧中继网络上的通用封装技术。该方案的灵活性在于识别多个备选方案，以识别任一方使用的不同协议
- end-to-end systems or - LAN to LAN bride and routers or - a combination of the above.
- 端到端系统或局域网到局域网和路由器或以上两者的组合。
over frame relay networks.
帧中继网络。
Q.922 control
|
|
--------------------------------------------
| |
UI I Frame
| |
--------------------------------- --------------
| 0x08 | 0x81 |0xCC | 0x80 |..01.... |..10....
| | | | | |
Q.933 CLNP IP SNAP ISO 8208 ISO 8208
| | Modulo 8 Modulo 128
| |
-------------------- OUI
| | |
L2 ID L3 ID -------
| User | |
| Specified | |
| 0x70 802.3 802.6
|
---------------------------
|0x51 |0x4E | |0x4C |0x50
| | | | |
7776 Q.922 Others 802.2 User
Specified
Q.922 control
|
|
--------------------------------------------
| |
UI I Frame
| |
--------------------------------- --------------
| 0x08 | 0x81 |0xCC | 0x80 |..01.... |..10....
| | | | | |
Q.933 CLNP IP SNAP ISO 8208 ISO 8208
| | Modulo 8 Modulo 128
| |
-------------------- OUI
| | |
L2 ID L3 ID -------
| User | |
| Specified | |
| 0x70 802.3 802.6
|
---------------------------
|0x51 |0x4E | |0x4C |0x50
| | | | |
7776 Q.922 Others 802.2 User
Specified
For those protocols which do not have a NLPID assigned or do not have a SNAP encapsulation, the NLPID value of 0x08, indicating ITU Recommendation Q.933 should be used. The four octets following the NLPID include both layer 2 and layer 3 protocol identification. The code points for most protocols are currently defined in ITU Q.933 low layer compatibility information element. The code points for "User Specified" are described in Frame Relay Forum FRF.3.1 [15]. There is also an escape for defining non-standard protocols.
对于那些没有指定NLPID或没有SNAP封装的协议，应使用NLPID值0x08，表示ITU建议Q.933。NLPID后面的四个八位组包括第2层和第3层协议标识。大多数协议的代码点目前在ITU Q.933低层兼容性信息元素中定义。帧中继论坛FRF.3.1[15]中描述了“用户指定”的代码点。定义非标准协议也是一种逃避。
Format of Other Protocols
using Q.933 NLPID
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | NLPID 0x08 |
+---------------+---------------+
| L2 Protocol ID |
| octet 1 | octet 2 |
+---------------+---------------+
| L3 Protocol ID |
| octet 1 | octet 2 |
+---------------+---------------+
| Protocol Data |
+-------------------------------+
| FCS |
+-------------------------------+
Format of Other Protocols
using Q.933 NLPID
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | NLPID 0x08 |
+---------------+---------------+
| L2 Protocol ID |
| octet 1 | octet 2 |
+---------------+---------------+
| L3 Protocol ID |
| octet 1 | octet 2 |
+---------------+---------------+
| Protocol Data |
+-------------------------------+
| FCS |
+-------------------------------+
ISO 8802/2 with user specified
layer 3
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | NLPID 0x08 |
+---------------+---------------+
| 802/2 0x4C | 0x80 |
+---------------+---------------+
|User Spec. 0x70| Note 1 |
+---------------+---------------+
| DSAP | SSAP |
+---------------+---------------+
| Control (Note 2) |
+-------------------------------+
| Remainder of PDU |
+-------------------------------+
| FCS |
+-------------------------------+
ISO 8802/2 with user specified
layer 3
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | NLPID 0x08 |
+---------------+---------------+
| 802/2 0x4C | 0x80 |
+---------------+---------------+
|User Spec. 0x70| Note 1 |
+---------------+---------------+
| DSAP | SSAP |
+---------------+---------------+
| Control (Note 2) |
+-------------------------------+
| Remainder of PDU |
+-------------------------------+
| FCS |
+-------------------------------+
Note 1: Indicates the code point for user specified layer 3 protocol.
注1：表示用户指定的第3层协议的代码点。
Note 2: Control field is two octets for I-format and S-format frames (see 88002/2)
注2：I格式和S格式帧的控制字段为两个八位字节（见88002/2）
Encapsulations using I frame (layer 2)
使用I帧的封装（第2层）
The Q.922 I frame is for supporting layer 3 protocols which require acknowledged data link layer (e.g., ISO 8208). The C/R bit will be used for command and response indications.
Q.922 I帧用于支持需要确认数据链路层（例如ISO 8208）的第3层协议。C/R位将用于命令和响应指示。
Format of ISO 8208 frame
Modulo 8
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| ....Control I frame |
+---------------+---------------+
| 8208 packet (modulo 8) Note 3 |
| |
+-------------------------------+
| FCS |
+-------------------------------+
Format of ISO 8208 frame
Modulo 8
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| ....Control I frame |
+---------------+---------------+
| 8208 packet (modulo 8) Note 3 |
| |
+-------------------------------+
| FCS |
+-------------------------------+
Note 3: First octet of 8208 packet also identifies the
NLPID which is "..01....".
Note 3: First octet of 8208 packet also identifies the
NLPID which is "..01....".
Format of ISO 8208 frame
Modulo 128
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| ....Control I frame |
+---------------+---------------+
| 8208 packet (modulo 128) |
| Note 4 |
+-------------------------------+
| FCS |
+-------------------------------+
Format of ISO 8208 frame
Modulo 128
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| ....Control I frame |
+---------------+---------------+
| 8208 packet (modulo 128) |
| Note 4 |
+-------------------------------+
| FCS |
+-------------------------------+
Note 4: First octet of 8208 packet also identifies the
NLPID which is "..10....".
Note 4: First octet of 8208 packet also identifies the
NLPID which is "..10....".
RFC 1490 has been widely implemented and used, and has been adopted by the Frame Relay Forum in FRF.3.1 [15] and by the ITU in Q.933 [2]. This section describes updates to RFC 1490 that have been made as a result of this implementation and interoperability experience, and which reflect current implementation practice.
RFC 1490已被广泛实施和使用，并已被FRF.3.1[15]中的帧中继论坛和ITU在Q.933[2]中采用。本节介绍了由于本次实施和互操作性经验而对RFC 1490进行的更新，这些更新反映了当前的实施实践。
Some language changes were necessary to clarify RFC 1490. None of these changes impacted the technical aspects of this document, but were required to keep diagrams and language specific and consistent. Specifics of these changes will not be listed here. Below are listed those changes which were significant.
为了澄清RFC 1490，需要进行一些语言更改。这些更改均未影响本文档的技术方面，但需要保持图表和语言的特定性和一致性。此处不列出这些更改的细节。下面列出了这些重大变化。
a) The requirement for stations to accept SNAP encapsulated protocols for which a NLPID was available, was removed. RFC 1490 indicated that, if a protocol, such as IP, had a designated NLPID value, it must be used. Later the document required stations to accept a SNAP encapsulated version of this same protocol. This is clearly inconsistent. A compliant station must send and accept the NLPID encapsulated version of such a protocol. It MAY accept the SNAP encapsulation but should not be required to do so as these frames are noncompliant.
a) 删除了站点接受SNAP封装协议（NLPID可用）的要求。RFC 1490指出，如果协议（如IP）具有指定的NLPID值，则必须使用该值。后来，该文件要求电台接受同一协议的快照封装版本。这显然是不一致的。兼容站必须发送和接受此类协议的NLPID封装版本。它可以接受捕捉封装，但不需要这样做，因为这些框架不符合要求。
b) Fragmentation was removed. To date there are no interoperable implementations of the fragmentation algorithm presented in RFC 1490. Additionally, there have been several suggestions that the proposed mechanisms are insufficient for some frame relay applications. To this end, fragmentation was removed from this document, and has been replaced by the fragmentation specified in FRF.12 [18].
b) 碎片被移除。迄今为止，RFC 1490中提出的分段算法还没有可互操作的实现。此外，有一些建议认为，所提出的机制不足以用于某些帧中继应用。为此，从本文件中删除了碎片，并用FRF.12[18]中规定的碎片替换。
c) The address resolution presented in RFC 1490 referred only to PVC environments and is insufficient for SVC environments. Therefore the section title was changed to reflect this. Further work on SVC address resolution will take place in the ION working group.
c) RFC 1490中提供的地址分辨率仅适用于PVC环境，不适用于SVC环境。因此，更改了章节标题以反映这一点。有关SVC地址解析的进一步工作将在ION工作组中进行。
d) The encapsulation for Source Routing BPDUs was added, and the lists in Appendix A were augmented.
d) 添加了源路由BPDU的封装，并增加了附录A中的列表。
e) The use of canonical and non-canonical MAC destination addresses in the bridging encapsulations was clarified.
e) 澄清了桥接封装中规范和非规范MAC目标地址的使用。
f) The Inverse ARP description was moved to the Inverse ARP specification [11].
f) 反向ARP描述已移至反向ARP规范[11]。
g) A new security section was added.
g) 增加了一个新的安全部分。
[1] International Telecommunication Union, "ISDN Data Link Layer Specification for Frame Mode Bearer Services", ITU-T Recommendation Q.922, 1992.
[1] 国际电信联盟，“帧模式承载业务的ISDN数据链路层规范”，ITU-T建议Q.9221992。
[2] International Telecommunication Union, "Signalling Specifications for Frame Mode Switched and Permanent Virtual Connection Control and Status Monitoring", ITU-T Recommendation Q.933, 1995.
[2] 国际电信联盟，“帧模式交换和永久虚拟连接控制和状态监测的信令规范”，ITU-T建议Q.933，1995年。
[3] Information technology - Telecommunications and Information Exchange between systems - Protocol Identification in the Network Layer, ISO/IEC TR 9577: 1992.
[3] 信息技术.系统间远程通信和信息交换.网络层协议识别，ISO/IEC TR 9577:1992。
[4] Baker, F., and R. Bowen, "PPP Bridging Control Protocol (BCP)", RFC 1638, June 1994.
[4] Baker，F.和R.Bowen，“PPP桥接控制协议（BCP）”，RFC16381994年6月。
[5] International Standard, Information Processing Systems - Local Area Networks - Logical Link Control, ISO 8802-2, ANSI/IEEE, Second Edition, 1994-12-30.
[5] 国际标准，信息处理系统-局域网-逻辑链路控制，ISO 8802-2，ANSI/IEEE，第二版，1994-12-30。
[6] Plummer, D., "An Ethernet Address Resolution Protocol - or - Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, November 1982.
[6] Plummer，D.，“以太网地址解析协议-或-将网络协议地址转换为48位以太网地址以便在以太网硬件上传输”，STD 37，RFC 826，1982年11月。
[7] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994. See also: http://www.iana.org/numbers.html
[7] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994. See also: http://www.iana.org/numbers.html
[8] Finlayson, R., Mann, R., Mogul, J., and M. Theimer, "A Reverse Address Resolution Protocol", STD 38, RFC 903, June 1984.
[8] Finlayson，R.，Mann，R.，Mogul，J.，和M.Theimer，“反向地址解析协议”，STD 38，RFC 903，1984年6月。
[9] Postel, J., and J. Reynolds, "A Standard for the Transmission of IP Datagrams over IEEE 802 Networks", RFC 1042, February 1988.
[9] Postel，J.和J.Reynolds，“通过IEEE 802网络传输IP数据报的标准”，RFC 1042，1988年2月。
[10] IEEE, "IEEE Standard for Local and Metropolitan Area Networks: Overview and architecture", IEEE Standard 802-1990.
[10] IEEE，“局域网和城域网的IEEE标准：概述和体系结构”，IEEE标准802-1990。
[11] Bradley, T., Brown, C., and A. Malis, "Inverse Address Resolution Protocol", RFC 2390, September 1998.
[11] Bradley，T.，Brown，C.和A.Malis，“反向地址解析协议”，RFC 23901998年9月。
[12] IEEE, "IEEE Standard for Local and Metropolitan Networks: Media Access Control (MAC) Bridges", IEEE Standard 802.1D-1990.
[12] IEEE，“本地和城域网IEEE标准：媒体访问控制（MAC）网桥”，IEEE标准802.1D-1990。
[13] ISO/IEC 15802-5 : 1998 (IEEE Standard 802.1G), Remote Media Access Control (MAC) Bridging, March 12, 1997.
[13] ISO/IEC 15802-5:1998（IEEE标准802.1G），远程媒体访问控制（MAC）桥接，1997年3月12日。
[14] Frame Relay Forum, "Data Compression Over Frame Relay Implementation Agreement", FRF.9, January 22, 1996.
[14] 帧中继论坛，“基于帧中继的数据压缩实现协议”，FRF.9，1996年1月22日。
[15] Frame Relay Forum, "Multiprotocol Encapsulation Implementation Agreement", FRF.3.1, June 22, 1995.
[15] 帧中继论坛，“多协议封装实施协议”，FRF.3.11995年6月22日。
[16] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[16] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[17] Simpson, W., "PPP in Frame Relay", RFC 1973, June 1996.
[17] 辛普森，W.，“PPP帧内中继”，RFC 1973，1996年6月。
[18] Frame Relay Forum, "Frame Relay Fragmentation Implementation Agreement", FRF.12, December 1997.
[18] 帧中继论坛，“帧中继分段实施协议”，FRF.12，1997年12月。
[19] Frame Relay Forum, "Frame Relay PVC Multicast Service and Protocol Implementation Agreement", FRF.7, October 21, 1994.
[19] 帧中继论坛，“帧中继PVC多播服务和协议实现协议”，FRF.71994年10月21日。
Caralyn Brown Consultant
卡拉林·布朗顾问
EMail: cbrown@juno.com
EMail: cbrown@juno.com
Andrew Malis Ascend Communications, Inc. 1 Robbins Road Westford, MA 01886
马萨诸塞州韦斯特福德罗宾斯路1号安德鲁·马利斯·阿森德通信公司，邮编01886
Phone: (978) 952-7414 EMail: malis@ascend.com
电话：（978）952-7414电子邮件：malis@ascend.com
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。