As per Relevance of the word procedure, we have this rfc below:

---

Network Working Group L.
Request for Comments: 3036 Nortel Networks Inc
Category: Standards Track P.
Ennovate
N.
IBM
A.
PhotonEx
B.
Cisco Systems, Inc
January 2001


LDP

Status of this

This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited

Copyright

Copyright (C) The Internet Society (2001). All Rights Reserved



The architecture for Multi Protocol Label Switching (MPLS)
described in RFC 3031. A fundamental concept in MPLS is that
Label Switching Routers (LSRs) must agree on the meaning of
labels used to forward traffic between and through them. This
understanding is achieved by using a set of procedures, called
label distribution protocol, by which one LSR informs another
label bindings it has made. This document defines a set of
procedures called LDP (for Label Distribution Protocol) by which
distribute labels to support MPLS forwarding along normally
paths












Andersson, et al. Standards Track [Page 1]

RFC 3036 LDP Specification January 2001


Table of

1 LDP Overview ....................................... 5
1.1 LDP Peers .......................................... 6
1.2 LDP Message Exchange ............................... 6
1.3 LDP Message Structure .............................. 7
1.4 LDP Error Handling ................................. 7
1.5 LDP Extensibility and Future Compatibility ......... 7
1.6 Specification Language ............................. 7
2 LDP Operation ...................................... 8
2.1 FECs ............................................... 8
2.2 Label Spaces, Identifiers, Sessions and Transport .. 9
2.2.1 Label Spaces ....................................... 9
2.2.2 LDP Identifiers .................................... 10
2.2.3 LDP Sessions ....................................... 10
2.2.4 LDP Transport ...................................... 11
2.3 LDP Sessions between non-Directly Connected LSRs ... 11
2.4 LDP Discovery ..................................... 11
2.4.1 Basic Discovery Mechanism .......................... 12
2.4.2 Extended Discovery Mechanism ....................... 12
2.5 Establishing and Maintaining LDP Sessions .......... 13
2.5.1 LDP Session Establishment .......................... 13
2.5.2 Transport Connection Establishment ................. 13
2.5.3 Session Initialization ............................. 14
2.5.4 Initialization State Machine ....................... 17
2.5.5 Maintaining Hello Adjacencies ...................... 20
2.5.6 Maintaining LDP Sessions ........................... 20
2.6 Label Distribution and Management .................. 21
2.6.1 Label Distribution Control Mode .................... 21
2.6.1.1 Independent Label Distribution Control ............. 21
2.6.1.2 Ordered Label Distribution Control ................. 21
2.6.2 Label Retention Mode ............................... 22
2.6.2.1 Conservative Label Retention Mode .................. 22
2.6.2.2 Liberal Label Retention Mode ....................... 22
2.6.3 Label Advertisement Mode ........................... 23
2.7 LDP Identifiers and Next Hop Addresses ............. 23
2.8 Loop Detection ..................................... 24
2.8.1 Label Request Message .............................. 24
2.8.2 Label Mapping Message .............................. 26
2.8.3 Discussion ......................................... 27
2.9 Authenticity and Integrity of LDP Messages ......... 28
2.9.1 TCP MD5 Signature Option ........................... 28
2.9.2 LDP Use of TCP MD5 Signature Option ................ 30
2.10 Label Distribution for Explicitly Routed LSPs ...... 30
3 Protocol Specification ............................. 31
3.1 LDP PDUs ........................................... 31
3.2 LDP Procedures ..................................... 32
3.3 Type-Length-Value Encoding ......................... 32



Andersson, et al. Standards Track [Page 2]

RFC 3036 LDP Specification January 2001


3.4 TLV Encodings for Commonly Used Parameters ......... 34
3.4.1 FEC TLV ............................................ 34
3.4.1.1 FEC Procedures ..................................... 37
3.4.2 Label TLVs ......................................... 37
3.4.2.1 Generic Label TLV .................................. 37
3.4.2.2 ATM Label TLV ...................................... 38
3.4.2.3 Frame Relay Label TLV .............................. 38
3.4.3 Address List TLV ................................... 39
3.4.4 Hop Count TLV ...................................... 40
3.4.4.1 Hop Count Procedures ............................... 40
3.4.5 Path Vector TLV .................................... 41
3.4.5.1 Path Vector Procedures ............................. 42
3.4.5.1.1 Label Request Path Vector .......................... 42
3.4.5.1.2 Label Mapping Path Vector .......................... 43
3.4.6 Status TLV ......................................... 43
3.5 LDP Messages ....................................... 45
3.5.1 Notification Message ............................... 47
3.5.1.1 Notification Message Procedures .................... 48
3.5.1.2 Events Signaled by Notification Messages ........... 49
3.5.1.2.1 Malformed PDU or Message ........................... 49
3.5.1.2.2 Unknown or Malformed TLV ........................... 50
3.5.1.2.3 Session KeepAlive Timer Expiration ................. 50
3.5.1.2.4 Unilateral Session Shutdown ........................ 51
3.5.1.2.5 Initialization Message Events ...................... 51
3.5.1.2.6 Events Resulting From Other Messages ............... 51
3.5.1.2.7 Internal Errors .................................... 51
3.5.1.2.8 Miscellaneous Events ............................... 51
3.5.2 Hello Message ...................................... 51
3.5.2.1 Hello Message Procedures ........................... 54
3.5.3 Initialization Message ............................. 55
3.5.3.1 Initialization Message Procedures .................. 63
3.5.4 KeepAlive Message .................................. 63
3.5.4.1 KeepAlive Message Procedures ....................... 63
3.5.5 Address Message .................................... 64
3.5.5.1 Address Message Procedures ......................... 64
3.5.6 Address Withdraw Message ........................... 65
3.5.6.1 Address Withdraw Message Procedures ................ 66
3.5.7 Label Mapping Message .............................. 66
3.5.7.1 Label Mapping Message Procedures ................... 67
3.5.7.1.1 Independent Control Mapping ........................ 67
3.5.7.1.2 Ordered Control Mapping ............................ 68
3.5.7.1.3 Downstream on Demand Label Advertisement ........... 68
3.5.7.1.4 Downstream Unsolicited Label Advertisement ......... 69
3.5.8 Label Request Message .............................. 69
3.5.8.1 Label Request Message Procedures ................... 70
3.5.9 Label Abort Request Message ........................ 72
3.5.9.1 Label Abort Request Message Procedures ............. 73
3.5.10 Label Withdraw Message ............................. 74



Andersson, et al. Standards Track [Page 3]

RFC 3036 LDP Specification January 2001


3.5.10.1 Label Withdraw Message Procedures .................. 75
3.5.11 Label Release Message .............................. 76
3.5.11.1 Label Release Message Procedures ................... 77
3.6 Messages and TLVs for Extensibility ................ 78
3.6.1 LDP Vendor-private Extensions ...................... 78
3.6.1.1 LDP Vendor-private TLVs ............................ 78
3.6.1.2 LDP Vendor-private Messages ........................ 80
3.6.2 LDP Experimental Extensions ........................ 81
3.7 Message Summary .................................... 81
3.8 TLV Summary ........................................ 82
3.9 Status Code Summary ................................ 83
3.10 Well-known Numbers ................................. 84
3.10.1 UDP and TCP Ports .................................. 84
3.10.2 Implicit NULL Label ................................ 84
4 IANA Considerations ................................ 84
4.1 Message Type Name Space ............................ 84
4.2 TLV Type Name Space ................................ 85
4.3 FEC Type Name Space ................................ 85
4.4 Status Code Name Space ............................. 86
4.5 Experiment ID Name Space ........................... 86
5 Security Considerations ............................ 86
5.1 Spoofing ........................................... 86
5.2 Privacy ............................................ 87
5.3 Denial of Service .................................. 87
6 Areas for Future Study ............................. 89
7 Intellectual Property Considerations ............... 89
8 Acknowledgments .................................... 89
9 References ......................................... 89
10 Authors' Addresses ................................. 92
Appendix A LDP Label Distribution Procedures .................. 93
A.1 Handling Label Distribution Events ................. 95
A.1.1 Receive Label Request .............................. 96
A.1.2 Receive Label Mapping .............................. 99
A.1.3 Receive Label Abort Request ........................ 105
A.1.4 Receive Label Release .............................. 107
A.1.5 Receive Label Withdraw ............................. 109
A.1.6 Recognize New FEC .................................. 110
A.1.7 Detect Change in FEC Next Hop ...................... 113
A.1.8 Receive Notification / Label Request Aborted ....... 116
A.1.9 Receive Notification / No Label Resources .......... 116
A.1.10 Receive Notification / No Route .................... 117
A.1.11 Receive Notification / Loop Detected ............... 118
A.1.12 Receive Notification / Label Resources Available ... 118
A.1.13 Detect local label resources have become available . 119
A.1.14 LSR decides to no longer label switch a FEC ........ 120
A.1.15 Timeout of deferred label request .................. 121
A.2 Common Label Distribution Procedures ............... 121
A.2.1 Send_Label ......................................... 121



Andersson, et al. Standards Track [Page 4]

RFC 3036 LDP Specification January 2001


A.2.2 Send_Label_Request ................................. 123
A.2.3 Send_Label_Withdraw ................................ 124
A.2.4 Send_Notification .................................. 125
A.2.5 Send_Message ....................................... 125
A.2.6 Check_Received_Attributes .......................... 126
A.2.7 Prepare_Label_Request_Attributes ................... 127
A.2.8 Prepare_Label_Mapping_Attributes ................... 129
Full Copyright Statement ...................................... 132

1. LDP

The MPLS architecture [RFC3031] defines a label distribution
as a set of procedures by which one Label Switched Router (LSR
informs another of the meaning of labels used to forward
between and through them

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

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

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

More information about the applicability of LDP can be found
[RFC3037].

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




Andersson, et al. Standards Track [Page 5]

RFC 3036 LDP Specification January 2001


1.1. LDP

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

1.2. LDP Message

There are four categories of LDP messages

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

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

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

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

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

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

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








Andersson, et al. Standards Track [Page 6]

RFC 3036 LDP Specification January 2001


1.3. LDP Message

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

1.4. LDP Error

LDP errors and other events of interest are signaled to an LDP
by notification messages

There are two kinds of LDP notification messages

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

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

1.5. LDP Extensibility and Future

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

1.6. Specification

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











Andersson, et al. Standards Track [Page 7]

RFC 3036 LDP Specification January 2001


2. LDP

2.1.

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

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

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

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

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

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

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

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

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

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



Andersson, et al. Standards Track [Page 8]

RFC 3036 LDP Specification January 2001


- If a packet matches exactly one LSP, the packet is mapped
that LSP

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

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

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

It is worth pointing out a few consequences of these rules

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

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

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

2.2. Label Spaces, Identifiers, Sessions and

2.2.1. Label

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







Andersson, et al. Standards Track [Page 9]

RFC 3036 LDP Specification January 2001


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

Note that the use of a per interface label space only
sense when the LDP peers are "directly connected" over
interface, and the label is only going to be used for
sent over that interface

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

2.2.2. LDP

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

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

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

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

2.2.3. LDP

LDP sessions exist between LSRs to support label exchange
them

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






Andersson, et al. Standards Track [Page 10]

RFC 3036 LDP Specification January 2001


2.2.4. LDP

LDP uses TCP as a reliable transport for sessions

When multiple LDP sessions are required between two LSRs there
one TCP session for each LDP session

2.3. LDP Sessions between non-Directly Connected

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

For example, consider a "traffic engineering" application where
sends traffic matching some criteria via an LSP to non-
connected LSRb rather than forwarding the traffic along its
routed path

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

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

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

2.4. LDP

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

There are two variants of the discovery mechanism

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

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





Andersson, et al. Standards Track [Page 11]

RFC 3036 LDP Specification January 2001


2.4.1. Basic Discovery

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

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

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

2.4.2. Extended Discovery

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

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

An LDP Targeted Hello sent by an LSR carries the LDP Identifier
the label space the LSR intends to use and possibly
optional information

Extended Discovery differs from Basic Discovery in the
ways

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

- Unlike Basic Discovery, which is symmetric, Extended
is asymmetric

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






Andersson, et al. Standards Track [Page 12]

RFC 3036 LDP Specification January 2001


Receipt of an LDP Targeted Hello identifies a "Hello adjacency"
a potential LDP peer reachable at the network level and the
space the peer intends to use

2.5. Establishing and Maintaining LDP

2.5.1. LDP Session

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

- Transport connection establishment
- Session

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

2.5.2. Transport Connection

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

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

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

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

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

Similarly, address A2 is determined as follows

a. If LSR2 uses the Transport Address optional object, A2
the address LSR2 advertises via the optional object

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




Andersson, et al. Standards Track [Page 13]

RFC 3036 LDP Specification January 2001


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

The procedure for comparing A1 and A2 as unsigned integers is

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

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

Let U2 be the abstract unsigned integer obtained from A2
a similar manner

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

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

Note that when an LSR sends a Hello it selects the transport
for its end of the session connection and uses the Hello to
the address, either explicitly by including it in an
Transport Address TLV or implicitly by omitting the TLV and using
as the Hello source address

An LSR MUST advertise the same transport address in all Hellos
advertise the same label space. This requirement ensures that
LSRs linked by multiple Hello adjacencies using the same label
play the same connection establishment role for each adjacency

2.5.3. Session

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






Andersson, et al. Standards Track [Page 14]

RFC 3036 LDP Specification January 2001


Successful negotiation completes establishment of an LDP
between LSR1 and LSR2 for the advertisement of label spaces LSR1:
and LSR2:b

The following describes the session initialization from LSR1's
of view

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

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

By waiting for the Initialization message from its peer the
LSR can match the label space to be advertised by the peer (
determined from the LDP Identifier in the PDU header for
Initialization message) with a Hello adjacency previously
when Hellos were exchanged

1. When LSR1 plays the passive role

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

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

Next LSR1 checks whether the session parameters proposed
the message are acceptable. If they are, LSR1 replies
an Initialization message of its own to propose
parameters it wishes to use and a KeepAlive message
signal acceptance of LSR2's parameters. If the
are not acceptable, LSR1 responds by sending a
Rejected/Parameters Error Notification message and
the TCP connection

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




Andersson, et al. Standards Track [Page 15]

RFC 3036 LDP Specification January 2001


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

e. If LSR1 receives an Error Notification message, LSR2
rejected its proposed session and LSR1 closes the
connection

2. When LSR1 plays the active role

a. If LSR1 receives an Error Notification message, LSR2
rejected its proposed session and LSR1 closes the
connection

b. If LSR1 receives an Initialization message, it
whether the session parameters are acceptable. If so,
replies with a KeepAlive message. If the session
are unacceptable, LSR1 sends a Session Rejected/
Error Notification message and closes the connection

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

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

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

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

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








Andersson, et al. Standards Track [Page 16]

RFC 3036 LDP Specification January 2001


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

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

2.5.4. Initialization State

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

































Andersson, et al. Standards Track [Page 17]

RFC 3036 LDP Specification January 2001


Session Initialization State Transition

STATE EVENT NEW

NON EXISTENT Session TCP connection established


INITIALIZED Transmit Initialization msg
(Active Role

Receive acceptable
Initialization
(Passive Role )
Action: Transmit
msg and KeepAlive

Receive Any other LDP msg NON
Action: Transmit Error Notification
(NAK) and close transport

OPENREC Receive KeepAlive msg

Receive Any other LDP msg NON
Action: Transmit Error Notification
(NAK) and close transport

OPENSENT Receive acceptable
Initialization
Action: Transmit KeepAlive

Receive Any other LDP msg NON
Action: Transmit Error Notification
(NAK) and close transport

OPERATIONAL Receive Shutdown msg NON
Action: Transmit Shutdown msg
close transport

Receive other LDP msgs

Timeout NON
Action: Transmit Shutdown msg
close transport








Andersson, et al. Standards Track [Page 18]

RFC 3036 LDP Specification January 2001


Session Initialization State Transition

+------------+
| |
+------------>|NON EXISTENT|<--------------------+
| | | |
| +------------+ |
| Session | ^ |
| connection | | |
| established | | Rx any LDP msg except |
| V | Init msg or Timeout |
| +-----------+ |
Rx Any other | | | |
msg or | |INITIALIZED| |
Timeout / | +---| |-+ |
Tx NAK msg | | +-----------+ | |
| | (Passive Role) | (Active Role) |
| | Rx Acceptable | Tx Init msg |
| | Init msg / | |
| | Tx Init msg | |
| | Tx KeepAlive | |
| V msg V |
| +-------+ +--------+ |
| | | | | |
+---|OPENREC| |OPENSENT|----------------->|
+---| | | | Rx Any other msg |
| +-------+ +--------+ or Timeout |
Rx KeepAlive | ^ | Tx NAK msg |
msg | | | |
| | | Rx Acceptable |
| | | Init msg / |
| +----------------+ Tx KeepAlive msg |
| |
| +-----------+ |
+----->| | |
|OPERATIONAL| |
| |---------------------------->+
+-----------+ Rx Shutdown
All other | ^ or Timeout /
LDP msgs | | Tx Shutdown
| |
+---+









Andersson, et al. Standards Track [Page 19]

RFC 3036 LDP Specification January 2001


2.5.5. Maintaining Hello

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

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

LDP includes mechanisms to monitor the necessity of an LDP
and its Hello adjacencies

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

2.5.6. Maintaining LDP

LDP includes mechanisms to monitor the integrity of the LDP session

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

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

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




Andersson, et al. Standards Track [Page 20]

RFC 3036 LDP Specification January 2001


2.6. Label Distribution and

The MPLS architecture [RF3031] allows an LSR to distribute a
label binding in response to an explicit request from another LSR
This is known as Downstream On Demand label distribution. It
allows an LSR to distribute label bindings to LSRs that have
explicitly requested them. [RFC3031] calls this method of
distribution Unsolicited Downstream; this document uses the
Downstream Unsolicited

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

2.6.1. Label Distribution Control

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

2.6.1.1. Independent Label Distribution

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

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

2.6.1.2. Ordered Label Distribution

When using LSP ordered control, an LSR may initiate the
of a label mapping only for a FEC for which it has a label
for the FEC next hop, or for which the LSR is the egress. For
FEC for which the LSR is not the egress and no mapping exists,
LSR MUST wait until a label from a downstream LSR is received
mapping the FEC and passing corresponding labels to upstream LSRs
An LSR may be an egress for some FECs and a non-egress for others
An LSR may act as an egress LSR, with respect to a particular FEC
under any of the following conditions




Andersson, et al. Standards Track [Page 21]

RFC 3036 LDP Specification January 2001


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

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

3. FEC elements are reachable by crossing a routing
boundary, such as another area for OSPF summary networks,
another autonomous system for OSPF AS externals and BGP
[RFC2328] [RFC1771].

Note that whether an LSR is an egress for a given FEC may change
time, depending on the state of the network and LSR
settings

2.6.2. Label Retention

The MPLS architecture [RFC3031] introduces the notion of
retention mode which specifies whether an LSR maintains a
binding for a FEC learned from a neighbor that is not its next
for the FEC

2.6.2.1. Conservative Label Retention

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

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

2.6.2.2. Liberal Label Retention

In Downstream Unsolicited advertisement mode, label
advertisements for all routes may be received from all LDP peers
When using liberal label retention, every label mappings



Andersson, et al. Standards Track [Page 22]

RFC 3036 LDP Specification January 2001


from a peer LSR is retained regardless of whether the LSR is the
hop for the advertised mapping. When operating in Downstream
Demand mode with liberal label retention, an LSR might choose
request label mappings for all known prefixes from all peer LSRs
Note, however, that Downstream on Demand mode is typically used
devices such as ATM switch-based LSRs for which the
approach is recommended

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

2.6.3. Label Advertisement

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

2.7. LDP Identifiers and Next Hop

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

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

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

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





Andersson, et al. Standards Track [Page 23]

RFC 3036 LDP Specification January 2001


An LSR sends an Address message to advertise its addresses to a peer
An LSR sends a Withdraw Address message to withdraw
advertised addresses from a

2.8. Loop

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

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

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

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

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

2.8.1. Label Request

The use of the Path Vector TLV and Hop Count TLV prevent
Request messages from looping in environments that include non-
capable LSRs



Andersson, et al. Standards Track [Page 24]

RFC 3036 LDP Specification January 2001


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

- The Label Request message MUST include a Hop Count TLV

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

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

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

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

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

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

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

If R receives a Label Request message from its next hop with a
Count TLV which exceeds the configured maximum value, or with a
Vector TLV containing its own LSR Id or which exceeds the
allowable length, then R detects that the Label Request message
traveled in a loop

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





Andersson, et al. Standards Track [Page 25]

RFC 3036 LDP Specification January 2001


2.8.2. Label Mapping

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

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

- R MUST include a Hop Count TLV

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

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

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

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

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

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

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

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





Andersson, et al. Standards Track [Page 26]

RFC 3036 LDP Specification January 2001


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

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

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

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

o If the received Label Mapping message included a Path Vector
the Path Vector sent upstream MUST be the result of adding R'
LSR Id to the received Path Vector

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

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

If R receives a Label Mapping message from its next hop with a
Count TLV which exceeds the configured maximum value, or with a
Vector TLV containing its own LSR Id or which exceeds the
allowable length, then R detects that the corresponding LSP
a loop

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

2.8.3.

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

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




Andersson, et al. Standards Track [Page 27]

RFC 3036 LDP Specification January 2001


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

In the case of ordered label distribution, Label Mapping messages
propagated from egress toward ingress, naturally creating the
Vector along the way. In the case of independent label distribution
an LSR may originate a Label Mapping message for an FEC
receiving a Label Mapping message from its downstream peer for
FEC. In this case, the subsequent Label Mapping message for the
received from the downstream peer is treated as an update to
attributes, and the Label Mapping message must be
upstream. Thus, it is recommended that loop detection be
in conjunction with ordered label distribution, to minimize
number of Label Mapping update messages

2.9. Authenticity and Integrity of LDP

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

The mechanism is based on use of the TCP MD5 Signature
specified in [RFC2385] for use by BGP. See [RFC1321] for
specification of the MD5 hash function

2.9.1. TCP MD5 Signature

The following quotes from [RFC2385] outline the security
achieved by using the TCP MD5 Signature Option and summarizes
operation

"IESG

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









Andersson, et al. Standards Track [Page 28]

RFC 3036 LDP Specification January 2001


"

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

"

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

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

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

"MD5 as a Hashing

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

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



Andersson, et al. Standards Track [Page 29]

RFC 3036 LDP Specification January 2001


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