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/rfc5036.txt | 7563 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 7563 insertions(+)
 create mode 100644 doc/rfc/rfc5036.txt

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

diff --git a/doc/rfc/rfc5036.txt b/doc/rfc/rfc5036.txt
new file mode 100644
index 0000000..3740911
--- /dev/null
+++ b/doc/rfc/rfc5036.txt
@@ -0,0 +1,7563 @@
+
+
+
+
+
+
+Network Working Group                                  L. Andersson, Ed.
+Request for Comments: 5036                                      Acreo AB
+Obsoletes: 3036                                            I. Minei, Ed.
+Category: Standards Track                               Juniper Networks
+                                                          B. Thomas, Ed.
+                                                     Cisco Systems, Inc.
+                                                            October 2007
+
+
+                           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.
+
+Abstract
+
+   The architecture for Multiprotocol 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.
+
+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 .....................................9
+           2.2.3. LDP Sessions .......................................10
+           2.2.4. LDP Transport ......................................10
+
+
+
+Andersson, et al.           Standards Track                     [Page 1]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      2.3. LDP Sessions between Non-Directly Connected LSRs ..........10
+      2.4. LDP Discovery .............................................11
+           2.4.1. Basic Discovery Mechanism ..........................11
+           2.4.2. Extended Discovery Mechanism .......................11
+      2.5. Establishing and Maintaining LDP Sessions .................12
+           2.5.1. LDP Session Establishment ..........................12
+           2.5.2. Transport Connection Establishment .................12
+           2.5.3. Session Initialization .............................14
+           2.5.4. Initialization State Machine .......................16
+           2.5.5. Maintaining Hello Adjacencies ......................19
+           2.5.6. Maintaining LDP Sessions ...........................19
+      2.6. Label Distribution and Management .........................20
+           2.6.1. Label Distribution Control Mode ....................20
+                  2.6.1.1. Independent Label Distribution Control ....20
+                  2.6.1.2. Ordered Label Distribution Control ........20
+           2.6.2. Label Retention Mode ...............................21
+                  2.6.2.1. Conservative Label Retention Mode .........21
+                  2.6.2.2. Liberal Label Retention Mode ..............21
+           2.6.3. Label Advertisement Mode ...........................22
+      2.7. LDP Identifiers and Next Hop Addresses ....................22
+      2.8. Loop Detection ............................................23
+           2.8.1. Label Request Message ..............................23
+           2.8.2. Label Mapping Message ..............................25
+           2.8.3. Discussion .........................................26
+      2.9. Authenticity and Integrity of LDP Messages ................27
+           2.9.1. TCP MD5 Signature Option ...........................27
+           2.9.2. LDP Use of TCP MD5 Signature Option ................29
+      2.10. Label Distribution for Explicitly Routed LSPs ............29
+   3. Protocol Specification .........................................30
+      3.1. LDP PDUs ..................................................30
+      3.2. LDP Procedures ............................................31
+      3.3. Type-Length-Value Encoding ................................31
+      3.4. TLV Encodings for Commonly Used Parameters ................33
+           3.4.1. FEC TLV ............................................33
+                  3.4.1.1. FEC Procedures ............................35
+           3.4.2. Label TLVs .........................................35
+                  3.4.2.1. Generic Label TLV .........................36
+                  3.4.2.2. ATM Label TLV .............................36
+                  3.4.2.3. Frame Relay Label TLV .....................37
+           3.4.3. Address List TLV ...................................38
+           3.4.4. Hop Count TLV ......................................39
+                  3.4.4.1. Hop Count Procedures ......................39
+           3.4.5. Path Vector TLV ....................................41
+                  3.4.5.1. Path Vector Procedures ....................41
+                           3.4.5.1.1. Label Request Path Vector ......41
+                           3.4.5.1.2. Label Mapping Path Vector ......42
+           3.4.6. Status TLV .........................................43
+
+
+
+
+Andersson, et al.           Standards Track                     [Page 2]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      3.5. LDP Messages ..............................................44
+           3.5.1. Notification Message ...............................46
+                  3.5.1.1. Notification Message Procedures ...........48
+                  3.5.1.2. Events Signaled by Notification Messages ..48
+                           3.5.1.2.1. Malformed PDU or Message .......48
+                           3.5.1.2.2. Unknown or Malformed TLV .......49
+                           3.5.1.2.3. Session KeepAlive Timer
+                                      Expiration .....................50
+                           3.5.1.2.4. Unilateral Session Shutdown ....50
+                           3.5.1.2.5. Initialization Message Events ..50
+                           3.5.1.2.6. Events Resulting from
+                                      Other Messages .................50
+                           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 ..................53
+           3.5.3. Initialization Message .............................54
+                  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 ..............................70
+                  3.5.8.1. Label Request Message Procedures ..........71
+           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
+                  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
+
+
+
+Andersson, et al.           Standards Track                     [Page 3]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      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 .........................................88
+   6. Areas for Future Study .........................................89
+   7. Changes from RFC 3036 ..........................................90
+   8. Acknowledgments ................................................93
+   9. References .....................................................93
+      9.1. Normative References ......................................93
+      9.2. Informative References ....................................94
+   Appendix A. LDP Label Distribution Procedures  ....................95
+      A.1. Handling Label Distribution Events  .......................97
+           A.1.1. Receive Label Request  .............................98
+           A.1.2.  Receive Label Mapping  ...........................101
+           A.1.3.  Receive Label Abort Request  .....................107
+           A.1.4.  Receive Label Release  ...........................109
+           A.1.5.  Receive Label Withdraw  ..........................111
+           A.1.6.  Recognize New FEC  ...............................113
+           A.1.7.  Detect Change in FEC Next Hop  ...................115
+           A.1.8.  Receive Notification / Label Request Aborted  ....118
+           A.1.9.  Receive Notification / No Label Resources  .......119
+           A.1.10.  Receive Notification / No Route  ................119
+           A.1.11.  Receive Notification / Loop Detected  ...........120
+           A.1.12.  Receive Notification / Label Resources Available 121
+           A.1.13.  Detect Local Label Resources Have Become
+                    Available  ......................................122
+           A.1.14.  LSR Decides to No Longer Label Switch a FEC  ....123
+           A.1.15.  Timeout of Deferred Label Request  ..............123
+      A.2. Common Label Distribution Procedures  ....................124
+           A.2.1.  Send_Label  ......................................124
+           A.2.2.  Send_Label_Request  ..............................125
+           A.2.3.  Send_Label_Withdraw  .............................127
+           A.2.4.  Send_Notification  ...............................127
+           A.2.5.  Send_Message  ....................................128
+           A.2.6.  Check_Received_Attributes  .......................128
+           A.2.7.  Prepare_Label_Request_Attributes  ................129
+           A.2.8.  Prepare_Label_Mapping_Attributes  ................131
+
+
+
+
+
+Andersson, et al.           Standards Track                     [Page 4]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+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) is a protocol defined for
+   distributing labels.  It was originally published as RFC 3036 in
+   January 2001.  It was produced by the MPLS Working Group of the IETF
+   and was jointly authored by Loa Andersson, Paul Doolan, Nancy
+   Feldman, Andre Fredette, and Bob Thomas.
+
+   LDP is a 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 (but does not require) 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 5036                   LDP Specification                October 2007
+
+
+1.1.  LDP Peers
+
+   Two LSRs that 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 bidirectional.
+
+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 5036                   LDP Specification                October 2007
+
+
+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 on 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 5036                   LDP Specification                October 2007
+
+
+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 that 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 that 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.
+
+   This specification defines a single type of FEC element, the "Address
+   Prefix FEC element".  This element is an address prefix of any length
+   from 0 to a full address, inclusive.
+
+   Additional FEC elements may be defined, as needed, by other
+   specifications.
+
+   In the remainder of this section, we give the rules to be used for
+   mapping packets to LSPs that have been set up using an Address Prefix
+   FEC element.
+
+   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 that matches the packet's
+   destination address.  With respect to a particular packet and a
+   particular LSP, we refer to any Address Prefix FEC element that
+   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 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.
+
+
+
+
+Andersson, et al.           Standards Track                     [Page 8]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      -  If it is known that a packet must traverse a particular egress
+         router, and there is an LSP that has an Address Prefix FEC
+         element that is a /32 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.)
+
+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:
+
+      -  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 (Virtual Channel Identifiers) as
+         labels, or a Frame Relay interface that uses DLCIs (Data Link
+         Connection Identifiers) 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:
+
+
+
+
+
+
+Andersson, et al.           Standards Track                     [Page 9]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+         <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.
+
+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.
+
+
+
+Andersson, et al.           Standards Track                    [Page 10]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+   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.
+
+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.
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 11]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+   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.
+
+   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.
+
+
+
+Andersson, et al.           Standards Track                    [Page 12]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+         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
+            Hellos 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.
+
+      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 that appears
+            earliest in the message is the most significant byte of the
+            integer and the byte that 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.
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 13]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+   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 (Virtual Path Identifier /
+   Virtual Channel Identifier) ranges for label controlled ATM, DLCI
+   (Data Link Connection Identifier) ranges for label controlled Frame
+   Relay, etc.
+
+   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.
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 14]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      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.
+
+         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.
+
+
+
+Andersson, et al.           Standards Track                    [Page 15]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+            Until the LDP session is established, no other messages
+            except those listed in the procedures above may be
+            exchanged, and the rules for processing the U-bit in LDP
+            messages are overridden.  If a message other than those
+            listed in the procedures above is received, a Shutdown msg
+            MUST be transmitted and the transport connection MUST be
+            closed.
+
+   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.
+
+   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.  Note that a Shutdown
+   message is implemented as a Notification message with a Status TLV
+   indicating a fatal error.
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 16]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+               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 17]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+              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 18]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+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 that 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 an 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 that 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 19]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+2.6.  Label Distribution and Management
+
+   The MPLS architecture [RFC3031] 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 20]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      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] [RFC4271].
+
+   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 21]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+   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 22]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+   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 that 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 describe 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 23]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+   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 that 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 24]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+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 25]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      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 that exceeds the configured maximum value, or with a
+      Path Vector TLV containing its own LSR Id or that 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 that 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 26]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+   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 that 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 a 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 [RFC4271].  See [RFC1321] for a
+   specification of the MD5 hash function.  From a standards maturity
+   point of view, the current document relates to [RFC2385] the same way
+   as [RFC4271] relates to [RFC2385].  This is explained in [RFC4278].
+
+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 summarize 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 27]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      "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 28]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+         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 29]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+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 30]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+   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 31]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+    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 MUST be silently ignored and the rest of the message
+      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.  By setting both
+      the U- and F-bits, a TLV can be propagated as opaque data through
+      nodes that do not recognize the TLV.
+
+   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.
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 32]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+   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
+   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 33]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+   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.
+
+      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 34]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      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 [ASSIGNED_AF] 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.
+
+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 that can appear in
+   situations that require a Label TLV.
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 35]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+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 represented as a 20-bit number in a 4
+      octet field as follows:
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     Label                             |                       |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      For further information, see [RFC3032].
+
+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.
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 36]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+   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                    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   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 of DLCI
+         2 = 23 bits of DLCI
+
+      Len values 1 and 3 are reserved.
+
+   DLCI
+      The Data Link Connection Identifier
+
+
+
+
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 37]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      For a 10-bit DLCI, the 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| Frame Relay Label (0x0202)|       Length                  |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | Reserved    |Len|            0            |    10-bit DLCI    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      For a 23-bit DLCI, the 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| Frame Relay Label (0x0202)|       Length                  |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | Reserved    |Len|              23-bit DLCI                    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      For further information, see [RFC3034].
+
+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 [ASSIGNED_AF] that encodes the addresses contained in the
+      Addresses field.
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 38]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+   Addresses
+      A list of addresses from the specified Address Family.  The
+      encoding of the individual addresses depends on the Address
+      Family.
+
+      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 set up.
+
+   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 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;
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 39]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+   -  If the message is a Label Mapping message, R determines the hop
+      count as follows:
+
+      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 an 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".
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 40]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+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
+   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 set up 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.
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 41]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+   The LSR MUST:
+
+      1. Transmit a Notification message to the sending LSR signaling
+         "Loop Detected".
+
+      2. Not propagate the Label Request message further.
+
+   Note that a Label Request message with a Path Vector TLV is forwarded
+   until:
+
+      1. A loop is found,
+
+      2. The LSP egress is reached, or
+
+      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 that 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.
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 42]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+3.4.6.  Status TLV
+
+   Notification messages carry Status TLVs to specify events being
+   signaled.
+
+   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.
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 43]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      Status Data
+         30-bit unsigned integer that specifies the status information.
+
+         This specification defines Status Codes (32-bit unsigned
+         integers with the above encoding).
+
+         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 44]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+   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 and that there is no padding at the end of a message;
+   that is, parameters can end at odd-byte boundaries.
+
+
+
+
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 45]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+   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"
+      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.
+
+
+
+
+
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 46]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+   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.
+
+   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.
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 47]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+   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 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.
+
+   The above statement does not apply to the processing of the Shutdown
+   message in the session initialization procedure.  When an LSR
+   receives a Shutdown message during session initialization, it SHOULD
+   transmit a Shutdown message and then close the transport connection.
+
+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:
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 48]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      -  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, d 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.
+
+         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 Length is too small, that is, smaller than the
+         smallest possible value component.  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 signaled 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:
+
+
+
+Andersson, et al.           Standards Track                    [Page 49]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      -  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.
+
+      -  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.
+
+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.
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 50]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+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:
+
+    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                  |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 51]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      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.
+
+      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 of the Hello message 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
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 52]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      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.
+
+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).
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 53]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      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:
+
+      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".
+
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 54]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+   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:
+
+       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
+
+
+
+Andersson, et al.           Standards Track                    [Page 55]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+         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 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 that 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.
+
+
+
+Andersson, et al.           Standards Track                    [Page 56]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      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".
+
+         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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 57]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      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:
+
+         -  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.
+
+      N, Number of label range components
+         Specifies the number of ATM Label Range Components included in
+         the TLV.
+
+
+
+Andersson, et al.           Standards Track                    [Page 58]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      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 that 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:
+
+       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.
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 59]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+         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 Channel 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.
+
+      Frame Relay Session Parameters
+         Used when an LDP session manages label exchange for a Frame
+         Relay link to specify Frame Relay-specific session parameters.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 60]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+       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
+         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.
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 61]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      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 that 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.
+
+      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.
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 62]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      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
+   that 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
+   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
+
+
+
+Andersson, et al.           Standards Track                    [Page 63]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+   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 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".
+
+   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.
+
+
+
+Andersson, et al.           Standards Track                    [Page 64]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+   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 signaling an error and abort processing the
+   message.
+
+   An LSR may re-advertise an address (A) that it has previously
+   advertised without explicitly withdrawing the address.  If the
+   receiver already has address binding (LSR, A), it SHOULD take no
+   further action.
+
+   An LSR may withdraw an address (A) without having previously
+   advertised it.  If the receiver has no address binding (LSR, A), it
+   SHOULD take no further action.
+
+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".
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 65]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+   Optional Parameters
+      No optional parameters are defined for the Address Withdraw
+      message.
+
+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 TLVs" 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:
+
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 66]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+         Optional Parameter    Length       Value
+
+         Label Request         4            See below
+             Message ID TLV
+         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".
+
+      Label Request Message ID
+         If this Label Mapping message is a response to a Label Request
+         message, it MUST include the Label 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 set up by the Label message.  Section "Hop Count
+         Procedures" describes how to handle this TLV.
+
+      Path Vector
+         Specifies the LSRs along the LSP being set up 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 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:
+
+
+
+Andersson, et al.           Standards Track                    [Page 67]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      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.
+
+      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
+
+
+
+Andersson, et al.           Standards Track                    [Page 68]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+   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.
+
+   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 re-advertise 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 re-advertising 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.
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 69]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+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.
+
+   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 set up by the Label Request message.  Section "Hop Count
+      Procedures" describes how to handle this TLV.
+
+   Path Vector
+      Specifies the LSRs along the LSR being set up by the Label Request
+      message.  Section "Path Vector Procedures" describes how to handle
+      this TLV.
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 70]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+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.
+
+   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 set up 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,
+   the receiving LSR uses its routing table to determine its response.
+   Unless its routing table includes an entry that exactly matches the
+   requested Prefix, 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 that
+   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.
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 71]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+   This version of the protocol defines the following Status Codes for
+   the Notification message that signals a request cannot be satisfied:
+
+      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.
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 72]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+   FEC TLV
+      Identifies the FEC for which the Label Request is being aborted.
+
+   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 a FEC sent to an LSR Rd in the
+   following circumstances:
+
+      1. Ru's next hop for the 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 the FEC from an upstream peer Y.
+
+      3. Ru is a merge, non-ingress LSR and has received a Label Abort
+         Request for the FEC from an upstream peer Y and Y is the only
+         (last) upstream LSR requesting a label for the 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 5036                   LDP Specification                October 2007
+
+
+   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 timeout
+   period should be relatively long (several minutes).  If the timeout
+   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 5036                   LDP Specification                October 2007
+
+
+   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 5036                   LDP Specification                October 2007
+
+
+   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 5036                   LDP Specification                October 2007
+
+
+   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 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 that 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 that 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
+   optional Label TLV in the Label Release message, then the sending LSR
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 77]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+   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 handles 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 5036                   LDP Specification                October 2007
+
+
+      The determination as to whether a vendor-private message is
+      understood is based on the Type and the mandatory Vendor ID field.
+
+      Implementations that support vendor-private TLVs MUST support a
+      user-accessible configuration interface that causes the U-bit to
+      be set on all transmitted vendor-private TLVs; this requirement
+      MAY be satisfied by a user-accessible configuration interface that
+      prevents transmission of all vendor-private TLVs for which the U-
+      bit is clear.
+
+   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 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 5036                   LDP Specification                October 2007
+
+
+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.
+
+      Implementations that support Vendor-Private messages MUST support
+      a user-accessible configuration interface that causes the U-bit to
+      be set on all transmitted Vendor-Private messages; this
+      requirement MAY be satisfied by a user-accessible configuration
+      interface that prevents transmission of all Vendor-Private
+      messages for which the U-bit is clear.
+
+   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.
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 80]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+   Message Length
+      Specifies the cumulative length in octets of the Message ID,
+      Vendor ID, Remaining Mandatory Parameters, and Optional
+      Parameters.
+
+   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.
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 81]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      Message Name            Type     Section Title
+
+      Notification            0x0001   "Notification Message"
+      Hello                   0x0100   "Hello Message"
+      Initialization          0x0200   "Initialization Message"
+      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
+
+
+
+Andersson, et al.           Standards Track                    [Page 82]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      Vendor-Private           0x3E00-   "LDP Vendor-Private Extensions"
+                               0x3EFF
+      Experimental             0x3F00-   "LDP Experimental Extensions"
+                               0x3FFF
+
+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 Abort Request ..."
+      Missing Message       0   0x00000016    "Events Signaled by ..."
+          Parameters
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 83]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      Unsupported Address   0   0x00000017    "FEC Procedures"
+          Family                              "Address Message Proc ..."
+      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 is defined in [RFC3031] as follows:
+
+   "The Implicit NULL label is a label with special semantics which an
+   LSR can bind to an address prefix.  If LSR Ru, by consulting its ILM
+   (Incoming Label Map) sees that labeled packet P must be forwarded
+   next to Rd, but that Rd has distributed a binding of Implicit NULL to
+   the corresponding address prefix, then instead of replacing the value
+   of the label on top of the label stack, Ru pops the label stack, and
+   then forwards the resulting packet to Rd."
+
+   The implicit NULL label is represented in LDP as a Generic Label TLV
+   with a Label field value of 3, as defined in [RFC3032].
+
+4.  IANA Considerations
+
+   LDP defines the following name spaces that 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:
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 84]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      -  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.
+
+      -  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.
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 85]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+   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.
+
+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 indicate their willingness to establish and maintain LDP
+      sessions by periodically sending Hello messages.  Receipt of a
+      Hello serves to create a new "Hello adjacency", if one does not
+      already exist, or to refresh an existing one.  Spoofing a Hello
+      packet for an existing adjacency can cause the adjacency to time
+      out and that can result in termination of the associated session.
+      This can occur when the spoofed Hello specifies a small Hold Time,
+      causing the receiver to expect Hellos within this interval, while
+      the true neighbor continues sending Hellos at the lower,
+      previously agreed to, frequency.
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 86]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      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.
+
+   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 that distribute
+   routing information.  By providing a mechanism to ensure the
+   authenticity and integrity of its messages, LDP provides a level of
+   security that 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
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 87]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+   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 that can be trusted to not initiate such an attack.
+      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 as 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:
+
+
+
+Andersson, et al.           Standards Track                    [Page 88]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+         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.
+
+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 (Class of Service) 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.
+
+      -  LDP support for signaling the maximum transmission unit is not
+         specified in this version.  It is discussed in the experimental
+         document [LDP-MTU].
+
+      -  The current specification does not address basic peer discovery
+         on Non-Broadcast Multi-Access (NBMA) media.  The solution
+         available in the current specification is to use extended peer
+
+
+
+Andersson, et al.           Standards Track                    [Page 89]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+         discovery in such setups.  The issue of defining a mechanism
+         semantically similar to Basic Discovery (1 hop limit, bind the
+         hello adjacency to an interface) that uses preconfigured
+         neighbor addresses is left for further study.
+
+      -  The current specification does not support shutting down an
+         adjacency.  The motivation for doing it and the mechanisms for
+         achieving it are left for further study.
+
+      -  The current specification does not include a method for
+         securing Hello messages, to detect spoofing of Hellos.  The
+         scenarios where this is necessary, as well as the mechanism for
+         achieving it are left for future study.
+
+      -  The current specification does not have the ability to detect a
+         stateless fast control plane restart.  The method for achieving
+         this, possibly through an "incarnation/instance" number carried
+         in the Hello message, is left for future study.
+
+      -  The current specification does not support an "end of LIB"
+         message, analogous to BGP's "end of RIB" message that an LDP
+         LSR (operating in DU mode) would use following session
+         establishment.  The discussion on the need for such a mechanism
+         and its implementation is left for future study.
+
+      -  The current specification does not deal with situations where
+         different LSRs advertise the same address.  Such situations
+         typically occur as the result of configuration errors, and the
+         goal in this case is to provide the LSRs advertising the same
+         address with enough information to enable operators to take
+         corrective action.  The specification of this mechanism is left
+         for a separate document.
+
+7.  Changes from RFC 3036
+
+   Here is a list of changes from RFC 3036
+
+       1. Removed the Host Address FEC and references to it, since it is
+          not used by any implementation.
+
+       2. Split the reference list into normative and informative
+          references
+
+       3. Removed "MPLS using ATM VP Switching" from the list of
+          normative references, and references to it.
+
+        4. Removed reference to RFC 1700 and replaced it with a link to
+          http://www.iana.org/assignments/address-family-numbers.
+
+
+
+Andersson, et al.           Standards Track                    [Page 90]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+       5. Removed reference to RFC 1771 and replaced it with a reference
+          to RFC 4271.
+
+       6. Clarified the use of the F-bit.
+
+       7. Added option to allow split horizon when doing Ordered
+          Control.
+
+       8. Clarified the processing of messages with the U-bit set during
+          the session initialization procedures
+
+       9. Clarified the processing of the E-bit during session
+          initialization procedures.
+
+      10. Added text explaining that the Shutdown message in the state
+          transition diagram is implemented as a notification message
+          with a Status TLV indicating a fatal error.
+
+      11. Added case for TLV length too short in the specification for
+          handling malformed TLVs.
+
+      12. Explained the security threat posed by hello spoofing.
+
+      13. Added reference to 4271 and 4278 and text for standards
+          maturity variance with regards to the MD5 option.
+
+      14. Added text from 3031 explaining the handling of implicit NULL
+          label.
+
+      15. Included the encoding of DLCIs to remove normative reference
+          to 3034.
+
+      16. Moved references to 3031, 3032, and 3034 to informative.
+
+      17. In the section describing handling of unknown TLV, removed
+          reference to inexistent section (errata in original document).
+
+      18. Added text clarifying how to achieve interoperability when
+          sending vendor-private TLVs and messages.
+
+      19. In the "receive label request" procedures, if a loop is
+          detected, changed the procedure to send a notification before
+          aborting the rest of the processing.
+
+      20. In "receive label release" procedures, clarified the behavior
+          for merge-capable LSRs.
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 91]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      21. In "receive label release" procedures, clarified the behavior
+          for receipt of an unknown FEC.
+
+      22. In note 4 of "Detect Change in FEC Next Hop", modified the
+          text to reference the correct set of conditions for sending a
+          label request procedure (typo in the original document).
+
+      23. In the procedures for "LSR decides to no longer label switch a
+          FEC", clarified the fact that the label must not be reused
+          until a label release is received.
+
+      24. In the routine "Prepare_Label_Mapping_Attributes", added a
+          note regarding the treatment of unknown TLVs according to
+          their U and F-bits.
+
+      25. In the Address message processing procedures, clarified the
+          behavior for the case where an LSR receives re-advertisement
+          of an address previously advertised it, or withdrawal of an
+          address from an LSR that has not previously advertised that
+          address.
+
+      26. In the routine "Receive Label Mapping", clarified the meaning
+          of PrevAdvLabel when no label advertisement message has been
+          sent previously.
+
+      27. In the "Receive Label Mapping" procedures, if a loop is
+          detected, modified the procedure to send a notification before
+          aborting the rest of the processing.
+
+      28. In the "Receive Label Mapping" procedures, corrected step
+          LMp.10 to handle label mapping messages for additional (non-
+          merged) LSPs for the FEC.
+
+      29. In the "Receive Label Mapping" procedures, clarified behavior
+          when receiving a duplicate label for the same FEC.
+
+      30. In the routine "Receive Label Abort Request", clarified the
+          behavior for non-merging LSRs.
+
+      31. Added the following items to the section discussing areas for
+          future study:
+
+         o  extensions for communicating the maximum transmission unit
+         o  basic peer discovery on NBMA media
+         o  option of shutting down an adjacency
+         o  mechanisms for securing Hello messages
+         o  detection of a stateless fast control plane restart
+         o  support of "end of LIB" message
+
+
+
+Andersson, et al.           Standards Track                    [Page 92]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+         o  mechanisms for dealing with the case where different LSRs
+            advertise the same address
+
+8.  Acknowledgments
+
+   This document is produced as part of advancing the LDP specification
+   to draft standard status.  This document was originally published as
+   RFC 3036 in January 2001.  It was produced by the MPLS Working Group
+   of the IETF and was jointly authored by Loa Andersson, Paul Doolan,
+   Nancy Feldman, Andre Fredette, and Bob Thomas.
+
+   The ideas and text in RFC 3036 were 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 for their input for RFC 3036.
+
+   The editors would like to thank Eric Gray, David Black, and Sam
+   Hartman for their input to and review of the current document.
+
+   In addition, the editors would like to thank the members of the MPLS
+   Working Group for their ideas and the support they have given to this
+   document, and in particular, to Eric Rosen, Luca Martini, Markus
+   Jork, Mark Duffy, Vach Kompella, Kishore Tiruveedhula, Rama
+   Ramakrishnan, Nick Weeds, Adrian Farrel, and Andy Malis.
+
+9.  References
+
+9.1.  Normative References
+
+   [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.
+
+   [ASSIGNED_AF] http://www.iana.org/assignments/address-family-numbers
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2385]     Heffernan, A., "Protection of BGP Sessions via the TCP
+                 MD5 Signature Option", RFC 2385, August 1998.
+
+   [RFC3035]     Davie, B., Lawrence, J., McCloghrie, K., Rosen, E.,
+                 Swallow, G., Rekhter, Y., and P. Doolan, "MPLS using
+                 LDP and ATM VC Switching", RFC 3035, January 2001.
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 93]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+   [RFC3037]     Thomas, B. and E. Gray, "LDP Applicability", RFC 3037,
+                 January 2001.
+
+9.2.  Informative References
+
+   [CRLDP]       Jamoussi, B., Ed., Andersson, L., Callon, R., Dantu,
+                 R., Wu, L., Doolan, P., Worster, T., Feldman, N.,
+                 Fredette, A., Girish, M., Gray, E., Heinanen, J.,
+                 Kilty, T., and A. Malis, "Constraint-Based LSP Setup
+                 using LDP", RFC 3212, January 2002.
+
+   [LDP-MTU]     Black, B. and K. Kompella, "Maximum Transmission Unit
+                 Signalling Extensions for the Label Distribution
+                 Protocol", RFC 3988, January 2005.
+
+   [RFC2328]     Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
+                 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., Tappan, D., Fedorkow, G., Rekhter, Y.,
+                 Farinacci, D., 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.
+
+   [RFC4271]     Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
+                 Border Gateway Protocol 4 (BGP-4)", RFC 4271, January
+                 2006.
+
+   [RFC4278]      Bellovin, S. and A. Zinin, "Standards Maturity
+                 Variance Regarding the TCP MD5 Signature Option (RFC
+                 2385) and the BGP-4 Specification", RFC 4278, January
+                 2006.
+
+
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 94]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+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:
+
+         .  Downstream Unsolicited Independent Control, called
+            PushUnconditional in [RFC3031].
+
+
+
+Andersson, et al.           Standards Track                    [Page 95]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+         .  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 ReleaseOnChange in
+            [RFC3031].
+
+         .  Liberal Label retention, called NoReleaseOnChange in
+            [RFC3031].
+
+      -  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:
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 96]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+         .  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 the NotAvailable 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 that 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.
+
+   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.
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 97]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+   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 the Label Request
+         message, if any, propagated to FEC Next Hop.
+
+      -  StoredHopCount.  The hop count, if any, previously recorded for
+         the FEC.
+
+   Algorithm:
+
+      LRq.1   Execute procedure Check_Received_Attributes (MsgSource,
+              LabelRequest, RAttributes).
+              If Loop Detected, goto LRq.4.
+
+      LRq.2   Is there a Next Hop for FEC?
+              If not, goto LRq.5.
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 98]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      LRq.3   Is MsgSource the Next Hop?
+              If not, 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).
+
+               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.
+
+
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                    [Page 99]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+               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
+
+               1. Install label sent to MsgSource and label from Next
+                  Hop (if LSR is not egress) for forwarding/switching
+                  use.
+
+      LRq.13  DONE.
+
+
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 100]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      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 the 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;
+
+      -  Installation of the newly learned label for
+         forwarding/switching use by the LSR.
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 101]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+   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 the FEC, if any, previously
+         advertised to an upstream peer.  Assuming no label was
+         previously advertised, this is the same label as the one in the
+         Label Mapping message being processed.
+
+      -  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 the 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.
+
+      LMp.7   Remove Label from forwarding/switching use.  (See Note 5.)
+
+
+
+Andersson, et al.           Standards Track                   [Page 102]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      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.)
+              OR
+              Is the received label mapping in response to a previously
+              outstanding label request sent to MsgSource?  (See Note
+              12.)
+              If so, goto LMp.11.
+
+      LMp.10a Is LSR operating in Downstream Unsolicited mode?  If so,
+              delete the label mapping for the label previously received
+              from MsgSource and remove it from forwarding/switching
+              use.
+              Execute procedure Send_Message (MsgSource, Label Release,
+              FEC, label previously received from MsgSource).
+
+      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.
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 103]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      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.
+
+      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).  (See Note 13.)
+              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:
+
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 104]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+            For Downstream Unsolicited Independent Control OR For
+            Downstream Unsolicited Ordered Control
+
+               1. Execute procedure
+                  Prepare_Label_Mapping_Attributes (Peer, FEC,
+                  RAttributes, SAttributes, IsPropagating,
+                  UnknownHopCount).
+
+               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.
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 105]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+               4. Goto LMp.31.
+
+      LMp.31  End iteration from LMp.17.
+              Go to LMp.33.
+
+      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 the 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 the 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) the 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 the LSR is operating in Downstream Unsolicited
+          Ordered Control mode.  Ordered Control prevents the LSR from
+          advertising a label for the FEC until it has received a label
+          mapping from its next hop (MsgSource) for the FEC.
+
+      8.  If the LSR is merging the LSP, it may have previously sent
+          label mappings for the FEC LSP to one or more peers.  If the
+
+
+
+Andersson, et al.           Standards Track                   [Page 106]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+          LSR is not merging, it may have sent a label mapping for the
+          LSP in question to at most one LSR.
+
+      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.
+
+      12. As determined by step LMp.1.
+
+      13. An LSR operating in Ordered Control mode may choose to skip at
+          this stage the peer from which it received the advertisement
+          that caused it to generate the label-map message.  Doing so
+          will in effect provide a form of split-horizon.
+
+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.
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 107]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+   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.
+
+      -  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 outstanding label requests for this 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.
+
+
+
+Andersson, et al.           Standards Track                   [Page 108]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      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.
+
+   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   Does FEC match a known FEC?  If not, goto LRl.14.
+
+      LRl.2   Remove MsgSource from record of peers that hold Label for
+              FEC.  (See Note 1.)
+
+      LRl.3   Does message match an outstanding label withdraw for FEC
+              previously sent to MsgSource?
+              If not, goto LRl.5
+
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 109]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      LRl.4   Delete record of outstanding label withdraw for FEC
+              previously sent to MsgSource.
+
+      LRl.5   Is LSR merging labels for this FEC?  If not, goto LRl.7.
+              (See Note 2.)
+
+      LRl.6   Does LSR have outstanding label advertisements for this
+              FEC?
+              If so, goto LRl.11.
+
+      LRl.7   Is LSR egress for the FEC?
+              If so, goto LRl.11.
+
+      LRl.8   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.11.
+
+      LRl.9   Is LSR configured to propagate releases?
+              If not, goto LRl.11.  (See Note 3.)
+
+      LRl.10  Execute procedure Send_Message (Next Hop, Label Release,
+              FEC, Label from Next Hop).
+
+      LRl.11  Remove Label from forwarding/switching use for traffic
+              from MsgSource.
+
+      LRl.12  Do any peers still hold Label for FEC?
+              If so, goto LRl.14.
+
+      LRl.13  Free the Label.
+
+      LRl.14  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.5 through LRl.9 deal with determining whether where the LSR
+         should propagate the Label Release to a downstream peer
+         (LRl.9).
+
+      3. If LRl.9 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
+
+
+
+Andersson, et al.           Standards Track                   [Page 110]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+         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
+         amount of signaling required small, and 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.
+
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 111]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      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.
+
+      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 the 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.
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 112]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+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;
+
+      -  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.
+
+
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 113]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+               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.
+
+               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
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 114]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+            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.
+
+   Notes:
+
+      1. An example of an attribute that might be part of InitAttributes
+         is one that 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;
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 115]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      -  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.
+
+      -  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 the 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.
+
+
+
+Andersson, et al.           Standards Track                   [Page 116]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      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 that a label abort request is pending for FEC with
+             Old Next Hop.
+
+      NH.10  Is there a New Next Hop for 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.
+
+      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 the Label is not in forwarding/switching use, NH.2 has no
+         effect.
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 117]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      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 that 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.13 hold.
+         Therefore, it executes the Send_Label_Request procedure
+         directly rather than perform the LSR Label Request procedure.
+
+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.
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 118]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+   Note:
+
+      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.
+
+      -  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 that 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.
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 119]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+   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.
+
+            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".
+
+
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 120]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+   Note:
+
+      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 the postponed Label
+         Request message.
+
+   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.
+
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 121]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+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 the 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.
+
+      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.
+
+   Note:
+
+      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.
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 122]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+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 the FEC previously advertised to
+      the Peer.
+
+   Algorithm:
+
+      NoLS.1  Execute procedure Send_Label_Withdraw (Peer, FEC,
+              PrevAdvLabel).  (See Note 1.)
+
+      NoLS.2  DONE.
+
+   Note:
+
+      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.  If the LSR
+         doesn't wait for the Label Release message from the peer, it
+         SHOULD NOT reuse the label until it receives the Label Release.
+
+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.
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 123]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      -  Attributes.  Attributes stored with the 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
+      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.  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.
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 124]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      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).
+
+      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.
+
+   Note:
+
+      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.
+
+
+
+Andersson, et al.           Standards Track                   [Page 125]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+   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
+
+      SLRq.3  Execute procedure Send_Message (Peer, Label Request, FEC,
+              Attributes).
+
+      SLRq.4  Record that 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 that label mapping
+              for FEC and Attributes from Peer is needed but that no
+              label resources are available.
+
+      SLRq.7  Return failure.
+
+   Note:
+
+      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.
+
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 126]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+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 that label withdraw for FEC has been sent to Peer
+              and mark it as outstanding.
+
+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.
+
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 127]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+   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.
+
+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.
+
+
+
+Andersson, et al.           Standards Track                   [Page 128]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      -  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).
+
+      CRa.8   Return Loop Detected.
+
+      CRa.9   DONE.
+
+   Note:
+
+      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.
+
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 129]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+   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.
+
+      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.
+
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 130]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      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.
+
+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.
+
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 131]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      -  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  Do the RAttributes include any unknown TLVs?
+              If not, goto PMpA.4.
+
+      PMpA.2  Do the settings of the U- and F-bits require forwarding of
+              these TLVs?
+              If not, goto PMpA.4.
+
+      PMpA.3  Copy the unknown TLVs in SAttributes.
+
+      PMpA.4  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.24.
+
+      PMpA.5  Is LSR egress for FEC?
+              If not, goto PMpA.7.
+
+      PMpA.6  Include Hop Count of 1 in SAttributes.  Goto PMpA.24.
+
+      PMpA.7  Do RAttributes have a Hop Count?
+              If not, goto PMpA.11.
+
+      PMpA.8  Is LSR a member of the 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.10.
+
+      PMpA.9  Include Hop Count of 1 in SAttributes.  Goto PMpA.12.
+
+      PMpA.10 Increment RAttributes Hop Count and copy the resulting Hop
+              Count to SAttributes.  (See Note 2.)  Goto PMpA.12.
+
+      PMpA.11 Include Hop Count of unknown (0) in SAttributes.
+
+      PMpA.12 Is Loop Detection configured on LSR?
+              If not, goto PMpA.24.
+
+      PMpA.13 Do RAttributes have a Path Vector?
+              If so, goto PMpA.22.
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 132]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+      PMpA.14 Is LSR propagating a received Label Mapping?
+              If not, goto PMpA.23.
+
+      PMpA.15 Does LSR support merging?
+              If not, goto PMpA.17.
+
+      PMpA.16 Has LSR previously sent a Label Mapping for FEC to Peer?
+              If not, goto PMpA.23.
+
+      PMpA.17 Do RAttributes include a Hop Count?
+              If not, goto PMpA.24.
+
+      PMpA.18 Is Hop Count in RAttributes unknown(0)?
+              If so, goto PMpA.23.
+
+      PMpA.19 Has LSR previously sent a Label Mapping for FEC to Peer?
+              If not, goto PMpA.24.
+
+      PMpA.20 Is Hop Count in RAttributes different from PrevHopCount?
+              If not, goto PMpA.24.
+
+      PMpA.21 Is the Hop Count in RAttributes > PrevHopCount? OR Is
+              PrevHopCount unknown(0)?
+              If not, goto PMpA.24.
+
+      PMpA.22 Add LSR Id to beginning of Path Vector from RAttributes
+              and copy the resulting Path Vector into SAttributes.
+              Goto PMpA.24.
+
+      PMpA.23 Include Path Vector of length 1 containing LSR Id in
+              SAttributes.
+
+      PMpA.24 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 133]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+Editors' Addresses
+
+   Loa Andersson
+   Acreo AB
+   Isafjordsgatan 22
+   Kista, Sweden
+   EMail: loa.andersson@acreo.se
+          loa@pi.se
+
+   Ina Minei
+   Juniper Networks
+   1194 N. Mathilda Ave.
+   Sunnyvale, CA 94089
+   EMail: ina@juniper.net
+
+   Bob Thomas
+   Cisco Systems, Inc.
+   1414 Massachusetts Ave
+   Boxborough, MA 01719
+   EMail: rhthomas@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 134]
+
+RFC 5036                   LDP Specification                October 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Andersson, et al.           Standards Track                   [Page 135]
+
-- 
cgit v1.2.3