Network Working Group Loa Andersson Internet Draft Bay Networks Inc. Expiration Date: February 1999 Paul Doolan Ennovate Networks Nancy Feldman IBM Corp Andre Fredette Bay Networks Inc. Bob Thomas Cisco Systems, Inc. August 1998 LDP Specification draft-ietf-mpls-ldp-00.txt Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract An overview of Multi Protocol Label Switching (MPLS) is provided in [FRAMEWORK] and a proposed architecture in [ARCH]. 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 Andersson, et al. [Page 1] Internet Draft draft-ietf-mpls-ldp-00.txt August 1998 through them. This common understanding is achieved by using the Label Distribution Protocol (LDP) referenced in [FRAMEWORK] and [ARCH]. This document defines the LDP protocol. Open Issues The following LDP issues are left unresolved with this version of the spec: - The loop prevention/detection mechanism to be employed by LDP. This spec has retained the path vector mechanism from previous drafts. However, draft-ohba-mpls-loop-prevention-01.txt has been proposed as an alternative. - Support for explicitly routed LSPs. The need for this feature has been debated at length. This spec refines the previous version of the spec in this area. However, there remains some belief in the WG that explicitly routed LSPs should be supported by enhancements to RSVP and not LDP. The support for explicitly routed LSPs in the spec is independent of other LDP features and could, should the WG decide to do so, be removed without impact on other LDP features. - Traffic engineering considerations beyond support for explicit routing. - The need for all of the FEC types (called FEC elements in this version of the spec, SMDs in previous versions) is being debated. This version of the spec defines fewer FEC types than previous versions. - LDP support for multicast is not defined in this version. Multicast support will be addressed in a future version. - The message and TLV encodings are likely to change in some minor ways in the next draft of the spec. Andersson, et al. [Page 2] Internet Draft draft-ietf-mpls-ldp-00.txt August 1998 Table of Contents 1 LDP Overview ....................................... 6 1.1 LDP Peers .......................................... 6 1.2 LDP Message Exchange ............................... 6 1.3 LDP Error Handling ................................. 7 1.4 LDP Extensibility and Future Compatibility ......... 8 2 LDP Operation ...................................... 8 2.1 FEC Types .......................................... 8 2.2 Mapping packets to FECs ........................... 9 2.3 Label Spaces, Identifiers, Sessions and Transport .. 10 2.4 LDP Sessions between non-Directly Connected LSRs ... 11 2.5 LDP Discovery ..................................... 12 2.5.1 Basic Discovery Mechanism .......................... 12 2.5.2 Extended Discovery Mechanism ....................... 12 2.6 Establishing and Maintaining LDP Sessions .......... 13 2.6.1 LDP Session Establishment .......................... 13 2.6.2 Transport Connection Establishment ................. 13 2.6.3 Session Initialization ............................. 14 2.6.4 Initialization State Machine ....................... 16 2.6.5 Maintaining Hello Adjacencies ...................... 19 2.6.6 Maintaining LDP Sessions ........................... 19 2.7 Label Distribution and Management .................. 20 2.7.1 Label Distribution Control Mode .................... 20 2.7.2 Label Retention Mode ............................... 21 2.7.3 Label Advertisement Mode ........................... 22 2.8 LDP Identifiers and Next Hop Addresses ............. 22 2.9 Loop Detection ..................................... 22 2.10 Loop Prevention via Diffusion ...................... 23 2.11 Explicitly Routing LSPs ............................ 24 2.12 ERLSP State Machine ................................ 28 2.12.1 Loose Segment Peg LSR Transitions: ................. 29 2.12.2 Loose Segment Non-Peg LSR Transitions: ............. 33 2.12.2.1 Strict Segment Transitions ......................... 35 2.12.3 ERLSP Timeouts ..................................... 35 2.12.4 ERLSP Error Codes .................................. 35 3 Protocol Specification ............................. 36 3.1 LDP PDUs ........................................... 36 3.2 Type-Length-Value Encoding ......................... 37 3.3 Commonly Used TLVs ................................. 38 3.3.1 FEC TLV ............................................ 38 3.3.1.1 FEC Procedures ..................................... 41 3.3.2 Label TLVs ......................................... 41 3.3.2.1 Generic Label TLV .................................. 42 3.3.2.2 ATM Label TLV ...................................... 42 3.3.2.3 Frame Relay Label TLV .............................. 43 Andersson, et al. [Page 3] Internet Draft draft-ietf-mpls-ldp-00.txt August 1998 3.3.3 Address List TLV ................................... 43 3.3.4 COS TLV ............................................ 44 3.3.5 Hop Count TLV ...................................... 45 3.3.5.1 Hop Count Procedures ............................... 45 3.3.6 Path Vector TLV .................................... 46 3.3.6.1 Path Vector Procedures ............................. 46 3.3.7 Status TLV ......................................... 47 3.4 LDP Messages ....................................... 48 3.4.1 Notification Message ............................... 50 3.4.1.1 Notification Message Procedures .................... 51 3.4.1.2 Events Signalled by Notification Messages .......... 51 3.4.1.2.1 Malformed PDU or Message ........................... 52 3.4.1.2.2 Unknown or Malformed TLV ........................... 52 3.4.1.2.3 Session Hold Timer Expiration ...................... 53 3.4.1.2.4 Unilateral Session Shutdown ........................ 53 3.4.1.2.5 Initialization Message Events ...................... 53 3.4.1.2.6 Events Resulting From Other Messages ............... 54 3.4.1.2.7 Explicitly Routed LSP Setup Events ................. 54 3.4.1.2.8 Miscellaneous Events ............................... 54 3.4.2 Hello Message ...................................... 54 3.4.2.1 Hello Message Procedures ........................... 55 3.4.3 Initialization Message ............................. 57 3.4.3.1 Initialization Message Procedures .................. 61 3.4.4 KeepAlive Message .................................. 61 3.4.4.1 KeepAlive Message Procedures ....................... 62 3.4.5 Address Message .................................... 62 3.4.5.1 Address Message Procedures ......................... 63 3.4.6 Address Withdraw Message ........................... 64 3.4.6.1 Address Withdraw Message Procedures ................ 64 3.4.7 Label Mapping Message .............................. 64 3.4.7.1 Label Mapping Message Procedures ................... 66 3.4.7.1.1 Independent Control Mapping ........................ 66 3.4.7.1.2 Ordered Control Mapping ............................ 67 3.4.7.1.3 Downstream-on-Demand Label Advertisement ........... 67 3.4.7.1.4 Downstream Allocation Label Advertisement .......... 68 3.4.8 Label Request Message .............................. 68 3.4.8.1 Label Request Message Procedures ................... 69 3.4.9 Label Withdraw Message ............................. 70 3.4.9.1 Label Withdraw Message Procedures .................. 71 3.4.10 Label Release Message .............................. 72 3.4.10.1 Label Release Message Procedures ................... 73 3.4.11 Label Query Message ................................ 73 3.4.11.1 Label Query Message Procecures ..................... 74 3.4.12 Explicit Route Request Message ..................... 74 3.4.12.1 Explicit Route Request Procedures .................. 78 3.4.13 Explicit Route Response Message .................... 78 3.4.13.1 Explicit Route Response Procedures ................. 79 3.5 Messages and TLVs for Extensibility ................ 80 Andersson, et al. [Page 4] Internet Draft draft-ietf-mpls-ldp-00.txt August 1998 3.5.1 Procedures for Unknown Messages and TLVs ........... 80 3.5.1.1 Unknown Message Types .............................. 80 3.5.1.2 Unknown TLV in Known Message Type .................. 80 3.5.2 LDP Vendor-Private Extensions ...................... 81 3.5.2.1 LDP Vendor-Private TLV ............................. 81 3.5.2.2 LDP Vendor-Private Messages ........................ 82 3.6 TLV Summary ........................................ 83 3.7 Status Code Summary ................................ 84 4 Security ........................................... 84 5 Acknowledgments .................................... 84 6 References ......................................... 84 7 Author Information ................................. 85 Andersson, et al. [Page 5] Internet Draft draft-ietf-mpls-ldp-00.txt August 1998 1. LDP Overview LDP 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) [ARCH] 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. Note that this document is written with respect to unicast routing only. Multicast will be addressed in a future revision. Note that this document is written with respect to control-driven traffic. It describes mappings which are initiated for routes in the forwarding table, regardless of traffic over those routes. However, LDP does not preclude data-driven support. 1.1. LDP Peers Two LSRs which use LDP to exchange label/stream 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 adjacency allows each peer to learn the other's label mappings i.e. the protocol is bi-directional. 1.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 and maintain terminate sessions between LSR peers. 3. Advertisement messages, used to create, change, and delete label mappings for FECs. Andersson, et al. [Page 6] Internet Draft draft-ietf-mpls-ldp-00.txt August 1998 4. Notification messages, used to provide advisory information and to signal errors. Discovery messages provide a mechanism whereby LSRs continually indicate their presence in a network via the Hello message. This is transmitted as a UDP packet to the LDP port at the `all LSR routers' group multicast address. When an LSR chooses to establish a session with an 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 mappings (although there are circumstances when this second requirement could be relaxed). To satisfy these requirements LDP uses the TCP transport for adjacency, advertisement and notification messages. 1.3. LDP Error Handling LDP errors and other events of interest are signaled to an LSR 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 for an LDP session with a peer, it terminates the peer 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 an LSR information about the LDP session or the status of some previous message received from the peer. Andersson, et al. [Page 7] Internet Draft draft-ietf-mpls-ldp-00.txt August 1998 1.4. LDP Extensibility and Future Compatibility It is likely that functionality will be added to LDP after its initial release. It is also likely that this additional 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. LDP Operation 2.1. FEC Types It is necessary to precisely define which IP packets may be mapped to each LSP. This is done by providing a FEC specification for each LSP. The FEC defines which IP packets may be mapped to the same LSP, using a unique label. LDP supports LSP granularity ranging from end-to-end flows to the aggregation of all traffic through a common egress node; the choice of granularity is determined by the FEC choice. Each FEC is specified as a list of one or more FEC elements. Each FEC element specifies a set of IP packets which may be mapped to the corresponding LSP. Following are the currently defined types of FEC elements. New element types may be added as needed: 1. IP Address Prefix. This element provides a list of one or more IP address prefixes. Any IP packet whose destination address matches one or more of the specified prefixes may be forwarded using the associated LSP. 2. Router ID This element provides a Router ID (ie, a 32 bit IP address of a router). Any IP packet for which the path to the destination is known to traverse the specified router may be forwarded using the associated LSP. This element allows the full set of destinations reachable via a specified router to be indicated Andersson, et al. [Page 8] Internet Draft draft-ietf-mpls-ldp-00.txt August 1998 in a single FEC element. 3. Flow This element specifies a set of datagram information, such as port, dest-addr, src-addr, etc. This element provides LDP with the ability to support MPLS flows with no aggregation. Where a packet maps to more than one FEC it is transmitted on the LSP associated with the FEC to which the packet has the 'most specific' match. 2.2. Mapping packets to FECs FEC objects (TLVs) are transmitted in the LDP messages that deal with (advertise, request, release ad withdraw) FEC-Label mappings. A stream of packets with a given destination network can be characterized by a single Address Prefix FEC Element. This results in each specified address prefix sustaining its own LSP tree. This singular mapping is recommended in environments where little or no aggregation information is provided by the routing protocols (such as within a simple IGP), or in networks where the number of destination prefixes is limited. In environments where additional aggregation not provided by the routing protocols is desired, an aggregation list may be created. In this, all prefixes that are to share a common egress point may be advertised within the same FEC. This type of aggregation is configured. The router ID FEC type may be used in any environment in which the routing protocols allow routers to determine the egress point for specific IP packets. For example, the router ID FEC type may be used in combination with BGP, OSPF, and/or IS-IS. For example, the mapping between IP packets and the router ID may be provided via the BGP NEXT_HOP attribute. When a BGP border LSR injects routes into the BGP mesh, it may use its own IP address or the address of its external BGP peer as the value of the NEXT_HOP attribute. If the BGP border ISR uses its own IP address as the NEXT_HOP attribute, then one LSP is created which terminates at the BGP border, and the border LSR will forward traffic at layer-3 towards its external BGP neighbors. If the BGP border LSR uses the external BGP peer as the NEXT_HOP attribute, then a separate LSP may be created for each external BGP neighbor, thereby allowing the border LSR to switch traffic directly to each of its external BGP Andersson, et al. [Page 9] Internet Draft draft-ietf-mpls-ldp-00.txt August 1998 neighbors. Similarly, the mapping between IP packet and router ID may be provided by OSPF. This is comprised of the Router ID of the router that initiated the link state advertisement. The Router ID may also be the OSPF Area Border Router. Note that BGP and OSPF may share the same LSP when a given Router ID is found in both protocol's Routing Information Base. The Router ID FEC allows aggregation of multiple IP address prefixes to the same LSP, without requiring that the prefixes be explicitly listed in the FEC. Also, it allows addresses advertised using OSPF and addresses advertised using BGP to be aggregated using the same LSP. Finally, when the set of addresses reachable via a router changes, and the changes are announced into the routing protocol (BGP, OSPF, and/or IS-IS), use of the routerID FEC eliminates the need to explicitly announce the route changes into LDP. 2.3. Label Spaces, Identifiers, Sessions and Transport 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 which uses VCIs as labels, or a frame Relay interface which uses DLCIs 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. An LDP identifier is a six octet quantity used to identify an LSR label space. The first four octets encode an IP address assigned to the LSR, and the last two octets identify a specific label space within the LSR. The last two octets of LDP Identif- iers for platform-wide label spaces are always both zero. This document uses the following print representation for LDP Iden- tifiers: Andersson, et al. [Page 10] Internet Draft draft-ietf-mpls-ldp-00.txt August 1998 :