Internet Engineering Task Force (IETF) K. Patel
Request for Comments: 8395 Arrcus
Updates: 4761 S. Boutros
Category: Standards Track VMware
ISSN: 2070-1721 J. Liste
Cisco
B. Wen
Comcast
J. Rabadan
Nokia
June 2018
Internet Engineering Task Force (IETF) K. Patel
Request for Comments: 8395 Arrcus
Updates: 4761 S. Boutros
Category: Standards Track VMware
ISSN: 2070-1721 J. Liste
Cisco
B. Wen
Comcast
J. Rabadan
Nokia
June 2018
Extensions to BGP-Signaled Pseudowires to Support Flow-Aware Transport Labels
BGP信号伪线的扩展，以支持流感知传输标签
Abstract
摘要
This document defines protocol extensions required to synchronize flow label states among Provider Edges (PEs) when using the BGP-based signaling procedures. These protocol extensions are equally applicable to point-to-point Layer 2 Virtual Private Networks (L2VPNs). This document updates RFC 4761 by defining new flags in the Control Flags field of the Layer2 Info Extended Community.
本文档定义了在使用基于BGP的信令过程时，同步提供商边缘（PE）之间的流标签状态所需的协议扩展。这些协议扩展同样适用于点对点第2层虚拟专用网络（L2VPN）。本文档通过在Layer2信息扩展社区的控制标志字段中定义新标志来更新RFC 4761。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8395.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8395.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Requirements Language ......................................3
2. Modifications to the Layer2 Info Extended Community .............4
3. Signaling the Presence of the Flow Label ........................5
4. IANA Considerations .............................................6
5. Security Considerations .........................................6
6. References ......................................................7
6.1. Normative References .......................................7
6.2. Informative References .....................................7
Acknowledgements ...................................................8
Contributors .......................................................8
Authors' Addresses .................................................9
1. Introduction ....................................................2
1.1. Requirements Language ......................................3
2. Modifications to the Layer2 Info Extended Community .............4
3. Signaling the Presence of the Flow Label ........................5
4. IANA Considerations .............................................6
5. Security Considerations .........................................6
6. References ......................................................7
6.1. Normative References .......................................7
6.2. Informative References .....................................7
Acknowledgements ...................................................8
Contributors .......................................................8
Authors' Addresses .................................................9
The mechanism described in [RFC6391] uses an additional label (Flow Label) in the MPLS label stack to allow Label Switching Routers (LSRs) to balance flows within Pseudowires (PWs) at a finer granularity than the individual PWs across the Equal Cost Multiple Paths (ECMPs) that exists within the Packet Switched Network (PSN).
[RFC6391]中描述的机制使用MPLS标签堆栈中的附加标签（流标签），以允许标签交换路由器（LSR）在分组交换网络（PSN）中存在的等成本多路径（ECMP）中以比单个PW更细的粒度平衡伪线（PW）中的流。
Furthermore, [RFC6391] defines the LDP protocol extensions required to synchronize the flow label states between the ingress and egress PEs when using the signaling procedures defined in the [RFC8077].
此外，[RFC6391]定义了在使用[RFC8077]中定义的信令过程时，同步入口和出口PE之间的流标签状态所需的LDP协议扩展。
A PW [RFC3985] is transported over one single network path, even if ECMPs exist between the ingress and egress PW provider edge (PE) equipment. This is required to preserve the characteristics of the emulated service.
PW[RFC3985]通过单个网络路径传输，即使入口和出口PW提供商边缘（PE）设备之间存在ECMP。这是保持模拟服务的特征所必需的。
This document introduces an optional mode of operation allowing a PW to be transported over ECMPs, for example when the use of ECMPs is known to be beneficial to the operation of the PW. This specification uses the principles defined in [RFC6391] and augments the BGP-signaling procedures of [RFC4761] and [RFC6624]. The use of a single path to preserve the packet delivery order remains the default mode of operation of a PW and is described in [RFC4385] and [RFC4928].
本文件介绍了允许通过ECMPs运输PW的可选操作模式，例如，当已知ECMPs的使用有利于PW的操作时。本规范使用了[RFC6391]中定义的原则，并扩充了[RFC4761]和[RFC6624]中的BGP信令程序。使用单个路径来保持数据包交付顺序仍然是PW的默认操作模式，并在[RFC4385]和[RFC4928]中进行了描述。
High-bandwidth Ethernet-based services are a prime example that use of the optional mode benefits from the ability to load-balance flows in a PW over multiple PSN paths. In general, load-balancing is applicable when the PW attachment circuit bandwidth and PSN core link bandwidth are of the same order of magnitude.
基于高带宽以太网的服务是一个主要示例，使用可选模式可以通过多个PSN路径在PW中平衡流量。通常，当PW连接电路带宽和PSN核心链路带宽具有相同数量级时，负载平衡适用。
To achieve the load-balancing goal, [RFC6391] introduces the notion of an additional Label Stack Entry (LSE) (flow label) located at the bottom of the stack (right after PW LSE). LSRs commonly generate a hash of the label stack in order to discriminate and distribute flows over available ECMPs. The presence of the flow label (closely associated to a flow determined by the ingress PE) will normally provide the greatest entropy.
为了实现负载平衡目标，[RFC6391]引入了位于堆栈底部（PW LSE之后）的附加标签堆栈项（LSE）（流标签）的概念。LSR通常生成标签堆栈的散列，以便在可用ECMP上区分和分配流。流量标签的存在（与入口PE确定的流量密切相关）通常会提供最大的熵。
Furthermore, following the procedures for inter-AS scenarios described in Section 3.4 of [RFC4761], the flow label should never be handled by the ASBRs; only the terminating PEs on each AS will be responsible for popping or pushing this label. This is equally applicable to Method B as described in Section 3.4.2 of [RFC4761], where ASBRs are responsible for swapping the PW label as traffic traverses from ASBR to PE and ASBR to ASBR. Therefore, the flow label will remain untouched across AS boundaries.
此外，按照[RFC4761]第3.4节所述的AS间场景程序，ASBR不得处理流量标签；只有每个AS上的终端PE负责弹出或推送此标签。这同样适用于[RFC4761]第3.4.2节所述的方法B，其中ASBR负责在流量从ASBR到PE和ASBR到ASBR的过程中交换PW标签。因此，流标签将作为边界保持不变。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
The Layer2 Info Extended Community is used to signal control information about the PWs to be set up. The Extended Community format is described in [RFC4761]. The format of this Extended Community is described as:
Layer2信息扩展社区用于发送有关要设置的PWs的控制信息。[RFC4761]中描述了扩展社区格式。该扩展社区的格式如下所述：
+------------------------------------+
| Extended Community type (2 octets) |
+------------------------------------+
| Encaps Type (1 octet) |
+------------------------------------+
| Control Flags (1 octet) |
+------------------------------------+
| Layer-2 MTU (2 octets) |
+------------------------------------+
| Reserved (2 octets) |
+------------------------------------+
+------------------------------------+
| Extended Community type (2 octets) |
+------------------------------------+
| Encaps Type (1 octet) |
+------------------------------------+
| Control Flags (1 octet) |
+------------------------------------+
| Layer-2 MTU (2 octets) |
+------------------------------------+
| Reserved (2 octets) |
+------------------------------------+
Figure 1: Layer2 Info Extended Community
图1:Layer2信息扩展社区
Control Flags:
控制标志：
This field contains bit flags relating to the control information about PWs. This field is augmented with a definition of two new flags fields.
此字段包含与PWs控制信息相关的位标志。此字段由两个新标志字段的定义扩充。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Z|Z|Z|Z|T|R|C|S| (Z = MUST Be Zero)
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Z|Z|Z|Z|T|R|C|S| (Z = MUST Be Zero)
+-+-+-+-+-+-+-+-+
Figure 2: Control Flags Bit Vector
图2：控制标志位向量
With reference to the Control Flags Bit Vector, the following bits in the Control Flags are defined. The remaining bits, designated "Z", MUST be set to zero when sending and MUST be ignored when receiving this Extended Community.
参考控制标志位向量，定义控制标志中的以下位。在发送时，指定为“Z”的剩余位必须设置为零，在接收此扩展社区时必须忽略。
T When the bit value is 1, the PE announces the ability to send a PW packet that includes a flow label. When the bit value is 0, the PE is indicating that it will not send a PW packet containing a flow label.
T当比特值为1时，PE宣布能够发送包含流标签的PW数据包。当位值为0时，PE表示它不会发送包含流标签的PW数据包。
R When the bit value is 1, the PE is able to receive a PW packet with a flow label present. When the bit value is 0, the PE is unable to receive a PW packet with the flow label present.
R当比特值为1时，PE能够接收存在流标签的PW分组。当位值为0时，PE无法接收流标签存在的PW数据包。
C Defined in [RFC4761].
C在[RFC4761]中定义。
S Defined in [RFC4761].
[RFC4761]中定义的。
As part of the PW signaling procedures described in [RFC4761], a Layer2 Info Extended Community is advertised in the Virtual Private LAN Service (VPLS) BGP Network Layer Reachability Information (NLRI).
作为[RFC4761]中描述的PW信令过程的一部分，在虚拟专用LAN服务（VPLS）BGP网络层可达性信息（NLRI）中公布Layer2信息扩展社区。
A PE that wishes to send a flow label in a PW packet MUST include in its VPLS BGP NLRI a Layer2 Info Extended Community using Control Flags field with T = 1.
希望在PW数据包中发送流标签的PE必须在其VPLS BGP NLRI中包含一个Layer2信息扩展社区，使用T=1的控制标志字段。
A PE that is willing to receive a flow label in a PW packet MUST include in its VPLS BGP NLRI a Layer2 Info Extended Community using Control Flags field with R = 1.
愿意在PW数据包中接收流标签的PE必须在其VPLS BGP NLRI中包含一个Layer2信息扩展社区，使用R=1的控制标志字段。
A PE that receives a VPLS BGP NLRI containing a Layer2 Info Extended Community with R = 0 MUST NOT include a flow label in the PW packet.
接收包含R=0的Layer2信息扩展社区的VPLS BGP NLRI的PE不得在PW数据包中包含流标签。
Therefore, a PE sending a Control Flags field with T = 1 and receiving a Control Flags field with R = 1 MUST include a flow label in the PW packet. With any other combination, a PE MUST NOT include a flow label in the PW packet.
因此，发送T=1的控制标志字段和接收R=1的控制标志字段的PE必须在PW数据包中包含流标签。对于任何其他组合，PE不得在PW数据包中包含流标签。
A PE MAY support the configuration of the flow label (T and R bits) on a per-service basis (e.g., a VPLS VPN Forwarding Instance (VFI)). Furthermore, it is also possible that on a given service, PEs may not share the same flow label settings. The presence of a flow label is therefore determined on a per-peer basis and according to the local and remote T and R bit values. For example, a PE part of a VPLS and with a local T = 1 must only transmit traffic with a flow label to those peers that signaled R = 1. If the same PE has local R = 1, it must only expect to receive traffic with a flow label from peers with T = 1. Any other traffic must not have a flow label. A PE expecting to receive traffic from a remote peer with a flow label MAY drop traffic that has no flow label. A PE expecting to receive traffic from a remote peer with no flow label MAY drop traffic that has a flow label.
PE可以基于每个服务（例如，VPLS VPN转发实例（VFI））支持流标签（T和R位）的配置。此外，在给定服务上，PEs也可能不共享相同的流标签设置。因此，流标签的存在基于每个对等点并根据本地和远程T和R比特值来确定。例如，VPLS的PE部分和本地T=1必须仅将具有流标签的流量传输给那些发出R=1信号的对等方。如果同一个PE的本地R=1，则它只能期望从T=1的对等方接收具有流标签的流量。任何其他流量不得有流量标签。希望从具有流标签的远程对等方接收流量的PE可能会丢弃没有流标签的流量。希望从没有流标签的远程对等方接收流量的PE可能会丢弃具有流标签的流量。
Modification of flow label settings may impact traffic over a PW, as these could trigger changes in the PEs data-plane programming (i.e., imposition/disposition of the flow label). This is an implementation-specific behavior and is outside the scope of this document.
流量标签设置的修改可能会影响PW上的流量，因为这些可能会触发PEs数据平面编程的更改（即，流量标签的施加/处置）。这是特定于实现的行为，不在本文档的范围内。
The signaling procedures in [RFC4761] state that the unspecified bits in the Control Flags field (bits 0-5) MUST be set to zero when sending and MUST be ignored when receiving. The signaling procedure described here is therefore backwards compatible with existing implementations. A PE not supporting the extensions described in this document will always advertise a value of zero in the R bit; therefore, a flow label will never be included in a packet sent to it by one of its peers. Similarly, it will always advertise a value of zero in the T bit; therefore, a peer will know that a flow label will never be included in a packet sent by it.
[RFC4761]中的信令程序规定，发送时控制标志字段中的未指定位（位0-5）必须设置为零，接收时必须忽略。因此，这里描述的信令过程与现有实现向后兼容。不支持本文件中所述扩展的PE将始终在R位中公布零值；因此，流标签永远不会包含在由其对等方之一发送给它的数据包中。类似地，它将始终在T位中公布一个0的值；因此，对等方将知道流标签永远不会包含在它发送的数据包中。
Note that what is signaled 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 signaled.
注意，发出信号的是希望在标签堆栈中包括流LSE。流量标签的值是入口PE的局部问题，并且标签值本身没有信号。
Although [RFC4761] defined a Control Flags Bit Vector as part of the Layer2 Info Extended Community, it did not ask for the creation of a registry.
尽管[RFC4761]将控制标志位向量定义为Layer2信息扩展社区的一部分，但它并未要求创建注册表。
Per this document, IANA has created the "Layer2 Info Extended Community Control Flags Bit Vector" registry <https://www.iana.org/assignments/bgp-extended-communities>.
根据本文件，IANA创建了“Layer2信息扩展社区控制标志位向量”注册表<https://www.iana.org/assignments/bgp-extended-communities>.
Based on [RFC4761] and this document, the initial contents of this registry are as follows:
根据[RFC4761]和本文件，本注册表的初始内容如下：
Value Name Reference
----- -------------------------------- --------------
T Request to send a flow label This document
R Ability to receive a flow label This document
C Presence of a Control Word RFC 4761
S Sequenced delivery of frames RFC 4761
Value Name Reference
----- -------------------------------- --------------
T Request to send a flow label This document
R Ability to receive a flow label This document
C Presence of a Control Word RFC 4761
S Sequenced delivery of frames RFC 4761
As per [RFC4761] and this document, the remaining bits are unassigned, and MUST be set to zero when sending and MUST be ignored when receiving the Layer2 Info Extended Community.
根据[RFC4761]和本文件，剩余位未分配，发送时必须设置为零，接收Layer2信息扩展社区时必须忽略。
This extension to BGP does not change the underlying security issues inherent in [RFC4271] and [RFC4761].
BGP的此扩展不会改变[RFC4271]和[RFC4761]中固有的基本安全问题。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.
[RFC4271]Rekhter，Y.，Ed.，Li，T.，Ed.，和S.Hares，Ed.，“边境网关协议4（BGP-4）”，RFC 4271，DOI 10.17487/RFC4271，2006年1月<https://www.rfc-editor.org/info/rfc4271>.
[RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, <https://www.rfc-editor.org/info/rfc4761>.
[RFC4761]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“使用BGP进行自动发现和信令的虚拟专用LAN服务（VPLS）”，RFC 4761，DOI 10.17487/RFC4761，2007年1月<https://www.rfc-editor.org/info/rfc4761>.
[RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., Regan, J., and S. Amante, "Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network", RFC 6391, DOI 10.17487/RFC6391, November 2011, <https://www.rfc-editor.org/info/rfc6391>.
[RFC6391]Bryant，S.，Ed.，Filsfils，C.，Drafz，U.，Kompella，V.，Regan，J.，和S.Amante，“MPLS分组交换网络上伪线的流感知传输”，RFC 6391，DOI 10.17487/RFC63911911<https://www.rfc-editor.org/info/rfc6391>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, DOI 10.17487/RFC3985, March 2005, <https://www.rfc-editor.org/info/rfc3985>.
[RFC3985]Bryant，S.，Ed.，和P.Pate，Ed.，“伪线仿真边到边（PWE3）架构”，RFC 3985，DOI 10.17487/RFC3985，2005年3月<https://www.rfc-editor.org/info/rfc3985>.
[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, DOI 10.17487/RFC4385, February 2006, <https://www.rfc-editor.org/info/rfc4385>.
[RFC4385]Bryant，S.，Swallow，G.，Martini，L.，和D.McPherson，“用于MPLS PSN的伪线仿真边到边（PWE3）控制字”，RFC 4385，DOI 10.17487/RFC4385，2006年2月<https://www.rfc-editor.org/info/rfc4385>.
[RFC8077] Martini, L., Ed., and G. Heron, Ed., "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, <https://www.rfc-editor.org/info/rfc8077>.
[RFC8077]Martini，L.，Ed.，和G.Heron，Ed.，“使用标签分发协议（LDP）的伪线设置和维护”，STD 84，RFC 8077，DOI 10.17487/RFC8077，2017年2月<https://www.rfc-editor.org/info/rfc8077>.
[RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal Cost Multipath Treatment in MPLS Networks", BCP 128, RFC 4928, DOI 10.17487/RFC4928, June 2007, <https://www.rfc-editor.org/info/rfc4928>.
[RFC4928]Swallow，G.，Bryant，S.和L.Andersson，“避免MPLS网络中的等成本多路径处理”，BCP 128，RFC 4928，DOI 10.17487/RFC4928，2007年6月<https://www.rfc-editor.org/info/rfc4928>.
[RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012, <https://www.rfc-editor.org/info/rfc6624>.
[RFC6624]Kompella，K.，Kothari，B.，和R.Cherukuri，“使用BGP进行自动发现和信令的第2层虚拟专用网络”，RFC 6624DOI 10.17487/RFC66242012年5月<https://www.rfc-editor.org/info/rfc6624>.
Acknowledgements
致谢
The authors would like to thank Bertrand Duvivier and John Drake for their review and comments.
作者要感谢Bertrand Duvivier和John Drake的评论和评论。
Contributors
贡献者
In addition to the authors listed above, the following individuals also contributed to this document:
除上述作者外，以下个人也对本文件作出了贡献：
Eric Lent
埃里克·伦特
John Brzozowski
约翰·布佐夫斯基
Steven Cotter
史蒂文·科特
Authors' Addresses
作者地址
Keyur Patel Arrcus
颈髌韧带
Email: keyur@arrcus.com
Email: keyur@arrcus.com
Sami Boutros VMware
萨米·布特罗斯
Email: boutros.sami@gmail.com
Email: boutros.sami@gmail.com
Jose Liste Cisco
何塞·李斯特·思科
Email: jliste@cisco.com
Email: jliste@cisco.com
Bin Wen Comcast
文彬康卡斯特
Email: bin_wen@cable.comcast.com
Email: bin_wen@cable.comcast.com
Jorge Rabadan Nokia
豪尔赫·拉巴丹诺基亚
Email: jorge.rabadan@nokia.com
Email: jorge.rabadan@nokia.com