draft-ietf-mpls-ldp-05.txt   draft-ietf-mpls-ldp-06.txt 
Network Working Group Loa Andersson Network Working Group Loa Andersson
Internet Draft Nortel Networks Inc. Internet Draft Nortel Networks Inc.
Expiration Date: December 1999 Expiration Date: April 2000
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.
June 1999 October 1999
LDP Specification LDP Specification
draft-ietf-mpls-ldp-05.txt draft-ietf-mpls-ldp-06.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 6 skipping to change at page 2, line 13
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
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 a set through them. This common understanding is achieved by using a set
of procedures, called a label distribution protocol, by which one LSR of procedures, called a label distribution protocol, by which one LSR
informs another of label bindins it has made. This document defines informs another of label bindings it has made. This document defines
a set of such procedures called LDP (for Label Distribution a set of such procedures called LDP (for Label Distribution
Protocol). Protocol).
Changes from Previous Draft
- This draft addresses issues raised during the LDP last call held
February 8, 1999 through February 24, 1999.
Open Issues
The following LDP issues are left unresolved with this version of the
spec:
- Section 2.16 of the MPLS architecture [ARCH] requires that the
initial label distribution protocol negotiation between peer LSRs
enable each LSR to determine whether its peer is capable of
popping the label stack. This version of LDP assumes that LSRs
support label popping for all link types except ATM and Frame
Relay. A future version may specify means to make this
determination part of the session initiation negotiation.
- LDP support for CoS is not specified in this version. CoS
support may be addressed in a future version.
- LDP support for multicast is not specified in this version.
Multicast support will be addressed in a future version.
- LDP support for multipath label switching is not specified in
this version. Multipath support will be addressed in a future
version.
Table of Contents Table of Contents
1 LDP Overview ....................................... 6 1 LDP Overview ....................................... 6
1.1 LDP Peers .......................................... 6 1.1 LDP Peers .......................................... 6
1.2 LDP Message Exchange ............................... 7 1.2 LDP Message Exchange ............................... 7
1.3 LDP Message Structure .............................. 7 1.3 LDP Message Structure .............................. 7
1.4 LDP Error Handling ................................. 8 1.4 LDP Error Handling ................................. 8
1.5 LDP Extensibility and Future Compatibility ......... 8 1.5 LDP Extensibility and Future Compatibility ......... 8
2 LDP Operation ...................................... 8 2 LDP Operation ...................................... 8
2.1 FECs ............................................... 8 2.1 FECs ............................................... 8
skipping to change at page 4, line 49 skipping to change at page 4, line 49
3.5.7.1 Label Mapping Message Procedures ................... 65 3.5.7.1 Label Mapping Message Procedures ................... 65
3.5.7.1.1 Independent Control Mapping ........................ 66 3.5.7.1.1 Independent Control Mapping ........................ 66
3.5.7.1.2 Ordered Control Mapping ............................ 66 3.5.7.1.2 Ordered Control Mapping ............................ 66
3.5.7.1.3 Downstream on Demand Label Advertisement ........... 67 3.5.7.1.3 Downstream on Demand Label Advertisement ........... 67
3.5.7.1.4 Downstream Unsolicited Label Advertisement ......... 67 3.5.7.1.4 Downstream Unsolicited Label Advertisement ......... 67
3.5.8 Label Request Message .............................. 68 3.5.8 Label Request Message .............................. 68
3.5.8.1 Label Request Message Procedures ................... 69 3.5.8.1 Label Request Message Procedures ................... 69
3.5.9 Label Abort Request Message ........................ 70 3.5.9 Label Abort Request Message ........................ 70
3.5.9.1 Label Abort Request Message Procedures ............. 71 3.5.9.1 Label Abort Request Message Procedures ............. 71
3.5.10 Label Withdraw Message ............................. 73 3.5.10 Label Withdraw Message ............................. 73
3.5.10.1 Label Withdraw Message Procedures .................. 73 3.5.10.1 Label Withdraw Message Procedures .................. 74
3.5.11 Label Release Message .............................. 74 3.5.11 Label Release Message .............................. 74
3.5.11.1 Label Release Message Procedures ................... 75 3.5.11.1 Label Release Message Procedures ................... 75
3.6 Messages and TLVs for Extensibility ................ 76 3.6 Messages and TLVs for Extensibility ................ 76
3.6.1 LDP Vendor-private Extensions ...................... 76 3.6.1 LDP Vendor-private Extensions ...................... 76
3.6.1.1 LDP Vendor-private TLVs ............................ 76 3.6.1.1 LDP Vendor-private TLVs ............................ 77
3.6.1.2 LDP Vendor-private Messages ........................ 78 3.6.1.2 LDP Vendor-private Messages ........................ 78
3.6.2 LDP Experimental Extensions ........................ 79 3.6.2 LDP Experimental Extensions ........................ 79
3.7 Message Summary .................................... 79 3.7 Message Summary .................................... 80
3.8 TLV Summary ........................................ 80 3.8 TLV Summary ........................................ 80
3.9 Status Code Summary ................................ 81 3.9 Status Code Summary ................................ 81
3.10 Well-known Numbers ................................. 82 3.10 Well-known Numbers ................................. 82
3.10.1 UDP and TCP Ports .................................. 82 3.10.1 UDP and TCP Ports .................................. 82
3.10.2 Implicit NULL Label ................................ 82 3.10.2 Implicit NULL Label ................................ 82
4 Security Considerations ............................ 82 4 Security Considerations ............................ 82
4.1 The TCP MD5 Signature Option ....................... 82 4.1 The TCP MD5 Signature Option ....................... 82
4.2 LDP Use of the TCP MD5 Signature Option ............ 84 4.2 LDP Use of the TCP MD5 Signature Option ............ 84
5 Intellectual Property Considerations ............... 84 5 Areas for Future Study ............................. 84
6 Acknowledgments .................................... 85 6 Intellectual Property Considerations ............... 85
7 References ......................................... 85 7 Acknowledgments .................................... 85
8 Author Information ................................. 86 8 References ......................................... 85
9 Author Information ................................. 87
Appendix.A LDP Label Distribution Procedures .................. 87 Appendix.A LDP Label Distribution Procedures .................. 88
A.1 Handling Label Distribution Events ................. 89 A.1 Handling Label Distribution Events ................. 90
A.1.1 Receive Label Request .............................. 90 A.1.1 Receive Label Request .............................. 91
A.1.2 Receive Label Mapping .............................. 93 A.1.2 Receive Label Mapping .............................. 94
A.1.3 Receive Label Abort Request ........................ 98 A.1.3 Receive Label Abort Request ........................ 98
A.1.4 Receive Label Release .............................. 99 A.1.4 Receive Label Release .............................. 100
A.1.5 Receive Label Withdraw ............................. 101 A.1.5 Receive Label Withdraw ............................. 102
A.1.6 Recognize New FEC .................................. 103 A.1.6 Recognize New FEC .................................. 104
A.1.7 Detect Change in FEC Next Hop ...................... 106 A.1.7 Detect Change in FEC Next Hop ...................... 106
A.1.8 Receive Notification / Label Request Aborted ....... 108 A.1.8 Receive Notification / Label Request Aborted ....... 109
A.1.9 Receive Notification / No Label Resources .......... 109 A.1.9 Receive Notification / No Label Resources .......... 110
A.1.10 Receive Notification / No Route .................... 110 A.1.10 Receive Notification / No Route .................... 110
A.1.11 Receive Notification / Loop Detected ............... 110 A.1.11 Receive Notification / Loop Detected ............... 111
A.1.12 Receive Notification / Label Resources Available ... 111 A.1.12 Receive Notification / Label Resources Available ... 112
A.1.13 Detect local label resources have become available . 112 A.1.13 Detect local label resources have become available . 112
A.1.14 LSR decides to no longer label switch a FEC ........ 113 A.1.14 LSR decides to no longer label switch a FEC ........ 113
A.1.15 Timeout of deferred label request .................. 113 A.1.15 Timeout of deferred label request .................. 114
A.2 Common Label Distribution Procedures ............... 114 A.2 Common Label Distribution Procedures ............... 115
A.2.1 Send_Label ......................................... 114 A.2.1 Send_Label ......................................... 115
A.2.2 Send_Label_Request ................................. 116 A.2.2 Send_Label_Request ................................. 116
A.2.3 Send_Label_Withdraw ................................ 117 A.2.3 Send_Label_Withdraw ................................ 118
A.2.4 Send_Notification .................................. 117 A.2.4 Send_Notification .................................. 118
A.2.5 Send_Message ....................................... 118 A.2.5 Send_Message ....................................... 119
A.2.6 Check_Received_Attributes .......................... 118 A.2.6 Check_Received_Attributes .......................... 119
A.2.7 Prepare_Label_Request_Attributes ................... 120 A.2.7 Prepare_Label_Request_Attributes ................... 120
A.2.8 Prepare_Label_Mapping_Attributes ................... 121 A.2.8 Prepare_Label_Mapping_Attributes ................... 122
1. LDP Overview 1. LDP Overview
Section 2.6 of the MPLS architecture [ARCH] defines a label Section 2.6 of the MPLS architecture [ARCH] defines a label
distribution protocol as a set of procedures by which one Label distribution protocol as a set of procedures by which one Label
Switched Router (LSR) informs another of the meaning of labels used Switched Router (LSR) informs another of the meaning of labels used
to forward traffic between and through them. to forward traffic between and through them.
The MPLS architecture does not assume a single label distribution The MPLS architecture does not assume a single label distribution
protocol. In fact, a number of different label distribution protocol. In fact, a number of different label distribution
protocols are being standardized. Existing protocols have been protocols are being standardized. Existing protocols have been
extended so that label distribution can be piggybacked on them. New extended so that label distribution can be piggybacked on them. New
protocols have also been defined for the explicit purpose of protocols have also been defined for the explicit purpose of
distributing labels. Section 2.29 of the architecture [ARCH] distributing labels. Section 2.29 of the architecture [ARCH]
discusses some of the considerations when chosing a label discusses some of the considerations when choosing a label
distribution protocol for use in particular MPLS applications such as distribution protocol for use in particular MPLS applications such as
Traffic Engineering [TE]. Traffic Engineering [TE].
The Label Distribution Protocol (LDP) defined in this document is a The Label Distribution Protocol (LDP) defined in this document is a
new protocol defined for distributing labels. It is the set of new protocol defined for distributing labels. It is the set of
procedures and messages by which Label Switched Routers (LSRs) procedures and messages by which Label Switched Routers (LSRs)
establish Label Switched Paths (LSPs) through a network by mapping establish Label Switched Paths (LSPs) through a network by mapping
network-layer routing information directly to data-link layer network-layer routing information directly to data-link layer
switched paths. These LSPs may have an endpoint at a directly switched paths. These LSPs may have an endpoint at a directly
attached neighbor (comparable to IP hop-by-hop forwarding), or may attached neighbor (comparable to IP hop-by-hop forwarding), or may
skipping to change at page 6, line 44 skipping to change at page 6, line 44
packets are "mapped" to that LSP. LSPs are extended through a packets are "mapped" to that LSP. LSPs are extended through a
network as each LSR "splices" incoming labels for a FEC to the network as each LSR "splices" incoming labels for a FEC to the
outgoing label assigned to the next hop for the given FEC. outgoing label assigned to the next hop for the given FEC.
This document assumes familiarity with the MPLS architecture [ARCH]. This document assumes familiarity with the MPLS architecture [ARCH].
Note that [ARCH] includes a glossary of MPLS terminology, such as Note that [ARCH] includes a glossary of MPLS terminology, such as
ingress, label switched path, etc. ingress, label switched path, etc.
1.1. LDP Peers 1.1. LDP Peers
Two LSRs which use LDP to exchange label/stream mapping information Two LSRs which use LDP to exchange label/FEC mapping information are
are known as "LDP Peers" with respect to that information and we known as "LDP Peers" with respect to that information and we speak of
speak of there being an "LDP Session" between them. A single LDP there being an "LDP Session" between them. A single LDP session
session allows each peer to learn the other's label mappings; i.e., allows each peer to learn the other's label mappings; i.e., the
the protocol is bi-directional. protocol is bi-directional.
1.2. LDP Message Exchange 1.2. LDP Message Exchange
There are four categories of LDP messages: There are four categories of LDP messages:
1. Discovery messages, used to announce and maintain the presence 1. Discovery messages, used to announce and maintain the presence
of an LSR in a network. of an LSR in a network.
2. Session messages, used to establish, maintain, and terminate 2. Session messages, used to establish, maintain, and terminate
sessions between LDP peers. sessions between LDP peers.
skipping to change at page 31, line 44 skipping to change at page 31, line 44
Type Type
Encodes how the Value field is to be interpreted. Encodes how the Value field is to be interpreted.
Length Length
Specifies the length of the Value field in octets. Specifies the length of the Value field in octets.
Value Value
Octet string of Length octets that encodes information to be Octet string of Length octets that encodes information to be
interpreted as specified by the Type field. interpreted as specified by the Type field.
Note that there is no alignment requirement for the first octect of a Note that there is no alignment requirement for the first octet of a
TLV. TLV.
Note that the Value field itself may contain TLV encodings. That is, Note that the Value field itself may contain TLV encodings. That is,
TLVs may be nested. TLVs may be nested.
The TLV encoding scheme is very general. In principle, everything The TLV encoding scheme is very general. In principle, everything
appearing in an LDP PDU could be encoded as a TLV. This appearing in an LDP PDU could be encoded as a TLV. This
specification does not use the TLV scheme to its full generality. It specification does not use the TLV scheme to its full generality. It
is not used where its generality is unnecessary and its use would is not used where its generality is unnecessary and its use would
waste space unnecessarily. These are usually places where the type waste space unnecessarily. These are usually places where the type
skipping to change at page 39, line 15 skipping to change at page 39, line 15
o Otherwise, R must increment the received hop count. o Otherwise, R must increment the received hop count.
The first LSR in the LSP (ingress for a Label Request message, egress 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. 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).
Use of the unknown hop count value greatly reduces the signalling Use of the unknown hop count value greatly reduces the signaling
overhead when independent control is used. When a new LSP is overhead when independent control is used. When a new LSP is
established, each LSR starts with unknown hop count. Addition of a established, each LSR starts with unknown hop count. Addition of a
new LSR whose hop count is also unknown does not cause a hop count new LSR whose hop count is also unknown does not cause a hop count
update to be propagated upstream since the hop count remains unknown. update to be propagated upstream since the hop count remains unknown.
When the egress is finally added to the LSP, then the LSRs propagate When the egress is finally added to the LSP, then the LSRs propagate
hop count updates upstream via Label Mapping messages. hop count updates upstream via Label Mapping messages.
Without use of the unknown hop count, each time a new LSR is added to Without use of the unknown hop count, each time a new LSR is added to
the LSP a hop count update would need to be propagated upstream if the LSP a hop count update would need to be propagated upstream if
the new LSR is closer to the egress than any of the other LSRs. the new LSR is closer to the egress than any of the other LSRs.
skipping to change at page 41, line 5 skipping to change at page 41, line 5
An LSR that receives a Path Vector in a Label Request message must An LSR that receives a Path Vector in a Label Request message must
perform the procedures described in Section "Loop Detection". perform the procedures described in Section "Loop Detection".
If the LSR detects a loop, it must reject the Label Request message. If the LSR detects a loop, it must reject the Label Request message.
The LSR must: The LSR must:
1. Transmit a Notification message to the sending LSR signaling 1. Transmit a Notification message to the sending LSR signaling
"Loop Detected". "Loop Detected".
2. Not propagate the Label Reqeust message further. 2. Not propagate the Label Request message further.
Note that a Label Request message with Path Vector TLV is forwarded Note that a Label Request message with Path Vector TLV is forwarded
until: until:
1. A loop is found, 1. A loop is found,
2. The LSP egress is reached, 2. The LSP egress is reached,
3. The maximum Path Vector limit or maximum Hop Count limit is 3. The maximum Path Vector limit or maximum Hop Count limit is
reached. This is treated as if a loop had been detected. reached. This is treated as if a loop had been detected.
skipping to change at page 46, line 48 skipping to change at page 46, line 48
Extended Status Extended Status
The 4 octet value is an Extended Status Code that encodes The 4 octet value is an Extended Status Code that encodes
additional information that supplements the status information additional information that supplements the status information
contained in the Notification Status Code. contained in the Notification Status Code.
Returned PDU Returned PDU
An LSR uses this parameter to return part of an LDP PDU to the An LSR uses this parameter to return part of an LDP PDU to the
LSR that sent it. The value of this TLV is the PDU header and LSR that sent it. The value of this TLV is the PDU header and
as much PDU data following the header as appropriate for the as much PDU data following the header as appropriate for the
condition being signalled by the Notification message. condition being signaled by the Notification message.
Returned Message Returned Message
An LSR uses this parameter to return part of an LDP message to An LSR uses this parameter to return part of an LDP message to
the LSR that sent it. The value of this TLV is the message the LSR that sent it. The value of this TLV is the message
type and length fields and as much message data following the type and length fields and as much message data following the
type and length fields as appropriate for the condition being type and length fields as appropriate for the condition being
signalled by the Notification message. signaled by the Notification message.
3.5.1.1. Notification Message Procedures 3.5.1.1. Notification Message Procedures
If an LSR encounters a condition requiring it to notify its peer with If an LSR encounters a condition requiring it to notify its peer with
advisory or error information it sends the peer a Notification advisory or error information it sends the peer a Notification
message containing a Status TLV that encodes the information and message containing a Status TLV that encodes the information and
optionally additional TLVs that provide more information about the optionally additional TLVs that provide more information about the
event. event.
If the condition is one that is a fatal error the Status Code carried If the condition is one that is a fatal error the Status Code carried
skipping to change at page 54, line 16 skipping to change at page 54, line 16
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Common Sess Parms (0x0500)| Length | |0|0| Common Sess Parms (0x0500)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Version | KeepAlive Time | | Protocol Version | KeepAlive Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|D| Reserved | PVLim | Max PDU Length | |A|D| Reserved | PVLim | Max PDU Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver LDP Identifer | | Receiver LDP Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++
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 protocol. This version of the specification specifies LDP
protocol version 1. protocol version 1.
KeepAlive Time KeepAlive Time
skipping to change at page 55, line 27 skipping to change at page 55, line 27
PVLim, Path Vector Limit PVLim, Path Vector Limit
The configured maximum path vector length. Must be 0 if loop The configured maximum path vector length. Must be 0 if loop
detection is disabled (D = 0). If the loop detection detection is disabled (D = 0). If the loop detection
procedures would require the LSR to send a path vector that procedures would require the LSR to send a path vector that
exceeds this limit, the LSR will behave as if a loop had been exceeds this limit, the LSR will behave as if a loop had been
detected for the FEC in question. detected for the FEC in question.
When Loop Detection is enabled in a portion of a network, it is When Loop Detection is enabled in a portion of a network, it is
recommended that all LSRs in that portion of the network be recommended that all LSRs in that portion of the network be
configured with the same path vector limit. Although configured with the same path vector limit. Although knowledge
knowledege of a peer's path vector limit will not change an of a peer's path vector limit will not change an LSR's
LSR's behavior, it does enable the LSR to alert an operator to behavior, it does enable the LSR to alert an operator to a
a possible misconfiguration. possible misconfiguration.
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.
Max PDU Length Max PDU Length
Two octet unsigned integer that proposes the maximum allowable Two octet unsigned integer that proposes the maximum allowable
length for LDP PDUs for the session. A value of 255 or less length for LDP PDUs for the session. A value of 255 or less
specifies the default maximum length of 4096 octets. specifies the default maximum length of 4096 octets.
The receiving LSR MUST calculate the maximum PDU length for the The receiving LSR MUST calculate the maximum PDU length for the
session by using the smaller of its and its peer's proposals session by using the smaller of its and its peer's proposals
for Max PDU Length. The default maximum PDU length applies for Max PDU Length. The default maximum PDU length applies
before session initialization completes. before session initialization completes.
If the maximum PDU length determined this way is unacceptable If the maximum PDU length determined this way is unacceptable
to an LSR, it must send a Session Rejected/Parameters Max PDU to an LSR, it must send a Session Rejected/Parameters Max PDU
Length Notification message in response to the Initialization Length Notification message in response to the Initialization
message and not establish the session. message and not establish the session.
Receiver LDP Identifer Receiver LDP Identifier
Identifies the receiver's label space. This LDP Identifier, Identifies the receiver's label space. This LDP Identifier,
together with the sender's LDP Identifier in the PDU header together with the sender's LDP Identifier in the PDU header
enables the receiver to match the Initialization message with enables the receiver to match the Initialization message with
one of its Hello adjacencies; see Section "Hello Message one of its Hello adjacencies; see Section "Hello Message
Procedures". Procedures".
If there is no matching Hello adjacency, the LSR must send a If there is no matching Hello adjacency, the LSR must send a
Session Rejected/No Hello Notification message in response to Session Rejected/No Hello Notification message in response to
the Initialization message and not establish the session. the Initialization message and not establish the session.
skipping to change at page 60, line 8 skipping to change at page 60, line 8
Specifies the number of Frame Relay Label Range Components Specifies the number of Frame Relay Label Range Components
included in the TLV. included in the TLV.
D, VC Directionality D, VC Directionality
A value of 0 specifies bidirectional VC capability, meaning the A value of 0 specifies bidirectional VC capability, meaning the
LSR can support the use of a given DLCI as a label for both LSR can support the use of a given DLCI as a label for both
link directions independently. A value of 1 specifies link directions independently. A value of 1 specifies
unidirectional VC capability, meaning a given DLCI may appear unidirectional VC capability, meaning a given DLCI may appear
in a label mapping for one direction on the link only. When in a label mapping for one direction on the link only. When
either or both of the peers specifies unidirectional VC either or both of the peers specifies unidirectional VC
capability, both LSRs use unidirectional VC label assignement capability, both LSRs use unidirectional VC label assignment
for the link as follows. The LSRs compare their LDP for the link as follows. The LSRs compare their LDP
Identifiers as unsigned integers. The LSR with the larger LDP Identifiers as unsigned integers. The LSR with the larger LDP
Identifier may assign only odd-numbered DLCIs in the range as Identifier may assign only odd-numbered DLCIs in the range as
labels. The system with the smaller LDP Identifier may assign labels. The system with the smaller LDP Identifier may assign
only even-numbered DLCIs in the range as labels. only even-numbered DLCIs in the 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.
skipping to change at page 61, line 12 skipping to change at page 61, line 12
This field specifies the number of bits of the DLCI. The This field specifies the number of bits of the DLCI. The
following values are supported: following values are supported:
Len DLCI bits Len DLCI bits
0 10 0 10
1 17 1 17
2 23 2 23
Minimum DLCI Minimum DLCI
This 23-bit vield specifies the lower bound of a block of This 23-bit field specifies the lower bound of a block of
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.
Maximum DLCI Maximum DLCI
This 23-bit vield specifies the upper bound of a block of This 23-bit field specifies the upper bound of a block of
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
skipping to change at page 66, line 6 skipping to change at page 66, line 6
whether it uses a different mapping for each of its peers. whether it uses a different mapping for each of its peers.
An LSR is responsible for the consistency of the label mappings it An LSR is responsible for the consistency of the label mappings it
has distributed, and that its peers have these mappings. has distributed, and that its peers have these mappings.
An LSR receiving a Label Mapping message from a downstream LSR for a An LSR receiving a Label Mapping message from a downstream LSR for a
Prefix or Host Address FEC Element should not use the label for Prefix or Host Address FEC Element should not use the label for
forwarding unless its routing table contains an entry that exactly forwarding unless its routing table contains an entry that exactly
matches the FEC Element. matches the FEC Element.
See Appendx A "LDP Label Distribution Procedures" for more details. See Appendix A "LDP Label Distribution Procedures" for more details.
3.5.7.1.1. Independent Control Mapping 3.5.7.1.1. Independent Control Mapping
If an LSR is configured for independent control, a mapping message is If an LSR is configured for independent control, a mapping message is
transmitted by the LSR upon any of the following conditions: transmitted by the LSR upon any of the following conditions:
1. The LSR recognizes a new FEC via the forwarding table, and the 1. The LSR recognizes a new FEC via the forwarding table, and the
label advertisement mode is Downstream Unsolicited label advertisement mode is Downstream Unsolicited
advertisement. advertisement.
skipping to change at page 69, line 36 skipping to change at page 69, line 36
conditions: conditions:
1. The LSR recognizes a new FEC via the forwarding table, and the 1. The LSR recognizes a new FEC via the forwarding table, and the
next hop is an LDP peer, and the LSR doesn't already have a next hop is an LDP peer, and the LSR doesn't already have a
mapping from the next hop for the given FEC. mapping from the next hop for the given FEC.
2. The next hop to the FEC changes, and the LSR doesn't already 2. The next hop to the FEC changes, and the LSR doesn't already
have a mapping from that next hop for the given FEC. have a mapping from that next hop for the given FEC.
Note that if the LSR already has a pending Label Request Note that if the LSR already has a pending Label Request
message for the new hext hop it should not issue an additional message for the new next hop it should not issue an additional
Label Request in response to the next hop change. Label Request in response to the next hop change.
3. The LSR receives a Label Request for a FEC from an upstream LDP 3. The LSR receives a Label Request for a FEC from an upstream LDP
peer, the FEC next hop is an LDP peer, and the LSR doesn't peer, the FEC next hop is an LDP peer, and the LSR doesn't
already have a mapping from the next hop. already have a mapping from the next hop.
Note that since a non-merge LSR must setup a separate LSP for Note that since a non-merge LSR must setup a separate LSP for
each upstream peer requesting a label, it must send a separate each upstream peer requesting a label, it must send a separate
Label Request for each such peer. A consequence of this is Label Request for each such peer. A consequence of this is
that a non-merge LSR may have multiple Label Request messages that a non-merge LSR may have multiple Label Request messages
skipping to change at page 70, line 40 skipping to change at page 70, line 40
When resources become available the LSR must notify the When resources become available the LSR must notify the
requesting LSR by sending a Notification message with the Label requesting 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
Available Status code. Available Status code.
Loop Detected Loop Detected
The LSR has detected a looping Label Requst message. The LSR has detected a looping Label Request message.
See Appendx A "LDP Label Distribution Procedures" for more details. See Appendix A "LDP Label Distribution Procedures" for more details.
3.5.9. Label Abort Request Message 3.5.9. Label Abort Request Message
The Label Abort Request message may be used to abort an outstanding The Label Abort Request message may be used to abort an outstanding
Label Request message. Label Request message.
The encoding for the Label Abort Request Message is: The encoding for the Label Abort Request 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 71, line 23 skipping to change at page 71, line 23
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Request Message ID TLV | | Label Request Message ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters | | Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID Message ID
32-bit value used to identify this message. 32-bit value used to identify this message.
FEC TLV FEC TLV
Identifies the FEC for which the FEC-label mapping is being Identifies the FEC for which the Label Request is being aborted.
withdrawn.
Label Request Message ID TLV Label Request Message ID TLV
Specifies the message ID of the Label Request message to be Specifies the message ID of the Label Request message to be
aborted. aborted.
Optional Parameters Optional Parameters
No optional parameters are defined for the Label Abort Req message. No optional parameters are defined for the Label Abort Req message.
3.5.9.1. Label Abort Request Message Procedures 3.5.9.1. Label Abort Request Message Procedures
skipping to change at page 71, line 50 skipping to change at page 71, line 49
2. Ru is a non-merge, non-ingress LSR and has received a Label 2. Ru is a non-merge, non-ingress LSR and has received a Label
Abort Request for FEC from an upstream peer Y. Abort Request for FEC from an upstream peer Y.
3. Ru is a merge, non-ingress LSR and has received a Label Abort 3. Ru is a merge, non-ingress LSR and has received a Label Abort
Request for FEC from an upstream peer Y and Y is the only Request for FEC from an upstream peer Y and Y is the only
(last) upstream LSR requesting a label for FEC. (last) upstream LSR requesting a label for FEC.
There may be other situations where an LSR may choose to abort an There may be other situations where an LSR may choose to abort an
outstanding Label Request message in order to reclaim resource outstanding Label Request message in order to reclaim resource
associated with the pending LSP. However, specificaion of general associated with the pending LSP. However, specification of general
strategies for using the abort mechanism is beyond the scope of LDP. strategies for using the abort mechanism is beyond the scope of LDP.
When an LSR receives a Label Abort Request message, if it has not When an LSR receives a Label Abort Request message, if it has not
previously responded to the Label Request being aborted with a Label previously responded to the Label Request being aborted with a Label
Mapping message or some other Notification message, it must Mapping message or some other Notification message, it must
acknowledge the abort by responding with a Label Request Aborted acknowledge the abort by responding with a Label Request Aborted
Notification message. The Notification must include a Label Request Notification message. The Notification must include a Label Request
Message ID TLV that carries the message ID of the aborted Label Message ID TLV that carries the message ID of the aborted Label
Request message. Request message.
If an LSR receives a Label Abort Request Message after it has If an LSR receives a Label Abort Request Message after it has
responded to the Label Request in question with a Label Mapping responded to the Label Request in question with a Label Mapping
message or a Notification message, it ignores the abort request. message or a Notification message, it ignores the abort request.
If an LSR receives a Label Mapping message in response to a Label If an LSR receives a Label Mapping message in response to a Label
Request message after it has sent a Label Abort Request message to Request message after it has sent a Label Abort Request message to
abort the Label Request, the label in the Label Mapping message is abort the Label Request, the label in the Label Mapping message is
valid. The LSR may choose to use the label or to release it with a valid. The LSR may choose to use the label or to release it with a
Label Release mesage. Label Release message.
An LSR aborting a Label Request message may not reuse the Message ID An LSR aborting a Label Request message may not reuse the Message ID
for the Label Request message until it receives one of the following for the Label Request message until it receives one of the following
from its peer: from its peer:
- A Label Request Aborted Notfication message acknowledging the - A Label Request Aborted Notification message acknowledging the
abort; abort;
- A Label Mapping message in response to the Label Request message - A Label Mapping message in response to the Label Request message
being aborted; being aborted;
- A Notification message in response to the Label Request message - A Notification message in response to the Label Request message
being aborted (e.g., Loop Detected, No Label Resources, etc.). being aborted (e.g., Loop Detected, No Label Resources, etc.).
To protect itself against tardy peers or faulty peer implementations To protect itself against tardy peers or faulty peer implementations
an LSR may choose to time out receipt of the above. The time out an LSR may choose to time out receipt of the above. The time out
skipping to change at page 73, line 25 skipping to change at page 73, line 25
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Withdraw (0x0402) | Message Length | |0| Label Withdraw (0x0402) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID | | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV | | FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV (optional) | | Label TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID Message ID
32-bit value used to identify this message. 32-bit value used to identify this message.
FEC TLV FEC TLV
Identifies the FEC for which the FEC-label mapping is being Identifies the FEC for which the FEC-label mapping is being
withdrawn. withdrawn.
Optional Parameters Optional Parameters
This variable length field contains 0 or more parameters, each This variable length field contains 0 or more parameters, each
skipping to change at page 74, line 28 skipping to change at page 74, line 33
contain no other FEC Elements. In this case, if the Label Withdraw contain no other FEC Elements. In this case, if the Label Withdraw
message contains an optional Label TLV, then the label is to be message contains an optional Label TLV, then the label is to be
withdrawn from all FECs to which it is bound. If there is not an withdrawn from all FECs to which it is bound. If there is not an
optional Label TLV in the Label Withdraw message, then the sending optional Label TLV in the Label Withdraw message, then the sending
LSR is withdrawing all label mappings previously advertised to the LSR is withdrawing all label mappings previously advertised to the
receiving LSR. receiving LSR.
An LSR that receives a Label Withdraw message must respond with a An LSR that receives a Label Withdraw message must respond with a
Label Release message. Label Release message.
See Appendx A "LDP Label Distribution Procedures" for more details. See Appendix A "LDP Label Distribution Procedures" for more details.
3.5.11. Label Release Message 3.5.11. Label Release Message
An LSR sends a Label Release message to an LDP peer to signal the An LSR sends a Label Release message to an LDP peer to signal the
peer that the LSR no longer needs specific FEC-label mappings peer that the LSR no longer needs specific FEC-label mappings
previously requested of and/or advertised by the peer. previously requested of and/or advertised by the peer.
The encoding for the Label Release Message is: The encoding for the Label Release 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Release (0x0403) | Message Length | |0| Label Release (0x0403) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID | | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV | | FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV (optional) | | Label TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID Message ID
32-bit value used to identify this message. 32-bit value used to identify this message.
FEC TLV FEC TLV
Identifies the FEC for which the FEC-label mapping is being Identifies the FEC for which the FEC-label mapping is being
released. released.
Optional Parameters Optional Parameters
This variable length field contains 0 or more parameters, each This variable length field contains 0 or more parameters, each
skipping to change at page 76, line 14 skipping to change at page 76, line 34
optional Label TLV is to be released. optional Label TLV is to be released.
The FEC TLV may contain the Wildcard FEC Element; if so, it may The FEC TLV may contain the Wildcard FEC Element; if so, it may
contain no other FEC Elements. In this case, if the Label Release contain no other FEC Elements. In this case, if the Label Release
message contains an optional Label TLV, then the label is to be message contains an optional Label TLV, then the label is to be
released for all FECs to which it is bound. If there is not an released for all FECs to which it is bound. If there is not an
optional Label TLV in the Label Release message, then the sending LSR optional Label TLV in the Label Release message, then the sending LSR
is releasing all label mappings previously learned from the receiving is releasing all label mappings previously learned from the receiving
LSR. LSR.
See Appendx A "LDP Label Distribution Procedures" for more details. See Appendix A "LDP Label Distribution Procedures" for more details.
3.6. Messages and TLVs for Extensibility 3.6. Messages and TLVs for Extensibility
Support for LDP extensibility includes the rules for the U and F bits Support for LDP extensibility includes the rules for the U and F bits
that specify how an LSR should handle unknown TLVs and messages. that specify how an LSR should handle unknown TLVs and messages.
This section specifies TLVs and messages for vendor-private and This section specifies TLVs and messages for vendor-private and
experimental use. experimental use.
3.6.1. LDP Vendor-private Extensions 3.6.1. LDP Vendor-private Extensions
skipping to change at page 77, line 32 skipping to change at page 77, line 39
(=0), a notification must be returned to the message originator and (=0), a notification must be returned to the message originator and
the entire message must be ignored; if U is set (=1), the unknown the entire message must be ignored; if U is set (=1), the unknown
TLV is silently ignored and the rest of the message is processed as TLV is silently ignored and the rest of the message is processed as
if the unknown TLV did not exist. if the unknown TLV did not exist.
The determination as to whether a vendor-private message is The determination as to whether a vendor-private message is
understood is based on the Type and the mandatory Vendor ID field. understood is based on the Type and the mandatory Vendor ID field.
F bit F bit
Forward unknown TLV bit. This bit only applies when the U bit is Forward unknown TLV bit. This bit only applies when the U bit is
set and the LDP message containing the unknown TLF is is to be set and the LDP message containing the unknown TLV is is to be
forwarded. If F is clear (=0), the unknown TLV is not forwarded forwarded. If F is clear (=0), the unknown TLV is not forwarded
with the containing message; if F is set (=1), the unknown TLV is with the containing message; if F is set (=1), the unknown TLV is
forwarded with the containing message. forwarded with the containing message.
Type Type
Type value in the range 0x3E00 through 0x3EFF. Together, the Type Type value in the range 0x3E00 through 0x3EFF. Together, the Type
and Vendor Id field specify how the Data field is to be and Vendor Id field specify how the Data field is to be
interpreted. interpreted.
Length Length
skipping to change at page 79, line 35 skipping to change at page 79, line 44
experimental messages. experimental messages.
- The encodings for experimental TLVs and messages are similar to - The encodings for experimental TLVs and messages are similar to
the vendor-private encodings with the following difference. the vendor-private encodings with the following difference.
Experimental TLVs and messages use an Experiment ID field in Experimental TLVs and messages use an Experiment ID field in
place of a Vendor ID field. The Experiment ID field is used with place of a Vendor ID field. The Experiment ID field is used with
the Type or Message Type field to specify the interpretation of the Type or Message Type field to specify the interpretation of
the experimental TLV or Message. the experimental TLV or Message.
Administration of Experiment IDs is the responsiblity of the Administration of Experiment IDs is the responsibility of the
experimenters. experimenters.
3.7. Message Summary 3.7. Message Summary
The following are the LDP messages defined in this version of the The following are the LDP messages defined in this version of the
protocol. protocol.
Message Name Type Section Title Message Name Type Section Title
Notification 0x0001 "Notification Message" Notification 0x0001 "Notification Message"
skipping to change at page 81, line 26 skipping to change at page 81, line 31
The "E" column is the required setting of the Status Code E-bit; the The "E" column is the required setting of the Status Code E-bit; the
"Status Data" column is the value of the 30-bit Status Data field in "Status Data" column is the value of the 30-bit Status Data field in
the Status Code TLV. the Status Code TLV.
Note that the setting of the Status Code F-bit is at the discretion Note that the setting of the Status Code F-bit is at the discretion
of the LSR originating the Status TLV. of the LSR originating the Status TLV.
Status Code E Status Data Section Title Status Code E Status Data Section Title
Success 0 0x00000000 "Status TLV" Success 0 0x00000000 "Status TLV"
Bad LDP Identifer 1 0x00000001 "Events Signaled by ..." Bad LDP Identifier 1 0x00000001 "Events Signaled by ..."
Bad Protocol Version 1 0x00000002 "Events Signaled by ..." Bad Protocol Version 1 0x00000002 "Events Signaled by ..."
Bad PDU Length 1 0x00000003 "Events Signaled by ..." Bad PDU Length 1 0x00000003 "Events Signaled by ..."
Unknown Message Type 0 0x00000004 "Events Signaled by ..." Unknown Message Type 0 0x00000004 "Events Signaled by ..."
Bad Message Length 1 0x00000005 "Events Signaled by ..." Bad Message Length 1 0x00000005 "Events Signaled by ..."
Unknown TLV 0 0x00000006 "Events Signaled by ..." Unknown TLV 0 0x00000006 "Events Signaled by ..."
Bad TLV length 1 0x00000007 "Events Signaled by ..." Bad TLV length 1 0x00000007 "Events Signaled by ..."
Malformed TLV Value 1 0x00000008 "Events Signaled by ..." Malformed TLV Value 1 0x00000008 "Events Signaled by ..."
Hold Timer Expired 1 0x00000009 "Events Signaled by ..." Hold Timer Expired 1 0x00000009 "Events Signaled by ..."
Shutdown 1 0x0000000A "Events Signaled by ..." Shutdown 1 0x0000000A "Events Signaled by ..."
Loop Detected 0 0x0000000B "Loop Detection" Loop Detected 0 0x0000000B "Loop Detection"
skipping to change at page 82, line 39 skipping to change at page 82, line 43
MD5 hash function. MD5 hash function.
4.1. The TCP MD5 Signature Option 4.1. The TCP MD5 Signature Option
The following quotes from [rfc2385] outline the security properties The following quotes from [rfc2385] outline the security properties
achieved by using the TCP MD5 Signature Option and summarizes its achieved by using the TCP MD5 Signature Option and summarizes its
operation: operation:
"IESG Note "IESG Note
This document describes currrent existing practice for securing This document describes current existing practice for securing
BGP against certain simple attacks. It is understood to have BGP against certain simple attacks. It is understood to have
security weaknesses against concerted attacks." security weaknesses against concerted attacks."
"Abstract "Abstract
This memo describes a TCP extension to enhance security for This memo describes a TCP extension to enhance security for
BGP. It defines a new TCP option for carrying an MD5 [RFC1321] BGP. It defines a new TCP option for carrying an MD5 [RFC1321]
digest in a TCP segment. This digest acts like a signature for digest in a TCP segment. This digest acts like a signature for
that segment, incorporating information known only to the that segment, incorporating information known only to the
connection end points. Since BGP uses TCP as its transport, connection end points. Since BGP uses TCP as its transport,
using this option in the way described in this paper using this option in the way described in this paper
significantly reduces the danger from certain security attacks significantly reduces the danger from certain security attacks
on BGP." on BGP."
"Introduction "Introduction
skipping to change at page 84, line 36 skipping to change at page 84, line 39
validates the segment by calculating the MD5 digest (using its validates the segment by calculating the MD5 digest (using its
own record of the password) and compares the computed digest with own record of the password) and compares the computed digest with
the received digest. If the comparison fails, the segment is the received digest. If the comparison fails, the segment is
dropped without any response to the sender. dropped without any response to the sender.
- The LSR ignores LDP Hellos from any LSR for which a password has - The LSR ignores LDP Hellos from any LSR for which a password has
not been configured. This ensures that the LSR establishes LDP not been configured. This ensures that the LSR establishes LDP
TCP connections only with LSRs for which a password has been TCP connections only with LSRs for which a password has been
configured. configured.
5. Intellectual Property Considerations 5. Areas for Future Study
The following topics not addressed in this version of LDP are
possible areas for future study:
- Section 2.16 of the MPLS architecture [ARCH] requires that the
initial label distribution protocol negotiation between peer LSRs
enable each LSR to determine whether its peer is capable of
popping the label stack. This version of LDP assumes that LSRs
support label popping for all link types except ATM and Frame
Relay. A future version may specify means to make this
determination part of the session initiation negotiation.
- LDP support for CoS is not specified in this version. CoS
support may be addressed in a future version.
- LDP support for multicast is not specified in this version.
Multicast support may be addressed in a future version.
- LDP support for multipath label switching is not specified in
this version. Multipath support may be addressed in a future
version.
6. Intellectual Property Considerations
The IETF has been notified of intellectual property rights claimed in The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this regard to some or all of the specification contained in this
document. For more information consult the online list of claimed document. For more information consult the online list of claimed
rights. rights.
6. Acknowledgments 7. 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 8. References
[ARCH] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label [ARCH] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label
Switching Architecture", Work in Progress, 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", Work in Swallow, P. Doolan, "Use of Label Switching With ATM", Work in
Progress, September, 1998. Progress, September, 1998.
[ATM-VP] N. Feldman, B. Jamoussi, S. Komandur, A, Viswanathan, T [ATM-VP] N. Feldman, B. Jamoussi, S. Komandur, A, Viswanathan, T
Worster, "MPLS using ATM VP Switching", Work in Progress, February, Worster, "MPLS using ATM VP Switching", Work in Progress, February,
skipping to change at page 86, line 14 skipping to change at page 86, line 36
[rfc1483] J. Heinanen, "Multiprotocol Encapsulation over ATM [rfc1483] J. Heinanen, "Multiprotocol Encapsulation over ATM
Adaptation Layer 5", RFC 1483, Telecom Finland, July 1993. Adaptation Layer 5", RFC 1483, Telecom Finland, July 1993.
[rfc1583] J. Moy, "OSPF Version 2", RFC 1583, Proteon Inc, March [rfc1583] J. Moy, "OSPF Version 2", RFC 1583, Proteon Inc, March
1994. 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, March 1995.
[rfc2205] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, [rfc2205] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997. Specification", 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, " [TE] D. Awduche, J. Malcolm, J Agogbua, M. O'Dell, J. McManus, "
Requirements for Traffic Engineering over MPLS", Work in Progress, Requirements for Traffic Engineering over MPLS", Work in Progress,
October 1998. October 1998.
8. Author Information 9. Author Information
Loa Andersson Andre Fredette Loa Andersson Andre Fredette
Nortel Networks Inc Nortel Networks Inc Nortel Networks Inc Nortel Networks Inc
Kungsgatan 34, PO Box 1788 3 Federal Street St Eriksgatan 115, PO Box 6701 600 Technology Park Drive
111 97 Stockholm Billerica, MA 01821 113 85 Stockholm Billerica, MA 01821
Sweden Phone: 978-916-8524 Sweden Phone: 978-288-8524
Phone: +46 8 441 78 34 email: fredette@baynetworks.com Phone: +46 8 5088 36 34 email:
fredette@nortelnetworks.com
Mobile: +46 70 522 78 34 Mobile: +46 70 522 78 34
email: loa_andersson@baynetworks.com email: loa.andersson@nortelnetworks.com
Paul Doolan Bob Thomas Paul Doolan Bob Thomas
Ennovate Networks Cisco Systems, Inc. Ennovate Networks Cisco Systems, Inc.
330 Codman Hill Rd 250 Apollo Dr. 330 Codman Hill Rd 250 Apollo Dr.
Marlborough MA 01719 Chelmsford, MA 01824 Marlborough MA 01719 Chelmsford, MA 01824
Phone: 978-263-2002 Phone: 978-244-8078 Phone: 978-263-2002 Phone: 978-244-8078
email: pdoolan@ennovatenetworks.com email: rhthomas@cisco.com email: pdoolan@ennovatenetworks.com email: rhthomas@cisco.com
Nancy Feldman Nancy Feldman
IBM Corp. IBM Corp.
skipping to change at page 88, line 25 skipping to change at page 89, line 25
PulledConditional in [ARCH]. PulledConditional in [ARCH].
- Label Withdrawal procedure, which is performed by a downstream - Label Withdrawal procedure, which is performed by a downstream
LSR to determine when to withdraw a FEC label mapping previously LSR to determine when to withdraw a FEC label mapping previously
distributed to LDP peers. The architecture defines a single Label distributed to LDP peers. The architecture defines a single Label
Withdrawal procedure. Whenever an LSR breaks the binding between Withdrawal procedure. Whenever an LSR breaks the binding between
a label and a FEC, it must withdraw the FEC label mapping from a label and a FEC, it must withdraw the FEC label mapping from
all LDP peers to which it has previously sent the mapping. all LDP peers to which it has previously sent the mapping.
- Label Request procedure, which is performed by an upstream LSR to - Label Request procedure, which is performed by an upstream LSR to
determine when to explicitly request that a downstrem LSR bind a determine when to explicitly request that a downstream LSR bind a
label to a FEC and send it the corresponding label mapping. The label to a FEC and send it the corresponding label mapping. The
architecture defines three Label Request procedures: architecture defines three Label Request procedures:
. Request Never. The LSR never requests a label. . Request Never. The LSR never requests a label.
. Request When Needed. The LSR requests a label whenever it . Request When Needed. The LSR requests a label whenever it
needs one. needs one.
. Request On Request. This procedure is used by non-label . Request On Request. This procedure is used by non-label
merging LSRs. The LSR requests a label when it receives a merging LSRs. The LSR requests a label when it receives a
skipping to change at page 89, line 41 skipping to change at page 90, line 41
. No Request Retry. The LSR should assume the downstream LSR . No Request Retry. The LSR should assume the downstream LSR
will provide a label mapping when the downstream LSR has a will provide a label mapping when the downstream LSR has a
next hop and it should not reissue the request. next hop and it should not reissue the request.
A.1. Handling Label Distribution Events A.1. Handling Label Distribution Events
This section defines LDP label distribution procedures by specifying This section defines LDP label distribution procedures by specifying
an algorithm for each label distribution event. The requirement on an algorithm for each label distribution event. The requirement on
an LDP implementation is that its event handling must have the effect an LDP implementation is that its event handling must have the effect
specifid by the algorithms. That is, an implementation need not specified by the algorithms. That is, an implementation need not
follow exactly the steps specified by the algorithms as long as the follow exactly the steps specified by the algorithms as long as the
effect is identical. effect is identical.
The algorithms for handling label distribution events share common The algorithms for handling label distribution events share common
actions. The specifications below package these common actions into actions. The specifications below package these common actions into
procedure units. Specifications for these common procedures are in procedure units. Specifications for these common procedures are in
their own section "Common Label Distribution Procedures", which their own section "Common Label Distribution Procedures", which
follows this. follows this.
An implementation would use data structures to store information An implementation would use data structures to store information
skipping to change at page 101, line 29 skipping to change at page 102, line 14
scarce label resource. In doing so, it also increases the scarce label resource. In doing so, it also increases the
latency for re-establishing the LSP should MsgSource or some latency for re-establishing the LSP should MsgSource or some
other upstream LSR send it a new Label Request for FEC. other upstream LSR send it a new Label Request for FEC.
Whether or not to propagate the release is not a protocol Whether or not to propagate the release is not a protocol
issue. Label distribution will operate properly whether or not issue. Label distribution will operate properly whether or not
the release is propagated. The decision to propagate or not the release is propagated. The decision to propagate or not
should take into consideration factors such as: whether labels should take into consideration factors such as: whether labels
are a scarce resource in the operating environment; the are a scarce resource in the operating environment; the
importance of keeping LSP setup latency low by keeping the importance of keeping LSP setup latency low by keeping the
amount of signalling required small; whether LSP setup is amount of signaling required small; whether LSP setup is
ingress-controlled or egress-controlled in the operating ingress-controlled or egress-controlled in the operating
environment. environment.
A.1.5. Receive Label Withdraw A.1.5. Receive Label Withdraw
Summary: Summary:
When an LSR receives a label withdraw message for a FEC from an LDP When an LSR receives a label withdraw message for a FEC from an LDP
peer, it responds with a label release message and it removes the peer, it responds with a label release message and it removes the
label from any forwarding/switching use. If ordered control is in label from any forwarding/switching use. If ordered control is in
skipping to change at page 102, line 37 skipping to change at page 103, line 20
LWd.6 Is MsgSource using Downstream On Demand label advertisement? LWd.6 Is MsgSource using Downstream On Demand label advertisement?
If not, goto LWd.13. If not, goto LWd.13.
LWd.7 Generate Event: Recognize New FEC for FEC. LWd.7 Generate Event: Recognize New FEC for FEC.
Goto LWd.13. (See Note 2.) Goto LWd.13. (See Note 2.)
LWd.8 Iterate through LWd.12 for each Peer, other than MsgSource. LWd.8 Iterate through LWd.12 for each Peer, other than MsgSource.
LWd.9 Has LSR previously sent a label mapping for FEC to Peer? LWd.9 Has LSR previously sent a label mapping for FEC to Peer?
If not, continue interation for next Peer at LWd.8. If not, continue iteration for next Peer at LWd.8.
LWd.10 Does the label previously sent to Peer "map" to the withdrawn LWd.10 Does the label previously sent to Peer "map" to the withdrawn
Label? Label?
If not, continue iteration for next Peer at LWd.8. (See Note If not, continue iteration for next Peer at LWd.8. (See Note
3.) 3.)
LWd.11 Execute procedure Send_Label_Withdraw (Peer, FEC, Label LWd.11 Execute procedure Send_Label_Withdraw (Peer, FEC, Label
previously sent to Peer). previously sent to Peer).
LWd.12 End iteration from LWd.8. LWd.12 End iteration from LWd.8.
skipping to change at page 104, line 36 skipping to change at page 105, line 19
For Downstream Unsolicited Ordered Control For Downstream Unsolicited Ordered Control
1. Iterate through 5 for each Peer. 1. Iterate through 5 for each Peer.
2. Is LSR egress for the FEC? OR 2. Is LSR egress for the FEC? OR
Has LSR previously received and retained a label Has LSR previously received and retained a label
mapping for FEC from Next Hop? mapping for FEC from Next Hop?
If not, continue iteration for next Peer. If not, continue iteration for next Peer.
3. xecute procedure Prepare_Label_Mapping_Attributes 3. Execute procedure Prepare_Label_Mapping_Attributes
(Peer, FEC, InitAttributes, SAttributes, Propagating, (Peer, FEC, InitAttributes, SAttributes, Propagating,
StoredHopCount). StoredHopCount).
4. Execute procedure Send_Label (Peer, FEC, SAttributes) 4. Execute procedure Send_Label (Peer, FEC, SAttributes)
5. End iteration from 1. 5. End iteration from 1.
Goto FEC.2. Goto FEC.2.
For Downstream On Demand Independent Control OR For Downstream On Demand Independent Control OR
For Downstream On Demand Ordered Control For Downstream On Demand Ordered Control
skipping to change at page 106, line 15 skipping to change at page 106, line 43
A.1.7. Detect Change in FEC Next Hop A.1.7. Detect Change in FEC Next Hop
Summary: Summary:
The response by an LSR to a change in the next hop for a FEC may The response by an LSR to a change in the next hop for a FEC may
involve one or more of the following actions: involve one or more of the following actions:
- Removal of the label from the FEC's old next hop from - Removal of the label from the FEC's old next hop from
forwarding/switching use; forwarding/switching use;
- Transmission of label mappping messages for the FEC to one or - Transmission of label mapping messages for the FEC to one or more
more LDP peers; LDP peers;
- Transmission of a label request to the FEC's new next hop; - Transmission of a label request to the FEC's new next hop;
- Any of the actions that can occur when the LSR receives a label - Any of the actions that can occur when the LSR receives a label
mapping from the FEC's new next hop. mapping from the FEC's new next hop.
Context: Context:
- LSR. The LSR handling the event. - LSR. The LSR handling the event.
- FEC. The FEC whose next hop changed. - FEC. The FEC whose next hop changed.
- New Next Hop. The current next hop for the FEC. - New Next Hop. The current next hop for the FEC.
skipping to change at page 107, line 47 skipping to change at page 108, line 33
NH.14 Execute procedure Prepare_Label_Request_Attributes (Next Hop, NH.14 Execute procedure Prepare_Label_Request_Attributes (Next Hop,
FEC, CurAttributes, SAttributes) FEC, CurAttributes, SAttributes)
NH.15 Execute procedure Send_Label_Request (New Next Hop, FEC, NH.15 Execute procedure Send_Label_Request (New Next Hop, FEC,
SAttributes). (See Note 4.) SAttributes). (See Note 4.)
Goto NH.20. Goto NH.20.
NH.16 Iterate through NH.19 for each Peer. NH.16 Iterate through NH.19 for each Peer.
NH.17 Has LSR previously sent a label maping for FEC to Peer? NH.17 Has LSR previously sent a label mapping for FEC to Peer?
If not, continue iteration for next Peer at NH.16. If not, continue iteration for next Peer at NH.16.
NH.18 Execute procedure Send_Label_Withdraw (Peer, FEC, Label NH.18 Execute procedure Send_Label_Withdraw (Peer, FEC, Label
previously sent to Peer). previously sent to Peer).
NH.19 End iteration from NH.16. NH.19 End iteration from NH.16.
NH.20 DONE. NH.20 DONE.
Notes: Notes:
skipping to change at page 110, line 22 skipping to change at page 111, line 7
action, or it will defer the label request by starting a timer and action, or it will defer the label request by starting a timer and
send another Label Request message to the peer when the timer later send another Label Request message to the peer when the timer later
expires. expires.
Context: Context:
- LSR. The LSR handling the event. - LSR. The LSR handling the event.
- FEC. The FEC for which a label was requested. - FEC. The FEC for which a label was requested.
- Attributes. The attibutes associated with the label request. - Attributes. The attributes associated with the label request.
- MsgSource. The LDP peer that sent the Notification message. - MsgSource. The LDP peer that sent the Notification message.
Algorithm: Algorithm:
NoNH.1 Delete record of outstanding label request for FEC sent to NoNH.1 Delete record of outstanding label request for FEC sent to
MsgSource. MsgSource.
NoNH.2 Perform LSR Label No Route procedure. NoNH.2 Perform LSR Label No Route procedure.
skipping to change at page 115, line 20 skipping to change at page 116, line 5
- Label. The label allocated and sent to Peer. - Label. The label allocated and sent to Peer.
Algorithm: Algorithm:
SL.1 Does LSR have a label to allocate? SL.1 Does LSR have a label to allocate?
If not, goto SL.9. If not, goto SL.9.
SL.2 Allocate Label and bind it to the FEC. SL.2 Allocate Label and bind it to the FEC.
SL.3 Install Label for forwarding/switchng use. SL.3 Install Label for forwarding/switching use.
SL.4 Execute procedure Send_Message (Peer, Label Mapping, FEC, SL.4 Execute procedure Send_Message (Peer, Label Mapping, FEC,
Label, Attributes). Label, Attributes).
SL.5 Record label mapping for FEC with Label and Attributes has SL.5 Record label mapping for FEC with Label and Attributes has
been sent to Peer. been sent to Peer.
SL.6 Does LSR have a record of a FEC label request from Peer SL.6 Does LSR have a record of a FEC label request from Peer
marked as pending? marked as pending?
If not, goto SL.8. If not, goto SL.8.
skipping to change at page 117, line 47 skipping to change at page 118, line 38
Label) Label)
SWd.2 Record label withdraw for FEC has been sent to Peer and mark SWd.2 Record label withdraw for FEC has been sent to Peer and mark
it as outstanding. it as outstanding.
A.2.4. Send_Notification A.2.4. Send_Notification
Summary: Summary:
An LSR uses the Send_Notification procedure to send an LDP peer a An LSR uses the Send_Notification procedure to send an LDP peer a
notificaction message. notification message.
Parameters: Parameters:
- Peer. The LDP peer to which the Notification message is to be - Peer. The LDP peer to which the Notification message is to be
sent. sent.
- Status. Status code to be included in the Notification message. - Status. Status code to be included in the Notification message.
Additional Context: Additional Context:
 End of changes. 

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