Network Working Group L. Martini
Request for Comments: 4618 E. Rosen
Category: Standards Track Cisco Systems, Inc.
G. Heron
A. Malis
Tellabs
September 2006
Network Working Group L. Martini
Request for Comments: 4618 E. Rosen
Category: Standards Track Cisco Systems, Inc.
G. Heron
A. Malis
Tellabs
September 2006
Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks
通过MPLS网络传输PPP/高级数据链路控制（HDLC）的封装方法
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 (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
A pseudowire (PW) can be used to carry Point to Point Protocol (PPP) or High-Level Data Link Control (HDLC) Protocol Data Units over a Multiprotocol Label Switching (MPLS) network without terminating the PPP/HDLC protocol. This enables service providers to offer "emulated" HDLC, or PPP link services over existing MPLS networks. This document specifies the encapsulation of PPP/HDLC Packet Data Units (PDUs) within a pseudowire.
伪线（PW）可用于在多协议标签交换（MPLS）网络上承载点对点协议（PPP）或高级数据链路控制（HDLC）协议数据单元，而无需终止PPP/HDLC协议。这使服务提供商能够在现有MPLS网络上提供“模拟”HDLC或PPP链路服务。本文件规定了PPP/HDLC分组数据单元（PDU）在伪线中的封装。
Table of Contents
目录
1. Introduction ....................................................2
2. Specification of Requirements ...................................2
3. Applicability Statement .........................................5
4. General Encapsulation Method ....................................6
4.1. The Control Word ...........................................6
4.2. MTU Requirements ...........................................8
5. Protocol-Specific Details .......................................9
5.1. HDLC .......................................................9
5.2. Frame Relay Port Mode ......................................9
5.3. PPP .......................................................10
6. Using an MPLS Label as the Demultiplexer Field .................11
6.1. MPLS Shim EXP Bit Values ..................................11
6.2. MPLS Shim S Bit Value .....................................11
7. Congestion Control .............................................12
8. IANA Considerations ............................................12
9. Security Considerations ........................................12
10. Normative References ..........................................13
11. Informative References ........................................13
1. Introduction ....................................................2
2. Specification of Requirements ...................................2
3. Applicability Statement .........................................5
4. General Encapsulation Method ....................................6
4.1. The Control Word ...........................................6
4.2. MTU Requirements ...........................................8
5. Protocol-Specific Details .......................................9
5.1. HDLC .......................................................9
5.2. Frame Relay Port Mode ......................................9
5.3. PPP .......................................................10
6. Using an MPLS Label as the Demultiplexer Field .................11
6.1. MPLS Shim EXP Bit Values ..................................11
6.2. MPLS Shim S Bit Value .....................................11
7. Congestion Control .............................................12
8. IANA Considerations ............................................12
9. Security Considerations ........................................12
10. Normative References ..........................................13
11. Informative References ........................................13
A PPP/HDLC pseudowire (PW) allows PPP/HDLC Protocol Data Units (PDUs) to be carried over an MPLS network. In addressing the issues associated with carrying a PPP/HDLC PDU over an MPLS network, this document assumes that a PW has been set up by some means outside the scope of this document. This may be via manual configuration, or using a signaling protocol such as that defined in [RFC4447].
PPP/HDLC伪线（PW）允许通过MPLS网络承载PPP/HDLC协议数据单元（PDU）。在解决与通过MPLS网络承载PPP/HDLC PDU相关的问题时，本文件假设已通过本文件范围之外的某种方式建立了PW。这可以通过手动配置，或使用[RFC4447]中定义的信令协议。
The following figure describes the reference models that are derived from [RFC3985] to support the HDLC/PPP PW emulated services. The reader is also assumed to be familiar with the content of the [RFC3985] document.
下图描述了从[RFC3985]衍生出来的支持HDLC/PPP PW模拟服务的参考模型。假定读者熟悉[RFC3985]文档的内容。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
|<-------------- Emulated Service ---------------->|
| |
| |<------- Pseudowire ------->| |
| | | |
| | |<-- PSN Tunnel -->| | |
| V V V V |
V AC +----+ +----+ AC V
+-----+ | | PE1|==================| PE2| | +-----+
| |----------|............PW1.............|----------| |
| CE1 | | | | | | | | CE2 |
| |----------|............PW2.............|----------| |
+-----+ ^ | | |==================| | | ^ +-----+
^ | +----+ +----+ | | ^
| | Provider Edge 1 Provider Edge 2 | |
| | | |
Customer | | Customer
Edge 1 | | Edge 2
| |
| |
native HDLC/PPP service native HDLC/PPP service
|<-------------- Emulated Service ---------------->|
| |
| |<------- Pseudowire ------->| |
| | | |
| | |<-- PSN Tunnel -->| | |
| V V V V |
V AC +----+ +----+ AC V
+-----+ | | PE1|==================| PE2| | +-----+
| |----------|............PW1.............|----------| |
| CE1 | | | | | | | | CE2 |
| |----------|............PW2.............|----------| |
+-----+ ^ | | |==================| | | ^ +-----+
^ | +----+ +----+ | | ^
| | Provider Edge 1 Provider Edge 2 | |
| | | |
Customer | | Customer
Edge 1 | | Edge 2
| |
| |
native HDLC/PPP service native HDLC/PPP service
Figure 1. PWE3 HDLC/PPP interface reference configuration
图1。PWE3 HDLC/PPP接口参考配置
This document specifies the emulated PW encapsulation for PPP and HDLC; however, quality of service related issues are not discussed in this document. For the purpose of the discussion in this document, PE1 will be defined as the ingress router and PE2 as the egress router. A layer 2 PDU will be received at PE1, encapsulated at PE1, transported across the network, decapsulated at PE2, and transmitted out on an attachment circuit at PE2.
本文件规定了PPP和HDLC的模拟PW封装；但是，本文档中未讨论与服务质量相关的问题。出于本文件讨论的目的，将PE1定义为入口路由器，将PE2定义为出口路由器。第2层PDU将在PE1处接收，在PE1处封装，通过网络传输，在PE2处解封装，并在PE2处的连接电路上发送出去。
The following reference model describes the termination point of each end of the PW within the PE:
以下参考模型描述了PE内PW各端的终止点：
+-----------------------------------+
| PE |
+---+ +-+ +-----+ +------+ +------+ +-+
| | |P| | | |PW ter| | PSN | |P|
| |<==|h|<=| NSP |<=|minati|<=|Tunnel|<=|h|<== From PSN
| | |y| | | |on | | | |y|
| C | +-+ +-----+ +------+ +------+ +-+
| E | | |
| | +-+ +-----+ +------+ +------+ +-+
| | |P| | | |PW ter| | PSN | |P|
| |==>|h|=>| NSP |=>|minati|=>|Tunnel|=>|h|==> To PSN
| | |y| | | |on | | | |y|
+---+ +-+ +-----+ +------+ +------+ +-+
| |
+-----------------------------------+
^ ^ ^
| | |
A B C
+-----------------------------------+
| PE |
+---+ +-+ +-----+ +------+ +------+ +-+
| | |P| | | |PW ter| | PSN | |P|
| |<==|h|<=| NSP |<=|minati|<=|Tunnel|<=|h|<== From PSN
| | |y| | | |on | | | |y|
| C | +-+ +-----+ +------+ +------+ +-+
| E | | |
| | +-+ +-----+ +------+ +------+ +-+
| | |P| | | |PW ter| | PSN | |P|
| |==>|h|=>| NSP |=>|minati|=>|Tunnel|=>|h|==> To PSN
| | |y| | | |on | | | |y|
+---+ +-+ +-----+ +------+ +------+ +-+
| |
+-----------------------------------+
^ ^ ^
| | |
A B C
Figure 2. PW reference diagram
图2。PW参考图
The PW terminates at a logical port within the PE, defined at point B in the above diagram. This port provides an HDLC Native Service Processing function that will deliver each PPP/HDLC packet that is received at point A, unaltered, to the point A in the corresponding PE at the other end of the PW.
PW终止于PE内的逻辑端口，在上图中的点B处定义。该端口提供HDLC本机服务处理功能，该功能将在点A处接收的每个PPP/HDLC数据包原封不动地传送到PW另一端相应PE中的点A。
The Native Service Processing (NSP) function includes packet processing that is required for the PPP/HDLC packets that are forwarded to the PW termination point. Such functions may include bit stuffing, PW-PW bridging, L2 encapsulation, shaping, and policing. These functions are specific to the native packet technology and may not be required for the PW emulation service.
本机服务处理（NSP）功能包括转发到PW终止点的PPP/HDLC数据包所需的数据包处理。这些功能可能包括位填充、PW-PW桥接、L2封装、整形和监管。这些功能特定于本机数据包技术，PW仿真服务可能不需要这些功能。
The points to the left of B, including the physical layer between the CE and PE, and any adaptation (NSP) functions between it and the PW terminations, are outside of the scope of PWE3 and are not defined here.
B左侧的点，包括CE和PE之间的物理层，以及它与PW终端之间的任何适配（NSP）功能，不在PWE3的范围内，此处不作定义。
"PW Termination", between A and B, represents the operations for setting up and maintaining the PW, and for encapsulating and decapsulating the PPP/HDLC packets as necessary to transmit them across the MPLS network.
A和B之间的“PW终止”表示用于设置和维护PW的操作，以及用于在必要时封装和解封PPP/HDLC数据包以通过MPLS网络传输它们的操作。
PPP/HDLC transport over PW service is not intended to emulate the traditional PPP or HDLC service perfectly, but it can be used for some applications that require PPP or HDLC transport service.
PW服务上的PPP/HDLC传输并不是为了完美地模拟传统的PPP或HDLC服务，但它可以用于一些需要PPP或HDLC传输服务的应用。
The applicability statements in [RFC4619] also apply to the Frame Relay port mode PW described in this document.
[RFC4619]中的适用性声明也适用于本文件中描述的帧中继端口模式PW。
The following are notable differences between traditional PPP/HDLC service, and the protocol described in this document:
以下是传统PPP/HDLC服务与本文件所述协议之间的显著差异：
- Packet ordering can be preserved using the OPTIONAL sequence field in the control word; however, implementations are not required to support this feature.
- 可以使用控制字中的可选序列字段来保持分组顺序；但是，不需要实现来支持此功能。
- The Quality of Service model for traditional PPP/HDLC links can be emulated, however this is outside the scope of this document.
- 可以模拟传统PPP/HDLC链路的服务质量模型，但这超出了本文档的范围。
- A Frame Relay Port mode PW, or HDLC PW, does not process any frame relay status messages or alarms as described in [Q922] [Q933].
- 帧中继端口模式PW或HDLC PW不处理[Q922][Q933]中所述的任何帧中继状态消息或警报。
- The HDLC Flags are processed locally in the PE connected to the attachment circuit.
- HDLC标志在连接至连接电路的PE中进行本地处理。
The HDLC mode is suitable for port-to-port transport of Frame Relay User Network Interface (UNI) or Network Node Interface (NNI) traffic. Since all packets are passed in a largely transparent manner over the HDLC PW, any protocol that has HDLC-like framing may use the HDLC PW mode, including PPP, Frame-Relay, and X.25. Exceptions include cases where direct access to the HDLC interface is required, or modes that operate on the flags, Frame Check Sequence (FCS), or bit/byte unstuffing that is performed before sending the HDLC PDU over the PW. An example of this is PPP Asynchronous-Control-Character-Map (ACCM) negotiation.
HDLC模式适用于帧中继用户网络接口（UNI）或网络节点接口（NNI）流量的端口到端口传输。由于所有分组在HDLC PW上以基本透明的方式传递，因此具有类似HDLC的帧的任何协议都可以使用HDLC PW模式，包括PPP、帧中继和X.25。例外情况包括需要直接访问HDLC接口的情况，或在通过PW发送HDLC PDU之前执行的标志、帧检查序列（FCS）或位/字节取消缓冲的模式。PPP异步控制字符映射（ACCM）协商就是一个例子。
For PPP, since media-specific framing is not carried, the following options will not operate correctly if the PPP peers attempt to negotiate them:
对于PPP，由于未进行媒体特定帧，如果PPP对等方试图协商，则以下选项将无法正常运行：
- Frame Check Sequence (FCS) Alternatives
- 帧检查序列（FCS）备选方案
- Address-and-Control-Field-Compression (ACFC)
- 地址和控制字段压缩（ACFC）
- Asynchronous-Control-Character-Map (ACCM)
- 异步控制字符映射（ACCM）
Note, also, that PW LSP Interface MTU negotiation, as specified in [RFC4447], is not affected by PPP Maximum Receive Unit (MRU)
另请注意，[RFC4447]中规定的PW LSP接口MTU协商不受PPP最大接收单元（MRU）的影响
advertisement. Thus, if a PPP peer sends a PDU with a length in excess of that negotiated for the PW tunnel, that PDU will be discarded by the ingress router.
广告因此，如果PPP对等方发送的PDU长度超过为PW隧道协商的长度，则该PDU将被入口路由器丢弃。
This section describes the general encapsulation format for PPP and HDLC packets over MPLS pseudowires.
本节介绍通过MPLS伪线的PPP和HDLC数据包的通用封装格式。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSN Transport Header (As Required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pseudowire Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPP/HDLC Service Payload |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSN Transport Header (As Required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pseudowire Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPP/HDLC Service Payload |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. General format for PPP/HDLC encapsulation over PSNs
图3。PSN上PPP/HDLC封装的通用格式
The PSN Transport Header depends on the particular tunneling technology in use. This header is used to transport the encapsulated PPP/HDLC information through the packet-switched core.
PSN传输头取决于使用的特定隧道技术。该报头用于通过分组交换核心传输封装的PPP/HDLC信息。
The Pseudowire Header identifies a particular PPP/HDLC service on a tunnel. In case the of MPLS, the Pseudowire Header is the MPLS label at the bottom of the MPLS label stack.
伪线报头标识隧道上的特定PPP/HDLC服务。对于MPLS，伪线报头是MPLS标签堆栈底部的MPLS标签。
The Control Word is inserted before the PPP/HDLC service payload. It may contain a length and sequence number.
控制字插入PPP/HDLC服务有效负载之前。它可能包含长度和序列号。
There are four requirements that may need to be satisfied when transporting layer 2 protocols over an MPLS PSN:
在MPLS PSN上传输第2层协议时，可能需要满足四个要求：
i. Sequentiality may need to be preserved.
i. 可能需要保留顺序性。
ii. Small packets may need to be padded in order to be transmitted on a medium where the minimum transport unit is larger than the actual packet size.
二、为了在最小传输单元大于实际分组大小的介质上传输，可能需要填充小分组。
iii. Control bits carried in the header of the layer 2 packet may need to be transported.
iii.可能需要传输层2分组的报头中携带的控制比特。
iv. Creating an in-band associated channel for operation and maintenance communications.
iv.为操作和维护通信创建带内相关信道。
The Control Word defined in this section is based on the Generic PW MPLS Control Word, as defined in [RFC4385]. It provides the ability to sequence individual packets on the PW and avoidance of equal-cost multiple-path load-balancing (ECMP) [RFC2992] and enables Operations and Management (OAM) mechanisms, including [VCCV].
本节中定义的控制字基于[RFC4385]中定义的通用PW MPLS控制字。它能够对PW上的各个数据包进行排序，避免等成本多路径负载平衡（ECMP）[RFC2992]，并启用操作和管理（OAM）机制，包括[VCCV]。
[RFC4385] states, "If a PW is sensitive to packet mis-ordering and is being carried over an MPLS PSN that uses the contents of the MPLS payload to select the ECMP path, it MUST employ a mechanism which prevents packet mis-ordering." This is necessary because ECMP implementations may examine the first nibble after the MPLS label stack to determine whether the content of the labeled packet is IP. Thus, if the PPP protocol number of a PPP packet carried over the PW without a control word present begins with 0x4 or 0x6, it could be mistaken for an IPv4 or IPv6 packet. This could, depending on the configuration and topology of the MPLS network, lead to a situation where all packets for a given PW do not follow the same path. This may increase out-of-order packets on a given PW or cause OAM packets to follow a different path from that of actual traffic.
[RFC4385]指出，“如果PW对数据包错误排序很敏感，并且正在通过使用MPLS有效负载的内容来选择ECMP路径的MPLS PSN进行传输，则它必须采用防止数据包错误排序的机制。”这是必要的，因为ECMP实现可能会检查MPLS标签堆栈之后的第一个半字节，以确定标记数据包的内容是否为IP。因此，如果不存在控制字而通过PW携带的PPP分组的PPP协议号以0x4或0x6开头，则可能会将其误认为是IPv4或IPv6分组。根据MPLS网络的配置和拓扑，这可能导致给定PW的所有数据包不遵循相同路径的情况。这可能会增加给定PW上的无序数据包，或导致OAM数据包遵循与实际流量不同的路径。
The features that the control word provides may not be needed for a given PPP/HDLC PW. For example, ECMP may not be present or active on a given MPLS network, and strict packet sequencing may not be required. If this is the case, the control word provides little value and is therefore optional. Early PPP/HDLC PW implementations have been deployed that do not include a control word or the ability to process one if present. To aid in backwards compatibility, future implementations MUST be able to send and receive packets without the control word.
给定PPP/HDLC PW可能不需要控制字提供的特性。例如，ECMP在给定MPLS网络上可能不存在或不活动，并且可能不需要严格的分组排序。如果是这种情况，控制字提供的值很小，因此是可选的。早期的PPP/HDLC PW实现已经部署，不包括控制字或处理控制字（如果存在）的能力。为了帮助实现向后兼容性，未来的实现必须能够在不使用控制字的情况下发送和接收数据包。
In all cases, the egress PE MUST be aware of whether the ingress PE will send a control word over a specific PW. This may be achieved by configuration of the PEs, or by signaling, as defined in [RFC4447].
在所有情况下，出口PE必须知道入口PE是否将通过特定PW发送控制字。如[RFC4447]中所定义，这可以通过配置PEs或通过信令来实现。
The control word is defined as follows:
控制字的定义如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0|0 0 0 0|FRG| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0|0 0 0 0|FRG| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. MPLS PWE3 control word
图4。MPLS PWE3控制字
In the above diagram, the first 4 bits are set to 0 in indicate a CW [RFC4385].
在上图中，前4位设置为0表示CW[RFC4385]。
The next 4 bits provide space for carrying protocol-specific flags. These are not used for HDLC/PPP, and they MUST be set to 0 for transmitting and MUST be ignored upon receipt.
接下来的4位提供用于承载协议特定标志的空间。这些不用于HDLC/PPP，传输时必须将其设置为0，接收时必须忽略。
The next 2 bits are defined in [RFC4623].
接下来的2位在[RFC4623]中定义。
The next 6 bits provide a length field, which is used as follows: If the packet's length (defined as the length of the layer 2 payload plus the length of the control word) is less than 64 bytes, the length field MUST be set to the packet's length. Otherwise, the length field MUST be set to zero. The value of the length field, if not zero, is used to remove any padding that may have been added by the MPLS network. If the control word is used and padding was added to the packet in transit on the MPLS network, then when the packet reaches the egress PE the padding MUST be removed before forwarding the packet.
接下来的6位提供一个长度字段，其使用如下：如果数据包的长度（定义为第2层有效负载的长度加上控制字的长度）小于64字节，则长度字段必须设置为数据包的长度。否则，长度字段必须设置为零。长度字段的值（如果不是零）用于删除MPLS网络可能添加的任何填充。如果使用了控制字并且在MPLS网络上向传输中的数据包添加了填充，则当数据包到达出口PE时，必须在转发数据包之前删除填充。
The next 16 bits provide a sequence number that can be used to guarantee ordered packet delivery. The processing of the sequence number field is OPTIONAL.[RFC4385]
接下来的16位提供了一个序列号，可以用来保证有序的数据包传递。序列号字段的处理是可选的。[RFC4385]
The sequence number space is a 16-bit, unsigned circular space. The sequence number value 0 is used to indicate an unsequenced packet.[RFC4385]
序列号空间是一个16位的无符号循环空间。序列号值0用于指示未排序的数据包。[RFC4385]
The procedures described in Section 4 of [RFC4385] MUST be followed to process the sequence number field.
必须遵循[RFC4385]第4节中描述的程序来处理序列号字段。
The network MUST be configured with an MTU that is sufficient to transport the largest encapsulation packets. When MPLS is used as the tunneling protocol, for example, this is likely to be 12 or more bytes greater than the largest packet size. The methodology described in [RFC4623] MAY be used to fragment encapsulated packets that exceed the PSN MTU. However, if [RFC4623] is not used, then if the ingress router determines that an encapsulated layer 2 PDU exceeds the MTU of the PSN tunnel through which it must be sent, the PDU MUST be dropped.
网络必须配置足以传输最大封装数据包的MTU。例如，当MPLS用作隧道协议时，这可能比最大分组大小大12个或更多字节。[RFC4623]中描述的方法可用于分割超过PSN MTU的封装包。然而，如果未使用[RFC4623]，则如果入口路由器确定封装的第2层PDU超过必须通过其发送的PSN隧道的MTU，则必须丢弃PDU。
If a packet is received on the attachment circuit that exceeds the interface MTU subTLV value [RFC4447], it MUST be dropped. It is also RECOMMENDED that PPP devices be configured to not negotiate PPP MRUs larger than that of the AC MTU.
如果在连接电路上接收到超过接口MTU subTLV值[RFC4447]的数据包，则必须丢弃该数据包。还建议将PPP设备配置为不协商大于AC MTU的PPP MRU。
HDLC mode provides port-to-port transport of HDLC-encapsulated traffic. The HDLC PDU is transported in its entirety, including the HDLC address and control fields, but excluding HDLC flags and the FCS. Bit/Byte stuffing is undone. If the OPTIONAL control word is used, then the flag bits in the control word are not used and MUST be set to 0 for transmitting and MUST be ignored upon receipt.
HDLC模式提供HDLC封装流量的端口到端口传输。HDLC PDU整体传输，包括HDLC地址和控制字段，但不包括HDLC标志和FCS。位/字节填充被撤消。如果使用可选控制字，则控制字中的标志位不使用，必须设置为0以进行传输，并且在接收时必须忽略。
When the PE detects a status change in the attachment circuit status, such as an attachment circuit physical link failure, or if the AC is administratively disabled, the PE MUST send the appropriate PW status notification message that corresponds to the HDLC AC status. In a similar manner, the local PW status MUST also be reflected in a respective PW status notification message, as described in [RFC4447].
当PE检测到附件电路状态的状态变化时，例如附件电路物理链路故障，或者如果AC被管理性禁用，则PE必须发送与HDLC AC状态相对应的适当PW状态通知消息。以类似的方式，本地PW状态也必须反映在相应的PW状态通知消息中，如[RFC4447]中所述。
The PW of type 0x0006 "HDLC" will be used to transport HDLC packets. The IANA allocation registry of "Pseudowire Type" is defined in the IANA allocation document for PWs [RFC4446] along with initial allocated values.
0x0006“HDLC”类型的PW将用于传输HDLC数据包。PWs[RFC4446]的IANA分配文档中定义了“伪导线类型”的IANA分配注册表以及初始分配值。
Figure 5 illustrates the concept of frame relay port mode or many-to-one mapping, which is an OPTIONAL capability.
图5说明了帧中继端口模式或多对一映射的概念，这是一种可选功能。
Figure 5a shows two frame relay devices physically connected with a frame relay UNI or NNI. Between their two ports, P1 and P2, n frame relay Virtual Circuits (VCs) are configured.
图5a显示了与帧中继UNI或NNI物理连接的两个帧中继设备。在它们的两个端口P1和P2之间，配置了n帧中继虚拟电路（VCs）。
Figure 5b shows the replacement of the physical frame relay interface with a pair of PEs and a PW between them. The interface between a Frame Relay (FR) device and a PE is either an FR UNI or an NNI. All FR VCs carried over the interface are mapped into one HDLC PW. The standard frame relay Link Management Interface (LMI) procedures happen directly between the CEs. Thus with port mode, we have many-to-one mapping between FR VCs and a PW.
图5b显示了用一对PEs和它们之间的PW替换物理帧中继接口。帧中继（FR）设备和PE之间的接口是FR UNI或NNI。通过接口携带的所有FR VCs映射到一个HDLC PW中。标准帧中继链路管理接口（LMI）程序直接发生在CEs之间。因此，在端口模式下，FR VCs和PW之间存在多对一映射。
+------+ +-------+
| FR | | FR |
|device| FR UNI/NNI | device|
| [P1]------------------------[P2] |
| | carrying n FR VCs | |
+------+ +-------+
+------+ +-------+
| FR | | FR |
|device| FR UNI/NNI | device|
| [P1]------------------------[P2] |
| | carrying n FR VCs | |
+------+ +-------+
[Pn]: A port
[请注意]：港口
Figure 5a. FR interface between two FR devices
图5a。两个FR设备之间的FR接口
|<---------------------------->|
| |
+----+ +----+
+------+ | | One PW | | +------+
| | | |==================| | | |
| FR | FR | PE1| carrying n FR VCs| PE2| FR | FR |
|device|----------| | | |---------|device|
| CE1 | UNI/NNI | | | | UNI/NNI | CE2 |
+------+ +----+ +----+ +------+
| |
|<----------------------------------------------->|
n FR VCs
|<---------------------------->|
| |
+----+ +----+
+------+ | | One PW | | +------+
| | | |==================| | | |
| FR | FR | PE1| carrying n FR VCs| PE2| FR | FR |
|device|----------| | | |---------|device|
| CE1 | UNI/NNI | | | | UNI/NNI | CE2 |
+------+ +----+ +----+ +------+
| |
|<----------------------------------------------->|
n FR VCs
Figure 5b. Pseudowires replacing the FR interface
图5b。取代FR接口的伪导线
FR VCs are not visible individually to a PE; there is no configuration of individual FR VC in a PE. A PE processes the set of FR VCs assigned to a port as an aggregate.
FR VCs对PE不可见；PE中没有单个FR VC的配置。PE将分配给端口的FR VCs集作为聚合进行处理。
FR port mode provides transport between two PEs of a complete FR frame using the same encapsulation as described above for HDLC mode.
FR端口模式使用与上述HDLC模式相同的封装在完整FR帧的两个PE之间提供传输。
Although frame relay port mode shares the same encapsulation as HDLC mode, a different PW type is allocated in [RFC4446]: 0x000F Frame-Relay Port mode.
尽管帧中继端口模式与HDLC模式共享相同的封装，但在[RFC4446]：0x000F帧中继端口模式中分配了不同的PW类型。
All other aspects of this PW type are identical to the HDLC PW encapsulation described above.
该PW类型的所有其他方面与上述HDLC PW封装相同。
PPP mode provides point-to-point transport of PPP-encapsulated traffic, as specified in [RFC1661]. The PPP PDU is transported in its entirety, including the protocol field (whether compressed using Protocol Field Compression or not), but excluding any media-specific framing information, such as HDLC address and control fields or FCS.
PPP模式提供PPP封装流量的点对点传输，如[RFC1661]所述。PPP PDU整体传输，包括协议字段（无论是否使用协议字段压缩进行压缩），但不包括任何特定于媒体的帧信息，如HDLC地址和控制字段或FCS。
If the OPTIONAL control word is used, then the flag bits in the control word are not used and MUST be set to 0 for transmitting and MUST be ignored upon receipt.
如果使用可选控制字，则控制字中的标志位不使用，必须设置为0以进行传输，并且在接收时必须忽略。
When the PE detects a status change in the attachment circuit (AC) status, such as an attachment circuit physical link failure, or if the AC is administratively disabled, the PE MUST send the appropriate PW status notification message that corresponds to the PPP AC status. Note that PPP negotiation status is transparent to the PW and MUST NOT be communicated to the remote MPLS PE. In a similar manner, the local PW status MUST also be reflected in a respective PW status notification message, as described in [RFC4447].
When the PE detects a status change in the attachment circuit (AC) status, such as an attachment circuit physical link failure, or if the AC is administratively disabled, the PE MUST send the appropriate PW status notification message that corresponds to the PPP AC status. Note that PPP negotiation status is transparent to the PW and MUST NOT be communicated to the remote MPLS PE. In a similar manner, the local PW status MUST also be reflected in a respective PW status notification message, as described in [RFC4447].translate error, please retry
A PW of type 0x0007 "PPP" will be used to transport PPP packets.
0x0007“PPP”类型的PW将用于传输PPP数据包。
The IANA allocation registry of "Pseudowire Type" is defined in the IANA allocation document for PWs [RFC4446] along with initial allocated values.
PWs[RFC4446]的IANA分配文档中定义了“伪导线类型”的IANA分配注册表以及初始分配值。
To use an MPLS label as the demultiplexer field, a 32-bit label stack entry [RFC3032] is simply prepended to the emulated PW encapsulation and thus appears as the bottom label of an MPLS label stack. This label may be called the "PW label". The particular emulated PW identified by a particular label value must be agreed by the ingress and egress LSRs, either by signaling (e.g., via the methods of [RFC4447]) or by configuration. Other fields of the label stack entry are set as described below.
要使用MPLS标签作为解复用器字段，32位标签堆栈条目[RFC3032]只需在模拟PW封装前加上前缀，从而显示为MPLS标签堆栈的底部标签。该标签可称为“PW标签”。由特定标签值标识的特定仿真PW必须由入口和出口LSR通过信令（例如，通过[RFC4447]的方法）或配置达成一致。标签堆栈项的其他字段设置如下所述。
If it is desired to carry Quality of Service information, the Quality of Service information SHOULD be represented in the EXP field of the PW label. If more than one MPLS label is imposed by the ingress LSR, the EXP field of any labels higher in the stack MUST also carry the same value.
如果需要携带服务质量信息，服务质量信息应在PW标签的EXP字段中表示。如果入口LSR施加了多个MPLS标签，则堆栈中任何较高标签的EXP字段也必须具有相同的值。
The ingress LSR, PE1, MUST set the S bit of the PW label to a value of 1 to denote that the PW label is at the bottom of the stack.
入口LSR PE1必须将PW标签的S位设置为值1，以表示PW标签位于堆栈底部。
As explained in [RFC3985], the PSN carrying the PW may be subject to congestion, the characteristics of which are dependent upon PSN type, network architecture, configuration, and loading. During congestion, the PSN may exhibit packet loss that will impact the service carried by the PPP/HLDC PW. In addition, since PPP/HDLC PWs carry an unspecified type of services across the PSN, they cannot behave in a TCP-friendly manner prescribed by [RFC2914]. In the presence of services that reduce transmission rate, PPP/HDLC PWs will thus consume more than their fair share and SHOULD be halted.
如[RFC3985]中所述，承载PW的PSN可能会发生拥塞，其特征取决于PSN类型、网络架构、配置和负载。在拥塞期间，PSN可能表现出分组丢失，这将影响PPP/HLDC PW承载的服务。此外，由于PPP/HDLC PW在PSN中承载未指定类型的服务，因此它们不能以[RFC2914]规定的TCP友好方式运行。在存在降低传输速率的服务的情况下，PPP/HDLC PW将因此消耗超过其公平份额的资源，应停止使用。
Whenever possible, PPP/HDLC PWs should be run over traffic-engineered PSNs providing bandwidth allocation and admission control mechanisms. IntServ-enabled domains providing the Guaranteed Service (GS) or DiffServ-enabled domains using EF (expedited forwarding) are examples of traffic-engineered PSNs. Such PSNs will minimize loss and delay while providing some degree of isolation of the PPP/HDLC PW's effects from neighboring streams.
只要可能，PPP/HDLC PW应在提供带宽分配和准入控制机制的流量工程PSN上运行。提供保证服务（GS）的支持IntServ的域或使用EF（加速转发）的支持DiffServ的域是流量工程PSN的示例。此类PSN将最大限度地减少损失和延迟，同时提供PPP/HDLC PW效应与相邻流的某种程度的隔离。
The PEs SHOULD monitor for congestion (by using explicit congestion notification, [VCCV], or by measuring packet loss) in order to ensure that the service using the PPP/HDLC PW may be maintained. When significant congestion is detected, the PPP/HDLC PW SHOULD be administratively disabled. If the PW has been set up using the protocol defined in [RFC4447], then procedures specified in [RFC4447] for status notification can be used to disable packet transmission on the ingress PE from the egress PE. The PW may be restarted by manual intervention, or by automatic means after an appropriate waiting time.
PEs应监测拥塞情况（通过使用显式拥塞通知[VCCV]或测量数据包丢失），以确保使用PPP/HDLC PW的服务可以得到维护。当检测到严重拥塞时，应在管理上禁用PPP/HDLC PW。如果已使用[RFC4447]中定义的协议设置PW，则[RFC4447]中指定的状态通知程序可用于禁用入口PE上来自出口PE的数据包传输。PW可通过手动干预或在适当的等待时间后通过自动方式重新启动。
This document has no new IANA Actions. All necessary IANA actions have already been included in [RFC4446].
本文档没有新的IANA操作。[RFC4446]中已包含所有必要的IANA措施。
The PPP and HDLC pseudowire type is subject to all the general security considerations discussed in [RFC3985][RFC4447]. This document specifies only encapsulations, and not the protocols that may be used to carry the encapsulated packets across the MPLS network. Each such protocol may have its own set of security issues, but those issues are not affected by the encapsulations specified herein.
PPP和HDLC伪线类型受[RFC3985][RFC4447]中讨论的所有一般安全注意事项的约束。本文档仅指定封装，而不指定可用于跨MPLS网络传输封装数据包的协议。每个这样的协议可能有其自己的一组安全问题，但是这些问题不受本文指定的封装的影响。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]辛普森，W.“点对点协议（PPP）”，标准51，RFC1661，1994年7月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.，和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月。
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006.
[RFC4385]Bryant，S.，Swallow，G.，Martini，L.，和D.McPherson，“用于MPLS PSN的伪线仿真边到边（PWE3）控制字”，RFC 43852006年2月。
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC4446]Martini，L.，“伪线边到边仿真（PWE3）的IANA分配”，BCP 116，RFC 4446，2006年4月。
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4447]Martini，L.，Rosen，E.，El Aawar，N.，Smith，T.，和G.Heron，“使用标签分发协议（LDP）的伪线设置和维护”，RFC 4447，2006年4月。
[RFC4619] Martini, L., Ed., Kawa, C., Ed., and A. Malis, Ed., "Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks", RFC 4619, September 2006.
[RFC4619]Martini，L.，Ed.，Kawa，C.，Ed.，和A.Malis，Ed.，“多协议标签交换（MPLS）网络上帧中继传输的封装方法”，RFC 4619，2006年9月。
[RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to-Edge (PWE3) Fragmentation and Reassembly", RFC 4623, August 2006.
[RFC4623]Malis，A.和M.Townsley，“伪线仿真边到边（PWE3）碎片化和重组”，RFC 46232006年8月。
[Q922] ITU-T Recommendation Q.922 Specification for Frame Mode Basic call control, ITU Geneva 1995.
[Q922]ITU-T建议Q.922帧模式基本呼叫控制规范，ITU日内瓦1995。
[Q933] ITU-T Recommendation Q.933 Specification for Frame Mode Basic call control, ITU Geneva 2003.
[Q933]ITU-T建议Q.933帧模式基本呼叫控制规范，ITU日内瓦2003。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]Floyd，S.，“拥塞控制原则”，BCP 41，RFC 2914，2000年9月。
[RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path Algorithm", RFC 2992, November 2000.
[RFC2992]Hopps，C.，“等成本多径算法分析”，RFC 2992，2000年11月。
[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985]Bryant，S.，Ed.和P.Pate，Ed.，“伪线仿真边到边（PWE3）架构”，RFC 39852005年3月。
[VCCV] Nadeau, T., et al., "Pseudo Wire Virtual Circuit Connection Verification (VCCV)", Work in Progress, October 2005.
[VCCV]Nadeau，T.，等人，“伪导线虚拟电路连接验证（VCCV）”，正在进行的工作，2005年10月。
Contributing Author Information
投稿人信息
Yeongil Seo 463-1 KT Technology Lab Jeonmin-dong Yusung-gu Daegeon, Korea
韩国全民东宇松古大江Yeongil Seo 463-1 KT技术实验室
EMail: syi1@kt.co.kr
EMail: syi1@kt.co.kr
Toby Smith Laurel Networks, Inc. Omega Corporate Center 1300 Omega Drive Pittsburgh, PA 15205
托比·史密斯·劳雷尔网络公司，宾夕法尼亚州匹兹堡欧米茄大道1300号欧米茄企业中心，邮编15205
EMail: tob@laurelnetworks.com
EMail: tob@laurelnetworks.com
Authors' Addresses
作者地址
Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO, 80112
卢卡·马蒂尼·思科系统公司，地址：科罗拉多州恩格尔伍德东尼科尔斯大道9155号400室，邮编：80112
EMail: lmartini@cisco.com
EMail: lmartini@cisco.com
Giles Heron Tellabs Abbey Place 24-28 Easton Street High Wycombe Bucks HP11 1NT UK
Giles Heron Tellabs Abbey Place 24-28 Easton Street High Wycombe Bucks HP11 1NT英国
EMail: giles.heron@tellabs.com
EMail: giles.heron@tellabs.com
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
Eric C.Rosen Cisco Systems，Inc.马萨诸塞州伯斯堡马萨诸塞大道1414号，邮编01719
EMail: erosen@cisco.com
EMail: erosen@cisco.com
Andrew G. Malis Tellabs 1415 West Diehl Road Naperville, IL 60563
伊利诺伊州纳珀维尔西迪尔路1415号安德鲁·G·马里斯·特拉伯斯，邮编：60563
EMail: Andy.Malis@tellabs.com
EMail: Andy.Malis@tellabs.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。