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 may respond with a label bind
    immediately or it may wait for corresponding label binds from its
    downstream neighbors.  The local LSR may provide a label bind
    immediately if it 1) has corresponding downstream labels or 2) it
    will act as egress for the corresponding LSP.  If the LSR does
    not provide an immediate bind, it may continue to receive
    unlabeled L3 datagrams from the requesting neighbor until such
    time as it does provide the requested bind.  If the LSR has
    elected to wait for corresponding downstream label binds, it
    may create a label bind for upstream neighbors at a later time
    (when it has obtained these binds and spliced them with the
    labels it will use in binds to upstream neighbors).

    On receiving a label bind from a downstream neighbor, an LSR 
    may immediately splice this label to labels it has provided, or
    will provide, to its upstream neighbors.

    Any LSR receiving unlabeled L3 datagrams either acts as ingress
    to a corresponding LSP (classifying the L3 datagram, assigning
    and attaching an appropriate label and forwarding the labeled L3
    datagram) or it forwards the datagram using routing.

    An LSR must handle unlabeled L3 datagrams received from routing
    neighbors until successful in negotiating labels with those
    neighbors; thus a downstream neighbor is encouraged to provide
    label binds to its upstream neighbors.

    Any LSR receiving labeled datagrams for which it has an unspliced
    label binding (port-label match but the Label Information Base -
    LIB - entry is incomplete) must act as egress for these datagrams.
    
  LSP Teardown

    If, for some reason (such as a routing change), labels associated
    with a forwarding equivalence are not valid for - or will not be
    supported by - the local LSR, the local LSR must invalidate the
    previous label bind by sending a label teardown message to its
    corresponding upstream neighbors.

    If the local LSR will no longer be using a label it has received
    from a downstream neighbor, it must send a teardown message to
    that neighbor.  This might happen, for example in the case where
    the local LSR asked for the label in a bind request, received
    it in a label bind and no longer requires this label.  This is
    required in order to eliminate associated unused labels.
    
    Teardown messages are sent in a reliable way in order to ensure
    that associated label bindings are released.  When an LSR receives
    an explicit teardown, it must acknowledge the message using a
    teardown acknowledge.  This ensures that the local LSR is able to
    free-up corresponding resources and - in the upstream case - does
    not continue to receive L3 datagrams that are incorrectly labeled.


Gray, et al         Expires in six months                   [Page 4]

Internet Draft    draft-gray-mpls-generic-ldp-spec-00      November 1997




    Implicit teardown occurs when the local LSR receives a bind
    request (label bind) from a neighboring LSR containing the same
    label as was used in a previous binding with the same neighbor.
    Implicit teardown may occur as a result of duplicate bind request
    (label bind) messages.  In general, use of implicit teardown is
    undesirable behavior.
    
    On receiving a label bind with a label already assigned by the
    downstream neighbor, the local LSR performs a level of checking
    to determine if the label identifies the same binding.  If it
    does not, an appropriate reject is returned.  If the label bind
    contains a hop-count that differs from that used in an earlier
    label bind but otherwise identifies the same binding, the local
    LSR removes the previous LIB entry and processes the label bind.
    
    On receiving a bind request specifying a label already in use for
    the upstream neighbor, the local LSR performs a level of checking
    to determine if it identifies the same binding.  If it does not,
    a label bind with an appropriate status is returned.  Otherwise,
    the local LSR removes the corresponding LIB entry and processes
    the bind request.

  Other

    An LSR receiving labeled datagrams for which it has no label
    binding may look beyond the label to determine if this label is
    the bottom of the stack and act as egress for those datagrams for
    which this is the case but must otherwise discard these datagrams.
    In this case, a teardown must be sent to the upstream neighbor
    for the unknown label.

    Except for teardown messages, reliable delivery of LDP messages is
    not required by the protocol.  Thus, explicit acknowledgement is
    defined for teardown messages only and then only in implementations
    not using reliable transport.
    
    Bindings may, as a local matter, be aged out using a very long
    time period.  If this is done - in order to ensure that labels
    are eventually removed when all other efforts to remove them 
    have somehow failed - labels should be associated with individual
    expiry times (perhaps using randomization) in order to reduce
    clumping of protocol activity.

 2.  LDP Messages

    LDP Messages are defined below in a media-independent format.  The
    intent is that several messages may be combined in a single datagram




Gray, et al         Expires in six months                   [Page 5]

Internet Draft    draft-gray-mpls-generic-ldp-spec-00      November 1997




    to minimize the CPU processing overhead associated with input/output.
    Media-specific companion documents will specify how to encapsulate
    LDP messages into actual datagrams, etc. and these specifications
    shall support the carriage of multiple LDP messages in any datagram
    where possible.  To simplify implementation, media-specific companion
    documents should specify use of reliable transport (e.g. - TCP).

    The following sections describe details of the six messages making
    up the generic MPLS protocol, consisting of a neighbor notification
    message (used to drive neighbor discovery and adjacency state) and
    and five messages associated with label setup and teardown (label
    distribution and teardown).  The specific messages are:

      LDP Neighbor Notification (section 2.3).
      LDP Bind Request (section 2.4).
      LDP Label Bind (section 2.5).
      LDP Teardown and Acknowledge (section 2.6).
      LDP Bind Reject (section 2.7).

    Section 2.1 describes the details of the message header common to
    all MPLS messages, section 2.2 describes the format of Message
    Extension Elements and sections 2.3 through 2.7 describe format
    and handling of the specific messages.

 2.1  Common Message Header

    Common Message 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    |    Msg Type   |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Checksum          |        Address Family         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Router ID                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Transaction ID                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Version:

      LDP Version - set to 0x01.








Gray, et al         Expires in six months                   [Page 6]

Internet Draft    draft-gray-mpls-generic-ldp-spec-00      November 1997




    Msg Type:

      Set to the type of this message.  Types are as follows:

          Msg Type   Message
          ========   =====================================
           0x01      LDP Neighbor Notification
           0x02      LDP Bind Request
           0x03      LDP Label Bind
           0x04      LDP Teardown
           0x05      LDP Teardown Acknowledge
           0xFF      LDP Bind Reject

    Length:

      Length of this message, in octets, minus the 12 octets in this
      header.

    Checksum:

      A checksum as defined in [5], except computed for the entire
      message, including header.  The Checksum field is not needed
      when the implementation uses an encasulation that provides
      for detection of corrupted data in messages; when not needed
      for a specific implementation, the contents of this field are
      ignored by the message recipient.

    Address Family:

      This 16 bit integer contains a value from ADDRESS FAMILY NUMBERS
      in Assigned Numbers [4] that encodes the address family that the
      network layer addresses in this message are from.  This provides
      support for multiple network protocols and corresponding address
      families.

    Transaction ID:

      Used to consistently identify pending transactions.  This ID is
      intended to be unique across all transactions currently pending
      at the local LSR but may not be unique to pairs of LSRs in a
      neighbor relationship.

 2.2  LDP Message Extension Elements.

    LDP MEEs consist of data structured in four fields.  In order the   
    fields are X, Type, Length and Value.
 
 



Gray, et al         Expires in six months                   [Page 7]

Internet Draft    draft-gray-mpls-generic-ldp-spec-00      November 1997

    LDP MEE format is as shown:
 
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | X |        Type               |        Length                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Value...                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                          ---                                  /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       ...Value        |               Pad (0's)               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
    X:

      determines how a recipient should behave when it doesn't 
      recognize the MEE Type field. Required behaviors are:
 
        X = 0   Skip the MEE, continue processing the list.
        X = 1   Stop processing, silently drop the LDP message.
        X = 2   Stop processing, drop message, give error indication.
        X = 3   Reserved (currently treat as x = 0).
 
      Unless otherwise specified for MEEs in LDP messages below, the
      value of X is determined by the originating LSR as follows:

        - zero if it is sufficient for ANY dowstream (Bind Request),
        or upstream (Label Bind) LSR to be able to interpret the MEE;

        - one if it is sufficient that failure to interpret this MEE 
        results in no further processing of the message that includes
        it;

        - two if it is necessary to receive an error indication from
        the first LSR that is unable to process this MEE.

    Type:

      A 14 bit integer value encoding how Value is to be interpreted.
      Behavior of an LSR on processing an MEE with an unknown type is
      defined by X above.  Type space is subdivided to encourage use
      outside the IETF as follows:
 
        0                       Null MEE.
        0x0001 - 0x0FFF         Reserved for the IETF.
        0x1000 - 0x11FF         Allocated to the ATM Forum.
        0x1200 - 0x37FF         Reserved for the IETF.
        0x3800 - 0x3FFE         Experimental use.
 




Gray, et al         Expires in six months                   [Page 8]

Internet Draft    draft-gray-mpls-generic-ldp-spec-00      November 1997




    Length:

      The length in octets of the value (not including X, Type and
      Length fields;  a null extension will have only an extension 
      header and a length of zero).  Length is always a multiple of
      four.

    Value:

      An octet string containing information in a format defined for
      Type and having a length in octets of Length.  Value is zero
      padded to the nearest 32-bit boundary.
 
    The extensions list is terminated by the Null MEE, having Type = 0
    and Length = 0.

 2.2.1  Null MEE

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 2.2.2  Forwarding Equivalency MEE

    Example Forwarding Equivalency Extensions for destination, multicast
    group address, source and multicast group address and source-desti-
    nation based forwarding equivalencies.

      Destination Forwarding Equivalency (DFE) MEE

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | X |        Type               |      Length                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Prefix Len|        Destination Prefix (variable length)       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Prefix (cont.)     |               Pad (0's)               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    
    Type:

      Type is set to 0x0001






Gray, et al         Expires in six months                   [Page 9]

Internet Draft    draft-gray-mpls-generic-ldp-spec-00      November 1997




      Multicast Forwarding Equivalency (MFE) MEE

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | X |        Type               |      Length                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 Multicast Group Address                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    
    Type:

      Type is set to 0x0002

      Source-qualified Multicast Forwarding Equivalency (SMFE) MEE

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | X |        Type               |      Length                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Prefix Len|          Source Prefix (variable length)          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Prefix (cont.)     |               Pad (0's)               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                Multicast Group Address                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
    Type:

      Type is set to 0x0003

      Source-destination Forwarding Equivalency (SFE) MEE

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | X |        Type               |      Length                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Prefix Len|        Destination Prefix (variable length)       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Prefix (cont.)     |               Pad (0's)               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Prefix Len|          Source Prefix (variable length)          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Prefix (cont.)     |               Pad (0's)               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Gray, et al         Expires in six months                   [Page 10]

Internet Draft    draft-gray-mpls-generic-ldp-spec-00      November 1997



    Type:

      Type is set to 0x0004

 2.2.3  Explicit Route MEE

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | X |        Type               |      Length                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Address Length (Bits)     |           Reserved            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Address 1                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                                                               /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Address 1 (cont)      |         Address 2                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                                                               /
     /                                                               /
     /                                                               /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Address N (cont)   |               Pad (0's)               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    X:

      X is set to either one or two, in LDP messages, as processing of
      this MEE is significant to message semantics.  Whether or not an
      error is to be reported on failure to interpret this MEE is local
      to the originating LSR, if the MEE is included in a Bind Request.
      In a Label Bind, however, X must be set to two in this MEE such
      that bindings may be released if one of the listed LSRs is unable
      to interpret this MEE.

    Type:

      Type is set to 0x0005

    Address Length:

      Length in bits of each address in the list.  All addresses in the 
      list must be of the same length.








Gray, et al         Expires in six months                   [Page 11]

Internet Draft    draft-gray-mpls-generic-ldp-spec-00      November 1997






    Address 1 - N:

      Addresses of the LSRs which this LSP is to traverse.  On Receipt,
      the first address should be an address of the local LSR.  On
      transmittal, the first address should be an address of the next
      neighboring LSR in the intended LSP.

    This MEE may be included in Bind Request and Label Bind messages.
    Each LSR processing a message containing this MEE must:

      verify that the first address in the list corresponds to a local
      address associated with this LSR;

      construct a new MEE omitting the first address;

      include this new MEE in Bind Request (downstream) or Label Bind
      (upstream), with additional values and MEEs as required and send
      this message to the next addressed LSR in the explicit path.

    Bind Requests with an Explicit Route MEE containing at least two
    addresses on receipt result in Bind Requests with one less address
    sent to the next downstream LSR neighbor.  In the same way, Label
    Bind messages result in Label Binds to the next upstream neighbor.

    If the only address present in the MEE is that of the local LSR,
    no further processing (beyond that of creating the binding) is
    required.

 2.2.4  Traversal List MEE

    This MEE may be included in in Bind Requests in order to prevent
    rippling LDP messages in a loop (useful - for instance - in Multi-
    cast LSPs setup using upstream allocation).
















Gray, et al         Expires in six months                   [Page 12]

Internet Draft    draft-gray-mpls-generic-ldp-spec-00      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | X |        Type               |      Length                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Address Length (Bits)     |          Reserved             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Address 1                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                                                               /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Address 1 (cont)      |         Address 2                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                                                               /
     /                                                               /
     /                                                               /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Address N (cont)   |               Pad (0's)               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    X:

      X is set to one, in LDP messages, as processing of this MEE is
      significant to message semantics yet an error due to not being
      able to interpret this MEE should not result in a Bind Reject
      message.

    Type:

      Type is set to 0x0006

    Address Length:

      Length in bits of each address in the list.  All addresses in the 
      list must be of the same length.

    Address 1 - N:

      Addresses of the LSRs which this LSP has traversed.  On Receipt,
      this list must not contain the address of this LSR (as defined 
      for the address family in the Common Message Header.  In the
      event that it does, the message containing this MEE is silently
      dropped.







Gray, et al         Expires in six months                   [Page 13]

Internet Draft    draft-gray-mpls-generic-ldp-spec-00      November 1997




2.2.5  Authentication MEE
 
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | X |        Type               |      Length                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Authentication Type                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
    X:

      X is set to two, in LDP messages, as processing of this MEE is
      significant to message semantics and an error should be reported
      as a result of authentication failure.

    Type:

      Type is set to 0x0007

    Authentication Type:

      Identifies the authentication method in use.  Current allowed
      values are:
 
        1  - Cleartext Password
        2  - Keyed MD5
        3+ - Reserved
 

    Authentication Data:

      Contains the type-specific authentication information.  For
      Cleartext Password Authentication, this field consists of a
      variable length password.
 
      For Keyed MD5 Authentication, the Authentication Data contains
      the 16 byte MD5 digest of the entire datagram, including the
      encapsulating protocol's header, with the authentication key
      appended to the end of the packet.  The authentication key is not
      transmitted with the packet.  The MD5 digest covers only the
      the Common Message Header.





Gray, et al         Expires in six months                   [Page 14]

Internet Draft    draft-gray-mpls-generic-ldp-spec-00      November 1997




 2.2.6  Vendor Specific MEE

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | X |        Type               |      Length                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  Vendor ID                    |  Data....     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                         Data (continued)                      /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
    Type:

      Type is set to 0x3FFF

    Vendor ID:

      802 Vendor ID as assigned by the IEEE [4]
 
    Data:

      The remaining octets after the Vendor ID in the payload are
      vendor-dependent data.

 2.3  LDP Neighbor Notification

    Neighbor Notification messages are similar to those defined in [12]
    - that is, each notification contains addresses of those neighbors 
    heard from.  The addresses are contained in a Neighbor List MEE as
    follows:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | X |        Type               |      Length                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Address Length (Bits)     |           Reserved            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Address 1                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                                                               /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Address 1 (cont)      |         Address 2                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                                                               /
     /                                                               /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Address N (cont)   |               Pad (0's)               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Gray, et al         Expires in six months                   [Page 15]

Internet Draft    draft-gray-mpls-generic-ldp-spec-00      November 1997



    X:

      X is set to 2.

    Type:

      Type is set to 0x0008

    Address Length:

      Length in bits of each address in the list.  All addresses in the 
      list must be of the same length.

    Address 1 - N:

      Addresses of the LSRs which this LSR has heard from.  Provided 
      that the cannonical address of the route engine is the same length
      as the network local address, that address would be used.  Other-
      wise the network local address associated with the local route
      engine is used.

    LDP Neighbor Notification format:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                        Common Header                          /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                                                               /
     /                       Neighbor List MEE                       /
     /                       (Variable  Length)                      /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                                                               /
     /               Additional Message Extension Elements           /
     /                            (if any)                           /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Common Header:
 
      In the common header, Type is set to 0x01.  Transaction ID is set
      to zero.
 
    Neighbor List Message Extension Element:

      Formatted as described above.  Neighbor List contains addresses
      of neighboring LSRs heard from.  The local LSR - if originating
      the message - attaches a Neighbor List MEE containing its address.
      On receiving a Neighbor Notification message not containing its
      address, the local LSR appends its address to the list and sends
      a new Neighbor Notification message.


Gray, et al         Expires in six months                   [Page 16]

Internet Draft    draft-gray-mpls-generic-ldp-spec-00      November 1997




    Additional Message Extension Elements:

      The Neighbor Notification may contain additional MEE information.
      This information can have no bearing on processing the preceding
      portions of the message.  Any interpretable MEEs may be included
      in Neighbor Notifications occurring as a result of processing
      this message.  Non-interpretable MEEs must be so included.  After
      all such additional MEEs (if any), a Null MEE must be appended.

    Neighbor Notification processing is further described in the state
    transition table in section 3 (LDP neighbor state transitions).

 2.4  LDP Bind Request

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                        Common Header                          /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Label Bits                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             Label                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                                                               /
     /              Forwarding Equivalency MEE Information           /
     /                       (Variable  Length)                      /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                                                               /
     /               Additional Message Extension Elements           /
     /                            (if any)                           /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Common Header:
 
      In the common header, Type is set to 0x02 and Transaction ID is
      a locally unique (non-zero) identifier which the local LSR may
      use to pair this request to a corresponding subsequent Label
      Bind.
 
    Label Bits:

      This field contains an integer in which binary 1 positions indicate
      the bits available for assignment in a label by the downstream
      neighboring LSR.  The responding LSR should not assign labeling
      significance to any bit positions not set in this field.  If this
      field is set to all ones, the downstream LSR is free to allocate
      any label for this request.




Gray, et al         Expires in six months                   [Page 17]

Internet Draft    draft-gray-mpls-generic-ldp-spec-00      November 1997


    Label:

      A Label requested by the upstream (requesting) LSR.  In the case 
      where the Label Bits field is not all ones, this field defines
      values for bit positions not available for assignment by the
      downstream LSR.  For example, a Label Bits field of all zeros
      indicates an upstream label allocation with the label requested
      exactly as defined by this field.  This field is set equal to
      zero to indicate that downstream allocation of all available
      bit positions is desired.

    Forwarding Equivalency MEE Information:

      This variable length field contains FEC-related information - for
      example - in a format defined in section 2.2.2 above, associated
      with this request.  Only one Forwarding Equivalency MEE may be
      included in each Bind Request.

    Additional Message Extension Elements:

      The Bind Request message may contain additional MEE information
      intended to further qualify the semantics associated with this
      label negotiation.  An example is inclusion of an Explicit Route
      MEE.  After all such additional MEEs (if any), a Null MEE must
      be appended.

    Bind Request messages may be satisfied by the local LSR if a label
    matching the the restrictions (if any) of the Bind Request can be
    allocated and any of the following conditions are met:

      the local LSR is able to interpret all MEEs included in the Bind
      Request message and has a LIB entry with an exactly matching
      qualified forwarding equivalency;

      the local LSR is able to interpret all MEEs included in the Bind
      Request message and will act as egress for L3 datagrams arriving
      labeled for this qualified forwarding equivalency;

      the local LSR is able to find a bit-wise match in an associated
      cache for all uninterpretable MEEs in a single LIB entry which
      otherwise matches interpretable portions of the Bind Request.

    If the Bind Request can be satisfied by the local LSR, the LSR
    creates a binding, splices it in the LIB, builds a Label Bind
    message as described in section 2.5 below and sends it to the
    requesting neighbor.

    If the Bind Request cannot be satisfied for reasons of labeling
    restrictions, a Label Bind is constructed as described below,
    with Status 0x0002 and labeling problem information (set bits
    in the Label field).


Gray, et al         Expires in six months                   [Page 18]

Internet Draft    draft-gray-mpls-generic-ldp-spec-00      November 1997




    If the Bind Request cannot be satisfied because one or more MEEs
    cannot be interpreted by the local LSR and at least one of these 
    has an "X" value of 2 OR the local LSR has no downstream neighbors
    (as potentially qualified by interpretable MEEs), a Label Bind is
    constructed with a Status of 0x0005, including all non-interprable
    MEEs.

    Otherwise, the local LSR sends a corresponding Bind Request to
    downstream neighbors (possibly restricted by qualifications in
    the pending Bind Request - e.g. Explicit Route MEE) including
    at least all semantically significant and uninterpretable MEEs.
    The local LSR preserves state information relating pending
    upstream (received) Bind Requests to pending downstream (sent)
    Bind Requests including a mapping of corresponding Transaction
    IDs.

 2.5  LDP Label Bind

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                        Common Header                          /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Bind Status          |          Hop Count            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             Label                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                                                               /
     /              Forwarding Equivalency MEE Information           /
     /                       (Variable  Length)                      /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                                                               /
     /               Additional Message Extension Elements           /
     /                            (if any)                           /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Common Header:
 
      In the common header, Type is set to 0x03.  Transaction ID is set
      equal to the transaction ID in the corresponding Bind Request, if
      any, otherwise, it is set equal to zero.
 
    Bind Status:

      This 16 bit integer contains the status of the binding.  A non-zero
      value here indicates that the LDP Bind Request associated with the
      included Request ID was unsuccessful for reasons indicated by the 
      status value.  This field is not significant and must be set to zero
      if this message is not the result of a LDP Bind Request message
      (Transaction ID equal zero).

Gray, et al         Expires in six months                   [Page 19]

Internet Draft    draft-gray-mpls-generic-ldp-spec-00      November 1997




    Status values are:

        0x0001 - Insufficient Resources
        0x0002 - Invalid Labeling Restrictions
        0x0003 - No suitable egress found
        0x0004 - Label in use or may not be assigned
        0x0005 - Unable to interpret MEE

    Hop Count:

      This is set to indicate the Hop Count reported to this LSR by its
      downstream neighbors (relative to this LSP) plus the number that
      this LSR would decrement TTL by for L3 datagrams on this LSP if
      these datagrams were being forwarded using L3 routing.  The LSR
      assumes a downstream Hop Count of zero if it is the egress for
      this LSP.

    Label:

      The Label associated with this message.  If this field is non-zero
      in an unsuccessful binding, non-zero bit positions indicate invalid
      bit-values or assignment in the corresponding LDP Bind Request.

    Forwarding Equivalency MEE Information:

      This variable length field contains FEC-related information - for
      example - in a format defined in section 2.2.2 above, associated
      with this request.  Only one Forwarding Equivalency MEE may be
      included in each Label Bind.

    Additional Message Extension Elements:

      The Label Bind message may contain additional MEE information
      intended to further qualify the semantics associated with this
      label negotiation.  After all such additional MEEs (if any), a
      Null MEE must be appended.

    Label Binds may be sent to upstream LSR neighbors for a number of
    reasons.  The local LSR may have information required to create a
    LIB entry and provide a Label Bind in response to a pending Bind
    Request, the local LSR may have detected a routing change and be
    in the process of setting up topology based labeling, the local
    LSR may have received an unlabelled datagram or the local LSR may
    need to negotiate labels with upstream neighbors in order to meet
    the requirements of a Label Bind received from a downstream LSR.






Gray, et al         Expires in six months                   [Page 20]

Internet Draft    draft-gray-mpls-generic-ldp-spec-00      November 1997




    On receipt of a Label Bind with a zero Transaction ID, the local
    LSR may create a LIB entry binding the downstream label to a
    forwarding equivalency (with possible MEE qualification) and
    construct corresponding Label Bind messages and forward them to
    its upstream neighbors (potentially restricted by qualifications
    in the Label Bind - e.g.  Explicit Route MEE) including at least
    semantically significant and all uninterpretable MEEs.

    The local LSR may act as ingress to the corresponding LSP if it
    is able to interpret all MEEs included in the Label Bind message.

    If the received Label Bind has a non-zero Transaction ID, the
    local LSR finds the corresponding Bind Request information.  If
    the status code in the Label Bind is success, the local LSR may
    insert the new label in a LIB entry from Label Bind and, if the
    Transaction ID corresponds to a Bind Request from one or more
    upstream neighbors, create appropriate label(s) for inclusion in
    Label Bind Message(s) to upstream neighbor(s).  If the Status is
    non-zero, processing is as follows:
    
      if there are no corresponding pending Bind Requests from
      upstream neighbors, the local LSR makes a local determination
      as to whether or not to repeat the Bind Request - based on
      the specific Status given,

      if there are corresponding pending Bind Requests from upstream
      meighbors, the action is determined using this table -

        Status        Action
        ==========    ===============================================
        0x0001|3      Accumulate Status from pending downstream Bind
                      Requests associated with upstream Bind Requests
                      and, if no further pending Bind Requests exist,
                      return a Label Bind with a Status code of 0x0003.

        0x0002|4      Make a local determination on whether or not to
                      repeat the Bind Request using different values.
                      In the event that Bind Request is not retried,
                      return a Label Bind to upstream neighbors with
                      with associated pending Bind Requests using a
                      Status code of 0x0003.

        Other         Return a Label Bind for associated pending Bind
                      Requests with this Status code to corresponding
                      upstream neighbors.






Gray, et al         Expires in six months                   [Page 21]

Internet Draft    draft-gray-mpls-generic-ldp-spec-00      November 1997



    As described in section 2.4 above, an LSR may make a local
    determination to satisfy Bind Requests of upstream neighbors in
    certain conditions.  In the event that the local LSR is able to
    act as egress, it may do so rather than returning a Label Bind
    with a Status code of either 0x0003 or 0x0005.

    Receipt of a Label Bind is not a commitment to use it, hence no
    acknowledgement is required.  However, if the local LSR is unable 
    to use a label included in a Label Bind, it should respond with
    an appropriate LDP Bind Reject.  Examples of why this might occur
    are:

      the current LSR has no upstream neighbors and is itself unable
      to act as ingress for the qualified forwarding equivalency (e.g.
      - it is unable to interpret one or more MEEs);

      the label provided is not consistent with the hardware used by
      the downstream interface;

      the label provided is already bound to a different qualified
      forwarding equivalency for this interface;

      the locally configured maximum hop-count is exceeded (indicating
      a possible labeling loop).

    Returning a Bind Reject message when appropriate allows the down-
    stream neighbor to release invalid bindings and, potentially try
    again.

    An LSR should report a Bind Reject downstream if, processing of
    the Label Bind message results in a excessive hop-count - either
    as reported by an upstream LSR or as determined by the local LSR. 
    Excessive hop-count results when the incremented value of the
    hop-count field in the Label Bind exceeds a locally configured
    maximum.  The default value for this maximum is 32.
    
 2.6  LDP Teardown and Acknowledge

    LDP Teardown format:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                        Common Header                          /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             Label                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                                                               /
     /               Additional Message Extension Elements           /
     /                            (if any)                           /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Gray, et al         Expires in six months                   [Page 22]

Internet Draft    draft-gray-mpls-generic-ldp-spec-00      November 1997


    Common Header:
 
      In the common header, Type is set to 0x04 and Transaction ID is a
      locally unique (non-zero) identifier which the local LSR may use to
      pair this message to a corresponding Teardown Acknowledge.
 
    Label:

      The Label associated with this message.  The value in this field is
      intended to reflect an existing label bound to the remaining contents
      of this message.

    Additional Message Extension Elements:

      The Teardown message may contain additional MEE information.
      This information can have no bearing on processing the preceding
      portions of the message.  For example, inclusion of a Forwarding
      Equivalency MEE does not scope this message.  Any interpretable
      MEEs may be included in Teardown messages which occur as a result
      of processing this message.  Non-interpretable MEEs must be so
      included.  After all such additional MEEs (if any), a Null MEE
      must be appended.

    LDP Teardown Acknowledge format:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                        Common Header                          /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Common Header:
 
      In the common header, Type is set to 0x05.  Transaction ID is set
      equal to the Transaction ID in the corresponding Teardown message.

    When the local LSR determines that a label or its corresponding LSP
    is no longer valid, it must send a Teardown message using reliable
    protocol.  This is necessary because the local LSR only invalidates
    LIB entries on loss of neighbor, Bind Reject, timeout (locally con-
    figurable parameter with a default on the order of hours) and Tear-
    down.  Consequently, for implementations using unreliable transport,
    Teardown messages must be acknowledged with a Teardown Acknowledge;
    un-acknowledged Teardown messages must be periodically repeated until
    they are acknowledged.  Repeat Teardown messages must use the same
    Transaction ID as was used in the original Teardown message.  For
    reliable transport, Teardown messages may be considered to have been
    acknowledged on successful transmission; in such implementations, the
    Transaction ID is without meaning and may be ignored by the receiver.




Gray, et al         Expires in six months                   [Page 23]

Internet Draft    draft-gray-mpls-generic-ldp-spec-00      November 1997



 
 2.7  LDP Bind Reject

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                        Common Header                          /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Reject Status         |         Reserved              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             Label                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                                                               /
     /                     Message Extension Elements                /
     /                            (if any)                           /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Common Header:
 
      In the common header, Type is set to 0xFF.  Transaction ID is 
      copied from the Transaction ID in the Label Bind triggering the
      Bind Reject.  

    Reject Status:

      Valid Status numbers are:

        0x0001 - Unusable label (label is incompatible with interface)
        0x0002 - Label in use
        0x0003 - No suitable ingress found
        0x0004 - locally configured maximum hop-count exceeded
        0x0005 - Unable to interpret MEE

    Label:

      When non-zero, used to indicate the label in a corresponding
      Label Bind or Teardown.  This field is needed in order to allow
      for the correction of invalid Label Binds in a state-less Label
      Bind protocol.  This label is used to find a LIB entry and remove
      the corresponding label - after which, the local LSR may make a
      local determination to retry.

    Message Extension Elements:

      Bind Rejects resulting from inability to process MEEs must include
      offending MEEs.  With Status "Unable to interpret MEE" (0x0005),
      the MEE may be truncated after the MEE header (Length set to 0).
      After all included MEEs (if any), a Null MEE must be appended.




Gray, et al         Expires in six months                   [Page 24]

Internet Draft    draft-gray-mpls-generic-ldp-spec-00      November 1997


    On receiving a Bind Reject message with a zero Transaction ID, the
    local LSR removes the (non-zero) label associated with the interface
    on which the reject was received and makes a local determination -
    based on Status code - as to whether or not to retry.  In the event
    that the label removed was part of otherwise complete LIB entries,
    the local LSR is unable to act as ingress for the corresponding LSP
    and will not retry, the local LSR must generate corresponding Bind
    Reject messages using downstream labels to appropriate downstream
    neighbors.
 
 3.  LDP State Transitions

    LDP neighbor state transitions (ND-FSM neighbors on one interface)

    State          Event              Action             New State
    ============   ================   ================   ============
    Down           NT Expires         Notify, Reset NT   Self Up
    Down           Get Notify(+)      Notify, Reset NT   LDP Up
    Self Up        NT Expires         Notify, Reset NT   Self Up
    Self Up        Get Notify(+)      Notify, Reset NT   Self Up
    Self Up        Get Notify(*)      Reset NT           LDP Up
    Self Up        Get LDP Message    Notify, Reset NT   Self Up
    LDP Up         NT Expires         Reset NT           Expired 1
    Expired 1      NT Expires         Notify, Reset NT   Expired 2
    Expired 2      NT Expires         Notify, Reset NT   Self Up
    LDP Up         Get Notify(+)      Notify, Reset NT   LDP Up
    LDP Up         Get LDP Message    Reset NT           LDP Up
    Expired 1      Get LDP Message    Reset NT           LDP Up
    Expired 2      Get LDP Message    Reset NT           LDP Up

    *  - Neighbor Notify containing the ID of the local LSR.
    +  - Neighbor Notify not containing the ID of the local LSR.
    NT - Neighbor Notification Timer

    Down:

      Starting state for LDP neighbor discovery.

    Self Up:

      Sending Notify to a neighbor which has not yet sent Notify.

    LDP Up:

      Neighbors in full LDP communication.

    Expired 1:

      One Notification Time (NT) has expired without receiving a
      Notify from this neighbor.



Gray, et al         Expires in six months                   [Page 25]

Internet Draft    draft-gray-mpls-generic-ldp-spec-00      November 1997




    Expired 2:

      Two Notification Times have elapsed without receiving a
      Notify from this neighbor.

    LDP state transitions (for each routing neighbor)

    State               Event                   New State
    =================   =====================   =================
    Routing Only        Reach LDP Up (ND-FSM)   Topology Labeling
    Topology Labeling   complete labeling       LDP Idle
    LDP Idle            get unlabeled datagram  Flow Labeling
    LDP Idle            management directive    Flow Labeling
    Flow Labeling       complete labeling       LDP Idle
    LDP Idle            routing change          Topology Labeling
    Any state           Self Up (ND-FSM)        Routing Only

    Routing Only:

      In the routing only state, the local LSR can have no valid
      LIB entries for this neighbor.

    Topology Labeling:

      Normal active label distribution mode.  Primarily used to
      setup topology based best effort label switched paths.

    LDP Idle:

      LDP essentially innactive.  Randomized aging of labels, 
      Neighbor Notifications being sent (to neighbors).

    Flow Labeling:

      Triggered by receipt of an unlabelled datagram or management
      or other directive.  The local LSR seeks to negotiate labels
      with neighbors to establish an LSP.

 4.  LDP Interaction With Routing

     Routing protocols drive LDP.  Changes in how datagrams classified
     in a forwarding equivalency would be forwarded must result in new
     LDP associated with the new LSP to be established.

     Routing protocols may produce temporary routing loops - loops 
     which are potentially more severe given improved forwarding as
     a result of MPLS.




Gray, et al         Expires in six months                   [Page 26]

Internet Draft    draft-gray-mpls-generic-ldp-spec-00      November 1997



     In this document, discussion of how any particular routing
     change results in setup of a new LSP is out-of-scope.  We assert
     that implementers are responsible for ensuring that this occurs.

     However, there are a few things that may be observed about this
     protocol as currently defined.

     a) given that routing protocols are used to drive LDP in any
        particular LSR, this protocol converges as corresponding
        routing protocols converge;

     b) routing changes driven by reachability advertisement tend to
        result in new Label Bind driving further Label Binds, thus
        increasing the likelihood that temporary loops in LDP will
        be detected via the hop-count mechanism;

     c) the local focus with end-to-end effect in this specification
        tends to break LSPs in highly dynamic route-change scenarios
        (rather then twisting them together) - forcing traffic to be
        routed conventionally under these conditions and reducing the
        likelihood of looping LSPs;

     d) the most likely scenarios in this specification for producing
        a loop are when performing upstream label allocation (as may
        be used for explicit route or multicast LSPs);

     e) looping in an explicit route is impossible and this document
        includes recommended mechanisms for preventing other types
        of looping LSP formation.

 5.  LDP Multicast

     Setting up Multicast LSPs using upstream allocation can be done
     using Bind Request messages including the appropriate Multicast
     FEC MEE.  The Traversal List MEE should be included in these
     Bind Request messages.

     Determination of the paths to be used in any Multicast tree is
     accomplished locally by the individual Multicast capable LSRs.
     Where it might be impossible for the local LSR to determine
     which of its neighbors need to be included, that neighbor will
     know whether it needs to be in the specified Multicast tree and
     may reject Bind Requests using Label Bind messages with a Status
     code of 0x0003.  Hence, if any LSR (Multicast capable or not) is
     unable to determine which of its neighbors need to be part of
     a Multicast LSP, that LSR forwards appropriate Bind Requests to
     all of its neighbors, except the one from which it received the
     original one, and only returns a successful Label Bind when it
     receives a successful Label Bind from at least one downstream
     neighbor.


Gray, et al         Expires in six months                   [Page 27]

Internet Draft    draft-gray-mpls-generic-ldp-spec-00      November 1997



 6.  Security Considerations

     When and where required, one or more Authentication MEEs may be
     included in the first LDP message in a transmission datagram.
     Successful authentication of the first message in a datagram
     is sufficient for all messages in the same transmission.  The
     entire transmission datagram is silently discarded on failure
     to authenticate.

     Media-specific companion documents may provide for security by
     inclusion of authentication in datagram encasulation, or by 
     some other means.

     Distribution of authentication keys used in comparison with the
     content of the Authentication MEE is outside the scope of this
     document.

 7.  References

   [1] "Tag Switching Architecture - Overview", Rekhter, Davie, Katz,
       Rosen, Swallow, Farinacci, work in progress, Internet Draft
       <draft-rekhter-tagswitch-arch-01.txt>

   [2] "NBMA Next Hop Resolution Protocol (NHRP)", J. Luciani et al.,
       work in progress, draft-ietf-rolc-nhrp-11.txt, March 1997.

   [3] "Cisco System's Tag Switching Overview", IETF RFC 2105,
       Y.Rekhter, B.Davie, D.Katz, E.Rosen, G.Swallow,
       February, 1997.

   [4] Reynolds J, Postel J. "Assigned numbers"  RFC 1700, October 1994

   [5] Postel, J. "INTERNET PROTOCOL" RFC 791, September 1981.

   [6] "A Proposed Architecture for MPLS", E. Rosen, A. Viswanathan, R.
       Callon, work in progress, draft-rosen-architecture-00.txt, July
       1997.

   [7] "Tag distribution Protocol", Doolan, Davie, Katz, Rekhter, Rosen,
       work in progress, internet draft <draft-doolan-tdp-spec-01.txt>

   [8] "Label Switching: Label Stack Encodings", Rosen, Rekhter, Tappan,
       Farinacci, Fedorkow, Li, work in progress, internet draft
       <draft-rosen-tag-stack-02.txt>

   [9] "A Framework for Multiprotocol Label Switching", 5/12/97, draft-
       ietf-mpls-framework-01.txt, Callon, Doolan, Feldman, Fredette,
       Swallow, Visanathawan




Gray, et al         Expires in six months                   [Page 28]

Internet Draft    draft-gray-mpls-generic-ldp-spec-00      November 1997




   [10] "ARIS: Aggregate Route-Based IP Switching", A. Viswanathan, N.
       Feldman, R. Boivie, R. Woundy, work in progress, Internet Draft
       <draft-viswanathan-aris-overview-00.txt>, March 1997.

   [11] "ARIS Specification", N. Feldman, A. Viswanathan, work in
       progress, Internet Draft <draft-feldman-aris-spec-00.txt>, March
       1997.

   [12] "Server Cache Synchronization Protocol", J. Luciani, et al,
        work in progress, Internet Draft <draft-ietf-ion-scsp-01.txt>,
        March, 1997.

8.  Author Information

        Eric Gray
        Lucent Technologies, Inc.
        1600 Osgood Street
        North Andover, MA 01845
        ewgray@lucent.com

        Zheng Wang
        Lucent Technologies, Inc.
        101 Crawfords Corner Road
        Holmdel, NJ 07733
        zhwang@lucent.com

        Grenville Armitage
        Lucent Technologies, Inc.
        101 Crawfords Corner Road
        Holmdel, NJ 07733
        gja@lucent.com




















Gray, et al         Expires in six months                   [Page 29]