Internet-Draft Nancy Feldman Expiration Date: May 1998 IBM Corp. Paul Doolan Ennovate Networks Andre Fredette Bay Networks Inc Loa Andersson Ericsson November 1997 LDP Specification 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), ds.internic.net (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 Feldman, et al. Expiration: May 1998 [Page 1] Internet-Draft Label Distribution Protocol November 1997 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 the Label Distribution Protocol (LDP) referenced in [FRAMEWORK] and [ARCH]. This document defines the LDP protocol. Feldman, et al. Expiration: May 1998 [Page 2] Internet-Draft Label Distribution Protocol November 1997 Table of Contents 1. Protocol Overview ........................ 4 2. Local and Egress Control ................. 5 3. Selecting Streams ........................ 6 4. LDP Messaging ............................ 8 4.1. Hello Message ............................ 8 4.2. Protocol Message Overview ................ 8 4.2.1. Adjacency Class Messages ................. 8 4.2.2. Advertisement Class Messages ............. 8 4.3. Advertisement Message .................... 9 4.3.1. Local Control ............................ 9 4.3.2. Egress Control ........................... 10 4.3.3. Label Use ................................ 10 4.4. Request Message .......................... 10 4.5. Withdraw Message ......................... 11 4.6. Release Message .......................... 11 4.7. Acknowledge Message ...................... 12 4.8. Query Message ............................ 12 5. Loop Detection ........................... 12 6. Loop Prevention via Diffusion ............ 12 7. Merging .................................. 14 8. Specification ............................ 14 8.1. LDP Hello mechanism ...................... 14 8.2. Common Header ............................ 15 8.3. Object Header ............................ 16 8.4. Adjacency Class Messages ................. 17 8.5. Advertisement Class ...................... 17 8.6. LDP Object definitions ................... 18 8.6.1. MsgType Object ........................... 18 8.6.2. LSR Object ............................... 19 8.6.3. LabelRange Object ........................ 20 8.6.4. Stream Member Descriptor (SMD) Object .... 21 8.6.5. Label Object ............................. 26 8.6.6. Class-of-Service Object .................. 26 8.6.7. LSR Path Vector Object ................... 27 8.6.8. Hop Count Object ......................... 28 8.6.9. MTU Object ............................... 28 8.6.10. Stack Object ............................. 29 8.6.11. Error Object ............................. 30 9. Intellectual Property Considerations ..... 31 10. Acknowledgments .......................... 31 11. References ............................... 31 12. Author Information ....................... 32 Feldman, et al. Expiration: May 1998 [Page 3] Internet-Draft Label Distribution Protocol November 1997 1. Protocol Overview LDP is the set of procedures and messages by which one LSR informs another of the mappings between labels and Streams that it has made. Two LSRs which use an 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 Adjacency" between them. A single LDP adjacency allows each peer to learn the other's label mappings ie the protocol is bidirectional. LDP provides a mechanism whereby LSRs continually indicate their presence in a network using advertisements which are sent as UDP packets to the LDP port at the 'all routers' group multicast address. When, perhaps in response to hearing an advertisement, one LSR decides to establish an adjacency with another it uses the initialization procedure of LDP. On succesful completion of this initialization procedure the two LSRs are LDP peers and may exchange label mappings. Note that this document is written with respect to unicast routing only. Multicast will be addressed in a future revision. LDP messages are broken into two classes: those required to establish and maintain neighbor adjacencies, and those which deal with the advertisement of label mappings. Correct operation of the label forwarding paradigm requires that forwarding peers agree on the 'meaning' of labels. This imposes certain requirements on the LDP including 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. The convention used in this document is the same as that used in the documentation of the internet protocols [rfc1700] ie to express numbers in decimal and to picture data in "big-endian" order. Fields are described left to right, with the most significant octet on the left and the least significant octet on the right. The order of transmission of the header and data described in this document is resolved to the octet level. Whenever a diagram shows a group of octets, the order of transmission of those octets is the normal order in which they are read in English. For example, in the following diagram the octets are transmitted in the order they are numbered. Feldman, et al. Expiration: May 1998 [Page 4] Internet-Draft Label Distribution Protocol November 1997 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | 2 | 3 | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5 | 6 | 7 | 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 9 | 10 | 11 | 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Transmission Order of Bytes Whenever an octet represents a numeric quantity the left most bit in the diagram is the high order or most significant bit. That is, the bit labeled 0 is the most significant bit. Similarly, whenever a multi-octet field represents a numeric quantity the left most bit of the whole field is the most significant bit. When a multi-octet quantity is transmitted the most significant octet is transmitted first. 2. Local and Egress Control Each LSR must be configured for local or egress control, to determine the behavior for the initial setup of LSPs. When LSP control is done locally, each node may at any time pass label mappings to its neighbors for each stream recognized by that node. When the neighboring nodes recognize the same streams, they map incoming labels to received outgoing labels. When LSP control is done via egress control, then only the egress node may initiate the transmission of label mappings. Non-egress nodes wait until they get a label from downstream for a recognized stream before mapping the stream and passing a corresponding label for the stream to upstream peers. An LSR behaves as an egress (that is, initiating mappings) on a per stream basis. Thus, an LSR may be considered an egress for a particular set of streams, and a non-egress for others. An LSR is an egress LSR, with respect to a particular stream, under any of the following conditions: 1. The stream refers to the LSR itself (including one of its Feldman, et al. Expiration: May 1998 [Page 5] Internet-Draft Label Distribution Protocol November 1997 directly attached interfaces). 2. The stream is reachable via a next hop router that is out- side the LSR switching infrastructure. 3. The stream is reachable by crossing a routing domain boun- dary, such as another area for OSPF summary net-works, or another autonomous system for OSPF AS externals and BGP routes [rfc1583] [rfc1771]. 3. Selecting Streams A stream is an aggregate of one or more flows, treated as one for the purpose of forwarding; that is, all aggregate flows use a single label. Following are the currently defined streams. New streams types may be added as needed: a) IPv4 address This stream is a single a IP prefix. This identifier is used for host or CIDR prefixes [rfc1519]. This type results in each IP destination prefix sustaining its own LSP tree. It is recommended in environments where no aggregation information is provided by the routing proto- cols (such as RIP), or in networks where the number of des- tination prefixes is limited. b) BGP Next Hop This stream is the value in the BGP NEXT_HOP attribute. It may be the IP address of a BGP border router (enabling one LSP tree for all destinations reachable through the same egress point), or the address of an external BGP peer (ena- bling one LSP tree for all routes destinated to the same external peer). This identifier provides the maximum obtainable aggregation. c) OSPF Router ID This stream is the OSPF Router ID of the router that ini- tiated the link state advertisement. This type allows aggregation of traffic on behalf of multiple datagram Feldman, et al. Expiration: May 1998 [Page 6] Internet-Draft Label Distribution Protocol November 1997 protocols routed by OSPF. d) OSPF Area Border Router This stream is the OSPF Router ID of the border router. This identifier is used in OSPF external link advertisement with a non-zero forwarding address. e) Explicit Path This stream is an explicitly defined source-routed path. This information may be provided via configuration, or may be computed via a Dijkstra calculation for a certain metric (e.g. QoS, Tos), and may be used for point-to-point, point-to-multipoint, or multipoint-to-point LSPs. This type of stream may be initiated by an ingress or egress LSR. f) Aggregate group This stream is a list of prefixes that are to share a com- mon egress point. This type is configured, and may be used when additional aggregation not provided by the routing protocols is required. g) Flow This stream contains information pertaining to a constant set of datagram information, such as port, dest-addr, src- addr, etc. This feature provides the user with the ability to use MPLS with no aggregation. This type of stream may be initiated by an ingress or egress LSR. h) Multicast (S,G) This stream is a unique (Source, Group) multicast pair. It creates one LSP tree per (S,G) pair. It is used by DVMRP and PIM-DM. i) Multicast (G) This stream is a unique multicast group on a multicast tree. It creates one switched path tree per group. It is used by PIM-SM. Feldman, et al. Expiration: May 1998 [Page 7] Internet-Draft Label Distribution Protocol November 1997 4. LDP Messaging 4.1. Hello Message The hello message is periodically transmitted to autodiscover LSR peers. The are transmitted as UDP packets to the LDP port at the 'all routers' group multicast address. 4.2. Protocol Message Overview The protocol messages are constructed from a common header followed by one or more message 'objects'. The message object structure is of the form Type, Length, Value. 4.2.1. Adjacency Class Messages Initialization Transmitted after neighbor discovery, to exchange LSR characteris- tics, and establish a neighbor adjacency. KeepAlive Periodically transmitted to maintain a neighbor adjacency. It need be sent only when no other MPLS messages are transmitted within the KeepAlive timer interval. Shutdown Transmitted to ACTIVE neighbors, to terminate a neighbor adja- cency. 4.2.2. Advertisement Class Messages Mapping Transmitted to establish an LSP by transmitting a mapping between a stream and a label, with associated characteristics. Request Transmitted to request a label mapping for a stream. Withdraw Transmitted to withdraw a previously allocated label. Feldman, et al. Expiration: May 1998 [Page 8] Internet-Draft Label Distribution Protocol November 1997 Release Transmitted to indicate a previously received label is no longer in use. Query Transmitted when diffusion is in use, to verify that a new routed path to the stream is loop free. Acknowledge An error transmitted on the receipt of an Advertisement Class mes- sage, or as a response to a query message 4.3. Advertisement Message The Advertisement message is used by a downstream LSR distribute a label mapping for a stream to its LDP peers. If an LSR must distri- bute a mapping for a stream to multiple MPLS peers, it is a local matter whether it maps a single label to the stream, and distributes that mapping to all its peers, or whether it uses a different mapping for each of its peers. It is the responsibility of the downstream LSR to keep track of the mappings which it has distributed, and to ensure that the upstream peer always has these mappings. 4.3.1. Local Control If an LSR is configured for local control, an advertisement is transmitted by an LSR to upstream peers upon any of the following conditions: 1. The LSR recognizes a new stream via the forwarding table. 2. The LSR receives a Request Advertisement from an upstream peer for a stream present in the LSR's forwarding table. 3. The next hop for a stream changes. 4. The next hop for a stream changes to another LDP peer. 5. The receipt of a mapping from the downstream next hop. Feldman, et al. Expiration: May 1998 [Page 9] Internet-Draft Label Distribution Protocol November 1997 4.3.2. Egress Control If an LSR is configured for egress control, an advertisement is transmitted by downstream LSRs upon any of the following conditions: 1. The LSR recognizes a new stream via the forwarding table, and is the egress for the stream. 2. The LSR receives a Request Advertisement from an upstream peer for a stream present in the LSR's forwarding table, and the LSR is the egress for that stream OR has a downstream mapping for that stream. 3. The next hop for a stream changes to another LDP peer. 4. The attributes of a mapping change. 5. The receipt of a mapping from the downstream next hop. 4.3.3. Label Use An upstream LSR uses a mapping received from the downstream peer if that peer is the next hop for the stream, and a routed path loop is not detected via the LSR-path-vector object (see section 8.6.7). If diffusion is configured, a diffusion algorith may need to be per- formed before the label is used (see section 6). If, at the time the mapping is received, the downstream peer is NOT the LSR's Next Hop for the stream, or an object is determined to be in a loop, the LSR will not use of the mapping at that time. 4.4. Request Message The Request message is used by the upstream LSR to explicitly request that the downstream LSR map and advertise a label for a stream. An LSR transmits a Request message under any of the following condi- tions: 1. The LSR recognizes a new stream via the forwarding table, and the next hop is an ACTIVE MPLS peer. 2. The next hop to the stream changes, and one doesn't already have a mapping from that next hop for the given stream. Feldman, et al. Expiration: May 1998 [Page 10] Internet-Draft Label Distribution Protocol November 1997 If a request cannot be satisfied by the downstream LSR, the request- ing LSR may optionally choose to request again at a later time, or may wait for the mapping, assuming that the the downstream LSR will provide the mapping automatically when it is available. 4.5. Withdraw Message A downstream LSR distributes a Withdraw message to upstream peers when it decides to break the mapping between a stream and a label. Note that if a downstream LSR peer becomes non-ACTIVE, all labels received from that peer are to be considered withdrawn. An LSR transmits a Withdraw message under the following condition: 1. The LSR no longer recognizes a previously known stream. 2. Optionally, the LSR has unspliced an upstream label from the downstream label. Note that a withdrawn label MAY NOT be reused until the upstream peer has acknowledged the withdraw via a Release message. 4.6. Release Message An LSR transmits a Release message to a downstream peer when it is not using a label previously received from that peer. An LSR transmits a Release message under any of the following condi- tions: 1. The downstream LSR which sent the label mapping is not the next hop for the mapped stream. 2. The downstream LSR which sent the label has ceased to be the next hop for a stream. 3. The LSR has received a Withdraw message for a previously received label. Note that if an LSR is configured for "liberal mode", a release mes- sage will never be transmitted. In this case, the upstream LSR keeps each unused label, so that it can immediately be used later if the downstream peer becomes the next hop for the stream. Feldman, et al. Expiration: May 1998 [Page 11] Internet-Draft Label Distribution Protocol November 1997 4.7. Acknowledge Message An LSR transmits an acknowledge message if it cannot process a received Advertisement message, or in response to the receipt of a diffusion query message. 4.8. Query Message The Query message is used with the diffusion algorithm to verify that new paths are loop-free before creating an LSP on the new path. See diffusion section ??? 5. Loop Detection All LSRs perform loop detection via the LSR-path-vector object con- tained within each label advertisement. Upon receiving such a mes- sage, the LSR performs loop detection by verifying that its unique router-id is not already present in the list. If a loop is detected, the LSR must transmit a NAK message to the sending node, and not install the mapping or propagate the message any further. In addi- tion, if there is an upstream label spliced to the downstream label for the stream, the LSR must unsplice the labels. On those messages in which no loop is detected, the LSR must concatenate itself to the LSR-path-vector before propagating. 6. Loop Prevention via Diffusion LSR diffusion support is a configurable option, which permits an LSR to verify that a new routed path is loop free before installing an LSP on that path. An LSR which supports diffusion does not splice an upstream label a new downstream label until it ensures that concate- nation of the upstream path with the new downstream path will be loop free. A LSR which detects a new nexthop for a stream transmits a query mes- sage containing its unique router id to each of its upstream peers. A node that receives such a query processes the query as follows: o If the sending LSR not the correct next hop for the given stream, the receiving LSR responds with a positive acknowledge message, indicating that the sending LSR may change to the new Feldman, et al. Expiration: May 1998 [Page 12] Internet-Draft Label Distribution Protocol November 1997 path. o If the sending LSR is the correct next hop for the given stream, the receiving LSR performs loop detection via the LSR-path-vector. o If a loop is detected, the receiving LSR responds with a nega- tive "prune" acknowledgment, and unsplices all connections to the sending node, thereby pruning itself off of the tree. o If a loop is not detected, the receiving node concatenates its unique router-id to the LSR-path-vector, and propagates the query message to its upstream neighbors. o Each LSR which receives a query acknowledgement from its upstream neighbor in turn forwards the acknowledgement to the downstream LSR which sent the query advertisement. o If an LSR doesn't receive an acknowledgment within a "reason- able" period of time, it "unsplices" its unsplice the upstream neighbor that has not responded, and responds with a negative "prune" acknowledgement. o An LSR which receives a new query advertisement for a stream before it has received responses from all of its upstream neighbors for a previous query advertisement must concaten- tated the old and the new LSR-path-vector within the new query advertisement before propagating. o The diffusion computation continues until each upstream path responds with an acknowledgment. An LSR that does not have any upstream MPLS neighbors must acknowledge the query adver- tisement. The LSR which began the diffusion may splice its upstream label to the new downstream label only after receiving an acknowledge message from the upstream peer. As LSR diffusion support is a configurable option, an LSRs which do not support diffusion will never originate a query advertisement. However, these LSRs must still recognize and process the query mes- sage, as described above. Feldman, et al. Expiration: May 1998 [Page 13] Internet-Draft Label Distribution Protocol November 1997 7. Merging VC/VP merging, non-merging, and interoperability will be addressed in a future revision. 8. Specification The hello mechanism is described first. Following that we define the structure of the common header and of the objects. We then provide definitions of the adjacency and advertisement messages and follow that with definitions for the objects that constitute those messages. 8.1. LDP Hello mechanism Hello message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Reserved | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version: This one octet unsigned integer contains the version number of the protocol. This version of the specification specifies protocol Version = 0x01. Reserved This field is reserved. It must be set to zero on transmission and must be ignored on receipt. Length: This two octet integer specifies the total length of this PDU in bytes. Network Address This 4 octet integer contains the address of the LSR which originated the discovery message. Feldman, et al. Expiration: May 1998 [Page 14] Internet-Draft Label Distribution Protocol November 1997 8.2. Common Header All LDP PDUs, with the exception of the hello message, must begin with the following common header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Reserved | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MPLS Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version: One octet unsigned integer containing the version number of the protocol. This version of the specification specifies protocol Version = 0x01. Length: Two octet integer specifying the total length of this PDU in bytes, including the common header. MsgClass One octet integer defining the class of the MPLS message. This version of the specification defines: Adjacency Class = 1 Advertisement Class = 2 MPLS Identifier: Six octet unsigned integer containing a unique identifier for the LSR that generated the PDU. The value of this Identifier is deter- mined on startup. The first four octets encode an IP address assigned to the LSR. The last two octets represent the 'instance' of MPLS on the LSR. A LSR with only one active MPLS session would supply the value zero in this field. Res: This field is reserved. It must be set to zero on transmission and must be ignored on receipt. Feldman, et al. Expiration: May 1998 [Page 15] Internet-Draft Label Distribution Protocol November 1997 8.3. Object Header All objects in an MPLS message must begin with the following object header. Objects must be placed back-to-back within the message, and must be padded to a word boundary. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Obj Type | Sub Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Object Type This one octet field specifies the type of the object following. This version of the specification defines the following objects for adjacency class messages: MSGTYPE_OBJECT = 1 LSR_OBJECT = 2 LABELRANGE_OBJECT = 3 This version of the specification defines the following objects for advertisement class messages: MSGTYPE_OBJECT = 1 SMD_OBJECT = 2 LABEL_OBJECT = 3 COS_OBJECT = 4 LSR_PATH_VECTOR_OBJECT = 5 HOPCOUNT_OBJECT = 6 MTU_OBJECT = 7 STACK_OBJECT = 8 ERROR_OBJECT = 9 Sub Type This one octet field specifies the subtype of this object. See each of the object definitions for a definition of the subtypes. Length This two octet unsigned integer specifies the length of the object, including this object header. Feldman, et al. Expiration: May 1998 [Page 16] Internet-Draft Label Distribution Protocol November 1997 8.4. Adjacency Class Messages The following notations show the objects that are valid with each Advertisement Class Message. Only one message may be contained within a single Adjacency Class PDU. Initialization Message: KeepAlive Message: Shutdown Message: 8.5. Advertisement Class All Advertisement Class PDUs begin with a common header: The following notations show the objects that are valid with each Advertisement Class Message. Multiple messages may be contained within a single Advertisement Class PDU. Mapping Message: [ ] ... :=