idnits 2.17.1 

draft-ietf-mpls-ldp-06.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

  ** Looks like you're using RFC 2026 boilerplate.  This must be updated to
     follow RFC 3978/3979, as updated by RFC 4748.


  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  == No 'Intended status' indicated for this document; assuming Proposed
     Standard

  == It seems as if not all pages are separated by form feeds - found 0 form
     feeds but 124 pages


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** The document seems to lack an IANA Considerations section.  (See Section
     2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
     when there are no actions for IANA.)

  ** The document seems to lack separate sections for Informative/Normative
     References.  All references will be assumed normative when checking for
     downward references.

  ** There are 13 instances of too long lines in the document, the longest
     one being 2 characters in excess of 72.

  ** The abstract seems to contain references ([ARCH], [FRAMEWORK]), which it
     shouldn't.  Please replace those with straight textual mentions of the
     documents in question.

  ** The document seems to lack a both a reference to RFC 2119 and the
     recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
     keywords. 

     RFC 2119 keyword, line 895: '...   LSR MUST wait until a label from a ...'
     RFC 2119 keyword, line 1044: '... Request message MUST include a Hop Co...'
     RFC 2119 keyword, line 1047: '...     MUST include a Hop Count TLV with...'
     RFC 2119 keyword, line 1051: '...Hop Count TLV, R MUST increment the re...'
     RFC 2119 keyword, line 1052: '...t value by 1 and MUST pass the resulti...'
     (25 more instances...)


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 
     (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)

  -- The document date (October 1999) is 8953 days in the past.  Is this
     intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  == Missing Reference: 'RFC1321' is mentioned on line 3624, but not defined

  == Missing Reference: 'Dobb' is mentioned on line 3657, but not defined

  == Missing Reference: 'RFC2385' is mentioned on line 3690, but not defined

  ** Obsolete undefined reference: RFC 2385 (Obsoleted by RFC 5925)

  == Unused Reference: 'DIFFSERV' is defined on line 3762, but no explicit
     reference was found in the text

  == Unused Reference: 'LSPTUN' is defined on line 3777, but no explicit
     reference was found in the text

  -- Possible downref: Non-RFC (?) normative reference: ref. 'ARCH'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'ATM'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'ATM-VP'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'CRLDP'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'DIFFSERV'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'ENCAP'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'FR'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'FRAMEWORK'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'LSPTUN'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'TE'


     Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 12 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

--------------------------------------------------------------------------------

1	Network Working Group                                      Loa Andersson
2	Internet Draft                                      Nortel Networks Inc.
3	Expiration Date: April 2000
4	                                                             Paul Doolan
5	                                                       Ennovate Networks

7	                                                           Nancy Feldman
8	                                                                IBM Corp

10	                                                          Andre Fredette
11	                                                    Nortel Networks Inc.

13	                                                              Bob Thomas
14	                                                     Cisco Systems, Inc.

16	                                                            October 1999

18	                           LDP Specification

20	                       draft-ietf-mpls-ldp-06.txt

22	Status of this Memo

24	   This document is an Internet-Draft and is in full conformance with
25	   all provisions of Section 10 of RFC2026.

27	   Internet-Drafts are working documents of the Internet Engineering
28	   Task Force (IETF), its areas, and its working groups.  Note that
29	   other groups may also distribute working documents as Internet-
30	   Drafts.

32	   Internet-Drafts are draft documents valid for a maximum of six months
33	   and may be updated, replaced, or obsoleted by other documents at any
34	   time.  It is inappropriate to use Internet-Drafts as reference
35	   material or to cite them other than as "work in progress."

37	   The list of current Internet-Drafts can be accessed at
38	   http://www.ietf.org/ietf/1id-abstracts.txt

40	   The list of Internet-Draft Shadow Directories can be accessed at
41	   http://www.ietf.org/shadow.html.

43	Abstract

45	   An overview of Multi Protocol Label Switching (MPLS) is provided in
46	   [FRAMEWORK] and a proposed architecture in [ARCH].  A fundamental
47	   concept in MPLS is that two Label Switching Routers (LSRs) must agree
48	   on the meaning of the labels used to forward traffic between and
49	   through them.  This common understanding is achieved by using a set
50	   of procedures, called a label distribution protocol, by which one LSR
51	   informs another of label bindings it has made.  This document defines
52	   a set of such procedures called LDP (for Label Distribution
53	   Protocol).

55	Table of Contents

57	    1          LDP Overview  .......................................   6
58	    1.1        LDP Peers  ..........................................   6
59	    1.2        LDP Message Exchange  ...............................   7
60	    1.3        LDP Message Structure  ..............................   7
61	    1.4        LDP Error Handling  .................................   8
62	    1.5        LDP Extensibility and Future Compatibility  .........   8
63	    2          LDP Operation  ......................................   8
64	    2.1        FECs  ...............................................   8
65	    2.2        Label Spaces, Identifiers, Sessions and Transport  ..  10
66	    2.2.1      Label Spaces  .......................................  10
67	    2.2.2      LDP Identifiers  ....................................  11
68	    2.2.3      LDP Sessions  .......................................  11
69	    2.2.4      LDP Transport  ......................................  11
70	    2.3        LDP Sessions between non-Directly Connected LSRs  ...  12
71	    2.4        LDP Discovery   .....................................  12
72	    2.4.1      Basic Discovery Mechanism  ..........................  12
73	    2.4.2      Extended Discovery Mechanism  .......................  13
74	    2.5        Establishing and Maintaining LDP Sessions  ..........  14
75	    2.5.1      LDP Session Establishment  ..........................  14
76	    2.5.2      Transport Connection Establishment  .................  14
77	    2.5.3      Session Initialization  .............................  15
78	    2.5.4      Initialization State Machine  .......................  17
79	    2.5.5      Maintaining Hello Adjacencies  ......................  20
80	    2.5.6      Maintaining LDP Sessions  ...........................  20
81	    2.6        Label Distribution and Management  ..................  21
82	    2.6.1      Label Distribution Control Mode  ....................  21
83	    2.6.1.1    Independent Label Distribution Control  .............  21
84	    2.6.1.2    Ordered Label Distribution Control  .................  21
85	    2.6.2      Label Retention Mode  ...............................  22
86	    2.6.2.1    Conservative Label Retention Mode  ..................  22
87	    2.6.2.2    Liberal Label Retention Mode  .......................  22
88	    2.6.3      Label Advertisement Mode  ...........................  23
89	    2.7        LDP Identifiers and Next Hop Addresses  .............  23
90	    2.8        Loop Detection  .....................................  24
91	    2.8.1      Label Request Message  ..............................  25
92	    2.8.2      Label Mapping Message  ..............................  26
93	    2.8.3      Discussion  .........................................  28
94	    2.9        Label Distribution for Explicitly Routed LSPs  ......  28
95	    3          Protocol Specification  .............................  29
96	    3.1        LDP PDUs  ...........................................  29
97	    3.2        LDP Procedures  .....................................  30
98	    3.3        Type-Length-Value Encoding  .........................  30
99	    3.4        TLV Encodings for Commonly Used Parameters  .........  32
100	    3.4.1      FEC TLV  ............................................  32
101	    3.4.1.1    FEC Procedures  .....................................  35
102	    3.4.2      Label TLVs  .........................................  35
103	    3.4.2.1    Generic Label TLV  ..................................  35
104	    3.4.2.2    ATM Label TLV  ......................................  35
105	    3.4.2.3    Frame Relay Label TLV  ..............................  36
106	    3.4.3      Address List TLV  ...................................  37
107	    3.4.4      Hop Count TLV  ......................................  38
108	    3.4.4.1    Hop Count Procedures  ...............................  38
109	    3.4.5      Path Vector TLV  ....................................  39
110	    3.4.5.1    Path Vector Procedures  .............................  40
111	    3.4.5.1.1  Label Request Path Vector  ..........................  40
112	    3.4.5.1.2  Label Mapping Path Vector  ..........................  41
113	    3.4.6      Status TLV  .........................................  42
114	    3.5        LDP Messages  .......................................  43
115	    3.5.1      Notification Message  ...............................  45
116	    3.5.1.1    Notification Message Procedures  ....................  47
117	    3.5.1.2    Events Signaled by Notification Messages  ...........  47
118	    3.5.1.2.1  Malformed PDU or Message  ...........................  47
119	    3.5.1.2.2  Unknown or Malformed TLV  ...........................  48
120	    3.5.1.2.3  Session KeepAlive Timer Expiration  .................  49
121	    3.5.1.2.4  Unilateral Session Shutdown  ........................  49
122	    3.5.1.2.5  Initialization Message Events  ......................  49
123	    3.5.1.2.6  Events Resulting From Other Messages  ...............  49
124	    3.5.1.2.7  Miscellaneous Events  ...............................  49
125	    3.5.2      Hello Message  ......................................  50
126	    3.5.2.1    Hello Message Procedures  ...........................  52
127	    3.5.3      Initialization Message  .............................  53
128	    3.5.3.1    Initialization Message Procedures  ..................  61
129	    3.5.4      KeepAlive Message  ..................................  61
130	    3.5.4.1    KeepAlive Message Procedures  .......................  62
131	    3.5.5      Address Message  ....................................  62
132	    3.5.5.1    Address Message Procedures  .........................  63
133	    3.5.6      Address Withdraw Message  ...........................  63
134	    3.5.6.1    Address Withdraw Message Procedures  ................  64
135	    3.5.7      Label Mapping Message  ..............................  64
136	    3.5.7.1    Label Mapping Message Procedures  ...................  65
137	    3.5.7.1.1  Independent Control Mapping  ........................  66
138	    3.5.7.1.2  Ordered Control Mapping  ............................  66
139	    3.5.7.1.3  Downstream on Demand Label Advertisement  ...........  67
140	    3.5.7.1.4  Downstream Unsolicited Label Advertisement  .........  67
141	    3.5.8      Label Request Message  ..............................  68
142	    3.5.8.1    Label Request Message Procedures  ...................  69
143	    3.5.9      Label Abort Request Message  ........................  70
144	    3.5.9.1    Label Abort Request Message Procedures  .............  71
145	    3.5.10     Label Withdraw Message  .............................  73
146	    3.5.10.1   Label Withdraw Message Procedures  ..................  74
147	    3.5.11     Label Release Message  ..............................  74
148	    3.5.11.1   Label Release Message Procedures  ...................  75
149	    3.6        Messages and TLVs for Extensibility  ................  76
150	    3.6.1      LDP Vendor-private Extensions  ......................  76
151	    3.6.1.1    LDP Vendor-private TLVs  ............................  77
152	    3.6.1.2    LDP Vendor-private Messages  ........................  78
153	    3.6.2      LDP Experimental Extensions  ........................  79
154	    3.7        Message Summary  ....................................  80
155	    3.8        TLV Summary  ........................................  80
156	    3.9        Status Code Summary  ................................  81
157	    3.10       Well-known Numbers  .................................  82
158	    3.10.1     UDP and TCP Ports  ..................................  82
159	    3.10.2     Implicit NULL Label  ................................  82
160	    4          Security Considerations  ............................  82
161	    4.1        The TCP MD5 Signature Option  .......................  82
162	    4.2        LDP Use of the TCP MD5 Signature Option  ............  84
163	    5          Areas for Future Study  .............................  84
164	    6          Intellectual Property Considerations  ...............  85
165	    7          Acknowledgments  ....................................  85
166	    8          References  .........................................  85
167	    9          Author Information  .................................  87

169	    Appendix.A LDP Label Distribution Procedures  ..................  88
170	    A.1        Handling Label Distribution Events  .................  90
171	    A.1.1      Receive Label Request  ..............................  91
172	    A.1.2      Receive Label Mapping  ..............................  94
173	    A.1.3      Receive Label Abort Request  ........................  98
174	    A.1.4      Receive Label Release  .............................. 100
175	    A.1.5      Receive Label Withdraw  ............................. 102
176	    A.1.6      Recognize New FEC  .................................. 104
177	    A.1.7      Detect Change in FEC Next Hop  ...................... 106
178	    A.1.8      Receive Notification / Label Request Aborted  ....... 109
179	    A.1.9      Receive Notification / No Label Resources  .......... 110
180	    A.1.10     Receive Notification / No Route  .................... 110
181	    A.1.11     Receive Notification / Loop Detected  ............... 111
182	    A.1.12     Receive Notification / Label Resources Available  ... 112
183	    A.1.13     Detect local label resources have become available  . 112
184	    A.1.14     LSR decides to no longer label switch a FEC  ........ 113
185	    A.1.15     Timeout of deferred label request  .................. 114
186	    A.2        Common Label Distribution Procedures  ............... 115
187	    A.2.1      Send_Label  ......................................... 115
188	    A.2.2      Send_Label_Request  ................................. 116
189	    A.2.3      Send_Label_Withdraw  ................................ 118
190	    A.2.4      Send_Notification  .................................. 118
191	    A.2.5      Send_Message  ....................................... 119
192	    A.2.6      Check_Received_Attributes  .......................... 119
193	    A.2.7      Prepare_Label_Request_Attributes  ................... 120
194	    A.2.8      Prepare_Label_Mapping_Attributes  ................... 122

196	1. LDP Overview

198	   Section 2.6 of the MPLS architecture [ARCH] defines a label
199	   distribution protocol as a set of procedures by which one Label
200	   Switched Router (LSR) informs another of the meaning of labels used
201	   to forward traffic between and through them.

203	   The MPLS architecture does not assume a single label distribution
204	   protocol.  In fact, a number of different label distribution
205	   protocols are being standardized.  Existing protocols have been
206	   extended so that label distribution can be piggybacked on them.  New
207	   protocols have also been defined for the explicit purpose of
208	   distributing labels.  Section 2.29 of the architecture [ARCH]
209	   discusses some of the considerations when choosing a label
210	   distribution protocol for use in particular MPLS applications such as
211	   Traffic Engineering [TE].

213	   The Label Distribution Protocol (LDP) defined in this document is a
214	   new protocol defined for distributing labels.  It is the set of
215	   procedures and messages by which Label Switched Routers (LSRs)
216	   establish Label Switched Paths (LSPs) through a network by mapping
217	   network-layer routing information directly to data-link layer
218	   switched paths.  These LSPs may have an endpoint at a directly
219	   attached neighbor (comparable to IP hop-by-hop forwarding), or may
220	   have an endpoint at a network egress node, enabling switching via all
221	   intermediary nodes.

223	   LDP associates a Forwarding Equivalence Class (FEC) [ARCH] with each
224	   LSP it creates. The FEC associated with an LSP specifies which
225	   packets are "mapped" to that LSP.  LSPs are extended through a
226	   network as each LSR "splices" incoming labels for a FEC to the
227	   outgoing label assigned to the next hop for the given FEC.

229	   This document assumes familiarity with the MPLS architecture [ARCH].
230	   Note that [ARCH] includes a glossary of MPLS terminology, such as
231	   ingress, label switched path, etc.

233	1.1. LDP Peers

235	   Two LSRs which use LDP to exchange label/FEC mapping information are
236	   known as "LDP Peers" with respect to that information and we speak of
237	   there being an "LDP Session" between them.  A single LDP session
238	   allows each peer to learn the other's label mappings; i.e., the
239	   protocol is bi-directional.

241	1.2. LDP Message Exchange

243	   There are four categories of LDP messages:

245	      1. Discovery messages, used to announce and maintain the presence
246	         of an LSR in a network.

248	      2. Session messages, used to establish, maintain, and terminate
249	         sessions between LDP peers.

251	      3. Advertisement messages, used to create, change, and delete
252	         label mappings for FECs.

254	      4. Notification messages, used to provide advisory information and
255	         to signal error information.

257	   Discovery messages provide a mechanism whereby LSRs indicate their
258	   presence in a network by sending the Hello message periodically.
259	   This is transmitted as a UDP packet to the LDP port at the `all
260	   routers on this subnet' group multicast address.  When an LSR chooses
261	   to establish a session with another LSR learned via the Hello
262	   message, it uses the LDP initialization procedure over TCP transport.
263	   Upon successful completion of the initialization procedure, the two
264	   LSRs are LDP peers, and may exchange advertisement messages.

266	   When to request a label or advertise a label mapping to a peer is
267	   largely a local decision made by an LSR.  In general, the LSR
268	   requests a label mapping from a neighboring LSR when it needs one,
269	   and advertises a label mapping to a neighboring LSR when it wishes
270	   the neighbor to use a label.

272	   Correct operation of LDP requires reliable and in order delivery of
273	   messages.  To satisfy these requirements LDP uses the TCP transport
274	   for session, advertisement and notification messages; i.e., for
275	   everything but the UDP-based discovery mechanism.

277	1.3. LDP Message Structure

279	   All LDP messages have a common structure that uses a Type-Length-
280	   Value (TLV) encoding scheme; see Section "Type-Length-Value"
281	   encoding.  The Value part of a TLV-encoded object, or TLV for short,
282	   may itself contain one or more TLVs.

284	1.4. LDP Error Handling

286	   LDP errors and other events of interest are signaled to an LDP peer
287	   by notification messages.

289	   There are two kinds of LDP notification messages:

291	      1. Error notifications, used to signal fatal errors.  If an LSR
292	         receives an error notification from a peer for an LDP session,
293	         it terminates the LDP session by closing the TCP transport
294	         connection for the session and discarding all label mappings
295	         learned via the session.

297	      2. Advisory notifications, used to pass an LSR information about
298	         the LDP session or the status of some previous message received
299	         from the peer.

301	1.5. LDP Extensibility and Future Compatibility

303	   Functionality may be added to LDP in the future.  It is likely that
304	   future functionality will utilize new messages and object types
305	   (TLVs).  It may be desirable to employ such new messages and TLVs
306	   within a network using older implementations that do not recognize
307	   them.  While it is not possible to make every future enhancement
308	   backwards compatible, some prior planning can ease the introduction
309	   of new capabilities.  This specification defines rules for handling
310	   unknown message types and unknown TLVs for this purpose.

312	2. LDP Operation

314	2.1. FECs

316	   It is necessary to precisely specify which packets may be mapped to
317	   each LSP.  This is done by providing a FEC specification for each
318	   LSP.  The FEC identifies the set of IP packets which may be mapped to
319	   that LSP.

321	   Each FEC is specified as a set of one or more FEC elements.  Each FEC
322	   element identifies a set of packets which may be mapped to the
323	   corresponding LSP.  When an LSP is shared by multiple FEC elements,
324	   that LSP is terminated at (or before) the node where the FEC elements
325	   can no longer share the same path.

327	   Following are the currently defined types of FEC elements.  New
328	   element types may be added as needed:

330	      1. Address Prefix.  This element is an address prefix of any
331	         length from 0 to a full address, inclusive.

333	      2. Host Address.  This element is a full host address.

335	   (We will see below that an Address Prefix FEC element which is a full
336	   address has a different effect than a Host Address FEC element which
337	   has the same address.)

339	   We say that a particular address "matches" a particular address
340	   prefix if and only if that address begins with that prefix.  We also
341	   say that a particular packet matches a particular LSP if and only if
342	   that LSP has an Address Prefix FEC element which matches the packet's
343	   destination address.  With respect to a particular packet and a
344	   particular LSP, we refer to any Address Prefix FEC element which
345	   matches the packet as the "matching prefix".

347	   The procedure for mapping a particular packet to a particular LSP
348	   uses the following rules.  Each rule is applied in turn until the
349	   packet can be mapped to an LSP.

351	     - If there is exactly one LSP which has a Host Address FEC element
352	       that is identical to the packet's destination address, then the
353	       packet is mapped to that LSP.

355	     - If there multiple LSPs, each containing a Host Address FEC
356	       element that is identical to the packet's destination address,
357	       then the packet is mapped to one of those LSPs.  The procedure
358	       for selecting one of those LSPs is beyond the scope of this
359	       document.

361	     - If a packet matches exactly one LSP, the packet is mapped to that
362	       LSP.

364	     - If a packet matches multiple LSPs, it is mapped to the LSP whose
365	       matching prefix is the longest.  If there is no one LSP whose
366	       matching prefix is longest, the packet is mapped to one from the
367	       set of LSPs whose matching prefix is longer than the others.  The
368	       procedure for selecting one of those LSPs is beyond the scope of
369	       this document.

371	     - If it is known that a packet must traverse a particular egress
372	       router, and there is an LSP which has an Address Prefix FEC
373	       element which is an address of that router, then the packet is
374	       mapped to that LSP.  The procedure for obtaining this knowledge
375	       is beyond the scope of this document.

377	   The procedure for determining that a packet must traverse a
378	   particular egress router is beyond the scope of this document.  (As
379	   an example, if one is running a link state routing algorithm, it may
380	   be possible to obtain this information from the link state data base.
381	   As another example, if one is running BGP, it may be possible to
382	   obtain this information from the BGP next hop attribute of the
383	   packet's route.)

385	   It is worth pointing out a few consequences of these rules:

387	     - A packet may be sent on the LSP whose Address Prefix FEC element
388	       is the address of the packet's egress router ONLY if there is no
389	       LSP matching the packet's destination address.

391	     - A packet may match two LSPs, one with a Host Address FEC element
392	       and one with an Address Prefix FEC element.  In this case, the
393	       packet is always assigned to the former.

395	     - A packet which does not match a particular Host Address FEC
396	       element may not be sent on the corresponding LSP, even if the
397	       Host Address FEC element identifies the packet's egress router.

399	2.2. Label Spaces, Identifiers, Sessions and Transport

401	2.2.1. Label Spaces

403	   The notion of "label space" is useful for discussing the assignment
404	   and distribution of labels.  There are two types of label spaces:

406	     - Per interface label space.  Interface-specific incoming labels
407	       are used for interfaces that use interface resources for labels.
408	       An example of such an interface is a label-controlled ATM
409	       interface that uses VCIs as labels, or a Frame Relay interface
410	       that uses DLCIs as labels.

412	       Note that the use of a per interface label space only makes sense
413	       when the LDP peers are "directly connected" over an interface,
414	       and the label is only going to be used for traffic sent over that
415	       interface.

417	     - Per platform label space. Platform-wide incoming labels are used
418	       for interfaces that can share the same labels.

420	2.2.2. LDP Identifiers

422	   An LDP identifier is a six octet quantity used to identify an LSR
423	   label space.  The first four octets encode an IP address assigned to
424	   the LSR, and the last two octets identify a specific label space
425	   within the LSR.  The last two octets of LDP Identifiers for
426	   platform-wide label spaces are always both zero.  This document uses
427	   the following print representation for LDP Identifiers:

429	              <IP address> : <label space id>

431	   e.g., 171.32.27.28:0, 192.0.3.5:2.

433	   Note that an LSR that manages and advertises multiple label spaces
434	   uses a different LDP Identifier for each such label space.

436	   A situation where an LSR would need to advertise more than one label
437	   space to a peer and hence use more than one LDP Identifier occurs
438	   when the LSR has two links to the peer and both are ATM (and use per
439	   interface labels).  Another situation would be where the LSR had two
440	   links to the peer, one of which is ethernet (and uses per platform
441	   labels) and the other of which is ATM.

443	2.2.3. LDP Sessions

445	   LDP sessions exist between LSRs to support label exchange between
446	   them.

448	      When an LSR uses LDP to advertise more than one label space to
449	      another LSR it uses a separate LDP session for each label space.

451	2.2.4. LDP Transport

453	   LDP uses TCP as a reliable transport for sessions.

455	      When multiple LDP sessions are required between two LSRs there is
456	      one TCP session for each LDP session.

458	2.3. LDP Sessions between non-Directly Connected LSRs

460	   LDP sessions between LSRs that are not directly connected at the link
461	   level may be desirable in some situations.

463	   For example, consider a "traffic engineering" application where LSRa
464	   sends traffic matching some criteria via an LSP to non-directly
465	   connected LSRb rather than forwarding the traffic along its normally
466	   routed path.

468	   The path between LSRa and LSRb would include one or more intermediate
469	   LSRs (LSR1,...LSRn).  An LDP session between LSRa and LSRb would
470	   enable LSRb to label switch traffic arriving on the LSP from LSRa by
471	   providing LSRb means to advertise labels for this purpose to LSRa.

473	   In this situation LSRa would apply two labels to traffic it forwards
474	   on the LSP to LSRb: a label learned from LSR1 to forward traffic
475	   along the LSP path from LSRa to LSRb; and a label learned from LSRb
476	   to enable LSRb to label switch traffic arriving on the LSP.

478	   LSRa first adds the label learned via its LDP session with LSRb to
479	   the packet label stack (either by replacing the label on top of the
480	   packet label stack with it if the packet arrives labeled or by
481	   pushing it if the packet arrives unlabeled).  Next, it pushes the
482	   label for the LSP learned from LSR1 onto the label stack.

484	2.4. LDP Discovery

486	   LDP discovery is a mechanism that enables an LSR to discover
487	   potential LDP peers.  Discovery makes it unnecessary to explicitly
488	   configure an LSR's label switching peers.

490	   There are two variants of the discovery mechanism:

492	     - A basic discovery mechanism used to discover LSR neighbors that
493	       are directly connected at the link level.

495	     - An extended discovery mechanism used to locate LSRs that are not
496	       directly connected at the link level.

498	2.4.1. Basic Discovery Mechanism

500	   To engage in LDP Basic Discovery on an interface an LSR periodically
501	   sends LDP Link Hellos out the interface.  LDP Link Hellos are sent as
502	   UDP packets addressed to the well-known LDP discovery port for the
503	   "all routers on this subnet" group multicast address.

505	   An LDP Link Hello sent by an LSR carries the LDP Identifier for the
506	   label space the LSR intends to use for the interface and possibly
507	   additional information.

509	   Receipt of an LDP Link Hello on an interface identifies a "Hello
510	   adjacency" with a potential LDP peer reachable at the link level on
511	   the interface as well as the label space the peer intends to use for
512	   the interface.

514	2.4.2. Extended Discovery Mechanism

516	   LDP sessions between non-directly connected LSRs are supported by LDP
517	   Extended Discovery.

519	   To engage in LDP Extended Discovery an LSR periodically sends LDP
520	   Targeted Hellos to a specific IP address.  LDP Targeted Hellos are
521	   sent as UDP packets addressed to the well-known LDP discovery port at
522	   the specific address.

524	   An LDP Targeted Hello sent by an LSR carries the LDP Identifier for
525	   the label space the LSR intends to use and possibly additional
526	   optional information.

528	   Extended Discovery differs from Basic Discovery in the following
529	   ways:

531	     - A Targeted Hello is sent to a specific IP address rather than to
532	       the "all routers" group multicast address for the outgoing
533	       interface.

535	     - Unlike Basic Discovery, which is symmetric, Extended Discovery is
536	       asymmetric.

538	       One LSR initiates Extended Discovery with another targeted LSR,
539	       and the targeted LSR decides whether to respond to or ignore the
540	       Targeted Hello.  A targeted LSR that chooses to respond does so
541	       by periodically sending Targeted Hellos to the initiating LSR.

543	   Receipt of an LDP Targeted Hello identifies a "Hello adjacency" with
544	   a potential LDP peer reachable at the network level and the label
545	   space the peer intends to use.

547	2.5. Establishing and Maintaining LDP Sessions

549	2.5.1. LDP Session Establishment

551	   The exchange of LDP Discovery Hellos between two LSRs triggers LDP
552	   session establishment.  Session establishment is a two step process:

554	           - Transport connection establishment.
555	           - Session initialization

557	   The following describes establishment of an LDP session between LSRs
558	   LSR1 and LSR2 from LSR1's point of view.  It assumes the exchange of
559	   Hellos specifying label space LSR1:a for LSR1 and label space LSR2:b
560	   for LSR2.

562	2.5.2. Transport Connection Establishment

564	   The exchange of Hellos results in the creation of a Hello adjacency
565	   at LSR1 that serves to bind the link (L) and the label spaces LSR1:a
566	   and LSR2:b.

568	     1.  If LSR1 does not already have an LDP session for the exchange
569	         of label spaces LSR1:a and LSR2:b it attempts to open a TCP
570	         connection for a new LDP session with LSR2.

572	         LSR1 determines the transport addresses to be used at its end
573	         (A1) and LSR2's end (A2) of the LDP TCP connection.  Address A1
574	         is determined as follows:

576	         a.  If LSR1 uses the Transport Address optional object (TLV) in
577	             Hello's it sends to LSR2 to advertise an address, A1 is the
578	             address LSR1 advertises via the optional object;

580	         b.  If LSR1 does not use the Transport Address optional object,
581	             A1 is the source IP address used in Hellos it sends to
582	             LSR2.

584	         Similarly, address A2 is determined as follows:

586	         a.  If LSR2 uses the Transport Address optional object, A2 is
587	             the address LSR2 advertises via the optional object;

589	         b.  If LSR2 does not use the Transport Address optional object,
590	             A2 is the source IP address in Hellos received from LSR2.

592	     2.  LSR1 determines whether it will play the active or passive role
593	         in session establishment by comparing addresses A1 and A2 as
594	         unsigned integers.  If A1 > A2, LSR1 plays the active role;
595	         otherwise it is passive.

597	     3.  If LSR1 is active, it attempts to establish the LDP TCP
598	         connection by connecting to the well-known LDP port at address
599	         A2.  If LSR1 is passive, it waits for LSR2 to establish the LDP
600	         TCP connection to its well-known LDP port.

602	2.5.3. Session Initialization

604	   After LSR1 and LSR2 establish a transport connection they negotiate
605	   session parameters by exchanging LDP Initialization messages.  The
606	   parameters negotiated include LDP protocol version, label
607	   distribution method, timer values, VPI/VCI ranges for label
608	   controlled ATM, DLCI ranges for label controlled Frame Relay, etc.

610	   Successful negotiation completes establishment of an LDP session
611	   between LSR1 and LSR2 for the advertisement of label spaces LSR1:a
612	   and LSR2:b.

614	   The following describes the session initialization from LSR1's point
615	   of view.

617	   After the connection is established, if LSR1 is playing the active
618	   role, it initiates negotiation of session parameters by sending an
619	   Initialization message to LSR2.  If LSR1 is passive, it waits for
620	   LSR2 to initiate the parameter negotiation.

622	   In general when there are multiple links between LSR1 and LSR2 and
623	   multiple label spaces to be advertised by each, the passive LSR
624	   cannot know which label space to advertise over a newly established
625	   TCP connection until it receives the first LDP PDU on the connection.

627	   By waiting for the Initialization message from its peer the passive
628	   LSR can match the label space to be advertised by the peer (as
629	   determined from the LDP Identifier in the PDU header for the
630	   Initialization message) with a Hello adjacency previously created
631	   when Hellos were exchanged.

633	     1.  When LSR1 plays the passive role:

635	         a.  If LSR1 receives an Initialization message it attempts to
636	             match the LDP Identifier carried by the message PDU with a
637	             Hello adjacency.

639	         b.  If there is a matching Hello adjacency, the adjacency
640	             specifies the local label space for the session.

642	             Next LSR1 checks whether the session parameters proposed in
643	             the message are acceptable.  If they are, LSR1 replies with
644	             an Initialization message of its own to propose the
645	             parameters it wishes to use and a KeepAlive message to
646	             signal acceptance of LSR2's parameters.  If the parameters
647	             are not acceptable, LSR1 responds by sending a Session
648	             Rejected/Parameters Error Notification message and closing
649	             the TCP connection.

651	         c.  If LSR1 cannot find a matching Hello adjacency it sends a
652	             Session Rejected/No Hello Error Notification message and
653	             closes the TCP connection.

655	         d.  If LSR1 receives a KeepAlive in response to its
656	             Initialization message, the session is operational from
657	             LSR1's point of view.

659	         e.  If LSR1 receives an Error Notification message, LSR2 has
660	             rejected its proposed session and LSR1 closes the TCP
661	             connection.

663	     2.  When LSR1 plays the active role:

665	         a.  If LSR1 receives an Error Notification message, LSR2 has
666	             rejected its proposed session and LSR1 closes the TCP
667	             connection.

669	         b.  If LSR1 receives an Initialization message, it checks
670	             whether the session parameters are acceptable.  If so, it
671	             replies with a KeepAlive message.  If the session
672	             parameters are unacceptable, LSR1 sends a Session
673	             Rejected/Parameters Error Notification message and closes
674	             the connection.

676	         c.  If LSR1 receives a KeepAlive message, LSR2 has accepted its
677	             proposed session parameters.

679	         d.  When LSR1 has received both an acceptable Initialization
680	             message and a KeepAlive message the session is operational
681	             from LSR1's point of view.

683	       It is possible for a pair of incompatibly configured LSRs that
684	       disagree on session parameters to engage in an endless sequence
685	       of messages as each NAKs the other's Initialization messages with
686	       Error Notification messages.

688	       An LSR must throttle its session setup retry attempts with an
689	       exponential backoff in situations where Initialization messages
690	       are being NAK'd.  It is also recommended that an LSR detecting
691	       such a situation take action to notify an operator.

693	       The session establishment setup attempt following a NAK'd
694	       Initialization message must be delayed no less than 15 seconds,
695	       and subsequent delays must grow to a maximum delay of no less
696	       than 2 minutes.  The specific session establishment action that
697	       must be delayed is the attempt to open the session transport
698	       connection by the LSR playing the active role.

700	       The throttled sequence of Initialization NAKs is unlikely to
701	       cease until operator intervention reconfigures one of the LSRs.
702	       After such a configuration action there is no further need to
703	       throttle subsequent session establishment attempts (until their
704	       initialization messages are NAK'd).

706	       Due to the asymmetric nature of session establishment,
707	       reconfiguration of the passive LSR will go unnoticed by the
708	       active LSR without some further action.  Section "Hello Message"
709	       describes an optional mechanism an LSR can use to signal
710	       potential LDP peers that it has been reconfigured.

712	2.5.4. Initialization State Machine

714	   It is convenient to describe LDP session negotiation behavior in
715	   terms of a state machine.  We define the LDP state machine to have
716	   five possible states and present the behavior as a state transition
717	   table and as a state transition diagram.

719	               Session Initialization State Transition Table

721	         STATE         EVENT                               NEW STATE

723	         NON EXISTENT  Session TCP connection established  INITIALIZED
724	                       established

726	         INITIALIZED   Transmit Initialization msg         OPENSENT
727	                             (Active Role)

729	                       Receive acceptable                  OPENREC
730	                             Initialization msg
731	                             (Passive Role )
732	                         Action: Transmit Initialization
733	                                 msg and KeepAlive msg

735	                       Receive Any other LDP msg           NON EXISTENT
736	                         Action: Transmit Error Notification msg
737	                                 (NAK) and close transport connection

739	         OPENREC       Receive KeepAlive msg               OPERATIONAL

741	                       Receive Any other LDP msg           NON EXISTENT
742	                         Action: Transmit Error Notification msg
743	                                 (NAK) and close transport connection

745	         OPENSENT      Receive acceptable                  OPENREC
746	                             Initialization msg
747	                         Action: Transmit KeepAlive msg

749	                       Receive Any other LDP msg           NON EXISTENT
750	                         Action: Transmit Error Notification msg
751	                                 (NAK) and close transport connection

753	         OPERATIONAL   Receive Shutdown msg                NON EXISTENT
754	                         Action: Transmit Shutdown msg and
755	                                 close transport connection

757	                       Receive other LDP msgs              OPERATIONAL

759	                       Timeout                             NON EXISTENT
760	                         Action: Transmit Shutdown msg and
761	                                 close transport connection

763	              Session Initialization State Transition Diagram

765	                                    +------------+
766	                                    |            |
767	                      +------------>|NON EXISTENT|<--------------------+
768	                      |             |            |                     |
769	                      |             +------------+                     |
770	                      | Session        |    ^                          |
771	                      |   connection   |    |                          |
772	                      |   established  |    | Rx any LDP msg except    |
773	                      |                V    |   Init msg or Timeout    |
774	                      |            +-----------+                       |
775	         Rx Any other |            |           |                       |
776	            msg or    |            |INITIALIZED|                       |
777	            Timeout / |        +---|           |-+                     |
778	         Tx NAK msg   |        |   +-----------+ |                     |
779	                      |        | (Passive Role)  | (Active Role)       |
780	                      |        | Rx Acceptable   | Tx Init msg         |
781	                      |        |    Init msg /   |                     |
782	                      |        | Tx Init msg     |                     |
783	                      |        |    Tx KeepAlive |                     |
784	                      |        V    msg          V                     |
785	                      |   +-------+        +--------+                  |
786	                      |   |       |        |        |                  |
787	                      +---|OPENREC|        |OPENSENT|----------------->|
788	                      +---|       |        |        | Rx Any other msg |
789	                      |   +-------+        +--------+    or Timeout    |
790	         Rx KeepAlive |        ^                |     Tx NAK msg       |
791	            msg       |        |                |                      |
792	                      |        |                | Rx Acceptable        |
793	                      |        |                |    Init msg /        |
794	                      |        +----------------+ Tx KeepAlive msg     |
795	                      |                                                |
796	                      |      +-----------+                             |
797	                      +----->|           |                             |
798	                             |OPERATIONAL|                             |
799	                             |           |---------------------------->+
800	                             +-----------+     Rx Shutdown msg
801	                      All other  |   ^            or Timeout /
802	                        LDP msgs |   |         Tx Shutdown msg
803	                                 |   |
804	                                 +---+

806	2.5.5. Maintaining Hello Adjacencies

808	   An LDP session with a peer has one or more Hello adjacencies.

810	   An LDP session has multiple Hello adjacencies when a pair of LSRs is
811	   connected by multiple links that share the same label space; for
812	   example, multiple PPP links between a pair of routers.  In this
813	   situation the Hellos an LSR sends on each such link carry the same
814	   LDP Identifier.

816	   LDP includes mechanisms to monitor the necessity of an LDP session
817	   and its Hello adjacencies.

819	   LDP uses the regular receipt of LDP Discovery Hellos to indicate a
820	   peer's intent to use the label space identified by the Hello.  An LSR
821	   maintains a hold timer with each Hello adjacency which it restarts
822	   when it receives a Hello that matches the adjacency.  If the timer
823	   expires without receipt of a matching Hello from the peer, LDP
824	   concludes that the peer no longer wishes to label switch using that
825	   label space for that link (or target, in the case of Targeted Hellos)
826	   or that the peer has failed.  The LSR then deletes the Hello
827	   adjacency.  When the last Hello adjacency for a LDP session is
828	   deleted, the LSR terminates the LDP session by sending a Notification
829	   message and closing the transport connection.

831	2.5.6. Maintaining LDP Sessions

833	   LDP includes mechanisms to monitor the integrity of the LDP session.

835	   LDP uses the regular receipt of LDP PDUs on the session transport
836	   connection to monitor the integrity of the session.  An LSR maintains
837	   a KeepAlive timer for each peer session which it resets whenever it
838	   receives an LDP PDU from the session peer.  If the KeepAlive timer
839	   expires without receipt of an LDP PDU from the peer the LSR concludes
840	   that the transport connection is bad or that the peer has failed, and
841	   it terminates the LDP session by closing the transport connection.

843	   After an LDP session has been established, an LSR must arrange that
844	   its peer receive an LDP PDU from it at least every KeepAlive time
845	   period to ensure the peer restarts the session KeepAlive timer.  The
846	   LSR may send any protocol message to meet this requirement.  In
847	   circumstances where an LSR has no other information to communicate to
848	   its peer, it sends a KeepAlive message.

850	   An LSR may choose to terminate an LDP session with a peer at any
851	   time. Should it choose to do so, it informs the peer with a Shutdown
852	   message.

854	2.6. Label Distribution and Management

856	   The MPLS architecture [ARCH] allows an LSR to distribute a FEC label
857	   binding in response to an explicit request from another LSR.  This is
858	   known as Downstream On Demand label distribution.  It also allows an
859	   LSR to distribute label bindings to LSRs that have not explicitly
860	   requested them.  This is known as Downstream Unsolicited label
861	   distribution.

863	   Both of these label distribution techniques may be used in the same
864	   network at the same time.  However, for any given LDP session, each
865	   LSR must be aware of the label distribution method used by its peer
866	   in order to avoid situations where one peer using Downstream
867	   Unsolicited label distribution assumes its peer is also.  See Section
868	   "Downstream on Demand label Advertisement".

870	2.6.1. Label Distribution Control Mode

872	   The behavior of the initial setup of LSPs is determined by whether
873	   the LSR is operating with independent or ordered LSP control.  An LSR
874	   may support both types of control as a configurable option.

876	2.6.1.1. Independent Label Distribution Control

878	   When using independent LSP control, each LSR may advertise label
879	   mappings to its neighbors at any time it desires.  For example, when
880	   operating in independent Downstream on Demand mode, an LSR may answer
881	   requests for label mappings immediately, without waiting for a label
882	   mapping from the next hop.  When operating in independent Downstream
883	   Unsolicited mode, an LSR may advertise a label mapping for a FEC to
884	   its neighbors whenever it is prepared to label-switch that FEC.

886	   A consequence of using independent mode is that an upstream label can
887	   be advertised before a downstream label is received.

889	2.6.1.2. Ordered Label Distribution Control

891	   When using LSP ordered control, an LSR may initiate the transmission
892	   of a label mapping only for a FEC for which it has a label mapping
893	   for the FEC next hop, or for which the LSR is the egress. For each
894	   FEC for which the LSR is not the egress and no mapping exists, the
895	   LSR MUST wait until a label from a downstream LSR is received before
896	   mapping the FEC and passing corresponding labels to upstream LSRs.

898	   An LSR may be an egress for some FECs and a non-egress for others.

900	   An LSR may act as an egress LSR, with respect to a particular FEC,
901	   under any of the following conditions:

903	      1. The FEC refers to the LSR itself (including one of its directly
904	         attached interfaces).

906	      2. The next hop router for the FEC is outside of the Label
907	         Switching Network.

909	      3. FEC elements are reachable by crossing a routing domain
910	         boundary, such as another area for OSPF summary networks, or
911	         another autonomous system for OSPF AS externals and BGP routes
912	         [rfc1583] [rfc1771].

914	   Note that whether an LSR is an egress for a given FEC may change over
915	   time, depending on the state of the network and LSR configuration
916	   settings.

918	2.6.2. Label Retention Mode

920	2.6.2.1. Conservative Label Retention Mode

922	   In Downstream Unsolicited advertisement mode, label mapping
923	   advertisements for all routes may be received from all peer LSRs.
924	   When using conservative label retention, advertised label mappings
925	   are retained only if they will be used to forward packets (i.e., if
926	   they are received from a valid next hop according to routing).  If
927	   operating in Downstream on Demand mode, an LSR will request label
928	   mappings only from the next hop LSR according to routing. Since
929	   Downstream on Demand mode is primarily used when label conservation
930	   is desired (e.g., an ATM switch with limited cross connect space), it
931	   is typically used with the conservative label retention mode.

933	   The main advantage of the conservative mode is that only the labels
934	   that are required for the forwarding of data are allocated and
935	   maintained.  This is particularly important in LSRs where the label
936	   space is inherently limited, such as in an ATM switch.  A
937	   disadvantage of the conservative mode is that if routing changes the
938	   next hop for a given destination, a new label must be obtained from
939	   the new next hop before labeled packets can be forwarded.

941	2.6.2.2. Liberal Label Retention Mode

943	   In Downstream Unsolicited advertisement mode, label mapping
944	   advertisements for all routes may be received from all LDP peers.
945	   When using liberal label retention, every label mappings received
946	   from a peer LSR is retained regardless of whether the LSR is the next
947	   hop for the advertised mapping.  When operating in Downstream on
948	   Demand mode with liberal label retention, an LSR might choose to
949	   request label mappings for all known prefixes from all peer LSRs.
950	   Note, however, that Downstream on Demand mode is typically used by
951	   devices such as ATM switch-based LSRs for which the conservative
952	   approach is recommended.

954	   The main advantage of the liberal label retention mode is that
955	   reaction to routing changes can be quick because labels already
956	   exist.  The main disadvantage of the liberal mode is that unneeded
957	   label mappings are distributed and maintained.

959	2.6.3. Label Advertisement Mode

961	   Each interface on an LSR is configured to operate in either
962	   Downstream Unsolicited or Downstream on Demand advertisement mode.
963	   LSRs exchange advertisement modes during initialization.  The major
964	   difference between Downstream Unsolicited and Downstream on Demand
965	   modes is in which LSR takes responsibility for initiating mapping
966	   requests and mapping advertisements.

968	2.7. LDP Identifiers and Next Hop Addresses

970	   An LSR maintains learned labels in a Label Information Base (LIB).
971	   When operating in Downstream Unsolicited mode, the LIB entry for an
972	   address prefix associates a collection of (LDP Identifier, label)
973	   pairs with the prefix, one such pair for each peer advertising a
974	   label for the prefix.

976	   When the next hop for a prefix changes the LSR must retrieve the
977	   label advertised by the new next hop from the LIB for use in
978	   forwarding.  To retrieve the label the LSR must be able to map the
979	   next hop address for the prefix to an LDP Identifier.

981	   Similarly, when the LSR learns a label for a prefix from an LDP peer,
982	   it must be able to determine whether that peer is currently a next
983	   hop for the prefix to determine whether it needs to start using the
984	   newly learned label when forwarding packets that match the prefix.
985	   To make that decision the LSR must be able to map an LDP Identifier
986	   to the peer's addresses to check whether any are a next hop for the
987	   prefix.

989	   To enable LSRs to map between a peer LDP identifier and the peer's
990	   addresses, LSRs advertise their addresses using LDP Address and
991	   Withdraw Address messages.

993	   An LSR sends an Address message to advertise its addresses to a peer.
994	   An LSR sends a Withdraw Address message to withdraw previously
995	   advertised addresses from a peer

997	2.8. Loop Detection

999	   Loop detection is a configurable option which provides a mechanism
1000	   for finding looping LSPs and for preventing Label Request messages
1001	   from looping in the presence of non-merge capable LSRs.

1003	   The mechanism makes use of Path Vector and Hop Count TLVs carried by
1004	   Label Request and Label Mapping messages.  It builds on the following
1005	   basic properties of these TLVs:

1007	     - A Path Vector TLV contains a list of the LSRs that its containing
1008	       message has traversed.  An LSR is identified in a Path Vector
1009	       list by its unique LSR Identifier (Id), which is the IP address
1010	       component of its LDP Identifier.  When an LSR propagates a
1011	       message containing a Path Vector TLV it adds its LSR Id to the
1012	       Path Vector list.  An LSR that receives a message with a Path
1013	       Vector that contains its LSR Id detects that the message has
1014	       traversed a loop.  LDP supports the notion of a maximum allowable
1015	       Path Vector length; an LSR that detects a Path Vector has reached
1016	       the maximum length behaves as if the containing message has
1017	       traversed a loop.

1019	     - A Hop Count TLV contains a count of the LSRS that the containing
1020	       message has traversed.  When an LSR propagates a message
1021	       containing a Hop Count TLV it increments the count.  An LSR that
1022	       detects a Hop Count has reached a configured maximum value
1023	       behaves as if the containing message has traversed a loop.  By
1024	       convention a count of 0 is interpreted to mean the hop count is
1025	       unknown.  Incrementing an unknown hop count value results in an
1026	       unknown hop count value (0).

1028	   The following paragraphs describes LDP loop detection procedures.  In
1029	   these paragraphs, "MUST" means "MUST if configured for loop
1030	   detection".  The paragraphs specify messages that must carry Path
1031	   Vector and Hop Count TLVs.  Note that the Hop Count TLV and its
1032	   procedures are used without the Path Vector TLV in situations when
1033	   loop detection is not configured (see [ATM] and [FR]).

1035	2.8.1. Label Request Message

1037	   The use of the Path Vector TLV and Hop Count TLV prevent Label
1038	   Request messages from looping in environments that include non-merge
1039	   capable LSRs.

1041	   The rules that govern use of the Hop Count TLV in Label Request
1042	   messages by LSR R when Loop Detection is enabled are the following:

1044	   - The Label Request message MUST include a Hop Count TLV.

1046	   - If R is sending the Label Request because it is a FEC ingress, it
1047	     MUST include a Hop Count TLV with hop count value 1.

1049	   - If R is sending the Label Request as a result of having received a
1050	     Label Request from an upstream LSR, and if the received Label
1051	     Request contains a Hop Count TLV, R MUST increment the received hop
1052	     count value by 1 and MUST pass the resulting value in a Hop Count
1053	     TLV to its next hop along with the Label Request message;

1055	   The rules that govern use of the Path Vector TLV in Label Request
1056	   messages by LSR R when Loop Detection is enabled are the following:

1058	   - If R is sending the Label Request because it is a FEC ingress, then
1059	     if R is non-merge capable, it MUST include a Path Vector TLV of
1060	     length 1 containing its own LSR Id.

1062	   - If R is sending the Label Request as a result of having received a
1063	     Label Request from an upstream LSR, then if the received Label
1064	     Request contains a Path Vector TLV or if R is non-merge capable:

1066	         R MUST add its own LSR Id to the Path Vector, and MUST pass the
1067	         resulting Path Vector to its next hop along with the Label
1068	         Request message.  If the Label Request contains no Path Vector
1069	         TLV, R MUST include a Path Vector TLV of length 1 containing
1070	         its own LSR Id.

1072	   Note that if R receives a Label Request message for a particular FEC,
1073	   and R has previously sent a Label Request message for that FEC to its
1074	   next hop and has not yet received a reply, and if R intends to merge
1075	   the newly received Label Request with the existing outstanding Label
1076	   Request, then R does not propagate the Label Request to the next hop.

1078	   If R receives a Label Request message from its next hop with a Hop
1079	   Count TLV which exceeds the configured maximum value, or with a Path
1080	   Vector TLV containing its own LSR Id or which exceeds the maximum
1081	   allowable length, then R detects that the Label Request message has
1082	   traveled in a loop.

1084	   When R detects a loop, it MUST send a Loop Detected Notification
1085	   message to the source of the Label Request message and drop the Label
1086	   Request message.

1088	2.8.2. Label Mapping Message

1090	   The use of the Path Vector TLV and Hop Count TLV in the Label Mapping
1091	   message provide a mechanism to find and terminate looping LSPs.  When
1092	   an LSR receives a Label Mapping message from a next hop, the message
1093	   is propagated upstream as specified below until an ingress LSR is
1094	   reached or a loop is found.

1096	   The rules that govern the use of the Hop Count TLV in Label Mapping
1097	   messages sent by an LSR R when Loop Detection is enabled are the
1098	   following:

1100	   - R MUST include a Hop Count TLV.

1102	   - If R is the egress, the hop count value MUST be 1.

1104	   - If the Label Mapping message is being sent to propagate a Label
1105	     Mapping message received from the next hop to an upstream peer, the
1106	     hop count value MUST be determined as follows:

1108	     o If R is a member of the edge set of an LSR domain whose LSRs do
1109	       not perform 'TTL-decrement' (e.g., an ATM LSR domain or a Frame
1110	       Relay LSR domain) and the upstream peer is within that domain, R
1111	       MUST reset the hop count to 1 before propagating the message.

1113	     o Otherwise, R MUST increment the hop count received from the next
1114	       hop before propagating the message.

1116	   - If the Label Mapping message is not being sent to propagate a Label
1117	     Mapping message, the hop count value MUST be the result of
1118	     incrementing R's current knowledge of the hop count learned from
1119	     previous Label Mapping messages.  Note that this hop count value
1120	     will be unknown if R has not received a Label Mapping message from
1121	     the next hop.

1123	   Any Label Mapping message MAY contain a Path Vector TLV.  The rules
1124	   that govern the mandatory use of the Path Vector TLV in Label Mapping
1125	   messages sent by LSR R when Loop Detection is enabled are the
1126	   following:

1128	   - If R is the egress, the Label Mapping message need not include a
1129	     Path Vector TLV.

1131	   - If R is sending the Label Mapping message to propagate a Label
1132	     Mapping message received from the next hop to an upstream peer,
1133	     then:

1135	       o If R is merge capable and if R has not previously sent a Label
1136	         Mapping message to the upstream peer, then it MUST include a
1137	         Path Vector TLV.

1139	       o If the received message contains an unknown hop count, then R
1140	         MUST include a Path Vector TLV.

1142	       o If R has previously sent a Label Mapping message to the
1143	         upstream peer, then it MUST include a Path Vector TLV if the
1144	         received message reports an LSP hop count increase, a change in
1145	         hop count from unknown to known, or a change from known to
1146	         unknown.

1148	     If the above rules require R include a Path Vector TLV in the Label
1149	     Mapping message, R computes it as follows:

1151	       o If the received Label Mapping message included a Path Vector,
1152	         the Path Vector sent upstream MUST be the result of adding R's
1153	         LSR Id to the received Path Vector.

1155	       o If the received message had no Path Vector, the Path Vector
1156	         sent upstream MUST be a path vector of length 1 containing R's
1157	         LSR Id.

1159	   - If the Label Mapping message is not being sent to propagate a
1160	     received message upstream, the Label Mapping message MUST include a
1161	     Path Vector of length 1 containing R's LSR Id.

1163	   If R receives a Label Mapping message from its next hop with a Hop
1164	   Count TLV which exceeds the configured maximum value, or with a Path
1165	   Vector TLV containing its own LSR Id or which exceeds the maximum
1166	   allowable length, then R detects that the corresponding LSP contains
1167	   a loop.

1169	   When R detects a loop, it MUST stop using the label for forwarding,
1170	   drop the Label Mapping message. and send a Loop Detected Notification
1171	   message to the source of the Label Mapping message.

1173	2.8.3. Discussion

1175	   LSRs which are configured for loop detection are NOT expected to
1176	   store the path vectors as part of the LSP state.

1178	   Note that in a network where only non-merge capable LSRs are present,
1179	   Path Vectors are passed downstream from ingress to egress, and are
1180	   not passed upstream.  Even when merge is supported, Path Vectors need
1181	   not be passed upstream along an LSP which is known to reach the
1182	   egress.  When an LSR experiences a change of next hop, it need pass
1183	   Path Vectors upstream only when it cannot tell from the hop count
1184	   that the change of next hop does not result in a loop.

1186	   In the case of ordered label distribution, Label Mapping messages are
1187	   propagated from egress toward ingress, naturally creating the Path
1188	   Vector along the way.  In the case of independent label distribution,
1189	   an LSR may originate a Label Mapping message for an FEC before
1190	   receiving a Label Mapping message from its downstream peer for that
1191	   FEC.  In this case, the subsequent Label Mapping message for the FEC
1192	   received from the downstream peer is treated as an update to LSP
1193	   attributes, and the Label Mapping message must be propagated
1194	   upstream.  Thus, it is recommended that loop detection be configured
1195	   in conjunction with ordered label distribution, to minimize the
1196	   number of Label Mapping update messages.

1198	   If loop detection is desired in an MPLS domain, then it should be
1199	   turned on in ALL LSRs within that MPLS domain, else loop detection
1200	   will not operate properly.

1202	2.9. Label Distribution for Explicitly Routed LSPs

1204	   Traffic Engineering [TE] is expected to be an important MPLS
1205	   application.  MPLS support for Traffic Engineering uses explicitly
1206	   routed LSPs, which need not follow normally-routed (hop-by-hop) paths
1207	   as determined by destination-based routing protocols.  CR-LDP [CRLDP]
1208	   defines extensions to LDP to use LDP to set up explicitly routed
1209	   LSPs.

1211	3. Protocol Specification

1213	   Previous sections that describe LDP operation have discussed
1214	   scenarios that involve the exchange of messages among LDP peers.
1215	   This section specifies the message encodings and procedures for
1216	   processing the messages.

1218	   LDP message exchanges are accomplished by sending LDP protocol data
1219	   units (PDUs) over LDP session TCP connections.

1221	   Each LDP PDU can carry one or more LDP messages.  Note that the
1222	   messages in an LDP PDU need not be related to one another.  For
1223	   example, a single PDU could carry a message advertising FEC-label
1224	   bindings for several FECs, another message requesting label bindings
1225	   for several other FECs, and a third notification message signaling
1226	   some event.

1228	3.1. LDP PDUs

1230	   Each LDP PDU is an LDP header followed by one or more LDP messages.
1231	   The LDP header is:

1233	    0                   1                   2                   3
1234	    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
1235	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1236	   |  Version                      |         PDU Length            |
1237	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1238	   |                         LDP Identifier                        |
1239	   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1240	   |                               |
1241	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1243	   Version
1244	     Two octet unsigned integer containing the version number of the
1245	     protocol.  This version of the specification specifies LDP protocol
1246	     version 1.

1248	   PDU Length
1249	     Two octet integer specifying the total length of this PDU in
1250	     octets, excluding the Version and PDU Length fields.

1252	     The maximum allowable PDU Length is negotiable when an LDP session
1253	     is initialized.  Prior to completion of the negotiation the maximum
1254	     allowable length is 4096 bytes.

1256	   LDP Identifier
1257	     Six octet field that uniquely identifies the label space of the
1258	     sending LSR for which this PDU applies.  The first four octets
1259	     encode an IP address assigned to the LSR.  This address should be
1260	     the router-id, also used to identify the LSR in loop detection Path
1261	     Vectors.  The last two octets identify a label space within the
1262	     LSR.  For a platform-wide label space, these should both be zero.

1264	   Note that there is no alignment requirement for the first octet of an
1265	   LDP PDU.

1267	3.2. LDP Procedures

1269	   LDP defines messages, TLVs and procedures in the following areas:

1271	     - Peer discovery;
1272	     - Session management;
1273	     - Label distribution;
1274	     - Notification of errors and advisory information.

1276	   The sections that follow describe the message and TLV encodings for
1277	   these areas and the procedures that apply to them.

1279	   The label distribution procedures are complex and are difficult to
1280	   describe fully, coherently and unambiguously as a collection of
1281	   separate message and TLV specifications.

1283	   Appendix A, "LDP Label Distribution Procedures", describes the label
1284	   distribution procedures in terms of label distribution events that
1285	   may occur at an LSR and how the LSR must respond.  Appendix A is the
1286	   specification of LDP label distribution procedures.  If a procedure
1287	   described elsewhere in this document conflicts with Appendix A,
1288	   Appendix A specifies LDP behavior.

1290	3.3. Type-Length-Value Encoding

1292	   LDP uses a Type-Length-Value (TLV) encoding scheme to encode much of
1293	   the information carried in LDP messages.

1295	   An LDP TLV is encoded as a 2 octet field that uses 14 bits to specify
1296	   a Type and 2 bits to specify behavior when an LSR doesn't recognize
1297	   the Type, followed by a 2 octet Length Field, followed by a variable
1298	   length Value field.

1300	    0                   1                   2                   3
1301	    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
1302	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1303	   |U|F|        Type               |            Length             |
1304	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1305	   |                                                               |
1306	   |                             Value                             |
1307	   ~                                                               ~
1308	   |                                                               |
1309	   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1310	   |                               |
1311	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1313	   U bit
1314	     Unknown TLV bit.  Upon receipt of an unknown TLV, if U is clear
1315	     (=0), a notification must be returned to the message originator and
1316	     the entire message must be ignored; if U is set (=1), the unknown
1317	     TLV is silently ignored and the rest of the message is processed as
1318	     if the unknown TLV did not exist.  The sections following that
1319	     define TLVs specify a value for the U-bit.

1321	   F bit
1322	     Forward unknown TLV bit.  This bit applies only when the U bit is
1323	     set and the LDP message containing the unknown TLV is to be
1324	     forwarded.  If F is clear (=0), the unknown TLV is not forwarded
1325	     with the containing message; if F is set (=1), the unknown TLV is
1326	     forwarded with the containing message.  The sections following that
1327	     define TLVs specify a value for the F-bit.

1329	   Type
1330	     Encodes how the Value field is to be interpreted.

1332	   Length
1333	     Specifies the length of the Value field in octets.

1335	   Value
1336	     Octet string of Length octets that encodes information to be
1337	     interpreted as specified by the Type field.

1339	   Note that there is no alignment requirement for the first octet of a
1340	   TLV.

1342	   Note that the Value field itself may contain TLV encodings.  That is,
1343	   TLVs may be nested.

1345	   The TLV encoding scheme is very general.  In principle, everything
1346	   appearing in an LDP PDU could be encoded as a TLV.  This
1347	   specification does not use the TLV scheme to its full generality.  It
1348	   is not used where its generality is unnecessary and its use would
1349	   waste space unnecessarily.  These are usually places where the type
1350	   of a value to be encoded is known, for example by its position in a
1351	   message or an enclosing TLV, and the length of the value is fixed or
1352	   readily derivable from the value encoding itself.

1354	   Some of the TLVs defined for LDP are similar to one another.  For
1355	   example, there is a Generic Label TLV, an ATM Label TLV, and a Frame
1356	   Relay TLV; see Sections "Generic Label TLV", "ATM Label TLV", and
1357	   "Frame Relay TLV".

1359	   While it is possible to think about TLVs related in this way in terms
1360	   of a TLV type that specifies a TLV class and a TLV subtype that
1361	   specifies a particular kind of TLV within that class, this
1362	   specification does not formalize the notion of a TLV subtype.

1364	   The specification assigns type values for related TLVs, such as the
1365	   label TLVs, from a contiguous block in the 16-bit TLV type number
1366	   space.

1368	   Section "TLV Summary" lists the TLVs defined in this version of the
1369	   protocol and the section in this document that describes each.

1371	3.4. TLV Encodings for Commonly Used Parameters

1373	   There are several parameters used by more than one LDP message.  The
1374	   TLV encodings for these commonly used parameters are specified in
1375	   this section.

1377	3.4.1. FEC TLV

1379	   Labels are bound to Forwarding Equivalence Classes (FECs).  a FEC is
1380	   a list of one or more FEC elements.  The FEC TLV encodes FEC items.

1382	   Its encoding is:

1384	    0                   1                   2                   3
1385	    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
1386	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1387	   |0|0| FEC (0x0100)              |      Length                   |
1388	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1389	   |                        FEC Element 1                          |
1390	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1391	   |                                                               |
1392	   ~                                                               ~
1393	   |                                                               |
1394	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1395	   |                        FEC Element n                          |
1396	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1398	   FEC Element 1 to FEC Element n
1399	     There are several types of FEC elements; see Section "FECs".  The
1400	     FEC element encoding depends on the type of FEC element.

1402	     A FEC Element value is encoded as a 1 octet field that specifies
1403	     the element type, and a variable length field that is the type-
1404	     dependent element value.  Note that while the representation of the
1405	     FEC element value is type-dependent, the FEC element encoding
1406	     itself is one where standard LDP TLV encoding is not used.

1408	     The FEC Element value encoding is:

1410	         FEC Element       Type      Value
1411	         type name

1413	           Wildcard        0x01      No value; i.e., 0 value octets;
1414	                                         see below.
1415	           Prefix          0x02      See below.
1416	           Host Address    0x03      Full host address; see below.

1418	     Note that this version of LDP supports the use of multiple FEC
1419	     Elements per FEC for the Label Mapping message only.  The use of
1420	     multiple FEC Elements in other messages is not permitted in this
1421	     version, and is a subject for future study.

1423	     Wildcard FEC Element
1424	       To be used only in the Label Withdraw and Label Release Messages.
1425	       Indicates the withdraw/release is to be applied to all FECs
1426	       associated with the label within the following label TLV.  Must
1427	       be the only FEC Element in the FEC TLV.

1429	     Prefix FEC Element value encoding:

1431	      0                   1                   2                   3
1432	      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
1433	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1434	     |  Prefix (2)   |     Address Family            |     PreLen    |
1435	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1436	     |                     Prefix                                    |
1437	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1439	       Address Family
1440	         Two octet quantity containing a value from ADDRESS FAMILY
1441	         NUMBERS in [rfc1700] that encodes the address family for the
1442	         address prefix in the Prefix field.

1444	       PreLen
1445	         One octet unsigned integer containing the length in bits of the
1446	         address prefix that follows.  A length of zero indicates a
1447	         prefix that matches all addresses (the default destination); in
1448	         this case the Prefix itself is zero octets).

1450	       Prefix
1451	         An address prefix encoded according to the Address Family
1452	         field, whose length, in bits, was specified in the PreLen
1453	         field, padded to a byte boundary.

1455	     Host Address FEC Element encoding:

1457	      0                   1                   2                   3
1458	      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
1459	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1460	     | Host Addr (3) |     Address Family            | Host Addr Len |
1461	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1462	     |                                                               |
1463	     |                     Host Addr                                 |
1464	     |                                                               |
1465	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1467	       Address Family
1468	         Two octet quantity containing a value from ADDRESS FAMILY
1469	         NUMBERS in [rfc1700] that encodes the address family for the
1470	         address prefix in the Prefix field.

1472	       Host Addr Len
1473	         Length of the Host address in octets.

1475	       Host Addr
1476	         An address encoded according to the Address Family field.

1478	3.4.1.1. FEC Procedures

1480	   If in decoding a FEC TLV an LSR encounters a FEC Element type it
1481	   cannot decode, it should stop decoding the FEC TLV, abort processing
1482	   the message containing the TLV, and send an Notification message to
1483	   its LDP peer signaling an error.

1485	3.4.2. Label TLVs

1487	   Label TLVs encode labels.  Label TLVs are carried by the messages
1488	   used to advertise, request, release and withdraw label mappings.

1490	   There are several different kinds of Label TLVs which can appear in
1491	   situations that require a Label TLV.

1493	3.4.2.1. Generic Label TLV

1495	   An LSR uses Generic Label TLVs to encode labels for use on links for
1496	   which label values are independent of the underlying link technology.
1497	   Examples of such links are PPP and Ethernet.

1499	    0                   1                   2                   3
1500	    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
1501	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1502	   |0|0| Generic Label (0x0200)    |      Length                   |
1503	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1504	   |     Label                                                     |
1505	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1507	   Label
1508	     This is a 20-bit label value as specified in [ENCAP] represented as
1509	     a 20-bit number in a 4 octet field.

1511	3.4.2.2. ATM Label TLV

1513	   An LSR uses ATM Label TLVs to encode labels for use on ATM links.

1515	    0                   1                   2                   3
1516	    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
1517	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1518	   |0|0| ATM Label (0x0201)        |         Length                |
1519	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1520	   |Res| V |          VPI          |         VCI                   |
1521	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1523	   Res
1524	     This field is reserved. It must be set to zero on transmission and
1525	     must be ignored on receipt.

1527	   V-bits
1528	     Two-bit switching indicator.  If V-bits is 00, both the VPI and VCI
1529	     are significant.  If V-bits is 01, only the VPI field is
1530	     significant.  If V-bit is 10, only the VCI is significant.

1532	   VPI
1533	     Virtual Path Identifier. If VPI is less than 12-bits it should be
1534	     right justified in this field and preceding bits should be set to
1535	     0.

1537	   VCI
1538	     Virtual Channel Identifier. If the VCI is less than 16- bits, it
1539	     should be right justified in the field and the preceding bits must
1540	     be set to 0. If Virtual Path switching is indicated in the V-bits
1541	     field, then this field must be ignored by the receiver and set to 0
1542	     by the sender.

1544	3.4.2.3. Frame Relay Label TLV

1546	   An LSR uses Frame Relay Label TLVs to encode labels for use on Frame
1547	   Relay links.

1549	    0                   1                   2                   3
1550	    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
1551	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1552	   |0|0| Frame Relay Label (0x0202)|       Length                  |
1553	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1554	   | Reserved    |Len|                     DLCI                    |
1555	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1557	   Res
1558	     This field is reserved. It must be set to zero on transmission and
1559	     must be ignored on receipt.

1561	   Len
1562	     This field specifies the number of bits of the DLCI. The following
1563	     values are supported:

1565	        0 = 10 bits DLCI
1566	        1 = 17 bits DLCI
1567	        2 = 23 bits DLCI

1569	   DLCI
1570	     The Data Link Connection Identifier.  Refer to [FR] for the label
1571	     values and formats.

1573	3.4.3. Address List TLV

1575	   The Address List TLV appears in Address and Address Withdraw
1576	   messages.

1578	   Its encoding is:

1580	    0                   1                   2                   3
1581	    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
1582	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1583	   |0|0| Address List (0x0101)     |      Length                   |
1584	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1585	   |     Address Family            |                               |
1586	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
1587	   |                                                               |
1588	   |                        Addresses                              |
1589	   ~                                                               ~
1590	   |                                                               |
1591	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1593	   Address Family
1594	     Two octet quantity containing a value from ADDRESS FAMILY NUMBERS
1595	     in [rfc1700] that encodes the addresses contained in the Addresses
1596	     field.

1598	   Addresses
1599	     A list of addresses from the specified Address Family.  The
1600	     encoding of the individual addresses depends on the Address Family.

1602	     The following address encodings are defined by this version of the
1603	     protocol:

1605	         Address Family      Address Encoding

1607	         IPv4                4 octet full IPv4 address

1609	3.4.4. Hop Count TLV

1611	   The Hop Count TLV appears as an optional field in messages that set
1612	   up LSPs.  It calculates the number of LSR hops along an LSP as the
1613	   LSP is being setup.

1615	   Note that setup procedures for LSPs that traverse ATM and Frame Relay
1616	   links require use of the Hop Count TLV (see [ATM] and [FR]).

1618	    0                   1                   2                   3
1619	    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
1620	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1621	   |0|0| Hop Count (0x0103)        |      Length                   |
1622	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1623	   |     HC Value  |
1624	   +-+-+-+-+-+-+-+-+

1626	   HC Value
1627	     1 octet unsigned integer hop count value.

1629	3.4.4.1. Hop Count Procedures

1631	   During setup of an LSP an LSR R may receive a Label Mapping or Label
1632	   Request message for the LSP that contains the Hop Count TLV.  If it
1633	   does, it should record the hop count value.

1635	   If LSR R then propagates the Label Mapping message for the LSP to an
1636	   upstream peer or the Label Request message to a downstream peer to
1637	   continue the LSP setup, it must must determine a hop count to include
1638	   in the propagated message as follows:

1640	   - If the message is a Label Request message, R must increment the
1641	     received hop count;

1643	   - If the message is a Label Mapping message, R determines the hop
1644	     count as follows:

1646	     o If R is a member of the edge set of an LSR domain whose LSRs do
1647	       not perform 'TTL-decrement' and the upstream peer is within that
1648	       domain, R must reset the hop count to 1 before propagating the
1649	       message.

1651	     o Otherwise, R must increment the received hop count.

1653	   The first LSR in the LSP (ingress for a Label Request message, egress
1654	   for a Label Mapping message) should set the hop count value to 1.

1656	   By convention a value of 0 indicates an unknown hop count.  The
1657	   result of incrementing an unknown hop count is itself an unknown hop
1658	   count (0).

1660	   Use of the unknown hop count value greatly reduces the signaling
1661	   overhead when independent control is used.  When a new LSP is
1662	   established, each LSR starts with unknown hop count.  Addition of a
1663	   new LSR whose hop count is also unknown does not cause a hop count
1664	   update to be propagated upstream since the hop count remains unknown.
1665	   When the egress is finally added to the LSP, then the LSRs propagate
1666	   hop count updates upstream via Label Mapping messages.

1668	   Without use of the unknown hop count, each time a new LSR is added to
1669	   the LSP a hop count update would need to be propagated upstream if
1670	   the new LSR is closer to the egress than any of the other LSRs.
1671	   These updates are useless overhead since they don't reflect the hop
1672	   count to the egress.

1674	   From the perspective of the ingress node, the fact that the hop count
1675	   is unknown implies nothing about whether a packet sent on the LSP
1676	   will actually make it to the egress.  All it implies is that the hop
1677	   count update from the egress has not yet reached the ingress.

1679	   If an LSR receives a message containing a Hop Count TLV, it must
1680	   check the hop count value to determine whether the hop count has
1681	   exceeded its configured maximum allowable value.  If so, it must
1682	   behave as if the containing message has traversed a loop by sending a
1683	   Notification message signaling Loop Detected in reply to the sender
1684	   of the message.

1686	   If Loop Detection is configured, the LSR must follow the procedures
1687	   specified in Section "Loop Detection".

1689	3.4.5. Path Vector TLV

1691	   The Path Vector TLV is used with the Hop Count TLV in Label Request
1692	   and Label Mapping messages to implement the optional LDP loop
1693	   detection mechanism.  See Section "Loop Detection".  Its use in the
1694	   Label Request message records the path of LSRs the request has
1695	   traversed.  Its use in the Label Mapping message records the path of
1696	   LSRs a label advertisement has traversed to setup an LSP.

1698	   Its encoding is:

1700	    0                   1                   2                   3
1701	    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
1702	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1703	   |0|0| Path Vector (0x0104)      |        Length                 |
1704	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1705	   |                            LSR Id 1                           |
1706	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1707	   |                                                               |
1708	   ~                                                               ~
1709	   |                                                               |
1710	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1711	   |                            LSR Id n                           |
1712	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1714	   One or more LSR Ids
1715	     A list of router-ids indicating the path of LSRs the message has
1716	     traversed.  Each LSR Id is the IP address (router-id) component of
1717	     the LDP identifier for the corresponding LSR.  This ensures it is
1718	     unique within the LSR network.

1720	3.4.5.1. Path Vector Procedures

1722	   The Path Vector TLV is carried in Label Mapping and Label Request
1723	   messages when loop detection is configured.

1725	3.4.5.1.1. Label Request Path Vector

1727	   Section "Loop Detection" specifies situations when an LSR must
1728	   include a Path Vector TLV in a Label Request message.

1730	   An LSR that receives a Path Vector in a Label Request message must
1731	   perform the procedures described in Section "Loop Detection".

1733	   If the LSR detects a loop, it must reject the Label Request message.
1734	   The LSR must:

1736	      1. Transmit a Notification message to the sending LSR signaling
1737	         "Loop Detected".

1739	      2. Not propagate the Label Request message further.

1741	   Note that a Label Request message with Path Vector TLV is forwarded
1742	   until:

1744	      1. A loop is found,

1746	      2. The LSP egress is reached,

1748	      3. The maximum Path Vector limit or maximum Hop Count limit is
1749	         reached.  This is treated as if a loop had been detected.

1751	3.4.5.1.2. Label Mapping Path Vector

1753	   Section "Loop Detection" specifies the situations when an LSR must
1754	   include a Path Vector TLV in a Label Mapping message.

1756	   An LSR that receives a Path Vector in a Label Mapping message must
1757	   perform the procedures described in Section "Loop Detection".

1759	   If the LSR detects a loop, it must reject the Label Mapping message
1760	   in order to prevent a forwarding loop.  The LSR must:

1762	      1. Transmit a Notification message to the sending LSR signaling
1763	         "Loop Detected".

1765	      2. Not propagate the message further.

1767	      3. Check whether the Label Mapping message is for an existing LSP.
1768	         If so, the LSR must unsplice any upstream labels which are
1769	         spliced to the downstream label for the FEC.

1771	   Note that a Label Mapping message with a Path Vector TLV is forwarded
1772	   until:

1774	      1. A loop is found,

1776	      2. An LSP ingress is reached, or

1778	      3. The maximum Path Vector or maximum Hop Count limit is reached.
1779	         This is treated as if a loop had been detected.

1781	3.4.6. Status TLV

1783	   Notification messages carry Status TLVs to specify events being
1784	   signaled.

1786	   The encoding for the Status TLV is:

1788	    0                   1                   2                   3
1789	    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
1790	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1791	   |0|0| Status (0x0300)           |      Length                   |
1792	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1793	   |                     Status Code                               |
1794	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1795	   |                     Message ID                                |
1796	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1797	   |      Message Type             |
1798	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1800	   Status Code
1801	     32-bit unsigned integer encoding the event being signaled.  The
1802	     structure of a Status Code is:

1804	      0                   1                   2                   3
1805	      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
1806	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1807	     |E|F|                 Status Data                               |
1808	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1810	     E bit
1811	       Fatal error bit.  If set (=1), this is a fatal error
1812	       notification.  If clear (=0), this is an advisory notification.

1814	     F bit
1815	       Forward bit.  If set (=1), the notification should be forwarded
1816	       to the LSR for the next-hop or previous-hop for the LSP, if any,
1817	       associated with the event being signaled.  If clear (=0), the
1818	       notification should not be forwarded.

1820	     Status Data
1821	       30-bit unsigned integer which specifies the status information.

1823	     This specification defines Status Codes (32-bit unsigned integers
1824	     with the above encoding).

1826	     A Status Code of 0 signals success.

1828	   Message ID
1829	     If non-zero, 32-bit value that identifies the peer message to which
1830	     the Status TLV refers.  If zero, no specific peer message is being
1831	     identified.

1833	   Message Type
1834	     If non-zero, the type of the peer message to which the Status TLV
1835	     refers.  If zero, the Status TLV does not refer to any specific
1836	     message type.

1838	 Note that use of the Status TLV is not limited to Notification
1839	 messages.  A message other than a Notification message may carry a
1840	 Status TLV as an Optional Parameter.  When a message other than a
1841	 Notification carries a Status TLV the U-bit of the Status TLV should be
1842	 set to 1 to indicate that the receiver should silently discard the TLV
1843	 if unprepared to handle it.

1845	3.5. LDP Messages

1847	   All LDP messages have the following format:

1849	    0                   1                   2                   3
1850	    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
1851	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1852	   |U|   Message Type              |      Message Length           |
1853	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1854	   |                     Message ID                                |
1855	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1856	   |                                                               |
1857	   +                                                               +
1858	   |                     Mandatory Parameters                      |
1859	   +                                                               +
1860	   |                                                               |
1861	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1862	   |                                                               |
1863	   +                                                               +
1864	   |                     Optional Parameters                       |
1865	   +                                                               +
1866	   |                                                               |
1867	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1869	   U bit
1870	     Unknown message bit.  Upon receipt of an unknown message, if U is
1871	     clear (=0), a notification is returned to the message originator;
1872	     if U is set (=1), the unknown message is silently ignored.  The
1873	     sections following that define messages specify a value for the U-
1874	     bit.

1876	   Message Type
1877	     Identifies the type of message

1879	   Message Length
1880	     Specifies the cumulative length in octets of the Message ID,
1881	     Mandatory Parameters, and Optional Parameters.

1883	   Message ID
1884	     32-bit value used to identify this message.  Used by the sending
1885	     LSR to facilitate identifying notification messages that may apply
1886	     to this message.  An LSR sending a notification message in response
1887	     to this message should include this Message Id in the notification
1888	     message; see Section "Notification Message".

1890	   Mandatory Parameters
1891	     Variable length set of required message parameters.  Some messages
1892	     have no required parameters.

1894	     For messages that have required parameters, the required parameters
1895	     MUST appear in the order specified by the individual message
1896	     specifications in the sections that follow.

1898	   Optional Parameters
1899	     Variable length set of optional message parameters.  Many messages
1900	     have no optional parameters.

1902	     For messages that have optional parameters, the optional parameters
1903	     may appear in any order.

1905	   Note that there is no alignment requirement for the first octet of an
1906	   LDP message.

1908	   The following message types are defined in this version of LDP:

1910	       Message Name            Section Title

1912	       Notification            "Notification Message"
1913	       Hello                   "Hello Message"
1914	       Initialization          "Initialization Message"
1915	       KeepAlive               "KeepAlive Message"
1916	       Address                 "Address Message"
1917	       Address Withdraw        "Address Withdraw Message"
1918	       Label Mapping           "Label Mapping Message"
1919	       Label Request           "Label Request Message"
1920	       Label Abort Request     "Label Abort Request Message"
1921	       Label Withdraw          "Label Withdraw Message"
1922	       Label Release           "Label Release Message"

1924	   The sections that follow specify the encodings and procedures for
1925	   these messages.

1927	   Some of the above messages are related to one another, for example
1928	   the Label Mapping, Label Request, Label Withdraw, and Label Release
1929	   messages.

1931	   While it is possible to think about messages related in this way in
1932	   terms of a message type that specifies a message class and a message
1933	   subtype that specifies a particular kind of message within that
1934	   class, this specification does not formalize the notion of a message
1935	   subtype.

1937	   The specification assigns type values for related messages, such as
1938	   the label messages, from of a contiguous block in the 16-bit message
1939	   type number space.

1941	3.5.1. Notification Message

1943	   An LSR sends a Notification message to inform an LDP peer of a
1944	   significant event.  A Notification message signals a fatal error or
1945	   provides advisory information such as the outcome of processing an
1946	   LDP message or the state of the LDP session.

1948	   The encoding for the Notification Message is:

1950	    0                   1                   2                   3
1951	    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
1952	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1953	   |0|   Notification (0x0001)     |      Message Length           |
1954	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1955	   |                     Message ID                                |
1956	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1957	   |                     Status (TLV)                              |
1958	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1959	   |                     Optional Parameters                       |
1960	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1962	   Message ID
1963	     32-bit value used to identify this message.

1965	   Status TLV
1966	     Indicates the event being signaled.  The encoding for the Status
1967	     TLV is specified in Section "Status TLV".

1969	   Optional Parameters
1970	     This variable length field contains 0 or more parameters, each
1971	     encoded as a TLV.  The following Optional Parameters are generic
1972	     and may appear in any Notification Message:

1974	         Optional Parameter     Type     Length  Value

1976	         Extended Status        0x0301    4      See below
1977	         Returned PDU           0x0302    var    See below
1978	         Returned Message       0x0303    var    See below

1980	     Other Optional Parameters, specific to the particular event being
1981	     signaled by the Notification Messages may appear.  These are
1982	     described elsewhere.

1984	       Extended Status
1985	         The 4 octet value is an Extended Status Code that encodes
1986	         additional information that supplements the status information
1987	         contained in the Notification Status Code.

1989	       Returned PDU
1990	         An LSR uses this parameter to return part of an LDP PDU to the
1991	         LSR that sent it.  The value of this TLV is the PDU header and
1992	         as much PDU data following the header as appropriate for the
1993	         condition being signaled by the Notification message.

1995	       Returned Message
1996	         An LSR uses this parameter to return part of an LDP message to
1997	         the LSR that sent it.  The value of this TLV is the message
1998	         type and length fields and as much message data following the
1999	         type and length fields as appropriate for the condition being
2000	         signaled by the Notification message.

2002	3.5.1.1. Notification Message Procedures

2004	   If an LSR encounters a condition requiring it to notify its peer with
2005	   advisory or error information it sends the peer a Notification
2006	   message containing a Status TLV that encodes the information and
2007	   optionally additional TLVs that provide more information about the
2008	   event.

2010	   If the condition is one that is a fatal error the Status Code carried
2011	   in the notification will indicate that.  In this case, after sending
2012	   the Notification message the LSR should terminate the LDP session by
2013	   closing the session TCP connection and discard all state associated
2014	   with the session, including all label-FEC bindings learned via the
2015	   session.

2017	   When an LSR receives a Notification message that carries a Status
2018	   Code that indicates a fatal error, it should terminate the LDP
2019	   session immediately by closing the session TCP connection and discard
2020	   all state associated with the session, including all label-FEC
2021	   bindings learned via the session.

2023	3.5.1.2. Events Signaled by Notification Messages

2025	   It is useful for descriptive purpose to classify events signaled by
2026	   Notification Messages into the following categories.

2028	3.5.1.2.1. Malformed PDU or Message

2030	   Malformed LDP PDUs or Messages that are part of the LDP Discovery
2031	   mechanism are handled by silently discarding them.

2033	   An LDP PDU received on a TCP connection for an LDP session is
2034	   malformed if:

2036	     - The LDP Identifier in the PDU header is unknown to the receiver,
2037	       or it is known but is not the LDP Identifier associated by the
2038	       receiver with the LDP peer for this LDP session.  This is a fatal
2039	       error signaled by the Bad LDP Identifier Status Code.

2041	     - The LDP protocol version is not supported by the receiver, or it
2042	       is supported but is not the version negotiated for the session
2043	       during session establishment.  This is a fatal error signaled by
2044	       the Bad Protocol Version Status Code.

2046	     - The PDU Length field is too small (< 14) or too large
2047	       (> maximum PDU length).  This is a fatal error signaled by the
2048	       Bad PDU Length Status Code.  Section "Initialization Message"
2049	       describes how the maximum PDU length for a session is determined.

2051	   An LDP Message is malformed if:

2053	     - The Message Type is unknown.

2055	       If the Message Type is < 0x8000 (high order bit = 0) it is an
2056	       error signaled by the Unknown Message Type Status Code.

2058	       If the Message Type is >= 0x8000 (high order bit = 1) it is
2059	       silently discarded.

2061	     - The Message Length is too large, that is, indicates that the
2062	       message extends beyond the end of the containing LDP PDU.  This
2063	       is a fatal error signaled by the Bad Message Length Status Code.

2065	3.5.1.2.2. Unknown or Malformed TLV

2067	   Malformed TLVs contained in LDP messages that are part of the LDP
2068	   Discovery mechanism are handled by silently discarding the containing
2069	   message.

2071	   A TLV contained in an LDP message received on a TCP connection of an
2072	   LDP is malformed if:

2074	     - The TLV Length is too large, that is, indicates that the TLV
2075	       extends beyond the end of the containing message.  This is a
2076	       fatal error signaled by the Bad TLV Length Status Code.

2078	     - The TLV type is unknown.

2080	       If the TLV type is < 0x8000 (high order bit 0) it is an error
2081	       signaled by the Unknown TLV Status Code.

2083	       If the TLV type is >= 08000 (high order bit 1) the TLV is
2084	       silently dropped.  Section "Unknown TLV in Known Message Type"
2085	       elaborates on this behavior.

2087	     - The TLV Value is malformed.  This occurs when the receiver
2088	       handles the TLV but cannot decode the TLV Value.  This is
2089	       interpreted as indicative of a bug in either the sending or
2090	       receiving LSR.  It is a fatal error signaled by the Malformed TLV
2091	       Value Status Code.

2093	3.5.1.2.3. Session KeepAlive Timer Expiration

2095	   This is a fatal error signaled by the KeepAlive Timer Expired Status
2096	   Code.

2098	3.5.1.2.4. Unilateral Session Shutdown

2100	   This is a fatal event signaled by the Shutdown Status Code.  The
2101	   Notification Message may optionally include an Extended Status TLV to
2102	   provide a reason for the Shutdown.  The sending LSR terminates the
2103	   session immediately after sending the Notification.

2105	3.5.1.2.5. Initialization Message Events

2107	   The session initialization negotiation (see Section "Session
2108	   Initialization") may fail if the session parameters received in the
2109	   Initialization Message are unacceptable.  This is a fatal error.  The
2110	   specific Status Code depends on the parameter deemed unacceptable,
2111	   and is defined in Sections "Initialization Message".

2113	3.5.1.2.6. Events Resulting From Other Messages

2115	   Messages other than the Initialization message may result in events
2116	   that must be signaled to LDP peers via Notification Messages.  These
2117	   events and the Status Codes used in the Notification Messages to
2118	   signal them are described in the sections that describe these
2119	   messages.

2121	3.5.1.2.7. Miscellaneous Events

2123	   These are events that fall into none of the categories above.  There
2124	   are no miscellaneous events defined in this version of the protocol.

2126	3.5.2. Hello Message

2128	   LDP Hello Messages are exchanged as part of the LDP Discovery
2129	   Mechanism; see Section "LDP Discovery".

2131	   The encoding for the Hello Message is:

2133	    0                   1                   2                   3
2134	    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
2135	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2136	   |0|   Hello (0x0100)            |      Message Length           |
2137	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2138	   |                     Message ID                                |
2139	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2140	   |                     Common Hello Parameters TLV               |
2141	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2142	   |                     Optional Parameters                       |
2143	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2145	   Message ID
2146	     32-bit value used to identify this message.

2148	   Common Hello Parameters TLV
2149	     Specifies parameters common to all Hello messages.  The encoding
2150	     for the Common Hello Parameters TLV is:

2152	      0                   1                   2                   3
2153	      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
2154	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2155	     |0|0| Common Hello Parms(0x0400)|      Length                   |
2156	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2157	     |      Hold Time                |T|R| Reserved                  |
2158	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2160	     Hold Time,
2161	       Hello hold time in seconds.  An LSR maintains a record of Hellos
2162	       received from potential peers (see Section "Hello Message
2163	       Procedures").  Hello Hold Time specifies the time the sending LSR
2164	       will maintain its record of Hellos from the receiving LSR without
2165	       receipt of another Hello.

2167	       A pair of LSRs negotiates the hold times they use for Hellos from
2168	       each other.  Each proposes a hold time.  The hold time used is
2169	       the minimum of the hold times proposed in their Hellos.

2171	       A value of 0 means use the default, which is 15 seconds for Link
2172	       Hellos and 45 seconds for Targeted Hellos.  A value of 0xffff
2173	       means infinite.

2175	     T, Targeted Hello
2176	       A value of 1 specifies that this Hello is a Targeted Hello.  A
2177	       value of 0 specifies that this Hello is a Link Hello.

2179	     R, Request Send Targeted Hellos
2180	       A value of 1 requests the receiver to send periodic Targeted
2181	       Hellos to the source of this Hello.  A value of 0 makes no
2182	       request.

2184	       An LSR initiating Extended Discovery sets R to 1.  If R is 1, the
2185	       receiving LSR checks whether it has been configured to send
2186	       Targeted Hellos to the Hello source in response to Hellos with
2187	       this request.  If not, it ignores the request.  If so, it
2188	       initiates periodic transmission of Targeted Hellos to the Hello
2189	       source.

2191	     Reserved
2192	       This field is reserved.  It must be set to zero on transmission
2193	       and ignored on receipt.

2195	     Optional Parameters
2196	       This variable length field contains 0 or more parameters, each
2197	       encoded as a TLV.  The optional parameters defined by this
2198	       version of the protocol are

2200	           Optional Parameter    Type     Length  Value

2202	           Transport Address     0x0401     4      See below
2203	           Configuration         0x0402     4      See below
2204	              Sequence Number

2206	       Transport Address
2207	         Specifies the IPv4 address to be used for the sending LSR when
2208	         opening the LDP session TCP connection.  If this optional TLV
2209	         is not present the IPv4 source address for the UDP packet
2210	         carrying the Hello should be used.

2212	       Configuration Sequence Number
2213	         Specifies a 4 octet unsigned configuration sequence number that
2214	         identifies the configuration state of the sending LSR.  Used by
2215	         the receiving LSR to detect configuration changes on the
2216	         sending LSR.

2218	3.5.2.1. Hello Message Procedures

2220	   An LSR receiving Hellos from another LSR maintains a Hello adjacency
2221	   corresponding to the Hellos.  The LSR maintains a hold timer with the
2222	   Hello adjacency which it restarts whenever it receives a Hello that
2223	   matches the Hello adjacency.  If the hold timer for a Hello adjacency
2224	   expires the LSR discards the Hello adjacency: see sections
2225	   "Maintaining Hello Adjacencies" and "Maintaining LDP Sessions".

2227	   We recommend that the interval between Hello transmissions be at most
2228	   one third of the Hello hold time.

2230	   An LSR processes a received LDP Hello as follows:

2232	      1. The LSR checks whether the Hello is acceptable.  The criteria
2233	         for determining whether a Hello is acceptable are
2234	         implementation dependent (see below for example criteria).

2236	      2. If the Hello is not acceptable, the LSR ignores it.

2238	      3. If the Hello is acceptable, the LSR checks whether it has a
2239	         Hello adjacency for the Hello source. If so, it restarts the
2240	         hold timer for the Hello adjacency.  If not it creates a Hello
2241	         adjacency for the Hello source and starts its hold timer.

2243	      4. If the Hello carries any optional TLVs the LSR processes them
2244	         (see below).

2246	      5. Finally, if the LSR has no LDP session for the label space
2247	         specified by the LDP identifier in the PDU header for the
2248	         Hello, it follows the procedures of Section "LDP Session
2249	         Establishment".

2251	   The following are examples of acceptability criteria for Link and
2252	   Targeted Hellos:

2254	       A Link Hello is acceptable if the interface on which it was
2255	       received has been configured for label switching.

2257	       A Targeted Hello from IP source address a.b.c.d is acceptable if
2258	       either:

2260	           - The LSR has been configured to accept Targeted Hellos, or

2262	           - The LSR has been configured to send Targeted Hellos to
2263	             a.b.c.d.

2265	       The following describes how an LSR processes Hello optional TLVs:

2267	       Transport Address
2268	         The LSR associates the specified transport address with the
2269	         Hello adjacency.

2271	       Configuration Sequence Number
2272	         The Configuration Sequence Number optional parameter is used by
2273	         the sending LSR to signal configuration changes to the
2274	         receiving LSR.  When a receiving LSR playing the active role in
2275	         LDP session establishment detects a change in the sending LSR
2276	         configuration, it may clear the session setup backoff delay, if
2277	         any, associated with the sending LSR (see Section "Session
2278	         Initialization").

2280	         A sending LSR using this optional parameter is responsible for
2281	         maintaining the configuration sequence number it transmits in
2282	         Hello messages.  Whenever there is a configuration change on
2283	         the sending LSR, it increments the configuration sequence
2284	         number.

2286	3.5.3. Initialization Message

2288	   The LDP Initialization Message is exchanged as part of the LDP
2289	   session establishment procedure; see Section "LDP Session
2290	   Establishment".

2292	   The encoding for the Initialization Message is:

2294	    0                   1                   2                   3
2295	    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
2296	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2297	   |0|   Initialization (0x0200)   |      Message Length           |
2298	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2299	   |                     Message ID                                |
2300	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2301	   |                     Common Session Parameters TLV             |
2302	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2303	   |                     Optional Parameters                       |
2304	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2306	   Message ID
2307	     32-bit value used to identify this message.

2309	   Common Session Parameters TLV
2310	     Specifies values proposed by the sending LSR for parameters that
2311	     must be negotiated for every LDP session.

2313	     The encoding for the Common Session Parameters TLV is:

2315	        0                   1                   2                   3
2316	        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
2317	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2318	       |0|0| Common Sess Parms (0x0500)|      Length                   |
2319	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2320	       | Protocol Version              |      KeepAlive Time           |
2321	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2322	       |A|D|  Reserved |     PVLim     |      Max PDU Length           |
2323	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2324	       |                 Receiver LDP Identifier                       |
2325	       +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2326	       |                               |
2327	       -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++

2329	       Protocol Version
2330	         Two octet unsigned integer containing the version number of the
2331	         protocol.  This version of the specification specifies LDP
2332	         protocol version 1.

2334	       KeepAlive Time
2335	         Two octet unsigned non zero integer that indicates the number
2336	         of seconds that the sending LSR proposes for the value of the
2337	         KeepAlive Time.  The receiving LSR MUST calculate the value of
2338	         the KeepAlive Timer by using the smaller of its proposed
2339	         KeepAlive Time and the KeepAlive Time received in the PDU.  The
2340	         value chosen for KeepAlive Time indicates the maximum number of
2341	         seconds that may elapse between the receipt of successive PDUs
2342	         from the LDP peer on the session TCP connection.  The KeepAlive
2343	         Timer is reset each time a PDU arrives.

2345	       A, Label Advertisement Discipline
2346	         Indicates the type of Label advertisement.  A value of 0 means
2347	         Downstream Unsolicited advertisement; a value of 1 means
2348	         Downstream On Demand.

2350	         If one LSR proposes Downstream Unsolicited and the other
2351	         proposes Downstream on Demand, the rules for resolving this
2352	         difference is:

2354	           - If the session is for a label-controlled ATM link or a
2355	             label-controlled Frame Relay link, then Downstream on
2356	             Demand must be used.

2358	           - Otherwise, Downstream Unsolicited must be used.

2360	         If the label advertisement discipline determined in this way is
2361	         unacceptable to an LSR, it must send a Session
2362	         Rejected/Parameters Advertisement Mode Notification message in
2363	         response to the Initialization message and not establish the
2364	         session.

2366	       D, Loop Detection
2367	         Indicates whether loop detection based on path vectors is
2368	         enabled.  A value of 0 means loop detection is disabled; a
2369	         value of 1 means that loop detection is enabled.

2371	       PVLim, Path Vector Limit
2372	         The configured maximum path vector length.  Must be 0 if loop
2373	         detection is disabled (D = 0).  If the loop detection
2374	         procedures would require the LSR to send a path vector that
2375	         exceeds this limit, the LSR will behave as if a loop had been
2376	         detected for the FEC in question.

2378	         When Loop Detection is enabled in a portion of a network, it is
2379	         recommended that all LSRs in that portion of the network be
2380	         configured with the same path vector limit.  Although knowledge
2381	         of a peer's path vector limit will not change an LSR's
2382	         behavior, it does enable the LSR to alert an operator to a
2383	         possible misconfiguration.

2385	       Reserved
2386	         This field is reserved.  It must be set to zero on transmission
2387	         and ignored on receipt.

2389	       Max PDU Length
2390	         Two octet unsigned integer that proposes the maximum allowable
2391	         length for LDP PDUs for the session.  A value of 255 or less
2392	         specifies the default maximum length of 4096 octets.

2394	         The receiving LSR MUST calculate the maximum PDU length for the
2395	         session by using the smaller of its and its peer's proposals
2396	         for Max PDU Length. The default maximum PDU length applies
2397	         before session initialization completes.

2399	         If the maximum PDU length determined this way is unacceptable
2400	         to an LSR, it must send a Session Rejected/Parameters Max PDU
2401	         Length Notification message in response to the Initialization
2402	         message and not establish the session.

2404	       Receiver LDP Identifier
2405	         Identifies the receiver's label space.  This LDP Identifier,
2406	         together with the sender's LDP Identifier in the PDU header
2407	         enables the receiver to match the Initialization message with
2408	         one of its Hello adjacencies; see Section "Hello Message
2409	         Procedures".

2411	         If there is no matching Hello adjacency, the LSR must send a
2412	         Session Rejected/No Hello Notification message in response to
2413	         the Initialization message and not establish the session.

2415	   Optional Parameters
2416	     This variable length field contains 0 or more parameters, each
2417	     encoded as a TLV.  The optional parameters are:

2419	         Optional Parameter       Type     Length  Value

2421	         ATM Session Parameters   0x0501   var     See below
2422	         Frame Relay Session      0x0502   var     See below
2423	           Parameters

2425	     ATM Session Parameters
2426	       Used when an LDP session manages label exchange for an ATM link
2427	       to specify ATM-specific session parameters.

2429	        0                   1                   2                   3
2430	        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
2431	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2432	       |0|0|   ATM Sess Parms (0x0501) |      Length                   |
2433	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2434	       | M |   N   |D|                        Reserved                 |
2435	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2436	       |                 ATM Label Range Component 1                   |
2437	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2438	       |                                                               |
2439	       ~                                                               ~
2440	       |                                                               |
2441	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2442	       |                 ATM Label Range Component N                   |
2443	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2445	       M, ATM Merge Capabilities
2446	         Specifies the merge capabilities of an ATM switch.  The
2447	         following values are supported in this version of the
2448	         specification:

2450	                   Value          Meaning
2451	                     0            Merge not supported
2452	                     1            VP Merge supported
2453	                     2            VC Merge supported
2454	                     3            VP & VC Merge supported

2456	         If the merge capabilities of the LSRs differ, then:

2458	           - Non-merge and VC-merge LSRs may freely interoperate.

2460	           - The interoperability of VP-merge-capable switches with
2461	             non-VP-merge-capable switches is a subject for future
2462	             study.

2464	         Note that if VP merge is used, it is the responsibility of the
2465	         ingress node to ensure that the chosen VCI is unique within the
2466	         LSR domain (see [ATM-VP]).

2468	       N, Number of label range components
2469	         Specifies the number of ATM Label Range Components included in
2470	         the TLV.

2472	       D, VC Directionality
2473	         A value of 0 specifies bidirectional VC capability, meaning the
2474	         LSR can (within a given VPI) support the use of a given VCI as
2475	         a label for both link directions independently.  A value of 1
2476	         specifies unidirectional VC capability, meaning (within a given
2477	         VPI) a given VCI may appear in a label mapping for one
2478	         direction on the link only.  When either or both of the peers
2479	         specifies unidirectional VC capability, both LSRs use
2480	         unidirectional VC label assignment for the link as follows.
2481	         The LSRs compare their LDP Identifiers as unsigned integers.
2482	         The LSR with the larger LDP Identifier may assign only odd-
2483	         numbered VCIs in the VPI/VCI range as labels.  The system with
2484	         the smaller LDP Identifier may assign only even-numbered VCIs
2485	         in the VPI/VCI range as labels.

2487	       Reserved
2488	         This field is reserved.  It must be set to zero on transmission
2489	         and ignored on receipt.

2491	       One or more ATM Label Range Components
2492	         A list of ATM Label Range Components which together specify the
2493	         Label range supported by the transmitting LSR.

2495	         A receiving LSR MUST calculate the intersection between the
2496	         received range and its own supported label range.  The
2497	         intersection is the range in which the LSR may allocate and
2498	         accept labels.  LSRs MUST NOT establish a session with
2499	         neighbors for which the intersection of ranges is NULL.  In
2500	         this case, the LSR must send a Session Rejected/Parameters
2501	         Label Range Notification message in response to the
2502	         Initialization message and not establish the session.

2504	         The encoding for an ATM Label Range Component is:

2506	          0                   1                   2                   3
2507	          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
2508	         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2509	         |  Res  |    Minimum VPI        |      Minimum VCI              |
2510	         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2511	         |  Res  |    Maximum VPI        |      Maximum VCI              |
2512	         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2514	         Res
2515	           This field is reserved. It must be set to zero on
2516	           transmission and must be ignored on receipt.

2518	         Minimum VPI (12 bits)
2519	           This 12 bit field specifies the lower bound of a block of
2520	           Virtual Path Identifiers that is supported on the originating
2521	           switch.  If the VPI is less than 12-bits it should be right
2522	           justified in this field and preceding bits should be set to
2523	           0.

2525	         Minimum VCI (16 bits)
2526	           This 16 bit field specifies the lower bound of a block of
2527	           Virtual Connection Identifiers that is supported on the
2528	           originating switch.  If the VCI is less than 16-bits it
2529	           should be right justified in this field and preceding bits
2530	           should be set to 0.

2532	         Maximum VPI (12 bits)
2533	           This 12 bit field specifies the upper bound of a block of
2534	           Virtual Path Identifiers that is supported on the originating
2535	           switch.  If the VPI is less than 12-bits it should be right
2536	           justified in this field and preceding bits should be set to
2537	           0.

2539	         Maximum VCI (16 bits)
2540	           This 16 bit field specifies the upper bound of a block of
2541	           Virtual Connection Identifiers that is supported on the
2542	           originating switch.  If the VCI is less than 16-bits it
2543	           should be right justified in this field and preceding bits
2544	           should be set to 0.

2546	       When peer LSRs are connected indirectly by means of an ATM VP,
2547	       the sending LSR should set the Minimum and Maximum VPI fields to
2548	       0, and the receiving LSR must ignore the Minimum and Maximum VPI
2549	       fields.

2551	       See [ATM-VP] for specification of the fields for ATM Label Range
2552	       Components to be used with VP merge LSRs.

2554	     Frame Relay Session Parameters
2555	       Used when an LDP session manages label exchange for a Frame Relay
2556	       link to specify Frame Relay-specific session parameters.

2558	        0                   1                   2                   3
2559	        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
2560	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2561	       |0|0|   FR Sess Parms (0x0502)  |      Length                   |
2562	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2563	       | M |   N   |D|                        Reserved                 |
2564	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2565	       |             Frame Relay Label Range Component 1               |
2566	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2567	       |                                                               |
2568	       ~                                                               ~
2569	       |                                                               |
2570	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2571	       |             Frame Relay Label Range Component N               |
2572	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2574	       M, Frame Relay Merge Capabilities
2575	         Specifies the merge capabilities of a Frame Relay switch.  The
2576	         following values are supported in this version of the
2577	         specification:

2579	                   Value          Meaning

2581	                     0            Merge not supported
2582	                     1            Merge supported

2584	         Non-merge and merge Frame Relay LSRs may freely interoperate.

2586	       N, Number of label range components
2587	         Specifies the number of Frame Relay Label Range Components
2588	         included in the TLV.

2590	       D, VC Directionality
2591	         A value of 0 specifies bidirectional VC capability, meaning the
2592	         LSR can support the use of a given DLCI as a label for both
2593	         link directions independently.  A value of 1 specifies
2594	         unidirectional VC capability, meaning a given DLCI may appear
2595	         in a label mapping for one direction on the link only.  When
2596	         either or both of the peers specifies unidirectional VC
2597	         capability, both LSRs use unidirectional VC label assignment
2598	         for the link as follows.  The LSRs compare their LDP
2599	         Identifiers as unsigned integers.  The LSR with the larger LDP
2600	         Identifier may assign only odd-numbered DLCIs in the range as
2601	         labels.  The system with the smaller LDP Identifier may assign
2602	         only even-numbered DLCIs in the range as labels.

2604	       Reserved
2605	         This field is reserved.  It must be set to zero on transmission
2606	         and ignored on receipt.

2608	       One or more Frame Relay Label Range Components
2609	         A list of Frame Relay Label Range Components which together
2610	         specify the Label range supported by the transmitting LSR.

2612	         A receiving LSR MUST calculate the intersection between the
2613	         received range and its own supported label range.  The
2614	         intersection is the range in which the LSR may allocate and
2615	         accept labels.  LSRs MUST NOT establish a session with
2616	         neighbors for which the intersection of ranges is NULL.  In
2617	         this case, the LSR must send a Session Rejected/Parameters
2618	         Label Range Notification message in response to the
2619	         Initialization message and not establish the session.

2621	         The encoding for a Frame Relay Label Range Component is:

2623	          0                   1                   2                   3
2624	          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
2625	         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2626	         | Reserved    |Len|                     Minimum DLCI            |
2627	         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2628	         | Reserved        |                     Maximum DLCI            |
2629	         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2631	         Reserved
2632	           This field is reserved.  It must be set to zero on
2633	           transmission and ignored on receipt.

2635	         Len
2636	           This field specifies the number of bits of the DLCI.  The
2637	           following values are supported:

2639	                Len    DLCI bits

2641	                0       10
2642	                1       17
2643	                2       23

2645	         Minimum DLCI
2646	           This 23-bit field specifies the lower bound of a block of
2647	           Data Link Connection Identifiers (DLCIs) that is supported on
2648	           the originating switch.  The DLCI should be right justified
2649	           in this field and unused bits should be set to 0.

2651	         Maximum DLCI
2652	           This 23-bit field specifies the upper bound of a block of
2653	           Data Link Connection Identifiers (DLCIs) that is supported on
2654	           the originating switch.  The DLCI should be right justified
2655	           in this field and unused bits should be set to 0.

2657	   Note that there is no Generic Session Parameters TLV for sessions
2658	   which advertise Generic Labels.

2660	3.5.3.1. Initialization Message Procedures

2662	   See Section "LDP Session Establishment" and particularly Section
2663	   "Session Initialization" for general procedures for handling the
2664	   Initialization Message.

2666	3.5.4. KeepAlive Message

2668	   An LSR sends KeepAlive Messages as part of a mechanism that monitors
2669	   the integrity of the LDP session transport connection.

2671	   The encoding for the KeepAlive Message is:

2673	    0                   1                   2                   3
2674	    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
2675	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2676	   |0|   KeepAlive (0x0201)        |      Message Length           |
2677	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2678	   |                     Message ID                                |
2679	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2680	   |                     Optional Parameters                       |
2681	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2682	   Message ID
2683	     32-bit value used to identify this message.

2685	   Optional Parameters
2686	     No optional parameters are defined for the KeepAlive message.

2688	3.5.4.1. KeepAlive Message Procedures

2690	   The KeepAlive Timer mechanism described in Section "Maintaining LDP
2691	   Sessions" resets a session KeepAlive timer every time an LDP PDU is
2692	   received on the session TCP connection.  The KeepAlive Message is
2693	   provided to allow reset of the KeepAlive Timer in circumstances where
2694	   an LSR has no other information to communicate to an LDP peer.

2696	   An LSR must arrange that its peer receive an LDP Message from it at
2697	   least every KeepAlive Time period.  Any LDP protocol message will do
2698	   but, in circumstances where no other LDP protocol messages have been
2699	   sent within the period, a KeepAlive message must be sent.

2701	3.5.5. Address Message

2703	   An LSR sends the Address Message to an LDP peer to advertise its
2704	   interface addresses.

2706	   The encoding for the Address Message is:

2708	    0                   1                   2                   3
2709	    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
2710	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2711	   |0|   Address (0x0300)          |      Message Length           |
2712	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2713	   |                     Message ID                                |
2714	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2715	   |                                                               |
2716	   |                     Address List TLV                          |
2717	   |                                                               |
2718	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2719	   |                     Optional Parameters                       |
2720	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2722	   Message ID
2723	     32-bit value used to identify this message.

2725	   Address List TLV
2726	     The list of interface addresses being advertised by the sending
2727	     LSR.  The encoding for the Address List TLV is specified in Section
2728	     "Address List TLV".

2730	   Optional Parameters
2731	     No optional parameters are defined for the Address message.

2733	3.5.5.1. Address Message Procedures

2735	   An LSR that receives an Address Message message uses the addresses it
2736	   learns to maintain a database for mapping between peer LDP
2737	   Identifiers and next hop addresses; see Section "LDP Identifiers and
2738	   Next Hop Addresses".

2740	   When a new LDP session is initialized and before sending Label
2741	   Mapping or Label Request messages an LSR should advertise its
2742	   interface addresses with one or more Address messages.

2744	   Whenever an LSR "activates" a new interface address, it should
2745	   advertise the new address with an Address message.

2747	   Whenever an LSR "de-activates" a previously advertised address, it
2748	   should withdraw the address with an Address Withdraw message; see
2749	   Section "Address Withdraw Message".

2751	3.5.6. Address Withdraw Message

2753	   An LSR sends the Address Withdraw Message to an LDP peer to withdraw
2754	   previously advertised interface addresses.

2756	   The encoding for the Address Withdraw Message is:

2758	    0                   1                   2                   3
2759	    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
2760	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2761	   |0|   Address Withdraw (0x0301) |      Message Length           |
2762	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2763	   |                     Message ID                                |
2764	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2765	   |                                                               |
2766	   |                     Address List TLV                          |
2767	   |                                                               |
2768	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2769	   |                     Optional Parameters                       |
2770	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2771	   Message ID
2772	     32-bit value used to identify this message.

2774	   Address list TLV
2775	     The list of interface addresses being withdrawn by the sending LSR.
2776	     The encoding for the Address list TLV is specified in Section
2777	     "Address List TLV".

2779	   Optional Parameters
2780	     No optional parameters are defined for the Address Withdraw
2781	     message.

2783	3.5.6.1. Address Withdraw Message Procedures

2785	   See Section "Address Message Procedures"

2787	3.5.7. Label Mapping Message

2789	   An LSR sends a Label Mapping message to an LDP peer to advertise
2790	   FEC-label bindings to the peer.

2792	   The encoding for the Label Mapping Message is:

2794	   0                   1                   2                   3
2795	   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
2796	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2797	   |0|   Label Mapping (0x0400)    |      Message Length           |
2798	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2799	   |                     Message ID                                |
2800	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2801	   |                     FEC TLV                                   |
2802	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2803	   |                     Label TLV                                 |
2804	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2805	   |                     Optional Parameters                       |
2806	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2808	   Message ID
2809	     32-bit value used to identify this message.

2811	   FEC TLV
2812	     Specifies the FEC component of the FEC-Label mapping being
2813	     advertised.  See Section "FEC TLV" for encoding.

2815	   Label TLV
2816	     Specifies the Label component of the FEC-Label mapping.  See
2817	     Section "Label TLV" for encoding.

2819	   Optional Parameters
2820	     This variable length field contains 0 or more parameters, each
2821	     encoded as a TLV.  The optional parameters are:

2823	         Optional Parameter    Length       Value

2825	         Label Request         4            See below
2826	             Message ID TLV
2827	         Hop Count TLV         1            See below
2828	         Path Vector TLV       variable     See below

2830	     The encodings for the Hop Count, and Path Vector TLVs can be found
2831	     in Section "TLV Encodings for Commonly Used Parameters".

2833	       Label Request Message ID
2834	         If this Label Mapping message is a response to a Label Request
2835	         message it must include the Request Message Id optional
2836	         parameter.  The value of this optional parameter is the Message
2837	         Id of the corresponding Label Request Message.

2839	       Hop Count
2840	         Specifies the running total of the number of LSR hops along the
2841	         LSP being setup by the Label Message.  Section "Hop Count
2842	         Procedures" describes how to handle this TLV.

2844	       Path Vector
2845	         Specifies the LSRs along the LSP being setup by the Label
2846	         Message.  Section "Path Vector Procedures" describes how to
2847	         handle this TLV.

2849	3.5.7.1. Label Mapping Message Procedures

2851	   The Mapping message is used by an LSR to distribute a label mapping
2852	   for a FEC to an LDP peer.  If an LSR distributes a mapping for a FEC
2853	   to multiple LDP peers, it is a local matter whether it maps a single
2854	   label to the FEC, and distributes that mapping to all its peers, or
2855	   whether it uses a different mapping for each of its peers.

2857	   An LSR is responsible for the consistency of the label mappings it
2858	   has distributed, and that its peers have these mappings.

2860	   An LSR receiving a Label Mapping message from a downstream LSR for a
2861	   Prefix or Host Address FEC Element should not use the label for
2862	   forwarding unless its routing table contains an entry that exactly
2863	   matches the FEC Element.

2865	   See Appendix A "LDP Label Distribution Procedures" for more details.

2867	3.5.7.1.1. Independent Control Mapping

2869	   If an LSR is configured for independent control, a mapping message is
2870	   transmitted by the LSR upon any of the following conditions:

2872	      1. The LSR recognizes a new FEC via the forwarding table, and the
2873	         label advertisement mode is Downstream Unsolicited
2874	         advertisement.

2876	      2. The LSR receives a Request message from an upstream peer for a
2877	         FEC present in the LSR's forwarding table.

2879	      3. The next hop for a FEC changes to another LDP peer, and loop
2880	         detection is configured.

2882	      4. The attributes of a mapping change.

2884	      5. The receipt of a mapping from the downstream next hop  AND
2885	            a) no upstream mapping has been created  OR
2886	            b) loop detection is configured  OR
2887	            c) the attributes of the mapping have changed.

2889	3.5.7.1.2. Ordered Control Mapping

2891	   If an LSR is doing ordered control, a Mapping message is transmitted
2892	   by downstream LSRs upon any of the following conditions:

2894	      1. The LSR recognizes a new FEC via the forwarding table, and is
2895	         the egress for that FEC.

2897	      2. The LSR receives a Request message from an upstream peer for a
2898	         FEC present in the LSR's forwarding table, and the LSR is the
2899	         egress for that FEC OR has a downstream mapping for that FEC.

2901	      3. The next hop for a FEC changes to another LDP peer, and loop
2902	         detection is configured.

2904	      4. The attributes of a mapping change.

2906	      5. The receipt of a mapping from the downstream next hop  AND
2907	            a) no upstream mapping has been created   OR
2908	            b) loop detection is configured   OR
2909	            c) the attributes of the mapping have changed.

2911	3.5.7.1.3. Downstream on Demand Label Advertisement

2913	   In general, the upstream LSR is responsible for requesting label
2914	   mappings when operating in Downstream on Demand mode.  However,
2915	   unless some rules are followed, it is possible for neighboring LSRs
2916	   with different advertisement modes to get into a livelock situation
2917	   where everything is functioning properly, but no labels are
2918	   distributed.  For example, consider two LSRs Ru and Rd where Ru is
2919	   the upstream LSR and Rd is the downstream LSR for a particular FEC.
2920	   In this example, Ru is using Downstream Unsolicited advertisement
2921	   mode and Rd is using Downstream on Demand mode.  In this case, Rd may
2922	   assume that Ru will request a label mapping when it wants one and Ru
2923	   may assume that Rd will advertise a label if it wants Ru to use one.
2924	   If Rd and Ru operate as suggested, no labels will be distributed from
2925	   Rd to Ru.

2927	   This livelock situation can be avoided if the following rule is
2928	   observed: an LSR operating in Downstream on Demand mode should not be
2929	   expected to send unsolicited mapping advertisements.  Therefore, if
2930	   the downstream LSR is operating in Downstream on Demand mode, the
2931	   upstream LSR is responsible for requesting label mappings as needed.

2933	3.5.7.1.4. Downstream Unsolicited Label Advertisement

2935	   In general, the downstream LSR is responsible for advertising a label
2936	   mapping when it wants an upstream LSR to use the label.  An upstream
2937	   LSR may issue a mapping request if it so desires.

2939	   The combination of Downstream Unsolicited mode and conservative label
2940	   retention can lead to a situation where an LSR releases the label for
2941	   a FEC that it later needs.  For example, if LSR Rd advertises to LSR
2942	   Ru the label for a FEC for which it is not Ru's next hop, Ru will
2943	   release the label.  If Ru's next hop for the FEC later changes to Rd,
2944	   it needs the previously released label.

2946	   To deal with this situation either Ru can explicitly request the
2947	   label when it needs it, or Rd can periodically readvertise it to Ru.
2948	   In many situations Ru will know when it needs the label from Rd.  For
2949	   example, when its next hop for the FEC changes to Rd.  However, there
2950	   could be situations when Ru does not.  For example, Rd may be
2951	   attempting to establish an LSP with non-standard properties.  Forcing
2952	   Ru to explicitly request the label in this situation would require it
2953	   to maintain state about a potential LSP with non-standard properties.

2955	   In situations where Ru knows it needs the label, it is responsible
2956	   for explicitly requesting the label by means of a Label Request
2957	   message.  In situations where Ru may not know that it needs the
2958	   label, Rd is responsible for periodically readvertising the label to
2959	   Ru.

2961	   For this version of LDP, the only situation where Ru knows it needs a
2962	   label for a FEC from Rd is when Rd is its next hop for the FEC, Ru
2963	   does not have a label from Rd, and the LSP for the FEC is one that
2964	   can be established with TLVs defined in this document.

2966	3.5.8. Label Request Message

2968	   An LSR sends the Label Request Message to an LDP peer to request a
2969	   binding (mapping) for a FEC.

2971	   The encoding for the Label Request Message is:

2973	    0                   1                   2                   3
2974	    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
2975	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2976	   |0|   Label Request (0x0401)    |      Message Length           |
2977	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2978	   |                     Message ID                                |
2979	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2980	   |                     FEC TLV                                   |
2981	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2982	   |                     Optional Parameters                       |
2983	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2985	   Message ID
2986	     32-bit value used to identify this message.

2988	   FEC TLV
2989	     The FEC for which a label is being requested.  See Section "FEC
2990	     TLV" for encoding.

2992	   Optional Parameters
2993	     This variable length field contains 0 or more parameters, each
2994	     encoded as a TLV.  The optional parameters are:

2996	         Optional Parameter     Length       Value
2997	         Hop Count TLV          1            See below
2998	         Path Vector TLV        variable     See below

3000	     The encodings for the Hop Count, and Path Vector TLVs can be found
3001	     in Section "TLV Encodings for Commonly Used Parameters".

3003	       Hop Count
3004	         Specifies the running total of the number of LSR hops along the
3005	         LSP being setup by the Label Request Message.  Section "Hop
3006	         Count Procedures" describes how to handle this TLV.

3008	       Path Vector
3009	         Specifies the LSRs along the LSR being setup by the Label
3010	         Request Message.  Section "Path Vector Procedures" describes
3011	         how to handle this TLV.

3013	3.5.8.1. Label Request Message Procedures

3015	   The Request message is used by an upstream LSR to explicitly request
3016	   that the downstream LSR assign and advertise a label for a FEC.

3018	   An LSR may transmit a Request message under any of the following
3019	   conditions:

3021	      1. The LSR recognizes a new FEC via the forwarding table, and the
3022	         next hop is an LDP peer, and the LSR doesn't already have a
3023	         mapping from the next hop for the given FEC.

3025	      2. The next hop to the FEC changes, and the LSR doesn't already
3026	         have a mapping from that next hop for the given FEC.

3028	         Note that if the LSR already has a pending Label Request
3029	         message for the new next hop it should not issue an additional
3030	         Label Request in response to the next hop change.

3032	      3. The LSR receives a Label Request for a FEC from an upstream LDP
3033	         peer, the FEC next hop is an LDP peer, and the LSR doesn't
3034	         already have a mapping from the next hop.

3036	         Note that since a non-merge LSR must setup a separate LSP for
3037	         each upstream peer requesting a label, it must send a separate
3038	         Label Request for each such peer.  A consequence of this is
3039	         that a non-merge LSR may have multiple Label Request messages
3040	         for a given FEC outstanding at the same time.

3042	   The receiving LSR should respond to a Label Request message with a
3043	   Label Mapping for the requested label or with a Notification message
3044	   indicating why it cannot satisfy the request.

3046	   When the FEC for which a label is requested is a Prefix FEC Element
3047	   or a Host Address FEC Element, the receiving LSR uses its routing
3048	   table to determine its response.  Unless its routing table includes
3049	   an entry that exactly matches the requested Prefix or Host Address,
3050	   the LSR must respond with a No Route Notification message.

3052	   The message ID of the Label Request message serves as an identifier
3053	   for the Label Request transaction.  When the receiving LSR responds
3054	   with a Label Mapping message, the mapping message must include a
3055	   Label Request/Returned Message ID TLV optional parameter which
3056	   includes the message ID of the Label Request message.  Note that
3057	   since LSRs use Label Request message IDs as transaction identifiers
3058	   an LSR should not reuse the message ID of a Label Request message
3059	   until the corresponding transaction completes.

3061	   This version of the protocol defines the following Status Codes for
3062	   the Notification message that signals a request cannot be satisfied:

3064	     No Route
3065	       The FEC for which a label was requested includes a FEC Element
3066	       for which the LSR does not have a route.

3068	     No Label Resources
3069	       The LSR cannot provide a label because of resource limitations.
3070	       When resources become available the LSR must notify the
3071	       requesting LSR by sending a Notification message with the Label
3072	       Resources Available Status Code.

3074	       An LSR that receives a No Label Resources response to a Label
3075	       Request message must not issue further Label Request messages
3076	       until it receives a Notification message with the Label Resources
3077	       Available Status code.

3079	     Loop Detected
3080	       The LSR has detected a looping Label Request message.

3082	   See Appendix A "LDP Label Distribution Procedures" for more details.

3084	3.5.9. Label Abort Request Message

3086	   The Label Abort Request message may be used to abort an outstanding
3087	   Label Request message.

3089	   The encoding for the Label Abort Request Message is:

3091	    0                   1                   2                   3
3092	    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
3093	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3094	   |0|   Label Abort Req (0x0404)  |      Message Length           |
3095	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3096	   |                     Message ID                                |
3097	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3098	   |                     FEC TLV                                   |
3099	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3100	   |                     Label Request Message ID TLV              |
3101	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3102	   |                     Optional Parameters                       |
3103	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3105	   Message ID
3106	     32-bit value used to identify this message.

3108	   FEC TLV
3109	     Identifies the FEC for which the Label Request is being aborted.

3111	   Label Request Message ID TLV
3112	     Specifies the message ID of the Label Request message to be
3113	     aborted.

3115	   Optional Parameters
3116	     No optional parameters are defined for the Label Abort Req message.

3118	3.5.9.1. Label Abort Request Message Procedures

3120	   An LSR Ru may send a Label Abort Request message to abort an
3121	   outstanding Label Request message for FEC sent to LSR Rd in the
3122	   following circumstances:

3124	      1. Ru's next hop for FEC has changed from LSR Rd to LSR X; or

3126	      2. Ru is a non-merge, non-ingress LSR and has received a Label
3127	         Abort Request for FEC from an upstream peer Y.

3129	      3. Ru is a merge, non-ingress LSR and has received a Label Abort
3130	         Request for FEC from an upstream peer Y and Y is the only
3131	         (last) upstream LSR requesting a label for FEC.

3133	   There may be other situations where an LSR may choose to abort an
3134	   outstanding Label Request message in order to reclaim resource
3135	   associated with the pending LSP.  However, specification of general
3136	   strategies for using the abort mechanism is beyond the scope of LDP.

3138	   When an LSR receives a Label Abort Request message, if it has not
3139	   previously responded to the Label Request being aborted with a Label
3140	   Mapping message or some other Notification message, it must
3141	   acknowledge the abort by responding with a Label Request Aborted
3142	   Notification message.  The Notification must include a Label Request
3143	   Message ID TLV that carries the message ID of the aborted Label
3144	   Request message.

3146	   If an LSR receives a Label Abort Request Message after it has
3147	   responded to the Label Request in question with a Label Mapping
3148	   message or a Notification message, it ignores the abort request.

3150	   If an LSR receives a Label Mapping message in response to a Label
3151	   Request message after it has sent a Label Abort Request message to
3152	   abort the Label Request, the label in the Label Mapping message is
3153	   valid.  The LSR may choose to use the label or to release it with a
3154	   Label Release message.

3156	   An LSR aborting a Label Request message may not reuse the Message ID
3157	   for the Label Request message until it receives one of the following
3158	   from its peer:

3160	     - A Label Request Aborted Notification message acknowledging the
3161	       abort;

3163	     - A Label Mapping message in response to the Label Request message
3164	       being aborted;

3166	     - A Notification message in response to the Label Request message
3167	       being aborted (e.g., Loop Detected, No Label Resources, etc.).

3169	   To protect itself against tardy peers or faulty peer implementations
3170	   an LSR may choose to time out receipt of the above.  The time out
3171	   period should be relatively long (several minutes).

3173	   Note that the response to a Label Abort Request message is never
3174	   "ordered".  That is, the response does not depend on the downstream
3175	   state of the LSP setup being aborted.  An LSR receiving a Label Abort
3176	   Request message must process it immediately, regardless of the
3177	   downstream state of the LSP, responding with a Label Request Aborted
3178	   Notification or ignoring it, as appropriate.

3180	3.5.10. Label Withdraw Message

3182	   An LSR sends a Label Withdraw Message to an LDP peer to signal the
3183	   peer that the peer may not continue to use specific FEC-label
3184	   mappings the LSR had previously advertised.  This breaks the mapping
3185	   between the FECs and the labels.

3187	   The encoding for the Label Withdraw Message is:

3189	    0                   1                   2                   3
3190	    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
3191	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3192	   |0|   Label Withdraw (0x0402)   |      Message Length           |
3193	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3194	   |                     Message ID                                |
3195	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3196	   |                     FEC TLV                                   |
3197	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3198	   |                     Label TLV (optional)                      |
3199	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3200	   |                     Optional Parameters                       |
3201	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3203	   Message ID
3204	     32-bit value used to identify this message.

3206	   FEC TLV
3207	     Identifies the FEC for which the FEC-label mapping is being
3208	     withdrawn.

3210	   Optional Parameters
3211	     This variable length field contains 0 or more parameters, each
3212	     encoded as a TLV.  The optional parameters are:

3214	         Optional Parameter    Length       Value

3216	         Label TLV             variable     See below

3218	     The encoding for Label TLVs are found in Section "Label TLVs".

3220	       Label
3221	         If present, specifies the label being withdrawn (see procedures
3222	         below).

3224	3.5.10.1. Label Withdraw Message Procedures

3226	   An LSR transmits a Label Withdraw message under the following
3227	   conditions:

3229	      1. The LSR no longer recognizes a previously known FEC for which
3230	         it has advertised a label.

3232	      2. The LSR has decided unilaterally (e.g., via configuration) to
3233	         no longer label switch a FEC (or FECs) with the label mapping
3234	         being withdrawn.

3236	   The FEC TLV specifies the FEC for which labels are to be withdrawn.
3237	   If no Label TLV follows the FEC, all labels associated with the FEC
3238	   are to be withdrawn; otherwise only the label specified in the
3239	   optional Label TLV is to be withdrawn.

3241	   The FEC TLV may contain the Wildcard FEC Element; if so, it may
3242	   contain no other FEC Elements.  In this case, if the Label Withdraw
3243	   message contains an optional Label TLV, then the label is to be
3244	   withdrawn from all FECs to which it is bound.  If there is not an
3245	   optional Label TLV in the Label Withdraw message, then the sending
3246	   LSR is withdrawing all label mappings previously advertised to the
3247	   receiving LSR.

3249	   An LSR that receives a Label Withdraw message must respond with a
3250	   Label Release message.

3252	   See Appendix A "LDP Label Distribution Procedures" for more details.

3254	3.5.11. Label Release Message

3256	   An LSR sends a Label Release message to an LDP peer to signal the
3257	   peer that the LSR no longer needs specific FEC-label mappings
3258	   previously requested of and/or advertised by the peer.

3260	   The encoding for the Label Release Message is:

3262	    0                   1                   2                   3
3263	    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
3264	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3265	   |0|   Label Release (0x0403)   |      Message Length            |
3266	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3267	   |                     Message ID                                |
3268	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3269	   |                     FEC TLV                                   |
3270	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3271	   |                     Label TLV (optional)                      |
3272	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3273	   |                     Optional Parameters                       |
3274	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3276	   Message ID
3277	     32-bit value used to identify this message.

3279	   FEC TLV
3280	     Identifies the FEC for which the FEC-label mapping is being
3281	     released.

3283	   Optional Parameters
3284	     This variable length field contains 0 or more parameters, each
3285	     encoded as a TLV.  The optional parameters are:

3287	         Optional Parameter    Length       Value

3289	         Label TLV             variable     See below

3291	     The encodings for Label TLVs are found in Section "Label TLVs".

3293	       Label
3294	         If present, the label being released (see procedures below).

3296	3.5.11.1. Label Release Message Procedures

3298	   An LSR transmits a Label Release message to a peer when it is no
3299	   longer needs a label previously received from or requested of that
3300	   peer.

3302	   An LSR must transmit a Label Release message under any of the
3303	   following conditions:

3305	      1. The LSR which sent the label mapping is no longer the next hop
3306	         for the mapped FEC, and the LSR is configured for conservative
3307	         operation.

3309	      2. The LSR receives a label mapping from an LSR which is not the
3310	         next hop for the FEC, and the LSR is configured for
3311	         conservative operation.

3313	      3. The LSR receives a Label Withdraw message.

3315	   Note that if an LSR is configured for "liberal mode", a release
3316	   message will never be transmitted in the case of conditions (1) and
3317	   (2) as specified above.  In this case, the upstream LSR keeps each
3318	   unused label, so that it can immediately be used later if the
3319	   downstream peer becomes the next hop for the FEC.

3321	   The FEC TLV specifies the FEC for which labels are to be released.
3322	   If no Label TLV follows the FEC, all labels associated with the FEC
3323	   are to be released; otherwise only the label specified in the
3324	   optional Label TLV is to be released.

3326	   The FEC TLV may contain the Wildcard FEC Element; if so, it may
3327	   contain no other FEC Elements.  In this case, if the Label Release
3328	   message contains an optional Label TLV, then the label is to be
3329	   released for all FECs to which it is bound.  If there is not an
3330	   optional Label TLV in the Label Release message, then the sending LSR
3331	   is releasing all label mappings previously learned from the receiving
3332	   LSR.

3334	   See Appendix A "LDP Label Distribution Procedures" for more details.

3336	3.6. Messages and TLVs for Extensibility

3338	   Support for LDP extensibility includes the rules for the U and F bits
3339	   that specify how an LSR should handle unknown TLVs and messages.

3341	   This section specifies TLVs and messages for vendor-private and
3342	   experimental use.

3344	3.6.1. LDP Vendor-private Extensions

3346	   Vendor-private TLVs and messages are used to convey vendor-private
3347	   information between LSRs.

3349	3.6.1.1. LDP Vendor-private TLVs

3351	   The Type range 0x3E00 through 0x3EFF is reserved for vendor-private
3352	   TLVs.

3354	   The encoding for a vendor-private TLV is:

3356	    0                   1                   2                   3
3357	    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
3358	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3359	   |U|F|    Type (0x3E00-0x3EFF)   |            Length             |
3360	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3361	   |                           Vendor ID                           |
3362	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3363	   |                                                               |
3364	   |                           Data....                            |
3365	   ~                                                               ~
3366	   |                                                               |
3367	   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3368	   |                               |
3369	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3371	   U bit
3372	     Unknown TLV bit.  Upon receipt of an unknown TLV, if U is clear
3373	     (=0), a notification must be returned to the message originator and
3374	     the entire message must be ignored; if U is set (=1), the unknown
3375	     TLV is silently ignored and the rest of the message is processed as
3376	     if the unknown TLV did not exist.

3378	     The determination as to whether a vendor-private message is
3379	     understood is based on the Type and the mandatory Vendor ID field.

3381	   F bit
3382	     Forward unknown TLV bit.  This bit only applies when the U bit is
3383	     set and the LDP message containing the unknown TLV is is to be
3384	     forwarded.  If F is clear (=0), the unknown TLV is not forwarded
3385	     with the containing message; if F is set (=1), the unknown TLV is
3386	     forwarded with the containing message.

3388	   Type
3389	     Type value in the range 0x3E00 through 0x3EFF.  Together, the Type
3390	     and Vendor Id field specify how the Data field is to be
3391	     interpreted.

3393	   Length
3394	     Specifies the cumulative length in octets of the Vendor ID and Data
3395	     fields.

3397	   Vendor Id
3398	     802 Vendor ID as assigned by the IEEE.

3400	   Data
3401	     The remaining octets after the Vendor ID in the Value field are
3402	     optional vendor-dependent data.

3404	3.6.1.2. LDP Vendor-private Messages

3406	   The Message Type range 0x3E00 through 0x3EFF is reserved for vendor-
3407	   private Messages.

3409	    0                   1                   2                   3
3410	    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
3411	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3412	   |U|    Msg Type (0x3E00-0x3EFF) |      Message Length           |
3413	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3414	   |                     Message ID                                |
3415	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3416	   |                     Vendor ID                                 |
3417	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3418	   +                                                               +
3419	   |                     Remaining Mandatory Parameters            |
3420	   +                                                               +
3421	   |                                                               |
3422	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3423	   |                                                               |
3424	   +                                                               +
3425	   |                     Optional Parameters                       |
3426	   +                                                               +
3427	   |                                                               |
3428	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3430	   U bit
3431	     Unknown message bit.  Upon receipt of an unknown message, if U is
3432	     clear (=0), a notification is returned to the message originator;
3433	     if U is set (=1), the unknown message is silently ignored.

3435	     The determination as to whether a vendor-private message is
3436	     understood is based on the Msg Type and the Vendor ID parameter.

3438	   Msg Type
3439	     Message type value in the range 0x3E00 through 0x3EFF.  Together,
3440	     the Msg Type and the Vendor ID specify how the message is to be
3441	     interpreted.

3443	   Message Length
3444	     Specifies the cumulative length in octets of the Message ID, Vendor
3445	     ID, Remaining Mandatory Parameters and Optional Parameters.

3447	   Message ID
3448	     32-bit integer used to identify this message.  Used by the sending
3449	     LSR to facilitate identifying notification messages that may apply
3450	     to this message.  An LSR sending a notification message in response
3451	     to this message will include this Message Id in the notification
3452	     message; see Section "Notification Message".

3454	   Vendor ID
3455	     802 Vendor ID as assigned by the IEEE.

3457	   Remaining Mandatory Parameters
3458	     Variable length set of remaining required message parameters.

3460	   Optional Parameters
3461	     Variable length set of optional message parameters.

3463	3.6.2. LDP Experimental Extensions

3465	   LDP support for experimentation is similar to support for vendor-
3466	   private extensions with the following differences:

3468	     - The Type range 0x3F00 through 0x3FFF is reserved for experimental
3469	       TLVs.

3471	     - The Message Type range 0x3F00 through 0x3FFF is reserved for
3472	       experimental messages.

3474	     - The encodings for experimental TLVs and messages are similar to
3475	       the vendor-private encodings with the following difference.

3477	       Experimental TLVs and messages use an Experiment ID field in
3478	       place of a Vendor ID field.  The Experiment ID field is used with
3479	       the Type or Message Type field to specify the interpretation of
3480	       the experimental TLV or Message.

3482	       Administration of Experiment IDs is the responsibility of the
3483	       experimenters.

3485	3.7. Message Summary

3487	   The following are the LDP messages defined in this version of the
3488	   protocol.

3490	       Message Name            Type     Section Title

3492	       Notification            0x0001   "Notification Message"
3493	       Hello                   0x0100   "Hello Message"
3494	       Initialization          0x0200   "Initialization Message"
3495	       KeepAlive               0x0201   "KeepAlive Message"
3496	       Address                 0x0300   "Address Message"
3497	       Address Withdraw        0x0301   "Address Withdraw Message"
3498	       Label Mapping           0x0400   "Label Mapping Message"
3499	       Label Request           0x0401   "Label Request Message"
3500	       Label Withdraw          0x0402   "Label Withdraw Message"
3501	       Label Release           0x0403   "Label Release Message"
3502	       Label Abort Request     0x0404   "Label Abort Request Message"
3503	       Vendor-Private          0x3E00-  "LDP Vendor-private Extensions"
3504	                               0x3EFF
3505	       Experimental            0x3F00-  "LDP Experimental Extensions"
3506	                               0x3FFF

3508	3.8. TLV Summary

3510	   The following are the TLVs defined in this version of the protocol.

3512	       TLV                      Type      Section Title

3514	       FEC                      0x0100    "FEC TLV"
3515	       Address List             0x0101    "Address List TLV"
3516	       Hop Count                0x0103    "Hop Count TLV"
3517	       Path Vector              0x0104    "Path Vector TLV"
3518	       Generic Label            0x0200    "Generic Label TLV"
3519	       ATM Label                0x0201    "ATM Label TLV"
3520	       Frame Relay Label        0x0202    "Frame Relay Label TLV"
3521	       Status                   0x0300    "Status TLV"
3522	       Extended Status          0x0301    "Notification Message"
3523	       Returned PDU             0x0302    "Notification Message"
3524	       Returned Message         0x0303    "Notification Message"
3525	       Common Hello             0x0400    "Hello Message"
3526	          Parameters
3527	       Transport Address        0x0401    "Hello Message"
3528	       Configuration            0x0402    "Hello Message"
3529	          Sequence Number

3531	       Common Session           0x0500    "Initialization Message"
3532	          Parameters
3533	       ATM Session Parameters   0x0501    "Initialization Message"
3534	       Frame Relay Session      0x0502    "Initialization Message"
3535	          Parameters
3536	       Label Request            0x0600    "Label Mapping Message"
3537	           Message ID
3538	       Vendor-Private           0x3E00-   "LDP Vendor-private Extensions"
3539	                                0x3EFF
3540	       Experimental             0x3F00-   "LDP Experimental Extensions"
3541	                                0x3FFF

3543	3.9. Status Code Summary

3545	   The following are the Status Codes defined in this version of the
3546	   protocol.

3548	   The "E" column is the required setting of the Status Code E-bit; the
3549	   "Status Data" column is the value of the 30-bit Status Data field in
3550	   the Status Code TLV.

3552	   Note that the setting of the Status Code F-bit is at the discretion
3553	   of the LSR originating the Status TLV.

3555	       Status Code           E   Status Data   Section Title

3557	       Success               0   0x00000000    "Status TLV"
3558	       Bad LDP Identifier    1   0x00000001    "Events Signaled by ..."
3559	       Bad Protocol Version  1   0x00000002    "Events Signaled by ..."
3560	       Bad PDU Length        1   0x00000003    "Events Signaled by ..."
3561	       Unknown Message Type  0   0x00000004    "Events Signaled by ..."
3562	       Bad Message Length    1   0x00000005    "Events Signaled by ..."
3563	       Unknown TLV           0   0x00000006    "Events Signaled by ..."
3564	       Bad TLV length        1   0x00000007    "Events Signaled by ..."
3565	       Malformed TLV Value   1   0x00000008    "Events Signaled by ..."
3566	       Hold Timer Expired    1   0x00000009    "Events Signaled by ..."
3567	       Shutdown              1   0x0000000A    "Events Signaled by ..."
3568	       Loop Detected         0   0x0000000B    "Loop Detection"
3569	       Unknown FEC           0   0x0000000C    "FEC Procedures"
3570	       No Route              0   0x0000000D    "Label Request Mess ..."
3571	       No Label Resources    0   0x0000000E    "Label Request Mess ..."
3572	       Label Resources /     0   0x0000000F    "Label Request Mess ..."
3573	           Available
3574	       Session Rejected/     1   0x00000010    "Session Initialization"
3575	          No Hello
3576	       Session Rejected/     1   0x00000011    "Session Initialization"
3577	          Parameters Advertisement Mode

3579	       Session Rejected/     1   0x00000012    "Session Initialization"
3580	          Parameters Max PDU Length
3581	       Session Rejected/     1   0x00000013    "Session Initialization"
3582	          Parameters Label Range
3583	       KeepAlive Timer       1   0x00000014    "Events Signaled by ..."
3584	           Expired
3585	       Label Request Aborted 0   0x00000015    "Label Request Abort ..."

3587	3.10. Well-known Numbers

3589	3.10.1. UDP and TCP Ports

3591	   The UDP port for LDP Hello messages is 646.

3593	   The TCP port for establishing LDP session connections is 646.

3595	3.10.2. Implicit NULL Label

3597	   The Implicit NULL label (see [ARCH]) is represented as a Generic
3598	   Label TLV with a Label field value as specified by [ENCAP].

3600	4. Security Considerations

3602	   This section specifies an optional mechanism to protect against the
3603	   introduction of spoofed TCP segments into LDP session connection
3604	   streams.

3606	   It is based on use of the TCP MD5 Signature Option specified in
3607	   [rfc2385] for use by BGP.  See [rfc1321] for a specification of the
3608	   MD5 hash function.

3610	4.1. The TCP MD5 Signature Option

3612	   The following quotes from [rfc2385] outline the security properties
3613	   achieved by using the TCP MD5 Signature Option and summarizes its
3614	   operation:

3616	      "IESG Note

3618	         This document describes current existing practice for securing
3619	         BGP against certain simple attacks.  It is understood to have
3620	         security weaknesses against concerted attacks."

3622	      "Abstract
3623	         This memo describes a TCP extension to enhance security for
3624	         BGP.  It defines a new TCP option for carrying an MD5 [RFC1321]
3625	         digest in a TCP segment.  This digest acts like a signature for
3626	         that segment, incorporating information known only to the
3627	         connection end points.  Since BGP uses TCP as its transport,
3628	         using this option in the way described in this paper
3629	         significantly reduces the danger from certain security attacks
3630	         on BGP."

3632	      "Introduction

3634	         The primary motivation for this option is to allow BGP to
3635	         protect itself against the introduction of spoofed TCP segments
3636	         into the connection stream.  Of particular concern are TCP
3637	         resets.

3639	         To spoof a connection using the scheme described in this paper,
3640	         an attacker would not only have to guess TCP sequence numbers,
3641	         but would also have had to obtain the password included in the
3642	         MD5 digest.  This password never appears in the connection
3643	         stream, and the actual form of the password is up to the
3644	         application.  It could even change during the lifetime of a
3645	         particular connection so long as this change was synchronized
3646	         on both ends (although retransmission can become problematical
3647	         in some TCP implementations with changing passwords).

3649	         Finally, there is no negotiation for the use of this option in
3650	         a connection, rather it is purely a matter of site policy
3651	         whether or not its connections use the option."

3653	      "MD5 as a Hashing Algorithm

3655	         Since this memo was first issued (under a different title), the
3656	         MD5 algorithm has been found to be vulnerable to collision
3657	         search attacks [Dobb], and is considered by some to be
3658	         insufficiently strong for this type of application.

3660	         This memo still specifies the MD5 algorithm, however, since the
3661	         option has already been deployed operationally, and there was
3662	         no "algorithm type" field defined to allow an upgrade using the
3663	         same option number.  The original document did not specify a
3664	         type field since this would require at least one more byte, and
3665	         it was felt at the time that taking 19 bytes for the complete
3666	         option (which would probably be padded to 20 bytes in TCP
3667	         implementations) would be too much of a waste of the already
3668	         limited option space.

3670	         This does not prevent the deployment of another similar option
3671	         which uses another hashing algorithm (like SHA-1).  Also, if
3672	         most implementations pad the 18 byte option as defined to 20
3673	         bytes anyway, it would be just as well to define a new option
3674	         which contains an algorithm type field.

3676	         This would need to be addressed in another document, however."

3678	   End of quotes from [rfc2385].

3680	4.2. LDP Use of the TCP MD5 Signature Option

3682	   LDP uses the TCP MD5 Signature Option as follows:

3684	     - Use of the MD5 Signature Option for LDP TCP connections is a
3685	       configurable LSR option.

3687	     - An LSR that uses the MD5 Signature Option is configured with a
3688	       password for each potential LDP peer.

3690	     - The LSR applies the MD5 algorithm as specified in [RFC2385] to
3691	       compute the MD5 digest for a TCP segment to be sent to a peer.
3692	       This computation makes use of the peer password as well as the
3693	       TCP segment.

3695	     - When the LSR receives a TCP segment with an MD5 digest, it
3696	       validates the segment by calculating the MD5 digest (using its
3697	       own record of the password) and compares the computed digest with
3698	       the received digest.  If the comparison fails, the segment is
3699	       dropped without any response to the sender.

3701	     - The LSR ignores LDP Hellos from any LSR for which a password has
3702	       not been configured.  This ensures that the LSR establishes LDP
3703	       TCP connections only with LSRs for which a password has been
3704	       configured.

3706	5. Areas for Future Study

3708	   The following topics not addressed in this version of LDP are
3709	   possible areas for future study:

3711	     - Section 2.16 of the MPLS architecture [ARCH] requires that the
3712	       initial label distribution protocol negotiation between peer LSRs
3713	       enable each LSR to determine whether its peer is capable of
3714	       popping the label stack.  This version of LDP assumes that LSRs
3715	       support label popping for all link types except ATM and Frame
3716	       Relay.  A future version may specify means to make this
3717	       determination part of the session initiation negotiation.

3719	     - LDP support for CoS is not specified in this version.  CoS
3720	       support may be addressed in a future version.

3722	     - LDP support for multicast is not specified in this version.
3723	       Multicast support may be addressed in a future version.

3725	     - LDP support for multipath label switching is not specified in
3726	       this version.  Multipath support may be addressed in a future
3727	       version.

3729	6. Intellectual Property Considerations

3731	   The IETF has been notified of intellectual property rights claimed in
3732	   regard to some or all of the specification contained in this
3733	   document.  For more information consult the online list of claimed
3734	   rights.

3736	7. Acknowledgments

3738	   The ideas and text in this document have been collected from a number
3739	   of sources. We would like to thank Rick Boivie, Ross Callon, Alex
3740	   Conta, Eric Gray, Yoshihiro Ohba, Eric Rosen, Bernard Suter, Yakov
3741	   Rekhter, and Arun Viswanathan.

3743	8. References

3745	   [ARCH] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label
3746	   Switching Architecture", Work in Progress, July 1998.

3748	   [ATM] B. Davie, J. Lawrence, K. McCloghrie, Y. Rekhter, E. Rosen, G.
3749	   Swallow, P. Doolan, "Use of Label Switching With ATM", Work in
3750	   Progress, September, 1998.

3752	   [ATM-VP] N. Feldman, B. Jamoussi, S. Komandur, A, Viswanathan, T
3753	   Worster, "MPLS using ATM VP Switching", Work in Progress, February,
3754	   1999.

3756	   [CRLDP] L. Andersson, A. Fredette, B. Jamoussi, R. Callon, P. Doolan,
3757	   N. Feldman, E. Gray, J. Halpern, J. Heinanen T. E. Kilty, A. G.
3758	   Malis, M. Girish, K. Sundell, P. Vaananen, T. Worster, L. Wu, R.
3759	   Dantu, "Constraint-Based LSP Setup using LDP", Work in Progress,
3760	   January, 1999.

3762	   [DIFFSERV] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W.
3763	   Weiss, "An Architecture for Differentiated Services", Work in
3764	   Progress, October, 1998.

3766	   [ENCAP] E. Rosen, Y. Rekhter, D. Tappan, D. Farinacci, G. Fedorkow,
3767	   T. Li, A. Conta, "MPLS Label Stack Encoding", Work in Progress, July,
3768	   1998.

3770	   [FR] A. Conta, P. Doolan, A. Malis, "Use of Label Switching on Frame
3771	   Relay Networks", Work in Progress, October, 1998.

3773	   [FRAMEWORK] R. Callon, P. Doolan, N. Feldman, A. Fredette, G.
3774	   Swallow, A. Viswanathan, "A Framework for Multiprotocol Label
3775	   Switching", Work in Progress, November 1997.

3777	   [LSPTUN] D. Awduche, L. Berger, D. Gan, T. Li, G. Swallow, Vijay
3778	   Srinivasan, "Extensions to RSVP for LSP Tunnels", Work in Progress,
3779	   November 1998.

3781	   [rfc1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321,
3782	   April 1992.

3784	   [rfc1483] J. Heinanen, "Multiprotocol Encapsulation over ATM
3785	   Adaptation Layer 5", RFC 1483, Telecom Finland, July 1993.

3787	   [rfc1583] J. Moy, "OSPF Version 2", RFC 1583, Proteon Inc, March
3788	   1994.

3790	   [rfc1700] J. Reynolds, J.Postel, "ASSIGNED NUMBERS", October 1994.

3792	   [rfc1771] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)",
3793	   RFC 1771, March 1995.

3795	   [rfc2205] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin,
3796	   "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
3797	   Specification", RFC 2205, September 1997.

3799	   [rfc2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
3800	   Signature Option", RFC 2385, August 1998.

3802	   [TE] D. Awduche, J. Malcolm, J Agogbua, M. O'Dell, J. McManus, "
3803	   Requirements for Traffic Engineering over MPLS", Work in Progress,
3804	   October 1998.

3806	9. Author Information

3808	   Loa Andersson                            Andre Fredette
3809	   Nortel Networks Inc                      Nortel Networks Inc
3810	   St Eriksgatan 115, PO Box 6701           600 Technology Park Drive
3811	   113 85 Stockholm                         Billerica, MA  01821
3812	   Sweden                                   Phone:  978-288-8524
3813	   Phone: +46 8 5088 36 34                  email:
3814	fredette@nortelnetworks.com
3815	   Mobile: +46 70 522 78 34
3816	   email: loa.andersson@nortelnetworks.com

3818	   Paul Doolan                              Bob Thomas
3819	   Ennovate Networks                        Cisco Systems, Inc.
3820	   330 Codman Hill Rd                       250 Apollo Dr.
3821	   Marlborough MA 01719                     Chelmsford, MA 01824
3822	   Phone: 978-263-2002                      Phone:  978-244-8078
3823	   email: pdoolan@ennovatenetworks.com      email: rhthomas@cisco.com

3825	   Nancy Feldman
3826	   IBM Corp.
3827	   17 Skyline Drive
3828	   Hawthorne NY 10532
3829	   Phone:  914-784-3254
3830	   email: nkf@us.ibm.com

3832	Appendix A. LDP Label Distribution Procedures

3834	   This section specifies label distribution behavior in terms of LSR
3835	   response to the following events:

3837	     - Receive Label Request Message;
3838	     - Receive Label Mapping Message;
3839	     - Receive Label Abort Request Message;
3840	     - Receive Label Release Message;
3841	     - Receive Label Withdraw Message;
3842	     - Recognize new FEC;
3843	     - Detect change in FEC next hop;
3844	     - Receive Notification Message / Label Request Aborted;
3845	     - Receive Notification Message / No Label Resources;
3846	     - Receive Notification Message / No Route;
3847	     - Receive Notification Message / Loop Detected;
3848	     - Receive Notification Message / Label Resources Available;
3849	     - Detect local label resources have become available;
3850	     - LSR decides to no longer label switch a FEC;
3851	     - Timeout of deferred label request.

3853	   The specification of LSR behavior in response to an event has three
3854	   parts:

3856	      1. Summary. Prose that describes LSR response to the event in
3857	         overview.

3859	      2. Context. A list of elements referred to by the Algorithm part
3860	         of the specification.  (See 3.)

3862	      3. Algorithm. An algorithm for LSR response to the event.

3864	   The Summary may omit details of the LSR response, such as bookkeeping
3865	   action or behavior dependent on the LSR label advertisement mode,
3866	   control mode, or label retention mode in use. The intent is that the
3867	   Algorithm fully and unambiguously specify the LSR response.

3869	   The algorithms in this section use procedures defined in the MPLS
3870	   architecture specification [ARCH] for hop-by-hop routed traffic.
3871	   These procedures are:

3873	     - Label Distribution procedure, which is performed by a downstream
3874	       LSR to determine when to distribute a label for a FEC to LDP
3875	       peers. The architecture defines four Label Distribution
3876	       procedures:

3878	         . Downstream Unsolicited Independent Control, called
3879	           PushUnconditional in [ARCH].

3881	         . Downstream Unsolicited Ordered Control, called
3882	           PushConditional in [ARCH].

3884	         . Downstream On Demand Independent Control, called
3885	           PulledUnconditional in [ARCH].

3887	         . Downstream On Demand Ordered Control, called
3888	           PulledConditional in [ARCH].

3890	     - Label Withdrawal procedure, which is performed by a downstream
3891	       LSR to determine when to withdraw a FEC label mapping previously
3892	       distributed to LDP peers. The architecture defines a single Label
3893	       Withdrawal procedure. Whenever an LSR breaks the binding between
3894	       a label and a FEC, it must withdraw the FEC label mapping from
3895	       all LDP peers to which it has previously sent the mapping.

3897	     - Label Request procedure, which is performed by an upstream LSR to
3898	       determine when to explicitly request that a downstream LSR bind a
3899	       label to a FEC and send it the corresponding label mapping. The
3900	       architecture defines three Label Request procedures:

3902	         . Request Never. The LSR never requests a label.

3904	         . Request When Needed. The LSR requests a label whenever it
3905	           needs one.

3907	         . Request On Request. This procedure is used by non-label
3908	           merging LSRs. The LSR requests a label when it receives a
3909	           request for one, in addition to whenever it needs one.

3911	     - Label Release procedure, which is performed by an upstream LSR to
3912	       determine when to release a previously received label mapping for
3913	       a FEC. The architecture defines two Label Release procedures:

3915	         . Conservative label retention, called Release On Change in
3916	           [ARCH].

3918	         . Liberal label retention, called No Release On Change in
3919	           [ARCH].

3921	     - Label Use procedure, which is performed by an LSR to determine
3922	       when to start using a FEC label for forwarding/switching. The
3923	       architecture defines three Label Use procedures:

3925	         . Use Immediate. The LSR immediately uses a label received from
3926	           a FEC next hop for forwarding/switching.

3928	         . Use If Loop Free. The LSR uses a FEC label received from a
3929	           FEC next hop for forwarding/switching only if it has
3930	           determined that by doing so it will not cause a forwarding
3931	           loop.

3933	         . Use If Loop Not Detected. This procedure is the same as Use
3934	           Immediate unless the LSR has detected a loop in the FEC LSP.
3935	           Use of the FEC label for forwarding/switching will continue
3936	           until the next hop for the FEC changes or the loop is no
3937	           longer detected.

3939	       This version of LDP does not include a loop prevention mechanism;
3940	       therefore, the procedures below do not make use of the Use If
3941	       Loop Free procedure.

3943	     - Label No Route procedure (called Label Not Available procedure in
3944	       [ARCH]), which is performed by an upstream LSR to determine how
3945	       to respond to a No Route notification from a downstream LSR in
3946	       response to a request for a FEC label mapping.  The architecture
3947	       specification defines two Label No Route procedures:

3949	         . Request Retry. The LSR should issue the label request at a
3950	           later time.

3952	         . No Request Retry. The LSR should assume the downstream LSR
3953	           will provide a label mapping when the downstream LSR has a
3954	           next hop and it should not reissue the request.

3956	A.1. Handling Label Distribution Events

3958	   This section defines LDP label distribution procedures by specifying
3959	   an algorithm for each label distribution event.  The requirement on
3960	   an LDP implementation is that its event handling must have the effect
3961	   specified by the algorithms.  That is, an implementation need not
3962	   follow exactly the steps specified by the algorithms as long as the
3963	   effect is identical.

3965	   The algorithms for handling label distribution events share common
3966	   actions.  The specifications below package these common actions into
3967	   procedure units.  Specifications for these common procedures are in
3968	   their own section "Common Label Distribution Procedures", which
3969	   follows this.

3971	   An implementation would use data structures to store information
3972	   about protocol activity.  This appendix specifies the information to
3973	   be stored in sufficient detail to describe the algorithms, and
3974	   assumes the ability to retrieve the information as needed.  It does
3975	   not specify the details of the data structures.

3977	A.1.1. Receive Label Request

3979	 Summary:

3981	     The response by an LSR to receipt of a FEC label request from an
3982	     LDP peer may involve one or more of the following actions:

3984	     - Transmission of a notification message to the requesting LSR
3985	       indicating why a label mapping for the FEC cannot be provided;

3987	     - Transmission of a FEC label mapping to the requesting LSR;

3989	     - Transmission of a FEC label request to the FEC next hop;

3991	     - Installation of labels for forwarding/switching use by the LSR.

3993	 Context:

3995	     - LSR. The LSR handling the event.

3997	     - MsgSource. The LDP peer that sent the message.

3999	     - FEC. The FEC specified in the message.

4001	     - RAttributes. Attributes received with the message. E.g., Hop
4002	       Count Path Vector.

4004	     - SAttributes. Attributes to be included in Label Request message,
4005	       if any, propagated to FEC Next Hop.

4007	     - StoredHopCount. The hop count, if any, previously recorded for
4008	       the FEC.

4010	 Algorithm:

4012	   LRq.1   Execute procedure Check_Received_Attributes (MsgSource,
4013	           RAttributes).
4014	           If Loop Detected, goto LRq.13.

4016	   LRq.2   Is there a Next Hop for FEC?
4017	           If not, goto LRq.5.

4019	   LRq.3   Is MsgSource the Next Hop?
4020	           Ifnot, goto LRq.6.

4022	   LRq.4   Execute procedure Send_Notification (MsgSource, Loop
4023	           Detected).
4024	           Goto LRq.13

4026	   LRq.5   Execute procedure Send_Notification (MsgSource, No Route).
4027	           Goto LRq.13.

4029	   LRq.6   Has LSR previously received a label request for FEC from
4030	           MsgSource?
4031	           If not, goto LRq.8.  (See Note 1.)

4033	   LRq.7   Is the label request a duplicate request?
4034	           If so, Goto LRq.13.  (See Note 2.)

4036	   LRq.8   Record label request for FEC received from MsgSource and mark
4037	           it pending.

4039	   LRq.9   Perform LSR Label Distribution procedure:

4041	             For Downstream Unsolicited Independent Control OR
4042	             For Downstream On Demand Independent Control

4044	               1.  Has LSR previously received and retained a label
4045	                   mapping for FEC from Next Hop?.
4046	                   Is so, set Propagating to IsPropagating.
4047	                   If not, set Propagating to NotPropagating.

4049	               2.  Execute procedure
4050	                   Prepare_Label_Mapping_Attributes(MsgSource, FEC,
4051	                   RAttributes, SAttributes, Propagating,
4052	                   StoredHopCount).

4054	               3.  Execute procedure Send_Label (MsgSource, FEC,
4055	                   SAttributes).

4057	               4.  Is LSR egress for FEC? OR
4058	                   Has LSR previously received and retained a label
4059	                   mapping for FEC from Next Hop?
4060	                   If so, goto LRq.11.  If not, goto LRq.10.

4062	             For Downstream Unsolicited Ordered Control OR
4063	             For Downstream On Demand Ordered Control

4065	               1.  Is LSR egress for FEC? OR
4066	                   Has LSR previously received and retained a label
4067	                   mapping for FEC from Next Hop?  (See Note 3.)
4068	                   If not, goto LRq.10.

4070	               2.  Execute procedure
4071	                   Prepare_Label_Mapping_Attributes(MsgSource, FEC,
4072	                   RAttributes, SAttributes, IsPropagating,
4073	                   StoredHopCount)

4075	               3.  Execute procedure Send_Label (MsgSource, FEC,
4076	                   SAttributes).
4077	                   Goto LRq.11.

4079	   LRq.10  Perform LSR Label Request procedure:

4081	             For Request Never

4083	               1.  Goto LRq.13.

4085	             For Request When Needed OR
4086	             For Request On Request

4088	               1.  Execute procedure Prepare_Label_Request_Attributes
4089	                   (Next Hop, FEC, RAttributes, SAttributes);

4091	               2.  Execute procedure Send_Label_Request (Next Hop, FEC,
4092	                   SAttributes).
4093	                   Goto LRq.13.

4095	   LRq.11  Has LSR successfully sent a label for FEC to MsgSource?
4096	           If not, goto LRq.13.  (See Note 4.)

4098	   LRq.12  Perform LSR Label Use procedure.

4100	             For Use Immediate OR
4101	             For Use If Loop Not Detected

4103	               1.  Install label sent to MsgSource and label from Next
4104	                   Hop (if LSR is not egress) for forwarding/switching
4105	                   use.

4107	   LRq.13  DONE

4109	 Notes:

4111	      1. In the case where MsgSource is a non-label merging LSR it will
4112	         send a label request for each upstream LDP peer that has
4113	         requested a label for FEC from it. The LSR must be able to
4114	         distinguish such requests from a non-label merging MsgSource
4115	         from duplicate label requests.

4117	         The LSR uses the message ID of received Label Request messages
4118	         to detect duplicate requests.  This means that an LSR (the
4119	         upstream peer) may not reuse the message ID used for a Label
4120	         Request until the Label Request transaction has completed.

4122	      2. When an LSR sends a label request to a peer it records that the
4123	         request has been sent and marks it as outstanding. As long as
4124	         the request is marked outstanding the LSR should not send
4125	         another request for the same label to the peer. Such a second
4126	         request would be a duplicate. The Send_Label_Request procedure
4127	         described below obeys this rule.

4129	         A duplicate label request is considered a protocol error and
4130	         should be dropped by the receiving LSR (perhaps with a suitable
4131	         notification returned to MsgSource).

4133	      3. If LSR is not merge-capable, this test will fail.

4135	      4. The Send_Label procedure may fail due to lack of label
4136	         resources, in which case the LSR should not perform the Label
4137	         Use procedure.

4139	A.1.2. Receive Label Mapping

4141	 Summary:

4143	     The response by an LSR to receipt of a FEC label mapping from an
4144	     LDP peer may involve one or more of the following actions:

4146	     - Transmission of a label release message for the FEC label to the
4147	       LDP peer;

4149	     - Transmission of label mapping messages for the FEC to one or more
4150	       LDP peers,

4152	     - Installation of the newly learned label for forwarding/switching
4153	       use by the LSR.

4155	 Context:

4157	     - LSR. The LSR handling the event.

4159	     - MsgSource. The LDP peer that sent the message.

4161	     - FEC. The FEC specified in the message.

4163	     - Label. The label specified in the message.

4165	     - PrevAdvLabel. The label for FEC, if any, previously advertised to
4166	       an upstream peer.

4168	     - StoredHopCount. The hop count previously recorded for the FEC.

4170	     - RAttributes. Attributes received with the message. E.g., Hop
4171	       Count, Path Vector.

4173	     - SAttributes to be included in Label Mapping message, if any,
4174	       propagated to upstream peers.

4176	 Algorithm:

4178	   LMp.1   Does the received label mapping match an outstanding label
4179	           request for FEC previously sent to MsgSource.
4180	           If not, goto LMp.9.

4182	   LMp.2   Delete record of outstanding FEC label request.

4184	   LMp.3   Execute procedure Check_Received_Attributes (MsgSource,
4185	           RAttributes).
4186	           If No Loop Detected, goto LMp.9.

4188	   LMp.4   Does the LSR have a previously received label mapping for FEC
4189	           from MsgSource?
4190	           If not, goto LMp.8. (See Note 1.).

4192	   LMp.5   Does the label previously received from MsgSource match Label
4193	           (i.e., the label received in the message)?
4194	           If not, goto LMp.8. (See Note 2.)

4196	   LMp.6   Delete matching label mapping for FEC previously received
4197	           from MsgSource.

4199	   LMp.7   Remove Label from forwarding/switching use. (See Note 3.).
4200	           Goto LMp.26.

4202	   LMp.8   Execute procedure Send_Message (MsgSource, Label Release,
4203	           FEC, Label).  Goto LMp.26.

4205	   LMp.9   Determine the Next Hop for FEC.

4207	   LMp.10  Is MsgSource the Next Hop for FEC?
4208	           If so, goto LMp.12.

4210	   LMp.11  Perform LSR Label Release procedure:

4212	             For Conservative Label retention:

4214	               1.  Execute procedure Send_Message (MsgSource, Label
4215	                   Release, FEC, Label).
4216	                   Goto LMp.26.

4218	             For Liberal Label retention:

4220	               1.  Record label mapping for FEC with Label and
4221	                   RAttributes has been received from MsgSource.
4222	                   Goto LMp.26.

4224	   LMp.12  Does LSR have a previously received label mapping for FEC
4225	           from MsgSource?
4226	           If not, goto LMp.14

4228	   LMp.13  Does the label previously received from MsgSource match Label
4229	           (i.e., the label received in the message)?
4230	           If not, goto LMp.8.  (See Note 2.)

4232	   LMp.14  Is LSR an ingress for FEC?
4233	           If not, goto LMp.16.

4235	   LMp.15  Install Label for forwarding/switching use.

4237	   LMp.16  Record label mapping for FEC with Label and RAttributes has
4238	           been received from MsgSource.

4240	   LMp.17  Iterate through for LMp.25 for each Peer, other than
4241	           MsgSource.

4243	   LMp.18  Has LSR previously sent a label mapping for FEC to Peer?
4244	           If not, goto LMp.23.

4246	   LMp.19  Are RAttributes in the received label mapping consistent with
4247	           those previously sent to Peer?
4248	           If so, goto LMp.24.  (See Note 4.)

4250	   LMp.20  Execute procedure Prepare_Label_Mapping_Attributes(Peer, FEC,
4251	           RAttributes, SAttributes, IsPropagating, StoredHopCount).

4253	   LMp.21  Execute procedure Send_Message (Peer, Label Mapping, FEC,
4254	           PrevAdvLabel, SAttributes).  (See Note 5.)

4256	   LMp.22  Update record of label mapping for FEC previously sent to
4257	           Peer to include the new attributes sent.
4258	           Goto LMp.24.

4260	   LMp.23  Perform LSR Label Distribution procedure:

4262	             For Downstream Unsolicited Independent Control OR
4263	             For Downstream Unsolicited Ordered Control

4265	               1.  Execute procedure
4266	                   Prepare_Label_Mapping_Attributes(Peer, FEC,
4267	                   RAttributes, SAttributes, IsPropagating,
4268	                   UnknownHopCount).

4270	               2.  Execute procedure Send_Label (Peer, FEC,
4271	                   SAttributes).
4272	                   If the procedure fails, continue iteration for next
4273	                   Peer at LMp.17.

4275	               3.  Goto LMp.24.

4277	             For Downstream On Demand Independent Control OR
4278	             For Downstream On Demand Ordered Control

4280	               1.  Does LSR have a label request for FEC from Peer
4281	                   marked as pending?
4282	                   If not, continue iteration for next Peer at LMp.17.

4284	               2.  Execute procedure
4285	                   Prepare_Label_Mapping_Attributes(Peer, FEC,
4286	                   RAttributes, SAttributes, IsPropagating,
4287	                   UnknownHopCount)

4289	               3.  Execute procedure Send_Label (Peer, FEC,
4290	                   SAttributes).
4291	                   If the procedure fails, continue iteration for next
4292	                   Peer at LMp.17.

4294	               4.  Goto LMp.24.

4296	   LMp.24  Perform LSR Label Use procedure:

4298	             For Use Immediate OR
4299	             For Use If Loop Not Detected

4301	               1.  Install label received and label sent to Peer for
4302	                   forwarding/switching use.
4303	                   Goto LMp.25.

4305	   LMp.25  End iteration from LMp.17.

4307	   LMp.26  DONE.

4309	 Notes:

4311	      1. If LSR has detected a loop and it has not previously received a
4312	         label mapping from MsgSource for the FEC, it simply releases
4313	         the label.

4315	      2. A mapping with a different label from the same peer would be an
4316	         attempt to establish multipath label switching, which is not
4317	         supported in this version of LDP.

4319	      3. If Label is not in forwarding/switching use, LMp.7 has no
4320	         effect.

4322	      4. The loop detection Path Vector attribute is considered in this
4323	         check.  If the received RAttributes include a Path Vector and
4324	         no Path Vector had been previously sent to the Peer, or if the
4325	         received Path Vector is inconsistent with the Path Vector
4326	         previously sent to the Peer, then the attributes are considered
4327	         to be inconsistent.  Note that an LSR is not required to store
4328	         a received Path Vector after it propagates the Path Vector in a
4329	         mapping message.  If an LSR does not store the Path Vector, it
4330	         has no way to check the consistency of a newly received Path
4331	         Vector.  This means that whenever such an LSR receives a
4332	         mapping message carrying a Path Vector it must always propagate
4333	         the Path Vector.

4335	      5. LMp.19 through LMp.21 deal with a situation that can arise when
4336	         the LSR is using independent control and it receives a mapping
4337	         from the downstream peer after it has sent a mapping to an
4338	         upstream peer. In this situation the LSR needs to propagate any
4339	         changed attributes, such as Hop Count, upstream. If Loop
4340	         Detection is configured on, the propagated attributes must
4341	         include the Path Vector

4343	A.1.3. Receive Label Abort Request

4345	 Summary:

4347	     When an LSR receives a label abort request message from a peer, it
4348	     checks whether it has already responded to the label request in
4349	     question. If it has, it silently ignores the message. If it has
4350	     not, it sends the peer a Label Request Aborted Notification. In
4351	     addition, if it has a label request outstanding for the LSP in
4352	     question to a downstream peer, it sends a Label Abort Request to
4353	     the downstream peer to abort the LSP.

4355	 Context:

4357	     - LSR. The LSR handling the event.

4359	     - MsgSource. The LDP peer that sent the message.

4361	     - FEC. The FEC specified in the message.

4363	     - RequestMessageID. The message ID of the label request message to
4364	       be aborted.

4366	     - Next Hop. The next hop for the FEC.

4368	 Algorithm:

4370	   LAbR.1  Does the message match a previously received label request
4371	           message from MsgSource? (See Note 1.)
4372	           If not, goto LAbR.12.

4374	   LAbR.2  Has LSR responded to the previously received label request?
4375	           If so, goto LAbR.12.

4377	   LAbR.3  Execute procedure Send_Message(MsgSource, Notification, Label
4378	           Request Aborted, TLV), where TLV is the Label Request Message
4379	           ID TLV received in the label abort request message.

4381	   LAbR.4  Does LSR have a label request message outstanding for FEC?
4382	           If so, goto LAbR.7

4384	   LAbR.5  Does LSR have a label mapping for FEC?
4385	           If not, goto LAbR.11

4387	   LAbR.6  Generate Event: Received Label Release Message for FEC from
4388	           MsgSource. (See Note 2.)
4389	           Goto LAbR.11.

4391	   LAbR.7  Is LSR merging the LSP for FEC?
4392	           If not, goto LAbR.9.

4394	   LAbR.8  Are there upstream peers other than MsgSource that have
4395	           requested a label for FEC?
4396	           If so, goto LAbR.11.

4398	   LAbR.9  Execute procedure Send_Message (Next Hop, Label Abort
4399	           Request, FEC, TLV), where TLV is a Label Request Message ID
4400	           TLV containing the Message ID used by the LSR in the
4401	           outstanding Label Request message.

4403	   LAbR.10  Record that a label abort request for FEC is pending.

4405	   LAbR.11  Delete record of label request for FEC from MsgSource.

4407	   LAbR.12  DONE

4409	 Notes:

4411	      1. LSR uses FEC and the Label Request Message ID TLV carried by
4412	         the label abort request to locate its record (if any) for the
4413	         previously received label request from MsgSource.

4415	      2. If LSR has received a label mapping from NextHop, it should
4416	         behave as if it had advertised a label mapping to MsgSource and
4417	         MsgSource has released it.

4419	A.1.4. Receive Label Release

4421	 Summary:

4423	     When an LSR receives a label release message for a FEC from a peer,
4424	     it checks whether other peers hold the released label. If none do,
4425	     the LSR removes the label from forwarding/switching use, if it has
4426	     not already done so, and if the LSR holds a label mapping from the
4427	     FEC next hop, it releases the label mapping.

4429	 Context:

4431	     - LSR. The LSR handling the event.

4433	     - MsgSource. The LDP peer that sent the message.

4435	     - Label. The label specified in the message.

4437	     - FEC. The FEC specified in the message.

4439	 Algorithm:

4441	   LRl.1   Remove MsgSource from record of peers that hold Label for
4442	           FEC.  (See Note 1.)

4444	   LRl.2   Does message match an outstanding label withdraw for FEC
4445	           previously sent to MsgSource?
4446	           If not, goto LRl.4

4448	   LRl.3   Delete record of outstanding label withdraw for FEC
4449	           previously sent to MsgSource.

4451	   LRl.4   Is LSR merging labels for this FEC?
4452	           If not, goto LRl.6.  (See Note 2.)

4454	   LRl.5   Has LSR previously advertised a label for this FEC to other
4455	           peers?
4456	           If so, goto LRl.10.

4458	   LRl.6   Is LSR egress for the FEC?
4459	           If so, goto LRl.10

4461	   LRl.7   Is there a Next Hop for FEC? AND
4462	           Does LSR have a previously received label mapping for FEC
4463	           from Next Hop?
4464	           If not, goto LRl.10.

4466	   LRl.8   Is LSR configured to propagate releases?
4467	           If not, goto LRl.10.  (See Note 3.)

4469	   LRl.9   Execute procedure Send_Message (Next Hop, Label Release, FEC,
4470	           Label from Next Hop).

4472	   LRl.10  Remove Label from forwarding/switching use for traffic from
4473	           MsgSource.

4475	   LRl.11  Do any peers still hold Label for FEC?
4476	           If so, goto LRl.13.

4478	   LRl.12  Free the Label.

4480	   LRl.13  DONE.

4482	 Notes:

4484	      1. If LSR is using Downstream Unsolicited label distribution, it
4485	         should not re-advertise a label mapping for FEC to MsgSource
4486	         until MsgSource requests it.

4488	      2. LRl.4 through LRl.8 deal with determining whether where the LSR
4489	         should propagate the label release to a downstream peer
4490	         (LRl.9).

4492	      3. If LRl.8 is reached, no upstream LSR holds a label for the FEC,
4493	         and the LSR holds a label for the FEC from the FEC Next Hop.
4494	         The LSR could propagate the Label Release to the Next Hop. By
4495	         propagating the Label Release the LSR releases a potentially
4496	         scarce label resource. In doing so, it also increases the
4497	         latency for re-establishing the LSP should MsgSource or some
4498	         other upstream LSR send it a new Label Request for FEC.

4500	         Whether or not to propagate the release is not a protocol
4501	         issue. Label distribution will operate properly whether or not
4502	         the release is propagated. The decision to propagate or not
4503	         should take into consideration factors such as: whether labels
4504	         are a scarce resource in the operating environment; the
4505	         importance of keeping LSP setup latency low by keeping the
4506	         amount of signaling required small; whether LSP setup is
4507	         ingress-controlled or egress-controlled in the operating
4508	         environment.

4510	A.1.5. Receive Label Withdraw

4512	 Summary:

4514	     When an LSR receives a label withdraw message for a FEC from an LDP
4515	     peer, it responds with a label release message and it removes the
4516	     label from any forwarding/switching use. If ordered control is in
4517	     use, the LSR sends a label withdraw message to each LDP peer to
4518	     which it had previously sent a label mapping for the FEC. If the
4519	     LSR is using Downstream on Demand label advertisement with
4520	     independent control, it then acts as if it had just recognized the
4521	     FEC.

4523	 Context:

4525	     - LSR. The LSR handling the event.

4527	     - MsgSource. The LDP peer that sent the message.

4529	     - Label. The label specified in the message.

4531	     - FEC. The FEC specified in the message.

4533	 Algorithm:

4535	   LWd.1   Remove Label from forwarding/switching use.  (See Note 1.)

4537	   LWd.2   Execute procedure Send_Message (MsgSource, Label Release,
4538	           FEC, Label)

4540	   LWd.3   Has LSR previously received and retained a matching label
4541	           mapping for FEC from MsgSource?
4542	           If not, goto LWd.13.

4544	   LWd.4   Delete matching label mapping for FEC previously received
4545	           from MsgSource.

4547	   LWd.5   Is LSR using ordered control?
4548	           If so, goto LWd.8.

4550	   LWd.6   Is MsgSource using Downstream On Demand label advertisement?
4551	           If not, goto LWd.13.

4553	   LWd.7   Generate Event: Recognize New FEC for FEC.
4554	           Goto LWd.13.  (See Note 2.)

4556	   LWd.8   Iterate through LWd.12 for each Peer, other than MsgSource.

4558	   LWd.9   Has LSR previously sent a label mapping for FEC to Peer?
4559	           If not, continue iteration for next Peer at LWd.8.

4561	   LWd.10  Does the label previously sent to Peer "map" to the withdrawn
4562	           Label?
4563	           If not, continue iteration for next Peer at LWd.8.  (See Note
4564	           3.)

4566	   LWd.11  Execute procedure Send_Label_Withdraw (Peer, FEC, Label
4567	           previously sent to Peer).

4569	   LWd.12  End iteration from LWd.8.

4571	   LWd.13  DONE

4573	 Notes:

4575	      1. If Label is not in forwarding/switching use, LWd.1 has no
4576	         effect.

4578	      2. LWd.7 handles the case where the LSR is using Downstream On
4579	         Demand label distribution with independent control. In this
4580	         situation the LSR should send a label request to the FEC next
4581	         hop as if it had just recognized the FEC.

4583	      3. LWd.10 handles both label merging (one or more incoming labels
4584	         map to the same outgoing label) and no label merging (one label
4585	         maps to the outgoing label) cases.

4587	A.1.6. Recognize New FEC

4589	 Summary:

4591	     The response by an LSR to learning a new FEC via the routing table
4592	     may involve one or more of the following actions:

4594	     - Transmission of label mappings for the FEC to one or more LDP
4595	       peers;

4597	     - Transmission of a label request for the FEC to the FEC next hop;

4599	     - Any of the actions that can occur when the LSR receives a label
4600	       mapping for the FEC from the FEC next hop.

4602	 Context:

4604	     - LSR. The LSR handling the event.

4606	     - FEC. The newly recognized FEC.

4608	     - Next Hop. The next hop for the FEC.

4610	     - InitAttributes. Attributes to be associated with the new FEC.
4611	       (See Note 1.)

4613	     - SAttributes. Attributes to be included in Label Mapping or Label
4614	       Request messages, if any, sent to peers.

4616	     - StoredHopCount. Hop count associated with FEC label mapping, if
4617	       any, previously received from Next Hop.

4619	 Algorithm:

4621	   FEC.1   Perform LSR Label Distribution procedure:

4623	             For Downstream Unsolicited Independent Control

4625	               1.  Iterate through 5 for each Peer.

4627	               2.  Has LSR previously received and retained a label
4628	                   mapping for FEC from Next Hop?
4629	                   If so, set Propagating to IsPropagating.
4630	                   If not, set Propagating to NotPropagating.

4632	               3.  Execute procedure Prepare_Label_Mapping_Attributes
4633	                   (Peer, FEC, InitAttributes, SAttributes, Propagating,
4634	                   Unknown hop count(0)).

4636	               4.  Execute procedure Send_Label (Peer, FEC, SAttributes)

4638	               5.  End iteration from 1.
4639	                   Goto FEC.2.

4641	             For Downstream Unsolicited Ordered Control

4643	               1.  Iterate through 5 for each Peer.

4645	               2.  Is LSR egress for the FEC? OR
4646	                   Has LSR previously received and retained a label
4647	                   mapping for FEC from Next Hop?
4648	                   If not, continue iteration for next Peer.

4650	               3.  Execute procedure Prepare_Label_Mapping_Attributes
4651	                   (Peer, FEC, InitAttributes, SAttributes, Propagating,
4652	                   StoredHopCount).

4654	               4.  Execute procedure Send_Label (Peer, FEC, SAttributes)

4656	               5.  End iteration from 1.
4657	                   Goto FEC.2.

4659	             For Downstream On Demand Independent Control OR
4660	             For Downstream On Demand Ordered Control

4662	               1.  Goto FEC.2.  (See Note 2.)

4664	   FEC.2   Has LSR previously received and retained a label mapping for
4665	           FEC from Next Hop?
4666	           If so, goto FEC.5

4668	   FEC.3   Is Next Hop an LDP peer?
4669	           If not, Goto FEC.6

4671	   FEC.4   Perform LSR Label Request procedure:

4673	             For Request Never

4675	               1.  Goto FEC.6

4677	             For Request When Needed OR
4678	             For Request On Request

4680	               1.  Execute procedure Prepare_Label_Request_Attributes
4681	                   (Next Hop, FEC, InitAttributes, SAttributes);

4683	               2.  Execute procedure Send_Label_Request (Next Hop, FEC,
4684	                   SAttributes).
4685	                   Goto FEC.6.

4687	   FEC.5   Generate Event: Received Label Mapping from Next Hop.  (See
4688	           Note 3.)

4690	   FEC.6   DONE.

4692	 Notes:

4694	      1. An example of an attribute that might be part of InitAttributes
4695	         is one which specifies desired LSP characteristics, such as
4696	         class of service (CoS).  (Note that while the current version
4697	         of LDP does not specify a CoS attribute, LDP extensions may.)
4698	         The means by which FEC InitAttributes, if any, are specified is
4699	         beyond the scope of LDP. Note that the InitAttributes will not
4700	         include a known Hop Count or a Path Vector.

4702	      2. An LSR using Downstream On Demand label distribution would send
4703	         a label only if it had a previously received label request
4704	         marked as pending. The LSR would have no such pending requests
4705	         because it responds to any label request for an unknown FEC by
4706	         sending the requesting LSR a No Route notification and
4707	         discarding the label request; see LRq.3

4709	      3. If the LSR has a label for the FEC from the Next Hop, it should
4710	         behave as if it had just received the label from the Next Hop.
4711	         This occurs in the case of Liberal label retention mode.

4713	A.1.7. Detect Change in FEC Next Hop

4715	 Summary:

4717	     The response by an LSR to a change in the next hop for a FEC may
4718	     involve one or more of the following actions:

4720	     - Removal of the label from the FEC's old next hop from
4721	       forwarding/switching use;

4723	     - Transmission of label mapping messages for the FEC to one or more
4724	       LDP peers;

4726	     - Transmission of a label request to the FEC's new next hop;
4727	     - Any of the actions that can occur when the LSR receives a label
4728	       mapping from the FEC's new next hop.

4730	 Context:

4732	     - LSR. The LSR handling the event.

4734	     - FEC. The FEC whose next hop changed.

4736	     - New Next Hop. The current next hop for the FEC.

4738	     - Old Next Hop. The previous next hop for the FEC.

4740	     - OldLabel. Label, if any, previously received from Old Next Hop.

4742	     - CurAttributes. The attributes, if any, currently associated with
4743	       the FEC.

4745	     - SAttributes. Attributes to be included in Label Label Request
4746	       message, if any, sent to New Next Hop.

4748	 Algorithm:

4750	    NH.1   Has LSR previously received and retained a label mapping for
4751	           FEC from Old Next Hop?
4752	           If not, goto NH.6.

4754	    NH.2   Remove label from forwarding/switching use. (See Note 1.)

4756	    NH.3   Is LSR using Liberal label retention?
4757	           If so, goto NH.6.

4759	    NH.4   Execute procedure Send_Message (Old Next Hop, Label Release,
4760	           OldLabel).

4762	    NH.5   Delete label mapping for FEC previously received from Old
4763	           Next Hop.

4765	    NH.6   Does LSR have a label request pending with Old Next Hop?
4766	           If not, goto NH.10.

4768	    NH.7   Is LSR using Conservative label retention?
4769	           If not, goto NH.10.

4771	    NH.8   Execute procedure Send_Message (Old Next Hop, Label Abort
4772	           Request, FEC, TLV), where TLV is a Label Request Message ID
4773	           TLV that carries the message ID of the pending label request.

4775	    NH.9   Record a label abort request is pending for FEC with Old Next
4776	           Hop.

4778	    NH.10  Is there a New Next Hop for the FEC?
4779	           If not, goto NH.16.

4781	    NH.11  Has LSR previously received and retained a label mapping for
4782	           FEC from New Next Hop?
4783	           If not, goto NH.13.

4785	    NH.12  Generate Event: Received Label Mapping from New Next Hop.
4786	           Goto NH.20. (See Note 2.)

4788	    NH.13  Is LSR using Downstream on Demand advertisement? OR
4789	           Is Next Hop using Downstream on Demand advertisement? OR
4790	           Is LSR using Conservative label retention? (See Note 3.)
4791	           If so, goto NH.14.
4792	           If not, goto NH.20.

4794	    NH.14  Execute procedure Prepare_Label_Request_Attributes (Next Hop,
4795	           FEC, CurAttributes, SAttributes)

4797	    NH.15  Execute procedure Send_Label_Request (New Next Hop, FEC,
4798	           SAttributes).  (See Note 4.)
4799	           Goto NH.20.

4801	    NH.16  Iterate through NH.19 for each Peer.

4803	    NH.17  Has LSR previously sent a label mapping for FEC to Peer?
4804	           If not, continue iteration for next Peer at NH.16.

4806	    NH.18  Execute procedure Send_Label_Withdraw (Peer, FEC, Label
4807	           previously sent to Peer).

4809	    NH.19  End iteration from NH.16.

4811	    NH.20  DONE.

4813	 Notes:

4815	      1. If Label is not in forwarding/switching use, NH.2 has no
4816	         effect.

4818	      2. If the LSR has a label for the FEC from the New Next Hop, it
4819	         should behave as if it had just received the label from the New
4820	         Next Hop.

4822	      3. The purpose of the check on label retention mode is to avoid a
4823	         race with steps LMp.10-LMp.11 of the procedure for handling a
4824	         Label Mapping message where the LSR operating in Conservative
4825	         Label retention mode may have released a label mapping received
4826	         from the New Next Hop before it detected the FEC next hop had
4827	         changed.

4829	      4. Regardless of the Label Request procedure in use by the LSR, it
4830	         must send a label request if the conditions in NH.8 hold.
4831	         Therefore it executes the Send_Label_Request procedure directly
4832	         rather than perform LSR Label Request procedure.

4834	A.1.8. Receive Notification / Label Request Aborted

4836	 Summary:

4838	     When an LSR receives a Label Request Aborted notification from an
4839	     LDP peer it records that the corresponding label request
4840	     transaction, if any, has completed.

4842	 Context:

4844	     - LSR. The LSR handling the event.

4846	     - FEC. The FEC for which a label was requested.

4848	     - RequestMessageID. The message ID of the label request message to
4849	       be aborted.

4851	     - MsgSource. The LDP peer that sent the Notification message.

4853	 Algorithm:

4855	   LRqA.1  Does the notification correspond to an outstanding label
4856	           request abort for FEC? (See Note 1).
4857	           If not, goto LRqA.3.

4859	   LRqA.2  Record that the label request for FEC has been aborted.

4861	   LRqA.3  DONE

4863	 Notes:

4865	      1. The LSR uses the FEC and RequestMessageID to locate its record,
4866	         if any, of the outstanding label request abort.

4868	A.1.9. Receive Notification / No Label Resources

4870	 Summary:

4872	     When an LSR receives a No Label Resources notification from an LDP
4873	     peer, it stops sending label request messages to the peer until it
4874	     receives a Label Resources Available Notification from the peer.

4876	 Context:

4878	     - LSR. The LSR handling the event.

4880	     - FEC. The FEC for which a label was requested.

4882	     - MsgSource. The LDP peer that sent the Notification message.

4884	 Algorithm:

4886	   NoRes.1 Delete record of outstanding label request for FEC sent to
4887	           MsgSource.

4889	   NoRes.2 Record label mapping for FEC from MsgSource is needed but
4890	           that no label resources are available.

4892	   NoRes.3 Set status record indicating it is not OK to send label
4893	           requests to MsgSource.

4895	   NoRes.4 DONE.

4897	A.1.10. Receive Notification / No Route

4899	 Summary:

4901	     When an LSR receives a No Route notification from an LDP peer in
4902	     response to a Label Request message, the Label No Route procedure
4903	     in use dictates its response. The LSR either will take no further
4904	     action, or it will defer the label request by starting a timer and
4905	     send another Label Request message to the peer when the timer later
4906	     expires.

4908	 Context:

4910	     - LSR. The LSR handling the event.

4912	     - FEC. The FEC for which a label was requested.

4914	     - Attributes. The attributes associated with the label request.

4916	     - MsgSource. The LDP peer that sent the Notification message.

4918	 Algorithm:

4920	   NoNH.1  Delete record of outstanding label request for FEC sent to
4921	           MsgSource.

4923	   NoNH.2  Perform LSR Label No Route procedure.

4925	             For Request No Retry

4927	               1.  Goto NoNH.3.

4929	             For Request Retry

4931	               1.  Record deferred label request for FEC and Attributes
4932	                   to be sent to MsgSource.

4934	               2.  Start timeout. Goto NoNH.3.

4936	   NoNH.3  DONE.

4938	A.1.11. Receive Notification / Loop Detected

4940	 Summary:

4942	     When an LSR receives a Loop Detected notification from an LDP peer
4943	     in response to a Label Request message, it behaves as if it had
4944	     received a No Route notification.

4946	     Context:

4948	         See "Receive Notification / No Route".

4950	     Algorithm:

4952	         See "Receive Notification / No Route"

4954	A.1.12. Receive Notification / Label Resources Available

4956	 Summary:

4958	     When an LSR receives a Label Resources Available notification from
4959	     an LDP peer, it resumes sending label requests to the peer.

4961	 Context:

4963	     - LSR. The LSR handling the event.

4965	     - MsgSource. The LDP peer that sent the Notification message.

4967	     - SAttributes. Attributes stored with postponed Label Request
4968	       message.

4970	 Algorithm:

4972	   Res.1   Set status record indicating it is OK to send label requests
4973	           to MsgSource.

4975	   Res.2   Iterate through Res.6 for each record of a FEC label mapping
4976	           needed from MsgSource for which no label resources are
4977	           available.

4979	   Res.3   Is MsgSource the next hop for FEC?
4980	           If not, goto Res.5.

4982	   Res.4   Execute procedure Send_Label_Request (MsgSource, FEC,
4983	           SAttributes).  If the procedure fails, terminate iteration.

4985	   Res.5   Delete record that no resources are available for a label
4986	           mapping for FEC needed from MsgSource.

4988	   Res.6   End iteration from Res.2

4990	   Res.7   DONE.

4992	A.1.13. Detect local label resources have become available

4994	 Summary:

4996	     After an LSR has sent a No Label Resources notification to an LDP
4997	     peer, when label resources later become available it sends a Label
4998	     Resources Available notification to each such peer.

5000	 Context:

5002	     - LSR. The LSR handling the event.

5004	     - Attributes. Attributes stored with postponed Label Mapping
5005	       message.

5007	 Algorithm:

5009	   ResA.1  Iterate through ResA.4 for each Peer to which LSR has
5010	           previously sent a No Label Resources notification.

5012	   ResA.2  Execute procedure Send_Notification (Peer, Label Resources
5013	           Available)

5015	   ResA.3  Delete record that No Label Resources notification was
5016	           previously sent to Peer.

5018	   ResA.4  End iteration from ResA.1

5020	   ResA.5  Iterate through ResA.8 for each record of a label mapping
5021	           needed for FEC for Peer but no-label-resources.  (See Note
5022	           1.)

5024	   ResA.6  Execute procedure Send_Label (Peer, FEC, Attributes). If the
5025	           procedure fails, terminate iteration.

5027	   ResA.7  Clear record of FEC label mapping needed for peer but no-
5028	           label-resources.

5030	   ResA.8  End iteration from ResA.5

5032	   ResA.9  DONE.

5034	 Notes:

5036	      1. Iteration ResA.5 through ResA.8 handles the situation where the
5037	         LSR is using Downstream Unsolicited label distribution and was
5038	         previously unable to allocate a label for a FEC.

5040	A.1.14. LSR decides to no longer label switch a FEC
5041	 Summary:

5043	     An LSR may unilaterally decide to no longer label switch a FEC for
5044	     an LDP peer. An LSR that does so must send a label withdraw message
5045	     for the FEC to the peer.

5047	 Context:

5049	     - Peer. The peer.

5051	     - FEC. The FEC.

5053	     - PrevAdvLabel. The label for FEC previously advertised to Peer.

5055	 Algorithm:

5057	   NoLS.1  Execute procedure Send_Label_Withdraw (Peer, FEC,
5058	           PrevAdvLabel).  (See Note 1.)

5060	   NoLS.2  DONE.

5062	 Notes:

5064	      1. The LSR may remove the label from forwarding/switching use as
5065	         part of this event or as part of processing the label release
5066	         from the peer in response to the label withdraw.

5068	A.1.15. Timeout of deferred label request

5070	 Summary:

5072	     Label requests are deferred in response to No Route and Loop
5073	     Detected notifications.  When a deferred FEC label request for a
5074	     peer times out, the LSR sends the label request.

5076	 Context:

5078	     - LSR. The LSR handling the event.

5080	     - FEC. The FEC associated with the timeout event.

5082	     - Peer. The LDP peer associated with the timeout event.

5084	     - Attributes. Attributes stored with deferred Label Request
5085	       message.

5087	 Algorithm:

5089	   TO.1    Retrieve the record of the deferred label request.

5091	   TO.2    Is Peer the next hop for FEC?
5092	           If not, goto TO.4.

5094	   TO.3    Execute procedure Send_Label_Request (Peer, FEC).

5096	   TO.4    DONE.

5098	A.2. Common Label Distribution Procedures

5100	   This section specifies utility procedures used by the algorithms that
5101	   handle label distribution events.

5103	A.2.1. Send_Label

5105	 Summary:

5107	     The Send_Label procedure allocates a label for a FEC for an LDP
5108	     peer, if possible, and sends a label mapping for the FEC to the
5109	     peer. If the LSR is unable to allocate the label and if it has a
5110	     pending label request from the peer, it sends the LDP peer a No
5111	     Label Resources notification.

5113	 Parameters:

5115	     - Peer. The LDP peer to which the label mapping is to be sent.

5117	     - FEC. The FEC for which a label mapping is to be sent.

5119	     - Attributes. The attributes to be included with the label mapping.

5121	 Additional Context:

5123	     - LSR. The LSR executing the procedure.

5125	     - Label. The label allocated and sent to Peer.

5127	 Algorithm:

5129	    SL.1   Does LSR have a label to allocate?
5130	           If not, goto SL.9.

5132	    SL.2   Allocate Label and bind it to the FEC.

5134	    SL.3   Install Label for forwarding/switching use.

5136	    SL.4   Execute procedure Send_Message (Peer, Label Mapping, FEC,
5137	           Label, Attributes).

5139	    SL.5   Record label mapping for FEC with Label and Attributes has
5140	           been sent to Peer.

5142	    SL.6   Does LSR have a record of a FEC label request from Peer
5143	           marked as pending?
5144	           If not, goto SL.8.

5146	    SL.7   Delete record of pending label request for FEC from Peer.

5148	    SL.8   Return success.

5150	    SL.9   Does LSR have a label request for FEC from Peer marked as
5151	           pending?
5152	           If not, goto SL.13.

5154	    SL.10  Execute procedure Send_Notification (Peer, No Label
5155	           Resources).

5157	    SL.11  Delete record of pending label request for FEC from Peer.

5159	    SL.12  Record No Label Resources notification has been sent to Peer.
5160	           Goto SL.14.

5162	    SL.13  Record label mapping needed for FEC and Attributes for Peer,
5163	           but no-label-resources. (See Note 1.)

5165	    SL.14  Return failure.

5167	 Notes:

5169	      1. SL.13 handles the case of Downstream Unsolicited label
5170	         distribution when the LSR is unable to allocate a label for a
5171	         FEC to send to a Peer.

5173	A.2.2. Send_Label_Request

5175	 Summary:

5177	     An LSR uses the Send_Label_Request procedure to send a request for
5178	     a label for a FEC to an LDP peer if currently permitted to do so.

5180	 Parameters:

5182	     - Peer. The LDP peer to which the label request is to be sent.

5184	     - FEC. The FEC for which a label request is to be sent.

5186	     - Attributes. Attributes to be included in the label request. E.g.,
5187	       Hop Count, Path Vector.

5189	 Additional Context:

5191	     - LSR. The LSR executing the procedure.

5193	 Algorithm:

5195	   SLRq.1  Has a label request for FEC previously been sent to Peer and
5196	           is it marked as outstanding?
5197	           If so, Return success.  (See Note 1.)

5199	   SLRq.2  Is status record indicating it is OK to send label requests
5200	           to Peer set?
5201	           If not, goto SLRq.6

5203	   SLRq.3  Execute procedure Send_Message (Peer, Label Request, FEC,
5204	           Attributes).

5206	   SLRq.4  Record label request for FEC has been sent to Peer and mark
5207	           it as outstanding.

5209	   SLRq.5  Return success.

5211	   SLRq.6  Postpone the label request by recording label mapping for FEC
5212	           and Attributes from Peer is needed but that no label
5213	           resources are available.

5215	   SLRq.7  Return failure.

5217	 Notes:

5219	      1. If the LSR is a non-merging LSR it must distinguish between
5220	         attempts to send label requests for a FEC triggered by
5221	         different upstream LDP peers from duplicate requests. This
5222	         procedure will not send a duplicate label request.

5224	A.2.3. Send_Label_Withdraw

5226	 Summary:

5228	     An LSR uses the Send_Label_Withdraw procedure to withdraw a label
5229	     for a FEC from an LDP peer. To do this the LSR sends a Label
5230	     Withdraw message to the peer.

5232	 Parameters:

5234	     - Peer. The LDP peer to which the label withdraw is to be sent.

5236	     - FEC. The FEC for which a label is being withdrawn.

5238	     - Label. The label being withdrawn

5240	 Additional Context:

5242	     - LSR. The LSR executing the procedure.

5244	 Algorithm:

5246	    SWd.1  Execute procedure Send_Message (Peer, Label Withdraw, FEC,
5247	           Label)

5249	    SWd.2  Record label withdraw for FEC has been sent to Peer and mark
5250	           it as outstanding.

5252	A.2.4. Send_Notification

5254	 Summary:

5256	     An LSR uses the Send_Notification procedure to send an LDP peer a
5257	     notification message.

5259	 Parameters:

5261	     - Peer. The LDP peer to which the Notification message is to be
5262	       sent.

5264	     - Status. Status code to be included in the Notification message.

5266	 Additional Context:

5268	     None.

5270	 Algorithm:

5272	   SNt.1  Execute procedure Send_Message (Peer, Notification, Status)

5274	A.2.5. Send_Message

5276	 Summary:

5278	     An LSR uses the Send_Message procedure to send an LDP peer an LDP
5279	     message.

5281	 Parameters:

5283	     - Peer. The LDP peer to which the message is to be sent.

5285	     - Message Type. The type of message to be sent.

5287	     - Additional message contents . . .  .

5289	 Additional Context:

5291	     None.

5293	 Algorithm:

5295	     This procedure is the means by which an LSR sends an LDP message of
5296	     the specified type to the specified LDP peer.

5298	A.2.6. Check_Received_Attributes

5300	 Summary:

5302	     Check the attributes received in a Label Mapping or Label Request
5303	     message. If the attributes include a Hop Count or Path Vector,
5304	     perform a loop detection check. If a loop is detected, send a Loop
5305	     Detected Notification message to MsgSource.

5307	 Parameters:

5309	     - MsgSource. The LDP peer that sent the message.

5311	     - RAttributes. The attributes in the message.

5313	 Additional Context:

5315	     - LSR Id. The unique LSR Id of this LSR.

5317	     - Hop Count. The Hop Count, if any, in the received attributes.

5319	     - Path Vector. The Path Vector, if any in the received attributes.

5321	 Algorithm:

5323	   CRa.1   Do RAttributes include Hop Count?
5324	           If not, goto CRa.5.

5326	   CRa.2   Does Hop Count exceed Max allowable hop count?
5327	           If so, goto CRa.6.

5329	   CRa.3   Do RAttributes include Path Vector?
5330	           If not, goto CRa.5.

5332	   CRa.4   Does Path Vector Include LSR Id? OR
5333	           Does length of Path Vector exceed Max allowable length?
5334	           If so, goto CRa.6

5336	   CRa.5   Return No Loop Detected.

5338	   CRa.6   Execute procedure Send_Notification (MsgSource, Loop
5339	           Detected)

5341	   CRa.7   Return Loop Detected.

5343	   CRa.8   DONE

5345	A.2.7. Prepare_Label_Request_Attributes

5347	 Summary:

5349	     This procedure is used whenever a Label Request is to be sent to a
5350	     Peer to compute the Hop Count and Path Vector, if any, to include
5351	     in the message.

5353	 Parameters:

5355	     - Peer. The LDP peer to which the message is to be sent.

5357	     - FEC. The FEC for which a label request is to be sent.

5359	     - RAttributes. The attributes this LSR associates with the LSP for
5360	       FEC.

5362	     - SAttributes. The attributes to be included in the Label Request
5363	       message.

5365	 Additional Context:

5367	     - LSR Id. The unique LSR Id of this LSR.

5369	 Algorithm:

5371	   PRqA.1  Is Hop Count required for this Peer (see Note 1.) ? OR
5372	           Do RAttributes include a Hop Count? OR
5373	           Is Loop Detection configured on LSR?
5374	           If not, goto PRqA.14.

5376	   PRqA.2  Is LSR ingress for FEC?
5377	           If not, goto PRqA.6.

5379	   PRqA.3  Include Hop Count of 1 in SAttributes.

5381	   PRqA.4  Is Loop Detection configured on LSR?
5382	           If not, goto PRqA.14.

5384	   PRqA.5  Is LSR merge-capable?
5385	           If so, goto PRqA.14.
5386	           If not, goto PRqA.13.

5388	   PRqA.6  Do RAttributes include a Hop Count?
5389	           If not, goto PRqA.8.

5391	   PRqA.7  Increment RAttributes Hop Count and copy the resulting Hop
5392	           Count to SAttributes. (See Note 2.)
5393	           Goto PRqA.9.

5395	   PRqA.8  Include Hop Count of unknown (0) in SAttributes.

5397	   PRqA.9  Is Loop Detection configured on LSR?
5398	           If not, goto PRqA.14.

5400	   PRqA.10 Do RAttributes have a Path Vector?
5401	           If so, goto PRqA.12.

5403	   PRqA.11 Is LSR merge-capable?
5404	           If so, goto PRqA.14.
5405	           If not, goto PRqA.13.

5407	   PRqA.12 Add LSR Id to beginning of Path Vector from RAttributes and
5408	           copy the resulting Path Vector into SAttributes.
5409	           Goto PRqA.14.

5411	   PRqA.13 Include Path Vector of length 1 containing LSR Id in
5412	           SAttributes.

5414	   PRqA.14 DONE.

5416	 Notes:

5418	      1. The link with Peer may require that Hop Count be included in
5419	         Label Request messages; for example, see [ATM] and [FR].

5421	      2. For hop count arithmetic, unknown + 1 = unknown.

5423	A.2.8. Prepare_Label_Mapping_Attributes

5425	 Summary:

5427	     This procedure is used whenever a Label Mapping is to be sent to a
5428	     Peer to compute the Hop Count and Path Vector, if any, to include
5429	     in the message.

5431	 Parameters:

5433	     - Peer. The LDP peer to which the message is to be sent.

5435	     - FEC. The FEC for which a label request is to be sent.

5437	     - RAttributes. The attributes this LSR associates with the LSP for
5438	       FEC.

5440	     - SAttributes. The attributes to be included in the Label Mapping
5441	       message.

5443	     - IsPropagating. The LSR is sending the Label Mapping message to
5444	       propagate one received from the FEC next hop.

5446	     - PrevHopCount. The Hop Count, if any, this LSR associates with the
5447	       LSP for the FEC.

5449	 Additional Context:

5451	     - LSR Id. The unique LSR Id of this LSR.

5453	 Algorithm:

5455	   PMpA.1  Is Hop Count required for this Peer (see Note 1.) ? OR
5456	           Do RAttributes include a Hop Count? OR
5457	           Is Loop Detection configured on LSR?
5458	           If not, goto PMpA.21.

5460	   PMpA.2  Is LSR egress for FEC?
5461	           If not, goto PMpA.4.

5463	   PMpA.3  Include Hop Count of 1 in SAttributes. Goto PMpA.21.

5465	   PMpA.4  Do RAttributes have a Hop Count?
5466	           If not, goto PMpA.8.

5468	   PMpA.5  Is LSR member of edge set for an LSR domain whose LSRs do not
5469	           perform TTL decrement AND
5470	           Is Peer in that domain (See Note 2.).
5471	           If not, goto PMpA.7.

5473	   PMpA.6  Include Hop Count of 1 in SAttributes. Goto PMpA.9.

5475	   PMpA.7  Increment RAttributes Hop Count and copy the resulting Hop
5476	           Count to SAttributes. See Note 2. Goto PMpA.9.

5478	   PMpA.8  Include Hop Count of unknown (0) in SAttributes.

5480	   PMpA.9  Is Loop Detection configured on LSR?
5481	           If not, goto PMpA.21.

5483	   PMpA.10 Do RAttributes have a Path Vector?
5484	           If so, goto PMpA.19.

5486	   PMpA.11 Is LSR propagating a received Label Mapping?
5487	           If not, goto PMpA.20.

5489	   PMpA.12 Does LSR support merging?
5490	           If not, goto PMpA.14.

5492	   PMpA.13 Has LSR previously sent a Label Mapping for FEC to Peer?
5493	           If not, goto PMpA.20.

5495	   PMpA.14 Do RAttributes include a Hop Count?
5496	           If not, goto PMpA.21.

5498	   Res.15 Is Hop Count in Rattributes unknown(0)?
5499	           If so, goto PMpA.20.

5501	   PMpA.16 Has LSR previously sent a Label Mapping for FEC to Peer?
5502	           If not goto PMpA.21.

5504	   PMpA.17 Is Hop Count in RAttributes different from PrevHopCount ?
5505	           If not goto PMpA.21.

5507	   PMpA.18 Is the Hop Count in RAttributes > PrevHopCount? OR
5508	           Is PrevHopCount unknown(0)
5509	           If not, goto PMpA.21.

5511	   PMpA.19 Add LSR Id to beginning of Path Vector from RAttributes and
5512	           copy the resulting Path Vector into SAttributes. Goto
5513	           PMpA.21.

5515	   PMpA.20 Include Path Vector of length 1 containing LSR Id in
5516	           SAttributes.

5518	   PMpA.21 DONE.

5520	 Notes:

5522	      1. The link with Peer may require that Hop Count be included in
5523	         Label Mapping messages; for example, see [ATM] and [FR].

5525	      2. If the LSR is at the edge of a cloud of LSRs that do not
5526	         perform TTL-decrement and it is propagating the Label Mapping
5527	         message upstream into the cloud, it sets the Hop Count to 1 so
5528	         that Hop Count across the cloud is calculated properly.  This
5529	         ensures proper TTL management for packets forwarded across the
5530	         part of the LSP that passes through the cloud.

5532	      3. For hop count arithmetic, unknown + 1 = unknown.