Network Working Group X. Chen Internet-Draft L. Andersson Intended status: Standards Track Huawei Technologies Expires: October 28, 2017 N. Leymann Deutsche Telekom I. Minei Google K. Raza Cisco Systems, Inc. April 26, 2017 LDP Specification draft-ijln-mpls-rfc5036bis-04.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 procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 October 28, 2017. Chen, et al. Expires October 28, 2017 [Page 1] Internet-Draft LDP Specification April 2017 Copyright Notice Copyright (c) 2017 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Editors notes - this section will be removed before publication . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Scope of RFC5036bis work . . . . . . . . . . . . . . . . 5 1.2. ToDo . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. LDP Overview . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. LDP Peers . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. LDP Message Exchange . . . . . . . . . . . . . . . . . . 8 2.3. LDP Message Structure . . . . . . . . . . . . . . . . . . 9 2.4. LDP Error Handling . . . . . . . . . . . . . . . . . . . 9 2.5. LDP Extensibility and Future Compatibility . . . . . . . 9 2.6. Specification Language . . . . . . . . . . . . . . . . . 9 3. LDP Operation . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. FECs . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Label Spaces, Identifiers, Sessions, and Transport . . . 11 3.2.1. Label Spaces . . . . . . . . . . . . . . . . . . . . 11 3.2.2. LDP Identifiers . . . . . . . . . . . . . . . . . . . 11 3.2.3. LDP Sessions . . . . . . . . . . . . . . . . . . . . 12 3.2.4. LDP Transport . . . . . . . . . . . . . . . . . . . . 12 3.3. LDP Sessions between Non-Directly Connected LSRs . . . . 12 Chen, et al. Expires October 28, 2017 [Page 2] Internet-Draft LDP Specification April 2017 3.4. LDP Discovery . . . . . . . . . . . . . . . . . . . . . . 13 3.4.1. Basic Discovery Mechanism . . . . . . . . . . . . . . 13 3.4.2. Extended Discovery Mechanism . . . . . . . . . . . . 13 3.5. Establishing and Maintaining LDP Sessions . . . . . . . . 14 3.5.1. LDP Session Establishment . . . . . . . . . . . . . . 14 3.5.2. Transport Connection Establishment . . . . . . . . . 14 3.5.3. Session Initialization . . . . . . . . . . . . . . . 16 3.5.4. Initialization State Machine . . . . . . . . . . . . 18 3.5.5. Maintaining Hello Adjacencies . . . . . . . . . . . . 20 3.5.6. Maintaining LDP Sessions . . . . . . . . . . . . . . 21 3.6. Label Distribution and Management . . . . . . . . . . . . 21 3.6.1. Label Distribution Control Mode . . . . . . . . . . . 22 3.6.1.1. Independent Label Distribution Control . . . . . 22 3.6.1.2. Ordered Label Distribution Control . . . . . . . 22 3.6.2. Label Retention Mode . . . . . . . . . . . . . . . . 23 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 . . . . . . . . . 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 4.4.2.3. Frame Relay Label TLV . . . . . . . . . . . . . . 39 4.4.3. Address List TLV . . . . . . . . . . . . . . . . . . 40 4.4.4. Hop Count TLV . . . . . . . . . . . . . . . . . . . . 41 4.4.4.1. Hop Count Procedures . . . . . . . . . . . . . . 42 4.4.5. Path Vector TLV . . . . . . . . . . . . . . . . . . . 43 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 Chen, et al. Expires October 28, 2017 [Page 3] Internet-Draft LDP Specification April 2017 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 . . . . . . . . . . . . . . . . . . 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 4.5.9.1. Label Abort Request Message Procedures . . . . . 77 4.5.10. Label Withdraw Message . . . . . . . . . . . . . . . 79 4.5.10.1. Label Withdraw Message Procedures . . . . . . . 80 4.5.11. Label Release Message . . . . . . . . . . . . . . . . 81 4.5.11.1. Label Release Message Procedures . . . . . . . . 82 4.6. Messages and TLVs for Extensibility . . . . . . . . . . . 82 4.6.1. LDP Vendor-Private Extensions . . . . . . . . . . . . 83 4.6.1.1. LDP Vendor-Private TLVs . . . . . . . . . . . . . 83 4.6.1.2. LDP Vendor-Private Messages . . . . . . . . . . . 84 4.6.2. LDP Experimental Extensions . . . . . . . . . . . . . 86 4.7. Message Summary . . . . . . . . . . . . . . . . . . . . . 86 4.8. TLV Summary . . . . . . . . . . . . . . . . . . . . . . . 87 4.9. Status Code Summary . . . . . . . . . . . . . . . . . . . 89 4.10. Well-Known Numbers . . . . . . . . . . . . . . . . . . . 90 4.10.1. UDP and TCP Ports . . . . . . . . . . . . . . . . . 90 4.10.2. Implicit NULL Label . . . . . . . . . . . . . . . . 90 5. RFC 5036 IANA Considerations . . . . . . . . . . . . . . . . 90 5.1. Message Type Name Space . . . . . . . . . . . . . . . . . 91 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. 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 Chen, et al. Expires October 28, 2017 [Page 4] Internet-Draft LDP Specification April 2017 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. Currently RFC 5036 - the LDP Specification - is a Draft Standard; this step on the Standards Track has been removed. It is therefore the plan to move the document to Internet Standard. Thhis document includes updates to the LDP Specification defined since the document was published, including: 1. Updates all references and citations. RFC 5036 obsoleted RFC 3036, and will in turn be obsoleted by the RFC5036-bis-to-be. Chen, et al. Expires October 28, 2017 [Page 5] Internet-Draft LDP Specification April 2017 2. RFC 5036 is updated by RFC 6720, RFC 6790, RFC 7358, RFC 7552. 3. Incorporate all outstanding Errata. These include the following approved Erratum with IDs: 3156, 2133, 3155, 3415, 3425. [Ed Note: Done in rev -01] 4. Close loops with Stephen on the security section. 5. Have IANA review the IANA section. 1.2. ToDo 1. Evaluation of which of the RFCs that updated RFC 5036 need to be incorporated into the rfc5036bis document. Specifically, these RFCs updated RFC 5036: RFC 6720, RFC 6790, RFC 7358, RFC 7552. RFCs that updated RFC 5036 and will be incorporated into this rfc5036bis, will be Obsoleted by rfc5036bis. 2. Review IANA Allocations. Review the IANA sections (there are currently two) and merge them into one. 3. Evaluate if there are things, based on e.g. non-deployment, that should be removed from the rfc5036bis-to-be. 4. Evaluate what to do about RFC 7349, it is not listed as an update of LDP, but it is an extension of the LDP security mechanisms (Hello crypto). 5. RFC 2385 (The TCP Authentication Option) has been obsoleted by RFC 5925, the changes are such that the text we refer to is no longer there. We probably need a minor re-write of section 2.9.1. 6. This document now carries a pre RFC 5378 copyright statement, since there clearly are material included in the document prior to RFC 5378 (10 Nov 2008), Verify that this is the right approach. 7. Revisit section 4.5.3 "Initialization Message" if we decide to remove ATM and FR. 8. Check if how to forward messages relating path-vector and hop- count from multiple downstreams needs to be specified/clarified. Chen, et al. Expires October 28, 2017 [Page 6] Internet-Draft LDP Specification April 2017 2. LDP Overview The MPLS architecture RFC 3031 [RFC3031] defines a label distribution protocol as a set of procedures by which one Label Switched Router (LSR) informs another of the meaning of labels used to forward traffic between and through them. The MPLS architecture does not assume a single label distribution protocol. In fact, a number of different label distribution protocols are being standardized. Existing protocols have been extended so that label distribution can be piggybacked on them. New protocols have also been defined for the explicit purpose of distributing labels. The MPLS architecture discusses some of the considerations when choosing a label distribution protocol for use in particular MPLS applications such as Traffic Engineering RFC 2702 [RFC2702]. The Label Distribution Protocol (LDP) is a protocol defined for distributing labels. It 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. LDP is a protocol defined for distributing labels. It is the set of procedures and messages by which Label Switched Routers (LSRs) establish Label Switched Paths (LSPs) through a network by mapping network-layer routing information directly to data-link layer switched paths. These LSPs may have an endpoint at a directly attached neighbor (comparable to IP hop-by-hop forwarding), or may have an endpoint at a network egress node, enabling switching via all intermediary nodes. LDP associates a Forwarding Equivalence Class (FEC) RFC 3031 [RFC3031] with each LSP it creates. The FEC associated with an LSP specifies which packets are "mapped" to that LSP. LSPs are extended through a network as each LSR "splices" incoming labels for a FEC to the outgoing label assigned to the next hop for the given FEC. More information about the applicability of LDP can be found in RFC 3037 [RFC3037]. This document assumes (but does not require) familiarity with the MPLS architecture RFC 3031 [RFC3031]. Note that RFC 3031 [RFC3031] includes a glossary of MPLS terminology, such as ingress, label switched path, etc. Chen, et al. Expires October 28, 2017 [Page 7] Internet-Draft LDP Specification April 2017 2.1. LDP Peers Two LSRs that use LDP to exchange label/FEC mapping information are known as "LDP Peers" with respect to that information, and we speak of there being an "LDP Session" between them. A single LDP session allows each peer to learn the other's label mappings; i.e., the protocol is bidirectional. 2.2. LDP Message Exchange There are four categories of LDP messages: 1. Discovery messages, used to announce and maintain the presence of an LSR in a network. 2. Session messages, used to establish, maintain, and terminate sessions between LDP peers. 3. Advertisement messages, used to create, change, and delete label mappings for FECs. 4. Notification messages, used to provide advisory information and to signal error information. Discovery messages provide a mechanism whereby LSRs indicate their presence in a network by sending a Hello message periodically. This is transmitted as a UDP packet to the LDP port at the 'all routers on this subnet' group multicast address. When an LSR chooses to establish a session with another LSR learned via the Hello message, it uses the LDP initialization procedure over TCP transport. Upon successful completion of the initialization procedure, the two LSRs are LDP peers, and may exchange advertisement messages. When to request a label or advertise a label mapping to a peer is largely a local decision made by an LSR. In general, the LSR requests a label mapping from a neighboring LSR when it needs one, and advertises a label mapping to a neighboring LSR when it wishes the neighbor to use a label. Correct operation of LDP requires reliable and in-order delivery of messages. To satisfy these requirements, LDP uses the TCP transport for Session, Advertisement, and Notification messages, i.e., for everything but the UDP-based discovery mechanism. Chen, et al. Expires October 28, 2017 [Page 8] Internet-Draft LDP Specification April 2017 2.3. LDP Message Structure All LDP messages have a common structure that uses a Type-Length- Value (TLV) encoding scheme; see Section "Type-Length-Value Encoding". The Value part of a TLV-encoded object, or TLV for short, may itself contain one or more TLVs. 2.4. LDP Error Handling LDP errors and other events of interest are signaled to an LDP peer by Notification messages. There are two kinds of LDP Notification messages: 1. Error Notifications, used to signal fatal errors. If an LSR receives an Error Notification from a peer for an LDP session, it terminates the LDP session by closing the TCP transport connection for the session and discarding all label mappings learned via the session. 2. Advisory Notifications, used to pass on LSR information about the LDP session or the status of some previous message received from the peer. 2.5. LDP Extensibility and Future Compatibility Functionality may be added to LDP in the future. It is likely that future functionality will utilize new messages and object types (TLVs). It may be desirable to employ such new messages and TLVs within a network using older implementations that do not recognize them. While it is not possible to make every future enhancement backwards compatible, some prior planning can ease the introduction of new capabilities. This specification defines rules for handling unknown message types and unknown TLVs for this purpose. 2.6. Specification Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. LDP Operation 3.1. FECs It is necessary to precisely specify which packets may be mapped to each LSP. This is done by providing a FEC specification for each Chen, et al. Expires October 28, 2017 [Page 9] Internet-Draft LDP Specification April 2017 LSP. The FEC identifies the set of IP packets that may be mapped to that LSP. Each FEC is specified as a set of one or more FEC elements. Each FEC element identifies a set of packets that may be mapped to the corresponding LSP. When an LSP is shared by multiple FEC elements, that LSP is terminated at (or before) the node where the FEC elements can no longer share the same path. This specification defines a single type of FEC element, the "Address Prefix FEC element". This element is an address prefix of any length from 0 to a full address, inclusive. Additional FEC elements may be defined, as needed, by other specifications. In the remainder of this section, we give the rules to be used for mapping packets to LSPs that have been set up using an Address Prefix FEC element. We say that a particular address "matches" a particular address prefix if and only if that address begins with that prefix. We also say that a particular packet matches a particular LSP if and only if that LSP has an Address Prefix FEC element that matches the packet's destination address. With respect to a particular packet and a particular LSP, we refer to any Address Prefix FEC element that matches the packet as the "matching prefix". The procedure for mapping a particular packet to a particular LSP uses the following rules. Each rule is applied in turn until the packet can be mapped to an LSP. - If a packet matches exactly one LSP, the packet is mapped to that LSP. - If a packet matches multiple LSPs, it is mapped to the LSP whose matching prefix is the longest. If there is no one LSP whose matching prefix is longest, the packet is mapped to one from the set of LSPs whose matching prefix is longer than the others. The procedure for selecting one of those LSPs is beyond the scope of this document. - If it is known that a packet must traverse a particular egress router, and there is an LSP that has an Address Prefix FEC element that is a /32 address of that router, then the packet is mapped to that LSP. The procedure for obtaining this knowledge is beyond the scope of this document. Chen, et al. Expires October 28, 2017 [Page 10] Internet-Draft LDP Specification April 2017 The procedure for determining that a packet must traverse a particular egress router is beyond the scope of this document. (As an example, if one is running a link state routing algorithm, it may be possible to obtain this information from the link state data base. As another example, if one is running BGP, it may be possible to obtain this information from the BGP next hop attribute of the packet's route.) 3.2. Label Spaces, Identifiers, Sessions, and Transport 3.2.1. Label Spaces The notion of "label space" is useful for discussing the assignment and distribution of labels. There are two types of label spaces: - Per interface label space. Interface-specific incoming labels are used for interfaces that use interface resources for labels. An example of such an interface is a label-controlled ATM interface that uses VCIs (Virtual Channel Identifiers) as labels, or a Frame Relay interface that uses DLCIs (Data Link Connection Identifiers) as labels. Note that the use of a per interface label space only makes sense when the LDP peers are "directly connected" over an interface, and the label is only going to be used for traffic sent over that interface. - Per platform label space. Platform-wide incoming labels are used for interfaces that can share the same labels. 3.2.2. LDP Identifiers An LDP Identifier is a six octet quantity used to identify an LSR label space. The first four octets identify the LSR and must be a globally unique value, such as a 32-bit router Id assigned to the LSR. The last two octets identify a specific label space within the LSR. The last two octets of LDP Identifiers for platform-wide label spaces are always both zero. This document uses the following print representation for LDP Identifiers: :