idnits 2.17.1 

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

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

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


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

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


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

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

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

  ** The abstract seems to contain references ([ARCH], [FRAMEWORK],
     [LDPAPPLIC]), 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 -- however, there's a paragraph with a matching beginning.
     Boilerplate error?

     RFC 2119 keyword, line 936: '...   LSR MUST wait until a label from a ...'
     RFC 2119 keyword, line 1088: '... Request message MUST include a Hop Co...'
     RFC 2119 keyword, line 1091: '...     MUST include a Hop Count TLV with...'
     RFC 2119 keyword, line 1095: '...Hop Count TLV, R MUST increment the re...'
     RFC 2119 keyword, line 1096: '...t value by 1 and MUST pass the resulti...'
     (26 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 2000) is 8713 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 1273, but not defined

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

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

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

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

  == Unused Reference: 'LSPTUN' is defined on line 4086, 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'

  ** Obsolete normative reference: RFC 2434 (ref. 'IANA') (Obsoleted by RFC
     5226)

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

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

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


     Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 13 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 2000
4	                                                             Paul Doolan
5	                                                       Ennovate Networks

7	                                                           Nancy Feldman
8	                                                                IBM Corp

10	                                                          Andre Fredette
11	                                                    Nortel Networks Inc.

13	                                                              Bob Thomas
14	                                                     Cisco Systems, Inc.

16	                                                               June 2000

18	                           LDP Specification

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

22	Status of this Memo

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

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

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

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

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

43	Abstract

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

56	Table of Contents

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

182	    Appendix.A LDP Label Distribution Procedures  ..................  96
183	    A.1        Handling Label Distribution Events  .................  98
184	    A.1.1      Receive Label Request  ..............................  99
185	    A.1.2      Receive Label Mapping  .............................. 102
186	    A.1.3      Receive Label Abort Request  ........................ 108
187	    A.1.4      Receive Label Release  .............................. 110
188	    A.1.5      Receive Label Withdraw  ............................. 112
189	    A.1.6      Recognize New FEC  .................................. 113
190	    A.1.7      Detect Change in FEC Next Hop  ...................... 116
191	    A.1.8      Receive Notification / Label Request Aborted  ....... 119
192	    A.1.9      Receive Notification / No Label Resources  .......... 119
193	    A.1.10     Receive Notification / No Route  .................... 120
194	    A.1.11     Receive Notification / Loop Detected  ............... 121
195	    A.1.12     Receive Notification / Label Resources Available  ... 122
196	    A.1.13     Detect local label resources have become available  . 122
197	    A.1.14     LSR decides to no longer label switch a FEC  ........ 123
198	    A.1.15     Timeout of deferred label request  .................. 124
199	    A.2        Common Label Distribution Procedures  ............... 125
200	    A.2.1      Send_Label  ......................................... 125
201	    A.2.2      Send_Label_Request  ................................. 126
202	    A.2.3      Send_Label_Withdraw  ................................ 128
203	    A.2.4      Send_Notification  .................................. 128
204	    A.2.5      Send_Message  ....................................... 129
205	    A.2.6      Check_Received_Attributes  .......................... 129
206	    A.2.7      Prepare_Label_Request_Attributes  ................... 131
207	    A.2.8      Prepare_Label_Mapping_Attributes  ................... 132

209	1. LDP Overview

211	   The MPLS architecture [ARCH] defines a label distribution protocol as
212	   a set of procedures by which one Label Switched Router (LSR) informs
213	   another of the meaning of labels used to forward traffic between and
214	   through them.

216	   The MPLS architecture does not assume a single label distribution
217	   protocol.  In fact, a number of different label distribution
218	   protocols are being standardized.  Existing protocols have been
219	   extended so that label distribution can be piggybacked on them.  New
220	   protocols have also been defined for the explicit purpose of
221	   distributing labels.  The MPLS architecture discusses some of the
222	   considerations when choosing a label distribution protocol for use in
223	   particular MPLS applications such as Traffic Engineering [TE].

225	   The Label Distribution Protocol (LDP) defined in this document is a
226	   new protocol defined for distributing labels.  It is the set of
227	   procedures and messages by which Label Switched Routers (LSRs)
228	   establish Label Switched Paths (LSPs) through a network by mapping
229	   network-layer routing information directly to data-link layer
230	   switched paths.  These LSPs may have an endpoint at a directly
231	   attached neighbor (comparable to IP hop-by-hop forwarding), or may
232	   have an endpoint at a network egress node, enabling switching via all
233	   intermediary nodes.

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

241	   More information about the applicability of LDP can be found in
242	   [LDPAPPLIC].

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

248	1.1. LDP Peers

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

256	1.2. LDP Message Exchange

258	   There are four categories of LDP messages:

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

263	      2. Session messages, used to establish, maintain, and terminate
264	         sessions between LDP peers.

266	      3. Advertisement messages, used to create, change, and delete
267	         label mappings for FECs.

269	      4. Notification messages, used to provide advisory information and
270	         to signal error information.

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

281	   When to request a label or advertise a label mapping to a peer is
282	   largely a local decision made by an LSR.  In general, the LSR
283	   requests a label mapping from a neighboring LSR when it needs one,
284	   and advertises a label mapping to a neighboring LSR when it wishes
285	   the neighbor to use a label.

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

292	1.3. LDP Message Structure

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

299	1.4. LDP Error Handling

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

304	   There are two kinds of LDP notification messages:

306	      1. Error notifications, used to signal fatal errors.  If an LSR
307	         receives an error notification from a peer for an LDP session,
308	         it terminates the LDP session by closing the TCP transport
309	         connection for the session and discarding all label mappings
310	         learned via the session.

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

316	1.5. LDP Extensibility and Future Compatibility

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

327	1.6. Specification Language

329	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
330	   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
331	   document are to be interpreted as described in [rfc2119].

333	2. LDP Operation

335	2.1. FECs

337	   It is necessary to precisely specify which packets may be mapped to
338	   each LSP.  This is done by providing a FEC specification for each
339	   LSP.  The FEC identifies the set of IP packets which may be mapped to
340	   that LSP.

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

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

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

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

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

360	   We say that a particular address "matches" a particular address
361	   prefix if and only if that address begins with that prefix.  We also
362	   say that a particular packet matches a particular LSP if and only if
363	   that LSP has an Address Prefix FEC element which matches the packet's
364	   destination address.  With respect to a particular packet and a
365	   particular LSP, we refer to any Address Prefix FEC element which
366	   matches the packet as the "matching prefix".

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

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

376	     - If there are multiple LSPs, each containing a Host Address FEC
377	       element that is identical to the packet's destination address,
378	       then the packet is mapped to one of those LSPs.  The procedure
379	       for selecting one of those LSPs is beyond the scope of this
380	       document.

382	     - If a packet matches exactly one LSP, the packet is mapped to that
383	       LSP.

385	     - If a packet matches multiple LSPs, it is mapped to the LSP whose
386	       matching prefix is the longest.  If there is no one LSP whose
387	       matching prefix is longest, the packet is mapped to one from the
388	       set of LSPs whose matching prefix is longer than the others.  The
389	       procedure for selecting one of those LSPs is beyond the scope of
390	       this document.

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

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

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

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

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

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

420	2.2. Label Spaces, Identifiers, Sessions and Transport

422	2.2.1. Label Spaces

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

427	     - Per interface label space.  Interface-specific incoming labels
428	       are used for interfaces that use interface resources for labels.
429	       An example of such an interface is a label-controlled ATM
430	       interface that uses VCIs as labels, or a Frame Relay interface
431	       that uses DLCIs as labels.

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

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

441	2.2.2. LDP Identifiers

443	   An LDP identifier is a six octet quantity used to identify an LSR
444	   label space.  The first four octets identify the LSR and must be a
445	   globally unique value, such as a 32-bit router Id assigned to the
446	   LSR.  The last two octets identify a specific label space within the
447	   LSR.  The last two octets of LDP Identifiers for platform-wide label
448	   spaces are always both zero.  This document uses the following print
449	   representation for LDP Identifiers:

451	              <LSR Id> : <label space id>

453	   e.g., lsr171:0, lsr19:2.

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

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

465	2.2.3. LDP Sessions

467	   LDP sessions exist between LSRs to support label exchange between
468	   them.

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

473	2.2.4. LDP Transport

475	   LDP uses TCP as a reliable transport for sessions.

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

480	2.3. LDP Sessions between non-Directly Connected LSRs

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

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

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

495	   In this situation LSRa would apply two labels to traffic it forwards
496	   on the LSP to LSRb: a label learned from LSR1 to forward traffic
497	   along the LSP path from LSRa to LSRb; and a label learned from LSRb
498	   to enable LSRb to label switch traffic arriving on the LSP.

500	   LSRa first adds the label learned via its LDP session with LSRb to
501	   the packet label stack (either by replacing the label on top of the
502	   packet label stack with it if the packet arrives labeled or by
503	   pushing it if the packet arrives unlabeled).  Next, it pushes the
504	   label for the LSP learned from LSR1 onto the label stack.

506	2.4. LDP Discovery

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

512	   There are two variants of the discovery mechanism:

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

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

520	2.4.1. Basic Discovery Mechanism

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

527	   An LDP Link Hello sent by an LSR carries the LDP Identifier for the
528	   label space the LSR intends to use for the interface and possibly
529	   additional information.

531	   Receipt of an LDP Link Hello on an interface identifies a "Hello
532	   adjacency" with a potential LDP peer reachable at the link level on
533	   the interface as well as the label space the peer intends to use for
534	   the interface.

536	2.4.2. Extended Discovery Mechanism

538	   LDP sessions between non-directly connected LSRs are supported by LDP
539	   Extended Discovery.

541	   To engage in LDP Extended Discovery an LSR periodically sends LDP
542	   Targeted Hellos to a specific address.  LDP Targeted Hellos are sent
543	   as UDP packets addressed to the well-known LDP discovery port at the
544	   specific address.

546	   An LDP Targeted Hello sent by an LSR carries the LDP Identifier for
547	   the label space the LSR intends to use and possibly additional
548	   optional information.

550	   Extended Discovery differs from Basic Discovery in the following
551	   ways:

553	     - A Targeted Hello is sent to a specific address rather than to the
554	       "all routers" group multicast address for the outgoing interface.

556	     - Unlike Basic Discovery, which is symmetric, Extended Discovery is
557	       asymmetric.

559	       One LSR initiates Extended Discovery with another targeted LSR,
560	       and the targeted LSR decides whether to respond to or ignore the
561	       Targeted Hello.  A targeted LSR that chooses to respond does so
562	       by periodically sending Targeted Hellos to the initiating LSR.

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

568	2.5. Establishing and Maintaining LDP Sessions

570	2.5.1. LDP Session Establishment

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

575	           - Transport connection establishment.
576	           - Session initialization

578	   The following describes establishment of an LDP session between LSRs
579	   LSR1 and LSR2 from LSR1's point of view.  It assumes the exchange of
580	   Hellos specifying label space LSR1:a for LSR1 and label space LSR2:b
581	   for LSR2.

583	2.5.2. Transport Connection Establishment

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

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

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

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

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

604	         Similarly, address A2 is determined as follows:

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

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

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

617	         The procedure for comparing A1 and A2 as unsigned integers is:

619	           - If A1 and A2 are not in the same address family, they are
620	             incomparable, and no session can be established.

622	           - Let U1 be the abstract unsigned integer obtained by
623	             treating A1 as a sequence of bytes, where the byte which
624	             appears earliest in the message is the most significant
625	             byte of the integer and the byte which appears latest in
626	             the message is the least significant byte of the integer.

628	             Let U2 be the abstract unsigned integer obtained from A2 in
629	             a similar manner.

631	           - Compare U1 with U2.  If U1 > U2, then A1 > A2; if U1 < U2,
632	             then A1 < A2.

634	     3.  If LSR1 is active, it attempts to establish the LDP TCP
635	         connection by connecting to the well-known LDP port at address
636	         A2.  If LSR1 is passive, it waits for LSR2 to establish the LDP
637	         TCP connection to its well-known LDP port.

639	2.5.3. Session Initialization

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

647	   Successful negotiation completes establishment of an LDP session
648	   between LSR1 and LSR2 for the advertisement of label spaces LSR1:a
649	   and LSR2:b.

651	   The following describes the session initialization from LSR1's point
652	   of view.

654	   After the connection is established, if LSR1 is playing the active
655	   role, it initiates negotiation of session parameters by sending an
656	   Initialization message to LSR2.  If LSR1 is passive, it waits for
657	   LSR2 to initiate the parameter negotiation.

659	   In general when there are multiple links between LSR1 and LSR2 and
660	   multiple label spaces to be advertised by each, the passive LSR
661	   cannot know which label space to advertise over a newly established
662	   TCP connection until it receives the LDP Initialization message on
663	   the connection.  The Initialization message carries both the LDP
664	   Identifier for the sender's (active LSR's) label space and the LDP
665	   Identifier for the receiver's (passive LSR's) label space.

667	   By waiting for the Initialization message from its peer the passive
668	   LSR can match the label space to be advertised by the peer (as
669	   determined from the LDP Identifier in the PDU header for the
670	   Initialization message) with a Hello adjacency previously created
671	   when Hellos were exchanged.

673	     1.  When LSR1 plays the passive role:

675	         a.  If LSR1 receives an Initialization message it attempts to
676	             match the LDP Identifier carried by the message PDU with a
677	             Hello adjacency.

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

682	             Next LSR1 checks whether the session parameters proposed in
683	             the message are acceptable.  If they are, LSR1 replies with
684	             an Initialization message of its own to propose the
685	             parameters it wishes to use and a KeepAlive message to
686	             signal acceptance of LSR2's parameters.  If the parameters
687	             are not acceptable, LSR1 responds by sending a Session
688	             Rejected/Parameters Error Notification message and closing
689	             the TCP connection.

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

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

699	         e.  If LSR1 receives an Error Notification message, LSR2 has
700	             rejected its proposed session and LSR1 closes the TCP
701	             connection.

703	     2.  When LSR1 plays the active role:

705	         a.  If LSR1 receives an Error Notification message, LSR2 has
706	             rejected its proposed session and LSR1 closes the TCP
707	             connection.

709	         b.  If LSR1 receives an Initialization message, it checks
710	             whether the session parameters are acceptable.  If so, it
711	             replies with a KeepAlive message.  If the session
712	             parameters are unacceptable, LSR1 sends a Session
713	             Rejected/Parameters Error Notification message and closes
714	             the connection.

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

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

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

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

733	       The session establishment setup attempt following a NAK'd
734	       Initialization message must be delayed no less than 15 seconds,
735	       and subsequent delays must grow to a maximum delay of no less
736	       than 2 minutes.  The specific session establishment action that
737	       must be delayed is the attempt to open the session transport
738	       connection by the LSR playing the active role.

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

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

752	2.5.4. Initialization State Machine

754	   It is convenient to describe LDP session negotiation behavior in
755	   terms of a state machine.  We define the LDP state machine to have
756	   five possible states and present the behavior as a state transition
757	   table and as a state transition diagram.

759	               Session Initialization State Transition Table

761	         STATE         EVENT                               NEW STATE

763	         NON EXISTENT  Session TCP connection established  INITIALIZED
764	                       established

766	         INITIALIZED   Transmit Initialization msg         OPENSENT
767	                             (Active Role)

769	                       Receive acceptable                  OPENREC
770	                             Initialization msg
771	                             (Passive Role )
772	                         Action: Transmit Initialization
773	                                 msg and KeepAlive msg

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

779	         OPENREC       Receive KeepAlive msg               OPERATIONAL

781	                       Receive Any other LDP msg           NON EXISTENT
782	                         Action: Transmit Error Notification msg
783	                                 (NAK) and close transport connection

785	         OPENSENT      Receive acceptable                  OPENREC
786	                             Initialization msg
787	                         Action: Transmit KeepAlive msg

789	                       Receive Any other LDP msg           NON EXISTENT
790	                         Action: Transmit Error Notification msg
791	                                 (NAK) and close transport connection

793	         OPERATIONAL   Receive Shutdown msg                NON EXISTENT
794	                         Action: Transmit Shutdown msg and
795	                                 close transport connection

797	                       Receive other LDP msgs              OPERATIONAL

799	                       Timeout                             NON EXISTENT
800	                         Action: Transmit Shutdown msg and
801	                                 close transport connection

803	              Session Initialization State Transition Diagram

805	                                    +------------+
806	                                    |            |
807	                      +------------>|NON EXISTENT|<--------------------+
808	                      |             |            |                     |
809	                      |             +------------+                     |
810	                      | Session        |    ^                          |
811	                      |   connection   |    |                          |
812	                      |   established  |    | Rx any LDP msg except    |
813	                      |                V    |   Init msg or Timeout    |
814	                      |            +-----------+                       |
815	         Rx Any other |            |           |                       |
816	            msg or    |            |INITIALIZED|                       |
817	            Timeout / |        +---|           |-+                     |
818	         Tx NAK msg   |        |   +-----------+ |                     |
819	                      |        | (Passive Role)  | (Active Role)       |
820	                      |        | Rx Acceptable   | Tx Init msg         |
821	                      |        |    Init msg /   |                     |
822	                      |        | Tx Init msg     |                     |
823	                      |        |    Tx KeepAlive |                     |
824	                      |        V    msg          V                     |
825	                      |   +-------+        +--------+                  |
826	                      |   |       |        |        |                  |
827	                      +---|OPENREC|        |OPENSENT|----------------->|
828	                      +---|       |        |        | Rx Any other msg |
829	                      |   +-------+        +--------+    or Timeout    |
830	         Rx KeepAlive |        ^                |     Tx NAK msg       |
831	            msg       |        |                |                      |
832	                      |        |                | Rx Acceptable        |
833	                      |        |                |    Init msg /        |
834	                      |        +----------------+ Tx KeepAlive msg     |
835	                      |                                                |
836	                      |      +-----------+                             |
837	                      +----->|           |                             |
838	                             |OPERATIONAL|                             |
839	                             |           |---------------------------->+
840	                             +-----------+     Rx Shutdown msg
841	                      All other  |   ^            or Timeout /
842	                        LDP msgs |   |         Tx Shutdown msg
843	                                 |   |
844	                                 +---+

846	2.5.5. Maintaining Hello Adjacencies

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

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

856	   LDP includes mechanisms to monitor the necessity of an LDP session
857	   and its Hello adjacencies.

859	   LDP uses the regular receipt of LDP Discovery Hellos to indicate a
860	   peer's intent to use the label space identified by the Hello.  An LSR
861	   maintains a hold timer with each Hello adjacency which it restarts
862	   when it receives a Hello that matches the adjacency.  If the timer
863	   expires without receipt of a matching Hello from the peer, LDP
864	   concludes that the peer no longer wishes to label switch using that
865	   label space for that link (or target, in the case of Targeted Hellos)
866	   or that the peer has failed.  The LSR then deletes the Hello
867	   adjacency.  When the last Hello adjacency for a LDP session is
868	   deleted, the LSR terminates the LDP session by sending a Notification
869	   message and closing the transport connection.

871	2.5.6. Maintaining LDP Sessions

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

875	   LDP uses the regular receipt of LDP PDUs on the session transport
876	   connection to monitor the integrity of the session.  An LSR maintains
877	   a KeepAlive timer for each peer session which it resets whenever it
878	   receives an LDP PDU from the session peer.  If the KeepAlive timer
879	   expires without receipt of an LDP PDU from the peer the LSR concludes
880	   that the transport connection is bad or that the peer has failed, and
881	   it terminates the LDP session by closing the transport connection.

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

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

894	2.6. Label Distribution and Management

896	   The MPLS architecture [ARCH] allows an LSR to distribute a FEC label
897	   binding in response to an explicit request from another LSR.  This is
898	   known as Downstream On Demand label distribution.  It also allows an
899	   LSR to distribute label bindings to LSRs that have not explicitly
900	   requested them.  [ARCH] calls this method of label distribution
901	   Unsolicited Downstream; this document uses the term Downstream
902	   Unsolicited.

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

911	2.6.1. Label Distribution Control Mode

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

917	2.6.1.1. Independent Label Distribution Control

919	   When using independent LSP control, each LSR may advertise label
920	   mappings to its neighbors at any time it desires.  For example, when
921	   operating in independent Downstream on Demand mode, an LSR may answer
922	   requests for label mappings immediately, without waiting for a label
923	   mapping from the next hop.  When operating in independent Downstream
924	   Unsolicited mode, an LSR may advertise a label mapping for a FEC to
925	   its neighbors whenever it is prepared to label-switch that FEC.

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

930	2.6.1.2. Ordered Label Distribution Control

932	   When using LSP ordered control, an LSR may initiate the transmission
933	   of a label mapping only for a FEC for which it has a label mapping
934	   for the FEC next hop, or for which the LSR is the egress. For each
935	   FEC for which the LSR is not the egress and no mapping exists, the
936	   LSR MUST wait until a label from a downstream LSR is received before
937	   mapping the FEC and passing corresponding labels to upstream LSRs.

939	   An LSR may be an egress for some FECs and a non-egress for others.
940	   An LSR may act as an egress LSR, with respect to a particular FEC,
941	   under any of the following conditions:

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

946	      2. The next hop router for the FEC is outside of the Label
947	         Switching Network.

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

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

958	2.6.2. Label Retention Mode

960	   The MPLS architecture [ARCH] introduces the notion of label retention
961	   mode which specifies whether an LSR maintains a label binding for a
962	   FEC learned from a neighbor that is not its next hop for the FEC.

964	2.6.2.1. Conservative Label Retention Mode

966	   In Downstream Unsolicited advertisement mode, label mapping
967	   advertisements for all routes may be received from all peer LSRs.
968	   When using conservative label retention, advertised label mappings
969	   are retained only if they will be used to forward packets (i.e., if
970	   they are received from a valid next hop according to routing).  If
971	   operating in Downstream on Demand mode, an LSR will request label
972	   mappings only from the next hop LSR according to routing. Since
973	   Downstream on Demand mode is primarily used when label conservation
974	   is desired (e.g., an ATM switch with limited cross connect space), it
975	   is typically used with the conservative label retention mode.

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

985	2.6.2.2. Liberal Label Retention Mode

987	   In Downstream Unsolicited advertisement mode, label mapping
988	   advertisements for all routes may be received from all LDP peers.
989	   When using liberal label retention, every label mappings received
990	   from a peer LSR is retained regardless of whether the LSR is the next
991	   hop for the advertised mapping.  When operating in Downstream on
992	   Demand mode with liberal label retention, an LSR might choose to
993	   request label mappings for all known prefixes from all peer LSRs.
994	   Note, however, that Downstream on Demand mode is typically used by
995	   devices such as ATM switch-based LSRs for which the conservative
996	   approach is recommended.

998	   The main advantage of the liberal label retention mode is that
999	   reaction to routing changes can be quick because labels already
1000	   exist.  The main disadvantage of the liberal mode is that unneeded
1001	   label mappings are distributed and maintained.

1003	2.6.3. Label Advertisement Mode

1005	   Each interface on an LSR is configured to operate in either
1006	   Downstream Unsolicited or Downstream on Demand advertisement mode.
1007	   LSRs exchange advertisement modes during initialization.  The major
1008	   difference between Downstream Unsolicited and Downstream on Demand
1009	   modes is in which LSR takes responsibility for initiating mapping
1010	   requests and mapping advertisements.

1012	2.7. LDP Identifiers and Next Hop Addresses

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

1020	   When the next hop for a prefix changes the LSR must retrieve the
1021	   label advertised by the new next hop from the LIB for use in
1022	   forwarding.  To retrieve the label the LSR must be able to map the
1023	   next hop address for the prefix to an LDP Identifier.

1025	   Similarly, when the LSR learns a label for a prefix from an LDP peer,
1026	   it must be able to determine whether that peer is currently a next
1027	   hop for the prefix to determine whether it needs to start using the
1028	   newly learned label when forwarding packets that match the prefix.
1029	   To make that decision the LSR must be able to map an LDP Identifier
1030	   to the peer's addresses to check whether any are a next hop for the
1031	   prefix.

1033	   To enable LSRs to map between a peer LDP identifier and the peer's
1034	   addresses, LSRs advertise their addresses using LDP Address and
1035	   Withdraw Address messages.

1037	   An LSR sends an Address message to advertise its addresses to a peer.
1038	   An LSR sends a Withdraw Address message to withdraw previously
1039	   advertised addresses from a peer

1041	2.8. Loop Detection

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

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

1051	     - A Path Vector TLV contains a list of the LSRs that its containing
1052	       message has traversed.  An LSR is identified in a Path Vector
1053	       list by its unique LSR Identifier (Id), which is the first four
1054	       octets of its LDP Identifier.  When an LSR propagates a message
1055	       containing a Path Vector TLV it adds its LSR Id to the Path
1056	       Vector list.  An LSR that receives a message with a Path Vector
1057	       that contains its LSR Id detects that the message has traversed a
1058	       loop.  LDP supports the notion of a maximum allowable Path Vector
1059	       length; an LSR that detects a Path Vector has reached the maximum
1060	       length behaves as if the containing message has traversed a loop.

1062	     - A Hop Count TLV contains a count of the LSRS that the containing
1063	       message has traversed.  When an LSR propagates a message
1064	       containing a Hop Count TLV it increments the count.  An LSR that
1065	       detects a Hop Count has reached a configured maximum value
1066	       behaves as if the containing message has traversed a loop.  By
1067	       convention a count of 0 is interpreted to mean the hop count is
1068	       unknown.  Incrementing an unknown hop count value results in an
1069	       unknown hop count value (0).

1071	   The following paragraphs describes LDP loop detection procedures.
1072	   For these paragraphs, and only these paragraphs, "MUST" is redfined
1073	   to mean "MUST if configured for loop detection".  The paragraphs
1074	   specify messages that must carry Path Vector and Hop Count TLVs.
1075	   Note that the Hop Count TLV and its procedures are used without the
1076	   Path Vector TLV in situations when loop detection is not configured
1077	   (see [ATM] and [FR]).

1079	2.8.1. Label Request Message

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

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

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

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

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

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

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

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

1110	         R MUST add its own LSR Id to the Path Vector, and MUST pass the
1111	         resulting Path Vector to its next hop along with the Label
1112	         Request message.  If the Label Request contains no Path Vector
1113	         TLV, R MUST include a Path Vector TLV of length 1 containing
1114	         its own LSR Id.

1116	   Note that if R receives a Label Request message for a particular FEC,
1117	   and R has previously sent a Label Request message for that FEC to its
1118	   next hop and has not yet received a reply, and if R intends to merge
1119	   the newly received Label Request with the existing outstanding Label
1120	   Request, then R does not propagate the Label Request to the next hop.

1122	   If R receives a Label Request message from its next hop with a Hop
1123	   Count TLV which exceeds the configured maximum value, or with a Path
1124	   Vector TLV containing its own LSR Id or which exceeds the maximum
1125	   allowable length, then R detects that the Label Request message has
1126	   traveled in a loop.

1128	   When R detects a loop, it MUST send a Loop Detected Notification
1129	   message to the source of the Label Request message and drop the Label
1130	   Request message.

1132	2.8.2. Label Mapping Message

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

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

1144	   - R MUST include a Hop Count TLV.

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

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

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

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

1160	   - If the Label Mapping message is not being sent to propagate a Label
1161	     Mapping message, the hop count value MUST be the result of
1162	     incrementing R's current knowledge of the hop count learned from
1163	     previous Label Mapping messages.  Note that this hop count value
1164	     will be unknown if R has not received a Label Mapping message from
1165	     the next hop.

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

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

1175	   - If R is sending the Label Mapping message to propagate a Label
1176	     Mapping message received from the next hop to an upstream peer,
1177	     then:

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

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

1186	       o If R has previously sent a Label Mapping message to the
1187	         upstream peer, then it MUST include a Path Vector TLV if the
1188	         received message reports an LSP hop count increase, a change in
1189	         hop count from unknown to known, or a change from known to
1190	         unknown.

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

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

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

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

1207	   If R receives a Label Mapping message from its next hop with a Hop
1208	   Count TLV which exceeds the configured maximum value, or with a Path
1209	   Vector TLV containing its own LSR Id or which exceeds the maximum
1210	   allowable length, then R detects that the corresponding LSP contains
1211	   a loop.

1213	   When R detects a loop, it MUST stop using the label for forwarding,
1214	   drop the Label Mapping message, and signal Loop Detected status to
1215	   the source of the Label Mapping message.

1217	2.8.3. Discussion

1219	   If loop detection is desired in an MPLS domain, then it should be
1220	   turned on in ALL LSRs within that MPLS domain, else loop detection
1221	   will not operate properly and may result in undetected loops or in
1222	   falsely detected loops.

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

1227	   Note that in a network where only non-merge capable LSRs are present,
1228	   Path Vectors are passed downstream from ingress to egress, and are
1229	   not passed upstream.  Even when merge is supported, Path Vectors need
1230	   not be passed upstream along an LSP which is known to reach the
1231	   egress.  When an LSR experiences a change of next hop, it need pass
1232	   Path Vectors upstream only when it cannot tell from the hop count
1233	   that the change of next hop does not result in a loop.

1235	   In the case of ordered label distribution, Label Mapping messages are
1236	   propagated from egress toward ingress, naturally creating the Path
1237	   Vector along the way.  In the case of independent label distribution,
1238	   an LSR may originate a Label Mapping message for an FEC before
1239	   receiving a Label Mapping message from its downstream peer for that
1240	   FEC.  In this case, the subsequent Label Mapping message for the FEC
1241	   received from the downstream peer is treated as an update to LSP
1242	   attributes, and the Label Mapping message must be propagated
1243	   upstream.  Thus, it is recommended that loop detection be configured
1244	   in conjunction with ordered label distribution, to minimize the
1245	   number of Label Mapping update messages.

1247	2.9. Authenticity and Integrity of LDP Messages

1249	   This section specifies a mechanism to protect against the
1250	   introduction of spoofed TCP segments into LDP session connection
1251	   streams.  The use of this mechanism MUST be supported as a
1252	   configurable option.

1254	   The mechanism is based on use of the TCP MD5 Signature Option
1255	   specified in [rfc2385] for use by BGP.  See [rfc1321] for a
1256	   specification of the MD5 hash function.

1258	2.9.1. TCP MD5 Signature Option

1260	   The following quotes from [rfc2385] outline the security properties
1261	   achieved by using the TCP MD5 Signature Option and summarizes its
1262	   operation:

1264	      "IESG Note

1266	         This document describes current existing practice for securing
1267	         BGP against certain simple attacks.  It is understood to have
1268	         security weaknesses against concerted attacks."

1270	      "Abstract

1272	         This memo describes a TCP extension to enhance security for
1273	         BGP.  It defines a new TCP option for carrying an MD5 [RFC1321]
1274	         digest in a TCP segment.  This digest acts like a signature for
1275	         that segment, incorporating information known only to the
1276	         connection end points.  Since BGP uses TCP as its transport,
1277	         using this option in the way described in this paper
1278	         significantly reduces the danger from certain security attacks
1279	         on BGP."

1281	      "Introduction

1283	         The primary motivation for this option is to allow BGP to
1284	         protect itself against the introduction of spoofed TCP segments
1285	         into the connection stream.  Of particular concern are TCP
1286	         resets.

1288	         To spoof a connection using the scheme described in this paper,
1289	         an attacker would not only have to guess TCP sequence numbers,
1290	         but would also have had to obtain the password included in the
1291	         MD5 digest.  This password never appears in the connection
1292	         stream, and the actual form of the password is up to the
1293	         application.  It could even change during the lifetime of a
1294	         particular connection so long as this change was synchronized
1295	         on both ends (although retransmission can become problematical
1296	         in some TCP implementations with changing passwords).

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

1302	      "MD5 as a Hashing Algorithm

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

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

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

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

1327	   End of quotes from [rfc2385].

1329	2.9.2. LDP Use of TCP MD5 Signature Option

1331	   LDP uses the TCP MD5 Signature Option as follows:

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

1336	     - An LSR that uses the MD5 Signature Option is configured with a
1337	       password (shared secret) for each potential LDP peer.

1339	     - The LSR applies the MD5 algorithm as specified in [RFC2385] to
1340	       compute the MD5 digest for a TCP segment to be sent to a peer.
1341	       This computation makes use of the peer password as well as the
1342	       TCP segment.

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

1350	     - The LSR ignores LDP Hellos from any LSR for which a password has
1351	       not been configured.  This ensures that the LSR establishes LDP
1352	       TCP connections only with LSRs for which a password has been
1353	       configured.

1355	2.10. Label Distribution for Explicitly Routed LSPs

1357	   Traffic Engineering [TE] is expected to be an important MPLS
1358	   application.  MPLS support for Traffic Engineering uses explicitly
1359	   routed LSPs, which need not follow normally-routed (hop-by-hop) paths
1360	   as determined by destination-based routing protocols.  CR-LDP [CRLDP]
1361	   defines extensions to LDP to use LDP to set up explicitly routed
1362	   LSPs.

1364	3. Protocol Specification

1366	   Previous sections that describe LDP operation have discussed
1367	   scenarios that involve the exchange of messages among LDP peers.
1368	   This section specifies the message encodings and procedures for
1369	   processing the messages.

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

1374	   Each LDP PDU can carry one or more LDP messages.  Note that the
1375	   messages in an LDP PDU need not be related to one another.  For
1376	   example, a single PDU could carry a message advertising FEC-label
1377	   bindings for several FECs, another message requesting label bindings
1378	   for several other FECs, and a third notification message signaling
1379	   some event.

1381	3.1. LDP PDUs

1383	   Each LDP PDU is an LDP header followed by one or more LDP messages.
1384	   The LDP header is:

1386	    0                   1                   2                   3
1387	    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
1388	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1389	   |  Version                      |         PDU Length            |
1390	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1391	   |                         LDP Identifier                        |
1392	   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1393	   |                               |
1394	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1395	   Version
1396	     Two octet unsigned integer containing the version number of the
1397	     protocol.  This version of the specification specifies LDP protocol
1398	     version 1.

1400	   PDU Length
1401	     Two octet integer specifying the total length of this PDU in
1402	     octets, excluding the Version and PDU Length fields.

1404	     The maximum allowable PDU Length is negotiable when an LDP session
1405	     is initialized.  Prior to completion of the negotiation the maximum
1406	     allowable length is 4096 bytes.

1408	   LDP Identifier
1409	     Six octet field that uniquely identifies the label space of the
1410	     sending LSR for which this PDU applies.  The first four octets
1411	     identify the LSR and must be a globally unique value.  It should be
1412	     a 32-bit router Id assigned to the LSR and also used to identify it
1413	     in loop detection Path Vectors.  The last two octets identify a
1414	     label space within the LSR.  For a platform-wide label space, these
1415	     should both be zero.

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

1420	3.2. LDP Procedures

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

1424	     - Peer discovery;
1425	     - Session management;
1426	     - Label distribution;
1427	     - Notification of errors and advisory information.

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

1432	   The label distribution procedures are complex and are difficult to
1433	   describe fully, coherently and unambiguously as a collection of
1434	   separate message and TLV specifications.

1436	   Appendix A, "LDP Label Distribution Procedures", describes the label
1437	   distribution procedures in terms of label distribution events that
1438	   may occur at an LSR and how the LSR must respond.  Appendix A is the
1439	   specification of LDP label distribution procedures.  If a procedure
1440	   described elsewhere in this document conflicts with Appendix A,
1441	   Appendix A specifies LDP behavior.

1443	3.3. Type-Length-Value Encoding

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

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

1453	    0                   1                   2                   3
1454	    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
1455	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1456	   |U|F|        Type               |            Length             |
1457	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1458	   |                                                               |
1459	   |                             Value                             |
1460	   ~                                                               ~
1461	   |                                                               |
1462	   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1463	   |                               |
1464	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1466	   U bit
1467	     Unknown TLV bit.  Upon receipt of an unknown TLV, if U is clear
1468	     (=0), a notification must be returned to the message originator and
1469	     the entire message must be ignored; if U is set (=1), the unknown
1470	     TLV is silently ignored and the rest of the message is processed as
1471	     if the unknown TLV did not exist.  The sections following that
1472	     define TLVs specify a value for the U-bit.

1474	   F bit
1475	     Forward unknown TLV bit.  This bit applies only when the U bit is
1476	     set and the LDP message containing the unknown TLV is to be
1477	     forwarded.  If F is clear (=0), the unknown TLV is not forwarded
1478	     with the containing message; if F is set (=1), the unknown TLV is
1479	     forwarded with the containing message.  The sections following that
1480	     define TLVs specify a value for the F-bit.

1482	   Type
1483	     Encodes how the Value field is to be interpreted.

1485	   Length
1486	     Specifies the length of the Value field in octets.

1488	   Value
1489	     Octet string of Length octets that encodes information to be
1490	     interpreted as specified by the Type field.

1492	   Note that there is no alignment requirement for the first octet of a
1493	   TLV.

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

1498	   The TLV encoding scheme is very general.  In principle, everything
1499	   appearing in an LDP PDU could be encoded as a TLV.  This
1500	   specification does not use the TLV scheme to its full generality.  It
1501	   is not used where its generality is unnecessary and its use would
1502	   waste space unnecessarily.  These are usually places where the type
1503	   of a value to be encoded is known, for example by its position in a
1504	   message or an enclosing TLV, and the length of the value is fixed or
1505	   readily derivable from the value encoding itself.

1507	   Some of the TLVs defined for LDP are similar to one another.  For
1508	   example, there is a Generic Label TLV, an ATM Label TLV, and a Frame
1509	   Relay TLV; see Sections "Generic Label TLV", "ATM Label TLV", and
1510	   "Frame Relay TLV".

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

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

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

1524	3.4. TLV Encodings for Commonly Used Parameters

1526	   There are several parameters used by more than one LDP message.  The
1527	   TLV encodings for these commonly used parameters are specified in
1528	   this section.

1530	3.4.1. FEC TLV

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

1535	   Its encoding is:

1537	    0                   1                   2                   3
1538	    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
1539	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1540	   |0|0| FEC (0x0100)              |      Length                   |
1541	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1542	   |                        FEC Element 1                          |
1543	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1544	   |                                                               |
1545	   ~                                                               ~
1546	   |                                                               |
1547	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1548	   |                        FEC Element n                          |
1549	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

1555	     A FEC Element value is encoded as a 1 octet field that specifies
1556	     the element type, and a variable length field that is the type-
1557	     dependent element value.  Note that while the representation of the
1558	     FEC element value is type-dependent, the FEC element encoding
1559	     itself is one where standard LDP TLV encoding is not used.

1561	     The FEC Element value encoding is:

1563	         FEC Element       Type      Value
1564	         type name

1566	           Wildcard        0x01      No value; i.e., 0 value octets;
1567	                                         see below.
1568	           Prefix          0x02      See below.
1569	           Host Address    0x03      Full host address; see below.

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

1576	     Wildcard FEC Element
1577	       To be used only in the Label Withdraw and Label Release Messages.
1578	       Indicates the withdraw/release is to be applied to all FECs
1579	       associated with the label within the following label TLV.  Must
1580	       be the only FEC Element in the FEC TLV.

1582	     Prefix FEC Element value encoding:

1584	      0                   1                   2                   3
1585	      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
1586	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1587	     |  Prefix (2)   |     Address Family            |     PreLen    |
1588	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1589	     |                     Prefix                                    |
1590	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1592	       Address Family
1593	         Two octet quantity containing a value from ADDRESS FAMILY
1594	         NUMBERS in [rfc1700] that encodes the address family for the
1595	         address prefix in the Prefix field.

1597	       PreLen
1598	         One octet unsigned integer containing the length in bits of the
1599	         address prefix that follows.  A length of zero indicates a
1600	         prefix that matches all addresses (the default destination); in
1601	         this case the Prefix itself is zero octets).

1603	       Prefix
1604	         An address prefix encoded according to the Address Family
1605	         field, whose length, in bits, was specified in the PreLen
1606	         field, padded to a byte boundary.

1608	     Host Address FEC Element encoding:

1610	      0                   1                   2                   3
1611	      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
1612	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1613	     | Host Addr (3) |     Address Family            | Host Addr Len |
1614	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1615	     |                                                               |
1616	     |                     Host Addr                                 |
1617	     |                                                               |
1618	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1620	       Address Family
1621	         Two octet quantity containing a value from ADDRESS FAMILY
1622	         NUMBERS in [rfc1700] that encodes the address family for the
1623	         address prefix in the Prefix field.

1625	       Host Addr Len
1626	         Length of the Host address in octets.

1628	       Host Addr
1629	         An address encoded according to the Address Family field.

1631	3.4.1.1. FEC Procedures

1633	   If in decoding a FEC TLV an LSR encounters a FEC Element with an
1634	   Address Family it does not support, it should stop decoding the FEC
1635	   TLV, abort processing the message containing the TLV, and send an
1636	   "Unsupported Address Family" Notification message to its LDP peer
1637	   signaling an error.

1639	   If it encounters a FEC Element type it cannot decode, it should stop
1640	   decoding the FEC TLV, abort processing the message containing the
1641	   TLV, and send an "Unknown FEC" Notification message to its LDP peer
1642	   signaling an error.

1644	3.4.2. Label TLVs

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

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

1652	3.4.2.1. Generic Label TLV

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

1658	    0                   1                   2                   3
1659	    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
1660	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1661	   |0|0| Generic Label (0x0200)    |      Length                   |
1662	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1663	   |     Label                                                     |
1664	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1666	   Label
1667	     This is a 20-bit label value as specified in [ENCAP] represented as
1668	     a 20-bit number in a 4 octet field.

1670	3.4.2.2. ATM Label TLV

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

1674	    0                   1                   2                   3
1675	    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
1676	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1677	   |0|0| ATM Label (0x0201)        |         Length                |
1678	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1679	   |Res| V |          VPI          |         VCI                   |
1680	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1682	   Res
1683	     This field is reserved. It must be set to zero on transmission and
1684	     must be ignored on receipt.

1686	   V-bits
1687	     Two-bit switching indicator.  If V-bits is 00, both the VPI and VCI
1688	     are significant.  If V-bits is 01, only the VPI field is
1689	     significant.  If V-bit is 10, only the VCI is significant.

1691	   VPI
1692	     Virtual Path Identifier. If VPI is less than 12-bits it should be
1693	     right justified in this field and preceding bits should be set to
1694	     0.

1696	   VCI
1697	     Virtual Channel Identifier. If the VCI is less than 16- bits, it
1698	     should be right justified in the field and the preceding bits must
1699	     be set to 0. If Virtual Path switching is indicated in the V-bits
1700	     field, then this field must be ignored by the receiver and set to 0
1701	     by the sender.

1703	3.4.2.3. Frame Relay Label TLV

1705	   An LSR uses Frame Relay Label TLVs to encode labels for use on Frame
1706	   Relay links.

1708	    0                   1                   2                   3
1709	    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
1710	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1711	   |0|0| Frame Relay Label (0x0202)|       Length                  |
1712	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1713	   | Reserved    |Len|                     DLCI                    |
1714	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1715	   Res
1716	     This field is reserved. It must be set to zero on transmission and
1717	     must be ignored on receipt.

1719	   Len
1720	     This field specifies the number of bits of the DLCI. The following
1721	     values are supported:

1723	        0 = 10 bits DLCI
1724	        1 = 17 bits DLCI
1725	        2 = 23 bits DLCI

1727	   DLCI
1728	     The Data Link Connection Identifier.  Refer to [FR] for the label
1729	     values and formats.

1731	3.4.3. Address List TLV

1733	   The Address List TLV appears in Address and Address Withdraw
1734	   messages.

1736	   Its encoding is:

1738	    0                   1                   2                   3
1739	    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
1740	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1741	   |0|0| Address List (0x0101)     |      Length                   |
1742	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1743	   |     Address Family            |                               |
1744	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
1745	   |                                                               |
1746	   |                        Addresses                              |
1747	   ~                                                               ~
1748	   |                                                               |
1749	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1751	   Address Family
1752	     Two octet quantity containing a value from ADDRESS FAMILY NUMBERS
1753	     in [rfc1700] that encodes the addresses contained in the Addresses
1754	     field.

1756	   Addresses
1757	     A list of addresses from the specified Address Family.  The
1758	     encoding of the individual addresses depends on the Address Family.

1760	     The following address encodings are defined by this version of the
1761	     protocol:

1763	         Address Family      Address Encoding

1765	         IPv4                4 octet full IPv4 address

1767	3.4.4. Hop Count TLV

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

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

1776	    0                   1                   2                   3
1777	    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
1778	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1779	   |0|0| Hop Count (0x0103)        |      Length                   |
1780	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1781	   |     HC Value  |
1782	   +-+-+-+-+-+-+-+-+

1784	   HC Value
1785	     1 octet unsigned integer hop count value.

1787	3.4.4.1. Hop Count Procedures

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

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

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

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

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

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

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

1814	   By convention a value of 0 indicates an unknown hop count.  The
1815	   result of incrementing an unknown hop count is itself an unknown hop
1816	   count (0).

1818	   Use of the unknown hop count value greatly reduces the signaling
1819	   overhead when independent control is used.  When a new LSP is
1820	   established, each LSR starts with unknown hop count.  Addition of a
1821	   new LSR whose hop count is also unknown does not cause a hop count
1822	   update to be propagated upstream since the hop count remains unknown.
1823	   When the egress is finally added to the LSP, then the LSRs propagate
1824	   hop count updates upstream via Label Mapping messages.

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

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

1837	   If an LSR receives a message containing a Hop Count TLV, it must
1838	   check the hop count value to determine whether the hop count has
1839	   exceeded its configured maximum allowable value.  If so, it must
1840	   behave as if the containing message has traversed a loop by sending a
1841	   Notification message signaling Loop Detected in reply to the sender
1842	   of the message.

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

1847	3.4.5. Path Vector TLV

1849	   The Path Vector TLV is used with the Hop Count TLV in Label Request
1850	   and Label Mapping messages to implement the optional LDP loop
1851	   detection mechanism.  See Section "Loop Detection".  Its use in the
1852	   Label Request message records the path of LSRs the request has
1853	   traversed.  Its use in the Label Mapping message records the path of
1854	   LSRs a label advertisement has traversed to setup an LSP.

1856	   Its encoding is:

1858	    0                   1                   2                   3
1859	    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
1860	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1861	   |0|0| Path Vector (0x0104)      |        Length                 |
1862	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1863	   |                            LSR Id 1                           |
1864	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1865	   |                                                               |
1866	   ~                                                               ~
1867	   |                                                               |
1868	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1869	   |                            LSR Id n                           |
1870	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1872	   One or more LSR Ids
1873	     A list of router-ids indicating the path of LSRs the message has
1874	     traversed.  Each LSR Id is the first four octets (router-id) of the
1875	     LDP identifier for the corresponding LSR.  This ensures it is
1876	     unique within the LSR network.

1878	3.4.5.1. Path Vector Procedures

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

1883	3.4.5.1.1. Label Request Path Vector

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

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

1891	   If the LSR detects a loop, it must reject the Label Request message.

1893	   The LSR must:

1895	      1. Transmit a Notification message to the sending LSR signaling
1896	         "Loop Detected".

1898	      2. Not propagate the Label Request message further.

1900	   Note that a Label Request message with Path Vector TLV is forwarded
1901	   until:

1903	      1. A loop is found,

1905	      2. The LSP egress is reached,

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

1910	3.4.5.1.2. Label Mapping Path Vector

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

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

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

1921	      1. Transmit a Label Release message carrying a Status TLV to the
1922	         sending LSR to signal "Loop Detected".

1924	      2. Not propagate the message further.

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

1930	   Note that a Label Mapping message with a Path Vector TLV is forwarded
1931	   until:

1933	      1. A loop is found,

1935	      2. An LSP ingress is reached, or
1936	      3. The maximum Path Vector or maximum Hop Count limit is reached.
1937	         This is treated as if a loop had been detected.

1939	3.4.6. Status TLV

1941	   Notification messages carry Status TLVs to specify events being
1942	   signaled.

1944	   The encoding for the Status TLV is:

1946	    0                   1                   2                   3
1947	    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
1948	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1949	   |U|F| Status (0x0300)           |      Length                   |
1950	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1951	   |                     Status Code                               |
1952	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1953	   |                     Message ID                                |
1954	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1955	   |      Message Type             |
1956	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1958	   U bit
1959	     Should be 0 when the Status TLV is sent in a Notification message.
1960	     Should be 1 when the Status TLV is sent in some other message.

1962	   F bit
1963	     Should be the same as the setting of the F-bit in the Status Code
1964	     field.

1966	   Status Code
1967	     32-bit unsigned integer encoding the event being signaled.  The
1968	     structure of a Status Code is:

1970	      0                   1                   2                   3
1971	      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
1972	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1973	     |E|F|                 Status Data                               |
1974	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1976	     E bit
1977	       Fatal error bit.  If set (=1), this is a fatal error
1978	       notification.  If clear (=0), this is an advisory notification.

1980	     F bit
1981	       Forward bit.  If set (=1), the notification should be forwarded
1982	       to the LSR for the next-hop or previous-hop for the LSP, if any,
1983	       associated with the event being signaled.  If clear (=0), the
1984	       notification should not be forwarded.

1986	     Status Data
1987	       30-bit unsigned integer which specifies the status information.

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

1992	     A Status Code of 0 signals success.

1994	   Message ID
1995	     If non-zero, 32-bit value that identifies the peer message to which
1996	     the Status TLV refers.  If zero, no specific peer message is being
1997	     identified.

1999	   Message Type
2000	     If non-zero, the type of the peer message to which the Status TLV
2001	     refers.  If zero, the Status TLV does not refer to any specific
2002	     message type.

2004	 Note that use of the Status TLV is not limited to Notification
2005	 messages.  A message other than a Notification message may carry a
2006	 Status TLV as an Optional Parameter.  When a message other than a
2007	 Notification carries a Status TLV the U-bit of the Status TLV should be
2008	 set to 1 to indicate that the receiver should silently discard the TLV
2009	 if unprepared to handle it.

2011	3.5. LDP Messages

2013	   All LDP messages have the following format:

2015	    0                   1                   2                   3
2016	    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
2017	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2018	   |U|   Message Type              |      Message Length           |
2019	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2020	   |                     Message ID                                |
2021	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2022	   |                                                               |
2023	   +                                                               +
2024	   |                     Mandatory Parameters                      |
2025	   +                                                               +
2026	   |                                                               |
2027	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2028	   |                                                               |
2029	   +                                                               +
2030	   |                     Optional Parameters                       |
2031	   +                                                               +
2032	   |                                                               |
2033	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2035	   U bit
2036	     Unknown message bit.  Upon receipt of an unknown message, if U is
2037	     clear (=0), a notification is returned to the message originator;
2038	     if U is set (=1), the unknown message is silently ignored.  The
2039	     sections following that define messages specify a value for the U-
2040	     bit.

2042	   Message Type
2043	     Identifies the type of message

2045	   Message Length
2046	     Specifies the cumulative length in octets of the Message ID,
2047	     Mandatory Parameters, and Optional Parameters.

2049	   Message ID
2050	     32-bit value used to identify this message.  Used by the sending
2051	     LSR to facilitate identifying notification messages that may apply
2052	     to this message.  An LSR sending a notification message in response
2053	     to this message should include this Message Id in the Status TLV
2054	     carried by the notification message; see Section "Notification
2055	     Message".

2057	   Mandatory Parameters
2058	     Variable length set of required message parameters.  Some messages
2059	     have no required parameters.

2061	     For messages that have required parameters, the required parameters
2062	     MUST appear in the order specified by the individual message
2063	     specifications in the sections that follow.

2065	   Optional Parameters
2066	     Variable length set of optional message parameters.  Many messages
2067	     have no optional parameters.

2069	     For messages that have optional parameters, the optional parameters
2070	     may appear in any order.

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

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

2077	       Message Name            Section Title

2079	       Notification            "Notification Message"
2080	       Hello                   "Hello Message"
2081	       Initialization          "Initialization Message"
2082	       KeepAlive               "KeepAlive Message"
2083	       Address                 "Address Message"
2084	       Address Withdraw        "Address Withdraw Message"
2085	       Label Mapping           "Label Mapping Message"
2086	       Label Request           "Label Request Message"
2087	       Label Abort Request     "Label Abort Request Message"
2088	       Label Withdraw          "Label Withdraw Message"
2089	       Label Release           "Label Release Message"

2091	   The sections that follow specify the encodings and procedures for
2092	   these messages.

2094	   Some of the above messages are related to one another, for example
2095	   the Label Mapping, Label Request, Label Withdraw, and Label Release
2096	   messages.

2098	   While it is possible to think about messages related in this way in
2099	   terms of a message type that specifies a message class and a message
2100	   subtype that specifies a particular kind of message within that
2101	   class, this specification does not formalize the notion of a message
2102	   subtype.

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

2108	3.5.1. Notification Message

2110	   An LSR sends a Notification message to inform an LDP peer of a
2111	   significant event.  A Notification message signals a fatal error or
2112	   provides advisory information such as the outcome of processing an
2113	   LDP message or the state of the LDP session.

2115	   The encoding for the Notification Message is:

2117	    0                   1                   2                   3
2118	    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
2119	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2120	   |0|   Notification (0x0001)     |      Message Length           |
2121	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2122	   |                     Message ID                                |
2123	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2124	   |                     Status (TLV)                              |
2125	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2126	   |                     Optional Parameters                       |
2127	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2129	   Message ID
2130	     32-bit value used to identify this message.

2132	   Status TLV
2133	     Indicates the event being signaled.  The encoding for the Status
2134	     TLV is specified in Section "Status TLV".

2136	   Optional Parameters
2137	     This variable length field contains 0 or more parameters, each
2138	     encoded as a TLV.  The following Optional Parameters are generic
2139	     and may appear in any Notification Message:

2141	         Optional Parameter     Type     Length  Value

2143	         Extended Status        0x0301    4      See below
2144	         Returned PDU           0x0302    var    See below
2145	         Returned Message       0x0303    var    See below

2147	     Other Optional Parameters, specific to the particular event being
2148	     signaled by the Notification Messages may appear.  These are
2149	     described elsewhere.

2151	       Extended Status
2152	         The 4 octet value is an Extended Status Code that encodes
2153	         additional information that supplements the status information
2154	         contained in the Notification Status Code.

2156	       Returned PDU
2157	         An LSR uses this parameter to return part of an LDP PDU to the
2158	         LSR that sent it.  The value of this TLV is the PDU header and
2159	         as much PDU data following the header as appropriate for the
2160	         condition being signaled by the Notification message.

2162	       Returned Message
2163	         An LSR uses this parameter to return part of an LDP message to
2164	         the LSR that sent it.  The value of this TLV is the message
2165	         type and length fields and as much message data following the
2166	         type and length fields as appropriate for the condition being
2167	         signaled by the Notification message.

2169	3.5.1.1. Notification Message Procedures

2171	   If an LSR encounters a condition requiring it to notify its peer with
2172	   advisory or error information it sends the peer a Notification
2173	   message containing a Status TLV that encodes the information and
2174	   optionally additional TLVs that provide more information about the
2175	   condition.

2177	   If the condition is one that is a fatal error the Status Code carried
2178	   in the notification will indicate that.  In this case, after sending
2179	   the Notification message the LSR should terminate the LDP session by
2180	   closing the session TCP connection and discard all state associated
2181	   with the session, including all label-FEC bindings learned via the
2182	   session.

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

2190	3.5.1.2. Events Signaled by Notification Messages

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

2195	3.5.1.2.1. Malformed PDU or Message

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

2200	   An LDP PDU received on a TCP connection for an LDP session is
2201	   malformed if:

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

2208	     - The LDP protocol version is not supported by the receiver, or it
2209	       is supported but is not the version negotiated for the session
2210	       during session establishment.  This is a fatal error signaled by
2211	       the Bad Protocol Version Status Code.

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

2218	   An LDP Message is malformed if:

2220	     - The Message Type is unknown.

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

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

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

2232	     - The message is missing one or more Mandatory Parameters.  This is
2233	       a non-fatal error signalled by the Missing Message Parameters
2234	       Status Code.

2236	3.5.1.2.2. Unknown or Malformed TLV

2238	   Malformed TLVs contained in LDP messages that are part of the LDP
2239	   Discovery mechanism are handled by silently discarding the containing
2240	   message.

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

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

2249	     - The TLV type is unknown.

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

2254	       If the TLV type is >= 0x8000 (high order bit 1) the TLV is
2255	       silently dropped.  Section "Unknown TLV in Known Message Type"
2256	       elaborates on this behavior.

2258	     - The TLV Value is malformed.  This occurs when the receiver
2259	       handles the TLV but cannot decode the TLV Value.  This is
2260	       interpreted as indicative of a bug in either the sending or
2261	       receiving LSR.  It is a fatal error signaled by the Malformed TLV
2262	       Value Status Code.

2264	3.5.1.2.3. Session KeepAlive Timer Expiration

2266	   This is a fatal error signaled by the KeepAlive Timer Expired Status
2267	   Code.

2269	3.5.1.2.4. Unilateral Session Shutdown

2271	   This is a fatal event signaled by the Shutdown Status Code.  The
2272	   Notification Message may optionally include an Extended Status TLV to
2273	   provide a reason for the Shutdown.  The sending LSR terminates the
2274	   session immediately after sending the Notification.

2276	3.5.1.2.5. Initialization Message Events

2278	   The session initialization negotiation (see Section "Session
2279	   Initialization") may fail if the session parameters received in the
2280	   Initialization Message are unacceptable.  This is a fatal error.  The
2281	   specific Status Code depends on the parameter deemed unacceptable,
2282	   and is defined in Sections "Initialization Message".

2284	3.5.1.2.6. Events Resulting From Other Messages

2286	   Messages other than the Initialization message may result in events
2287	   that must be signaled to LDP peers via Notification Messages.  These
2288	   events and the Status Codes used in the Notification Messages to
2289	   signal them are described in the sections that describe these
2290	   messages.

2292	3.5.1.2.7. Internal Errors

2294	   An LDP implementation may be capable of detecting problem conditions
2295	   specific to its implementation.  When such a condition prevents an
2296	   implementation from interacting correctly with a peer, the
2297	   implementation should, when capable of doing so, use the Internal
2298	   Error Status Code to signal the peer.  This is a fatal error.

2300	3.5.1.2.8. Miscellaneous Events

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

2305	3.5.2. Hello Message

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

2310	   The encoding for the Hello Message is:

2312	    0                   1                   2                   3
2313	    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
2314	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2315	   |0|   Hello (0x0100)            |      Message Length           |
2316	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2317	   |                     Message ID                                |
2318	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2319	   |                     Common Hello Parameters TLV               |
2320	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2321	   |                     Optional Parameters                       |
2322	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2324	   Message ID
2325	     32-bit value used to identify this message.

2327	   Common Hello Parameters TLV
2328	     Specifies parameters common to all Hello messages.  The encoding
2329	     for the Common Hello Parameters TLV is:

2331	      0                   1                   2                   3
2332	      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
2333	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2334	     |0|0| Common Hello Parms(0x0400)|      Length                   |
2335	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2336	     |      Hold Time                |T|R| Reserved                  |
2337	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2339	     Hold Time,
2340	       Hello hold time in seconds.  An LSR maintains a record of Hellos
2341	       received from potential peers (see Section "Hello Message
2342	       Procedures").  Hello Hold Time specifies the time the sending LSR
2343	       will maintain its record of Hellos from the receiving LSR without
2344	       receipt of another Hello.

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

2350	       A value of 0 means use the default, which is 15 seconds for Link
2351	       Hellos and 45 seconds for Targeted Hellos.  A value of 0xffff
2352	       means infinite.

2354	     T, Targeted Hello
2355	       A value of 1 specifies that this Hello is a Targeted Hello.  A
2356	       value of 0 specifies that this Hello is a Link Hello.

2358	     R, Request Send Targeted Hellos
2359	       A value of 1 requests the receiver to send periodic Targeted
2360	       Hellos to the source of this Hello.  A value of 0 makes no
2361	       request.

2363	       An LSR initiating Extended Discovery sets R to 1.  If R is 1, the
2364	       receiving LSR checks whether it has been configured to send
2365	       Targeted Hellos to the Hello source in response to Hellos with
2366	       this request.  If not, it ignores the request.  If so, it
2367	       initiates periodic transmission of Targeted Hellos to the Hello
2368	       source.

2370	     Reserved
2371	       This field is reserved.  It must be set to zero on transmission
2372	       and ignored on receipt.

2374	     Optional Parameters
2375	       This variable length field contains 0 or more parameters, each
2376	       encoded as a TLV.  The optional parameters defined by this
2377	       version of the protocol are
2378	           Optional Parameter         Type     Length  Value

2380	           IPv4 Transport Address     0x0401     4      See below
2381	           Configuration              0x0402     4      See below
2382	              Sequence Number
2383	           IPv6 Transport Address     0x0403     8      See below

2385	       IPv4 Transport Address
2386	         Specifies the IPv4 address to be used for the sending LSR when
2387	         opening the LDP session TCP connection.  If this optional TLV
2388	         is not present the IPv4 source address for the UDP packet
2389	         carrying the Hello should be used.

2391	       Configuration Sequence Number
2392	         Specifies a 4 octet unsigned configuration sequence number that
2393	         identifies the configuration state of the sending LSR.  Used by
2394	         the receiving LSR to detect configuration changes on the
2395	         sending LSR.

2397	       IPv6 Transport Address
2398	         Specifies the IPv6 address to be used for the sending LSR when
2399	         opening the LDP session TCP connection.  If this optional TLV
2400	         is not present the IPv6 source address for the UDP packet
2401	         carrying the Hello should be used.

2403	3.5.2.1. Hello Message Procedures

2405	   An LSR receiving Hellos from another LSR maintains a Hello adjacency
2406	   corresponding to the Hellos.  The LSR maintains a hold timer with the
2407	   Hello adjacency which it restarts whenever it receives a Hello that
2408	   matches the Hello adjacency.  If the hold timer for a Hello adjacency
2409	   expires the LSR discards the Hello adjacency: see sections
2410	   "Maintaining Hello Adjacencies" and "Maintaining LDP Sessions".

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

2415	   An LSR processes a received LDP Hello as follows:

2417	      1. The LSR checks whether the Hello is acceptable.  The criteria
2418	         for determining whether a Hello is acceptable are
2419	         implementation dependent (see below for example criteria).

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

2423	      3. If the Hello is acceptable, the LSR checks whether it has a
2424	         Hello adjacency for the Hello source. If so, it restarts the
2425	         hold timer for the Hello adjacency.  If not it creates a Hello
2426	         adjacency for the Hello source and starts its hold timer.

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

2431	      5. Finally, if the LSR has no LDP session for the label space
2432	         specified by the LDP identifier in the PDU header for the
2433	         Hello, it follows the procedures of Section "LDP Session
2434	         Establishment".

2436	   The following are examples of acceptability criteria for Link and
2437	   Targeted Hellos:

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

2442	       A Targeted Hello from source address A is acceptable if either:

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

2446	           - The LSR has been configured to send Targeted Hellos to A.

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

2450	       Transport Address
2451	         The LSR associates the specified transport address with the
2452	         Hello adjacency.

2454	       Configuration Sequence Number
2455	         The Configuration Sequence Number optional parameter is used by
2456	         the sending LSR to signal configuration changes to the
2457	         receiving LSR.  When a receiving LSR playing the active role in
2458	         LDP session establishment detects a change in the sending LSR
2459	         configuration, it may clear the session setup backoff delay, if
2460	         any, associated with the sending LSR (see Section "Session
2461	         Initialization").

2463	         A sending LSR using this optional parameter is responsible for
2464	         maintaining the configuration sequence number it transmits in
2465	         Hello messages.  Whenever there is a configuration change on
2466	         the sending LSR, it increments the configuration sequence
2467	         number.

2469	3.5.3. Initialization Message

2471	   The LDP Initialization Message is exchanged as part of the LDP
2472	   session establishment procedure; see Section "LDP Session
2473	   Establishment".

2475	   The encoding for the Initialization Message is:

2477	    0                   1                   2                   3
2478	    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
2479	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2480	   |0|   Initialization (0x0200)   |      Message Length           |
2481	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2482	   |                     Message ID                                |
2483	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2484	   |                     Common Session Parameters TLV             |
2485	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2486	   |                     Optional Parameters                       |
2487	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2489	   Message ID
2490	     32-bit value used to identify this message.

2492	   Common Session Parameters TLV
2493	     Specifies values proposed by the sending LSR for parameters that
2494	     must be negotiated for every LDP session.

2496	     The encoding for the Common Session Parameters TLV is:

2498	        0                   1                   2                   3
2499	        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
2500	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2501	       |0|0| Common Sess Parms (0x0500)|      Length                   |
2502	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2503	       | Protocol Version              |      KeepAlive Time           |
2504	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2505	       |A|D|  Reserved |     PVLim     |      Max PDU Length           |
2506	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2507	       |                 Receiver LDP Identifier                       |
2508	       +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2509	       |                               |
2510	       -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++

2512	       Protocol Version
2513	         Two octet unsigned integer containing the version number of the
2514	         protocol.  This version of the specification specifies LDP
2515	         protocol version 1.

2517	       KeepAlive Time
2518	         Two octet unsigned non zero integer that indicates the number
2519	         of seconds that the sending LSR proposes for the value of the
2520	         KeepAlive Time.  The receiving LSR MUST calculate the value of
2521	         the KeepAlive Timer by using the smaller of its proposed
2522	         KeepAlive Time and the KeepAlive Time received in the PDU.  The
2523	         value chosen for KeepAlive Time indicates the maximum number of
2524	         seconds that may elapse between the receipt of successive PDUs
2525	         from the LDP peer on the session TCP connection.  The KeepAlive
2526	         Timer is reset each time a PDU arrives.

2528	       A, Label Advertisement Discipline
2529	         Indicates the type of Label advertisement.  A value of 0 means
2530	         Downstream Unsolicited advertisement; a value of 1 means
2531	         Downstream On Demand.

2533	         If one LSR proposes Downstream Unsolicited and the other
2534	         proposes Downstream on Demand, the rules for resolving this
2535	         difference is:

2537	           - If the session is for a label-controlled ATM link or a
2538	             label-controlled Frame Relay link, then Downstream on
2539	             Demand must be used.

2541	           - Otherwise, Downstream Unsolicited must be used.

2543	         If the label advertisement discipline determined in this way is
2544	         unacceptable to an LSR, it must send a Session
2545	         Rejected/Parameters Advertisement Mode Notification message in
2546	         response to the Initialization message and not establish the
2547	         session.

2549	       D, Loop Detection
2550	         Indicates whether loop detection based on path vectors is
2551	         enabled.  A value of 0 means loop detection is disabled; a
2552	         value of 1 means that loop detection is enabled.

2554	       PVLim, Path Vector Limit
2555	         The configured maximum path vector length.  Must be 0 if loop
2556	         detection is disabled (D = 0).  If the loop detection
2557	         procedures would require the LSR to send a path vector that
2558	         exceeds this limit, the LSR will behave as if a loop had been
2559	         detected for the FEC in question.

2561	         When Loop Detection is enabled in a portion of a network, it is
2562	         recommended that all LSRs in that portion of the network be
2563	         configured with the same path vector limit.  Although knowledge
2564	         of a peer's path vector limit will not change an LSR's
2565	         behavior, it does enable the LSR to alert an operator to a
2566	         possible misconfiguration.

2568	       Reserved
2569	         This field is reserved.  It must be set to zero on transmission
2570	         and ignored on receipt.

2572	       Max PDU Length
2573	         Two octet unsigned integer that proposes the maximum allowable
2574	         length for LDP PDUs for the session.  A value of 255 or less
2575	         specifies the default maximum length of 4096 octets.

2577	         The receiving LSR MUST calculate the maximum PDU length for the
2578	         session by using the smaller of its and its peer's proposals
2579	         for Max PDU Length. The default maximum PDU length applies
2580	         before session initialization completes.

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

2587	       Receiver LDP Identifier
2588	         Identifies the receiver's label space.  This LDP Identifier,
2589	         together with the sender's LDP Identifier in the PDU header
2590	         enables the receiver to match the Initialization message with
2591	         one of its Hello adjacencies; see Section "Hello Message
2592	         Procedures".

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

2598	   Optional Parameters
2599	     This variable length field contains 0 or more parameters, each
2600	     encoded as a TLV.  The optional parameters are:

2602	         Optional Parameter       Type     Length  Value

2604	         ATM Session Parameters   0x0501   var     See below
2605	         Frame Relay Session      0x0502   var     See below
2606	           Parameters

2608	     ATM Session Parameters
2609	       Used when an LDP session manages label exchange for an ATM link
2610	       to specify ATM-specific session parameters.

2612	        0                   1                   2                   3
2613	        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
2614	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2615	       |0|0|   ATM Sess Parms (0x0501) |      Length                   |
2616	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2617	       | M |   N   |D|                        Reserved                 |
2618	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2619	       |                 ATM Label Range Component 1                   |
2620	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2621	       |                                                               |
2622	       ~                                                               ~
2623	       |                                                               |
2624	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2625	       |                 ATM Label Range Component N                   |
2626	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2628	       M, ATM Merge Capabilities
2629	         Specifies the merge capabilities of an ATM switch.  The
2630	         following values are supported in this version of the
2631	         specification:

2633	                   Value          Meaning

2635	                     0            Merge not supported
2636	                     1            VP Merge supported
2637	                     2            VC Merge supported
2638	                     3            VP & VC Merge supported

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

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

2644	           - The interoperability of VP-merge-capable switches with
2645	             non-VP-merge-capable switches is a subject for future
2646	             study.  When the LSRs differ on the use of VP-merge, the
2647	             session is established, but VP merge is not used.

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

2653	       N, Number of label range components
2654	         Specifies the number of ATM Label Range Components included in
2655	         the TLV.

2657	       D, VC Directionality
2658	         A value of 0 specifies bidirectional VC capability, meaning the
2659	         LSR can (within a given VPI) support the use of a given VCI as
2660	         a label for both link directions independently.  A value of 1
2661	         specifies unidirectional VC capability, meaning (within a given
2662	         VPI) a given VCI may appear in a label mapping for one
2663	         direction on the link only.  When either or both of the peers
2664	         specifies unidirectional VC capability, both LSRs use
2665	         unidirectional VC label assignment for the link as follows.
2666	         The LSRs compare their LDP Identifiers as unsigned integers.
2667	         The LSR with the larger LDP Identifier may assign only odd-
2668	         numbered VCIs in the VPI/VCI range as labels.  The system with
2669	         the smaller LDP Identifier may assign only even-numbered VCIs
2670	         in the VPI/VCI range as labels.

2672	       Reserved
2673	         This field is reserved.  It must be set to zero on transmission
2674	         and ignored on receipt.

2676	       One or more ATM Label Range Components
2677	         A list of ATM Label Range Components which together specify the
2678	         Label range supported by the transmitting LSR.

2680	         A receiving LSR MUST calculate the intersection between the
2681	         received range and its own supported label range.  The
2682	         intersection is the range in which the LSR may allocate and
2683	         accept labels.  LSRs MUST NOT establish a session with
2684	         neighbors for which the intersection of ranges is NULL.  In
2685	         this case, the LSR must send a Session Rejected/Parameters
2686	         Label Range Notification message in response to the
2687	         Initialization message and not establish the session.

2689	         The encoding for an ATM Label Range Component is:

2691	          0                   1                   2                   3
2692	          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
2693	         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2694	         |  Res  |    Minimum VPI        |      Minimum VCI              |
2695	         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2696	         |  Res  |    Maximum VPI        |      Maximum VCI              |
2697	         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2699	         Res
2700	           This field is reserved. It must be set to zero on
2701	           transmission and must be ignored on receipt.

2703	         Minimum VPI (12 bits)
2704	           This 12 bit field specifies the lower bound of a block of
2705	           Virtual Path Identifiers that is supported on the originating
2706	           switch.  If the VPI is less than 12-bits it should be right
2707	           justified in this field and preceding bits should be set to
2708	           0.

2710	         Minimum VCI (16 bits)
2711	           This 16 bit field specifies the lower bound of a block of
2712	           Virtual Connection Identifiers that is supported on the
2713	           originating switch.  If the VCI is less than 16-bits it
2714	           should be right justified in this field and preceding bits
2715	           should be set to 0.

2717	         Maximum VPI (12 bits)
2718	           This 12 bit field specifies the upper bound of a block of
2719	           Virtual Path Identifiers that is supported on the originating
2720	           switch.  If the VPI is less than 12-bits it should be right
2721	           justified in this field and preceding bits should be set to
2722	           0.

2724	         Maximum VCI (16 bits)
2725	           This 16 bit field specifies the upper bound of a block of
2726	           Virtual Connection Identifiers that is supported on the
2727	           originating switch.  If the VCI is less than 16-bits it
2728	           should be right justified in this field and preceding bits
2729	           should be set to 0.

2731	       When peer LSRs are connected indirectly by means of an ATM VP,
2732	       the sending LSR should set the Minimum and Maximum VPI fields to
2733	       0, and the receiving LSR must ignore the Minimum and Maximum VPI
2734	       fields.

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

2739	     Frame Relay Session Parameters
2740	       Used when an LDP session manages label exchange for a Frame Relay
2741	       link to specify Frame Relay-specific session parameters.

2743	        0                   1                   2                   3
2744	        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
2745	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2746	       |0|0|   FR Sess Parms (0x0502)  |      Length                   |
2747	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2748	       | M |   N   |D|                        Reserved                 |
2749	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2750	       |             Frame Relay Label Range Component 1               |
2751	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2752	       |                                                               |
2753	       ~                                                               ~
2754	       |                                                               |
2755	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2756	       |             Frame Relay Label Range Component N               |
2757	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2759	       M, Frame Relay Merge Capabilities
2760	         Specifies the merge capabilities of a Frame Relay switch.  The
2761	         following values are supported in this version of the
2762	         specification:

2764	                   Value          Meaning

2766	                     0            Merge not supported
2767	                     1            Merge supported

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

2771	       N, Number of label range components
2772	         Specifies the number of Frame Relay Label Range Components
2773	         included in the TLV.

2775	       D, VC Directionality
2776	         A value of 0 specifies bidirectional VC capability, meaning the
2777	         LSR can support the use of a given DLCI as a label for both
2778	         link directions independently.  A value of 1 specifies
2779	         unidirectional VC capability, meaning a given DLCI may appear
2780	         in a label mapping for one direction on the link only.  When
2781	         either or both of the peers specifies unidirectional VC
2782	         capability, both LSRs use unidirectional VC label assignment
2783	         for the link as follows.  The LSRs compare their LDP
2784	         Identifiers as unsigned integers.  The LSR with the larger LDP
2785	         Identifier may assign only odd-numbered DLCIs in the range as
2786	         labels.  The system with the smaller LDP Identifier may assign
2787	         only even-numbered DLCIs in the range as labels.

2789	       Reserved
2790	         This field is reserved.  It must be set to zero on transmission
2791	         and ignored on receipt.

2793	       One or more Frame Relay Label Range Components
2794	         A list of Frame Relay Label Range Components which together
2795	         specify the Label range supported by the transmitting LSR.

2797	         A receiving LSR MUST calculate the intersection between the
2798	         received range and its own supported label range.  The
2799	         intersection is the range in which the LSR may allocate and
2800	         accept labels.  LSRs MUST NOT establish a session with
2801	         neighbors for which the intersection of ranges is NULL.  In
2802	         this case, the LSR must send a Session Rejected/Parameters
2803	         Label Range Notification message in response to the
2804	         Initialization message and not establish the session.

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

2808	          0                   1                   2                   3
2809	          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
2810	         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2811	         | Reserved    |Len|                     Minimum DLCI            |
2812	         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2813	         | Reserved        |                     Maximum DLCI            |
2814	         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2816	         Reserved
2817	           This field is reserved.  It must be set to zero on
2818	           transmission and ignored on receipt.

2820	         Len
2821	           This field specifies the number of bits of the DLCI.  The
2822	           following values are supported:

2824	                Len    DLCI bits

2826	                0       10
2827	                1       17
2828	                2       23

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

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

2842	   Note that there is no Generic Session Parameters TLV for sessions
2843	   which advertise Generic Labels.

2845	3.5.3.1. Initialization Message Procedures

2847	   See Section "LDP Session Establishment" and particularly Section
2848	   "Session Initialization" for general procedures for handling the
2849	   Initialization Message.

2851	3.5.4. KeepAlive Message

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

2856	   The encoding for the KeepAlive Message is:

2858	    0                   1                   2                   3
2859	    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
2860	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2861	   |0|   KeepAlive (0x0201)        |      Message Length           |
2862	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2863	   |                     Message ID                                |
2864	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2865	   |                     Optional Parameters                       |
2866	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2868	   Message ID
2869	     32-bit value used to identify this message.

2871	   Optional Parameters
2872	     No optional parameters are defined for the KeepAlive message.

2874	3.5.4.1. KeepAlive Message Procedures

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

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

2887	3.5.5. Address Message

2889	   An LSR sends the Address Message to an LDP peer to advertise its
2890	   interface addresses.

2892	   The encoding for the Address Message is:

2894	    0                   1                   2                   3
2895	    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
2896	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2897	   |0|   Address (0x0300)          |      Message Length           |
2898	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2899	   |                     Message ID                                |
2900	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2901	   |                                                               |
2902	   |                     Address List TLV                          |
2903	   |                                                               |
2904	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2905	   |                     Optional Parameters                       |
2906	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2908	   Message ID
2909	     32-bit value used to identify this message.

2911	   Address List TLV
2912	     The list of interface addresses being advertised by the sending
2913	     LSR.  The encoding for the Address List TLV is specified in Section
2914	     "Address List TLV".

2916	   Optional Parameters
2917	     No optional parameters are defined for the Address message.

2919	3.5.5.1. Address Message Procedures

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

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

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

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

2937	   If an LSR does not support the Address Family specified in the
2938	   Address List TLV, it should send an "Unsupported Address Family"
2939	   Notification to its LDP signalling an error and abort processing the
2940	   message.

2942	3.5.6. Address Withdraw Message

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

2947	   The encoding for the Address Withdraw Message is:

2949	    0                   1                   2                   3
2950	    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
2951	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2952	   |0|   Address Withdraw (0x0301) |      Message Length           |
2953	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2954	   |                     Message ID                                |
2955	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2956	   |                                                               |
2957	   |                     Address List TLV                          |
2958	   |                                                               |
2959	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2960	   |                     Optional Parameters                       |
2961	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2963	   Message ID
2964	     32-bit value used to identify this message.

2966	   Address list TLV
2967	     The list of interface addresses being withdrawn by the sending LSR.
2968	     The encoding for the Address list TLV is specified in Section
2969	     "Address List TLV".

2971	   Optional Parameters
2972	     No optional parameters are defined for the Address Withdraw
2973	     message.

2975	3.5.6.1. Address Withdraw Message Procedures

2977	   See Section "Address Message Procedures"

2979	3.5.7. Label Mapping Message

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

2984	   The encoding for the Label Mapping Message is:

2986	   0                   1                   2                   3
2987	   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
2988	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2989	   |0|   Label Mapping (0x0400)    |      Message Length           |
2990	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2991	   |                     Message ID                                |
2992	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2993	   |                     FEC TLV                                   |
2994	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2995	   |                     Label TLV                                 |
2996	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2997	   |                     Optional Parameters                       |
2998	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3000	   Message ID
3001	     32-bit value used to identify this message.

3003	   FEC TLV
3004	     Specifies the FEC component of the FEC-Label mapping being
3005	     advertised.  See Section "FEC TLV" for encoding.

3007	   Label TLV
3008	     Specifies the Label component of the FEC-Label mapping.  See
3009	     Section "Label TLV" for encoding.

3011	   Optional Parameters
3012	     This variable length field contains 0 or more parameters, each
3013	     encoded as a TLV.  The optional parameters are:

3015	         Optional Parameter    Length       Value
3016	         Label Request         4            See below
3017	             Message ID TLV
3018	         Hop Count TLV         1            See below
3019	         Path Vector TLV       variable     See below

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

3024	       Label Request Message ID
3025	         If this Label Mapping message is a response to a Label Request
3026	         message it must include the Request Message Id optional
3027	         parameter.  The value of this optional parameter is the Message
3028	         Id of the corresponding Label Request Message.

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

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

3040	3.5.7.1. Label Mapping Message Procedures

3042	   The Mapping message is used by an LSR to distribute a label mapping
3043	   for a FEC to an LDP peer.  If an LSR distributes a mapping for a FEC
3044	   to multiple LDP peers, it is a local matter whether it maps a single
3045	   label to the FEC, and distributes that mapping to all its peers, or
3046	   whether it uses a different mapping for each of its peers.

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

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

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

3058	3.5.7.1.1. Independent Control Mapping

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

3063	      1. The LSR recognizes a new FEC via the forwarding table, and the
3064	         label advertisement mode is Downstream Unsolicited
3065	         advertisement.

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

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

3073	      4. The attributes of a mapping change.

3075	      5. The receipt of a mapping from the downstream next hop  AND
3076	            a) no upstream mapping has been created  OR
3077	            b) loop detection is configured  OR
3078	            c) the attributes of the mapping have changed.

3080	3.5.7.1.2. Ordered Control Mapping

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

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

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

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

3095	      4. The attributes of a mapping change.

3097	      5. The receipt of a mapping from the downstream next hop  AND
3098	            a) no upstream mapping has been created   OR
3099	            b) loop detection is configured   OR
3100	            c) the attributes of the mapping have changed.

3102	3.5.7.1.3. Downstream on Demand Label Advertisement

3104	   In general, the upstream LSR is responsible for requesting label
3105	   mappings when operating in Downstream on Demand mode.  However,
3106	   unless some rules are followed, it is possible for neighboring LSRs
3107	   with different advertisement modes to get into a livelock situation
3108	   where everything is functioning properly, but no labels are
3109	   distributed.  For example, consider two LSRs Ru and Rd where Ru is
3110	   the upstream LSR and Rd is the downstream LSR for a particular FEC.
3111	   In this example, Ru is using Downstream Unsolicited advertisement
3112	   mode and Rd is using Downstream on Demand mode.  In this case, Rd may
3113	   assume that Ru will request a label mapping when it wants one and Ru
3114	   may assume that Rd will advertise a label if it wants Ru to use one.
3115	   If Rd and Ru operate as suggested, no labels will be distributed from
3116	   Rd to Ru.

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

3124	3.5.7.1.4. Downstream Unsolicited Label Advertisement

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

3130	   The combination of Downstream Unsolicited mode and conservative label
3131	   retention can lead to a situation where an LSR releases the label for
3132	   a FEC that it later needs.  For example, if LSR Rd advertises to LSR
3133	   Ru the label for a FEC for which it is not Ru's next hop, Ru will
3134	   release the label.  If Ru's next hop for the FEC later changes to Rd,
3135	   it needs the previously released label.

3137	   To deal with this situation either Ru can explicitly request the
3138	   label when it needs it, or Rd can periodically readvertise it to Ru.
3139	   In many situations Ru will know when it needs the label from Rd.  For
3140	   example, when its next hop for the FEC changes to Rd.  However, there
3141	   could be situations when Ru does not.  For example, Rd may be
3142	   attempting to establish an LSP with non-standard properties.  Forcing
3143	   Ru to explicitly request the label in this situation would require it
3144	   to maintain state about a potential LSP with non-standard properties.

3146	   In situations where Ru knows it needs the label, it is responsible
3147	   for explicitly requesting the label by means of a Label Request
3148	   message.  In situations where Ru may not know that it needs the
3149	   label, Rd is responsible for periodically readvertising the label to
3150	   Ru.

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

3157	3.5.8. Label Request Message

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

3162	   The encoding for the Label Request Message is:

3164	    0                   1                   2                   3
3165	    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
3166	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3167	   |0|   Label Request (0x0401)    |      Message Length           |
3168	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3169	   |                     Message ID                                |
3170	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3171	   |                     FEC TLV                                   |
3172	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3173	   |                     Optional Parameters                       |
3174	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3176	   Message ID
3177	     32-bit value used to identify this message.

3179	   FEC TLV
3180	     The FEC for which a label is being requested.  See Section "FEC
3181	     TLV" for encoding.

3183	   Optional Parameters
3184	     This variable length field contains 0 or more parameters, each
3185	     encoded as a TLV.  The optional parameters are:

3187	         Optional Parameter     Length       Value

3189	         Hop Count TLV          1            See below
3190	         Path Vector TLV        variable     See below

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

3195	       Hop Count
3196	         Specifies the running total of the number of LSR hops along the
3197	         LSP being setup by the Label Request Message.  Section "Hop
3198	         Count Procedures" describes how to handle this TLV.

3200	       Path Vector
3201	         Specifies the LSRs along the LSR being setup by the Label
3202	         Request Message.  Section "Path Vector Procedures" describes
3203	         how to handle this TLV.

3205	3.5.8.1. Label Request Message Procedures

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

3210	   An LSR may transmit a Request message under any of the following
3211	   conditions:

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

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

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

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

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

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

3238	   When the FEC for which a label is requested is a Prefix FEC Element
3239	   or a Host Address FEC Element, the receiving LSR uses its routing
3240	   table to determine its response.  Unless its routing table includes
3241	   an entry that exactly matches the requested Prefix or Host Address,
3242	   the LSR must respond with a No Route Notification message.

3244	   The message ID of the Label Request message serves as an identifier
3245	   for the Label Request transaction.  When the receiving LSR responds
3246	   with a Label Mapping message, the mapping message must include a
3247	   Label Request/Returned Message ID TLV optional parameter which
3248	   includes the message ID of the Label Request message.  Note that
3249	   since LSRs use Label Request message IDs as transaction identifiers
3250	   an LSR should not reuse the message ID of a Label Request message
3251	   until the corresponding transaction completes.

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

3256	     No Route
3257	       The FEC for which a label was requested includes a FEC Element
3258	       for which the LSR does not have a route.

3260	     No Label Resources
3261	       The LSR cannot provide a label because of resource limitations.
3262	       When resources become available the LSR must notify the
3263	       requesting LSR by sending a Notification message with the Label
3264	       Resources Available Status Code.

3266	       An LSR that receives a No Label Resources response to a Label
3267	       Request message must not issue further Label Request messages
3268	       until it receives a Notification message with the Label Resources
3269	       Available Status code.

3271	     Loop Detected
3272	       The LSR has detected a looping Label Request message.

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

3276	3.5.9. Label Abort Request Message

3278	   The Label Abort Request message may be used to abort an outstanding
3279	   Label Request message.

3281	   The encoding for the Label Abort Request Message is:

3283	    0                   1                   2                   3
3284	    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
3285	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3286	   |0|   Label Abort Req (0x0404)  |      Message Length           |
3287	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3288	   |                     Message ID                                |
3289	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3290	   |                     FEC TLV                                   |
3291	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3292	   |                     Label Request Message ID TLV              |
3293	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3294	   |                     Optional Parameters                       |
3295	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3297	   Message ID
3298	     32-bit value used to identify this message.

3300	   FEC TLV
3301	     Identifies the FEC for which the Label Request is being aborted.

3303	   Label Request Message ID TLV
3304	     Specifies the message ID of the Label Request message to be
3305	     aborted.

3307	   Optional Parameters
3308	     No optional parameters are defined for the Label Abort Req message.

3310	3.5.9.1. Label Abort Request Message Procedures

3312	   An LSR Ru may send a Label Abort Request message to abort an
3313	   outstanding Label Request message for FEC sent to LSR Rd in the
3314	   following circumstances:

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

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

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

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

3330	   When an LSR receives a Label Abort Request message, if it has not
3331	   previously responded to the Label Request being aborted with a Label
3332	   Mapping message or some other Notification message, it must
3333	   acknowledge the abort by responding with a Label Request Aborted
3334	   Notification message.  The Notification must include a Label Request
3335	   Message ID TLV that carries the message ID of the aborted Label
3336	   Request message.

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

3342	   If an LSR receives a Label Mapping message in response to a Label
3343	   Request message after it has sent a Label Abort Request message to
3344	   abort the Label Request, the label in the Label Mapping message is
3345	   valid.  The LSR may choose to use the label or to release it with a
3346	   Label Release message.

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

3352	     - A Label Request Aborted Notification message acknowledging the
3353	       abort;

3355	     - A Label Mapping message in response to the Label Request message
3356	       being aborted;

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

3361	   To protect itself against tardy peers or faulty peer implementations
3362	   an LSR may choose to time out receipt of the above.  The time out
3363	   period should be relatively long (several minutes).  If the time out
3364	   period elapses with no reply from the peer the LSR may reuse the
3365	   Message Id of the Label Request message; if it does so, it should
3366	   also discard any record of the outstanding Label Request and Label
3367	   Abort messages.

3369	   Note that the response to a Label Abort Request message is never
3370	   "ordered".  That is, the response does not depend on the downstream
3371	   state of the LSP setup being aborted.  An LSR receiving a Label Abort
3372	   Request message must process it immediately, regardless of the
3373	   downstream state of the LSP, responding with a Label Request Aborted
3374	   Notification or ignoring it, as appropriate.

3376	3.5.10. Label Withdraw Message

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

3383	   The encoding for the Label Withdraw Message is:

3385	    0                   1                   2                   3
3386	    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
3387	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3388	   |0|   Label Withdraw (0x0402)   |      Message Length           |
3389	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3390	   |                     Message ID                                |
3391	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3392	   |                     FEC TLV                                   |
3393	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3394	   |                     Label TLV (optional)                      |
3395	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3396	   |                     Optional Parameters                       |
3397	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3399	   Message ID
3400	     32-bit value used to identify this message.

3402	   FEC TLV
3403	     Identifies the FEC for which the FEC-label mapping is being
3404	     withdrawn.

3406	   Optional Parameters
3407	     This variable length field contains 0 or more parameters, each
3408	     encoded as a TLV.  The optional parameters are:

3410	         Optional Parameter    Length       Value

3412	         Label TLV             variable     See below

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

3416	       Label
3417	         If present, specifies the label being withdrawn (see procedures
3418	         below).

3420	3.5.10.1. Label Withdraw Message Procedures

3422	   An LSR transmits a Label Withdraw message under the following
3423	   conditions:

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

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

3432	   The FEC TLV specifies the FEC for which labels are to be withdrawn.
3433	   If no Label TLV follows the FEC, all labels associated with the FEC
3434	   are to be withdrawn; otherwise only the label specified in the
3435	   optional Label TLV is to be withdrawn.

3437	   The FEC TLV may contain the Wildcard FEC Element; if so, it may
3438	   contain no other FEC Elements.  In this case, if the Label Withdraw
3439	   message contains an optional Label TLV, then the label is to be
3440	   withdrawn from all FECs to which it is bound.  If there is not an
3441	   optional Label TLV in the Label Withdraw message, then the sending
3442	   LSR is withdrawing all label mappings previously advertised to the
3443	   receiving LSR.

3445	   An LSR that receives a Label Withdraw message must respond with a
3446	   Label Release message.

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

3450	3.5.11. Label Release Message

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

3456	   The encoding for the Label Release Message is:

3458	    0                   1                   2                   3
3459	    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
3460	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3461	   |0|   Label Release (0x0403)   |      Message Length            |
3462	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3463	   |                     Message ID                                |
3464	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3465	   |                     FEC TLV                                   |
3466	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3467	   |                     Label TLV (optional)                      |
3468	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3469	   |                     Optional Parameters                       |
3470	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3472	   Message ID
3473	     32-bit value used to identify this message.

3475	   FEC TLV
3476	     Identifies the FEC for which the FEC-label mapping is being
3477	     released.

3479	   Optional Parameters
3480	     This variable length field contains 0 or more parameters, each
3481	     encoded as a TLV.  The optional parameters are:

3483	         Optional Parameter    Length       Value

3485	         Label TLV             variable     See below

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

3489	       Label
3490	         If present, the label being released (see procedures below).

3492	3.5.11.1. Label Release Message Procedures

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

3498	   An LSR must transmit a Label Release message under any of the
3499	   following conditions:

3501	      1. The LSR which sent the label mapping is no longer the next hop
3502	         for the mapped FEC, and the LSR is configured for conservative
3503	         operation.

3505	      2. The LSR receives a label mapping from an LSR which is not the
3506	         next hop for the FEC, and the LSR is configured for
3507	         conservative operation.

3509	      3. The LSR receives a Label Withdraw message.

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

3517	   The FEC TLV specifies the FEC for which labels are to be released.
3518	   If no Label TLV follows the FEC, all labels associated with the FEC
3519	   are to be released; otherwise only the label specified in the
3520	   optional Label TLV is to be released.

3522	   The FEC TLV may contain the Wildcard FEC Element; if so, it may
3523	   contain no other FEC Elements.  In this case, if the Label Release
3524	   message contains an optional Label TLV, then the label is to be
3525	   released for all FECs to which it is bound.  If there is not an
3526	   optional Label TLV in the Label Release message, then the sending LSR
3527	   is releasing all label mappings previously learned from the receiving
3528	   LSR.

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

3532	3.6. Messages and TLVs for Extensibility

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

3537	   This section specifies TLVs and messages for vendor-private and
3538	   experimental use.

3540	3.6.1. LDP Vendor-private Extensions

3542	   Vendor-private TLVs and messages are used to convey vendor-private
3543	   information between LSRs.

3545	3.6.1.1. LDP Vendor-private TLVs

3547	   The Type range 0x3E00 through 0x3EFF is reserved for vendor-private
3548	   TLVs.

3550	   The encoding for a vendor-private TLV is:

3552	    0                   1                   2                   3
3553	    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
3554	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3555	   |U|F|    Type (0x3E00-0x3EFF)   |            Length             |
3556	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3557	   |                           Vendor ID                           |
3558	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3559	   |                                                               |
3560	   |                           Data....                            |
3561	   ~                                                               ~
3562	   |                                                               |
3563	   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3564	   |                               |
3565	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3566	   U bit
3567	     Unknown TLV bit.  Upon receipt of an unknown TLV, if U is clear
3568	     (=0), a notification must be returned to the message originator and
3569	     the entire message must be ignored; if U is set (=1), the unknown
3570	     TLV is silently ignored and the rest of the message is processed as
3571	     if the unknown TLV did not exist.

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

3576	   F bit
3577	     Forward unknown TLV bit.  This bit only applies when the U bit is
3578	     set and the LDP message containing the unknown TLV is is to be
3579	     forwarded.  If F is clear (=0), the unknown TLV is not forwarded
3580	     with the containing message; if F is set (=1), the unknown TLV is
3581	     forwarded with the containing message.

3583	   Type
3584	     Type value in the range 0x3E00 through 0x3EFF.  Together, the Type
3585	     and Vendor Id field specify how the Data field is to be
3586	     interpreted.

3588	   Length
3589	     Specifies the cumulative length in octets of the Vendor ID and Data
3590	     fields.

3592	   Vendor Id
3593	     802 Vendor ID as assigned by the IEEE.

3595	   Data
3596	     The remaining octets after the Vendor ID in the Value field are
3597	     optional vendor-dependent data.

3599	3.6.1.2. LDP Vendor-private Messages

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

3604	    0                   1                   2                   3
3605	    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
3606	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3607	   |U|    Msg Type (0x3E00-0x3EFF) |      Message Length           |
3608	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3609	   |                     Message ID                                |
3610	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3611	   |                     Vendor ID                                 |
3612	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3613	   +                                                               +
3614	   |                     Remaining Mandatory Parameters            |
3615	   +                                                               +
3616	   |                                                               |
3617	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3618	   |                                                               |
3619	   +                                                               +
3620	   |                     Optional Parameters                       |
3621	   +                                                               +
3622	   |                                                               |
3623	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3625	   U bit
3626	     Unknown message bit.  Upon receipt of an unknown message, if U is
3627	     clear (=0), a notification is returned to the message originator;
3628	     if U is set (=1), the unknown message is silently ignored.

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

3633	   Msg Type
3634	     Message type value in the range 0x3E00 through 0x3EFF.  Together,
3635	     the Msg Type and the Vendor ID specify how the message is to be
3636	     interpreted.

3638	   Message Length
3639	     Specifies the cumulative length in octets of the Message ID, Vendor
3640	     ID, Remaining Mandatory Parameters and Optional Parameters.

3642	   Message ID
3643	     32-bit integer used to identify this message.  Used by the sending
3644	     LSR to facilitate identifying notification messages that may apply
3645	     to this message.  An LSR sending a notification message in response
3646	     to this message will include this Message Id in the notification
3647	     message; see Section "Notification Message".

3649	   Vendor ID
3650	     802 Vendor ID as assigned by the IEEE.

3652	   Remaining Mandatory Parameters
3653	     Variable length set of remaining required message parameters.

3655	   Optional Parameters
3656	     Variable length set of optional message parameters.

3658	3.6.2. LDP Experimental Extensions

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

3663	     - The Type range 0x3F00 through 0x3FFF is reserved for experimental
3664	       TLVs.

3666	     - The Message Type range 0x3F00 through 0x3FFF is reserved for
3667	       experimental messages.

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

3672	       Experimental TLVs and messages use an Experiment ID field in
3673	       place of a Vendor ID field.  The Experiment ID field is used with
3674	       the Type or Message Type field to specify the interpretation of
3675	       the experimental TLV or Message.

3677	       Administration of Experiment IDs is the responsibility of the
3678	       experimenters.

3680	3.7. Message Summary

3682	   The following are the LDP messages defined in this version of the
3683	   protocol.

3685	       Message Name            Type     Section Title

3687	       Notification            0x0001   "Notification Message"
3688	       Hello                   0x0100   "Hello Message"
3689	       Initialization          0x0200   "Initialization Message"
3690	       KeepAlive               0x0201   "KeepAlive Message"
3691	       Address                 0x0300   "Address Message"
3692	       Address Withdraw        0x0301   "Address Withdraw Message"
3693	       Label Mapping           0x0400   "Label Mapping Message"
3694	       Label Request           0x0401   "Label Request Message"
3695	       Label Withdraw          0x0402   "Label Withdraw Message"
3696	       Label Release           0x0403   "Label Release Message"
3697	       Label Abort Request     0x0404   "Label Abort Request Message"
3698	       Vendor-Private          0x3E00-  "LDP Vendor-private Extensions"
3699	                               0x3EFF
3700	       Experimental            0x3F00-  "LDP Experimental Extensions"
3701	                               0x3FFF

3703	3.8. TLV Summary

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

3707	       TLV                      Type      Section Title

3709	       FEC                      0x0100    "FEC TLV"
3710	       Address List             0x0101    "Address List TLV"
3711	       Hop Count                0x0103    "Hop Count TLV"
3712	       Path Vector              0x0104    "Path Vector TLV"
3713	       Generic Label            0x0200    "Generic Label TLV"
3714	       ATM Label                0x0201    "ATM Label TLV"
3715	       Frame Relay Label        0x0202    "Frame Relay Label TLV"
3716	       Status                   0x0300    "Status TLV"
3717	       Extended Status          0x0301    "Notification Message"
3718	       Returned PDU             0x0302    "Notification Message"
3719	       Returned Message         0x0303    "Notification Message"
3720	       Common Hello             0x0400    "Hello Message"
3721	          Parameters
3722	       IPv4 Transport Address   0x0401    "Hello Message"
3723	       Configuration            0x0402    "Hello Message"
3724	          Sequence Number
3725	       IPv6 Transport Address   0x0403    "Hello Message"
3726	       Common Session           0x0500    "Initialization Message"
3727	          Parameters
3728	       ATM Session Parameters   0x0501    "Initialization Message"
3729	       Frame Relay Session      0x0502    "Initialization Message"
3730	          Parameters

3732	       Label Request            0x0600    "Label Mapping Message"
3733	           Message ID
3734	       Vendor-Private           0x3E00-   "LDP Vendor-private Extensions"
3735	                                0x3EFF
3736	       Experimental             0x3F00-   "LDP Experimental Extensions"
3737	                                0x3FFF

3739	3.9. Status Code Summary

3741	   The following are the Status Codes defined in this version of the
3742	   protocol.

3744	   The "E" column is the required setting of the Status Code E-bit; the
3745	   "Status Data" column is the value of the 30-bit Status Data field in
3746	   the Status Code TLV.

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

3751	       Status Code           E   Status Data   Section Title

3753	       Success               0   0x00000000    "Status TLV"
3754	       Bad LDP Identifier    1   0x00000001    "Events Signaled by ..."
3755	       Bad Protocol Version  1   0x00000002    "Events Signaled by ..."
3756	       Bad PDU Length        1   0x00000003    "Events Signaled by ..."
3757	       Unknown Message Type  0   0x00000004    "Events Signaled by ..."
3758	       Bad Message Length    1   0x00000005    "Events Signaled by ..."
3759	       Unknown TLV           0   0x00000006    "Events Signaled by ..."
3760	       Bad TLV length        1   0x00000007    "Events Signaled by ..."
3761	       Malformed TLV Value   1   0x00000008    "Events Signaled by ..."
3762	       Hold Timer Expired    1   0x00000009    "Events Signaled by ..."
3763	       Shutdown              1   0x0000000A    "Events Signaled by ..."
3764	       Loop Detected         0   0x0000000B    "Loop Detection"
3765	       Unknown FEC           0   0x0000000C    "FEC Procedures"
3766	       No Route              0   0x0000000D    "Label Request Mess ..."
3767	       No Label Resources    0   0x0000000E    "Label Request Mess ..."
3768	       Label Resources /     0   0x0000000F    "Label Request Mess ..."
3769	           Available
3770	       Session Rejected/     1   0x00000010    "Session Initialization"
3771	          No Hello
3772	       Session Rejected/     1   0x00000011    "Session Initialization"
3773	          Parameters Advertisement Mode
3774	       Session Rejected/     1   0x00000012    "Session Initialization"
3775	          Parameters Max PDU Length
3776	       Session Rejected/     1   0x00000013    "Session Initialization"
3777	          Parameters Label Range

3779	       KeepAlive Timer       1   0x00000014    "Events Signaled by ..."
3780	           Expired
3781	       Label Request Aborted 0   0x00000015    "Label Request Abort ..."
3782	       Missing Message       0   0x00000016    "Events Signaled by ..."
3783	           Parameters
3784	       Unsupported Address   0   0x00000017    "FEC Procedures"
3785	           Family                              "Address Message Proc ..."
3786	       Session Rejected/     1   0x00000018    "Session Initialization"
3787	          Bad KeepAlive Time
3788	       Internal Error        1   0x00000019    "Events Signaled by ..."

3790	3.10. Well-known Numbers

3792	3.10.1. UDP and TCP Ports

3794	   The UDP port for LDP Hello messages is 646.

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

3798	3.10.2. Implicit NULL Label

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

3803	4. IANA Considerations

3805	   LDP defines the following name spaces which require management:

3807	     - Message types.
3808	     - TLV types.
3809	     - FEC types.
3810	     - Status codes.
3811	     - Experiment Ids.

3813	   The following sections provide guidelines for managing these name
3814	   spaces.

3816	4.1. Message Type Name Space

3818	   LDP divides the name space for message types into three ranges.  The
3819	   following are the guidelines for managing these ranges:

3821	     - Message Types 0x0000 - 0x3DFF.  Message types in this range are
3822	       part of the LDP base protocol.  Following the policies outlined
3823	       in [IANA], Message types in this range are allocated through an
3824	       IETF Consensus action.

3826	     - Message Types 0x3E00 - 0x3EFF.  Message types in this range are
3827	       reserved for Vendor Private extensions and are the responsibility
3828	       of the individual vendors (see Section "LDP Vendor-private
3829	       Messages").

3831	     - Message Types 0x3F00 - 0x3FFF.  Message types in this range are
3832	       reserved for Experimental extensions and are the responsibility
3833	       of the individual experimenters (see Sections "LDP Experimental
3834	       Extensions" and "Experiment ID Name Space").

3836	4.2. TLV Type Name Space

3838	   LDP divides the name space for TLV types into three ranges.  The
3839	   following are the guidelines for managing these ranges:

3841	     - TLV Types 0x0000 - 0x3DFF.  TLV types in this range are part of
3842	       the LDP base protocol.  Following the policies outlined in
3843	       [IANA], TLV types in this range are allocated through an IETF
3844	       Consensus action.

3846	     - TLV Types 0x3E00 - 0x3EFF.  TLV types in this range are reserved
3847	       for Vendor Private extensions and are the responsibility of the
3848	       individual vendors (see Section "LDP Vendor-private TLVs").

3850	     - TLV Types 0x3F00 - 0x3FFF.  TLV types in this range are reserved
3851	       for Experimental extensions and are the responsibility of the
3852	       individual experimenters (see Sections "LDP Experimental
3853	       Extensions" and "Experiment ID Name Space").

3855	4.3. FEC Type Name Space

3857	   The range for FEC types is 0 - 255.

3859	   Following the policies outlined in [IANA], FEC types in the range 0 -
3860	   127 are allocated through an IETF Consensus action, types in the
3861	   range 128 - 191 are allocated as First Come First Served, and types
3862	   in the range 192 - 255 are reserved for Private Use.

3864	4.4. Status Code Space

3866	   The range for Status Codes is 0x00000000 - 0x3FFFFFFF.

3868	   Following the policies outlined in [IANA], Status Codes in the range
3869	   0x00000000 - 0x1FFFFFFF are allocated through an IETF Consensus
3870	   action, codes in the range 0x20000000 - 0x3EFFFFFF are allocated as
3871	   First Come First Served, and codes in the range 0x3F000000 -
3872	   0x3FFFFFFF are reserved for Private Use.

3874	4.5. Experiment ID Name Space

3876	   The range for Experiment Ids is 0x00000000 - 0xffffffff.

3878	   Following the policies outlined in [IANA], Experiment Ids in the
3879	   range 0x00000000 - 0xefffffff are allocated as First Come First
3880	   Served and Experiment Ids in the range 0xf0000000 are reserved for
3881	   Private Use.

3883	5. Security Considerations

3885	   This section identifies threats to which LDP may be vulnerable and
3886	   discusses means by which those threats might be mitigated.

3888	5.1. Spoofing

3890	   There are two types of LDP communication that could be the target of
3891	   a spoofing attack.

3893	   1.  Discovery exchanges carried by UDP.

3895	       LSRs directly connected at the link level exchange Basic Hello
3896	       messages over the link.  The threat of spoofed Basic Hellos can
3897	       be reduced by:

3899	         o Accepting Basic Hellos only on interfaces to which LSRs that
3900	           can be trusted are directly connected.

3902	         o Ignoring Basic Hellos not addressed to the All Routers on
3903	           this Subnet multicast group.

3905	       LSRs not directly connected at the link level may use Extended
3906	       Hello messages to indicate willingness to establish an LDP
3907	       session.  An LSR can reduce the threat of spoofed Extended Hellos
3908	       by filtering them and accepting only those originating at sources
3909	       permitted by an access list.

3911	   2.  Session communication carried by TCP.

3913	       LDP specifies use of the TCP MD5 Signature Option to provide for
3914	       the authenticity and integrity of session messages.

3916	       [rfc2385] asserts that MD5 authentication is now considered by
3917	       some to be too weak for this application.  It also points out
3918	       that a similar TCP option with a stronger hashing algorithm (it
3919	       cites SHA-1 as an example) could be deployed.  To our knowledge
3920	       no such TCP option has been defined and deployed.  However, we
3921	       note that LDP can use whatever TCP message digest techniques are
3922	       available, and when one stronger than MD5 is specified and
3923	       implemented, upgrading LDP to use it would be relatively
3924	       straightforward.

3926	5.2. Privacy

3928	   LDP provides no mechanism for protecting the privacy of label
3929	   distribution.

3931	   The security requirements of label distribution protocols are
3932	   essentially identical to those of the protocols which distribute
3933	   routing information.  By providing a mechanism to ensure the
3934	   authenticity and integrity of its messages LDP provides a level of
3935	   security which is at least as good as, though no better than, that
3936	   which can be provided by the routing protocols themselves.  The more
3937	   general issue of whether privacy should be required for routing
3938	   protocols is beyond the scope of this document.

3940	   One might argue that label distribution requires privacy to address
3941	   the threat of label spoofing.  However, that privacy would not
3942	   protect against label spoofing attacks since data packets carry
3943	   labels in the clear.  Furthermoe, label spoofing attacks can be made
3944	   without knowledge of the FEC bound to a label.

3946	   To avoid label spoofing attacks, it is necessary to ensure that
3947	   labeled data packets are labeled by trusted LSRs and that the labels
3948	   placed on the packets are properly learned by the labeling LSRs.

3950	5.3. Denial of Service

3952	   LDP provides two potential targets for denial of service (DoS)
3953	   attacks:

3955	   1.  Well known UDP Port for LDP Discovery

3957	       An LSR adminstrator can address the threat of DoS attacks via
3958	       Basic Hellos by ensuring that the LSR is directly connected only
3959	       to peers which can be trusted to not initiate such an attack.
3960	       Interfaces to peers interior to the administrator's domain should
3961	       not represent a threat since interior peers are under the
3962	       administrator's control.  Interfaces to peers exterior to the
3963	       domain represent a potential threat since exterior peers are not.
3964	       An adminstrator can reduce that threat by connecting the LSR only
3965	       to exterior peers that can be trusted to not initiate a Basic
3966	       Hello attack.

3968	       DoS attacks via Extended Hellos are potentially a more serious
3969	       threat.  This threat can be addressed by filtering Extended
3970	       Hellos using access lists that define addresses with which
3971	       extended discovery is permitted.  However, performing the
3972	       filering requires LSR resource.

3974	       In an environment where a trusted MPLS cloud can be identified,
3975	       LSRs at the edge of the cloud can be used to protect interior
3976	       LSRs against DoS attacks via Extended Hellos by filtering out
3977	       Extended Hellos originating outside of the trusted MPLS cloud,
3978	       accepting only those originating at addresses permitted by access
3979	       lists.  This filtering protects LSRs in the interior of the cloud
3980	       but consumes resoures at the edges.

3982	   2.  Well known TCP port for LDP Session Establishment

3984	       Like other control plane protocols that use TCP, LDP may be the
3985	       target of DoS attacks, such a SYN attacks.  LDP is no more or
3986	       less vulnerable to such attacks than other control plane
3987	       protocols that use TCP.

3989	       The threat of such attacks can be mitigated somewhat by the
3990	       following:

3992	         o An LSR should avoid promiscuous TCP listens for LDP session
3993	           establishment.  It should use only listens that are specific
3994	           to discovered peers.  This enables it to drop attack packets
3995	           early in their processing since they are less likely to match
3996	           existing or in-progress connections.

3998	         o The use of the MD5 option helps somewhat since it prevents a
3999	           SYN from being accepted unless the MD5 segment checksum is
4000	           valid.  However, the receiver must compute the checksum
4001	           before it can decide to discard an otherwise acceptable SYN
4002	           segment.

4004	         o The use of access list mechanisms applied at the boundary of
4005	           the MPLS cloud in a manner similar to that suggested above
4006	           for Extended Hellos can protect the interior against attacks
4007	           originating from outside the cloud.

4009	6. Areas for Future Study

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

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

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

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

4028	     - LDP support for multipath label switching is not specified in
4029	       this version.  Multipath support may be addressed in a future
4030	       version.

4032	7. Intellectual Property Considerations

4034	   The IETF has been notified of intellectual property rights claimed in
4035	   regard to some or all of the specification contained in this
4036	   document.  For more information consult the online list of claimed
4037	   rights.

4039	8. Acknowledgments

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

4046	9. References

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

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

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

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

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

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

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

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

4080	   [IANA] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
4081	   Considerations Section in RFCs", RFC 2434, October 1998.

4083	   [LDPAPPLIC] B. Thomas, E. Gray, "LDP Applicability", Work in
4084	   Progress, June 2000.

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

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

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

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

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

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

4104	   [rfc2119] S. Bradner, "Key words for use in RFCs to Indicate
4105	   Requirement Levels", RFC 2119, March 1997.

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

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

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

4118	10. Author Information

4120	   Loa Andersson                            Andre Fredette
4121	   Nortel Networks Inc                      Nortel Networks Inc
4122	   St Eriksgatan 115, PO Box 6701           600 Technology Park Drive
4123	   113 85 Stockholm                         Billerica, MA  01821
4124	   Sweden                                   Phone:  978-288-8524
4125	   Phone: +46 8 5088 36 34                  email: fredette@nortelnetworks.com
4126	   Mobile: +46 70 522 78 34
4127	   email: loa.andersson@nortelnetworks.com

4129	   Paul Doolan                              Bob Thomas
4130	   Ennovate Networks                        Cisco Systems, Inc.
4131	   330 Codman Hill Rd                       250 Apollo Dr.
4132	   Marlborough MA 01719                     Chelmsford, MA 01824
4133	   Phone: 978-263-2002                      Phone:  978-244-8078
4134	   email: pdoolan@ennovatenetworks.com      email: rhthomas@cisco.com

4136	   Nancy Feldman
4137	   IBM Corp.
4138	   17 Skyline Drive
4139	   Hawthorne NY 10532
4140	   Phone:  914-784-3254
4141	   email: nkf@us.ibm.com

4143	Appendix A. LDP Label Distribution Procedures

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

4148	     - Receive Label Request Message;
4149	     - Receive Label Mapping Message;
4150	     - Receive Label Abort Request Message;
4151	     - Receive Label Release Message;
4152	     - Receive Label Withdraw Message;
4153	     - Recognize new FEC;
4154	     - Detect change in FEC next hop;
4155	     - Receive Notification Message / Label Request Aborted;
4156	     - Receive Notification Message / No Label Resources;
4157	     - Receive Notification Message / No Route;
4158	     - Receive Notification Message / Loop Detected;
4159	     - Receive Notification Message / Label Resources Available;
4160	     - Detect local label resources have become available;
4161	     - LSR decides to no longer label switch a FEC;
4162	     - Timeout of deferred label request.

4164	   The specification of LSR behavior in response to an event has three
4165	   parts:

4167	      1. Summary. Prose that describes LSR response to the event in
4168	         overview.

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

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

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

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

4184	     - Label Distribution procedure, which is performed by a downstream
4185	       LSR to determine when to distribute a label for a FEC to LDP
4186	       peers. The architecture defines four Label Distribution
4187	       procedures:

4189	         . Downstream Unsolicited Independent Control, called
4190	           PushUnconditional in [ARCH].

4192	         . Downstream Unsolicited Ordered Control, called
4193	           PushConditional in [ARCH].

4195	         . Downstream On Demand Independent Control, called
4196	           PulledUnconditional in [ARCH].

4198	         . Downstream On Demand Ordered Control, called
4199	           PulledConditional in [ARCH].

4201	     - Label Withdrawal procedure, which is performed by a downstream
4202	       LSR to determine when to withdraw a FEC label mapping previously
4203	       distributed to LDP peers. The architecture defines a single Label
4204	       Withdrawal procedure. Whenever an LSR breaks the binding between
4205	       a label and a FEC, it must withdraw the FEC label mapping from
4206	       all LDP peers to which it has previously sent the mapping.

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

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

4215	         . Request When Needed. The LSR requests a label whenever it
4216	           needs one.

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

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

4226	         . Conservative label retention, called Release On Change in
4227	           [ARCH].

4229	         . Liberal label retention, called No Release On Change in
4230	           [ARCH].

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

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

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

4244	         . Use If Loop Not Detected. This procedure is the same as Use
4245	           Immediate unless the LSR has detected a loop in the FEC LSP.
4246	           Use of the FEC label for forwarding/switching will continue
4247	           until the next hop for the FEC changes or the loop is no
4248	           longer detected.

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

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

4260	         . Request Retry. The LSR should issue the label request at a
4261	           later time.

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

4267	A.1. Handling Label Distribution Events

4269	   This section defines LDP label distribution procedures by specifying
4270	   an algorithm for each label distribution event.  The requirement on
4271	   an LDP implementation is that its event handling must have the effect
4272	   specified by the algorithms.  That is, an implementation need not
4273	   follow exactly the steps specified by the algorithms as long as the
4274	   effect is identical.

4276	   The algorithms for handling label distribution events share common
4277	   actions.  The specifications below package these common actions into
4278	   procedure units.  Specifications for these common procedures are in
4279	   their own section "Common Label Distribution Procedures", which
4280	   follows this.

4282	   An implementation would use data structures to store information
4283	   about protocol activity.  This appendix specifies the information to
4284	   be stored in sufficient detail to describe the algorithms, and
4285	   assumes the ability to retrieve the information as needed.  It does
4286	   not specify the details of the data structures.

4288	A.1.1. Receive Label Request

4290	 Summary:

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

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

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

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

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

4304	 Context:

4306	     - LSR. The LSR handling the event.

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

4310	     - FEC. The FEC specified in the message.

4312	     - RAttributes. Attributes received with the message. E.g., Hop
4313	       Count Path Vector.

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

4318	     - StoredHopCount. The hop count, if any, previously recorded for
4319	       the FEC.

4321	 Algorithm:

4323	   LRq.1   Execute procedure Check_Received_Attributes (MsgSource,
4324	           LabelRequest, RAttributes).
4325	           If Loop Detected, goto LRq.13.

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

4330	   LRq.3   Is MsgSource the Next Hop?
4331	           Ifnot, goto LRq.6.

4333	   LRq.4   Execute procedure Send_Notification (MsgSource, Loop
4334	           Detected).
4335	           Goto LRq.13

4337	   LRq.5   Execute procedure Send_Notification (MsgSource, No Route).
4338	           Goto LRq.13.

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

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

4347	   LRq.8   Record label request for FEC received from MsgSource and mark
4348	           it pending.

4350	   LRq.9   Perform LSR Label Distribution procedure:

4352	             For Downstream Unsolicited Independent Control OR
4353	             For Downstream On Demand Independent Control

4355	               1.  Has LSR previously received and retained a label
4356	                   mapping for FEC from Next Hop?.
4357	                   Is so, set Propagating to IsPropagating.
4358	                   If not, set Propagating to NotPropagating.

4360	               2.  Execute procedure
4361	                   Prepare_Label_Mapping_Attributes(MsgSource, FEC,
4362	                   RAttributes, SAttributes, Propagating,
4363	                   StoredHopCount).

4365	               3.  Execute procedure Send_Label (MsgSource, FEC,
4366	                   SAttributes).

4368	               4.  Is LSR egress for FEC? OR
4369	                   Has LSR previously received and retained a label
4370	                   mapping for FEC from Next Hop?
4371	                   If so, goto LRq.11.  If not, goto LRq.10.

4373	             For Downstream Unsolicited Ordered Control OR
4374	             For Downstream On Demand Ordered Control

4376	               1.  Is LSR egress for FEC? OR
4377	                   Has LSR previously received and retained a label
4378	                   mapping for FEC from Next Hop?  (See Note 3.)
4379	                   If not, goto LRq.10.

4381	               2.  Execute procedure
4382	                   Prepare_Label_Mapping_Attributes(MsgSource, FEC,
4383	                   RAttributes, SAttributes, IsPropagating,
4384	                   StoredHopCount)

4386	               3.  Execute procedure Send_Label (MsgSource, FEC,
4387	                   SAttributes).
4388	                   Goto LRq.11.

4390	   LRq.10  Perform LSR Label Request procedure:

4392	             For Request Never

4394	               1.  Goto LRq.13.

4396	             For Request When Needed OR
4397	             For Request On Request

4399	               1.  Execute procedure Prepare_Label_Request_Attributes
4400	                   (Next Hop, FEC, RAttributes, SAttributes);

4402	               2.  Execute procedure Send_Label_Request (Next Hop, FEC,
4403	                   SAttributes).
4404	                   Goto LRq.13.

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

4409	   LRq.12  Perform LSR Label Use procedure.

4411	             For Use Immediate OR
4412	             For Use If Loop Not Detected

4414	               1.  Install label sent to MsgSource and label from Next
4415	                   Hop (if LSR is not egress) for forwarding/switching
4416	                   use.

4418	   LRq.13  DONE

4420	 Notes:

4422	      1. In the case where MsgSource is a non-label merging LSR it will
4423	         send a label request for each upstream LDP peer that has
4424	         requested a label for FEC from it. The LSR must be able to
4425	         distinguish such requests from a non-label merging MsgSource
4426	         from duplicate label requests.

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

4433	      2. When an LSR sends a label request to a peer it records that the
4434	         request has been sent and marks it as outstanding. As long as
4435	         the request is marked outstanding the LSR should not send
4436	         another request for the same label to the peer. Such a second
4437	         request would be a duplicate. The Send_Label_Request procedure
4438	         described below obeys this rule.

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

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

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

4450	A.1.2. Receive Label Mapping

4452	 Summary:

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

4457	     - Transmission of a label release message for the FEC label to the
4458	       LDP peer;

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

4463	     - Installation of the newly learned label for forwarding/switching
4464	       use by the LSR.

4466	 Context:

4468	     - LSR. The LSR handling the event.

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

4472	     - FEC. The FEC specified in the message.

4474	     - Label. The label specified in the message.

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

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

4481	     - RAttributes. Attributes received with the message. E.g., Hop
4482	       Count, Path Vector.

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

4487	 Algorithm:

4489	   LMp.1   Does the received label mapping match an outstanding label
4490	           request for FEC previously sent to MsgSource.
4491	           If not, goto LMp.3.

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

4495	   LMp.3   Execute procedure Check_Received_Attributes (MsgSource,
4496	           LabelMapping, RAttributes).
4497	           If No Loop Detected, goto LMp.9.

4499	   LMp.4   Does the LSR have a previously received label mapping for FEC
4500	           from MsgSource? (See Note 1.)
4501	           If not, goto LMp.8. (See Note 2.)

4503	   LMp.5   Does the label previously received from MsgSource match Label
4504	           (i.e., the label received in the message)? (See Note 3.)
4505	           If not, goto LMp.8. (See Note 4.)

4507	   LMp.6   Delete matching label mapping for FEC previously received
4508	           from MsgSource.

4510	   LMp.7   Remove Label from forwarding/switching use. (See Note 5.)
4511	           Goto LMp.33.

4513	   LMp.8   Execute procedure Send_Message (MsgSource, Label Release,
4514	           FEC, Label, Loop Detected Status code).  Goto LMp.33.

4516	   LMp.9   Does LSR have a previously received label mapping for FEC
4517	           from MsgSource for the LSP in question?  (See Note 6.)
4518	           If not, goto LMp.11.

4520	   LMp.10  Does the label previously received from MsgSource match Label
4521	           (i.e., the label received in the message)?  (See Note 3.)
4522	           If not, goto LMp.32.  (See Note 4.)

4524	   LMp.11  Determine the Next Hop for FEC.

4526	   LMp.12  Is MsgSource the Next Hop for FEC?
4527	           If so, goto LMp.14.

4529	   LMp.13  Perform LSR Label Release procedure:

4531	             For Conservative Label retention:

4533	               1.  Goto LMp.32.

4535	             For Liberal Label retention:

4537	               1.  Record label mapping for FEC with Label and
4538	                   RAttributes has been received from MsgSource.
4539	                   Goto LMp.33.

4541	   LMp.14  Is LSR an ingress for FEC?
4542	           If not, goto LMp.16.

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

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

4549	   LMp.17  Iterate through LMp.31 for each Peer.  (See Note 7).

4551	   LMp.18  Has LSR previously sent a label mapping for FEC to Peer for
4552	           the LSP in question?  (See Note 8.)
4553	           If so, goto LMp.22.

4555	   LMp.19  Is the Downstream Unsolicited Ordered Control Label
4556	           Distribution procedure being used by LSR?  If not, goto
4557	           LMp.28.

4559	   LMp.20  Execute procedure Prepare_Label_Mapping_Attributes(Peer, FEC,
4560	           RAttributes, SAttributes, IsPropagating, StoredHopCount).

4562	   LMp.21  Execute procedure Send_Message (Peer, Label Mapping, FEC,
4563	           PrevAdvLabel, SAttributes).
4564	           Goto LMp.28

4566	   LMp.22  Iterate through LMp.27 for each label mapping for FEC
4567	           previously sent to Peer.

4569	   LMp.23  Are RAttributes in the received label mapping consistent with
4570	           those previously sent to Peer?
4571	           If so, continue iteration from LMp.22 for next label mapping.
4572	           (See Note 9.)

4574	   LMp.24  Execute procedure Prepare_Label_Mapping_Attributes(Peer, FEC,
4575	           RAttributes, SAttributes, IsPropagating, StoredHopCount).

4577	   LMp.25  Execute procedure Send_Message (Peer, Label Mapping, FEC,
4578	           PrevAdvLabel, SAttributes).  (See Note 10.)

4580	   LMp.26  Update record of label mapping for FEC previously sent to
4581	           Peer to include the new attributes sent.

4583	   LMp.27  End iteration from LMp.22.

4585	   LMp.28  Does LSR have any label requests for FEC from Peer marked as
4586	           pending?
4587	           If not, goto LMp.30.

4589	   LMp.29  Perform LSR Label Distribution procedure:

4591	             For Downstream Unsolicited Independent Control OR
4592	             For Downstream Unsolicited Ordered Control

4594	               1.  Execute procedure
4595	                   Prepare_Label_Mapping_Attributes(Peer, FEC,
4596	                   RAttributes, SAttributes, IsPropagating,
4597	                   UnknownHopCount).

4599	               2.  Execute procedure Send_Label (Peer, FEC,
4600	                   SAttributes).
4601	                   If the procedure fails, continue iteration for next
4602	                   Peer at LMp.17.

4604	               3.  If no pending requests exist for Peer goto LMp.30.
4605	                   (See Note 11.)

4607	             For Downstream On Demand Independent Control OR
4608	             For Downstream On Demand Ordered Control

4610	               1.  Iterate through Step 5 for each pending label request
4611	                   for FEC from Peer marked as pending.

4613	               2.  Execute procedure
4614	                   Prepare_Label_Mapping_Attributes(Peer, FEC,
4615	                   RAttributes, SAttributes, IsPropagating,
4616	                   UnknownHopCount)

4618	               3.  Execute procedure Send_Label (Peer, FEC,
4619	                   SAttributes).
4620	                   If the procedure fails, continue iteration for next
4621	                   Peer at LMp.17.

4623	               4.  Delete record of pending request.

4625	               5.  End iteration from Step 1.

4627	               6.  Goto LMp.30.

4629	   LMp.30  Perform LSR Label Use procedure:

4631	             For Use Immediate OR
4632	             For Use If Loop Not Detected

4634	               1.  Iterate through Step 3 for each label mapping for FEC
4635	                   previously sent to Peer.

4637	               2.  Install label received and label sent to Peer for
4638	                   forwarding/switching use.

4640	               3.  End iteration from Step 1.

4642	               4.  Goto LMp.31.

4644	   LMp.31  End iteration from LMp.17.
4645	           Go to LMp.33.

4647	   LMp.32  Execute procedure Send_Message (MsgSource, Label Release,
4648	           FEC, Label).

4650	   LMp.33  DONE.

4652	 Notes:

4654	      1. If the LSR is merging there should be at most 1 received
4655	         mapping for the FEC for the LSP in question. In the non-merging
4656	         case there could be multiple received mappings for the FEC for
4657	         the LSP in question.

4659	      2. If LSR has detected a loop and it has not previously received a
4660	         label mapping from MsgSource for the FEC, it simply releases
4661	         the label.

4663	      3. Does the Label received in the message match any of the 1 or
4664	         more label mappings identified in the previous step (LMp.4 or
4665	         LMp.9)?

4667	      4. An unsolicited mapping with a different label from the same
4668	         peer would be an attempt to establish multipath label
4669	         switching, which is not supported in this version of LDP.

4671	      5. If Label is not in forwarding/switching use, LMp.7 has no
4672	         effect.

4674	      6. If the received label mapping message matched an outstanding
4675	         label request in LMp.1, then (by definition) LSR has not
4676	         previously received a label mapping for FEC for the LSP in
4677	         question.  If the LSR is merging upstream labels for the LSP in
4678	         question, there should be at most 1 received mapping.  In the
4679	         non-merging case, there could be multiple received label
4680	         mappings for the same FEC, one for each resulting LSP.

4682	      7. The LMp.17 iteration includes MsgSource in order to handle the
4683	         case where LSR is operating in Downstream Unsolicited ordered
4684	         control mode.  Ordered control prevents LSR from advertising a
4685	         label for FEC until it has received a label mapping from its
4686	         next hop (MsgSource) for FEC.

4688	      8. If LSR is merging the LSP it may have previously sent label
4689	         mappings for the FEC LSP to one or more peers.  If LSR is not
4690	         merging, it may have sent a label mapping for the LSP in
4691	         question to at most one LSR.

4693	      9. The loop detection Path Vector attribute is considered in this
4694	         check.  If the received RAttributes include a Path Vector and
4695	         no Path Vector had been previously sent to the Peer, or if the
4696	         received Path Vector is inconsistent with the Path Vector
4697	         previously sent to the Peer, then the attributes are considered
4698	         to be inconsistent.  Note that an LSR is not required to store
4699	         a received Path Vector after it propagates the Path Vector in a
4700	         mapping message.  If an LSR does not store the Path Vector, it
4701	         has no way to check the consistency of a newly received Path
4702	         Vector.  This means that whenever such an LSR receives a
4703	         mapping message carrying a Path Vector it must always propagate
4704	         the Path Vector.

4706	     10. LMp.22 through LMp.27 deal with a situation that can arise when
4707	         the LSR is using independent control and it receives a mapping
4708	         from the downstream peer after it has sent a mapping to an
4709	         upstream peer. In this situation the LSR needs to propagate any
4710	         changed attributes, such as Hop Count, upstream. If Loop
4711	         Detection is configured on, the propagated attributes must
4712	         include the Path Vector

4714	     11. An LSR operating in Downstream Unsolicited mode must process
4715	         any Label Request messages it receives.  If there are pending
4716	         label requests, fall through into the Downstream on Demand
4717	         procedures in order to satisfy the pending requests.

4719	A.1.3. Receive Label Abort Request

4721	 Summary:

4723	     When an LSR receives a label abort request message from a peer, it
4724	     checks whether it has already responded to the label request in
4725	     question. If it has, it silently ignores the message. If it has
4726	     not, it sends the peer a Label Request Aborted Notification. In
4727	     addition, if it has a label request outstanding for the LSP in
4728	     question to a downstream peer, it sends a Label Abort Request to
4729	     the downstream peer to abort the LSP.

4731	 Context:

4733	     - LSR. The LSR handling the event.

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

4737	     - FEC. The FEC specified in the message.

4739	     - RequestMessageID. The message ID of the label request message to
4740	       be aborted.

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

4744	 Algorithm:

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

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

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

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

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

4763	   LAbR.6  Generate Event: Received Label Release Message for FEC from
4764	           MsgSource. (See Note 2.)
4765	           Goto LAbR.11.

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

4770	   LAbR.8  Are there upstream peers other than MsgSource that have
4771	           requested a label for FEC?
4772	           If so, goto LAbR.11.

4774	   LAbR.9  Execute procedure Send_Message (Next Hop, Label Abort
4775	           Request, FEC, TLV), where TLV is a Label Request Message ID
4776	           TLV containing the Message ID used by the LSR in the
4777	           outstanding Label Request message.

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

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

4783	   LAbR.12  DONE

4785	 Notes:

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

4791	      2. If LSR has received a label mapping from NextHop, it should
4792	         behave as if it had advertised a label mapping to MsgSource and
4793	         MsgSource has released it.

4795	A.1.4. Receive Label Release

4797	 Summary:

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

4805	 Context:

4807	     - LSR. The LSR handling the event.

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

4811	     - Label. The label specified in the message.

4813	     - FEC. The FEC specified in the message.

4815	 Algorithm:

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

4820	   LRl.2   Does message match an outstanding label withdraw for FEC
4821	           previously sent to MsgSource?
4822	           If not, goto LRl.4

4824	   LRl.3   Delete record of outstanding label withdraw for FEC
4825	           previously sent to MsgSource.

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

4830	   LRl.5   Has LSR previously advertised a label for this FEC to other
4831	           peers?
4832	           If so, goto LRl.10.

4834	   LRl.6   Is LSR egress for the FEC?
4835	           If so, goto LRl.10

4837	   LRl.7   Is there a Next Hop for FEC? AND
4838	           Does LSR have a previously received label mapping for FEC
4839	           from Next Hop?
4840	           If not, goto LRl.10.

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

4845	   LRl.9   Execute procedure Send_Message (Next Hop, Label Release, FEC,
4846	           Label from Next Hop).

4848	   LRl.10  Remove Label from forwarding/switching use for traffic from
4849	           MsgSource.

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

4854	   LRl.12  Free the Label.

4856	   LRl.13  DONE.

4858	 Notes:

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

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

4868	      3. If LRl.8 is reached, no upstream LSR holds a label for the FEC,
4869	         and the LSR holds a label for the FEC from the FEC Next Hop.
4870	         The LSR could propagate the Label Release to the Next Hop. By
4871	         propagating the Label Release the LSR releases a potentially
4872	         scarce label resource. In doing so, it also increases the
4873	         latency for re-establishing the LSP should MsgSource or some
4874	         other upstream LSR send it a new Label Request for FEC.

4876	         Whether or not to propagate the release is not a protocol
4877	         issue. Label distribution will operate properly whether or not
4878	         the release is propagated. The decision to propagate or not
4879	         should take into consideration factors such as: whether labels
4880	         are a scarce resource in the operating environment; the
4881	         importance of keeping LSP setup latency low by keeping the
4882	         amount of signaling required small; whether LSP setup is
4883	         ingress-controlled or egress-controlled in the operating
4884	         environment.

4886	A.1.5. Receive Label Withdraw

4888	 Summary:

4890	     When an LSR receives a label withdraw message for a FEC from an LDP
4891	     peer, it responds with a label release message and it removes the
4892	     label from any forwarding/switching use. If ordered control is in
4893	     use, the LSR sends a label withdraw message to each LDP peer to
4894	     which it had previously sent a label mapping for the FEC. If the
4895	     LSR is using Downstream on Demand label advertisement with
4896	     independent control, it then acts as if it had just recognized the
4897	     FEC.

4899	 Context:

4901	     - LSR. The LSR handling the event.

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

4905	     - Label. The label specified in the message.

4907	     - FEC. The FEC specified in the message.

4909	 Algorithm:

4911	   LWd.1   Remove Label from forwarding/switching use.  (See Note 1.)

4913	   LWd.2   Execute procedure Send_Message (MsgSource, Label Release,
4914	           FEC, Label)

4916	   LWd.3   Has LSR previously received and retained a matching label
4917	           mapping for FEC from MsgSource?
4918	           If not, goto LWd.13.

4920	   LWd.4   Delete matching label mapping for FEC previously received
4921	           from MsgSource.

4923	   LWd.5   Is LSR using ordered control?
4924	           If so, goto LWd.8.

4926	   LWd.6   Is MsgSource using Downstream On Demand label advertisement?
4927	           If not, goto LWd.13.

4929	   LWd.7   Generate Event: Recognize New FEC for FEC.
4930	           Goto LWd.13.  (See Note 2.)

4932	   LWd.8   Iterate through LWd.12 for each Peer, other than MsgSource.

4934	   LWd.9   Has LSR previously sent a label mapping for FEC to Peer?
4935	           If not, continue iteration for next Peer at LWd.8.

4937	   LWd.10  Does the label previously sent to Peer "map" to the withdrawn
4938	           Label?
4939	           If not, continue iteration for next Peer at LWd.8.  (See Note
4940	           3.)

4942	   LWd.11  Execute procedure Send_Label_Withdraw (Peer, FEC, Label
4943	           previously sent to Peer).

4945	   LWd.12  End iteration from LWd.8.

4947	   LWd.13  DONE

4949	 Notes:

4951	      1. If Label is not in forwarding/switching use, LWd.1 has no
4952	         effect.

4954	      2. LWd.7 handles the case where the LSR is using Downstream On
4955	         Demand label distribution with independent control. In this
4956	         situation the LSR should send a label request to the FEC next
4957	         hop as if it had just recognized the FEC.

4959	      3. LWd.10 handles both label merging (one or more incoming labels
4960	         map to the same outgoing label) and no label merging (one label
4961	         maps to the outgoing label) cases.

4963	A.1.6. Recognize New FEC

4965	 Summary:

4967	     The response by an LSR to learning a new FEC via the routing table
4968	     may involve one or more of the following actions:

4970	     - Transmission of label mappings for the FEC to one or more LDP
4971	       peers;

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

4975	     - Any of the actions that can occur when the LSR receives a label
4976	       mapping for the FEC from the FEC next hop.

4978	 Context:

4980	     - LSR. The LSR handling the event.

4982	     - FEC. The newly recognized FEC.

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

4986	     - InitAttributes. Attributes to be associated with the new FEC.
4987	       (See Note 1.)

4989	     - SAttributes. Attributes to be included in Label Mapping or Label
4990	       Request messages, if any, sent to peers.

4992	     - StoredHopCount. Hop count associated with FEC label mapping, if
4993	       any, previously received from Next Hop.

4995	 Algorithm:

4997	   FEC.1   Perform LSR Label Distribution procedure:

4999	             For Downstream Unsolicited Independent Control

5001	               1.  Iterate through 5 for each Peer.

5003	               2.  Has LSR previously received and retained a label
5004	                   mapping for FEC from Next Hop?
5005	                   If so, set Propagating to IsPropagating.
5006	                   If not, set Propagating to NotPropagating.

5008	               3.  Execute procedure Prepare_Label_Mapping_Attributes
5009	                   (Peer, FEC, InitAttributes, SAttributes, Propagating,
5010	                   Unknown hop count(0)).

5012	               4.  Execute procedure Send_Label (Peer, FEC, SAttributes)

5014	               5.  End iteration from 1.
5015	                   Goto FEC.2.

5017	             For Downstream Unsolicited Ordered Control

5019	               1.  Iterate through 5 for each Peer.

5021	               2.  Is LSR egress for the FEC? OR
5022	                   Has LSR previously received and retained a label
5023	                   mapping for FEC from Next Hop?
5024	                   If not, continue iteration for next Peer.

5026	               3.  Execute procedure Prepare_Label_Mapping_Attributes
5027	                   (Peer, FEC, InitAttributes, SAttributes, Propagating,
5028	                   StoredHopCount).

5030	               4.  Execute procedure Send_Label (Peer, FEC, SAttributes)

5032	               5.  End iteration from 1.
5033	                   Goto FEC.2.

5035	             For Downstream On Demand Independent Control OR
5036	             For Downstream On Demand Ordered Control

5038	               1.  Goto FEC.2.  (See Note 2.)

5040	   FEC.2   Has LSR previously received and retained a label mapping for
5041	           FEC from Next Hop?
5042	           If so, goto FEC.5

5044	   FEC.3   Is Next Hop an LDP peer?
5045	           If not, Goto FEC.6

5047	   FEC.4   Perform LSR Label Request procedure:

5049	             For Request Never

5051	               1.  Goto FEC.6

5053	             For Request When Needed OR
5054	             For Request On Request

5056	               1.  Execute procedure Prepare_Label_Request_Attributes
5057	                   (Next Hop, FEC, InitAttributes, SAttributes);

5059	               2.  Execute procedure Send_Label_Request (Next Hop, FEC,
5060	                   SAttributes).
5061	                   Goto FEC.6.

5063	   FEC.5   Generate Event: Received Label Mapping from Next Hop.  (See
5064	           Note 3.)

5066	   FEC.6   DONE.

5068	 Notes:

5070	      1. An example of an attribute that might be part of InitAttributes
5071	         is one which specifies desired LSP characteristics, such as
5072	         class of service (CoS).  (Note that while the current version
5073	         of LDP does not specify a CoS attribute, LDP extensions may.)
5074	         The means by which FEC InitAttributes, if any, are specified is
5075	         beyond the scope of LDP. Note that the InitAttributes will not
5076	         include a known Hop Count or a Path Vector.

5078	      2. An LSR using Downstream On Demand label distribution would send
5079	         a label only if it had a previously received label request
5080	         marked as pending. The LSR would have no such pending requests
5081	         because it responds to any label request for an unknown FEC by
5082	         sending the requesting LSR a No Route notification and
5083	         discarding the label request; see LRq.3

5085	      3. If the LSR has a label for the FEC from the Next Hop, it should
5086	         behave as if it had just received the label from the Next Hop.
5087	         This occurs in the case of Liberal label retention mode.

5089	A.1.7. Detect Change in FEC Next Hop

5091	 Summary:

5093	     The response by an LSR to a change in the next hop for a FEC may
5094	     involve one or more of the following actions:

5096	     - Removal of the label from the FEC's old next hop from
5097	       forwarding/switching use;

5099	     - Transmission of label mapping messages for the FEC to one or more
5100	       LDP peers;

5102	     - Transmission of a label request to the FEC's new next hop;

5104	     - Any of the actions that can occur when the LSR receives a label
5105	       mapping from the FEC's new next hop.

5107	 Context:

5109	     - LSR. The LSR handling the event.

5111	     - FEC. The FEC whose next hop changed.

5113	     - New Next Hop. The current next hop for the FEC.

5115	     - Old Next Hop. The previous next hop for the FEC.

5117	     - OldLabel. Label, if any, previously received from Old Next Hop.

5119	     - CurAttributes. The attributes, if any, currently associated with
5120	       the FEC.

5122	     - SAttributes. Attributes to be included in Label Label Request
5123	       message, if any, sent to New Next Hop.

5125	 Algorithm:

5127	    NH.1   Has LSR previously received and retained a label mapping for
5128	           FEC from Old Next Hop?
5129	           If not, goto NH.6.

5131	    NH.2   Remove label from forwarding/switching use. (See Note 1.)

5133	    NH.3   Is LSR using Liberal label retention?
5134	           If so, goto NH.6.

5136	    NH.4   Execute procedure Send_Message (Old Next Hop, Label Release,
5137	           OldLabel).

5139	    NH.5   Delete label mapping for FEC previously received from Old
5140	           Next Hop.

5142	    NH.6   Does LSR have a label request pending with Old Next Hop?
5143	           If not, goto NH.10.

5145	    NH.7   Is LSR using Conservative label retention?
5146	           If not, goto NH.10.

5148	    NH.8   Execute procedure Send_Message (Old Next Hop, Label Abort
5149	           Request, FEC, TLV), where TLV is a Label Request Message ID
5150	           TLV that carries the message ID of the pending label request.

5152	    NH.9   Record a label abort request is pending for FEC with Old Next
5153	           Hop.

5155	    NH.10  Is there a New Next Hop for the FEC?
5156	           If not, goto NH.16.

5158	    NH.11  Has LSR previously received and retained a label mapping for
5159	           FEC from New Next Hop?
5160	           If not, goto NH.13.

5162	    NH.12  Generate Event: Received Label Mapping from New Next Hop.
5163	           Goto NH.20. (See Note 2.)

5165	    NH.13  Is LSR using Downstream on Demand advertisement? OR
5166	           Is Next Hop using Downstream on Demand advertisement? OR
5167	           Is LSR using Conservative label retention? (See Note 3.)
5168	           If so, goto NH.14.
5169	           If not, goto NH.20.

5171	    NH.14  Execute procedure Prepare_Label_Request_Attributes (Next Hop,
5172	           FEC, CurAttributes, SAttributes)

5174	    NH.15  Execute procedure Send_Label_Request (New Next Hop, FEC,
5175	           SAttributes).  (See Note 4.)
5176	           Goto NH.20.

5178	    NH.16  Iterate through NH.19 for each Peer.

5180	    NH.17  Has LSR previously sent a label mapping for FEC to Peer?
5181	           If not, continue iteration for next Peer at NH.16.

5183	    NH.18  Execute procedure Send_Label_Withdraw (Peer, FEC, Label
5184	           previously sent to Peer).

5186	    NH.19  End iteration from NH.16.

5188	    NH.20  DONE.

5190	 Notes:

5192	      1. If Label is not in forwarding/switching use, NH.2 has no
5193	         effect.

5195	      2. If the LSR has a label for the FEC from the New Next Hop, it
5196	         should behave as if it had just received the label from the New
5197	         Next Hop.

5199	      3. The purpose of the check on label retention mode is to avoid a
5200	         race with steps LMp.12-LMp.13 of the procedure for handling a
5201	         Label Mapping message where the LSR operating in Conservative
5202	         Label retention mode may have released a label mapping received
5203	         from the New Next Hop before it detected the FEC next hop had
5204	         changed.

5206	      4. Regardless of the Label Request procedure in use by the LSR, it
5207	         must send a label request if the conditions in NH.8 hold.
5208	         Therefore it executes the Send_Label_Request procedure directly
5209	         rather than perform LSR Label Request procedure.

5211	A.1.8. Receive Notification / Label Request Aborted

5213	 Summary:

5215	     When an LSR receives a Label Request Aborted notification from an
5216	     LDP peer it records that the corresponding label request
5217	     transaction, if any, has completed.

5219	 Context:

5221	     - LSR. The LSR handling the event.

5223	     - FEC. The FEC for which a label was requested.

5225	     - RequestMessageID. The message ID of the label request message to
5226	       be aborted.

5228	     - MsgSource. The LDP peer that sent the Notification message.

5230	 Algorithm:

5232	   LRqA.1  Does the notification correspond to an outstanding label
5233	           request abort for FEC? (See Note 1).
5234	           If not, goto LRqA.3.

5236	   LRqA.2  Record that the label request for FEC has been aborted.

5238	   LRqA.3  DONE

5240	 Notes:

5242	      1. The LSR uses the FEC and RequestMessageID to locate its record,
5243	         if any, of the outstanding label request abort.

5245	A.1.9. Receive Notification / No Label Resources

5247	 Summary:

5249	     When an LSR receives a No Label Resources notification from an LDP
5250	     peer, it stops sending label request messages to the peer until it
5251	     receives a Label Resources Available Notification from the peer.

5253	 Context:

5255	     - LSR. The LSR handling the event.

5257	     - FEC. The FEC for which a label was requested.

5259	     - MsgSource. The LDP peer that sent the Notification message.

5261	 Algorithm:

5263	   NoRes.1 Delete record of outstanding label request for FEC sent to
5264	           MsgSource.

5266	   NoRes.2 Record label mapping for FEC from MsgSource is needed but
5267	           that no label resources are available.

5269	   NoRes.3 Set status record indicating it is not OK to send label
5270	           requests to MsgSource.

5272	   NoRes.4 DONE.

5274	A.1.10. Receive Notification / No Route

5276	 Summary:

5278	     When an LSR receives a No Route notification from an LDP peer in
5279	     response to a Label Request message, the Label No Route procedure
5280	     in use dictates its response. The LSR either will take no further
5281	     action, or it will defer the label request by starting a timer and
5282	     send another Label Request message to the peer when the timer later
5283	     expires.

5285	 Context:

5287	     - LSR. The LSR handling the event.

5289	     - FEC. The FEC for which a label was requested.

5291	     - Attributes. The attributes associated with the label request.

5293	     - MsgSource. The LDP peer that sent the Notification message.

5295	 Algorithm:

5297	   NoNH.1  Delete record of outstanding label request for FEC sent to
5298	           MsgSource.

5300	   NoNH.2  Perform LSR Label No Route procedure.

5302	             For Request No Retry

5304	               1.  Goto NoNH.3.

5306	             For Request Retry

5308	               1.  Record deferred label request for FEC and Attributes
5309	                   to be sent to MsgSource.

5311	               2.  Start timeout. Goto NoNH.3.

5313	   NoNH.3  DONE.

5315	A.1.11. Receive Notification / Loop Detected

5317	 Summary:

5319	     When an LSR receives a Loop Detected Status Code from an LDP peer
5320	     in response to a Label Request message or a Label Mapping message,
5321	     it behaves as if it had received a No Route notification.

5323	     Context:

5325	         See "Receive Notification / No Route".

5327	     Algorithm:

5329	         See "Receive Notification / No Route"

5331	     Notes:

5333	          1. When the Loop Detected notification is in response to a
5334	             Label Request message, it arrives in a Status Code TLV in a
5335	             Notification message.  When it is in response to a Label
5336	             Mapping message, it arrives in a Status Code TLV in a Label
5337	             Release message.

5339	A.1.12. Receive Notification / Label Resources Available

5341	 Summary:

5343	     When an LSR receives a Label Resources Available notification from
5344	     an LDP peer, it resumes sending label requests to the peer.

5346	 Context:

5348	     - LSR. The LSR handling the event.

5350	     - MsgSource. The LDP peer that sent the Notification message.

5352	     - SAttributes. Attributes stored with postponed Label Request
5353	       message.

5355	 Algorithm:

5357	   Res.1   Set status record indicating it is OK to send label requests
5358	           to MsgSource.

5360	   Res.2   Iterate through Res.6 for each record of a FEC label mapping
5361	           needed from MsgSource for which no label resources are
5362	           available.

5364	   Res.3   Is MsgSource the next hop for FEC?
5365	           If not, goto Res.5.

5367	   Res.4   Execute procedure Send_Label_Request (MsgSource, FEC,
5368	           SAttributes).  If the procedure fails, terminate iteration.

5370	   Res.5   Delete record that no resources are available for a label
5371	           mapping for FEC needed from MsgSource.

5373	   Res.6   End iteration from Res.2

5375	   Res.7   DONE.

5377	A.1.13. Detect local label resources have become available

5379	 Summary:

5381	     After an LSR has sent a No Label Resources notification to an LDP
5382	     peer, when label resources later become available it sends a Label
5383	     Resources Available notification to each such peer.

5385	 Context:

5387	     - LSR. The LSR handling the event.

5389	     - Attributes. Attributes stored with postponed Label Mapping
5390	       message.

5392	 Algorithm:

5394	   ResA.1  Iterate through ResA.4 for each Peer to which LSR has
5395	           previously sent a No Label Resources notification.

5397	   ResA.2  Execute procedure Send_Notification (Peer, Label Resources
5398	           Available)

5400	   ResA.3  Delete record that No Label Resources notification was
5401	           previously sent to Peer.

5403	   ResA.4  End iteration from ResA.1

5405	   ResA.5  Iterate through ResA.8 for each record of a label mapping
5406	           needed for FEC for Peer but no-label-resources.  (See Note
5407	           1.)

5409	   ResA.6  Execute procedure Send_Label (Peer, FEC, Attributes). If the
5410	           procedure fails, terminate iteration.

5412	   ResA.7  Clear record of FEC label mapping needed for peer but no-
5413	           label-resources.

5415	   ResA.8  End iteration from ResA.5

5417	   ResA.9  DONE.

5419	 Notes:

5421	      1. Iteration ResA.5 through ResA.8 handles the situation where the
5422	         LSR is using Downstream Unsolicited label distribution and was
5423	         previously unable to allocate a label for a FEC.

5425	A.1.14. LSR decides to no longer label switch a FEC
5426	 Summary:

5428	     An LSR may unilaterally decide to no longer label switch a FEC for
5429	     an LDP peer. An LSR that does so must send a label withdraw message
5430	     for the FEC to the peer.

5432	 Context:

5434	     - Peer. The peer.

5436	     - FEC. The FEC.

5438	     - PrevAdvLabel. The label for FEC previously advertised to Peer.

5440	 Algorithm:

5442	   NoLS.1  Execute procedure Send_Label_Withdraw (Peer, FEC,
5443	           PrevAdvLabel).  (See Note 1.)

5445	   NoLS.2  DONE.

5447	 Notes:

5449	      1. The LSR may remove the label from forwarding/switching use as
5450	         part of this event or as part of processing the label release
5451	         from the peer in response to the label withdraw.

5453	A.1.15. Timeout of deferred label request

5455	 Summary:

5457	     Label requests are deferred in response to No Route and Loop
5458	     Detected notifications.  When a deferred FEC label request for a
5459	     peer times out, the LSR sends the label request.

5461	 Context:

5463	     - LSR. The LSR handling the event.

5465	     - FEC. The FEC associated with the timeout event.

5467	     - Peer. The LDP peer associated with the timeout event.

5469	     - Attributes. Attributes stored with deferred Label Request
5470	       message.

5472	 Algorithm:

5474	   TO.1    Retrieve the record of the deferred label request.

5476	   TO.2    Is Peer the next hop for FEC?
5477	           If not, goto TO.4.

5479	   TO.3    Execute procedure Send_Label_Request (Peer, FEC).

5481	   TO.4    DONE.

5483	A.2. Common Label Distribution Procedures

5485	   This section specifies utility procedures used by the algorithms that
5486	   handle label distribution events.

5488	A.2.1. Send_Label

5490	 Summary:

5492	     The Send_Label procedure allocates a label for a FEC for an LDP
5493	     peer, if possible, and sends a label mapping for the FEC to the
5494	     peer. If the LSR is unable to allocate the label and if it has a
5495	     pending label request from the peer, it sends the LDP peer a No
5496	     Label Resources notification.

5498	 Parameters:

5500	     - Peer. The LDP peer to which the label mapping is to be sent.

5502	     - FEC. The FEC for which a label mapping is to be sent.

5504	     - Attributes. The attributes to be included with the label mapping.

5506	 Additional Context:

5508	     - LSR. The LSR executing the procedure.

5510	     - Label. The label allocated and sent to Peer.

5512	 Algorithm:

5514	    SL.1   Does LSR have a label to allocate?
5515	           If not, goto SL.9.

5517	    SL.2   Allocate Label and bind it to the FEC.

5519	    SL.3   Install Label for forwarding/switching use.

5521	    SL.4   Execute procedure Send_Message (Peer, Label Mapping, FEC,
5522	           Label, Attributes).

5524	    SL.5   Record label mapping for FEC with Label and Attributes has
5525	           been sent to Peer.

5527	    SL.6   Does LSR have a record of a FEC label request from Peer
5528	           marked as pending?
5529	           If not, goto SL.8.

5531	    SL.7   Delete record of pending label request for FEC from Peer.

5533	    SL.8   Return success.

5535	    SL.9   Does LSR have a label request for FEC from Peer marked as
5536	           pending?
5537	           If not, goto SL.13.

5539	    SL.10  Execute procedure Send_Notification (Peer, No Label
5540	           Resources).

5542	    SL.11  Delete record of pending label request for FEC from Peer.

5544	    SL.12  Record No Label Resources notification has been sent to Peer.
5545	           Goto SL.14.

5547	    SL.13  Record label mapping needed for FEC and Attributes for Peer,
5548	           but no-label-resources. (See Note 1.)

5550	    SL.14  Return failure.

5552	 Notes:

5554	      1. SL.13 handles the case of Downstream Unsolicited label
5555	         distribution when the LSR is unable to allocate a label for a
5556	         FEC to send to a Peer.

5558	A.2.2. Send_Label_Request

5560	 Summary:

5562	     An LSR uses the Send_Label_Request procedure to send a request for
5563	     a label for a FEC to an LDP peer if currently permitted to do so.

5565	 Parameters:

5567	     - Peer. The LDP peer to which the label request is to be sent.

5569	     - FEC. The FEC for which a label request is to be sent.

5571	     - Attributes. Attributes to be included in the label request. E.g.,
5572	       Hop Count, Path Vector.

5574	 Additional Context:

5576	     - LSR. The LSR executing the procedure.

5578	 Algorithm:

5580	   SLRq.1  Has a label request for FEC previously been sent to Peer and
5581	           is it marked as outstanding?
5582	           If so, Return success.  (See Note 1.)

5584	   SLRq.2  Is status record indicating it is OK to send label requests
5585	           to Peer set?
5586	           If not, goto SLRq.6

5588	   SLRq.3  Execute procedure Send_Message (Peer, Label Request, FEC,
5589	           Attributes).

5591	   SLRq.4  Record label request for FEC has been sent to Peer and mark
5592	           it as outstanding.

5594	   SLRq.5  Return success.

5596	   SLRq.6  Postpone the label request by recording label mapping for FEC
5597	           and Attributes from Peer is needed but that no label
5598	           resources are available.

5600	   SLRq.7  Return failure.

5602	 Notes:

5604	      1. If the LSR is a non-merging LSR it must distinguish between
5605	         attempts to send label requests for a FEC triggered by
5606	         different upstream LDP peers from duplicate requests. This
5607	         procedure will not send a duplicate label request.

5609	A.2.3. Send_Label_Withdraw

5611	 Summary:

5613	     An LSR uses the Send_Label_Withdraw procedure to withdraw a label
5614	     for a FEC from an LDP peer. To do this the LSR sends a Label
5615	     Withdraw message to the peer.

5617	 Parameters:

5619	     - Peer. The LDP peer to which the label withdraw is to be sent.

5621	     - FEC. The FEC for which a label is being withdrawn.

5623	     - Label. The label being withdrawn

5625	 Additional Context:

5627	     - LSR. The LSR executing the procedure.

5629	 Algorithm:

5631	    SWd.1  Execute procedure Send_Message (Peer, Label Withdraw, FEC,
5632	           Label)

5634	    SWd.2  Record label withdraw for FEC has been sent to Peer and mark
5635	           it as outstanding.

5637	A.2.4. Send_Notification

5639	 Summary:

5641	     An LSR uses the Send_Notification procedure to send an LDP peer a
5642	     notification message.

5644	 Parameters:

5646	     - Peer. The LDP peer to which the Notification message is to be
5647	       sent.

5649	     - Status. Status code to be included in the Notification message.

5651	 Additional Context:

5653	     None.

5655	 Algorithm:

5657	   SNt.1  Execute procedure Send_Message (Peer, Notification, Status)

5659	A.2.5. Send_Message

5661	 Summary:

5663	     An LSR uses the Send_Message procedure to send an LDP peer an LDP
5664	     message.

5666	 Parameters:

5668	     - Peer. The LDP peer to which the message is to be sent.

5670	     - Message Type. The type of message to be sent.

5672	     - Additional message contents . . .  .

5674	 Additional Context:

5676	     None.

5678	 Algorithm:

5680	     This procedure is the means by which an LSR sends an LDP message of
5681	     the specified type to the specified LDP peer.

5683	A.2.6. Check_Received_Attributes

5685	 Summary:

5687	     Check the attributes received in a Label Mapping or Label Request
5688	     message. If the attributes include a Hop Count or Path Vector,
5689	     perform a loop detection check. If a loop is detected, cause a Loop
5690	     Detected Notification message to be sent to MsgSource.

5692	 Parameters:

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

5696	     - MsgType. The type of message received.

5698	     - RAttributes. The attributes in the message.

5700	 Additional Context:

5702	     - LSR Id. The unique LSR Id of this LSR.

5704	     - Hop Count. The Hop Count, if any, in the received attributes.

5706	     - Path Vector. The Path Vector, if any in the received attributes.

5708	 Algorithm:

5710	   CRa.1   Do RAttributes include Hop Count?
5711	           If not, goto CRa.5.

5713	   CRa.2   Does Hop Count exceed Max allowable hop count?
5714	           If so, goto CRa.6.

5716	   CRa.3   Do RAttributes include Path Vector?
5717	           If not, goto CRa.5.

5719	   CRa.4   Does Path Vector Include LSR Id? OR
5720	           Does length of Path Vector exceed Max allowable length?
5721	           If so, goto CRa.6

5723	   CRa.5   Return No Loop Detected.

5725	   CRa.6   Is MsgType LabelMapping?
5726	           If so, goto CRa.8.  (See Note 1.)

5728	   CRa.7   Execute procedure Send_Notification (MsgSource, Loop
5729	           Detected)

5731	   CRa.8   Return Loop Detected.

5733	   CRa.9   DONE

5735	 Notes:

5737	      1. When the attributes being checked were received in a Label
5738	         Mapping message, the LSR sends the Loop Detected notification
5739	         in a Status Code TLV in a Label Release message.  (See Section
5740	         "Receive Label Mapping").

5742	A.2.7. Prepare_Label_Request_Attributes

5744	 Summary:

5746	     This procedure is used whenever a Label Request is to be sent to a
5747	     Peer to compute the Hop Count and Path Vector, if any, to include
5748	     in the message.

5750	 Parameters:

5752	     - Peer. The LDP peer to which the message is to be sent.

5754	     - FEC. The FEC for which a label request is to be sent.

5756	     - RAttributes. The attributes this LSR associates with the LSP for
5757	       FEC.

5759	     - SAttributes. The attributes to be included in the Label Request
5760	       message.

5762	 Additional Context:

5764	     - LSR Id. The unique LSR Id of this LSR.

5766	 Algorithm:

5768	   PRqA.1  Is Hop Count required for this Peer (see Note 1.) ? OR
5769	           Do RAttributes include a Hop Count? OR
5770	           Is Loop Detection configured on LSR?
5771	           If not, goto PRqA.14.

5773	   PRqA.2  Is LSR ingress for FEC?
5774	           If not, goto PRqA.6.

5776	   PRqA.3  Include Hop Count of 1 in SAttributes.

5778	   PRqA.4  Is Loop Detection configured on LSR?
5779	           If not, goto PRqA.14.

5781	   PRqA.5  Is LSR merge-capable?
5782	           If so, goto PRqA.14.
5783	           If not, goto PRqA.13.

5785	   PRqA.6  Do RAttributes include a Hop Count?
5786	           If not, goto PRqA.8.

5788	   PRqA.7  Increment RAttributes Hop Count and copy the resulting Hop
5789	           Count to SAttributes. (See Note 2.)
5790	           Goto PRqA.9.

5792	   PRqA.8  Include Hop Count of unknown (0) in SAttributes.

5794	   PRqA.9  Is Loop Detection configured on LSR?
5795	           If not, goto PRqA.14.

5797	   PRqA.10 Do RAttributes have a Path Vector?
5798	           If so, goto PRqA.12.

5800	   PRqA.11 Is LSR merge-capable?
5801	           If so, goto PRqA.14.
5802	           If not, goto PRqA.13.

5804	   PRqA.12 Add LSR Id to beginning of Path Vector from RAttributes and
5805	           copy the resulting Path Vector into SAttributes.
5806	           Goto PRqA.14.

5808	   PRqA.13 Include Path Vector of length 1 containing LSR Id in
5809	           SAttributes.

5811	   PRqA.14 DONE.

5813	 Notes:

5815	      1. The link with Peer may require that Hop Count be included in
5816	         Label Request messages; for example, see [ATM] and [FR].

5818	      2. For hop count arithmetic, unknown + 1 = unknown.

5820	A.2.8. Prepare_Label_Mapping_Attributes

5822	 Summary:

5824	     This procedure is used whenever a Label Mapping is to be sent to a
5825	     Peer to compute the Hop Count and Path Vector, if any, to include
5826	     in the message.

5828	 Parameters:

5830	     - Peer. The LDP peer to which the message is to be sent.

5832	     - FEC. The FEC for which a label request is to be sent.

5834	     - RAttributes. The attributes this LSR associates with the LSP for
5835	       FEC.

5837	     - SAttributes. The attributes to be included in the Label Mapping
5838	       message.

5840	     - IsPropagating. The LSR is sending the Label Mapping message to
5841	       propagate one received from the FEC next hop.

5843	     - PrevHopCount. The Hop Count, if any, this LSR associates with the
5844	       LSP for the FEC.

5846	 Additional Context:

5848	     - LSR Id. The unique LSR Id of this LSR.

5850	 Algorithm:

5852	   PMpA.1  Is Hop Count required for this Peer (see Note 1.) ? OR
5853	           Do RAttributes include a Hop Count? OR
5854	           Is Loop Detection configured on LSR?
5855	           If not, goto PMpA.21.

5857	   PMpA.2  Is LSR egress for FEC?
5858	           If not, goto PMpA.4.

5860	   PMpA.3  Include Hop Count of 1 in SAttributes. Goto PMpA.21.

5862	   PMpA.4  Do RAttributes have a Hop Count?
5863	           If not, goto PMpA.8.

5865	   PMpA.5  Is LSR member of edge set for an LSR domain whose LSRs do not
5866	           perform TTL decrement AND
5867	           Is Peer in that domain (See Note 2.).
5868	           If not, goto PMpA.7.

5870	   PMpA.6  Include Hop Count of 1 in SAttributes. Goto PMpA.9.

5872	   PMpA.7  Increment RAttributes Hop Count and copy the resulting Hop
5873	           Count to SAttributes. See Note 2. Goto PMpA.9.

5875	   PMpA.8  Include Hop Count of unknown (0) in SAttributes.

5877	   PMpA.9  Is Loop Detection configured on LSR?
5878	           If not, goto PMpA.21.

5880	   PMpA.10 Do RAttributes have a Path Vector?
5881	           If so, goto PMpA.19.

5883	   PMpA.11 Is LSR propagating a received Label Mapping?
5884	           If not, goto PMpA.20.

5886	   PMpA.12 Does LSR support merging?
5887	           If not, goto PMpA.14.

5889	   PMpA.13 Has LSR previously sent a Label Mapping for FEC to Peer?
5890	           If not, goto PMpA.20.

5892	   PMpA.14 Do RAttributes include a Hop Count?
5893	           If not, goto PMpA.21.

5895	   Res.15 Is Hop Count in Rattributes unknown(0)?
5896	           If so, goto PMpA.20.

5898	   PMpA.16 Has LSR previously sent a Label Mapping for FEC to Peer?
5899	           If not goto PMpA.21.

5901	   PMpA.17 Is Hop Count in RAttributes different from PrevHopCount ?
5902	           If not goto PMpA.21.

5904	   PMpA.18 Is the Hop Count in RAttributes > PrevHopCount? OR
5905	           Is PrevHopCount unknown(0)
5906	           If not, goto PMpA.21.

5908	   PMpA.19 Add LSR Id to beginning of Path Vector from RAttributes and
5909	           copy the resulting Path Vector into SAttributes. Goto
5910	           PMpA.21.

5912	   PMpA.20 Include Path Vector of length 1 containing LSR Id in
5913	           SAttributes.

5915	   PMpA.21 DONE.

5917	 Notes:

5919	      1. The link with Peer may require that Hop Count be included in
5920	         Label Mapping messages; for example, see [ATM] and [FR].

5922	      2. If the LSR is at the edge of a cloud of LSRs that do not
5923	         perform TTL-decrement and it is propagating the Label Mapping
5924	         message upstream into the cloud, it sets the Hop Count to 1 so
5925	         that Hop Count across the cloud is calculated properly.  This
5926	         ensures proper TTL management for packets forwarded across the
5927	         part of the LSP that passes through the cloud.

5929	      3. For hop count arithmetic, unknown + 1 = unknown.