Network Working Group D. Grossman
Request for Comments: 2684 Motorola, Inc.
Obsoletes: 1483 J. Heinanen
Category: Standards Track Telia
September 1999
Network Working Group D. Grossman
Request for Comments: 2684 Motorola, Inc.
Obsoletes: 1483 J. Heinanen
Category: Standards Track Telia
September 1999
Multiprotocol Encapsulation over ATM Adaptation Layer 5
ATM适配层5上的多协议封装
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 (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
This memo replaces RFC 1483. It describes two encapsulations methods for carrying network interconnect traffic over AAL type 5 over ATM. The first method allows multiplexing of multiple protocols over a single ATM virtual connection whereas the second method assumes that each protocol is carried over a separate ATM virtual connection.
本备忘录取代RFC 1483。它描述了在ATM上通过AAL类型5承载网络互连流量的两种封装方法。第一种方法允许在单个ATM虚拟连接上多路复用多个协议，而第二种方法假设每个协议通过单独的ATM虚拟连接进行传输。
Applicability
适用性
This specification is intended to be used in implementations which use ATM networks to carry multiprotocol traffic among hosts, routers and bridges which are ATM end systems.
本规范旨在用于使用ATM网络在作为ATM终端系统的主机、路由器和网桥之间传输多协议通信的实现中。
Asynchronous Transfer Mode (ATM) wide area, campus and local area networks are used to transport IP datagrams and other connectionless traffic between hosts, routers, bridges and other networking devices. This memo describes two methods for carrying connectionless routed and bridged Protocol Data Units (PDUs) over an ATM network. The "LLC Encapsulation" method allows multiplexing of multiple protocols over a single ATM virtual connection (VC). The protocol type of each PDU is identified by a prefixed IEEE 802.2 Logical Link Control (LLC) header. In the "VC Multiplexing" method, each ATM VC carries PDUs of exactly one protocol type. When multiple protocols need to be transported, there is a separate VC for each.
异步传输模式（ATM）广域网、校园网和局域网用于在主机、路由器、网桥和其他网络设备之间传输IP数据报和其他无连接流量。本备忘录描述了通过ATM网络承载无连接路由和桥接协议数据单元（PDU）的两种方法。“LLC封装”方法允许在单个ATM虚拟连接（VC）上多路复用多个协议。每个PDU的协议类型由带前缀的IEEE 802.2逻辑链路控制（LLC）头标识。在“VC多路复用”方法中，每个ATM VC只携带一种协议类型的PDU。当需要传输多个协议时，每个协议都有一个单独的VC。
The unit of transport in ATM is a 53 octet fixed length PDU called a cell. A cell consists of a 5 octet header and a 48 byte payload. Variable length PDUs, including those addressed in this memo, must be segmented by the transmitter to fit into the 48 octet ATM cell payload, and reassembled by the receiver. This memo specifies the use of the ATM Adaptation Layer type 5 (AAL5), as defined in ITU-T Recommendation I.363.5 [2] for this purpose. Variable length PDUs are carried in the Payload field of the AAL5 Common Part Convergence Sublayer (CPCS) PDU.
ATM中的传输单元是一个53个八位组的固定长度PDU，称为信元。一个单元由一个5字节的头和一个48字节的有效载荷组成。可变长度PDU，包括本备忘录中所述的PDU，必须由发射机分段，以适合48个八位字节的ATM信元有效载荷，并由接收机重新组装。本备忘录规定了使用ITU-T建议I.363.5[2]中定义的ATM适配层类型5（AAL5）。可变长度PDU在AAL5公共部分会聚子层（CPCS）PDU的有效载荷字段中携带。
This memo only describes how routed and bridged PDUs are carried directly over the AAL5 CPCS, i.e., when the Service Specific Convergence Sublayer (SSCS) of AAL5 is absent. If Frame Relay Service Specific Convergence Sublayer (FR-SSCS), as defined in ITU-T Recommendation I.365.1 [3], is used over the CPCS, then routed and bridged PDUs are carried using the NLPID multiplexing method described in RFC 2427 [4]. The RFC 2427 encapsulation MUST be used in the special case that Frame Relay Network Interworking or transparent mode Service Interworking [9] are used, but is NOT RECOMMENDED for other applications. Appendix A (which is for information only) shows the format of the FR-SSCS-PDU as well as how IP and CLNP PDUs are encapsulated over FR-SSCS according to RFC 2427.
本备忘录仅描述了在AAL5的服务特定汇聚子层（SSC）不存在的情况下，如何将路由和桥接PDU直接传送到AAL5 CPC上。如果在CPC上使用ITU-T建议I.365.1[3]中定义的帧中继服务特定汇聚子层（FR-SSC），则使用RFC 2427[4]中描述的NLPID多路复用方法承载路由和桥接PDU。RFC 2427封装必须在使用帧中继网络互连或透明模式服务互连[9]的特殊情况下使用，但不建议用于其他应用。附录A（仅供参考）显示了FR-SSCS-PDU的格式，以及IP和CLNP PDU如何根据RFC 2427封装在FR-SSC上。
This memo also includes an optional encapsulation for use with Virtual Private Networks that operate over an ATM subnet.
此备忘录还包括一个可选的封装，用于在ATM子网上运行的虚拟专用网络。
If it is desired to use the facilities which are designed for the Point-to-Point Protocol (PPP), and there exists a point-to-point relationship between peer systems, then RFC 2364, rather than this memo, applies.
如果希望使用为点对点协议（PPP）设计的设施，并且对等系统之间存在点对点关系，则适用RFC 2364，而不是本备忘录。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [10].
本文件中出现的关键词必须、不得、必需、应、不应、应、不应、推荐、不推荐、可和可选时，应按照RFC 2119[10]中的说明进行解释。
The decision as to whether to use LLC encapsulation or VC-multiplexing depends on implementation and system requirements. In general, LLC encapsulation tends to require fewer VCs in a multiprotocol environment. VC multiplexing tends to reduce fragmentation overhead (e.g., an IPV4 datagram containing a TCP control packet with neither IP nor TCP options exactly fits into a single cell).
是否使用LLC封装或VC多路复用取决于实现和系统需求。通常，在多协议环境中，LLC封装往往需要较少的VCs。VC多路复用倾向于减少碎片开销（例如，包含既没有IP选项也没有TCP选项的TCP控制数据包的IPV4数据报正好适合单个单元）。
When two ATM end systems wish to exchange connectionless PDUs across an ATM Permanent Virtual Connection (PVC), selection of the multiplexing method is done by configuration. ATM connection control signalling procedures are used to negotiate the encapsulation method when ATM Switched Virtual Connections (SVCs) are to be used. [5] and [8] specify how this negotiation is done.
当两个ATM终端系统希望通过ATM永久虚拟连接（PVC）交换无连接PDU时，通过配置选择多路复用方法。当使用ATM交换虚拟连接（SVC）时，ATM连接控制信令程序用于协商封装方法。[5] 和[8]指定如何进行协商。
For both multiplexing methods, routed and bridged PDUs MUST be encapsulated within the Payload field of an AAL5 CPCS-PDU.
对于这两种多路复用方法，路由和桥接PDU必须封装在AAL5 CPCS-PDU的有效负载字段中。
ITU-T Recomendation I.363.5 [2] provides the complete definition of the AAL5 PDU format and procedures at the sender and receiver. The AAL5 message mode service, in the non-assured mode of operation MUST be used. The corrupted delivery option MUST NOT be used. A reassembly timer MAY be used. The following description is provided for information.
ITU-T建议I.363.5[2]提供了发送端和接收端AAL5 PDU格式和程序的完整定义。必须使用非保证运行模式下的AAL5消息模式服务。不得使用损坏的传递选项。可使用重新组装计时器。以下说明仅供参考。
The format of the AAL5 CPCS-PDU is shown below:
AAL5 CPCS-PDU的格式如下所示：
AAL5 CPCS-PDU Format
+-------------------------------+
| . |
| . |
| CPCS-PDU Payload |
| up to 2^16 - 1 octets) |
| . |
| . |
+-------------------------------+
| PAD ( 0 - 47 octets) |
+-------------------------------+ -------
| CPCS-UU (1 octet ) |
+-------------------------------+
| CPI (1 octet ) |
+-------------------------------+CPCS-PDU Trailer
| Length (2 octets) |
+-------------------------------|
| CRC (4 octets) |
+-------------------------------+ -------
AAL5 CPCS-PDU Format
+-------------------------------+
| . |
| . |
| CPCS-PDU Payload |
| up to 2^16 - 1 octets) |
| . |
| . |
+-------------------------------+
| PAD ( 0 - 47 octets) |
+-------------------------------+ -------
| CPCS-UU (1 octet ) |
+-------------------------------+
| CPI (1 octet ) |
+-------------------------------+CPCS-PDU Trailer
| Length (2 octets) |
+-------------------------------|
| CRC (4 octets) |
+-------------------------------+ -------
The Payload field contains user information up to 2^16 - 1 octets.
有效负载字段包含最多2^16-1个八位字节的用户信息。
The PAD field pads the CPCS-PDU to fit exactly into the ATM cells such that the last 48 octet cell payload created by the SAR sublayer will have the CPCS-PDU Trailer right justified in the cell.
PAD字段将CPCS-PDU填充到ATM信元中，以便SAR子层创建的最后48个八位字节信元有效载荷将使CPCS-PDU拖车在信元中正确对齐。
The CPCS-UU (User-to-User indication) field is used to transparently transfer CPCS user to user information. The field is not used by the multiprotocol ATM encapsulation described in this memo and MAY be set to any value.
CPCS-UU（用户到用户指示）字段用于透明地传输CPCS用户到用户的信息。本备忘录中描述的多协议ATM封装不使用该字段，可以将其设置为任何值。
The CPI (Common Part Indicator) field aligns the CPCS-PDU trailer to 64 bits. This field MUST be coded as 0x00.
CPI（公共零件指示器）字段将CPCS-PDU尾部对齐到64位。此字段必须编码为0x00。
The Length field indicates the length, in octets, of the Payload field. The maximum value for the Length field is 65535 octets. A Length field coded as 0x00 is used for the abort function.
长度字段表示有效负载字段的长度（以八位字节为单位）。长度字段的最大值为65535个八位字节。编码为0x00的长度字段用于中止功能。
The CRC field is used to detect bit errors in the CPCS-PDU. A CRC-32 is used.
CRC字段用于检测CPCS-PDU中的位错误。使用CRC-32。
LLC Encapsulation is needed when more than one protocol might be carried over the same VC. In order to allow the receiver to properly process the incoming AAL5 CPCS-PDU, the Payload Field contains information necessary to identify the protocol of the routed or bridged PDU. In LLC Encapsulation, this information MUST be encoded in an LLC header placed in front of the carried PDU.
当同一个VC上可能有多个协议时，需要LLC封装。为了允许接收机正确处理传入的AAL5 CPCS-PDU，有效载荷字段包含识别路由或桥接PDU协议所需的信息。在LLC封装中，必须将此信息编码到放置在所携带PDU前面的LLC标头中。
Although this memo only deals with protocols that operate over LLC Type 1 (unacknowledged connectionless mode) service, the same encapsulation principle also applies to protocols operating over LLC Type 2 (connection-mode) service. In the latter case the format and contents of the LLC header would be as described in IEEE 802.1 and IEEE 802.2.
尽管本备忘录仅涉及在LLC类型1（未确认无连接模式）服务上运行的协议，但相同的封装原则也适用于在LLC类型2（连接模式）服务上运行的协议。在后一种情况下，LLC报头的格式和内容将如IEEE 802.1和IEEE 802.2中所述。
In LLC Encapsulation, the protocol type of routed PDUs MUST be identified by prefixing an IEEE 802.2 LLC header to each PDU. In some cases, the LLC header MUST be followed by an IEEE 802.1a SubNetwork Attachment Point (SNAP) header. In LLC Type 1 operation, the LLC header MUST consist of three one octet fields:
在LLC封装中，必须通过在每个PDU前面加上IEEE 802.2 LLC头来标识路由PDU的协议类型。在某些情况下，LLC报头后面必须紧跟IEEE 802.1a子网连接点（SNAP）报头。在LLC类型1操作中，LLC报头必须由三个一个八位字节字段组成：
+------+------+------+
| DSAP | SSAP | Ctrl |
+------+------+------+
+------+------+------+
| DSAP | SSAP | Ctrl |
+------+------+------+
In LLC Encapsulation for routed protocols, the Control field MUST be set to 0x03, specifying a Unnumbered Information (UI) Command PDU.
在路由协议的LLC封装中，必须将控制字段设置为0x03，以指定未编号的信息（UI）命令PDU。
The LLC header value 0xFE-FE-03 MUST be used to identify a routed PDU in the ISO NLPID format (see [6] and Appendix B). For NLPID-formatted routed PDUs, the content of the AAL5 CPCS-PDU Payload field MUST be as follows:
LLC标题值0xFE-FE-03必须用于标识ISO NLPID格式的路由PDU（见[6]和附录B）。对于NLPID格式的路由PDU，AAL5 CPCS-PDU有效负载字段的内容必须如下所示：
Payload Format for Routed NLPID-formatted PDUs
+-------------------------------+
| LLC 0xFE-FE-03 |
+-------------------------------+
| NLPID (1 octet) |
+-------------------------------+
| . |
| PDU |
| (up to 2^16 - 4 octets) |
| . |
+-------------------------------+
Payload Format for Routed NLPID-formatted PDUs
+-------------------------------+
| LLC 0xFE-FE-03 |
+-------------------------------+
| NLPID (1 octet) |
+-------------------------------+
| . |
| PDU |
| (up to 2^16 - 4 octets) |
| . |
+-------------------------------+
The routed protocol MUST be identified by a one octet NLPID field that is part of Protocol Data. NLPID values are administered by ISO and ITU-T. They are defined in ISO/IEC TR 9577 [6] and some of the currently defined ones are listed in Appendix C.
路由协议必须由作为协议数据一部分的一个八位字节NLPID字段标识。NLPID值由ISO和ITU-T管理。它们在ISO/IEC TR 9577[6]中定义，一些当前定义的值在附录C中列出。
An NLPID value of 0x00 is defined in ISO/IEC TR 9577 as the Null Network Layer or Inactive Set. Since it has no significance within the context of this encapsulation scheme, a NLPID value of 0x00 MUST NOT be used.
NLPID值0x00在ISO/IEC TR 9577中定义为空网络层或非活动集。因为它在这个封装方案的上下文中没有意义，所以不能使用0x00的NLPID值。
Although there is a NLPID value (0xCC) that indicates IP, the NLPID format MUST NOT be used for IP. Instead, IP datagrams MUST be identified by a SNAP header, as defined below.
尽管存在指示IP的NLPID值（0xCC），但NLPID格式不得用于IP。相反，IP数据报必须由SNAP报头标识，如下所述。
The presence of am IEEE 802.1a SNAP header is indicated by the LLC header value 0xAA-AA-03. A SNAP header is of the form
LLC报头值0xAA-AA-03表示存在am IEEE 802.1a SNAP报头。捕捉标头的格式如下所示
+------+------+------+------+------+
| OUI | PID |
+------+------+------+------+------+
+------+------+------+------+------+
| OUI | PID |
+------+------+------+------+------+
The SNAP header consists of a three octet Organizationally Unique Identifier (OUI) and a two octet Protocol Identifier (PID). The OUI is administered by IEEE and identifies an organization which administers the values which might be assigned to the PID. The SNAP header thus uniquely identifies a routed or bridged protocol. The OUI value 0x00-00-00 indicates that the PID is an EtherType.
SNAP标头由三个八位字节的组织唯一标识符（OUI）和两个八位字节的协议标识符（PID）组成。OUI由IEEE管理，并标识管理可能分配给PID的值的组织。因此，SNAP报头唯一地标识路由或桥接协议。OUI值0x00-00-00表示PID为以太网类型。
The format of the AAL5 CPCS-PDU Payload field for routed non-NLPID Formatted PDUs MUST be as follows:
路由非NLPID格式PDU的AAL5 CPCS-PDU有效负载字段的格式必须如下所示：
Payload Format for Routed non-NLPID formatted PDUs
+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-00-00 |
+-------------------------------+
| EtherType (2 octets) |
+-------------------------------+
| . |
| Non-NLPID formatted PDU |
| (up to 2^16 - 9 octets) |
| . |
+-------------------------------+
Payload Format for Routed non-NLPID formatted PDUs
+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-00-00 |
+-------------------------------+
| EtherType (2 octets) |
+-------------------------------+
| . |
| Non-NLPID formatted PDU |
| (up to 2^16 - 9 octets) |
| . |
+-------------------------------+
In the particular case of an IPv4 PDU, the Ethertype value is 0x08- 00, and the payload format MUST be:
在IPv4 PDU的特定情况下，Ethertype值为0x08-00，有效负载格式必须为：
Payload Format for Routed IPv4 PDUs
+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-00-00 |
+-------------------------------+
| EtherType 0x08-00 |
+-------------------------------+
| . |
| IPv4 PDU |
| (up to 2^16 - 9 octets) |
| . |
+-------------------------------+
Payload Format for Routed IPv4 PDUs
+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-00-00 |
+-------------------------------+
| EtherType 0x08-00 |
+-------------------------------+
| . |
| IPv4 PDU |
| (up to 2^16 - 9 octets) |
| . |
+-------------------------------+
This format is consistent with that defined in RFC 1042 [7].
该格式与RFC 1042[7]中定义的格式一致。
In LLC Encapsulation, bridged PDUs are encapsulated by identifying the type of the bridged media in the SNAP header. The presence of the SNAP header MUST be indicated by the LLC header value 0xAA-AA-03. The OUI value in the SNAP header MUST be the 802.1 organization code 0x00-80-C2. The type of the bridged media MUST be specified by the two octet PID. The PID MUST also indicate whether the original Frame Check Sequence (FCS) is preserved within the bridged PDU. Appendix B provides a list of media type (PID) values that can be used in ATM encapsulation.
在LLC封装中，桥接PDU通过标识快照头中桥接介质的类型来封装。必须通过LLC标头值0xAA-AA-03指示是否存在捕捉标头。快照标头中的OUI值必须是802.1组织代码0x00-80-C2。桥接媒体的类型必须由两个八位组PID指定。PID还必须指示桥接PDU中是否保留了原始帧检查序列（FCS）。附录B提供了可用于ATM封装的媒体类型（PID）值列表。
The AAL5 CPCS-PDU Payload field carrying a bridged PDU MUST have one of the following formats. The necessary number of padding octets MUST be added after the PID field in order to align the Ethernet/802.3 LLC Data field, 802.4 Data Unit field, 802.5 Info field, FDDI Info field or 802.6 Info field (respectively) of the bridged PDU to begin at a four octet boundary. The bit ordering of the MAC address MUST be the same as it would be on the LAN or MAN (e.g., in canoncial form for bridged Ethernet/IEEE 802.3 PDUs, but in 802.5/FDDI format for bridged 802.5 PDUs).
承载桥接PDU的AAL5 CPCS-PDU有效负载字段必须具有以下格式之一。必须在PID字段后添加必要数量的填充八位字节，以便将桥接PDU的Ethernet/802.3 LLC数据字段、802.4数据单元字段、802.5信息字段、FDDI信息字段或802.6信息字段（分别）从四个八位字节边界开始对齐。MAC地址的位顺序必须与LAN或MAN上的相同（例如，桥接以太网/IEEE 802.3 PDU的标准格式，但桥接802.5 PDU的标准格式）。
Payload Format for Bridged Ethernet/802.3 PDUs
+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-01 or 0x00-07 |
+-------------------------------+
| PAD 0x00-00 |
+-------------------------------+
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| LAN FCS (if PID is 0x00-01) |
+-------------------------------+
Payload Format for Bridged Ethernet/802.3 PDUs
+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-01 or 0x00-07 |
+-------------------------------+
| PAD 0x00-00 |
+-------------------------------+
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| LAN FCS (if PID is 0x00-01) |
+-------------------------------+
The Ethernet/802.3 physical layer requires padding of frames to a minimum size. A bridge that uses uses the Bridged Ethernet/802.3 encapsulation format with the preserved LAN FCS MUST include padding. A bridge that uses the Bridged Ethernet/802.3 encapsulation format without the preserved LAN FCS MAY either include padding, or omit it. When a bridge receives a frame in this format without the LAN FCS, it MUST be able to insert the necessary padding (if none is already present) before forwarding to an Ethernet/802.3 subnetwork.
以太网/802.3物理层要求将帧填充到最小大小。使用桥接以太网/802.3封装格式并保留LAN FCS的网桥必须包含填充。使用桥接以太网/802.3封装格式而不保留LAN FCS的网桥可以包含填充，也可以省略填充。当网桥在没有LAN FCS的情况下接收到此格式的帧时，它必须能够在转发到Ethernet/802.3子网之前插入必要的填充（如果没有填充）。
Payload Format for Bridged 802.4 PDUs
+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-02 or 0x00-08 |
+-------------------------------+
| PAD 0x00-00-00 |
+-------------------------------+
| Frame Control (1 octet) |
+-------------------------------+
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| LAN FCS (if PID is 0x00-02) |
+-------------------------------+
Payload Format for Bridged 802.4 PDUs
+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-02 or 0x00-08 |
+-------------------------------+
| PAD 0x00-00-00 |
+-------------------------------+
| Frame Control (1 octet) |
+-------------------------------+
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| LAN FCS (if PID is 0x00-02) |
+-------------------------------+
Payload Format for Bridged 802.5 PDUs
+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-03 or 0x00-09 |
+-------------------------------+
| PAD 0x00-00-XX |
+-------------------------------+
| Frame Control (1 octet) |
+-------------------------------+
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| LAN FCS (if PID is 0x00-03) |
+-------------------------------+
Payload Format for Bridged 802.5 PDUs
+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-03 or 0x00-09 |
+-------------------------------+
| PAD 0x00-00-XX |
+-------------------------------+
| Frame Control (1 octet) |
+-------------------------------+
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| LAN FCS (if PID is 0x00-03) |
+-------------------------------+
Since the 802.5 Access Control (AC) field has no significance outside the local 802.5 subnetwork, it is treated by this encapsulation as the last octet of the three octet PAD field. It MAY be set to any value by the sending bridge and MUST be ignored by the receiving bridge.
由于802.5访问控制（AC）字段在本地802.5子网之外没有任何意义，因此该封装将其视为三个八位组焊盘字段的最后一个八位组。它可以由发送网桥设置为任何值，并且必须由接收网桥忽略。
Payload Format for Bridged FDDI PDUs
+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-04 or 0x00-0A |
+-------------------------------+
| PAD 0x00-00-00 |
+-------------------------------+
| Frame Control (1 octet) |
+-------------------------------+
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| LAN FCS (if PID is 0x00-04) |
+-------------------------------+
Payload Format for Bridged FDDI PDUs
+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-04 or 0x00-0A |
+-------------------------------+
| PAD 0x00-00-00 |
+-------------------------------+
| Frame Control (1 octet) |
+-------------------------------+
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| LAN FCS (if PID is 0x00-04) |
+-------------------------------+
Payload Format for Bridged 802.6 PDUs
+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-0B |
+---------------+---------------+ ------
| Reserved | BEtag | Common
+---------------+---------------+ PDU
| BAsize | Header
+-------------------------------+ -------
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| |
| Common PDU Trailer |
| |
+-------------------------------+
Payload Format for Bridged 802.6 PDUs
+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-0B |
+---------------+---------------+ ------
| Reserved | BEtag | Common
+---------------+---------------+ PDU
| BAsize | Header
+-------------------------------+ -------
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| |
| Common PDU Trailer |
| |
+-------------------------------+
In bridged 802.6 PDUs, the presence of a CRC-32 is indicated by the CIB bit in the header of the MAC frame. Therefore, the same PID value is used regardless of the presence or absence of the CRC-32 in the PDU.
在桥接的802.6 PDU中，MAC帧报头中的CIB位指示CRC-32的存在。因此，无论PDU中是否存在CRC-32，都使用相同的PID值。
The Common Protocol Data Unit (PDU) Header and Trailer are conveyed to allow pipelining at the egress bridge to an 802.6 subnetwork. Specifically, the Common PDU 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.
公共协议数据单元（PDU）头部和尾部被传送，以允许在出口网桥处到802.6子网的管道传输。具体来说，公共PDU标头包含BAsize字段，该字段包含PDU的长度。如果该字段对出口802.6网桥不可用，则该网桥在接收到整个PDU、计算长度并将长度插入BAsize字段之前无法开始传输分段PDU。如果该字段可用，出口802.6网桥可以从公共PDU报头的BAsize字段提取长度，将其插入第一段的相应字段，并立即将该段传输到802.6子网。因此，网桥可以在接收到完整的PDU之前开始传输802.6 PDU。
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值冲突。
An ingress 802.6 bridge can abort an AAL5 CPCS-PDU by setting its Length field to zero. If the egress bridge has already begun transmitting segments of the PDU to an 802.6 subnetwork and then notices that the AAL5 CPCS-PDU has been aborted, it may immediately generate an EOM cell that causes the 802.6 PDU to be rejected at the receiving bridge. Such an EOM cell could, for example, contain an invalid value in the Length field of the Common PDU Trailer.
入口802.6网桥可以通过将AAL5 CPCS-PDU的长度字段设置为零来中止AAL5 CPCS-PDU。如果出口网桥已经开始将PDU的段发送到802.6子网，然后注意到AAL5 CPCS-PDU已经中止，则出口网桥可以立即生成EOM小区，该EOM小区导致802.6 PDU在接收网桥处被拒绝。例如，这样的EOM单元可能在公共PDU尾部的长度字段中包含无效值。
Payload Format for BPDUs
+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-0E |
+-------------------------------+
| |
| BPDU as defined by |
| 802.1(d) or 802.1(g) |
| |
+-------------------------------+
Payload Format for BPDUs
+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-0E |
+-------------------------------+
| |
| BPDU as defined by |
| 802.1(d) or 802.1(g) |
| |
+-------------------------------+
VC Multiplexing creates a binding between an ATM VC and the type of the network protocol carried on that VC. Thus, there is no need for protocol identification information to be carried in the payload of each AAL5 CPCS-PDU. This reduces payload overhead and can reduce per-packet processing. VC multiplexing can improve efficiency by reducing the number of cells needed to carry PDUs of certain lengths.
VC多路复用在ATM VC和该VC上承载的网络协议类型之间创建绑定。因此，不需要在每个AAL5 CPCS-PDU的有效载荷中携带协议标识信息。这减少了有效负载开销，并可以减少每个数据包的处理。VC多路复用可以通过减少携带特定长度PDU所需的单元数量来提高效率。
For ATM PVCs, the type of the protocol to be carried over each PVC MUST be determined by configuration. For ATM SVCs, the negotiations specified in RFC 1755 [5] MUST be used.
对于ATM PVC，必须通过配置确定每个PVC上要承载的协议类型。对于ATM SVC，必须使用RFC 1755[5]中规定的协商。
PDUs of routed protocols MUST be carried as the only content of the Payload of the AAL5 CPCS-PDU. The format of the AAL5 CPCS-PDU Payload field thus becomes:
路由协议的PDU必须作为AAL5 CPCS-PDU有效负载的唯一内容携带。AAL5 CPCS-PDU有效载荷字段的格式因此变为：
Payload Format for Routed PDUs
+-------------------------------+
| . |
| Carried PDU |
| (up to 2^16 - 1 octets) |
| . |
| . |
+-------------------------------+
Payload Format for Routed PDUs
+-------------------------------+
| . |
| Carried PDU |
| (up to 2^16 - 1 octets) |
| . |
| . |
+-------------------------------+
PDUs of bridged protocols MUST be carried in the Payload of the AAL5 CPCS-PDU exactly as described in section 5.2, except that only the fields after the PID field MUST be included. The AAL5 CPCS-PDU Payload field carrying a bridged PDU MUST, therefore, have one of the following formats.
桥接协议的PDU必须完全按照第5.2节所述携带在AAL5 CPCS-PDU的有效载荷中，但必须仅包括PID字段之后的字段。因此，承载桥接PDU的AAL5 CPCS-PDU有效负载字段必须具有以下格式之一。
Payload Format for Bridged Ethernet/802.3 PDUs
+-------------------------------+
| PAD 0x00-00 |
+-------------------------------+
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| LAN FCS (VC dependent option) |
+-------------------------------+
Payload Format for Bridged Ethernet/802.3 PDUs
+-------------------------------+
| PAD 0x00-00 |
+-------------------------------+
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| LAN FCS (VC dependent option) |
+-------------------------------+
Payload Format for Bridged 802.4/802.5/FDDI PDUs
+-------------------------------+
| PAD 0x00-00-00 or 0x00-00-XX |
+-------------------------------+
| Frame Control (1 octet) |
+-------------------------------+
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| LAN FCS (VC dependent option) |
+-------------------------------+
Payload Format for Bridged 802.4/802.5/FDDI PDUs
+-------------------------------+
| PAD 0x00-00-00 or 0x00-00-XX |
+-------------------------------+
| Frame Control (1 octet) |
+-------------------------------+
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| LAN FCS (VC dependent option) |
+-------------------------------+
Note that the 802.5 Access Control (AC) field has no significance outside the local 802.5 subnetwork. It can thus be regarded as the last octet of the three octet PAD field, which in case of 802.5 can be set to any value (XX).
请注意，802.5访问控制（AC）字段在本地802.5子网之外没有意义。因此，它可以被视为三个八位组焊盘字段的最后一个八位组，在802.5的情况下，可以将其设置为任何值（XX）。
Payload Format for Bridged 802.6 PDUs
+---------------+---------------+ -------
| Reserved | BEtag | Common
+---------------+---------------+ PDU
| BAsize | Header
+-------------------------------+ -------
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| |
| Common PDU Trailer |
| |
+-------------------------------+
Payload Format for Bridged 802.6 PDUs
+---------------+---------------+ -------
| Reserved | BEtag | Common
+---------------+---------------+ PDU
| BAsize | Header
+-------------------------------+ -------
| MAC destination address |
+-------------------------------+
| |
| (remainder of MAC frame) |
| |
+-------------------------------+
| |
| Common PDU Trailer |
| |
+-------------------------------+
Payload Format for BPDUs
+-------------------------------+
| |
| BPDU as defined by |
| 802.1(d) or 802.1(g) |
| |
+-------------------------------+
Payload Format for BPDUs
+-------------------------------+
| |
| BPDU as defined by |
| 802.1(d) or 802.1(g) |
| |
+-------------------------------+
In case of Ethernet, 802.3, 802.4, 802.5, and FDDI PDUs the presense or absence of the trailing LAN FCS shall be identified implicitly by the VC, since the PID field is not included. PDUs with the LAN FCS and PDUs without the LAN FCS are thus considered to belong to different protocols even if the bridged media type would be the same.
对于以太网、802.3、802.4、802.5和FDDI PDU，由于不包括PID字段，VC应隐式识别是否存在后续LAN FCS。因此，即使桥接媒体类型相同，带LAN FCS的PDU和不带LAN FCS的PDU也被视为属于不同的协议。
A bridge with an ATM interface that serves as a link to one or more other bridge MUST be able to flood, forward, and filter bridged PDUs.
具有ATM接口的网桥（用作到一个或多个其他网桥的链路）必须能够泛洪、转发和过滤桥接的PDU。
Flooding is performed by sending the PDU to all possible appropriate destinations. In the ATM environment this means sending the PDU through each relevant VC. This may be accomplished by explicitly copying it to each VC or by using a point-to-multipoint VC.
通过将PDU发送到所有可能的适当目的地来执行泛洪。在ATM环境中，这意味着通过每个相关VC发送PDU。这可以通过显式地将其复制到每个VC或使用点对多点VC来实现。
To forward a PDU, a bridge MUST be able to associate a destination MAC address with a VC. It is unreasonable and perhaps impossible to require bridges to statically configure an association of every possible destination MAC address with a VC. Therefore, ATM bridges must provide enough information to allow an ATM interface to dynamically learn about foreign destinations beyond the set of ATM stations.
要转发PDU，网桥必须能够将目标MAC地址与VC关联。要求网桥静态地配置每个可能的目标MAC地址与VC的关联是不合理的，也许是不可能的。因此，ATM网桥必须提供足够的信息，以允许ATM接口动态地了解ATM站集合之外的国外目的地。
To accomplish dynamic learning, a bridged PDU MUST conform to the encapsulation described in section 5. In this way, the receiving ATM interface will know to look into the bridged PDU and learn the association between foreign destination and an ATM station.
为了实现动态学习，桥接PDU必须符合第5节中描述的封装。通过这种方式，接收ATM接口将了解桥接PDU并了解外部目的地和ATM站之间的关联。
The encapsulation defined in this section applies only to Virtual Private Networks (VPNs) that operate over an ATM subnet.
本节中定义的封装仅适用于在ATM子网上运行的虚拟专用网络（VPN）。
A mechanism for globally unique identification of Virtual Private multiprotocol networks is defined in [11]. The 7-octet VPN-Id consists of a 3-octet VPN-related OUI (IEEE 802-1990 Organizationally Unique Identifier), followed by a 4-octet VPN index which is allocated by the owner of the VPN-related OUI. Typically, the VPN-related OUI value is assigned to a VPN service provider, which then allocates VPN index values for its customers.
[11]中定义了虚拟专用多协议网络的全局唯一标识机制。7-octet VPN Id由3-octet VPN相关OUI（IEEE 802-1990组织唯一标识符）和4-octet VPN索引组成，该索引由VPN相关OUI的所有者分配。通常，与VPN相关的OUI值分配给VPN服务提供商，然后该提供商为其客户分配VPN索引值。
The format of the VPN encapsulation header is as follows:
VPN封装头的格式如下：
VPN Encapsulation Header
+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-00-5E |
+-------------------------------+
| PID 0x00-08 |
+-------------------------------+
| PAD 0x00 |
+-------------------------------+
| VPN related OUI (3 octets) |
+-------------------------------+
| VPN Index (4 octets) |
+-------------------------------+
| |
| (remainder of PDU) |
| |
+-------------------------------+
VPN Encapsulation Header
+-------------------------------+
| LLC 0xAA-AA-03 |
+-------------------------------+
| OUI 0x00-00-5E |
+-------------------------------+
| PID 0x00-08 |
+-------------------------------+
| PAD 0x00 |
+-------------------------------+
| VPN related OUI (3 octets) |
+-------------------------------+
| VPN Index (4 octets) |
+-------------------------------+
| |
| (remainder of PDU) |
| |
+-------------------------------+
When the encapsulation header is used, the remainder of the PDU MUST be structured according to the appropiate format described in section 5 or 6 (i.e., the VPN encapsulation header is prepended to the PDU within an AAL5 CPCS SDU).
当使用封装头时，PDU的其余部分必须按照第5节或第6节中描述的适当格式进行构造（即，VPN封装头在AAL5 CPCS SDU内预先添加到PDU）。
When a LLC-encapsulated routed or bridged PDU is sent within a VPN using ATM over AAL5, a VPN encapsulation header MUST be prepended to the appropriate routed or bridged PDU format defined in sections 5.1 and 5.2, respectively.
当使用AAL5上的ATM在VPN内发送LLC封装的路由或桥接PDU时，必须将VPN封装头分别添加到第5.1节和第5.2节中定义的适当路由或桥接PDU格式。
When a routed or bridged PDU is sent within a VPN using VC multiplexing, the VPN identifier MAY either be specified a priori, using ATM connection control signalling or adminstrative assignment to an ATM interface, or it MAY be indicated using an encapsulation header.
当使用VC多路复用在VPN内发送路由或桥接PDU时，可以使用ATM连接控制信令或对ATM接口的管理分配来预先指定VPN标识符，或者可以使用封装报头来指示。
If the VPN is identified using ATM connection control signalling, all PDUs carried by the ATM VC are associated with the same VPN. In this case, the payload formats of routed and bridged PDUs MUST be as defined in sections 6.1 and 6.2, respectively. If a PDU is received containing a VPN encapsulation header when the VPN has been
如果使用ATM连接控制信令识别VPN，则ATM VC携带的所有PDU都与同一VPN相关联。在这种情况下，路由和桥接PDU的有效负载格式必须分别如第6.1节和第6.2节所定义。如果接收到包含VPN封装头的PDU，则VPN已被删除
identified using ATM signalling, the receiver MAY drop it and/or take other actions which are implementation specific. Specification of the mechanism in ATM connection control signalling for carrying VPN identifiers is outside the scope of this Memo.
使用ATM信令识别，接收器可以丢弃它和/或采取特定于实现的其他行动。ATM连接控制信令中用于承载VPN标识符的机制规范不在本备忘录的范围内。
If a VPN identifier is administratively assigned to an ATM interface, then all PDUs carried by any ATM VCs within that interface are associated with that VPN. In this case, the payload formats of routed and bridged PDUs MUST be as defined in sections 6.1 and 6.2, respectively. If a PDU is received containing a VPN encapsulation header when the VPN identifier has been administratively assigned, the receiver MAY drop it and/or take other actions which are implementation specific. Specification of mechanisms (such as MIBs) for assigning VPN identifiers to ATM interfaces is outside the scope of this memo.
如果VPN标识符以管理方式分配给ATM接口，则该接口内任何ATM VCs携带的所有PDU都与该VPN关联。在这种情况下，路由和桥接PDU的有效负载格式必须分别如第6.1节和第6.2节所定义。如果在VPN标识符已被管理分配时接收到包含VPN封装报头的PDU，则接收器可丢弃该PDU和/或采取特定于实现的其他操作。为ATM接口分配VPN标识符的机制（如MIB）的规范不在本备忘录的范围内。
If the VPN identifier is to be indicated using an encapsulation header, then a VPN encapsulation header MUST be prepended to the appropriate routed or bridged PDU format defined in sections 6.1 and 6.2, respectively.
如果要使用封装头指示VPN标识符，则必须将VPN封装头分别添加到第6.1节和第6.2节中定义的适当路由或桥接PDU格式。
This memo defines mechanisms for multiprotocol encapsulation over ATM. There is an element of trust in any encapsulation protocol: a receiver must trust that the sender has correctly identified the protocol being encapsulated. There is no way to ascertain that the sender did use the proper protocol identification (nor would this be desirable functionality). The encapsulation mechanisms described in this memo are believed not to have any other properties that might be exploited by an attacker. However, architectures and protocols operating above the encapsulation layer may be subject to a variety of attacks. In particular, the bridging architecture discussed in section 7 has the same vulnerabilities as other bridging architectures.
本备忘录定义了ATM上的多协议封装机制。在任何封装协议中都有一个信任元素：接收方必须相信发送方已正确识别了被封装的协议。无法确定发送方是否使用了正确的协议标识（这也不是理想的功能）。本备忘录中描述的封装机制被认为没有任何其他可能被攻击者利用的属性。然而，在封装层之上运行的架构和协议可能会受到各种攻击。特别是，第7节中讨论的桥接体系结构与其他桥接体系结构具有相同的漏洞。
System security may be affected by the properties of the underlying ATM network. The ATM Forum has published a security framework [12] and a security specification [13] which may be relevant.
系统安全性可能会受到底层ATM网络属性的影响。ATM论坛发布了可能相关的安全框架[12]和安全规范[13]。
Acknowledgements
致谢
This memo replaces RFC 1483, which was developed by the IP over ATM working group, and edited by Juha Heinanen (then at Telecom Finland, now at Telia). The update was developed in the IP-over-NBMA (ION) working group, and Dan Grossman (Motorola) was editor and also contributed to the work on RFC 1483.
本备忘录取代了RFC 1483，RFC 1483由IP over ATM工作组开发，并由Juha Heinanen（当时在芬兰电信，现在在Telia）编辑。该更新由IP over NBMA（ION）工作组开发，Dan Grossman（摩托罗拉）担任编辑，并对RFC 1483的工作做出了贡献。
This material evolved from RFCs [1] and [4] from which much of the material has been adopted. Thanks to their authors Terry Bradley, Caralyn Brown, Andy Malis, Dave Piscitello, and C. Lawrence. Other key contributors to the work included Brian Carpenter (CERN), Rao Cherukuri (IBM), Joel Halpern (then at Network Systems), Bob Hinden (Sun Microsystems, presently at Nokia), and Gary Kessler (MAN Technology).
这种材料是从RFC[1]和[4]演变而来的，许多材料都是从RFC中采用的。感谢他们的作者特里·布拉德利、卡拉琳·布朗、安迪·马里、戴夫·皮西泰罗和C·劳伦斯。这项工作的其他主要贡献者包括布赖恩·卡彭特（欧洲核子研究所）、拉奥·切鲁库里（IBM）、乔尔·哈尔佩恩（当时在网络系统公司）、鲍勃·欣登（太阳微系统公司，目前在诺基亚公司）和加里·凯斯勒（曼恩科技公司）。
The material concerning VPNs was developed by Barbara Fox (Lucent) and Bernhard Petri (Siemens).
有关VPN的资料由Barbara Fox（朗讯）和Bernhard Petri（西门子）开发。
References
工具书类
[1] Piscitello, D. and C. Lawrence, "The Transmission of IP Datagrams over the SMDS Service", RFC 1209, March 1991.
[1] Piscitello，D.和C.Lawrence，“通过SMDS服务传输IP数据报”，RFC 1209，1991年3月。
[2] ITU-T Recommendation I.363.5, "B-ISDN ATM Adaptation Layer (AAL) Type 5 Specification", August 1996.
[2] ITU-T建议I.363.5，“B-ISDN ATM适配层（AAL）第5类规范”，1996年8月。
[3] ITU-T Recommendation I.365.1, "Frame Relaying Service Specific Convergence Sublayer (SSCS), November 1993.
[3] ITU-T建议I.365.1，“帧中继服务特定汇聚子层（SSCS），1993年11月。
[4] Brown, C. and A. Malis, "Multiprotocol Interconnect over Frame Relay", RFC 2427, September 1998.
[4] Brown，C.和A.Malis，“帧中继上的多协议互连”，RFC 2427，1998年9月。
[5] Perez M., Liaw, F., Mankin, E., Grossman, D. and A. Malis, "ATM Signalling Support for IP over ATM", RFC 1755, February 1995.
[5] Perez M.，Liaw，F.，Mankin，E.，Grossman，D.和A.Malis，“ATM上IP的ATM信令支持”，RFC 17551995年2月。
[6] Information technology - Telecommunications and Information Exchange Between Systems, "Protocol Identification in the Network Layer". ISO/IEC TR 9577, October 1990.
[6] 信息技术.系统间远程通信和信息交换，“网络层的协议识别”。ISO/IEC TR 9577，1990年10月。
[7] Postel, J. and J. Reynolds, "A Standard for the Transmission of IP Datagrams over IEEE 802 Networks", STD 43, RFC 1042, February 1988.
[7] Postel，J.和J.Reynolds，“通过IEEE 802网络传输IP数据报的标准”，STD 43，RFC 1042，1988年2月。
[8] Maher, M., "IP over ATM Signalling - SIG 4.0 Update", RFC 2331, April 1998.
[8] Maher，M.，“ATM上的IP信令-SIG 4.0更新”，RFC 2331，1998年4月。
[9] ITU-T Recommendation I.555, "Frame Relay Bearer Service Interworking", September 1997.
[9] ITU-T建议I.555，“帧中继承载业务互通”，1997年9月。
[10] Bradner, S. "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[10] Bradner，S.“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[11] Fox, B. and B. Gleeson, "Virtual Private Networks Identifier", RFC 2685, September 1999.
[11] Fox，B.和B.Gleeson，“虚拟专用网络标识符”，RFC 26851999年9月。
[12] The ATM Forum, "ATM Security Framework Version 1.0", af-sec-0096.000, February 1998.
[12] ATM论坛，“ATM安全框架1.0版”，af-sec-0096.000，1998年2月。
[13] The ATM Forum, "ATM Security Specification v1.0", af-sec-0100.001, February 1999.
[13] ATM论坛，“ATM安全规范v1.0”，af-sec-0100.001，1999年2月。
ITU-T Recommendation I.365.1 defines a Frame Relaying Specific Convergence Sublayer (FR- SSCS) to be used on the top of the Common Part Convergence Sublayer CPCS) of the AAL type 5 for Frame Relay/ATM interworking. The service offered by FR-SSCS corresponds to the Core service for Frame Relaying as described in I.233.
ITU-T建议I.365.1定义了帧中继专用汇聚子层（FR-SSCS），用于AAL类型5的公共部分汇聚子层（CPCS）的顶部，用于帧中继/ATM互通。FR-SSC提供的服务与I.233中所述的帧中继核心服务相对应。
An FR-SSCS-PDU consists of Q.922 Address field followed by Q.922 Information field. The Q.922 flags and the FCS are omitted, since the corresponding functions are provided by the AAL. The figure below shows an FR-SSCS-PDU embedded in the Payload of an AAL5 CPCS-PDU.
FR-SSCS-PDU由Q.922地址字段和Q.922信息字段组成。由于AAL提供了相应的功能，因此省略了Q.922标志和FCS。下图显示了嵌入AAL5 CPCS-PDU有效载荷中的FR-SSCS-PDU。
FR-SSCS-PDU in Payload of AAL5 CPCS-PDU
+-------------------------------+ -------
| Q.922 Address Field | FR-SSCS-PDU Header
| (2-4 octets) |
+-------------------------------+ -------
| . |
| . |
| Q.922 Information field | FR-SSCS-PDU Payload
| . |
| . |
+-------------------------------+ -------
| AAL5 CPCS-PDU Trailer |
+-------------------------------+
FR-SSCS-PDU in Payload of AAL5 CPCS-PDU
+-------------------------------+ -------
| Q.922 Address Field | FR-SSCS-PDU Header
| (2-4 octets) |
+-------------------------------+ -------
| . |
| . |
| Q.922 Information field | FR-SSCS-PDU Payload
| . |
| . |
+-------------------------------+ -------
| AAL5 CPCS-PDU Trailer |
+-------------------------------+
Routed and bridged PDUs are encapsulated inside the FR-SSCS-PDU as defined in RFC 2427. The Q.922 Information field starts with a Q.922 Control field followed by an optional Pad octet that is used to align the remainder of the frame to a convenient boundary for the sender. The protocol of the carried PDU is then identified by prefixing the PDU by an ISO/IEC TR 9577 Network Layer Protocol ID (NLPID).
路由和桥接PDU封装在RFC 2427中定义的FR-SSCS-PDU内。Q.922信息字段以一个Q.922控制字段开始，后跟一个可选的Pad八位字节，用于将帧的其余部分与发送方方便的边界对齐。然后，通过将ISO/IEC TR 9577网络层协议ID（NLPID）作为PDU的前缀来识别所携带PDU的协议。
In the particular case of an IP PDU, the NLPID is 0xCC and the FR-SSCS-PDU has the following format:
在IP PDU的特定情况下，NLPID为0xCC，FR-SSCS-PDU具有以下格式：
FR-SSCS-PDU Format for Routed IP PDUs
+-------------------------------+
| Q.922 Addr Field |
| (2 or 4 octets) |
+-------------------------------+
| 0x03 (Q.922 Control) |
+-------------------------------+
| NLPID 0xCC |
+-------------------------------+
| . |
| IP PDU |
| (up to 2^16 - 5 octets) |
| . |
+-------------------------------+
FR-SSCS-PDU Format for Routed IP PDUs
+-------------------------------+
| Q.922 Addr Field |
| (2 or 4 octets) |
+-------------------------------+
| 0x03 (Q.922 Control) |
+-------------------------------+
| NLPID 0xCC |
+-------------------------------+
| . |
| IP PDU |
| (up to 2^16 - 5 octets) |
| . |
+-------------------------------+
Note that according to RFC 2427, the Q.922 Address field MUST be either 2 or 4 octets, i.e., a 3 octet Address field MUST NOT be used.
注意，根据RFC 2427，Q.922地址字段必须为2或4个八位字节，即不得使用3个八位字节的地址字段。
In the particular case of a CLNP PDU, the NLPID is 0x81 and the FR-SSCS-PDU has the following format:
在CLNP PDU的特定情况下，NLPID为0x81，FR-SSCS-PDU的格式如下：
FR-SSCS-PDU Format for Routed CLNP PDUs
+-------------------------------+
| Q.922 Addr Field |
| (2 or 4 octets) |
+-------------------------------+
| 0x03 (Q.922 Control) |
+-------------------------------+
| NLPID 0x81 |
+-------------------------------+
| . |
| Rest of CLNP PDU |
| (up to 2^16 - 5 octets) |
| . |
+-------------------------------+
FR-SSCS-PDU Format for Routed CLNP PDUs
+-------------------------------+
| Q.922 Addr Field |
| (2 or 4 octets) |
+-------------------------------+
| 0x03 (Q.922 Control) |
+-------------------------------+
| NLPID 0x81 |
+-------------------------------+
| . |
| Rest of CLNP PDU |
| (up to 2^16 - 5 octets) |
| . |
+-------------------------------+
Note that in case of ISO protocols the NLPID field forms the first octet of the PDU itself and MUST not be repeated.
注意，对于ISO协议，NLPID字段构成PDU本身的第一个八位字节，不得重复。
The above encapsulation applies only to those routed protocols that have a unique NLPID assigned. For other routed protocols (and for bridged protocols), it is necessary to provide another mechanism for easy protocol identification. This can be achieved by using an NLPID value 0x80 to indicate that an IEEE 802.1a SubNetwork Attachment Point (SNAP) header follows.
上述封装仅适用于分配了唯一NLPID的路由协议。对于其他路由协议（以及桥接协议），有必要提供另一种机制以便于协议识别。这可以通过使用NLPID值0x80来表示遵循IEEE 802.1a子网连接点（SNAP）头来实现。
See RFC 2427 for more details related to multiprotocol encapsulation over FRCS.
有关FRC上多协议封装的更多详细信息，请参见RFC 2427。
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-05 0x00-0B 802.6
0x00-0D Fragments
0x00-0E 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-05 0x00-0B 802.6
0x00-0D Fragments
0x00-0E BPDUs
0x00 Null Network Layer or Inactive Set (not used with ATM) 0x80 SNAP 0x81 ISO CLNP 0x82 ISO ESIS 0x83 ISO ISIS 0xCC Internet IP
0x00空网络层或非活动集（不与ATM一起使用）0x80快照0x81 ISO CLNP 0x82 ISO ESIS 0x83 ISO ISIS 0xCC Internet IP
Mutiprotocol encapsulation is necessary, but generally not sufficient, for routing and bridging over the ATM networks. Since the publication of RFC 1483 (the predecessor of this memo), several system specifications were developed by the IETF and the ATM Forum to address various aspects of, or scenarios for, bridged or routed protocols. This appendix summarizes these applications.
对于ATM网络上的路由和桥接，多协议封装是必要的，但通常是不够的。自RFC 1483（本备忘录的前身）出版以来，IETF和ATM论坛制定了若干系统规范，以解决桥接或路由协议的各个方面或场景。本附录总结了这些应用。
1) Point-to-point connection between routers and bridges -- multiprotocol encapsulation over ATM PVCs has been used to provide a simple point-to-point link between bridges and routers across an ATM network. Some amount of manual configuration (e.g., in lieu of INARP) was necessary in these scenarios.
1) 路由器和网桥之间的点对点连接——ATM PVCs上的多协议封装已被用于跨ATM网络在网桥和路由器之间提供简单的点对点链接。在这些场景中，需要一些手动配置（例如，代替INARP）。
2) Classical IP over ATM -- RFC 2225 (formerly RFC 1577) provides an environment where the ATM network serves as a logical IP subnet (LIS). ATM PVCs are supported, with address resolution provided by INARP. For ATM SVCs, a new form of ARP, ATMARP, operates over the ATM network between a host (or router) and an ATMARP server. Where servers are replicated to provide higher availability or performance, a Server Synchronization Cache Protocol (SCSP) defined in RFC 2335 is used. Classical IP over ATM defaults to the LLC/SNAP encapsulation.
2) 经典的ATM上的IP——RFC2225（以前的RFC1577）提供了一个ATM网络作为逻辑IP子网（LIS）的环境。支持ATM PVC，地址解析由INAP提供。对于ATM SVC，一种新的ARP形式ATMARP在主机（或路由器）和ATMARP服务器之间的ATM网络上运行。如果复制服务器以提供更高的可用性或性能，则使用RFC 2335中定义的服务器同步缓存协议（SCSP）。传统的IP over ATM默认为LLC/SNAP封装。
3) LAN Emulation -- The ATM Forum LAN Emulation specification provides an environment where the ATM network is enhanced by LAN Emulation Server(s) to behave as a bridged LAN. Stations obtain configuration information from, and register with, a LAN Emulation Configuration Server; they resolve MAC addresses to ATM addresses through the services of a LAN Emulation Server; they can send broadcast and multicast frames, and also send unicast frames for which they have no direct VC to a Broadcast and Unicast Server. LANE uses the VC multiplexing encapsulation foramts for Bridged Etherent/802.3 (without LAN FCS) or Bridged 802.5 (without LAN FCS) for the Data Direct, LE Multicast Send and Multicast Forward VCCS. However, the initial PAD field described in this memo is used as an LE header, and might not be set to all '0'.
3) LAN仿真——ATM论坛LAN仿真规范提供了一个环境，在该环境中，LAN仿真服务器增强了ATM网络，使其表现为桥接LAN。站点从LAN仿真配置服务器获取配置信息并向其注册；它们通过局域网仿真服务器的服务将MAC地址解析为ATM地址；它们可以发送广播和多播帧，也可以将没有直接VC的单播帧发送到广播和单播服务器。LANE将VC多路复用封装用于桥接Ethernet/802.3（无LAN FCS）或桥接802.5（无LAN FCS），用于数据直接、LE多播发送和多播转发VCC。但是，此备忘录中描述的初始PAD字段用作LE标题，并且可能不会全部设置为“0”。
4) Next Hop Resolution Protocol (NHRP) -- In some cases, the constraint that Classical IP over ATM serve a single LIS limits performance. NHRP, as defined in RFC 2332, extends Classical to allow 'shortcuts' over a an ATM network that supports several LISs.
4) 下一跳解析协议（NHRP）——在某些情况下，ATM上的经典IP服务于单个LIS的限制限制了性能。RFC 2332中定义的NHRP扩展了经典，允许通过支持多个LIS的ATM网络实现“快捷方式”。
5) Multiprotocol over ATM (MPOA) -- The ATM Forum Multiprotocol over ATM Specification integrates LANE and NHRP to provide a generic bridging/routing environment.
5) ATM上的多协议（MPOA）——ATM论坛ATM上的多协议规范集成了LANE和NHRP，以提供通用的桥接/路由环境。
6) IP Multicast -- RFC 2022 extends Classical IP to support IP multicast. A multicast address resolution server (MARS) is used possibly in conjunction with a multicast server to provide IP multicast behavior over ATM point-to-multipoint and/or point to point virtual connections.
6) IP多播——RFC2022扩展了传统IP以支持IP多播。多播地址解析服务器（MARS）可能与多播服务器结合使用，以通过ATM点对多点和/或点对点虚拟连接提供IP多播行为。
7) PPP over ATM -- RFC 2364 extends multiprotocol over ATM to the case where the encapsulated protocol is the Point-to-Point protocols. Both the VC based multiplexing and LLC/SNAP encapsulations are used. This approach is used when the ATM network is used as a point-to-point link and PPP functions are required.
7) ATM上的PPP——RFC 2364将ATM上的多协议扩展到封装协议为点对点协议的情况。使用基于VC的多路复用和LLC/SNAP封装。当ATM网络用作点到点链路且需要PPP功能时，使用这种方法。
Appendix E Differences from RFC 1483
附录E与RFC 1483的差异
This memo replaces RFC 1483. It was intended to remove anachronisms, provide clarifications of ambiguities discovered by implementors or created by changes to the base standards, and advance this work through the IETF standards track process. A number of editorial improvements were made, the RFC 2119 [10] conventions applied, and the current RFC boilerplate added. The following substantive changes were made. None of them is believed to obsolete implementations of RFC 1483:
本备忘录取代RFC 1483。其目的是消除年代错误，澄清实施者发现的或基础标准变更产生的歧义，并通过IETF标准跟踪过程推进这项工作。进行了大量编辑改进，应用了RFC 2119[10]约定，并添加了当前的RFC样板。作出了以下实质性改变。其中没有一个被认为是RFC 1483的过时实现：
-- usage of NLPID encapsulation is clarified in terms of the RFC 2119 conventions
--NLPID封装的使用根据RFC2119约定进行了说明
-- a pointer to RFC 2364 is added to cover the case of PPP over ATM
--添加了指向RFC 2364的指针，以涵盖ATM上的PPP情况
-- RFC 1755 and RFC 2331 are referenced to describe how encapsulations are negotiated, rather than a long-obsolete CCITT (now ITU-T) working document and references to work then in progress
--参考RFC 1755和RFC 2331来描述封装是如何协商的，而不是一份过时已久的CCITT（现在的ITU-T）工作文件和当时正在进行的工作参考
-- usage of AAL5 is now a reference to ITU-T I.363.5. Options created in AAL5 since the publication of RFC 1483 are selected.
--AAL5的使用现在参考了ITU-T I.363.5。选择自RFC 1483发布以来在AAL5中创建的选项。
-- formatting of routed NLPID-formatted PDUs (which are called "routed ISO PDUs" in RFC 1483) is clarified
--阐明了路由NLPID格式PDU（在RFC 1483中称为“路由ISO PDU”）的格式
-- clarification is provided concerning the use of padding between the PID and MAC destination address in bridged PDUs and the bit ordering of the MAC address.
--提供了关于桥接pdu中PID和MAC目的地址之间填充的使用以及MAC地址的位顺序的说明。
-- clarification is provided concerning the use of padding of Ethernet/802.3 frames
--对以太网/802.3帧填充的使用进行了说明
-- a new encapuslation for VPNs is added
--添加了一个新的VPN封装
-- substantive security considerations were added
--增加了实质性的安全考虑
-- a new appendix D provides a summary of applications of multiprotocol over ATM
--新附录D概述了ATM上的多协议应用
Authors' Addresses
作者地址
Dan Grossman Motorola, Inc. 20 Cabot Blvd. Mansfield, MA 02048
丹格罗斯曼摩托罗拉公司，卡博特大道20号。马萨诸塞州曼斯菲尔德02048
EMail: dan@dma.isg.mot.com
EMail: dan@dma.isg.mot.com
Juha Heinanen Telia Finland Myyrmaentie 2 01600 Vantaa, Finland
朱哈·海纳南·泰利亚芬兰迈尔马恩蒂2 01600芬兰万塔
EMail: jh@telia.fi
EMail: jh@telia.fi
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。