Network Working Group A. Malis
Request for Comments: 4623 Tellabs
Category: Standards Track M. Townsley
Cisco Systems
August 2006
Network Working Group A. Malis
Request for Comments: 4623 Tellabs
Category: Standards Track M. Townsley
Cisco Systems
August 2006
Pseudowire Emulation Edge-to-Edge (PWE3) Fragmentation and Reassembly
伪线仿真边到边（PWE3）分段和重新组装
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
摘要
This document defines a generalized method of performing fragmentation for use by Pseudowire Emulation Edge-to-Edge (PWE3) protocols and services.
本文档定义了一种执行分段的通用方法，供伪线仿真边缘到边缘（PWE3）协议和服务使用。
Table of Contents
目录
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
3. Alternatives to PWE3 Fragmentation/Reassembly ...................5
4. PWE3 Fragmentation with MPLS ....................................5
4.1. Fragment Bit Locations for MPLS ............................6
4.2. Other Considerations .......................................6
5. PWE3 Fragmentation with L2TP ....................................6
5.1. PW-Specific Fragmentation vs. IP fragmentation .............7
5.2. Advertising Reassembly Support in L2TP .....................7
5.3. L2TP Maximum Receive Unit (MRU) AVP ........................8
5.4. L2TP Maximum Reassembled Receive Unit (MRRU) AVP ...........8
5.5. Fragment Bit Locations for L2TPv3 Encapsulation ............9
5.6. Fragment Bit Locations for L2TPv2 Encapsulation ............9
6. Security Considerations ........................................10
7. IANA Considerations ............................................10
7.1. Control Message Attribute Value Pairs (AVPs) ..............11
7.2. Default L2-Specific Sublayer Bits .........................11
7.3. Leading Bits of the L2TPv2 Message Header .................11
8. Acknowledgements ...............................................11
9. Normative References ...........................................12
10. Informative References ........................................12
Appendix A. Relationship Between This Document and RFC 1990 .......14
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
3. Alternatives to PWE3 Fragmentation/Reassembly ...................5
4. PWE3 Fragmentation with MPLS ....................................5
4.1. Fragment Bit Locations for MPLS ............................6
4.2. Other Considerations .......................................6
5. PWE3 Fragmentation with L2TP ....................................6
5.1. PW-Specific Fragmentation vs. IP fragmentation .............7
5.2. Advertising Reassembly Support in L2TP .....................7
5.3. L2TP Maximum Receive Unit (MRU) AVP ........................8
5.4. L2TP Maximum Reassembled Receive Unit (MRRU) AVP ...........8
5.5. Fragment Bit Locations for L2TPv3 Encapsulation ............9
5.6. Fragment Bit Locations for L2TPv2 Encapsulation ............9
6. Security Considerations ........................................10
7. IANA Considerations ............................................10
7.1. Control Message Attribute Value Pairs (AVPs) ..............11
7.2. Default L2-Specific Sublayer Bits .........................11
7.3. Leading Bits of the L2TPv2 Message Header .................11
8. Acknowledgements ...............................................11
9. Normative References ...........................................12
10. Informative References ........................................12
Appendix A. Relationship Between This Document and RFC 1990 .......14
The Pseudowire Emulation Edge-to-Edge Architecture Document [Architecture] defines a network reference model for PWE3:
伪线仿真边到边架构文档[Architecture]定义了PWE3的网络参考模型：
|<-------------- Emulated Service ---------------->|
| |
| |<------- Pseudowire ------->| |
| | | |
| | |<-- PSN Tunnel -->| | |
| PW End V V V V PW End |
V Service +----+ +----+ Service V
+-----+ | | PE1|==================| PE2| | +-----+
| |----------|............PW1.............|----------| |
| CE1 | | | | | | | | CE2 |
| |----------|............PW2.............|----------| |
+-----+ ^ | | |==================| | | ^ +-----+
^ | +----+ +----+ | | ^
| | Provider Edge 1 Provider Edge 2 | |
| | | |
Customer | | Customer
Edge 1 | | Edge 2
| |
| |
native service native service
|<-------------- Emulated Service ---------------->|
| |
| |<------- Pseudowire ------->| |
| | | |
| | |<-- PSN Tunnel -->| | |
| PW End V V V V PW End |
V Service +----+ +----+ Service V
+-----+ | | PE1|==================| PE2| | +-----+
| |----------|............PW1.............|----------| |
| CE1 | | | | | | | | CE2 |
| |----------|............PW2.............|----------| |
+-----+ ^ | | |==================| | | ^ +-----+
^ | +----+ +----+ | | ^
| | Provider Edge 1 Provider Edge 2 | |
| | | |
Customer | | Customer
Edge 1 | | Edge 2
| |
| |
native service native service
Figure 1: PWE3 Network Reference Model
图1:PWE3网络参考模型
A Pseudowire (PW) payload is normally relayed across the PW as a single IP or MPLS Packet Switched Network (PSN) Protocol Data Unit (PDU). However, there are cases where the combined size of the payload and its associated PWE3 and PSN headers may exceed the PSN path Maximum Transmission Unit (MTU). When a packet exceeds the MTU of a given network, fragmentation and reassembly will allow the packet to traverse the network and reach its intended destination.
伪线（PW）有效载荷通常作为单个IP或MPLS分组交换网络（PSN）协议数据单元（PDU）在PW上中继。然而，在某些情况下，有效载荷及其相关PWE3和PSN报头的组合大小可能超过PSN路径最大传输单元（MTU）。当数据包超过给定网络的MTU时，碎片和重组将允许数据包穿越网络并到达其预期目的地。
The purpose of this document is to define a generalized method of performing fragmentation for use with all PWE3 protocols and services. This method should be utilized only in cases where MTU-management methods fail. Due to the increased processing overhead, fragmentation and reassembly in core network devices should always be considered something to avoid whenever possible.
本文档的目的是定义一种执行分段的通用方法，用于所有PWE3协议和服务。只有在MTU管理方法失败的情况下，才应使用此方法。由于处理开销的增加，应始终考虑尽可能避免核心网络设备中的碎片和重新组装。
The PWE3 fragmentation and reassembly domain is shown in Figure 2:
PWE3碎片和重组域如图2所示：
|<-------------- Emulated Service ---------------->|
| |<---Fragmentation Domain--->| |
| ||<------- Pseudowire ----->|| |
| || || |
| || |<-- PSN Tunnel -->| || |
| PW End VV V V VV PW End |
V Service +----+ +----+ Service V
+-----+ | | PE1|==================| PE2| | +-----+
| |----------|............PW1.............|----------| |
| CE1 | | | | | | | | CE2 |
| |----------|............PW2.............|----------| |
+-----+ ^ | | |==================| | | ^ +-----+
^ | +----+ +----+ | | ^
| | Provider Edge 1 Provider Edge 2 | |
| | | |
Customer | | Customer
Edge 1 | | Edge 2
| |
| |
native service native service
|<-------------- Emulated Service ---------------->|
| |<---Fragmentation Domain--->| |
| ||<------- Pseudowire ----->|| |
| || || |
| || |<-- PSN Tunnel -->| || |
| PW End VV V V VV PW End |
V Service +----+ +----+ Service V
+-----+ | | PE1|==================| PE2| | +-----+
| |----------|............PW1.............|----------| |
| CE1 | | | | | | | | CE2 |
| |----------|............PW2.............|----------| |
+-----+ ^ | | |==================| | | ^ +-----+
^ | +----+ +----+ | | ^
| | Provider Edge 1 Provider Edge 2 | |
| | | |
Customer | | Customer
Edge 1 | | Edge 2
| |
| |
native service native service
Figure 2: PWE3 Fragmentation/Reassembly Domain
图2:PWE3碎片/重组域
Fragmentation takes place in the transmitting PE immediately prior to PW encapsulation, and reassembly takes place in the receiving PE immediately after PW decapsulation.
在PW封装之前，发射PE中立即发生碎片，在PW去封装之后，接收PE中立即发生重新组装。
Since a sequence number is necessary for the fragmentation and reassembly procedures, using the Sequence Number field on fragmented packets is REQUIRED (see Sections 4.1 and 5.5 for the location of the Sequence Number fields for MPLS and L2TPv3 encapsulations, respectively). The order of operation is that first fragmentation is performed, and then the resulting fragments are assigned sequential sequence numbers.
由于分段和重新组装程序需要序列号，因此需要在分段数据包上使用序列号字段（MPLS和L2TPv3封装的序列号字段位置分别见第4.1节和第5.5节）。操作顺序是执行第一个片段，然后为生成的片段分配序列号。
Depending on the specific PWE3 encapsulation in use, the value 0 may not be a part of the sequence number space, in which case its use for fragmentation must follow this same rule: as the sequence number is incremented, it skips zero and wraps from 65535 to 1. Conversely, if the value 0 is part of the sequence space, then the same sequence space is also used for fragmentation and reassembly.
根据使用的特定PWE3封装，值0可能不是序列号空间的一部分，在这种情况下，它用于分段必须遵循相同的规则：随着序列号的增加，它跳过零并从65535换行到1。相反，如果值0是序列空间的一部分，则相同的序列空间也用于分段和重新组装。
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 RFC 2119 [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[关键词]中所述进行解释。
Fragmentation and reassembly in network equipment generally requires significantly greater resources than sending a packet as a single unit. As such, fragmentation and reassembly should be avoided whenever possible. Ideal solutions for avoiding fragmentation include proper configuration and management of MTU sizes between the Customer Edge (CE) router and Provider Edge (PE) router and across the PSN, as well as adaptive measures that operate with the originating host (e.g., [PATHMTU], [PATHMTUv6]) to reduce the packet sizes at the source.
网络设备中的碎片化和重组通常比作为单个单元发送数据包需要更多的资源。因此，应尽可能避免碎片和重新组装。避免碎片化的理想解决方案包括正确配置和管理客户边缘（CE）路由器和提供商边缘（PE）路由器之间以及整个PSN的MTU大小，以及使用发起主机（例如，[PATHMTU]、[PATHMTUv6]）的自适应措施，以减少源位置的数据包大小。
In some cases, a PE may be able to fragment an IP version 4 (IPv4) [RFC791] packet before it enters a PW. For example, if the PE can fragment and forward IPv4 packets with the DF bit clear in a manner that is identical to an IPv4 router, it may fragment packets arriving from a CE, forwarding the IPv4 fragments with associated framing for that attachment circuit (AC) over the PW. Architecturally, the IPv4 fragmentation happens before reaching the PW, presenting multiple frames to the PW to forward in the normal manner for that PWType. Thus, this method is entirely transparent to the PW encapsulation and to the remote end of the PW itself. Packet fragments are ultimately reassembled on the destination IPv4 host in the normal way. IPv6 packets are not to be fragmented in this manner.
在某些情况下，PE可能能够在进入PW之前对IP版本4（IPv4）[RFC791]数据包进行分段。例如，如果PE可以以与IPv4路由器相同的方式对DF位为clear的IPv4分组进行分段和转发，则它可以对来自CE的分组进行分段，通过PW转发具有该连接电路（AC）的相关帧的IPv4分段。在体系结构上，IPv4碎片在到达PW之前发生，向PW呈现多个帧，以该PW类型的正常方式转发。因此，该方法对PW封装和PW本身的远程端是完全透明的。数据包片段最终以正常方式在目标IPv4主机上重新组装。IPv6数据包不能以这种方式分段。
When using the signaling procedures in [MPLS-Control], there is a Pseudowire Interface Parameter Sub-TLV type used to signal the use of fragmentation when advertising a VC label [IANA]:
当在[MPLS Control]中使用信令程序时，有一个伪线接口参数Sub-TLV类型，用于在广告VC标签[IANA]时发出碎片使用的信号：
Parameter Length Description 0x09 4 Fragmentation indicator
参数长度说明0x09 4碎片指示器
The presence of this parameter in the VC FEC element indicates that the receiver is able to reassemble fragments when the control word is in use for the VC label being advertised. It does not obligate the sender to use fragmentation; it is simply an indication that the sender MAY use fragmentation. The sender MUST NOT use fragmentation if this parameter is not present in the VC FEC element.
VC FEC元素中存在此参数表明，当控制字用于正在播发的VC标签时，接收器能够重新组装片段。它不强制发送方使用碎片；它只是表明发送方可能使用碎片。如果VC FEC元素中不存在此参数，则发送方不得使用碎片。
If [MPLS-Control] signaling is not in use, then whether or not to use fragmentation MUST be configured in the sender.
如果未使用[MPLS Control]信令，则必须在发送方中配置是否使用分段。
MPLS-based PWE3 uses the following control word format [Control-Word], with the B and E fragmentation bits identified in position 8 and 9:
基于MPLS的PWE3使用以下控制字格式[控制字]，在位置8和9中标识B和E碎片位：
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| Flags |B|E| 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| Flags |B|E| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Preferred PW MPLS Control Word
图3：首选PW MPLS控制字
The B and E bits are defined as follows:
B和E位定义如下：
BE -- 00 indicates that the entire (un-fragmented) payload is carried in a single packet 01 indicates the packet carrying the first fragment 10 indicates the packet carrying the last fragment 11 indicates a packet carrying an intermediate fragment
BE--00表示整个（未分段的）有效载荷在单个数据包中承载01表示承载第一个片段的数据包10表示承载最后一个片段的数据包11表示承载中间片段的数据包
See Appendix A for a discussion of the derivation of these values for the B and E bits.
关于B位和E位的这些值的推导，请参见附录A。
See Section 1 for the description of the use of the Sequence Number field.
有关序列号字段的使用说明，请参见第1节。
Path MTU [PATHMTU] [PATHMTUv6] may be used to dynamically determine the maximum size for fragments. The application of path MTU to MPLS is discussed in [LABELSTACK]. The maximum size of the fragments may also be configured. The signaled Interface MTU parameter in [MPLS-Control] SHOULD be used to set the maximum size of the reassembly buffer for received packets to make optimal use of reassembly buffer resources.
路径MTU[PATHMTU][PATHMTUv6]可用于动态确定片段的最大大小。在[LABELSTACK]中讨论了路径MTU在MPLS中的应用。还可以配置片段的最大大小。[MPLS Control]中的信号接口MTU参数应用于为接收的数据包设置重组缓冲区的最大大小，以最佳利用重组缓冲区资源。
This section defines the location of the B and E bits for L2TPv3 [L2TPv3] and L2TPv2 [L2TPv2] headers, as well as the signaling mechanism for advertising MRU (Maximum Receive Unit) values and support for fragmentation on a given PW. As IP is the most common PSN used with L2TP, IP PSN fragmentation and reassembly is discussed as well.
本节定义了L2TPv3[L2TPv3]和L2TPv2[L2TPv2]头的B位和E位的位置，以及在给定PW上公布MRU（最大接收单元）值和支持分段的信令机制。由于IP是L2TP最常用的PSN，因此也讨论了IP PSN的碎片化和重组。
When proper MTU management across a network fails, IP PSN fragmentation and reassembly may be used to accommodate MTU mismatches between tunnel endpoints. If the overall traffic requiring fragmentation and reassembly is very light, or there are sufficient optimized mechanisms for IP PSN fragmentation and reassembly available, IP PSN fragmentation and reassembly may be sufficient.
当跨网络的适当MTU管理失败时，可以使用IP PSN分段和重新组装来适应隧道端点之间的MTU不匹配。如果需要分段和重新组装的总流量非常小，或者有足够的优化机制用于IP PSN分段和重新组装，则IP PSN分段和重新组装可能就足够了。
When facing a large number of PW packets requiring fragmentation and reassembly, a PW-specific method has properties that potentially allow for more resource-friendly implementations. Specifically, the ability to assign buffer usage on a per-PW basis and PW sequencing may be utilized to gain advantage over a general mechanism applying to all IP packets across all PWs. Further, PW fragmentation may be more easily enabled in a selective manner for some or all PWs, rather than enabling reassembly for all IP traffic arriving at a given node.
当面对大量需要分段和重新组装的PW数据包时，特定于PW的方法具有允许更多资源友好型实现的属性。具体地说，可以利用在每个PW的基础上分配缓冲区使用和PW排序的能力来获得相对于应用于所有PW上的所有IP分组的一般机制的优势。此外，对于某些或所有PW，可以更容易地以选择性方式启用PW分段，而不是对到达给定节点的所有IP流量启用重新组装。
Deployments SHOULD avoid a situation that uses a combination of IP PSN and PW fragmentation and reassembly on the same node. Such operation clearly defeats the purpose behind the mechanism defined in this document. This is especially important for L2TPv3 pseudowires, since potentially fragmentation can take place in three different places (the IP PSN, the PW, and the encapsulated payload). Care must be taken to ensure that the MTU/MRU values are set and advertised properly at each tunnel endpoint to avoid this. When fragmentation is enabled within a given PW, the DF bit MUST be set on all L2TP over IP packets for that PW.
部署应避免在同一节点上同时使用IP PSN和PW碎片和重新组装的情况。这种操作显然违背了本文件中定义的机制的目的。这对于L2TPv3伪线尤其重要，因为潜在的碎片可能发生在三个不同的位置（IP PSN、PW和封装的有效负载）。必须注意确保在每个隧道端点正确设置和公布MTU/MRU值，以避免出现这种情况。当在给定PW内启用分段时，必须在该PW的所有L2TP over IP数据包上设置DF位。
L2TPv3 nodes SHOULD participate in Path MTU ([PATHMTU], [PATHMTUv6]) for automatic adjustment of the PSN MTU. When the payload is IP, Path MTU should be used at they payload level as well.
L2TPv3节点应参与路径MTU（[PATHMTU]、[PATHMTUv6]），以自动调整PSN MTU。当有效负载为IP时，路径MTU也应在有效负载级别使用。
The constructs defined in this section for advertising fragmentation support in L2TP are applicable to [L2TPv3] and [L2TPv2].
本节中为L2TP中的广告碎片支持定义的构造适用于[L2TPv3]和[L2TPv2]。
This document defines two new AVPs to advertise maximum receive unit values and reassembly support. These AVPs MAY be present in the Incoming-Call-Request (ICRQ), Incoming-Call-Reply (ICRP), Incoming-Call-Connected (ICCN), Outgoing-Call-Request (OCRQ), Outgoing-Call-Reply (OCRP), Outgoing-Call-Connected (OCCN), or Set-Link-Info (SLI) messages. The most recent value received always takes precedence over a previous value and MUST be dynamic over the life of the
本文件定义了两个新的AVP，用于公布最大接收单元值和重新组装支持。这些AVP可能存在于传入呼叫请求（ICRQ）、传入呼叫应答（ICRP）、已连接的传入呼叫（ICCN）、传出呼叫请求（OCRQ）、传出呼叫应答（OCRP）、已连接的传出呼叫（OCCN）或设置链接信息（SLI）消息中。收到的最新值始终优先于前一个值，并且在数据生命周期内必须是动态的
session if received via the SLI message. One of the two new AVPs (MRRU) is used to advertise that PWE3 reassembly is supported by the sender of the AVP. Reassembly support MAY be unidirectional.
会话（如果通过SLI消息接收）。两个新的AVP（MRRU）中的一个用于通知AVP的发送方支持PWE3重新组装。重新装配支架可能是单向的。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: L2TP Maximum Receive Unit (MRU) AVP
图4:L2TP最大接收单元（MRU）AVP
MRU (Maximum Receive Unit), attribute number 94, is the maximum size, in octets, of a fragmented or complete PW frame, including L2TP encapsulation, receivable by the side of the PW advertising this value. The advertised MRU does NOT include the PSN header (i.e., the IP and/or UDP header). This AVP does not imply that PWE3 fragmentation or reassembly is supported. If reassembly is not enabled or unavailable, this AVP may be used alone to advertise the MRU for a complete frame.
MRU（最大接收单元），属性号94，是一个碎片或完整PW帧（包括L2TP封装）的最大大小，以八位字节为单位，可由宣传此值的PW侧接收。公布的MRU不包括PSN报头（即IP和/或UDP报头）。本AVP并不意味着支持PWE3碎片或重新组装。如果重新组装未启用或不可用，则可以单独使用此AVP来公布MRU的完整帧。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The mandatory (M) bit for this AVP SHOULD be set to 0. The Length (before hiding) is 8. The Vendor ID is the IETF Vendor ID of 0.
该AVP可能被隐藏（H位可能为0或1）。此AVP的强制（M）位应设置为0。长度（隐藏前）为8。供应商ID是0的IETF供应商ID。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRRU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRRU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: L2TP Maximum Reassembled Receive Unit (MRRU) AVP
图5:L2TP最大重新组装接收单元（MRRU）AVP
MRRU (Maximum Reassembled Receive Unit AVP), attribute number 95, is the maximum size, in octets, of a reassembled frame, including any PW framing, but not including the L2TP encapsulation or L2-specific sublayer. Presence of this AVP signifies the ability to receive PW fragments and reassemble them. Packet fragments MUST NOT be sent by a peer that has not received this AVP in a control message. If the MRRU is present in a message, the MRU AVP MUST be present as well.
MRRU（最大重组接收单元AVP），属性号95，是重组帧的最大大小，以八位字节为单位，包括任何PW帧，但不包括L2TP封装或L2特定子层。AVP的存在意味着能够接收PW碎片并重新组装它们。未在控制消息中接收此AVP的对等方不得发送数据包片段。如果消息中存在MRRU，则MRU AVP也必须存在。
The MRRU SHOULD be used to set the maximum size of the reassembly buffer for received packets to make optimal use of reassembly buffer resources.
MRRU应用于为接收的数据包设置重组缓冲区的最大大小，以优化重组缓冲区资源的使用。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The mandatory (M) bit for this AVP SHOULD be set to 0. The Length (before hiding) is 8. The Vendor ID is the IETF Vendor ID of 0.
该AVP可能被隐藏（H位可能为0或1）。此AVP的强制（M）位应设置为0。长度（隐藏前）为8。供应商ID是0的IETF供应商ID。
The usage of the B and E bits is described in Section 4.1. For L2TPv3 encapsulation, the B and E bits are defined as bits 2 and 3 in the leading bits of the Default L2-Specific Sublayer (see Section 7).
第4.1节描述了B和E位的使用。对于L2TPv3封装，B和E位被定义为默认L2特定子层的前导位中的位2和3（参见第7节）。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|B|E|x|x|x|x| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|B|E|x|x|x|x| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: B and E Bits Location in the Default L2-Specific Sublayer
图6：默认L2特定子层中的B和E位位置
The S (Sequence) bit is as defined in [L2TPv3]. Location of the B and E bits for PW-Types that use a variant L2 specific sublayer are outside the scope of this document.
S（序列）位如[L2TPv3]中所定义。使用变体L2特定子层的PW类型的B和E位的位置不在本文档的范围内。
When fragmentation is used, an L2-Specific Sublayer with B and E bits defined MUST be present in all data packets for a given session. The presence and format of the L2-Specific Sublayer is advertised via the L2-Specific Sublayer AVP, Attribute Type 69, defined in Section 5.4.4 of [L2TPv3].
当使用分段时，在给定会话的所有数据包中必须存在一个定义了B和E位的L2特定子层。L2特定子层的存在和格式通过[L2TPv3]第5.4.4节中定义的属性类型为69的L2特定子层AVP发布。
See Section 1 for the description of the use of the Sequence Number field.
有关序列号字段的使用说明，请参见第1节。
The usage of the B and E bits is described in Section 4.1. For L2TPv2 encapsulation, the B and E bits are defined as bits 8 and 9 in the leading bits of the L2TPv2 header as depicted below (see Section 7).
第4.1节描述了B和E位的使用。对于L2TPv2封装，B和E位被定义为L2TPv2报头的前导位中的位8和9，如下所示（参见第7节）。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L|x|x|S|x|O|P|B|E|x|x| Ver | Length (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L|x|x|S|x|O|P|B|E|x|x| Ver | Length (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: B and E bits location in the L2TPv2 Message Header
图7:L2TPv2消息头中的B和E位位置
As with any additional protocol construct, each level of complexity adds the potential to exploit protocol and implementation errors. Implementers should be especially careful of not tying up an abundance of resources, even for the most pathological combination of packet fragments that could be received. Beyond these issues of general implementation quality, there are no known notable security issues with using the mechanism defined in this document. It should be pointed out that RFC 1990, on which this document is based, and its derivatives have been widely implemented and extensively used in the Internet and elsewhere.
与任何其他协议构造一样，每一级别的复杂性都增加了利用协议和实现错误的可能性。实现者应该特别小心，不要占用大量资源，即使对于可能接收到的最病态的数据包片段组合也是如此。除了这些一般实现质量问题外，使用本文档中定义的机制没有已知的显著安全问题。应该指出的是，本文件所依据的RFC 1990及其衍生产品已在互联网和其他地方得到广泛实施和广泛使用。
[IPFRAG-SEC] and [TINYFRAG] describe potential network attacks associated with IP fragmentation and reassembly. The issues described in these documents attempt to bypass IP access controls by sending various carefully formed "tiny fragments", or by exploiting the IP offset field to cause fragments to overlap and rewrite interesting portions of an IP packet after access checks have been performed. The latter is not an issue with the PW-specific fragmentation method described in this document, as there is no offset field. However, implementations MUST be sure not to allow more than one whole fragment to overwrite another in a reconstructed frame. The former may be a concern if packet filtering and access controls are being placed on tunneled frames within the PW encapsulation. To circumvent any possible attacks in either case, all filtering and access controls should be applied to the resulting reconstructed frame rather than any PW fragments.
[IPFRAG-SEC]和[TINYFRAG]描述了与IP碎片化和重组相关的潜在网络攻击。这些文档中描述的问题试图通过发送各种精心形成的“微小片段”，或通过利用IP偏移字段使片段重叠并在执行访问检查后重写IP分组的感兴趣部分来绕过IP访问控制。后者与本文档中描述的PW特定分段方法无关，因为没有偏移字段。然而，实现必须确保不允许一个以上的完整片段覆盖重构帧中的另一个片段。如果分组过滤和访问控制被放置在PW封装内的隧道帧上，则前者可能是一个问题。为了避免任何一种情况下可能发生的攻击，所有过滤和访问控制都应应用于生成的重建帧，而不是任何PW片段。
This document does not define any new registries for IANA to maintain.
本文件未定义IANA需要维护的任何新注册。
Note that [IANA] has already allocated the Fragmentation Indicator interface parameter, so no further IANA action is required.
请注意，[IANA]已经分配了碎片指示符接口参数，因此不需要进一步的IANA操作。
This document requires IANA to assign new values for registries already managed by IANA (see Sections 7.1 and 7.2) and two reserved bits in an existing header (see Section 7.3).
本文件要求IANA为已由IANA管理的注册表（见第7.1节和第7.2节）和现有标头中的两个保留位（见第7.3节）分配新值。
Two additional AVP Attributes are specified in Sections 5.3 and 5.4. They are required to be defined by IANA as described in Section 2.2 of [BCP0068].
第5.3节和第5.4节规定了另外两个AVP属性。IANA要求按照[BCP0068]第2.2节的规定对其进行定义。
Control Message Attribute Value Pairs
-------------------------------------
Control Message Attribute Value Pairs
-------------------------------------
94 - Maximum Receive Unit (MRU) AVP 95 - Maximum Reassembled Receive Unit (MRRU) AVP
94-最大接收单元（MRU）AVP 95-最大重新组装接收单元（MRRU）AVP
This registry was created as part of the publication of [L2TPv3]. This document defines two reserved bits in the Default L2-Specific Sublayer in Section 5.5, which may be assigned by IETF Consensus [RFC2434]. They are required to be assigned by IANA.
此注册表是作为[L2TPv3]发布的一部分创建的。本文件在第5.5节中的默认L2特定子层中定义了两个保留位，可由IETF协商一致[RFC2434]分配。它们必须由IANA分配。
Default L2-Specific Sublayer bits - per [L2TPv3]
---------------------------------
Default L2-Specific Sublayer bits - per [L2TPv3]
---------------------------------
Bit 2 - B (Fragmentation) bit Bit 3 - E (Fragmentation) bit
位2-B（碎片）位3-E（碎片）位
This document requires definition of two reserved bits in the L2TPv2 [L2TPv2] header. Locations are noted by the "B" and "E" bits in Section 5.6.
本文档要求在L2TPv2[L2TPv2]头中定义两个保留位。位置由第5.6节中的“B”和“E”位表示。
Leading Bits of the L2TPv2 Message Header - per [L2TPv2, L2TPv3]
-----------------------------------------
Leading Bits of the L2TPv2 Message Header - per [L2TPv2, L2TPv3]
-----------------------------------------
Bit 8 - B (Fragmentation) bit Bit 9 - E (Fragmentation) bit
位8-B（碎片）位9-E（碎片）位
The authors wish to thank Eric Rosen and Carlos Pignataro, both of Cisco Systems, for their review of this document.
作者感谢思科系统公司的Eric Rosen和Carlos Pignataro对本文件的审阅。
[Control-Word] 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.
[控制字]Bryant，S.，Swallow，G.，Martini，L.，和D.McPherson，“在MPLS PSN上使用的伪线仿真边到边（PWE3）控制字”，RFC 4385，2006年2月。
[IANA] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[IANA]Martini，L.，“伪线边到边仿真（PWE3）的IANA分配”，BCP 116，RFC 4446，2006年4月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[LABELSTACK] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[LABELSTACK]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.，和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月。
[L2TPv2] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[L2TPv2]汤斯利，W.，瓦伦西亚，A.，鲁本斯，A.，帕尔，G.，佐恩，G.，和B.帕尔特，“第二层隧道协议“L2TP”，RFC 26611999年8月。
[L2TPv3] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[L2TPv3]Lau，J.，Townsley，M.，和I.Goyret，“第二层隧道协议-版本3（L2TPv3）”，RFC 39312005年3月。
[MLPPP] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
[MLPPP]Sklower，K.，Lloyd，B.，McGregor，G.，Carr，D.，和T.Coradetti，“PPP多链路协议（MP）”，RFC 1990，1996年8月。
[MPLS-Control] 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.
[MPLS控制]Martini，L.，Rosen，E.，El Aawar，N.，Smith，T.，和G.Heron，“使用标签分发协议（LDP）的伪线设置和维护”，RFC 4447，2006年4月。
[PATHMTU] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[PATHMTU]Mogul，J.和S.Deering，“PATHMTU发现”，RFC191990年11月。
[PATHMTUv6] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[PATHMTUv6]McCann，J.，Deering，S.，和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，1996年8月。
[Architecture] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[架构]Bryant，S.和P.Pate，“伪线仿真边到边（PWE3）架构”，RFC 3985，2005年3月。
[BCP0068] Townsley, W., "Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update", BCP 68, RFC 3438, December 2002.
[BCP0068]汤斯利，W.“第二层隧道协议（L2TP）互联网分配号码管理局（IANA）注意事项更新”，BCP 68，RFC 3438，2002年12月。
[FAST] ATM Forum, "Frame Based ATM over SONET/SDH Transport (FAST)", af-fbatm-0151.000, July 2000.
[FAST]ATM论坛，“基于帧的SONET/SDH传输ATM（FAST）”，af-fbatm-0151.000，2000年7月。
[FRF.12] Frame Relay Forum, "Frame Relay Fragmentation Implementation Agreement", FRF.12, December 1997.
[FRF.12]帧中继论坛，“帧中继分段实施协议”，FRF.12，1997年12月。
[IPFRAG-SEC] Ziemba, G., Reed, D., and P. Traina, "Security Considerations for IP Fragment Filtering", RFC 1858, October 1995.
[IPFRAG-SEC]Ziemba，G.，Reed，D.，和P.Trana，“IP片段过滤的安全考虑”，RFC 1858，1995年10月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，“互联网协议”，标准5，RFC7911981年9月。
[TINYFRAG] Miller, I., "Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)", RFC 3128, June 2001.
[TINYFRAG]Miller，I.，“防止微小碎片攻击的变体（RFC 1858）”，RFC 3128，2001年6月。
The fragmentation of large packets into smaller units for transmission is not new. One fragmentation and reassembly method was defined in RFC 1990, Multi-Link PPP [MLPPP]. This method was also adopted for both Frame Relay [FRF.12] and ATM [FAST] network technology. This document adopts the RFC 1990 fragmentation and reassembly procedures as well, with some distinct modifications described in this appendix. Familiarity with RFC 1990 is assumed.
将大数据包分割成更小的单元进行传输并不是什么新鲜事。RFC 1990中定义了一种碎片和重组方法，即多链路PPP[MLPPP]。帧中继[FRF.12]和ATM[FAST]网络技术也采用了这种方法。本文件还采用了RFC 1990碎片和重新组装程序，并在本附录中进行了一些不同的修改。假设熟悉RFC 1990。
RFC 1990 was designed for use in environments where packet fragments may arrive out of order due to their transmission on multiple parallel links, specifying that buffering be used to place the fragments in correct order. For PWE3, the ability to reorder fragments prior to reassembly is OPTIONAL; receivers MAY choose to drop frames when a lost fragment is detected. Thus, when the sequence number on received fragments shows that a fragment has been skipped, the partially reassembled packet MAY be dropped, or the receiver MAY wish to wait for the fragment to arrive out of order. In the latter case, a reassembly timer MUST be used to avoid locking up buffer resources for too long a period.
RFC 1990设计用于数据包碎片可能由于在多个并行链路上的传输而无序到达的环境中，指定使用缓冲将碎片按正确顺序放置。对于PWE3，在重新组装之前对碎片重新排序的能力是可选的；当检测到丢失的片段时，接收机可以选择丢弃帧。因此，当所接收片段上的序列号显示片段已被跳过时，可丢弃部分重新组装的分组，或接收器可能希望等待片段无序到达。在后一种情况下，必须使用重新组装计时器，以避免将缓冲区资源锁定太长时间。
Dropping out-of-order fragments on a given PW can provide a considerable scalability advantage for network equipment performing reassembly. If out-of-order fragments are a relatively rare event on a given PW, throughput should not be adversely affected by this. Note, however, if there are cases where fragments of a given frame are received out-or-order in a consistent manner (e.g., a short fragment is always switched ahead of a larger fragment), then dropping out-of-order fragments will cause the fragmented frame never to be received. This condition may result in an effective denial of service to a higher-lever application. As such, implementations fragmenting a PW frame MUST at the very least ensure that all fragments are sent in order from their own egress point.
在给定PW上丢弃无序片段可以为执行重新组装的网络设备提供相当大的可伸缩性优势。如果无序片段在给定PW上是相对罕见的事件，则吞吐量不应受到此影响。然而，请注意，如果存在以一致方式接收给定帧的片段或顺序的情况（例如，短片段总是在较大片段之前切换），则丢失无序片段将导致永远无法接收片段帧。这种情况可能导致对更高级别应用程序的有效拒绝服务。因此，分割PW帧的实现必须至少确保所有片段都从它们自己的出口点按顺序发送。
An implementation may also choose to allow reassembly of a limited number of fragmented frames on a given PW, or across a set of PWs with reassembly enabled. This allows for a more even distribution of reassembly resources, reducing the chance that a single or small set of PWs will exhaust all reassembly resources for a node. As with dropping out-of-order fragments, there are perceivable cases where this may also provide an effective denial of service. For example, if fragments of multiple frames are consistently received before each frame can be reconstructed in a set of limited PW reassembly buffers, then a set of these fragmented frames will never be delivered.
实现还可以选择允许在给定PW上重新组装有限数量的碎片帧，或者在启用重新组装的情况下跨一组PW重新组装。这允许更均匀地分配重新组装资源，减少单个或小组PW耗尽节点的所有重新组装资源的可能性。与丢失无序片段一样，在一些可感知的情况下，这也可能提供有效的拒绝服务。例如，如果在一组有限的PW重组缓冲区中重建每个帧之前，一致地接收到多个帧的片段，那么这些片段帧的集合将永远不会被交付。
RFC 1990 headers use two bits that indicate the first and last fragments in a frame, and a sequence number. The sequence number may be either 12 or 24 bits in length (from [MLPPP]):
RFC1990报头使用两个表示帧中第一个和最后一个片段的位以及一个序列号。序列号的长度可以是12位或24位（从[MLPPP]）：
0 7 8 15
+-+-+-+-+-------+---------------+
|B|E|0|0| sequence number |
+-+-+-+-+-------+---------------+
0 7 8 15
+-+-+-+-+-------+---------------+
|B|E|0|0| sequence number |
+-+-+-+-+-------+---------------+
+-+-+-+-+-+-+-+-+---------------+
|B|E|0|0|0|0|0|0|sequence number|
+-+-+-+-+-+-+-+-+---------------+
| sequence number (L) |
+---------------+---------------+
+-+-+-+-+-+-+-+-+---------------+
|B|E|0|0|0|0|0|0|sequence number|
+-+-+-+-+-+-+-+-+---------------+
| sequence number (L) |
+---------------+---------------+
Figure 6: RFC 1990 Header Formats
图6:RFC1990标题格式
PWE3 fragmentation takes advantage of existing PW sequence numbers and control bit fields wherever possible, rather than defining a separate header exclusively for the use of fragmentation. Thus, it uses neither of the RFC 1990 sequence number formats described above, relying instead on the sequence number that already exists in the PWE3 header.
PWE3分段尽可能利用现有的PW序列号和控制位字段，而不是专门为分段使用定义单独的报头。因此，它不使用上述RFC 1990序列号格式，而是依赖于PWE3报头中已经存在的序列号。
RFC 1990 defines two one-bit fields: a (B)eginning fragment bit and an (E)nding fragment bit. The B bit is set to 1 on the first fragment derived from a PPP packet and set to 0 for all other fragments from the same PPP packet. The E bit is set to 1 on the last fragment and set to 0 for all other fragments. A complete unfragmented frame has both the B and E bits set to 1.
RFC1990定义了两个一位字段：一个（B）开始片段位和一个（E）结束片段位。在从PPP数据包派生的第一个片段上，B位被设置为1，对于来自同一PPP数据包的所有其他片段，B位被设置为0。最后一个片段的E位设置为1，所有其他片段的E位设置为0。完整的未分段帧的B位和E位都设置为1。
PWE3 fragmentation inverts the value of the B and E bits, while retaining the operational concept of marking the beginning and ending of a fragmented frame. Thus, for PW the B bit is set to 0 on the first fragment derived from a PW frame and set to 1 for all other fragments derived from the same frame. The E bit is set to 0 on the last fragment and set to 1 for all other fragments. A complete unfragmented frame has both the B and E bits set to 0. The motivation behind this value inversion for the B and E bits is to allow complete frames (and particularly, implementations that only support complete frames) simply to leave the B and E bits in the header set to 0.
PWE3分段反转B和E位的值，同时保留标记分段帧的开始和结束的操作概念。因此，对于PW，在从PW帧派生的第一个片段上，B位被设置为0，对于从同一帧派生的所有其他片段，B位被设置为1。最后一个片段的E位设置为0，所有其他片段的E位设置为1。完整的未分段帧的B位和E位都设置为0。B和E位的值反转背后的动机是允许完整帧（特别是仅支持完整帧的实现）简单地将报头中的B和E位设置为0。
In order to support fragmentation, the B and E bits MUST be defined or identified for all PWE3 tunneling protocols. Sections 4 and 5 define these locations for PWE3 MPLS [Control-Word], L2TPv2 [L2TPv2], and L2TPv3 [L2TPv3] tunneling protocols.
为了支持分段，必须为所有PWE3隧道协议定义或标识B和E位。第4节和第5节定义了PWE3 MPLS[控制字]、L2TPv2[L2TPv2]和L2TPv3[L2TPv3]隧道协议的这些位置。
Authors' Addresses
作者地址
Andrew G. Malis Tellabs 1415 West Diehl Road Naperville, IL 60563
伊利诺伊州纳珀维尔西迪尔路1415号安德鲁·G·马里斯·特拉伯斯，邮编：60563
EMail: Andy.Malis@tellabs.com
EMail: Andy.Malis@tellabs.com
W. Mark Townsley Cisco Systems 7025 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709
美国北卡罗来纳州三角研究公园14987号吉特克里克路邮政信箱7025号马克·汤斯利思科系统公司
EMail: mark@townsley.net
EMail: mark@townsley.net
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）提供。