Internet Draft Internet Draft Eric Gray <draft-gray-mpls-generic-ldp-spec-00.txt> Zheng Wang Grenville Armitage Lucent Technologies, Inc. Expires May 1998 Generic Label Distribution Protocol 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 This document describes the specification of generic Label Distribution Protocol (LDP) for Multi-Protocol Label Switching (MPLS). Its purpose is to define those parts of LDP that are media/technology independent. Other documents, both existing works in progress and yet to come, will describe specifics of MPLS protocol behavior that apply to a particular media or technology. Acknowledgements While not otherwise specifically referred to in this document, the authors would like to acknowledge the influence, ideas, examples and - in some cases - text from a number of sources ([1], [2], [3], [7], [8], [9], [10] and [11]). Gray, et al Expires in six months [Page 1] Internet Draft draft-gray-mpls-generic-ldp-spec-00 November 1997 Table of Contents Status of this Memo ...................................... 1 Abstract ................................................. 1 Acknowledgements ......................................... 1 Table of Contents ........................................ 2 1 Protocol Overview ........................................ 2 2 LDP Messages ............................................. 5 2.1 Common Message Header .................................... 6 2.2 LDP Message Extension Elements ........................... 7 2.2.1 Null MEE ............................................... 9 2.2.2 Forwarding Equivalency MEE ............................. 9 2.2.3 Explicit Route MEE ..................................... 11 2.2.4 Traversal List MEE ..................................... 12 2.2.5 Authentication MEE ..................................... 14 2.2.6 Vendor Specific MEE .................................... 15 2.3 LDP Neighbor Notification ................................ 15 2.4 LDP Bind Request ......................................... 17 2.5 LDP Label Bind ........................................... 19 2.6 LDP Teardown and Acknowledge ............................. 21 2.7 LDP Bind Reject .......................................... 24 3 LDP State Transitions .................................... 25 4 LDP Interaction With Routing ............................. 26 5 LDP Multicast ............................................ 27 6 Security Considerations .................................. 28 7 References ............................................... 28 8 Author Information ....................................... 29 1. Protocol Overview A Multi-Protocol Label Switch (MPLS) architecture is proposed in [6]. As suggested in that document, a mechanism is needed for distribution of labels with semantic significance to adjacent Label Switch Routers (LSRs). This section provides an overview of the necessary protocol interactions required of a generic Label Distribution Protocol (LDP). MPLS Neighbor Discovery MPLS is intended to be a simple extension to L3 technologies, such as IP, to allow for simplified forwarding syntax. Instead of making a forwarding decision with each L3 datagram - based on the entire contents of the L3 header - a forwarding equivalency is determined for classes of L3 datagrams and a fixed-length label is negotiated between neighboring LSRs along Label Switch Paths (LSPs) from ingress to egress. Thus forwarding for a class of L3 datagrams is determined at each LSR during LSP setup and the per-datagram forwarding process is reduced to label-lookup, label swap and forwarding port selection. Gray, et al Expires in six months [Page 2] Internet Draft draft-gray-mpls-generic-ldp-spec-00 November 1997 To do this, routers with label switching capabilities must be able to determine which of their neighboring peers are similarly capable and - in order to ensure reliable continued operation - the state of each neighbor's label-switch engine. This protocol assumes that the state of the label-switch and route engines is not necessarily identical - i.e. - continued peer-level communication with adjacent routers known earlier to be LSR-enabled is not sufficient evidence of the continued operation of LSR function in the adjacent router. The local LSR sends notification messages periodically (once in a notification period) to each routing neighbor until it has both sent and received such a notification for that neighbor. This message may be sent periodically thereafter in order to maintain the neighbor relationship. The maximum time between such messages is referred to as notification time (NT). Once neighbor relation- ship is established, normal LDP control traffic received from a neighbor within the notification period is sufficient to maintain the relationship. After three notification periods have elapsed with out receiving any LDP protocol messages from a neighboring LSR, the neighbor relationship is considered to have ended and any LDP label bindings acquired from that neighbor are removed. It may be necessary to unsplice and remove bindings for other neighbors as a result of ending a neighbor relationship. LSP Setup An LSR needs to establish and maintain label-associations with the routing neighbors which it knows are LSR capable at any given time in order to provide MPLS functionality across negotiated LSPs. The local LSR may request label bindings (associations of a label with a forwarding equivalency) from downstream neighbors (i.e. - those neighbors advertising reachability for L3 datagrams in that forwarding equivalency), it may create label bindings for its up- stream neighbors (possibly as a result of a bind request) and it may remove bindings (teardown an LSP) associated with specific forwarding equivalencies with any of its neighbors. The local LSR may request a label bind from downstream neighbors corresponding to forwarding equivalencies for which it received bind requests from upstream neighbors, for which it will ingress matching L3 datagrams or in anticipation of LDP bind requests from upstream neighbors. Until receiving a corresponding label bind, the local LSR forwards datagrams using routing (egressing corresponding LSPs if necessary). Gray, et al Expires in six months [Page 3] Internet Draft draft-gray-mpls-generic-ldp-spec-00 November 1997 On receiving a bind request, an LSR