draft-ietf-mpls-ldp-02.txt   draft-ietf-mpls-ldp-03.txt 
Network Working Group Loa Andersson Network Working Group Loa Andersson
Internet Draft Nortel Networks Inc. Internet Draft Nortel Networks Inc.
Expiration Date: May 1999 Expiration Date: July 1999
Paul Doolan Paul Doolan
Ennovate Networks Ennovate Networks
Nancy Feldman Nancy Feldman
IBM Corp IBM Corp
Andre Fredette Andre Fredette
Nortel Networks Inc. Nortel Networks Inc.
Bob Thomas Bob Thomas
Cisco Systems, Inc. Cisco Systems, Inc.
November 1998 January 1999
LDP Specification LDP Specification
draft-ietf-mpls-ldp-02.txt draft-ietf-mpls-ldp-03.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at page 2, line 10 skipping to change at page 2, line 10
An overview of Multi Protocol Label Switching (MPLS) is provided in An overview of Multi Protocol Label Switching (MPLS) is provided in
[FRAMEWORK] and a proposed architecture in [ARCH]. A fundamental [FRAMEWORK] and a proposed architecture in [ARCH]. A fundamental
concept in MPLS is that two Label Switching Routers (LSRs) must agree concept in MPLS is that two Label Switching Routers (LSRs) must agree
on the meaning of the labels used to forward traffic between and on the meaning of the labels used to forward traffic between and
through them. This common understanding is achieved by using the through them. This common understanding is achieved by using the
Label Distribution Protocol (LDP) referenced in [ARCH]. This Label Distribution Protocol (LDP) referenced in [ARCH]. This
document defines the LDP protocol. document defines the LDP protocol.
Changes from Previous Draft Changes from Previous Draft
- This draft removes the explicit path setup mechanism from the - This draft includes by reference the CR-LDP-based and RSVP-based
spec. methods for establishing explicitly routed LSPs.
- This draft removes loop prevention from the spec. The MPLS
working group will continue to evaluate and compare the two
leading contenders for loop prevention: loop prevention via path
vectors and draft-ohba-mpls-loop-prevention-01.txt. We expect
that one of these methods will be selected and added to a later
version of LDP.
- This draft retains and refines the path vector mechanism for
optional loop detection. In addition, it introduces an upper
limit on the size of path vectors.
- This draft specifies parameters for the exponential backup used
to throttle session setup retry attempts. It also specifies a
mechanism for resetting the backoff parameters in response to LSR
configuration changes by adding an optional parameter to the
Hello message.
- This draft adds Appendix "LDP Label Distribution Procedures".
- This draft adds rules for resolving differences in the Label
Distribution Discipline and Merge session parameters exchanged in
the Initialization message.
- This draft modifies message and TLV encodings slightly by adding
explicit specification of LSR behavior when an LSR does not
recognize the message or TLV.
- This draft modifies the encodings for the Initialization and - This draft modifies hop count procedures slightly for Label
Hello messages to group parameters likely to be used together and Mapping messages to correctly support TTL maintenance for packets
to reduce message sizes. It defines some new TLVs for use with traversing LSPs which include multiple clouds of devices which do
these messages and eliminates some previously defined TLVs. not perform 'TTL-decrement'.
- This draft specifies a procedure for negotiating the maximum PDU - This draft removes the E-bit (Null Encapsulation bit) from the
length to be used for a session. ATM Session Parameters TLV used in the Initialization message
because draft-ietf-mpls-atm-01.txt leaves no encapsulation
parameters to negotiate at session setup time.
- This draft simplifies the encodings for the Label Mapping, Label - This draft adds the D-bit, (VC Directionality bit) to the ATM
Request, Label Withdraw and Label Release messages by eliminating Session Paramameters TLV in order to allow interoperability with
the FEC-Label Mapping, FEC-Request, and FEC-Withdraw-Release ATM switches with 'paired' cross connects. When such a switch
TLVs. establishes a VC in one direction, connectivity is established
automatically in the other direction.
- This draft modifies the CoS TLV by specifying that its detailed - This draft specifies the representation of the Implicit NULL
definition is a subject for further study. label [see ARCH].
- This draft adds a Return Message Id optional parameter to the - This draft updates the procedure for the "Detect change in FEC
Label Request message and a Label Request Message Id parameter to next hop" event in order to explicitly address the case where
the Label Mapping message to enable an LSR to match received there is no next hop.
Label Mapping messages with outstanding Label Request messages.
- This draft refines support for vendor-private protocol extensions - This draft expands the PVLim field of the Common Session
and specifies support for experimental protocol extensions. Parameters TLV to allow specification of loop detection path
vector length limits of up to 255.
- This draft specifies optional use of the TCP MD5 Signature Option - This draft corrects several errors of omission (e.g., failure to
to protect against the introduction of spoofed TCP segments into specify certain TLV type codes, failure to note that Frame Relay,
LDP session connection streams. like ATM, requires use of Hop Count TLV in Label Mapping and
Request messages), corrects numerous typos, and includes minor
re-wordings intended to clarify meaning.
Open Issues Open Issues
The following LDP issues are left unresolved with this version of the The following LDP issues are left unresolved with this version of the
spec: spec:
- LDP support for CoS is not completely specified in this version. - LDP support for CoS is not completely specified in this version.
Cos support will be more fully addressed in a future version. Cos support will be more fully addressed in a future version.
- LDP support for multicast is not specified in this version. - LDP support for multicast is not specified in this version.
skipping to change at page 4, line 44 skipping to change at page 4, line 44
2.6.1.2 Ordered Label Distribution Control ................. 21 2.6.1.2 Ordered Label Distribution Control ................. 21
2.6.2 Label Retention Mode ............................... 22 2.6.2 Label Retention Mode ............................... 22
2.6.2.1 Conservative Label Retention Mode .................. 22 2.6.2.1 Conservative Label Retention Mode .................. 22
2.6.2.2 Liberal Label Retention Mode ....................... 22 2.6.2.2 Liberal Label Retention Mode ....................... 22
2.6.3 Label Advertisement Mode ........................... 23 2.6.3 Label Advertisement Mode ........................... 23
2.7 LDP Identifiers and Next Hop Addresses ............. 23 2.7 LDP Identifiers and Next Hop Addresses ............. 23
2.8 Loop Detection ..................................... 24 2.8 Loop Detection ..................................... 24
2.8.1 Label Request Message .............................. 24 2.8.1 Label Request Message .............................. 24
2.8.2 Label Mapping Message .............................. 26 2.8.2 Label Mapping Message .............................. 26
2.8.3 Discussion ......................................... 27 2.8.3 Discussion ......................................... 27
2.9 Label Distribution for Explicitly Routed LSPs ...... 28
3 Protocol Specification ............................. 28 3 Protocol Specification ............................. 28
3.1 LDP PDUs ........................................... 28 3.1 LDP PDUs ........................................... 29
3.2 LDP Procedures ..................................... 29 3.2 LDP Procedures ..................................... 30
3.3 Type-Length-Value Encoding ......................... 30 3.3 Type-Length-Value Encoding ......................... 30
3.4 TLV Encodings for Commonly Used Parameters ......... 31 3.4 TLV Encodings for Commonly Used Parameters ......... 32
3.4.1 FEC TLV ............................................ 31 3.4.1 FEC TLV ............................................ 32
3.4.1.1 FEC Procedures ..................................... 34 3.4.1.1 FEC Procedures ..................................... 34
3.4.2 Label TLVs ......................................... 34 3.4.2 Label TLVs ......................................... 34
3.4.2.1 Generic Label TLV .................................. 34 3.4.2.1 Generic Label TLV .................................. 34
3.4.2.2 ATM Label TLV ...................................... 34 3.4.2.2 ATM Label TLV ...................................... 35
3.4.2.3 Frame Relay Label TLV .............................. 35 3.4.2.3 Frame Relay Label TLV .............................. 36
3.4.3 Address List TLV ................................... 36 3.4.3 Address List TLV ................................... 36
3.4.4 COS TLV ............................................ 37 3.4.4 COS TLV ............................................ 37
3.4.5 Hop Count TLV ...................................... 37 3.4.5 Hop Count TLV ...................................... 38
3.4.5.1 Hop Count Procedures ............................... 38 3.4.5.1 Hop Count Procedures ............................... 38
3.4.6 Path Vector TLV .................................... 38 3.4.6 Path Vector TLV .................................... 39
3.4.6.1 Path Vector Procedures ............................. 39 3.4.6.1 Path Vector Procedures ............................. 40
3.4.6.1.1 Label Request Path Vector .......................... 39 3.4.6.1.1 Label Request Path Vector .......................... 40
3.4.6.1.2 Label Mapping Path Vector .......................... 40 3.4.6.1.2 Label Mapping Path Vector .......................... 41
3.4.7 Status TLV ......................................... 40 3.4.7 Status TLV ......................................... 41
3.5 LDP Messages ....................................... 42 3.5 LDP Messages ....................................... 43
3.5.1 Notification Message ............................... 44 3.5.1 Notification Message ............................... 45
3.5.1.1 Notification Message Procedures .................... 45 3.5.1.1 Notification Message Procedures .................... 46
3.5.1.2 Events Signaled by Notification Messages ........... 45 3.5.1.2 Events Signaled by Notification Messages ........... 46
3.5.1.2.1 Malformed PDU or Message ........................... 46 3.5.1.2.1 Malformed PDU or Message ........................... 47
3.5.1.2.2 Unknown or Malformed TLV ........................... 46 3.5.1.2.2 Unknown or Malformed TLV ........................... 47
3.5.1.2.3 Session Hold Timer Expiration ...................... 47 3.5.1.2.3 Session Hold Timer Expiration ...................... 48
3.5.1.2.4 Unilateral Session Shutdown ........................ 47 3.5.1.2.4 Unilateral Session Shutdown ........................ 48
3.5.1.2.5 Initialization Message Events ...................... 47 3.5.1.2.5 Initialization Message Events ...................... 48
3.5.1.2.6 Events Resulting From Other Messages ............... 47 3.5.1.2.6 Events Resulting From Other Messages ............... 48
3.5.1.2.7 Miscellaneous Events ............................... 48 3.5.1.2.7 Miscellaneous Events ............................... 49
3.5.2 Hello Message ...................................... 48 3.5.2 Hello Message ...................................... 49
3.5.2.1 Hello Message Procedures ........................... 50 3.5.2.1 Hello Message Procedures ........................... 51
3.5.3 Initialization Message ............................. 51 3.5.3 Initialization Message ............................. 52
3.5.3.1 Initialization Message Procedures .................. 58 3.5.3.1 Initialization Message Procedures .................. 60
3.5.4 KeepAlive Message .................................. 59 3.5.4 KeepAlive Message .................................. 60
3.5.4.1 KeepAlive Message Procedures ....................... 59 3.5.4.1 KeepAlive Message Procedures ....................... 60
3.5.5 Address Message .................................... 59 3.5.5 Address Message .................................... 61
3.5.5.1 Address Message Procedures ......................... 60 3.5.5.1 Address Message Procedures ......................... 61
3.5.6 Address Withdraw Message ........................... 61 3.5.6 Address Withdraw Message ........................... 62
3.5.6.1 Address Withdraw Message Procedures ................ 61 3.5.6.1 Address Withdraw Message Procedures ................ 62
3.5.7 Label Mapping Message .............................. 61 3.5.7 Label Mapping Message .............................. 63
3.5.7.1 Label Mapping Message Procedures ................... 63 3.5.7.1 Label Mapping Message Procedures ................... 64
3.5.7.1.1 Independent Control Mapping ........................ 63 3.5.7.1.1 Independent Control Mapping ........................ 64
3.5.7.1.2 Ordered Control Mapping ............................ 64 3.5.7.1.2 Ordered Control Mapping ............................ 65
3.5.7.1.3 Downstream-on-Demand Label Advertisement ........... 64 3.5.7.1.3 Downstream on Demand Label Advertisement ........... 65
3.5.7.1.4 Downstream Unsolicited Label Advertisement ......... 65 3.5.7.1.4 Downstream Unsolicited Label Advertisement ......... 66
3.5.8 Label Request Message .............................. 65 3.5.8 Label Request Message .............................. 66
3.5.8.1 Label Request Message Procedures ................... 66 3.5.8.1 Label Request Message Procedures ................... 67
3.5.9 Label Withdraw Message ............................. 67 3.5.9 Label Withdraw Message ............................. 68
3.5.9.1 Label Withdraw Message Procedures .................. 68 3.5.9.1 Label Withdraw Message Procedures .................. 69
3.5.10 Label Release Message .............................. 69 3.5.10 Label Release Message .............................. 70
3.5.10.1 Label Release Message Procedures ................... 70 3.5.10.1 Label Release Message Procedures ................... 71
3.6 Messages and TLVs for Extensibility ................ 71 3.6 Messages and TLVs for Extensibility ................ 72
3.6.1 LDP Vendor-private Extensions ...................... 71 3.6.1 LDP Vendor-private Extensions ...................... 72
3.6.1.1 LDP Vendor-private TLVs ............................ 71 3.6.1.1 LDP Vendor-private TLVs ............................ 72
3.6.1.2 LDP Vendor-private Messages ........................ 72 3.6.1.2 LDP Vendor-private Messages ........................ 73
3.6.2 LDP Experimental Extensions ........................ 74 3.6.2 LDP Experimental Extensions ........................ 75
3.7 Message Summary .................................... 74 3.7 Message Summary .................................... 75
3.8 TLV Summary ........................................ 75 3.8 TLV Summary ........................................ 76
3.9 Status Code Summary ................................ 76 3.9 Status Code Summary ................................ 77
3.10 UDP and TCP Ports .................................. 76 3.10 Well-known Numbers ................................. 78
4 Security ........................................... 77 3.10.1 UDP and TCP Ports .................................. 78
4.1 The TCP MD5 Signature Option ....................... 77 3.10.2 Implicit NULL Label ................................ 78
4.2 LDP Use of the TCP MD5 Signature Option ............ 78 4 Security ........................................... 78
5 Intellectual Property Considerations ............... 79 4.1 The TCP MD5 Signature Option ....................... 78
6 Acknowledgments .................................... 79 4.2 LDP Use of the TCP MD5 Signature Option ............ 80
7 References ......................................... 79 5 Intellectual Property Considerations ............... 80
8 Author Information ................................. 80 6 Acknowledgments .................................... 80
7 References ......................................... 81
8 Author Information ................................. 82
Appendix.A LDP Label Distribution Procedures .................. 82 Appendix.A LDP Label Distribution Procedures .................. 83
A.1 Handling Label Distribution Events ................. 84 A.1 Handling Label Distribution Events ................. 85
A.1.1 Receive Label Request .............................. 85 A.1.1 Receive Label Request .............................. 86
A.1.2 Receive Label Mapping .............................. 88 A.1.2 Receive Label Mapping .............................. 89
A.1.3 Receive Label Release .............................. 92 A.1.3 Receive Label Release .............................. 93
A.1.4 Receive Label Withdraw ............................. 94 A.1.4 Receive Label Withdraw ............................. 95
A.1.5 Recognize New FEC .................................. 95 A.1.5 Recognize New FEC .................................. 96
A.1.6 Detect change in FEC next hop ...................... 98 A.1.6 Detect change in FEC next hop ...................... 99
A.1.7 Receive Notification / No Label Resources .......... 100 A.1.7 Receive Notification / No Label Resources .......... 101
A.1.8 Receive Notification / No Route .................... 101 A.1.8 Receive Notification / No Route .................... 102
A.1.9 Receive Notification / Loop Detected ............... 102 A.1.9 Receive Notification / Loop Detected ............... 103
A.1.10 Receive Notification / Label Resources Available ... 102 A.1.10 Receive Notification / Label Resources Available ... 103
A.1.11 Detect local label resources have become available . 103 A.1.11 Detect local label resources have become available . 104
A.1.12 LSR decides to no longer label switch a FEC ........ 104 A.1.12 LSR decides to no longer label switch a FEC ........ 105
A.1.13 Timeout of deferred label request .................. 104 A.1.13 Timeout of deferred label request .................. 105
A.2 Common Label Distribution Procedures ............... 105 A.2 Common Label Distribution Procedures ............... 106
A.2.1 Send_Label ......................................... 105 A.2.1 Send_Label ......................................... 106
A.2.2 Send_Label_Request ................................. 107 A.2.2 Send_Label_Request ................................. 108
A.2.3 Send_Label_Withdraw ................................ 108 A.2.3 Send_Label_Withdraw ................................ 109
A.2.4 Send_Notification .................................. 108 A.2.4 Send_Notification .................................. 109
A.2.5 Send_Message ....................................... 109 A.2.5 Send_Message ....................................... 110
A.2.6 Check_Received_Attributes .......................... 109 A.2.6 Check_Received_Attributes .......................... 110
A.2.7 Prepare_Label_Request_Attributes ................... 110 A.2.7 Prepare_Label_Request_Attributes ................... 111
A.2.8 Prepare_Label_Mapping_Attributes ................... 112 A.2.8 Prepare_Label_Mapping_Attributes ................... 113
1. LDP Overview 1. LDP Overview
LDP is the set of procedures and messages by which Label Switched LDP is the set of procedures and messages by which Label Switched
Routers (LSRs) establish Label Switched Paths (LSPs) through a Routers (LSRs) establish Label Switched Paths (LSPs) through a
network by mapping network-layer routing information directly to network by mapping network-layer routing information directly to
data-link layer switched paths. These LSPs may have an endpoint at a data-link layer switched paths. These LSPs may have an endpoint at a
directly attached neighbor (comparable to IP hop-by-hop forwarding), directly attached neighbor (comparable to IP hop-by-hop forwarding),
or may have an endpoint at a network egress node, enabling switching or may have an endpoint at a network egress node, enabling switching
via all intermediary nodes. via all intermediary nodes.
skipping to change at page 8, line 4 skipping to change at page 8, line 4
3. Advertisement messages, used to create, change, and delete 3. Advertisement messages, used to create, change, and delete
label mappings for FECs. label mappings for FECs.
4. Notification messages, used to provide advisory information and 4. Notification messages, used to provide advisory information and
to signal error information. to signal error information.
Discovery messages provide a mechanism whereby LSRs indicate their Discovery messages provide a mechanism whereby LSRs indicate their
presence in a network by sending the Hello message periodically. presence in a network by sending the Hello message periodically.
This is transmitted as a UDP packet to the LDP port at the `all This is transmitted as a UDP packet to the LDP port at the `all
routers' group multicast address. When an LSR chooses to establish a routers on this subnet' group multicast address. When an LSR chooses
session with another LSR learned via the Hello message, it uses the to establish a session with another LSR learned via the Hello
LDP initialization procedure over TCP transport. Upon successful message, it uses the LDP initialization procedure over TCP transport.
completion of the initialization procedure, the two LSRs are LDP Upon successful completion of the initialization procedure, the two
peers, and may exchange advertisement messages. LSRs are LDP peers, and may exchange advertisement messages.
When to request a label or advertise a label mapping to a peer is When to request a label or advertise a label mapping to a peer is
largely a local decision made by an LSR. In general, the LSR largely a local decision made by an LSR. In general, the LSR
requests a label mapping from a neighboring LSR when it needs one, requests a label mapping from a neighboring LSR when it needs one,
and advertises a label mapping to a neighboring LSR when it wishes and advertises a label mapping to a neighboring LSR when it wishes
the neighbor to use a label. the neighbor to use a label.
Correct operation of LDP requires reliable and in order delivery of Correct operation of LDP requires reliable and in order delivery of
messages. To satisfy these requirements LDP uses the TCP transport messages. To satisfy these requirements LDP uses the TCP transport
for session, advertisement and notification messages; i.e., for for session, advertisement and notification messages; i.e., for
everything but the UDP-based discovery mechanism. everything but the UDP-based discovery mechanism.
1.3. LDP Message Structure 1.3. LDP Message Structure
All LDP messages have a common structure that uses a Type- All LDP messages have a common structure that uses a Type-Length-
Length_Value (TLV) encoding scheme; see Section "Type-Length-Value" Value (TLV) encoding scheme; see Section "Type-Length-Value"
encoding. The Value part of a TLV-encoded object, or TLV for short, encoding. The Value part of a TLV-encoded object, or TLV for short,
may itself contain one or more TLVs. may itself contain one or more TLVs.
1.4. LDP Error Handling 1.4. LDP Error Handling
LDP errors and other events of interest are signaled to an LDP peer LDP errors and other events of interest are signaled to an LDP peer
by notification messages. by notification messages.
There are two kinds of LDP notification messages: There are two kinds of LDP notification messages:
skipping to change at page 10, line 20 skipping to change at page 10, line 20
element that is identical to the packet's IP destination address, element that is identical to the packet's IP destination address,
then the packet is mapped to one of those LSPs. The procedure then the packet is mapped to one of those LSPs. The procedure
for selecting one of those LSPs is beyond the scope of this for selecting one of those LSPs is beyond the scope of this
document. document.
- If a packet matches exactly one LSP, the packet is mapped to that - If a packet matches exactly one LSP, the packet is mapped to that
LSP. LSP.
- If a packet matches multiple LSPs, it is mapped to the LSP whose - If a packet matches multiple LSPs, it is mapped to the LSP whose
matching prefix is the longest. If there is no one LSP whose matching prefix is the longest. If there is no one LSP whose
matching prefix is longest, the packet is mapped to one of those matching prefix is longest, the packet is mapped to one from the
LSPs. The procedure for selecting one of those LSPs is beyond set of LSPs whose matching prefix is longer than the others. The
the scope of this document. procedure for selecting one of those LSPs is beyond the scope of
this document.
- If it is known that a packet must traverse a particular egress - If it is known that a packet must traverse a particular egress
router, and there is an LSP which has an IP Address Prefix FEC router, and there is an LSP which has an IP Address Prefix FEC
element (of length 32 bits) which is an address of that router, element (of length 32 bits) which is an address of that router,
then the packet is mapped to that LSP. The procedure for then the packet is mapped to that LSP. The procedure for
obtaining this knowledge is beyond the scope of this document. obtaining this knowledge is beyond the scope of this document.
2.2. Label Spaces, Identifiers, Sessions and Transport 2.2. Label Spaces, Identifiers, Sessions and Transport
2.2.1. Label Spaces 2.2.1. Label Spaces
skipping to change at page 12, line 50 skipping to change at page 12, line 50
are directly connected at the link level. are directly connected at the link level.
- An extended discovery mechanism used to locate LSRs that are not - An extended discovery mechanism used to locate LSRs that are not
directly connected at the link level. directly connected at the link level.
2.4.1. Basic Discovery Mechanism 2.4.1. Basic Discovery Mechanism
To engage in LDP Basic Discovery on an interface an LSR periodically To engage in LDP Basic Discovery on an interface an LSR periodically
sends LDP Link Hellos out the interface. LDP Link Hellos are sent as sends LDP Link Hellos out the interface. LDP Link Hellos are sent as
UDP packets addressed to the well-known LDP discovery port for the UDP packets addressed to the well-known LDP discovery port for the
"all routers" group multicast address. "all routers on this subnet" group multicast address.
An LDP Link Hello sent by an LSR carries the LDP Identifier for the An LDP Link Hello sent by an LSR carries the LDP Identifier for the
label space the LSR intends to use for the interface and possibly label space the LSR intends to use for the interface and possibly
additional information. additional information.
Receipt of an LDP Link Hello on an interface identifies a "Hello Receipt of an LDP Link Hello on an interface identifies a "Hello
adjacency" with a potential LDP peer reachable at the link level on adjacency" with a potential LDP peer reachable at the link level on
the interface as well as the label space the peer intends to use for the interface as well as the label space the peer intends to use for
the interface. the interface.
skipping to change at page 19, line 21 skipping to change at page 19, line 21
| Session | ^ | | Session | ^ |
| connection | | | | connection | | |
| established | | Rx any LDP msg except | | established | | Rx any LDP msg except |
| V | Init msg or Timeout | | V | Init msg or Timeout |
| +-----------+ | | +-----------+ |
Rx Any other | | | | Rx Any other | | | |
msg or | |INITIALIZED| | msg or | |INITIALIZED| |
Timeout / | +---| |-+ | Timeout / | +---| |-+ |
Tx NAK msg | | +-----------+ | | Tx NAK msg | | +-----------+ | |
| | (Passive Role) | (Active Role) | | | (Passive Role) | (Active Role) |
| | Rx Acceptble | Tx Init msg | | | Rx Acceptable | Tx Init msg |
| | Init msg / | | | | Init msg / | |
| | Tx Init msg | | | | Tx Init msg | |
| | Tx KeepAlive | | | | Tx KeepAlive | |
| V msg V | | V msg V |
| +-------+ +--------+ | | +-------+ +--------+ |
| | | | | | | | | | | |
+---|OPENREC| |OPENSENT|----------------->| +---|OPENREC| |OPENSENT|----------------->|
+---| | | | Rx Any other msg | +---| | | | Rx Any other msg |
| +-------+ +--------+ or Timeout | | +-------+ +--------+ or Timeout |
Rx KeepAlive | ^ | Tx NAK msg | Rx KeepAlive | ^ | Tx NAK msg |
skipping to change at page 21, line 19 skipping to change at page 21, line 19
known as Downstream On Demand label distribution. It also allows an known as Downstream On Demand label distribution. It also allows an
LSR to distribute label bindings to LSRs that have not explicitly LSR to distribute label bindings to LSRs that have not explicitly
requested them. This is known as Downstream Unsolicited label requested them. This is known as Downstream Unsolicited label
distribution. distribution.
Both of these label distribution techniques may be used in the same Both of these label distribution techniques may be used in the same
network at the same time. However, for any given LDP session, each network at the same time. However, for any given LDP session, each
LSR must be aware of the label distribution method used by its peer LSR must be aware of the label distribution method used by its peer
in order to avoid situations where one peer using Downstream in order to avoid situations where one peer using Downstream
Unsolicted label distribution assumes its peer is also. See Section Unsolicted label distribution assumes its peer is also. See Section
"Downstream-on-Demand label Advertisement". "Downstream on Demand label Advertisement".
2.6.1. Label Distribution Control Mode 2.6.1. Label Distribution Control Mode
The behavior of the initial setup of LSPs is determined by whether The behavior of the initial setup of LSPs is determined by whether
the LSR is operating with independent or ordered LSP control. An LSR the LSR is operating with independent or ordered LSP control. An LSR
may support both types of control as a configurable option. may support both types of control as a configurable option.
2.6.1.1. Independent Label Distribution Control 2.6.1.1. Independent Label Distribution Control
When using independent LSP control, each LSR may advertise label When using independent LSP control, each LSR may advertise label
mappings to its neighbors at any time it desires. For example, when mappings to its neighbors at any time it desires. For example, when
operating in independent Downstream-on-Demand mode, an LSR may answer operating in independent Downstream on Demand mode, an LSR may answer
requests for label mappings immediately, without waiting for a label requests for label mappings immediately, without waiting for a label
mapping from the next hop. When operating in independent Downstream mapping from the next hop. When operating in independent Downstream
Unsolicited mode, an LSR may advertise a label mapping for a FEC to Unsolicited mode, an LSR may advertise a label mapping for a FEC to
its neighbors whenever it is prepared to label-switch that FEC. its neighbors whenever it is prepared to label-switch that FEC.
A consequence of using independent mode is that an upstream label can A consequence of using independent mode is that an upstream label can
be advertised before a downstream label is received. This can result be advertised before a downstream label is received.
in unlabeled packets being sent to the downstream LSR.
2.6.1.2. Ordered Label Distribution Control 2.6.1.2. Ordered Label Distribution Control
When using LSP ordered control, an LSR may initiate the transmission When using LSP ordered control, an LSR may initiate the transmission
of a label mapping only for a FEC for which it has a label mapping of a label mapping only for a FEC for which it has a label mapping
for the FEC next hop, or for which the LSR is the egress. For each for the FEC next hop, or for which the LSR is the egress. For each
FEC for which the LSR is not the egress and no mapping exists, the FEC for which the LSR is not the egress and no mapping exists, the
LSR MUST wait until a label from a downstream LSR is received before LSR MUST wait until a label from a downstream LSR is received before
mapping the FEC and passing corresponding labels to upstream LSRs. mapping the FEC and passing corresponding labels to upstream LSRs.
skipping to change at page 22, line 29 skipping to change at page 22, line 28
2.6.2. Label Retention Mode 2.6.2. Label Retention Mode
2.6.2.1. Conservative Label Retention Mode 2.6.2.1. Conservative Label Retention Mode
In Downstream Unsolicited advertisement mode, label mapping adver- In Downstream Unsolicited advertisement mode, label mapping adver-
tisements for all routes may be received from all peer LSRs. When tisements for all routes may be received from all peer LSRs. When
using conservative label retention, advertised label mappings are using conservative label retention, advertised label mappings are
retained only if they will be used to forward packets (i.e., if they retained only if they will be used to forward packets (i.e., if they
are received from a valid next hop according to routing). If operat- are received from a valid next hop according to routing). If operat-
ing in Downstream-on-Demand mode, an LSR will request label mappings ing in Downstream on Demand mode, an LSR will request label mappings
only from the next hop LSR according to routing. Since Downstream- only from the next hop LSR according to routing. Since Downstream on
on-Demand mode is primarily used when label conservation is desired Demand mode is primarily used when label conservation is desired
(e.g., an ATM switch with limited cross connect space), it is typi- (e.g., an ATM switch with limited cross connect space), it is typi-
cally used with the conservative label retention mode. cally used with the conservative label retention mode.
The main advantage of the conservative mode is that only the labels The main advantage of the conservative mode is that only the labels
that are required for the forwarding of data are allocated and main- that are required for the forwarding of data are allocated and main-
tained. This is particularly important in LSRs where the label space tained. This is particularly important in LSRs where the label space
is inherently limited, such as in an ATM switch. A disadvantage of is inherently limited, such as in an ATM switch. A disadvantage of
the conservative mode is that if routing changes the next hop for a the conservative mode is that if routing changes the next hop for a
given destination, a new label must be obtained from the new next hop given destination, a new label must be obtained from the new next hop
before labeled packets can be forwarded. before labeled packets can be forwarded.
2.6.2.2. Liberal Label Retention Mode 2.6.2.2. Liberal Label Retention Mode
In Downstream Unsolicited advertisement mode, label mapping adver- In Downstream Unsolicited advertisement mode, label mapping adver-
tisements for all routes may be received from all LDP peers. When tisements for all routes may be received from all LDP peers. When
using liberal label retention, every label mappings received from a using liberal label retention, every label mappings received from a
peer LSR is retained regardless of whether the LSR is the next hop peer LSR is retained regardless of whether the LSR is the next hop
for the advertised mapping. When operating in Downstream-on-Demand for the advertised mapping. When operating in Downstream on Demand
mode with liberal label retention, an LSR might choose to request mode with liberal label retention, an LSR might choose to request
label mappings for all known prefixes from all peer LSRs. Note, how- label mappings for all known prefixes from all peer LSRs. Note,
ever, that Downstream-on-Demand mode is typically used by devices however, that Downstream on Demand mode is typically used by devices
such as ATM switch-based LSRs for which the conservative approach is such as ATM switch-based LSRs for which the conservative approach is
recommended. recommended.
The main advantage of the liberal label retention mode is that reac- The main advantage of the liberal label retention mode is that reac-
tion to routing changes can be quick because labels already exist. tion to routing changes can be quick because labels already exist.
The main disadvantage of the liberal mode is that unneeded label map- The main disadvantage of the liberal mode is that unneeded label map-
pings are distributed and maintained. pings are distributed and maintained.
2.6.3. Label Advertisement Mode 2.6.3. Label Advertisement Mode
Each interface on an LSR is configured to operate in either Down- Each interface on an LSR is configured to operate in either Down-
stream Unsolicited or Downstream-on-Demand advertisement mode. LSRs stream Unsolicited or Downstream on Demand advertisement mode. LSRs
exchange advertisement modes during initialization. The major exchange advertisement modes during initialization. The major
difference between Downstream Unsolicited and Downstream-on-Demand difference between Downstream Unsolicited and Downstream on Demand
modes is in which LSR takes responsibility for initiating mapping modes is in which LSR takes responsibility for initiating mapping
requests and mapping advertisements. requests and mapping advertisements.
2.7. LDP Identifiers and Next Hop Addresses 2.7. LDP Identifiers and Next Hop Addresses
An LSR maintains learned labels in a Label Information Base (LIB). An LSR maintains learned labels in a Label Information Base (LIB).
When operating in Downstream Unsolicited mode, the LIB entry for an When operating in Downstream Unsolicited mode, the LIB entry for an
address prefix associates a collection of (LDP Identifier, label) address prefix associates a collection of (LDP Identifier, label)
pairs with the prefix, one such pair for each peer advertising a pairs with the prefix, one such pair for each peer advertising a
label for the prefix. label for the prefix.
skipping to change at page 23, line 49 skipping to change at page 23, line 48
newly learned label when forwarding packets that match the prefix. newly learned label when forwarding packets that match the prefix.
To make that decision the LSR must be able to map an LDP Identifier To make that decision the LSR must be able to map an LDP Identifier
to the peer's addresses to check whether any are a next hop for the to the peer's addresses to check whether any are a next hop for the
prefix. prefix.
To enable LSRs to map between a peer LDP identifier and the peer's To enable LSRs to map between a peer LDP identifier and the peer's
addresses, LSRs advertise their addresses using LDP Address and With- addresses, LSRs advertise their addresses using LDP Address and With-
draw Address messages. draw Address messages.
An LSR sends an Address message to advertise its addresses to a peer. An LSR sends an Address message to advertise its addresses to a peer.
An LSR sends a Withdraw Address message to withdraw previously An LSR sends a Withdraw Address message to withdraw previously adver-
advertised addresses from a peer tised addresses from a peer
2.8. Loop Detection 2.8. Loop Detection
Loop detection is a configurable option which provides a mechanism Loop detection is a configurable option which provides a mechanism
for finding looping LSPs and for preventing Label Request messages for finding looping LSPs and for preventing Label Request messages
from looping in the presence of non-merge capable LSRs. from looping in the presence of non-merge capable LSRs.
The mechanism makes use of Path Vector and Hop Count TLVs carried by The mechanism makes use of Path Vector and Hop Count TLVs carried by
Label Request and Label Mapping messages. It builds on the following Label Request and Label Mapping messages. It builds on the following
basic properties of these TLVs: basic properties of these TLVs:
skipping to change at page 24, line 41 skipping to change at page 24, line 40
the containing message has traversed a loop. By convention a the containing message has traversed a loop. By convention a
count of 0 is interpreted to mean the hop count is unknown. count of 0 is interpreted to mean the hop count is unknown.
Incrementing an unknown hop count value results in an unknown hop Incrementing an unknown hop count value results in an unknown hop
count value (0). count value (0).
The following paragraphs describes LDP loop detection procedures. In The following paragraphs describes LDP loop detection procedures. In
these paragraphs, "MUST" means "MUST if configured for loop detec- these paragraphs, "MUST" means "MUST if configured for loop detec-
tion". The paragraphs specify messages that must carry Path Vector tion". The paragraphs specify messages that must carry Path Vector
and Hop Count TLVs. Note that the Hop Count TLV and its procedures and Hop Count TLVs. Note that the Hop Count TLV and its procedures
are used without the Path Vector TLV in situations when loop detec- are used without the Path Vector TLV in situations when loop detec-
tion is not configured (see [ATM]). tion is not configured (see [ATM] and [FR]).
2.8.1. Label Request Message 2.8.1. Label Request Message
The use of the Path Vector TLV and Hop Count TLV prevent Label The use of the Path Vector TLV and Hop Count TLV prevent Label
Request messages from looping in environments that include non-merge Request messages from looping in environments that include non-merge
capable LSRs. capable LSRs.
The rules that govern use of the Hop Count TLV in Label Request The rules that govern use of the Hop Count TLV in Label Request mes-
messages by LSR R when Loop Detection is enabled are the following: sages by LSR R when Loop Detection is enabled are the following:
- The Label Request message MUST include a Hop Count TLV. - The Label Request message MUST include a Hop Count TLV.
- If R is sending the Label Request because it is a FEC ingress, it - If R is sending the Label Request because it is a FEC ingress, it
MUST include a Hop Count TLV with hop count value 1. MUST include a Hop Count TLV with hop count value 1.
- If R is sending the Label Request as a result of having received a - If R is sending the Label Request as a result of having received a
Label Request from an upstream LSR, and if the received Label Label Request from an upstream LSR, and if the received Label
Request contains a Hop Count TLV, R MUST increment the received hop Request contains a Hop Count TLV, R MUST increment the received hop
count value by 1 and MUST pass the resulting value in a Hop Count count value by 1 and MUST pass the resulting value in a Hop Count
skipping to change at page 25, line 43 skipping to change at page 25, line 40
Note that if R receives a Label Request message for a particular FEC, Note that if R receives a Label Request message for a particular FEC,
and R has previously sent a Label Request message for that FEC to its and R has previously sent a Label Request message for that FEC to its
next hop and has not yet received a reply, and if R intends to merge next hop and has not yet received a reply, and if R intends to merge
the newly received Label Request with the existing outstanding Label the newly received Label Request with the existing outstanding Label
Request, then R does not propagate the Label Request to the next hop. Request, then R does not propagate the Label Request to the next hop.
If R receives a Label Request message from its next hop with a Hop If R receives a Label Request message from its next hop with a Hop
Count TLV which exceeds the configured maximum value, or with a Path Count TLV which exceeds the configured maximum value, or with a Path
Vector TLV containing its own LSR Id or which exceeds the maximum Vector TLV containing its own LSR Id or which exceeds the maximum
allowable length, then R detects that the Label Reqeust message has allowable length, then R detects that the Label Request message has
traveled in a loop. traveled in a loop.
When R detects a loop, it MUST send a Loop Detected Notification mes- When R detects a loop, it MUST send a Loop Detected Notification mes-
sage to the source of the Label Request message and drop the Label sage to the source of the Label Request message and drop the Label
Request message. Request message.
2.8.2. Label Mapping Message 2.8.2. Label Mapping Message
The use of the Path Vector TLV and Hop Count TLV in the Label Mapping The use of the Path Vector TLV and Hop Count TLV in the Label Mapping
message provide a mechanism to find and terminate looping LSPs. When message provide a mechanism to find and terminate looping LSPs. When
an LSR receives a Label Mapping message from a next hop, the message an LSR receives a Label Mapping message from a next hop, the message
is propagated upstream as specified below until an a ingress LSR is is propagated upstream as specified below until an ingress LSR is
reached or a loop is found. reached or a loop is found.
The rules that govern the use of the Hop Count TLV in Label Mapping The rules that govern the use of the Hop Count TLV in Label Mapping
messages sent by an LSR R when Loop Detection is enabled are the fol- messages sent by an LSR R when Loop Detection is enabled are the fol-
lowing: lowing:
- R MUST include a Hop Count TLV. - R MUST include a Hop Count TLV.
- If R is the egress, the hop count value MUST be 1. - If R is the egress, the hop count value MUST be 1.
- If the Label Mapping message is being sent to propagate a Label - If the Label Mapping message is being sent to propagate a Label
Mapping message received from the next hop to an upstream peer, the Mapping message received from the next hop to an upstream peer, the
hop count value MUST be the result of incrementing the hop count hop count value MUST be determined as follows:
value received from the next hop.
o If R is a member of the edge set of an LSR domain whose LSRs do
not perform 'TTL-decrement' (e.g., an ATM LSR domain or a Frame
Relay LSR domain) and the upstream peer is within that domain, R
MUST reset the hop count to 1 before propagating the message.
o Otherwise, R MUST increment the hop count received from the next
hop before propagating the message.
- If the Label Mapping message is not being sent to propagate a Label - If the Label Mapping message is not being sent to propagate a Label
Mapping message, the hop count value MUST be the result of incre- Mapping message, the hop count value MUST be the result of incre-
menting R's current knowledge of the hop count to the egress. Note menting R's current knowledge of the hop count learned from previ-
that the hop count to the egress will be unknown if R has not ous Label Mapping messages. Note that this hop count value will be
received a Label Mapping message from the next hop. unknown if R has not received a Label Mapping message from the next
hop.
Any Label Mapping message MAY contain a Path Vector TLV. The rules Any Label Mapping message MAY contain a Path Vector TLV. The rules
that govern the mandatory use of the Path Vector TLV in Label Mapping that govern the mandatory use of the Path Vector TLV in Label Mapping
messages sent by LSR R when Loop Detection is enabled are the follow- messages sent by LSR R when Loop Detection is enabled are the follow-
ing: ing:
- If R is the egress, the Label Mapping message need not include a - If R is the egress, the Label Mapping message need not include a
Path Vector TLV. Path Vector TLV.
- If R is sending the Label Mapping message to propagate a Label Map- - If R is sending the Label Mapping message to propagate a Label Map-
skipping to change at page 28, line 10 skipping to change at page 28, line 18
Vector along the way. In the case of independent label distribution, Vector along the way. In the case of independent label distribution,
an LSR may originate a Label Mapping message for an FEC before an LSR may originate a Label Mapping message for an FEC before
receiving a Label Mapping message from its downstream peer for that receiving a Label Mapping message from its downstream peer for that
FEC. In this case, the subsequent Label Mapping message for the FEC FEC. In this case, the subsequent Label Mapping message for the FEC
received from the downstream peer is treated as an update to LSP received from the downstream peer is treated as an update to LSP
attributes, and the Label Mapping message must be propagated attributes, and the Label Mapping message must be propagated
upstream. Thus, it is recommended that loop detection be configured upstream. Thus, it is recommended that loop detection be configured
in conjunction with ordered label distribution, to minimize the in conjunction with ordered label distribution, to minimize the
number of Label Mapping update messages. number of Label Mapping update messages.
If loop detection is desired in some portion of the network, then it If loop detection is desired in an MPLS domain, then it should be
should be turned on in ALL LSRs within that portion of the network, turned on in ALL LSRs within that MPLS domain, else loop detection
else loop detection will not operate properly. will not operate properly.
2.9. Label Distribution for Explicitly Routed LSPs
Traffic Engineering [TE] is expected to be an important MPLS applica-
tion. It uses explicitly routed LSPs, which need not follow
normally-routed (hop-by-hop) paths as determined by destination-based
routing protocols.
Two approaches for establishing explictily routed LSPs are under
development within the MPLS WG. One approach [CRLDP] uses extensions
to LDP to accomplish label distribution; the other [LSPTUN] uses
extensions to RSVP [rfc2205].
3. Protocol Specification 3. Protocol Specification
Previous sections that describe LDP operation have discussed Previous sections that describe LDP operation have discussed
scenarios that involve the exchange of messages among LDP peers. scenarios that involve the exchange of messages among LDP peers.
This section specifies the message encodings and procedures for pro- This section specifies the message encodings and procedures for pro-
cessing the messages. cessing the messages.
LDP message exchanges are accomplished by sending LDP protocol data LDP message exchanges are accomplished by sending LDP protocol data
units (PDUs) over LDP session TCP connections. units (PDUs) over LDP session TCP connections.
skipping to change at page 31, line 31 skipping to change at page 32, line 6
example, there is a Generic Label TLV, an ATM Label TLV, and a Frame example, there is a Generic Label TLV, an ATM Label TLV, and a Frame
Relay TLV; see Sections "Generic Label TLV", "ATM Label TLV", and Relay TLV; see Sections "Generic Label TLV", "ATM Label TLV", and
"Frame Relay TLV". "Frame Relay TLV".
While it is possible to think about TLVs related in this way in terms While it is possible to think about TLVs related in this way in terms
of a TLV type that specifies a TLV class and a TLV subtype that of a TLV type that specifies a TLV class and a TLV subtype that
specifies a particular kind of TLV within that class, this specifica- specifies a particular kind of TLV within that class, this specifica-
tion does not formalize the notion of a TLV subtype. tion does not formalize the notion of a TLV subtype.
The specification assigns type values for related TLVs, such as the The specification assigns type values for related TLVs, such as the
label TLVs, from of a contiguous block in the 16-bit TLV type number label TLVs, from a contiguous block in the 16-bit TLV type number
space. space.
Section "TLV Summary" lists the TLVs defined in this version of the Section "TLV Summary" lists the TLVs defined in this version of the
protocol and the section in this document that describes each. protocol and the section in this document that describes each.
3.4. TLV Encodings for Commonly Used Parameters 3.4. TLV Encodings for Commonly Used Parameters
There are several parameters used by more than one LDP message. The There are several parameters used by more than one LDP message. The
TLV encodings for these commonly used parameters are specified in TLV encodings for these commonly used parameters are specified in
this section. this section.
skipping to change at page 37, line 36 skipping to change at page 38, line 18
ferentiated Services [DIFFSERV] code points. Other CoS values ferentiated Services [DIFFSERV] code points. Other CoS values
could be supported in addition to or in place of the Differentiated could be supported in addition to or in place of the Differentiated
Services code points. Services code points.
3.4.5. Hop Count TLV 3.4.5. Hop Count TLV
The Hop Count TLV appears as an optional field in messages that set The Hop Count TLV appears as an optional field in messages that set
up LSPs. It calculates the number of LSR hops along an LSP as the up LSPs. It calculates the number of LSR hops along an LSP as the
LSP is being setup. LSP is being setup.
Note that setup procedures for LSPs that traverse ATM links require Note that setup procedures for LSPs that traverse ATM and Frame Relay
use of the Hop Count TLV (see [ATM]). links require use of the Hop Count TLV (see [ATM] and [FR]).
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Hop Count (0x0103) | Length | |U|F| Hop Count (0x0103) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HC Value | | HC Value |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
HC Value HC Value
1 octet unsigned integer hop count value. 1 octet unsigned integer hop count value.
3.4.5.1. Hop Count Procedures 3.4.5.1. Hop Count Procedures
During setup of an LSP an LSR may receive a Label Mapping or Label During setup of an LSP an LSR R may receive a Label Mapping or Label
Request message for the LSP that contains the Hop Count TLV. If it Request message for the LSP that contains the Hop Count TLV. If it
does, it should record the hop count value. If the LSR then pro- does, it should record the hop count value.
pagates the Label Mapping message for the LSP to an upstream peer or
the Label Request message to a downstream peer to continue the LSP If LSR R then propagates the Label Mapping message for the LSP to an
setup, it must increment the recorded hop count value and include it upstream peer or the Label Request message to a downstream peer to
in a Hop Count TLV in the message. The first LSR in the LSP should continue the LSP setup, it must must determine a hop count to include
set the hop count value to 1. in the propagated message as follows:
- If the message is a Label Request message, R must increment the
received hop count;
- If the message is a Label Mapping message, R determines the hop
count as follows:
o If R is a member of the edge set of an LSR domain whose LSRs do
not perform 'TTL-decrement' and the upstream peer is within that
domain, R must reset the hop count to 1 before propagating the
message.
o Otherwise, R must increment the received hop count.
The first LSR in the LSP (ingress for a Label Request message, egress
for a Label Mapping message) should set the hop count value to 1.
By convention a value of 0 indicates an unknown hop count. The By convention a value of 0 indicates an unknown hop count. The
result of incrementing an unknown hop count is itself an unknown hop result of incrementing an unknown hop count is itself an unknown hop
count (0). count (0).
If an LSR receives a message containing a Hop Count TLV, it must If an LSR receives a message containing a Hop Count TLV, it must
check the hop count value to determine whether the hop count has check the hop count value to determine whether the hop count has
exceeded its configured maximum allowable value. If so, it must exceeded its configured maximum allowable value. If so, it must
behave as if the containing message has traversed a loop by sending a behave as if the containing message has traversed a loop by sending a
Notification message signaling Loop Detected in reply to the sender Notification message signaling Loop Detected in reply to the sender
skipping to change at page 42, line 5 skipping to change at page 43, line 5
A Status Code of 0 signals success. A Status Code of 0 signals success.
Message ID Message ID
If non-zero, 32-bit value that identifies the peer message to which If non-zero, 32-bit value that identifies the peer message to which
the Status TLV refers. If zero, no specific peer message is being the Status TLV refers. If zero, no specific peer message is being
identified. identified.
Message Type Message Type
If non-zero, the type of the peer message to which the Status TLV If non-zero, the type of the peer message to which the Status TLV
refers. If zero, the Status TLV does not refer to any specific refers. If zero, the Status TLV does not refer to any specific
peer message. message type.
3.5. LDP Messages 3.5. LDP Messages
All LDP messages have the following format: All LDP messages have the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| Message Type | Message Length | |U| Message Type | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 43, line 45 skipping to change at page 44, line 45
Label Withdraw "Label Withdraw Message" Label Withdraw "Label Withdraw Message"
Label Release "Label Release Message" Label Release "Label Release Message"
The sections that follow specify the encodings and procedures for The sections that follow specify the encodings and procedures for
these messages. these messages.
Some of the above messages are related to one another, for example Some of the above messages are related to one another, for example
the Label Mapping, Label Request, Label Withdraw, and Label Release the Label Mapping, Label Request, Label Withdraw, and Label Release
messages. messages.
While is possible to think about messages related in this way in While it is possible to think about messages related in this way in
terms of a message type that specifies a message class and a message terms of a message type that specifies a message class and a message
subtype that specifies a particular kind of message within that subtype that specifies a particular kind of message within that
class, this specification does not formalize the notion of a message class, this specification does not formalize the notion of a message
subtype. subtype.
The specification assigns type values for related messages, such as The specification assigns type values for related messages, such as
the label messages, from of a contiguous block in the 16-bit message the label messages, from of a contiguous block in the 16-bit message
type number space. type number space.
3.5.1. Notification Message 3.5.1. Notification Message
skipping to change at page 46, line 23 skipping to change at page 47, line 23
- The LDP Identifier in the PDU header is unknown to the receiver, - The LDP Identifier in the PDU header is unknown to the receiver,
or it is known but is not the LDP Identifier associated by the or it is known but is not the LDP Identifier associated by the
receiver with the LDP session. This is a fatal error signaled by receiver with the LDP session. This is a fatal error signaled by
the Bad LDP Identifier Status Code. the Bad LDP Identifier Status Code.
- The LDP protocol version is not supported by the receiver, or it - The LDP protocol version is not supported by the receiver, or it
is supported but is not the version negotiated for the session is supported but is not the version negotiated for the session
during session establishment. This is a fatal error signaled by during session establishment. This is a fatal error signaled by
the Bad Protocol Version Status Code. the Bad Protocol Version Status Code.
- The PDU Length field is too short (< 20) or too long - The PDU Length field is too short (< 18) or too long
(> maximum PDU length). This is a fatal error signaled by the (> maximum PDU length). This is a fatal error signaled by the
Bad PDU Length Status Code. Section "Initialization Message" Bad PDU Length Status Code. Section "Initialization Message"
describes how the maximum PDU length for a session is determined. describes how the maximum PDU length for a session is determined.
An LDP Message is malformed if: An LDP Message is malformed if:
- The Message Type is unknown. - The Message Type is unknown.
If the Message Type is < 0x8000 (high order bit = 0) it is a If the Message Type is < 0x8000 (high order bit = 0) it is a
fatal error signaled by the Unknown Message Type Status Code. fatal error signaled by the Unknown Message Type Status Code.
skipping to change at page 52, line 20 skipping to change at page 53, line 20
The encoding for the Common Session Parameters TLV is: The encoding for the Common Session Parameters TLV is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Common Sess Parms (0x0500)| Length | |U|F| Common Sess Parms (0x0500)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Version | Hold Time | | Protocol Version | Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|D| PVLim | Reserved | Max PDU Length | |A|D| Reserved | PVLim | Max PDU Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver LDP Identifer | | Receiver LDP Identifer |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++
Protocol Version Protocol Version
Two octet unsigned integer containing the version number of the Two octet unsigned integer containing the version number of the
protocol. This version of the specification specifies LDP pro- protocol. This version of the specification specifies LDP pro-
tocol version 1. tocol version 1.
skipping to change at page 54, line 36 skipping to change at page 55, line 36
ATM Session Parameters ATM Session Parameters
Used when an LDP session manages label exchange for an ATM link Used when an LDP session manages label exchange for an ATM link
to specify ATM-specific session parameters. to specify ATM-specific session parameters.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| ATM Sess Parms (0x0501) | Length | |U|F| ATM Sess Parms (0x0501) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| M | N |E| Reserved | | M | N |D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATM Label Range Component 1 | | ATM Label Range Component 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATM Label Range Component N | | ATM Label Range Component N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 55, line 17 skipping to change at page 56, line 17
0 Merge not supported 0 Merge not supported
1 VP Merge supported 1 VP Merge supported
2 VC Merge supported 2 VC Merge supported
3 VP & VC Merge supported 3 VP & VC Merge supported
If the merge capabilities of the LSRs differ, then: If the merge capabilities of the LSRs differ, then:
- Non-merge and VC-merge LSRs may freely interoperate. - Non-merge and VC-merge LSRs may freely interoperate.
- The interoperability of VP-merge-capable switches with - The interoperability of VP-merge-capable switches with
non-VPN-merge-capable switches is a subject for future non-VP-merge-capable switches is a subject for future
study. study.
Note that if VP merge is used, it is the responsibility of the Note that if VP merge is used, it is the responsibility of the
ingress node to ensure that the chosen VCI is unique within the ingress node to ensure that the chosen VCI is unique within the
LSR domain. LSR domain.
N, Number of label range components N, Number of label range components
Specifies the number of ATM Label Range Components included in Specifies the number of ATM Label Range Components included in
the TLV. the TLV.
E, ATM Null Encapsulation D, VC Directionality
A value of 1 specifies specifies that the LSR supports the null A value of 0 specifies bidirectional VC capability, meaning the
encapsulation of [rfc1483] for its data VCs on the ATM link LSR can (within a given VPI) support the use of a given VCI as
managed by the LDP session. In this case IP packets are car- a label for both link directions independently. A value of 1
ried directly inside AAL5 frames. A value of 0 specifies that specifies unidirectional VC capability, meaning (within a given
the null encapsulation is not supported. VPI) a given VCI may appear in a label mapping for one direc-
tion on the link only. When either or both of the peers speci-
fies unidirectional VC capability, both LSRs use unidirectional
VC label assignement for the link as follows. The LSRs compare
their LDP Identifiers as unsigned integers. The LSR with the
larger LDP Identifier may assign only odd-numbered VCIs in the
VPI/VCI range as labels. The system with the smaller LDP Iden-
tifier may assign only even-numbered VCIs in the VPI/VCI range
as labels.
Reserved Reserved
This field is reserved. It must be set to zero on transmission This field is reserved. It must be set to zero on transmission
and ignored on receipt. and ignored on receipt.
One or more ATM Label Range Components One or more ATM Label Range Components
A list of ATM Label Range Components which together specify the A list of ATM Label Range Components which together specify the
Label range supported by the transmitting LSR. Label range supported by the transmitting LSR.
A receiving LSR MUST calculate the intersection between the A receiving LSR MUST calculate the intersection between the
received range and its own supported label range. The inter- received range and its own supported label range. The
section is the range in which the LSR may allocate and accept intersection is the range in which the LSR may allocate and
labels. LSRs MUST NOT establish a session with neighbors for accept labels. LSRs MUST NOT establish a session with neigh-
which the intersection of ranges is NULL. In this case, the bors for which the intersection of ranges is NULL. In this
LSR must send a Session Rejected/Parameters Label Range Notifi- case, the LSR must send a Session Rejected/Parameters Label
cation message in response to the Initialization message and Range Notification message in response to the Initialization
not establish the session. message and not establish the session.
The encoding for an ATM Label Range Component is: The encoding for an ATM Label Range Component is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res | Minimum VPI | Minimum VCI | | Res | Minimum VPI | Minimum VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res | Maximum VPI | Maximum VCI | | Res | Maximum VPI | Maximum VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 58, line 48 skipping to change at page 60, line 8
Data Link Connection Identifiers (DLCIs) that is supported on Data Link Connection Identifiers (DLCIs) that is supported on
the originating switch. The DLCI should be right justified the originating switch. The DLCI should be right justified
in this field and unused bits should be set to 0. in this field and unused bits should be set to 0.
Note that there is no Generic Session Parameters TLV for sessions Note that there is no Generic Session Parameters TLV for sessions
which advertise Generic Labels. which advertise Generic Labels.
3.5.3.1. Initialization Message Procedures 3.5.3.1. Initialization Message Procedures
See Section "LDP Session Establishment" and particularly Section See Section "LDP Session Establishment" and particularly Section
"Session Initialization" for general procedures for handling the "Session Initialization" for general procedures for handling the Ini-
Initialization Message. tialization Message.
3.5.4. KeepAlive Message 3.5.4. KeepAlive Message
An LSR sends KeepAlive Messages as part of a mechanism that monitors An LSR sends KeepAlive Messages as part of a mechanism that monitors
the integrity of the LDP session transport connection. the integrity of the LDP session transport connection.
The encoding for the KeepAlive Message is: The encoding for the KeepAlive Message is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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
skipping to change at page 62, line 37 skipping to change at page 63, line 44
Specifies the Label component of the FEC-Label mapping. See Sec- Specifies the Label component of the FEC-Label mapping. See Sec-
tion "Label TLV" for encoding. tion "Label TLV" for encoding.
Optional Parameters Optional Parameters
This variable length field contains 0 or more parameters, each This variable length field contains 0 or more parameters, each
encoded as a TLV. The optional parameters are: encoded as a TLV. The optional parameters are:
Optional Parameter Length Value Optional Parameter Length Value
Label Request 4 See below Label Request 4 See below
Message Id Message Id TLV
COS TLV 1 See below COS TLV 1 See below
Hop Count TLV 1 See below Hop Count TLV 1 See below
Path Vector TLV variable See below Path Vector TLV variable See below
The encodings for the COS, Hop Count, and Path Vector TLVs can be The encodings for the COS, Hop Count, and Path Vector TLVs can be
found in Section "TLV Encodings for Commonly Used Parameters". found in Section "TLV Encodings for Commonly Used Parameters".
Label Request Message Id Label Request Message Id
If this Label Mapping message is a response to a Label Request If this Label Mapping message is a response to a Label Request
message that carried the Return Message Id optional parameter message that carried the Return Message Id optional parameter
skipping to change at page 64, line 34 skipping to change at page 65, line 40
3. The next hop for a FEC changes to another LDP peer, and loop 3. The next hop for a FEC changes to another LDP peer, and loop
detection is configured. detection is configured.
4. The attributes of a mapping change. 4. The attributes of a mapping change.
5. The receipt of a mapping from the downstream next hop AND 5. The receipt of a mapping from the downstream next hop AND
a) no upstream mapping has been created OR a) no upstream mapping has been created OR
b) loop detection is configured OR b) loop detection is configured OR
c) the attributes of the mapping have changed. c) the attributes of the mapping have changed.
3.5.7.1.3. Downstream-on-Demand Label Advertisement 3.5.7.1.3. Downstream on Demand Label Advertisement
In general, the upstream LSR is responsible for requesting label map- In general, the upstream LSR is responsible for requesting label map-
pings when operating in Downstream-on-Demand mode. However, unless pings when operating in Downstream on Demand mode. However, unless
some rules are followed, it is possible for neighboring LSRs with some rules are followed, it is possible for neighboring LSRs with
different advertisement modes to get into a livelock situation where different advertisement modes to get into a livelock situation where
everything is functioning properly, but no labels are distributed. everything is functioning properly, but no labels are distributed.
For example, consider two LSRs Ru and Rd where Ru is the upstream LSR For example, consider two LSRs Ru and Rd where Ru is the upstream LSR
and Rd is the downstream LSR for a particular FEC. In this example, and Rd is the downstream LSR for a particular FEC. In this example,
Ru is using Downstream Unsolicited advertisement mode and Rd is using Ru is using Downstream Unsolicited advertisement mode and Rd is using
Downstream-on-Demand mode. In this case, Rd may assume that Ru will Downstream on Demand mode. In this case, Rd may assume that Ru will
request a label mapping when it wants one and Ru may assume that Rd request a label mapping when it wants one and Ru may assume that Rd
will advertise a label if it wants Ru to use one. If Rd and Ru will advertise a label if it wants Ru to use one. If Rd and Ru
operate as suggested, no labels will be distributed from Rd to Ru. operate as suggested, no labels will be distributed from Rd to Ru.
This livelock situation can be avoided if the following rule is This livelock situation can be avoided if the following rule is
observed: an LSR operating in Downstream-on-Demand mode should not be observed: an LSR operating in Downstream on Demand mode should not be
expected to send unsolicited mapping advertisements. Therefore, if expected to send unsolicited mapping advertisements. Therefore, if
the downstream LSR is operating in Downstream-on-Demand mode, the the downstream LSR is operating in Downstream on Demand mode, the
upstream LSR is responsible for requesting label mappings as needed. upstream LSR is responsible for requesting label mappings as needed.
3.5.7.1.4. Downstream Unsolicited Label Advertisement 3.5.7.1.4. Downstream Unsolicited Label Advertisement
In general, the downstream LSR is responsible for advertising a label In general, the downstream LSR is responsible for advertising a label
mapping when it wants an upstream LSR to use the label. An upstream mapping when it wants an upstream LSR to use the label. An upstream
LSR may issue a mapping request if it so desires. LSR may issue a mapping request if it so desires.
3.5.8. Label Request Message 3.5.8. Label Request Message
skipping to change at page 65, line 46 skipping to change at page 67, line 7
FEC TLV FEC TLV
The FEC for which a label is being requested. See Section "FEC The FEC for which a label is being requested. See Section "FEC
TLV" for encoding. TLV" for encoding.
Optional Parameters Optional Parameters
This variable length field contains 0 or more parameters, each This variable length field contains 0 or more parameters, each
encoded as a TLV. The optional parameters are: encoded as a TLV. The optional parameters are:
Optional Parameter Length Value Optional Parameter Length Value
Return Message Id 0 See below Return Message Id TLV 0 See below
COS TLV 1 See below COS TLV 1 See below
Hop Count TLV 1 See below Hop Count TLV 1 See below
Path Vector TLV variable See below Path Vector TLV variable See below
The encodings for the COS, Hop Count, and Path Vector TLVs can be The encodings for the COS, Hop Count, and Path Vector TLVs can be
found in Section "TLV Encodings for Commonly Used Parameters". found in Section "TLV Encodings for Commonly Used Parameters".
Return Message Id Return Message Id
Requests the LDP peer include the Message Id of this Label Requests the LDP peer include the Message Id of this Label
Request message in its Label Mapping message response. If an Request message in its Label Mapping message response. If an
skipping to change at page 67, line 17 skipping to change at page 68, line 20
already have a mapping from the next hop. already have a mapping from the next hop.
The receiving LSR should respond to a Label Request message with a The receiving LSR should respond to a Label Request message with a
Label Mapping for the requested label or with a Notification message Label Mapping for the requested label or with a Notification message
indicating why it cannot satisfy the request. indicating why it cannot satisfy the request.
This version of the protocol defines the following Status Codes for This version of the protocol defines the following Status Codes for
the Notification message that signals a request cannot be satisfied: the Notification message that signals a request cannot be satisfied:
No Route No Route
The FEC for which a label was requested is for a Prefix FEC Ele- The FEC for which a label was requested includes a FEC Element
ment, and the LSR does not have a route for that prefix. for which the LSR does not have a route.
No Label Resources No Label Resources
The LSR cannot provide a label because of resource limitations. The LSR cannot provide a label because of resource limitations.
When resources become available the LSR must notify the request- When resources become available the LSR must notify the request-
ing LSR by sending a Notification message with the Label ing LSR by sending a Notification message with the Label
Resources Available Status Code. Resources Available Status Code.
An LSR that receives a No Label Resources response to a Label An LSR that receives a No Label Resources response to a Label
Request message must not issue further Label Request messages Request message must not issue further Label Request messages
until it receives a Notification message with the Label Resources until it receives a Notification message with the Label Resources
skipping to change at page 75, line 17 skipping to change at page 76, line 17
Notification 0x0001 "Notification Message" Notification 0x0001 "Notification Message"
Hello 0x0100 "Hello Message" Hello 0x0100 "Hello Message"
Initialization 0x0200 "Initialization Message" Initialization 0x0200 "Initialization Message"
KeepAlive 0x0201 "KeepAlive Message" KeepAlive 0x0201 "KeepAlive Message"
Address 0x0300 "Address Message" Address 0x0300 "Address Message"
Address Withdraw 0x0301 "Address Withdraw Message" Address Withdraw 0x0301 "Address Withdraw Message"
Label Mapping 0x0400 "Label Mapping Message" Label Mapping 0x0400 "Label Mapping Message"
Label Request 0x0401 "Label Request Message" Label Request 0x0401 "Label Request Message"
Label Withdraw 0x0402 "Label Withdraw Message" Label Withdraw 0x0402 "Label Withdraw Message"
Label Release 0x0403 "Label Release Message" Label Release 0x0403 "Label Release Message"
Vendor-Private 0x2F00-0x2FFF Vendor-Private 0x2F00- "LDP Vendor-private Extensions"
Experimental 0x3F00-0x3FFF 0x2FFF
Experimental 0x3F00- "LDP Experimental Extensions"
0x3FFF
3.8. TLV Summary 3.8. TLV Summary
The following are the TLVs defined in this version of the protocol. The following are the TLVs defined in this version of the protocol.
TLV Type Section Title TLV Type Section Title
FEC 0x0100 "FEC TLV" FEC 0x0100 "FEC TLV"
Address List 0x0101 "Address List TLV" Address List 0x0101 "Address List TLV"
COS 0x0102 "COS TLV" COS 0x0102 "COS TLV"
skipping to change at page 75, line 48 skipping to change at page 77, line 4
Common Hello 0x0400 "Hello Message" Common Hello 0x0400 "Hello Message"
Parameters Parameters
Transport Address 0x0401 "Hello Message" Transport Address 0x0401 "Hello Message"
Configuration 0x0402 "Hello Message" Configuration 0x0402 "Hello Message"
Sequence Number Sequence Number
Common Session 0x0500 "Initialization Message" Common Session 0x0500 "Initialization Message"
Parameters Parameters
ATM Session Parameters 0x0501 "Initialization Message" ATM Session Parameters 0x0501 "Initialization Message"
Frame Relay Session 0x0502 "Initialization Message" Frame Relay Session 0x0502 "Initialization Message"
Parameters Parameters
Vendor-Private 0x2F00-0x2FFF Label Request 0x0600 "Label Request Message"
Experimental 0x3F00-0x3FFF Message Id
Return Message Id 0x0601 "Label Mapping Message"
Vendor-Private 0x2F00- "LDP Vendor-private Extensions"
0x2FFF
Experimental 0x3F00- "LDP Experimental Extensions"
0x3FFF
3.9. Status Code Summary 3.9. Status Code Summary
The following are the Status Codes defined in this version of the The following are the Status Codes defined in this version of the
protocol. protocol.
Status Code Type Section Title Status Code Type Section Title
Success 0x00000000 "Status TLV" Success 0x00000000 "Status TLV"
Bad LDP Identifer 0x80000001 "Events Signaled by ..." Bad LDP Identifer 0x80000001 "Events Signaled by ..."
skipping to change at page 76, line 37 skipping to change at page 78, line 5
Label Resources Available 0x0000000F "Label Request Mess ..." Label Resources Available 0x0000000F "Label Request Mess ..."
Session Rejected/ 0x80000010 "Session Initialization" Session Rejected/ 0x80000010 "Session Initialization"
No Hello No Hello
Session Rejected/ 0x80000011 "Session Initialization" Session Rejected/ 0x80000011 "Session Initialization"
Parameters Advertisement Mode Parameters Advertisement Mode
Session Rejected/ 0x80000012 "Session Initialization" Session Rejected/ 0x80000012 "Session Initialization"
Parameters Max PDU Length Parameters Max PDU Length
Session Rejected/ 0x80000013 "Session Initialization" Session Rejected/ 0x80000013 "Session Initialization"
Parameters Label Range Parameters Label Range
3.10. UDP and TCP Ports 3.10. Well-known Numbers
3.10.1. UDP and TCP Ports
The UDP port for LDP Hello messages is 646. The UDP port for LDP Hello messages is 646.
The TCP port for establishing LDP session connections is 646. The TCP port for establishing LDP session connections is 646.
3.10.2. Implicit NULL Label
The Implicit NULL label (see [ARCH]) is represented as a Generic
Label TLV with a Label field of 0.
4. Security 4. Security
This section specifies an optional mechanism to protect against the This section specifies an optional mechanism to protect against the
introduction of spoofed TCP segments into LDP session connection introduction of spoofed TCP segments into LDP session connection
streams. streams.
It is based on use of the TCP MD5 Signature Option specified in It is based on use of the TCP MD5 Signature Option specified in
[rfc2385] for use by BGP. See [rfc1321] for a specification of the [rfc2385] for use by BGP. See [rfc1321] for a specification of the
MD5 hash function. MD5 hash function.
skipping to change at page 79, line 33 skipping to change at page 81, line 8
6. Acknowledgments 6. Acknowledgments
The ideas and text in this document have been collected from a number The ideas and text in this document have been collected from a number
of sources. We would like to thank Rick Boivie, Ross Callon, Alex of sources. We would like to thank Rick Boivie, Ross Callon, Alex
Conta, Eric Gray, Yoshihiro Ohba, Eric Rosen, Bernard Suter, Yakov Conta, Eric Gray, Yoshihiro Ohba, Eric Rosen, Bernard Suter, Yakov
Rekhter, and Arun Viswanathan. Rekhter, and Arun Viswanathan.
7. References 7. References
[ARCH] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label [ARCH] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label
Switching Architecture", draft-ietf-mpls-arch-02.txt, July 1998 Switching Architecture", Work in Progress, July 1998.
[ATM] B. Davie, J. Lawrence, K. McCloghrie, Y. Rekhter, E. Rosen, G. [ATM] B. Davie, J. Lawrence, K. McCloghrie, Y. Rekhter, E. Rosen, G.
Swallow, P. Doolan, "Use of Label Switching With ATM", draft-ietf- Swallow, P. Doolan, "Use of Label Switching With ATM", Work in Pro-
mpls-atm-00.txt, September, 1998 gress, September, 1998.
[CRLDP] L. Andersson, A. Fredette, B. Jamoussi, R. Callon, P. Doolan,
N. Feldman, E. Gray, J. Halpern, J. Heinanen T. E. Kilty, A. G.
Malis, M. Girish, K. Sundell, P. Vaananen, T. Worster, L. Wu, R.
Dantu, "Constraint-Based LSP Setup using LDP", Work in Progress,
January, 1999.
[DIFFSERV] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. [DIFFSERV] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W.
Weiss, "An Architecture for Differentiated Services", draft-ietf- Weiss, "An Architecture for Differentiated Services", Work in Pro-
diffserv-arch-02.txt, October, 1998 gress, October, 1998.
[ENCAP] E. Rosen, Y. Rekhter, D. Tappan, D. Farinacci, G. Fedorkow, [ENCAP] E. Rosen, Y. Rekhter, D. Tappan, D. Farinacci, G. Fedorkow,
T. Li, A. Conta, "MPLS Label Stack Encoding" draft-ietf-mpls-label- T. Li, A. Conta, "MPLS Label Stack Encoding", Work in Progress, July,
encaps-02.txt, July, 1998 1998.
[FR] A. Conta, P. Doolan, A. Malis, "Use of Label Switching on Frame [FR] A. Conta, P. Doolan, A. Malis, "Use of Label Switching on Frame
Relay Networks" draft-ietf-mpls-fr-02.txt, October, 1998 Relay Networks", Work in Progress, October, 1998.
[FRAMEWORK] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swal- [FRAMEWORK] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swal-
low, A. Viswanathan, "A Framework for Multiprotocol Label Switching" low, A. Viswanathan, "A Framework for Multiprotocol Label Switching",
draft-ietf-mpls-framework-02.txt, November 1997 Work in Progress, November 1997.
[LSPTUN] D. Awduche, L. Berger, D. Gan, T. Li, G. Swallow, Vijay
Srinivasan, "Extensions to RSVP for LSP Tunnels", Work in Progress,
November 1998.
[rfc1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321, [rfc1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321,
April 1992. April 1992.
[rfc1483] J. Heinanen, "Multiprotocol Encapsulation over ATM Adapta- [rfc1483] J. Heinanen, "Multiprotocol Encapsulation over ATM Adapta-
tion Layer 5", RFC 1483, Telecom Finland, July 1993 tion Layer 5", RFC 1483, Telecom Finland, July 1993.
[rfc1583] J. Moy, "OSPF Version 2", RFC 1583, Proteon Inc, March 1994 [rfc1583] J. Moy, "OSPF Version 2", RFC 1583, Proteon Inc, March
1994.
[rfc1700] J. Reynolds, J.Postel, "ASSIGNED NUMBERS", October 1994. [rfc1700] J. Reynolds, J.Postel, "ASSIGNED NUMBERS", October 1994.
[rfc1771] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)", [rfc1771] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771, IBM Corp, Cisco Systems, March 1995 RFC 1771, IBM Corp, Cisco Systems, March 1995.
[rfc2205] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specif-
ication", RFC 2205, September 1997.
[rfc2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [rfc2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998. Signature Option", RFC 2385, August 1998.
[TE] D. Awduche, J. Malcolm, J Agogbua, M. O'Dell, J. McManus, "
Requirements for Traffic Engineering over MPLS", Work in Progress,
October 1998.
8. Author Information 8. Author Information
Loa Andersson Loa Andersson Andre Fredette
Nortel Networks Inc Nortel Networks Inc Nortel Networks Inc
Kungsgatan 34, PO Box 1788 Kungsgatan 34, PO Box 1788 3 Federal Street
111 97 Stockholm 111 97 Stockholm Billerica, MA 01821
Sweden Sweden Phone: 978-916-8524
Phone: +46 8 441 78 34, Mobile: +46 70 522 78 34 Phone: +46 8 441 78 34 email: fredette@baynetworks.com
Mobile: +46 70 522 78 34
email: loa_andersson@baynetworks.com email: loa_andersson@baynetworks.com
Paul Doolan Paul Doolan Bob Thomas
Ennovate Networks Ennovate Networks Cisco Systems, Inc.
330 Codman Hill Rd 330 Codman Hill Rd 250 Apollo Dr.
Marlborough MA 01719 Marlborough MA 01719 Chelmsford, MA 01824
Phone: 978-263-2002 Phone: 978-263-2002 Phone: 978-244-8078
email: pdoolan@ennovatenetworks.com email: pdoolan@ennovatenetworks.com email: rhthomas@cisco.com
Nancy Feldman Nancy Feldman
IBM Corp. IBM Corp.
17 Skyline Drive 17 Skyline Drive
Hawthorne NY 10532 Hawthorne NY 10532
Phone: 914-784-3254 Phone: 914-784-3254
email: nkf@us.ibm.com email: nkf@us.ibm.com
Andre Fredette
Nortel Networks Inc
3 Federal Street
Billerica, MA 01821
Phone: 978-916-8524
email: fredette@baynetworks.com
Bob Thomas
Cisco Systems, Inc.
250 Apollo Dr.
Chelmsford, MA 01824
Phone: 978-244-8078
email: rhthomas@cisco.com
Appendix A. LDP Label Distribution Procedures Appendix A. LDP Label Distribution Procedures
This section specifies label distribution behavior in terms of LSR This section specifies label distribution behavior in terms of LSR
response to the following events: response to the following events:
- Receive Label Request Message; - Receive Label Request Message;
- Receive Label Mapping Message; - Receive Label Mapping Message;
- Receive Label Release Message; - Receive Label Release Message;
- Receive Label Withdraw Message; - Receive Label Withdraw Message;
- Recognize new FEC; - Recognize new FEC;
skipping to change at page 99, line 32 skipping to change at page 100, line 32
NH.3 Is LSR using Liberal label retention? NH.3 Is LSR using Liberal label retention?
If so, goto NH.6. If so, goto NH.6.
NH.4 Execute procedure Send_Message (Old Next Hop, Label Release, NH.4 Execute procedure Send_Message (Old Next Hop, Label Release,
OldLlabel). OldLlabel).
NH.5 Delete label mapping for FEC previously received from Old NH.5 Delete label mapping for FEC previously received from Old
Next Hop. Next Hop.
NH.6 Has LSR previously received and retained a label mapping for NH.6 Is there a New Next Hop for the FEC?
If not, goto NH.12.
NH.7 Has LSR previously received and retained a label mapping for
FEC from New Next Hop? FEC from New Next Hop?
If not, goto NH.8. If not, goto NH.9.
NH.7 Generate Event: Received Label Mapping from New Next Hop. NH.8 Generate Event: Received Label Mapping from New Next Hop.
Goto NH.11. (See Note 2.) Goto NH.12. (See Note 2.)
NH.8 Is LSR using Downstream on Demand advertisement? OR NH.9 Is LSR using Downstream on Demand advertisement? OR
Is Next Hop using Downstream on Demand advertisement? OR Is Next Hop using Downstream on Demand advertisement? OR
Is LSR using Conservative label retention? (See Note 3.) Is LSR using Conservative label retention? (See Note 3.)
If so, goto NH.9. If not, goto NH.11. If so, goto NH.10. If not, goto NH.12.
NH.9 Execute procedure Prepare_Label_Request_Attributes (Next Hop, NH.10 Execute procedure Prepare_Label_Request_Attributes (Next
FEC, CurAttributes, SAttributes) Hop, FEC, CurAttributes, SAttributes)
NH.10 Execute procedure Send_Label_Request (New Next Hop, FEC, SAt- NH.11 Execute procedure Send_Label_Request (New Next Hop, FEC, SAt-
tributes). tributes).
(See Note 4.) (See Note 4.)
NH.11 DONE. NH.11 DONE.
Notes: Notes:
1. If Label is not in forwarding/switching use, NH.2 has no 1. If Label is not in forwarding/switching use, NH.2 has no
effect. effect.
2. If the LSR has a label for the FEC from the New Next Hop, it 2. If the LSR has a label for the FEC from the New Next Hop, it
should behave as if it had just received the label from the New should behave as if it had just received the label from the New
Next Hop. Next Hop.
skipping to change at page 112, line 21 skipping to change at page 113, line 21
copy the resulting Path Vector into SAttributes. copy the resulting Path Vector into SAttributes.
Goto PRqA.14. Goto PRqA.14.
PRqA.13 Include Path Vector of length 1 containing LSR Id in SAttri- PRqA.13 Include Path Vector of length 1 containing LSR Id in SAttri-
butes. butes.
PRqA.14 DONE. PRqA.14 DONE.
Notes: Notes:
1. The link with Peer may require that Hop Count be 1. The link with Peer may require that Hop Count be included in
included in Label Request messages; for example, see Label Request messages; for example, see [ATM] and [FR].
[ATM].
2. For hop count arithmetic, unknown + 1 = unknown. 2. For hop count arithmetic, unknown + 1 = unknown.
A.2.8. Prepare_Label_Mapping_Attributes A.2.8. Prepare_Label_Mapping_Attributes
Summary: Summary:
This procedure is used whenever a Label Mapping is to be sent to a This procedure is used whenever a Label Mapping is to be sent to a
Peer to compute the Hop Count and Path Vector, if any, to include Peer to compute the Hop Count and Path Vector, if any, to include
in the message. in the message.
skipping to change at page 113, line 17 skipping to change at page 114, line 17
Additional Context: Additional Context:
- LSR Id. The unique LSR Id of this LSR. - LSR Id. The unique LSR Id of this LSR.
Algorithm: Algorithm:
PMpA.1 Is Hop Count required for this Peer (see Note 1.) ? OR PMpA.1 Is Hop Count required for this Peer (see Note 1.) ? OR
Do RAttributes include a Hop Count? OR Do RAttributes include a Hop Count? OR
Is Loop Detection configured on LSR? Is Loop Detection configured on LSR?
If not, goto PMpA.19. If not, goto PMpA.21.
PMpA.2 Is LSR egress for FEC? PMpA.2 Is LSR egress for FEC?
If not, goto PMpA.4. If not, goto PMpA.4.
PMpA.3 Include Hop Count of 1 in SAttributes. Goto PMpA.19. PMpA.3 Include Hop Count of 1 in SAttributes. Goto PMpA.21.
PMpA.4 Do RAttributes have a Hop Count? PMpA.4 Do RAttributes have a Hop Count?
If not, goto PMpA.6. If not, goto PMpA.8.
PMpA.5 Increment RAttributes Hop Count and copy the resulting Hop PMpA.5 Is LSR member of edge set for an LSR domain whose LSRs do not
Count to SAttributes. See Note 2. Goto PMpA.7. perform TTL decrement AND
Is Peer in that domain (See Note 2.).
If not, goto PMpA.7.
PMpA.6 Include Hop Count of unknown (0) in SAttributes. PMpA.6 Include Hop Count of 1 in SAttributes. Goto PMpA.9.
PMpA.7 Is Loop Detection configured on LSR? PMpA.7 Increment RAttributes Hop Count and copy the resulting Hop
If not, goto PMpA.19. Count to SAttributes. See Note 2. Goto PMpA.9.
PMpA.8 Do RAttributes have a Path Vector? PMpA.8 Include Hop Count of unknown (0) in SAttributes.
If so, goto PMpA.17.
PMpA.9 Is LSR propagating a received Label Mapping? PMpA.9 Is Loop Detection configured on LSR?
If not, goto PMpA.18. If not, goto PMpA.21.
PMpA.10 Does LSR support merging? PMpA.10 Do RAttributes have a Path Vector?
If not, goto PMpA.12. If so, goto PMpA.19.
PMpA.11 Has LSR previously sent a Label Mapping for FEC to Peer? PMpA.11 Is LSR propagating a received Label Mapping?
If not, goto PMpA.18. If not, goto PMpA.20.
PMpA.12 Do RAttributes include a Hop Count? PMpA.12 Does LSR support merging?
If not, goto PMpA.19. If not, goto PMpA.14.
Res.13 Is Hop Count in Rattributes unknown(0)? PMpA.13 Has LSR previously sent a Label Mapping for FEC to Peer?
If so, goto PMpA.18. If not, goto PMpA.20.
PMpA.14 Has LSR previously sent a Label Mapping for FEC to Peer? PMpA.14 Do RAttributes include a Hop Count?
If not goto PMpA.19. If not, goto PMpA.21.
PMpA.15 Is Hop Count in RAttributes different from PrevHopCount ? Res.15 Is Hop Count in Rattributes unknown(0)?
If not goto PMpA.19. If so, goto PMpA.20.
PMpA.16 Is the Hop Count in RAttributes > PrevHopCount? OR PMpA.16 Has LSR previously sent a Label Mapping for FEC to Peer?
If not goto PMpA.21.
PMpA.17 Is Hop Count in RAttributes different from PrevHopCount ?
If not goto PMpA.21.
PMpA.18 Is the Hop Count in RAttributes > PrevHopCount? OR
Is PrevHopCount unknown(0) Is PrevHopCount unknown(0)
If not, goto PMpA.19. If not, goto PMpA.21.
PMpA.17 Add LSR Id to beginning of Path Vector from RAttributes and PMpA.19 Add LSR Id to beginning of Path Vector from RAttributes and
copy the resulting Path Vector into SAttributes. Goto copy the resulting Path Vector into SAttributes. Goto
PMpA.19. PMpA.21.
PMpA.18 Include Path Vector of length 1 containing LSR Id in SAttri- PMpA.20 Include Path Vector of length 1 containing LSR Id in SAttri-
butes. butes.
PMpA.19 DONE. PMpA.21 DONE.
Notes: Notes:
1. The link with Peer may require that Hop Count be included in 1. The link with Peer may require that Hop Count be included in
Label Mapping messages; for example, see [ATM]. Label Mapping messages; for example, see [ATM] and [FR].
2. For hop count arithmetic, unknown + 1 = unknown. 2. If the LSR is at the edge of a cloud of LSRs that do not per-
form TTL-decrement and it is propagating the Label Mapping mes-
sage upstream into the cloud, it sets the Hop Count to 1 so
that Hop Count across the cloud is calculated properly. This
ensures proper TTL mamagement for packets forwarded across the
part of the LSP that passes through the cloud.
3. For hop count arithmetic, unknown + 1 = unknown.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/