Internet Draft


Network Working Group                                        L Andersson
Internet Draft                                                  Ericcson
Expiration Date: September 1998
                                                                P Doolan
                                                       Ennovate Networks

                                                               N Feldman
                                                                     IBM

                                                              A Fredette
                                                             Bay Networks

                                                                R Thomas
                                                           cisco Systems

                                                              March 1998


                      Label Distribution Protocol


                         draft-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), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).











Anderson, et al.                                                [Page 1]


Internet Draft            draft-mpls-ldp-00.txt               March 1998


1. 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
   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.





Contents

         Status of this Memo  ......................................   1
    1    Abstract  .................................................   2
    2    LDP Overview  .............................................   3
    3    LDP Operation  ............................................   4
    3.1  Selecting Streams  ........................................   4
    3.2  Label Spaces, LDP Identifiers, LDP Sessions and LDP Transport  5
    3.3  LDP Sessions between non-Directly Connected LSRs  .........   6
    3.4  LDP Discovery  ............................................   7
    3.5  Establishing and Maintaining LDP Session  .................   8
    3.6  Label Distribution and Management  ........................  15
    3.7  LDP Identifiers and Next Hop Addresses  ...................  17
    3.8  Loop Detection  ...........................................  18
    3.9  Loop Prevention via Diffusion  ............................  18
    3.10 Explicitly routing LSPs  ..................................  19
    4    Protocol Specification  ...................................  22
    4.1  Discovery Class Messages  .................................  22
    4.2  Adjacency Class Messages  .................................  26
    4.3  Advertisement Class Messages  .............................  29
    4.4  LDP Objects  ..............................................  43
    5    Security  .................................................  63
    6    Acknowledgments  ..........................................  63
    7    References  ...............................................  64
    8    Author Information  .......................................  64












Anderson, et al.                                                [Page 2]


Internet Draft            draft-mpls-ldp-00.txt               March 1998


2. 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.

   An LSP is created for a stream, which identifies a path through a
   network.  Streams may be extracted from information existing in the
   routing protocols, or may be configured.  LSPs are extended through a
   network as each LSR "splices" incoming labels for a stream to the
   outgoing label assigned to the next hop for the given stream.

   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 Adjacency" between them. A single LDP
   adjacency allows each peer to learn the other's label mappings i.e.
   the protocol is bi-directional.

   There are three classes of LDP messages: 1) A discovery class
   message, used to announce and maintain the presence of an LSR in a
   network, 2) An adjacency class message, used to establish, maintain,
   and terminate adjacencies between LSR peers, and 3) An advertisement
   class message, used to create, change, and delete label mappings for
   streams.

   The discovery class message provides the 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 an adjacency 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 or advertise a label mapping to a peer is largely a
   local decision made by the LSR.  In general, an 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.  This document is written from the perspective of  control-
   traffic driven allocation of labels ie it describes mappings which
   are initiated for routes in the forwarding table, regardless of the
   traffic over those routes. However, LDP does not preclude support of
   a data-driven model.




Anderson, et al.                                                [Page 3]


Internet Draft            draft-mpls-ldp-00.txt               March 1998


   Correct operation of the label forwarding paradigm requires that
   forwarding peers agree on the mappings between Streams and 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 for adjacency and
   advertisement class messages.

   This document is written with respect to unicast routing only.
   Multicast will be addressed in a future revision, although in some
   cases placeholders for multicast have been indicated.

   The convention used in this document is the same as that used in the
   documentation of the internet protocols [rfc1700] i.e. 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.


3. LDP Operation

3.1. Selecting Streams

   A stream is one path or an aggregate of several paths, treated as one
   for the purpose of forwarding; i.e., all paths using the same 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 stream choice.

   Following are the currently defined type of streams. New streams
   types may be added as needed:


        a)   Network Address
             This stream is a single network address which resides in a
             forwarding information base (FIB).  This type results in
             the specified address sustaining its own LSP tree.  It is
             recommended in environments where no aggregation informa-
             tion is provided by the routing protocols (such as RIP), or
             in networks where the number of destination 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



Anderson, et al.                                                [Page 4]


Internet Draft            draft-mpls-ldp-00.txt               March 1998


             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 initi-
             ated the link state advertisement.  This type allows aggre-
             gation of traffic on behalf of multiple datagram 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)   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.

        f)   Flow This stream contains information pertaining to a con-
             stant 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.


3.2. Label Spaces, LDP Identifiers, LDP Sessions and LDP Transport

   The notion of "label space" is useful for discussing the assignment
   and distribution of local (incoming) 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.

          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



Anderson, et al.                                                [Page 5]


Internet Draft            draft-mpls-ldp-00.txt               March 1998


          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 Identifiers for plat-
     form-wide label spaces are always both zero.  This document uses
     the following print representation for LDP Identifiers:
                      :