Internet Engineering Task Force (IETF) C. Villamizar, Ed.
Request for Comments: 7226 OCCNC, LLC
Category: Informational D. McDysan, Ed.
ISSN: 2070-1721 Verizon
S. Ning
Tata Communications
A. Malis
Huawei
L. Yong
Huawei USA
May 2014
Internet Engineering Task Force (IETF) C. Villamizar, Ed.
Request for Comments: 7226 OCCNC, LLC
Category: Informational D. McDysan, Ed.
ISSN: 2070-1721 Verizon
S. Ning
Tata Communications
A. Malis
Huawei
L. Yong
Huawei USA
May 2014
Requirements for Advanced Multipath in MPLS Networks
MPLS网络中对高级多路径的要求
Abstract
摘要
This document provides a set of requirements for Advanced Multipath in MPLS networks.
本文档提供了MPLS网络中高级多路径的一组要求。
Advanced Multipath is a formalization of multipath techniques currently in use in IP and MPLS networks and a set of extensions to existing multipath techniques.
高级多路径是目前在IP和MPLS网络中使用的多路径技术的形式化，是对现有多路径技术的一组扩展。
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/rfc7226.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7226.
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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Functional Requirements . . . . . . . . . . . . . . . . . . . 6
3.1. Availability, Stability, and Transient Response . . . . . 6
3.2. Component Links Provided by Lower-Layer Networks . . . . 7
3.3. Component Links with Different Characteristics . . . . . 8
3.4. Considerations for Bidirectional Client LSP . . . . . . . 9
3.5. Multipath Load-Balancing Dynamics . . . . . . . . . . . . 10
4. General Requirements for Protocol Solutions . . . . . . . . . 12
5. Management Requirements . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 15
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Functional Requirements . . . . . . . . . . . . . . . . . . . 6
3.1. Availability, Stability, and Transient Response . . . . . 6
3.2. Component Links Provided by Lower-Layer Networks . . . . 7
3.3. Component Links with Different Characteristics . . . . . 8
3.4. Considerations for Bidirectional Client LSP . . . . . . . 9
3.5. Multipath Load-Balancing Dynamics . . . . . . . . . . . . 10
4. General Requirements for Protocol Solutions . . . . . . . . . 12
5. Management Requirements . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 15
There is often a need to provide large aggregates of bandwidth that are best provided using parallel links between routers or carrying traffic over multiple MPLS Label Switched Paths (LSPs). In core networks, there is often no alternative since the aggregate capacities of core networks today far exceed the capacity of a single physical link or a single packet-processing element.
通常需要提供大量带宽，最好使用路由器之间的并行链路或通过多个MPLS标签交换路径（LSP）承载流量来提供这些带宽。在核心网络中，通常没有替代方案，因为当今核心网络的总容量远远超过单个物理链路或单个分组处理单元的容量。
The presence of parallel links, with each link potentially comprised of multiple layers, has resulted in additional requirements. Certain services may benefit from being restricted to a subset of the component links or a specific component link, where component link characteristics, such as latency, differ. Certain services require that an LSP be treated as atomic and avoid reordering. Other services will continue to require only that reordering not occur within a flow as is current practice.
平行链路的存在，每个链路可能由多个层组成，导致了额外的需求。某些服务可能受益于受限于组件链接的子集或特定组件链接，其中组件链接特性（如延迟）不同。某些服务要求LSP被视为原子的，并避免重新排序。其他服务将继续只要求重新排序，而不是像目前的做法那样在流中发生。
Numerous forms of multipath exist today, including MPLS Link Bundling [RFC4201], Ethernet Link Aggregation [IEEE-802.1AX], and various forms of Equal Cost Multipath (ECMP) such as for OSPF ECMP, IS-IS ECMP, and BGP ECMP. Refer to the appendices in [USE-CASES] for a description of existing techniques and a set of references.
目前存在多种形式的多路径，包括MPLS链路捆绑[RFC4201]、以太网链路聚合[IEEE-802.1AX]和各种形式的等成本多路径（ECMP），如OSPF ECMP、IS-IS ECMP和BGP ECMP。有关现有技术的描述和一组参考资料，请参阅[用例]中的附录。
The purpose of this document is to clearly enumerate a set of requirements related to the protocols and mechanisms that provide MPLS-based Advanced Multipath. The intent is to first provide a set of functional requirements, in Section 3, that are as independent as possible of protocol specifications. A set of general protocol requirements are defined in Section 4. A set of network management requirements are defined in Section 5.
本文档的目的是明确列举与提供基于MPLS的高级多路径的协议和机制相关的一组需求。目的是在第3节中首先提供一组功能需求，这些需求尽可能独立于协议规范。第4节定义了一套通用协议要求。第5节定义了一组网络管理要求。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Any statement that requires the solution to support some new functionality through use of [RFC2119] keywords should be interpreted as follows. The implementation either MUST or SHOULD support the new functionality, depending on the use of either MUST or SHOULD in the requirements statement. The implementation SHOULD, in most or all cases, allow any new functionality to be individually enabled or disabled through configuration. A service provider or other deployment MAY enable or disable any feature in their network, subject to implementation limitations on sets of features that can be disabled.
任何需要解决方案通过使用[RFC2119]关键字来支持某些新功能的语句都应解释如下。实现必须或应该支持新功能，具体取决于需求声明中必须或应该的使用。在大多数或所有情况下，实现应允许通过配置单独启用或禁用任何新功能。服务提供商或其他部署可以启用或禁用其网络中的任何功能，但受可禁用功能集的实现限制的限制。
Multipath The term "multipath" includes all techniques in which:
多路径术语“多路径”包括所有技术，其中：
1. Traffic can take more than one path from one node to a destination.
1. 流量可以从一个节点到一个目的地采用多条路径。
2. Individual packets take one path only. Packets are not subdivided and reassembled at the receiving end.
2. 单个数据包仅采用一条路径。数据包不在接收端进行细分和重新组装。
3. Packets are not resequenced at the receiving end.
3. 数据包不会在接收端重新排序。
4. The paths may be:
4. 路径可以是：
a. parallel links between two nodes,
a. 两个节点之间的并行链接，
b. specific paths across a network to a destination node, or
b. 通过网络到目标节点的特定路径，或
c. links or paths to an intermediate node used to reach a common destination.
c. 指向用于到达公共目的地的中间节点的链接或路径。
The paths need not have equal capacity. The paths may or may not have equal cost in a routing protocol.
路径不需要具有相同的容量。在路由协议中，路径的成本可能相等，也可能不相等。
Advanced Multipath Advanced Multipath is a formalization of multipath techniques that meets the requirements defined in this document. A key capability of Advanced Multipath is the support of non-homogeneous component links.
高级多路径高级多路径是满足本文档中定义的要求的多路径技术的形式化。高级多路径的一个关键功能是支持非同质组件链路。
Advanced Multipath Group (AMG) An AMG is a collection of component links where Advanced Multipath techniques are applied.
高级多路径组（AMG）AMG是应用高级多路径技术的组件链接的集合。
Composite Link The term "composite link" had been a registered trademark of Avici Systems, but it was abandoned in 2007. The term "composite link" is now defined by the ITU-T in [ITU-T.G.800]. The ITU-T definition includes multipath as defined here, plus inverse multiplexing, which is explicitly excluded from the definition of multipath.
复合链接术语“复合链接”是Avici Systems的注册商标，但在2007年被放弃。术语“复合链路”现在由ITU-T在[ITU-T.G.800]中定义。ITU-T定义包括此处定义的多路径，加上反向多路复用，这被明确排除在多路径定义之外。
Inverse Multiplexing Inverse multiplexing is another method of sending traffic over multiple links. Inverse multiplexing either transmits whole packets and resequences the packets at the receiving end or subdivides packets and reassembles the packets at the receiving end. Inverse multiplexing requires that all packets be handled by a common egress packet processing element and is, therefore, not useful for very high-bandwidth applications.
反向多路复用反向多路复用是通过多个链路发送通信量的另一种方法。反向多路复用要么在接收端传输整个数据包并对数据包重新排序，要么在接收端细分数据包并重新组装数据包。反向多路复用要求所有分组由公共出口分组处理元件处理，因此，对于非常高带宽的应用不有用。
Component Link The ITU-T definition of composite link in [ITU-T.G.800] and the IETF definition of link bundling in [RFC4201] both refer to an individual link in the composite link or link bundle as a component link. The term "component link" is applicable to all forms of multipath. The IEEE uses the term "member" rather than "component link" in Ethernet Link Aggregation [IEEE-802.1AX].
组件链路[ITU-T.G.800]中的ITU-T复合链路定义和[RFC4201]中的IETF链路捆绑定义均将复合链路或链路捆绑中的单个链路称为组件链路。术语“组件链路”适用于所有形式的多路径。IEEE在以太网链路聚合[IEEE-802.1AX]中使用术语“成员”而不是“组件链路”。
Client Layer A client layer is the layer immediately above a server layer.
客户端层客户端层是服务器层正上方的层。
Server Layer A server layer is the layer immediately below a client layer.
服务器层服务器层是紧挨着客户端层的层。
Higher Layers Relative to a particular layer, a client layer and any layer above that is considered a higher layer. Upper layer is synonymous with higher layer.
相对于特定层、客户端层和其上被视为更高层的任何层的更高层。上层是上层的同义词。
Lower Layers Relative to a particular layer, a server layer and any layer below that is considered a lower layer.
相对于特定层、服务器层和其下任何被视为较低层的层的较低层。
Client LSP A client LSP is an LSP that has been set up over one or more lower layers. In the context of this discussion, one type of client LSP is an LSP that has been set up over an AMG.
客户端LSP客户端LSP是在一个或多个较低层上设置的LSP。在本讨论的上下文中，一种类型的客户端LSP是在AMG上设置的LSP。
Flow A sequence of packets that should be transferred in order on one component link of a multipath.
在多路径的一个组件链路上按顺序传输的数据包序列。
Flow Identification The label stack and other information that uniquely identifies a flow. Other information in flow identification may include an IP header, pseudowire (PW) control word, Ethernet Media Access Control (MAC) address, etc. Note that a client LSP may contain one or more flows, or a client LSP may be equivalent to a flow. Flow identification is used to locally select a component link or a path through the network toward the destination.
流标识唯一标识流的标签堆栈和其他信息。流标识中的其他信息可包括IP报头、伪线（PW）控制字、以太网媒体访问控制（MAC）地址等。注意，客户端LSP可包含一个或多个流，或者客户端LSP可等效于流。流标识用于本地选择组件链接或通过网络指向目标的路径。
Load Balance Load split, load balance, or load distribution refers to subdividing traffic over a set of component links such that load is fairly evenly distributed over the set of component links and certain packet ordering requirements are met. Some existing techniques better achieve these objectives than others.
负载平衡负载拆分、负载平衡或负载分配指的是在一组组件链路上对流量进行细分，以使负载在该组组件链路上均匀分布，并满足某些数据包排序要求。一些现有技术比其他技术更好地实现这些目标。
Performance Objective Numerical values for performance measures: principally availability, latency, and delay variation. Performance objectives may be related to Service Level Agreements (SLAs) as defined in [RFC2475] or may be strictly internal. Performance objectives may span links from edge to edge or from end to end. Performance objectives may span one provider or multiple providers.
性能指标的性能目标数值：主要是可用性、延迟和延迟变化。绩效目标可能与[RFC2475]中定义的服务水平协议（SLA）有关，也可能是严格的内部目标。性能目标可能跨越从边缘到边缘或从端到端的链接。性能目标可以跨越一个提供商或多个提供商。
A component link may be a point-to-point physical link (where a "physical link" includes one or more link layers, plus a physical layer) or a logical link that preserves ordering in the steady state. A component link may have transient out-of-order events, but such events must not exceed the network's performance objectives. For example, a component link may be comprised of any supportable combination of link layers over a physical layer or over logical sub-layers -- including those providing physical-layer emulation -- or over MPLS server-layer LSP.
组件链路可以是点对点物理链路（其中“物理链路”包括一个或多个链路层，加上物理层）或在稳定状态下保持顺序的逻辑链路。组件链路可能存在瞬时无序事件，但此类事件不得超过网络的性能目标。例如，组件链路可以由物理层或逻辑子层（包括提供物理层仿真的层）或MPLS服务器层LSP上的链路层的任何可支持组合组成。
The ingress and egress of a multipath may be midpoint LSRs with respect to a given client LSP. A midpoint LSR does not participate in the signaling of any clients of the client LSP. Therefore, in general, multipath endpoints cannot determine requirements of clients of a client LSP through participation in the signaling of the clients of the client LSP.
多路径的入口和出口可以是关于给定客户端LSP的中点lsr。中点LSR不参与客户端LSP的任何客户端的信令。因此，通常，多路径端点不能通过参与客户端LSP的客户端的信令来确定客户端LSP的客户端的需求。
This document makes no statement on whether Advanced Multipath is itself a layer or whether an instance of AMG is itself a layer. This is to avoid engaging in long and pointless discussions about what constitutes a proper layer.
本文档没有说明高级多路径本身是一个层还是AMG实例本身是一个层。这是为了避免就什么构成一个合适的层进行冗长而毫无意义的讨论。
The term "Advanced Multipath" is intended to be used within the context described in this document and related documents, for example, [USE-CASES] and [FRAMEWORK]. Other Advanced Multipath techniques may arise in the future. If the capabilities defined in this document become commonplace, they would no longer be considered "advanced". Use of the term "advanced multipath" outside this document, if referring to the term as defined here, should indicate Advanced Multipath as defined by this document, citing the current document name. If using another definition of "advanced multipath", documents may optionally clarify that they are not using the term "advanced multipath" as defined by this document if clarification is deemed helpful.
术语“高级多路径”旨在在本文档和相关文档中描述的上下文中使用，例如，[用例]和[框架]。未来可能会出现其他先进的多路径技术。如果本文件中定义的功能变得普遍，则不再将其视为“高级”。在本文档之外使用术语“高级多路径”，如果指此处定义的术语，则应表示本文档定义的高级多路径，并引用当前文档名称。如果使用了“高级多路径”的另一个定义，如果澄清被认为有帮助，文档可以选择性地澄清它们没有使用本文档定义的术语“高级多路径”。
The functional requirements in this section are grouped in subsections, starting with the highest priority.
本节中的功能需求分为几个小节，从最高优先级开始。
In addition to maintaining stability, limiting the period of unavailability in response to failures or transient events is extremely important.
除了保持稳定性外，限制故障或瞬态事件时的不可用期也极为重要。
FR#1 The transient period between some service disrupting event and the convergence of the routing and/or signaling protocols MUST occur within a time frame specified by performance objective values.
FR#1某些服务中断事件与路由和/或信令协议收敛之间的过渡期必须在性能目标值指定的时间范围内发生。
FR#2 An AMG MAY be announced in conjunction with detailed parameters about its component links, such as bandwidth and latency. The AMG SHALL behave as a single IGP adjacency.
FR#2 AMG可能会与其组件链路的详细参数（如带宽和延迟）一起发布。AMG应表现为单个IGP邻接。
FR#3 The solution SHALL provide a means to summarize some routing advertisements regarding the characteristics of an AMG such that the updated protocol mechanisms maintain convergence times within the time frame needed to meet or not significantly exceed existing performance objectives for convergence on the same network or convergence on a network with a similar topology.
FR#3解决方案应提供一种方法，总结一些关于AMG特性的路由公告，以便更新的协议机制在满足或不显著超过现有性能目标所需的时间范围内保持收敛时间，以便在同一网络上收敛或在同一网络上收敛具有相似拓扑结构的网络。
FR#4 The solution SHALL ensure that restoration operations happen within the time frame needed to meet existing performance objectives for restoration time on the same network or restoration time on a network with a similar topology.
FR#4解决方案应确保恢复操作在满足相同网络上恢复时间或具有类似拓扑的网络上恢复时间的现有性能目标所需的时间范围内进行。
FR#5 The solution shall provide a mechanism to select a set of paths for an LSP across a network in such a way that flows within the LSP are distributed across the set of paths, while meeting all of the other requirements stated above. The solution SHOULD work in a manner similar to existing multipath techniques, except as necessary to accommodate Advanced Multipath requirements.
FR#5解决方案应提供一种机制，为网络上的LSP选择一组路径，使LSP内的流分布在该组路径上，同时满足上述所有其他要求。该解决方案应以类似于现有多路径技术的方式工作，除非满足高级多路径需求。
FR#6 If extensions to existing protocols are specified and/or new protocols are defined, then the solution SHOULD provide a means for a network operator to migrate an existing deployment in a minimally disruptive manner.
FR#6如果指定了对现有协议的扩展和/或定义了新协议，则解决方案应为网络运营商提供一种方法，使其能够以最小中断的方式迁移现有部署。
FR#7 Any load-balancing solutions MUST NOT oscillate. Some change in path MAY occur. The solution MUST ensure that path stability and traffic reordering continue to meet performance objectives on the same network or on a network with a similar topology. Since oscillation may cause reordering, there MUST be means to control the frequency of changing the component link over which a flow is placed.
FR#7任何负载平衡解决方案都不得振荡。路径可能会发生一些变化。解决方案必须确保路径稳定性和流量重新排序在同一网络或具有类似拓扑的网络上继续满足性能目标。由于振荡可能会导致重新排序，因此必须有方法控制改变组件链接的频率，在组件链接上放置流。
FR#8 Management and diagnostic protocols MUST be able to operate over AMGs.
FR#8管理和诊断协议必须能够在AMG上运行。
Existing scaling techniques used in MPLS networks apply to MPLS networks that support Advanced Multipath. Scalability and stability are covered in more detail in [FRAMEWORK].
MPLS网络中使用的现有扩展技术适用于支持高级多路径的MPLS网络。可扩展性和稳定性在[框架]中有更详细的介绍。
A component link may be supported by a lower-layer network. For example, the lower layer may be a circuit-switched network or another MPLS network (e.g., MPLS Transport Profile (MPLS-TP)). The lower-layer network may change the latency (and/or other performance parameters) seen by the client layer. Currently, there is no protocol for the lower-layer network to inform the higher-layer network of a change in a performance parameter. Communication of the latency performance parameter is a very important requirement. Communication of other performance parameters (e.g., delay variation) is desirable.
组件链路可由较低层网络支持。例如，较低层可以是电路交换网络或另一MPLS网络（例如，MPLS传输配置文件（MPLS-TP））。较低层网络可能会更改客户端层看到的延迟（和/或其他性能参数）。目前，低层网络没有向高层网络通知性能参数变化的协议。延迟性能参数的通信是一个非常重要的要求。其他性能参数（例如延迟变化）的通信是可取的。
FR#9 The solution SHALL specify a protocol means to allow a server-layer network to communicate latency to the client-layer network.
FR#9解决方案应指定一种协议方式，以允许服务器层网络与客户端层网络进行通信延迟。
FR#10 The precision of latency reporting SHOULD be configurable. A reasonable default SHOULD be provided. Implementations SHOULD support precision of at least 10% of the one-way latencies for latency of 1 msec or more.
FR#10延迟报告的精度应可配置。应提供合理的违约。对于1毫秒或以上的延迟，实现应支持至少10%的单向延迟精度。
The intent is to measure the predominant latency in uncongested service-provider networks, where geographic delay dominates and is on the order of milliseconds or more. The argument for including queuing delay is that it reflects the delay experienced by applications. The argument against including queuing delay is that if used in routing decisions, it can result in routing instability. This trade-off is discussed in detail in [FRAMEWORK].
其目的是测量未拥挤服务提供商网络中的主要延迟，其中地理延迟占主导地位，大约为毫秒或更多。包含排队延迟的理由是，它反映了应用程序所经历的延迟。反对包含排队延迟的理由是，如果在路由决策中使用排队延迟，可能会导致路由不稳定。在[框架]中详细讨论了这种权衡。
As one means to provide high availability, network operators deploy a topology in the MPLS network using lower-layer networks that have a certain degree of diversity at the lower layer(s). Many techniques have been developed to balance the distribution of flows across component links that connect the same pair of nodes or ultimately lead to a common destination.
作为提供高可用性的一种手段，网络运营商使用在较低层具有一定程度多样性的较低层网络在MPLS网络中部署拓扑。已经开发了许多技术来平衡连接同一对节点或最终通向公共目的地的组件链接之间的流分布。
FR#11 In the requirements that follow in this document, the word "indicate" is used where information may be provided by either the combination of link state IGP advertisement and MPLS LSP signaling or via management plane protocols. In later documents, providing framework and protocol definitions, both signaling and management plane mechanisms, MUST be defined.
FR#11在本文件后面的要求中，如果信息可以通过链路状态IGP公告和MPLS LSP信令的组合或通过管理平面协议提供，则使用“指示”一词。在以后的文档中，必须定义提供框架和协议定义的信令和管理平面机制。
FR#12 The solution SHALL provide a means for the client layer to indicate a requirement that a client LSP will traverse a component link with the minimum-latency value. This will provide a means by which minimum latency performance objectives of flows within the client LSP can be supported.
FR#12解决方案应为客户端层提供一种方法，以表明客户端LSP将以最小延迟值穿越组件链路的要求。这将提供一种方法，通过该方法可以支持客户端LSP内流的最小延迟性能目标。
FR#13 The solution SHALL provide a means for the client layer to indicate a requirement that a client LSP will traverse a component link with a maximum acceptable latency value as specified by protocol. This will provide a means by which bounded latency performance objectives of flows within the client LSP can be supported.
FR#13解决方案应为客户端层提供一种方法，以表明客户端LSP将以协议规定的最大可接受延迟值穿越组件链路的要求。这将提供一种方法，通过该方法可以支持客户端LSP内流的有界延迟性能目标。
FR#14 The solution SHALL provide a means for the client layer to indicate a requirement that a client LSP will traverse a component link with a maximum acceptable delay variation value as specified by protocol.
FR#14解决方案应为客户层提供一种方法，以表明客户LSP将以协议规定的最大可接受延迟变化值穿过组件链路的要求。
The above set of requirements applies to component links with different characteristics, regardless of whether those component links are provided by parallel physical links between nodes or by sets of paths across a network provided by a server-layer LSP.
上述一组要求适用于具有不同特征的组件链路，而不管这些组件链路是由节点之间的并行物理链路提供的，还是由服务器层LSP提供的网络上的路径集提供的。
Allowing multipath to contain component links with different characteristics can improve the overall load balance and can be accomplished while still accommodating the more strict requirements of a subset of client LSP.
允许多路径包含具有不同特性的组件链接可以改善总体负载平衡，并且可以在满足客户端LSP子集更严格要求的同时实现。
Some client LSPs MAY require a path bound to a specific set of component links. This case is most likely to occur in a bidirectional client LSP where time synchronization protocols such as the Precision Time Protocol (PTP) or the Network Time Protocol (NTP) are carried or in any other case where symmetric delay is highly desirable. There may be other uses of this capability.
某些客户端LSP可能需要绑定到一组特定组件链接的路径。这种情况最有可能发生在双向客户端LSP中，其中承载诸如精确时间协议（PTP）或网络时间协议（NTP）之类的时间同步协议，或者在非常需要对称延迟的任何其他情况下。此功能可能还有其他用途。
Other client LSPs may only require that the LSP serve the same set of nodes in both directions. This is necessary if protocols are carried that make use of the reverse direction of the LSP as a back channel in cases such Operations, Administration, and Maintenance (OAM) protocols using IPv4 Time to Live (TTL) or IPv4 Hop Limit to monitor or diagnose the underlying path. There may be other uses of this capability.
其他客户端LSP可能只要求LSP在两个方向上服务于相同的节点集。如果在使用IPv4生存时间（TTL）或IPv4跃点限制来监视或诊断底层路径的操作、管理和维护（OAM）协议的情况下，承载的协议将LSP的反向用作反向通道，则这是必要的。此功能可能还有其他用途。
FR#15 The solution SHALL provide a means for the client layer to indicate a requirement that a client LSP be bound to a particular component link within an AMG. If this option is not exercised, then a client LSP that is carried over an AMG may be bound to any component link or set of component links matching all other signaled requirements, and different directions of a bidirectional client LSP can be bound to different component links.
FR#15解决方案应为客户层提供一种方法，以表明客户LSP绑定到AMG内特定组件链路的要求。如果未行使此选项，则通过AMG承载的客户LSP可绑定到任何组件链路或与所有其他信号要求相匹配的组件链路集，双向客户端LSP的不同方向可以绑定到不同的组件链路。
FR#16 The solution MUST support a means for the client layer to indicate a requirement that for a specific co-routed bidirectional client LSP, both directions of the co-routed bidirectional client LSP MUST be bound to the same set of nodes.
FR#16该解决方案必须支持客户端层的一种方式，以表明对于特定的共路由双向客户端LSP，共路由双向客户端LSP的两个方向必须绑定到同一组节点的要求。
FR#17 A client LSP that is bound to a specific component link SHOULD NOT exceed the capacity of a single component link. This is inherent in the assumption that a network SHOULD NOT operate in a congested state if congestion is avoidable.
FR#17绑定到特定组件链路的客户端LSP不应超过单个组件链路的容量。这是一种固有的假设，即如果可以避免拥塞，则网络不应在拥塞状态下运行。
For some large bidirectional client LSPs, it may not be necessary (or possible due to the client LSP capacity) to bind the LSP to a common set of component links, but it may be necessary or desirable to constrain the path taken by the LSP to the same set of nodes in both directions. Without an entirely new and highly dynamic protocol, it is not feasible to constrain such a bidirectional client LSP from taking multiple paths and coordinating load balance on each side in order to keep both directions of flows within such an LSP on common paths.
对于一些大型双向客户端LSP，可能没有必要（或可能由于客户端LSP的容量）将LSP绑定到一组公共的组件链路，但是可能有必要或希望将LSP采用的路径约束到两个方向上的同一组节点。如果没有一个全新的、高度动态的协议，就不可能限制这样一个双向客户机LSP采用多条路径并协调每侧的负载平衡，以便将这样一个LSP内的流的两个方向保持在公共路径上。
Multipath load balancing attempts to keep traffic levels on all component links below congestion levels if possible and preferably well balanced. Load balancing is minimally disruptive (see the discussion below this section's list of requirements). The sensitivity to these minimal disruptions of traffic flows within a specific client LSP needs to be considered.
多路径负载平衡尝试将所有组件链路上的流量级别保持在拥塞级别以下（如果可能），并且最好保持良好平衡。负载平衡的破坏性最小（请参阅本节需求列表下面的讨论）。需要考虑对特定客户端LSP内的这些最小流量中断的敏感性。
FR#18 The solution SHALL provide a means for the client layer to indicate a requirement that a specific client LSP MUST NOT be split across multiple component links.
FR#18解决方案应为客户端层提供一种方法，以表明特定客户端LSP不得跨多个组件链路拆分的要求。
FR#19 The solution SHALL provide a means local to a node that automatically distributes flows across the component links in the AMG such that performance objectives are met, as described in the prior requirements in Section 3.3.
FR#19该解决方案应提供一种节点本地方式，该节点可自动在AMG中的组件链路上分配流量，从而满足第3.3节先前要求中所述的性能目标。
FR#20 The solution SHALL measure traffic flows or groups of traffic flows and dynamically select the component link on which to place this traffic in order to balance the load so that no component link in the AMG between a pair of nodes is overloaded.
FR#20该解决方案应测量流量或流量组，并动态选择用于放置该流量的组件链路，以平衡负载，从而使一对节点之间的AMG中没有组件链路过载。
FR#21 When a traffic flow is moved from one component link to another in the same AMG between a set of nodes, it MUST be done so in a minimally disruptive manner.
FR#21当流量在一组节点之间以相同的AMG从一个组件链路移动到另一个组件链路时，必须以最小的中断方式进行。
FR#22 Load balancing MAY be used during sustained low-traffic periods to reduce the number of active component links for the purpose of power reduction.
FR#22负载平衡可在持续低流量期间使用，以减少有源组件链路的数量，从而降低功率。
FR#23 The solution SHALL provide a means for the client layer to indicate a requirement that a specific client LSP contains traffic whose frequency of component link change due to load balancing needs to be bounded by a specific value. The solution MUST provide a means to bound the frequency of a component link change due to load balancing for subsets of traffic flow on AMGs.
FR#23解决方案应为客户端层提供一种方法，以表明特定客户端LSP包含因负载平衡导致组件链路更改频率需要限定在特定值范围内的流量的要求。该解决方案必须提供一种方法来限制由于AMG上流量子集的负载平衡而导致的组件链路更改的频率。
FR#24 The solution SHALL provide a means to distribute traffic flows from a single client LSP across multiple component links to handle at least the case where the traffic carried in a client LSP exceeds that of any component link in the AMG.
FR#24该解决方案应提供一种将来自单个客户端LSP的流量分布到多个组件链路的方法，以至少处理客户端LSP中承载的流量超过AMG中任何组件链路的流量的情况。
FR#25 The solution SHOULD support the use case where an AMG itself is a component link for a higher order AMG. For example, an AMG comprised of MPLS-TP bidirectional tunnels viewed as logical links could then be used as a component link in yet another AMG that connects MPLS routers.
FR#25解决方案应支持AMG本身是高阶AMG组件链路的用例。例如，由MPLS-TP双向隧道组成的AMG被视为逻辑链路，然后可在连接MPLS路由器的另一个AMG中用作组件链路。
FR#26 If the total demand offered by traffic flows exceeds the capacity of the AMG, the solution SHOULD define a means to cause some client LSPs to move to an alternate set of paths that are not congested. These "preempted LSPs" may not be restored if there is no uncongested path in the network.
FR#26如果交通流提供的总需求超过AMG的容量，则解决方案应定义一种方法，使一些客户端LSP移动到一组不拥挤的备用路径。如果网络中没有未占用的路径，这些“抢占LSP”可能无法恢复。
A minimally disruptive change implies that as little disruption as is practical occurs. Such a change can be achieved with zero packet loss. A delay discontinuity may occur, which is considered to be a minimally disruptive event for most services if this type of event is sufficiently rare. A delay discontinuity is an example of a minimally disruptive behavior corresponding to current techniques.
破坏性最小的变化意味着尽可能少的破坏发生。这种改变可以在零分组丢失的情况下实现。可能发生延迟中断，如果此类事件足够罕见，则对于大多数服务而言，这被认为是最小的中断事件。延迟不连续性是与当前技术相对应的最小破坏行为的示例。
A delay discontinuity is an isolated event that may greatly exceed the normal delay variation (jitter). A delay discontinuity has the following effect. When a flow is moved from a current link to a target link with lower latency, reordering can occur. When a flow is moved from a current link to a target link with a higher latency, a time gap can occur. Some flows (e.g., timing distribution and PW circuit emulation) are quite sensitive to these effects. A delay discontinuity can also cause a jitter buffer underrun or overrun, affecting user experience in real-time voice services (causing an audible click). These sensitivities may be specified in a performance objective.
延迟不连续性是一个可能大大超过正常延迟变化（抖动）的孤立事件。延迟不连续性具有以下影响。当流从当前链接移动到延迟较低的目标链接时，可能会发生重新排序。当流从当前链接移动到延迟更高的目标链接时，可能会出现时间间隔。一些流（例如，定时分布和PW电路仿真）对这些影响非常敏感。延迟中断还可能导致抖动缓冲区不足或溢出，从而影响实时语音服务中的用户体验（导致听到咔哒声）。这些敏感性可在性能目标中规定。
As with any load-balancing change, a change initiated for the purpose of power reduction may be minimally disruptive. Typically, the disruption is limited to a change in delay characteristics and the potential for a very brief period with traffic reordering. When
与任何负载平衡更改一样，为降低功耗而启动的更改可能会造成最小程度的中断。通常，中断仅限于延迟特性的变化和流量重新排序后很短时间内的可能性。什么时候
configuring a network for power reduction, the network operator should weigh the benefit of power reduction against the disadvantage of a minimal disruption.
配置网络以降低功耗时，网络运营商应权衡功耗降低的好处和中断最小化的缺点。
This section defines requirements for protocol specifications used to meet the functional requirements specified in Section 3.
本节定义了用于满足第3节规定功能要求的协议规范要求。
GR#1 The solution SHOULD extend existing protocols wherever possible, developing a new protocol only where doing so adds a significant set of capabilities.
GR#1解决方案应尽可能扩展现有协议，仅在这样做增加了一组重要功能的情况下才开发新协议。
GR#2 A solution SHOULD extend LDP capabilities to meet functional requirements. This MUST be accomplished without defining LDP Traffic Engineering (TE) methods as decided in [RFC3468].
GR#2解决方案应扩展LDP功能以满足功能需求。这必须在不定义[RFC3468]中确定的LDP流量工程（TE）方法的情况下完成。
GR#3 Coexistence of LDP- and RSVP-TE-signaled LSPs MUST be supported on an AMG. Function requirements SHOULD, where possible, be accommodated in a manner that supports LDP-signaled LSP, RSVP-signaled LSP, and LSP setup using management plane mechanisms.
GR#3 AMG上必须支持LDP和RSVP TE信号LSP共存。功能需求应尽可能以支持LDP信号LSP、RSVP信号LSP和使用管理平面机制的LSP设置的方式满足。
GR#4 When the nodes connected via an AMG are in the same routing domain, the solution MAY define extensions to the IGP.
GR#4当通过AMG连接的节点位于同一路由域中时，该解决方案可以定义IGP的扩展。
GR#5 When the nodes are connected via an AMG are in different MPLS network topologies, the solution SHALL NOT rely on extensions to the IGP.
GR#5当通过AMG连接的节点处于不同的MPLS网络拓扑中时，解决方案不应依赖于IGP的扩展。
GR#6 The solution SHOULD support AMG IGP advertisement that results in convergence time better than that of advertising the individual component links. The solution SHALL be designed so that it represents the range of capabilities of the individual component links such that functional requirements are met, and it also minimizes the frequency of advertisement updates that may cause IGP convergence to occur.
GR#6该解决方案应支持AMG IGP广告，其结果是收敛时间优于单个组件链接广告。该解决方案的设计应确保其代表单个组件链路的能力范围，以满足功能要求，并将可能导致IGP收敛的广告更新频率降至最低。
Examples of advertisement-update-triggering events to be considered include: client LSP establishment/release, changes in component-link characteristics (e.g., latency and up/down state), and/or bandwidth utilization.
要考虑的广告更新触发事件的示例包括：客户端LSP建立/释放、组件链路特性的变化（例如，延迟和向上/向下状态）和/或带宽利用率。
GR#7 When a worst-case failure scenario occurs, the number of RSVP-TE client LSPs to be resignaled will cause a period of unavailability as perceived by users. The resignaling time of the solution MUST support protocol mechanisms meeting existing provider performance objectives for the duration of unavailability without significantly relaxing those existing performance objectives for the same network or for networks with similar topology. For example, the processing load due to IGP readvertisement MUST NOT increase significantly, and the resignaling time of the solution MUST NOT increase significantly as compared with current methods.
GR#7当发生最坏情况下的故障场景时，要重新指定的RSVP-TE客户端LSP的数量将导致用户认为的一段不可用期。解决方案的重新签名时间必须支持在不可用期间满足现有提供商性能目标的协议机制，而不会显著降低相同网络或具有类似拓扑结构的网络的现有性能目标。例如，与当前方法相比，IGP读取引起的处理负载不得显著增加，且溶液的重新签名时间不得显著增加。
MR#1 The Management Plane MUST support polling of the status and configuration of an AMG and its individual component links and support notification of status change.
MR#1管理平面必须支持对AMG及其各个组件链接的状态和配置进行轮询，并支持状态更改通知。
MR#2 The Management Plane MUST be able to activate or deactivate any component link in an AMG in order to facilitate operation maintenance tasks. The routers at each end of an AMG MUST redistribute traffic to move traffic from a deactivated link to other component links based on the traffic flow TE criteria.
MR#2管理平面必须能够激活或停用AMG中的任何组件链接，以便于操作维护任务。AMG两端的路由器必须重新分配流量，以便根据流量流量标准将流量从停用链路移动到其他组件链路。
MR#3 The Management Plane MUST be able to configure a client LSP over an AMG and be able to select a component link for the client LSP.
MR#3管理平面必须能够通过AMG配置客户端LSP，并能够为客户端LSP选择组件链接。
MR#4 The Management Plane MUST be able to trace which component link a client LSP is assigned to and monitor individual component link and AMG performance.
MR#4管理平面必须能够跟踪客户端LSP分配给哪个组件链路，并监控单个组件链路和AMG性能。
MR#5 The Management Plane MUST be able to verify connectivity over each individual component link within an AMG.
MR#5管理平面必须能够验证AMG内每个单独组件链路的连通性。
MR#6 Component link fault notification MUST be sent to the management plane.
MR#6组件链路故障通知必须发送到管理平面。
MR#7 AMG fault notification MUST be sent to the management plane and MUST be distributed via a link state message in the IGP.
MR#7 AMG故障通知必须发送到管理平面，并且必须通过IGP中的链路状态消息分发。
MR#8 The Management Plane SHOULD provide the means for an operator to initiate an optimization process.
MR#8管理层应为运营商提供启动优化流程的手段。
MR#9 An operator-initiated optimization MUST be performed in a minimally disruptive manner, as described in Section 3.5.
MR#9操作员发起的优化必须以最小破坏性的方式进行，如第3.5节所述。
Frederic Jounay of France Telecom and Yuji Kamite of NTT Communications Corporation coauthored a version of this document.
法国电信公司的Frederic Jounay和NTT通信公司的Yuji Kamite共同编写了本文件的一个版本。
A rewrite of this document occurred after the IETF 77 meeting. Dimitri Papadimitriou, Lou Berger, Tony Li, the former WG Chairs John Scuder and Alex Zinin, the current WG Chair Alia Atlas, and others provided valuable guidance prior to and at the IETF 77 RTGWG meeting.
IETF 77会议后，对本文件进行了重写。Dimitri Papadimitriou、Lou Berger、Tony Li、前工作组主席John Scuder和Alex Zinin、现任工作组主席Alia Atlas以及其他人在IETF 77 RTGWG会议之前和会议上提供了宝贵的指导。
Tony Li and John Drake have made numerous valuable comments on the RTGWG mailing list that are reflected in versions following the IETF 77 meeting.
Tony Li和John Drake对RTGWG邮件列表发表了许多有价值的评论，这些评论反映在IETF 77会议之后的版本中。
Iftekhar Hussain and Kireeti Kompella made comments on the RTGWG mailing list after the IETF 82 meeting that identified a new requirement. Iftekhar Hussain made numerous valuable comments on the RTGWG mailing list that resulted in improvements to the document's clarity.
Iftekhar Hussain和Kireeti Kompella在IETF 82会议后对RTGWG邮件列表发表了意见，确定了新的要求。Iftekhar Hussain对RTGWG邮件列表发表了许多有价值的评论，从而提高了文件的清晰度。
In the interest of full disclosure of affiliation and in the interest of acknowledging sponsorship, past affiliations of authors are noted here. Much of the work done by Ning So and Andrew Malis occurred while they were at Verizon. Much of the work done by Curtis Villamizar occurred while he was at Infinera.
为了充分披露所属关系和承认赞助关系，此处注明了作者过去的所属关系。Ning So和Andrew Malis所做的大部分工作都是在Verizon期间完成的。柯蒂斯·维拉米扎所做的大部分工作都发生在他在英菲拉的时候。
Tom Yu and Francis Dupont provided the SecDir and GenArt reviews, respectively. Both reviews provided useful comments. The current wording of the security section is based on suggested wording from Tom Yu. Lou Berger provided the RtgDir review, which resulted in the document being renamed and the substantial clarification of terminology and document wording, particularly in the Abstract, Introduction, and Definitions sections.
Tom Yu和Francis Dupont分别提供了SecDir和GenArt评论。两次审查都提出了有益的意见。安全部分的当前措辞基于Tom Yu的建议措辞。Lou Berger提供了RtgDir审查，结果对文件进行了重命名，并对术语和文件措辞进行了实质性澄清，特别是在摘要、引言和定义部分。
The security considerations for MPLS/GMPLS and for MPLS-TP are documented in [RFC5920] and [RFC6941]. This document does not impact the security of MPLS, GMPLS, or MPLS-TP.
MPLS/GMPLS和MPLS-TP的安全注意事项记录在[RFC5920]和[RFC6941]中。本文件不影响MPLS、GMPLS或MPLS-TP的安全性。
The additional information that this document requires does not provide significant additional value to an attacker beyond the information already typically available from attacking a routing or signaling protocol. If the requirements of this document are met by extending an existing routing or signaling protocol, the security considerations of the protocol being extended apply. If the requirements of this document are met by specifying a new protocol, the security considerations of that new protocol should include an
除了攻击路由或信令协议时通常已获得的信息外，本文档所需的附加信息不会为攻击者提供显著的附加价值。如果通过扩展现有路由或信令协议来满足本文件的要求，则扩展协议的安全考虑因素适用。如果通过指定新协议满足本文件的要求，则新协议的安全考虑应包括
evaluation of what level of protection is required by the additional information specified in this document, such as data origin authentication.
评估本文件中规定的附加信息（如数据源身份验证）所需的保护级别。
[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月。
[FRAMEWORK] Ning, S., McDysan, D., Osborne, E., Yong, L., and C. Villamizar, "Advanced Multipath Framework in MPLS", Work in Progress, July 2013.
[框架]Ning，S.，McDysan，D.，Osborne，E.，Yong，L.，和C.Villamizar，“MPLS中的高级多路径框架”，正在进行的工作，2013年7月。
[IEEE-802.1AX] IEEE Standards Association, "IEEE Std 802.1AX-2008 IEEE Standard for Local and Metropolitan Area Networks - Link Aggregation", 2006, <http://standards.ieee.org/getieee802/ download/802.1AX-2008.pdf>.
[IEEE-802.1AX]IEEE标准协会，“IEEE标准802.1AX-2008 IEEE局域网和城域网标准-链路聚合”，2006年<http://standards.ieee.org/getieee802/ 下载/802.1AX-2008.pdf>。
[ITU-T.G.800] ITU-T, "Unified functional architecture of transport networks", ITU-T Recommendation G.800, February 2012, <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，2012年2月<http://www.itu.int/rec/T-REC-G/ 建议.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月。
[RFC3468] Andersson, L. and G. Swallow, "The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols", RFC 3468, February 2003.
[RFC3468]Andersson，L.和G.Swallow，“多协议标签交换（MPLS）工作组关于MPLS信令协议的决定”，RFC 3468，2003年2月。
[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月。
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920]方，L，“MPLS和GMPLS网络的安全框架”，RFC 5920，2010年7月。
[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月。
[USE-CASES] Ning, S., Malis, A., McDysan, D., Yong, L., and C. Villamizar, "Advanced Multipath Use Cases and Design Considerations", Work in Progress, November 2013.
[用例]Ning，S.，Malis，A.，McDysan，D.，Yong，L.，和C.Villamizar，“高级多路径用例和设计考虑”，正在进行的工作，2013年11月。
Authors' Addresses
作者地址
Curtis Villamizar (editor) OCCNC, LLC
柯蒂斯·维拉米扎（编辑）OCCNC有限责任公司
EMail: curtis@occnc.com
EMail: curtis@occnc.com
Dave McDysan (editor) Verizon 22001 Loudoun County PKWY Ashburn, VA 20147 USA
Dave McDysan（编辑）美国弗吉尼亚州阿什本市劳顿县Verizon 22001邮编：20147
EMail: dave.mcdysan@verizon.com
EMail: dave.mcdysan@verizon.com
So Ning Tata Communications
苏宁塔塔通讯
EMail: ning.so@tatacommunications.com
EMail: ning.so@tatacommunications.com
Andrew G. Malis Huawei Technologies 2330 Central Expressway Santa Clara, CA 95050 USA
美国加利福尼亚州圣克拉拉中央高速公路2330号安德鲁·G·马里斯华为技术公司，邮编95050
EMail: agmalis@gmail.com
EMail: agmalis@gmail.com
Lucy Yong Huawei USA 5340 Legacy Dr. Plano, TX 75025 USA
Lucy Yong华为美国5340 Legacy Plano博士，德克萨斯州75025
Phone: +1 469-277-5837
EMail: lucy.yong@huawei.com
Phone: +1 469-277-5837
EMail: lucy.yong@huawei.com