Internet Engineering Task Force (IETF) A. Malis
Request for Comments: 8596 S. Bryant
Category: Informational Futurewei
ISSN: 2070-1721 J. Halpern
Ericsson
W. Henderickx
Nokia
June 2019
Internet Engineering Task Force (IETF) A. Malis
Request for Comments: 8596 S. Bryant
Category: Informational Futurewei
ISSN: 2070-1721 J. Halpern
Ericsson
W. Henderickx
Nokia
June 2019
MPLS Transport Encapsulation for the Service Function Chaining (SFC) Network Service Header (NSH)
服务功能链（SFC）网络服务头（NSH）的MPLS传输封装
Abstract
摘要
This document describes how to use a Service Function Forwarder (SFF) Label (similar to a pseudowire label or VPN label) to indicate the presence of a Service Function Chaining (SFC) Network Service Header (NSH) between an MPLS label stack and the NSH original packet/frame. This allows SFC packets using the NSH to be forwarded between SFFs over an MPLS network. The label is also used to select between multiple SFFs in the destination MPLS node.
本文档描述了如何使用服务功能转发器（SFF）标签（类似于伪线标签或VPN标签）来指示MPLS标签堆栈和NSH原始数据包/帧之间存在服务功能链接（SFC）网络服务头（NSH）。这允许使用NSH的SFC数据包通过MPLS网络在SFF之间转发。标签还用于在目标MPLS节点中的多个SFF之间进行选择。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc8596.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8596.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 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. Terminology ................................................3
2. MPLS Encapsulation Using an SFF Label ...........................3
2.1. MPLS Label Stack Construction at the Sending Node ..........4
2.2. SFF Label Processing at the Destination Node ...............5
3. Equal-Cost Multipath (ECMP) Considerations ......................5
4. Operations, Administration, and Maintenance (OAM)
Considerations ..................................................6
5. IANA Considerations .............................................6
6. Security Considerations .........................................6
7. References ......................................................7
7.1. Normative References .......................................7
7.2. Informative References .....................................8
Acknowledgements ...................................................9
Authors' Addresses .................................................9
1. Introduction ....................................................2
1.1. Terminology ................................................3
2. MPLS Encapsulation Using an SFF Label ...........................3
2.1. MPLS Label Stack Construction at the Sending Node ..........4
2.2. SFF Label Processing at the Destination Node ...............5
3. Equal-Cost Multipath (ECMP) Considerations ......................5
4. Operations, Administration, and Maintenance (OAM)
Considerations ..................................................6
5. IANA Considerations .............................................6
6. Security Considerations .........................................6
7. References ......................................................7
7.1. Normative References .......................................7
7.2. Informative References .....................................8
Acknowledgements ...................................................9
Authors' Addresses .................................................9
As discussed in [RFC8300], a number of transport encapsulations for the Service Function Chaining (SFC) Network Service Header (NSH) already exist, such as Ethernet, UDP, GRE, and others.
如[RFC8300]中所述，服务功能链（SFC）网络服务头（NSH）的许多传输封装已经存在，例如以太网、UDP、GRE和其他。
This document describes an MPLS transport encapsulation for the NSH and how to use a Service Function Forwarder (SFF) [RFC7665] Label to indicate the presence of the NSH in the MPLS packet payload. This allows SFC packets using the NSH to be forwarded between SFFs in an MPLS transport network, where MPLS is used to interconnect the network nodes that contain one or more SFFs. The label is also used to select between multiple SFFs in the destination MPLS node.
本文档描述了NSH的MPLS传输封装，以及如何使用服务功能转发器（SFF）[RFC7665]标签来指示MPLS数据包有效负载中存在NSH。这允许使用NSH的SFC数据包在MPLS传输网络中的SFF之间转发，其中MPLS用于互连包含一个或多个SFF的网络节点。标签还用于在目标MPLS节点中的多个SFF之间进行选择。
From an SFC perspective, this encapsulation is equivalent to other transport encapsulations of packets using the NSH. This can be illustrated by adding an additional line to the example of a next-hop SPI / SI-to-network ("SPI" and "SI" stand for "Service Path Identifier" and "Service Index") overlay network locator mapping in Table 1 of [RFC8300]:
从SFC的角度来看，这种封装相当于使用NSH的包的其他传输封装。这可以通过在[RFC8300]表1中的下一跳SPI/SI到网络（“SPI”和“SI”代表“服务路径标识符”和“服务索引”）覆盖网络定位器映射的示例中添加额外的行来说明：
+------+------+---------------------+-------------------------+
| SPI | SI | Next Hop(s) | Transport Encapsulation |
+------+------+---------------------+-------------------------+
| 25 | 220 | Label 5467 | MPLS |
+------+------+---------------------+-------------------------+
+------+------+---------------------+-------------------------+
| SPI | SI | Next Hop(s) | Transport Encapsulation |
+------+------+---------------------+-------------------------+
| 25 | 220 | Label 5467 | MPLS |
+------+------+---------------------+-------------------------+
Table 1: Extension to Table 1 in RFC 8300
表1:RFC 8300中表1的扩展
SFF Labels are similar to other service labels at the bottom of an MPLS label stack that denote the contents of the MPLS payload being other than a normally routed IP packet, such as a Layer 2 pseudowire, an IP packet that is routed in a VPN context with a private address, or an Ethernet virtual private wire service.
SFF标签类似于MPLS标签堆栈底部的其他服务标签，这些标签表示MPLS有效负载的内容不是正常路由的IP分组，例如第2层伪线、在VPN上下文中路由且具有专用地址的IP分组或以太网虚拟专用线服务。
This informational document follows well-established MPLS procedures and does not require any actions by IANA or any new protocol extensions.
本信息性文档遵循完善的MPLS程序，不需要IANA采取任何行动或任何新的协议扩展。
Note that using the MPLS label stack as a replacement for the SFC NSH, covering use cases that do not require per-packet metadata, is described in [RFC8595].
请注意，[RFC8595]中描述了使用MPLS标签堆栈替代SFC NSH，涵盖不需要每包元数据的用例。
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 encapsulation is a standard MPLS label stack [RFC3032] with an SFF Label at the bottom of the stack, followed by an NSH as defined by [RFC8300] and the NSH original packet/frame.
封装是一个标准MPLS标签堆栈[RFC3032]，在堆栈底部有一个SFF标签，然后是[RFC8300]定义的NSH和NSH原始数据包/帧。
Much like a pseudowire label, an SFF Label MUST be allocated by the downstream receiver of the NSH from its per-platform label space, since the meaning of the label is identical, independent of which incoming interface it is received from [RFC3031].
与伪线标签非常相似，NSH的下游接收器必须从其每个平台标签空间分配SFF标签，因为标签的含义是相同的，独立于从哪个传入接口接收[RFC3031]。
If a receiving node supports more than one SFF (i.e., more than one SFC forwarding instance), then the SFF Label can be used to select the proper SFF, by having the receiving node advertise more than one SFF Label to its upstream sending nodes as appropriate.
如果接收节点支持多个SFF（即，多个SFC转发实例），则SFF标签可用于选择适当的SFF，方法是让接收节点酌情向其上游发送节点通告多个SFF标签。
The method used by the downstream receiving node to advertise SFF Labels to the upstream sending node is out of scope for this document. That said, a number of methods are possible, such as via a protocol exchange, or via a controller that manages both the sender and the receiver using the Network Configuration Protocol (NETCONF) / YANG, BGP, the Path Computation Element Communication Protocol (PCEP), etc. One such BGP-based method has already been defined and is documented in [BGP-NSH-SFC]. This does not constrain the further definition of other such advertisement methods in the future.
下游接收节点用于向上游发送节点播发SFF标签的方法超出了本文档的范围。也就是说，许多方法是可能的，例如通过协议交换，或者通过使用网络配置协议（NETCONF）/YANG、BGP、路径计算元素通信协议（PCEP）等来管理发送方和接收方的控制器。已经定义了一种这样的基于BGP的方法，并在中记录[BGP-NSH-SFC]。这并不限制将来对其他此类广告方法的进一步定义。
While the SFF Label will usually be at the bottom of the label stack, there may be cases where there are additional label stack entries beneath it. For example, when an Associated Channel Header (ACH) is carried that applies to the SFF, a Generic Associated Channel Label (GAL) [RFC5586] will be in the label stack below the SFF. Similarly, an Entropy Label Indicator / Entropy Label (ELI/EL) [RFC6790] may be carried below the SFF in the label stack. This is identical to the situation with VPN labels.
虽然SFF标签通常位于标签堆栈的底部，但在某些情况下，它下面可能有其他标签堆栈条目。例如，当携带适用于SFF的关联信道报头（ACH）时，通用关联信道标签（GAL）[RFC5586]将位于SFF下方的标签堆栈中。类似地，熵标签指示符/熵标签（ELI/EL）[RFC6790]可携带在标签堆栈中的SFF的下方。这与VPN标签的情况相同。
This document does not define the setting of the Traffic Class (TC) field [RFC5462] (formerly known as the Experimental Use (EXP) bits [RFC3032]) in the SFF Label.
本文件未定义SFF标签中流量类别（TC）字段[RFC5462]（以前称为实验使用（EXP）位[RFC3032]）的设置。
When one SFF wishes to send an SFC packet with an NSH to another SFF over an MPLS transport network, a label stack needs to be constructed by the MPLS node that contains the sending SFF in order to transport the packet to the destination MPLS node that contains the receiving SFF. The label stack is constructed as follows:
当一个SFF希望通过MPLS传输网络向另一个SFF发送带有NSH的SFC数据包时，需要由包含发送SFF的MPLS节点构造标签堆栈，以便将数据包传输到包含接收SFF的目标MPLS节点。标签堆栈的构造如下所示：
1. Push zero or more labels that are interpreted by the destination MPLS node on to the packet, such as the GAL [RFC5586] (see Section 4). The TTL for these labels is set according to the relevant standards that define these labels.
1. 将目标MPLS节点解释的零个或多个标签推送到数据包上，例如GAL[RFC5586]（参见第4节）。这些标签的TTL是根据定义这些标签的相关标准设置的。
2. Push the SFF Label to identify the desired SFF in the receiving MPLS node. The TTL for this MPLS label MUST be set to 1 to avoid mis-forwarding.
2. 推送SFF标签以标识接收MPLS节点中所需的SFF。此MPLS标签的TTL必须设置为1，以避免错误转发。
3. Push zero or more additional labels such that (a) the resulting label stack will cause the packet to be transported to the destination MPLS node, and (b) when the packet arrives at the destination node, either:
3. 推送零个或多个附加标签，以便（a）产生的标签堆栈将导致数据包传输到目标MPLS节点，以及（b）当数据包到达目标节点时，或者：
* the SFF Label will be at the top of the label stack (this is typically the case when penultimate hop popping is used at the penultimate node), or
* SFF标签将位于标签堆栈的顶部（这通常是在倒数第二个节点使用倒数第二跳弹出时的情况），或者
* as a part of normal MPLS processing, the SFF Label becomes the top label in the stack before the packet is forwarded to another node and before the packet is dispatched to a higher layer.
* 作为正常MPLS处理的一部分，SFF标签在包被转发到另一个节点之前以及在包被调度到更高层之前成为堆栈中的顶部标签。
The TTL for these labels is set by configuration or set to the defaults for normal MPLS operation in the network.
这些标签的TTL由配置设置，或设置为网络中正常MPLS操作的默认值。
The destination MPLS node performs a lookup on the SFF Label to retrieve the next-hop context between the SFF and SF, e.g., to retrieve the destination Media Access Control (MAC) address in the case where native Ethernet encapsulation is used between the SFF and SF. How the next-hop context is populated is out of scope for this document.
目标MPLS节点在SFF标签上执行查找以检索SFF和SF之间的下一跳上下文，例如，在SFF和SF之间使用本机以太网封装的情况下检索目标媒体访问控制（MAC）地址。如何填充下一跳上下文超出了本文档的范围。
The receiving SFF SHOULD check that the received SFF Label has a TTL of 1 upon receipt. Any other values indicate a likely error condition and SHOULD result in discarding the packet.
接收SFF时，应检查接收到的SFF标签的TTL是否为1。任何其他值指示可能的错误情况，并应导致丢弃数据包。
The receiving MPLS node then pops the SFF Label (and any labels beneath it) so that the destination SFF receives the SFC packet with the NSH at the top of the packet.
然后，接收MPLS节点弹出SFF标签（及其下的任何标签），以便目标SFF接收SFC数据包，NSH位于数据包顶部。
As discussed in [RFC4928] and [RFC7325], there are ECMP considerations for payloads carried by MPLS.
如[RFC4928]和[RFC7325]中所述，MPLS承载的有效载荷有ECMP考虑因素。
Many existing routers use deep packet inspection to examine the payload of an MPLS packet. If the first nibble of the payload is equal to 0x4 or 0x6, these routers (sometimes incorrectly, as discussed in [RFC4928]) assume that the payload is IPv4 or IPv6, respectively and, as a result, perform ECMP load balancing based on (presumed) information present in IP/TCP/UDP payload headers or in a combination of MPLS label stack and (presumed) IP/TCP/UDP payload headers in the packet.
许多现有路由器使用深度包检查来检查MPLS包的有效负载。如果有效载荷的第一个半字节等于0x4或0x6，则这些路由器（有时不正确，如[RFC4928]中所述）分别假定有效载荷为IPv4或IPv6，因此，基于IP/TCP/UDP有效载荷头中存在的（假定）信息或MPLS标签堆栈和（假定）的组合执行ECMP负载平衡数据包中的IP/TCP/UDP有效负载头。
For SFC, ECMP may or may not be desirable. To prevent ECMP when it is not desired, the NSH Base Header was carefully constructed so that the NSH could not look like IPv4 or IPv6 based on its first nibble. See Section 2.2 of [RFC8300] for further details. Accordingly, the default behavior for MPLS-encapsulated SFC is to not use ECMP other than by using entropy derived from the MPLS label stack. This results in all packets going to the same SF taking the same path regardless of the use of ECMP in the network.
For SFC, ECMP may or may not be desirable. To prevent ECMP when it is not desired, the NSH Base Header was carefully constructed so that the NSH could not look like IPv4 or IPv6 based on its first nibble. See Section 2.2 of [RFC8300] for further details. Accordingly, the default behavior for MPLS-encapsulated SFC is to not use ECMP other than by using entropy derived from the MPLS label stack. This results in all packets going to the same SF taking the same path regardless of the use of ECMP in the network.translate error, please retry
If ECMP is desired when SFC is used with an MPLS transport network, there are two possible options: entropy labels [RFC6790] and flow-aware transport [RFC6391] labels. A recommendation regarding choosing between these options, and their proper placement in the label stack, is left for future study.
如果SFC与MPLS传输网络一起使用时需要ECMP，则有两种可能的选项：熵标签[RFC6790]和流感知传输[RFC6391]标签。关于在这些选项之间进行选择以及它们在标签堆栈中的正确位置的建议留待将来研究。
OAM at the SFC layer is handled by SFC-defined mechanisms [RFC8300]. However, OAM may be required at the MPLS transport layer. If so, then standard MPLS-layer OAM mechanisms such as the GAL [RFC5586] may be used at the transport label layer.
SFC层的OAM由SFC定义的机制处理[RFC8300]。然而，在MPLS传输层可能需要OAM。如果是，则可以在传输标签层使用诸如GAL[RFC5586]的标准MPLS层OAM机制。
This document has no IANA actions.
本文档没有IANA操作。
This document describes a method for transporting SFC packets using the NSH over an MPLS transport network. It follows well-established MPLS procedures in widespread operational use. It does not define any new protocol elements or allocate any new code points, and it is no more or less secure than carrying any other protocol over MPLS. To the MPLS network, the NSH and its contents are simply an opaque payload.
本文档描述了使用NSH在MPLS传输网络上传输SFC数据包的方法。它遵循广泛使用的成熟MPLS程序。它不定义任何新的协议元素或分配任何新的代码点，并且它与通过MPLS承载任何其他协议一样安全。对于MPLS网络，NSH及其内容只是一个不透明的有效载荷。
In addition, the security considerations in [RFC8595] also apply to this document.
此外，[RFC8595]中的安全注意事项也适用于本文件。
[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>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 3031，DOI 10.17487/RFC3031，2001年1月<https://www.rfc-editor.org/info/rfc3031>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, <https://www.rfc-editor.org/info/rfc3032>.
[RFC3032]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.，和A.Conta，“MPLS标签堆栈编码”，RFC 3032，DOI 10.17487/RFC3032，2001年1月<https://www.rfc-editor.org/info/rfc3032>.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 2009, <https://www.rfc-editor.org/info/rfc5462>.
[RFC5462]Andersson，L.和R.Asati，“多协议标签交换（MPLS）标签堆栈条目：“EXP”字段重命名为“流量类”字段”，RFC 5462，DOI 10.17487/RFC5462，2009年2月<https://www.rfc-editor.org/info/rfc5462>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, <https://www.rfc-editor.org/info/rfc7665>.
[RFC7665]Halpern，J.，Ed.和C.Pignataro，Ed.，“服务功能链（SFC）架构”，RFC 7665，DOI 10.17487/RFC7665，2015年10月<https://www.rfc-editor.org/info/rfc7665>.
[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>.
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, January 2018, <https://www.rfc-editor.org/info/rfc8300>.
[RFC8300]Quinn，P.，Ed.，Elzur，U.，Ed.，和C.Pignataro，Ed.，“网络服务头（NSH）”，RFC 8300，DOI 10.17487/RFC8300，2018年1月<https://www.rfc-editor.org/info/rfc8300>.
[RFC8595] Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based Forwarding Plane for Service Function Chaining", RFC 8595, DOI 10.17487/RFC8595, June 2019, <https://www.rfc-editor.org/info/rfc8595>.
[RFC8595]Farrel，A.，Bryant，S.，和J.Drake，“基于MPLS的服务功能链转发平面”，RFC 8595，DOI 10.17487/RFC8595，2019年6月<https://www.rfc-editor.org/info/rfc8595>.
[BGP-NSH-SFC] Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. Jalil, "BGP Control Plane for NSH SFC", Work in Progress, draft-ietf-bess-nsh-bgp-control-plane-11, May 2019.
[BGP-NSH-SFC]Farrel，A.，Drake，J.，Rosen，E.，Uttaro，J.，和L.Jalil，“NSH-SFC的BGP控制平面”，在建工程，草案-ietf-bess-NSH-BGP-Control-Plane-11，2019年5月。
[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>.
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, DOI 10.17487/RFC5586, June 2009, <https://www.rfc-editor.org/info/rfc5586>.
[RFC5586]Bocci，M.，Ed.，Vigoureux，M.，Ed.，和S.Bryant，Ed.，“MPLS通用关联信道”，RFC 5586，DOI 10.17487/RFC55862009年6月<https://www.rfc-editor.org/info/rfc5586>.
[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>.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, DOI 10.17487/RFC6790, November 2012, <https://www.rfc-editor.org/info/rfc6790>.
[RFC6790]Kompella，K.，Drake，J.，Amante，S.，Henderickx，W.，和L.Yong，“MPLS转发中熵标签的使用”，RFC 6790，DOI 10.17487/RFC6790，2012年11月<https://www.rfc-editor.org/info/rfc6790>.
[RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A., and C. Pignataro, "MPLS Forwarding Compliance and Performance Requirements", RFC 7325, DOI 10.17487/RFC7325, August 2014, <https://www.rfc-editor.org/info/rfc7325>.
[RFC7325]Villamizar，C.，Ed.，Kompella，K.，Amante，S.，Malis，A.，和C.Pignataro，“MPLS转发合规性和性能要求”，RFC 7325，DOI 10.17487/RFC73252014年8月<https://www.rfc-editor.org/info/rfc7325>.
Acknowledgements
致谢
The authors would like to thank Jim Guichard, Eric Rosen, Med Boucadair, Alexander (Sasha) Vainshtein, Jeff Tantsura, Anoop Ghanwani, John Drake, Loa Andersson, Carlos Pignataro, Christian Hopps, and Benjamin Kaduk for their reviews and comments.
作者要感谢Jim Guichard、Eric Rosen、Med Boucadair、Alexander（Sasha）Vainstein、Jeff Tantsura、Anoop Ghanwani、John Drake、Loa Andersson、Carlos Pignataro、Christian Hopps和Benjamin Kaduk的评论和评论。
Authors' Addresses
作者地址
Andrew G. Malis Futurewei
安德鲁·G·马里的未来
Email: agmalis@gmail.com
Email: agmalis@gmail.com
Stewart Bryant Futurewei
斯图尔特·布莱恩特的未来
Email: stewart.bryant@gmail.com
Email: stewart.bryant@gmail.com
Joel M. Halpern Ericsson
乔尔·M·哈珀·爱立信
Email: joel.halpern@ericsson.com
Email: joel.halpern@ericsson.com
Wim Henderickx Nokia
Wim Henderickx诺基亚
Email: wim.henderickx@nokia.com
Email: wim.henderickx@nokia.com