Internet Engineering Task Force (IETF) S. Bryant, Ed.
Request for Comments: 6391 C. Filsfils
Category: Standards Track Cisco Systems
ISSN: 2070-1721 U. Drafz
Deutsche Telekom
V. Kompella
J. Regan
Alcatel-Lucent
S. Amante
Level 3 Communications, LLC
November 2011
Internet Engineering Task Force (IETF) S. Bryant, Ed.
Request for Comments: 6391 C. Filsfils
Category: Standards Track Cisco Systems
ISSN: 2070-1721 U. Drafz
Deutsche Telekom
V. Kompella
J. Regan
Alcatel-Lucent
S. Amante
Level 3 Communications, LLC
November 2011
Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network
MPLS分组交换网络上伪线的流感知传输
Abstract
摘要
Where the payload of a pseudowire comprises a number of distinct flows, it can be desirable to carry those flows over the Equal Cost Multiple Paths (ECMPs) that exist in the packet switched network. Most forwarding engines are able to generate a hash of the MPLS label stack and use this mechanism to balance MPLS flows over ECMPs.
在伪线的有效载荷包括多个不同的流的情况下，可以期望在分组交换网络中存在的等成本多路径（ecmp）上承载这些流。大多数转发引擎能够生成MPLS标签堆栈的散列，并使用此机制在ECMPs上平衡MPLS流。
This document describes a method of identifying the flows, or flow groups, within pseudowires such that Label Switching Routers can balance flows at a finer granularity than individual pseudowires. The mechanism uses an additional label in the MPLS label stack.
本文档描述了一种在伪线内识别流或流组的方法，以便标签交换路由器能够以比单个伪线更细的粒度平衡流。该机制在MPLS标签堆栈中使用附加标签。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6391.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6391.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Requirements Language ......................................4
1.2. ECMP in Label Switching Routers ............................4
1.3. Flow Label .................................................4
2. Native Service Processing Function ..............................5
3. Pseudowire Forwarder ............................................6
3.1. Encapsulation ..............................................7
4. Signalling the Presence of the Flow Label .......................8
4.1. Structure of Flow Label Sub-TLV ............................9
5. Static Pseudowires ..............................................9
6. Multi-Segment Pseudowires .......................................9
7. Operations, Administration, and Maintenance (OAM) ..............10
8. Applicability of PWs Using Flow Labels .........................11
8.1. Equal Cost Multiple Paths .................................12
8.2. Link Aggregation Groups ...................................13
8.3. Multiple RSVP-TE Paths ....................................13
8.4. The Single Large Flow Case ................................14
8.5. Applicability to MPLS-TP ..................................15
8.6. Asymmetric Operation ......................................15
9. Applicability to MPLS LSPs .....................................15
10. Security Considerations .......................................16
11. IANA Considerations ...........................................16
12. Congestion Considerations .....................................16
13. Acknowledgements ..............................................17
14. References ....................................................17
14.1. Normative References .....................................17
14.2. Informative References ...................................18
1. Introduction ....................................................3
1.1. Requirements Language ......................................4
1.2. ECMP in Label Switching Routers ............................4
1.3. Flow Label .................................................4
2. Native Service Processing Function ..............................5
3. Pseudowire Forwarder ............................................6
3.1. Encapsulation ..............................................7
4. Signalling the Presence of the Flow Label .......................8
4.1. Structure of Flow Label Sub-TLV ............................9
5. Static Pseudowires ..............................................9
6. Multi-Segment Pseudowires .......................................9
7. Operations, Administration, and Maintenance (OAM) ..............10
8. Applicability of PWs Using Flow Labels .........................11
8.1. Equal Cost Multiple Paths .................................12
8.2. Link Aggregation Groups ...................................13
8.3. Multiple RSVP-TE Paths ....................................13
8.4. The Single Large Flow Case ................................14
8.5. Applicability to MPLS-TP ..................................15
8.6. Asymmetric Operation ......................................15
9. Applicability to MPLS LSPs .....................................15
10. Security Considerations .......................................16
11. IANA Considerations ...........................................16
12. Congestion Considerations .....................................16
13. Acknowledgements ..............................................17
14. References ....................................................17
14.1. Normative References .....................................17
14.2. Informative References ...................................18
A pseudowire (PW) [RFC3985] is normally transported over one single network path, even if multiple Equal Cost Multiple Paths (ECMPs) exist between the ingress and egress PW provider edge (PE) equipment [RFC4385] [RFC4928]. This is required to preserve the characteristics of the emulated service (e.g., to avoid misordering Structure-Agnostic Time Division Multiplexing over Packet (SAToP) PW packets [RFC4553] or subjecting the packets to unusable inter-arrival times). The use of a single path to preserve order remains the default mode of operation of a PW. The new capability proposed in this document is an OPTIONAL mode that may be used when the use of ECMPs is known to be beneficial (and not harmful) to the operation of the PW.
即使入口和出口PW提供商边缘（PE）设备[RFC4385][RFC4928]之间存在多条等成本多路径（ECMP），伪线（PW）[RFC3985]通常通过一条网络路径传输。这是为了保持模拟服务的特性（例如，避免分组上的结构无关时分复用（SAToP）PW分组[RFC4553]或使分组受到不可用的到达时间的影响）所必需的。使用单一路径保持秩序仍然是PW的默认操作模式。本文件中提出的新功能是一种可选模式，当已知ECMPs的使用对PW的运行有益（而非有害）时，可使用该模式。
Some PWs are used to transport large volumes of IP traffic between routers. One example of this is the use of an Ethernet PW to create a virtual direct link between a pair of routers. Such PWs may carry from hundreds of Mbps to Gbps of traffic. These PWs only require packet ordering to be preserved within the context of each individual transported IP flow. They do not require packet ordering to be preserved between all packets of all IP flows within the pseudowire.
一些PW用于在路由器之间传输大量IP流量。其中一个例子是使用以太网PW在一对路由器之间创建虚拟直接链路。这种PWs可以承载数百Mbps到Gbps的流量。这些PW只需要在每个单独传输的IP流的上下文中保留数据包顺序。它们不要求在伪线内所有IP流的所有数据包之间保留数据包顺序。
The ability to explicitly configure such a PW to leverage the availability of multiple ECMPs allows for better capacity planning, as the statistical multiplexing of a larger number of smaller flows is more efficient than with a smaller set of larger flows.
明确配置这样一个PW以利用多个ECMP的可用性的能力允许更好的容量规划，因为统计复用更多的较小流比使用更小的较大流集更有效。
Typically, forwarding hardware can deduce that an IP payload is being directly carried by an MPLS label stack, and it is capable of looking at some fields in packets to construct hash buckets for conversations or flows. However, when the MPLS payload is a PW, an intermediate node has no information on the type of PW being carried in the packet. This limits the forwarder at the intermediate node to only being able to make an ECMP choice based on a hash of the MPLS label stack. In the case of a PW emulating a high-bandwidth trunk, the granularity obtained by hashing the label stack is inadequate for satisfactory load balancing. The ingress node, however, is in the special position of being able to understand the unencapsulated packet header to assist with spreading flows among any available ECMPs, or even any Loop-Free Alternates [RFC5286]. This document defines a method to introduce granularity on the hashing of traffic running over PWs by introducing an additional label, chosen by the ingress node, and placed at the bottom of the label stack.
通常，转发硬件可以推断MPLS标签堆栈直接承载IP有效负载，并且它能够查看数据包中的某些字段，为会话或流构造哈希桶。然而，当MPLS有效载荷是PW时，中间节点没有关于分组中承载的PW类型的信息。这将中间节点的转发器限制为只能根据MPLS标签堆栈的哈希值进行ECMP选择。在PW模拟高带宽主干的情况下，通过散列标签堆栈获得的粒度不足以实现令人满意的负载平衡。然而，入口节点处于能够理解未封装的分组报头的特殊位置，以帮助在任何可用的ecmp、甚至任何无环替代物之间传播流[RFC5286]。本文档定义了一种方法，通过引入由入口节点选择并放置在标签堆栈底部的附加标签，在PWs上运行的流量哈希上引入粒度。
In addition to providing an indication of the flow structure for use in ECMP forwarding decisions, the mechanism described in the document may also be used to select flows for distribution over an IEEE 802.1AX-2008 (originally specified as IEEE 802.3ad-2000) Link Aggregation Group (LAG) that has been used in an MPLS network.
除了提供在ECMP转发决策中使用的流结构的指示之外，文档中描述的机制还可用于选择在MPLS网络中使用的IEEE 802.1AX-2008（最初指定为IEEE 802.3ad-2000）链路聚合组（LAG）上分发的流。
NOTE: Although Ethernet is frequently referenced as a use case in this RFC, the mechanisms described in this document are general mechanisms that may be applied to any PW type in which there are identifiable flows, and in which there is no requirement to preserve the order between those flows.
注：尽管以太网在本RFC中经常被作为用例引用，但本文档中描述的机制是可应用于任何PW类型的通用机制，其中存在可识别的流，并且不要求保留这些流之间的顺序。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Label Switching Routers (LSRs) commonly generate a hash of the label stack or some elements of the label stack as a method of discriminating between flows and use this to distribute those flows over the available ECMPs that exist in the network. Since the label at the bottom of the stack is usually the label most closely associated with the flow, this normally provides the greatest entropy, and hence is usually included in the hash. This document describes a method of adding an additional Label Stack Entry (LSE) at the bottom of the stack in order to facilitate the load balancing of the flows within a PW over the available ECMPs. A similar design for general MPLS use has also been proposed [MPLS-ENTROPY]; see Section 9 of this document.
标签交换路由器（LSR）通常生成标签堆栈的散列或标签堆栈的某些元素，作为区分流的方法，并使用此方法在网络中存在的可用ECMP上分发这些流。由于堆栈底部的标签通常是与流关联最密切的标签，因此通常提供最大的熵，因此通常包含在哈希中。本文档描述了一种在堆栈底部添加额外标签堆栈项（LSE）的方法，以促进PW内的流在可用ECMP上的负载平衡。还提出了一种用于一般MPLS的类似设计[MPLS-熵]；见本文件第9节。
An alternative method of load balancing by creating a number of PWs and distributing the flows amongst them was considered, but was rejected because:
考虑了通过创建多个PW并在其中分配流量来实现负载平衡的替代方法，但被拒绝，因为：
o It did not introduce as much entropy as can be introduced by adding an additional LSE.
o 它并没有像增加一个额外的LSE那样引入更多的熵。
o It required additional PWs to be set up and maintained.
o 需要设置和维护额外的PWs。
An additional LSE [RFC3032] is interposed between the PW LSE and the control word, or if the control word is not present, between the PW LSE and the PW payload. This additional LSE is called the flow LSE, and the label carried by the flow LSE is called the flow label.
另外一个LSE[RFC3032]插入PW LSE和控制字之间，或者如果控制字不存在，则插入PW LSE和PW有效负载之间。这个附加的LSE称为流LSE，流LSE携带的标签称为流标签。
Indivisible flows within the PW MUST be mapped to the same flow label by the ingress PE. The flow label stimulates the correct ECMP load-balancing behaviour in the packet switched network (PSN). On receipt of the PW packet at the egress PE (which knows a flow LSE is present), the flow LSE is discarded without processing.
PW内的不可分割流必须由入口PE映射到相同的流标签。流标签刺激分组交换网络（PSN）中正确的ECMP负载平衡行为。在出口PE（知道存在流LSE）处接收到PW分组时，流LSE被丢弃而不进行处理。
Note that the flow label MUST NOT be an MPLS reserved label (values in the range 0..15) [RFC3032], but is otherwise unconstrained by the protocol.
请注意，流标签不能是MPLS保留标签（值范围为0..15）[RFC3032]，否则不受协议限制。
It is useful to give consideration to the choice of Time to Live (TTL) value in the flow LSE [RFC3032]. The flow LSE is at the bottom of the label stack; therefore, even when penultimate hop popping is employed, it will always be preceded by the PW label on arrival at the PE. If, due to an error condition, the flow LSE becomes the top of the stack, it might be examined as if it were a normal LSE, and the packet might then be forwarded. This can be prevented by setting the flow LSE TTL to 1, thereby forcing the packet to be discarded by the forwarder. Note that setting the TTL to 1 regardless of the payload may be considered a departure from the TTL procedures defined in [RFC3032] that apply to the general MPLS case.
在流LSE[RFC3032]中考虑生存时间（TTL）值的选择非常有用。流LSE位于标签堆栈的底部；因此，即使使用倒数第二跳弹出，在到达PE时，始终会在其前面加上PW标签。如果由于错误条件，流LSE成为堆栈的顶部，则可以像检查正常LSE一样对其进行检查，然后可以转发数据包。这可以通过将流LSE TTL设置为1来防止，从而强制转发器丢弃数据包。请注意，将TTL设置为1而不考虑有效负载可能被视为偏离[RFC3032]中定义的适用于一般MPLS情况的TTL程序。
This document does not define a use for the Traffic Class (TC) field [RFC5462] (formerly known as the Experimental Use (EXP) bits [RFC3032]) in the flow label. Future documents may define a use for these bits; therefore, implementations conforming to this specification MUST set the TC field to zero at the ingress and MUST ignore them at the egress.
本文件未定义流量标签中流量类别（TC）字段[RFC5462]（以前称为实验使用（EXP）位[RFC3032]）的用途。未来的文件可能会定义这些位的用途；因此，符合本规范的实现必须在入口处将TC字段设置为零，并且在出口处必须忽略它们。
The Native Service Processing (NSP) function [RFC3985] is a component of a PE that has knowledge of the structure of the emulated service and is able to take action on the service outside the scope of the PW. In this case, it is REQUIRED that the NSP in the ingress PE identify flows, or groups of flows within the service, and indicate the flow (group) identity of each packet as it is passed to the pseudowire forwarder. As an example, where the PW type is an Ethernet, the NSP might parse the ingress Ethernet traffic and consider all of the IP traffic. This traffic could then be categorised into flows by considering all traffic with the same source and destination address pair to be a single indivisible flow. Since this is an NSP function, by definition, the method used to identify a flow is outside the scope of the PW design. Similarly, since the NSP is internal to the PE, the method of flow indication to the PW forwarder is outside the scope of this document.
本机服务处理（NSP）功能[RFC3985]是PE的一个组件，它了解模拟服务的结构，并且能够对PW范围之外的服务采取行动。在这种情况下，要求入口PE中的NSP识别服务内的流或流组，并在每个数据包传递到伪线转发器时指示其流（组）标识。作为一个例子，在PW类型是以太网的情况下，NSP可以解析入口以太网流量并考虑所有IP流量。然后，通过将具有相同源地址对和目标地址对的所有流量视为单个不可分割流，可以将该流量分类为流。由于这是一个NSP功能，根据定义，用于识别流的方法不在PW设计范围内。同样，由于NSP是PE内部的，因此PW转发器的流量指示方法不在本文件的范围内。
The PW forwarder must be provided with a method of mapping flows to load-balanced paths.
PW转发器必须提供一种将流映射到负载平衡路径的方法。
The forwarder must generate a label for the flow or group of flows. How the flow label values are determined is outside the scope of this document; however, the flow label allocated to a flow MUST NOT be an MPLS reserved label and SHOULD remain constant for the life of the flow. It is RECOMMENDED that the method chosen to generate the load-balancing labels introduce a high degree of entropy in their values, to maximise the entropy presented to the ECMP selection mechanism in the LSRs in the PSN, and hence distribute the flows as evenly as possible over the available PSN ECMP. The forwarder at the ingress PE prepends the PW control word (if applicable), and then pushes the flow label, followed by the PW label.
转发器必须为流或流组生成标签。如何确定流量标签值不在本文件范围内；但是，分配给流的流标签不能是MPLS保留标签，并且在流的生命周期内保持不变。建议选择用于生成负载平衡标签的方法在其值中引入高度熵，以最大化PSN中LSR中ECMP选择机制的熵，从而尽可能均匀地在可用PSN ECMP上分配流。入口PE处的转发器预先输入PW控制字（如果适用），然后推送流量标签，然后推送PW标签。
NOTE: Although this document does not attempt to specify any hash algorithms, it is suggested that any such algorithm should be based on the assumption that there will be a high degree of entropy in the values assigned to the flow labels.
注：尽管本文件未试图指定任何哈希算法，但建议任何此类算法均应基于以下假设，即分配给流标签的值中存在高度熵。
The forwarder at the egress PE uses the pseudowire label to identify the pseudowire. From the context associated with the pseudowire label, the egress PE can determine whether a flow LSE is present. If a flow LSE is present, it MUST be checked to determine whether it carries a reserved label. If it is a reserved label, the packet is processed according to the rules associated with that reserved label; otherwise, the LSE is discarded.
出口PE处的转发器使用伪线标签识别伪线。从与伪线标签相关联的上下文，出口PE可以确定是否存在流LSE。如果存在流LSE，则必须对其进行检查，以确定其是否带有保留标签。如果是保留标签，则根据与该保留标签相关联的规则处理该分组；否则，将丢弃LSE。
All other PW forwarding operations are unmodified by the inclusion of the flow LSE.
所有其他PW转发操作都不会因包含流LSE而被修改。
The PWE3 Protocol Stack Reference Model modified to include flow LSE is shown in Figure 1.
图1显示了修改后的PWE3协议栈参考模型，以包括流LSE。
+-------------+ +-------------+
| Emulated | | Emulated |
| Ethernet | | Ethernet |
| (including | Emulated Service | (including |
| VLAN) |<==============================>| VLAN) |
| Services | | Services |
+-------------+ +-------------+
| Flow | | Flow |
+-------------+ Pseudowire +-------------+
|Demultiplexer|<==============================>|Demultiplexer|
+-------------+ +-------------+
| PSN | PSN Tunnel | PSN |
| MPLS |<==============================>| MPLS |
+-------------+ +-------------+
| Physical | | Physical |
+-----+-------+ +-----+-------+
+-------------+ +-------------+
| Emulated | | Emulated |
| Ethernet | | Ethernet |
| (including | Emulated Service | (including |
| VLAN) |<==============================>| VLAN) |
| Services | | Services |
+-------------+ +-------------+
| Flow | | Flow |
+-------------+ Pseudowire +-------------+
|Demultiplexer|<==============================>|Demultiplexer|
+-------------+ +-------------+
| PSN | PSN Tunnel | PSN |
| MPLS |<==============================>| MPLS |
+-------------+ +-------------+
| Physical | | Physical |
+-----+-------+ +-----+-------+
Figure 1: PWE3 Protocol Stack Reference Model
图1:PWE3协议栈参考模型
The encapsulation of a PW with a flow LSE is shown in Figure 2.
用流动LSE封装PW如图2所示。
+---------------------------+
| |
| Payload |
| | n octets
| |
+---------------------------+
| Optional Control Word | 4 octets
+---------------------------+
| Flow LSE | 4 octets
+---------------------------+
| PW LSE | 4 octets
+---------------------------+
| MPLS Tunnel LSE (s) | n*4 octets (four octets per LSE)
+---------------------------+
+---------------------------+
| |
| Payload |
| | n octets
| |
+---------------------------+
| Optional Control Word | 4 octets
+---------------------------+
| Flow LSE | 4 octets
+---------------------------+
| PW LSE | 4 octets
+---------------------------+
| MPLS Tunnel LSE (s) | n*4 octets (four octets per LSE)
+---------------------------+
Figure 2: Encapsulation of a Pseudowire with a Pseudowire Flow LSE
图2：用伪线流LSE封装伪线
When using the signalling procedures in [RFC4447], a new Pseudowire Interface Parameter Sub-TLV, the Flow Label Sub-TLV (FL Sub-TLV), is used to synchronise the flow label states between the ingress and egress PEs.
当使用[RFC4447]中的信令程序时，一个新的伪线接口参数Sub-TLV，即流量标签Sub-TLV（FL Sub-TLV），用于同步入口和出口PEs之间的流量标签状态。
The absence of an FL Sub-TLV indicates that the PE is unable to process flow labels. An ingress PE that is using PW signalling and that does not send an FL Sub-TLV MUST NOT include a flow label in the PW packet. An ingress PE that is using PW signalling and that does not receive an FL Sub-TLV from its egress peer MUST NOT include a flow label in the PW packet. This preserves backwards compatibility with existing PW specifications.
缺少FL子TLV表示PE无法处理流标签。使用PW信令且未发送FL子TLV的入口PE不得在PW数据包中包含流标签。使用PW信令且未从其出口对等方接收FL子TLV的入口PE不得在PW分组中包括流标签。这保留了与现有PW规范的向后兼容性。
A PE that wishes to send a flow label in a PW packet MUST include in its label mapping message an FL Sub-TLV with T = 1 (see Section 4.1).
希望在PW数据包中发送流标签的PE必须在其标签映射消息中包含T=1的FL子TLV（见第4.1节）。
A PE that is willing to receive a flow label MUST include in its label mapping message an FL Sub-TLV with R = 1 (see Section 4.1).
愿意接收流量标签的PE必须在其标签映射消息中包含R=1的FL子TLV（见第4.1节）。
A PE that receives a label mapping message containing an FL Sub-TLV with R = 0 MUST NOT include a flow label in the PW packet.
接收包含R=0的FL子TLV的标签映射消息的PE不得在PW数据包中包含流标签。
Thus, a PE sending an FL Sub-TLV with T = 1 and receiving an FL Sub-TLV with R = 1 MUST include a flow label in the PW packet. Under all other combinations of FL Sub-TLV signalling, a PE MUST NOT include a flow label in the PW packet.
因此，发送T=1的FL-Sub-TLV和接收R=1的FL-Sub-TLV的PE必须在PW分组中包括流标签。在FL子TLV信令的所有其他组合下，PE不得在PW分组中包括流标签。
The signalling procedures in [RFC4447] state that "Processing of the interface parameters should continue when unknown interface parameters are encountered, and they MUST be silently ignored". The signalling procedure described here is therefore backwards compatible with existing implementations.
[RFC4447]中的信令程序说明“当遇到未知接口参数时，接口参数的处理应继续进行，并且必须默默忽略”。因此，此处描述的信令过程与现有实现向后兼容。
Note that what is signalled is the desire to include the flow LSE in the label stack. The value of the flow label is a local matter for the ingress PE, and the label value itself is not signalled.
注意，发出信号的是希望在标签堆栈中包括流LSE。流量标签的值是入口PE的局部问题，并且标签值本身没有发出信号。
The structure of the Flow Label Sub-TLV is shown in Figure 3.
流标签子TLV的结构如图3所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FL=0x17 | Length |T|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FL=0x17 | Length |T|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Flow Label Sub-TLV
图3：流量标签子TLV
Where:
哪里：
o FL (value 0x17) is the Flow Label Sub-TLV identifier assigned by IANA (see Section 11).
o FL（值0x17）是IANA分配的流量标签子TLV标识符（见第11节）。
o Length is the length of the Sub-TLV in octets and is 4.
o 长度是子TLV的长度（以八位字节为单位），为4。
o When T = 1, the PE is requesting the ability to send a PW packet that includes a flow label. When T = 0, the PE is indicating that it will not send a PW packet containing a flow label.
o 当T＝1时，PE请求能够发送包括流标签的PW分组。当T=0时，PE表示它不会发送包含流标签的PW数据包。
o When R = 1, the PE is able to receive a PW packet with a flow label present. When R = 0, the PE is unable to receive a PW packet with the flow label present.
o 当R＝1时，PE能够接收存在流标签的PW分组。当R=0时，PE无法接收流标签存在的PW数据包。
o Reserved bits MUST be zero on transmit and MUST be ignored on receive.
o 保留位在传输时必须为零，在接收时必须忽略。
If PWE3 signalling [RFC4447] is not in use for a PW, then whether the flow label is used MUST be identically provisioned in both PEs at the PW endpoints. If there is no provisioning support for this option, the default behaviour is not to include the flow label.
如果PWE3信令[RFC4447]未用于PW，则必须在PW端点的两个PE中相同地设置是否使用流标签。如果此选项不支持设置，则默认行为不包括流标签。
The flow label mechanism described in this document works on multi-segment PWs without requiring modification to the Switching PEs (S-PEs). This is because the flow LSE is transparent to the label swap operation, and because interface parameter Sub-TLV signalling is transitive.
本文件中描述的流量标签机制适用于多段PWs，无需修改切换PEs（S-PEs）。这是因为流LSE对标签交换操作是透明的，并且因为接口参数Sub TLV信令是可传递的。
The following OAM considerations apply to this method of load balancing.
以下OAM注意事项适用于此负载平衡方法。
Where the OAM is only to be used to perform a basic test to verify that the PWs have been configured at the PEs, Virtual Circuit Connectivity Verification (VCCV) [RFC5085] messages may be sent using any load balance PW path, i.e., using any value for the flow label.
如果OAM仅用于执行基本测试，以验证PWs是否已在PEs处配置，则可使用任何负载平衡PW路径发送虚拟电路连接验证（VCCV）[RFC5085]消息，即使用流标签的任何值。
Where it is required to verify that a pseudowire is fully functional for all flows, a VCCV [RFC5085] connectivity verification message MUST be sent over each ECMP path to the pseudowire egress PE. This solution may be difficult to achieve and scales poorly. Under these circumstances, it may be sufficient to send VCCV messages using any load balance pseudowire path, because if a failure occurs within the PSN, the failure will normally be detected and repaired by the PSN. That is, the PSN's Interior Gateway Protocol (IGP) link/node failure detection mechanism (loss of light, bidirectional forwarding detection [RFC5880], or IGP hello detection) and the IGP convergence will naturally modify the ECMP set of network paths between the ingress and egress PEs. Hence, the PW is only impacted during the normal IGP convergence time. Note that this period may be reduced if a fast re-route or fast convergence technology is deployed in the network [RFC4090] [RFC5286].
如果需要验证伪线对所有流是否完全起作用，则必须通过每个ECMP路径向伪线出口PE发送VCCV[RFC5085]连接验证消息。此解决方案可能难以实现，而且扩展性较差。在这些情况下，使用任何负载平衡伪线路径发送VCCV消息就足够了，因为如果PSN内发生故障，故障通常会被PSN检测并修复。也就是说，PSN的内部网关协议（IGP）链路/节点故障检测机制（失光、双向转发检测[RFC5880]或IGP hello检测）和IGP汇聚将自然地修改入口和出口PE之间的ECMP网络路径集。因此，PW仅在正常IGP收敛时间内受到影响。请注意，如果在网络中部署了快速重路由或快速汇聚技术[RFC4090][RFC5286]，则此时间段可能会缩短。
If the failure is related to the individual corruption of a Label Forwarding Information Base (LFIB) entry in a router, then only the network path using that specific entry is impacted. If the PW is load-balanced over multiple network paths, then this failure can only be detected if, by chance, the transported OAM flow is mapped onto the impacted network path, or if all paths are tested. Since testing all paths may present problems as noted above, other mechanisms to detect this type of error may need to be developed, such as a Label Switched Path (LSP) self-test technology.
如果故障与路由器中标签转发信息库（LFIB）条目的个别损坏有关，则只有使用该特定条目的网络路径受到影响。如果PW在多个网络路径上进行负载平衡，则只有在传输的OAM流被映射到受影响的网络路径上，或者如果所有路径都经过测试，才能检测到此故障。由于测试所有路径可能会出现上述问题，因此可能需要开发检测此类错误的其他机制，例如标签交换路径（LSP）自检技术。
To troubleshoot the MPLS PSN, including multiple paths, the techniques described in [RFC4378] and [RFC4379] can be used.
为了对MPLS PSN（包括多条路径）进行故障排除，可以使用[RFC4378]和[RFC4379]中描述的技术。
Where the PW OAM is carried out of band (VCCV Type 2) [RFC5085], it is necessary to insert an "MPLS Router Alert Label" in the label stack. The resultant label stack is as follows:
如果PW OAM在带外执行（VCCV类型2）[RFC5085]，则有必要在标签堆栈中插入“MPLS路由器警报标签”。生成的标签堆栈如下所示：
+-------------------------------+
| |
| VCCV Message | n octets
| |
+-------------------------------+
| Optional Control Word | 4 octets
+-------------------------------+
| Flow LSE | 4 octets
+-------------------------------+
| PW LSE | 4 octets
+-------------------------------+
| Router Alert LSE | 4 octets
+-------------------------------+
| MPLS Tunnel LSE(s) | n*4 octets (four octets per label)
+-------------------------------+
+-------------------------------+
| |
| VCCV Message | n octets
| |
+-------------------------------+
| Optional Control Word | 4 octets
+-------------------------------+
| Flow LSE | 4 octets
+-------------------------------+
| PW LSE | 4 octets
+-------------------------------+
| Router Alert LSE | 4 octets
+-------------------------------+
| MPLS Tunnel LSE(s) | n*4 octets (four octets per label)
+-------------------------------+
Figure 4: Use of Router Alert Label
图4：路由器警报标签的使用
Note that, depending on the number of labels hashed by the LSR, the inclusion of the Router Alert label may cause the OAM packet to be load-balanced to a different path from that taken by the data packets with identical flow and PW labels.
注意，根据LSR散列的标签数量，路由器警报标签的包含可能导致OAM分组负载平衡到与具有相同流和PW标签的数据分组所采用的路径不同的路径。
A node within the PSN is not able to perform deep packet inspection (DPI) of the PW, as the PW technology is not self-describing: the structure of the PW payload is only known to the ingress and egress PE devices. The method proposed in this document provides a statistical mitigation of the problem of load balance in those cases where a PE is able to discern flows embedded in the traffic received on the attachment circuit.
PSN内的节点不能执行PW的深度分组检查（DPI），因为PW技术不是自描述的：PW有效载荷的结构仅对入口和出口PE设备已知。本文件中提出的方法在PE能够识别在连接电路上接收的流量中嵌入的流量的情况下，提供了负载平衡问题的统计缓解。
The methods described in this document are transparent to the PSN and as such do not require any new capability from the PSN.
本文档中描述的方法对PSN是透明的，因此不需要PSN提供任何新功能。
The requirement to load-balance over multiple PSN paths occurs when the ratio between the PW access speed and the PSN's core link bandwidth is large (e.g., >= 10%). ATM and Frame Relay are unlikely to meet this property. Ethernet may have this property, and for that reason this document focuses on Ethernet. Applications for other high-access-bandwidth PWs may be defined in the future.
当PW访问速度和PSN的核心链路带宽之间的比率较大（例如>=10%）时，需要在多个PSN路径上进行负载平衡。ATM和帧中继不太可能满足此特性。以太网可能具有此属性，因此本文档重点介绍以太网。将来可能会定义其他高访问带宽PW的应用。
This design applies to MPLS PWs where it is meaningful to de-construct the packets presented to the ingress PE into flows. The mechanism described in this document promotes the distribution of flows within the PW over different network paths. In turn, this means that whilst packets within a flow are delivered in order
此设计适用于MPLS PWs，在MPLS PWs中，将呈现给入口PE的数据包分解为流是有意义的。本文件中描述的机制促进了PW内不同网络路径上的流量分布。反过来，这意味着流中的数据包是按顺序传递的
(subject to normal IP delivery perturbations due to topology variation), order is no longer maintained for all packets sent over the PW. It is not proposed to associate a different sequence number with each flow. If sequence number support is required, the flow label mechanism MUST NOT be used.
（受拓扑变化导致的正常IP交付干扰的影响），不再维持通过PW发送的所有数据包的顺序。不建议将不同的序列号与每个流相关联。如果需要序列号支持，则不得使用流标签机制。
Where it is known that the traffic carried by the Ethernet PW is IP, the flows can be identified and mapped to an ECMP. Such methods typically include hashing on the source and destination addresses, the protocol ID and higher-layer flow-dependent fields such as TCP/UDP ports, Layer 2 Tunneling Protocol version 3 (L2TPv3) Session IDs, etc.
在已知以太网PW承载的流量是IP的情况下，可以识别流并将其映射到ECMP。此类方法通常包括对源地址和目标地址、协议ID和更高层的流相关字段（如TCP/UDP端口、第2层隧道协议版本3（L2TPv3）会话ID）进行哈希处理。
Where it is known that the traffic carried by the Ethernet PW is non-IP, techniques used for link bundling between Ethernet switches may be reused. In this case, however, the latency distribution would be larger than is found in the link bundle case. The acceptability of the increased latency is for further study. Of particular importance, the Ethernet control frames SHOULD always be mapped to the same PSN path to ensure in-order delivery.
在已知以太网PW承载的业务是非IP的情况下，用于以太网交换机之间的链路捆绑的技术可以重用。但是，在这种情况下，延迟分布将比链路包情况下的延迟分布更大。增加的潜伏期的可接受性有待进一步研究。特别重要的是，以太网控制帧应始终映射到相同的PSN路径，以确保有序交付。
ECMP in packet switched networks is statistical in nature. The mapping of flows to a particular path does not take into account the bandwidth of the flow being mapped or the current bandwidth usage of the members of the ECMP set. This simplification works well when the distribution of flows is evenly spread over the ECMP set and there are a large number of flows that have low bandwidth relative to the paths. The random allocation of a flow to a path provides a good approximation to an even spread of flows, provided that polarisation effects are avoided. The method defined in this document has the same statistical properties as an IP PSN.
分组交换网络中的ECMP本质上是统计的。流到特定路径的映射不考虑被映射流的带宽或ECMP集成员的当前带宽使用情况。当流的分布均匀地分布在ECMP集合上，并且存在大量相对于路径具有低带宽的流时，这种简化效果很好。在避免极化效应的前提下，将流随机分配到路径可以很好地近似于流的均匀分布。本文件中定义的方法与IP PSN具有相同的统计特性。
ECMP is a load-sharing mechanism that is based on sharing the load over a number of layer 3 paths through the PSN. Often, however, multiple links exist between a pair of LSRs that are considered by the IGP to be a single link. These are known as link bundles. The mechanism described in this document can also be used to distribute the flows within a PW over the members of the link bundle by using the flow label value to identify candidate flows. How that mapping takes place is outside the scope of this specification. Similar considerations apply to Link Aggregation Groups.
ECMP是一种负载共享机制，它基于通过PSN在多个第3层路径上共享负载。然而，通常情况下，一对LSR之间存在多条链路，IGP将其视为一条链路。这些被称为链接束。本文档中描述的机制还可用于通过使用流标签值识别候选流，将PW内的流分布到链接束的成员上。映射的发生方式超出了本规范的范围。类似的注意事项也适用于链接聚合组。
There is no mechanism currently defined to indicate the bandwidths in use by specific flows using the fields of the MPLS shim header. Furthermore, since the semantics of the MPLS shim header are fully defined in [RFC3032] and [RFC5462], those fields cannot be assigned
目前还没有定义任何机制来指示特定流使用MPLS垫片报头字段使用的带宽。此外，由于在[RFC3032]和[RFC5462]中完全定义了MPLS垫片头的语义，因此无法分配这些字段
semantics to carry this information. This document does not define any semantic for use in the TTL or TC fields of the label entry that carries the flow label, but requires that the flow label itself be selected with a high degree of entropy suggesting that the label value should not be overloaded with additional meaning in any subsequent specification.
语义来承载这些信息。本文件未定义任何语义，用于携带流量标签的标签条目的TTL或TC字段，但要求选择具有高度熵的流量标签本身，这表明标签值不应在任何后续规范中具有额外含义。
A different type of load balancing is the desire to carry a PW over a set of PSN links in which the bandwidth of members of the link set is less than the bandwidth of the PW. Proposals to address this problem have been made in the past [PWBONDING]. Such a mechanism can be considered complementary to this mechanism.
不同类型的负载平衡是希望在一组PSN链路上承载PW，其中链路组成员的带宽小于PW的带宽。过去曾提出过解决这一问题的建议。这种机制可以被认为是对这一机制的补充。
A Link Aggregation Group (LAG) is used to bond together several physical circuits between two adjacent nodes so they appear to higher-layer protocols as a single, higher-bandwidth "virtual" pipe. These may coexist in various parts of a given network. An advantage of LAGs is that they reduce the number of routing and signalling protocol adjacencies between devices, reducing control plane processing overhead. As with ECMP, the key problem related to LAGs is that due to inefficiencies in LAG load-distribution algorithms, a particular component of a LAG may experience congestion. The mechanism proposed here may be able to assist in producing a more uniform flow distribution.
链路聚合组（LAG）用于将两个相邻节点之间的多个物理电路连接在一起，以便它们在高层协议中显示为单个、更高带宽的“虚拟”管道。这些可能共存于给定网络的各个部分。LAGs的一个优点是，它们减少了设备之间路由和信令协议邻接的数量，从而减少了控制平面处理开销。与ECMP一样，与滞后相关的关键问题是，由于滞后负载分配算法效率低下，滞后的特定部分可能会遇到拥塞。这里提出的机制可能有助于产生更均匀的流量分布。
The same considerations requiring a flow to go over a single member of an ECMP set apply to a member of a LAG.
要求流通过ECMP集的单个成员的考虑同样适用于LAG的成员。
In some networks, it is desirable for a Label Edge Router (LER) to be able to load-balance a PW across multiple Resource Reservation Protocol - Traffic Engineering (RSVP-TE) tunnels. The flow label mechanism described in this document may be used to provide the LER with the required flow information and necessary entropy to provide this type of load balancing. An example of such a case is the use of the flow label mechanism in networks using a link bundle with the all ones component [RFC4201].
在一些网络中，标签边缘路由器（LER）需要能够跨多个资源预留协议-流量工程（RSVP-TE）隧道对PW进行负载平衡。本文档中描述的流标签机制可用于向LER提供所需的流信息和必要的熵，以提供此类负载平衡。这种情况的一个例子是在网络中使用流标签机制，该网络使用带有“全一”组件的链接束[RFC4201]。
Methods by which the LER is configured to apply this type of ECMP are outside the scope of this document.
配置LER以应用此类ECMP的方法不在本文档的范围内。
Clearly, the operator should make sure that the service offered using PW technology and the method described in this document do not exceed the maximum planned link capacity, unless it can be guaranteed that they conform to the Internet traffic profile of a very large number of small flows.
显然，运营商应确保使用PW技术和本文件所述方法提供的服务不超过最大计划链路容量，除非可以保证它们符合大量小流量的互联网流量分布。
If the NSP cannot access sufficient information to distinguish flows, perhaps because the protocol stack required parsing further into the packet than it is able, then the functionality described in this document does not give any benefits. The most common case where a single flow dominates the traffic on a PW is when it is used to transport enterprise traffic. Enterprise traffic may well consist of a single, large TCP flow, or encrypted flows that cannot be handled by the methods described in this document.
如果NSP无法访问足够的信息来区分流，可能是因为协议栈需要进一步解析到数据包中，超出了它的能力，那么本文档中描述的功能不会带来任何好处。单个流主导PW上的流量的最常见情况是用于传输企业流量。企业流量很可能由单个大型TCP流或加密流组成，这些流无法通过本文档中描述的方法进行处理。
An operator has four options under these circumstances:
在这些情况下，运营商有四种选择：
1. The operator can choose to do nothing, and the system will work as it does without the flow label.
1. 操作员可以选择不执行任何操作，系统将在没有流量标签的情况下正常工作。
2. The operator can make the customer aware that the service offering has a restriction on flow bandwidth and police flows to that restriction. This would allow customers offering multiple flows to use a larger fraction of their access bandwidth, whilst preventing a single flow from consuming a fraction of internal link bandwidth that the operator considered excessive.
2. 运营商可以让客户意识到服务提供对流量带宽有限制，并监督流向该限制的流量。这将允许提供多个流的客户使用其访问带宽的较大部分，同时防止单个流消耗运营商认为过多的部分内部链路带宽。
3. The operator could configure the ingress PE to assign a constant flow label to all high-bandwidth flows so that only one path was affected by these flows.
3. 操作员可以配置入口PE，为所有高带宽流分配恒定流标签，以便只有一条路径受到这些流的影响。
4. The operator could configure the ingress PE to assign a random flow label to all high-bandwidth flows so as to minimise the disruption to the network at the cost of out-of-order traffic to the user.
4. 运营商可以配置入口PE，以将随机流标签分配给所有高带宽流，从而最大限度地减少对网络的干扰，同时以用户的无序流量为代价。
The issues described above are mitigated by the following two factors:
以下两个因素缓解了上述问题：
o Firstly, the customer of a high-bandwidth PW service has an incentive to get the best transport service, because an inefficient use of the PSN leads to jitter and eventually to loss to the PW's payload.
o 首先，高带宽PW服务的客户有获得最佳传输服务的动机，因为PSN的低效使用会导致抖动，并最终导致PW的有效负载丢失。
o Secondly, the customer is usually able to tailor their applications to generate many flows in the PSN. A well-known example is massive data transport between servers that use many parallel TCP sessions. This same technique can be used by any transport protocol: multiple UDP ports, multiple L2TPv3 Session IDs, or multiple Generic Routing Encapsulation (GRE) keys may be used to decompose a large flow into smaller components. This approach may be applied to IPsec [RFC4301] where multiple Security Parameter Indexes (SPIs) may be allocated to the same security association.
o 其次，客户通常能够定制他们的应用程序以在PSN中生成许多流。一个著名的例子是使用许多并行TCP会话的服务器之间的海量数据传输。任何传输协议都可以使用相同的技术：可以使用多个UDP端口、多个L2TPv3会话ID或多个通用路由封装（GRE）密钥将大流量分解为更小的组件。此方法可应用于IPsec[RFC4301]，其中多个安全参数索引（SPI）可分配给同一安全关联。
The MPLS Transport Profile (MPLS-TP) [RFC5654] Requirement 44 states that "MPLS-TP MUST support mechanisms that ensure the integrity of the transported customer's service traffic as required by its associated Service Level Agreement (SLA). Loss of integrity may be defined as packet corruption, reordering, or loss during normal network conditions". In addition, MPLS-TP makes extensive use of the fate sharing between OAM and data packets, which is defeated by the flow LSE. The flow-aware transport of a PW reorders packets and therefore MUST NOT be deployed in a network conforming to MPLS-TP, unless these integrity requirements specified in the SLA can be satisfied.
MPLS传输配置文件（MPLS-TP）[RFC5654]要求44规定，“MPLS-TP必须支持相关服务水平协议（SLA）要求的机制，以确保传输的客户服务流量的完整性。完整性损失可定义为正常网络条件下的数据包损坏、重新排序或丢失。”. 此外，MPLS-TP广泛利用了OAM和数据包之间的命运共享，这一点被流LSE所克服。PW的流感知传输对数据包进行重新排序，因此不得部署在符合MPLS-TP的网络中，除非满足SLA中规定的这些完整性要求。
The protocol defined in this document supports the asymmetric inclusion of the flow LSE. Asymmetric operation can be expected when there is asymmetry in the bandwidth requirements making it unprofitable for one PE to perform the flow classification, or when that PE is otherwise unable to perform the classification but is able to receive flow labeled packets from its peer. Asymmetric operation of the PW may also be required when one PE has a high transmission bandwidth requirement, but has a need to receive the entire PW on a single interface in order to perform a processing operation that requires the context of the complete PW (for example, policing of the egress traffic).
本文档中定义的协议支持流LSE的非对称包含。当带宽需求不对称使得一个PE执行流分类无利可图时，或者当该PE无法执行分类但能够从其对等方接收流标记的分组时，可以预期不对称操作。当一个PE具有高传输带宽需求，但需要在单个接口上接收整个PW以执行需要完整PW的上下文的处理操作（例如，出口业务的监管）时，也可能需要PW的非对称操作。
An extension of this technique is to create a basis for hash diversity without having to peek below the label stack for IP traffic carried over Label Distribution Protocol (LDP) LSPs. The generalisation of this extension to MPLS has been described in [MPLS-ENTROPY]. This generalisation can be regarded as a
该技术的一个扩展是为哈希多样性创建基础，而无需查看标签分发协议（LDP）LSP上承载的IP流量的标签堆栈下方。[MPLS-熵]中描述了该扩展对MPLS的推广。这一概括可被视为一种
complementary, but distinct, approach from the technique described in this document. While similar consideration may apply to the identification of flows and the allocation of flow label values, the flow labels are imposed by different network components, and the associated signalling mechanisms are different.
与本文件中描述的技术互补但不同的方法。虽然类似的考虑可应用于流的识别和流标签值的分配，但流标签由不同的网络组件施加，并且相关的信令机制不同。
The PW generic security considerations described in [RFC3985] and the security considerations applicable to a specific PW type (for example, in the case of an Ethernet PW [RFC4448]) apply. The security considerations in [RFC5920] also apply.
[RFC3985]中描述的PW通用安全注意事项和适用于特定PW类型的安全注意事项（例如，在以太网PW[RFC4448]的情况下）适用。[RFC5920]中的安全注意事项也适用。
Section 1.3 describes considerations that apply to the TTL value used in the flow LSE. The use of a TTL value of one prevents the accidental forwarding of a packet based on the label value in the flow LSE.
第1.3节描述了适用于流量LSE中使用的TTL值的注意事项。TTL值的使用防止了基于流LSE中的标签值的分组的意外转发。
IANA maintains the registry "Pseudowire Name Spaces (PWE3)" with sub-registry "Pseudowire Interface Parameters Sub-TLV type Registry". IANA has registered the Flow Label Sub-TLV type in this registry.
IANA使用子注册表“伪线接口参数子TLV类型注册表”维护注册表“伪线名称空间（PWE3）”。IANA已在此注册表中注册流标签子TLV类型。
Parameter ID Length Description Reference
------------------------------------------------------
0x17 4 Flow Label RFC 6391
Parameter ID Length Description Reference
------------------------------------------------------
0x17 4 Flow Label RFC 6391
The congestion considerations applicable to PWs as described in [RFC3985] apply to this design.
[RFC3985]中描述的适用于PWs的拥塞考虑适用于本设计。
The ability to explicitly configure a PW to leverage the availability of multiple ECMPs is beneficial to capacity planning as, all other parameters being constant, the statistical multiplexing of a larger number of smaller flows is more efficient than with a smaller number of larger flows.
显式配置PW以利用多个ECMP的可用性的能力有利于容量规划，因为在所有其他参数不变的情况下，较大数量的较小流的统计复用比较小数量的较大流更有效。
Note that if the classification into flows is only performed on IP packets, the behaviour of those flows in the face of congestion will be as already defined by the IETF for packets of that type, and no additional congestion processing is required.
请注意，如果仅对IP数据包执行流分类，则这些流在拥塞情况下的行为将与IETF针对该类型数据包所定义的行为相同，并且不需要额外的拥塞处理。
Where flows that are not IP are classified, PW congestion avoidance must be applied to each non-IP load balance group.
如果对非IP流进行分类，则必须对每个非IP负载平衡组应用PW拥塞避免。
The authors wish to thank Mary Barnes, Eric Grey, Kireeti Kompella, Joerg Kuechemann, Wilfried Maas, Luca Martini, Mark Townsley, Rolf Winter, and Lucy Yong for valuable comments on this document.
作者感谢玛丽·巴恩斯、埃里克·格雷、基里蒂·科佩拉、约尔格·库切曼、威尔弗里德·马斯、卢卡·马提尼、马克·汤斯利、罗尔夫·温特和露西·杨对本文件的宝贵意见。
[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月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379]Kompella，K.和G.Swallow，“检测多协议标签交换（MPLS）数据平面故障”，RFC 4379，2006年2月。
[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月。
[RFC4447] Martini, L., Ed., 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.，Ed.，Rosen，E.，El Aawar，N.，Smith，T.，和G.Heron，“使用标签分发协议（LDP）的伪线设置和维护”，RFC 4447，2006年4月。
[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006.
[RFC4448]Martini，L.，Ed.，Rosen，E.，El Aawar，N.，和G.Heron，“通过MPLS网络传输以太网的封装方法”，RFC 4448，2006年4月。
[RFC4553] Vainshtein, A., Ed., and YJ. Stein, Ed., "Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)", RFC 4553, June 2006.
[RFC4553]Vainstein，A.，Ed.，和YJ。Stein，Ed.“数据包上的结构不可知时分复用（TDM）（SAToP）”，RFC4553，2006年6月。
[RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal Cost Multipath Treatment in MPLS Networks", BCP 128, RFC 4928, June 2007.
[RFC4928]Swallow，G.，Bryant，S.和L.Andersson，“避免MPLS网络中的等成本多路径处理”，BCP 128，RFC 4928，2007年6月。
[RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[RFC5085]Nadeau，T.，Ed.，和C.Pignataro，Ed.，“伪线虚拟电路连接验证（VCCV）：伪线的控制通道”，RFC 5085，2007年12月。
[MPLS-ENTROPY] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", Work in Progress, October 2011.
[MPLS-熵]Kompella，K.，Drake，J.，Amante，S.，Henderickx，W.，和L.Yong，“MPLS转发中熵标签的使用”，正在进行的工作，2011年10月。
[PWBONDING] Stein, Y(J)., Mendelsohn, I., and R. Insler, "PW Bonding", Work in Progress, November 2008.
[PWBONDING]Stein，Y（J.），Mendelsohn，I.和R.Insler，“PW Bonding”，进行中的工作，2008年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月。
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090]Pan，P.，Ed.，Swallow，G.，Ed.，和A.Atlas，Ed.，“LSP隧道RSVP-TE快速重路由扩展”，RFC 40902005年5月。
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4201]Kompella，K.，Rekhter，Y.，和L.Berger，“MPLS流量工程（TE）中的链路捆绑”，RFC 42012005年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4378] Allan, D., Ed., and T. Nadeau, Ed., "A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM)", RFC 4378, February 2006.
[RFC4378]Allan，D.，Ed.，和T.Nadeau，Ed.，“多协议标签交换（MPLS）操作和管理（OAM）框架”，RFC 4378，2006年2月。
[RFC5286] Atlas, A., Ed., and A. Zinin, Ed., "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, September 2008.
[RFC5286]Atlas，A.，Ed.，和A.Zinin，Ed.“IP快速重路由的基本规范：无环路替代”，RFC 5286，2008年9月。
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, February 2009.
[RFC5462]Andersson，L.和R.Asati，“多协议标签交换（MPLS）标签堆栈条目：“EXP”字段重命名为“流量类”字段”，RFC 5462，2009年2月。
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
[RFC5654]Niven Jenkins，B.，Ed.，Brungard，D.，Ed.，Betts，M.，Ed.，Sprecher，N.，和S.Ueno，“MPLS传输配置文件的要求”，RFC 56542009年9月。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[RFC5880]Katz，D.和D.Ward，“双向转发检测（BFD）”，RFC 58802010年6月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，RFC 5920，2010年7月。
Authors' Addresses
作者地址
Stewart Bryant (editor) Cisco Systems 250 Longwater Ave. Reading RG2 6GB United Kingdom
Stewart Bryant（编辑）Cisco Systems 250 Longwater Ave.Reading RG2 6GB英国
Phone: +44-208-824-8828
EMail: stbryant@cisco.com
Phone: +44-208-824-8828
EMail: stbryant@cisco.com
Clarence Filsfils Cisco Systems Brussels Belgium
Clarence Filsfils思科系统比利时布鲁塞尔
EMail: cfilsfil@cisco.com
EMail: cfilsfil@cisco.com
Ulrich Drafz Deutsche Telekom Muenster Germany
德国慕尼黑电信公司
EMail: Ulrich.Drafz@telekom.de
EMail: Ulrich.Drafz@telekom.de
Vach Kompella Alcatel-Lucent
阿尔卡特朗讯公司
EMail: vach.kompella@alcatel-lucent.com
EMail: vach.kompella@alcatel-lucent.com
Joe Regan Alcatel-Lucent
乔·里根·阿尔卡特·朗讯
EMail: joe.regan@alcatel-lucent.com
EMail: joe.regan@alcatel-lucent.com
Shane Amante Level 3 Communications, LLC 1025 Eldorado Blvd. Broomfield, CO 80021 USA
谢恩·阿曼特三级通信有限责任公司埃尔多拉多大道1025号。美国科罗拉多州布鲁姆菲尔德80021
EMail: shane@level3.net
EMail: shane@level3.net