From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001
From: Thomas Voss <mail@thomasvoss.com>
Date: Wed, 27 Nov 2024 20:54:24 +0100
Subject: doc: Add RFC documents

---
 doc/rfc/rfc3036.txt | 7395 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 7395 insertions(+)
 create mode 100644 doc/rfc/rfc3036.txt

(limited to 'doc/rfc/rfc3036.txt')

diff --git a/doc/rfc/rfc3036.txt b/doc/rfc/rfc3036.txt
new file mode 100644
index 0000000..63867bd
--- /dev/null
+++ b/doc/rfc/rfc3036.txt
@@ -0,0 +1,7395 @@
+
+
+
+
+
+
+Network Working Group                                        L. Andersson
+Request for Comments: 3036                           Nortel Networks Inc.
+Category: Standards Track                                       P. Doolan
+                                                        Ennovate Networks
+                                                               N. Feldman
+                                                                 IBM Corp
+                                                              A. Fredette
+                                                            PhotonEx Corp
+                                                                B. Thomas
+                                                      Cisco Systems, Inc.
+                                                             January 2001
+
+
+                           LDP Specification
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   The architecture for Multi Protocol Label Switching (MPLS) is
+   described in RFC 3031.  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 a set of procedures, called a
+   label distribution protocol, by which one LSR informs another of
+   label bindings it has made.  This document defines a set of such
+   procedures called LDP (for Label Distribution Protocol) by which LSRs
+   distribute labels to support MPLS forwarding along normally routed
+   paths.
+
+
+
+
+
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                     [Page 1]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+Table of Contents
+
+   1          LDP Overview  .......................................   5
+   1.1        LDP Peers  ..........................................   6
+   1.2        LDP Message Exchange  ...............................   6
+   1.3        LDP Message Structure  ..............................   7
+   1.4        LDP Error Handling  .................................   7
+   1.5        LDP Extensibility and Future Compatibility  .........   7
+   1.6        Specification Language  .............................   7
+   2          LDP Operation  ......................................   8
+   2.1        FECs  ...............................................   8
+   2.2        Label Spaces, Identifiers, Sessions and Transport  ..   9
+   2.2.1      Label Spaces  .......................................   9
+   2.2.2      LDP Identifiers  ....................................  10
+   2.2.3      LDP Sessions  .......................................  10
+   2.2.4      LDP Transport  ......................................  11
+   2.3        LDP Sessions between non-Directly Connected LSRs  ...  11
+   2.4        LDP Discovery   .....................................  11
+   2.4.1      Basic Discovery Mechanism  ..........................  12
+   2.4.2      Extended Discovery Mechanism  .......................  12
+   2.5        Establishing and Maintaining LDP Sessions  ..........  13
+   2.5.1      LDP Session Establishment  ..........................  13
+   2.5.2      Transport Connection Establishment  .................  13
+   2.5.3      Session Initialization  .............................  14
+   2.5.4      Initialization State Machine  .......................  17
+   2.5.5      Maintaining Hello Adjacencies  ......................  20
+   2.5.6      Maintaining LDP Sessions  ...........................  20
+   2.6        Label Distribution and Management  ..................  21
+   2.6.1      Label Distribution Control Mode  ....................  21
+   2.6.1.1    Independent Label Distribution Control  .............  21
+   2.6.1.2    Ordered Label Distribution Control  .................  21
+   2.6.2      Label Retention Mode  ...............................  22
+   2.6.2.1    Conservative Label Retention Mode  ..................  22
+   2.6.2.2    Liberal Label Retention Mode  .......................  22
+   2.6.3      Label Advertisement Mode  ...........................  23
+   2.7        LDP Identifiers and Next Hop Addresses  .............  23
+   2.8        Loop Detection  .....................................  24
+   2.8.1      Label Request Message  ..............................  24
+   2.8.2      Label Mapping Message  ..............................  26
+   2.8.3      Discussion  .........................................  27
+   2.9        Authenticity and Integrity of LDP Messages  .........  28
+   2.9.1      TCP MD5 Signature Option  ...........................  28
+   2.9.2      LDP Use of TCP MD5 Signature Option  ................  30
+   2.10       Label Distribution for Explicitly Routed LSPs  ......  30
+   3          Protocol Specification  .............................  31
+   3.1        LDP PDUs  ...........................................  31
+   3.2        LDP Procedures  .....................................  32
+   3.3        Type-Length-Value Encoding  .........................  32
+
+
+
+Andersson, et al.           Standards Track                     [Page 2]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+   3.4        TLV Encodings for Commonly Used Parameters  .........  34
+   3.4.1      FEC TLV  ............................................  34
+   3.4.1.1    FEC Procedures  .....................................  37
+   3.4.2      Label TLVs  .........................................  37
+   3.4.2.1    Generic Label TLV  ..................................  37
+   3.4.2.2    ATM Label TLV  ......................................  38
+   3.4.2.3    Frame Relay Label TLV  ..............................  38
+   3.4.3      Address List TLV  ...................................  39
+   3.4.4      Hop Count TLV  ......................................  40
+   3.4.4.1    Hop Count Procedures  ...............................  40
+   3.4.5      Path Vector TLV  ....................................  41
+   3.4.5.1    Path Vector Procedures  .............................  42
+   3.4.5.1.1  Label Request Path Vector  ..........................  42
+   3.4.5.1.2  Label Mapping Path Vector  ..........................  43
+   3.4.6      Status TLV  .........................................  43
+   3.5        LDP Messages  .......................................  45
+   3.5.1      Notification Message  ...............................  47
+   3.5.1.1    Notification Message Procedures  ....................  48
+   3.5.1.2    Events Signaled by Notification Messages  ...........  49
+   3.5.1.2.1  Malformed PDU or Message  ...........................  49
+   3.5.1.2.2  Unknown or Malformed TLV  ...........................  50
+   3.5.1.2.3  Session KeepAlive Timer Expiration  .................  50
+   3.5.1.2.4  Unilateral Session Shutdown  ........................  51
+   3.5.1.2.5  Initialization Message Events  ......................  51
+   3.5.1.2.6  Events Resulting From Other Messages  ...............  51
+   3.5.1.2.7  Internal Errors  ....................................  51
+   3.5.1.2.8  Miscellaneous Events  ...............................  51
+   3.5.2      Hello Message  ......................................  51
+   3.5.2.1    Hello Message Procedures  ...........................  54
+   3.5.3      Initialization Message  .............................  55
+   3.5.3.1    Initialization Message Procedures  ..................  63
+   3.5.4      KeepAlive Message  ..................................  63
+   3.5.4.1    KeepAlive Message Procedures  .......................  63
+   3.5.5      Address Message  ....................................  64
+   3.5.5.1    Address Message Procedures  .........................  64
+   3.5.6      Address Withdraw Message  ...........................  65
+   3.5.6.1    Address Withdraw Message Procedures  ................  66
+   3.5.7      Label Mapping Message  ..............................  66
+   3.5.7.1    Label Mapping Message Procedures  ...................  67
+   3.5.7.1.1  Independent Control Mapping  ........................  67
+   3.5.7.1.2  Ordered Control Mapping  ............................  68
+   3.5.7.1.3  Downstream on Demand Label Advertisement  ...........  68
+   3.5.7.1.4  Downstream Unsolicited Label Advertisement  .........  69
+   3.5.8      Label Request Message  ..............................  69
+   3.5.8.1    Label Request Message Procedures  ...................  70
+   3.5.9      Label Abort Request Message  ........................  72
+   3.5.9.1    Label Abort Request Message Procedures  .............  73
+   3.5.10     Label Withdraw Message  .............................  74
+
+
+
+Andersson, et al.           Standards Track                     [Page 3]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+   3.5.10.1   Label Withdraw Message Procedures  ..................  75
+   3.5.11     Label Release Message  ..............................  76
+   3.5.11.1   Label Release Message Procedures  ...................  77
+   3.6        Messages and TLVs for Extensibility  ................  78
+   3.6.1      LDP Vendor-private Extensions  ......................  78
+   3.6.1.1    LDP Vendor-private TLVs  ............................  78
+   3.6.1.2    LDP Vendor-private Messages  ........................  80
+   3.6.2      LDP Experimental Extensions  ........................  81
+   3.7        Message Summary  ....................................  81
+   3.8        TLV Summary  ........................................  82
+   3.9        Status Code Summary  ................................  83
+   3.10       Well-known Numbers  .................................  84
+   3.10.1     UDP and TCP Ports  ..................................  84
+   3.10.2     Implicit NULL Label  ................................  84
+   4          IANA Considerations  ................................  84
+   4.1        Message Type Name Space  ............................  84
+   4.2        TLV Type Name Space  ................................  85
+   4.3        FEC Type Name Space  ................................  85
+   4.4        Status Code Name Space  .............................  86
+   4.5        Experiment ID Name Space  ...........................  86
+   5          Security Considerations  ............................  86
+   5.1        Spoofing  ...........................................  86
+   5.2        Privacy  ............................................  87
+   5.3        Denial of Service  ..................................  87
+   6          Areas for Future Study  .............................  89
+   7          Intellectual Property Considerations  ...............  89
+   8          Acknowledgments  ....................................  89
+   9          References  .........................................  89
+   10         Authors' Addresses  .................................  92
+   Appendix A LDP Label Distribution Procedures  ..................  93
+   A.1        Handling Label Distribution Events  .................  95
+   A.1.1      Receive Label Request  ..............................  96
+   A.1.2      Receive Label Mapping  ..............................  99
+   A.1.3      Receive Label Abort Request  ........................ 105
+   A.1.4      Receive Label Release  .............................. 107
+   A.1.5      Receive Label Withdraw  ............................. 109
+   A.1.6      Recognize New FEC  .................................. 110
+   A.1.7      Detect Change in FEC Next Hop  ...................... 113
+   A.1.8      Receive Notification / Label Request Aborted  ....... 116
+   A.1.9      Receive Notification / No Label Resources  .......... 116
+   A.1.10     Receive Notification / No Route  .................... 117
+   A.1.11     Receive Notification / Loop Detected  ............... 118
+   A.1.12     Receive Notification / Label Resources Available  ... 118
+   A.1.13     Detect local label resources have become available  . 119
+   A.1.14     LSR decides to no longer label switch a FEC  ........ 120
+   A.1.15     Timeout of deferred label request  .................. 121
+   A.2        Common Label Distribution Procedures  ............... 121
+   A.2.1      Send_Label  ......................................... 121
+
+
+
+Andersson, et al.           Standards Track                     [Page 4]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+   A.2.2      Send_Label_Request  ................................. 123
+   A.2.3      Send_Label_Withdraw  ................................ 124
+   A.2.4      Send_Notification  .................................. 125
+   A.2.5      Send_Message  ....................................... 125
+   A.2.6      Check_Received_Attributes  .......................... 126
+   A.2.7      Prepare_Label_Request_Attributes  ................... 127
+   A.2.8      Prepare_Label_Mapping_Attributes  ................... 129
+   Full Copyright Statement  ...................................... 132
+
+1. LDP Overview
+
+   The MPLS architecture [RFC3031] defines a label distribution protocol
+   as a set of procedures by which one Label Switched Router (LSR)
+   informs another of the meaning of labels used to forward traffic
+   between and through them.
+
+   The MPLS architecture does not assume a single label distribution
+   protocol.  In fact, a number of different label distribution
+   protocols are being standardized.  Existing protocols have been
+   extended so that label distribution can be piggybacked on them.  New
+   protocols have also been defined for the explicit purpose of
+   distributing labels.  The MPLS architecture discusses some of the
+   considerations when choosing a label distribution protocol for use in
+   particular MPLS applications such as Traffic Engineering [RFC2702].
+
+   The Label Distribution Protocol (LDP) defined in this document is a
+   new protocol defined for distributing labels.  It is the set of
+   procedures and messages by which Label Switched Routers (LSRs)
+   establish Label Switched Paths (LSPs) through a network by mapping
+   network-layer routing information directly to data-link layer
+   switched paths.  These LSPs may have an endpoint at a directly
+   attached neighbor (comparable to IP hop-by-hop forwarding), or may
+   have an endpoint at a network egress node, enabling switching via all
+   intermediary nodes.
+
+   LDP associates a Forwarding Equivalence Class (FEC) [RFC3031] with
+   each LSP it creates.  The FEC associated with an LSP specifies which
+   packets are "mapped" to that LSP.  LSPs are extended through a
+   network as each LSR "splices" incoming labels for a FEC to the
+   outgoing label assigned to the next hop for the given FEC.
+
+   More information about the applicability of LDP can be found in
+   [RFC3037].
+
+   This document assumes familiarity with the MPLS architecture
+   [RFC3031].  Note that [RFC3031] includes a glossary of MPLS
+   terminology, such as ingress, label switched path, etc.
+
+
+
+
+Andersson, et al.           Standards Track                     [Page 5]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+1.1. LDP Peers
+
+   Two LSRs which use LDP to exchange label/FEC mapping information are
+   known as "LDP Peers" with respect to that information and we speak of
+   there being an "LDP Session" between them.  A single LDP session
+   allows each peer to learn the other's label mappings; i.e., the
+   protocol is bi-directional.
+
+1.2. LDP Message Exchange
+
+   There are four categories of LDP messages:
+
+      1. Discovery messages, used to announce and maintain the presence
+         of an LSR in a network.
+
+      2. Session messages, used to establish, maintain, and terminate
+         sessions between LDP peers.
+
+      3. Advertisement messages, used to create, change, and delete
+         label mappings for FECs.
+
+      4. Notification messages, used to provide advisory information and
+         to signal error information.
+
+   Discovery messages provide a mechanism whereby LSRs indicate their
+   presence in a network by sending a Hello message periodically.  This
+   is transmitted as a UDP packet to the LDP port at the `all routers on
+   this subnet' group multicast address.  When an LSR chooses to
+   establish a session with another LSR learned via the Hello message,
+   it uses the LDP initialization procedure over TCP transport.  Upon
+   successful completion of the initialization procedure, the two LSRs
+   are LDP peers, and may exchange advertisement messages.
+
+   When to request a label or advertise a label mapping to a peer is
+   largely a local decision made by an LSR.  In general, the LSR
+   requests a label mapping from a neighboring LSR when it needs one,
+   and advertises a label mapping to a neighboring LSR when it wishes
+   the neighbor to use a label.
+
+   Correct operation of LDP requires reliable and in order delivery of
+   messages.  To satisfy these requirements LDP uses the TCP transport
+   for session, advertisement and notification messages; i.e., for
+   everything but the UDP-based discovery mechanism.
+
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                     [Page 6]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+1.3. LDP Message Structure
+
+   All LDP messages have a common structure that uses a Type-Length-
+   Value (TLV) encoding scheme; see Section "Type-Length-Value"
+   encoding.  The Value part of a TLV-encoded object, or TLV for short,
+   may itself contain one or more TLVs.
+
+1.4. LDP Error Handling
+
+   LDP errors and other events of interest are signaled to an LDP peer
+   by notification messages.
+
+   There are two kinds of LDP notification messages:
+
+      1. Error notifications, used to signal fatal errors.  If an LSR
+         receives an error notification from a peer for an LDP session,
+         it terminates the LDP session by closing the TCP transport
+         connection for the session and discarding all label mappings
+         learned via the session.
+
+      2. Advisory notifications, used to pass an LSR information about
+         the LDP session or the status of some previous message received
+         from the peer.
+
+1.5. LDP Extensibility and Future Compatibility
+
+   Functionality may be added to LDP in the future.  It is likely that
+   future functionality will utilize new messages and object types
+   (TLVs).  It may be desirable to employ such new messages and TLVs
+   within a network using older implementations that do not recognize
+   them.  While it is not possible to make every future enhancement
+   backwards compatible, some prior planning can ease the introduction
+   of new capabilities.  This specification defines rules for handling
+   unknown message types and unknown TLVs for this purpose.
+
+1.6. Specification Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                     [Page 7]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+2. LDP Operation
+
+2.1. FECs
+
+   It is necessary to precisely specify which packets may be mapped to
+   each LSP.  This is done by providing a FEC specification for each
+   LSP.  The FEC identifies the set of IP packets which may be mapped to
+   that LSP.
+
+   Each FEC is specified as a set of one or more FEC elements.  Each FEC
+   element identifies a set of packets which may be mapped to the
+   corresponding LSP.  When an LSP is shared by multiple FEC elements,
+   that LSP is terminated at (or before) the node where the FEC elements
+   can no longer share the same path.
+
+   Following are the currently defined types of FEC elements.  New
+   element types may be added as needed:
+
+      1. Address Prefix.  This element is an address prefix of any
+         length from 0 to a full address, inclusive.
+
+      2. Host Address.  This element is a full host address.
+
+   (We will see below that an Address Prefix FEC element which is a full
+   address has a different effect than a Host Address FEC element which
+   has the same address.)
+
+   We say that a particular address "matches" a particular address
+   prefix if and only if that address begins with that prefix.  We also
+   say that a particular packet matches a particular LSP if and only if
+   that LSP has an Address Prefix FEC element which matches the packet's
+   destination address.  With respect to a particular packet and a
+   particular LSP, we refer to any Address Prefix FEC element which
+   matches the packet as the "matching prefix".
+
+   The procedure for mapping a particular packet to a particular LSP
+   uses the following rules.  Each rule is applied in turn until the
+   packet can be mapped to an LSP.
+
+      -  If there is exactly one LSP which has a Host Address FEC
+         element that is identical to the packet's destination address,
+         then the packet is mapped to that LSP.
+
+      -  If there are multiple LSPs, each containing a Host Address FEC
+         element that is identical to the packet's destination address,
+         then the packet is mapped to one of those LSPs.  The procedure
+         for selecting one of those LSPs is beyond the scope of this
+         document.
+
+
+
+Andersson, et al.           Standards Track                     [Page 8]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      -  If a packet matches exactly one LSP, the packet is mapped to
+         that LSP.
+
+      -  If a packet matches multiple LSPs, it is mapped to the LSP
+         whose matching prefix is the longest.  If there is no one LSP
+         whose matching prefix is longest, the packet is mapped to one
+         from the set of LSPs whose matching prefix is longer than the
+         others.  The procedure for selecting one of those LSPs is
+         beyond the scope of this document.
+
+      -  If it is known that a packet must traverse a particular egress
+         router, and there is an LSP which has an Address Prefix FEC
+         element which is an address of that router, then the packet is
+         mapped to that LSP.  The procedure for obtaining this knowledge
+         is beyond the scope of this document.
+
+   The procedure for determining that a packet must traverse a
+   particular egress router is beyond the scope of this document.  (As
+   an example, if one is running a link state routing algorithm, it may
+   be possible to obtain this information from the link state data base.
+   As another example, if one is running BGP, it may be possible to
+   obtain this information from the BGP next hop attribute of the
+   packet's route.)
+
+   It is worth pointing out a few consequences of these rules:
+
+      -  A packet may be sent on the LSP whose Address Prefix FEC
+         element is the address of the packet's egress router ONLY if
+         there is no LSP matching the packet's destination address.
+
+      -  A packet may match two LSPs, one with a Host Address FEC
+         element and one with an Address Prefix FEC element.  In this
+         case, the packet is always assigned to the former.
+
+      -  A packet which does not match a particular Host Address FEC
+         element may not be sent on the corresponding LSP, even if the
+         Host Address FEC element identifies the packet's egress router.
+
+2.2. Label Spaces, Identifiers, Sessions and Transport
+
+2.2.1. Label Spaces
+
+   The notion of "label space" is useful for discussing the assignment
+   and distribution of labels.  There are two types of label spaces:
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                     [Page 9]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      -  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 that uses VCIs as labels, or a Frame Relay
+         interface that uses DLCIs as labels.
+
+         Note that the use of a per interface label space only makes
+         sense when the LDP peers are "directly connected" over an
+         interface, and the label is only going to be used for traffic
+         sent over that interface.
+
+      -  Per platform label space.  Platform-wide incoming labels are
+         used for interfaces that can share the same labels.
+
+2.2.2. LDP Identifiers
+
+   An LDP identifier is a six octet quantity used to identify an LSR
+   label space.  The first four octets identify the LSR and must be a
+   globally unique value, such as a 32-bit router Id assigned to the
+   LSR.  The last two octets identify a specific label space within the
+   LSR.  The last two octets of LDP Identifiers for platform-wide label
+   spaces are always both zero.  This document uses the following print
+   representation for LDP Identifiers:
+
+             <LSR Id> : <label space id>
+
+   e.g., lsr171:0, lsr19:2.
+
+   Note that an LSR that manages and advertises multiple label spaces
+   uses a different LDP Identifier for each such label space.
+
+   A situation where an LSR would need to advertise more than one label
+   space to a peer and hence use more than one LDP Identifier occurs
+   when the LSR has two links to the peer and both are ATM (and use per
+   interface labels).  Another situation would be where the LSR had two
+   links to the peer, one of which is ethernet (and uses per platform
+   labels) and the other of which is ATM.
+
+2.2.3. LDP Sessions
+
+   LDP sessions exist between LSRs to support label exchange between
+   them.
+
+      When an LSR uses LDP to advertise more than one label space to
+      another LSR it uses a separate LDP session for each label space.
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 10]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+2.2.4. LDP Transport
+
+   LDP uses TCP as a reliable transport for sessions.
+
+      When multiple LDP sessions are required between two LSRs there is
+      one TCP session for each LDP session.
+
+2.3. LDP Sessions between non-Directly Connected LSRs
+
+   LDP sessions between LSRs that are not directly connected at the link
+   level may be desirable in some situations.
+
+   For example, consider a "traffic engineering" application where LSRa
+   sends traffic matching some criteria via an LSP to non-directly
+   connected LSRb rather than forwarding the traffic along its normally
+   routed path.
+
+   The path between LSRa and LSRb would include one or more intermediate
+   LSRs (LSR1,...LSRn).  An LDP session between LSRa and LSRb would
+   enable LSRb to label switch traffic arriving on the LSP from LSRa by
+   providing LSRb means to advertise labels for this purpose to LSRa.
+
+   In this situation LSRa would apply two labels to traffic it forwards
+   on the LSP to LSRb: a label learned from LSR1 to forward traffic
+   along the LSP path from LSRa to LSRb; and a label learned from LSRb
+   to enable LSRb to label switch traffic arriving on the LSP.
+
+   LSRa first adds the label learned via its LDP session with LSRb to
+   the packet label stack (either by replacing the label on top of the
+   packet label stack with it if the packet arrives labeled or by
+   pushing it if the packet arrives unlabeled).  Next, it pushes the
+   label for the LSP learned from LSR1 onto the label stack.
+
+2.4. LDP Discovery
+
+   LDP discovery is a mechanism that enables an LSR to discover
+   potential LDP peers.  Discovery makes it unnecessary to explicitly
+   configure an LSR's label switching peers.
+
+   There are two variants of the discovery mechanism:
+
+      -  A basic discovery mechanism used to discover LSR neighbors that
+         are directly connected at the link level.
+
+      -  An extended discovery mechanism used to locate LSRs that are
+         not directly connected at the link level.
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 11]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+2.4.1. Basic Discovery Mechanism
+
+   To engage in LDP Basic Discovery on an interface an LSR periodically
+   sends LDP Link Hellos out the interface.  LDP Link Hellos are sent as
+   UDP packets addressed to the well-known LDP discovery port for the
+   "all routers on this subnet" group multicast address.
+
+   An LDP Link Hello sent by an LSR carries the LDP Identifier for the
+   label space the LSR intends to use for the interface and possibly
+   additional information.
+
+   Receipt of an LDP Link Hello on an interface identifies a "Hello
+   adjacency" with a potential LDP peer reachable at the link level on
+   the interface as well as the label space the peer intends to use for
+   the interface.
+
+2.4.2. Extended Discovery Mechanism
+
+   LDP sessions between non-directly connected LSRs are supported by LDP
+   Extended Discovery.
+
+   To engage in LDP Extended Discovery an LSR periodically sends LDP
+   Targeted Hellos to a specific address.  LDP Targeted Hellos are sent
+   as UDP packets addressed to the well-known LDP discovery port at the
+   specific address.
+
+   An LDP Targeted Hello sent by an LSR carries the LDP Identifier for
+   the label space the LSR intends to use and possibly additional
+   optional information.
+
+   Extended Discovery differs from Basic Discovery in the following
+   ways:
+
+      -  A Targeted Hello is sent to a specific address rather than to
+         the "all routers" group multicast address for the outgoing
+         interface.
+
+      -  Unlike Basic Discovery, which is symmetric, Extended Discovery
+         is asymmetric.
+
+         One LSR initiates Extended Discovery with another targeted LSR,
+         and the targeted LSR decides whether to respond to or ignore
+         the Targeted Hello.  A targeted LSR that chooses to respond
+         does so by periodically sending Targeted Hellos to the
+         initiating LSR.
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 12]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+   Receipt of an LDP Targeted Hello identifies a "Hello adjacency" with
+   a potential LDP peer reachable at the network level and the label
+   space the peer intends to use.
+
+2.5. Establishing and Maintaining LDP Sessions
+
+2.5.1. LDP Session Establishment
+
+   The exchange of LDP Discovery Hellos between two LSRs triggers LDP
+   session establishment.  Session establishment is a two step process:
+
+            -  Transport connection establishment.
+            -  Session initialization
+
+   The following describes establishment of an LDP session between LSRs
+   LSR1 and LSR2 from LSR1's point of view.  It assumes the exchange of
+   Hellos specifying label space LSR1:a for LSR1 and label space LSR2:b
+   for LSR2.
+
+2.5.2. Transport Connection Establishment
+
+   The exchange of Hellos results in the creation of a Hello adjacency
+   at LSR1 that serves to bind the link (L) and the label spaces LSR1:a
+   and LSR2:b.
+
+      1. If LSR1 does not already have an LDP session for the exchange
+         of label spaces LSR1:a and LSR2:b it attempts to open a TCP
+         connection for a new LDP session with LSR2.
+
+         LSR1 determines the transport addresses to be used at its end
+         (A1) and LSR2's end (A2) of the LDP TCP connection.  Address A1
+         is determined as follows:
+
+         a. If LSR1 uses the Transport Address optional object (TLV) in
+            Hello's it sends to LSR2 to advertise an address, A1 is the
+            address LSR1 advertises via the optional object;
+
+         b. If LSR1 does not use the Transport Address optional object,
+            A1 is the source address used in Hellos it sends to LSR2.
+
+         Similarly, address A2 is determined as follows:
+
+         a. If LSR2 uses the Transport Address optional object, A2 is
+            the address LSR2 advertises via the optional object;
+
+         b. If LSR2 does not use the Transport Address optional object,
+            A2 is the source address in Hellos received from LSR2.
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 13]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      2. LSR1 determines whether it will play the active or passive role
+         in session establishment by comparing addresses A1 and A2 as
+         unsigned integers.  If A1 > A2, LSR1 plays the active role;
+         otherwise it is passive.
+
+         The procedure for comparing A1 and A2 as unsigned integers is:
+
+         -  If A1 and A2 are not in the same address family, they are
+            incomparable, and no session can be established.
+
+         -  Let U1 be the abstract unsigned integer obtained by treating
+            A1 as a sequence of bytes, where the byte which appears
+            earliest in the message is the most significant byte of the
+            integer and the byte which appears latest in the message is
+            the least significant byte of the integer.
+
+            Let U2 be the abstract unsigned integer obtained from A2 in
+            a similar manner.
+
+         -  Compare U1 with U2.  If U1 > U2, then A1 > A2; if U1 < U2,
+            then A1 < A2.
+
+      3. If LSR1 is active, it attempts to establish the LDP TCP
+         connection by connecting to the well-known LDP port at address
+         A2.  If LSR1 is passive, it waits for LSR2 to establish the LDP
+         TCP connection to its well-known LDP port.
+
+   Note that when an LSR sends a Hello it selects the transport address
+   for its end of the session connection and uses the Hello to advertise
+   the address, either explicitly by including it in an optional
+   Transport Address TLV or implicitly by omitting the TLV and using it
+   as the Hello source address.
+
+   An LSR MUST advertise the same transport address in all Hellos that
+   advertise the same label space.  This requirement ensures that two
+   LSRs linked by multiple Hello adjacencies using the same label spaces
+   play the same connection establishment role for each adjacency.
+
+2.5.3. Session Initialization
+
+   After LSR1 and LSR2 establish a transport connection they negotiate
+   session parameters by exchanging LDP Initialization messages.  The
+   parameters negotiated include LDP protocol version, label
+   distribution method, timer values, VPI/VCI ranges for label
+   controlled ATM, DLCI ranges for label controlled Frame Relay, etc.
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 14]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+   Successful negotiation completes establishment of an LDP session
+   between LSR1 and LSR2 for the advertisement of label spaces LSR1:a
+   and LSR2:b.
+
+   The following describes the session initialization from LSR1's point
+   of view.
+
+   After the connection is established, if LSR1 is playing the active
+   role, it initiates negotiation of session parameters by sending an
+   Initialization message to LSR2.  If LSR1 is passive, it waits for
+   LSR2 to initiate the parameter negotiation.
+
+   In general when there are multiple links between LSR1 and LSR2 and
+   multiple label spaces to be advertised by each, the passive LSR
+   cannot know which label space to advertise over a newly established
+   TCP connection until it receives the LDP Initialization message on
+   the connection.  The Initialization message carries both the LDP
+   Identifier for the sender's (active LSR's) label space and the LDP
+   Identifier for the receiver's (passive LSR's) label space.
+
+   By waiting for the Initialization message from its peer the passive
+   LSR can match the label space to be advertised by the peer (as
+   determined from the LDP Identifier in the PDU header for the
+   Initialization message) with a Hello adjacency previously created
+   when Hellos were exchanged.
+
+      1. When LSR1 plays the passive role:
+
+         a. If LSR1 receives an Initialization message it attempts to
+            match the LDP Identifier carried by the message PDU with a
+            Hello adjacency.
+
+         b. If there is a matching Hello adjacency, the adjacency
+            specifies the local label space for the session.
+
+            Next LSR1 checks whether the session parameters proposed in
+            the message are acceptable.  If they are, LSR1 replies with
+            an Initialization message of its own to propose the
+            parameters it wishes to use and a KeepAlive message to
+            signal acceptance of LSR2's parameters.  If the parameters
+            are not acceptable, LSR1 responds by sending a Session
+            Rejected/Parameters Error Notification message and closing
+            the TCP connection.
+
+         c. If LSR1 cannot find a matching Hello adjacency it sends a
+            Session Rejected/No Hello Error Notification message and
+            closes the TCP connection.
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 15]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+         d. If LSR1 receives a KeepAlive in response to its
+            Initialization message, the session is operational from
+            LSR1's point of view.
+
+         e. If LSR1 receives an Error Notification message, LSR2 has
+            rejected its proposed session and LSR1 closes the TCP
+            connection.
+
+      2. When LSR1 plays the active role:
+
+         a. If LSR1 receives an Error Notification message, LSR2 has
+            rejected its proposed session and LSR1 closes the TCP
+            connection.
+
+         b. If LSR1 receives an Initialization message, it checks
+            whether the session parameters are acceptable.  If so, it
+            replies with a KeepAlive message.  If the session parameters
+            are unacceptable, LSR1 sends a Session Rejected/Parameters
+            Error Notification message and closes the connection.
+
+         c. If LSR1 receives a KeepAlive message, LSR2 has accepted its
+            proposed session parameters.
+
+         d. When LSR1 has received both an acceptable Initialization
+            message and a KeepAlive message the session is operational
+            from LSR1's point of view.
+
+      It is possible for a pair of incompatibly configured LSRs that
+      disagree on session parameters to engage in an endless sequence of
+      messages as each NAKs the other's Initialization messages with
+      Error Notification messages.
+
+      An LSR must throttle its session setup retry attempts with an
+      exponential backoff in situations where Initialization messages
+      are being NAK'd.  It is also recommended that an LSR detecting
+      such a situation take action to notify an operator.
+
+      The session establishment setup attempt following a NAK'd
+      Initialization message must be delayed no less than 15 seconds,
+      and subsequent delays must grow to a maximum delay of no less than
+      2 minutes.  The specific session establishment action that must be
+      delayed is the attempt to open the session transport connection by
+      the LSR playing the active role.
+
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 16]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      The throttled sequence of Initialization NAKs is unlikely to cease
+      until operator intervention reconfigures one of the LSRs.  After
+      such a configuration action there is no further need to throttle
+      subsequent session establishment attempts (until their
+      initialization messages are NAK'd).
+
+      Due to the asymmetric nature of session establishment,
+      reconfiguration of the passive LSR will go unnoticed by the active
+      LSR without some further action.  Section "Hello Message"
+      describes an optional mechanism an LSR can use to signal potential
+      LDP peers that it has been reconfigured.
+
+2.5.4. Initialization State Machine
+
+   It is convenient to describe LDP session negotiation behavior in
+   terms of a state machine.  We define the LDP state machine to have
+   five possible states and present the behavior as a state transition
+   table and as a state transition diagram.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 17]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+               Session Initialization State Transition Table
+
+      STATE         EVENT                               NEW STATE
+
+      NON EXISTENT  Session TCP connection established  INITIALIZED
+                    established
+
+      INITIALIZED   Transmit Initialization msg         OPENSENT
+                          (Active Role)
+
+                    Receive acceptable                  OPENREC
+                          Initialization msg
+                          (Passive Role )
+                      Action: Transmit Initialization
+                              msg and KeepAlive msg
+
+                    Receive Any other LDP msg           NON EXISTENT
+                      Action: Transmit Error Notification msg
+                              (NAK) and close transport connection
+
+      OPENREC       Receive KeepAlive msg               OPERATIONAL
+
+                    Receive Any other LDP msg           NON EXISTENT
+                      Action: Transmit Error Notification msg
+                              (NAK) and close transport connection
+
+      OPENSENT      Receive acceptable                  OPENREC
+                          Initialization msg
+                      Action: Transmit KeepAlive msg
+
+                    Receive Any other LDP msg           NON EXISTENT
+                      Action: Transmit Error Notification msg
+                              (NAK) and close transport connection
+
+      OPERATIONAL   Receive Shutdown msg                NON EXISTENT
+                      Action: Transmit Shutdown msg and
+                              close transport connection
+
+                    Receive other LDP msgs              OPERATIONAL
+
+                    Timeout                             NON EXISTENT
+                      Action: Transmit Shutdown msg and
+                              close transport connection
+
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 18]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+               Session Initialization State Transition Diagram
+
+                                 +------------+
+                                 |            |
+                   +------------>|NON EXISTENT|<--------------------+
+                   |             |            |                     |
+                   |             +------------+                     |
+                   | Session        |    ^                          |
+                   |   connection   |    |                          |
+                   |   established  |    | Rx any LDP msg except    |
+                   |                V    |   Init msg or Timeout    |
+                   |            +-----------+                       |
+      Rx Any other |            |           |                       |
+         msg or    |            |INITIALIZED|                       |
+         Timeout / |        +---|           |-+                     |
+      Tx NAK msg   |        |   +-----------+ |                     |
+                   |        | (Passive Role)  | (Active Role)       |
+                   |        | Rx Acceptable   | Tx Init msg         |
+                   |        |    Init msg /   |                     |
+                   |        | Tx Init msg     |                     |
+                   |        |    Tx KeepAlive |                     |
+                   |        V    msg          V                     |
+                   |   +-------+        +--------+                  |
+                   |   |       |        |        |                  |
+                   +---|OPENREC|        |OPENSENT|----------------->|
+                   +---|       |        |        | Rx Any other msg |
+                   |   +-------+        +--------+    or Timeout    |
+      Rx KeepAlive |        ^                |     Tx NAK msg       |
+         msg       |        |                |                      |
+                   |        |                | Rx Acceptable        |
+                   |        |                |    Init msg /        |
+                   |        +----------------+ Tx KeepAlive msg     |
+                   |                                                |
+                   |      +-----------+                             |
+                   +----->|           |                             |
+                          |OPERATIONAL|                             |
+                          |           |---------------------------->+
+                          +-----------+     Rx Shutdown msg
+                   All other  |   ^            or Timeout /
+                     LDP msgs |   |         Tx Shutdown msg
+                              |   |
+                              +---+
+
+
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 19]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+2.5.5. Maintaining Hello Adjacencies
+
+   An LDP session with a peer has one or more Hello adjacencies.
+
+   An LDP session has multiple Hello adjacencies when a pair of LSRs is
+   connected by multiple links that share the same label space; for
+   example, multiple PPP links between a pair of routers.  In this
+   situation the Hellos an LSR sends on each such link carry the same
+   LDP Identifier.
+
+   LDP includes mechanisms to monitor the necessity of an LDP session
+   and its Hello adjacencies.
+
+   LDP uses the regular receipt of LDP Discovery Hellos to indicate a
+   peer's intent to use the label space identified by the Hello.  An LSR
+   maintains a hold timer with each Hello adjacency which it restarts
+   when it receives a Hello that matches the adjacency.  If the timer
+   expires without receipt of a matching Hello from the peer, LDP
+   concludes that the peer no longer wishes to label switch using that
+   label space for that link (or target, in the case of Targeted Hellos)
+   or that the peer has failed.  The LSR then deletes the Hello
+   adjacency.  When the last Hello adjacency for a LDP session is
+   deleted, the LSR terminates the LDP session by sending a Notification
+   message and closing the transport connection.
+
+2.5.6. Maintaining LDP Sessions
+
+   LDP includes mechanisms to monitor the integrity of the LDP session.
+
+   LDP uses the regular receipt of LDP PDUs on the session transport
+   connection to monitor the integrity of the session.  An LSR maintains
+   a KeepAlive timer for each peer session which it resets whenever it
+   receives an LDP PDU from the session peer.  If the KeepAlive timer
+   expires without receipt of an LDP PDU from the peer the LSR concludes
+   that the transport connection is bad or that the peer has failed, and
+   it terminates the LDP session by closing the transport connection.
+
+   After an LDP session has been established, an LSR must arrange that
+   its peer receive an LDP PDU from it at least every KeepAlive time
+   period to ensure the peer restarts the session KeepAlive timer.  The
+   LSR may send any protocol message to meet this requirement.  In
+   circumstances where an LSR has no other information to communicate to
+   its peer, it sends a KeepAlive message.
+
+   An LSR may choose to terminate an LDP session with a peer at any
+   time.  Should it choose to do so, it informs the peer with a Shutdown
+   message.
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 20]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+2.6. Label Distribution and Management
+
+   The MPLS architecture [RF3031] allows an LSR to distribute a FEC
+   label binding in response to an explicit request from another LSR.
+   This is known as Downstream On Demand label distribution.  It also
+   allows an LSR to distribute label bindings to LSRs that have not
+   explicitly requested them.  [RFC3031] calls this method of label
+   distribution Unsolicited Downstream; this document uses the term
+   Downstream Unsolicited.
+
+   Both of these label distribution techniques may be used in the same
+   network at the same time.  However, for any given LDP session, each
+   LSR must be aware of the label distribution method used by its peer
+   in order to avoid situations where one peer using Downstream
+   Unsolicited label distribution assumes its peer is also.  See Section
+   "Downstream on Demand label Advertisement".
+
+2.6.1. Label Distribution Control Mode
+
+   The behavior of the initial setup of LSPs is determined by whether
+   the LSR is operating with independent or ordered LSP control.  An LSR
+   may support both types of control as a configurable option.
+
+2.6.1.1. Independent Label Distribution Control
+
+   When using independent LSP control, each LSR may advertise label
+   mappings to its neighbors at any time it desires.  For example, when
+   operating in independent Downstream on Demand mode, an LSR may answer
+   requests for label mappings immediately, without waiting for a label
+   mapping from the next hop.  When operating in independent Downstream
+   Unsolicited mode, an LSR may advertise a label mapping for a FEC to
+   its neighbors whenever it is prepared to label-switch that FEC.
+
+   A consequence of using independent mode is that an upstream label can
+   be advertised before a downstream label is received.
+
+2.6.1.2. Ordered Label Distribution Control
+
+   When using LSP ordered control, an LSR may initiate the transmission
+   of a label mapping only for a FEC for which it has a label mapping
+   for the FEC next hop, or for which the LSR is the egress.  For each
+   FEC for which the LSR is not the egress and no mapping exists, the
+   LSR MUST wait until a label from a downstream LSR is received before
+   mapping the FEC and passing corresponding labels to upstream LSRs.
+   An LSR may be an egress for some FECs and a non-egress for others.
+   An LSR may act as an egress LSR, with respect to a particular FEC,
+   under any of the following conditions:
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 21]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      1. The FEC refers to the LSR itself (including one of its directly
+         attached interfaces).
+
+      2. The next hop router for the FEC is outside of the Label
+         Switching Network.
+
+      3. FEC elements are reachable by crossing a routing domain
+         boundary, such as another area for OSPF summary networks, or
+         another autonomous system for OSPF AS externals and BGP routes
+         [RFC2328] [RFC1771].
+
+   Note that whether an LSR is an egress for a given FEC may change over
+   time, depending on the state of the network and LSR configuration
+   settings.
+
+2.6.2. Label Retention Mode
+
+   The MPLS architecture [RFC3031] introduces the notion of label
+   retention mode which specifies whether an LSR maintains a label
+   binding for a FEC learned from a neighbor that is not its next hop
+   for the FEC.
+
+2.6.2.1. Conservative Label Retention Mode
+
+   In Downstream Unsolicited advertisement mode, label mapping
+   advertisements for all routes may be received from all peer LSRs.
+   When using conservative label retention, advertised label mappings
+   are retained only if they will be used to forward packets (i.e., if
+   they are received from a valid next hop according to routing).  If
+   operating in Downstream on Demand mode, an LSR will request label
+   mappings only from the next hop LSR according to routing.  Since
+   Downstream on Demand mode is primarily used when label conservation
+   is desired (e.g., an ATM switch with limited cross connect space), it
+   is typically used with the conservative label retention mode.
+
+   The main advantage of the conservative mode is that only the labels
+   that are required for the forwarding of data are allocated and
+   maintained.  This is particularly important in LSRs where the label
+   space is inherently limited, such as in an ATM switch.  A
+   disadvantage of the conservative mode is that if routing changes the
+   next hop for a given destination, a new label must be obtained from
+   the new next hop before labeled packets can be forwarded.
+
+2.6.2.2. Liberal Label Retention Mode
+
+   In Downstream Unsolicited advertisement mode, label mapping
+   advertisements for all routes may be received from all LDP peers.
+   When using liberal label retention, every label mappings received
+
+
+
+Andersson, et al.           Standards Track                    [Page 22]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+   from a peer LSR is retained regardless of whether the LSR is the next
+   hop for the advertised mapping.  When operating in Downstream on
+   Demand mode with liberal label retention, an LSR might choose to
+   request label mappings for all known prefixes from all peer LSRs.
+   Note, however, that Downstream on Demand mode is typically used by
+   devices such as ATM switch-based LSRs for which the conservative
+   approach is recommended.
+
+   The main advantage of the liberal label retention mode is that
+   reaction to routing changes can be quick because labels already
+   exist.  The main disadvantage of the liberal mode is that unneeded
+   label mappings are distributed and maintained.
+
+2.6.3. Label Advertisement Mode
+
+   Each interface on an LSR is configured to operate in either
+   Downstream Unsolicited or Downstream on Demand advertisement mode.
+   LSRs exchange advertisement modes during initialization.  The major
+   difference between Downstream Unsolicited and Downstream on Demand
+   modes is in which LSR takes responsibility for initiating mapping
+   requests and mapping advertisements.
+
+2.7. LDP Identifiers and Next Hop Addresses
+
+   An LSR maintains learned labels in a Label Information Base (LIB).
+   When operating in Downstream Unsolicited mode, the LIB entry for an
+   address prefix associates a collection of (LDP Identifier, label)
+   pairs with the prefix, one such pair for each peer advertising a
+   label for the prefix.
+
+   When the next hop for a prefix changes the LSR must retrieve the
+   label advertised by the new next hop from the LIB for use in
+   forwarding.  To retrieve the label the LSR must be able to map the
+   next hop address for the prefix to an LDP Identifier.
+
+   Similarly, when the LSR learns a label for a prefix from an LDP peer,
+   it must be able to determine whether that peer is currently a next
+   hop for the prefix to determine whether it needs to start using the
+   newly learned label when forwarding packets that match the prefix.
+   To make that decision the LSR must be able to map an LDP Identifier
+   to the peer's addresses to check whether any are a next hop for the
+   prefix.
+
+   To enable LSRs to map between a peer LDP identifier and the peer's
+   addresses, LSRs advertise their addresses using LDP Address and
+   Withdraw Address messages.
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 23]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+   An LSR sends an Address message to advertise its addresses to a peer.
+   An LSR sends a Withdraw Address message to withdraw previously
+   advertised addresses from a peer
+
+2.8. Loop Detection
+
+   Loop detection is a configurable option which provides a mechanism
+   for finding looping LSPs and for preventing Label Request messages
+   from looping in the presence of non-merge capable LSRs.
+
+   The mechanism makes use of Path Vector and Hop Count TLVs carried by
+   Label Request and Label Mapping messages.  It builds on the following
+   basic properties of these TLVs:
+
+      -  A Path Vector TLV contains a list of the LSRs that its
+         containing message has traversed.  An LSR is identified in a
+         Path Vector list by its unique LSR Identifier (Id), which is
+         the first four octets of its LDP Identifier.  When an LSR
+         propagates a message containing a Path Vector TLV it adds its
+         LSR Id to the Path Vector list.  An LSR that receives a message
+         with a Path Vector that contains its LSR Id detects that the
+         message has traversed a loop.  LDP supports the notion of a
+         maximum allowable Path Vector length; an LSR that detects a
+         Path Vector has reached the maximum length behaves as if the
+         containing message has traversed a loop.
+
+      -  A Hop Count TLV contains a count of the LSRS that the
+         containing message has traversed.  When an LSR propagates a
+         message containing a Hop Count TLV it increments the count.  An
+         LSR that detects a Hop Count has reached a configured maximum
+         value behaves as if the containing message has traversed a
+         loop.  By convention a count of 0 is interpreted to mean the
+         hop count is unknown.  Incrementing an unknown hop count value
+         results in an unknown hop count value (0).
+
+   The following paragraphs describes LDP loop detection procedures.
+   For these paragraphs, and only these paragraphs, "MUST" is redefined
+   to mean "MUST if configured for loop detection".  The paragraphs
+   specify messages that must carry Path Vector and Hop Count TLVs.
+   Note that the Hop Count TLV and its procedures are used without the
+   Path Vector TLV in situations when loop detection is not configured
+   (see [RFC3035] and [RFC3034]).
+
+2.8.1. Label Request Message
+
+   The use of the Path Vector TLV and Hop Count TLV prevent Label
+   Request messages from looping in environments that include non-merge
+   capable LSRs.
+
+
+
+Andersson, et al.           Standards Track                    [Page 24]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+   The rules that govern use of the Hop Count TLV in Label Request
+   messages by LSR R when Loop Detection is enabled are the following:
+
+   -  The Label Request message MUST include a Hop Count TLV.
+
+   -  If R is sending the Label Request because it is a FEC ingress, it
+      MUST include a Hop Count TLV with hop count value 1.
+
+   -  If R is sending the Label Request as a result of having received a
+      Label Request from an upstream LSR, and if the received Label
+      Request contains a Hop Count TLV, R MUST increment the received
+      hop count value by 1 and MUST pass the resulting value in a Hop
+      Count TLV to its next hop along with the Label Request message;
+
+   The rules that govern use of the Path Vector TLV in Label Request
+   messages by LSR R when Loop Detection is enabled are the following:
+
+   -  If R is sending the Label Request because it is a FEC ingress,
+      then if R is non-merge capable, it MUST include a Path Vector TLV
+      of length 1 containing its own LSR Id.
+
+   -  If R is sending the Label Request as a result of having received a
+      Label Request from an upstream LSR, then if the received Label
+      Request contains a Path Vector TLV or if R is non-merge capable:
+
+         R MUST add its own LSR Id to the Path Vector, and MUST pass the
+         resulting Path Vector to its next hop along with the Label
+         Request message.  If the Label Request contains no Path Vector
+         TLV, R MUST include a Path Vector TLV of length 1 containing
+         its own LSR Id.
+
+   Note that if R receives a Label Request message for a particular FEC,
+   and R has previously sent a Label Request message for that FEC to its
+   next hop and has not yet received a reply, and if R intends to merge
+   the newly received Label Request with the existing outstanding Label
+   Request, then R does not propagate the Label Request to the next hop.
+
+   If R receives a Label Request message from its next hop with a Hop
+   Count TLV which exceeds the configured maximum value, or with a Path
+   Vector TLV containing its own LSR Id or which exceeds the maximum
+   allowable length, then R detects that the Label Request message has
+   traveled in a loop.
+
+   When R detects a loop, it MUST send a Loop Detected Notification
+   message to the source of the Label Request message and drop the Label
+   Request message.
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 25]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+2.8.2. Label Mapping Message
+
+   The use of the Path Vector TLV and Hop Count TLV in the Label Mapping
+   message provide a mechanism to find and terminate looping LSPs.  When
+   an LSR receives a Label Mapping message from a next hop, the message
+   is propagated upstream as specified below until an ingress LSR is
+   reached or a loop is found.
+
+   The rules that govern the use of the Hop Count TLV in Label Mapping
+   messages sent by an LSR R when Loop Detection is enabled are the
+   following:
+
+   -  R MUST include a Hop Count TLV.
+
+   -  If R is the egress, the hop count value MUST be 1.
+
+   -  If the Label Mapping message is being sent to propagate a Label
+      Mapping message received from the next hop to an upstream peer,
+      the hop count value MUST be determined as follows:
+
+      o  If R is a member of the edge set of an LSR domain whose LSRs do
+         not perform 'TTL-decrement' (e.g., an ATM LSR domain or a Frame
+         Relay LSR domain) and the upstream peer is within that domain,
+         R MUST reset the hop count to 1 before propagating the message.
+
+      o  Otherwise, R MUST increment the hop count received from the
+         next hop before propagating the message.
+
+   -  If the Label Mapping message is not being sent to propagate a
+      Label Mapping message, the hop count value MUST be the result of
+      incrementing R's current knowledge of the hop count learned from
+      previous Label Mapping messages.  Note that this hop count value
+      will be unknown if R has not received a Label Mapping message from
+      the next hop.
+
+   Any Label Mapping message MAY contain a Path Vector TLV.  The rules
+   that govern the mandatory use of the Path Vector TLV in Label Mapping
+   messages sent by LSR R when Loop Detection is enabled are the
+   following:
+
+   -  If R is the egress, the Label Mapping message need not include a
+      Path Vector TLV.
+
+   -  If R is sending the Label Mapping message to propagate a Label
+      Mapping message received from the next hop to an upstream peer,
+      then:
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 26]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      o  If R is merge capable and if R has not previously sent a Label
+         Mapping message to the upstream peer, then it MUST include a
+         Path Vector TLV.
+
+      o  If the received message contains an unknown hop count, then R
+         MUST include a Path Vector TLV.
+
+      o  If R has previously sent a Label Mapping message to the
+         upstream peer, then it MUST include a Path Vector TLV if the
+         received message reports an LSP hop count increase, a change in
+         hop count from unknown to known, or a change from known to
+         unknown.
+
+      If the above rules require R include a Path Vector TLV in the
+      Label Mapping message, R computes it as follows:
+
+      o  If the received Label Mapping message included a Path Vector,
+         the Path Vector sent upstream MUST be the result of adding R's
+         LSR Id to the received Path Vector.
+
+      o  If the received message had no Path Vector, the Path Vector
+         sent upstream MUST be a path vector of length 1 containing R's
+         LSR Id.
+
+   -  If the Label Mapping message is not being sent to propagate a
+      received message upstream, the Label Mapping message MUST include
+      a Path Vector of length 1 containing R's LSR Id.
+
+   If R receives a Label Mapping message from its next hop with a Hop
+   Count TLV which exceeds the configured maximum value, or with a Path
+   Vector TLV containing its own LSR Id or which exceeds the maximum
+   allowable length, then R detects that the corresponding LSP contains
+   a loop.
+
+   When R detects a loop, it MUST stop using the label for forwarding,
+   drop the Label Mapping message, and signal Loop Detected status to
+   the source of the Label Mapping message.
+
+2.8.3. Discussion
+
+   If loop detection is desired in an MPLS domain, then it should be
+   turned on in ALL LSRs within that MPLS domain, else loop detection
+   will not operate properly and may result in undetected loops or in
+   falsely detected loops.
+
+   LSRs which are configured for loop detection are NOT expected to
+   store the path vectors as part of the LSP state.
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 27]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+   Note that in a network where only non-merge capable LSRs are present,
+   Path Vectors are passed downstream from ingress to egress, and are
+   not passed upstream.  Even when merge is supported, Path Vectors need
+   not be passed upstream along an LSP which is known to reach the
+   egress.  When an LSR experiences a change of next hop, it need pass
+   Path Vectors upstream only when it cannot tell from the hop count
+   that the change of next hop does not result in a loop.
+
+   In the case of ordered label distribution, Label Mapping messages are
+   propagated from egress toward ingress, naturally creating the Path
+   Vector along the way.  In the case of independent label distribution,
+   an LSR may originate a Label Mapping message for an FEC before
+   receiving a Label Mapping message from its downstream peer for that
+   FEC.  In this case, the subsequent Label Mapping message for the FEC
+   received from the downstream peer is treated as an update to LSP
+   attributes, and the Label Mapping message must be propagated
+   upstream.  Thus, it is recommended that loop detection be configured
+   in conjunction with ordered label distribution, to minimize the
+   number of Label Mapping update messages.
+
+2.9. Authenticity and Integrity of LDP Messages
+
+   This section specifies a mechanism to protect against the
+   introduction of spoofed TCP segments into LDP session connection
+   streams.  The use of this mechanism MUST be supported as a
+   configurable option.
+
+   The mechanism is based on use of the TCP MD5 Signature Option
+   specified in [RFC2385] for use by BGP.  See [RFC1321] for a
+   specification of the MD5 hash function.
+
+2.9.1. TCP MD5 Signature Option
+
+   The following quotes from [RFC2385] outline the security properties
+   achieved by using the TCP MD5 Signature Option and summarizes its
+   operation:
+
+      "IESG Note
+
+         This document describes current existing practice for securing
+         BGP against certain simple attacks.  It is understood to have
+         security weaknesses against concerted attacks."
+
+
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 28]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      "Abstract
+
+         This memo describes a TCP extension to enhance security for
+         BGP.  It defines a new TCP option for carrying an MD5 [RFC1321]
+         digest in a TCP segment.  This digest acts like a signature for
+         that segment, incorporating information known only to the
+         connection end points.  Since BGP uses TCP as its transport,
+         using this option in the way described in this paper
+         significantly reduces the danger from certain security attacks
+         on BGP."
+
+      "Introduction
+
+         The primary motivation for this option is to allow BGP to
+         protect itself against the introduction of spoofed TCP segments
+         into the connection stream.  Of particular concern are TCP
+         resets.
+
+         To spoof a connection using the scheme described in this paper,
+         an attacker would not only have to guess TCP sequence numbers,
+         but would also have had to obtain the password included in the
+         MD5 digest.  This password never appears in the connection
+         stream, and the actual form of the password is up to the
+         application.  It could even change during the lifetime of a
+         particular connection so long as this change was synchronized
+         on both ends (although retransmission can become problematical
+         in some TCP implementations with changing passwords).
+
+         Finally, there is no negotiation for the use of this option in
+         a connection, rather it is purely a matter of site policy
+         whether or not its connections use the option."
+
+      "MD5 as a Hashing Algorithm
+
+         Since this memo was first issued (under a different title), the
+         MD5 algorithm has been found to be vulnerable to collision
+         search attacks [Dobb], and is considered by some to be
+         insufficiently strong for this type of application.
+
+         This memo still specifies the MD5 algorithm, however, since the
+         option has already been deployed operationally, and there was
+         no "algorithm type" field defined to allow an upgrade using the
+         same option number.  The original document did not specify a
+         type field since this would require at least one more byte, and
+         it was felt at the time that taking 19 bytes for the complete
+         option (which would probably be padded to 20 bytes in TCP
+         implementations) would be too much of a waste of the already
+         limited option space.
+
+
+
+Andersson, et al.           Standards Track                    [Page 29]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+         This does not prevent the deployment of another similar option
+         which uses another hashing algorithm (like SHA-1).  Also, if
+         most implementations pad the 18 byte option as defined to 20
+         bytes anyway, it would be just as well to define a new option
+         which contains an algorithm type field.
+
+         This would need to be addressed in another document, however."
+
+   End of quotes from [RFC2385].
+
+2.9.2. LDP Use of TCP MD5 Signature Option
+
+   LDP uses the TCP MD5 Signature Option as follows:
+
+      -  Use of the MD5 Signature Option for LDP TCP connections is a
+         configurable LSR option.
+
+      -  An LSR that uses the MD5 Signature Option is configured with a
+         password (shared secret) for each potential LDP peer.
+
+      -  The LSR applies the MD5 algorithm as specified in [RFC2385] to
+         compute the MD5 digest for a TCP segment to be sent to a peer.
+         This computation makes use of the peer password as well as the
+         TCP segment.
+
+      -  When the LSR receives a TCP segment with an MD5 digest, it
+         validates the segment by calculating the MD5 digest (using its
+         own record of the password) and compares the computed digest
+         with the received digest.  If the comparison fails, the segment
+         is dropped without any response to the sender.
+
+      -  The LSR ignores LDP Hellos from any LSR for which a password
+         has not been configured.  This ensures that the LSR establishes
+         LDP TCP connections only with LSRs for which a password has
+         been configured.
+
+2.10. Label Distribution for Explicitly Routed LSPs
+
+   Traffic Engineering [RFC2702] is expected to be an important MPLS
+   application.  MPLS support for Traffic Engineering uses explicitly
+   routed LSPs, which need not follow normally-routed (hop-by-hop) paths
+   as determined by destination-based routing protocols.  CR-LDP [CRLDP]
+   defines extensions to LDP to use LDP to set up explicitly routed
+   LSPs.
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 30]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+3. Protocol Specification
+
+   Previous sections that describe LDP operation have discussed
+   scenarios that involve the exchange of messages among LDP peers.
+   This section specifies the message encodings and procedures for
+   processing the messages.
+
+   LDP message exchanges are accomplished by sending LDP protocol data
+   units (PDUs) over LDP session TCP connections.
+
+   Each LDP PDU can carry one or more LDP messages.  Note that the
+   messages in an LDP PDU need not be related to one another.  For
+   example, a single PDU could carry a message advertising FEC-label
+   bindings for several FECs, another message requesting label bindings
+   for several other FECs, and a third notification message signaling
+   some event.
+
+3.1. LDP PDUs
+
+   Each LDP PDU is an LDP header followed by one or more LDP messages.
+   The LDP header is:
+
+    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                      |         PDU Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         LDP Identifier                        |
+   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Version
+      Two octet unsigned integer containing the version number of the
+      protocol.  This version of the specification specifies LDP protocol
+      version 1.
+
+   PDU Length
+      Two octet integer specifying the total length of this PDU in
+      octets, excluding the Version and PDU Length fields.
+
+      The maximum allowable PDU Length is negotiable when an LDP session
+      is initialized.  Prior to completion of the negotiation the maximum
+      allowable length is 4096 bytes.
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 31]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+   LDP Identifier
+      Six octet field that uniquely identifies the label space of the
+      sending LSR for which this PDU applies.  The first four octets
+      identify the LSR and must be a globally unique value.  It should be
+      a 32-bit router Id assigned to the LSR and also used to identify it
+      in loop detection Path Vectors.  The last two octets identify a
+      label space within the LSR.  For a platform-wide label space, these
+      should both be zero.
+
+   Note that there is no alignment requirement for the first octet of an
+   LDP PDU.
+
+3.2. LDP Procedures
+
+   LDP defines messages, TLVs and procedures in the following areas:
+
+      -  Peer discovery;
+      -  Session management;
+      -  Label distribution;
+      -  Notification of errors and advisory information.
+
+   The sections that follow describe the message and TLV encodings for
+   these areas and the procedures that apply to them.
+
+   The label distribution procedures are complex and are difficult to
+   describe fully, coherently and unambiguously as a collection of
+   separate message and TLV specifications.
+
+   Appendix A, "LDP Label Distribution Procedures", describes the label
+   distribution procedures in terms of label distribution events that
+   may occur at an LSR and how the LSR must respond.  Appendix A is the
+   specification of LDP label distribution procedures.  If a procedure
+   described elsewhere in this document conflicts with Appendix A,
+   Appendix A specifies LDP behavior.
+
+3.3. Type-Length-Value Encoding
+
+   LDP uses a Type-Length-Value (TLV) encoding scheme to encode much of
+   the information carried in LDP messages.
+
+   An LDP TLV is encoded as a 2 octet field that uses 14 bits to specify
+   a Type and 2 bits to specify behavior when an LSR doesn't recognize
+   the Type, followed by a 2 octet Length Field, followed by a variable
+   length Value field.
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 32]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |U|F|        Type               |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   |                             Value                             |
+   ~                                                               ~
+   |                                                               |
+   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   U bit
+      Unknown TLV bit.  Upon receipt of an unknown TLV, if U is clear
+      (=0), a notification must be returned to the message originator
+      and the entire message must be ignored; if U is set (=1), the
+      unknown TLV is silently ignored and the rest of the message is
+      processed as if the unknown TLV did not exist.  The sections
+      following that define TLVs specify a value for the U-bit.
+
+   F bit
+      Forward unknown TLV bit.  This bit applies only when the U bit is
+      set and the LDP message containing the unknown TLV is to be
+      forwarded.  If F is clear (=0), the unknown TLV is not forwarded
+      with the containing message; if F is set (=1), the unknown TLV is
+      forwarded with the containing message.  The sections following
+      that define TLVs specify a value for the F-bit.
+
+   Type
+      Encodes how the Value field is to be interpreted.
+
+   Length
+      Specifies the length of the Value field in octets.
+
+   Value
+      Octet string of Length octets that encodes information to be
+      interpreted as specified by the Type field.
+
+   Note that there is no alignment requirement for the first octet of a
+   TLV.
+
+   Note that the Value field itself may contain TLV encodings.  That is,
+   TLVs may be nested.
+
+   The TLV encoding scheme is very general.  In principle, everything
+   appearing in an LDP PDU could be encoded as a TLV.  This
+   specification does not use the TLV scheme to its full generality.  It
+
+
+
+Andersson, et al.           Standards Track                    [Page 33]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+   is not used where its generality is unnecessary and its use would
+   waste space unnecessarily.  These are usually places where the type
+   of a value to be encoded is known, for example by its position in a
+   message or an enclosing TLV, and the length of the value is fixed or
+   readily derivable from the value encoding itself.
+
+   Some of the TLVs defined for LDP are similar to one another.  For
+   example, there is a Generic Label TLV, an ATM Label TLV, and a Frame
+   Relay TLV; see Sections "Generic Label TLV", "ATM Label TLV", and
+   "Frame Relay TLV".
+
+   While it is possible to think about TLVs related in this way in terms
+   of a TLV type that specifies a TLV class and a TLV subtype that
+   specifies a particular kind of TLV within that class, this
+   specification does not formalize the notion of a TLV subtype.
+
+   The specification assigns type values for related TLVs, such as the
+   label TLVs, from a contiguous block in the 16-bit TLV type number
+   space.
+
+   Section "TLV Summary" lists the TLVs defined in this version of the
+   protocol and the section in this document that describes each.
+
+3.4. TLV Encodings for Commonly Used Parameters
+
+   There are several parameters used by more than one LDP message.  The
+   TLV encodings for these commonly used parameters are specified in
+   this section.
+
+3.4.1. FEC TLV
+
+   Labels are bound to Forwarding Equivalence Classes (FECs).  A FEC is
+   a list of one or more FEC elements.  The FEC TLV encodes FEC items.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 34]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+   Its encoding is:
+
+    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| FEC (0x0100)              |      Length                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        FEC Element 1                          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   ~                                                               ~
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        FEC Element n                          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   FEC Element 1 to FEC Element n
+      There are several types of FEC elements; see Section "FECs".  The
+      FEC element encoding depends on the type of FEC element.
+
+      A FEC Element value is encoded as a 1 octet field that specifies
+      the element type, and a variable length field that is the type-
+      dependent element value.  Note that while the representation of
+      the FEC element value is type-dependent, the FEC element encoding
+      itself is one where standard LDP TLV encoding is not used.
+
+      The FEC Element value encoding is:
+
+         FEC Element       Type      Value
+         type name
+
+           Wildcard        0x01      No value; i.e., 0 value octets;
+                                         see below.
+           Prefix          0x02      See below.
+           Host Address    0x03      Full host address; see below.
+
+      Note that this version of LDP supports the use of multiple FEC
+      Elements per FEC for the Label Mapping message only.  The use of
+      multiple FEC Elements in other messages is not permitted in this
+      version, and is a subject for future study.
+
+      Wildcard FEC Element
+         To be used only in the Label Withdraw and Label Release
+         Messages.  Indicates the withdraw/release is to be applied to
+         all FECs associated with the label within the following label
+         TLV.  Must be the only FEC Element in the FEC TLV.
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 35]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      Prefix FEC Element value encoding:
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Prefix (2)   |     Address Family            |     PreLen    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                     Prefix                                    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Address Family
+         Two octet quantity containing a value from ADDRESS FAMILY
+         NUMBERS in [RFC1700] that encodes the address family for the
+         address prefix in the Prefix field.
+
+      PreLen
+         One octet unsigned integer containing the length in bits of the
+         address prefix that follows.  A length of zero indicates a
+         prefix that matches all addresses (the default destination); in
+         this case the Prefix itself is zero octets).
+
+      Prefix
+         An address prefix encoded according to the Address Family
+         field, whose length, in bits, was specified in the PreLen
+         field, padded to a byte boundary.
+
+      Host Address FEC Element encoding:
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | Host Addr (3) |     Address Family            | Host Addr Len |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      |                     Host Addr                                 |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Address Family
+         Two octet quantity containing a value from ADDRESS FAMILY
+         NUMBERS in [RFC1700] that encodes the address family for the
+         address prefix in the Prefix field.
+
+      Host Addr Len
+         Length of the Host address in octets.
+
+      Host Addr
+         An address encoded according to the Address Family field.
+
+
+
+Andersson, et al.           Standards Track                    [Page 36]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+3.4.1.1. FEC Procedures
+
+   If in decoding a FEC TLV an LSR encounters a FEC Element with an
+   Address Family it does not support, it should stop decoding the FEC
+   TLV, abort processing the message containing the TLV, and send an
+   "Unsupported Address Family" Notification message to its LDP peer
+   signaling an error.
+
+   If it encounters a FEC Element type it cannot decode, it should stop
+   decoding the FEC TLV, abort processing the message containing the
+   TLV, and send an "Unknown FEC" Notification message to its LDP peer
+   signaling an error.
+
+3.4.2. Label TLVs
+
+   Label TLVs encode labels.  Label TLVs are carried by the messages
+   used to advertise, request, release and withdraw label mappings.
+
+   There are several different kinds of Label TLVs which can appear in
+   situations that require a Label TLV.
+
+3.4.2.1. Generic Label TLV
+
+   An LSR uses Generic Label TLVs to encode labels for use on links for
+   which label values are independent of the underlying link technology.
+   Examples of such links are PPP and Ethernet.
+
+    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| Generic Label (0x0200)    |      Length                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Label                                                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Label
+      This is a 20-bit label value as specified in [RFC3032] represented
+      as a 20-bit number in a 4 octet field.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 37]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+3.4.2.2. ATM Label TLV
+
+   An LSR uses ATM Label TLVs to encode labels for use on ATM links.
+
+    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| ATM Label (0x0201)        |         Length                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |Res| V |          VPI          |         VCI                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Res
+      This field is reserved.  It must be set to zero on transmission
+      and must be ignored on receipt.
+
+   V-bits
+      Two-bit switching indicator.  If V-bits is 00, both the VPI and
+      VCI are significant.  If V-bits is 01, only the VPI field is
+      significant.  If V-bit is 10, only the VCI is significant.
+
+   VPI
+      Virtual Path Identifier.  If VPI is less than 12-bits it should be
+      right justified in this field and preceding bits should be set to
+      0.
+
+   VCI
+      Virtual Channel Identifier.  If the VCI is less than 16- bits, it
+      should be right justified in the field and the preceding bits must
+      be set to 0.  If Virtual Path switching is indicated in the V-bits
+      field, then this field must be ignored by the receiver and set to
+      0 by the sender.
+
+3.4.2.3. Frame Relay Label TLV
+
+   An LSR uses Frame Relay Label TLVs to encode labels for use on Frame
+   Relay links.
+
+    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| Frame Relay Label (0x0202)|       Length                  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | Reserved    |Len|                     DLCI                    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 38]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+   Res
+      This field is reserved.  It must be set to zero on transmission
+      and must be ignored on receipt.
+
+   Len
+      This field specifies the number of bits of the DLCI.  The
+      following values are supported:
+
+         0 = 10 bits DLCI
+         2 = 23 bits DLCI
+
+      Len values 1 and 3 are reserved.
+
+   DLCI
+      The Data Link Connection Identifier.  Refer to [RFC3034] for the
+      label values and formats.
+
+3.4.3. Address List TLV
+
+   The Address List TLV appears in Address and Address Withdraw
+   messages.
+
+   Its encoding is:
+
+    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| Address List (0x0101)     |      Length                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Address Family            |                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
+   |                                                               |
+   |                        Addresses                              |
+   ~                                                               ~
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Address Family
+      Two octet quantity containing a value from ADDRESS FAMILY NUMBERS
+      in [RFC1700] that encodes the addresses contained in the Addresses
+      field.
+
+   Addresses
+      A list of addresses from the specified Address Family.  The
+      encoding of the individual addresses depends on the Address Family.
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 39]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      The following address encodings are defined by this version of the
+      protocol:
+
+         Address Family      Address Encoding
+
+         IPv4                4 octet full IPv4 address
+         IPv6                16 octet full IPv6 address
+
+3.4.4. Hop Count TLV
+
+   The Hop Count TLV appears as an optional field in messages that set
+   up LSPs.  It calculates the number of LSR hops along an LSP as the
+   LSP is being setup.
+
+   Note that setup procedures for LSPs that traverse ATM and Frame Relay
+   links require use of the Hop Count TLV (see [RFC3035] and [RFC3034]).
+
+    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| Hop Count (0x0103)        |      Length                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     HC Value  |
+   +-+-+-+-+-+-+-+-+
+
+   HC Value
+      1 octet unsigned integer hop count value.
+
+3.4.4.1. Hop Count Procedures
+
+   During setup of an LSP an LSR R may receive a Label Mapping or Label
+   Request message for the LSP that contains the Hop Count TLV.  If it
+   does, it should record the hop count value.
+
+   If LSR R then propagates the Label Mapping message for the LSP to an
+   upstream peer or the Label Request message to a downstream peer to
+   continue the LSP setup, it must must determine a hop count to include
+   in the propagated message as follows:
+
+   -  If the message is a Label Request message, R must increment the
+      received hop count;
+
+   -  If the message is a Label Mapping message, R determines the hop
+      count as follows:
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 40]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      o  If R is a member of the edge set of an LSR domain whose LSRs do
+         not perform 'TTL-decrement' and the upstream peer is within
+         that domain, R must reset the hop count to 1 before propagating
+         the message.
+
+      o  Otherwise, R must increment the received hop count.
+
+   The first LSR in the LSP (ingress for a Label Request message, egress
+   for a Label Mapping message) should set the hop count value to 1.
+
+   By convention a value of 0 indicates an unknown hop count.  The
+   result of incrementing an unknown hop count is itself an unknown hop
+   count (0).
+
+   Use of the unknown hop count value greatly reduces the signaling
+   overhead when independent control is used.  When a new LSP is
+   established, each LSR starts with unknown hop count.  Addition of a
+   new LSR whose hop count is also unknown does not cause a hop count
+   update to be propagated upstream since the hop count remains unknown.
+   When the egress is finally added to the LSP, then the LSRs propagate
+   hop count updates upstream via Label Mapping messages.
+
+   Without use of the unknown hop count, each time a new LSR is added to
+   the LSP a hop count update would need to be propagated upstream if
+   the new LSR is closer to the egress than any of the other LSRs.
+   These updates are useless overhead since they don't reflect the hop
+   count to the egress.
+
+   From the perspective of the ingress node, the fact that the hop count
+   is unknown implies nothing about whether a packet sent on the LSP
+   will actually make it to the egress.  All it implies is that the hop
+   count update from the egress has not yet reached the ingress.
+
+   If an LSR receives a message containing a Hop Count TLV, it must
+   check the hop count value to determine whether the hop count has
+   exceeded its configured maximum allowable value.  If so, it must
+   behave as if the containing message has traversed a loop by sending a
+   Notification message signaling Loop Detected in reply to the sender
+   of the message.
+
+   If Loop Detection is configured, the LSR must follow the procedures
+   specified in Section "Loop Detection".
+
+3.4.5. Path Vector TLV
+
+   The Path Vector TLV is used with the Hop Count TLV in Label Request
+   and Label Mapping messages to implement the optional LDP loop
+   detection mechanism.  See Section "Loop Detection".  Its use in the
+
+
+
+Andersson, et al.           Standards Track                    [Page 41]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+   Label Request message records the path of LSRs the request has
+   traversed.  Its use in the Label Mapping message records the path of
+   LSRs a label advertisement has traversed to setup an LSP.
+
+   Its encoding is:
+
+    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| Path Vector (0x0104)      |        Length                 |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                            LSR Id 1                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   ~                                                               ~
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                            LSR Id n                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   One or more LSR Ids
+      A list of router-ids indicating the path of LSRs the message has
+      traversed.  Each LSR Id is the first four octets (router-id) of
+      the LDP identifier for the corresponding LSR.  This ensures it is
+      unique within the LSR network.
+
+3.4.5.1. Path Vector Procedures
+
+   The Path Vector TLV is carried in Label Mapping and Label Request
+   messages when loop detection is configured.
+
+3.4.5.1.1. Label Request Path Vector
+
+   Section "Loop Detection" specifies situations when an LSR must
+   include a Path Vector TLV in a Label Request message.
+
+   An LSR that receives a Path Vector in a Label Request message must
+   perform the procedures described in Section "Loop Detection".
+
+   If the LSR detects a loop, it must reject the Label Request message.
+
+   The LSR must:
+
+      1. Transmit a Notification message to the sending LSR signaling
+         "Loop Detected".
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 42]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      2. Not propagate the Label Request message further.
+
+   Note that a Label Request message with Path Vector TLV is forwarded
+   until:
+
+      1. A loop is found,
+
+      2. The LSP egress is reached,
+
+      3. The maximum Path Vector limit or maximum Hop Count limit is
+         reached.  This is treated as if a loop had been detected.
+
+3.4.5.1.2. Label Mapping Path Vector
+
+   Section "Loop Detection" specifies the situations when an LSR must
+   include a Path Vector TLV in a Label Mapping message.
+
+   An LSR that receives a Path Vector in a Label Mapping message must
+   perform the procedures described in Section "Loop Detection".
+
+   If the LSR detects a loop, it must reject the Label Mapping message
+   in order to prevent a forwarding loop.  The LSR must:
+
+      1. Transmit a Label Release message carrying a Status TLV to the
+         sending LSR to signal "Loop Detected".
+
+      2. Not propagate the message further.
+
+      3. Check whether the Label Mapping message is for an existing LSP.
+         If so, the LSR must unsplice any upstream labels which are
+         spliced to the downstream label for the FEC.
+
+   Note that a Label Mapping message with a Path Vector TLV is forwarded
+   until:
+
+      1. A loop is found,
+
+      2. An LSP ingress is reached, or
+
+      3. The maximum Path Vector or maximum Hop Count limit is reached.
+         This is treated as if a loop had been detected.
+
+3.4.6. Status TLV
+
+   Notification messages carry Status TLVs to specify events being
+   signaled.
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 43]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+   The encoding for the Status TLV is:
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |U|F| Status (0x0300)           |      Length                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Status Code                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Message ID                                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |      Message Type             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   U bit
+      Should be 0 when the Status TLV is sent in a Notification message.
+      Should be 1 when the Status TLV is sent in some other message.
+
+   F bit
+      Should be the same as the setting of the F-bit in the Status Code
+      field.
+
+   Status Code
+      32-bit unsigned integer encoding the event being signaled.  The
+      structure of a Status Code is:
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |E|F|                 Status Data                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      E bit
+         Fatal error bit.  If set (=1), this is a fatal error
+         notification.  If clear (=0), this is an advisory notification.
+
+      F bit
+         Forward bit.  If set (=1), the notification should be forwarded
+         to the LSR for the next-hop or previous-hop for the LSP, if
+         any, associated with the event being signaled.  If clear (=0),
+         the notification should not be forwarded.
+
+      Status Data
+         30-bit unsigned integer which specifies the status information.
+
+      This specification defines Status Codes (32-bit unsigned integers
+      with the above encoding).
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 44]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      A Status Code of 0 signals success.
+
+   Message ID
+      If non-zero, 32-bit value that identifies the peer message to
+      which the Status TLV refers.  If zero, no specific peer message is
+      being identified.
+
+   Message Type
+      If non-zero, the type of the peer message to which the Status TLV
+      refers.  If zero, the Status TLV does not refer to any specific
+      message type.
+
+   Note that use of the Status TLV is not limited to Notification
+   messages.  A message other than a Notification message may carry a
+   Status TLV as an Optional Parameter.  When a message other than a
+   Notification carries a Status TLV the U-bit of the Status TLV should
+   be set to 1 to indicate that the receiver should silently discard the
+   TLV if unprepared to handle it.
+
+3.5. LDP Messages
+
+   All LDP messages have the following 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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |U|   Message Type              |      Message Length           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Message ID                                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   +                                                               +
+   |                     Mandatory Parameters                      |
+   +                                                               +
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   +                                                               +
+   |                     Optional Parameters                       |
+   +                                                               +
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 45]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+   U bit
+      Unknown message bit.  Upon receipt of an unknown message, if U is
+      clear (=0), a notification is returned to the message originator;
+      if U is set (=1), the unknown message is silently ignored.  The
+      sections following that define messages specify a value for the
+      U-bit.
+
+   Message Type
+      Identifies the type of message
+
+   Message Length
+      Specifies the cumulative length in octets of the Message ID,
+      Mandatory Parameters, and Optional Parameters.
+
+   Message ID
+      32-bit value used to identify this message.  Used by the sending
+      LSR to facilitate identifying notification messages that may apply
+      to this message.  An LSR sending a notification message in
+      response to this message should include this Message Id in the
+      Status TLV carried by the notification message; see Section
+      "Notification Message".
+
+   Mandatory Parameters
+      Variable length set of required message parameters.  Some messages
+      have no required parameters.
+
+      For messages that have required parameters, the required
+      parameters MUST appear in the order specified by the individual
+      message specifications in the sections that follow.
+
+   Optional Parameters
+      Variable length set of optional message parameters.  Many messages
+      have no optional parameters.
+
+      For messages that have optional parameters, the optional
+      parameters may appear in any order.
+
+   Note that there is no alignment requirement for the first octet of an
+   LDP message.
+
+   The following message types are defined in this version of LDP:
+
+      Message Name            Section Title
+
+      Notification            "Notification Message"
+      Hello                   "Hello Message"
+      Initialization          "Initialization Message"
+      KeepAlive               "KeepAlive Message"
+
+
+
+Andersson, et al.           Standards Track                    [Page 46]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      Address                 "Address Message"
+      Address Withdraw        "Address Withdraw Message"
+      Label Mapping           "Label Mapping Message"
+      Label Request           "Label Request Message"
+      Label Abort Request     "Label Abort Request Message"
+      Label Withdraw          "Label Withdraw Message"
+      Label Release           "Label Release Message"
+
+   The sections that follow specify the encodings and procedures for
+   these messages.
+
+   Some of the above messages are related to one another, for example
+   the Label Mapping, Label Request, Label Withdraw, and Label Release
+   messages.
+
+   While it is possible to think about messages related in this way in
+   terms of a message type that specifies a message class and a message
+   subtype that specifies a particular kind of message within that
+   class, this specification does not formalize the notion of a message
+   subtype.
+
+   The specification assigns type values for related messages, such as
+   the label messages, from of a contiguous block in the 16-bit message
+   type number space.
+
+3.5.1. Notification Message
+
+   An LSR sends a Notification message to inform an LDP peer of a
+   significant event.  A Notification message signals a fatal error or
+   provides advisory information such as the outcome of processing an
+   LDP message or the state of the LDP session.
+
+   The encoding for the Notification Message is:
+
+    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|   Notification (0x0001)     |      Message Length           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Message ID                                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Status (TLV)                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Optional Parameters                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Message ID
+      32-bit value used to identify this message.
+
+
+
+Andersson, et al.           Standards Track                    [Page 47]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+   Status TLV
+      Indicates the event being signaled.  The encoding for the Status
+      TLV is specified in Section "Status TLV".
+
+   Optional Parameters
+      This variable length field contains 0 or more parameters, each
+      encoded as a TLV.  The following Optional Parameters are generic
+      and may appear in any Notification Message:
+
+         Optional Parameter     Type     Length  Value
+
+         Extended Status        0x0301    4      See below
+         Returned PDU           0x0302    var    See below
+         Returned Message       0x0303    var    See below
+
+      Other Optional Parameters, specific to the particular event being
+      signaled by the Notification Messages may appear.  These are
+      described elsewhere.
+
+      Extended Status
+         The 4 octet value is an Extended Status Code that encodes
+         additional information that supplements the status information
+         contained in the Notification Status Code.
+
+      Returned PDU
+         An LSR uses this parameter to return part of an LDP PDU to the
+         LSR that sent it.  The value of this TLV is the PDU header and
+         as much PDU data following the header as appropriate for the
+         condition being signaled by the Notification message.
+
+      Returned Message
+         An LSR uses this parameter to return part of an LDP message to
+         the LSR that sent it.  The value of this TLV is the message
+         type and length fields and as much message data following the
+         type and length fields as appropriate for the condition being
+         signaled by the Notification message.
+
+3.5.1.1. Notification Message Procedures
+
+   If an LSR encounters a condition requiring it to notify its peer with
+   advisory or error information it sends the peer a Notification
+   message containing a Status TLV that encodes the information and
+   optionally additional TLVs that provide more information about the
+   condition.
+
+   If the condition is one that is a fatal error the Status Code carried
+   in the notification will indicate that.  In this case, after sending
+   the Notification message the LSR should terminate the LDP session by
+
+
+
+Andersson, et al.           Standards Track                    [Page 48]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+   closing the session TCP connection and discard all state associated
+   with the session, including all label-FEC bindings learned via the
+   session.
+
+   When an LSR receives a Notification message that carries a Status
+   Code that indicates a fatal error, it should terminate the LDP
+   session immediately by closing the session TCP connection and discard
+   all state associated with the session, including all label-FEC
+   bindings learned via the session.
+
+3.5.1.2. Events Signaled by Notification Messages
+
+   It is useful for descriptive purpose to classify events signaled by
+   Notification Messages into the following categories.
+
+3.5.1.2.1. Malformed PDU or Message
+
+   Malformed LDP PDUs or Messages that are part of the LDP Discovery
+   mechanism are handled by silently discarding them.
+
+   An LDP PDU received on a TCP connection for an LDP session is
+   malformed if:
+
+      -  The LDP Identifier in the PDU header is unknown to the
+         receiver, or it is known but is not the LDP Identifier
+         associated by the receiver with the LDP peer for this LDP
+         session.  This is a fatal error signaled by the Bad LDP
+         Identifier Status Code.
+
+      -  The LDP protocol version is not supported by the receiver, or
+         it is supported but is not the version negotiated for the
+         session during session establishment.  This is a fatal error
+         signaled by the Bad Protocol Version Status Code.
+
+      -  The PDU Length field is too small (< 14) or too large
+         (> maximum PDU length).  This is a fatal error signaled by the
+         Bad PDU Length Status Code.  Section "Initialization Message"
+         describes how the maximum PDU length for a session is
+         determined.
+
+   An LDP Message is malformed if:
+
+      -  The Message Type is unknown.
+
+         If the Message Type is < 0x8000 (high order bit = 0) it is an
+         error signaled by the Unknown Message Type Status Code.
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 49]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+         If the Message Type is >= 0x8000 (high order bit = 1) it is
+         silently discarded.
+
+      -  The Message Length is too large, that is, indicates that the
+         message extends beyond the end of the containing LDP PDU.  This
+         is a fatal error signaled by the Bad Message Length Status
+         Code.
+
+      -  The message is missing one or more Mandatory Parameters.  This
+         is a non-fatal error signalled by the Missing Message
+         Parameters Status Code.
+
+3.5.1.2.2. Unknown or Malformed TLV
+
+   Malformed TLVs contained in LDP messages that are part of the LDP
+   Discovery mechanism are handled by silently discarding the containing
+   message.
+
+   A TLV contained in an LDP message received on a TCP connection of an
+   LDP is malformed if:
+
+      -  The TLV Length is too large, that is, indicates that the TLV
+         extends beyond the end of the containing message.  This is a
+         fatal error signaled by the Bad TLV Length Status Code.
+
+      -  The TLV type is unknown.
+
+         If the TLV type is < 0x8000 (high order bit 0) it is an error
+         signaled by the Unknown TLV Status Code.
+
+         If the TLV type is >= 0x8000 (high order bit 1) the TLV is
+         silently dropped.  Section "Unknown TLV in Known Message Type"
+         elaborates on this behavior.
+
+      -  The TLV Value is malformed.  This occurs when the receiver
+         handles the TLV but cannot decode the TLV Value.  This is
+         interpreted as indicative of a bug in either the sending or
+         receiving LSR.  It is a fatal error signaled by the Malformed
+         TLV Value Status Code.
+
+3.5.1.2.3. Session KeepAlive Timer Expiration
+
+   This is a fatal error signaled by the KeepAlive Timer Expired Status
+   Code.
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 50]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+3.5.1.2.4. Unilateral Session Shutdown
+
+   This is a fatal event signaled by the Shutdown Status Code.  The
+   Notification Message may optionally include an Extended Status TLV to
+   provide a reason for the Shutdown.  The sending LSR terminates the
+   session immediately after sending the Notification.
+
+3.5.1.2.5. Initialization Message Events
+
+   The session initialization negotiation (see Section "Session
+   Initialization") may fail if the session parameters received in the
+   Initialization Message are unacceptable.  This is a fatal error.  The
+   specific Status Code depends on the parameter deemed unacceptable,
+   and is defined in Sections "Initialization Message".
+
+3.5.1.2.6. Events Resulting From Other Messages
+
+   Messages other than the Initialization message may result in events
+   that must be signaled to LDP peers via Notification Messages.  These
+   events and the Status Codes used in the Notification Messages to
+   signal them are described in the sections that describe these
+   messages.
+
+3.5.1.2.7. Internal Errors
+
+   An LDP implementation may be capable of detecting problem conditions
+   specific to its implementation.  When such a condition prevents an
+   implementation from interacting correctly with a peer, the
+   implementation should, when capable of doing so, use the Internal
+   Error Status Code to signal the peer.  This is a fatal error.
+
+3.5.1.2.8. Miscellaneous Events
+
+   These are events that fall into none of the categories above.  There
+   are no miscellaneous events defined in this version of the protocol.
+
+3.5.2. Hello Message
+
+   LDP Hello Messages are exchanged as part of the LDP Discovery
+   Mechanism; see Section "LDP Discovery".
+
+   The encoding for the Hello Message is:
+
+
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 51]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+    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|   Hello (0x0100)            |      Message Length           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Message ID                                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Common Hello Parameters TLV               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Optional Parameters                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Message ID
+      32-bit value used to identify this message.
+
+   Common Hello Parameters TLV
+      Specifies parameters common to all Hello messages.  The encoding
+      for the Common Hello Parameters TLV is:
+
+       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| Common Hello Parms(0x0400)|      Length                   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |      Hold Time                |T|R| Reserved                  |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Hold Time,
+         Hello hold time in seconds.  An LSR maintains a record of
+         Hellos received from potential peers (see Section "Hello
+         Message Procedures").  Hello Hold Time specifies the time the
+         sending LSR will maintain its record of Hellos from the
+         receiving LSR without receipt of another Hello.
+
+         A pair of LSRs negotiates the hold times they use for Hellos
+         from each other.  Each proposes a hold time.  The hold time
+         used is the minimum of the hold times proposed in their Hellos.
+
+         A value of 0 means use the default, which is 15 seconds for
+         Link Hellos and 45 seconds for Targeted Hellos.  A value of
+         0xffff means infinite.
+
+      T, Targeted Hello
+         A value of 1 specifies that this Hello is a Targeted Hello.  A
+         value of 0 specifies that this Hello is a Link Hello.
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 52]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      R, Request Send Targeted Hellos
+         A value of 1 requests the receiver to send periodic Targeted
+         Hellos to the source of this Hello.  A value of 0 makes no
+         request.
+
+         An LSR initiating Extended Discovery sets R to 1.  If R is 1,
+         the receiving LSR checks whether it has been configured to send
+         Targeted Hellos to the Hello source in response to Hellos with
+         this request.  If not, it ignores the request.  If so, it
+         initiates periodic transmission of Targeted Hellos to the Hello
+         source.
+
+      Reserved
+         This field is reserved.  It must be set to zero on transmission
+         and ignored on receipt.
+
+      Optional Parameters
+         This variable length field contains 0 or more parameters, each
+         encoded as a TLV.  The optional parameters defined by this
+         version of the protocol are
+
+         Optional Parameter         Type     Length  Value
+
+         IPv4 Transport Address     0x0401     4      See below
+         Configuration              0x0402     4      See below
+            Sequence Number
+         IPv6 Transport Address     0x0403    16      See below
+
+      IPv4 Transport Address
+         Specifies the IPv4 address to be used for the sending LSR when
+         opening the LDP session TCP connection.  If this optional TLV
+         is not present the IPv4 source address for the UDP packet
+         carrying the Hello should be used.
+
+      Configuration Sequence Number
+         Specifies a 4 octet unsigned configuration sequence number that
+         identifies the configuration state of the sending LSR.  Used by
+         the receiving LSR to detect configuration changes on the
+         sending LSR.
+
+      IPv6 Transport Address
+         Specifies the IPv6 address to be used for the sending LSR when
+         opening the LDP session TCP connection.  If this optional TLV
+         is not present the IPv6 source address for the UDP packet
+         carrying the Hello should be used.
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 53]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+3.5.2.1. Hello Message Procedures
+
+   An LSR receiving Hellos from another LSR maintains a Hello adjacency
+   corresponding to the Hellos.  The LSR maintains a hold timer with the
+   Hello adjacency which it restarts whenever it receives a Hello that
+   matches the Hello adjacency.  If the hold timer for a Hello adjacency
+   expires the LSR discards the Hello adjacency: see sections
+   "Maintaining Hello Adjacencies" and "Maintaining LDP Sessions".
+
+   We recommend that the interval between Hello transmissions be at most
+   one third of the Hello hold time.
+
+   An LSR processes a received LDP Hello as follows:
+
+      1. The LSR checks whether the Hello is acceptable.  The criteria
+         for determining whether a Hello is acceptable are
+         implementation dependent (see below for example criteria).
+
+      2. If the Hello is not acceptable, the LSR ignores it.
+
+      3. If the Hello is acceptable, the LSR checks whether it has a
+         Hello adjacency for the Hello source.  If so, it restarts the
+         hold timer for the Hello adjacency.  If not it creates a Hello
+         adjacency for the Hello source and starts its hold timer.
+
+      4. If the Hello carries any optional TLVs the LSR processes them
+         (see below).
+
+      5. Finally, if the LSR has no LDP session for the label space
+         specified by the LDP identifier in the PDU header for the
+         Hello, it follows the procedures of Section "LDP Session
+         Establishment".
+
+   The following are examples of acceptability criteria for Link and
+   Targeted Hellos:
+
+      A Link Hello is acceptable if the interface on which it was
+      received has been configured for label switching.
+
+      A Targeted Hello from source address A is acceptable if either:
+
+      -  The LSR has been configured to accept Targeted Hellos, or
+
+      -  The LSR has been configured to send Targeted Hellos to A.
+
+      The following describes how an LSR processes Hello optional TLVs:
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 54]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      Transport Address
+         The LSR associates the specified transport address with the
+         Hello adjacency.
+
+      Configuration Sequence Number
+         The Configuration Sequence Number optional parameter is used by
+         the sending LSR to signal configuration changes to the
+         receiving LSR.  When a receiving LSR playing the active role in
+         LDP session establishment detects a change in the sending LSR
+         configuration, it may clear the session setup backoff delay, if
+         any, associated with the sending LSR (see Section "Session
+         Initialization").
+
+         A sending LSR using this optional parameter is responsible for
+         maintaining the configuration sequence number it transmits in
+         Hello messages.  Whenever there is a configuration change on
+         the sending LSR, it increments the configuration sequence
+         number.
+
+3.5.3. Initialization Message
+
+   The LDP Initialization Message is exchanged as part of the LDP
+   session establishment procedure; see Section "LDP Session
+   Establishment".
+
+   The encoding for the Initialization Message is:
+
+    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|   Initialization (0x0200)   |      Message Length           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Message ID                                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Common Session Parameters TLV             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Optional Parameters                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Message ID
+      32-bit value used to identify this message.
+
+   Common Session Parameters TLV
+      Specifies values proposed by the sending LSR for parameters that
+      must be negotiated for every LDP session.
+
+      The encoding for the Common Session Parameters TLV is:
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 55]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+       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| Common Sess Parms (0x0500)|      Length                   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | Protocol Version              |      KeepAlive Time           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |A|D|  Reserved |     PVLim     |      Max PDU Length           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                 Receiver LDP Identifier                       |
+      +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                               |
+      -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++
+
+      Protocol Version
+         Two octet unsigned integer containing the version number of the
+         protocol.  This version of the specification specifies LDP
+         protocol version 1.
+
+      KeepAlive Time
+         Two octet unsigned non zero integer that indicates the number
+         of seconds that the sending LSR proposes for the value of the
+         KeepAlive Time.  The receiving LSR MUST calculate the value of
+         the KeepAlive Timer by using the smaller of its proposed
+         KeepAlive Time and the KeepAlive Time received in the PDU.  The
+         value chosen for KeepAlive Time indicates the maximum number of
+         seconds that may elapse between the receipt of successive PDUs
+         from the LDP peer on the session TCP connection.  The KeepAlive
+         Timer is reset each time a PDU arrives.
+
+      A, Label Advertisement Discipline
+         Indicates the type of Label advertisement.  A value of 0 means
+         Downstream Unsolicited advertisement; a value of 1 means
+         Downstream On Demand.
+
+         If one LSR proposes Downstream Unsolicited and the other
+         proposes Downstream on Demand, the rules for resolving this
+         difference is:
+
+         -  If the session is for a label-controlled ATM link or a
+            label-controlled Frame Relay link, then Downstream on Demand
+            must be used.
+
+         -  Otherwise, Downstream Unsolicited must be used.
+
+         If the label advertisement discipline determined in this way is
+         unacceptable to an LSR, it must send a Session
+         Rejected/Parameters Advertisement Mode Notification message in
+
+
+
+Andersson, et al.           Standards Track                    [Page 56]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+         response to the Initialization message and not establish the
+         session.
+
+      D, Loop Detection
+         Indicates whether loop detection based on path vectors is
+         enabled.  A value of 0 means loop detection is disabled; a
+         value of 1 means that loop detection is enabled.
+
+      PVLim, Path Vector Limit
+         The configured maximum path vector length.  Must be 0 if loop
+         detection is disabled (D = 0).  If the loop detection
+         procedures would require the LSR to send a path vector that
+         exceeds this limit, the LSR will behave as if a loop had been
+         detected for the FEC in question.
+
+         When Loop Detection is enabled in a portion of a network, it is
+         recommended that all LSRs in that portion of the network be
+         configured with the same path vector limit.  Although knowledge
+         of a peer's path vector limit will not change an LSR's
+         behavior, it does enable the LSR to alert an operator to a
+         possible misconfiguration.
+
+      Reserved
+         This field is reserved.  It must be set to zero on transmission
+         and ignored on receipt.
+
+      Max PDU Length
+         Two octet unsigned integer that proposes the maximum allowable
+         length for LDP PDUs for the session.  A value of 255 or less
+         specifies the default maximum length of 4096 octets.
+
+         The receiving LSR MUST calculate the maximum PDU length for the
+         session by using the smaller of its and its peer's proposals
+         for Max PDU Length.  The default maximum PDU length applies
+         before session initialization completes.
+
+         If the maximum PDU length determined this way is unacceptable
+         to an LSR, it must send a Session Rejected/Parameters Max PDU
+         Length Notification message in response to the Initialization
+         message and not establish the session.
+
+      Receiver LDP Identifier
+         Identifies the receiver's label space.  This LDP Identifier,
+         together with the sender's LDP Identifier in the PDU header
+         enables the receiver to match the Initialization message with
+         one of its Hello adjacencies; see Section "Hello Message
+         Procedures".
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 57]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+         If there is no matching Hello adjacency, the LSR must send a
+         Session Rejected/No Hello Notification message in response to
+         the Initialization message and not establish the session.
+
+   Optional Parameters
+      This variable length field contains 0 or more parameters, each
+      encoded as a TLV.  The optional parameters are:
+
+         Optional Parameter       Type     Length  Value
+
+         ATM Session Parameters   0x0501   var     See below
+         Frame Relay Session      0x0502   var     See below
+           Parameters
+
+      ATM Session Parameters
+         Used when an LDP session manages label exchange for an ATM link
+         to specify ATM-specific session parameters.
+
+       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|   ATM Sess Parms (0x0501) |      Length                   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | M |   N   |D|                        Reserved                 |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                 ATM Label Range Component 1                   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~                                                               ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                 ATM Label Range Component N                   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      M, ATM Merge Capabilities
+         Specifies the merge capabilities of an ATM switch.  The
+         following values are supported in this version of the
+         specification:
+
+                  Value          Meaning
+
+                    0            Merge not supported
+                    1            VP Merge supported
+                    2            VC Merge supported
+                    3            VP & VC Merge supported
+
+         If the merge capabilities of the LSRs differ, then:
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 58]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+         -  Non-merge and VC-merge LSRs may freely interoperate.
+
+         -  The interoperability of VP-merge-capable switches with non-
+            VP-merge-capable switches is a subject for future study.
+            When the LSRs differ on the use of VP-merge, the session is
+            established, but VP merge is not used.
+
+         Note that if VP merge is used, it is the responsibility of the
+         ingress node to ensure that the chosen VCI is unique within the
+         LSR domain (see [ATM-VP]).
+
+      N, Number of label range components
+         Specifies the number of ATM Label Range Components included in
+         the TLV.
+
+      D, VC Directionality
+         A value of 0 specifies bidirectional VC capability, meaning the
+         LSR can (within a given VPI) support the use of a given VCI as
+         a label for both link directions independently.  A value of 1
+         specifies unidirectional VC capability, meaning (within a given
+         VPI) a given VCI may appear in a label mapping for one
+         direction on the link only.  When either or both of the peers
+         specifies unidirectional VC capability, both LSRs use
+         unidirectional VC label assignment for the link as follows.
+         The LSRs compare their LDP Identifiers as unsigned integers.
+         The LSR with the larger LDP Identifier may assign only odd-
+         numbered VCIs in the VPI/VCI range as labels.  The system with
+         the smaller LDP Identifier may assign only even-numbered VCIs
+         in the VPI/VCI range as labels.
+
+      Reserved
+         This field is reserved.  It must be set to zero on transmission
+         and ignored on receipt.
+
+      One or more ATM Label Range Components
+         A list of ATM Label Range Components which together specify the
+         Label range supported by the transmitting LSR.
+
+         A receiving LSR MUST calculate the intersection between the
+         received range and its own supported label range.  The
+         intersection is the range in which the LSR may allocate and
+         accept labels.  LSRs MUST NOT establish a session with
+         neighbors for which the intersection of ranges is NULL.  In
+         this case, the LSR must send a Session Rejected/Parameters
+         Label Range Notification message in response to the
+         Initialization message and not establish the session.
+
+         The encoding for an ATM Label Range Component is:
+
+
+
+Andersson, et al.           Standards Track                    [Page 59]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Res  |    Minimum VPI        |      Minimum VCI              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Res  |    Maximum VPI        |      Maximum VCI              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+         Res
+            This field is reserved. It must be set to zero on
+            transmission and must be ignored on receipt.
+
+         Minimum VPI (12 bits)
+            This 12 bit field specifies the lower bound of a block of
+            Virtual Path Identifiers that is supported on the
+            originating switch.  If the VPI is less than 12-bits it
+            should be right justified in this field and preceding bits
+            should be set to 0.
+
+         Minimum VCI (16 bits)
+            This 16 bit field specifies the lower bound of a block of
+            Virtual Connection Identifiers that is supported on the
+            originating switch.  If the VCI is less than 16-bits it
+            should be right justified in this field and preceding bits
+            should be set to 0.
+
+         Maximum VPI (12 bits)
+            This 12 bit field specifies the upper bound of a block of
+            Virtual Path Identifiers that is supported on the
+            originating switch.  If the VPI is less than 12-bits it
+            should be right justified in this field and preceding bits
+            should be set to 0.
+
+         Maximum VCI (16 bits)
+            This 16 bit field specifies the upper bound of a block of
+            Virtual Connection Identifiers that is supported on the
+            originating switch.  If the VCI is less than 16-bits it
+            should be right justified in this field and preceding bits
+            should be set to 0.
+
+      When peer LSRs are connected indirectly by means of an ATM VP, the
+      sending LSR should set the Minimum and Maximum VPI fields to 0,
+      and the receiving LSR must ignore the Minimum and Maximum VPI
+      fields.
+
+      See [ATM-VP] for specification of the fields for ATM Label Range
+      Components to be used with VP merge LSRs.
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 60]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      Frame Relay Session Parameters
+         Used when an LDP session manages label exchange for a Frame
+         Relay link to specify Frame Relay-specific session parameters.
+
+       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|   FR Sess Parms (0x0502)  |      Length                   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | M |   N   |D|                        Reserved                 |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |             Frame Relay Label Range Component 1               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~                                                               ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |             Frame Relay Label Range Component N               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      M, Frame Relay Merge Capabilities
+         Specifies the merge capabilities of a Frame Relay switch.  The
+         following values are supported in this version of the
+         specification:
+
+                  Value          Meaning
+
+                    0            Merge not supported
+                    1            Merge supported
+
+         Non-merge and merge Frame Relay LSRs may freely interoperate.
+
+      N, Number of label range components
+         Specifies the number of Frame Relay Label Range Components
+         included in the TLV.
+
+      D, VC Directionality
+         A value of 0 specifies bidirectional VC capability, meaning the
+         LSR can support the use of a given DLCI as a label for both
+         link directions independently.  A value of 1 specifies
+         unidirectional VC capability, meaning a given DLCI may appear
+         in a label mapping for one direction on the link only.  When
+         either or both of the peers specifies unidirectional VC
+         capability, both LSRs use unidirectional VC label assignment
+         for the link as follows.  The LSRs compare their LDP
+         Identifiers as unsigned integers.  The LSR with the larger LDP
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 61]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+         Identifier may assign only odd-numbered DLCIs in the range as
+         labels.  The system with the smaller LDP Identifier may assign
+         only even-numbered DLCIs in the range as labels.
+
+      Reserved
+         This field is reserved.  It must be set to zero on transmission
+         and ignored on receipt.
+
+      One or more Frame Relay Label Range Components
+         A list of Frame Relay Label Range Components which together
+         specify the Label range supported by the transmitting LSR.
+
+         A receiving LSR MUST calculate the intersection between the
+         received range and its own supported label range.  The
+         intersection is the range in which the LSR may allocate and
+         accept labels.  LSRs MUST NOT establish a session with
+         neighbors for which the intersection of ranges is NULL.  In
+         this case, the LSR must send a Session Rejected/Parameters
+         Label Range Notification message in response to the
+         Initialization message and not establish the session.
+
+         The encoding for a Frame Relay Label Range Component is:
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | Reserved    |Len|                     Minimum DLCI            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | Reserved        |                     Maximum DLCI            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+         Reserved
+            This field is reserved.  It must be set to zero on
+            transmission and ignored on receipt.
+
+         Len
+            This field specifies the number of bits of the DLCI.  The
+            following values are supported:
+
+                 Len    DLCI bits
+
+                 0       10
+                 2       23
+
+            Len values 1 and 3 are reserved.
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 62]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+         Minimum DLCI
+            This 23-bit field specifies the lower bound of a block of
+            Data Link Connection Identifiers (DLCIs) that is supported
+            on the originating switch.  The DLCI should be right
+            justified in this field and unused bits should be set to 0.
+
+         Maximum DLCI
+            This 23-bit field specifies the upper bound of a block of
+            Data Link Connection Identifiers (DLCIs) that is supported
+            on the originating switch.  The DLCI should be right
+            justified in this field and unused bits should be set to 0.
+
+   Note that there is no Generic Session Parameters TLV for sessions
+   which advertise Generic Labels.
+
+3.5.3.1. Initialization Message Procedures
+
+   See Section "LDP Session Establishment" and particularly Section
+   "Session Initialization" for general procedures for handling the
+   Initialization Message.
+
+3.5.4. KeepAlive Message
+
+   An LSR sends KeepAlive Messages as part of a mechanism that monitors
+   the integrity of the LDP session transport connection.
+
+   The encoding for the KeepAlive Message is:
+
+    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|   KeepAlive (0x0201)        |      Message Length           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Message ID                                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Optional Parameters                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Message ID
+      32-bit value used to identify this message.
+
+   Optional Parameters
+      No optional parameters are defined for the KeepAlive message.
+
+3.5.4.1. KeepAlive Message Procedures
+
+   The KeepAlive Timer mechanism described in Section "Maintaining LDP
+   Sessions" resets a session KeepAlive timer every time an LDP PDU is
+
+
+
+Andersson, et al.           Standards Track                    [Page 63]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+   received on the session TCP connection.  The KeepAlive Message is
+   provided to allow reset of the KeepAlive Timer in circumstances where
+   an LSR has no other information to communicate to an LDP peer.
+
+   An LSR must arrange that its peer receive an LDP Message from it at
+   least every KeepAlive Time period.  Any LDP protocol message will do
+   but, in circumstances where no other LDP protocol messages have been
+   sent within the period, a KeepAlive message must be sent.
+
+3.5.5. Address Message
+
+   An LSR sends the Address Message to an LDP peer to advertise its
+   interface addresses.
+
+   The encoding for the Address Message is:
+
+    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|   Address (0x0300)          |      Message Length           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Message ID                                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   |                     Address List TLV                          |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Optional Parameters                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Message ID
+      32-bit value used to identify this message.
+
+   Address List TLV
+      The list of interface addresses being advertised by the sending
+      LSR.  The encoding for the Address List TLV is specified in Section
+      "Address List TLV".
+
+   Optional Parameters
+      No optional parameters are defined for the Address message.
+
+3.5.5.1. Address Message Procedures
+
+   An LSR that receives an Address Message message uses the addresses it
+   learns to maintain a database for mapping between peer LDP
+   Identifiers and next hop addresses; see Section "LDP Identifiers and
+   Next Hop Addresses".
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 64]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+   When a new LDP session is initialized and before sending Label
+   Mapping or Label Request messages an LSR should advertise its
+   interface addresses with one or more Address messages.
+
+   Whenever an LSR "activates" a new interface address, it should
+   advertise the new address with an Address message.
+
+   Whenever an LSR "de-activates" a previously advertised address, it
+   should withdraw the address with an Address Withdraw message; see
+   Section "Address Withdraw Message".
+
+   If an LSR does not support the Address Family specified in the
+   Address List TLV, it should send an "Unsupported Address Family"
+   Notification to its LDP signalling an error and abort processing the
+   message.
+
+3.5.6. Address Withdraw Message
+
+   An LSR sends the Address Withdraw Message to an LDP peer to withdraw
+   previously advertised interface addresses.
+
+   The encoding for the Address Withdraw Message is:
+
+    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|   Address Withdraw (0x0301) |      Message Length           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Message ID                                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   |                     Address List TLV                          |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Optional Parameters                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Message ID
+      32-bit value used to identify this message.
+
+   Address list TLV
+      The list of interface addresses being withdrawn by the sending
+      LSR.  The encoding for the Address list TLV is specified in
+      Section "Address List TLV".
+
+   Optional Parameters
+      No optional parameters are defined for the Address Withdraw
+      message.
+
+
+
+Andersson, et al.           Standards Track                    [Page 65]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+3.5.6.1. Address Withdraw Message Procedures
+
+   See Section "Address Message Procedures"
+
+3.5.7. Label Mapping Message
+
+   An LSR sends a Label Mapping message to an LDP peer to advertise
+   FEC-label bindings to the peer.
+
+   The encoding for the Label Mapping Message is:
+
+   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|   Label Mapping (0x0400)    |      Message Length           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Message ID                                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     FEC TLV                                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Label TLV                                 |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Optional Parameters                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Message ID
+      32-bit value used to identify this message.
+
+   FEC TLV
+      Specifies the FEC component of the FEC-Label mapping being
+      advertised.  See Section "FEC TLV" for encoding.
+
+   Label TLV
+      Specifies the Label component of the FEC-Label mapping.  See
+      Section "Label TLV" for encoding.
+
+   Optional Parameters
+      This variable length field contains 0 or more parameters, each
+      encoded as a TLV.  The optional parameters are:
+
+         Optional Parameter    Length       Value
+
+         Label Request         4            See below
+             Message ID TLV
+         Hop Count TLV         1            See below
+         Path Vector TLV       variable     See below
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 66]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      The encodings for the Hop Count, and Path Vector TLVs can be found
+      in Section "TLV Encodings for Commonly Used Parameters".
+
+      Label Request Message ID
+         If this Label Mapping message is a response to a Label Request
+         message it must include the Request Message Id optional
+         parameter.  The value of this optional parameter is the Message
+         Id of the corresponding Label Request Message.
+
+      Hop Count
+         Specifies the running total of the number of LSR hops along the
+         LSP being setup by the Label Message.  Section "Hop Count
+         Procedures" describes how to handle this TLV.
+
+      Path Vector
+         Specifies the LSRs along the LSP being setup by the Label
+         Message.  Section "Path Vector Procedures" describes how to
+         handle this TLV.
+
+3.5.7.1. Label Mapping Message Procedures
+
+   The Mapping message is used by an LSR to distribute a label mapping
+   for a FEC to an LDP peer.  If an LSR distributes a mapping for a FEC
+   to multiple LDP peers, it is a local matter whether it maps a single
+   label to the FEC, and distributes that mapping to all its peers, or
+   whether it uses a different mapping for each of its peers.
+
+   An LSR is responsible for the consistency of the label mappings it
+   has distributed, and that its peers have these mappings.
+
+   An LSR receiving a Label Mapping message from a downstream LSR for a
+   Prefix or Host Address FEC Element should not use the label for
+   forwarding unless its routing table contains an entry that exactly
+   matches the FEC Element.
+
+   See Appendix A "LDP Label Distribution Procedures" for more details.
+
+3.5.7.1.1. Independent Control Mapping
+
+   If an LSR is configured for independent control, a mapping message is
+   transmitted by the LSR upon any of the following conditions:
+
+      1. The LSR recognizes a new FEC via the forwarding table, and the
+         label advertisement mode is Downstream Unsolicited
+         advertisement.
+
+      2. The LSR receives a Request message from an upstream peer for a
+         FEC present in the LSR's forwarding table.
+
+
+
+Andersson, et al.           Standards Track                    [Page 67]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      3. The next hop for a FEC changes to another LDP peer, and loop
+         detection is configured.
+
+      4. The attributes of a mapping change.
+
+      5. The receipt of a mapping from the downstream next hop  AND
+            a) no upstream mapping has been created  OR
+            b) loop detection is configured  OR
+            c) the attributes of the mapping have changed.
+
+3.5.7.1.2. Ordered Control Mapping
+
+   If an LSR is doing ordered control, a Mapping message is transmitted
+   by downstream LSRs upon any of the following conditions:
+
+      1. The LSR recognizes a new FEC via the forwarding table, and is
+         the egress for that FEC.
+
+      2. The LSR receives a Request message from an upstream peer for a
+         FEC present in the LSR's forwarding table, and the LSR is the
+         egress for that FEC OR has a downstream mapping for that FEC.
+
+      3. The next hop for a FEC changes to another LDP peer, and loop
+         detection is configured.
+
+      4. The attributes of a mapping change.
+
+      5. The receipt of a mapping from the downstream next hop  AND
+            a) no upstream mapping has been created   OR
+            b) loop detection is configured   OR
+            c) the attributes of the mapping have changed.
+
+3.5.7.1.3. Downstream on Demand Label Advertisement
+
+   In general, the upstream LSR is responsible for requesting label
+   mappings when operating in Downstream on Demand mode.  However,
+   unless some rules are followed, it is possible for neighboring LSRs
+   with different advertisement modes to get into a livelock situation
+   where everything is functioning properly, but no labels are
+   distributed.  For example, consider two LSRs Ru and Rd where Ru is
+   the upstream LSR and Rd is the downstream LSR for a particular FEC.
+   In this example, Ru is using Downstream Unsolicited advertisement
+   mode and Rd is using Downstream on Demand mode.  In this case, Rd may
+   assume that Ru will request a label mapping when it wants one and Ru
+   may assume that Rd will advertise a label if it wants Ru to use one.
+   If Rd and Ru operate as suggested, no labels will be distributed from
+   Rd to Ru.
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 68]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+   This livelock situation can be avoided if the following rule is
+   observed: an LSR operating in Downstream on Demand mode should not be
+   expected to send unsolicited mapping advertisements.  Therefore, if
+   the downstream LSR is operating in Downstream on Demand mode, the
+   upstream LSR is responsible for requesting label mappings as needed.
+
+3.5.7.1.4. Downstream Unsolicited Label Advertisement
+
+   In general, the downstream LSR is responsible for advertising a label
+   mapping when it wants an upstream LSR to use the label.  An upstream
+   LSR may issue a mapping request if it so desires.
+
+   The combination of Downstream Unsolicited mode and conservative label
+   retention can lead to a situation where an LSR releases the label for
+   a FEC that it later needs.  For example, if LSR Rd advertises to LSR
+   Ru the label for a FEC for which it is not Ru's next hop, Ru will
+   release the label.  If Ru's next hop for the FEC later changes to Rd,
+   it needs the previously released label.
+
+   To deal with this situation either Ru can explicitly request the
+   label when it needs it, or Rd can periodically readvertise it to Ru.
+   In many situations Ru will know when it needs the label from Rd.  For
+   example, when its next hop for the FEC changes to Rd.  However, there
+   could be situations when Ru does not.  For example, Rd may be
+   attempting to establish an LSP with non-standard properties.  Forcing
+   Ru to explicitly request the label in this situation would require it
+   to maintain state about a potential LSP with non-standard properties.
+
+   In situations where Ru knows it needs the label, it is responsible
+   for explicitly requesting the label by means of a Label Request
+   message.  In situations where Ru may not know that it needs the
+   label, Rd is responsible for periodically readvertising the label to
+   Ru.
+
+   For this version of LDP, the only situation where Ru knows it needs a
+   label for a FEC from Rd is when Rd is its next hop for the FEC, Ru
+   does not have a label from Rd, and the LSP for the FEC is one that
+   can be established with TLVs defined in this document.
+
+3.5.8. Label Request Message
+
+   An LSR sends the Label Request Message to an LDP peer to request a
+   binding (mapping) for a FEC.
+
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 69]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+   The encoding for the Label Request Message is:
+
+    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|   Label Request (0x0401)    |      Message Length           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Message ID                                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     FEC TLV                                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Optional Parameters                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Message ID
+      32-bit value used to identify this message.
+
+   FEC TLV
+      The FEC for which a label is being requested.  See Section "FEC
+      TLV" for encoding.
+
+   Optional Parameters
+      This variable length field contains 0 or more parameters, each
+      encoded as a TLV.  The optional parameters are:
+
+         Optional Parameter     Length       Value
+
+         Hop Count TLV          1            See below
+         Path Vector TLV        variable     See below
+
+      The encodings for the Hop Count, and Path Vector TLVs can be found
+      in Section "TLV Encodings for Commonly Used Parameters".
+
+      Hop Count
+         Specifies the running total of the number of LSR hops along the
+         LSP being setup by the Label Request Message.  Section "Hop
+         Count Procedures" describes how to handle this TLV.
+
+      Path Vector
+         Specifies the LSRs along the LSR being setup by the Label
+         Request Message.  Section "Path Vector Procedures" describes
+         how to handle this TLV.
+
+3.5.8.1. Label Request Message Procedures
+
+   The Request message is used by an upstream LSR to explicitly request
+   that the downstream LSR assign and advertise a label for a FEC.
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 70]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+   An LSR may transmit a Request message under any of the following
+   conditions:
+
+      1. The LSR recognizes a new FEC via the forwarding table, and the
+         next hop is an LDP peer, and the LSR doesn't already have a
+         mapping from the next hop for the given FEC.
+
+      2. The next hop to the FEC changes, and the LSR doesn't already
+         have a mapping from that next hop for the given FEC.
+
+         Note that if the LSR already has a pending Label Request
+         message for the new next hop it should not issue an additional
+         Label Request in response to the next hop change.
+
+      3. The LSR receives a Label Request for a FEC from an upstream LDP
+         peer, the FEC next hop is an LDP peer, and the LSR doesn't
+         already have a mapping from the next hop.
+
+         Note that since a non-merge LSR must setup a separate LSP for
+         each upstream peer requesting a label, it must send a separate
+         Label Request for each such peer.  A consequence of this is
+         that a non-merge LSR may have multiple Label Request messages
+         for a given FEC outstanding at the same time.
+
+   The receiving LSR should respond to a Label Request message with a
+   Label Mapping for the requested label or with a Notification message
+   indicating why it cannot satisfy the request.
+
+   When the FEC for which a label is requested is a Prefix FEC Element
+   or a Host Address FEC Element, the receiving LSR uses its routing
+   table to determine its response.  Unless its routing table includes
+   an entry that exactly matches the requested Prefix or Host Address,
+   the LSR must respond with a No Route Notification message.
+
+   The message ID of the Label Request message serves as an identifier
+   for the Label Request transaction.  When the receiving LSR responds
+   with a Label Mapping message, the mapping message must include a
+   Label Request/Returned Message ID TLV optional parameter which
+   includes the message ID of the Label Request message.  Note that
+   since LSRs use Label Request message IDs as transaction identifiers
+   an LSR should not reuse the message ID of a Label Request message
+   until the corresponding transaction completes.
+
+   This version of the protocol defines the following Status Codes for
+   the Notification message that signals a request cannot be satisfied:
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 71]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      No Route
+         The FEC for which a label was requested includes a FEC Element
+         for which the LSR does not have a route.
+
+      No Label Resources
+         The LSR cannot provide a label because of resource limitations.
+         When resources become available the LSR must notify the
+         requesting LSR by sending a Notification message with the Label
+         Resources Available Status Code.
+
+         An LSR that receives a No Label Resources response to a Label
+         Request message must not issue further Label Request messages
+         until it receives a Notification message with the Label
+         Resources Available Status code.
+
+      Loop Detected
+         The LSR has detected a looping Label Request message.
+
+   See Appendix A "LDP Label Distribution Procedures" for more details.
+
+3.5.9. Label Abort Request Message
+
+   The Label Abort Request message may be used to abort an outstanding
+   Label Request message.
+
+   The encoding for the Label Abort Request Message is:
+
+    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|   Label Abort Req (0x0404)  |      Message Length           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Message ID                                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     FEC TLV                                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Label Request Message ID TLV              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Optional Parameters                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Message ID
+      32-bit value used to identify this message.
+
+   FEC TLV
+      Identifies the FEC for which the Label Request is being aborted.
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 72]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+   Label Request Message ID TLV
+      Specifies the message ID of the Label Request message to be
+      aborted.
+
+   Optional Parameters
+      No optional parameters are defined for the Label Abort Req
+      message.
+
+3.5.9.1. Label Abort Request Message Procedures
+
+   An LSR Ru may send a Label Abort Request message to abort an
+   outstanding Label Request message for FEC sent to LSR Rd in the
+   following circumstances:
+
+      1. Ru's next hop for FEC has changed from LSR Rd to LSR X; or
+
+      2. Ru is a non-merge, non-ingress LSR and has received a Label
+         Abort Request for FEC from an upstream peer Y.
+
+      3. Ru is a merge, non-ingress LSR and has received a Label Abort
+         Request for FEC from an upstream peer Y and Y is the only
+         (last) upstream LSR requesting a label for FEC.
+
+   There may be other situations where an LSR may choose to abort an
+   outstanding Label Request message in order to reclaim resource
+   associated with the pending LSP.  However, specification of general
+   strategies for using the abort mechanism is beyond the scope of LDP.
+
+   When an LSR receives a Label Abort Request message, if it has not
+   previously responded to the Label Request being aborted with a Label
+   Mapping message or some other Notification message, it must
+   acknowledge the abort by responding with a Label Request Aborted
+   Notification message.  The Notification must include a Label Request
+   Message ID TLV that carries the message ID of the aborted Label
+   Request message.
+
+   If an LSR receives a Label Abort Request Message after it has
+   responded to the Label Request in question with a Label Mapping
+   message or a Notification message, it ignores the abort request.
+
+   If an LSR receives a Label Mapping message in response to a Label
+   Request message after it has sent a Label Abort Request message to
+   abort the Label Request, the label in the Label Mapping message is
+   valid.  The LSR may choose to use the label or to release it with a
+   Label Release message.
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 73]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+   An LSR aborting a Label Request message may not reuse the Message ID
+   for the Label Request message until it receives one of the following
+   from its peer:
+
+      -  A Label Request Aborted Notification message acknowledging the
+         abort;
+
+      -  A Label Mapping message in response to the Label Request
+         message being aborted;
+
+      -  A Notification message in response to the Label Request message
+         being aborted (e.g., Loop Detected, No Label Resources, etc.).
+
+   To protect itself against tardy peers or faulty peer implementations
+   an LSR may choose to time out receipt of the above.  The time out
+   period should be relatively long (several minutes).  If the time out
+   period elapses with no reply from the peer the LSR may reuse the
+   Message Id of the Label Request message; if it does so, it should
+   also discard any record of the outstanding Label Request and Label
+   Abort messages.
+
+   Note that the response to a Label Abort Request message is never
+   "ordered".  That is, the response does not depend on the downstream
+   state of the LSP setup being aborted.  An LSR receiving a Label Abort
+   Request message must process it immediately, regardless of the
+   downstream state of the LSP, responding with a Label Request Aborted
+   Notification or ignoring it, as appropriate.
+
+3.5.10. Label Withdraw Message
+
+   An LSR sends a Label Withdraw Message to an LDP peer to signal the
+   peer that the peer may not continue to use specific FEC-label
+   mappings the LSR had previously advertised.  This breaks the mapping
+   between the FECs and the labels.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 74]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+   The encoding for the Label Withdraw Message is:
+
+    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|   Label Withdraw (0x0402)   |      Message Length           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Message ID                                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     FEC TLV                                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Label TLV (optional)                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Optional Parameters                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Message ID
+      32-bit value used to identify this message.
+
+   FEC TLV
+      Identifies the FEC for which the FEC-label mapping is being
+      withdrawn.
+
+   Optional Parameters
+      This variable length field contains 0 or more parameters, each
+      encoded as a TLV.  The optional parameters are:
+
+         Optional Parameter    Length       Value
+
+         Label TLV             variable     See below
+
+      The encoding for Label TLVs are found in Section "Label TLVs".
+
+      Label
+         If present, specifies the label being withdrawn (see procedures
+         below).
+
+3.5.10.1. Label Withdraw Message Procedures
+
+   An LSR transmits a Label Withdraw message under the following
+   conditions:
+
+      1. The LSR no longer recognizes a previously known FEC for which
+         it has advertised a label.
+
+      2. The LSR has decided unilaterally (e.g., via configuration) to
+         no longer label switch a FEC (or FECs) with the label mapping
+         being withdrawn.
+
+
+
+Andersson, et al.           Standards Track                    [Page 75]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+   The FEC TLV specifies the FEC for which labels are to be withdrawn.
+   If no Label TLV follows the FEC, all labels associated with the FEC
+   are to be withdrawn; otherwise only the label specified in the
+   optional Label TLV is to be withdrawn.
+
+   The FEC TLV may contain the Wildcard FEC Element; if so, it may
+   contain no other FEC Elements.  In this case, if the Label Withdraw
+   message contains an optional Label TLV, then the label is to be
+   withdrawn from all FECs to which it is bound.  If there is not an
+   optional Label TLV in the Label Withdraw message, then the sending
+   LSR is withdrawing all label mappings previously advertised to the
+   receiving LSR.
+
+   An LSR that receives a Label Withdraw message must respond with a
+   Label Release message.
+
+   See Appendix A "LDP Label Distribution Procedures" for more details.
+
+3.5.11. Label Release Message
+
+   An LSR sends a Label Release message to an LDP peer to signal the
+   peer that the LSR no longer needs specific FEC-label mappings
+   previously requested of and/or advertised by the peer.
+
+   The encoding for the Label Release Message is:
+
+    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|   Label Release (0x0403)   |      Message Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Message ID                                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     FEC TLV                                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Label TLV (optional)                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Optional Parameters                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Message ID
+      32-bit value used to identify this message.
+
+   FEC TLV
+      Identifies the FEC for which the FEC-label mapping is being
+      released.
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 76]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+   Optional Parameters
+      This variable length field contains 0 or more parameters, each
+      encoded as a TLV.  The optional parameters are:
+
+         Optional Parameter    Length       Value
+
+         Label TLV             variable     See below
+
+      The encodings for Label TLVs are found in Section "Label TLVs".
+
+      Label
+         If present, the label being released (see procedures below).
+
+3.5.11.1. Label Release Message Procedures
+
+   An LSR transmits a Label Release message to a peer when it is no
+   longer needs a label previously received from or requested of that
+   peer.
+
+   An LSR must transmit a Label Release message under any of the
+   following conditions:
+
+      1. The LSR which sent the label mapping is no longer the next hop
+         for the mapped FEC, and the LSR is configured for conservative
+         operation.
+
+      2. The LSR receives a label mapping from an LSR which is not the
+         next hop for the FEC, and the LSR is configured for
+         conservative operation.
+
+      3. The LSR receives a Label Withdraw message.
+
+   Note that if an LSR is configured for "liberal mode", a release
+   message will never be transmitted in the case of conditions (1) and
+   (2) as specified above.  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 FEC.
+
+   The FEC TLV specifies the FEC for which labels are to be released.
+   If no Label TLV follows the FEC, all labels associated with the FEC
+   are to be released; otherwise only the label specified in the
+   optional Label TLV is to be released.
+
+   The FEC TLV may contain the Wildcard FEC Element; if so, it may
+   contain no other FEC Elements.  In this case, if the Label Release
+   message contains an optional Label TLV, then the label is to be
+   released for all FECs to which it is bound.  If there is not an
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 77]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+   optional Label TLV in the Label Release message, then the sending LSR
+   is releasing all label mappings previously learned from the receiving
+   LSR.
+
+   See Appendix A "LDP Label Distribution Procedures" for more details.
+
+3.6. Messages and TLVs for Extensibility
+
+   Support for LDP extensibility includes the rules for the U and F bits
+   that specify how an LSR should handle unknown TLVs and messages.
+
+   This section specifies TLVs and messages for vendor-private and
+   experimental use.
+
+3.6.1. LDP Vendor-private Extensions
+
+   Vendor-private TLVs and messages are used to convey vendor-private
+   information between LSRs.
+
+3.6.1.1. LDP Vendor-private TLVs
+
+   The Type range 0x3E00 through 0x3EFF is reserved for vendor-private
+   TLVs.
+
+   The encoding for a vendor-private TLV is:
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |U|F|    Type (0x3E00-0x3EFF)   |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           Vendor ID                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   |                           Data....                            |
+   ~                                                               ~
+   |                                                               |
+   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   U bit
+      Unknown TLV bit.  Upon receipt of an unknown TLV, if U is clear
+      (=0), a notification must be returned to the message originator
+      and the entire message must be ignored; if U is set (=1), the
+      unknown TLV is silently ignored and the rest of the message is
+      processed as if the unknown TLV did not exist.
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 78]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      The determination as to whether a vendor-private message is
+      understood is based on the Type and the mandatory Vendor ID field.
+
+   F bit
+      Forward unknown TLV bit.  This bit only applies when the U bit is
+      set and the LDP message containing the unknown TLV is is to be
+      forwarded.  If F is clear (=0), the unknown TLV is not forwarded
+      with the containing message; if F is set (=1), the unknown TLV is
+      forwarded with the containing message.
+
+   Type
+      Type value in the range 0x3E00 through 0x3EFF.  Together, the Type
+      and Vendor Id field specify how the Data field is to be
+      interpreted.
+
+   Length
+      Specifies the cumulative length in octets of the Vendor ID and
+      Data fields.
+
+   Vendor Id
+      802 Vendor ID as assigned by the IEEE.
+
+   Data
+      The remaining octets after the Vendor ID in the Value field are
+      optional vendor-dependent data.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 79]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+3.6.1.2. LDP Vendor-private Messages
+
+   The Message Type range 0x3E00 through 0x3EFF is reserved for vendor-
+   private Messages.
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |U|    Msg Type (0x3E00-0x3EFF) |      Message Length           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Message ID                                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Vendor ID                                 |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   +                                                               +
+   |                     Remaining Mandatory Parameters            |
+   +                                                               +
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   +                                                               +
+   |                     Optional Parameters                       |
+   +                                                               +
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   U bit
+      Unknown message bit.  Upon receipt of an unknown message, if U is
+      clear (=0), a notification is returned to the message originator;
+      if U is set (=1), the unknown message is silently ignored.
+
+      The determination as to whether a vendor-private message is
+      understood is based on the Msg Type and the Vendor ID parameter.
+
+   Msg Type
+      Message type value in the range 0x3E00 through 0x3EFF.  Together,
+      the Msg Type and the Vendor ID specify how the message is to be
+      interpreted.
+
+   Message Length
+      Specifies the cumulative length in octets of the Message ID,
+      Vendor ID, Remaining Mandatory Parameters and Optional Parameters.
+
+
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 80]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+   Message ID
+      32-bit integer used to identify this message.  Used by the sending
+      LSR to facilitate identifying notification messages that may apply
+      to this message.  An LSR sending a notification message in
+      response to this message will include this Message Id in the
+      notification message; see Section "Notification Message".
+
+   Vendor ID
+      802 Vendor ID as assigned by the IEEE.
+
+   Remaining Mandatory Parameters
+      Variable length set of remaining required message parameters.
+
+   Optional Parameters
+      Variable length set of optional message parameters.
+
+3.6.2. LDP Experimental Extensions
+
+   LDP support for experimentation is similar to support for vendor-
+   private extensions with the following differences:
+
+      -  The Type range 0x3F00 through 0x3FFF is reserved for
+         experimental TLVs.
+
+      -  The Message Type range 0x3F00 through 0x3FFF is reserved for
+         experimental messages.
+
+      -  The encodings for experimental TLVs and messages are similar to
+         the vendor-private encodings with the following difference.
+
+         Experimental TLVs and messages use an Experiment ID field in
+         place of a Vendor ID field.  The Experiment ID field is used
+         with the Type or Message Type field to specify the
+         interpretation of the experimental TLV or Message.
+
+         Administration of Experiment IDs is the responsibility of the
+         experimenters.
+
+3.7. Message Summary
+
+   The following are the LDP messages defined in this version of the
+   protocol.
+
+      Message Name            Type     Section Title
+
+      Notification            0x0001   "Notification Message"
+      Hello                   0x0100   "Hello Message"
+      Initialization          0x0200   "Initialization Message"
+
+
+
+Andersson, et al.           Standards Track                    [Page 81]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      KeepAlive               0x0201   "KeepAlive Message"
+      Address                 0x0300   "Address Message"
+      Address Withdraw        0x0301   "Address Withdraw Message"
+      Label Mapping           0x0400   "Label Mapping Message"
+      Label Request           0x0401   "Label Request Message"
+      Label Withdraw          0x0402   "Label Withdraw Message"
+      Label Release           0x0403   "Label Release Message"
+      Label Abort Request     0x0404   "Label Abort Request Message"
+      Vendor-Private          0x3E00-  "LDP Vendor-private Extensions"
+                              0x3EFF
+      Experimental            0x3F00-  "LDP Experimental Extensions"
+                              0x3FFF
+
+3.8. TLV Summary
+
+   The following are the TLVs defined in this version of the protocol.
+
+      TLV                      Type      Section Title
+
+      FEC                      0x0100    "FEC TLV"
+      Address List             0x0101    "Address List TLV"
+      Hop Count                0x0103    "Hop Count TLV"
+      Path Vector              0x0104    "Path Vector TLV"
+      Generic Label            0x0200    "Generic Label TLV"
+      ATM Label                0x0201    "ATM Label TLV"
+      Frame Relay Label        0x0202    "Frame Relay Label TLV"
+      Status                   0x0300    "Status TLV"
+      Extended Status          0x0301    "Notification Message"
+      Returned PDU             0x0302    "Notification Message"
+      Returned Message         0x0303    "Notification Message"
+      Common Hello             0x0400    "Hello Message"
+         Parameters
+      IPv4 Transport Address   0x0401    "Hello Message"
+      Configuration            0x0402    "Hello Message"
+         Sequence Number
+      IPv6 Transport Address   0x0403    "Hello Message"
+      Common Session           0x0500    "Initialization Message"
+         Parameters
+      ATM Session Parameters   0x0501    "Initialization Message"
+      Frame Relay Session      0x0502    "Initialization Message"
+         Parameters
+      Label Request            0x0600    "Label Mapping Message"
+          Message ID
+      Vendor-Private           0x3E00-   "LDP Vendor-private Extensions"
+                               0x3EFF
+      Experimental             0x3F00-   "LDP Experimental Extensions"
+                               0x3FFF
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 82]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+3.9. Status Code Summary
+
+   The following are the Status Codes defined in this version of the
+   protocol.
+
+   The "E" column is the required setting of the Status Code E-bit; the
+   "Status Data" column is the value of the 30-bit Status Data field in
+   the Status Code TLV.
+
+   Note that the setting of the Status Code F-bit is at the discretion
+   of the LSR originating the Status TLV.
+
+      Status Code           E   Status Data   Section Title
+
+      Success               0   0x00000000    "Status TLV"
+      Bad LDP Identifier    1   0x00000001    "Events Signaled by ..."
+      Bad Protocol Version  1   0x00000002    "Events Signaled by ..."
+      Bad PDU Length        1   0x00000003    "Events Signaled by ..."
+      Unknown Message Type  0   0x00000004    "Events Signaled by ..."
+      Bad Message Length    1   0x00000005    "Events Signaled by ..."
+      Unknown TLV           0   0x00000006    "Events Signaled by ..."
+      Bad TLV length        1   0x00000007    "Events Signaled by ..."
+      Malformed TLV Value   1   0x00000008    "Events Signaled by ..."
+      Hold Timer Expired    1   0x00000009    "Events Signaled by ..."
+      Shutdown              1   0x0000000A    "Events Signaled by ..."
+      Loop Detected         0   0x0000000B    "Loop Detection"
+      Unknown FEC           0   0x0000000C    "FEC Procedures"
+      No Route              0   0x0000000D    "Label Request Mess ..."
+      No Label Resources    0   0x0000000E    "Label Request Mess ..."
+      Label Resources /     0   0x0000000F    "Label Request Mess ..."
+          Available
+      Session Rejected/     1   0x00000010    "Session Initialization"
+         No Hello
+      Session Rejected/     1   0x00000011    "Session Initialization"
+         Parameters Advertisement Mode
+      Session Rejected/     1   0x00000012    "Session Initialization"
+         Parameters Max PDU Length
+      Session Rejected/     1   0x00000013    "Session Initialization"
+         Parameters Label Range
+      KeepAlive Timer       1   0x00000014    "Events Signaled by ..."
+          Expired
+      Label Request Aborted 0   0x00000015    "Label Request Abort ..."
+      Missing Message       0   0x00000016    "Events Signaled by ..."
+          Parameters
+      Unsupported Address   0   0x00000017    "FEC Procedures"
+          Family                              "Address Message Proc ..."
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 83]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      Session Rejected/     1   0x00000018    "Session Initialization"
+         Bad KeepAlive Time
+      Internal Error        1   0x00000019    "Events Signaled by ..."
+
+3.10. Well-known Numbers
+
+3.10.1. UDP and TCP Ports
+
+   The UDP port for LDP Hello messages is 646.
+
+   The TCP port for establishing LDP session connections is 646.
+
+3.10.2. Implicit NULL Label
+
+   The Implicit NULL label (see [RFC3031]) is represented as a Generic
+   Label TLV with a Label field value as specified by [RFC3032].
+
+4. IANA Considerations
+
+   LDP defines the following name spaces which require management:
+
+      -  Message Type Name Space.
+      -  TLV Type Name Space.
+      -  FEC Type Name Space.
+      -  Status Code Name Space.
+      -  Experiment ID Name Space.
+
+   The following sections provide guidelines for managing these name
+   spaces.
+
+4.1. Message Type Name Space
+
+   LDP divides the name space for message types into three ranges.  The
+   following are the guidelines for managing these ranges:
+
+      -  Message Types 0x0000 - 0x3DFF.  Message types in this range are
+         part of the LDP base protocol.  Following the policies outlined
+         in [IANA], Message types in this range are allocated through an
+         IETF Consensus action.
+
+      -  Message Types 0x3E00 - 0x3EFF.  Message types in this range are
+         reserved for Vendor Private extensions and are the
+         responsibility of the individual vendors (see Section "LDP
+         Vendor-private Messages").  IANA management of this range of
+         the Message Type Name Space is unnecessary.
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 84]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      -  Message Types 0x3F00 - 0x3FFF.  Message types in this range are
+         reserved for Experimental extensions and are the responsibility
+         of the individual experimenters (see Sections "LDP Experimental
+         Extensions" and "Experiment ID Name Space").  IANA management
+         of this range of the Message Type Name Space is unnecessary;
+         however, IANA is responsible for managing part of the
+         Experiment ID Name Space (see below).
+
+4.2. TLV Type Name Space
+
+   LDP divides the name space for TLV types into three ranges.  The
+   following are the guidelines for managing these ranges:
+
+      -  TLV Types 0x0000 - 0x3DFF.  TLV types in this range are part of
+         the LDP base protocol.  Following the policies outlined in
+         [IANA], TLV types in this range are allocated through an IETF
+         Consensus action.
+
+      -  TLV Types 0x3E00 - 0x3EFF.  TLV types in this range are
+         reserved for Vendor Private extensions and are the
+         responsibility of the individual vendors (see Section "LDP
+         Vendor-private TLVs").  IANA management of this range of the
+         TLV Type Name Space is unnecessary.
+
+      -  TLV Types 0x3F00 - 0x3FFF.  TLV types in this range are
+         reserved for Experimental extensions and are the responsibility
+         of the individual experimenters (see Sections "LDP Experimental
+         Extensions" and "Experiment ID Name Space").  IANA management
+         of this range of the TLV Name Space is unnecessary; however,
+         IANA is responsible for managing part of the Experiment ID Name
+         Space (see below).
+
+4.3. FEC Type Name Space
+
+   The range for FEC types is 0 - 255.
+
+   Following the policies outlined in [IANA], FEC types in the range 0 -
+   127 are allocated through an IETF Consensus action, types in the
+   range 128 - 191 are allocated as First Come First Served, and types
+   in the range 192 - 255 are reserved for Private Use.
+
+
+
+
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 85]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+4.4. Status Code Name Space
+
+   The range for Status Codes is 0x00000000 - 0x3FFFFFFF.
+
+   Following the policies outlined in [IANA], Status Codes in the range
+   0x00000000 - 0x1FFFFFFF are allocated through an IETF Consensus
+   action, codes in the range 0x20000000 - 0x3EFFFFFF are allocated as
+   First Come First Served, and codes in the range 0x3F000000 -
+   0x3FFFFFFF are reserved for Private Use.
+
+4.5. Experiment ID Name Space
+
+   The range for Experiment Ids is 0x00000000 - 0xffffffff.
+
+   Following the policies outlined in [IANA], Experiment Ids in the
+   range 0x00000000 - 0xefffffff are allocated as First Come First
+   Served and Experiment Ids in the range 0xf0000000 - 0xffffffff are
+   reserved for Private Use.
+
+5. Security Considerations
+
+   This section identifies threats to which LDP may be vulnerable and
+   discusses means by which those threats might be mitigated.
+
+5.1. Spoofing
+
+   There are two types of LDP communication that could be the target of
+   a spoofing attack.
+
+   1. Discovery exchanges carried by UDP.
+
+      LSRs directly connected at the link level exchange Basic Hello
+      messages over the link.  The threat of spoofed Basic Hellos can be
+      reduced by:
+
+         o  Accepting Basic Hellos only on interfaces to which LSRs that
+            can be trusted are directly connected.
+
+         o  Ignoring Basic Hellos not addressed to the All Routers on
+            this Subnet multicast group.
+
+      LSRs not directly connected at the link level may use Extended
+      Hello messages to indicate willingness to establish an LDP
+      session.  An LSR can reduce the threat of spoofed Extended Hellos
+      by filtering them and accepting only those originating at sources
+      permitted by an access list.
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 86]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+   2. Session communication carried by TCP.
+
+      LDP specifies use of the TCP MD5 Signature Option to provide for
+      the authenticity and integrity of session messages.
+
+      [RFC2385] asserts that MD5 authentication is now considered by
+      some to be too weak for this application.  It also points out that
+      a similar TCP option with a stronger hashing algorithm (it cites
+      SHA-1 as an example) could be deployed.  To our knowledge no such
+      TCP option has been defined and deployed.  However, we note that
+      LDP can use whatever TCP message digest techniques are available,
+      and when one stronger than MD5 is specified and implemented,
+      upgrading LDP to use it would be relatively straightforward.
+
+5.2. Privacy
+
+   LDP provides no mechanism for protecting the privacy of label
+   distribution.
+
+   The security requirements of label distribution protocols are
+   essentially identical to those of the protocols which distribute
+   routing information.  By providing a mechanism to ensure the
+   authenticity and integrity of its messages LDP provides a level of
+   security which is at least as good as, though no better than, that
+   which can be provided by the routing protocols themselves.  The more
+   general issue of whether privacy should be required for routing
+   protocols is beyond the scope of this document.
+
+   One might argue that label distribution requires privacy to address
+   the threat of label spoofing.  However, that privacy would not
+   protect against label spoofing attacks since data packets carry
+   labels in the clear.  Furthermore, label spoofing attacks can be made
+   without knowledge of the FEC bound to a label.
+
+   To avoid label spoofing attacks, it is necessary to ensure that
+   labeled data packets are labeled by trusted LSRs and that the labels
+   placed on the packets are properly learned by the labeling LSRs.
+
+5.3. Denial of Service
+
+   LDP provides two potential targets for denial of service (DoS)
+   attacks:
+
+   1. Well known UDP Port for LDP Discovery
+
+      An LSR administrator can address the threat of DoS attacks via
+      Basic Hellos by ensuring that the LSR is directly connected only
+      to peers which can be trusted to not initiate such an attack.
+
+
+
+Andersson, et al.           Standards Track                    [Page 87]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      Interfaces to peers interior to the administrator's domain should
+      not represent a threat since interior peers are under the
+      administrator's control.  Interfaces to peers exterior to the
+      domain represent a potential threat since exterior peers are not.
+      An administrator can reduce that threat by connecting the LSR only
+      to exterior peers that can be trusted to not initiate a Basic
+      Hello attack.
+
+      DoS attacks via Extended Hellos are potentially a more serious
+      threat.  This threat can be addressed by filtering Extended Hellos
+      using access lists that define addresses with which extended
+      discovery is permitted.  However, performing the filtering
+      requires LSR resource.
+
+      In an environment where a trusted MPLS cloud can be identified,
+      LSRs at the edge of the cloud can be used to protect interior LSRs
+      against DoS attacks via Extended Hellos by filtering out Extended
+      Hellos originating outside of the trusted MPLS cloud, accepting
+      only those originating at addresses permitted by access lists.
+      This filtering protects LSRs in the interior of the cloud but
+      consumes resources at the edges.
+
+   2. Well known TCP port for LDP Session Establishment
+
+      Like other control plane protocols that use TCP, LDP may be the
+      target of DoS attacks, such a SYN attacks.  LDP is no more or less
+      vulnerable to such attacks than other control plane protocols that
+      use TCP.
+
+      The threat of such attacks can be mitigated somewhat by the
+      following:
+
+         o  An LSR should avoid promiscuous TCP listens for LDP session
+            establishment.  It should use only listens that are specific
+            to discovered peers.  This enables it to drop attack packets
+            early in their processing since they are less likely to
+            match existing or in-progress connections.
+
+         o  The use of the MD5 option helps somewhat since it prevents a
+            SYN from being accepted unless the MD5 segment checksum is
+            valid.  However, the receiver must compute the checksum
+            before it can decide to discard an otherwise acceptable SYN
+            segment.
+
+         o  The use of access list mechanisms applied at the boundary of
+            the MPLS cloud in a manner similar to that suggested above
+            for Extended Hellos can protect the interior against attacks
+            originating from outside the cloud.
+
+
+
+Andersson, et al.           Standards Track                    [Page 88]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+6. Areas for Future Study
+
+   The following topics not addressed in this version of LDP are
+   possible areas for future study:
+
+      -  Section 2.16 of the MPLS architecture [RFC3031] requires that
+         the initial label distribution protocol negotiation between
+         peer LSRs enable each LSR to determine whether its peer is
+         capable of popping the label stack.  This version of LDP
+         assumes that LSRs support label popping for all link types
+         except ATM and Frame Relay.  A future version may specify means
+         to make this determination part of the session initiation
+         negotiation.
+
+      -  LDP support for CoS is not specified in this version.  CoS
+         support may be addressed in a future version.
+
+      -  LDP support for multicast is not specified in this version.
+         Multicast support may be addressed in a future version.
+
+      -  LDP support for multipath label switching is not specified in
+         this version.  Multipath support may be addressed in a future
+         version.
+
+7. Intellectual Property Considerations
+
+   The IETF has been notified of intellectual property rights claimed in
+   regard to some or all of the specification contained in this
+   document.  For more information consult the online list of claimed
+   rights.
+
+8. Acknowledgments
+
+   The ideas and text in this document have been collected from a number
+   of sources.  We would like to thank Rick Boivie, Ross Callon, Alex
+   Conta, Eric Gray, Yoshihiro Ohba, Eric Rosen, Bernard Suter, Yakov
+   Rekhter, and Arun Viswanathan.
+
+9. References
+
+   [ATM-VP]    N. Feldman, B. Jamoussi, S. Komandur, A, Viswanathan, T
+               Worster, "MPLS using ATM VP Switching", Work in Progress.
+
+   [CRLDP]     L. Andersson, A. Fredette, B. Jamoussi, R. Callon, P.
+               Doolan, N. Feldman, E. Gray, J. Halpern, J. Heinanen T.
+               E. Kilty, A. G.  Malis, M. Girish, K. Sundell, P.
+               Vaananen, T. Worster, L. Wu, R.  Dantu, "Constraint-Based
+               LSP Setup using LDP", Work in Progress.
+
+
+
+Andersson, et al.           Standards Track                    [Page 89]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+   [DIFFSERV]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
+               and W. Weiss, "An Architecture for Differentiated
+               Services", RFC 2475, December 1998.
+
+   [IANA]      Narten, T. and H. Alvestrand, "Guidelines for Writing an
+               IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+               October 1998.
+
+   [RFC1321]   Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321,
+               April 1992.
+
+   [RFC1483]   Heinanen, J., "Multiprotocol Encapsulation over ATM
+               Adaptation Layer 5", RFC 1483, July 1993.
+
+   [RFC2328]   Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
+
+   [RFC1700]   Reynolds, J. and J. Postel, "ASSIGNED NUMBERS", STD 2,
+               RFC 1700, October 1994.
+
+   [RFC1771]   Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
+               (BGP-4)", RFC 1771, March 1995.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2205]   Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
+               Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
+               Functional Specification", RFC 2205, September 1997.
+
+   [RFC2385]   Heffernan, A., "Protection of BGP Sessions via the TCP
+               MD5 Signature Option", RFC 2385, August 1998.
+
+   [RFC2702]   Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J.
+               McManus, "Requirements for Traffic Engineering over
+               MPLS", RFC 2702, September 1999.
+
+   [RFC3031]   Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol
+               Label Switching Architecture", RFC 3031, January 2001.
+
+   [RFC3032]   Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D.,
+               Fedorkow, G.,  Li, T. and A. Conta, "MPLS Label Stack
+               Encoding", RFC 3032, January 2001.
+
+   [RFC3034]   Conta, A., Doolan, P. and A. Malis, "Use of Label
+               Switching on Frame Relay Networks Specification", RFC
+               3034, January 2001.
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 90]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+   [RFC3035]   Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y.,
+               Rosen, E., Swallow, G. and P. Doolan, "MPLS using LDP and
+               ATM VC Switching", RFC 3035, January 2001.
+
+   [RFC3037]   Thomas, B. and E. Gray, "LDP Applicability", RFC 3037,
+               January 2001.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 91]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+10. Authors' Addresses
+
+   Loa Andersson
+   Nortel Networks Inc
+   St Eriksgatan 115, PO Box 6701
+   113 85 Stockholm
+   Sweden
+
+   Phone: +46 8 5088 36 34
+   Mobile: +46 70 522 78 34
+   EMail: loa.andersson@nortelnetworks.com
+
+
+   Paul Doolan
+   Ennovate Networks
+   60 Codman Hill Rd
+   Marlborough MA 01719
+
+   Phone: 978-263-2002
+   EMail: pdoolan@ennovatenetworks.com
+
+
+   Nancy Feldman
+   IBM Research
+   30 Saw Mill River Road
+   Hawthorne, NY 10532
+
+   Phone:  914-784-3254
+   EMail: nkf@us.ibm.com
+
+
+   Andre Fredette
+   PhotonEx Corporation
+   8C Preston Court
+   Bedford, MA 01730
+
+   Phone: 781-301-4655
+   EMail: fredette@photonex.com
+
+
+   Bob Thomas
+   Cisco Systems, Inc.
+   250 Apollo Dr.
+   Chelmsford, MA 01824
+
+   Phone:  978-244-8078
+   EMail: rhthomas@cisco.com
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 92]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+Appendix A. LDP Label Distribution Procedures
+
+   This section specifies label distribution behavior in terms of LSR
+   response to the following events:
+
+      -  Receive Label Request Message;
+      -  Receive Label Mapping Message;
+      -  Receive Label Abort Request Message;
+      -  Receive Label Release Message;
+      -  Receive Label Withdraw Message;
+      -  Recognize new FEC;
+      -  Detect change in FEC next hop;
+      -  Receive Notification Message / Label Request Aborted;
+      -  Receive Notification Message / No Label Resources;
+      -  Receive Notification Message / No Route;
+      -  Receive Notification Message / Loop Detected;
+      -  Receive Notification Message / Label Resources Available;
+      -  Detect local label resources have become available;
+      -  LSR decides to no longer label switch a FEC;
+      -  Timeout of deferred label request.
+
+   The specification of LSR behavior in response to an event has three
+   parts:
+
+      1. Summary.  Prose that describes LSR response to the event in
+         overview.
+
+      2. Context.  A list of elements referred to by the Algorithm part
+         of the specification.  (See 3.)
+
+      3. Algorithm.  An algorithm for LSR response to the event.
+
+   The Summary may omit details of the LSR response, such as bookkeeping
+   action or behavior dependent on the LSR label advertisement mode,
+   control mode, or label retention mode in use.  The intent is that the
+   Algorithm fully and unambiguously specify the LSR response.
+
+   The algorithms in this section use procedures defined in the MPLS
+   architecture specification [RFC3031] for hop-by-hop routed traffic.
+   These procedures are:
+
+      -  Label Distribution procedure, which is performed by a
+         downstream LSR to determine when to distribute a label for a
+         FEC to LDP peers.  The architecture defines four Label
+         Distribution procedures:
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 93]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+         .  Downstream Unsolicited Independent Control, called
+            PushUnconditional in [RFC3031].
+
+         .  Downstream Unsolicited Ordered Control, called
+            PushConditional in [RFC3031].
+
+         .  Downstream On Demand Independent Control, called
+            PulledUnconditional in [RFC3031].
+
+         .  Downstream On Demand Ordered Control, called
+            PulledConditional in [RFC3031].
+
+      -  Label Withdrawal procedure, which is performed by a downstream
+         LSR to determine when to withdraw a FEC label mapping
+         previously distributed to LDP peers.  The architecture defines
+         a single Label Withdrawal procedure.  Whenever an LSR breaks
+         the binding between a label and a FEC, it must withdraw the FEC
+         label mapping from all LDP peers to which it has previously
+         sent the mapping.
+
+      -  Label Request procedure, which is performed by an upstream LSR
+         to determine when to explicitly request that a downstream LSR
+         bind a label to a FEC and send it the corresponding label
+         mapping.  The architecture defines three Label Request
+         procedures:
+
+         .  Request Never.  The LSR never requests a label.
+
+         .  Request When Needed.  The LSR requests a label whenever
+            it needs one.
+
+         .  Request On Request.  This procedure is used by
+            non-label merging LSRs.  The LSR requests a label
+            when it receives a request for one, in addition
+            to whenever it needs one.
+
+      -  Label Release procedure, which is performed by an upstream LSR
+         to determine when to release a previously received label
+         mapping for a FEC.  The architecture defines two Label Release
+         procedures:
+
+         .  Conservative label retention, called Release On Change in
+            [RFC3031].
+
+         .  Liberal label retention, called No Release On Change in
+            [RFC3031].
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 94]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      -  Label Use procedure, which is performed by an LSR to determine
+         when to start using a FEC label for forwarding/switching.  The
+         architecture defines three Label Use procedures:
+
+         .  Use Immediate.  The LSR immediately uses a label received
+            from a FEC next hop for forwarding/switching.
+
+         .  Use If Loop Free.  The LSR uses a FEC label received from a
+            FEC next hop for forwarding/switching only if it has
+            determined that by doing so it will not cause a forwarding
+            loop.
+
+         .  Use If Loop Not Detected.  This procedure is the same as Use
+            Immediate unless the LSR has detected a loop in the FEC LSP.
+            Use of the FEC label for forwarding/switching will continue
+            until the next hop for the FEC changes or the loop is no
+            longer detected.
+
+         This version of LDP does not include a loop prevention
+         mechanism; therefore, the procedures below do not make use of
+         the Use If Loop Free procedure.
+
+      -  Label No Route procedure (called Label Not Available procedure
+         in [RFC3031]), which is performed by an upstream LSR to
+         determine how to respond to a No Route notification from a
+         downstream LSR in response to a request for a FEC label
+         mapping.  The architecture specification defines two Label No
+         Route procedures:
+
+         .  Request Retry.  The LSR should issue the label request at a
+            later time.
+
+         .  No Request Retry.  The LSR should assume the downstream LSR
+            will provide a label mapping when the downstream LSR has a
+            next hop and it should not reissue the request.
+
+A.1. Handling Label Distribution Events
+
+   This section defines LDP label distribution procedures by specifying
+   an algorithm for each label distribution event.  The requirement on
+   an LDP implementation is that its event handling must have the effect
+   specified by the algorithms.  That is, an implementation need not
+   follow exactly the steps specified by the algorithms as long as the
+   effect is identical.
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 95]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+   The algorithms for handling label distribution events share common
+   actions.  The specifications below package these common actions into
+   procedure units.  Specifications for these common procedures are in
+   their own section "Common Label Distribution Procedures", which
+   follows this.
+
+   An implementation would use data structures to store information
+   about protocol activity.  This appendix specifies the information to
+   be stored in sufficient detail to describe the algorithms, and
+   assumes the ability to retrieve the information as needed.  It does
+   not specify the details of the data structures.
+
+A.1.1. Receive Label Request
+
+   Summary:
+
+      The response by an LSR to receipt of a FEC label request from an
+      LDP peer may involve one or more of the following actions:
+
+      -  Transmission of a notification message to the requesting LSR
+         indicating why a label mapping for the FEC cannot be provided;
+
+      -  Transmission of a FEC label mapping to the requesting LSR;
+
+      -  Transmission of a FEC label request to the FEC next hop;
+
+      -  Installation of labels for forwarding/switching use by the LSR.
+
+   Context:
+
+      -  LSR.  The LSR handling the event.
+
+      -  MsgSource.  The LDP peer that sent the message.
+
+      -  FEC.  The FEC specified in the message.
+
+      -  RAttributes.  Attributes received with the message.  E.g., Hop
+         Count, Path Vector.
+
+      -  SAttributes.  Attributes to be included in Label Request
+         message, if any, propagated to FEC Next Hop.
+
+      -  StoredHopCount.  The hop count, if any, previously recorded for
+         the FEC.
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 96]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+   Algorithm:
+
+      LRq.1   Execute procedure Check_Received_Attributes (MsgSource,
+              LabelRequest, RAttributes).
+              If Loop Detected, goto LRq.13.
+
+      LRq.2   Is there a Next Hop for FEC?
+              If not, goto LRq.5.
+
+      LRq.3   Is MsgSource the Next Hop?
+              Ifnot, goto LRq.6.
+
+      LRq.4   Execute procedure Send_Notification (MsgSource, Loop
+              Detected).
+              Goto LRq.13
+
+      LRq.5   Execute procedure Send_Notification (MsgSource, No Route).
+              Goto LRq.13.
+
+      LRq.6   Has LSR previously received a label request for FEC from
+              MsgSource?
+              If not, goto LRq.8.  (See Note 1.)
+
+      LRq.7   Is the label request a duplicate request?
+              If so, Goto LRq.13.  (See Note 2.)
+
+      LRq.8   Record label request for FEC received from MsgSource and
+              mark it pending.
+
+      LRq.9   Perform LSR Label Distribution procedure:
+
+            For Downstream Unsolicited Independent Control OR
+            For Downstream On Demand Independent Control
+
+               1. Has LSR previously received and retained a label
+                  mapping for FEC from Next Hop?.
+                  Is so, set Propagating to IsPropagating.
+                  If not, set Propagating to NotPropagating.
+
+               2. Execute procedure
+                  Prepare_Label_Mapping_Attributes(MsgSource, FEC,
+                  RAttributes, SAttributes, Propagating,
+                  StoredHopCount).
+
+               3. Execute procedure Send_Label (MsgSource, FEC,
+                  SAttributes).
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 97]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+               4. Is LSR egress for FEC? OR
+                  Has LSR previously received and retained a label
+                  mapping for FEC from Next Hop?
+                  If so, goto LRq.11.
+                  If not, goto LRq.10.
+
+            For Downstream Unsolicited Ordered Control OR
+            For Downstream On Demand Ordered Control
+
+               1. Is LSR egress for FEC? OR
+                  Has LSR previously received and retained a label
+                  mapping for FEC from Next Hop?  (See Note 3.)
+                  If not, goto LRq.10.
+
+               2. Execute procedure
+                  Prepare_Label_Mapping_Attributes(MsgSource, FEC,
+                  RAttributes, SAttributes, IsPropagating,
+                  StoredHopCount)
+
+               3. Execute procedure Send_Label (MsgSource, FEC,
+                  SAttributes).
+                  Goto LRq.11.
+
+      LRq.10  Perform LSR Label Request procedure:
+
+            For Request Never
+
+               1. Goto LRq.13.
+
+            For Request When Needed OR
+            For Request On Request
+
+               1. Execute procedure Prepare_Label_Request_Attributes
+                  (Next Hop, FEC, RAttributes, SAttributes);
+
+               2. Execute procedure Send_Label_Request (Next Hop, FEC,
+                  SAttributes).
+                  Goto LRq.13.
+
+      LRq.11  Has LSR successfully sent a label for FEC to MsgSource?
+              If not, goto LRq.13.  (See Note 4.)
+
+      LRq.12  Perform LSR Label Use procedure.
+
+            For Use Immediate OR
+            For Use If Loop Not Detected
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 98]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+               1. Install label sent to MsgSource and label from Next
+                  Hop (if LSR is not egress) for forwarding/switching
+                  use.
+
+      LRq.13  DONE
+
+   Notes:
+
+      1. In the case where MsgSource is a non-label merging LSR it will
+         send a label request for each upstream LDP peer that has
+         requested a label for FEC from it.  The LSR must be able to
+         distinguish such requests from a non-label merging MsgSource
+         from duplicate label requests.
+
+         The LSR uses the message ID of received Label Request messages
+         to detect duplicate requests.  This means that an LSR (the
+         upstream peer) may not reuse the message ID used for a Label
+         Request until the Label Request transaction has completed.
+
+      2. When an LSR sends a label request to a peer it records that the
+         request has been sent and marks it as outstanding.  As long as
+         the request is marked outstanding the LSR should not send
+         another request for the same label to the peer.  Such a second
+         request would be a duplicate.  The Send_Label_Request procedure
+         described below obeys this rule.
+
+         A duplicate label request is considered a protocol error and
+         should be dropped by the receiving LSR (perhaps with a suitable
+         notification returned to MsgSource).
+
+      3. If LSR is not merge-capable, this test will fail.
+
+      4. The Send_Label procedure may fail due to lack of label
+         resources, in which case the LSR should not perform the Label
+         Use procedure.
+
+A.1.2. Receive Label Mapping
+
+   Summary:
+
+      The response by an LSR to receipt of a FEC label mapping from an
+      LDP peer may involve one or more of the following actions:
+
+      -  Transmission of a label release message for the FEC label to
+         the LDP peer;
+
+      -  Transmission of label mapping messages for the FEC to one or
+         more LDP peers,
+
+
+
+Andersson, et al.           Standards Track                    [Page 99]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      -  Installation of the newly learned label for
+         forwarding/switching use by the LSR.
+
+   Context:
+
+      -  LSR.  The LSR handling the event.
+
+      -  MsgSource.  The LDP peer that sent the message.
+
+      -  FEC.  The FEC specified in the message.
+
+      -  Label.  The label specified in the message.
+
+      -  PrevAdvLabel.  The label for FEC, if any, previously advertised
+         to an upstream peer.
+
+      -  StoredHopCount.  The hop count previously recorded for the FEC.
+
+      -  RAttributes.  Attributes received with the message.  E.g., Hop
+         Count, Path Vector.
+
+      -  SAttributes to be included in Label Mapping message, if any,
+         propagated to upstream peers.
+
+   Algorithm:
+
+      LMp.1   Does the received label mapping match an outstanding
+              label request for FEC previously sent to MsgSource.
+              If not, goto LMp.3.
+
+      LMp.2   Delete record of outstanding FEC label request.
+
+      LMp.3   Execute procedure Check_Received_Attributes (MsgSource,
+              LabelMapping, RAttributes).
+              If No Loop Detected, goto LMp.9.
+
+      LMp.4   Does the LSR have a previously received label mapping for
+              FEC from MsgSource? (See Note 1.)
+              If not, goto LMp.8.  (See Note 2.)
+
+      LMp.5   Does the label previously received from MsgSource match
+              Label (i.e., the label received in the message)?
+              (See Note 3.)
+              If not, goto LMp.8.  (See Note 4.)
+
+      LMp.6   Delete matching label mapping for FEC previously
+              received from MsgSource.
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 100]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      LMp.7   Remove Label from forwarding/switching use.  (See Note 5.)
+              Goto LMp.33.
+
+      LMp.8   Execute procedure Send_Message (MsgSource, Label Release,
+              FEC, Label, Loop Detected Status code).  Goto LMp.33.
+
+      LMp.9   Does LSR have a previously received label mapping for FEC
+              from MsgSource for the LSP in question?  (See Note 6.)
+              If not, goto LMp.11.
+
+      LMp.10  Does the label previously received from MsgSource match
+              Label (i.e., the label received in the message)?
+              (See Note 3.)
+              If not, goto LMp.32.  (See Note 4.)
+
+      LMp.11  Determine the Next Hop for FEC.
+
+      LMp.12  Is MsgSource the Next Hop for FEC?
+              If so, goto LMp.14.
+
+      LMp.13  Perform LSR Label Release procedure:
+
+            For Conservative Label retention:
+
+              1. Goto LMp.32.
+
+            For Liberal Label retention:
+
+              1. Record label mapping for FEC with Label and
+                 RAttributes has been received from MsgSource.
+                 Goto LMp.33.
+
+      LMp.14  Is LSR an ingress for FEC?
+              If not, goto LMp.16.
+
+      LMp.15  Install Label for forwarding/switching use.
+
+      LMp.16  Record label mapping for FEC with Label and RAttributes
+              has been received from MsgSource.
+
+      LMp.17  Iterate through LMp.31 for each Peer.  (See Note 7).
+
+      LMp.18  Has LSR previously sent a label mapping for FEC to Peer
+              for the LSP in question?  (See Note 8.)
+              If so, goto LMp.22.
+
+
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 101]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      LMp.19  Is the Downstream Unsolicited Ordered Control Label
+              Distribution procedure being used by LSR?  If not, goto
+              LMp.28.
+
+      LMp.20  Execute procedure Prepare_Label_Mapping_Attributes(Peer,
+              FEC, RAttributes, SAttributes, IsPropagating,
+              StoredHopCount).
+
+      LMp.21  Execute procedure Send_Message (Peer, Label Mapping, FEC,
+              PrevAdvLabel, SAttributes).
+              Goto LMp.28
+
+      LMp.22  Iterate through LMp.27 for each label mapping for FEC
+              previously sent to Peer.
+
+      LMp.23  Are RAttributes in the received label mapping consistent
+              with those previously sent to Peer?
+              If so, continue iteration from LMp.22 for next label
+              mapping. (See Note 9.)
+
+      LMp.24  Execute procedure Prepare_Label_Mapping_Attributes(Peer,
+              FEC, RAttributes, SAttributes, IsPropagating,
+              StoredHopCount).
+
+      LMp.25  Execute procedure Send_Message (Peer, Label Mapping, FEC,
+              PrevAdvLabel, SAttributes).  (See Note 10.)
+
+      LMp.26  Update record of label mapping for FEC previously sent to
+              Peer to include the new attributes sent.
+
+      LMp.27  End iteration from LMp.22.
+
+      LMp.28  Does LSR have any label requests for FEC from Peer marked
+              as pending?
+              If not, goto LMp.30.
+
+      LMp.29  Perform LSR Label Distribution procedure:
+
+            For Downstream Unsolicited Independent Control OR
+            For Downstream Unsolicited Ordered Control
+
+              1. Execute procedure
+                 Prepare_Label_Mapping_Attributes(Peer, FEC,
+                 RAttributes, SAttributes, IsPropagating,
+                 UnknownHopCount).
+
+
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 102]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+              2. Execute procedure Send_Label (Peer, FEC, SAttributes).
+                 If the procedure fails, continue iteration for
+                 next Peer at LMp.17.
+
+              3. If no pending requests exist for Peer goto LMp.30.
+                 (See Note 11.)
+
+            For Downstream On Demand Independent Control OR
+            For Downstream On Demand Ordered Control
+
+              1. Iterate through Step 5 for each pending label
+                 request for FEC from Peer marked as pending.
+
+              2. Execute procedure
+                 Prepare_Label_Mapping_Attributes(Peer, FEC,
+                 RAttributes, SAttributes, IsPropagating,
+                 UnknownHopCount)
+
+              3. Execute procedure Send_Label (Peer, FEC,
+                 SAttributes).
+                 If the procedure fails, continue iteration for next
+                 Peer at LMp.17.
+
+              4. Delete record of pending request.
+
+              5. End iteration from Step 1.
+
+              6. Goto LMp.30.
+
+      LMp.30  Perform LSR Label Use procedure:
+
+            For Use Immediate OR
+            For Use If Loop Not Detected
+
+              1. Iterate through Step 3 for each label mapping for
+                 FEC previously sent to Peer.
+
+              2. Install label received and label sent to Peer for
+                 forwarding/switching use.
+
+              3. End iteration from Step 1.
+
+              4. Goto LMp.31.
+
+      LMp.31  End iteration from LMp.17.
+              Go to LMp.33.
+
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 103]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      LMp.32  Execute procedure Send_Message (MsgSource, Label Release,
+              FEC, Label).
+
+      LMp.33  DONE.
+
+   Notes:
+
+      1.  If the LSR is merging there should be at most 1 received
+          mapping for the FEC for the LSP in question.  In the non-
+          merging case there could be multiple received mappings for the
+          FEC for the LSP in question.
+
+      2.  If LSR has detected a loop and it has not previously received
+          a label mapping from MsgSource for the FEC, it simply releases
+          the label.
+
+      3.  Does the Label received in the message match any of the 1 or
+          more label mappings identified in the previous step (LMp.4 or
+          LMp.9)?
+
+      4.  An unsolicited mapping with a different label from the same
+          peer would be an attempt to establish multipath label
+          switching, which is not supported in this version of LDP.
+
+      5.  If Label is not in forwarding/switching use, LMp.7 has no
+          effect.
+
+      6.  If the received label mapping message matched an outstanding
+          label request in LMp.1, then (by definition) LSR has not
+          previously received a label mapping for FEC for the LSP in
+          question.  If the LSR is merging upstream labels for the LSP
+          in question, there should be at most 1 received mapping.  In
+          the non-merging case, there could be multiple received label
+          mappings for the same FEC, one for each resulting LSP.
+
+      7.  The LMp.17 iteration includes MsgSource in order to handle the
+          case where LSR is operating in Downstream Unsolicited ordered
+          control mode.  Ordered control prevents LSR from advertising a
+          label for FEC until it has received a label mapping from its
+          next hop (MsgSource) for FEC.
+
+      8.  If LSR is merging the LSP it may have previously sent label
+          mappings for the FEC LSP to one or more peers.  If LSR is not
+          merging, it may have sent a label mapping for the LSP in
+          question to at most one LSR.
+
+
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 104]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      9.  The loop detection Path Vector attribute is considered in this
+          check.  If the received RAttributes include a Path Vector and
+          no Path Vector had been previously sent to the Peer, or if the
+          received Path Vector is inconsistent with the Path Vector
+          previously sent to the Peer, then the attributes are
+          considered to be inconsistent.  Note that an LSR is not
+          required to store a received Path Vector after it propagates
+          the Path Vector in a mapping message.  If an LSR does not
+          store the Path Vector, it has no way to check the consistency
+          of a newly received Path Vector.  This means that whenever
+          such an LSR receives a mapping message carrying a Path Vector
+          it must always propagate the Path Vector.
+
+      10. LMp.22 through LMp.27 deal with a situation that can arise
+          when the LSR is using independent control and it receives a
+          mapping from the downstream peer after it has sent a mapping
+          to an upstream peer.  In this situation the LSR needs to
+          propagate any changed attributes, such as Hop Count, upstream.
+          If Loop Detection is configured on, the propagated attributes
+          must include the Path Vector
+
+      11. An LSR operating in Downstream Unsolicited mode must process
+          any Label Request messages it receives.  If there are pending
+          label requests, fall through into the Downstream on Demand
+          procedures in order to satisfy the pending requests.
+
+A.1.3. Receive Label Abort Request
+
+   Summary:
+
+      When an LSR receives a label abort request message from a peer, it
+      checks whether it has already responded to the label request in
+      question. If it has, it silently ignores the message.  If it has
+      not, it sends the peer a Label Request Aborted Notification.  In
+      addition, if it has a label request outstanding for the LSP in
+      question to a downstream peer, it sends a Label Abort Request to
+      the downstream peer to abort the LSP.
+
+   Context:
+
+      -  LSR.  The LSR handling the event.
+
+      -  MsgSource.  The LDP peer that sent the message.
+
+      -  FEC.  The FEC specified in the message.
+
+      -  RequestMessageID.  The message ID of the label request message
+         to be aborted.
+
+
+
+Andersson, et al.           Standards Track                   [Page 105]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      -  Next Hop.  The next hop for the FEC.
+
+   Algorithm:
+
+      LAbR.1  Does the message match a previously received label request
+              message from MsgSource? (See Note 1.)
+              If not, goto LAbR.12.
+
+      LAbR.2  Has LSR responded to the previously received label
+              request?
+              If so, goto LAbR.12.
+
+      LAbR.3  Execute procedure Send_Message(MsgSource, Notification,
+              Label Request Aborted, TLV), where TLV is the Label
+              Request Message ID TLV received in the label abort
+              request message.
+
+      LAbR.4  Does LSR have a label request message outstanding for
+              FEC?
+              If so, goto LAbR.7
+
+      LAbR.5  Does LSR have a label mapping for FEC?
+              If not, goto LAbR.11
+
+      LAbR.6  Generate Event: Received Label Release Message for FEC
+              from MsgSource.  (See Note 2.)
+              Goto LAbR.11.
+
+      LAbR.7  Is LSR merging the LSP for FEC?
+              If not, goto LAbR.9.
+
+      LAbR.8  Are there upstream peers other than MsgSource that have
+              requested a label for FEC?
+              If so, goto LAbR.11.
+
+      LAbR.9  Execute procedure Send_Message (Next Hop, Label Abort
+              Request, FEC, TLV), where TLV is a Label Request Message
+              ID TLV containing the Message ID used by the LSR in the
+              outstanding Label Request message.
+
+      LAbR.10  Record that a label abort request for FEC is pending.
+
+      LAbR.11  Delete record of label request for FEC from MsgSource.
+
+      LAbR.12  DONE
+
+
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 106]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+   Notes:
+
+      1. LSR uses FEC and the Label Request Message ID TLV carried by
+         the label abort request to locate its record (if any) for the
+         previously received label request from MsgSource.
+
+      2. If LSR has received a label mapping from NextHop, it should
+         behave as if it had advertised a label mapping to MsgSource and
+         MsgSource has released it.
+
+A.1.4. Receive Label Release
+
+   Summary:
+
+      When an LSR receives a label release message for a FEC from a
+      peer, it checks whether other peers hold the released label.  If
+      none do, the LSR removes the label from forwarding/switching use,
+      if it has not already done so, and if the LSR holds a label
+      mapping from the FEC next hop, it releases the label mapping.
+
+   Context:
+
+      -  LSR.  The LSR handling the event.
+
+      -  MsgSource.  The LDP peer that sent the message.
+
+      -  Label.  The label specified in the message.
+
+      -  FEC.  The FEC specified in the message.
+
+   Algorithm:
+
+      LRl.1   Remove MsgSource from record of peers that hold Label for
+              FEC.  (See Note 1.)
+
+      LRl.2   Does message match an outstanding label withdraw for FEC
+              previously sent to MsgSource?
+              If not, goto LRl.4
+
+      LRl.3   Delete record of outstanding label withdraw for FEC
+              previously sent to MsgSource.
+
+      LRl.4   Is LSR merging labels for this FEC?
+              If not, goto LRl.6.  (See Note 2.)
+
+      LRl.5   Has LSR previously advertised a label for this FEC to
+              other peers?
+              If so, goto LRl.10.
+
+
+
+Andersson, et al.           Standards Track                   [Page 107]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      LRl.6   Is LSR egress for the FEC?
+              If so, goto LRl.10
+
+      LRl.7   Is there a Next Hop for FEC? AND
+              Does LSR have a previously received label mapping for FEC
+              from Next Hop?
+              If not, goto LRl.10.
+
+      LRl.8   Is LSR configured to propagate releases?
+              If not, goto LRl.10.  (See Note 3.)
+
+      LRl.9   Execute procedure Send_Message (Next Hop, Label Release,
+              FEC, Label from Next Hop).
+
+      LRl.10  Remove Label from forwarding/switching use for traffic
+              from MsgSource.
+
+      LRl.11  Do any peers still hold Label for FEC?
+              If so, goto LRl.13.
+
+      LRl.12  Free the Label.
+
+      LRl.13  DONE.
+
+   Notes:
+
+      1. If LSR is using Downstream Unsolicited label distribution, it
+         should not re-advertise a label mapping for FEC to MsgSource
+         until MsgSource requests it.
+
+      2. LRl.4 through LRl.8 deal with determining whether where the LSR
+         should propagate the label release to a downstream peer
+         (LRl.9).
+
+      3. If LRl.8 is reached, no upstream LSR holds a label for the FEC,
+         and the LSR holds a label for the FEC from the FEC Next Hop.
+         The LSR could propagate the Label Release to the Next Hop.  By
+         propagating the Label Release the LSR releases a potentially
+         scarce label resource.  In doing so, it also increases the
+         latency for re-establishing the LSP should MsgSource or some
+         other upstream LSR send it a new Label Request for FEC.
+
+         Whether or not to propagate the release is not a protocol
+         issue.  Label distribution will operate properly whether or not
+         the release is propagated.  The decision to propagate or not
+         should take into consideration factors such as: whether labels
+         are a scarce resource in the operating environment; the
+         importance of keeping LSP setup latency low by keeping the
+
+
+
+Andersson, et al.           Standards Track                   [Page 108]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+         amount of signaling required small; whether LSP setup is
+         ingress-controlled or egress-controlled in the operating
+         environment.
+
+A.1.5. Receive Label Withdraw
+
+   Summary:
+
+      When an LSR receives a label withdraw message for a FEC from an
+      LDP peer, it responds with a label release message and it removes
+      the label from any forwarding/switching use.  If ordered control
+      is in use, the LSR sends a label withdraw message to each LDP peer
+      to which it had previously sent a label mapping for the FEC.  If
+      the LSR is using Downstream on Demand label advertisement with
+      independent control, it then acts as if it had just recognized the
+      FEC.
+
+   Context:
+
+      -  LSR.  The LSR handling the event.
+
+      -  MsgSource.  The LDP peer that sent the message.
+
+      -  Label.  The label specified in the message.
+
+      -  FEC.  The FEC specified in the message.
+
+   Algorithm:
+
+      LWd.1   Remove Label from forwarding/switching use.  (See Note 1.)
+
+      LWd.2   Execute procedure Send_Message (MsgSource, Label Release,
+              FEC, Label)
+
+      LWd.3   Has LSR previously received and retained a matching label
+              mapping for FEC from MsgSource?
+              If not, goto LWd.13.
+
+      LWd.4   Delete matching label mapping for FEC previously received
+              from MsgSource.
+
+      LWd.5   Is LSR using ordered control?
+              If so, goto LWd.8.
+
+      LWd.6   Is MsgSource using Downstream On Demand label
+              advertisement?
+              If not, goto LWd.13.
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 109]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      LWd.7   Generate Event: Recognize New FEC for FEC.
+              Goto LWd.13.  (See Note 2.)
+
+      LWd.8   Iterate through LWd.12 for each Peer, other than
+              MsgSource.
+
+      LWd.9   Has LSR previously sent a label mapping for FEC to Peer?
+              If not, continue iteration for next Peer at LWd.8.
+
+      LWd.10  Does the label previously sent to Peer "map" to the
+              withdrawn Label?
+              If not, continue iteration for next Peer at LWd.8.
+              (See Note 3.)
+
+      LWd.11  Execute procedure Send_Label_Withdraw (Peer, FEC, Label
+              previously sent to Peer).
+
+      LWd.12  End iteration from LWd.8.
+
+      LWd.13  DONE
+
+   Notes:
+
+      1. If Label is not in forwarding/switching use, LWd.1 has no
+         effect.
+
+      2. LWd.7 handles the case where the LSR is using Downstream On
+         Demand label distribution with independent control.  In this
+         situation the LSR should send a label request to the FEC next
+         hop as if it had just recognized the FEC.
+
+      3. LWd.10 handles both label merging (one or more incoming labels
+         map to the same outgoing label) and no label merging (one label
+         maps to the outgoing label) cases.
+
+A.1.6. Recognize New FEC
+
+   Summary:
+
+      The response by an LSR to learning a new FEC via the routing table
+      may involve one or more of the following actions:
+
+      -  Transmission of label mappings for the FEC to one or more LDP
+         peers;
+
+      -  Transmission of a label request for the FEC to the FEC next
+         hop;
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 110]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      -  Any of the actions that can occur when the LSR receives a label
+         mapping for the FEC from the FEC next hop.
+
+   Context:
+
+      -  LSR.  The LSR handling the event.
+
+      -  FEC. The newly recognized FEC.
+
+      -  Next Hop.  The next hop for the FEC.
+
+      -  InitAttributes.  Attributes to be associated with the new FEC.
+         (See Note 1.)
+
+      -  SAttributes.  Attributes to be included in Label Mapping or
+         Label Request messages, if any, sent to peers.
+
+      -  StoredHopCount.  Hop count associated with FEC label mapping,
+         if any, previously received from Next Hop.
+
+   Algorithm:
+
+      FEC.1   Perform LSR Label Distribution procedure:
+
+            For Downstream Unsolicited Independent Control
+
+               1. Iterate through 5 for each Peer.
+
+               2. Has LSR previously received and retained a label
+                  mapping for FEC from Next Hop?
+                  If so, set Propagating to IsPropagating.
+                  If not, set Propagating to NotPropagating.
+
+               3. Execute procedure Prepare_Label_Mapping_Attributes
+                  (Peer, FEC, InitAttributes, SAttributes, Propagating,
+                  Unknown hop count(0)).
+
+               4. Execute procedure Send_Label (Peer, FEC, SAttributes)
+
+               5. End iteration from 1.
+                  Goto FEC.2.
+
+            For Downstream Unsolicited Ordered Control
+
+               1. Iterate through 5 for each Peer.
+
+
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 111]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+               2. Is LSR egress for the FEC? OR
+                  Has LSR previously received and retained a label
+                  mapping for FEC from Next Hop?
+                  If not, continue iteration for next Peer.
+
+               3. Execute procedure Prepare_Label_Mapping_Attributes
+                  (Peer, FEC, InitAttributes, SAttributes, Propagating,
+                  StoredHopCount).
+
+               4. Execute procedure Send_Label (Peer, FEC, SAttributes)
+
+               5. End iteration from 1.
+                  Goto FEC.2.
+
+            For Downstream On Demand Independent Control OR
+            For Downstream On Demand Ordered Control
+
+               1. Goto FEC.2.  (See Note 2.)
+
+      FEC.2   Has LSR previously received and retained a label
+              mapping for FEC from Next Hop?
+              If so, goto FEC.5
+
+      FEC.3   Is Next Hop an LDP peer?
+              If not, Goto FEC.6
+
+      FEC.4   Perform LSR Label Request procedure:
+
+            For Request Never
+
+              1. Goto FEC.6
+
+            For Request When Needed OR
+            For Request On Request
+
+              1. Execute procedure
+                 Prepare_Label_Request_Attributes
+                 (Next Hop, FEC, InitAttributes, SAttributes);
+
+              2. Execute procedure Send_Label_Request (Next
+                 Hop, FEC, SAttributes).
+                 Goto FEC.6.
+
+      FEC.5   Generate Event: Received Label Mapping from Next Hop.
+              (See Note 3.)
+
+      FEC.6   DONE.
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 112]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+   Notes:
+
+      1. An example of an attribute that might be part of InitAttributes
+         is one which specifies desired LSP characteristics, such as
+         class of service (CoS).  (Note that while the current version
+         of LDP does not specify a CoS attribute, LDP extensions may.)
+
+         The means by which FEC InitAttributes, if any, are specified is
+         beyond the scope of LDP.  Note that the InitAttributes will not
+         include a known Hop Count or a Path Vector.
+
+      2. An LSR using Downstream On Demand label distribution would send
+         a label only if it had a previously received label request
+         marked as pending.  The LSR would have no such pending requests
+         because it responds to any label request for an unknown FEC by
+         sending the requesting LSR a No Route notification and
+         discarding the label request; see LRq.3
+
+      3. If the LSR has a label for the FEC from the Next Hop, it should
+         behave as if it had just received the label from the Next Hop.
+         This occurs in the case of Liberal label retention mode.
+
+A.1.7. Detect Change in FEC Next Hop
+
+   Summary:
+
+      The response by an LSR to a change in the next hop for a FEC may
+      involve one or more of the following actions:
+
+      -  Removal of the label from the FEC's old next hop from
+         forwarding/switching use;
+
+      -  Transmission of label mapping messages for the FEC to one or
+         more LDP peers;
+
+      -  Transmission of a label request to the FEC's new next hop;
+
+      -  Any of the actions that can occur when the LSR receives a label
+         mapping from the FEC's new next hop.
+
+   Context:
+
+      -  LSR.  The LSR handling the event.
+
+      -  FEC.  The FEC whose next hop changed.
+
+      -  New Next Hop.  The current next hop for the FEC.
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 113]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      -  Old Next Hop.  The previous next hop for the FEC.
+
+      -  OldLabel.  Label, if any, previously received from Old Next
+         Hop.
+
+      -  CurAttributes.  The attributes, if any, currently associated
+         with the FEC.
+
+      -  SAttributes.  Attributes to be included in Label Label Request
+         message, if any, sent to New Next Hop.
+
+   Algorithm:
+
+      NH.1   Has LSR previously received and retained a label mapping
+             for FEC from Old Next Hop?
+             If not, goto NH.6.
+
+      NH.2   Remove label from forwarding/switching use.  (See Note 1.)
+
+      NH.3   Is LSR using Liberal label retention?
+             If so, goto NH.6.
+
+      NH.4   Execute procedure Send_Message (Old Next Hop, Label
+             Release, OldLabel).
+
+      NH.5   Delete label mapping for FEC previously received from Old
+             Next Hop.
+
+      NH.6   Does LSR have a label request pending with Old Next Hop?
+             If not, goto NH.10.
+
+      NH.7   Is LSR using Conservative label retention?
+             If not, goto NH.10.
+
+      NH.8   Execute procedure Send_Message (Old Next Hop, Label Abort
+             Request, FEC, TLV), where TLV is a Label Request Message
+             ID TLV that carries the message ID of the pending label
+             request.
+
+      NH.9   Record a label abort request is pending for FEC with Old
+             Next Hop.
+
+      NH.10  Is there a New Next Hop for the FEC?
+             If not, goto NH.16.
+
+      NH.11  Has LSR previously received and retained a label mapping
+             for FEC from New Next Hop?
+             If not, goto NH.13.
+
+
+
+Andersson, et al.           Standards Track                   [Page 114]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      NH.12  Generate Event: Received Label Mapping from New Next Hop.
+             Goto NH.20.  (See Note 2.)
+
+      NH.13  Is LSR using Downstream on Demand advertisement? OR
+             Is Next Hop using Downstream on Demand advertisement? OR
+             Is LSR using Conservative label retention? (See Note 3.)
+             If so, goto NH.14.
+             If not, goto NH.20.
+
+      NH.14  Execute procedure Prepare_Label_Request_Attributes (Next
+             Hop, FEC, CurAttributes, SAttributes)
+
+      NH.15  Execute procedure Send_Label_Request (New Next Hop, FEC,
+             SAttributes).  (See Note 4.)
+             Goto NH.20.
+
+      NH.16  Iterate through NH.19 for each Peer.
+
+      NH.17  Has LSR previously sent a label mapping for FEC to Peer?
+             If not, continue iteration for next Peer at NH.16.
+
+      NH.18  Execute procedure Send_Label_Withdraw (Peer, FEC, Label
+             previously sent to Peer).
+
+      NH.19  End iteration from NH.16.
+
+      NH.20  DONE.
+
+   Notes:
+
+      1. If Label is not in forwarding/switching use, NH.2 has no
+         effect.
+
+      2. If the LSR has a label for the FEC from the New Next Hop, it
+         should behave as if it had just received the label from the New
+         Next Hop.
+
+      3. The purpose of the check on label retention mode is to avoid a
+         race with steps LMp.12-LMp.13 of the procedure for handling a
+         Label Mapping message where the LSR operating in Conservative
+         Label retention mode may have released a label mapping received
+         from the New Next Hop before it detected the FEC next hop had
+         changed.
+
+      4. Regardless of the Label Request procedure in use by the LSR, it
+         must send a label request if the conditions in NH.8 hold.
+         Therefore it executes the Send_Label_Request procedure directly
+         rather than perform LSR Label Request procedure.
+
+
+
+Andersson, et al.           Standards Track                   [Page 115]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+A.1.8. Receive Notification / Label Request Aborted
+
+   Summary:
+
+      When an LSR receives a Label Request Aborted notification from an
+      LDP peer it records that the corresponding label request
+      transaction, if any, has completed.
+
+   Context:
+
+      -  LSR.  The LSR handling the event.
+
+      -  FEC.  The FEC for which a label was requested.
+
+      -  RequestMessageID.  The message ID of the label request message
+         to be aborted.
+
+      -  MsgSource.  The LDP peer that sent the Notification message.
+
+   Algorithm:
+
+      LRqA.1  Does the notification correspond to an outstanding label
+              request abort for FEC? (See Note 1).
+              If not, goto LRqA.3.
+
+      LRqA.2  Record that the label request for FEC has been aborted.
+
+      LRqA.3  DONE
+
+   Notes:
+
+      1. The LSR uses the FEC and RequestMessageID to locate its record,
+         if any, of the outstanding label request abort.
+
+A.1.9. Receive Notification / No Label Resources
+
+   Summary:
+
+      When an LSR receives a No Label Resources notification from an LDP
+      peer, it stops sending label request messages to the peer until it
+      receives a Label Resources Available Notification from the peer.
+
+   Context:
+
+      -  LSR.  The LSR handling the event.
+
+      -  FEC.  The FEC for which a label was requested.
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 116]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      -  MsgSource.  The LDP peer that sent the Notification message.
+
+   Algorithm:
+
+      NoRes.1 Delete record of outstanding label request for FEC sent
+              to MsgSource.
+
+      NoRes.2 Record label mapping for FEC from MsgSource is needed but
+              that no label resources are available.
+
+      NoRes.3 Set status record indicating it is not OK to send label
+              requests to MsgSource.
+
+      NoRes.4 DONE.
+
+A.1.10. Receive Notification / No Route
+
+   Summary:
+
+      When an LSR receives a No Route notification from an LDP peer in
+      response to a Label Request message, the Label No Route procedure
+      in use dictates its response. The LSR either will take no further
+      action, or it will defer the label request by starting a timer and
+      send another Label Request message to the peer when the timer
+      later expires.
+
+   Context:
+
+      -  LSR.  The LSR handling the event.
+
+      -  FEC.  The FEC for which a label was requested.
+
+      -  Attributes.  The attributes associated with the label request.
+
+      -  MsgSource.  The LDP peer that sent the Notification message.
+
+   Algorithm:
+
+      NoNH.1  Delete record of outstanding label request for FEC sent
+              to MsgSource.
+
+      NoNH.2  Perform LSR Label No Route procedure.
+
+            For Request No Retry
+
+              1. Goto NoNH.3.
+
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 117]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+            For Request Retry
+
+              1. Record deferred label request for FEC and Attributes
+                 to be sent to MsgSource.
+
+              2. Start timeout.  Goto NoNH.3.
+
+      NoNH.3  DONE.
+
+A.1.11. Receive Notification / Loop Detected
+
+   Summary:
+
+      When an LSR receives a Loop Detected Status Code from an LDP peer
+      in response to a Label Request message or a Label Mapping message,
+      it behaves as if it had received a No Route notification.
+
+   Context:
+
+      See "Receive Notification / No Route".
+
+   Algorithm:
+
+      See "Receive Notification / No Route"
+
+   Notes:
+
+      1. When the Loop Detected notification is in response to a Label
+         Request message, it arrives in a Status Code TLV in a
+         Notification message.  When it is in response to a Label
+         Mapping message, it arrives in a Status Code TLV in a Label
+         Release message.
+
+A.1.12. Receive Notification / Label Resources Available
+
+   Summary:
+
+      When an LSR receives a Label Resources Available notification from
+      an LDP peer, it resumes sending label requests to the peer.
+
+   Context:
+
+      -  LSR.  The LSR handling the event.
+
+      -  MsgSource.  The LDP peer that sent the Notification message.
+
+      -  SAttributes.  Attributes stored with postponed Label Request
+         message.
+
+
+
+Andersson, et al.           Standards Track                   [Page 118]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+   Algorithm:
+
+      Res.1   Set status record indicating it is OK to send label
+              requests to MsgSource.
+
+      Res.2   Iterate through Res.6 for each record of a FEC label
+              mapping needed from MsgSource for which no label
+              resources are available.
+
+      Res.3   Is MsgSource the next hop for FEC?
+              If not, goto Res.5.
+
+      Res.4   Execute procedure Send_Label_Request (MsgSource, FEC,
+              SAttributes).  If the procedure fails, terminate
+              iteration.
+
+      Res.5   Delete record that no resources are available for a label
+              mapping for FEC needed from MsgSource.
+
+      Res.6   End iteration from Res.2
+
+      Res.7   DONE.
+
+A.1.13. Detect local label resources have become available
+
+   Summary:
+
+      After an LSR has sent a No Label Resources notification to an LDP
+      peer, when label resources later become available it sends a Label
+      Resources Available notification to each such peer.
+
+   Context:
+
+      -  LSR.  The LSR handling the event.
+
+      -  Attributes.  Attributes stored with postponed Label Mapping
+         message.
+
+   Algorithm:
+
+      ResA.1  Iterate through ResA.4 for each Peer to which LSR has
+              previously sent a No Label Resources notification.
+
+      ResA.2  Execute procedure Send_Notification (Peer, Label
+              Resources Available)
+
+      ResA.3  Delete record that No Label Resources notification was
+              previously sent to Peer.
+
+
+
+Andersson, et al.           Standards Track                   [Page 119]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      ResA.4  End iteration from ResA.1
+
+      ResA.5  Iterate through ResA.8 for each record of a label mapping
+              needed for FEC for Peer but no-label-resources.  (See Note
+              1.)
+
+      ResA.6  Execute procedure Send_Label (Peer, FEC, Attributes).  If
+              the procedure fails, terminate iteration.
+
+      ResA.7  Clear record of FEC label mapping needed for peer but no-
+              label-resources.
+
+      ResA.8  End iteration from ResA.5
+
+      ResA.9  DONE.
+
+   Notes:
+
+      1. Iteration ResA.5 through ResA.8 handles the situation where the
+         LSR is using Downstream Unsolicited label distribution and was
+         previously unable to allocate a label for a FEC.
+
+A.1.14. LSR decides to no longer label switch a FEC
+
+   Summary:
+
+      An LSR may unilaterally decide to no longer label switch a FEC for
+      an LDP peer.  An LSR that does so must send a label withdraw message
+      for the FEC to the peer.
+
+   Context:
+
+      -  Peer.  The peer.
+
+      -  FEC.  The FEC.
+
+      -  PrevAdvLabel.  The label for FEC previously advertised to Peer.
+
+   Algorithm:
+
+      NoLS.1  Execute procedure Send_Label_Withdraw (Peer, FEC,
+              PrevAdvLabel).  (See Note 1.)
+
+      NoLS.2  DONE.
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 120]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+   Notes:
+
+      1. The LSR may remove the label from forwarding/switching use as
+         part of this event or as part of processing the label release
+         from the peer in response to the label withdraw.
+
+A.1.15. Timeout of deferred label request
+
+   Summary:
+
+      Label requests are deferred in response to No Route and Loop
+      Detected notifications.  When a deferred FEC label request for a
+      peer times out, the LSR sends the label request.
+
+   Context:
+
+      -  LSR.  The LSR handling the event.
+
+      -  FEC.  The FEC associated with the timeout event.
+
+      -  Peer.  The LDP peer associated with the timeout event.
+
+      -  Attributes.  Attributes stored with deferred Label Request
+         message.
+
+   Algorithm:
+
+      TO.1    Retrieve the record of the deferred label request.
+
+      TO.2    Is Peer the next hop for FEC?
+              If not, goto TO.4.
+
+      TO.3    Execute procedure Send_Label_Request (Peer, FEC).
+
+      TO.4    DONE.
+
+A.2. Common Label Distribution Procedures
+
+      This section specifies utility procedures used by the algorithms
+      that handle label distribution events.
+
+A.2.1. Send_Label
+
+   Summary:
+
+      The Send_Label procedure allocates a label for a FEC for an LDP
+      peer, if possible, and sends a label mapping for the FEC to the
+      peer.  If the LSR is unable to allocate the label and if it has a
+
+
+
+Andersson, et al.           Standards Track                   [Page 121]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      pending label request from the peer, it sends the LDP peer a No
+      Label Resources notification.
+
+   Parameters:
+
+      -  Peer.  The LDP peer to which the label mapping is to be sent.
+
+      -  FEC.  The FEC for which a label mapping is to be sent.
+
+      -  Attributes.  The attributes to be included with the label
+         mapping.
+
+   Additional Context:
+
+      -  LSR.  The LSR executing the procedure.
+
+      -  Label.  The label allocated and sent to Peer.
+
+   Algorithm:
+
+      SL.1   Does LSR have a label to allocate?
+             If not, goto SL.9.
+
+      SL.2   Allocate Label and bind it to the FEC.
+
+      SL.3   Install Label for forwarding/switching use.
+
+      SL.4   Execute procedure Send_Message (Peer, Label Mapping, FEC,
+             Label, Attributes).
+
+      SL.5   Record label mapping for FEC with Label and Attributes has
+             been sent to Peer.
+
+      SL.6   Does LSR have a record of a FEC label request from Peer
+             marked as pending?
+             If not, goto SL.8.
+
+      SL.7   Delete record of pending label request for FEC from Peer.
+
+      SL.8   Return success.
+
+      SL.9   Does LSR have a label request for FEC from Peer marked as
+             pending?
+             If not, goto SL.13.
+
+      SL.10  Execute procedure Send_Notification (Peer, No Label
+             Resources).
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 122]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      SL.11  Delete record of pending label request for FEC from Peer.
+
+      SL.12  Record No Label Resources notification has been sent to
+             Peer.
+             Goto SL.14.
+
+      SL.13  Record label mapping needed for FEC and Attributes for
+             Peer, but no-label-resources.  (See Note 1.)
+
+      SL.14  Return failure.
+
+   Notes:
+
+      1. SL.13 handles the case of Downstream Unsolicited label
+         distribution when the LSR is unable to allocate a label for a
+         FEC to send to a Peer.
+
+A.2.2. Send_Label_Request
+
+   Summary:
+
+      An LSR uses the Send_Label_Request procedure to send a request for
+      a label for a FEC to an LDP peer if currently permitted to do so.
+
+   Parameters:
+
+      -  Peer.  The LDP peer to which the label request is to be sent.
+
+      -  FEC.  The FEC for which a label request is to be sent.
+
+      -  Attributes.  Attributes to be included in the label request.
+         E.g., Hop Count, Path Vector.
+
+   Additional Context:
+
+      -  LSR.  The LSR executing the procedure.
+
+   Algorithm:
+
+      SLRq.1  Has a label request for FEC previously been sent to Peer
+              and is it marked as outstanding?
+              If so, Return success.  (See Note 1.)
+
+      SLRq.2  Is status record indicating it is OK to send label
+              requests to Peer set?
+              If not, goto SLRq.6
+
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 123]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      SLRq.3  Execute procedure Send_Message (Peer, Label Request, FEC,
+              Attributes).
+
+      SLRq.4  Record label request for FEC has been sent to Peer and
+              mark it as outstanding.
+
+      SLRq.5  Return success.
+
+      SLRq.6  Postpone the label request by recording label mapping for
+              FEC and Attributes from Peer is needed but that no label
+              resources are available.
+
+      SLRq.7  Return failure.
+
+   Notes:
+
+      1. If the LSR is a non-merging LSR it must distinguish between
+         attempts to send label requests for a FEC triggered by
+         different upstream LDP peers from duplicate requests.  This
+         procedure will not send a duplicate label request.
+
+A.2.3. Send_Label_Withdraw
+
+   Summary:
+
+      An LSR uses the Send_Label_Withdraw procedure to withdraw a label
+      for a FEC from an LDP peer.  To do this the LSR sends a Label
+      Withdraw message to the peer.
+
+   Parameters:
+
+      -  Peer.  The LDP peer to which the label withdraw is to be sent.
+
+      -  FEC.  The FEC for which a label is being withdrawn.
+
+      -  Label.  The label being withdrawn
+
+   Additional Context:
+
+      -  LSR.  The LSR executing the procedure.
+
+   Algorithm:
+
+      SWd.1  Execute procedure Send_Message (Peer, Label Withdraw, FEC,
+             Label)
+
+      SWd.2  Record label withdraw for FEC has been sent to Peer and
+             mark it as outstanding.
+
+
+
+Andersson, et al.           Standards Track                   [Page 124]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+A.2.4. Send_Notification
+
+   Summary:
+
+      An LSR uses the Send_Notification procedure to send an LDP peer a
+      notification message.
+
+   Parameters:
+
+      -  Peer.  The LDP peer to which the Notification message is to be
+         sent.
+
+      -  Status.  Status code to be included in the Notification
+         message.
+
+   Additional Context:
+
+      None.
+
+   Algorithm:
+
+      SNt.1  Execute procedure Send_Message (Peer, Notification, Status)
+
+A.2.5. Send_Message
+
+   Summary:
+
+      An LSR uses the Send_Message procedure to send an LDP peer an LDP
+      message.
+
+   Parameters:
+
+      -  Peer.  The LDP peer to which the message is to be sent.
+
+      -  Message Type.  The type of message to be sent.
+
+      -  Additional message contents . . .  .
+
+   Additional Context:
+
+      None.
+
+   Algorithm:
+
+      This procedure is the means by which an LSR sends an LDP message
+      of the specified type to the specified LDP peer.
+
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 125]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+A.2.6. Check_Received_Attributes
+
+   Summary:
+
+      Check the attributes received in a Label Mapping or Label Request
+      message.  If the attributes include a Hop Count or Path Vector,
+      perform a loop detection check.  If a loop is detected, cause a
+      Loop Detected Notification message to be sent to MsgSource.
+
+   Parameters:
+
+      -  MsgSource.  The LDP peer that sent the message.
+
+      -  MsgType.  The type of message received.
+
+      -  RAttributes.  The attributes in the message.
+
+   Additional Context:
+
+      -  LSR Id.  The unique LSR Id of this LSR.
+
+      -  Hop Count.  The Hop Count, if any, in the received attributes.
+
+      -  Path Vector.  The Path Vector, if any in the received
+         attributes.
+
+   Algorithm:
+
+      CRa.1   Do RAttributes include Hop Count?
+              If not, goto CRa.5.
+
+      CRa.2   Does Hop Count exceed Max allowable hop count?
+              If so, goto CRa.6.
+
+      CRa.3   Do RAttributes include Path Vector?
+              If not, goto CRa.5.
+
+      CRa.4   Does Path Vector Include LSR Id? OR
+              Does length of Path Vector exceed Max allowable length?
+              If so, goto CRa.6
+
+      CRa.5   Return No Loop Detected.
+
+      CRa.6   Is MsgType LabelMapping?
+              If so, goto CRa.8.  (See Note 1.)
+
+      CRa.7   Execute procedure Send_Notification (MsgSource, Loop
+              Detected)
+
+
+
+Andersson, et al.           Standards Track                   [Page 126]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      CRa.8   Return Loop Detected.
+
+      CRa.9   DONE
+
+   Notes:
+
+      1. When the attributes being checked were received in a Label
+         Mapping message, the LSR sends the Loop Detected notification
+         in a Status Code TLV in a Label Release message.  (See Section
+         "Receive Label Mapping").
+
+A.2.7. Prepare_Label_Request_Attributes
+
+   Summary:
+
+      This procedure is used whenever a Label Request is to be sent to a
+      Peer to compute the Hop Count and Path Vector, if any, to include
+      in the message.
+
+   Parameters:
+
+      -  Peer.  The LDP peer to which the message is to be sent.
+
+      -  FEC.  The FEC for which a label request is to be sent.
+
+      -  RAttributes.  The attributes this LSR associates with the LSP
+         for FEC.
+
+      -  SAttributes.  The attributes to be included in the Label
+         Request message.
+
+   Additional Context:
+
+      -  LSR Id.  The unique LSR Id of this LSR.
+
+   Algorithm:
+
+      PRqA.1  Is Hop Count required for this Peer (see Note 1.) ? OR
+              Do RAttributes include a Hop Count? OR
+              Is Loop Detection configured on LSR?
+              If not, goto PRqA.14.
+
+      PRqA.2  Is LSR ingress for FEC?
+              If not, goto PRqA.6.
+
+      PRqA.3  Include Hop Count of 1 in SAttributes.
+
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 127]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      PRqA.4  Is Loop Detection configured on LSR?
+              If not, goto PRqA.14.
+
+      PRqA.5  Is LSR merge-capable?
+              If so, goto PRqA.14.
+              If not, goto PRqA.13.
+
+      PRqA.6  Do RAttributes include a Hop Count?
+              If not, goto PRqA.8.
+
+      PRqA.7  Increment RAttributes Hop Count and copy the resulting Hop
+              Count to SAttributes.  (See Note 2.)
+              Goto PRqA.9.
+
+      PRqA.8  Include Hop Count of unknown (0) in SAttributes.
+
+      PRqA.9  Is Loop Detection configured on LSR?
+              If not, goto PRqA.14.
+
+      PRqA.10 Do RAttributes have a Path Vector?
+              If so, goto PRqA.12.
+
+      PRqA.11 Is LSR merge-capable?
+              If so, goto PRqA.14.
+              If not, goto PRqA.13.
+
+      PRqA.12 Add LSR Id to beginning of Path Vector from RAttributes
+              and copy the resulting Path Vector into SAttributes.
+              Goto PRqA.14.
+
+      PRqA.13 Include Path Vector of length 1 containing LSR Id in
+              SAttributes.
+
+      PRqA.14 DONE.
+
+   Notes:
+
+      1. The link with Peer may require that Hop Count be included in
+         Label Request messages; for example, see [RFC3035] and
+         [RFC3034].
+
+      2. For hop count arithmetic, unknown + 1 = unknown.
+
+
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 128]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+A.2.8.  Prepare_Label_Mapping_Attributes
+
+   Summary:
+
+      This procedure is used whenever a Label Mapping is to be sent to a
+      Peer to compute the Hop Count and Path Vector, if any, to include
+      in the message.
+
+   Parameters:
+
+      -  Peer.  The LDP peer to which the message is to be sent.
+
+      -  FEC.  The FEC for which a label request is to be sent.
+
+      -  RAttributes.  The attributes this LSR associates with the LSP
+         for FEC.
+
+      -  SAttributes.  The attributes to be included in the Label
+         Mapping message.
+
+      -  IsPropagating.  The LSR is sending the Label Mapping message to
+         propagate one received from the FEC next hop.
+
+      -  PrevHopCount.  The Hop Count, if any, this LSR associates with
+         the LSP for the FEC.
+
+   Additional Context:
+
+      -  LSR Id.  The unique LSR Id of this LSR.
+
+   Algorithm:
+
+      PMpA.1  Is Hop Count required for this Peer (see Note 1.) ? OR
+              Do RAttributes include a Hop Count? OR
+              Is Loop Detection configured on LSR?
+              If not, goto PMpA.21.
+
+      PMpA.2  Is LSR egress for FEC?
+              If not, goto PMpA.4.
+
+      PMpA.3  Include Hop Count of 1 in SAttributes.  Goto PMpA.21.
+
+      PMpA.4  Do RAttributes have a Hop Count?
+              If not, goto PMpA.8.
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 129]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      PMpA.5  Is LSR member of edge set for an LSR domain whose LSRs do
+              not perform TTL decrement AND
+              Is Peer in that domain (See Note 2.).
+              If not, goto PMpA.7.
+
+      PMpA.6  Include Hop Count of 1 in SAttributes.  Goto PMpA.9.
+
+      PMpA.7  Increment RAttributes Hop Count and copy the resulting
+              Hop Count to SAttributes.  See Note 2.  Goto PMpA.9.
+
+      PMpA.8  Include Hop Count of unknown (0) in SAttributes.
+
+      PMpA.9  Is Loop Detection configured on LSR?
+              If not, goto PMpA.21.
+
+      PMpA.10 Do RAttributes have a Path Vector?
+              If so, goto PMpA.19.
+
+      PMpA.11 Is LSR propagating a received Label Mapping?
+              If not, goto PMpA.20.
+
+      PMpA.12 Does LSR support merging?
+              If not, goto PMpA.14.
+
+      PMpA.13 Has LSR previously sent a Label Mapping for FEC to Peer?
+              If not, goto PMpA.20.
+
+      PMpA.14 Do RAttributes include a Hop Count?
+              If not, goto PMpA.21.
+
+      PMpA.15 Is Hop Count in Rattributes unknown(0)?
+              If so, goto PMpA.20.
+
+      PMpA.16 Has LSR previously sent a Label Mapping for FEC to Peer?
+              If not goto PMpA.21.
+
+      PMpA.17 Is Hop Count in RAttributes different from PrevHopCount ?
+              If not goto PMpA.21.
+
+      PMpA.18 Is the Hop Count in RAttributes > PrevHopCount? OR
+              Is PrevHopCount unknown(0)
+              If not, goto PMpA.21.
+
+      PMpA.19 Add LSR Id to beginning of Path Vector from RAttributes
+              and copy the resulting Path Vector into SAttributes.
+              Goto PMpA.21.
+
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 130]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+      PMpA.20 Include Path Vector of length 1 containing LSR Id in
+              SAttributes.
+
+      PMpA.21 DONE.
+
+   Notes:
+
+      1. The link with Peer may require that Hop Count be included in
+         Label Mapping messages; for example, see [RFC3035] and
+         [RFC3034].
+
+      2. If the LSR is at the edge of a cloud of LSRs that do not
+         perform TTL-decrement and it is propagating the Label Mapping
+         message upstream into the cloud, it sets the Hop Count to 1 so
+         that Hop Count across the cloud is calculated properly.  This
+         ensures proper TTL management for packets forwarded across the
+         part of the LSP that passes through the cloud.
+
+      3. For hop count arithmetic, unknown + 1 = unknown.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 131]
+
+RFC 3036                   LDP Specification                January 2001
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 132]
+
-- 
cgit v1.2.3