idnits 2.17.1 

draft-ietf-mpls-ldp-05.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:
  ----------------------------------------------------------------------------

  ** Missing expiration date.  The document expiration date should appear on
     the first and last page.

  == 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 14 instances of too long lines in the document, the longest
     one being 3 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 922: '...   LSR MUST wait until a label from a ...'
     RFC 2119 keyword, line 1071: '... Request message MUST include a Hop Co...'
     RFC 2119 keyword, line 1074: '...     MUST include a Hop Count TLV with...'
     RFC 2119 keyword, line 1078: '...Hop Count TLV, R MUST increment the re...'
     RFC 2119 keyword, line 1079: '...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 (June 1999) is 9081 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 3649, but not defined

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

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

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

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

  == Unused Reference: 'LSPTUN' is defined on line 3779, 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: 8 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: December 1999
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	                                                               June 1999

18	                           LDP Specification

20	                       draft-ietf-mpls-ldp-05.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 bindins it has made.  This document defines
52	   a set of such procedures called LDP (for Label Distribution
53	   Protocol).

55	Changes from Previous Draft

57	     - This draft addresses issues raised during the LDP last call held
58	       February 8, 1999 through February 24, 1999.

60	Open Issues

62	   The following LDP issues are left unresolved with this version of the
63	   spec:

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

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

76	     - LDP support for multicast is not specified in this version.
77	       Multicast support will be addressed in a future version.

79	     - LDP support for multipath label switching is not specified in
80	       this version.  Multipath support will be addressed in a future
81	       version.

83	Table of Contents

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

196	    Appendix.A LDP Label Distribution Procedures  ..................  87
197	    A.1        Handling Label Distribution Events  .................  89
198	    A.1.1      Receive Label Request  ..............................  90
199	    A.1.2      Receive Label Mapping  ..............................  93
200	    A.1.3      Receive Label Abort Request  ........................  98
201	    A.1.4      Receive Label Release  ..............................  99
202	    A.1.5      Receive Label Withdraw  ............................. 101
203	    A.1.6      Recognize New FEC  .................................. 103
204	    A.1.7      Detect Change in FEC Next Hop  ...................... 106
205	    A.1.8      Receive Notification / Label Request Aborted  ....... 108
206	    A.1.9      Receive Notification / No Label Resources  .......... 109
207	    A.1.10     Receive Notification / No Route  .................... 110
208	    A.1.11     Receive Notification / Loop Detected  ............... 110
209	    A.1.12     Receive Notification / Label Resources Available  ... 111
210	    A.1.13     Detect local label resources have become available  . 112
211	    A.1.14     LSR decides to no longer label switch a FEC  ........ 113
212	    A.1.15     Timeout of deferred label request  .................. 113
213	    A.2        Common Label Distribution Procedures  ............... 114
214	    A.2.1      Send_Label  ......................................... 114
215	    A.2.2      Send_Label_Request  ................................. 116
216	    A.2.3      Send_Label_Withdraw  ................................ 117
217	    A.2.4      Send_Notification  .................................. 117
218	    A.2.5      Send_Message  ....................................... 118
219	    A.2.6      Check_Received_Attributes  .......................... 118
220	    A.2.7      Prepare_Label_Request_Attributes  ................... 120
221	    A.2.8      Prepare_Label_Mapping_Attributes  ................... 121

223	1. LDP Overview

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

230	   The MPLS architecture does not assume a single label distribution
231	   protocol.  In fact, a number of different label distribution
232	   protocols are being standardized.  Existing protocols have been
233	   extended so that label distribution can be piggybacked on them.  New
234	   protocols have also been defined for the explicit purpose of
235	   distributing labels.  Section 2.29 of the architecture [ARCH]
236	   discusses some of the considerations when chosing a label
237	   distribution protocol for use in particular MPLS applications such as
238	   Traffic Engineering [TE].

240	   The Label Distribution Protocol (LDP) defined in this document is a
241	   new protocol defined for distributing labels.  It is the set of
242	   procedures and messages by which Label Switched Routers (LSRs)
243	   establish Label Switched Paths (LSPs) through a network by mapping
244	   network-layer routing information directly to data-link layer
245	   switched paths.  These LSPs may have an endpoint at a directly
246	   attached neighbor (comparable to IP hop-by-hop forwarding), or may
247	   have an endpoint at a network egress node, enabling switching via all
248	   intermediary nodes.

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

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

260	1.1. LDP Peers

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

268	1.2. LDP Message Exchange

270	   There are four categories of LDP messages:

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

275	      2. Session messages, used to establish, maintain, and terminate
276	         sessions between LDP peers.

278	      3. Advertisement messages, used to create, change, and delete
279	         label mappings for FECs.

281	      4. Notification messages, used to provide advisory information and
282	         to signal error information.

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

293	   When to request a label or advertise a label mapping to a peer is
294	   largely a local decision made by an LSR.  In general, the LSR
295	   requests a label mapping from a neighboring LSR when it needs one,
296	   and advertises a label mapping to a neighboring LSR when it wishes
297	   the neighbor to use a label.

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

304	1.3. LDP Message Structure

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

311	1.4. LDP Error Handling

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

316	   There are two kinds of LDP notification messages:

318	      1. Error notifications, used to signal fatal errors.  If an LSR
319	         receives an error notification from a peer for an LDP session,
320	         it terminates the LDP session by closing the TCP transport
321	         connection for the session and discarding all label mappings
322	         learned via the session.

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

328	1.5. LDP Extensibility and Future Compatibility

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

339	2. LDP Operation

341	2.1. FECs

343	   It is necessary to precisely specify which packets may be mapped to
344	   each LSP.  This is done by providing a FEC specification for each
345	   LSP.  The FEC identifies the set of IP packets which may be mapped to
346	   that LSP.

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

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

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

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

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

366	   We say that a particular address "matches" a particular address
367	   prefix if and only if that address begins with that prefix.  We also
368	   say that a particular packet matches a particular LSP if and only if
369	   that LSP has an Address Prefix FEC element which matches the packet's
370	   destination address.  With respect to a particular packet and a
371	   particular LSP, we refer to any Address Prefix FEC element which
372	   matches the packet as the "matching prefix".

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

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

382	     - If there multiple LSPs, each containing a Host Address FEC
383	       element that is identical to the packet's destination address,
384	       then the packet is mapped to one of those LSPs.  The procedure
385	       for selecting one of those LSPs is beyond the scope of this
386	       document.

388	     - If a packet matches exactly one LSP, the packet is mapped to that
389	       LSP.

391	     - If a packet matches multiple LSPs, it is mapped to the LSP whose
392	       matching prefix is the longest.  If there is no one LSP whose
393	       matching prefix is longest, the packet is mapped to one from the
394	       set of LSPs whose matching prefix is longer than the others.  The
395	       procedure for selecting one of those LSPs is beyond the scope of
396	       this document.

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

404	   The procedure for determining that a packet must traverse a
405	   particular egress router is beyond the scope of this document.  (As
406	   an example, if one is running a link state routing algorithm, it may
407	   be possible to obtain this information from the link state data base.
408	   As another example, if one is running BGP, it may be possible to
409	   obtain this information from the BGP next hop attribute of the
410	   packet's route.)

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

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

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

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

426	2.2. Label Spaces, Identifiers, Sessions and Transport

428	2.2.1. Label Spaces

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

433	     - Per interface label space.  Interface-specific incoming labels
434	       are used for interfaces that use interface resources for labels.
435	       An example of such an interface is a label-controlled ATM
436	       interface that uses VCIs as labels, or a Frame Relay interface
437	       that uses DLCIs as labels.

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

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

447	2.2.2. LDP Identifiers

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

456	              <IP address> : <label space id>

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

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

463	   A situation where an LSR would need to advertise more than one label
464	   space to a peer and hence use more than one LDP Identifier occurs
465	   when the LSR has two links to the peer and both are ATM (and use per
466	   interface labels).  Another situation would be where the LSR had two
467	   links to the peer, one of which is ethernet (and uses per platform
468	   labels) and the other of which is ATM.

470	2.2.3. LDP Sessions

472	   LDP sessions exist between LSRs to support label exchange between
473	   them.

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

478	2.2.4. LDP Transport

480	   LDP uses TCP as a reliable transport for sessions.

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

485	2.3. LDP Sessions between non-Directly Connected LSRs

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

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

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

500	   In this situation LSRa would apply two labels to traffic it forwards
501	   on the LSP to LSRb: a label learned from LSR1 to forward traffic
502	   along the LSP path from LSRa to LSRb; and a label learned from LSRb
503	   to enable LSRb to label switch traffic arriving on the LSP.

505	   LSRa first adds the label learned via its LDP session with LSRb to
506	   the packet label stack (either by replacing the label on top of the
507	   packet label stack with it if the packet arrives labeled or by
508	   pushing it if the packet arrives unlabeled).  Next, it pushes the
509	   label for the LSP learned from LSR1 onto the label stack.

511	2.4. LDP Discovery

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

517	   There are two variants of the discovery mechanism:

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

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

525	2.4.1. Basic Discovery Mechanism

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

532	   An LDP Link Hello sent by an LSR carries the LDP Identifier for the
533	   label space the LSR intends to use for the interface and possibly
534	   additional information.

536	   Receipt of an LDP Link Hello on an interface identifies a "Hello
537	   adjacency" with a potential LDP peer reachable at the link level on
538	   the interface as well as the label space the peer intends to use for
539	   the interface.

541	2.4.2. Extended Discovery Mechanism

543	   LDP sessions between non-directly connected LSRs are supported by LDP
544	   Extended Discovery.

546	   To engage in LDP Extended Discovery an LSR periodically sends LDP
547	   Targeted Hellos to a specific IP address.  LDP Targeted Hellos are
548	   sent as UDP packets addressed to the well-known LDP discovery port at
549	   the specific address.

551	   An LDP Targeted Hello sent by an LSR carries the LDP Identifier for
552	   the label space the LSR intends to use and possibly additional
553	   optional information.

555	   Extended Discovery differs from Basic Discovery in the following
556	   ways:

558	     - A Targeted Hello is sent to a specific IP address rather than to
559	       the "all routers" group multicast address for the outgoing
560	       interface.

562	     - Unlike Basic Discovery, which is symmetric, Extended Discovery is
563	       asymmetric.

565	       One LSR initiates Extended Discovery with another targeted LSR,
566	       and the targeted LSR decides whether to respond to or ignore the
567	       Targeted Hello.  A targeted LSR that chooses to respond does so
568	       by periodically sending Targeted Hellos to the initiating LSR.

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

574	2.5. Establishing and Maintaining LDP Sessions

576	2.5.1. LDP Session Establishment

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

581	           - Transport connection establishment.
582	           - Session initialization

584	   The following describes establishment of an LDP session between LSRs
585	   LSR1 and LSR2 from LSR1's point of view.  It assumes the exchange of
586	   Hellos specifying label space LSR1:a for LSR1 and label space LSR2:b
587	   for LSR2.

589	2.5.2. Transport Connection Establishment

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

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

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

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

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

611	         Similarly, address A2 is determined as follows:

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

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

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

624	     3.  If LSR1 is active, it attempts to establish the LDP TCP
625	         connection by connecting to the well-known LDP port at address
626	         A2.  If LSR1 is passive, it waits for LSR2 to establish the LDP
627	         TCP connection to its well-known LDP port.

629	2.5.3. Session Initialization

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

637	   Successful negotiation completes establishment of an LDP session
638	   between LSR1 and LSR2 for the advertisement of label spaces LSR1:a
639	   and LSR2:b.

641	   The following describes the session initialization from LSR1's point
642	   of view.

644	   After the connection is established, if LSR1 is playing the active
645	   role, it initiates negotiation of session parameters by sending an
646	   Initialization message to LSR2.  If LSR1 is passive, it waits for
647	   LSR2 to initiate the parameter negotiation.

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

654	   By waiting for the Initialization message from its peer the passive
655	   LSR can match the label space to be advertised by the peer (as
656	   determined from the LDP Identifier in the PDU header for the
657	   Initialization message) with a Hello adjacency previously created
658	   when Hellos were exchanged.

660	     1.  When LSR1 plays the passive role:

662	         a.  If LSR1 receives an Initialization message it attempts to
663	             match the LDP Identifier carried by the message PDU with a
664	             Hello adjacency.

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

669	             Next LSR1 checks whether the session parameters proposed in
670	             the message are acceptable.  If they are, LSR1 replies with
671	             an Initialization message of its own to propose the
672	             parameters it wishes to use and a KeepAlive message to
673	             signal acceptance of LSR2's parameters.  If the parameters
674	             are not acceptable, LSR1 responds by sending a Session
675	             Rejected/Parameters Error Notification message and closing
676	             the TCP connection.

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

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

686	         e.  If LSR1 receives an Error Notification message, LSR2 has
687	             rejected its proposed session and LSR1 closes the TCP
688	             connection.

690	     2.  When LSR1 plays the active role:

692	         a.  If LSR1 receives an Error Notification message, LSR2 has
693	             rejected its proposed session and LSR1 closes the TCP
694	             connection.

696	         b.  If LSR1 receives an Initialization message, it checks
697	             whether the session parameters are acceptable.  If so, it
698	             replies with a KeepAlive message.  If the session
699	             parameters are unacceptable, LSR1 sends a Session
700	             Rejected/Parameters Error Notification message and closes
701	             the connection.

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

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

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

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

720	       The session establishment setup attempt following a NAK'd
721	       Initialization message must be delayed no less than 15 seconds,
722	       and subsequent delays must grow to a maximum delay of no less
723	       than 2 minutes.  The specific session establishment action that
724	       must be delayed is the attempt to open the session transport
725	       connection by the LSR playing the active role.

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

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

739	2.5.4. Initialization State Machine

741	   It is convenient to describe LDP session negotiation behavior in
742	   terms of a state machine.  We define the LDP state machine to have
743	   five possible states and present the behavior as a state transition
744	   table and as a state transition diagram.

746	               Session Initialization State Transition Table

748	         STATE         EVENT                               NEW STATE

750	         NON EXISTENT  Session TCP connection established  INITIALIZED
751	                       established

753	         INITIALIZED   Transmit Initialization msg         OPENSENT
754	                             (Active Role)

756	                       Receive acceptable                  OPENREC
757	                             Initialization msg
758	                             (Passive Role )
759	                         Action: Transmit Initialization
760	                                 msg and KeepAlive msg

762	                       Receive Any other LDP msg           NON EXISTENT
763	                         Action: Transmit Error Notification msg
764	                                 (NAK) and close transport connection

766	         OPENREC       Receive KeepAlive msg               OPERATIONAL

768	                       Receive Any other LDP msg           NON EXISTENT
769	                         Action: Transmit Error Notification msg
770	                                 (NAK) and close transport connection

772	         OPENSENT      Receive acceptable                  OPENREC
773	                             Initialization msg
774	                         Action: Transmit KeepAlive msg

776	                       Receive Any other LDP msg           NON EXISTENT
777	                         Action: Transmit Error Notification msg
778	                                 (NAK) and close transport connection

780	         OPERATIONAL   Receive Shutdown msg                NON EXISTENT
781	                         Action: Transmit Shutdown msg and
782	                                 close transport connection

784	                       Receive other LDP msgs              OPERATIONAL

786	                       Timeout                             NON EXISTENT
787	                         Action: Transmit Shutdown msg and
788	                                 close transport connection

790	              Session Initialization State Transition Diagram

792	                                    +------------+
793	                                    |            |
794	                      +------------>|NON EXISTENT|<--------------------+
795	                      |             |            |                     |
796	                      |             +------------+                     |
797	                      | Session        |    ^                          |
798	                      |   connection   |    |                          |
799	                      |   established  |    | Rx any LDP msg except    |
800	                      |                V    |   Init msg or Timeout    |
801	                      |            +-----------+                       |
802	         Rx Any other |            |           |                       |
803	            msg or    |            |INITIALIZED|                       |
804	            Timeout / |        +---|           |-+                     |
805	         Tx NAK msg   |        |   +-----------+ |                     |
806	                      |        | (Passive Role)  | (Active Role)       |
807	                      |        | Rx Acceptable   | Tx Init msg         |
808	                      |        |    Init msg /   |                     |
809	                      |        | Tx Init msg     |                     |
810	                      |        |    Tx KeepAlive |                     |
811	                      |        V    msg          V                     |
812	                      |   +-------+        +--------+                  |
813	                      |   |       |        |        |                  |
814	                      +---|OPENREC|        |OPENSENT|----------------->|
815	                      +---|       |        |        | Rx Any other msg |
816	                      |   +-------+        +--------+    or Timeout    |
817	         Rx KeepAlive |        ^                |     Tx NAK msg       |
818	            msg       |        |                |                      |
819	                      |        |                | Rx Acceptable        |
820	                      |        |                |    Init msg /        |
821	                      |        +----------------+ Tx KeepAlive msg     |
822	                      |                                                |
823	                      |      +-----------+                             |
824	                      +----->|           |                             |
825	                             |OPERATIONAL|                             |
826	                             |           |---------------------------->+
827	                             +-----------+     Rx Shutdown msg
828	                      All other  |   ^            or Timeout /
829	                        LDP msgs |   |         Tx Shutdown msg
830	                                 |   |
831	                                 +---+

833	2.5.5. Maintaining Hello Adjacencies

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

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

843	   LDP includes mechanisms to monitor the necessity of an LDP session
844	   and its Hello adjacencies.

846	   LDP uses the regular receipt of LDP Discovery Hellos to indicate a
847	   peer's intent to use the label space identified by the Hello.  An LSR
848	   maintains a hold timer with each Hello adjacency which it restarts
849	   when it receives a Hello that matches the adjacency.  If the timer
850	   expires without receipt of a matching Hello from the peer, LDP
851	   concludes that the peer no longer wishes to label switch using that
852	   label space for that link (or target, in the case of Targeted Hellos)
853	   or that the peer has failed.  The LSR then deletes the Hello
854	   adjacency.  When the last Hello adjacency for a LDP session is
855	   deleted, the LSR terminates the LDP session by sending a Notification
856	   message and closing the transport connection.

858	2.5.6. Maintaining LDP Sessions

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

862	   LDP uses the regular receipt of LDP PDUs on the session transport
863	   connection to monitor the integrity of the session.  An LSR maintains
864	   a KeepAlive timer for each peer session which it resets whenever it
865	   receives an LDP PDU from the session peer.  If the KeepAlive timer
866	   expires without receipt of an LDP PDU from the peer the LSR concludes
867	   that the transport connection is bad or that the peer has failed, and
868	   it terminates the LDP session by closing the transport connection.

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

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

881	2.6. Label Distribution and Management

883	   The MPLS architecture [ARCH] allows an LSR to distribute a FEC label
884	   binding in response to an explicit request from another LSR.  This is
885	   known as Downstream On Demand label distribution.  It also allows an
886	   LSR to distribute label bindings to LSRs that have not explicitly
887	   requested them.  This is known as Downstream Unsolicited label
888	   distribution.

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

897	2.6.1. Label Distribution Control Mode

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

903	2.6.1.1. Independent Label Distribution Control

905	   When using independent LSP control, each LSR may advertise label
906	   mappings to its neighbors at any time it desires.  For example, when
907	   operating in independent Downstream on Demand mode, an LSR may answer
908	   requests for label mappings immediately, without waiting for a label
909	   mapping from the next hop.  When operating in independent Downstream
910	   Unsolicited mode, an LSR may advertise a label mapping for a FEC to
911	   its neighbors whenever it is prepared to label-switch that FEC.

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

916	2.6.1.2. Ordered Label Distribution Control

918	   When using LSP ordered control, an LSR may initiate the transmission
919	   of a label mapping only for a FEC for which it has a label mapping
920	   for the FEC next hop, or for which the LSR is the egress. For each
921	   FEC for which the LSR is not the egress and no mapping exists, the
922	   LSR MUST wait until a label from a downstream LSR is received before
923	   mapping the FEC and passing corresponding labels to upstream LSRs.

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

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

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

933	      2. The next hop router for the FEC is outside of the Label
934	         Switching Network.

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

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

945	2.6.2. Label Retention Mode

947	2.6.2.1. Conservative Label Retention Mode

949	   In Downstream Unsolicited advertisement mode, label mapping
950	   advertisements for all routes may be received from all peer LSRs.
951	   When using conservative label retention, advertised label mappings
952	   are retained only if they will be used to forward packets (i.e., if
953	   they are received from a valid next hop according to routing).  If
954	   operating in Downstream on Demand mode, an LSR will request label
955	   mappings only from the next hop LSR according to routing. Since
956	   Downstream on Demand mode is primarily used when label conservation
957	   is desired (e.g., an ATM switch with limited cross connect space), it
958	   is typically used with the conservative label retention mode.

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

968	2.6.2.2. Liberal Label Retention Mode

970	   In Downstream Unsolicited advertisement mode, label mapping
971	   advertisements for all routes may be received from all LDP peers.
972	   When using liberal label retention, every label mappings received
973	   from a peer LSR is retained regardless of whether the LSR is the next
974	   hop for the advertised mapping.  When operating in Downstream on
975	   Demand mode with liberal label retention, an LSR might choose to
976	   request label mappings for all known prefixes from all peer LSRs.
977	   Note, however, that Downstream on Demand mode is typically used by
978	   devices such as ATM switch-based LSRs for which the conservative
979	   approach is recommended.

981	   The main advantage of the liberal label retention mode is that
982	   reaction to routing changes can be quick because labels already
983	   exist.  The main disadvantage of the liberal mode is that unneeded
984	   label mappings are distributed and maintained.

986	2.6.3. Label Advertisement Mode

988	   Each interface on an LSR is configured to operate in either
989	   Downstream Unsolicited or Downstream on Demand advertisement mode.
990	   LSRs exchange advertisement modes during initialization.  The major
991	   difference between Downstream Unsolicited and Downstream on Demand
992	   modes is in which LSR takes responsibility for initiating mapping
993	   requests and mapping advertisements.

995	2.7. LDP Identifiers and Next Hop Addresses

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

1003	   When the next hop for a prefix changes the LSR must retrieve the
1004	   label advertised by the new next hop from the LIB for use in
1005	   forwarding.  To retrieve the label the LSR must be able to map the
1006	   next hop address for the prefix to an LDP Identifier.

1008	   Similarly, when the LSR learns a label for a prefix from an LDP peer,
1009	   it must be able to determine whether that peer is currently a next
1010	   hop for the prefix to determine whether it needs to start using the
1011	   newly learned label when forwarding packets that match the prefix.
1012	   To make that decision the LSR must be able to map an LDP Identifier
1013	   to the peer's addresses to check whether any are a next hop for the
1014	   prefix.

1016	   To enable LSRs to map between a peer LDP identifier and the peer's
1017	   addresses, LSRs advertise their addresses using LDP Address and
1018	   Withdraw Address messages.

1020	   An LSR sends an Address message to advertise its addresses to a peer.
1021	   An LSR sends a Withdraw Address message to withdraw previously
1022	   advertised addresses from a peer

1024	2.8. Loop Detection

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

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

1034	     - A Path Vector TLV contains a list of the LSRs that its containing
1035	       message has traversed.  An LSR is identified in a Path Vector
1036	       list by its unique LSR Identifier (Id), which is the IP address
1037	       component of its LDP Identifier.  When an LSR propagates a
1038	       message containing a Path Vector TLV it adds its LSR Id to the
1039	       Path Vector list.  An LSR that receives a message with a Path
1040	       Vector that contains its LSR Id detects that the message has
1041	       traversed a loop.  LDP supports the notion of a maximum allowable
1042	       Path Vector length; an LSR that detects a Path Vector has reached
1043	       the maximum length behaves as if the containing message has
1044	       traversed a loop.

1046	     - A Hop Count TLV contains a count of the LSRS that the containing
1047	       message has traversed.  When an LSR propagates a message
1048	       containing a Hop Count TLV it increments the count.  An LSR that
1049	       detects a Hop Count has reached a configured maximum value
1050	       behaves as if the containing message has traversed a loop.  By
1051	       convention a count of 0 is interpreted to mean the hop count is
1052	       unknown.  Incrementing an unknown hop count value results in an
1053	       unknown hop count value (0).

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

1062	2.8.1. Label Request Message

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

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

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

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

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

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

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

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

1093	         R MUST add its own LSR Id to the Path Vector, and MUST pass the
1094	         resulting Path Vector to its next hop along with the Label
1095	         Request message.  If the Label Request contains no Path Vector
1096	         TLV, R MUST include a Path Vector TLV of length 1 containing
1097	         its own LSR Id.

1099	   Note that if R receives a Label Request message for a particular FEC,
1100	   and R has previously sent a Label Request message for that FEC to its
1101	   next hop and has not yet received a reply, and if R intends to merge
1102	   the newly received Label Request with the existing outstanding Label
1103	   Request, then R does not propagate the Label Request to the next hop.

1105	   If R receives a Label Request message from its next hop with a Hop
1106	   Count TLV which exceeds the configured maximum value, or with a Path
1107	   Vector TLV containing its own LSR Id or which exceeds the maximum
1108	   allowable length, then R detects that the Label Request message has
1109	   traveled in a loop.

1111	   When R detects a loop, it MUST send a Loop Detected Notification
1112	   message to the source of the Label Request message and drop the Label
1113	   Request message.

1115	2.8.2. Label Mapping Message

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

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

1127	   - R MUST include a Hop Count TLV.

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

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

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

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

1143	   - If the Label Mapping message is not being sent to propagate a Label
1144	     Mapping message, the hop count value MUST be the result of
1145	     incrementing R's current knowledge of the hop count learned from
1146	     previous Label Mapping messages.  Note that this hop count value
1147	     will be unknown if R has not received a Label Mapping message from
1148	     the next hop.

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

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

1158	   - If R is sending the Label Mapping message to propagate a Label
1159	     Mapping message received from the next hop to an upstream peer,
1160	     then:

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

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

1169	       o If R has previously sent a Label Mapping message to the
1170	         upstream peer, then it MUST include a Path Vector TLV if the
1171	         received message reports an LSP hop count increase, a change in
1172	         hop count from unknown to known, or a change from known to
1173	         unknown.

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

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

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

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

1190	   If R receives a Label Mapping message from its next hop with a Hop
1191	   Count TLV which exceeds the configured maximum value, or with a Path
1192	   Vector TLV containing its own LSR Id or which exceeds the maximum
1193	   allowable length, then R detects that the corresponding LSP contains
1194	   a loop.

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

1200	2.8.3. Discussion

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

1205	   Note that in a network where only non-merge capable LSRs are present,
1206	   Path Vectors are passed downstream from ingress to egress, and are
1207	   not passed upstream.  Even when merge is supported, Path Vectors need
1208	   not be passed upstream along an LSP which is known to reach the
1209	   egress.  When an LSR experiences a change of next hop, it need pass
1210	   Path Vectors upstream only when it cannot tell from the hop count
1211	   that the change of next hop does not result in a loop.

1213	   In the case of ordered label distribution, Label Mapping messages are
1214	   propagated from egress toward ingress, naturally creating the Path
1215	   Vector along the way.  In the case of independent label distribution,
1216	   an LSR may originate a Label Mapping message for an FEC before
1217	   receiving a Label Mapping message from its downstream peer for that
1218	   FEC.  In this case, the subsequent Label Mapping message for the FEC
1219	   received from the downstream peer is treated as an update to LSP
1220	   attributes, and the Label Mapping message must be propagated
1221	   upstream.  Thus, it is recommended that loop detection be configured
1222	   in conjunction with ordered label distribution, to minimize the
1223	   number of Label Mapping update messages.

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

1229	2.9. Label Distribution for Explicitly Routed LSPs

1231	   Traffic Engineering [TE] is expected to be an important MPLS
1232	   application.  MPLS support for Traffic Engineering uses explicitly
1233	   routed LSPs, which need not follow normally-routed (hop-by-hop) paths
1234	   as determined by destination-based routing protocols.  CR-LDP [CRLDP]
1235	   defines extensions to LDP to use LDP to set up explicitly routed
1236	   LSPs.

1238	3. Protocol Specification

1240	   Previous sections that describe LDP operation have discussed
1241	   scenarios that involve the exchange of messages among LDP peers.
1242	   This section specifies the message encodings and procedures for
1243	   processing the messages.

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

1248	   Each LDP PDU can carry one or more LDP messages.  Note that the
1249	   messages in an LDP PDU need not be related to one another.  For
1250	   example, a single PDU could carry a message advertising FEC-label
1251	   bindings for several FECs, another message requesting label bindings
1252	   for several other FECs, and a third notification message signaling
1253	   some event.

1255	3.1. LDP PDUs

1257	   Each LDP PDU is an LDP header followed by one or more LDP messages.
1258	   The LDP header is:

1260	    0                   1                   2                   3
1261	    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
1262	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1263	   |  Version                      |         PDU Length            |
1264	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1265	   |                         LDP Identifier                        |
1266	   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1267	   |                               |
1268	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1270	   Version
1271	     Two octet unsigned integer containing the version number of the
1272	     protocol.  This version of the specification specifies LDP protocol
1273	     version 1.

1275	   PDU Length
1276	     Two octet integer specifying the total length of this PDU in
1277	     octets, excluding the Version and PDU Length fields.

1279	     The maximum allowable PDU Length is negotiable when an LDP session
1280	     is initialized.  Prior to completion of the negotiation the maximum
1281	     allowable length is 4096 bytes.

1283	   LDP Identifier
1284	     Six octet field that uniquely identifies the label space of the
1285	     sending LSR for which this PDU applies.  The first four octets
1286	     encode an IP address assigned to the LSR.  This address should be
1287	     the router-id, also used to identify the LSR in loop detection Path
1288	     Vectors.  The last two octets identify a label space within the
1289	     LSR.  For a platform-wide label space, these should both be zero.

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

1294	3.2. LDP Procedures

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

1298	     - Peer discovery;
1299	     - Session management;
1300	     - Label distribution;
1301	     - Notification of errors and advisory information.

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

1306	   The label distribution procedures are complex and are difficult to
1307	   describe fully, coherently and unambiguously as a collection of
1308	   separate message and TLV specifications.

1310	   Appendix A, "LDP Label Distribution Procedures", describes the label
1311	   distribution procedures in terms of label distribution events that
1312	   may occur at an LSR and how the LSR must respond.  Appendix A is the
1313	   specification of LDP label distribution procedures.  If a procedure
1314	   described elsewhere in this document conflicts with Appendix A,
1315	   Appendix A specifies LDP behavior.

1317	3.3. Type-Length-Value Encoding

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

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

1327	    0                   1                   2                   3
1328	    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
1329	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1330	   |U|F|        Type               |            Length             |
1331	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1332	   |                                                               |
1333	   |                             Value                             |
1334	   ~                                                               ~
1335	   |                                                               |
1336	   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1337	   |                               |
1338	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1340	   U bit
1341	     Unknown TLV bit.  Upon receipt of an unknown TLV, if U is clear
1342	     (=0), a notification must be returned to the message originator and
1343	     the entire message must be ignored; if U is set (=1), the unknown
1344	     TLV is silently ignored and the rest of the message is processed as
1345	     if the unknown TLV did not exist.  The sections following that
1346	     define TLVs specify a value for the U-bit.

1348	   F bit
1349	     Forward unknown TLV bit.  This bit applies only when the U bit is
1350	     set and the LDP message containing the unknown TLV is to be
1351	     forwarded.  If F is clear (=0), the unknown TLV is not forwarded
1352	     with the containing message; if F is set (=1), the unknown TLV is
1353	     forwarded with the containing message.  The sections following that
1354	     define TLVs specify a value for the F-bit.

1356	   Type
1357	     Encodes how the Value field is to be interpreted.

1359	   Length
1360	     Specifies the length of the Value field in octets.

1362	   Value
1363	     Octet string of Length octets that encodes information to be
1364	     interpreted as specified by the Type field.

1366	   Note that there is no alignment requirement for the first octect of a
1367	   TLV.

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

1372	   The TLV encoding scheme is very general.  In principle, everything
1373	   appearing in an LDP PDU could be encoded as a TLV.  This
1374	   specification does not use the TLV scheme to its full generality.  It
1375	   is not used where its generality is unnecessary and its use would
1376	   waste space unnecessarily.  These are usually places where the type
1377	   of a value to be encoded is known, for example by its position in a
1378	   message or an enclosing TLV, and the length of the value is fixed or
1379	   readily derivable from the value encoding itself.

1381	   Some of the TLVs defined for LDP are similar to one another.  For
1382	   example, there is a Generic Label TLV, an ATM Label TLV, and a Frame
1383	   Relay TLV; see Sections "Generic Label TLV", "ATM Label TLV", and
1384	   "Frame Relay TLV".

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

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

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

1398	3.4. TLV Encodings for Commonly Used Parameters

1400	   There are several parameters used by more than one LDP message.  The
1401	   TLV encodings for these commonly used parameters are specified in
1402	   this section.

1404	3.4.1. FEC TLV

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

1409	   Its encoding is:

1411	    0                   1                   2                   3
1412	    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
1413	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1414	   |0|0| FEC (0x0100)              |      Length                   |
1415	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1416	   |                        FEC Element 1                          |
1417	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1418	   |                                                               |
1419	   ~                                                               ~
1420	   |                                                               |
1421	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1422	   |                        FEC Element n                          |
1423	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

1429	     A FEC Element value is encoded as a 1 octet field that specifies
1430	     the element type, and a variable length field that is the type-
1431	     dependent element value.  Note that while the representation of the
1432	     FEC element value is type-dependent, the FEC element encoding
1433	     itself is one where standard LDP TLV encoding is not used.

1435	     The FEC Element value encoding is:

1437	         FEC Element       Type      Value
1438	         type name

1440	           Wildcard        0x01      No value; i.e., 0 value octets;
1441	                                         see below.
1442	           Prefix          0x02      See below.
1443	           Host Address    0x03      Full host address; see below.

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

1450	     Wildcard FEC Element
1451	       To be used only in the Label Withdraw and Label Release Messages.
1452	       Indicates the withdraw/release is to be applied to all FECs
1453	       associated with the label within the following label TLV.  Must
1454	       be the only FEC Element in the FEC TLV.

1456	     Prefix FEC Element value encoding:

1458	      0                   1                   2                   3
1459	      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
1460	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1461	     |  Prefix (2)   |     Address Family            |     PreLen    |
1462	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1463	     |                     Prefix                                    |
1464	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

1471	       PreLen
1472	         One octet unsigned integer containing the length in bits of the
1473	         address prefix that follows.  A length of zero indicates a
1474	         prefix that matches all addresses (the default destination); in
1475	         this case the Prefix itself is zero octets).

1477	       Prefix
1478	         An address prefix encoded according to the Address Family
1479	         field, whose length, in bits, was specified in the PreLen
1480	         field, padded to a byte boundary.

1482	     Host Address FEC Element encoding:

1484	      0                   1                   2                   3
1485	      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
1486	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1487	     | Host Addr (3) |     Address Family            | Host Addr Len |
1488	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1489	     |                                                               |
1490	     |                     Host Addr                                 |
1491	     |                                                               |
1492	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1494	       Address Family
1495	         Two octet quantity containing a value from ADDRESS FAMILY
1496	         NUMBERS in [rfc1700] that encodes the address family for the
1497	         address prefix in the Prefix field.

1499	       Host Addr Len
1500	         Length of the Host address in octets.

1502	       Host Addr
1503	         An address encoded according to the Address Family field.

1505	3.4.1.1. FEC Procedures

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

1512	3.4.2. Label TLVs

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

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

1520	3.4.2.1. Generic Label TLV

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

1526	    0                   1                   2                   3
1527	    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
1528	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1529	   |0|0| Generic Label (0x0200)    |      Length                   |
1530	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1531	   |     Label                                                     |
1532	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1534	   Label
1535	     This is a 20-bit label value as specified in [ENCAP] represented as
1536	     a 20-bit number in a 4 octet field.

1538	3.4.2.2. ATM Label TLV

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

1542	    0                   1                   2                   3
1543	    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
1544	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1545	   |0|0| ATM Label (0x0201)        |         Length                |
1546	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1547	   |Res| V |          VPI          |         VCI                   |
1548	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1550	   Res
1551	     This field is reserved. It must be set to zero on transmission and
1552	     must be ignored on receipt.

1554	   V-bits
1555	     Two-bit switching indicator.  If V-bits is 00, both the VPI and VCI
1556	     are significant.  If V-bits is 01, only the VPI field is
1557	     significant.  If V-bit is 10, only the VCI is significant.

1559	   VPI
1560	     Virtual Path Identifier. If VPI is less than 12-bits it should be
1561	     right justified in this field and preceding bits should be set to
1562	     0.

1564	   VCI
1565	     Virtual Channel Identifier. If the VCI is less than 16- bits, it
1566	     should be right justified in the field and the preceding bits must
1567	     be set to 0. If Virtual Path switching is indicated in the V-bits
1568	     field, then this field must be ignored by the receiver and set to 0
1569	     by the sender.

1571	3.4.2.3. Frame Relay Label TLV

1573	   An LSR uses Frame Relay Label TLVs to encode labels for use on Frame
1574	   Relay links.

1576	    0                   1                   2                   3
1577	    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
1578	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1579	   |0|0| Frame Relay Label (0x0202)|       Length                  |
1580	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1581	   | Reserved    |Len|                     DLCI                    |
1582	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1584	   Res
1585	     This field is reserved. It must be set to zero on transmission and
1586	     must be ignored on receipt.

1588	   Len
1589	     This field specifies the number of bits of the DLCI. The following
1590	     values are supported:

1592	        0 = 10 bits DLCI
1593	        1 = 17 bits DLCI
1594	        2 = 23 bits DLCI

1596	   DLCI
1597	     The Data Link Connection Identifier.  Refer to [FR] for the label
1598	     values and formats.

1600	3.4.3. Address List TLV

1602	   The Address List TLV appears in Address and Address Withdraw
1603	   messages.

1605	   Its encoding is:

1607	    0                   1                   2                   3
1608	    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
1609	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1610	   |0|0| Address List (0x0101)     |      Length                   |
1611	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1612	   |     Address Family            |                               |
1613	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
1614	   |                                                               |
1615	   |                        Addresses                              |
1616	   ~                                                               ~
1617	   |                                                               |
1618	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1620	   Address Family
1621	     Two octet quantity containing a value from ADDRESS FAMILY NUMBERS
1622	     in [rfc1700] that encodes the addresses contained in the Addresses
1623	     field.

1625	   Addresses
1626	     A list of addresses from the specified Address Family.  The
1627	     encoding of the individual addresses depends on the Address Family.

1629	     The following address encodings are defined by this version of the
1630	     protocol:

1632	         Address Family      Address Encoding

1634	         IPv4                4 octet full IPv4 address

1636	3.4.4. Hop Count TLV

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

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

1645	    0                   1                   2                   3
1646	    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
1647	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1648	   |0|0| Hop Count (0x0103)        |      Length                   |
1649	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1650	   |     HC Value  |
1651	   +-+-+-+-+-+-+-+-+

1653	   HC Value
1654	     1 octet unsigned integer hop count value.

1656	3.4.4.1. Hop Count Procedures

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

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

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

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

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

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

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

1683	   By convention a value of 0 indicates an unknown hop count.  The
1684	   result of incrementing an unknown hop count is itself an unknown hop
1685	   count (0).

1687	   Use of the unknown hop count value greatly reduces the signalling
1688	   overhead when independent control is used.  When a new LSP is
1689	   established, each LSR starts with unknown hop count.  Addition of a
1690	   new LSR whose hop count is also unknown does not cause a hop count
1691	   update to be propagated upstream since the hop count remains unknown.
1692	   When the egress is finally added to the LSP, then the LSRs propagate
1693	   hop count updates upstream via Label Mapping messages.

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

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

1706	   If an LSR receives a message containing a Hop Count TLV, it must
1707	   check the hop count value to determine whether the hop count has
1708	   exceeded its configured maximum allowable value.  If so, it must
1709	   behave as if the containing message has traversed a loop by sending a
1710	   Notification message signaling Loop Detected in reply to the sender
1711	   of the message.

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

1716	3.4.5. Path Vector TLV

1718	   The Path Vector TLV is used with the Hop Count TLV in Label Request
1719	   and Label Mapping messages to implement the optional LDP loop
1720	   detection mechanism.  See Section "Loop Detection".  Its use in the
1721	   Label Request message records the path of LSRs the request has
1722	   traversed.  Its use in the Label Mapping message records the path of
1723	   LSRs a label advertisement has traversed to setup an LSP.

1725	   Its encoding is:

1727	    0                   1                   2                   3
1728	    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
1729	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1730	   |0|0| Path Vector (0x0104)      |        Length                 |
1731	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1732	   |                            LSR Id 1                           |
1733	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1734	   |                                                               |
1735	   ~                                                               ~
1736	   |                                                               |
1737	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1738	   |                            LSR Id n                           |
1739	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1741	   One or more LSR Ids
1742	     A list of router-ids indicating the path of LSRs the message has
1743	     traversed.  Each LSR Id is the IP address (router-id) component of
1744	     the LDP identifier for the corresponding LSR.  This ensures it is
1745	     unique within the LSR network.

1747	3.4.5.1. Path Vector Procedures

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

1752	3.4.5.1.1. Label Request Path Vector

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

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

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

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

1766	      2. Not propagate the Label Reqeust message further.

1768	   Note that a Label Request message with Path Vector TLV is forwarded
1769	   until:

1771	      1. A loop is found,

1773	      2. The LSP egress is reached,

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

1778	3.4.5.1.2. Label Mapping Path Vector

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

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

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

1789	      1. Transmit a Notification message to the sending LSR signaling
1790	         "Loop Detected".

1792	      2. Not propagate the message further.

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

1798	   Note that a Label Mapping message with a Path Vector TLV is forwarded
1799	   until:

1801	      1. A loop is found,

1803	      2. An LSP ingress is reached, or

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

1808	3.4.6. Status TLV

1810	   Notification messages carry Status TLVs to specify events being
1811	   signaled.

1813	   The encoding for the Status TLV is:

1815	    0                   1                   2                   3
1816	    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
1817	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1818	   |0|0| Status (0x0300)           |      Length                   |
1819	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1820	   |                     Status Code                               |
1821	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1822	   |                     Message ID                                |
1823	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1824	   |      Message Type             |
1825	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1827	   Status Code
1828	     32-bit unsigned integer encoding the event being signaled.  The
1829	     structure of a Status Code is:

1831	      0                   1                   2                   3
1832	      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
1833	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1834	     |E|F|                 Status Data                               |
1835	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1837	     E bit
1838	       Fatal error bit.  If set (=1), this is a fatal error
1839	       notification.  If clear (=0), this is an advisory notification.

1841	     F bit
1842	       Forward bit.  If set (=1), the notification should be forwarded
1843	       to the LSR for the next-hop or previous-hop for the LSP, if any,
1844	       associated with the event being signaled.  If clear (=0), the
1845	       notification should not be forwarded.

1847	     Status Data
1848	       30-bit unsigned integer which specifies the status information.

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

1853	     A Status Code of 0 signals success.

1855	   Message ID
1856	     If non-zero, 32-bit value that identifies the peer message to which
1857	     the Status TLV refers.  If zero, no specific peer message is being
1858	     identified.

1860	   Message Type
1861	     If non-zero, the type of the peer message to which the Status TLV
1862	     refers.  If zero, the Status TLV does not refer to any specific
1863	     message type.

1865	 Note that use of the Status TLV is not limited to Notification
1866	 messages.  A message other than a Notification message may carry a
1867	 Status TLV as an Optional Parameter.  When a message other than a
1868	 Notification carries a Status TLV the U-bit of the Status TLV should be
1869	 set to 1 to indicate that the receiver should silently discard the TLV
1870	 if unprepared to handle it.

1872	3.5. LDP Messages

1874	   All LDP messages have the following format:

1876	    0                   1                   2                   3
1877	    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
1878	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1879	   |U|   Message Type              |      Message Length           |
1880	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1881	   |                     Message ID                                |
1882	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1883	   |                                                               |
1884	   +                                                               +
1885	   |                     Mandatory Parameters                      |
1886	   +                                                               +
1887	   |                                                               |
1888	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1889	   |                                                               |
1890	   +                                                               +
1891	   |                     Optional Parameters                       |
1892	   +                                                               +
1893	   |                                                               |
1894	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1896	   U bit
1897	     Unknown message bit.  Upon receipt of an unknown message, if U is
1898	     clear (=0), a notification is returned to the message originator;
1899	     if U is set (=1), the unknown message is silently ignored.  The
1900	     sections following that define messages specify a value for the U-
1901	     bit.

1903	   Message Type
1904	     Identifies the type of message

1906	   Message Length
1907	     Specifies the cumulative length in octets of the Message ID,
1908	     Mandatory Parameters, and Optional Parameters.

1910	   Message ID
1911	     32-bit value used to identify this message.  Used by the sending
1912	     LSR to facilitate identifying notification messages that may apply
1913	     to this message.  An LSR sending a notification message in response
1914	     to this message should include this Message Id in the notification
1915	     message; see Section "Notification Message".

1917	   Mandatory Parameters
1918	     Variable length set of required message parameters.  Some messages
1919	     have no required parameters.

1921	     For messages that have required parameters, the required parameters
1922	     MUST appear in the order specified by the individual message
1923	     specifications in the sections that follow.

1925	   Optional Parameters
1926	     Variable length set of optional message parameters.  Many messages
1927	     have no optional parameters.

1929	     For messages that have optional parameters, the optional parameters
1930	     may appear in any order.

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

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

1937	       Message Name            Section Title

1939	       Notification            "Notification Message"
1940	       Hello                   "Hello Message"
1941	       Initialization          "Initialization Message"
1942	       KeepAlive               "KeepAlive Message"
1943	       Address                 "Address Message"
1944	       Address Withdraw        "Address Withdraw Message"
1945	       Label Mapping           "Label Mapping Message"
1946	       Label Request           "Label Request Message"
1947	       Label Abort Request     "Label Abort Request Message"
1948	       Label Withdraw          "Label Withdraw Message"
1949	       Label Release           "Label Release Message"

1951	   The sections that follow specify the encodings and procedures for
1952	   these messages.

1954	   Some of the above messages are related to one another, for example
1955	   the Label Mapping, Label Request, Label Withdraw, and Label Release
1956	   messages.

1958	   While it is possible to think about messages related in this way in
1959	   terms of a message type that specifies a message class and a message
1960	   subtype that specifies a particular kind of message within that
1961	   class, this specification does not formalize the notion of a message
1962	   subtype.

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

1968	3.5.1. Notification Message

1970	   An LSR sends a Notification message to inform an LDP peer of a
1971	   significant event.  A Notification message signals a fatal error or
1972	   provides advisory information such as the outcome of processing an
1973	   LDP message or the state of the LDP session.

1975	   The encoding for the Notification Message is:

1977	    0                   1                   2                   3
1978	    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
1979	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1980	   |0|   Notification (0x0001)     |      Message Length           |
1981	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1982	   |                     Message ID                                |
1983	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1984	   |                     Status (TLV)                              |
1985	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1986	   |                     Optional Parameters                       |
1987	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1989	   Message ID
1990	     32-bit value used to identify this message.

1992	   Status TLV
1993	     Indicates the event being signaled.  The encoding for the Status
1994	     TLV is specified in Section "Status TLV".

1996	   Optional Parameters
1997	     This variable length field contains 0 or more parameters, each
1998	     encoded as a TLV.  The following Optional Parameters are generic
1999	     and may appear in any Notification Message:

2001	         Optional Parameter     Type     Length  Value

2003	         Extended Status        0x0301    4      See below
2004	         Returned PDU           0x0302    var    See below
2005	         Returned Message       0x0303    var    See below

2007	     Other Optional Parameters, specific to the particular event being
2008	     signaled by the Notification Messages may appear.  These are
2009	     described elsewhere.

2011	       Extended Status
2012	         The 4 octet value is an Extended Status Code that encodes
2013	         additional information that supplements the status information
2014	         contained in the Notification Status Code.

2016	       Returned PDU
2017	         An LSR uses this parameter to return part of an LDP PDU to the
2018	         LSR that sent it.  The value of this TLV is the PDU header and
2019	         as much PDU data following the header as appropriate for the
2020	         condition being signalled by the Notification message.

2022	       Returned Message
2023	         An LSR uses this parameter to return part of an LDP message to
2024	         the LSR that sent it.  The value of this TLV is the message
2025	         type and length fields and as much message data following the
2026	         type and length fields as appropriate for the condition being
2027	         signalled by the Notification message.

2029	3.5.1.1. Notification Message Procedures

2031	   If an LSR encounters a condition requiring it to notify its peer with
2032	   advisory or error information it sends the peer a Notification
2033	   message containing a Status TLV that encodes the information and
2034	   optionally additional TLVs that provide more information about the
2035	   event.

2037	   If the condition is one that is a fatal error the Status Code carried
2038	   in the notification will indicate that.  In this case, after sending
2039	   the Notification message the LSR should terminate the LDP session by
2040	   closing the session TCP connection and discard all state associated
2041	   with the session, including all label-FEC bindings learned via the
2042	   session.

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

2050	3.5.1.2. Events Signaled by Notification Messages

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

2055	3.5.1.2.1. Malformed PDU or Message

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

2060	   An LDP PDU received on a TCP connection for an LDP session is
2061	   malformed if:

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

2068	     - The LDP protocol version is not supported by the receiver, or it
2069	       is supported but is not the version negotiated for the session
2070	       during session establishment.  This is a fatal error signaled by
2071	       the Bad Protocol Version Status Code.

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

2078	   An LDP Message is malformed if:

2080	     - The Message Type is unknown.

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

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

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

2092	3.5.1.2.2. Unknown or Malformed TLV

2094	   Malformed TLVs contained in LDP messages that are part of the LDP
2095	   Discovery mechanism are handled by silently discarding the containing
2096	   message.

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

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

2105	     - The TLV type is unknown.

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

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

2114	     - The TLV Value is malformed.  This occurs when the receiver
2115	       handles the TLV but cannot decode the TLV Value.  This is
2116	       interpreted as indicative of a bug in either the sending or
2117	       receiving LSR.  It is a fatal error signaled by the Malformed TLV
2118	       Value Status Code.

2120	3.5.1.2.3. Session KeepAlive Timer Expiration

2122	   This is a fatal error signaled by the KeepAlive Timer Expired Status
2123	   Code.

2125	3.5.1.2.4. Unilateral Session Shutdown

2127	   This is a fatal event signaled by the Shutdown Status Code.  The
2128	   Notification Message may optionally include an Extended Status TLV to
2129	   provide a reason for the Shutdown.  The sending LSR terminates the
2130	   session immediately after sending the Notification.

2132	3.5.1.2.5. Initialization Message Events

2134	   The session initialization negotiation (see Section "Session
2135	   Initialization") may fail if the session parameters received in the
2136	   Initialization Message are unacceptable.  This is a fatal error.  The
2137	   specific Status Code depends on the parameter deemed unacceptable,
2138	   and is defined in Sections "Initialization Message".

2140	3.5.1.2.6. Events Resulting From Other Messages

2142	   Messages other than the Initialization message may result in events
2143	   that must be signaled to LDP peers via Notification Messages.  These
2144	   events and the Status Codes used in the Notification Messages to
2145	   signal them are described in the sections that describe these
2146	   messages.

2148	3.5.1.2.7. Miscellaneous Events

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

2153	3.5.2. Hello Message

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

2158	   The encoding for the Hello Message is:

2160	    0                   1                   2                   3
2161	    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
2162	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2163	   |0|   Hello (0x0100)            |      Message Length           |
2164	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2165	   |                     Message ID                                |
2166	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2167	   |                     Common Hello Parameters TLV               |
2168	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2169	   |                     Optional Parameters                       |
2170	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2172	   Message ID
2173	     32-bit value used to identify this message.

2175	   Common Hello Parameters TLV
2176	     Specifies parameters common to all Hello messages.  The encoding
2177	     for the Common Hello Parameters TLV is:

2179	      0                   1                   2                   3
2180	      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
2181	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2182	     |0|0| Common Hello Parms(0x0400)|      Length                   |
2183	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2184	     |      Hold Time                |T|R| Reserved                  |
2185	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2187	     Hold Time,
2188	       Hello hold time in seconds.  An LSR maintains a record of Hellos
2189	       received from potential peers (see Section "Hello Message
2190	       Procedures").  Hello Hold Time specifies the time the sending LSR
2191	       will maintain its record of Hellos from the receiving LSR without
2192	       receipt of another Hello.

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

2198	       A value of 0 means use the default, which is 15 seconds for Link
2199	       Hellos and 45 seconds for Targeted Hellos.  A value of 0xffff
2200	       means infinite.

2202	     T, Targeted Hello
2203	       A value of 1 specifies that this Hello is a Targeted Hello.  A
2204	       value of 0 specifies that this Hello is a Link Hello.

2206	     R, Request Send Targeted Hellos
2207	       A value of 1 requests the receiver to send periodic Targeted
2208	       Hellos to the source of this Hello.  A value of 0 makes no
2209	       request.

2211	       An LSR initiating Extended Discovery sets R to 1.  If R is 1, the
2212	       receiving LSR checks whether it has been configured to send
2213	       Targeted Hellos to the Hello source in response to Hellos with
2214	       this request.  If not, it ignores the request.  If so, it
2215	       initiates periodic transmission of Targeted Hellos to the Hello
2216	       source.

2218	     Reserved
2219	       This field is reserved.  It must be set to zero on transmission
2220	       and ignored on receipt.

2222	     Optional Parameters
2223	       This variable length field contains 0 or more parameters, each
2224	       encoded as a TLV.  The optional parameters defined by this
2225	       version of the protocol are

2227	           Optional Parameter    Type     Length  Value

2229	           Transport Address     0x0401     4      See below
2230	           Configuration         0x0402     4      See below
2231	              Sequence Number

2233	       Transport Address
2234	         Specifies the IPv4 address to be used for the sending LSR when
2235	         opening the LDP session TCP connection.  If this optional TLV
2236	         is not present the IPv4 source address for the UDP packet
2237	         carrying the Hello should be used.

2239	       Configuration Sequence Number
2240	         Specifies a 4 octet unsigned configuration sequence number that
2241	         identifies the configuration state of the sending LSR.  Used by
2242	         the receiving LSR to detect configuration changes on the
2243	         sending LSR.

2245	3.5.2.1. Hello Message Procedures

2247	   An LSR receiving Hellos from another LSR maintains a Hello adjacency
2248	   corresponding to the Hellos.  The LSR maintains a hold timer with the
2249	   Hello adjacency which it restarts whenever it receives a Hello that
2250	   matches the Hello adjacency.  If the hold timer for a Hello adjacency
2251	   expires the LSR discards the Hello adjacency: see sections
2252	   "Maintaining Hello Adjacencies" and "Maintaining LDP Sessions".

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

2257	   An LSR processes a received LDP Hello as follows:

2259	      1. The LSR checks whether the Hello is acceptable.  The criteria
2260	         for determining whether a Hello is acceptable are
2261	         implementation dependent (see below for example criteria).

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

2265	      3. If the Hello is acceptable, the LSR checks whether it has a
2266	         Hello adjacency for the Hello source. If so, it restarts the
2267	         hold timer for the Hello adjacency.  If not it creates a Hello
2268	         adjacency for the Hello source and starts its hold timer.

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

2273	      5. Finally, if the LSR has no LDP session for the label space
2274	         specified by the LDP identifier in the PDU header for the
2275	         Hello, it follows the procedures of Section "LDP Session
2276	         Establishment".

2278	   The following are examples of acceptability criteria for Link and
2279	   Targeted Hellos:

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

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

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

2289	           - The LSR has been configured to send Targeted Hellos to
2290	             a.b.c.d.

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

2294	       Transport Address
2295	         The LSR associates the specified transport address with the
2296	         Hello adjacency.

2298	       Configuration Sequence Number
2299	         The Configuration Sequence Number optional parameter is used by
2300	         the sending LSR to signal configuration changes to the
2301	         receiving LSR.  When a receiving LSR playing the active role in
2302	         LDP session establishment detects a change in the sending LSR
2303	         configuration, it may clear the session setup backoff delay, if
2304	         any, associated with the sending LSR (see Section "Session
2305	         Initialization").

2307	         A sending LSR using this optional parameter is responsible for
2308	         maintaining the configuration sequence number it transmits in
2309	         Hello messages.  Whenever there is a configuration change on
2310	         the sending LSR, it increments the configuration sequence
2311	         number.

2313	3.5.3. Initialization Message

2315	   The LDP Initialization Message is exchanged as part of the LDP
2316	   session establishment procedure; see Section "LDP Session
2317	   Establishment".

2319	   The encoding for the Initialization Message is:

2321	    0                   1                   2                   3
2322	    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
2323	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2324	   |0|   Initialization (0x0200)   |      Message Length           |
2325	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2326	   |                     Message ID                                |
2327	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2328	   |                     Common Session Parameters TLV             |
2329	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2330	   |                     Optional Parameters                       |
2331	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2333	   Message ID
2334	     32-bit value used to identify this message.

2336	   Common Session Parameters TLV
2337	     Specifies values proposed by the sending LSR for parameters that
2338	     must be negotiated for every LDP session.

2340	     The encoding for the Common Session Parameters TLV is:

2342	        0                   1                   2                   3
2343	        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
2344	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2345	       |0|0| Common Sess Parms (0x0500)|      Length                   |
2346	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2347	       | Protocol Version              |      KeepAlive Time           |
2348	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2349	       |A|D|  Reserved |     PVLim     |      Max PDU Length           |
2350	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2351	       |                 Receiver LDP Identifer                        |
2352	       +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2353	       |                               |
2354	       -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++

2356	       Protocol Version
2357	         Two octet unsigned integer containing the version number of the
2358	         protocol.  This version of the specification specifies LDP
2359	         protocol version 1.

2361	       KeepAlive Time
2362	         Two octet unsigned non zero integer that indicates the number
2363	         of seconds that the sending LSR proposes for the value of the
2364	         KeepAlive Time.  The receiving LSR MUST calculate the value of
2365	         the KeepAlive Timer by using the smaller of its proposed
2366	         KeepAlive Time and the KeepAlive Time received in the PDU.  The
2367	         value chosen for KeepAlive Time indicates the maximum number of
2368	         seconds that may elapse between the receipt of successive PDUs
2369	         from the LDP peer on the session TCP connection.  The KeepAlive
2370	         Timer is reset each time a PDU arrives.

2372	       A, Label Advertisement Discipline
2373	         Indicates the type of Label advertisement.  A value of 0 means
2374	         Downstream Unsolicited advertisement; a value of 1 means
2375	         Downstream On Demand.

2377	         If one LSR proposes Downstream Unsolicited and the other
2378	         proposes Downstream on Demand, the rules for resolving this
2379	         difference is:

2381	           - If the session is for a label-controlled ATM link or a
2382	             label-controlled Frame Relay link, then Downstream on
2383	             Demand must be used.

2385	           - Otherwise, Downstream Unsolicited must be used.

2387	         If the label advertisement discipline determined in this way is
2388	         unacceptable to an LSR, it must send a Session
2389	         Rejected/Parameters Advertisement Mode Notification message in
2390	         response to the Initialization message and not establish the
2391	         session.

2393	       D, Loop Detection
2394	         Indicates whether loop detection based on path vectors is
2395	         enabled.  A value of 0 means loop detection is disabled; a
2396	         value of 1 means that loop detection is enabled.

2398	       PVLim, Path Vector Limit
2399	         The configured maximum path vector length.  Must be 0 if loop
2400	         detection is disabled (D = 0).  If the loop detection
2401	         procedures would require the LSR to send a path vector that
2402	         exceeds this limit, the LSR will behave as if a loop had been
2403	         detected for the FEC in question.

2405	         When Loop Detection is enabled in a portion of a network, it is
2406	         recommended that all LSRs in that portion of the network be
2407	         configured with the same path vector limit.  Although
2408	         knowledege of a peer's path vector limit will not change an
2409	         LSR's behavior, it does enable the LSR to alert an operator to
2410	         a possible misconfiguration.

2412	       Reserved
2413	         This field is reserved.  It must be set to zero on transmission
2414	         and ignored on receipt.

2416	       Max PDU Length
2417	         Two octet unsigned integer that proposes the maximum allowable
2418	         length for LDP PDUs for the session.  A value of 255 or less
2419	         specifies the default maximum length of 4096 octets.

2421	         The receiving LSR MUST calculate the maximum PDU length for the
2422	         session by using the smaller of its and its peer's proposals
2423	         for Max PDU Length. The default maximum PDU length applies
2424	         before session initialization completes.

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

2431	       Receiver LDP Identifer
2432	         Identifies the receiver's label space.  This LDP Identifier,
2433	         together with the sender's LDP Identifier in the PDU header
2434	         enables the receiver to match the Initialization message with
2435	         one of its Hello adjacencies; see Section "Hello Message
2436	         Procedures".

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

2442	   Optional Parameters
2443	     This variable length field contains 0 or more parameters, each
2444	     encoded as a TLV.  The optional parameters are:

2446	         Optional Parameter       Type     Length  Value

2448	         ATM Session Parameters   0x0501   var     See below
2449	         Frame Relay Session      0x0502   var     See below
2450	           Parameters

2452	     ATM Session Parameters
2453	       Used when an LDP session manages label exchange for an ATM link
2454	       to specify ATM-specific session parameters.

2456	        0                   1                   2                   3
2457	        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
2458	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2459	       |0|0|   ATM Sess Parms (0x0501) |      Length                   |
2460	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2461	       | M |   N   |D|                        Reserved                 |
2462	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2463	       |                 ATM Label Range Component 1                   |
2464	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2465	       |                                                               |
2466	       ~                                                               ~
2467	       |                                                               |
2468	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2469	       |                 ATM Label Range Component N                   |
2470	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2472	       M, ATM Merge Capabilities
2473	         Specifies the merge capabilities of an ATM switch.  The
2474	         following values are supported in this version of the
2475	         specification:

2477	                   Value          Meaning
2478	                     0            Merge not supported
2479	                     1            VP Merge supported
2480	                     2            VC Merge supported
2481	                     3            VP & VC Merge supported

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

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

2487	           - The interoperability of VP-merge-capable switches with
2488	             non-VP-merge-capable switches is a subject for future
2489	             study.

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

2495	       N, Number of label range components
2496	         Specifies the number of ATM Label Range Components included in
2497	         the TLV.

2499	       D, VC Directionality
2500	         A value of 0 specifies bidirectional VC capability, meaning the
2501	         LSR can (within a given VPI) support the use of a given VCI as
2502	         a label for both link directions independently.  A value of 1
2503	         specifies unidirectional VC capability, meaning (within a given
2504	         VPI) a given VCI may appear in a label mapping for one
2505	         direction on the link only.  When either or both of the peers
2506	         specifies unidirectional VC capability, both LSRs use
2507	         unidirectional VC label assignment for the link as follows.
2508	         The LSRs compare their LDP Identifiers as unsigned integers.
2509	         The LSR with the larger LDP Identifier may assign only odd-
2510	         numbered VCIs in the VPI/VCI range as labels.  The system with
2511	         the smaller LDP Identifier may assign only even-numbered VCIs
2512	         in the VPI/VCI range as labels.

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

2518	       One or more ATM Label Range Components
2519	         A list of ATM Label Range Components which together specify the
2520	         Label range supported by the transmitting LSR.

2522	         A receiving LSR MUST calculate the intersection between the
2523	         received range and its own supported label range.  The
2524	         intersection is the range in which the LSR may allocate and
2525	         accept labels.  LSRs MUST NOT establish a session with
2526	         neighbors for which the intersection of ranges is NULL.  In
2527	         this case, the LSR must send a Session Rejected/Parameters
2528	         Label Range Notification message in response to the
2529	         Initialization message and not establish the session.

2531	         The encoding for an ATM Label Range Component is:

2533	          0                   1                   2                   3
2534	          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
2535	         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2536	         |  Res  |    Minimum VPI        |      Minimum VCI              |
2537	         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2538	         |  Res  |    Maximum VPI        |      Maximum VCI              |
2539	         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2541	         Res
2542	           This field is reserved. It must be set to zero on
2543	           transmission and must be ignored on receipt.

2545	         Minimum VPI (12 bits)
2546	           This 12 bit field specifies the lower bound of a block of
2547	           Virtual Path Identifiers that is supported on the originating
2548	           switch.  If the VPI is less than 12-bits it should be right
2549	           justified in this field and preceding bits should be set to
2550	           0.

2552	         Minimum VCI (16 bits)
2553	           This 16 bit field specifies the lower bound of a block of
2554	           Virtual Connection Identifiers that is supported on the
2555	           originating switch.  If the VCI is less than 16-bits it
2556	           should be right justified in this field and preceding bits
2557	           should be set to 0.

2559	         Maximum VPI (12 bits)
2560	           This 12 bit field specifies the upper bound of a block of
2561	           Virtual Path Identifiers that is supported on the originating
2562	           switch.  If the VPI is less than 12-bits it should be right
2563	           justified in this field and preceding bits should be set to
2564	           0.

2566	         Maximum VCI (16 bits)
2567	           This 16 bit field specifies the upper bound of a block of
2568	           Virtual Connection Identifiers that is supported on the
2569	           originating switch.  If the VCI is less than 16-bits it
2570	           should be right justified in this field and preceding bits
2571	           should be set to 0.

2573	       When peer LSRs are connected indirectly by means of an ATM VP,
2574	       the sending LSR should set the Minimum and Maximum VPI fields to
2575	       0, and the receiving LSR must ignore the Minimum and Maximum VPI
2576	       fields.

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

2581	     Frame Relay Session Parameters
2582	       Used when an LDP session manages label exchange for a Frame Relay
2583	       link to specify Frame Relay-specific session parameters.

2585	        0                   1                   2                   3
2586	        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
2587	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2588	       |0|0|   FR Sess Parms (0x0502)  |      Length                   |
2589	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2590	       | M |   N   |D|                        Reserved                 |
2591	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2592	       |             Frame Relay Label Range Component 1               |
2593	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2594	       |                                                               |
2595	       ~                                                               ~
2596	       |                                                               |
2597	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2598	       |             Frame Relay Label Range Component N               |
2599	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2601	       M, Frame Relay Merge Capabilities
2602	         Specifies the merge capabilities of a Frame Relay switch.  The
2603	         following values are supported in this version of the
2604	         specification:

2606	                   Value          Meaning

2608	                     0            Merge not supported
2609	                     1            Merge supported

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

2613	       N, Number of label range components
2614	         Specifies the number of Frame Relay Label Range Components
2615	         included in the TLV.

2617	       D, VC Directionality
2618	         A value of 0 specifies bidirectional VC capability, meaning the
2619	         LSR can support the use of a given DLCI as a label for both
2620	         link directions independently.  A value of 1 specifies
2621	         unidirectional VC capability, meaning a given DLCI may appear
2622	         in a label mapping for one direction on the link only.  When
2623	         either or both of the peers specifies unidirectional VC
2624	         capability, both LSRs use unidirectional VC label assignement
2625	         for the link as follows.  The LSRs compare their LDP
2626	         Identifiers as unsigned integers.  The LSR with the larger LDP
2627	         Identifier may assign only odd-numbered DLCIs in the range as
2628	         labels.  The system with the smaller LDP Identifier may assign
2629	         only even-numbered DLCIs in the range as labels.

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

2635	       One or more Frame Relay Label Range Components
2636	         A list of Frame Relay Label Range Components which together
2637	         specify the Label range supported by the transmitting LSR.

2639	         A receiving LSR MUST calculate the intersection between the
2640	         received range and its own supported label range.  The
2641	         intersection is the range in which the LSR may allocate and
2642	         accept labels.  LSRs MUST NOT establish a session with
2643	         neighbors for which the intersection of ranges is NULL.  In
2644	         this case, the LSR must send a Session Rejected/Parameters
2645	         Label Range Notification message in response to the
2646	         Initialization message and not establish the session.

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

2650	          0                   1                   2                   3
2651	          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
2652	         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2653	         | Reserved    |Len|                     Minimum DLCI            |
2654	         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2655	         | Reserved        |                     Maximum DLCI            |
2656	         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2658	         Reserved
2659	           This field is reserved.  It must be set to zero on
2660	           transmission and ignored on receipt.

2662	         Len
2663	           This field specifies the number of bits of the DLCI.  The
2664	           following values are supported:

2666	                Len    DLCI bits

2668	                0       10
2669	                1       17
2670	                2       23

2672	         Minimum DLCI
2673	           This 23-bit vield specifies the lower bound of a block of
2674	           Data Link Connection Identifiers (DLCIs) that is supported on
2675	           the originating switch.  The DLCI should be right justified
2676	           in this field and unused bits should be set to 0.

2678	         Maximum DLCI
2679	           This 23-bit vield specifies the upper bound of a block of
2680	           Data Link Connection Identifiers (DLCIs) that is supported on
2681	           the originating switch.  The DLCI should be right justified
2682	           in this field and unused bits should be set to 0.

2684	   Note that there is no Generic Session Parameters TLV for sessions
2685	   which advertise Generic Labels.

2687	3.5.3.1. Initialization Message Procedures

2689	   See Section "LDP Session Establishment" and particularly Section
2690	   "Session Initialization" for general procedures for handling the
2691	   Initialization Message.

2693	3.5.4. KeepAlive Message

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

2698	   The encoding for the KeepAlive Message is:

2700	    0                   1                   2                   3
2701	    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
2702	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2703	   |0|   KeepAlive (0x0201)        |      Message Length           |
2704	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2705	   |                     Message ID                                |
2706	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2707	   |                     Optional Parameters                       |
2708	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2709	   Message ID
2710	     32-bit value used to identify this message.

2712	   Optional Parameters
2713	     No optional parameters are defined for the KeepAlive message.

2715	3.5.4.1. KeepAlive Message Procedures

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

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

2728	3.5.5. Address Message

2730	   An LSR sends the Address Message to an LDP peer to advertise its
2731	   interface addresses.

2733	   The encoding for the Address Message is:

2735	    0                   1                   2                   3
2736	    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
2737	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2738	   |0|   Address (0x0300)          |      Message Length           |
2739	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2740	   |                     Message ID                                |
2741	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2742	   |                                                               |
2743	   |                     Address List TLV                          |
2744	   |                                                               |
2745	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2746	   |                     Optional Parameters                       |
2747	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2749	   Message ID
2750	     32-bit value used to identify this message.

2752	   Address List TLV
2753	     The list of interface addresses being advertised by the sending
2754	     LSR.  The encoding for the Address List TLV is specified in Section
2755	     "Address List TLV".

2757	   Optional Parameters
2758	     No optional parameters are defined for the Address message.

2760	3.5.5.1. Address Message Procedures

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

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

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

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

2778	3.5.6. Address Withdraw Message

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

2783	   The encoding for the Address Withdraw Message is:

2785	    0                   1                   2                   3
2786	    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
2787	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2788	   |0|   Address Withdraw (0x0301) |      Message Length           |
2789	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2790	   |                     Message ID                                |
2791	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2792	   |                                                               |
2793	   |                     Address List TLV                          |
2794	   |                                                               |
2795	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2796	   |                     Optional Parameters                       |
2797	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2798	   Message ID
2799	     32-bit value used to identify this message.

2801	   Address list TLV
2802	     The list of interface addresses being withdrawn by the sending LSR.
2803	     The encoding for the Address list TLV is specified in Section
2804	     "Address List TLV".

2806	   Optional Parameters
2807	     No optional parameters are defined for the Address Withdraw
2808	     message.

2810	3.5.6.1. Address Withdraw Message Procedures

2812	   See Section "Address Message Procedures"

2814	3.5.7. Label Mapping Message

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

2819	   The encoding for the Label Mapping Message is:

2821	   0                   1                   2                   3
2822	   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
2823	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2824	   |0|   Label Mapping (0x0400)    |      Message Length           |
2825	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2826	   |                     Message ID                                |
2827	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2828	   |                     FEC TLV                                   |
2829	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2830	   |                     Label TLV                                 |
2831	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2832	   |                     Optional Parameters                       |
2833	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2835	   Message ID
2836	     32-bit value used to identify this message.

2838	   FEC TLV
2839	     Specifies the FEC component of the FEC-Label mapping being
2840	     advertised.  See Section "FEC TLV" for encoding.

2842	   Label TLV
2843	     Specifies the Label component of the FEC-Label mapping.  See
2844	     Section "Label TLV" for encoding.

2846	   Optional Parameters
2847	     This variable length field contains 0 or more parameters, each
2848	     encoded as a TLV.  The optional parameters are:

2850	         Optional Parameter    Length       Value

2852	         Label Request         4            See below
2853	             Message ID TLV
2854	         Hop Count TLV         1            See below
2855	         Path Vector TLV       variable     See below

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

2860	       Label Request Message ID
2861	         If this Label Mapping message is a response to a Label Request
2862	         message it must include the Request Message Id optional
2863	         parameter.  The value of this optional parameter is the Message
2864	         Id of the corresponding Label Request Message.

2866	       Hop Count
2867	         Specifies the running total of the number of LSR hops along the
2868	         LSP being setup by the Label Message.  Section "Hop Count
2869	         Procedures" describes how to handle this TLV.

2871	       Path Vector
2872	         Specifies the LSRs along the LSP being setup by the Label
2873	         Message.  Section "Path Vector Procedures" describes how to
2874	         handle this TLV.

2876	3.5.7.1. Label Mapping Message Procedures

2878	   The Mapping message is used by an LSR to distribute a label mapping
2879	   for a FEC to an LDP peer.  If an LSR distributes a mapping for a FEC
2880	   to multiple LDP peers, it is a local matter whether it maps a single
2881	   label to the FEC, and distributes that mapping to all its peers, or
2882	   whether it uses a different mapping for each of its peers.

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

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

2892	   See Appendx A "LDP Label Distribution Procedures" for more details.

2894	3.5.7.1.1. Independent Control Mapping

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

2899	      1. The LSR recognizes a new FEC via the forwarding table, and the
2900	         label advertisement mode is Downstream Unsolicited
2901	         advertisement.

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

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

2909	      4. The attributes of a mapping change.

2911	      5. The receipt of a mapping from the downstream next hop  AND
2912	            a) no upstream mapping has been created  OR
2913	            b) loop detection is configured  OR
2914	            c) the attributes of the mapping have changed.

2916	3.5.7.1.2. Ordered Control Mapping

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

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

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

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

2931	      4. The attributes of a mapping change.

2933	      5. The receipt of a mapping from the downstream next hop  AND
2934	            a) no upstream mapping has been created   OR
2935	            b) loop detection is configured   OR
2936	            c) the attributes of the mapping have changed.

2938	3.5.7.1.3. Downstream on Demand Label Advertisement

2940	   In general, the upstream LSR is responsible for requesting label
2941	   mappings when operating in Downstream on Demand mode.  However,
2942	   unless some rules are followed, it is possible for neighboring LSRs
2943	   with different advertisement modes to get into a livelock situation
2944	   where everything is functioning properly, but no labels are
2945	   distributed.  For example, consider two LSRs Ru and Rd where Ru is
2946	   the upstream LSR and Rd is the downstream LSR for a particular FEC.
2947	   In this example, Ru is using Downstream Unsolicited advertisement
2948	   mode and Rd is using Downstream on Demand mode.  In this case, Rd may
2949	   assume that Ru will request a label mapping when it wants one and Ru
2950	   may assume that Rd will advertise a label if it wants Ru to use one.
2951	   If Rd and Ru operate as suggested, no labels will be distributed from
2952	   Rd to Ru.

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

2960	3.5.7.1.4. Downstream Unsolicited Label Advertisement

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

2966	   The combination of Downstream Unsolicited mode and conservative label
2967	   retention can lead to a situation where an LSR releases the label for
2968	   a FEC that it later needs.  For example, if LSR Rd advertises to LSR
2969	   Ru the label for a FEC for which it is not Ru's next hop, Ru will
2970	   release the label.  If Ru's next hop for the FEC later changes to Rd,
2971	   it needs the previously released label.

2973	   To deal with this situation either Ru can explicitly request the
2974	   label when it needs it, or Rd can periodically readvertise it to Ru.
2975	   In many situations Ru will know when it needs the label from Rd.  For
2976	   example, when its next hop for the FEC changes to Rd.  However, there
2977	   could be situations when Ru does not.  For example, Rd may be
2978	   attempting to establish an LSP with non-standard properties.  Forcing
2979	   Ru to explicitly request the label in this situation would require it
2980	   to maintain state about a potential LSP with non-standard properties.

2982	   In situations where Ru knows it needs the label, it is responsible
2983	   for explicitly requesting the label by means of a Label Request
2984	   message.  In situations where Ru may not know that it needs the
2985	   label, Rd is responsible for periodically readvertising the label to
2986	   Ru.

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

2993	3.5.8. Label Request Message

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

2998	   The encoding for the Label Request Message is:

3000	    0                   1                   2                   3
3001	    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
3002	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3003	   |0|   Label Request (0x0401)    |      Message Length           |
3004	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3005	   |                     Message ID                                |
3006	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3007	   |                     FEC TLV                                   |
3008	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3009	   |                     Optional Parameters                       |
3010	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3012	   Message ID
3013	     32-bit value used to identify this message.

3015	   FEC TLV
3016	     The FEC for which a label is being requested.  See Section "FEC
3017	     TLV" for encoding.

3019	   Optional Parameters
3020	     This variable length field contains 0 or more parameters, each
3021	     encoded as a TLV.  The optional parameters are:

3023	         Optional Parameter     Length       Value
3024	         Hop Count TLV          1            See below
3025	         Path Vector TLV        variable     See below

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

3030	       Hop Count
3031	         Specifies the running total of the number of LSR hops along the
3032	         LSP being setup by the Label Request Message.  Section "Hop
3033	         Count Procedures" describes how to handle this TLV.

3035	       Path Vector
3036	         Specifies the LSRs along the LSR being setup by the Label
3037	         Request Message.  Section "Path Vector Procedures" describes
3038	         how to handle this TLV.

3040	3.5.8.1. Label Request Message Procedures

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

3045	   An LSR may transmit a Request message under any of the following
3046	   conditions:

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

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

3055	         Note that if the LSR already has a pending Label Request
3056	         message for the new hext hop it should not issue an additional
3057	         Label Request in response to the next hop change.

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

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

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

3073	   When the FEC for which a label is requested is a Prefix FEC Element
3074	   or a Host Address FEC Element, the receiving LSR uses its routing
3075	   table to determine its response.  Unless its routing table includes
3076	   an entry that exactly matches the requested Prefix or Host Address,
3077	   the LSR must respond with a No Route Notification message.

3079	   The message ID of the Label Request message serves as an identifier
3080	   for the Label Request transaction.  When the receiving LSR responds
3081	   with a Label Mapping message, the mapping message must include a
3082	   Label Request/Returned Message ID TLV optional parameter which
3083	   includes the message ID of the Label Request message.  Note that
3084	   since LSRs use Label Request message IDs as transaction identifiers
3085	   an LSR should not reuse the message ID of a Label Request message
3086	   until the corresponding transaction completes.

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

3091	     No Route
3092	       The FEC for which a label was requested includes a FEC Element
3093	       for which the LSR does not have a route.

3095	     No Label Resources
3096	       The LSR cannot provide a label because of resource limitations.
3097	       When resources become available the LSR must notify the
3098	       requesting LSR by sending a Notification message with the Label
3099	       Resources Available Status Code.

3101	       An LSR that receives a No Label Resources response to a Label
3102	       Request message must not issue further Label Request messages
3103	       until it receives a Notification message with the Label Resources
3104	       Available Status code.

3106	     Loop Detected
3107	       The LSR has detected a looping Label Requst message.

3109	   See Appendx A "LDP Label Distribution Procedures" for more details.

3111	3.5.9. Label Abort Request Message

3113	   The Label Abort Request message may be used to abort an outstanding
3114	   Label Request message.

3116	   The encoding for the Label Abort Request Message is:

3118	    0                   1                   2                   3
3119	    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
3120	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3121	   |0|   Label Abort Req (0x0404)  |      Message Length           |
3122	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3123	   |                     Message ID                                |
3124	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3125	   |                     FEC TLV                                   |
3126	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3127	   |                     Label Request Message ID TLV              |
3128	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3129	   |                     Optional Parameters                       |
3130	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3132	   Message ID
3133	     32-bit value used to identify this message.

3135	   FEC TLV
3136	     Identifies the FEC for which the FEC-label mapping is being
3137	     withdrawn.

3139	   Label Request Message ID TLV
3140	     Specifies the message ID of the Label Request message to be
3141	     aborted.

3143	   Optional Parameters
3144	     No optional parameters are defined for the Label Abort Req message.

3146	3.5.9.1. Label Abort Request Message Procedures

3148	   An LSR Ru may send a Label Abort Request message to abort an
3149	   outstanding Label Request message for FEC sent to LSR Rd in the
3150	   following circumstances:

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

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

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

3161	   There may be other situations where an LSR may choose to abort an
3162	   outstanding Label Request message in order to reclaim resource
3163	   associated with the pending LSP.  However, specificaion of general
3164	   strategies for using the abort mechanism is beyond the scope of LDP.

3166	   When an LSR receives a Label Abort Request message, if it has not
3167	   previously responded to the Label Request being aborted with a Label
3168	   Mapping message or some other Notification message, it must
3169	   acknowledge the abort by responding with a Label Request Aborted
3170	   Notification message.  The Notification must include a Label Request
3171	   Message ID TLV that carries the message ID of the aborted Label
3172	   Request message.

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

3178	   If an LSR receives a Label Mapping message in response to a Label
3179	   Request message after it has sent a Label Abort Request message to
3180	   abort the Label Request, the label in the Label Mapping message is
3181	   valid.  The LSR may choose to use the label or to release it with a
3182	   Label Release mesage.

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

3188	     - A Label Request Aborted Notfication message acknowledging the
3189	       abort;

3191	     - A Label Mapping message in response to the Label Request message
3192	       being aborted;

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

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

3201	   Note that the response to a Label Abort Request message is never
3202	   "ordered".  That is, the response does not depend on the downstream
3203	   state of the LSP setup being aborted.  An LSR receiving a Label Abort
3204	   Request message must process it immediately, regardless of the
3205	   downstream state of the LSP, responding with a Label Request Aborted
3206	   Notification or ignoring it, as appropriate.

3208	3.5.10. Label Withdraw Message

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

3215	   The encoding for the Label Withdraw Message is:

3217	    0                   1                   2                   3
3218	    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
3219	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3220	   |0|   Label Withdraw (0x0402)   |      Message Length           |
3221	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3222	   |                     Message ID                                |
3223	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3224	   |                     FEC TLV                                   |
3225	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3226	   |                     Label TLV (optional)                      |
3227	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3229	   Message ID
3230	     32-bit value used to identify this message.

3232	   FEC TLV
3233	     Identifies the FEC for which the FEC-label mapping is being
3234	     withdrawn.

3236	   Optional Parameters
3237	     This variable length field contains 0 or more parameters, each
3238	     encoded as a TLV.  The optional parameters are:

3240	         Optional Parameter    Length       Value

3242	         Label TLV             variable     See below

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

3246	       Label
3247	         If present, specifies the label being withdrawn (see procedures
3248	         below).

3250	3.5.10.1. Label Withdraw Message Procedures

3252	   An LSR transmits a Label Withdraw message under the following
3253	   conditions:

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

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

3262	   The FEC TLV specifies the FEC for which labels are to be withdrawn.
3263	   If no Label TLV follows the FEC, all labels associated with the FEC
3264	   are to be withdrawn; otherwise only the label specified in the
3265	   optional Label TLV is to be withdrawn.

3267	   The FEC TLV may contain the Wildcard FEC Element; if so, it may
3268	   contain no other FEC Elements.  In this case, if the Label Withdraw
3269	   message contains an optional Label TLV, then the label is to be
3270	   withdrawn from all FECs to which it is bound.  If there is not an
3271	   optional Label TLV in the Label Withdraw message, then the sending
3272	   LSR is withdrawing all label mappings previously advertised to the
3273	   receiving LSR.

3275	   An LSR that receives a Label Withdraw message must respond with a
3276	   Label Release message.

3278	   See Appendx A "LDP Label Distribution Procedures" for more details.

3280	3.5.11. Label Release Message

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

3286	   The encoding for the Label Release Message is:

3288	    0                   1                   2                   3
3289	    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
3290	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3291	   |0|   Label Release (0x0403)   |      Message Length            |
3292	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3293	   |                     Message ID                                |
3294	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3295	   |                     FEC TLV                                   |
3296	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3297	   |                     Label TLV (optional)                      |
3298	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3300	   Message ID
3301	     32-bit value used to identify this message.

3303	   FEC TLV
3304	     Identifies the FEC for which the FEC-label mapping is being
3305	     released.

3307	   Optional Parameters
3308	     This variable length field contains 0 or more parameters, each
3309	     encoded as a TLV.  The optional parameters are:

3311	         Optional Parameter    Length       Value

3313	         Label TLV             variable     See below

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

3317	       Label
3318	         If present, the label being released (see procedures below).

3320	3.5.11.1. Label Release Message Procedures

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

3326	   An LSR must transmit a Label Release message under any of the
3327	   following conditions:

3329	      1. The LSR which sent the label mapping is no longer the next hop
3330	         for the mapped FEC, and the LSR is configured for conservative
3331	         operation.

3333	      2. The LSR receives a label mapping from an LSR which is not the
3334	         next hop for the FEC, and the LSR is configured for
3335	         conservative operation.

3337	      3. The LSR receives a Label Withdraw message.

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

3345	   The FEC TLV specifies the FEC for which labels are to be released.
3346	   If no Label TLV follows the FEC, all labels associated with the FEC
3347	   are to be released; otherwise only the label specified in the
3348	   optional Label TLV is to be released.

3350	   The FEC TLV may contain the Wildcard FEC Element; if so, it may
3351	   contain no other FEC Elements.  In this case, if the Label Release
3352	   message contains an optional Label TLV, then the label is to be
3353	   released for all FECs to which it is bound.  If there is not an
3354	   optional Label TLV in the Label Release message, then the sending LSR
3355	   is releasing all label mappings previously learned from the receiving
3356	   LSR.

3358	   See Appendx A "LDP Label Distribution Procedures" for more details.

3360	3.6. Messages and TLVs for Extensibility

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

3365	   This section specifies TLVs and messages for vendor-private and
3366	   experimental use.

3368	3.6.1. LDP Vendor-private Extensions

3370	   Vendor-private TLVs and messages are used to convey vendor-private
3371	   information between LSRs.

3373	3.6.1.1. LDP Vendor-private TLVs

3375	   The Type range 0x3E00 through 0x3EFF is reserved for vendor-private
3376	   TLVs.

3378	   The encoding for a vendor-private TLV is:

3380	    0                   1                   2                   3
3381	    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
3382	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3383	   |U|F|    Type (0x3E00-0x3EFF)   |            Length             |
3384	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3385	   |                           Vendor ID                           |
3386	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3387	   |                                                               |
3388	   |                           Data....                            |
3389	   ~                                                               ~
3390	   |                                                               |
3391	   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3392	   |                               |
3393	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3395	   U bit
3396	     Unknown TLV bit.  Upon receipt of an unknown TLV, if U is clear
3397	     (=0), a notification must be returned to the message originator and
3398	     the entire message must be ignored; if U is set (=1), the unknown
3399	     TLV is silently ignored and the rest of the message is processed as
3400	     if the unknown TLV did not exist.

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

3405	   F bit
3406	     Forward unknown TLV bit.  This bit only applies when the U bit is
3407	     set and the LDP message containing the unknown TLF is is to be
3408	     forwarded.  If F is clear (=0), the unknown TLV is not forwarded
3409	     with the containing message; if F is set (=1), the unknown TLV is
3410	     forwarded with the containing message.

3412	   Type
3413	     Type value in the range 0x3E00 through 0x3EFF.  Together, the Type
3414	     and Vendor Id field specify how the Data field is to be
3415	     interpreted.

3417	   Length
3418	     Specifies the cumulative length in octets of the Vendor ID and Data
3419	     fields.

3421	   Vendor Id
3422	     802 Vendor ID as assigned by the IEEE.

3424	   Data
3425	     The remaining octets after the Vendor ID in the Value field are
3426	     optional vendor-dependent data.

3428	3.6.1.2. LDP Vendor-private Messages

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

3433	    0                   1                   2                   3
3434	    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
3435	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3436	   |U|    Msg Type (0x3E00-0x3EFF) |      Message Length           |
3437	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3438	   |                     Message ID                                |
3439	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3440	   |                     Vendor ID                                 |
3441	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3442	   +                                                               +
3443	   |                     Remaining Mandatory Parameters            |
3444	   +                                                               +
3445	   |                                                               |
3446	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3447	   |                                                               |
3448	   +                                                               +
3449	   |                     Optional Parameters                       |
3450	   +                                                               +
3451	   |                                                               |
3452	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3454	   U bit
3455	     Unknown message bit.  Upon receipt of an unknown message, if U is
3456	     clear (=0), a notification is returned to the message originator;
3457	     if U is set (=1), the unknown message is silently ignored.

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

3462	   Msg Type
3463	     Message type value in the range 0x3E00 through 0x3EFF.  Together,
3464	     the Msg Type and the Vendor ID specify how the message is to be
3465	     interpreted.

3467	   Message Length
3468	     Specifies the cumulative length in octets of the Message ID, Vendor
3469	     ID, Remaining Mandatory Parameters and Optional Parameters.

3471	   Message ID
3472	     32-bit integer used to identify this message.  Used by the sending
3473	     LSR to facilitate identifying notification messages that may apply
3474	     to this message.  An LSR sending a notification message in response
3475	     to this message will include this Message Id in the notification
3476	     message; see Section "Notification Message".

3478	   Vendor ID
3479	     802 Vendor ID as assigned by the IEEE.

3481	   Remaining Mandatory Parameters
3482	     Variable length set of remaining required message parameters.

3484	   Optional Parameters
3485	     Variable length set of optional message parameters.

3487	3.6.2. LDP Experimental Extensions

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

3492	     - The Type range 0x3F00 through 0x3FFF is reserved for experimental
3493	       TLVs.

3495	     - The Message Type range 0x3F00 through 0x3FFF is reserved for
3496	       experimental messages.

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

3501	       Experimental TLVs and messages use an Experiment ID field in
3502	       place of a Vendor ID field.  The Experiment ID field is used with
3503	       the Type or Message Type field to specify the interpretation of
3504	       the experimental TLV or Message.

3506	       Administration of Experiment IDs is the responsiblity of the
3507	       experimenters.

3509	3.7. Message Summary

3511	   The following are the LDP messages defined in this version of the
3512	   protocol.

3514	       Message Name            Type     Section Title

3516	       Notification            0x0001   "Notification Message"
3517	       Hello                   0x0100   "Hello Message"
3518	       Initialization          0x0200   "Initialization Message"
3519	       KeepAlive               0x0201   "KeepAlive Message"
3520	       Address                 0x0300   "Address Message"
3521	       Address Withdraw        0x0301   "Address Withdraw Message"
3522	       Label Mapping           0x0400   "Label Mapping Message"
3523	       Label Request           0x0401   "Label Request Message"
3524	       Label Withdraw          0x0402   "Label Withdraw Message"
3525	       Label Release           0x0403   "Label Release Message"
3526	       Label Abort Request     0x0404   "Label Abort Request Message"
3527	       Vendor-Private          0x3E00-  "LDP Vendor-private Extensions"
3528	                               0x3EFF
3529	       Experimental            0x3F00-  "LDP Experimental Extensions"
3530	                               0x3FFF

3532	3.8. TLV Summary

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

3536	       TLV                      Type      Section Title

3538	       FEC                      0x0100    "FEC TLV"
3539	       Address List             0x0101    "Address List TLV"
3540	       Hop Count                0x0103    "Hop Count TLV"
3541	       Path Vector              0x0104    "Path Vector TLV"
3542	       Generic Label            0x0200    "Generic Label TLV"
3543	       ATM Label                0x0201    "ATM Label TLV"
3544	       Frame Relay Label        0x0202    "Frame Relay Label TLV"
3545	       Status                   0x0300    "Status TLV"
3546	       Extended Status          0x0301    "Notification Message"
3547	       Returned PDU             0x0302    "Notification Message"
3548	       Returned Message         0x0303    "Notification Message"
3549	       Common Hello             0x0400    "Hello Message"
3550	          Parameters
3551	       Transport Address        0x0401    "Hello Message"
3552	       Configuration            0x0402    "Hello Message"
3553	          Sequence Number
3554	       Common Session           0x0500    "Initialization Message"
3555	          Parameters
3556	       ATM Session Parameters   0x0501    "Initialization Message"
3557	       Frame Relay Session      0x0502    "Initialization Message"
3558	          Parameters

3560	       Label Request            0x0600    "Label Mapping Message"
3561	           Message ID
3562	       Vendor-Private           0x3E00-   "LDP Vendor-private Extensions"
3563	                                0x3EFF
3564	       Experimental             0x3F00-   "LDP Experimental Extensions"
3565	                                0x3FFF

3567	3.9. Status Code Summary

3569	   The following are the Status Codes defined in this version of the
3570	   protocol.

3572	   The "E" column is the required setting of the Status Code E-bit; the
3573	   "Status Data" column is the value of the 30-bit Status Data field in
3574	   the Status Code TLV.

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

3579	       Status Code           E   Status Data   Section Title

3581	       Success               0   0x00000000    "Status TLV"
3582	       Bad LDP Identifer     1   0x00000001    "Events Signaled by ..."
3583	       Bad Protocol Version  1   0x00000002    "Events Signaled by ..."
3584	       Bad PDU Length        1   0x00000003    "Events Signaled by ..."
3585	       Unknown Message Type  0   0x00000004    "Events Signaled by ..."
3586	       Bad Message Length    1   0x00000005    "Events Signaled by ..."
3587	       Unknown TLV           0   0x00000006    "Events Signaled by ..."
3588	       Bad TLV length        1   0x00000007    "Events Signaled by ..."
3589	       Malformed TLV Value   1   0x00000008    "Events Signaled by ..."
3590	       Hold Timer Expired    1   0x00000009    "Events Signaled by ..."
3591	       Shutdown              1   0x0000000A    "Events Signaled by ..."
3592	       Loop Detected         0   0x0000000B    "Loop Detection"
3593	       Unknown FEC           0   0x0000000C    "FEC Procedures"
3594	       No Route              0   0x0000000D    "Label Request Mess ..."
3595	       No Label Resources    0   0x0000000E    "Label Request Mess ..."
3596	       Label Resources /     0   0x0000000F    "Label Request Mess ..."
3597	           Available
3598	       Session Rejected/     1   0x00000010    "Session Initialization"
3599	          No Hello
3600	       Session Rejected/     1   0x00000011    "Session Initialization"
3601	          Parameters Advertisement Mode
3602	       Session Rejected/     1   0x00000012    "Session Initialization"
3603	          Parameters Max PDU Length
3604	       Session Rejected/     1   0x00000013    "Session Initialization"
3605	          Parameters Label Range

3607	       KeepAlive Timer       1   0x00000014    "Events Signaled by ..."
3608	           Expired
3609	       Label Request Aborted 0   0x00000015    "Label Request Abort ..."

3611	3.10. Well-known Numbers

3613	3.10.1. UDP and TCP Ports

3615	   The UDP port for LDP Hello messages is 646.

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

3619	3.10.2. Implicit NULL Label

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

3624	4. Security Considerations

3626	   This section specifies an optional mechanism to protect against the
3627	   introduction of spoofed TCP segments into LDP session connection
3628	   streams.

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

3634	4.1. The TCP MD5 Signature Option

3636	   The following quotes from [rfc2385] outline the security properties
3637	   achieved by using the TCP MD5 Signature Option and summarizes its
3638	   operation:

3640	      "IESG Note

3642	         This document describes currrent existing practice for securing
3643	         BGP against certain simple attacks.  It is understood to have
3644	         security weaknesses against concerted attacks."

3646	      "Abstract

3648	         This memo describes a TCP extension to enhance security for
3649	         BGP.  It defines a new TCP option for carrying an MD5 [RFC1321]
3650	         digest in a TCP segment.  This digest acts like a signature for
3651	         that segment, incorporating information known only to the
3652	         connection end points.  Since BGP uses TCP as its transport,
3653	         using this option in the way described in this paper
3654	         significantly reduces the danger from certain security attacks
3655	         on BGP."

3657	      "Introduction

3659	         The primary motivation for this option is to allow BGP to
3660	         protect itself against the introduction of spoofed TCP segments
3661	         into the connection stream.  Of particular concern are TCP
3662	         resets.

3664	         To spoof a connection using the scheme described in this paper,
3665	         an attacker would not only have to guess TCP sequence numbers,
3666	         but would also have had to obtain the password included in the
3667	         MD5 digest.  This password never appears in the connection
3668	         stream, and the actual form of the password is up to the
3669	         application.  It could even change during the lifetime of a
3670	         particular connection so long as this change was synchronized
3671	         on both ends (although retransmission can become problematical
3672	         in some TCP implementations with changing passwords).

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

3678	      "MD5 as a Hashing Algorithm

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

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

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

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

3703	   End of quotes from [rfc2385].

3705	4.2. LDP Use of the TCP MD5 Signature Option

3707	   LDP uses the TCP MD5 Signature Option as follows:

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

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

3715	     - The LSR applies the MD5 algorithm as specified in [RFC2385] to
3716	       compute the MD5 digest for a TCP segment to be sent to a peer.
3717	       This computation makes use of the peer password as well as the
3718	       TCP segment.

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

3726	     - The LSR ignores LDP Hellos from any LSR for which a password has
3727	       not been configured.  This ensures that the LSR establishes LDP
3728	       TCP connections only with LSRs for which a password has been
3729	       configured.

3731	5. Intellectual Property Considerations

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

3738	6. Acknowledgments

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

3745	7. References

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

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

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

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

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

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

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

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

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

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

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

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

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

3794	   [rfc1771] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)",
3795	   RFC 1771, IBM Corp, Cisco Systems, March 1995.

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

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

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

3808	8. Author Information

3810	   Loa Andersson                            Andre Fredette
3811	   Nortel Networks Inc                      Nortel Networks Inc
3812	   Kungsgatan 34, PO Box 1788               3 Federal Street
3813	   111 97 Stockholm                         Billerica, MA  01821
3814	   Sweden                                   Phone:  978-916-8524
3815	   Phone: +46 8 441 78 34                   email: fredette@baynetworks.com
3816	   Mobile: +46 70 522 78 34
3817	   email: loa_andersson@baynetworks.com

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

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

3833	Appendix A. LDP Label Distribution Procedures

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3957	A.1. Handling Label Distribution Events

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

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

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

3978	A.1.1. Receive Label Request

3980	 Summary:

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

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

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

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

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

3994	 Context:

3996	     - LSR. The LSR handling the event.

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

4000	     - FEC. The FEC specified in the message.

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

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

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

4011	 Algorithm:

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

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

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

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

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

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

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

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

4040	   LRq.9   Perform LSR Label Distribution procedure:

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

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

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

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

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

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

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

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

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

4080	   LRq.10  Perform LSR Label Request procedure:

4082	             For Request Never

4084	               1.  Goto LRq.13.

4086	             For Request When Needed OR
4087	             For Request On Request

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

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

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

4099	   LRq.12  Perform LSR Label Use procedure.

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

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

4108	   LRq.13  DONE

4110	 Notes:

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

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

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

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

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

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

4140	A.1.2. Receive Label Mapping

4142	 Summary:

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

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

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

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

4156	 Context:

4158	     - LSR. The LSR handling the event.

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

4162	     - FEC. The FEC specified in the message.

4164	     - Label. The label specified in the message.

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

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

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

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

4177	 Algorithm:

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

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

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

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

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

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

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

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

4206	   LMp.9   Determine the Next Hop for FEC.

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

4211	   LMp.11  Perform LSR Label Release procedure:

4213	             For Conservative Label retention:

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

4219	             For Liberal Label retention:

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

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

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

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

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

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

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

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

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

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

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

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

4261	   LMp.23  Perform LSR Label Distribution procedure:

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

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

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

4276	               3.  Goto LMp.24.

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

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

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

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

4295	               4.  Goto LMp.24.

4297	   LMp.24  Perform LSR Label Use procedure:

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

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

4306	   LMp.25  End iteration from LMp.17.

4308	   LMp.26  DONE.

4310	 Notes:

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

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

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

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

4336	      5. LMp.19 through LMp.21 deal with a situation that can arise when
4337	         the LSR is using independent control and it receives a mapping
4338	         from the downstream peer after it has sent a mapping to an
4339	         upstream peer. In this situation the LSR needs to propagate any
4340	         changed attributes, such as Hop Count, upstream. If Loop
4341	         Detection is configured on, the propagated attributes must
4342	         include the Path Vector

4344	A.1.3. Receive Label Abort Request

4346	 Summary:

4348	     When an LSR receives a label abort request message from a peer, it
4349	     checks whether it has already responded to the label request in
4350	     question. If it has, it silently ignores the message. If it has
4351	     not, it sends the peer a Label Request Aborted Notification. In
4352	     addition, if it has a label request outstanding for the LSP in
4353	     question to a downstream peer, it sends a Label Abort Request to
4354	     the downstream peer to abort the LSP.

4356	 Context:

4358	     - LSR. The LSR handling the event.

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

4362	     - FEC. The FEC specified in the message.

4364	     - RequestMessageID. The message ID of the label request message to
4365	       be aborted.

4367	     - Next Hop. The next hop for the FEC.

4369	 Algorithm:

4371	   LAbR.1  Does the message match a previously received label request
4372	           message from MsgSource? (See Note 1.)
4373	           If not, goto LAbR.12.

4375	   LAbR.2  Has LSR responded to the previously received label request?
4376	           If so, goto LAbR.12.

4378	   LAbR.3  Execute procedure Send_Message(MsgSource, Notification, Label
4379	           Request Aborted, TLV), where TLV is the Label Request Message
4380	           ID TLV received in the label abort request message.

4382	   LAbR.4  Does LSR have a label request message outstanding for FEC?
4383	           If so, goto LAbR.7

4385	   LAbR.5  Does LSR have a label mapping for FEC?
4386	           If not, goto LAbR.11

4388	   LAbR.6  Generate Event: Received Label Release Message for FEC from
4389	           MsgSource. (See Note 2.)
4390	           Goto LAbR.11.

4392	   LAbR.7  Is LSR merging the LSP for FEC?
4393	           If not, goto LAbR.9.

4395	   LAbR.8  Are there upstream peers other than MsgSource that have
4396	           requested a label for FEC?
4397	           If so, goto LAbR.11.

4399	   LAbR.9  Execute procedure Send_Message (Next Hop, Label Abort
4400	           Request, FEC, TLV), where TLV is a Label Request Message ID
4401	           TLV containing the Message ID used by the LSR in the
4402	           outstanding Label Request message.

4404	   LAbR.10  Record that a label abort request for FEC is pending.

4406	   LAbR.11  Delete record of label request for FEC from MsgSource.

4408	   LAbR.12  DONE

4410	 Notes:

4412	      1. LSR uses FEC and the Label Request Message ID TLV carried by
4413	         the label abort request to locate its record (if any) for the
4414	         previously received label request from MsgSource.

4416	      2. If LSR has received a label mapping from NextHop, it should
4417	         behave as if it had advertised a label mapping to MsgSource and
4418	         MsgSource has released it.

4420	A.1.4. Receive Label Release

4422	 Summary:

4424	     When an LSR receives a label release message for a FEC from a peer,
4425	     it checks whether other peers hold the released label. If none do,
4426	     the LSR removes the label from forwarding/switching use, if it has
4427	     not already done so, and if the LSR holds a label mapping from the
4428	     FEC next hop, it releases the label mapping.

4430	 Context:

4432	     - LSR. The LSR handling the event.

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

4436	     - Label. The label specified in the message.

4438	     - FEC. The FEC specified in the message.

4440	 Algorithm:

4442	   LRl.1   Remove MsgSource from record of peers that hold Label for
4443	           FEC.  (See Note 1.)

4445	   LRl.2   Does message match an outstanding label withdraw for FEC
4446	           previously sent to MsgSource?
4447	           If not, goto LRl.4

4449	   LRl.3   Delete record of outstanding label withdraw for FEC
4450	           previously sent to MsgSource.

4452	   LRl.4   Is LSR merging labels for this FEC?
4453	           If not, goto LRl.6.  (See Note 2.)

4455	   LRl.5   Has LSR previously advertised a label for this FEC to other
4456	           peers?
4457	           If so, goto LRl.10.

4459	   LRl.6   Is LSR egress for the FEC?
4460	           If so, goto LRl.10

4462	   LRl.7   Is there a Next Hop for FEC? AND
4463	           Does LSR have a previously received label mapping for FEC
4464	           from Next Hop?
4465	           If not, goto LRl.10.

4467	   LRl.8   Is LSR configured to propagate releases?
4468	           If not, goto LRl.10.  (See Note 3.)

4470	   LRl.9   Execute procedure Send_Message (Next Hop, Label Release, FEC,
4471	           Label from Next Hop).

4473	   LRl.10  Remove Label from forwarding/switching use for traffic from
4474	           MsgSource.

4476	   LRl.11  Do any peers still hold Label for FEC?
4477	           If so, goto LRl.13.

4479	   LRl.12  Free the Label.

4481	   LRl.13  DONE.

4483	 Notes:

4485	      1. If LSR is using Downstream Unsolicited label distribution, it
4486	         should not re-advertise a label mapping for FEC to MsgSource
4487	         until MsgSource requests it.

4489	      2. LRl.4 through LRl.8 deal with determining whether where the LSR
4490	         should propagate the label release to a downstream peer
4491	         (LRl.9).

4493	      3. If LRl.8 is reached, no upstream LSR holds a label for the FEC,
4494	         and the LSR holds a label for the FEC from the FEC Next Hop.
4495	         The LSR could propagate the Label Release to the Next Hop. By
4496	         propagating the Label Release the LSR releases a potentially
4497	         scarce label resource. In doing so, it also increases the
4498	         latency for re-establishing the LSP should MsgSource or some
4499	         other upstream LSR send it a new Label Request for FEC.

4501	         Whether or not to propagate the release is not a protocol
4502	         issue. Label distribution will operate properly whether or not
4503	         the release is propagated. The decision to propagate or not
4504	         should take into consideration factors such as: whether labels
4505	         are a scarce resource in the operating environment; the
4506	         importance of keeping LSP setup latency low by keeping the
4507	         amount of signalling required small; whether LSP setup is
4508	         ingress-controlled or egress-controlled in the operating
4509	         environment.

4511	A.1.5. Receive Label Withdraw

4513	 Summary:

4515	     When an LSR receives a label withdraw message for a FEC from an LDP
4516	     peer, it responds with a label release message and it removes the
4517	     label from any forwarding/switching use. If ordered control is in
4518	     use, the LSR sends a label withdraw message to each LDP peer to
4519	     which it had previously sent a label mapping for the FEC. If the
4520	     LSR is using Downstream on Demand label advertisement with
4521	     independent control, it then acts as if it had just recognized the
4522	     FEC.

4524	 Context:

4526	     - LSR. The LSR handling the event.

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

4530	     - Label. The label specified in the message.

4532	     - FEC. The FEC specified in the message.

4534	 Algorithm:

4536	   LWd.1   Remove Label from forwarding/switching use.  (See Note 1.)

4538	   LWd.2   Execute procedure Send_Message (MsgSource, Label Release,
4539	           FEC, Label)

4541	   LWd.3   Has LSR previously received and retained a matching label
4542	           mapping for FEC from MsgSource?
4543	           If not, goto LWd.13.

4545	   LWd.4   Delete matching label mapping for FEC previously received
4546	           from MsgSource.

4548	   LWd.5   Is LSR using ordered control?
4549	           If so, goto LWd.8.

4551	   LWd.6   Is MsgSource using Downstream On Demand label advertisement?
4552	           If not, goto LWd.13.

4554	   LWd.7   Generate Event: Recognize New FEC for FEC.
4555	           Goto LWd.13.  (See Note 2.)

4557	   LWd.8   Iterate through LWd.12 for each Peer, other than MsgSource.

4559	   LWd.9   Has LSR previously sent a label mapping for FEC to Peer?
4560	           If not, continue interation for next Peer at LWd.8.

4562	   LWd.10  Does the label previously sent to Peer "map" to the withdrawn
4563	           Label?
4564	           If not, continue iteration for next Peer at LWd.8.  (See Note
4565	           3.)

4567	   LWd.11  Execute procedure Send_Label_Withdraw (Peer, FEC, Label
4568	           previously sent to Peer).

4570	   LWd.12  End iteration from LWd.8.

4572	   LWd.13  DONE

4574	 Notes:

4576	      1. If Label is not in forwarding/switching use, LWd.1 has no
4577	         effect.

4579	      2. LWd.7 handles the case where the LSR is using Downstream On
4580	         Demand label distribution with independent control. In this
4581	         situation the LSR should send a label request to the FEC next
4582	         hop as if it had just recognized the FEC.

4584	      3. LWd.10 handles both label merging (one or more incoming labels
4585	         map to the same outgoing label) and no label merging (one label
4586	         maps to the outgoing label) cases.

4588	A.1.6. Recognize New FEC

4590	 Summary:

4592	     The response by an LSR to learning a new FEC via the routing table
4593	     may involve one or more of the following actions:

4595	     - Transmission of label mappings for the FEC to one or more LDP
4596	       peers;

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

4600	     - Any of the actions that can occur when the LSR receives a label
4601	       mapping for the FEC from the FEC next hop.

4603	 Context:

4605	     - LSR. The LSR handling the event.

4607	     - FEC. The newly recognized FEC.

4609	     - Next Hop. The next hop for the FEC.

4611	     - InitAttributes. Attributes to be associated with the new FEC.
4612	       (See Note 1.)

4614	     - SAttributes. Attributes to be included in Label Mapping or Label
4615	       Request messages, if any, sent to peers.

4617	     - StoredHopCount. Hop count associated with FEC label mapping, if
4618	       any, previously received from Next Hop.

4620	 Algorithm:

4622	   FEC.1   Perform LSR Label Distribution procedure:

4624	             For Downstream Unsolicited Independent Control

4626	               1.  Iterate through 5 for each Peer.

4628	               2.  Has LSR previously received and retained a label
4629	                   mapping for FEC from Next Hop?
4630	                   If so, set Propagating to IsPropagating.
4631	                   If not, set Propagating to NotPropagating.

4633	               3.  Execute procedure Prepare_Label_Mapping_Attributes
4634	                   (Peer, FEC, InitAttributes, SAttributes, Propagating,
4635	                   Unknown hop count(0)).

4637	               4.  Execute procedure Send_Label (Peer, FEC, SAttributes)

4639	               5.  End iteration from 1.
4640	                   Goto FEC.2.

4642	             For Downstream Unsolicited Ordered Control

4644	               1.  Iterate through 5 for each Peer.

4646	               2.  Is LSR egress for the FEC? OR
4647	                   Has LSR previously received and retained a label
4648	                   mapping for FEC from Next Hop?
4649	                   If not, continue iteration for next Peer.

4651	               3.  xecute procedure Prepare_Label_Mapping_Attributes
4652	                   (Peer, FEC, InitAttributes, SAttributes, Propagating,
4653	                   StoredHopCount).

4655	               4.  Execute procedure Send_Label (Peer, FEC, SAttributes)

4657	               5.  End iteration from 1.
4658	                   Goto FEC.2.

4660	             For Downstream On Demand Independent Control OR
4661	             For Downstream On Demand Ordered Control

4663	               1.  Goto FEC.2.  (See Note 2.)

4665	   FEC.2   Has LSR previously received and retained a label mapping for
4666	           FEC from Next Hop?
4667	           If so, goto FEC.5

4669	   FEC.3   Is Next Hop an LDP peer?
4670	           If not, Goto FEC.6

4672	   FEC.4   Perform LSR Label Request procedure:

4674	             For Request Never

4676	               1.  Goto FEC.6

4678	             For Request When Needed OR
4679	             For Request On Request

4681	               1.  Execute procedure Prepare_Label_Request_Attributes
4682	                   (Next Hop, FEC, InitAttributes, SAttributes);

4684	               2.  Execute procedure Send_Label_Request (Next Hop, FEC,
4685	                   SAttributes).
4686	                   Goto FEC.6.

4688	   FEC.5   Generate Event: Received Label Mapping from Next Hop.  (See
4689	           Note 3.)

4691	   FEC.6   DONE.

4693	 Notes:

4695	      1. An example of an attribute that might be part of InitAttributes
4696	         is one which specifies desired LSP characteristics, such as
4697	         class of service (CoS).  (Note that while the current version
4698	         of LDP does not specify a CoS attribute, LDP extensions may.)
4699	         The means by which FEC InitAttributes, if any, are specified is
4700	         beyond the scope of LDP. Note that the InitAttributes will not
4701	         include a known Hop Count or a Path Vector.

4703	      2. An LSR using Downstream On Demand label distribution would send
4704	         a label only if it had a previously received label request
4705	         marked as pending. The LSR would have no such pending requests
4706	         because it responds to any label request for an unknown FEC by
4707	         sending the requesting LSR a No Route notification and
4708	         discarding the label request; see LRq.3

4710	      3. If the LSR has a label for the FEC from the Next Hop, it should
4711	         behave as if it had just received the label from the Next Hop.
4712	         This occurs in the case of Liberal label retention mode.

4714	A.1.7. Detect Change in FEC Next Hop

4716	 Summary:

4718	     The response by an LSR to a change in the next hop for a FEC may
4719	     involve one or more of the following actions:

4721	     - Removal of the label from the FEC's old next hop from
4722	       forwarding/switching use;

4724	     - Transmission of label mappping messages for the FEC to one or
4725	       more LDP peers;

4727	     - Transmission of a label request to the FEC's new next hop;

4729	     - Any of the actions that can occur when the LSR receives a label
4730	       mapping from the FEC's new next hop.

4732	 Context:

4734	     - LSR. The LSR handling the event.

4736	     - FEC. The FEC whose next hop changed.

4738	     - New Next Hop. The current next hop for the FEC.

4740	     - Old Next Hop. The previous next hop for the FEC.

4742	     - OldLabel. Label, if any, previously received from Old Next Hop.

4744	     - CurAttributes. The attributes, if any, currently associated with
4745	       the FEC.

4747	     - SAttributes. Attributes to be included in Label Label Request
4748	       message, if any, sent to New Next Hop.

4750	 Algorithm:

4752	    NH.1   Has LSR previously received and retained a label mapping for
4753	           FEC from Old Next Hop?
4754	           If not, goto NH.6.

4756	    NH.2   Remove label from forwarding/switching use. (See Note 1.)

4758	    NH.3   Is LSR using Liberal label retention?
4759	           If so, goto NH.6.

4761	    NH.4   Execute procedure Send_Message (Old Next Hop, Label Release,
4762	           OldLabel).

4764	    NH.5   Delete label mapping for FEC previously received from Old
4765	           Next Hop.

4767	    NH.6   Does LSR have a label request pending with Old Next Hop?
4768	           If not, goto NH.10.

4770	    NH.7   Is LSR using Conservative label retention?
4771	           If not, goto NH.10.

4773	    NH.8   Execute procedure Send_Message (Old Next Hop, Label Abort
4774	           Request, FEC, TLV), where TLV is a Label Request Message ID
4775	           TLV that carries the message ID of the pending label request.

4777	    NH.9   Record a label abort request is pending for FEC with Old Next
4778	           Hop.

4780	    NH.10  Is there a New Next Hop for the FEC?
4781	           If not, goto NH.16.

4783	    NH.11  Has LSR previously received and retained a label mapping for
4784	           FEC from New Next Hop?
4785	           If not, goto NH.13.

4787	    NH.12  Generate Event: Received Label Mapping from New Next Hop.
4788	           Goto NH.20. (See Note 2.)

4790	    NH.13  Is LSR using Downstream on Demand advertisement? OR
4791	           Is Next Hop using Downstream on Demand advertisement? OR
4792	           Is LSR using Conservative label retention? (See Note 3.)
4793	           If so, goto NH.14.
4794	           If not, goto NH.20.

4796	    NH.14  Execute procedure Prepare_Label_Request_Attributes (Next Hop,
4797	           FEC, CurAttributes, SAttributes)

4799	    NH.15  Execute procedure Send_Label_Request (New Next Hop, FEC,
4800	           SAttributes).  (See Note 4.)
4801	           Goto NH.20.

4803	    NH.16  Iterate through NH.19 for each Peer.

4805	    NH.17  Has LSR previously sent a label maping for FEC to Peer?
4806	           If not, continue iteration for next Peer at NH.16.

4808	    NH.18  Execute procedure Send_Label_Withdraw (Peer, FEC, Label
4809	           previously sent to Peer).

4811	    NH.19  End iteration from NH.16.

4813	    NH.20  DONE.

4815	 Notes:

4817	      1. If Label is not in forwarding/switching use, NH.2 has no
4818	         effect.

4820	      2. If the LSR has a label for the FEC from the New Next Hop, it
4821	         should behave as if it had just received the label from the New
4822	         Next Hop.

4824	      3. The purpose of the check on label retention mode is to avoid a
4825	         race with steps LMp.10-LMp.11 of the procedure for handling a
4826	         Label Mapping message where the LSR operating in Conservative
4827	         Label retention mode may have released a label mapping received
4828	         from the New Next Hop before it detected the FEC next hop had
4829	         changed.

4831	      4. Regardless of the Label Request procedure in use by the LSR, it
4832	         must send a label request if the conditions in NH.8 hold.
4833	         Therefore it executes the Send_Label_Request procedure directly
4834	         rather than perform LSR Label Request procedure.

4836	A.1.8. Receive Notification / Label Request Aborted

4838	 Summary:

4840	     When an LSR receives a Label Request Aborted notification from an
4841	     LDP peer it records that the corresponding label request
4842	     transaction, if any, has completed.

4844	 Context:

4846	     - LSR. The LSR handling the event.

4848	     - FEC. The FEC for which a label was requested.

4850	     - RequestMessageID. The message ID of the label request message to
4851	       be aborted.

4853	     - MsgSource. The LDP peer that sent the Notification message.

4855	 Algorithm:

4857	   LRqA.1  Does the notification correspond to an outstanding label
4858	           request abort for FEC? (See Note 1).
4859	           If not, goto LRqA.3.

4861	   LRqA.2  Record that the label request for FEC has been aborted.

4863	   LRqA.3  DONE

4865	 Notes:

4867	      1. The LSR uses the FEC and RequestMessageID to locate its record,
4868	         if any, of the outstanding label request abort.

4870	A.1.9. Receive Notification / No Label Resources

4872	 Summary:

4874	     When an LSR receives a No Label Resources notification from an LDP
4875	     peer, it stops sending label request messages to the peer until it
4876	     receives a Label Resources Available Notification from the peer.

4878	 Context:

4880	     - LSR. The LSR handling the event.

4882	     - FEC. The FEC for which a label was requested.

4884	     - MsgSource. The LDP peer that sent the Notification message.

4886	 Algorithm:

4888	   NoRes.1 Delete record of outstanding label request for FEC sent to
4889	           MsgSource.

4891	   NoRes.2 Record label mapping for FEC from MsgSource is needed but
4892	           that no label resources are available.

4894	   NoRes.3 Set status record indicating it is not OK to send label
4895	           requests to MsgSource.

4897	   NoRes.4 DONE.

4899	A.1.10. Receive Notification / No Route

4901	 Summary:

4903	     When an LSR receives a No Route notification from an LDP peer in
4904	     response to a Label Request message, the Label No Route procedure
4905	     in use dictates its response. The LSR either will take no further
4906	     action, or it will defer the label request by starting a timer and
4907	     send another Label Request message to the peer when the timer later
4908	     expires.

4910	 Context:

4912	     - LSR. The LSR handling the event.

4914	     - FEC. The FEC for which a label was requested.

4916	     - Attributes. The attibutes associated with the label request.

4918	     - MsgSource. The LDP peer that sent the Notification message.

4920	 Algorithm:

4922	   NoNH.1  Delete record of outstanding label request for FEC sent to
4923	           MsgSource.

4925	   NoNH.2  Perform LSR Label No Route procedure.

4927	             For Request No Retry

4929	               1.  Goto NoNH.3.

4931	             For Request Retry

4933	               1.  Record deferred label request for FEC and Attributes
4934	                   to be sent to MsgSource.

4936	               2.  Start timeout. Goto NoNH.3.

4938	   NoNH.3  DONE.

4940	A.1.11. Receive Notification / Loop Detected
4941	 Summary:

4943	     When an LSR receives a Loop Detected notification from an LDP peer
4944	     in response to a Label Request message, it behaves as if it had
4945	     received a No Route notification.

4947	     Context:

4949	         See "Receive Notification / No Route".

4951	     Algorithm:

4953	         See "Receive Notification / No Route"

4955	A.1.12. Receive Notification / Label Resources Available

4957	 Summary:

4959	     When an LSR receives a Label Resources Available notification from
4960	     an LDP peer, it resumes sending label requests to the peer.

4962	 Context:

4964	     - LSR. The LSR handling the event.

4966	     - MsgSource. The LDP peer that sent the Notification message.

4968	     - SAttributes. Attributes stored with postponed Label Request
4969	       message.

4971	 Algorithm:

4973	   Res.1   Set status record indicating it is OK to send label requests
4974	           to MsgSource.

4976	   Res.2   Iterate through Res.6 for each record of a FEC label mapping
4977	           needed from MsgSource for which no label resources are
4978	           available.

4980	   Res.3   Is MsgSource the next hop for FEC?
4981	           If not, goto Res.5.

4983	   Res.4   Execute procedure Send_Label_Request (MsgSource, FEC,
4984	           SAttributes).  If the procedure fails, terminate iteration.

4986	   Res.5   Delete record that no resources are available for a label
4987	           mapping for FEC needed from MsgSource.

4989	   Res.6   End iteration from Res.2

4991	   Res.7   DONE.

4993	A.1.13. Detect local label resources have become available

4995	 Summary:

4997	     After an LSR has sent a No Label Resources notification to an LDP
4998	     peer, when label resources later become available it sends a Label
4999	     Resources Available notification to each such peer.

5001	 Context:

5003	     - LSR. The LSR handling the event.

5005	     - Attributes. Attributes stored with postponed Label Mapping
5006	       message.

5008	 Algorithm:

5010	   ResA.1  Iterate through ResA.4 for each Peer to which LSR has
5011	           previously sent a No Label Resources notification.

5013	   ResA.2  Execute procedure Send_Notification (Peer, Label Resources
5014	           Available)

5016	   ResA.3  Delete record that No Label Resources notification was
5017	           previously sent to Peer.

5019	   ResA.4  End iteration from ResA.1

5021	   ResA.5  Iterate through ResA.8 for each record of a label mapping
5022	           needed for FEC for Peer but no-label-resources.  (See Note
5023	           1.)

5025	   ResA.6  Execute procedure Send_Label (Peer, FEC, Attributes). If the
5026	           procedure fails, terminate iteration.

5028	   ResA.7  Clear record of FEC label mapping needed for peer but no-
5029	           label-resources.

5031	   ResA.8  End iteration from ResA.5

5033	   ResA.9  DONE.

5035	 Notes:

5037	      1. Iteration ResA.5 through ResA.8 handles the situation where the
5038	         LSR is using Downstream Unsolicited label distribution and was
5039	         previously unable to allocate a label for a FEC.

5041	A.1.14. LSR decides to no longer label switch a FEC

5043	 Summary:

5045	     An LSR may unilaterally decide to no longer label switch a FEC for
5046	     an LDP peer. An LSR that does so must send a label withdraw message
5047	     for the FEC to the peer.

5049	 Context:

5051	     - Peer. The peer.

5053	     - FEC. The FEC.

5055	     - PrevAdvLabel. The label for FEC previously advertised to Peer.

5057	 Algorithm:

5059	   NoLS.1  Execute procedure Send_Label_Withdraw (Peer, FEC,
5060	           PrevAdvLabel).  (See Note 1.)

5062	   NoLS.2  DONE.

5064	 Notes:

5066	      1. The LSR may remove the label from forwarding/switching use as
5067	         part of this event or as part of processing the label release
5068	         from the peer in response to the label withdraw.

5070	A.1.15. Timeout of deferred label request

5072	 Summary:

5074	     Label requests are deferred in response to No Route and Loop
5075	     Detected notifications.  When a deferred FEC label request for a
5076	     peer times out, the LSR sends the label request.

5078	 Context:

5080	     - LSR. The LSR handling the event.

5082	     - FEC. The FEC associated with the timeout event.

5084	     - Peer. The LDP peer associated with the timeout event.

5086	     - Attributes. Attributes stored with deferred Label Request
5087	       message.

5089	 Algorithm:

5091	   TO.1    Retrieve the record of the deferred label request.

5093	   TO.2    Is Peer the next hop for FEC?
5094	           If not, goto TO.4.

5096	   TO.3    Execute procedure Send_Label_Request (Peer, FEC).

5098	   TO.4    DONE.

5100	A.2. Common Label Distribution Procedures

5102	   This section specifies utility procedures used by the algorithms that
5103	   handle label distribution events.

5105	A.2.1. Send_Label

5107	 Summary:

5109	     The Send_Label procedure allocates a label for a FEC for an LDP
5110	     peer, if possible, and sends a label mapping for the FEC to the
5111	     peer. If the LSR is unable to allocate the label and if it has a
5112	     pending label request from the peer, it sends the LDP peer a No
5113	     Label Resources notification.

5115	 Parameters:

5117	     - Peer. The LDP peer to which the label mapping is to be sent.

5119	     - FEC. The FEC for which a label mapping is to be sent.

5121	     - Attributes. The attributes to be included with the label mapping.

5123	 Additional Context:

5125	     - LSR. The LSR executing the procedure.

5127	     - Label. The label allocated and sent to Peer.

5129	 Algorithm:

5131	    SL.1   Does LSR have a label to allocate?
5132	           If not, goto SL.9.

5134	    SL.2   Allocate Label and bind it to the FEC.

5136	    SL.3   Install Label for forwarding/switchng use.

5138	    SL.4   Execute procedure Send_Message (Peer, Label Mapping, FEC,
5139	           Label, Attributes).

5141	    SL.5   Record label mapping for FEC with Label and Attributes has
5142	           been sent to Peer.

5144	    SL.6   Does LSR have a record of a FEC label request from Peer
5145	           marked as pending?
5146	           If not, goto SL.8.

5148	    SL.7   Delete record of pending label request for FEC from Peer.

5150	    SL.8   Return success.

5152	    SL.9   Does LSR have a label request for FEC from Peer marked as
5153	           pending?
5154	           If not, goto SL.13.

5156	    SL.10  Execute procedure Send_Notification (Peer, No Label
5157	           Resources).

5159	    SL.11  Delete record of pending label request for FEC from Peer.

5161	    SL.12  Record No Label Resources notification has been sent to Peer.
5162	           Goto SL.14.

5164	    SL.13  Record label mapping needed for FEC and Attributes for Peer,
5165	           but no-label-resources. (See Note 1.)

5167	    SL.14  Return failure.

5169	 Notes:

5171	      1. SL.13 handles the case of Downstream Unsolicited label
5172	         distribution when the LSR is unable to allocate a label for a
5173	         FEC to send to a Peer.

5175	A.2.2. Send_Label_Request

5177	 Summary:

5179	     An LSR uses the Send_Label_Request procedure to send a request for
5180	     a label for a FEC to an LDP peer if currently permitted to do so.

5182	 Parameters:

5184	     - Peer. The LDP peer to which the label request is to be sent.

5186	     - FEC. The FEC for which a label request is to be sent.

5188	     - Attributes. Attributes to be included in the label request. E.g.,
5189	       Hop Count, Path Vector.

5191	 Additional Context:

5193	     - LSR. The LSR executing the procedure.

5195	 Algorithm:

5197	   SLRq.1  Has a label request for FEC previously been sent to Peer and
5198	           is it marked as outstanding?
5199	           If so, Return success.  (See Note 1.)

5201	   SLRq.2  Is status record indicating it is OK to send label requests
5202	           to Peer set?
5203	           If not, goto SLRq.6

5205	   SLRq.3  Execute procedure Send_Message (Peer, Label Request, FEC,
5206	           Attributes).

5208	   SLRq.4  Record label request for FEC has been sent to Peer and mark
5209	           it as outstanding.

5211	   SLRq.5  Return success.

5213	   SLRq.6  Postpone the label request by recording label mapping for FEC
5214	           and Attributes from Peer is needed but that no label
5215	           resources are available.

5217	   SLRq.7  Return failure.

5219	 Notes:

5221	      1. If the LSR is a non-merging LSR it must distinguish between
5222	         attempts to send label requests for a FEC triggered by
5223	         different upstream LDP peers from duplicate requests. This
5224	         procedure will not send a duplicate label request.

5226	A.2.3. Send_Label_Withdraw

5228	 Summary:

5230	     An LSR uses the Send_Label_Withdraw procedure to withdraw a label
5231	     for a FEC from an LDP peer. To do this the LSR sends a Label
5232	     Withdraw message to the peer.

5234	 Parameters:

5236	     - Peer. The LDP peer to which the label withdraw is to be sent.

5238	     - FEC. The FEC for which a label is being withdrawn.

5240	     - Label. The label being withdrawn

5242	 Additional Context:

5244	     - LSR. The LSR executing the procedure.

5246	 Algorithm:

5248	    SWd.1  Execute procedure Send_Message (Peer, Label Withdraw, FEC,
5249	           Label)

5251	    SWd.2  Record label withdraw for FEC has been sent to Peer and mark
5252	           it as outstanding.

5254	A.2.4. Send_Notification

5256	 Summary:

5258	     An LSR uses the Send_Notification procedure to send an LDP peer a
5259	     notificaction message.

5261	 Parameters:

5263	     - Peer. The LDP peer to which the Notification message is to be
5264	       sent.

5266	     - Status. Status code to be included in the Notification message.

5268	 Additional Context:

5270	     None.

5272	 Algorithm:

5274	   SNt.1  Execute procedure Send_Message (Peer, Notification, Status)

5276	A.2.5. Send_Message

5278	 Summary:

5280	     An LSR uses the Send_Message procedure to send an LDP peer an LDP
5281	     message.

5283	 Parameters:

5285	     - Peer. The LDP peer to which the message is to be sent.

5287	     - Message Type. The type of message to be sent.

5289	     - Additional message contents . . .  .

5291	 Additional Context:

5293	     None.

5295	 Algorithm:

5297	     This procedure is the means by which an LSR sends an LDP message of
5298	     the specified type to the specified LDP peer.

5300	A.2.6. Check_Received_Attributes
5301	 Summary:

5303	     Check the attributes received in a Label Mapping or Label Request
5304	     message. If the attributes include a Hop Count or Path Vector,
5305	     perform a loop detection check. If a loop is detected, send a Loop
5306	     Detected Notification message to MsgSource.

5308	 Parameters:

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

5312	     - RAttributes. The attributes in the message.

5314	 Additional Context:

5316	     - LSR Id. The unique LSR Id of this LSR.

5318	     - Hop Count. The Hop Count, if any, in the received attributes.

5320	     - Path Vector. The Path Vector, if any in the received attributes.

5322	 Algorithm:

5324	   CRa.1   Do RAttributes include Hop Count?
5325	           If not, goto CRa.5.

5327	   CRa.2   Does Hop Count exceed Max allowable hop count?
5328	           If so, goto CRa.6.

5330	   CRa.3   Do RAttributes include Path Vector?
5331	           If not, goto CRa.5.

5333	   CRa.4   Does Path Vector Include LSR Id? OR
5334	           Does length of Path Vector exceed Max allowable length?
5335	           If so, goto CRa.6

5337	   CRa.5   Return No Loop Detected.

5339	   CRa.6   Execute procedure Send_Notification (MsgSource, Loop
5340	           Detected)

5342	   CRa.7   Return Loop Detected.

5344	   CRa.8   DONE

5346	A.2.7. Prepare_Label_Request_Attributes

5348	 Summary:

5350	     This procedure is used whenever a Label Request is to be sent to a
5351	     Peer to compute the Hop Count and Path Vector, if any, to include
5352	     in the message.

5354	 Parameters:

5356	     - Peer. The LDP peer to which the message is to be sent.

5358	     - FEC. The FEC for which a label request is to be sent.

5360	     - RAttributes. The attributes this LSR associates with the LSP for
5361	       FEC.

5363	     - SAttributes. The attributes to be included in the Label Request
5364	       message.

5366	 Additional Context:

5368	     - LSR Id. The unique LSR Id of this LSR.

5370	 Algorithm:

5372	   PRqA.1  Is Hop Count required for this Peer (see Note 1.) ? OR
5373	           Do RAttributes include a Hop Count? OR
5374	           Is Loop Detection configured on LSR?
5375	           If not, goto PRqA.14.

5377	   PRqA.2  Is LSR ingress for FEC?
5378	           If not, goto PRqA.6.

5380	   PRqA.3  Include Hop Count of 1 in SAttributes.

5382	   PRqA.4  Is Loop Detection configured on LSR?
5383	           If not, goto PRqA.14.

5385	   PRqA.5  Is LSR merge-capable?
5386	           If so, goto PRqA.14.
5387	           If not, goto PRqA.13.

5389	   PRqA.6  Do RAttributes include a Hop Count?
5390	           If not, goto PRqA.8.

5392	   PRqA.7  Increment RAttributes Hop Count and copy the resulting Hop
5393	           Count to SAttributes. (See Note 2.)
5394	           Goto PRqA.9.

5396	   PRqA.8  Include Hop Count of unknown (0) in SAttributes.

5398	   PRqA.9  Is Loop Detection configured on LSR?
5399	           If not, goto PRqA.14.

5401	   PRqA.10 Do RAttributes have a Path Vector?
5402	           If so, goto PRqA.12.

5404	   PRqA.11 Is LSR merge-capable?
5405	           If so, goto PRqA.14.
5406	           If not, goto PRqA.13.

5408	   PRqA.12 Add LSR Id to beginning of Path Vector from RAttributes and
5409	           copy the resulting Path Vector into SAttributes.
5410	           Goto PRqA.14.

5412	   PRqA.13 Include Path Vector of length 1 containing LSR Id in
5413	           SAttributes.

5415	   PRqA.14 DONE.

5417	 Notes:

5419	      1. The link with Peer may require that Hop Count be included in
5420	         Label Request messages; for example, see [ATM] and [FR].

5422	      2. For hop count arithmetic, unknown + 1 = unknown.

5424	A.2.8. Prepare_Label_Mapping_Attributes

5426	 Summary:

5428	     This procedure is used whenever a Label Mapping is to be sent to a
5429	     Peer to compute the Hop Count and Path Vector, if any, to include
5430	     in the message.

5432	 Parameters:

5434	     - Peer. The LDP peer to which the message is to be sent.

5436	     - FEC. The FEC for which a label request is to be sent.

5438	     - RAttributes. The attributes this LSR associates with the LSP for
5439	       FEC.

5441	     - SAttributes. The attributes to be included in the Label Mapping
5442	       message.

5444	     - IsPropagating. The LSR is sending the Label Mapping message to
5445	       propagate one received from the FEC next hop.

5447	     - PrevHopCount. The Hop Count, if any, this LSR associates with the
5448	       LSP for the FEC.

5450	 Additional Context:

5452	     - LSR Id. The unique LSR Id of this LSR.

5454	 Algorithm:

5456	   PMpA.1  Is Hop Count required for this Peer (see Note 1.) ? OR
5457	           Do RAttributes include a Hop Count? OR
5458	           Is Loop Detection configured on LSR?
5459	           If not, goto PMpA.21.

5461	   PMpA.2  Is LSR egress for FEC?
5462	           If not, goto PMpA.4.

5464	   PMpA.3  Include Hop Count of 1 in SAttributes. Goto PMpA.21.

5466	   PMpA.4  Do RAttributes have a Hop Count?
5467	           If not, goto PMpA.8.

5469	   PMpA.5  Is LSR member of edge set for an LSR domain whose LSRs do not
5470	           perform TTL decrement AND
5471	           Is Peer in that domain (See Note 2.).
5472	           If not, goto PMpA.7.

5474	   PMpA.6  Include Hop Count of 1 in SAttributes. Goto PMpA.9.

5476	   PMpA.7  Increment RAttributes Hop Count and copy the resulting Hop
5477	           Count to SAttributes. See Note 2. Goto PMpA.9.

5479	   PMpA.8  Include Hop Count of unknown (0) in SAttributes.

5481	   PMpA.9  Is Loop Detection configured on LSR?
5482	           If not, goto PMpA.21.

5484	   PMpA.10 Do RAttributes have a Path Vector?
5485	           If so, goto PMpA.19.

5487	   PMpA.11 Is LSR propagating a received Label Mapping?
5488	           If not, goto PMpA.20.

5490	   PMpA.12 Does LSR support merging?
5491	           If not, goto PMpA.14.

5493	   PMpA.13 Has LSR previously sent a Label Mapping for FEC to Peer?
5494	           If not, goto PMpA.20.

5496	   PMpA.14 Do RAttributes include a Hop Count?
5497	           If not, goto PMpA.21.

5499	   Res.15 Is Hop Count in Rattributes unknown(0)?
5500	           If so, goto PMpA.20.

5502	   PMpA.16 Has LSR previously sent a Label Mapping for FEC to Peer?
5503	           If not goto PMpA.21.

5505	   PMpA.17 Is Hop Count in RAttributes different from PrevHopCount ?
5506	           If not goto PMpA.21.

5508	   PMpA.18 Is the Hop Count in RAttributes > PrevHopCount? OR
5509	           Is PrevHopCount unknown(0)
5510	           If not, goto PMpA.21.

5512	   PMpA.19 Add LSR Id to beginning of Path Vector from RAttributes and
5513	           copy the resulting Path Vector into SAttributes. Goto
5514	           PMpA.21.

5516	   PMpA.20 Include Path Vector of length 1 containing LSR Id in
5517	           SAttributes.

5519	   PMpA.21 DONE.

5521	 Notes:

5523	      1. The link with Peer may require that Hop Count be included in
5524	         Label Mapping messages; for example, see [ATM] and [FR].

5526	      2. If the LSR is at the edge of a cloud of LSRs that do not
5527	         perform TTL-decrement and it is propagating the Label Mapping
5528	         message upstream into the cloud, it sets the Hop Count to 1 so
5529	         that Hop Count across the cloud is calculated properly.  This
5530	         ensures proper TTL management for packets forwarded across the
5531	         part of the LSP that passes through the cloud.

5533	      3. For hop count arithmetic, unknown + 1 = unknown.