Internet Engineering Task Force (IETF) R. Asati
Request for Comments: 5919 P. Mohapatra
Category: Standards Track Cisco Systems
ISSN: 2070-1721 E. Chen
Huawei Technologies
B. Thomas
August 2010
Internet Engineering Task Force (IETF) R. Asati
Request for Comments: 5919 P. Mohapatra
Category: Standards Track Cisco Systems
ISSN: 2070-1721 E. Chen
Huawei Technologies
B. Thomas
August 2010
Signaling LDP Label Advertisement Completion
信令LDP标签广告完成
Abstract
摘要
There are situations following Label Distribution Protocol (LDP) session establishment where it would be useful for an LDP speaker to know when its peer has advertised all of its labels. The LDP specification provides no mechanism for an LDP speaker to notify a peer when it has completed its initial label advertisements to that peer. This document specifies means for an LDP speaker to signal completion of its initial label advertisements following session establishment.
在标签分发协议（LDP）会话建立之后，有一些情况下，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/rfc5919.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5919.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Applicability - Label Advertisement Mode ...................3
2. Specification Language ..........................................3
3. Unrecognized Notification Capability ............................4
4. Signaling Completion of Label Advertisement .....................4
4.1. Missing Expected End-of-LIB Notifications ..................5
5. Usage Guidelines ................................................6
5.1. LDP-IGP Sync ...............................................6
5.2. LDP Graceful Restart .......................................7
5.3. Wildcard Label Request .....................................7
6. Security Considerations .........................................8
7. IANA Considerations .............................................8
8. Acknowledgments .................................................8
9. References ......................................................8
9.1. Normative References .......................................8
9.2. Informative References .....................................9
1. Introduction ....................................................3
1.1. Applicability - Label Advertisement Mode ...................3
2. Specification Language ..........................................3
3. Unrecognized Notification Capability ............................4
4. Signaling Completion of Label Advertisement .....................4
4.1. Missing Expected End-of-LIB Notifications ..................5
5. Usage Guidelines ................................................6
5.1. LDP-IGP Sync ...............................................6
5.2. LDP Graceful Restart .......................................7
5.3. Wildcard Label Request .....................................7
6. Security Considerations .........................................8
7. IANA Considerations .............................................8
8. Acknowledgments .................................................8
9. References ......................................................8
9.1. Normative References .......................................8
9.2. Informative References .....................................9
There are situations following LDP session establishment where it would be useful for an LDP speaker to know when its peer has advertised all of the labels from its Label Information Base (LIB). For example, when an LDP speaker is using LDP-IGP synchronization procedures [RFC5443], it would be useful for the speaker to know when its peer has completed advertisement of its IP label bindings. Similarly, after an LDP session is re-established when LDP Graceful Restart [RFC3478] is in effect, it would be helpful for each peer to signal the other after it has advertised all its label bindings.
在LDP会话建立之后，有一些情况下，LDP演讲者可以知道其对等方何时从其标签信息库（LIB）发布了所有标签。例如，当LDP演讲者正在使用LDP-IGP同步过程[RFC5443]时，演讲者知道其对等方何时完成其IP标签绑定的广告将是有用的。类似地，当LDP优雅重启[RFC3478]生效时重新建立LDP会话后，每个对等方在通告其所有标签绑定后向另一方发出信号将是有益的。
The LDP specification [RFC5036] provides no mechanism for an LDP speaker to notify a peer when it has completed its initial label advertisements to that peer.
LDP规范[RFC5036]没有提供LDP说话者在完成向对等方的初始标签广告时通知对等方的机制。
This document specifies use of a Notification message with the End-of-LIB Status Code for an LDP speaker to signal completion of its label advertisements following session establishment.
本文件规定了LDP演讲者在会话建立后使用带有LIB结束状态码的通知消息来表示其标签广告完成。
RFC 5036 implicitly assumes that new Status Codes will be defined over the course of time. However, it does not explicitly define the behavior of an LDP speaker that does not understand the Status Code in a Notification message. To avoid backward compatibility issues, this document specifies use of the LDP capability mechanism [RFC5561] at session establishment time for informing a peer that an LDP speaker is capable of handling a Notification message that carries an unrecognized Status Code.
RFC 5036隐式假设随着时间的推移将定义新的状态代码。但是，它没有明确定义不理解通知消息中状态码的LDP说话人的行为。为了避免向后兼容性问题，本文件规定在会话建立时使用LDP能力机制[RFC5561]来通知对等方LDP说话人能够处理携带未识别状态码的通知消息。
The mechanisms specified in this document are deemed useful to LDP peering using the 'Downstream Unsolicited' label advertisement mode [RFC5036]. They are not deemed useful to any LDP peering using the 'Downstream on Demand' label advertisement mode since the LDP speaker would request particular label binding(s) from the peer anyway and know when it has received them.
本文件中规定的机制被认为对使用“下游未经请求”标签广告模式的LDP对等有用[RFC5036]。它们对于使用“下游按需”标签广告模式的任何LDP对等都没有用处，因为LDP说话者无论如何都会向对等方请求特定的标签绑定，并且知道它何时收到它们。
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]中所述进行解释。
An LDP speaker MAY include a Capability Parameter [RFC5561] in the Initialization message to inform a peer that it ignores Notification Messages that carry a Status Type-Length-Value (TLV) with a non-fatal Status Code unknown to it.
LDP扬声器可在初始化消息中包括能力参数[RFC5561]，以通知对等方其忽略携带状态类型长度值（TLV）且非致命状态代码未知的通知消息。
The Capability Parameter for the Unrecognized Notification capability is a TLV with the following format:
无法识别的通知功能的功能参数是具有以下格式的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| Unrecognized Noti (0x0603)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved |
+-+-+-+-+-+-+-+-+
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| Unrecognized Noti (0x0603)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved |
+-+-+-+-+-+-+-+-+
Figure 1: Unrecognized Notification Capability Format
图1：无法识别的通知功能格式
Where:
哪里：
U- and F-bits: MUST be 1 and 0, respectively, as per Section 3 of LDP Capabilities [RFC5561].
U位和F位：根据LDP功能[RFC5561]第3节，必须分别为1和0。
Unrecognized Notif: 0x0603
无法识别的Notif:0x0603
S-bit: MUST be 1 (indicates that capability is being advertised).
S位：必须为1（表示正在公布功能）。
Upon receiving a Notification with an unrecognized Status Code, an LDP speaker MAY generate a console or system log message for trouble shooting purposes.
在收到带有无法识别的状态码的通知时，LDP扬声器可能会生成控制台或系统日志消息，以便进行故障排除。
An LDP speaker that conforms to this specification SHOULD signal completion of its label advertisements to a peer by means of a Notification message, if its peer has advertised the Unrecognized Notification capability during session establishment. The LDP speaker SHOULD send the Notification message (per Forwarding Equivalence Class (FEC) Type) to a peer even if the LDP speaker has zero Label bindings to advertise to that peer.
符合本规范的LDP演讲者应通过通知消息向对等方发出标签广告完成的信号，如果其对等方在会话建立期间已通告无法识别的通知能力。LDP说话人应向对等方发送通知消息（每个转发等价类（FEC）类型），即使LDP说话人没有向该对等方播发的标签绑定。
Such a Notification message MUST carry:
此类通知信息必须包含：
- A status TLV (with TLV E- and F-bits set to zero) that carries an End-of-LIB Status Code (0x0000002F).
- 携带库结束状态代码（0x0000002F）的状态TLV（TLV E位和F位设置为零）。
- A FEC TLV with the Typed Wildcard FEC Element [RFC5918] that identifies the FEC type for which initial label advertisements have been completed. In terms of Section 3.5.1 of RFC 5036, this TLV is an "Optional Parameter" of the Notification message.
- 具有类型化通配符FEC元素[RFC5918]的FEC TLV，用于标识已完成初始标签播发的FEC类型。根据RFC 5036第3.5.1节，该TLV是通知消息的“可选参数”。
An LDP speaker MUST NOT send a Notification that carries a Status TLV with the End-of-LIB Status Code to a peer unless the peer has advertised the Unrecognized Notification capability during session establishment.
LDP演讲者不得向对等方发送带有LIB结束状态代码的状态TLV的通知，除非该对等方在会话建立期间公布了无法识别的通知功能。
This applies to any LDP peers discovered via either basic discovery or extended discovery mechanisms (per Section 2.4 of [RFC5036]).
这适用于通过基本发现或扩展发现机制发现的任何LDP对等点（根据[RFC5036]第2.4节）。
There is no guarantee that an LDP speaker will receive (or send) an End-of-LIB Notification from (or to) a peer even if the LDP speaker has signaled the Unrecognized Notification capability (Section 3).
即使LDP说话人已发出无法识别的通知能力的信号（第3节），也不能保证LDP说话人将从（或发送）对等方接收（或发送）LIB结束通知。
Although it is expected that an LDP speaker supporting the Unrecognized Notification capability would support sending and receiving an End-of-LIB Notification, it is not mandatory by definition.
虽然预计支持未识别通知功能的LDP说话人将支持发送和接收LIB结束通知，但根据定义，这不是强制性的。
Please note that this is not a concern since the LDP speaker would simply ignore the received Notification with an End-of-LIB status code (or any status code) that is not recognized or supported, by definition.
请注意，这不是一个问题，因为自民党发言人只会忽略接收到的通知，通知中有一个库尾状态代码（或任何状态代码），根据定义，该代码不被识别或支持。
To deal with the possibility of missing End-of-LIB Notifications after the LDP session establishment, an LDP speaker MAY time out receipt of an expected End-of-LIB Notification. An LDP speaker SHOULD start a per-peer internal timer, called 'EOL Notification' timer (the default value of 60 seconds is RECOMMENDED, though the value of this timer SHOULD be configurable) immediately following the LDP session establishment.
为了处理在LDP会话建立后丢失LIB结束通知的可能性，LDP发言人可能会暂停接收预期的LIB结束通知。LDP扬声器应在LDP会话建立后立即启动每个对等内部计时器，称为“下线通知”计时器（建议默认值为60秒，但该计时器的值应可配置）。
This timer is reset by the subsequent label advertisement, and stopped by the End-of-LIB Notification message. Lacking any label advertisement from the peer, the timer would expire, causing the LDP speaker to behave as if it had received the End-of-LIB notification from the peer.
此计时器由后续标签播发重置，并在LIB结束通知消息时停止。如果没有来自对等方的任何标签广告，计时器将过期，导致LDP演讲者表现得好像从对等方收到了LIB结束通知。
If the End-of-LIB Notification message is received after the timer expires, then the message SHOULD be ignored.
如果在计时器过期后收到LIB结束通知消息，则应忽略该消息。
The FECs known to an LDP speaker and the labels the speaker has bound to those FECs may change over the course of time. This makes it difficult to determine when an LDP speaker has advertised "all" of its label bindings for a given FEC type. Ultimately, this determination is a judgment call the LDP speaker makes. The following guidelines may be useful.
LDP演讲者已知的FEC以及演讲者绑定到这些FEC的标签可能会随着时间的推移而改变。这使得很难确定LDP演讲者何时为给定的FEC类型发布了“所有”标签绑定。最终，这一决定是自民党发言人做出的判断。以下指南可能有用。
An LDP speaker is assumed to "know" a set of FECs. Depending on a variety of criteria, such as:
自民党发言人被假定“知道”一组FEC。根据各种标准，例如：
- the label distribution control mode in use (Independent or Ordered);
- 使用中的标签分发控制模式（独立或有序）；
- the set of FECs to which the speaker has bound local labels;
- 说话人已绑定本地标签的一组FEC；
- configuration settings that may constrain which label bindings the speaker may advertise to peers.
- 可约束说话人向对等方播发哪些标签绑定的配置设置。
The speaker can determine the set of bindings for a given FEC type that it is permitted to advertise to a given peer.
演讲者可以确定允许播发给给定对等方的给定FEC类型的绑定集。
LDP-IGP Sync, LDP Graceful Restart, and the response to a Wildcard Label Request [RFC5918] are situations that would benefit from End-of-LIB Notification. In these situations, after an LDP speaker completes its label binding advertisements to a peer, sending an End-of-LIB Notification to the peer makes their outcome deterministic. The following subsections further explain each of these situations one by one.
LDP-IGP同步、LDP优雅重启以及对通配符标签请求的响应[RFC5918]都是从库结束通知中受益的情况。在这些情况下，在LDP演讲者完成其向对等方的标签绑定广告后，向对等方发送LIB结束通知使其结果具有确定性。以下各小节将逐一进一步解释这些情况。
The LDP-IGP Synchronization [RFC5443] specifies a mechanism by which directly connected LDP speakers may delay the use of the link (between them) for transit IP traffic forwarding until the labels required to support IP-over-MPLS traffic forwarding have been distributed and installed.
LDP-IGP同步[RFC5443]规定了一种机制，通过该机制，直接连接的LDP扬声器可以延迟使用（它们之间的）链路进行传输IP流量转发，直到分发和安装了支持IP over MPLS流量转发所需的标签。
Without an End-of-LIB Notification, the speaker must rely on some heuristic to determine when it has received all of its peer's label bindings. The heuristic chosen could cause LDP to signal the IGP too soon (in which case, the likelihood that traffic will be dropped increases) or too late (in which case, traffic is kept on sub-optimal paths longer than necessary).
在没有结束库通知的情况下，说话者必须依靠某种启发式方法来确定何时已收到其对等方的所有标签绑定。所选择的启发式可能会导致LDP过早地（在这种情况下，流量丢失的可能性增加）或太晚（在这种情况下，流量保持在次优路径上的时间比需要的时间长）向IGP发送信号。
Following session establishment, with a directly connected peer that has advertised the Unrecognized Notification capability, an LDP speaker using LDP-IGP Sync may send the peer an End-of-LIB Notification after it completes advertisement of its IP label bindings to the peer. Similarly, the LDP speaker may use the End-of-LIB Notification received from a directly connected peer to determine when the peer has completed advertisement of its label bindings for IP prefixes. After receiving the notification, the LDP speaker should consider LDP to be fully operational for the link and should signal the IGP to start advertising the link with normal cost.
在会话建立之后，对于已通告无法识别的通知能力的直接连接的对等方，使用LDP-IGP Sync的LDP说话者可以在完成向对等方通告其IP标签绑定后向对等方发送LIB结束通知。类似地，LDP演讲者可以使用从直接连接的对等方接收到的LIB结束通知来确定对等方何时已经完成其IP前缀的标签绑定的广告。在收到通知后，LDP发言人应考虑LDP对链路的完全操作，并应向IGP发出信号，开始以正常的成本对链路进行广告。
LDP Graceful Restart [RFC3478] helps to reduce the loss of MPLS traffic caused by the restart of a router's LDP component. It defines procedures that allow routers capable of preserving MPLS forwarding state across the restart to continue forwarding MPLS traffic using forwarding state installed prior to the restart for a configured time period.
LDP优雅重启[RFC3478]有助于减少因重启路由器的LDP组件而导致的MPLS流量损失。它定义了允许能够在重启期间保留MPLS转发状态的路由器使用重启前安装的转发状态在配置的时间段内继续转发MPLS流量的过程。
The current behavior without End-of-LIB Notification is as follows: the restarting router and its peers consider the preserved forwarding state to be usable but stale until it is refreshed by receipt of new label advertisements following re-establishment of new LDP sessions or until the time period expires. When the time period expires, any remaining stale forwarding state is removed by the router.
当前没有LIB通知结束的行为如下：重新启动路由器及其对等者认为保留的转发状态可用但过时，直到在重新建立新的LDP会话之后或者直到时间期限届满之后，通过接收新的标签广告来刷新。当时间段到期时，路由器将删除任何剩余的过时转发状态。
Receiving End-of-LIB Notification from a peer in an LDP Graceful Restart scenario enables an LDP speaker to stop using stale forwarding information learned from that peer and to recover the resources it requires without having to wait until the time period expiry. The time period expiry can still be used if the End-of-LIB Notification message is not received.
在LDP优雅重启场景中，从对等方接收LIB结束通知可使LDP说话者停止使用从该对等方获悉的过时转发信息，并恢复其所需的资源，而无需等待时间段到期。如果未收到LIB结束通知消息，则仍可使用时间段到期。
When an LDP speaker receives a Label Request message for a Typed Wildcard FEC (e.g., a particular FEC Element Type) from a peer, the LDP speaker determines the set of bindings (as per any local filtering policy) to advertise to the peer for the FEC type specified by the request. Assuming the peer had advertised the Unrecognized Notification capability at session initialization time, the speaker should send the peer an End-of-LIB Notification for the FEC type when it completes advertisement of the permitted bindings.
当LDP说话人从对等方接收到类型化通配符FEC（例如，特定FEC元素类型）的标签请求消息时，LDP说话人确定绑定集（根据任何本地过滤策略）以向对等方播发由请求指定的FEC类型。假设对等方在会话初始化时公布了无法识别的通知功能，则演讲者应在完成允许绑定的公布时向对等方发送FEC类型的LIB结束通知。
As in the previous applications, receipt of the Notification eliminates uncertainty as to when the peer has completed its advertisements of label bindings for the requested Wildcard FEC Element Type.
与以前的应用程序一样，接收通知消除了对等方何时完成所请求的通配符FEC元素类型的标签绑定的播发的不确定性。
No security considerations beyond those that apply to the base LDP specification [RFC5036] and that are further described in [RFC5920] apply to signaling the End-of-LIB condition as described in this document.
除了适用于基本LDP规范[RFC5036]和[RFC5920]中进一步描述的安全注意事项外，没有其他安全注意事项适用于本文件中所述的发送LIB结束条件的信号。
This document introduces a new LDP Status Code and a new LDP Capability.
本文档介绍了一种新的LDP状态码和一种新的LDP功能。
IANA has assigned the 'End-of-LIB' status code (0x0000002F) from the Status Code Name Space. [RFC5036] partitions the Status Code Name Space into 3 regions: IETF Consensus region, First Come First Served region, and Private Use region. The code point 0x0000002F is from the IETF Consensus range.
IANA已从状态代码名称空间分配了“库结束”状态代码（0x0000002F）。[RFC5036]将状态代码名称空间划分为3个区域：IETF共识区域、先到先服务区域和专用区域。代码点0x0000002F来自IETF共识范围。
IANA has assigned the 'Unrecognized Notification' capability (0x0603) from the TLV Type name space. [RFC5036] partitions the TLV Type name space into 3 regions: IETF Consensus region, Vendor Private Use region, and Experimental Use region. The code point 0x0603 is from the IETF Consensus range.
IANA已从TLV类型名称空间分配了“无法识别的通知”功能（0x0603）。[RFC5036]将TLV类型名称空间划分为3个区域：IETF共识区域、供应商专用区域和实验使用区域。代码点0x0603来自IETF共识范围。
The authors would like to recognize Kamran Raza, who helped to formulate this draft.
作者希望表彰帮助制定本草案的Kamran Raza。
The authors would like to thank Ina Minei, Alia Atlas, Yakov Rekhter, Loa Andersson, and Luyuan Fang for their valuable feedback and contributions.
作者要感谢Ina Minei、Alia Atlas、Yakov Rekhter、Loa Andersson和Luyuan Fang的宝贵反馈和贡献。
[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月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036]Andersson，L.，Ed.，Minei，I.，Ed.，和B.Thomas，Ed.，“LDP规范”，RFC 5036，2007年10月。
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. Le Roux, "LDP Capabilities", RFC 5561, July 2009.
[RFC5561]托马斯，B.，拉扎，K.，阿加瓦尔，S.，阿加瓦尔，R.，和JL。Le Roux，“LDP能力”，RFC 55612009年7月。
[RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)", RFC 5918, August 2010.
[RFC5918]Asati，R.，Minei，I.，和B.Thomas，“标签分发协议（LDP）“类型通配符”前向等价类（FEC）”，RFC 59182010年8月。
[RFC3478] Leelanivas, M., Rekhter, Y., and R. Aggarwal, "Graceful Restart Mechanism for Label Distribution Protocol", RFC 3478, February 2003.
[RFC3478]Leelanivas，M.，Rekhter，Y.，和R.Aggarwal，“标签分发协议的优雅重启机制”，RFC 3478，2003年2月。
[RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP Synchronization", RFC 5443, March 2009.
[RFC5443]Jork，M.，Atlas，A.，和L.Fang，“LDP IGP同步”，RFC 54432009年3月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，RFC 5920，2010年7月。
Authors' Addresses
作者地址
Rajiv Asati Cisco Systems 7025-6 Kit Creek Rd. Research Triangle Park, NC 27709-4987 EMail: rajiva@cisco.com
Rajiv Asati Cisco Systems 7025-6北卡罗来纳州三角研究公园Kit Creek路27709-4987电子邮件：rajiva@cisco.com
Pradosh Mohapatra Cisco Systems 3750 Cisco Way San Jose, CA 95134 EMail: pmohapat@cisco.com
Pradosh Mohapatra Cisco Systems 3750 Cisco Way San Jose，CA 95134电子邮件：pmohapat@cisco.com
Emily Chen Huawei Technologies No. 5 Street, Shangdi Information, Haidian Beijing, China EMail: chenying220@huawei.com
中国北京市海淀区上地信息街5号华为技术有限公司Emily Chen电子邮件：chenying220@huawei.com
Bob Thomas EMail: bobthomas@alum.mit.edu
鲍勃·托马斯电子邮件：bobthomas@alum.mit.edu