draft-ijln-mpls-rfc5036bis-01.txt   draft-ijln-mpls-rfc5036bis-02.txt 
Network Working Group X. Chen Network Working Group X. Chen
Internet-Draft L. Andersson Internet-Draft L. Andersson
Intended status: Standards Track Huawei Technologies Intended status: Standards Track Huawei Technologies
Expires: September 19, 2016 N. Leymann Expires: October 9, 2016 N. Leymann
Deutsche Telekom Deutsche Telekom
I. Minei I. Minei
Google Google
K. Raza K. Raza
Cisco Systems, Inc. Cisco Systems, Inc.
March 18, 2016 April 7, 2016
LDP Specification LDP Specification
draft-ijln-mpls-rfc5036bis-01.txt draft-ijln-mpls-rfc5036bis-02.txt
Abstract Abstract
The architecture for Multiprotocol Label Switching (MPLS) is The architecture for Multiprotocol Label Switching (MPLS) is
described in RFC 3031. A fundamental concept in MPLS is that two described in RFC 3031. A fundamental concept in MPLS is that two
Label Switching Routers (LSRs) must agree on the meaning of the Label Switching Routers (LSRs) must agree on the meaning of the
labels used to forward traffic between and through them. This common labels used to forward traffic between and through them. This common
understanding is achieved by using a set of procedures, called a understanding is achieved by using a set of procedures, called a
label distribution protocol, by which one LSR informs another of label distribution protocol, by which one LSR informs another of
label bindings it has made. This document defines a set of such label bindings it has made. This document defines a set of such
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 19, 2016. This Internet-Draft will expire on October 9, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 29 skipping to change at page 3, line 29
3.6.2.1. Conservative Label Retention Mode . . . . . . . . 23 3.6.2.1. Conservative Label Retention Mode . . . . . . . . 23
3.6.2.2. Liberal Label Retention Mode . . . . . . . . . . 23 3.6.2.2. Liberal Label Retention Mode . . . . . . . . . . 23
3.6.3. Label Advertisement Mode . . . . . . . . . . . . . . 24 3.6.3. Label Advertisement Mode . . . . . . . . . . . . . . 24
3.7. LDP Identifiers and Next Hop Addresses . . . . . . . . . 24 3.7. LDP Identifiers and Next Hop Addresses . . . . . . . . . 24
3.8. Loop Detection . . . . . . . . . . . . . . . . . . . . . 24 3.8. Loop Detection . . . . . . . . . . . . . . . . . . . . . 24
3.8.1. Label Request Message . . . . . . . . . . . . . . . . 25 3.8.1. Label Request Message . . . . . . . . . . . . . . . . 25
3.8.2. Label Mapping Message . . . . . . . . . . . . . . . . 26 3.8.2. Label Mapping Message . . . . . . . . . . . . . . . . 26
3.8.3. Discussion . . . . . . . . . . . . . . . . . . . . . 28 3.8.3. Discussion . . . . . . . . . . . . . . . . . . . . . 28
3.9. Authenticity and Integrity of LDP Messages . . . . . . . 29 3.9. Authenticity and Integrity of LDP Messages . . . . . . . 29
3.9.1. TCP MD5 Signature Option . . . . . . . . . . . . . . 29 3.9.1. TCP MD5 Signature Option . . . . . . . . . . . . . . 29
3.9.2. LDP Use of TCP MD5 Signature Option . . . . . . . . . 30 3.9.2. LDP Use of TCP MD5 Signature Option . . . . . . . . . 31
4. Protocol Specification . . . . . . . . . . . . . . . . . . . 31 4. Protocol Specification . . . . . . . . . . . . . . . . . . . 31
4.1. LDP PDUs . . . . . . . . . . . . . . . . . . . . . . . . 31 4.1. LDP PDUs . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2. LDP Procedures . . . . . . . . . . . . . . . . . . . . . 32 4.2. LDP Procedures . . . . . . . . . . . . . . . . . . . . . 32
4.3. Type-Length-Value Encoding . . . . . . . . . . . . . . . 33 4.3. Type-Length-Value Encoding . . . . . . . . . . . . . . . 33
4.4. TLV Encodings for Commonly Used Parameters . . . . . . . 35 4.4. TLV Encodings for Commonly Used Parameters . . . . . . . 35
4.4.1. FEC TLV . . . . . . . . . . . . . . . . . . . . . . . 35 4.4.1. FEC TLV . . . . . . . . . . . . . . . . . . . . . . . 35
4.4.1.1. FEC Procedures . . . . . . . . . . . . . . . . . 37 4.4.1.1. FEC Procedures . . . . . . . . . . . . . . . . . 37
4.4.2. Label TLVs . . . . . . . . . . . . . . . . . . . . . 37 4.4.2. Label TLVs . . . . . . . . . . . . . . . . . . . . . 37
4.4.2.1. Generic Label TLV . . . . . . . . . . . . . . . . 37 4.4.2.1. Generic Label TLV . . . . . . . . . . . . . . . . 37
4.4.2.2. ATM Label TLV . . . . . . . . . . . . . . . . . . 38 4.4.2.2. ATM Label TLV . . . . . . . . . . . . . . . . . . 38
skipping to change at page 4, line 7 skipping to change at page 4, line 7
4.4.5.1. Path Vector Procedures . . . . . . . . . . . . . 44 4.4.5.1. Path Vector Procedures . . . . . . . . . . . . . 44
4.4.6. Status TLV . . . . . . . . . . . . . . . . . . . . . 45 4.4.6. Status TLV . . . . . . . . . . . . . . . . . . . . . 45
4.5. LDP Messages . . . . . . . . . . . . . . . . . . . . . . 47 4.5. LDP Messages . . . . . . . . . . . . . . . . . . . . . . 47
4.5.1. Notification Message . . . . . . . . . . . . . . . . 49 4.5.1. Notification Message . . . . . . . . . . . . . . . . 49
4.5.1.1. Notification Message Procedures . . . . . . . . . 50 4.5.1.1. Notification Message Procedures . . . . . . . . . 50
4.5.1.2. Events Signaled by Notification Messages . . . . 51 4.5.1.2. Events Signaled by Notification Messages . . . . 51
4.5.2. Hello Message . . . . . . . . . . . . . . . . . . . . 53 4.5.2. Hello Message . . . . . . . . . . . . . . . . . . . . 53
4.5.2.1. Hello Message Procedures . . . . . . . . . . . . 56 4.5.2.1. Hello Message Procedures . . . . . . . . . . . . 56
4.5.3. Initialization Message . . . . . . . . . . . . . . . 57 4.5.3. Initialization Message . . . . . . . . . . . . . . . 57
4.5.3.1. Initialization Message Procedures . . . . . . . . 66 4.5.3.1. Initialization Message Procedures . . . . . . . . 66
4.5.4. KeepAlive Message . . . . . . . . . . . . . . . . . . 66 4.5.4. KeepAlive Message . . . . . . . . . . . . . . . . . . 67
4.5.4.1. KeepAlive Message Procedures . . . . . . . . . . 67 4.5.4.1. KeepAlive Message Procedures . . . . . . . . . . 67
4.5.5. Address Message . . . . . . . . . . . . . . . . . . . 67 4.5.5. Address Message . . . . . . . . . . . . . . . . . . . 67
4.5.5.1. Address Message Procedures . . . . . . . . . . . 68 4.5.5.1. Address Message Procedures . . . . . . . . . . . 68
4.5.6. Address Withdraw Message . . . . . . . . . . . . . . 69 4.5.6. Address Withdraw Message . . . . . . . . . . . . . . 69
4.5.6.1. Address Withdraw Message Procedures . . . . . . . 70 4.5.6.1. Address Withdraw Message Procedures . . . . . . . 70
4.5.7. Label Mapping Message . . . . . . . . . . . . . . . . 70 4.5.7. Label Mapping Message . . . . . . . . . . . . . . . . 70
4.5.7.1. Label Mapping Message Procedures . . . . . . . . 71 4.5.7.1. Label Mapping Message Procedures . . . . . . . . 71
4.5.8. Label Request Message . . . . . . . . . . . . . . . . 74 4.5.8. Label Request Message . . . . . . . . . . . . . . . . 74
4.5.8.1. Label Request Message Procedures . . . . . . . . 75 4.5.8.1. Label Request Message Procedures . . . . . . . . 75
4.5.9. Label Abort Request Message . . . . . . . . . . . . . 77 4.5.9. Label Abort Request Message . . . . . . . . . . . . . 77
skipping to change at page 4, line 46 skipping to change at page 4, line 46
5.2. TLV Type Name Space . . . . . . . . . . . . . . . . . . . 92 5.2. TLV Type Name Space . . . . . . . . . . . . . . . . . . . 92
5.3. FEC Type Name Space . . . . . . . . . . . . . . . . . . . 92 5.3. FEC Type Name Space . . . . . . . . . . . . . . . . . . . 92
5.4. Status Code Name Space . . . . . . . . . . . . . . . . . 92 5.4. Status Code Name Space . . . . . . . . . . . . . . . . . 92
5.5. Experiment ID Name Space . . . . . . . . . . . . . . . . 93 5.5. Experiment ID Name Space . . . . . . . . . . . . . . . . 93
6. Security Considerations . . . . . . . . . . . . . . . . . . . 93 6. Security Considerations . . . . . . . . . . . . . . . . . . . 93
6.1. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . 93 6.1. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . 93
6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 94 6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 95 6.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 95
7. Areas for Future Study . . . . . . . . . . . . . . . . . . . 96 7. Areas for Future Study . . . . . . . . . . . . . . . . . . . 96
8. Changes from RFC 5036 . . . . . . . . . . . . . . . . . . . . 97 8. Changes from RFC 5036 . . . . . . . . . . . . . . . . . . . . 97
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 97 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 97
10. Appendix A. LDP Label Distribution Procedures . . . . . . . 98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 98
10.1. A.1. Handling Label Distribution Events . . . . . . . . 101 10.1. Normative References . . . . . . . . . . . . . . . . . . 98
10.1.1. A.1.1. Receive Label Request . . . . . . . . . . . 101 10.2. Informative References . . . . . . . . . . . . . . . . . 100
10.1.2. A.1.2. Receive Label Mapping . . . . . . . . . . . 105 Appendix A. LDP Label Distribution Procedures . . . . . . . . . 101
10.1.3. A.1.3 Receive Label Abort Request . . . . . . . . . 111 A.1. Handling Label Distribution Events . . . . . . . . . . . 104
10.1.4. A.1.4 Receive Label Release . . . . . . . . . . . . 112 A.1.1. Receive Label Request . . . . . . . . . . . . . . . . 104
10.1.5. A.1.5 Receive Label Withdraw . . . . . . . . . . . . 114 A.1.2. Receive Label Mapping . . . . . . . . . . . . . . . . 108
10.1.6. A.1.6 Recognize New FEC . . . . . . . . . . . . . . 116 A.1.3. Receive Label Abort Request . . . . . . . . . . . . . 114
10.1.7. A.1.7 Detect Change in FEC Next Hop . . . . . . . . 119 A.1.4. Receive Label Release . . . . . . . . . . . . . . . . 115
10.1.8. A.1.8. Receive Notification / Label Request Aborted 121 A.1.5. Receive Label Withdraw . . . . . . . . . . . . . . . 117
10.1.9. A.1.9. Receive Notification / No Label Resources . 122 A.1.6. Recognize New FEC . . . . . . . . . . . . . . . . . . 119
10.1.10. A.1.10. Receive Notification / No Route . . . . . . 123 A.1.7. Detect Change in FEC Next Hop . . . . . . . . . . . . 122
10.1.11. A.1.11. Receive Notification / Loop Detected . . . 124 A.1.8. Receive Notification / Label Request Aborted . . . . 124
10.1.12. A.1.12. Receive Notification / Label Resources A.1.9. Receive Notification / No Label Resources . . . . . . 125
Available . . . . . . . . . . . . . . . . . . . . . 124 A.1.10. Receive Notification / No Route . . . . . . . . . . . 126
10.1.13. A.1.13. Detect Local Label Resources Have Become A.1.11. Receive Notification / Loop Detected . . . . . . . . 127
Available . . . . . . . . . . . . . . . . . . . . . 125 A.1.12. Receive Notification / Label Resources Available . . 127
10.1.14. A.1.14. LSR Decides to No Longer Label Switch a FEC 126 A.1.13. Detect Local Label Resources Have Become Available . 128
10.1.15. A.1.15. Timeout of Deferred Label Request . . . . . 127 A.1.14. LSR Decides to No Longer Label Switch a FEC . . . . . 129
10.2. A.2. Common Label Distribution Procedures . . . . . . . 127 A.1.15. Timeout of Deferred Label Request . . . . . . . . . . 130
10.2.1. A.2.1. Send_Label . . . . . . . . . . . . . . . . . 127 A.2. Common Label Distribution Procedures . . . . . . . . . . 130
10.2.2. A.2.2. Send_Label_Request . . . . . . . . . . . . . 129 A.2.1. Send_Label . . . . . . . . . . . . . . . . . . . . . 130
10.2.3. A.2.3. Send_Label_Withdraw . . . . . . . . . . . . 130 A.2.2. Send_Label_Request . . . . . . . . . . . . . . . . . 132
10.2.4. A.2.4. Send_Notification . . . . . . . . . . . . . 130 A.2.3. Send_Label_Withdraw . . . . . . . . . . . . . . . . . 133
10.2.5. A.2.5. Send_Message . . . . . . . . . . . . . . . . 131 A.2.4. Send_Notification . . . . . . . . . . . . . . . . . . 133
10.2.6. A.2.6. Check_Received_Attributes . . . . . . . . . 131 A.2.5. Send_Message . . . . . . . . . . . . . . . . . . . . 134
10.2.7. A.2.7. Prepare_Label_Request_Attributes . . . . . . 133 A.2.6. Check_Received_Attributes . . . . . . . . . . . . . . 134
10.2.8. A.2.8. Prepare_Label_Mapping_Attributes . . . . . . 134 A.2.7. Prepare_Label_Request_Attributes . . . . . . . . . . 136
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 137 A.2.8. Prepare_Label_Mapping_Attributes . . . . . . . . . . 137
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 137 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 140
12.1. Normative References . . . . . . . . . . . . . . . . . . 137
12.2. Informative References . . . . . . . . . . . . . . . . . 139
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 141 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 141
1. Editors notes - this section will be removed before publication 1. Editors notes - this section will be removed before publication
This entire section will be removed before publication. This entire section will be removed before publication.
1.1. Scope of RFC5036bis work 1.1. Scope of RFC5036bis work
The goal of this document is to take the LDP specification to The goal of this document is to take the LDP specification to
Internet Standard. Internet Standard.
skipping to change at page 90, line 35 skipping to change at page 90, line 35
then forwards the resulting packet to Rd." then forwards the resulting packet to Rd."
The implicit NULL label is represented in LDP as a Generic Label TLV The implicit NULL label is represented in LDP as a Generic Label TLV
with a Label field value of 3, as defined in RFC 3032 [RFC3032]. with a Label field value of 3, as defined in RFC 3032 [RFC3032].
5. RFC 5036 IANA Considerations 5. RFC 5036 IANA Considerations
Note: In version -00 of this document does only minimal changes to Note: In version -00 of this document does only minimal changes to
the RFC 5036 IANA considerationns. The author believe that some the RFC 5036 IANA considerationns. The author believe that some
further minor changes will be made eventually. The "IANA further minor changes will be made eventually. The "IANA
consideration" section (see Section 11) is included to capture consideration" section (see Section 9) is included to capture
anything new that relates to IANA, Before publication the two section anything new that relates to IANA, Before publication the two section
will be merged. will be merged.
The LDP specification defines the following name spaces that are The LDP specification defines the following name spaces that are
managed by IANA and found at [LDP_NAME_SPACE]: managed by IANA and found at [LDP_NAME_SPACE]:
- Message Type Name Space, found at [MSG_TYPE_NAME_SPACE] - Message Type Name Space, found at [MSG_TYPE_NAME_SPACE]
- TLV Type Name Space, found at [TLV_TYPE_NAME_SPACE] - TLV Type Name Space, found at [TLV_TYPE_NAME_SPACE]
- FEC Type Name Space, found at [FEC_TYPE_NAME_SPACE] - FEC Type Name Space, found at [FEC_TYPE_NAME_SPACE]
- Status Code Name Space, found at [STATUS_CODE_NAME_SPACE] - Status Code Name Space, found at [STATUS_CODE_NAME_SPACE]
skipping to change at page 97, line 46 skipping to change at page 97, line 46
1. Some editorial changes has been made, e.g. internal references is 1. Some editorial changes has been made, e.g. internal references is
more frequently used, some implicit lists has been replaced by more frequently used, some implicit lists has been replaced by
tables, e.g. for Optional Parameters carried in LDP messages. tables, e.g. for Optional Parameters carried in LDP messages.
2. The refrence to CR-LDP has been removed. 2. The refrence to CR-LDP has been removed.
3. References to the LDP registries create outside the LDP 3. References to the LDP registries create outside the LDP
Specification has been added. Specification has been added.
9. Acknowledgments 9. IANA Considerations
The editors of this document relies heavily on, and would like to There are no requests for IANA actions in this document.
thank, everyone that contributed to the develoment and improvement of
the LDP Specification.
This document is produced as part of advancing the LDP specification Note to the RFC Editor - this section can be removed before
to Internet Standard status. The predessor (RFC 5036) was published publication.
as Draft Standard October 2007. It was produced by the MPLS Working
Group of the IETF and was jointly authored by Loa Andersson, Bob
Thomas and Ina Minei.
Since the Draft Standard version was published IETF has abandoned the 10. References
3 steps standards ladder. Now there is only proposed standard (PS)
and Internet Standard (IS). This is part of the motivation to make
the effort to bring the LDP specification to Internet Standard.
The LDP specification was originally published as RFC 3036 in January 10.1. Normative References
2001. It was produced by the MPLS Working Group of the IETF and was
jointly authored by Loa Andersson, Paul Doolan, Nancy Feldman, Andre
Fredette, and Bob Thomas.
The ideas and text in RFC 3036 were collected from a number of [ASSIGNED_AF]
sources. We would like to thank Rick Boivie, Ross Callon, Alex "IANA Assigned Address Families",
Conta, Eric Gray, Yoshihiro Ohba, Eric Rosen, Bernard Suter, Yakov <http://www.iana.org/assignments/address-family-numbers>.
Rekhter, and Arun Viswanathan for their input for RFC 3036.
The authors would like to thank Eric Gray, David Black, and Sam [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
Hartman for their input to and review of RFC 5036. That input has DOI 10.17487/RFC1321, April 1992,
been of great help also for the current document. <http://www.rfc-editor.org/info/rfc1321>.
In addition, the authors would like to thank the members of the MPLS [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Working Group for their ideas and the support they have given to this Requirement Levels", BCP 14, RFC 2119,
document, and in particular, to Eric Rosen, Luca Martini, Markus DOI 10.17487/RFC2119, March 1997,
Jork, Mark Duffy, Vach Kompella, Kishore Tiruveedhula, Rama <http://www.rfc-editor.org/info/rfc2119>.
Ramakrishnan, Nick Weeds, Adrian Farrel, and Andy Malis.
Editor note - this section is still work in progress. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998,
<http://www.rfc-editor.org/info/rfc2328>.
10. Appendix A. LDP Label Distribution Procedures [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, DOI 10.17487/RFC2385, August
1998, <http://www.rfc-editor.org/info/rfc2385>.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2434,
DOI 10.17487/RFC2434, October 1998,
<http://www.rfc-editor.org/info/rfc2434>.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, DOI 10.17487/RFC2702, September 1999,
<http://www.rfc-editor.org/info/rfc2702>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001,
<http://www.rfc-editor.org/info/rfc3031>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<http://www.rfc-editor.org/info/rfc3032>.
[RFC3034] Conta, A., Doolan, P., and A. Malis, "Use of Label
Switching on Frame Relay Networks Specification",
RFC 3034, DOI 10.17487/RFC3034, January 2001,
<http://www.rfc-editor.org/info/rfc3034>.
[RFC3035] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E.,
Swallow, G., Rekhter, Y., and P. Doolan, "MPLS using LDP
and ATM VC Switching", RFC 3035, DOI 10.17487/RFC3035,
January 2001, <http://www.rfc-editor.org/info/rfc3035>.
[RFC3037] Thomas, B. and E. Gray, "LDP Applicability", RFC 3037,
DOI 10.17487/RFC3037, January 2001,
<http://www.rfc-editor.org/info/rfc3037>.
[RFC3988] Black, B. and K. Kompella, "Maximum Transmission Unit
Signalling Extensions for the Label Distribution
Protocol", RFC 3988, DOI 10.17487/RFC3988, January 2005,
<http://www.rfc-editor.org/info/rfc3988>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed.,
"Requirements for Operations, Administration, and
Maintenance (OAM) in MPLS Transport Networks", RFC 5860,
DOI 10.17487/RFC5860, May 2010,
<http://www.rfc-editor.org/info/rfc5860>.
[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
L., and L. Berger, "A Framework for MPLS in Transport
Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010,
<http://www.rfc-editor.org/info/rfc5921>.
[RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations,
Administration, and Maintenance Framework for MPLS-Based
Transport Networks", RFC 6371, DOI 10.17487/RFC6371,
September 2011, <http://www.rfc-editor.org/info/rfc6371>.
[RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport
Profile (MPLS-TP) Survivability Framework", RFC 6372,
DOI 10.17487/RFC6372, September 2011,
<http://www.rfc-editor.org/info/rfc6372>.
10.2. Informative References
[EXP_ID_NAME_SPACE]
"Experiment ID Name Space",
<http://www.iana.org/assignments/ldp-namespaces/
ldp-namespaces.xhtml#ldp-namespaces-10>.
[EXT_BASIC_OPAQUE]
"LDP MP Opaque Value Element extended type",
<http://www.iana.org/assignments/ldp-namespaces/
ldp-namespaces.xhtml#ldp-namespaces-13>.
[FEC_TYPE_NAME_SPACE]
"Forwarding Equivalence Class (FEC) Type Name Space",
<http://www.iana.org/assignments/ldp-namespaces/
ldp-namespaces.xhtml#fec-type>.
[LDP_NAME_SPACE]
"Label Distribution Protocol (LDP) Parameters",
<http://www.iana.org/assignments/ldp-namespaces/
ldp-namespaces.xhtml>.
[MAC_FLUSH]
"MAC Flush Flags", <http://www.iana.org/assignments/ldp-
namespaces/ldp-namespaces.xhtml#mac-flush-flags>.
[MP_BASIC_OPAQUE]
"LDP MP Opaque Value Element basic type",
<http://www.iana.org/assignments/ldp-namespaces/
ldp-namespaces.xhtml#ldp-namespaces-11>.
[MP_STATUS_VALUE]
"LDP MP Opaque Value Element extended type",
<http://www.iana.org/assignments/ldp-namespaces/
ldp-namespaces.xhtml#ldp-namespaces-14>.
[MSG_TYPE_NAME_SPACE]
"Message Type Name Space",
<http://www.iana.org/assignments/ldp-namespaces/
ldp-namespaces.xhtml#ldp-namespaces-2>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<http://www.rfc-editor.org/info/rfc4271>.
[RFC4278] Bellovin, S. and A. Zinin, "Standards Maturity Variance
Regarding the TCP MD5 Signature Option (RFC 2385) and the
BGP-4 Specification", RFC 4278, DOI 10.17487/RFC4278,
January 2006, <http://www.rfc-editor.org/info/rfc4278>.
[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, DOI 10.17487/RFC6388, November 2011,
<http://www.rfc-editor.org/info/rfc6388>.
[RFC7361] Dutta, P., Balus, F., Stokes, O., Calvignac, G., and D.
Fedyk, "LDP Extensions for Optimized MAC Address
Withdrawal in a Hierarchical Virtual Private LAN Service
(H-VPLS)", RFC 7361, DOI 10.17487/RFC7361, September 2014,
<http://www.rfc-editor.org/info/rfc7361>.
[STATUS_CODE_NAME_SPACE]
"Status Code Name Space",
<http://www.iana.org/assignments/ldp-namespaces/
ldp-namespaces.xhtml#status-codes>.
[TLV_TYPE_NAME_SPACE]
"TLV Type Name Space", <http://www.iana.org/assignments/
ldp-namespaces/ldp-namespaces.xhtml#ldp-namespaces-4>.
Appendix A. LDP Label Distribution Procedures
This section specifies label distribution behavior in terms of LSR This section specifies label distribution behavior in terms of LSR
response to the following events: response to the following events:
- Receive Label Request Message; - Receive Label Request Message;
- Receive Label Mapping Message; - Receive Label Mapping Message;
- Receive Label Abort Request Message; - Receive Label Abort Request Message;
- Receive Label Release Message; - Receive Label Release Message;
- Receive Label Withdraw Message; - Receive Label Withdraw Message;
- Recognize new FEC; - Recognize new FEC;
skipping to change at page 99, line 35 skipping to change at page 102, line 30
The algorithms in this section use procedures defined in the MPLS The algorithms in this section use procedures defined in the MPLS
architecture specification RFC 3031 [RFC3031] for hop-by-hop routed architecture specification RFC 3031 [RFC3031] for hop-by-hop routed
traffic. These procedures are: traffic. These procedures are:
- Label Distribution procedure, which is performed by a downstream - Label Distribution procedure, which is performed by a downstream
LSR to determine when to distribute a label for a FEC to LDP LSR to determine when to distribute a label for a FEC to LDP
peers. The architecture defines four Label Distribution peers. The architecture defines four Label Distribution
procedures: procedures:
. Downstream Unsolicited Independent Control, called o Downstream Unsolicited Independent Control, called
PushUnconditional in RFC 3031 [RFC3031]. PushUnconditional in RFC 3031 [RFC3031].
. Downstream Unsolicited Ordered Control, called PushConditional o Downstream Unsolicited Ordered Control, called PushConditional
in RFC 3031 [RFC3031]. in RFC 3031 [RFC3031].
. Downstream On Demand Independent Control, called o Downstream On Demand Independent Control, called
PulledUnconditional in RFC 3031 [RFC3031]. PulledUnconditional in RFC 3031 [RFC3031].
. Downstream On Demand Ordered Control, called PulledConditional o Downstream On Demand Ordered Control, called PulledConditional
in RFC 3031 [RFC3031]. in RFC 3031 [RFC3031].
- Label Withdrawal procedure, which is performed by a downstream LSR - Label Withdrawal procedure, which is performed by a downstream LSR
to determine when to withdraw a FEC label mapping previously to determine when to withdraw a FEC label mapping previously
distributed to LDP peers. The architecture defines a single Label distributed to LDP peers. The architecture defines a single Label
Withdrawal procedure. Whenever an LSR breaks the binding between Withdrawal procedure. Whenever an LSR breaks the binding between
a label and a FEC, it MUST withdraw the FEC label mapping from all a label and a FEC, it MUST withdraw the FEC label mapping from all
LDP peers to which it has previously sent the mapping. LDP peers to which it has previously sent the mapping.
- Label Request procedure, which is performed by an upstream LSR to - Label Request procedure, which is performed by an upstream LSR to
determine when to explicitly request that a downstream LSR bind a determine when to explicitly request that a downstream LSR bind a
label to a FEC and send it the corresponding label mapping. The label to a FEC and send it the corresponding label mapping. The
architecture defines three Label Request procedures: architecture defines three Label Request procedures:
. Request Never. The LSR never requests a label. o Request Never. The LSR never requests a label.
. Request When Needed. The LSR requests a label whenever it o Request When Needed. The LSR requests a label whenever it
needs one. needs one.
. Request On Request. This procedure is used by non-label o Request On Request. This procedure is used by non-label
merging LSRs. The LSR requests a label when it receives a merging LSRs. The LSR requests a label when it receives a
request for one, in addition to whenever it needs one. request for one, in addition to whenever it needs one.
- Label Release procedure, which is performed by an upstream LSR to - Label Release procedure, which is performed by an upstream LSR to
determine when to release a previously received label mapping for determine when to release a previously received label mapping for
a FEC. The architecture defines two Label Release procedures: a FEC. The architecture defines two Label Release procedures:
. Conservative Label retention, called ReleaseOnChange in RFC o Conservative Label retention, called ReleaseOnChange in RFC
3031 [RFC3031]. 3031 [RFC3031].
. Liberal Label retention, called NoReleaseOnChange in RFC 3031 o Liberal Label retention, called NoReleaseOnChange in RFC 3031
[RFC3031]. [RFC3031].
- Label Use procedure, which is performed by an LSR to determine - Label Use procedure, which is performed by an LSR to determine
when to start using a FEC label for forwarding/switching. The when to start using a FEC label for forwarding/switching. The
architecture defines three Label Use procedures: architecture defines three Label Use procedures:
. Use Immediate. The LSR immediately uses a label received from o Use Immediate. The LSR immediately uses a label received from
a FEC next hop for forwarding/switching. a FEC next hop for forwarding/switching.
. Use If Loop Free. The LSR uses a FEC label received from a FEC o Use If Loop Free. The LSR uses a FEC label received from a FEC
next hop for forwarding/switching only if it has determined next hop for forwarding/switching only if it has determined
that by doing so it will not cause a forwarding loop. that by doing so it will not cause a forwarding loop.
. Use If Loop Not Detected. This procedure is the same as Use o Use If Loop Not Detected. This procedure is the same as Use
Immediate unless the LSR has detected a loop in the FEC LSP. Immediate unless the LSR has detected a loop in the FEC LSP.
Use of the FEC label for forwarding/switching will continue Use of the FEC label for forwarding/switching will continue
until the next hop for the FEC changes or the loop is no longer until the next hop for the FEC changes or the loop is no longer
detected. detected.
This version of LDP does not include a loop prevention mechanism; This version of LDP does not include a loop prevention mechanism;
therefore, the procedures below do not make use of the Use If Loop therefore, the procedures below do not make use of the Use If Loop
Free procedure. Free procedure.
- Label No Route procedure (called the NotAvailable procedure in RFC - Label No Route procedure (called the NotAvailable procedure in RFC
3031 [RFC3031]), which is performed by an upstream LSR to 3031 [RFC3031]), which is performed by an upstream LSR to
determine how to respond to a No Route notification from a determine how to respond to a No Route notification from a
downstream LSR in response to a request for a FEC label mapping. downstream LSR in response to a request for a FEC label mapping.
The architecture specification defines two Label No Route The architecture specification defines two Label No Route
procedures: procedures:
. Request Retry. The LSR should issue the label request at a o Request Retry. The LSR should issue the label request at a
later time. later time.
. No Request Retry. The LSR should assume that the downstream o No Request Retry. The LSR should assume that the downstream
LSR will provide a label mapping when the downstream LSR has a LSR will provide a label mapping when the downstream LSR has a
next hop, and it should not reissue the request. next hop, and it should not reissue the request.
10.1. A.1. Handling Label Distribution Events A.1. Handling Label Distribution Events
This section defines LDP label distribution procedures by specifying This section defines LDP label distribution procedures by specifying
an algorithm for each label distribution event. The requirement on an algorithm for each label distribution event. The requirement on
an LDP implementation is that its event handling must have the effect an LDP implementation is that its event handling must have the effect
specified by the algorithms. That is, an implementation need not specified by the algorithms. That is, an implementation need not
follow exactly the steps specified by the algorithms as long as the follow exactly the steps specified by the algorithms as long as the
effect is identical. effect is identical.
The algorithms for handling label distribution events share common The algorithms for handling label distribution events share common
actions. The specifications below package these common actions into actions. The specifications below package these common actions into
procedure units. Specifications for these common procedures are in procedure units. Specifications for these common procedures are in
their own Section, "Common Label Distribution Procedures", which their own Section, "Common Label Distribution Procedures", which
follows this. follows this.
An implementation would use data structures to store information An implementation would use data structures to store information
about protocol activity. This appendix specifies the information to about protocol activity. This appendix specifies the information to
be stored in sufficient detail to describe the algorithms, and be stored in sufficient detail to describe the algorithms, and
assumes the ability to retrieve the information as needed. It does assumes the ability to retrieve the information as needed. It does
not specify the details of the data structures. not specify the details of the data structures.
10.1.1. A.1.1. Receive Label Request A.1.1. Receive Label Request
Summary: Summary:
The response by an LSR to receipt of a FEC label request from an The response by an LSR to receipt of a FEC label request from an
LDP peer may involve one or more of the following actions: LDP peer may involve one or more of the following actions:
- Transmission of a notification message to the requesting LSR - Transmission of a notification message to the requesting LSR
indicating why a label mapping for the FEC cannot be provided; indicating why a label mapping for the FEC cannot be provided;
- Transmission of a FEC label mapping to the requesting LSR; - Transmission of a FEC label mapping to the requesting LSR;
skipping to change at page 105, line 8 skipping to change at page 108, line 5
A duplicate label request is considered a protocol error and A duplicate label request is considered a protocol error and
SHOULD be dropped by the receiving LSR (perhaps with a suitable SHOULD be dropped by the receiving LSR (perhaps with a suitable
notification returned to MsgSource). notification returned to MsgSource).
3. If the LSR is not merge-capable, this test will fail. 3. If the LSR is not merge-capable, this test will fail.
4. The Send_Label procedure may fail due to lack of label resources, 4. The Send_Label procedure may fail due to lack of label resources,
in which case the LSR SHOULD NOT perform the Label Use procedure. in which case the LSR SHOULD NOT perform the Label Use procedure.
10.1.2. A.1.2. Receive Label Mapping A.1.2. Receive Label Mapping
Summary: Summary:
The response by an LSR to receipt of a FEC label mapping from an LDP The response by an LSR to receipt of a FEC label mapping from an LDP
peer may involve one or more of the following actions: peer may involve one or more of the following actions:
- Transmission of a Label Release message for the FEC label to the - Transmission of a Label Release message for the FEC label to the
LDP peer; LDP peer;
- Transmission of Label Mapping messages for the FEC to one or more - Transmission of Label Mapping messages for the FEC to one or more
skipping to change at page 111, line 19 skipping to change at page 114, line 19
requests, fall through into the Downstream on Demand procedures requests, fall through into the Downstream on Demand procedures
in order to satisfy the pending requests. in order to satisfy the pending requests.
12. As determined by step LMp.1. 12. As determined by step LMp.1.
13. An LSR operating in Ordered Control mode may choose to skip at 13. An LSR operating in Ordered Control mode may choose to skip at
this stage the peer from which it received the advertisement this stage the peer from which it received the advertisement
that caused it to generate the label-map message. Doing so will that caused it to generate the label-map message. Doing so will
in effect provide a form of split-horizon. in effect provide a form of split-horizon.
10.1.3. A.1.3 Receive Label Abort Request A.1.3. Receive Label Abort Request
Summary: Summary:
When an LSR receives a Label Abort Request message from a peer, it When an LSR receives a Label Abort Request message from a peer, it
checks whether it has already responded to the label request in checks whether it has already responded to the label request in
question. If it has, it silently ignores the message. If it has question. If it has, it silently ignores the message. If it has
not, it sends the peer a Label Request Aborted Notification. In not, it sends the peer a Label Request Aborted Notification. In
addition, if it has a label request outstanding for the LSP in addition, if it has a label request outstanding for the LSP in
question to a downstream peer, it sends a Label Abort Request to question to a downstream peer, it sends a Label Abort Request to
the downstream peer to abort the LSP. the downstream peer to abort the LSP.
skipping to change at page 112, line 46 skipping to change at page 115, line 46
Notes: Notes:
1. LSR uses FEC and the Label Request message ID TLV carried by the 1. LSR uses FEC and the Label Request message ID TLV carried by the
label abort request to locate its record (if any) for the label abort request to locate its record (if any) for the
previously received label request from MsgSource. previously received label request from MsgSource.
2. If LSR has received a label mapping from NextHop, it should 2. If LSR has received a label mapping from NextHop, it should
behave as if it had advertised a label mapping to MsgSource and behave as if it had advertised a label mapping to MsgSource and
MsgSource has released it. MsgSource has released it.
10.1.4. A.1.4 Receive Label Release A.1.4. Receive Label Release
Summary: Summary:
When an LSR receives a Label Release message for a FEC from a When an LSR receives a Label Release message for a FEC from a
peer, it checks whether other peers hold the released label. If peer, it checks whether other peers hold the released label. If
none do, the LSR removes the label from forwarding/switching use, none do, the LSR removes the label from forwarding/switching use,
if it has not already done so, and if the LSR holds a label if it has not already done so, and if the LSR holds a label
mapping from the FEC next hop, it releases the label mapping. mapping from the FEC next hop, it releases the label mapping.
Context: Context:
skipping to change at page 114, line 37 skipping to change at page 117, line 37
other upstream LSR send it a new Label Request for FEC. other upstream LSR send it a new Label Request for FEC.
Whether or not to propagate the release is not a protocol issue. Whether or not to propagate the release is not a protocol issue.
Label distribution will operate properly whether or not the Label distribution will operate properly whether or not the
release is propagated. The decision to propagate or not should release is propagated. The decision to propagate or not should
take into consideration factors such as, whether labels are a take into consideration factors such as, whether labels are a
scarce resource in the operating environment, the importance of scarce resource in the operating environment, the importance of
keeping LSP setup latency low by keeping the amount of signaling keeping LSP setup latency low by keeping the amount of signaling
required small, and whether LSP setup is ingress-controlled or required small, and whether LSP setup is ingress-controlled or
egress-controlled in the operating environment. egress-controlled in the operating environment.
10.1.5. A.1.5 Receive Label Withdraw A.1.5. Receive Label Withdraw
Summary: Summary:
When an LSR receives a Label Withdraw message for a FEC from an When an LSR receives a Label Withdraw message for a FEC from an
LDP peer, it responds with a Label Release message and it removes LDP peer, it responds with a Label Release message and it removes
the label from any forwarding/switching use. If Ordered Control the label from any forwarding/switching use. If Ordered Control
is in use, the LSR sends a Label Withdraw message to each LDP peer is in use, the LSR sends a Label Withdraw message to each LDP peer
to which it had previously sent a label mapping for the FEC. If to which it had previously sent a label mapping for the FEC. If
the LSR is using Downstream on Demand label advertisement with the LSR is using Downstream on Demand label advertisement with
independent control, it then acts as if it had just recognized the independent control, it then acts as if it had just recognized the
skipping to change at page 116, line 17 skipping to change at page 119, line 17
2. LWd.7 handles the case where the LSR is using Downstream On 2. LWd.7 handles the case where the LSR is using Downstream On
Demand label distribution with independent control. In this Demand label distribution with independent control. In this
situation, the LSR should send a label request to the FEC next situation, the LSR should send a label request to the FEC next
hop as if it had just recognized the FEC. hop as if it had just recognized the FEC.
3. LWd.10 handles both label merging (one or more incoming labels 3. LWd.10 handles both label merging (one or more incoming labels
map to the same outgoing label) and no label merging (one label map to the same outgoing label) and no label merging (one label
maps to the outgoing label) cases. maps to the outgoing label) cases.
10.1.6. A.1.6 Recognize New FEC A.1.6. Recognize New FEC
Summary: Summary:
The response by an LSR to learning a new FEC via the routing table The response by an LSR to learning a new FEC via the routing table
may involve one or more of the following actions: may involve one or more of the following actions:
- Transmission of label mappings for the FEC to one or more LDP - Transmission of label mappings for the FEC to one or more LDP
peers; peers;
- Transmission of a label request for the FEC to the FEC next - Transmission of a label request for the FEC to the FEC next
skipping to change at page 119, line 9 skipping to change at page 122, line 9
label only if it had a previously received label request marked label only if it had a previously received label request marked
as pending. The LSR would have no such pending requests because as pending. The LSR would have no such pending requests because
it responds to any label request for an unknown FEC by sending it responds to any label request for an unknown FEC by sending
the requesting LSR a No Route notification and discarding the the requesting LSR a No Route notification and discarding the
label request; see LRq.3 label request; see LRq.3
3. If the LSR has a label for the FEC from the Next Hop, it should 3. If the LSR has a label for the FEC from the Next Hop, it should
behave as if it had just received the label from the Next Hop. behave as if it had just received the label from the Next Hop.
This occurs in the case of Liberal Label retention mode. This occurs in the case of Liberal Label retention mode.
10.1.7. A.1.7 Detect Change in FEC Next Hop A.1.7. Detect Change in FEC Next Hop
Summary: Summary:
The response by an LSR to a change in the next hop for a FEC may The response by an LSR to a change in the next hop for a FEC may
involve one or more of the following actions: involve one or more of the following actions:
- Removal of the label from the FEC's old next hop from - Removal of the label from the FEC's old next hop from
forwarding/switching use; forwarding/switching use;
- Transmission of label mapping messages for the FEC to one or - Transmission of label mapping messages for the FEC to one or
skipping to change at page 121, line 46 skipping to change at page 124, line 46
Label Mapping message where the LSR operating in Conservative Label Mapping message where the LSR operating in Conservative
Label retention mode may have released a label mapping received Label retention mode may have released a label mapping received
from the New Next Hop before it detected that the FEC next hop had from the New Next Hop before it detected that the FEC next hop had
changed. changed.
- Regardless of the Label Request procedure in use by the LSR, it - Regardless of the Label Request procedure in use by the LSR, it
MUST send a label request if the conditions in NH.13 hold. MUST send a label request if the conditions in NH.13 hold.
Therefore, it executes the Send_Label_Request procedure directly Therefore, it executes the Send_Label_Request procedure directly
rather than perform the LSR Label Request procedure. rather than perform the LSR Label Request procedure.
10.1.8. A.1.8. Receive Notification / Label Request Aborted A.1.8. Receive Notification / Label Request Aborted
Summary: Summary:
When an LSR receives a Label Request Aborted notification from an LDP When an LSR receives a Label Request Aborted notification from an LDP
peer, it records that the corresponding label request transaction, if peer, it records that the corresponding label request transaction, if
any, has completed. any, has completed.
Context: Context:
- LSR. The LSR handling the event. - LSR. The LSR handling the event.
skipping to change at page 122, line 32 skipping to change at page 125, line 32
LRqA.b Record that the label request for FEC has been aborted. LRqA.b Record that the label request for FEC has been aborted.
LRqA.c DONE. LRqA.c DONE.
Note: Note:
1. The LSR uses the FEC and RequestMessageID to locate its record, 1. The LSR uses the FEC and RequestMessageID to locate its record,
if any, of the outstanding label request abort. if any, of the outstanding label request abort.
10.1.9. A.1.9. Receive Notification / No Label Resources A.1.9. Receive Notification / No Label Resources
Summary: Summary:
When an LSR receives a No Label Resources notification from an LDP When an LSR receives a No Label Resources notification from an LDP
peer, it stops sending label request messages to the peer until it peer, it stops sending label request messages to the peer until it
receives a Label Resources Available Notification from the peer. receives a Label Resources Available Notification from the peer.
Context: Context:
LSR. The LSR handling the event. LSR. The LSR handling the event.
skipping to change at page 123, line 13 skipping to change at page 126, line 13
MsgSource. MsgSource.
NoRes.2 Record that label mapping for FEC from MsgSource is needed NoRes.2 Record that label mapping for FEC from MsgSource is needed
but that no label resources are available. but that no label resources are available.
NoRes.3 Set status record indicating it is not OK to send label NoRes.3 Set status record indicating it is not OK to send label
requests to MsgSource. requests to MsgSource.
NoRes.4 DONE. NoRes.4 DONE.
10.1.10. A.1.10. Receive Notification / No Route A.1.10. Receive Notification / No Route
Summary: Summary:
When an LSR receives a No Route notification from an LDP peer in When an LSR receives a No Route notification from an LDP peer in
response to a Label Request message, the Label No Route procedure response to a Label Request message, the Label No Route procedure
in use dictates its response. The LSR either will take no further in use dictates its response. The LSR either will take no further
action, or it will defer the label request by starting a timer and action, or it will defer the label request by starting a timer and
send another Label Request message to the peer when the timer send another Label Request message to the peer when the timer
later expires. later expires.
skipping to change at page 124, line 5 skipping to change at page 127, line 5
For Request Retry For Request Retry
1. Record deferred label request for FEC and Attributes 1. Record deferred label request for FEC and Attributes
to be sent to MsgSource. to be sent to MsgSource.
2. Start timeout. Goto NoNH.3. 2. Start timeout. Goto NoNH.3.
NoNH.3 DONE. NoNH.3 DONE.
10.1.11. A.1.11. Receive Notification / Loop Detected A.1.11. Receive Notification / Loop Detected
Summary: Summary:
When an LSR receives a Loop Detected Status Code from an LDP peer When an LSR receives a Loop Detected Status Code from an LDP peer
in response to a Label Request message or a Label Mapping message, in response to a Label Request message or a Label Mapping message,
it behaves as if it had received a No Route notification. it behaves as if it had received a No Route notification.
Context: Context:
See "Receive Notification / No Route". See "Receive Notification / No Route".
skipping to change at page 124, line 29 skipping to change at page 127, line 29
See "Receive Notification / No Route". See "Receive Notification / No Route".
Note: Note:
1. When the Loop Detected notification is in response to a Label 1. When the Loop Detected notification is in response to a Label
Request message, it arrives in a Status Code TLV in a Request message, it arrives in a Status Code TLV in a
Notification message. When it is in response to a Label Mapping Notification message. When it is in response to a Label Mapping
message, it arrives in a Status Code TLV in a Label Release message, it arrives in a Status Code TLV in a Label Release
message. message.
10.1.12. A.1.12. Receive Notification / Label Resources Available A.1.12. Receive Notification / Label Resources Available
Summary: Summary:
When an LSR receives a Label Resources Available notification from When an LSR receives a Label Resources Available notification from
an LDP peer, it resumes sending label requests to the peer. an LDP peer, it resumes sending label requests to the peer.
Context: Context:
- LSR. The LSR handling the event. - LSR. The LSR handling the event.
skipping to change at page 125, line 19 skipping to change at page 128, line 19
Res.4 Execute procedure Send_Label_Request (MsgSource, FEC, Res.4 Execute procedure Send_Label_Request (MsgSource, FEC,
SAttributes). If the procedure fails, terminate iteration. SAttributes). If the procedure fails, terminate iteration.
Res.5 Delete record that no resources are available for a label Res.5 Delete record that no resources are available for a label
mapping for FEC needed from MsgSource. mapping for FEC needed from MsgSource.
Res.6 Res.6 End iteration from Res.2. Res.6 Res.6 End iteration from Res.2.
Res.7 DONE. Res.7 DONE.
10.1.13. A.1.13. Detect Local Label Resources Have Become Available A.1.13. Detect Local Label Resources Have Become Available
Summary: Summary:
After an LSR has sent a No Label Resources notification to an LDP After an LSR has sent a No Label Resources notification to an LDP
peer, when label resources later become available it sends a Label peer, when label resources later become available it sends a Label
Resources Available notification to each such peer. Resources Available notification to each such peer.
Context: Context:
- LSR. The LSR handling the event. - LSR. The LSR handling the event.
skipping to change at page 126, line 18 skipping to change at page 129, line 18
ResA.8 End iteration from ResA.5 ResA.8 End iteration from ResA.5
ResA.9 DONE. ResA.9 DONE.
Note: Note:
1. Iteration ResA.5 through ResA.8 handles the situation where the 1. Iteration ResA.5 through ResA.8 handles the situation where the
LSR is using Downstream Unsolicited label distribution and was LSR is using Downstream Unsolicited label distribution and was
previously unable to allocate a label for a FEC. previously unable to allocate a label for a FEC.
10.1.14. A.1.14. LSR Decides to No Longer Label Switch a FEC A.1.14. LSR Decides to No Longer Label Switch a FEC
Summary: Summary:
An LSR may unilaterally decide to no longer label switch a FEC for An LSR may unilaterally decide to no longer label switch a FEC for
an LDP peer. An LSR that does so MUST send a Label Withdraw an LDP peer. An LSR that does so MUST send a Label Withdraw
message for the FEC to the peer. message for the FEC to the peer.
Context: Context:
- Peer. The peer. - Peer. The peer.
skipping to change at page 127, line 5 skipping to change at page 130, line 5
DONE. DONE.
Note: Note:
1. The LSR may remove the label from forwarding/switching use as 1. The LSR may remove the label from forwarding/switching use as
part of this event or as part of processing the Label Release part of this event or as part of processing the Label Release
from the peer in response to the label withdraw. If the LSR from the peer in response to the label withdraw. If the LSR
doesn't wait for the Label Release message from the peer, it doesn't wait for the Label Release message from the peer, it
SHOULD NOT reuse the label until it receives the Label Release. SHOULD NOT reuse the label until it receives the Label Release.
10.1.15. A.1.15. Timeout of Deferred Label Request A.1.15. Timeout of Deferred Label Request
Summary: Summary:
Label requests are deferred in response to No Route and Loop Label requests are deferred in response to No Route and Loop
Detected notifications. When a deferred FEC label request for a Detected notifications. When a deferred FEC label request for a
peer times out, the LSR sends the label request. peer times out, the LSR sends the label request.
Context: Context:
- LSR. The LSR handling the event. - LSR. The LSR handling the event.
skipping to change at page 127, line 36 skipping to change at page 130, line 36
TO.1 Retrieve the record of the deferred label request. TO.1 Retrieve the record of the deferred label request.
TO.2 Is Peer the next hop for FEC? TO.2 Is Peer the next hop for FEC?
If not, goto TO.4. If not, goto TO.4.
TO.3 Execute procedure Send_Label_Request (Peer, FEC). TO.3 Execute procedure Send_Label_Request (Peer, FEC).
TO.4 DONE. TO.4 DONE.
10.2. A.2. Common Label Distribution Procedures A.2. Common Label Distribution Procedures
This section specifies utility procedures used by the algorithms that This section specifies utility procedures used by the algorithms that
handle label distribution events. handle label distribution events.
10.2.1. A.2.1. Send_Label A.2.1. Send_Label
Summary: Summary:
The Send_Label procedure allocates a label for a FEC for an LDP The Send_Label procedure allocates a label for a FEC for an LDP
peer, if possible, and sends a label mapping for the FEC to the peer, if possible, and sends a label mapping for the FEC to the
peer. If the LSR is unable to allocate the label and if it has a peer. If the LSR is unable to allocate the label and if it has a
pending label request from the peer, it sends the LDP peer a No pending label request from the peer, it sends the LDP peer a No
Label Resources notification. Label Resources notification.
Parameters: Parameters:
skipping to change at page 129, line 16 skipping to change at page 132, line 16
but no-label-resources. (See Note 1.) but no-label-resources. (See Note 1.)
SL.14 Return failure. SL.14 Return failure.
Note: Note:
1. SL.13 handles the case of Downstream Unsolicited label 1. SL.13 handles the case of Downstream Unsolicited label
distribution when the LSR is unable to allocate a label for a FEC distribution when the LSR is unable to allocate a label for a FEC
to send to a Peer. to send to a Peer.
10.2.2. A.2.2. Send_Label_Request A.2.2. Send_Label_Request
Summary: Summary:
An LSR uses the Send_Label_Request procedure to send a request for An LSR uses the Send_Label_Request procedure to send a request for
a label for a FEC to an LDP peer if currently permitted to do so. a label for a FEC to an LDP peer if currently permitted to do so.
Parameters: Parameters:
- Peer. The LDP peer to which the label request is to be sent. - Peer. The LDP peer to which the label request is to be sent.
skipping to change at page 130, line 18 skipping to change at page 133, line 18
SLRq.7 Return failure. SLRq.7 Return failure.
Note: Note:
1. If the LSR is a non-merging LSR, it must distinguish between 1. If the LSR is a non-merging LSR, it must distinguish between
attempts to send label requests for a FEC triggered by different attempts to send label requests for a FEC triggered by different
upstream LDP peers from duplicate requests. This procedure will upstream LDP peers from duplicate requests. This procedure will
not send a duplicate label request. not send a duplicate label request.
10.2.3. A.2.3. Send_Label_Withdraw A.2.3. Send_Label_Withdraw
Summary: Summary:
An LSR uses the Send_Label_Withdraw procedure to withdraw a label An LSR uses the Send_Label_Withdraw procedure to withdraw a label
for a FEC from an LDP peer. To do this, the LSR sends a Label for a FEC from an LDP peer. To do this, the LSR sends a Label
Withdraw message to the peer. Withdraw message to the peer.
Parameters: Parameters:
- Peer. The LDP peer to which the label withdraw is to be sent. - Peer. The LDP peer to which the label withdraw is to be sent.
skipping to change at page 130, line 46 skipping to change at page 133, line 46
- LSR. The LSR executing the procedure. - LSR. The LSR executing the procedure.
Algorithm: Algorithm:
SWd.1 Execute procedure Send_Message (Peer, Label Withdraw, FEC, SWd.1 Execute procedure Send_Message (Peer, Label Withdraw, FEC,
Label). Label).
SWd.2 Record that label withdraw for FEC has been sent to Peer and SWd.2 Record that label withdraw for FEC has been sent to Peer and
mark it as outstanding. mark it as outstanding.
10.2.4. A.2.4. Send_Notification A.2.4. Send_Notification
Summary: Summary:
An LSR uses the Send_Notification procedure to send an LDP peer a An LSR uses the Send_Notification procedure to send an LDP peer a
Notification message. Notification message.
Parameters Parameters
- Peer. The LDP peer to which the Notification message is to be - Peer. The LDP peer to which the Notification message is to be
sent. sent.
skipping to change at page 131, line 20 skipping to change at page 134, line 20
- Status. Status code to be included in the Notification message. - Status. Status code to be included in the Notification message.
Additional Context: Additional Context:
None. None.
Algorithm: Algorithm:
SNt.1 Execute procedure Send_Message (Peer, Notification, Status) SNt.1 Execute procedure Send_Message (Peer, Notification, Status)
10.2.5. A.2.5. Send_Message A.2.5. Send_Message
Summary: Summary:
An LSR uses the Send_Message procedure to send an LDP peer an LDP An LSR uses the Send_Message procedure to send an LDP peer an LDP
message. message.
Parameters: Parameters:
Peer. The LDP peer to which the message is to be sent. Peer. The LDP peer to which the message is to be sent.
skipping to change at page 131, line 44 skipping to change at page 134, line 44
Additional Context: Additional Context:
None. None.
Algorithm: Algorithm:
This procedure is the means by which an LSR sends an LDP message This procedure is the means by which an LSR sends an LDP message
of the specified type to the specified LDP peer. of the specified type to the specified LDP peer.
10.2.6. A.2.6. Check_Received_Attributes A.2.6. Check_Received_Attributes
Summary: Summary:
Check the attributes received in a Label Mapping or Label Request Check the attributes received in a Label Mapping or Label Request
message. If the attributes include a Hop Count or Path Vector, message. If the attributes include a Hop Count or Path Vector,
perform a Loop Detection check. If a loop is detected, cause a perform a Loop Detection check. If a loop is detected, cause a
Loop Detected Notification message to be sent to MsgSource. Loop Detected Notification message to be sent to MsgSource.
Parameters: Parameters:
skipping to change at page 133, line 7 skipping to change at page 136, line 7
CRa.9 DONE. CRa.9 DONE.
Note: Note:
1. When the attributes being checked were received in a Label 1. When the attributes being checked were received in a Label
Mapping message, the LSR sends the Loop Detected notification in Mapping message, the LSR sends the Loop Detected notification in
a Status Code TLV in a Label Release message. (See a Status Code TLV in a Label Release message. (See
Section "Receive Label Mapping".) Section "Receive Label Mapping".)
10.2.7. A.2.7. Prepare_Label_Request_Attributes A.2.7. Prepare_Label_Request_Attributes
Summary: Summary:
This procedure is used whenever a Label Request is to be sent to a This procedure is used whenever a Label Request is to be sent to a
Peer to compute the Hop Count and Path Vector, if any, to include Peer to compute the Hop Count and Path Vector, if any, to include
in the message. in the message.
Parameters: Parameters:
Peer. The LDP peer to which the message is to be sent. Peer. The LDP peer to which the message is to be sent.
skipping to change at page 134, line 38 skipping to change at page 137, line 38
PRqA.14 DONE. PRqA.14 DONE.
Notes: Notes:
1. The link with Peer may require that Hop Count be included in 1. The link with Peer may require that Hop Count be included in
Label Request messages; for example, see RFC 3035 [RFC3034] and Label Request messages; for example, see RFC 3035 [RFC3034] and
RFC 3034 [RFC3034]. RFC 3034 [RFC3034].
2. For hop count arithmetic, unknown + 1 = unknown. 2. For hop count arithmetic, unknown + 1 = unknown.
10.2.8. A.2.8. Prepare_Label_Mapping_Attributes A.2.8. Prepare_Label_Mapping_Attributes
Summary: Summary:
This procedure is used whenever a Label Mapping is to be sent to a This procedure is used whenever a Label Mapping is to be sent to a
Peer to compute the Hop Count and Path Vector, if any, to include Peer to compute the Hop Count and Path Vector, if any, to include
in the message. in the message.
Parameters: Parameters:
- Peer. The LDP peer to which the message is to be sent. - Peer. The LDP peer to which the message is to be sent.
skipping to change at page 137, line 18 skipping to change at page 140, line 18
2. If the LSR is at the edge of a cloud of LSRs that do not perform 2. If the LSR is at the edge of a cloud of LSRs that do not perform
TTL-decrement and it is propagating the Label Mapping message TTL-decrement and it is propagating the Label Mapping message
upstream into the cloud, it sets the Hop Count to 1 so that Hop upstream into the cloud, it sets the Hop Count to 1 so that Hop
Count across the cloud is calculated properly. This ensures Count across the cloud is calculated properly. This ensures
proper TTL management for packets forwarded across the part of proper TTL management for packets forwarded across the part of
the LSP that passes through the cloud. the LSP that passes through the cloud.
3. For hop count arithmetic, unknown + 1 = unknown. 3. For hop count arithmetic, unknown + 1 = unknown.
11. IANA Considerations Acknowledgments
There are no requests for IANA actions in this document.
Note to the RFC Editor - this section can be removed before
publication.
12. References
12.1. Normative References
[ASSIGNED_AF]
"IANA Assigned Address Families",
<http://www.iana.org/assignments/address-family-numbers>.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
DOI 10.17487/RFC1321, April 1992,
<http://www.rfc-editor.org/info/rfc1321>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998,
<http://www.rfc-editor.org/info/rfc2328>.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, DOI 10.17487/RFC2385, August
1998, <http://www.rfc-editor.org/info/rfc2385>.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2434,
DOI 10.17487/RFC2434, October 1998,
<http://www.rfc-editor.org/info/rfc2434>.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, DOI 10.17487/RFC2702, September 1999,
<http://www.rfc-editor.org/info/rfc2702>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001,
<http://www.rfc-editor.org/info/rfc3031>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<http://www.rfc-editor.org/info/rfc3032>.
[RFC3034] Conta, A., Doolan, P., and A. Malis, "Use of Label
Switching on Frame Relay Networks Specification",
RFC 3034, DOI 10.17487/RFC3034, January 2001,
<http://www.rfc-editor.org/info/rfc3034>.
[RFC3035] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E.,
Swallow, G., Rekhter, Y., and P. Doolan, "MPLS using LDP
and ATM VC Switching", RFC 3035, DOI 10.17487/RFC3035,
January 2001, <http://www.rfc-editor.org/info/rfc3035>.
[RFC3037] Thomas, B. and E. Gray, "LDP Applicability", RFC 3037,
DOI 10.17487/RFC3037, January 2001,
<http://www.rfc-editor.org/info/rfc3037>.
[RFC3988] Black, B. and K. Kompella, "Maximum Transmission Unit
Signalling Extensions for the Label Distribution
Protocol", RFC 3988, DOI 10.17487/RFC3988, January 2005,
<http://www.rfc-editor.org/info/rfc3988>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed.,
"Requirements for Operations, Administration, and
Maintenance (OAM) in MPLS Transport Networks", RFC 5860,
DOI 10.17487/RFC5860, May 2010,
<http://www.rfc-editor.org/info/rfc5860>.
[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
L., and L. Berger, "A Framework for MPLS in Transport
Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010,
<http://www.rfc-editor.org/info/rfc5921>.
[RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations,
Administration, and Maintenance Framework for MPLS-Based
Transport Networks", RFC 6371, DOI 10.17487/RFC6371,
September 2011, <http://www.rfc-editor.org/info/rfc6371>.
[RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport
Profile (MPLS-TP) Survivability Framework", RFC 6372,
DOI 10.17487/RFC6372, September 2011,
<http://www.rfc-editor.org/info/rfc6372>.
12.2. Informative References
[EXP_ID_NAME_SPACE]
"Experiment ID Name Space",
<http://www.iana.org/assignments/ldp-namespaces/
ldp-namespaces.xhtml#ldp-namespaces-10>.
[EXT_BASIC_OPAQUE]
"LDP MP Opaque Value Element extended type",
<http://www.iana.org/assignments/ldp-namespaces/
ldp-namespaces.xhtml#ldp-namespaces-13>.
[FEC_TYPE_NAME_SPACE]
"Forwarding Equivalence Class (FEC) Type Name Space",
<http://www.iana.org/assignments/ldp-namespaces/
ldp-namespaces.xhtml#fec-type>.
[LDP_NAME_SPACE]
"Label Distribution Protocol (LDP) Parameters",
<http://www.iana.org/assignments/ldp-namespaces/
ldp-namespaces.xhtml>.
[MAC_FLUSH]
"MAC Flush Flags", <http://www.iana.org/assignments/ldp-
namespaces/ldp-namespaces.xhtml#mac-flush-flags>.
[MP_BASIC_OPAQUE]
"LDP MP Opaque Value Element basic type",
<http://www.iana.org/assignments/ldp-namespaces/
ldp-namespaces.xhtml#ldp-namespaces-11>.
[MP_STATUS_VALUE] The editors of this document relies heavily on, and would like to
"LDP MP Opaque Value Element extended type", thank, everyone that contributed to the develoment and improvement of
<http://www.iana.org/assignments/ldp-namespaces/ the LDP Specification.
ldp-namespaces.xhtml#ldp-namespaces-14>.
[MSG_TYPE_NAME_SPACE] This document is produced as part of advancing the LDP specification
"Message Type Name Space", to Internet Standard status. The predessor (RFC 5036) was published
<http://www.iana.org/assignments/ldp-namespaces/ as Draft Standard October 2007. It was produced by the MPLS Working
ldp-namespaces.xhtml#ldp-namespaces-2>. Group of the IETF and was jointly authored by Loa Andersson, Bob
Thomas and Ina Minei.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Since the Draft Standard version was published IETF has abandoned the
Border Gateway Protocol 4 (BGP-4)", RFC 4271, 3 steps standards ladder. Now there is only proposed standard (PS)
DOI 10.17487/RFC4271, January 2006, and Internet Standard (IS). This is part of the motivation to make
<http://www.rfc-editor.org/info/rfc4271>. the effort to bring the LDP specification to Internet Standard.
[RFC4278] Bellovin, S. and A. Zinin, "Standards Maturity Variance The LDP specification was originally published as RFC 3036 in January
Regarding the TCP MD5 Signature Option (RFC 2385) and the 2001. It was produced by the MPLS Working Group of the IETF and was
BGP-4 Specification", RFC 4278, DOI 10.17487/RFC4278, jointly authored by Loa Andersson, Paul Doolan, Nancy Feldman, Andre
January 2006, <http://www.rfc-editor.org/info/rfc4278>. Fredette, and Bob Thomas.
[RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. The ideas and text in RFC 3036 were collected from a number of
Thomas, "Label Distribution Protocol Extensions for Point- sources. We would like to thank Rick Boivie, Ross Callon, Alex
to-Multipoint and Multipoint-to-Multipoint Label Switched Conta, Eric Gray, Yoshihiro Ohba, Eric Rosen, Bernard Suter, Yakov
Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, Rekhter, and Arun Viswanathan for their input for RFC 3036.
<http://www.rfc-editor.org/info/rfc6388>.
[RFC7361] Dutta, P., Balus, F., Stokes, O., Calvignac, G., and D. The authors would like to thank Eric Gray, David Black, and Sam
Fedyk, "LDP Extensions for Optimized MAC Address Hartman for their input to and review of RFC 5036. That input has
Withdrawal in a Hierarchical Virtual Private LAN Service been of great help also for the current document.
(H-VPLS)", RFC 7361, DOI 10.17487/RFC7361, September 2014,
<http://www.rfc-editor.org/info/rfc7361>.
[STATUS_CODE_NAME_SPACE] In addition, the authors would like to thank the members of the MPLS
"Status Code Name Space", Working Group for their ideas and the support they have given to this
<http://www.iana.org/assignments/ldp-namespaces/ document, and in particular, to Eric Rosen, Luca Martini, Markus
ldp-namespaces.xhtml#status-codes>. Jork, Mark Duffy, Vach Kompella, Kishore Tiruveedhula, Rama
Ramakrishnan, Nick Weeds, Adrian Farrel, and Andy Malis.
[TLV_TYPE_NAME_SPACE] Editor note - this section is still work in progress.
"TLV Type Name Space", <http://www.iana.org/assignments/
ldp-namespaces/ldp-namespaces.xhtml#ldp-namespaces-4>.
Authors' Addresses Authors' Addresses
Xia Chen Xia Chen
Huawei Technologies Huawei Technologies
Email: jescia.chenxia@huawei.com Email: jescia.chenxia@huawei.com
Loa Andersson Loa Andersson
Huawei Technologies Huawei Technologies
 End of changes. 66 change blocks. 
270 lines changed or deleted 268 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/