--- 1/draft-ijln-mpls-rfc5036bis-01.txt 2016-04-07 14:16:01.566644870 -0700 +++ 2/draft-ijln-mpls-rfc5036bis-02.txt 2016-04-07 14:16:01.826651381 -0700 @@ -1,24 +1,24 @@ Network Working Group X. Chen Internet-Draft L. Andersson Intended status: Standards Track Huawei Technologies -Expires: September 19, 2016 N. Leymann +Expires: October 9, 2016 N. Leymann Deutsche Telekom I. Minei Google K. Raza Cisco Systems, Inc. - March 18, 2016 + April 7, 2016 LDP Specification - draft-ijln-mpls-rfc5036bis-01.txt + draft-ijln-mpls-rfc5036bis-02.txt Abstract The architecture for Multiprotocol Label Switching (MPLS) is described in RFC 3031. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such @@ -34,21 +34,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. 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 @@ -109,21 +109,21 @@ 3.6.2.1. Conservative Label Retention Mode . . . . . . . . 23 3.6.2.2. Liberal Label Retention Mode . . . . . . . . . . 23 3.6.3. Label Advertisement Mode . . . . . . . . . . . . . . 24 3.7. LDP Identifiers and Next Hop Addresses . . . . . . . . . 24 3.8. Loop Detection . . . . . . . . . . . . . . . . . . . . . 24 3.8.1. Label Request Message . . . . . . . . . . . . . . . . 25 3.8.2. Label Mapping Message . . . . . . . . . . . . . . . . 26 3.8.3. Discussion . . . . . . . . . . . . . . . . . . . . . 28 3.9. Authenticity and Integrity of LDP Messages . . . . . . . 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.1. LDP PDUs . . . . . . . . . . . . . . . . . . . . . . . . 31 4.2. LDP Procedures . . . . . . . . . . . . . . . . . . . . . 32 4.3. Type-Length-Value Encoding . . . . . . . . . . . . . . . 33 4.4. TLV Encodings for Commonly Used Parameters . . . . . . . 35 4.4.1. FEC TLV . . . . . . . . . . . . . . . . . . . . . . . 35 4.4.1.1. FEC Procedures . . . . . . . . . . . . . . . . . 37 4.4.2. Label TLVs . . . . . . . . . . . . . . . . . . . . . 37 4.4.2.1. Generic Label TLV . . . . . . . . . . . . . . . . 37 4.4.2.2. ATM Label TLV . . . . . . . . . . . . . . . . . . 38 @@ -135,21 +135,21 @@ 4.4.5.1. Path Vector Procedures . . . . . . . . . . . . . 44 4.4.6. Status TLV . . . . . . . . . . . . . . . . . . . . . 45 4.5. LDP Messages . . . . . . . . . . . . . . . . . . . . . . 47 4.5.1. Notification Message . . . . . . . . . . . . . . . . 49 4.5.1.1. Notification Message Procedures . . . . . . . . . 50 4.5.1.2. Events Signaled by Notification Messages . . . . 51 4.5.2. Hello Message . . . . . . . . . . . . . . . . . . . . 53 4.5.2.1. Hello Message Procedures . . . . . . . . . . . . 56 4.5.3. Initialization Message . . . . . . . . . . . . . . . 57 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.5. Address Message . . . . . . . . . . . . . . . . . . . 67 4.5.5.1. Address Message Procedures . . . . . . . . . . . 68 4.5.6. Address Withdraw Message . . . . . . . . . . . . . . 69 4.5.6.1. Address Withdraw Message Procedures . . . . . . . 70 4.5.7. Label Mapping Message . . . . . . . . . . . . . . . . 70 4.5.7.1. Label Mapping Message Procedures . . . . . . . . 71 4.5.8. Label Request Message . . . . . . . . . . . . . . . . 74 4.5.8.1. Label Request Message Procedures . . . . . . . . 75 4.5.9. Label Abort Request Message . . . . . . . . . . . . . 77 @@ -174,53 +174,51 @@ 5.2. TLV Type Name Space . . . . . . . . . . . . . . . . . . . 92 5.3. FEC Type Name Space . . . . . . . . . . . . . . . . . . . 92 5.4. Status Code Name Space . . . . . . . . . . . . . . . . . 92 5.5. Experiment ID Name Space . . . . . . . . . . . . . . . . 93 6. Security Considerations . . . . . . . . . . . . . . . . . . . 93 6.1. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . 93 6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 94 6.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 95 7. Areas for Future Study . . . . . . . . . . . . . . . . . . . 96 8. Changes from RFC 5036 . . . . . . . . . . . . . . . . . . . . 97 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 97 - 10. Appendix A. LDP Label Distribution Procedures . . . . . . . 98 - 10.1. A.1. Handling Label Distribution Events . . . . . . . . 101 - 10.1.1. A.1.1. Receive Label Request . . . . . . . . . . . 101 - 10.1.2. A.1.2. Receive Label Mapping . . . . . . . . . . . 105 - 10.1.3. A.1.3 Receive Label Abort Request . . . . . . . . . 111 - 10.1.4. A.1.4 Receive Label Release . . . . . . . . . . . . 112 - 10.1.5. A.1.5 Receive Label Withdraw . . . . . . . . . . . . 114 - 10.1.6. A.1.6 Recognize New FEC . . . . . . . . . . . . . . 116 - 10.1.7. A.1.7 Detect Change in FEC Next Hop . . . . . . . . 119 - 10.1.8. A.1.8. Receive Notification / Label Request Aborted 121 - 10.1.9. A.1.9. Receive Notification / No Label Resources . 122 - 10.1.10. A.1.10. Receive Notification / No Route . . . . . . 123 - 10.1.11. A.1.11. Receive Notification / Loop Detected . . . 124 - 10.1.12. A.1.12. Receive Notification / Label Resources - Available . . . . . . . . . . . . . . . . . . . . . 124 - 10.1.13. A.1.13. Detect Local Label Resources Have Become - Available . . . . . . . . . . . . . . . . . . . . . 125 - 10.1.14. A.1.14. LSR Decides to No Longer Label Switch a FEC 126 - 10.1.15. A.1.15. Timeout of Deferred Label Request . . . . . 127 - 10.2. A.2. Common Label Distribution Procedures . . . . . . . 127 - 10.2.1. A.2.1. Send_Label . . . . . . . . . . . . . . . . . 127 - 10.2.2. A.2.2. Send_Label_Request . . . . . . . . . . . . . 129 - 10.2.3. A.2.3. Send_Label_Withdraw . . . . . . . . . . . . 130 - 10.2.4. A.2.4. Send_Notification . . . . . . . . . . . . . 130 - 10.2.5. A.2.5. Send_Message . . . . . . . . . . . . . . . . 131 - 10.2.6. A.2.6. Check_Received_Attributes . . . . . . . . . 131 - 10.2.7. A.2.7. Prepare_Label_Request_Attributes . . . . . . 133 - 10.2.8. A.2.8. Prepare_Label_Mapping_Attributes . . . . . . 134 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 137 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 137 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 137 - 12.2. Informative References . . . . . . . . . . . . . . . . . 139 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 97 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 98 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 98 + 10.2. Informative References . . . . . . . . . . . . . . . . . 100 + Appendix A. LDP Label Distribution Procedures . . . . . . . . . 101 + A.1. Handling Label Distribution Events . . . . . . . . . . . 104 + A.1.1. Receive Label Request . . . . . . . . . . . . . . . . 104 + A.1.2. Receive Label Mapping . . . . . . . . . . . . . . . . 108 + A.1.3. Receive Label Abort Request . . . . . . . . . . . . . 114 + A.1.4. Receive Label Release . . . . . . . . . . . . . . . . 115 + A.1.5. Receive Label Withdraw . . . . . . . . . . . . . . . 117 + A.1.6. Recognize New FEC . . . . . . . . . . . . . . . . . . 119 + A.1.7. Detect Change in FEC Next Hop . . . . . . . . . . . . 122 + A.1.8. Receive Notification / Label Request Aborted . . . . 124 + A.1.9. Receive Notification / No Label Resources . . . . . . 125 + A.1.10. Receive Notification / No Route . . . . . . . . . . . 126 + A.1.11. Receive Notification / Loop Detected . . . . . . . . 127 + A.1.12. Receive Notification / Label Resources Available . . 127 + A.1.13. Detect Local Label Resources Have Become Available . 128 + A.1.14. LSR Decides to No Longer Label Switch a FEC . . . . . 129 + A.1.15. Timeout of Deferred Label Request . . . . . . . . . . 130 + A.2. Common Label Distribution Procedures . . . . . . . . . . 130 + A.2.1. Send_Label . . . . . . . . . . . . . . . . . . . . . 130 + A.2.2. Send_Label_Request . . . . . . . . . . . . . . . . . 132 + A.2.3. Send_Label_Withdraw . . . . . . . . . . . . . . . . . 133 + A.2.4. Send_Notification . . . . . . . . . . . . . . . . . . 133 + A.2.5. Send_Message . . . . . . . . . . . . . . . . . . . . 134 + A.2.6. Check_Received_Attributes . . . . . . . . . . . . . . 134 + A.2.7. Prepare_Label_Request_Attributes . . . . . . . . . . 136 + A.2.8. Prepare_Label_Mapping_Attributes . . . . . . . . . . 137 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 140 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 141 1. Editors notes - this section will be removed before publication This entire section will be removed before publication. 1.1. Scope of RFC5036bis work The goal of this document is to take the LDP specification to Internet Standard. @@ -4170,21 +4168,21 @@ then forwards the resulting packet to Rd." 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]. 5. RFC 5036 IANA Considerations Note: In version -00 of this document does only minimal changes to the RFC 5036 IANA considerationns. The author believe that some 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 will be merged. The LDP specification defines the following name spaces that are managed by IANA and found at [LDP_NAME_SPACE]: - Message Type Name Space, found at [MSG_TYPE_NAME_SPACE] - TLV Type Name Space, found at [TLV_TYPE_NAME_SPACE] - FEC Type Name Space, found at [FEC_TYPE_NAME_SPACE] - Status Code Name Space, found at [STATUS_CODE_NAME_SPACE] @@ -4509,60 +4507,190 @@ 1. Some editorial changes has been made, e.g. internal references is more frequently used, some implicit lists has been replaced by tables, e.g. for Optional Parameters carried in LDP messages. 2. The refrence to CR-LDP has been removed. 3. References to the LDP registries create outside the LDP Specification has been added. -9. Acknowledgments +9. IANA Considerations - The editors of this document relies heavily on, and would like to - thank, everyone that contributed to the develoment and improvement of - the LDP Specification. + There are no requests for IANA actions in this document. - This document is produced as part of advancing the LDP specification - to Internet Standard status. The predessor (RFC 5036) was published - 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. + Note to the RFC Editor - this section can be removed before + publication. - Since the Draft Standard version was published IETF has abandoned the - 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. +10. References - The LDP specification was originally published as RFC 3036 in January - 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. +10.1. Normative References - The ideas and text in RFC 3036 were collected from a number of - sources. We would like to thank Rick Boivie, Ross Callon, Alex - Conta, Eric Gray, Yoshihiro Ohba, Eric Rosen, Bernard Suter, Yakov - Rekhter, and Arun Viswanathan for their input for RFC 3036. + [ASSIGNED_AF] + "IANA Assigned Address Families", + . - The authors would like to thank Eric Gray, David Black, and Sam - Hartman for their input to and review of RFC 5036. That input has - been of great help also for the current document. + [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, + DOI 10.17487/RFC1321, April 1992, + . - In addition, the authors would like to thank the members of the MPLS - Working Group for their ideas and the support they have given to this - document, and in particular, to Eric Rosen, Luca Martini, Markus - Jork, Mark Duffy, Vach Kompella, Kishore Tiruveedhula, Rama - Ramakrishnan, Nick Weeds, Adrian Farrel, and Andy Malis. + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . - 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, + . -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, . + + [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", RFC 2434, + DOI 10.17487/RFC2434, October 1998, + . + + [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, + . + + [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol + Label Switching Architecture", RFC 3031, + DOI 10.17487/RFC3031, January 2001, + . + + [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, + . + + [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, + . + + [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, . + + [RFC3037] Thomas, B. and E. Gray, "LDP Applicability", RFC 3037, + DOI 10.17487/RFC3037, January 2001, + . + + [RFC3988] Black, B. and K. Kompella, "Maximum Transmission Unit + Signalling Extensions for the Label Distribution + Protocol", RFC 3988, DOI 10.17487/RFC3988, January 2005, + . + + [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, + . + + [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, + . + + [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, + . + + [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, . + + [RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport + Profile (MPLS-TP) Survivability Framework", RFC 6372, + DOI 10.17487/RFC6372, September 2011, + . + +10.2. Informative References + + [EXP_ID_NAME_SPACE] + "Experiment ID Name Space", + . + + [EXT_BASIC_OPAQUE] + "LDP MP Opaque Value Element extended type", + . + + [FEC_TYPE_NAME_SPACE] + "Forwarding Equivalence Class (FEC) Type Name Space", + . + + [LDP_NAME_SPACE] + "Label Distribution Protocol (LDP) Parameters", + . + + [MAC_FLUSH] + "MAC Flush Flags", . + + [MP_BASIC_OPAQUE] + "LDP MP Opaque Value Element basic type", + . + + [MP_STATUS_VALUE] + "LDP MP Opaque Value Element extended type", + . + + [MSG_TYPE_NAME_SPACE] + "Message Type Name Space", + . + + [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, + . + + [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, . + + [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, + . + + [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, + . + + [STATUS_CODE_NAME_SPACE] + "Status Code Name Space", + . + + [TLV_TYPE_NAME_SPACE] + "TLV Type Name Space", . + +Appendix A. LDP Label Distribution Procedures This section specifies label distribution behavior in terms of LSR response to the following events: - Receive Label Request Message; - Receive Label Mapping Message; - Receive Label Abort Request Message; - Receive Label Release Message; - Receive Label Withdraw Message; - Recognize new FEC; @@ -4594,120 +4722,120 @@ The algorithms in this section use procedures defined in the MPLS architecture specification RFC 3031 [RFC3031] for hop-by-hop routed traffic. These procedures are: - Label Distribution procedure, which is performed by a downstream LSR to determine when to distribute a label for a FEC to LDP peers. The architecture defines four Label Distribution procedures: - . Downstream Unsolicited Independent Control, called + o Downstream Unsolicited Independent Control, called PushUnconditional in RFC 3031 [RFC3031]. - . Downstream Unsolicited Ordered Control, called PushConditional + o Downstream Unsolicited Ordered Control, called PushConditional in RFC 3031 [RFC3031]. - . Downstream On Demand Independent Control, called + o Downstream On Demand Independent Control, called PulledUnconditional in RFC 3031 [RFC3031]. - . Downstream On Demand Ordered Control, called PulledConditional + o Downstream On Demand Ordered Control, called PulledConditional in RFC 3031 [RFC3031]. - Label Withdrawal procedure, which is performed by a downstream LSR to determine when to withdraw a FEC label mapping previously distributed to LDP peers. The architecture defines a single Label Withdrawal procedure. Whenever an LSR breaks the binding between a label and a FEC, it MUST withdraw the FEC label mapping from all LDP peers to which it has previously sent the mapping. - Label Request procedure, which is performed by an upstream LSR to determine when to explicitly request that a downstream LSR bind a label to a FEC and send it the corresponding label mapping. The 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. - . 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 request for one, in addition to whenever it needs one. - Label Release procedure, which is performed by an upstream LSR to determine when to release a previously received label mapping for 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]. - . Liberal Label retention, called NoReleaseOnChange in RFC 3031 + o Liberal Label retention, called NoReleaseOnChange in RFC 3031 [RFC3031]. - Label Use procedure, which is performed by an LSR to determine when to start using a FEC label for forwarding/switching. The 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. - . 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 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. Use of the FEC label for forwarding/switching will continue until the next hop for the FEC changes or the loop is no longer detected. This version of LDP does not include a loop prevention mechanism; therefore, the procedures below do not make use of the Use If Loop Free procedure. - Label No Route procedure (called the NotAvailable procedure in RFC 3031 [RFC3031]), which is performed by an upstream LSR to determine how to respond to a No Route notification from a downstream LSR in response to a request for a FEC label mapping. The architecture specification defines two Label No Route 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. - . 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 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 an algorithm for each label distribution event. The requirement on an LDP implementation is that its event handling must have the effect specified by the algorithms. That is, an implementation need not follow exactly the steps specified by the algorithms as long as the effect is identical. The algorithms for handling label distribution events share common actions. The specifications below package these common actions into procedure units. Specifications for these common procedures are in their own Section, "Common Label Distribution Procedures", which follows this. An implementation would use data structures to store information about protocol activity. This appendix specifies the information to be stored in sufficient detail to describe the algorithms, and assumes the ability to retrieve the information as needed. It does not specify the details of the data structures. -10.1.1. A.1.1. Receive Label Request +A.1.1. Receive Label Request Summary: 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: - Transmission of a notification message to the requesting LSR indicating why a label mapping for the FEC cannot be provided; - Transmission of a FEC label mapping to the requesting LSR; @@ -4852,21 +4980,21 @@ A duplicate label request is considered a protocol error and SHOULD be dropped by the receiving LSR (perhaps with a suitable notification returned to MsgSource). 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, 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: 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: - Transmission of a Label Release message for the FEC label to the LDP peer; - Transmission of Label Mapping messages for the FEC to one or more @@ -5152,21 +5280,21 @@ requests, fall through into the Downstream on Demand procedures in order to satisfy the pending requests. 12. As determined by step LMp.1. 13. An LSR operating in Ordered Control mode may choose to skip at this stage the peer from which it received the advertisement that caused it to generate the label-map message. Doing so will 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: When an LSR receives a Label Abort Request message from a peer, it checks whether it has already responded to the label request in question. If it has, it silently ignores the message. If it has not, it sends the peer a Label Request Aborted Notification. 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 the downstream peer to abort the LSP. @@ -5227,21 +5355,21 @@ Notes: 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 previously received label request from MsgSource. 2. If LSR has received a label mapping from NextHop, it should behave as if it had advertised a label mapping to MsgSource and MsgSource has released it. -10.1.4. A.1.4 Receive Label Release +A.1.4. Receive Label Release Summary: When an LSR receives a Label Release message for a FEC from a peer, it checks whether other peers hold the released label. If 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 mapping from the FEC next hop, it releases the label mapping. Context: @@ -5315,21 +5443,21 @@ other upstream LSR send it a new Label Request for FEC. Whether or not to propagate the release is not a protocol issue. Label distribution will operate properly whether or not the release is propagated. The decision to propagate or not should take into consideration factors such as, whether labels are a scarce resource in the operating environment, the importance of keeping LSP setup latency low by keeping the amount of signaling required small, and whether LSP setup is ingress-controlled or egress-controlled in the operating environment. -10.1.5. A.1.5 Receive Label Withdraw +A.1.5. Receive Label Withdraw Summary: 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 the label from any forwarding/switching use. If Ordered Control 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 the LSR is using Downstream on Demand label advertisement with independent control, it then acts as if it had just recognized the @@ -5392,21 +5520,21 @@ 2. LWd.7 handles the case where the LSR is using Downstream On Demand label distribution with independent control. In this situation, the LSR should send a label request to the FEC next hop as if it had just recognized the FEC. 3. LWd.10 handles both label merging (one or more incoming labels map to the same outgoing label) and no label merging (one label maps to the outgoing label) cases. -10.1.6. A.1.6 Recognize New FEC +A.1.6. Recognize New FEC Summary: The response by an LSR to learning a new FEC via the routing table may involve one or more of the following actions: - Transmission of label mappings for the FEC to one or more LDP peers; - Transmission of a label request for the FEC to the FEC next @@ -5521,21 +5649,21 @@ label only if it had a previously received label request marked as pending. The LSR would have no such pending requests because it responds to any label request for an unknown FEC by sending the requesting LSR a No Route notification and discarding the label request; see LRq.3 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. 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: The response by an LSR to a change in the next hop for a FEC may involve one or more of the following actions: - Removal of the label from the FEC's old next hop from forwarding/switching use; - Transmission of label mapping messages for the FEC to one or @@ -5652,21 +5780,21 @@ Label Mapping message where the LSR operating in Conservative Label retention mode may have released a label mapping received from the New Next Hop before it detected that the FEC next hop had changed. - Regardless of the Label Request procedure in use by the LSR, it MUST send a label request if the conditions in NH.13 hold. Therefore, it executes the Send_Label_Request procedure directly 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: When an LSR receives a Label Request Aborted notification from an LDP peer, it records that the corresponding label request transaction, if any, has completed. Context: - LSR. The LSR handling the event. @@ -5687,21 +5815,21 @@ LRqA.b Record that the label request for FEC has been aborted. LRqA.c DONE. Note: 1. The LSR uses the FEC and RequestMessageID to locate its record, 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: When an LSR receives a No Label Resources notification from an LDP peer, it stops sending label request messages to the peer until it receives a Label Resources Available Notification from the peer. Context: LSR. The LSR handling the event. @@ -5716,21 +5844,21 @@ MsgSource. NoRes.2 Record that label mapping for FEC from MsgSource is needed but that no label resources are available. NoRes.3 Set status record indicating it is not OK to send label requests to MsgSource. NoRes.4 DONE. -10.1.10. A.1.10. Receive Notification / No Route +A.1.10. Receive Notification / No Route Summary: When an LSR receives a No Route notification from an LDP peer in response to a Label Request message, the Label No Route procedure 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 send another Label Request message to the peer when the timer later expires. @@ -5757,21 +5885,21 @@ For Request Retry 1. Record deferred label request for FEC and Attributes to be sent to MsgSource. 2. Start timeout. Goto NoNH.3. NoNH.3 DONE. -10.1.11. A.1.11. Receive Notification / Loop Detected +A.1.11. Receive Notification / Loop Detected Summary: 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, it behaves as if it had received a No Route notification. Context: See "Receive Notification / No Route". @@ -5781,21 +5909,21 @@ See "Receive Notification / No Route". Note: 1. When the Loop Detected notification is in response to a Label Request message, it arrives in a Status Code TLV in a Notification message. When it is in response to a Label Mapping message, it arrives in a Status Code TLV in a Label Release message. -10.1.12. A.1.12. Receive Notification / Label Resources Available +A.1.12. Receive Notification / Label Resources Available Summary: When an LSR receives a Label Resources Available notification from an LDP peer, it resumes sending label requests to the peer. Context: - LSR. The LSR handling the event. @@ -5820,21 +5948,21 @@ Res.4 Execute procedure Send_Label_Request (MsgSource, FEC, SAttributes). If the procedure fails, terminate iteration. Res.5 Delete record that no resources are available for a label mapping for FEC needed from MsgSource. Res.6 Res.6 End iteration from Res.2. 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: After an LSR has sent a No Label Resources notification to an LDP peer, when label resources later become available it sends a Label Resources Available notification to each such peer. Context: - LSR. The LSR handling the event. @@ -5868,21 +5996,21 @@ ResA.8 End iteration from ResA.5 ResA.9 DONE. Note: 1. Iteration ResA.5 through ResA.8 handles the situation where the LSR is using Downstream Unsolicited label distribution and was 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: 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 message for the FEC to the peer. Context: - Peer. The peer. @@ -5900,21 +6028,21 @@ DONE. Note: 1. The LSR may remove the label from forwarding/switching use as part of this event or as part of processing the Label Release from the peer in response to the label withdraw. If the LSR doesn't wait for the Label Release message from the peer, it 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: Label requests are deferred in response to No Route and Loop Detected notifications. When a deferred FEC label request for a peer times out, the LSR sends the label request. Context: - LSR. The LSR handling the event. @@ -5931,26 +6059,26 @@ TO.1 Retrieve the record of the deferred label request. TO.2 Is Peer the next hop for FEC? If not, goto TO.4. TO.3 Execute procedure Send_Label_Request (Peer, FEC). 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 handle label distribution events. -10.2.1. A.2.1. Send_Label +A.2.1. Send_Label Summary: 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 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 Label Resources notification. Parameters: @@ -6006,21 +6134,21 @@ but no-label-resources. (See Note 1.) SL.14 Return failure. Note: 1. SL.13 handles the case of Downstream Unsolicited label distribution when the LSR is unable to allocate a label for a FEC to send to a Peer. -10.2.2. A.2.2. Send_Label_Request +A.2.2. Send_Label_Request Summary: 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. Parameters: - Peer. The LDP peer to which the label request is to be sent. @@ -6057,21 +6185,21 @@ SLRq.7 Return failure. Note: 1. If the LSR is a non-merging LSR, it must distinguish between attempts to send label requests for a FEC triggered by different upstream LDP peers from duplicate requests. This procedure will not send a duplicate label request. -10.2.3. A.2.3. Send_Label_Withdraw +A.2.3. Send_Label_Withdraw Summary: 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 Withdraw message to the peer. Parameters: - Peer. The LDP peer to which the label withdraw is to be sent. @@ -6085,21 +6213,21 @@ - LSR. The LSR executing the procedure. Algorithm: SWd.1 Execute procedure Send_Message (Peer, Label Withdraw, FEC, Label). SWd.2 Record that label withdraw for FEC has been sent to Peer and mark it as outstanding. -10.2.4. A.2.4. Send_Notification +A.2.4. Send_Notification Summary: An LSR uses the Send_Notification procedure to send an LDP peer a Notification message. Parameters - Peer. The LDP peer to which the Notification message is to be sent. @@ -6107,21 +6235,21 @@ - Status. Status code to be included in the Notification message. Additional Context: None. Algorithm: SNt.1 Execute procedure Send_Message (Peer, Notification, Status) -10.2.5. A.2.5. Send_Message +A.2.5. Send_Message Summary: An LSR uses the Send_Message procedure to send an LDP peer an LDP message. Parameters: Peer. The LDP peer to which the message is to be sent. @@ -6131,21 +6259,21 @@ Additional Context: None. Algorithm: This procedure is the means by which an LSR sends an LDP message 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: Check the attributes received in a Label Mapping or Label Request message. If the attributes include a Hop Count or Path Vector, perform a Loop Detection check. If a loop is detected, cause a Loop Detected Notification message to be sent to MsgSource. Parameters: @@ -6190,21 +6318,21 @@ CRa.9 DONE. Note: 1. When the attributes being checked were received in a Label Mapping message, the LSR sends the Loop Detected notification in a Status Code TLV in a Label Release message. (See Section "Receive Label Mapping".) -10.2.7. A.2.7. Prepare_Label_Request_Attributes +A.2.7. Prepare_Label_Request_Attributes Summary: 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 in the message. Parameters: Peer. The LDP peer to which the message is to be sent. @@ -6269,21 +6397,21 @@ PRqA.14 DONE. Notes: 1. The link with Peer may require that Hop Count be included in Label Request messages; for example, see RFC 3035 [RFC3034] and RFC 3034 [RFC3034]. 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: 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 in the message. Parameters: - Peer. The LDP peer to which the message is to be sent. @@ -6393,188 +6521,58 @@ 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 upstream into the cloud, it sets the Hop Count to 1 so that Hop Count across the cloud is calculated properly. This ensures proper TTL management for packets forwarded across the part of the LSP that passes through the cloud. 3. For hop count arithmetic, unknown + 1 = unknown. -11. IANA Considerations - - 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", - . - - [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, - DOI 10.17487/RFC1321, April 1992, - . - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, - DOI 10.17487/RFC2119, March 1997, - . - - [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, - DOI 10.17487/RFC2328, April 1998, - . - - [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 - Signature Option", RFC 2385, DOI 10.17487/RFC2385, August - 1998, . - - [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", RFC 2434, - DOI 10.17487/RFC2434, October 1998, - . - - [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, - . - - [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol - Label Switching Architecture", RFC 3031, - DOI 10.17487/RFC3031, January 2001, - . - - [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, - . - - [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, - . - - [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, . - - [RFC3037] Thomas, B. and E. Gray, "LDP Applicability", RFC 3037, - DOI 10.17487/RFC3037, January 2001, - . - - [RFC3988] Black, B. and K. Kompella, "Maximum Transmission Unit - Signalling Extensions for the Label Distribution - Protocol", RFC 3988, DOI 10.17487/RFC3988, January 2005, - . - - [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, - . - - [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, - . - - [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, - . - - [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, . - - [RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport - Profile (MPLS-TP) Survivability Framework", RFC 6372, - DOI 10.17487/RFC6372, September 2011, - . - -12.2. Informative References - - [EXP_ID_NAME_SPACE] - "Experiment ID Name Space", - . - - [EXT_BASIC_OPAQUE] - "LDP MP Opaque Value Element extended type", - . - - [FEC_TYPE_NAME_SPACE] - "Forwarding Equivalence Class (FEC) Type Name Space", - . - - [LDP_NAME_SPACE] - "Label Distribution Protocol (LDP) Parameters", - . - - [MAC_FLUSH] - "MAC Flush Flags", . - - [MP_BASIC_OPAQUE] - "LDP MP Opaque Value Element basic type", - . +Acknowledgments - [MP_STATUS_VALUE] - "LDP MP Opaque Value Element extended type", - . + The editors of this document relies heavily on, and would like to + thank, everyone that contributed to the develoment and improvement of + the LDP Specification. - [MSG_TYPE_NAME_SPACE] - "Message Type Name Space", - . + This document is produced as part of advancing the LDP specification + to Internet Standard status. The predessor (RFC 5036) was published + 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. - [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, - . + Since the Draft Standard version was published IETF has abandoned the + 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. - [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, . + The LDP specification was originally published as RFC 3036 in January + 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. - [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, - . + The ideas and text in RFC 3036 were collected from a number of + sources. We would like to thank Rick Boivie, Ross Callon, Alex + Conta, Eric Gray, Yoshihiro Ohba, Eric Rosen, Bernard Suter, Yakov + Rekhter, and Arun Viswanathan for their input for RFC 3036. - [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, - . + The authors would like to thank Eric Gray, David Black, and Sam + Hartman for their input to and review of RFC 5036. That input has + been of great help also for the current document. - [STATUS_CODE_NAME_SPACE] - "Status Code Name Space", - . + In addition, the authors would like to thank the members of the MPLS + Working Group for their ideas and the support they have given to this + document, and in particular, to Eric Rosen, Luca Martini, Markus + Jork, Mark Duffy, Vach Kompella, Kishore Tiruveedhula, Rama + Ramakrishnan, Nick Weeds, Adrian Farrel, and Andy Malis. - [TLV_TYPE_NAME_SPACE] - "TLV Type Name Space", . + Editor note - this section is still work in progress. Authors' Addresses Xia Chen Huawei Technologies Email: jescia.chenxia@huawei.com Loa Andersson Huawei Technologies