Internet Engineering Task Force (IETF) C. Villamizar
Request for Comments: 7190 Outer Cape Cod Network Consulting
Category: Informational March 2014
ISSN: 2070-1721
Internet Engineering Task Force (IETF) C. Villamizar
Request for Comments: 7190 Outer Cape Cod Network Consulting
Category: Informational March 2014
ISSN: 2070-1721
Use of Multipath with MPLS and MPLS Transport Profile (MPLS-TP)
在MPLS和MPLS传输配置文件（MPLS-TP）中使用多路径
Abstract
摘要
Many MPLS implementations have supported multipath techniques, and many MPLS deployments have used multipath techniques, particularly in very high-bandwidth applications, such as provider IP/MPLS core networks. MPLS Transport Profile (MPLS-TP) has strongly discouraged the use of multipath techniques. Some degradation of MPLS-TP Operations, Administration, and Maintenance (OAM) performance cannot be avoided when operating over many types of multipath implementations.
许多MPLS实现都支持多路径技术，许多MPLS部署都使用了多路径技术，特别是在非常高带宽的应用中，如提供商IP/MPLS核心网络。MPLS传输配置文件（MPLS-TP）强烈反对使用多路径技术。在多种类型的多路径实现上运行时，无法避免MPLS-TP操作、管理和维护（OAM）性能的某些降级。
Using MPLS Entropy Labels (RFC 6790), MPLS Label Switched Paths (LSPs) can be carried over multipath links while also providing a fully MPLS-TP-compliant server layer for MPLS-TP LSPs. This document describes the means of supporting MPLS as a server layer for MPLS-TP. The use of MPLS-TP LSPs as a server layer for MPLS LSPs is also discussed.
使用MPLS熵标签（RFC 6790），MPLS标签交换路径（LSP）可以通过多路径链路传输，同时还为MPLS-TP LSP提供完全符合MPLS TP的服务器层。本文档描述了支持MPLS作为MPLS-TP服务器层的方法。还讨论了使用MPLS-TP LSP作为MPLS LSP的服务器层。
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 a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc7190.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7190.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. MPLS as a Server Layer for MPLS-TP . . . . . . . . . . . . . 5
3.1. MPLS-TP Forwarding and Server-Layer Requirements . . . . 5
3.2. Methods of Supporting MPLS-TP Client LSPs over MPLS . . . 7
4. MPLS-TP as a Server Layer for MPLS . . . . . . . . . . . . . 11
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 13
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. MPLS as a Server Layer for MPLS-TP . . . . . . . . . . . . . 5
3.1. MPLS-TP Forwarding and Server-Layer Requirements . . . . 5
3.2. Methods of Supporting MPLS-TP Client LSPs over MPLS . . . 7
4. MPLS-TP as a Server Layer for MPLS . . . . . . . . . . . . . 11
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 13
Today the requirement to handle large aggregations of traffic can be met by a number of techniques that we will collectively call "multipath". Multipath applied to parallel links between the same set of nodes includes Ethernet Link Aggregation [IEEE-802.1AX], link bundling [RFC4201], or other aggregation techniques, some of which could be vendor specific. Multipath applied to diverse paths rather than parallel links includes Equal-Cost Multipath (ECMP) as applied to OSPF, IS-IS, or BGP, and equal-cost Label Switched Paths (LSPs). Some vendors support load splitting across equal-cost MPLS LSPs where the load is split proportionally to the reserved bandwidth of the set of LSPs.
今天，处理大量流量聚合的需求可以通过我们统称为“多路径”的许多技术来满足。应用于同一组节点之间并行链路的多路径包括以太网链路聚合[IEEE-802.1AX]、链路捆绑[RFC4201]或其他聚合技术，其中一些技术可能是特定于供应商的。应用于不同路径而非并行链路的多路径包括应用于OSPF、IS-IS或BGP的等成本多路径（ECMP）和等成本标签交换路径（LSP）。一些供应商支持在成本相等的MPLS LSP之间进行负载拆分，其中负载按照LSP组的保留带宽成比例进行拆分。
RFC 5654 requirement 33 requires the capability to carry a client MPLS Transport Profile (MPLS-TP) or MPLS layer over a server MPLS-TP or MPLS layer [RFC5654]. This is possible in all cases with one exception. When an MPLS LSP exceeds the capacity of any single
RFC 5654要求33要求能够在服务器MPLS-TP或MPLS层上承载客户端MPLS传输配置文件（MPLS-TP）或MPLS层[RFC5654]。这在所有情况下都是可能的，只有一个例外。当MPLS LSP超过任何单个
component link, it MAY be carried by a network using multipath techniques, but it SHOULD NOT be carried by a single MPLS-TP LSP due to the inherent MPLS-TP capacity limitation imposed by MPLS-TP Operations, Administration, and Maintenance (OAM) fate-sharing constraints and MPLS-TP Loss Measurement OAM packet-ordering constraints (see Section 3.1). Instead, multiple MPLS-TP LSPs SHOULD be used to carry a large MPLS LSP (see Section 4).
组件链路，它可以由使用多路径技术的网络承载，但不应由单个MPLS-TP LSP承载，因为MPLS-TP操作、管理和维护（OAM）命运共享约束和MPLS-TP损耗测量OAM数据包顺序约束施加了固有的MPLS-TP容量限制（见第3.1节）. 相反，应使用多个MPLS-TP LSP来承载大型MPLS LSP（参见第4节）。
The term "composite link" is more general than terms such as "link aggregation" (which is specific to Ethernet) or "ECMP" (which implies equal-cost paths within a routing protocol). The use of the term "composite link" here is consistent with the broad definition in [ITU-T.G.800]. Multipath is very similar to composite link as defined by ITU-T but specifically excludes inverse multiplexing.
术语“复合链路”比诸如“链路聚合”（特定于以太网）或“ECMP”（意味着路由协议内的等成本路径）等术语更为通用。此处使用的术语“复合链路”与[ITU-T.G.800]中的广义定义一致。多径与ITU-T定义的复合链路非常相似，但具体排除了反向多路复用。
MPLS LSPs today are able to function as a server layer and carry client MPLS LSPs. When control-plane signaling is used, forwarding adjacency (FA) advertisements are used to inform the set of Label Switching Routers (LSRs) of Packet Switching Capable (PSC) LSPs within the MPLS topology [RFC4206]. Client MPLS LSP at a higher layer (lower PSC number) may signal their intention to use PSC LSPs as hops in the RSVP-TE Explicit Route Object (ERO). LSRs with no explicit support for RFC 4206 see the PSC LSPs as ordinary links and therefore use them.
如今，MPLS LSP能够作为服务器层运行，并承载客户端MPLS LSP。当使用控制平面信令时，转发邻接（FA）广告用于通知标签交换路由器（lsr）组MPLS拓扑内具有分组交换能力（PSC）的lsp[RFC4206]。较高层（较低PSC编号）的客户机MPLS LSP可表示其打算将PSC LSP用作RSVP-TE显式路由对象（ERO）中的跳。不明确支持RFC 4206的LSR将PSC LSP视为普通链接，因此使用它们。
An MPLS LSP that has been set up using RSVP-TE appears to its ingress LSR as a viable IP next hop to a distant LSR. If LDP is used and bidirectional RSVP-TE LSP connectivity is available, then LDP signaling can be set up among the RSVP-TE LSP endpoints, and LDP can make use of the RSVP-TE LSP as an LDP hop. This is another form of existing MPLS-in-MPLS use. MPLS LSPs may also make use of hierarchy that is configured through the management plane rather than signaled using RSVP-TE.
使用RSVP-TE建立的MPLS LSP在其入口LSR看来是远程LSR的可行IP下一跳。如果使用LDP并且双向RSVP-TE LSP连接可用，则可以在RSVP-TE LSP端点之间建立LDP信令，并且LDP可以将RSVP-TE LSP用作LDP跳。这是MPLS使用中现有MPLS的另一种形式。MPLS LSP还可以利用通过管理平面配置的层次结构，而不是使用RSVP-TE发送信号。
These existing forms of MPLS-in-MPLS may traverse multipath hops such as Ethernet Link Aggregation Group (LAG) [IEEE-802.1AX] or MPLS Link Bundling [RFC4201]. MPLS-TP brings with it a new set of requirements not considered in past deployments of the various forms of MPLS-in-MPLS where multipath was in use. This document merely discusses use of existing forwarding and protocol mechanisms that can support the case where either the client-layer LSPs or the server-layer LSPs are MPLS-TP and where multipath is used.
MPLS中的这些现有形式的MPLS可以穿越多路径跳，例如以太网链路聚合组（LAG）[IEEE-802.1AX]或MPLS链路捆绑[RFC4201]。MPLS-TP带来了一组新的需求，在使用多路径的MPLS中，过去部署各种形式的MPLS时没有考虑到这些需求。本文档仅讨论现有转发和协议机制的使用，这些机制可支持客户机层LSP或服务器层LSP为MPLS-TP且使用多路径的情况。
Please refer to the terminology related to multipath introduced in [ADV-MULTIPATH-REQ]. The following additional terms are used in this document; related terms are grouped together.
请参考[ADV-multipath-REQ]中介绍的与多路径相关的术语。本文件中使用了以下附加术语：；相关术语被分组在一起。
Link Bundle Link bundling is a multipath technique specific to MPLS [RFC4201]. Link bundling supports two modes of operations. Either an LSP can be placed on one component link of a link bundle, or an LSP can be load-split across all members of the bundle. There is no signaling defined that allows a per-LSP preference regarding load split, therefore whether to load split is generally configured per bundle and applied to all LSPs across the bundle.
链路捆绑链路捆绑是MPLS特有的多路径技术[RFC4201]。链接绑定支持两种操作模式。LSP可以放置在链接束的一个组件链接上，或者LSP可以跨该束的所有成员进行负载拆分。没有定义允许关于负载拆分的每个LSP首选项的信令，因此是否进行负载拆分通常是针对每个捆绑包配置的，并应用于整个捆绑包中的所有LSP。
All-Ones Component Within the context of link bundling, [RFC4201] defines a special case where the same label is to be valid across all component links. This case is indicated in signaling by a bit value of "all ones" when identifying a component link. Following the publication of RFC 4201, for brevity this special case has been referred to as the "all-ones component".
链接绑定上下文中的所有组件，[RFC4201]定义了一种特殊情况，其中相同的标签在所有组件链接中都有效。这种情况在信令中由标识组件链路时的“所有”位值指示。在RFC 4201出版后，为了简洁起见，这种特殊情况被称为“全一组件”。
Equal-Cost Multipath (ECMP) Equal-Cost Multipath (ECMP) is a specific form of multipath in which the costs of the links or paths must be equal in a given routing protocol. The load may be split equally across all available links (or available paths), or the load may be split proportionally to the capacity of each link (or path).
等成本多路径（ECMP）等成本多路径（ECMP）是一种特定形式的多路径，在给定的路由协议中，链路或路径的成本必须相等。负载可以在所有可用链路（或可用路径）上平均分配，也可以根据每个链路（或路径）的容量按比例分配。
Loop-Free Alternate Paths (LFA) "Loop-free alternate paths" (LFA) are defined in Section 5.2 of RFC 5714 [RFC5714] as follows: "Such a path exists when a direct neighbor of the router adjacent to the failure has a path to the destination that can be guaranteed not to traverse the failure." Further detail can be found in [RFC5286]. LFA as defined for IP Fast Reroute (IPFRR) can be used to load balance by relaxing the equal-cost criteria of ECMP, though IPFRR defined LFA for use in selecting protection paths. When used with IP, proportional split is generally not used. LFA use in load balancing is implemented by some vendors, though it may be rare or non-existent in deployments.
无环路备用路径（LFA）“无环路备用路径”（LFA）在RFC 5714[RFC5714]的第5.2节中定义如下：“当与故障相邻的路由器的直接邻居有一条到目的地的路径，可以保证不会穿越故障时，这种路径就存在了。”更多详情见[RFC5286]。为IP快速重路由（IPFRR）定义的LFA可以通过放松ECMP的等成本标准来实现负载平衡，尽管IPFRR定义LFA用于选择保护路径。与IP一起使用时，通常不使用比例拆分。LFA在负载平衡中的使用是由一些供应商实现的，尽管它在部署中可能很少或不存在。
Link Aggregation The term "link aggregation" generally refers to Ethernet Link Aggregation as defined by [IEEE-802.1AX]. Ethernet Link Aggregation defines a Link Aggregation Control Protocol (LACP) which coordinates inclusion of Link Aggregation Group (LAG) members in the LAG.
链路聚合术语“链路聚合”通常指[IEEE-802.1AX]定义的以太网链路聚合。以太网链路聚合定义了链路聚合控制协议（LACP），该协议协调链路聚合组（LAG）成员在LAG中的包含。
Link Aggregation Group (LAG) A group of physical Ethernet interfaces that are treated as a logical link when using Ethernet Link Aggregation is referred to as a Link Aggregation Group (LAG).
链路聚合组（LAG）使用以太网链路聚合时被视为逻辑链路的一组物理以太网接口称为链路聚合组（LAG）。
LAG Member Ethernet Link Aggregation as defined in [IEEE-802.1AX] refers to an individual link in a LAG as a LAG member. A LAG member is a component link. An Ethernet LAG is a composite link. IEEE does not use the terms "composite link" or "component link".
[IEEE-802.1AX]中定义的滞后成员以太网链路聚合将滞后中的单个链路称为滞后成员。滞后成员是一个组件链接。以太网延迟是一种复合链路。IEEE不使用术语“复合链路”或“组件链路”。
A small set of requirements are discussed. These requirements make use of keywords such as MUST and SHOULD as described in [RFC2119].
讨论了一小部分需求。这些要求使用[RFC2119]中所述的关键词，如必须和应该。
An MPLS LSP may be used as a server layer for MPLS-TP LSPs as long as all MPLS-TP requirements are met. Section 3.1 reviews the basis for requirements of a server layer that supports MPLS-TP as a client layer. Key requirements include OAM "fate-sharing" and that packets within an MPLS-TP LSP (including both payload and OAM packets) not be reordered. Section 3.2 discusses implied requirements where MPLS is the server layer for MPLS-TP client LSPs and describes a set of solutions that use existing MPLS mechanisms.
只要满足所有MPLS-TP要求，MPLS LSP可以用作MPLS-TP LSP的服务器层。第3.1节回顾了支持MPLS-TP作为客户端层的服务器层需求的基础。关键要求包括OAM“命运共享”和MPLS-TP LSP内的数据包（包括有效负载和OAM数据包）不被重新排序。第3.2节讨论了MPLS是MPLS-TP客户端LSP的服务器层的隐含要求，并描述了一组使用现有MPLS机制的解决方案。
[RFC5960] defines the data-plane requirements for MPLS-TP. Two very relevant paragraphs in Section 3.1.1 ("LSP Packet Encapsulation and Forwarding") are the following:
[RFC5960]定义了MPLS-TP的数据平面要求。第3.1.1节（“LSP数据包封装和转发”）中两个非常相关的段落如下：
RFC 5960, Section 3.1.1, Paragraph 3 Except for transient packet reordering that may occur, for example, during fault conditions, packets are delivered in order on L-LSPs, and on E-LSPs within a specific ordered aggregate.
RFC 5960，第3.1.1节，第3段，除了可能发生的瞬态数据包重新排序，例如，在故障条件下，数据包在L-LSP和E-LSP上按顺序在特定的有序聚合内交付。
RFC 5960, Section 3.1.1, Paragraph 6 Equal-Cost Multi-Path (ECMP) load-balancing MUST NOT be performed on an MPLS-TP LSP. MPLS-TP LSPs as defined in this document MAY operate over a server layer that supports load-balancing, but this load-balancing MUST operate in such a manner that it is transparent to MPLS-TP. This does not preclude the future definition of new MPLS-TP LSP types that have different requirements regarding the use of ECMP in the server layer.
RFC 5960第3.1.1节第6段等成本多路径（ECMP）负载平衡不得在MPLS-TP LSP上执行。本文档中定义的MPLS-TP LSP可以在支持负载平衡的服务器层上运行，但这种负载平衡必须以对MPLS-TP透明的方式运行。这并不排除将来定义新的MPLS-TP LSP类型，这些类型在服务器层使用ECMP方面有不同的要求。
[RFC5960], Section 3.1.1, Paragraph 3 requires that packets within a specific ordered aggregate be delivered in order. This same requirement is already specified by Differentiated Services [RFC2475]. [RFC5960], Section 3.1.1, Paragraph 6 explicitly allows a server layer to use ECMP, provided that it is transparent to the MPLS-TP client layer.
[RFC5960]第3.1.1节第3段要求按照顺序交付特定有序聚合中的数据包。区分服务[RFC2475]已经规定了同样的要求。[RFC5960]，第3.1.1节第6段明确允许服务器层使用ECMP，前提是它对MPLS-TP客户端层是透明的。
[RFC6371] adds a requirement for data traffic and OAM traffic "fate-sharing". The following paragraph in Section 1 ("Introduction") summarizes this requirement.
[RFC6371]增加了数据流量和OAM流量“命运共享”的要求。第1节（“引言”）中的以下段落总结了该要求。
RFC 6371, Section 1, Paragraph 7 OAM packets that instrument a particular direction of a transport path are subject to the same forwarding treatment (i.e., fate-share) as the user data packets and in some cases, where Explicitly TC-encoded-PSC LSPs (E-LSPs) are employed, may be required to have common per-hop behavior (PHB) Scheduling Class (PSC) End-to-End (E2E) with the class of traffic monitored. In case of Label-Only-Inferred-PSC LSP (L-LSP), only one class of traffic needs to be monitored, and therefore the OAM packets have common PSC with the monitored traffic class.
指示传输路径的特定方向的RFC 6371第1节第7段OAM分组受到与用户数据分组相同的转发处理（即命运共享），并且在某些情况下，在使用显式TC编码的PSC LSP（e-LSP）的情况下，可能需要具有公共每跳行为（PHB）调度类（PSC）端到端（E2E），监控流量等级。在仅标签推断的PSC LSP（L-LSP）的情况下，只需要监控一类流量，因此OAM数据包具有与监控的流量类别相同的PSC。
[RFC6371] does not prohibit multilink techniques in Section 4.6 ("Fate-Sharing Considerations for Multilink"), where multilink is defined as Ethernet Link Aggregation and the use of Link Bundling for MPLS, but it does declare that such a network would be only partially MPLS-TP compliant. The characteristic that is to be avoided is contained in the following sentence in that section.
[RFC6371]并未禁止第4.6节（“多链路的命运共享注意事项”）中的多链路技术，其中多链路被定义为以太网链路聚合和MPLS链路捆绑的使用，但它声明此类网络仅部分符合MPLS-TP。应避免的特征包含在该节的以下句子中。
RFC 6371, Section 4.6, Paragraph 1, last sentence These techniques frequently share the characteristic that an LSP may be spread over a set of component links and therefore be reordered, but no flow within the LSP is reordered (except when very infrequent and minimally disruptive load rebalancing occurs).
RFC 6371，第4.6节，第1段，最后一句这些技术通常具有这样的特点：LSP可以分布在一组组件链路上，因此可以重新排序，但LSP内的流不会重新排序（除非发生极不频繁且破坏性最小的负载再平衡）。
A declaration that implies that Link Bundling for MPLS yields a partially MPLS-TP-compliant network is perhaps overstated since only the Link Bundling all-ones component link has this characteristic.
暗示MPLS链路捆绑产生部分MPLS TP兼容网络的声明可能言过其实，因为只有绑定所有组件链路的链路才具有此特性。
[RFC6374] defines a direct Loss Measurement (LM) where LM OAM packets cannot be reordered with respect to payload packets. This will require that payload packets themselves not be reordered. The following paragraph in Section 2.9.4 ("Equal Cost Multipath") gives the reason for this restriction.
[RFC6374]定义了直接损失测量（LM），其中LM OAM数据包不能相对于有效负载数据包重新排序。这将要求负载数据包本身不被重新排序。第2.9.4节（“等成本多路径”）中的以下段落给出了该限制的原因。
RFC 6374, Section 2.9.4, Paragraph 2 The effects of ECMP on loss measurement will depend on the LM mode. In the case of direct LM, the measurement will account for any packets lost between the sender and the receiver, regardless of how many paths exist between them. However, the presence of ECMP increases the likelihood of misordering both of LM messages relative to data packets and of the LM messages themselves. Such misorderings tend to create unmeasurable intervals and thus degrade the accuracy of loss measurement. The effects of ECMP are similar for inferred LM, with the additional caveat that, unless the test packets are specially constructed so as to probe all available paths, the loss characteristics of one or more of the alternate paths cannot be accounted for.
RFC 6374第2.9.4节第2段ECMP对损耗测量的影响将取决于LM模式。在直接LM的情况下，测量将考虑发送方和接收方之间丢失的任何数据包，而不管它们之间存在多少条路径。然而，ECMP的存在增加了LM消息相对于数据分组和LM消息本身的错误排序的可能性。这种错误排序往往会造成无法测量的间隔，从而降低损耗测量的准确性。ECMP对推断的LM的影响类似，但另外需要注意的是，除非测试数据包经过特殊构造以探测所有可用路径，否则无法解释一条或多条备用路径的丢失特性。
Supporting MPLS-TP LSPs over a fully MPLS-TP conformant MPLS LSP server layer where the MPLS LSPs are making use of multipath requires special treatment of the MPLS-TP LSPs such that those LSPs meet MPLS-TP forwarding requirements (see Section 3.1). This implies the following brief set of requirements.
在MPLS LSP使用多路径的完全符合MPLS-TP的MPLS LSP服务器层上支持MPLS-TP LSP需要对MPLS-TP LSP进行特殊处理，以使这些LSP满足MPLS-TP转发要求（参见第3.1节）。这意味着以下一组简短的需求。
MP#1 It MUST be possible for a midpoint MPLS-TP Label Switching Router (LSR) that is serving as ingress to a server-layer MPLS LSP to identify MPLS-TP LSPs, so that MPLS-TP forwarding requirements can be applied, or to otherwise accommodate the MPLS-TP forwarding requirements.
MP#1作为服务器层MPLS LSP入口的中点MPLS-TP标签交换路由器（LSR）必须能够识别MPLS-TP LSP，以便可以应用MPLS-TP转发要求，或者以其他方式适应MPLS-TP转发要求。
MP#2 The ability to completely exclude MPLS-TP LSPs from the multipath hash and load split SHOULD be supported. If the selected component link no longer meets requirements, an LSP is considered down, which may trigger protection and/or may require that the ingress LSR select a new path and signal a new LSP.
MP#2应支持从多路径散列和负载拆分中完全排除MPLS-TP LSP的能力。如果所选组件链路不再满足要求，则认为LSP已关闭，这可能触发保护和/或可能要求入口LSR选择新路径并发出新LSP信号。
MP#3 It SHOULD be possible to ensure that MPLS-TP LSPs will not be moved to another component link as a result of a load-rebalancing operation for multipath. If the selected component link no longer meets requirements, another component link may be selected; however, a change in path SHOULD NOT occur solely for load balancing.
MP#3应能够确保MPLS-TP LSP不会由于多路径负载重新平衡操作而移动到另一个组件链路。如果所选组件链接不再满足要求，则可以选择另一个组件链接；但是，路径的更改不应仅用于负载平衡。
MP#4 Where a Resource Reservation Protocol - Traffic Engineering (RSVP-TE) control plane is used, it MUST be possible for an ingress LSR that is setting up an MPLS-TP or an MPLS LSP to determine at path selection time whether a link or Forwarding Adjacency (FA; see [RFC4206]) within the topology can support the MPLS-TP requirements of the LSP.
MP#4在使用资源预留协议-流量工程（RSVP-TE）控制平面的情况下，设置MPLS-TP或MPLS LSP的入口LSR必须能够在路径选择时确定拓扑内的链路或转发邻接（FA；参见[RFC4206]）是否能够支持LSP的MPLS-TP要求。
The reason for requirement MP#1 may not be obvious. An MPLS-TP LSP may be aggregated along with other client LSPs by a midpoint LSR into a very large MPLS server-layer LSP, as would be the case in a core-node-to-core-node MPLS LSP between major cities. In this case, the ingress of the MPLS LSP, being a midpoint LSR for a set of client LSPs, has no signaling mechanism that can be used to determine whether one of its specific client LSPs is using MPLS or MPLS-TP. Multipath load splitting can be avoided for MPLS-TP LSPs if at the MPLS server-layer LSP ingress LSR an Entropy Label Indicator (ELI) and Entropy Label (EL) are added to the label stack by the midpoint LSR for the client MPLS-TP LSP, at the ingress of the MPLS LSP [RFC6790]. For those client LSPs that are MPLS-TP LSPs, a single per-LSP EL value must be chosen. For those client LSPs that are MPLS LSPs, per-packet entropy below the top label must, for practical reasons, be used to determine the entropy label value. The resulting label stack contains the server MPLS LSP label, ELI, EL and the client LSP label. Requirement MP#1 simply states that there must be a means to make this decision.
要求MP#1的原因可能并不明显。可以通过中点LSR将MPLS-TP LSP与其他客户端LSP聚合到非常大的MPLS服务器层LSP中，如主要城市之间的核心节点到核心节点MPLS LSP中的情况。在这种情况下，作为一组客户端LSP的中点LSR的MPLS LSP的入口没有可用于确定其特定客户端LSP中的一个是否正在使用MPLS或MPLS-TP的信令机制。如果在MPLS服务器层LSP入口LSR处，在MPLS LSP入口处，客户端MPLS-TP LSP的中点LSR将熵标签指示符（ELI）和熵标签（EL）添加到标签堆栈中，则可以避免MPLS-TP LSP的多路径负载分裂[RFC6790]。对于那些属于MPLS-TP LSP的客户机LSP，必须选择单个每LSP EL值。对于那些属于MPLS LSP的客户端LSP，出于实际原因，必须使用顶部标签下的每个数据包熵来确定熵标签值。生成的标签堆栈包含服务器MPLS LSP标签、ELI、EL和客户端LSP标签。要求MP#1简单地说，必须有一种方法来做出这一决定。
There is currently no signaling mechanism defined to support requirement MP#1, though that does not preclude a new extension being defined later. In the absence of a signaling extension, MPLS-TP can be identified through some form of configuration, such as configuration that provides an MPLS-TP-compatible server layer to all LSPs arriving on a specific interface or originating from a specific set of ingress LSRs.
目前没有定义支持需求MP#1的信号机制，尽管这并不排除以后定义新的扩展。在没有信令扩展的情况下，可以通过某种形式的配置来识别MPLS-TP，例如向到达特定接口或源自特定入口lsr集合的所有lsp提供MPLS-TP兼容服务器层的配置。
Alternatively, the need for requirement MP#1 can be eliminated if every MPLS-TP LSP created by an MPLS-TP ingress makes use of an Entropy Label Indicator (ELI) and Entropy Label (EL) below the MPLS-TP label [RFC6790]. This would require that all MPLS-TP LSRs in a deployment support Entropy Label, which may render it impractical in many deployments.
或者，如果由MPLS-TP入口创建的每个MPLS-TP LSP使用MPLS-TP标签下方的熵标签指示器（ELI）和熵标签（EL）[RFC6790]，则可以消除对需求MP#1的需求。这将要求部署中的所有MPLS-TP LSR都支持熵标签，这可能使其在许多部署中不切实际。
Some hardware that exists today can support requirement MP#2. Signaling in the absence of MPLS Entropy Labels can make use of link bundling with the path pinned to a specific component for MPLS-TP LSPs and link bundling using the all-ones component for MPLS LSPs. This prevents MPLS-TP LSPs from being carried within MPLS LSPs but does allow the coexistence of MPLS-TP and very large MPLS LSPs.
目前存在的一些硬件可以支持需求MP#2。在没有MPLS熵标签的情况下，信令可以利用链路捆绑（路径固定到MPLS-TP LSP的特定组件）和链路捆绑（使用MPLS LSP的全一组件）。这可以防止MPLS-TP LSP在MPLS LSP中传输，但允许MPLS-TP和非常大的MPLS LSP共存。
When Entropy Label Indicators (ELIs) and Entropy Labels (ELs) are not applied by MPLS-TP ingresses, MPLS-TP LSPs can be carried as client LSPs within an MPLS server LSP if the ingress of the MPLS server-layer LSP pushes an Entropy Label Indicator (ELI) and Entropy Label (EL) below the server-layer LSP label(s) in the label stack, just above the MPLS-TP LSP label entry [RFC6790]. The value of EL can be randomly selected at the client MPLS-TP LSP setup time, and the same EL value can be used for all packets of that MPLS-TP LSP. This allows MPLS-TP LSPs to be carried as client LSPs within MPLS LSPs and satisfies MPLS-TP forwarding requirements but requires that MPLS LSRs be able to identify MPLS-TP LSPs (requirement MP#1).
当MPLS-TP入口未应用熵标签指示符（ELI）和熵标签（EL）时，如果MPLS服务器层LSP的入口将熵标签指示符（ELI）和熵标签（EL）推到标签堆栈中服务器层LSP标签的下方，则MPLS-TP LSP可以作为MPLS服务器LSP内的客户端LSP携带，就在MPLS-TP LSP标签条目[RFC6790]上方。EL值可以在客户端MPLS-TP LSP设置时随机选择，并且相同的EL值可以用于该MPLS-TP LSP的所有数据包。这允许MPLS-TP LSP在MPLS LSP中作为客户端LSP携带，并满足MPLS-TP转发要求，但要求MPLS LSR能够识别MPLS-TP LSP（要求MP#1）。
MPLS-TP traffic can be protected from degraded performance due to an imperfect load split if the MPLS-TP traffic is given queuing priority. For example, using (1) strict priority and policing, shaping at ingress, or per-LSP shaping locally, or (2) per-LSP weighted queuing locally. This can be accomplished using the Traffic Class (TC) field and Diffserv treatment of traffic [RFC5462] [RFC2475]. In the event of congestion due to load imbalance, only non-prioritized traffic will suffer as long as there is a low percentage of prioritized traffic.
如果MPLS-TP流量具有排队优先级，则可以保护MPLS-TP流量不受由于不完全负载分割而导致的性能降级的影响。例如，使用（1）严格的优先级和策略、入口整形、或本地每LSP整形，或（2）本地每LSP加权排队。这可以通过使用流量类别（TC）字段和流量的区分服务处理[RFC5462][RFC2475]来实现。如果由于负载不平衡而出现拥塞，只要优先流量的百分比较低，只有非优先流量才会受到影响。
If MPLS-TP LSPs are carried within MPLS LSPs and ELI and EL are used, requirement MP#3 is satisfied (1) for uncongested links where load balancing is not required, or (2) for MPLS-TP LSPs using Traffic Class (TC) and Diffserv, where the load rebalancing implementation rebalances only the less preferred traffic. Load rebalance is generally needed only when congestion occurs; therefore, restricting MPLS-TP to be carried over MPLS LSPs that are known to traverse only links that are expected to be uncongested can satisfy requirement MP#3.
如果MPLS-TP LSP在MPLS LSP中承载，并且使用ELI和EL，则满足要求MP#3（1）对于不需要负载平衡的未阻塞链路，或（2）对于使用流量类（TC）和Diffserv的MPLS-TP LSP，其中负载再平衡实现仅重新平衡较低优先级的流量。通常只有在发生拥堵时才需要重新平衡负荷；因此，将MPLS-TP限制在已知仅遍历预期未被占用的链路的MPLS LSP上可以满足要求MP#3。
An MPLS-TP LSP can be pinned to a Link Bundle component link if the behavior of requirement MP#2 is preferred. An MPLS-TP LSP can be assigned to a Link Bundle but not pinned if the behavior of requirement MP#3 is preferred. In both of these cases, the MPLS-TP LSP must be the top-level LSP, except as noted above.
如果首选需求MP#2的行为，则MPLS-TP LSP可以固定到链路束组件链路。如果首选需求MP#3的行为，则MPLS-TP LSP可以分配给链路束，但不能固定。在这两种情况下，MPLS-TP LSP必须是顶级LSP，除非如上所述。
If MPLS-TP LSPs can be moved among component links, then the Link Bundle all-ones component link can be used or server-layer MPLS LSPs can be used with no restrictions on the server-layer MPLS use of multipath, except that Entropy Labels must be supported along the entire path. An Entropy Label must be used to ensure that all of the MPLS-TP payload and OAM traffic are carried on the same component, except during very infrequent transitions due to load balancing. Since the Entropy Label Indicator and Entropy Label are always placed above the Generic Associated Channel Label (GAL) in the stack, the
如果MPLS-TP LSP可以在组件链路之间移动，则可以使用链路包all-One组件链路，或者使用服务器层MPLS LSP，而不限制服务器层MPLS使用多路径，但必须沿整个路径支持熵标签。必须使用熵标签来确保所有MPLS-TP有效负载和OAM流量都在同一个组件上进行，除非在由于负载平衡而导致的极不频繁的转换期间。由于熵标签指示器和熵标签始终位于堆栈中通用关联通道标签（GAL）的上方，因此
presence of a GAL will not affect the selection of a component link as long as the LSR does not hash on the label stack entries below the Entropy Label.
只要LSR不在熵标签下方的标签堆栈项上散列，GAL的存在就不会影响组件链接的选择。
An MPLS-TP LSP may not traverse multipath links on the path where MPLS-TP forwarding requirements cannot be met. Such links include any using pre-[RFC6790] Ethernet Link Aggregation, pre-[RFC6790] Link Bundling using the all-ones component link, or any other form of multipath that does not support termination of the entropy search at the EL as called for in [RFC6790]. An MPLS-TP LSP MUST NOT traverse a server-layer MPLS LSP that traverses any form of multipath that does not support termination of the entropy search at the EL. For this to occur, the MPLS-TP ingress LSR MUST be aware of these links. This is the reason for requirement MP#4.
MPLS-TP LSP可能不会在无法满足MPLS-TP转发要求的路径上穿越多路径链路。此类链路包括使用预[RFC6790]以太网链路聚合的任何链路、使用“全一”组件链路的预[RFC6790]链路捆绑，或不支持在EL处终止熵搜索的任何其他形式的多路径，如[RFC6790]中所述。MPLS-TP LSP不得遍历服务器层MPLS LSP，该服务器层MPLS LSP遍历不支持在EL处终止熵搜索的任何形式的多路径。为此，MPLS-TP入口LSR必须知道这些链路。这就是要求MP#4的原因。
Requirement MP#4 can be supported using administrative attributes. Administrative attributes are defined in [RFC3209]. Some configuration is required to support this.
可以使用管理属性支持需求MP#4。管理属性在[RFC3209]中定义。需要一些配置来支持这一点。
In MPLS Link Bundling the requirement for bidirectional co-routing can be interpreted as meaning that the same set of LSRs must be traversed or can be interpreted to mean that the same set of component links must be traversed [RFC4201] [RFC3473]. Following the procedures of Section 3 of RFC 3473 where Link Bundling is used only ensures that the same set of LSRs are traversed and that acceptable labels are created in each direction.
在MPLS链路捆绑中，双向共路由的要求可以解释为意味着必须遍历同一组LSR，或者可以解释为意味着必须遍历同一组组件链路[RFC4201][RFC3473]。按照RFC 3473第3节中使用链路捆绑的程序，仅确保穿过同一组LSR，并在每个方向上创建可接受的标签。
When an MPLS-TP LSP is set up over a MPLS LSP, if the MPLS-TP LSP is a bidirectional LSP, then providers who want to only set these MPLS-TP LSPs over bidirectional co-routed MPLS LSPs can make use of administrative attributes [RFC3209] to ensure that this occurs. If MPLS-TP LSPs are carried by unidirectional MPLS LSPs, the MPLS-TP OAM will be unaffected, as only the MPLS LSP endpoints will appear as MPLS-TP OAM Maintenance Entity Group Intermediate Points (MIPs).
当通过MPLS LSP设置MPLS-TP LSP时，如果MPLS-TP LSP是双向LSP，则仅希望通过双向共路由MPLS LSP设置这些MPLS-TP LSP的提供商可以使用管理属性[RFC3209]来确保发生这种情况。如果MPLS-TP LSP由单向MPLS LSP承载，则MPLS-TP OAM将不受影响，因为只有MPLS LSP端点将显示为MPLS-TP OAM维护实体组中间点（MIP）。
Two methods of adding an Entropy Label are described above. The MPLS-TP ingress must have a means to determine which links can support MPLS-TP in selecting a path (MP#4). Administrative attributes can satisfy that requirement. If the MPLS-TP LSR is capable of adding ELI/EL to the label stack, this method is preferred. However, equipment furthest from a provider's network core is the least likely to support RFC 6790 in the near term. For portions of the topology where an MPLS-TP is carried within a server-layer MPLS LSP, the ingress of the server-layer MPLS LSP can add ELI/ EL using a fixed EL value per client LSP, except those known not to require MPLS-TP treatment. There are numerous ways to determine which client LSPs are MPLS-TP LSPs and which are not. While this
上面描述了添加熵标签的两种方法。MPLS-TP入口必须有一种方法来确定哪些链路可以支持MPLS-TP选择路径（MP#4）。管理属性可以满足这一要求。如果MPLS-TP LSR能够向标签堆栈添加ELI/EL，则首选此方法。但是，距离提供商网络核心最远的设备在短期内最不可能支持RFC 6790。对于在服务器层MPLS-LSP内承载MPLS-TP的拓扑部分，服务器层MPLS-LSP的入口可以使用每个客户端LSP的固定EL值添加ELI/EL，已知不需要MPLS-TP处理的除外。有许多方法可以确定哪些客户端LSP是MPLS-TP LSP，哪些不是。而这
determination is out of scope and will vary among deployments, configuration or the presence of specific attribute affinities in RSVP-TE signaling are among the likely means to do so.
确定不在范围内，并且会因部署而有所不同，RSVP-TE信令中的配置或特定属性亲和力的存在是可能的方法之一。
Carrying MPLS LSPs that are larger than a component link over an MPLS-TP server layer requires that the large MPLS client-layer LSP be accommodated by multiple MPLS-TP server-layer LSPs. MPLS multipath can be used in the client-layer MPLS.
在MPLS-TP服务器层上承载大于组件链路的MPLS LSP需要由多个MPLS-TP服务器层LSP容纳大型MPLS客户端层LSP。MPLS多路径可用于客户端层MPLS。
Creating multiple MPLS-TP server-layer LSPs places a greater Incoming Label Map (ILM) scaling burden on the LSR. High-bandwidth MPLS cores with a smaller amount of nodes have the greatest tendency to require LSPs in excess of component links; therefore, the reduction in the number of nodes offsets the impact of increasing the number of server-layer LSPs in parallel. Today, only in cases where deployed LSR ILMs are small would this be an issue.
创建多个MPLS-TP服务器层LSP会给LSR带来更大的传入标签映射（ILM）扩展负担。节点数量较少的高带宽MPLS核心最有可能需要超过组件链路的LSP；因此，节点数量的减少抵消了并行增加服务器层LSP数量的影响。今天，只有在部署的LSR ILM很小的情况下，这才是一个问题。
The most significant disadvantage of MPLS-TP as a server layer for MPLS is that the use of MPLS-TP server-layer LSPs reduces the efficiency of carrying the MPLS client layer. The service that provides by far the largest offered load in provider networks is the Internet, for which the LSP capacity reservations are predictions of expected load. Many of these MPLS LSPs may be smaller than component link capacity. Using MPLS-TP as a server layer results in bin-packing problems for these smaller LSPs. For those LSPs that are larger than component link capacity, the LSP capacities need not be (and often are not) integer multiples of convenient capacity increments such as 10 Gbit/s. Using MPLS-TP as an underlying server layer greatly reduces the ability of the client-layer MPLS LSPs to share capacity. For example, when one MPLS LSP is underutilizing its predicted capacity, the fixed allocation of MPLS-TP to component links may not allow another LSP to exceed its predicted capacity. Using MPLS-TP as a server layer may result in less efficient use of resources and may result in a less cost-effective network.
MPLS-TP作为MPLS的服务器层的最大缺点是，使用MPLS-TP服务器层LSP会降低承载MPLS客户端层的效率。目前为止，在提供商网络中提供最大负载的服务是Internet，对于该服务，LSP容量预留是对预期负载的预测。许多MPLS LSP可能小于组件链路容量。使用MPLS-TP作为服务器层会导致这些较小的LSP出现装箱问题。对于那些大于组件链路容量的LSP，LSP容量不需要（通常不是）方便容量增量的整数倍，例如10gbit/s。使用MPLS-TP作为底层服务器层大大降低了客户端层MPLS LSP共享容量的能力。例如，当一个MPLS LSP未充分利用其预测容量时，MPLS-TP对组件链路的固定分配可能不允许另一个LSP超过其预测容量。将MPLS-TP用作服务器层可能会导致资源使用效率降低，并可能导致网络成本效益降低。
No additional requirements beyond MPLS-TP as it is now currently defined are required to support MPLS-TP as a server layer for MPLS. It is therefore viable but has some undesirable characteristics discussed above.
除了目前定义的MPLS-TP之外，不需要其他要求来支持MPLS-TP作为MPLS的服务器层。因此，它是可行的，但具有上面讨论过的一些不良特征。
MPLS equipment deployed in the core currently supports multipath. For large service providers, core LSR must support some form of multipath to be deployable. Deployed MPLS access and edge equipment is often oblivious to the use of multipath in the core. It is
部署在核心中的MPLS设备目前支持多路径。对于大型服务提供商，核心LSR必须支持某种形式的可部署多路径。部署的MPLS接入和边缘设备通常不会注意到在核心中使用多路径。它是
expected that at least first-generation MPLS-TP equipment will be oblivious to the use of multipath in the core. This first-generation MPLS-TP equipment is deployable in a core using multipath, with no adverse impact to RSVP-TE signaling, if:
预计至少第一代MPLS-TP设备将忽略核心中的多路径使用。第一代MPLS-TP设备可使用多路径部署在核心中，对RSVP-TE信令没有不利影响，前提是：
1. the edge equipment can support administrative attributes (RFC 3209),
1. 边缘设备可以支持管理属性（RFC 3209），
2. the core equipment can support ELI/EL, and
2. 核心设备可支持ELI/EL，以及
3. the core equipment can put a per-LSP fixed EL value on any LSP that indicates a particular attribute affinity or can identify a client MPLS-TP LSP through some other means.
3. 核心设备可以在指示特定属性亲缘关系的任何LSP上放置每LSP固定EL值，或者可以通过一些其他方式识别客户端MPLS-TP LSP。
There are no issues carrying MPLS over MPLS-TP, except when the MPLS LSP is too big to be carried by a single MPLS-TP LSP. Most MPLS core equipment and some edge equipment can configure an MPLS Link Bundle [RFC4201] over multiple component links where the component links are themselves MPLS LSP. This existing capability can be used to carry large MPLS LSPs and overcome the limited capacity of any single server-layer MPLS-TP LSP.
在MPLS-TP上承载MPLS没有问题，除非MPLS LSP太大，无法由单个MPLS-TP LSP承载。大多数MPLS核心设备和一些边缘设备可以在多个组件链路上配置MPLS链路包[RFC4201]，其中组件链路本身就是MPLS LSP。此现有功能可用于承载大型MPLS LSP，并克服任何单一服务器层MPLS-TP LSP的容量限制。
MPLS OAM and MPLS-TP OAM are unaffected in the following cases proposed in this document:
MPLS OAM和MPLS-TP OAM在本文件提出的以下情况下不受影响：
1. Where MPLS is carried over a single MPLS-TP, all traffic flows on one link, MPLS OAM is unaffected and need not use multipath support in LSP Ping [RFC4379].
1. 当MPLS通过单个MPLS-TP传输时，一条链路上的所有流量、MPLS OAM不受影响，并且不需要在LSP Ping中使用多路径支持[RFC4379]。
2. Where MPLS-TP is carried over MPLS, all traffic for that MPLS-TP LSP is carried over one link thanks to the fixed EL value. In this case, MPLS-TP OAM is unaffected.
2. 在通过MPLS承载MPLS-TP的情况下，由于固定EL值，该MPLS-TP LSP的所有流量都通过一条链路承载。在这种情况下，MPLS-TP OAM不受影响。
3. Where MPLS LSPs are carried over MPLS LSPs (an existing case) or over multiple MPLS-TP LSPs, the multipath support in LSP Ping is used and LSP Ping operation is unaffected [RFC4379] [RFC6425].
3. 如果MPLS LSP通过MPLS LSP（现有情况）或多个MPLS-TP LSP承载，则使用LSP Ping中的多路径支持，并且LSP Ping操作不受影响[RFC4379][RFC6425]。
Carlos Pignataro, Dave Allan, and Mach Chen provided valuable comments and suggestions. Carlos suggested that MPLS-TP requirements in RFC 5960 be explicitly referenced or quoted. An email conversation with Dave led to the inclusion of references and quotes from RFCs 6371 and 6374. Mach made suggestions to improve the clarity of the document.
Carlos Pignataro、Dave Allan和Mach Chen提供了宝贵的意见和建议。Carlos建议明确引用或引用RFC 5960中的MPLS-TP要求。通过与Dave的电子邮件对话，纳入了RFC 6371和6374的参考和引用。马赫提出了提高文件清晰度的建议。
This document specifies use of existing MPLS and MPLS-TP mechanisms to support MPLS and MPLS-TP as client and server layers for each other. This use of existing mechanisms supports coexistence of MPLS/ GMPLS (without MPLS-TP) when used over a packet network, MPLS-TP, and multipath. The combination of MPLS, MPLS-TP, and multipath does not introduce any new security threats. The security considerations for MPLS/GMPLS and for MPLS-TP are documented in [RFC5920] and [RFC6941].
本文档指定如何使用现有的MPLS和MPLS-TP机制来支持MPLS和MPLS-TP互为客户端和服务器层。当在分组网络、MPLS-TP和多路径上使用时，现有机制的这种使用支持MPLS/GMPLS（无MPLS-TP）共存。MPLS、MPLS-TP和多路径的结合不会带来任何新的安全威胁。MPLS/GMPLS和MPLS-TP的安全注意事项记录在[RFC5920]和[RFC6941]中。
[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月。
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
[RFC5654]Niven Jenkins，B.，Brungard，D.，Betts，M.，Sprecher，N.，和S.Ueno，“MPLS传输配置文件的要求”，RFC 56542009年9月。
[RFC5960] Frost, D., Bryant, S., and M. Bocci, "MPLS Transport Profile Data Plane Architecture", RFC 5960, August 2010.
[RFC5960]Frost，D.，Bryant，S.，和M.Bocci，“MPLS传输配置文件数据平面架构”，RFC 59602010年8月。
[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, September 2011.
[RFC6371]Busi，I.和D.Allan，“基于MPLS的传输网络的运营、管理和维护框架”，RFC 6371，2011年9月。
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, September 2011.
[RFC6374]Frost，D.和S.Bryant，“MPLS网络的数据包丢失和延迟测量”，RFC 63742011年9月。
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, November 2012.
[RFC6790]Kompella，K.，Drake，J.，Amante，S.，Henderickx，W.，和L.Yong，“MPLS转发中熵标签的使用”，RFC 67902012年11月。
[ADV-MULTIPATH-REQ] Villamizar, C., McDysan, D., Ning, S., Malis, A., and L. Yong, "Requirements for Advanced Multipath in MPLS Networks", Work in Progress, February 2014.
[ADV-MULTIPATH-REQ]Villamizar，C.，McDysan，D.，Ning，S.，Malis，A.，和L.Yong，“MPLS网络中高级多路径的要求”，正在进行的工作，2014年2月。
[IEEE-802.1AX] IEEE, "IEEE Standard for Local and Metropolitan Area Networks - Link Aggregation", IEEE Std 802.1AX-2008, 2006, <http://standards.ieee.org/getieee802/download/ 802.1AX-2008.pdf>.
[IEEE-802.1AX]IEEE，“局域网和城域网的IEEE标准-链路聚合”，IEEE标准802.1AX-2008，2006<http://standards.ieee.org/getieee802/download/ 802.1AX-2008.pdf>。
[ITU-T.G.800] ITU-T, "Unified functional architecture of transport networks", ITU-T G.800, 2007, <http://www.itu.int/rec/ T-REC-G/recommendation.asp?parent=T-REC-G.800>.
[ITU-T.G.800]ITU-T，“传输网络的统一功能架构”，ITU-T G.800，2007年<http://www.itu.int/rec/ T-REC-G/recommendation.asp？parent=T-REC-G.800>。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.，和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[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月。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4206]Kompella，K.和Y.Rekhter，“具有通用多协议标签交换（GMPLS）流量工程（TE）的标签交换路径（LSP）层次结构”，RFC 4206，2005年10月。
[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月。
[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, September 2008.
[RFC5286]Atlas，A.和A.Zinin，“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月。
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, January 2010.
[RFC5714]Shand，M.和S.Bryant，“IP快速重路由框架”，RFC 5714，2010年1月。
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920]方，L，“MPLS和GMPLS网络的安全框架”，RFC 5920，2010年7月。
[RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa, S., and T. Nadeau, "Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 6425, November 2011.
[RFC6425]Saxena，S.，Swallow，G.，Ali，Z.，Farrel，A.，Yasukawa，S.，和T.Nadeau，“检测点对多点MPLS中的数据平面故障-LSP Ping扩展”，RFC 64252011年11月。
[RFC6941] Fang, L., Niven-Jenkins, B., Mansfield, S., and R. Graveman, "MPLS Transport Profile (MPLS-TP) Security Framework", RFC 6941, April 2013.
[RFC6941]Fang，L.，Niven Jenkins，B.，Mansfield，S.，和R.Graveman，“MPLS传输配置文件（MPLS-TP）安全框架”，RFC 69412013年4月。
Author's Address
作者地址
Curtis Villamizar Outer Cape Cod Network Consulting
Curtis Villamizar外科德角网络咨询公司
EMail: curtis@occnc.com
EMail: curtis@occnc.com