Internet Engineering Task Force (IETF) K. Raza
Request for Comments: 7473 S. Boutros
Category: Standards Track Cisco Systems, Inc.
ISSN: 2070-1721 March 2015
Internet Engineering Task Force (IETF) K. Raza
Request for Comments: 7473 S. Boutros
Category: Standards Track Cisco Systems, Inc.
ISSN: 2070-1721 March 2015
Controlling State Advertisements of Non-negotiated LDP Applications
控制非协商LDP应用程序的状态广告
Abstract
摘要
There is no capability negotiation done for Label Distribution Protocol (LDP) applications that set up Label Switched Paths (LSPs) for IP prefixes or that signal point-to-point (P2P) Pseudowires (PWs) for Layer 2 Virtual Private Networks (L2VPNs). When an LDP session comes up, an LDP speaker may unnecessarily advertise its local state for such LDP applications even when the peer session is established for some other applications like Multipoint LDP (mLDP) or the Inter-Chassis Communication Protocol (ICCP). This document defines a solution by which an LDP speaker announces to its peer its disinterest in such non-negotiated applications, thus disabling the unnecessary advertisement of corresponding application state, which would have otherwise been advertised over the established LDP session.
对于为IP前缀设置标签交换路径（LSP）或为第二层虚拟专用网络（L2VPN）设置信号点对点（P2P）伪线（PWs）的标签分发协议（LDP）应用程序，没有进行能力协商。当出现LDP会话时，即使为诸如多点LDP（mLDP）或机箱间通信协议（ICCP）等一些其他应用建立对等会话，LDP演讲者也可能不必要地为此类LDP应用宣传其本地状态。本文件定义了一种解决方案，通过该解决方案，LDP演讲者向其对等方宣布其对此类非协商应用不感兴趣，从而禁止不必要的相应应用程序状态广告，否则将在已建立的LDP会话上进行广告。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7473.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7473.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
3. Non-negotiated LDP Applications .................................4
3.1. Uninteresting State ........................................5
3.1.1. Prefix-LSPs .........................................5
3.1.2. P2P-PWs .............................................5
4. Controlling State Advertisement .................................5
4.1. State Advertisement Control Capability .....................6
4.2. Capabilities Procedures ....................................8
4.2.1. State Control Capability in an
Initialization Message ..............................9
4.2.2. State Control Capability in a Capability Message ....9
5. Applicability Statement .........................................9
6. Operational Examples ...........................................11
6.1. Disabling Prefix-LSPs and P2P-PWs on an ICCP Session ......11
6.2. Disabling Prefix-LSPs on a L2VPN/PW tLDP Session ..........11
6.3. Disabling Prefix-LSPs Dynamically on an
Established LDP Session ...................................12
6.4. Disabling Prefix-LSPs on an mLDP-only Session .............12
6.5. Disabling IPv4 or IPv6 Prefix-LSPs on a Dual-Stack LSR ....12
7. Security Considerations ........................................13
8. IANA Considerations ............................................13
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................14
Acknowledgments ...................................................15
Authors' Addresses ................................................15
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
3. Non-negotiated LDP Applications .................................4
3.1. Uninteresting State ........................................5
3.1.1. Prefix-LSPs .........................................5
3.1.2. P2P-PWs .............................................5
4. Controlling State Advertisement .................................5
4.1. State Advertisement Control Capability .....................6
4.2. Capabilities Procedures ....................................8
4.2.1. State Control Capability in an
Initialization Message ..............................9
4.2.2. State Control Capability in a Capability Message ....9
5. Applicability Statement .........................................9
6. Operational Examples ...........................................11
6.1. Disabling Prefix-LSPs and P2P-PWs on an ICCP Session ......11
6.2. Disabling Prefix-LSPs on a L2VPN/PW tLDP Session ..........11
6.3. Disabling Prefix-LSPs Dynamically on an
Established LDP Session ...................................12
6.4. Disabling Prefix-LSPs on an mLDP-only Session .............12
6.5. Disabling IPv4 or IPv6 Prefix-LSPs on a Dual-Stack LSR ....12
7. Security Considerations ........................................13
8. IANA Considerations ............................................13
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................14
Acknowledgments ...................................................15
Authors' Addresses ................................................15
The LDP Capabilities specification [RFC5561] introduced a mechanism to negotiate LDP capabilities for a given feature between peer Label Switching Routers (LSRs). The capability mechanism ensures that no unnecessary state is exchanged between peer LSRs unless the corresponding feature capability is successfully negotiated between the peers.
LDP能力规范[RFC5561]引入了一种机制，用于在对等标签交换路由器（LSR）之间协商给定功能的LDP能力。能力机制确保对等LSR之间不会交换不必要的状态，除非对等LSR之间成功协商了相应的功能能力。
Newly defined LDP features and applications, such as Typed Wildcard Forwarding Equivalence Class (FEC) [RFC5918], Inter-Chassis Communication Protocol [RFC7275], mLDP [RFC6388], and L2VPN Point-to-multipoint (P2MP) PW [RFC7338] make use of LDP capabilities framework for their feature negotiation. However, the earlier LDP applications allowed LDP speakers to exchange application state without any capability negotiation. This, in turn, results in the unnecessary advertisement of state when a given application is not enabled on one of the LDP speakers. These earlier LDP applications include (i) application to establish LSPs for IP unicast prefixes and (ii) application to signal when L2VPN P2P PW [RFC4447] [RFC4762]. For example, when bringing up and using an LDP peer session with a remote Provider Edge (PE) LSR for purely ICCP-signaling reasons, an LDP speaker may unnecessarily advertise labels for IP (unicast) prefixes to this ICCP-related LDP peer.
新定义的LDP功能和应用程序，例如类型化通配符转发等价类（FEC）[RFC5918]、机箱间通信协议[RFC7275]、mLDP[RFC6388]和L2VPN点对多点（P2MP）PW[RFC7338]利用LDP功能框架进行功能协商。然而，早期的LDP应用允许LDP演讲者在没有任何能力协商的情况下交换应用状态。这反过来导致当给定的应用未在LDP扬声器之一上启用时，不必要的状态广告。这些早期的LDP应用包括（i）为IP单播前缀建立LSP的应用和（ii）在L2VPN P2P PW[RFC4447][RFC4762]时发送信号的应用。例如，当出于纯粹的ICCP信令原因而启动并使用具有远程提供商边缘（PE）LSR的LDP对等会话时，LDP说话者可能不必要地向该ICCP相关LDP对等方播发IP（单播）前缀的标签。
Another example of unnecessary state advertisement can be cited when LDP is to be deployed in an IP dual-stack environment. For instance, an LSR that is locally enabled to set up LSPs for both IPv4 and IPv6 prefixes may advertise (address and label) bindings for both IPv4 and IPv6 address families towards an LDP peer that is interested in IPv4 bindings only. In this case, the advertisement of IPv6 bindings to the peer is unnecessary, as well as wasteful, from the point of view of LSR memory/CPU and network resource consumption.
当要在IP双栈环境中部署LDP时，可以引用不必要的状态公告的另一个示例。例如，本地启用为IPv4和IPv6前缀设置LSP的LSR可能会向只对IPv4绑定感兴趣的LDP对等方公布IPv4和IPv6地址族的绑定（地址和标签）。在这种情况下，从LSR内存/CPU和网络资源消耗的角度来看，向对等方发布IPv6绑定是不必要的，也是浪费的。
To avoid this unnecessary state advertisement and exchange, currently an operator is typically required to configure and define filtering policies on the LSR, which introduces unnecessary operational overhead and complexity for such deployments.
为了避免这种不必要的状态公布和交换，目前通常需要运营商在LSR上配置和定义过滤策略，这会为此类部署带来不必要的操作开销和复杂性。
This document defines a solution based on LDP Capabilities [RFC5561] by which an LDP speaker may announce to its peer(s) its disinterest (or non-support) for state to set up IP Prefix LSPs and/or to signal L2VPN P2P PW at the time of session establishment. This capability helps in avoiding unnecessary state advertisement for such feature applications. This document also states the mechanics to dynamically
本文件定义了一种基于LDP能力[RFC5561]的解决方案，通过该方案，LDP演讲者可以向其对等方宣布其不感兴趣（或不支持）国家在会话建立时设置IP前缀LSP和/或向L2VPN P2P PW发送信号。此功能有助于避免此类功能应用程序不必要的状态公告。本文件还说明了动态调整的机制
disable or enable the state advertisement for such applications during the session lifetime. The "uninteresting" state of an application depends on the type of application and is described later in Section 3.1.
在会话生存期内禁用或启用此类应用程序的状态播发。应用程序的“无趣”状态取决于应用程序的类型，稍后将在第3.1节中描述。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The term "IP" in this document refers to both IPv4 and IPv6 unicast address families.
本文档中的术语“IP”指IPv4和IPv6单播地址系列。
For the applications that existed prior to the definition of the LDP Capabilities framework [RFC5561], an LDP speaker typically advertises, without waiting for any capabilities exchange and negotiation, its corresponding application state to its peers after the session establishment. These early LDP applications include:
对于在定义LDP能力框架[RFC5561]之前存在的应用程序，LDP演讲者通常在会话建立后，在不等待任何能力交换和协商的情况下向其对等方宣传其相应的应用程序状态。这些早期LDP应用包括：
o IPv4/IPv6 Prefix LSPs Setup o L2VPN P2P FEC 128 and FEC 129 PWs Signaling
o L2VPN P2P FEC 128和FEC 129 PWs信令的IPv4/IPv6前缀LSP设置
The rest of This document uses the following shorthand terms for these earlier LDP applications:
本文件其余部分对这些早期LDP应用使用了以下简写术语：
o "Prefix-LSPs": Refers to an application that sets up LDP LSPs corresponding to IP routes/prefixes by advertising label bindings for Prefix FEC (as defined in RFC 5036).
o “前缀LSP”：指通过为前缀FEC（如RFC 5036中所定义）发布标签绑定来设置与IP路由/前缀相对应的LDP LSP的应用程序。
o "P2P-PWs": Refers to an application that signals FEC 128 and/or FEC 129 L2VPN P2P PWs using LDP (as defined in RFC 4447).
o “P2P PWs”：指使用LDP（如RFC 4447中所定义）向FEC 128和/或FEC 129 L2VPN P2P PWs发送信号的应用程序。
To disable unnecessary state exchange for such LDP applications over an established LDP session, a new capability is being introduced in this document. This new capability controls the advertisement of application state and enables an LDP speaker to notify its peer its disinterest in the state of one or more of these "Non-negotiated" LDP applications at the time of session establishment. Upon receipt of such a capability, the receiving LDP speaker, if supporting the capability, disables the advertisement of the state related to the application towards the sender of the capability. This new capability can also be sent later in a Capability message either to disable a previously enabled application's state advertisement or to enable a previously disabled application's state advertisement.
为了在已建立的LDP会话上禁用此类LDP应用程序的不必要状态交换，本文引入了一种新功能。这种新能力控制应用状态的广告，并使LDP演讲者能够在会话建立时通知其对等方其对一个或多个这些“非协商”LDP应用的状态不感兴趣。在接收到这样的能力时，接收LDP扬声器如果支持该能力，则禁用向该能力的发送方发布与该应用相关的状态。此新功能也可以稍后在功能消息中发送，以禁用以前启用的应用程序的状态播发或启用以前禁用的应用程序的状态播发。
A uninteresting state of a non-negotiated LDP application:
非协商LDP应用程序的无趣状态：
- is the application state that is of no interest to an LSR and need not be advertised to the LSR;
- 是LSR不感兴趣且无需向LSR通告的应用程序状态；
- need not be advertised in any of the LDP protocol messages;
- 不需要在任何LDP协议消息中公布；
- is dependent on application type and specified accordingly.
- 取决于应用程序类型，并相应指定。
For the Prefix-LSP application type, the uninteresting state refers to any state related to IP Prefix FEC (such as FEC label bindings, LDP Status). This document, however, does not classify IP address bindings (advertised via ADDRESS message) as a uninteresting state and allows the advertisement of IP address bindings. The reason for this allowance is that an LSR typically uses peer IP address(es) to map an IP routing next hop to an LDP peer in order to implement its control plane procedures. For example, mLDP [RFC6388] uses a peer's IP address(es) to determine its upstream LSR to reach the Root node as well as to select the forwarding interface towards its downstream LSR. Hence, in an mLDP-only network, while it is desirable to disable advertisement of label bindings for IP (unicast) prefixes, disabling advertisement of IP address bindings will break mLDP functionality. Similarly, other LDP applications may also depend on learnt peer IP addresses; hence, this document does not put IP address binding into a uninteresting state category to facilitate such LDP applications.
对于前缀LSP应用程序类型，无趣状态指与IP前缀FEC相关的任何状态（例如FEC标签绑定、LDP状态）。但是，本文档并未将IP地址绑定（通过地址消息公布）归类为无趣状态，并允许公布IP地址绑定。这种允许的原因是，LSR通常使用对等IP地址（es）将IP路由下一跳映射到LDP对等，以实现其控制平面过程。例如，mLDP[RFC6388]使用对等方的IP地址来确定其上游LSR以到达根节点，以及选择朝向其下游LSR的转发接口。因此，在仅mLDP的网络中，虽然需要禁用IP（单播）前缀标签绑定的播发，但禁用IP地址绑定的播发将破坏mLDP功能。类似地，其他LDP应用也可能依赖于学习的对等IP地址；因此，本文档不会将IP地址绑定置于无趣状态类别中，以方便此类LDP应用。
For the P2P-PW application type, the uninteresting state refers to any state related to P2P PW FEC 128 / FEC 129 (such as FEC label bindings, Media Access Control (MAC) address withdrawal, and LDP PW Status). In this document, the term "state" will mean to refer to the "uninteresting state" for an application, as defined in this section.
对于P2P-PW应用程序类型，无趣状态指与P2P-PW FEC 128/FEC 129相关的任何状态（例如FEC标签绑定、媒体访问控制（MAC）地址撤回和LDP-PW状态）。在本文件中，术语“状态”是指本节中定义的应用程序的“无趣状态”。
To control advertisement of uninteresting state related to non-negotiated LDP applications defined in Section 3, a new capability TLV is defined as follows.
为了控制与第3节中定义的非协商LDP应用相关的无趣状态的播发，定义了一种新的能力TLV，如下所示。
The "State Advertisement Control Capability" is a new Capability Parameter TLV defined in accordance with Section 3 of LDP Capabilities specification [RFC5561]. The format of this new TLV is as follows:
“状态广告控制能力”是根据LDP能力规范[RFC5561]第3节定义的新能力参数TLV。新TLV的格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| SAC Capability (0x050D) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | |
+-+-+-+-+-+-+-+-+
| |
~ State Advertisement Control Element(s) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| SAC Capability (0x050D) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | |
+-+-+-+-+-+-+-+-+
| |
~ State Advertisement Control Element(s) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format of a "State Advertisement Control Capability" TLV
图1：“状态广告控制能力”TLV的格式
The value of the U-bit for the TLV MUST be set to 1 so that a receiver MUST silently ignore this TLV if unknown to it, and continue processing the rest of the message. Whereas, The value of F-bit MUST be set to 0. Once advertised, this capability cannot be withdrawn; thus, the S-bit MUST be set to 1 in an Initialization and Capability message.
TLV的U位值必须设置为1，以便接收方在未知时必须悄悄忽略此TLV，并继续处理消息的其余部分。然而，F位的值必须设置为0。一旦公布，这种能力就不能撤回；因此，在初始化和功能消息中，S位必须设置为1。
The capability data associated with this State Advertisement Control (SAC) Capability TLV is one or more State Advertisement Control Elements, where each element indicates enabling/disabling of advertisement of uninteresting state for a given application. The format of a SAC Element is defined as follows:
与该状态播发控制（SAC）能力TLV相关联的能力数据是一个或多个状态播发控制元素，其中每个元素指示为给定应用启用/禁用无兴趣状态的播发。SAC元素的格式定义如下：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|D| App |Unused |
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|D| App |Unused |
+-+-+-+-+-+-+-+-+
Figure 2: Format of "State Advertisement Control Element"
图2：“状态广告控制元素”的格式
Where: D-bit: Controls the advertisement of the state specified in the "App" field: 1: Disable state advertisement 0: Enable state advertisement When sent in an Initialization message, the D-bit MUST be set to 1.
其中：D位：控制“应用”字段中指定状态的播发：1：禁用状态播发0：启用状态播发在初始化消息中发送时，D位必须设置为1。
App: Defines the legacy application type whose state advertisement is to be controlled. The value of this field is defined as follows:
应用：定义要控制其状态播发的旧应用程序类型。该字段的值定义如下：
1: IPv4 Prefix-LSPs (LSPs for IPv4 prefixes) 2: IPv6 Prefix-LSPs (LSPs for IPv6 prefixes) 3: FEC 128 P2P-PW (L2VPN PWid FEC signaling) 4: FEC 129 P2P-PW (L2VPN Generalized PWid FEC signaling)
1:IPv4前缀LSP（用于IPv4前缀的LSP）2:IPv6前缀LSP（用于IPv6前缀的LSP）3:FEC 128 P2P-PW（L2VPN PWid FEC信令）4:FEC 129 P2P-PW（L2VPN广义PWid FEC信令）
Any other value in this field MUST be treated as an error.
此字段中的任何其他值都必须视为错误。
Unused: Must Be Zero (MBZ) on transmit and ignored on receipt.
未使用：传输时必须为零（MBZ），接收时忽略。
The "Length" field of the SAC Capability TLV (in octets) is computed as follows:
SAC能力TLV的“长度”字段（以八位字节为单位）计算如下：
Length (in octets) = 1 + number of SAC elements
长度（八位字节）=1+SAC元素数
For example, if there are two SAC elements present, then the "Length" field is set to 3 octets. A receiver of this capability TLV can deduce the number of elements present in the TLV by using the "Length" field.
例如，如果存在两个SAC元素，“长度”字段设置为3个八位字节。具有此功能的TLV接收器可以使用“长度”字段推断TLV中存在的元素数。
This document uses the term "element" to refer to a SAC Element.
本文件使用术语“元素”来指SAC元素。
As described earlier, the SAC Capability TLV MAY be included by an LDP speaker in an Initialization message to signal to its peer LSR that state exchange for one or more applications needs to be disabled on the given peer session. This TLV can also be sent later in a Capability message to selectively enable or disable these applications. If there is more than one element present in a SAC Capability TLV, the elements MUST belong to distinct app types and the app type MUST NOT appear more than once. If a receiver receives such a malformed TLV, it SHOULD discard this TLV and continue processing the rest of the message. If an LSR receives a message with a SAC capability TLV containing an element with the "App" field set to a value other than defined above, the receiver MUST ignore and discard the element and continue processing the rest of the TLV.
如前所述，LDP扬声器可将SAC能力TLV包括在初始化消息中，以向其对等LSR发出信号，表示需要在给定对等会话上禁用一个或多个应用程序的状态交换。该TLV也可以稍后在功能消息中发送，以有选择地启用或禁用这些应用程序。如果SAC能力TLV中存在多个元素，则这些元素必须属于不同的应用程序类型，且应用程序类型不得出现多次。如果接收方接收到这种格式错误的TLV，则应丢弃此TLV并继续处理消息的其余部分。如果LSR接收到具有SAC能力TLV的消息，其中包含“App”字段设置为上述定义以外的值的元素，则接收器必须忽略并放弃该元素，并继续处理TLV的其余部分。
To control more than one application state, a sender LSR can either send a single capability TLV in a message with multiple elements present or send separate messages with a capability TLV specifying one or more elements. A receiving LSR, however, MUST treat each incoming capability TLV with an element corresponding to a given application type as an update to its existing policy for the given type.
要控制多个应用程序状态，发送方LSR可以在存在多个元素的消息中发送单个功能TLV，也可以发送单独的消息，其中功能TLV指定一个或多个元素。但是，接收LSR必须使用与给定应用程序类型对应的元素将每个传入功能TLV视为对给定类型的现有策略的更新。
To understand capability updates from an example, let us consider two LSRs, S (LDP speaker) and P (LDP peer), both of which support all the non-negotiated applications listed earlier. By default, these LSRs will advertise state for these applications, as configured, to their peer as soon as an LDP session is established. Now assume that P receives from S a SAC capability in an Initialization message with "IPv6 Prefix-LSPs" and "FEC 129 P2P-PW" applications disabled. This updates P's outbound policy towards S to advertise state related to only IPv4 Prefix-LSPs and FEC 128 P2P-PW applications. Later, P receives another capability update from S via a Capability message with "IPv6 Prefix-LSPs" enabled and "FEC 128 P2P-PWs" disabled. This results in P's outbound policy towards S to advertise both IPv4 and IPv6 Prefix-LSPs application state and disable both FEC 128 and FEC 129 P2P-PWs signaling. Finally, P receives another update from S via a Capability message that specifies to disable all four non-negotiated applications states, resulting in P outbound policy towards S to block/disable state for all these applications and only advertise state for any other application, as applicable.
为了理解一个例子中的能力更新，让我们考虑两个LSR，S（LDP扬声器）和P（LDP对等体），它们都支持前面列出的所有未协商的应用。默认情况下，一旦建立LDP会话，这些LSR将根据配置将这些应用程序的状态播发给它们的对等方。现在假设P从S接收到一条初始化消息中的SAC功能，其中禁用了“IPv6前缀LSP”和“FEC 129 P2P-PW”应用程序。这将更新P对s的出站策略，以便只公布与IPv4前缀LSP和FEC 128 P2P-PW应用程序相关的状态。稍后，P通过启用“IPv6前缀LSP”和禁用“FEC 128 P2P PWs”的功能消息从S接收另一个功能更新。这导致P对s的出站策略同时公布IPv4和IPv6前缀LSPs应用程序状态，并禁用FEC 128和FEC 129 P2P PWs信令。最后，P通过指定禁用所有四个非协商应用程序状态的功能消息从S接收另一个更新，从而导致P针对S的出站策略阻止/禁用所有这些应用程序的状态，并且仅公告任何其他应用程序的状态（如适用）。
The SAC capability conveys the desire of an LSR to disable the receipt of unwanted/unnecessary state from its LDP peer. This capability is unilateral and unidirectional in nature, and a receiving LSR is not required to send a similar capability TLV in an Initialization or Capability message towards the sender of this capability. This unilateral behavior conforms to the procedures defined in the Section 6 of LDP Capabilities [RFC5561].
SAC能力传达了LSR禁止从其LDP对等方接收不需要/不必要状态的愿望。该能力本质上是单向的，接收LSR不需要在初始化或能力消息中向该能力的发送方发送类似的能力TLV。这种单方面行为符合LDP能力[RFC5561]第6节中定义的程序。
After this capability is successfully negotiated (i.e., sent by an LSR and received/understood by its peer), then the receiving LSR MUST NOT advertise any state related to the disabled applications towards the capability-sending LSR until and unless these application states are explicitly enabled again via a capability update. Upon receipt of a capability update to disable an enabled application state during the lifetime of a session, the receiving LSR MUST also withdraw from the peer any previously advertised state corresponding to the disabled application.
在成功协商该能力之后（即，由LSR发送并由其对等方接收/理解），则接收LSR不得向发送LSR的能力通告与禁用的应用程序相关的任何状态，直到并且除非通过能力更新再次显式启用这些应用程序状态。在会话生存期内收到禁用已启用应用程序状态的能力更新后，接收LSR还必须从对等方撤回与已禁用应用程序对应的任何先前公布的状态。
If a receiving LDP speaker does not understand the SAC capability TLV, then it MUST respond to the sender with an "Unsupported TLV" notification as described in "LDP Capabilities" [RFC5561]. If a receiving LDP speaker does not understand or does not support an application specified in an application control element, it SHOULD silently ignore/skip such an element and continue processing rest of the TLV.
如果接收LDP扬声器不理解SAC能力TLV，则必须按照“LDP能力”[RFC5561]中的说明，以“不支持的TLV”通知响应发送方。如果接收LDP扬声器不理解或不支持在应用程序控制元素中指定的应用程序，则应默默忽略/跳过该元素，并继续处理TLV的其余部分。
The LDP Capabilities framework [RFC5561] dictates that the S-bit of the capability parameter in an Initialization message MUST be set to 1 and SHOULD be ignored on receipt.
LDP能力框架[RFC5561]规定初始化消息中能力参数的S位必须设置为1，并且在接收时应忽略。
An LDP speaker determines (e.g., via some local configuration or default policy) if it needs to disable Prefix-LSPs and/or P2P-PW applications with a peer LSR. If there is a need to disable, then the SAC TLV needs to be included in the Initialization message with respective SAC elements included with their D-bit set to 1.
LDP扬声器确定（例如，通过一些本地配置或默认策略）是否需要禁用前缀LSP和/或具有对等LSR的P2P-PW应用程序。如果需要禁用，则需要在初始化消息中包括SAC TLV，其D位设置为1时包括相应的SAC元素。
An LDP speaker that supports the SAC capability MUST interpret the capability TLV in a received Initialization message such that it disables the advertisement of the application state towards the capability sending LSR for Prefix-LSPs and/or P2P-PW applications if their SAC element's D-bit is set to 1.
支持SAC能力的LDP演讲者必须在接收到的初始化消息中解释能力TLV，以便在其SAC元素的D位设置为1时，其禁用向发送前缀LSP和/或P2P-PW应用的LSR的能力的应用程序状态的播发。
If the LDP peer supports "Dynamic Announcement Capability" [RFC5561], then an LDP speaker may send a SAC capability in a Capability message towards the peer. Once advertised, these capabilities cannot be withdrawn; hence, the S-bit of the TLV MUST be set to 1 when sent in a Capability message.
如果LDP对等方支持“动态公告能力”[RFC5561]，则LDP说话人可以在能力消息中向对等方发送SAC能力。一旦公布，这些能力就不能撤回；因此，在能力消息中发送时，TLV的S位必须设置为1。
An LDP speaker may decide to send this TLV towards an LDP peer if one or more of its Prefix-LSPs and/or P2P-PW applications get disabled, or if a previously disabled application gets enabled again. In this case, the LDP speaker constructs the TLV with appropriate SAC elements and sends the corresponding capability TLV in a Capability message.
如果LDP演讲者的一个或多个前缀LSP和/或P2P-PW应用程序被禁用，或者如果先前被禁用的应用程序再次被启用，则LDP演讲者可以决定向LDP对等方发送该TLV。在这种情况下，LDP说话人用适当的SAC元素构造TLV，并在能力消息中发送相应的能力TLV。
Upon receipt of this TLV in a Capability message, the receiving LDP speaker reacts in the same manner as it reacts upon the receipt of this TLV in an Initialization message. Additionally, the peer withdraws/advertises the application state to/from the capability-sending LDP speaker according to the capability update.
在能力消息中接收到此TLV时，接收LDP扬声器的反应方式与在初始化消息中接收到此TLV时的反应方式相同。此外，对等方根据能力更新向发送LDP扬声器的能力撤回/通告应用状态。
The procedures defined in this document may result in a disabling announcement of label bindings for IP Prefixes and/or P2P PW FECs and, hence, should be used with caution and discretion. This document recommends that this new SAC capability and its procedures SHOULD be enabled on an LSR only via a configuration knob. This knob could either be a global LDP knob or be implemented per LDP neighbor. Hence, it is recommended that an operator SHOULD enable this
本文档中定义的程序可能导致IP前缀和/或P2P PW FEC标签绑定的禁用公告，因此应谨慎使用。本文件建议仅通过配置旋钮在LSR上启用此新SAC功能及其程序。该旋钮可以是全局LDP旋钮，也可以是每个LDP邻居实现的。因此，建议操作员启用此功能
capability and its associated procedures on an LSR towards a neighbor only if it is known that such bindings advertisement and exchange with the neighbor is unnecessary and wasteful.
只有在知道与邻居的绑定和交换是不必要和浪费的情况下，LSR上针对邻居的功能及其相关过程。
The following table summarizes a non-exhaustive list of typical LDP session types on which this new SAC capability and its procedures are expected to be applied to disable advertisement of uninteresting state:
下表总结了典型LDP会话类型的非详尽列表，预计该新SAC功能及其程序将用于禁用无趣状态的播发：
+===============================+=================================+
| Session Type(s) | Uninteresting State |
+===============================+=================================+
| P2P-PW FEC 128-only | IP Prefix LSPs + P2P-PW FEC 129 |
|-------------------------------|---------------------------------|
| P2P-PW only (FEC 128/129) | IP Prefix LSPs |
|-------------------------------|---------------------------------|
| IPv4-only on a Dual-Stack LSR | IPv6 Prefix LSPs + P2P-PW |
|-------------------------------|---------------------------------|
| IPv6-only on a Dual-Stack LSR | IPv4 Prefix LSPs + P2P-PW |
|-------------------------------|---------------------------------|
| mLDP-only | IP Prefix LSPs + P2P-PW |
|-------------------------------|---------------------------------|
| ICCP-only | IP Prefix LSPs + P2P-PW |
+-------------------------------+---------------------------------+
+===============================+=================================+
| Session Type(s) | Uninteresting State |
+===============================+=================================+
| P2P-PW FEC 128-only | IP Prefix LSPs + P2P-PW FEC 129 |
|-------------------------------|---------------------------------|
| P2P-PW only (FEC 128/129) | IP Prefix LSPs |
|-------------------------------|---------------------------------|
| IPv4-only on a Dual-Stack LSR | IPv6 Prefix LSPs + P2P-PW |
|-------------------------------|---------------------------------|
| IPv6-only on a Dual-Stack LSR | IPv4 Prefix LSPs + P2P-PW |
|-------------------------------|---------------------------------|
| mLDP-only | IP Prefix LSPs + P2P-PW |
|-------------------------------|---------------------------------|
| ICCP-only | IP Prefix LSPs + P2P-PW |
+-------------------------------+---------------------------------+
It is to be noted that if an application state needs changing after session initialization (e.g., to enable a previously disabled application or to disable a previously enabled application), the procedures defined in this document expect LSR peers to support the LDP "Dynamic Announcement" Capability to announce the change in SAC capability via an LDP Capability message. However, if any of the peering LSRs do not support this capability, the alternate option is to force reset the LDP session to advertise the new SAC capability accordingly during the following session initialization.
需要注意的是，如果在会话初始化后需要更改应用程序状态（例如，启用以前禁用的应用程序或禁用以前启用的应用程序），则本文档中定义的过程期望LSR对等方支持LDP“动态公告”通过LDP能力消息宣布SAC能力变化的能力。但是，如果任何对等LSR不支持此功能，则替代选项是强制重置LDP会话，以便在接下来的会话初始化期间相应地公布新的SAC功能。
The following are some additional important points that an operator needs to consider regarding the applicability of this new capability and associated procedures defined in this document:
以下是操作员需要考虑的重要附加点，关于本文档中定义的新功能和相关程序的适用性：
- An operator SHOULD disable Prefix-LSP state on any Targeted LDP (tLDP) session that is established for ICCP-only and/or PW-only purposes.
- 操作员应在仅为ICCP和/或PW目的建立的任何目标LDP（tLDP）会话上禁用前缀LSP状态。
- An operator MUST NOT disable Prefix-LSP state on any tLDP session that is established for reasons related to remote Loop-Free Alternate (LFA) Fast Re-Route (FRR) [RLFA].
- 操作员不得在因远程无环路备用（LFA）快速重路由（FRR）[RLFA]相关原因而建立的任何tLDP会话上禁用前缀LSP状态。
- In a remote network that is LFA FRR [RLFA] enabled, it is RECOMMENDED not to disable Prefix-LSP state on a tLDP session even if the current session type is PW-only and/or ICCP-only. This is recommended because any remote/tLDP neighbor could potentially be picked as a remote LFA PQ node.
- 在启用LFA FRR[RLFA]的远程网络中，建议不要在tLDP会话上禁用前缀LSP状态，即使当前会话类型仅为PW和/或ICCP。建议这样做，因为任何远程/tLDP邻居都可能被选为远程LFA PQ节点。
- This capability SHOULD be enabled for Prefix-LSPs in the scenarios when it is desirable to disable (or enable) advertisement of "all" the prefix label bindings. For scenarios in which a "subset" of bindings need to be filtered, the existing filtering procedures pertaining to label binding announcement should be used.
- 当需要禁用（或启用）“所有”前缀标签绑定的播发时，应为前缀LSP启用此功能。对于需要过滤绑定“子集”的场景，应使用与标签绑定公告相关的现有过滤过程。
- Using label advertisement filtering policies in conjunction with the procedures defined in this document for Prefix-LSPs is allowed. In such cases, the label bindings will be announced as per the label filtering policy for the given neighbor when Prefix-LSP application is enabled.
- 允许将标签广告筛选策略与本文档中为前缀LSP定义的过程结合使用。在这种情况下，当启用前缀LSP应用程序时，将根据给定邻居的标签筛选策略宣布标签绑定。
Consider two PE routers, LSR1 and LSR2, that understand/support SAC capability TLV and have an established LDP session to exchange ICCP state related to dual-homed devices connected to these LSRs. Let us assume that both LSRs are provisioned not to exchange any state for Prefix-LSPs (IPv4/IPv6) and P2P-PWs (FEC 128/129) application.
考虑两个PE路由器，LSR1和LSR2，它理解/支持SAC能力TLV，并建立一个已建立的LDP会话来交换与连接到这些LSR的双归属设备相关的ICCP状态。假设这两个LSR都设置为不为前缀LSP（IPv4/IPv6）和P2P PWs（FEC 128/129）应用程序交换任何状态。
To indicate their disinterest in these applications, the LSRs will include a SAC capability TLV (with four SAC elements corresponding to these four applications with D-bit set to 1 for each one) in the Initialization message. Upon receipt of this TLV in Initialization message, the receiving LSR will disable the advertisement of IPv4/IPv6 label bindings, as well as P2P PW FEC 128/129 signaling, towards its peer after session establishment.
为了表明它们对这些应用不感兴趣，LSR将在初始化消息中包括SAC能力TLV（四个SAC元素对应于这四个应用，每个应用的D位设置为1）。在收到该TLV in初始化消息后，接收LSR将在会话建立后禁用IPv4/IPv6标签绑定以及P2P PW FEC 128/129信令向其对等方的播发。
Consider LSR1 and LSR2 have an established tLDP session for P2P-PW applications to exchange label bindings for FEC 128/129. Given that there is no need to exchange IP label bindings amongst the PE LSRs over a PW tLDP session in most typical deployments, let us assume that LSRs are provisioned to disable IPv4/IPv6 Prefix-LSPs application state on the given PW session.
考虑LSR1和LSR2有一个建立的用于PDP PW应用程序的TLDP会话来交换FEC 128/129的标签绑定。鉴于在大多数典型部署中，不需要通过PW tLDP会话在PE LSR之间交换IP标签绑定，让我们假设LSR被配置为在给定PW会话上禁用IPv4/IPv6前缀LSPs应用程序状态。
To indicate their disinterest in Prefix-LSP applications over a PW tLDP session, the LSRs will follow/apply the same procedures as described in previous section. As a result, only P2P-PW-related state will be exchanged between these LSRs over this tLDP session.
为了表明其对PW tLDP会话中前缀LSP应用的不感兴趣，LSR将遵循/应用上一节所述的相同程序。因此，在这个tLDP会话中，这些LSR之间只交换与P2P PW相关的状态。
Assume that LSRs from previous sections were initially provisioned to exchange both Prefix-LSP and P2P-PW state over the session between them and also support the "Dynamic Announcement" Capability of [RFC5561]. Now, assume that LSR1 is dynamically provisioned to disable (IPv4/IPv6) Prefix-LSPs over a tLDP session with LSR2. In this case, LSR1 will send a SAC capability TLV in a Capability message towards LSR2 with application control elements defined for IPv4 and IPv6 Prefix-LSPs with the D-bit set to 1. Upon receipt of this TLV, LSR2 will disable Prefix-LSPs application state(s) towards LSR1 and withdraw all previously advertised application state from LSR1. To withdraw label bindings from its peer, LSR2 MAY use a single Prefix FEC Typed Wildcard Label Withdraw message [RFC5918] if the peer supports the Typed Wildcard FEC capability.
假设前面章节中的LSR最初配置为在它们之间的会话中交换前缀LSP和P2P-PW状态，并且还支持[RFC5561]的“动态公告”功能。现在，假设LSR1被动态设置为在与LSR2的tLDP会话上禁用（IPv4/IPv6）前缀LSP。在这种情况下，LSR1将在能力消息中向LSR2发送SAC能力TLV，其中为IPv4和IPv6前缀LSP定义了应用程序控制元素，D位设置为1。收到此TLV后，LSR2将禁用指向LSR1的前缀LSPs应用程序状态，并从LSR1中撤回所有以前公布的应用程序状态。要从对等方提取标签绑定，如果对等方支持类型化通配符FEC功能，LSR2可以使用单前缀FEC类型的通配符标签提取消息[RFC5918]。
This dynamic disability of Prefix-LSPs application does not impact L2VPN P2P-PW application on the given session, and both LSRs should continue to exchange state related to PW Signaling applications.
前缀LSPs应用程序的这种动态禁用不会影响给定会话上的L2VPN P2P-PW应用程序，两个LSR应继续交换与PW信令应用程序相关的状态。
Assume that LSR1 and LSR2 have formed an LDP session to exchange mLDP state only. In typical deployments, LSR1 and LSR2 also exchange bindings for IP (unicast) prefixes upon mLDP session, which is unnecessary and wasteful for an mLDP-only LSR.
假设LSR1和LSR2已形成LDP会话，仅交换mLDP状态。在典型的部署中，LSR1和LSR2还在mLDP会话时交换IP（单播）前缀的绑定，这对于仅mLDP的LSR来说是不必要和浪费的。
Using the procedures defined earlier, an LSR can indicate its disinterest in Prefix-LSP application state to its peer upon session establishment time or dynamically later via an LDP capabilities update.
使用前面定义的过程，LSR可以在会话建立时或稍后通过LDP能力更新动态地向其对等方指示其对前缀LSP应用程序状态的不感兴趣。
In reference to Section 3.1, the peer disables the advertisement of any state related to IP Prefix FECs, but it still advertises IP address bindings that are required for the correct operation of mLDP.
参考第3.1节，对等方禁用与IP前缀FEC相关的任何状态的播发，但它仍然播发正确操作mLDP所需的IP地址绑定。
In IP dual-stack scenarios, LSR2 may advertise unnecessary state (e.g., IPv6 prefix label bindings) towards peer LSR1 corresponding to IPv6 Prefix-LSP applications once a session is established mainly for exchanging state for IPv4. The similar scenario also applies when
在IP双栈方案中，一旦建立了主要用于交换IPv4状态的会话，LSR2可能会向对应于IPv6前缀LSP应用程序的对等LSR1通告不必要的状态（例如，IPv6前缀标签绑定）。类似的情况也适用于以下情况：
advertising IPv4 Prefix-LSP state on a session meant for IPv6. The SAC capability and its procedures defined in this document can help to avoid such unnecessary state advertisement.
在用于IPv6的会话上公布IPv4前缀LSP状态。本文件中定义的SAC能力及其程序有助于避免此类不必要的状态公告。
Consider an IP dual-stack environment where LSR2 is enabled for Prefix-LSPs application for both IPv4 and IPv6, but LSR1 is enabled for (or interested in) only IPv4 Prefix-LSPs. To avoid receiving unwanted state advertisement for IPv6 Prefix-LSP applications from LSR2, LSR1 can send a SAC capability with an element for IPv6 Prefix-LSPs with the D-bit set to 1 in the Initialization message towards LSR2 at the time of session establishment. Upon receipt of this capability, LSR2 will disable all IPv6 label binding advertisements towards LSR1. If IPv6 Prefix-LSP applications are later enabled on LSR1, LSR1 can update the capability by sending a SAC capability in a Capability message towards LSR2 to enable this application dynamically.
考虑一个IP双栈环境，其中为Prefix LSPs应用程序既启用了IPv4和IPv6，又启用了LSR2，但对（或感兴趣的）仅启用了IPv4前缀LSP。为了避免从LSR2接收到IPv6前缀LSP应用程序的不需要的状态公告，LSR1可以在会话建立时向LSR2发送一个SAC功能，其中包含一个IPv6前缀LSP元素，该元素在初始化消息中的D位设置为1。收到此功能后，LSR2将禁用指向LSR1的所有IPv6标签绑定播发。如果以后在LSR1上启用IPv6前缀LSP应用程序，则LSR1可以通过向LSR2发送能力消息中的SAC能力来更新能力，以动态启用此应用程序。
The proposal introduced in this document does not introduce any new security considerations beyond those that already apply to the base LDP specification [RFC5036] and to MPLS and GMPLS [RFC5920].
本文件中介绍的方案没有引入任何新的安全注意事项，除了已经适用于基本LDP规范[RFC5036]和MPLS和GMPLS[RFC5920]的安全注意事项之外。
This document defines a new LDP capability parameter TLV. IANA has assigned the following value from "TLV Type Name Space" in the "Label Distribution Protocol (LDP) Parameters" registry as the new code point for the new LDP capability TLV code point.
本文件定义了一个新的LDP能力参数TLV。IANA已从“标签分发协议（LDP）参数”注册表中的“TLV类型名称空间”中指定以下值作为新LDP功能TLV码点的新码点。
+--------+---------------------+-----------+-----------------------+
| Value | Description | Reference |Notes/Registration Date|
+--------+---------------------+-----------+-----------------------+
| 0x050D | State Advertisement | RFC 7473 | |
| | Control Capability | | |
+--------+---------------------+-----------+-----------------------+
+--------+---------------------+-----------+-----------------------+
| Value | Description | Reference |Notes/Registration Date|
+--------+---------------------+-----------+-----------------------+
| 0x050D | State Advertisement | RFC 7473 | |
| | Control Capability | | |
+--------+---------------------+-----------+-----------------------+
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC5036]Andersson，L.，Ed.，Minei，I.，Ed.，和B.Thomas，Ed.，“LDP规范”，RFC 5036，2007年10月<http://www.rfc-editor.org/info/rfc5036>.
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. Le Roux, "LDP Capabilities", RFC 5561, July 2009, <http://www.rfc-editor.org/info/rfc5561>.
[RFC5561]托马斯，B.，拉扎，K.，阿加瓦尔，S.，阿加瓦尔，R.，和JL。Le Roux，“LDP能力”，RFC 55612009年7月<http://www.rfc-editor.org/info/rfc5561>.
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006, <http://www.rfc-editor.org/info/rfc4447>.
[RFC4447]Martini，L.，Ed.，Rosen，E.，El Aawar，N.，Smith，T.，和G.Heron，“使用标签分发协议（LDP）的伪线设置和维护”，RFC 4447，2006年4月<http://www.rfc-editor.org/info/rfc4447>.
[RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007, <http://www.rfc-editor.org/info/rfc4762>.
[RFC4762]Lasserre，M.，Ed.，和V.Kompella，Ed.，“使用标签分发协议（LDP）信令的虚拟专用LAN服务（VPLS）”，RFC 4762，2007年1月<http://www.rfc-editor.org/info/rfc4762>.
[RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)", RFC 5918, August 2010, <http://www.rfc-editor.org/info/rfc5918>.
[RFC5918]Asati，R.，Minei，I.，和B.Thomas，“标签分发协议（LDP）“类型通配符”前向等价类（FEC）”，RFC 59182010年8月<http://www.rfc-editor.org/info/rfc5918>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010, <http://www.rfc-editor.org/info/rfc5920>.
[RFC5920]Fang，L.，Ed.“MPLS和GMPLS网络的安全框架”，RFC 5920，2010年7月<http://www.rfc-editor.org/info/rfc5920>.
[RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November 2011, <http://www.rfc-editor.org/info/rfc6388>.
[RFC6388]Wijnands，IJ.，Ed.，Minei，I.，Ed.，Kompella，K.和B.Thomas，“点对多点和多点对多点标签交换路径的标签分发协议扩展”，RFC 6388，2011年11月<http://www.rfc-editor.org/info/rfc6388>.
[RFC7275] Martini, L., Salam, S., Sajassi, A., Bocci, M., Matsushima, S., and T. Nadeau, "Inter-Chassis Communication Protocol for Layer 2 Virtual Private Network (L2VPN) Provider Edge (PE) Redundancy", RFC 7275, June 2014, <http://www.rfc-editor.org/info/rfc7275>.
[RFC7275]Martini，L.，Salam，S.，Sajassi，A.，Bocci，M.，Matsushima，S.，和T.Nadeau，“第2层虚拟专用网络（L2VPN）提供商边缘（PE）冗余的机箱间通信协议”，RFC 7275，2014年6月<http://www.rfc-editor.org/info/rfc7275>.
[RFC7338] Jounay, F., Ed., Kamite, Y., Ed., Heron, G., and M. Bocci, "Requirements and Framework for Point-to-Multipoint Pseudowires over MPLS Packet Switched Networks", RFC 7338, September 2014, <http://www.rfc-editor.org/info/rfc7338>.
[RFC7338]Jounay，F.，Ed.，Kamite，Y.，Ed.，Heron，G.，和M.Bocci，“MPLS分组交换网络上点对多点伪线的要求和框架”，RFC 7338，2014年9月<http://www.rfc-editor.org/info/rfc7338>.
[RLFA] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. So, "Remote Loop-Free Alternate (LFA) Fast Re-Route (FRR)", draft-ietf-rtgwg-remote-lfa-11, Work in Progress, January 2015.
[RLFA]Bryant，S.，Filsfils，C.，Previdi，S.，Shand，M.，和N.So，“远程无环路备用（LFA）快速重路由（FRR）”，草案-ietf-rtgwg-Remote-LFA-11，正在进行的工作，2015年1月。
Acknowledgments
致谢
The authors would like to thank Eric Rosen and Alexander Vainshtein for their review and valuable comments. We also acknowledge Karthik Subramanian and IJsbrand Wijnands for bringing up mLDP use case.
作者要感谢Eric Rosen和Alexander Vainstein的评论和宝贵意见。我们还感谢Karthik Subramanian和IJsbrand Wijnands提出mLDP用例。
Authors' Addresses
作者地址
Kamran Raza Cisco Systems, Inc. 2000 Innovation Drive Ottawa, ON K2K-3E8 Canada EMail: skraza@cisco.com
Kamran Raza Cisco Systems，Inc.渥太华创新大道2000号，加拿大K2K-3E8电子邮件：skraza@cisco.com
Sami Boutros Cisco Systems, Inc. 3750 Cisco Way San Jose, CA 95134 United States EMail: sboutros@cisco.com
Sami Boutros Cisco Systems，Inc.美国加利福尼亚州圣何塞市思科大道3750号，邮编95134电子邮件：sboutros@cisco.com