draft-ietf-mpls-rfc3036bis-03.txt   draft-ietf-mpls-rfc3036bis-04.txt 
Network Working Group Loa Andersson Network Working Group Loa Andersson
Internet Draft Ina Minei Internet Draft Ina Minei
Expiration Date: April 2006 Bob Thomas Expiration Date: March 2007 Bob Thomas
Editors Editors
October 2005 September 2006
LDP Specification LDP Specification
draft-ietf-mpls-rfc3036bis-03.txt draft-ietf-mpls-rfc3036bis-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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 other Task Force (IETF), its areas, and its working groups. Note that other
skipping to change at page 3, line 47 skipping to change at page 3, line 47
2.6.2 Label Retention Mode .................................. 23 2.6.2 Label Retention Mode .................................. 23
2.6.2.1 Conservative Label Retention Mode ..................... 23 2.6.2.1 Conservative Label Retention Mode ..................... 23
2.6.2.2 Liberal Label Retention Mode .......................... 24 2.6.2.2 Liberal Label Retention Mode .......................... 24
2.6.3 Label Advertisement Mode .............................. 24 2.6.3 Label Advertisement Mode .............................. 24
2.7 LDP Identifiers and Next Hop Addresses ................ 24 2.7 LDP Identifiers and Next Hop Addresses ................ 24
2.8 Loop Detection ........................................ 25 2.8 Loop Detection ........................................ 25
2.8.1 Label Request Message ................................. 26 2.8.1 Label Request Message ................................. 26
2.8.2 Label Mapping Message ................................. 27 2.8.2 Label Mapping Message ................................. 27
2.8.3 Discussion ............................................ 29 2.8.3 Discussion ............................................ 29
2.9 Authenticity and Integrity of LDP Messages ............ 29 2.9 Authenticity and Integrity of LDP Messages ............ 29
2.9.1 TCP MD5 Signature Option .............................. 29 2.9.1 TCP MD5 Signature Option .............................. 30
2.9.2 LDP Use of TCP MD5 Signature Option ................... 31 2.9.2 LDP Use of TCP MD5 Signature Option ................... 31
2.10 Label Distribution for Explicitly Routed LSPs ......... 32 2.10 Label Distribution for Explicitly Routed LSPs ......... 32
3 Protocol Specification ................................ 32 3 Protocol Specification ................................ 32
3.1 LDP PDUs .............................................. 32 3.1 LDP PDUs .............................................. 32
3.2 LDP Procedures ........................................ 33 3.2 LDP Procedures ........................................ 33
3.3 Type-Length-Value Encoding ............................ 34 3.3 Type-Length-Value Encoding ............................ 34
3.4 TLV Encodings for Commonly Used Parameters ............ 35 3.4 TLV Encodings for Commonly Used Parameters ............ 35
3.4.1 FEC TLV ............................................... 36 3.4.1 FEC TLV ............................................... 36
3.4.1.1 FEC Procedures ........................................ 37 3.4.1.1 FEC Procedures ........................................ 37
3.4.2 Label TLVs ............................................ 38 3.4.2 Label TLVs ............................................ 38
3.4.2.1 Generic Label TLV ..................................... 38 3.4.2.1 Generic Label TLV ..................................... 38
3.4.2.2 ATM Label TLV ......................................... 38 3.4.2.2 ATM Label TLV ......................................... 38
3.4.2.3 Frame Relay Label TLV ................................. 39 3.4.2.3 Frame Relay Label TLV ................................. 39
3.4.3 Address List TLV ...................................... 40 3.4.3 Address List TLV ...................................... 40
3.4.4 Hop Count TLV ......................................... 40 3.4.4 Hop Count TLV ......................................... 41
3.4.4.1 Hop Count Procedures .................................. 41 3.4.4.1 Hop Count Procedures .................................. 41
3.4.5 Path Vector TLV ....................................... 42 3.4.5 Path Vector TLV ....................................... 43
3.4.5.1 Path Vector Procedures ................................ 43 3.4.5.1 Path Vector Procedures ................................ 43
3.4.5.1.1 Label Request Path Vector ............................. 43 3.4.5.1.1 Label Request Path Vector ............................. 43
3.4.5.1.2 Label Mapping Path Vector ............................. 43 3.4.5.1.2 Label Mapping Path Vector ............................. 44
3.4.6 Status TLV ............................................ 44 3.4.6 Status TLV ............................................ 45
3.5 LDP Messages .......................................... 46 3.5 LDP Messages .......................................... 46
3.5.1 Notification Message .................................. 48 3.5.1 Notification Message .................................. 49
3.5.1.1 Notification Message Procedures ....................... 49 3.5.1.1 Notification Message Procedures ....................... 50
3.5.1.2 Events Signaled by Notification Messages .............. 49 3.5.1.2 Events Signaled by Notification Messages .............. 50
3.5.1.2.1 Malformed PDU or Message .............................. 50 3.5.1.2.1 Malformed PDU or Message .............................. 51
3.5.1.2.2 Unknown or Malformed TLV .............................. 51 3.5.1.2.2 Unknown or Malformed TLV .............................. 52
3.5.1.2.3 Session KeepAlive Timer Expiration .................... 51 3.5.1.2.3 Session KeepAlive Timer Expiration .................... 52
3.5.1.2.4 Unilateral Session Shutdown ........................... 51 3.5.1.2.4 Unilateral Session Shutdown ........................... 52
3.5.1.2.5 Initialization Message Events ......................... 51 3.5.1.2.5 Initialization Message Events ......................... 52
3.5.1.2.6 Events Resulting From Other Messages .................. 52 3.5.1.2.6 Events Resulting From Other Messages .................. 53
3.5.1.2.7 Internal Errors ....................................... 52 3.5.1.2.7 Internal Errors ....................................... 53
3.5.1.2.8 Miscellaneous Events .................................. 52 3.5.1.2.8 Miscellaneous Events .................................. 53
3.5.2 Hello Message ......................................... 52 3.5.2 Hello Message ......................................... 53
3.5.2.1 Hello Message Procedures .............................. 54 3.5.2.1 Hello Message Procedures .............................. 55
3.5.3 Initialization Message ................................ 56 3.5.3 Initialization Message ................................ 57
3.5.3.1 Initialization Message Procedures ..................... 64 3.5.3.1 Initialization Message Procedures ..................... 65
3.5.4 KeepAlive Message ..................................... 64 3.5.4 KeepAlive Message ..................................... 65
3.5.4.1 KeepAlive Message Procedures .......................... 64 3.5.4.1 KeepAlive Message Procedures .......................... 65
3.5.5 Address Message ....................................... 65 3.5.5 Address Message ....................................... 66
3.5.5.1 Address Message Procedures ............................ 65 3.5.5.1 Address Message Procedures ............................ 66
3.5.6 Address Withdraw Message .............................. 66 3.5.6 Address Withdraw Message .............................. 67
3.5.6.1 Address Withdraw Message Procedures ................... 67 3.5.6.1 Address Withdraw Message Procedures ................... 68
3.5.7 Label Mapping Message ................................. 67 3.5.7 Label Mapping Message ................................. 68
3.5.7.1 Label Mapping Message Procedures ...................... 68 3.5.7.1 Label Mapping Message Procedures ...................... 69
3.5.7.1.1 Independent Control Mapping ........................... 69 3.5.7.1.1 Independent Control Mapping ........................... 70
3.5.7.1.2 Ordered Control Mapping ............................... 69 3.5.7.1.2 Ordered Control Mapping ............................... 70
3.5.7.1.3 Downstream on Demand Label Advertisement .............. 70 3.5.7.1.3 Downstream on Demand Label Advertisement .............. 71
3.5.7.1.4 Downstream Unsolicited Label Advertisement ............ 70 3.5.7.1.4 Downstream Unsolicited Label Advertisement ............ 71
3.5.8 Label Request Message ................................. 71 3.5.8 Label Request Message ................................. 72
3.5.8.1 Label Request Message Procedures ...................... 72 3.5.8.1 Label Request Message Procedures ...................... 73
3.5.9 Label Abort Request Message ........................... 73 3.5.9 Label Abort Request Message ........................... 74
3.5.9.1 Label Abort Request Message Procedures ................ 74 3.5.9.1 Label Abort Request Message Procedures ................ 75
3.5.10 Label Withdraw Message ................................ 76 3.5.10 Label Withdraw Message ................................ 77
3.5.10.1 Label Withdraw Message Procedures ..................... 77 3.5.10.1 Label Withdraw Message Procedures ..................... 78
3.5.11 Label Release Message ................................. 77 3.5.11 Label Release Message ................................. 78
3.5.11.1 Label Release Message Procedures ...................... 78 3.5.11.1 Label Release Message Procedures ...................... 79
3.6 Messages and TLVs for Extensibility ................... 79 3.6 Messages and TLVs for Extensibility ................... 80
3.6.1 LDP Vendor-private Extensions ......................... 79 3.6.1 LDP Vendor-private Extensions ......................... 80
3.6.1.1 LDP Vendor-private TLVs ............................... 79 3.6.1.1 LDP Vendor-private TLVs ............................... 80
3.6.1.2 LDP Vendor-private Messages ........................... 81 3.6.1.2 LDP Vendor-private Messages ........................... 82
3.6.2 LDP Experimental Extensions ........................... 82 3.6.2 LDP Experimental Extensions ........................... 83
3.7 Message Summary ....................................... 82 3.7 Message Summary ....................................... 84
3.8 TLV Summary ........................................... 83 3.8 TLV Summary ........................................... 84
3.9 Status Code Summary ................................... 84 3.9 Status Code Summary ................................... 85
3.10 Well-known Numbers .................................... 85 3.10 Well-known Numbers .................................... 86
3.10.1 UDP and TCP Ports ..................................... 85 3.10.1 UDP and TCP Ports ..................................... 86
3.10.2 Implicit NULL Label ................................... 85 3.10.2 Implicit NULL Label ................................... 86
4 IANA Considerations ................................... 85 4 IANA Considerations ................................... 87
4.1 Message Type Name Space ............................... 85 4.1 Message Type Name Space ............................... 87
4.2 TLV Type Name Space ................................... 86 4.2 TLV Type Name Space ................................... 87
4.3 FEC Type Name Space ................................... 86 4.3 FEC Type Name Space ................................... 88
4.4 Status Code Name Space ................................ 87 4.4 Status Code Name Space ................................ 88
4.5 Experiment ID Name Space .............................. 87 4.5 Experiment ID Name Space .............................. 88
5 Security Considerations ............................... 87 5 Security Considerations ............................... 89
5.1 Spoofing .............................................. 87 5.1 Spoofing .............................................. 89
5.2 Privacy ............................................... 88 5.2 Privacy ............................................... 90
5.3 Denial of Service ..................................... 89 5.3 Denial of Service ..................................... 90
6 Areas for Future Study ................................ 90 6 Areas for Future Study ................................ 92
7 Changes from RFC3036 .................................. 91 7 Changes from RFC3036 .................................. 93
8 Acknowledgments ....................................... 93 8 Acknowledgments ....................................... 95
9 References ............................................ 93 9 References ............................................ 96
9.1 Normative references .................................. 93 9.1 Normative references .................................. 96
9.2 Non-normative references .............................. 94 9.2 Non-normative references .............................. 96
10 Intellectual Property Statement ....................... 95 10 Intellectual Property Statement ....................... 97
11 Editors' Addresses .................................... 95 11 Editors' Addresses .................................... 98
Appendix A LDP Label Distribution Procedures ..................... 96 Appendix A LDP Label Distribution Procedures ..................... 99
A.1 Handling Label Distribution Events .................... 98 A.1 Handling Label Distribution Events .................... 101
A.1.1 Receive Label Request ................................. 99 A.1.1 Receive Label Request ................................. 102
A.1.2 Receive Label Mapping ................................. 102 A.1.2 Receive Label Mapping ................................. 105
A.1.3 Receive Label Abort Request ........................... 108 A.1.3 Receive Label Abort Request ........................... 111
A.1.4 Receive Label Release ................................. 110 A.1.4 Receive Label Release ................................. 113
A.1.5 Receive Label Withdraw ................................ 112 A.1.5 Receive Label Withdraw ................................ 115
A.1.6 Recognize New FEC ..................................... 113 A.1.6 Recognize New FEC ..................................... 117
A.1.7 Detect Change in FEC Next Hop ......................... 116 A.1.7 Detect Change in FEC Next Hop ......................... 119
A.1.8 Receive Notification / Label Request Aborted .......... 119 A.1.8 Receive Notification / Label Request Aborted .......... 122
A.1.9 Receive Notification / No Label Resources ............. 119 A.1.9 Receive Notification / No Label Resources ............. 123
A.1.10 Receive Notification / No Route ....................... 120 A.1.10 Receive Notification / No Route ....................... 123
A.1.11 Receive Notification / Loop Detected .................. 121 A.1.11 Receive Notification / Loop Detected .................. 124
A.1.12 Receive Notification / Label Resources Available ...... 121 A.1.12 Receive Notification / Label Resources Available ...... 125
A.1.13 Detect local label resources have become available .... 122 A.1.13 Detect local label resources have become available .... 126
A.1.14 LSR decides to no longer label switch a FEC ........... 123 A.1.14 LSR decides to no longer label switch a FEC ........... 127
A.1.15 Timeout of deferred label request ..................... 124 A.1.15 Timeout of deferred label request ..................... 127
A.2 Common Label Distribution Procedures .................. 124 A.2 Common Label Distribution Procedures .................. 128
A.2.1 Send_Label ............................................ 125 A.2.1 Send_Label ............................................ 128
A.2.2 Send_Label_Request .................................... 126 A.2.2 Send_Label_Request .................................... 130
A.2.3 Send_Label_Withdraw ................................... 127 A.2.3 Send_Label_Withdraw ................................... 131
A.2.4 Send_Notification ..................................... 128 A.2.4 Send_Notification ..................................... 131
A.2.5 Send_Message .......................................... 128 A.2.5 Send_Message .......................................... 132
A.2.6 Check_Received_Attributes ............................. 129 A.2.6 Check_Received_Attributes ............................. 132
A.2.7 Prepare_Label_Request_Attributes ...................... 130 A.2.7 Prepare_Label_Request_Attributes ...................... 133
A.2.8 Prepare_Label_Mapping_Attributes ...................... 132 A.2.8 Prepare_Label_Mapping_Attributes ...................... 135
Full Copyright Statement .............................. 135 Full Copyright Statement .............................. 138
1. LDP Overview 1. LDP Overview
The MPLS architecture [RFC3031] defines a label distribution protocol The MPLS architecture [RFC3031] defines a label distribution protocol
as a set of procedures by which one Label Switched Router (LSR) as a set of procedures by which one Label Switched Router (LSR)
informs another of the meaning of labels used to forward traffic informs another of the meaning of labels used to forward traffic
between and through them. 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 proto- protocol. In fact, a number of different label distribution proto-
skipping to change at page 7, line 45 skipping to change at page 7, line 45
LDP associates a Forwarding Equivalence Class (FEC) [RFC3031] with LDP associates a Forwarding Equivalence Class (FEC) [RFC3031] with
each LSP it creates. The FEC associated with an LSP specifies which each LSP it creates. The FEC associated with an LSP specifies which
packets are "mapped" to that LSP. LSPs are extended through a net- packets are "mapped" to that LSP. LSPs are extended through a net-
work as each LSR "splices" incoming labels for a FEC to the outgoing work as each LSR "splices" incoming labels for a FEC to the outgoing
label assigned to the next hop for the given FEC. label assigned to the next hop for the given FEC.
More information about the applicability of LDP can be found in More information about the applicability of LDP can be found in
[RFC3037]. [RFC3037].
This document assumes familiarity with the MPLS architecture This document assumes (but does not require) familiarity with the
[RFC3031]. Note that [RFC3031] includes a glossary of MPLS terminol- MPLS architecture [RFC3031]. Note that [RFC3031] includes a glossary
ogy, such as ingress, label switched path, etc. of MPLS terminology, such as ingress, label switched path, etc.
1.1. LDP Peers 1.1. LDP Peers
Two LSRs which use LDP to exchange label/FEC mapping information are Two LSRs which use LDP to exchange label/FEC mapping information are
known as "LDP Peers" with respect to that information and we speak of known as "LDP Peers" with respect to that information and we speak of
there being an "LDP Session" between them. A single LDP session there being an "LDP Session" between them. A single LDP session
allows each peer to learn the other's label mappings; i.e., the pro- allows each peer to learn the other's label mappings; i.e., the pro-
tocol is bi-directional. tocol is bi-directional.
1.2. LDP Message Exchange 1.2. LDP Message Exchange
skipping to change at page 11, line 30 skipping to change at page 11, line 30
2.2.1. Label Spaces 2.2.1. Label Spaces
The notion of "label space" is useful for discussing the assignment The notion of "label space" is useful for discussing the assignment
and distribution of labels. There are two types of label spaces: and distribution of labels. There are two types of label spaces:
- Per interface label space. Interface-specific incoming labels - Per interface label space. Interface-specific incoming labels
are used for interfaces that use interface resources for labels. are used for interfaces that use interface resources for labels.
An example of such an interface is a label-controlled ATM inter- An example of such an interface is a label-controlled ATM inter-
face that uses VCIs as labels, or a Frame Relay interface that face that uses VCIs as labels, or a Frame Relay interface that
uses DLCIs as labels. uses DLCIs (Data Link Connection Identifiers) as labels.
Note that the use of a per interface label space only makes sense Note that the use of a per interface label space only makes sense
when the LDP peers are "directly connected" over an interface, when the LDP peers are "directly connected" over an interface,
and the label is only going to be used for traffic sent over that and the label is only going to be used for traffic sent over that
interface. interface.
- Per platform label space. Platform-wide incoming labels are used - Per platform label space. Platform-wide incoming labels are used
for interfaces that can share the same labels. for interfaces that can share the same labels.
2.2.2. LDP Identifiers 2.2.2. LDP Identifiers
skipping to change at page 16, line 29 skipping to change at page 16, line 29
An LSR MUST advertise the same transport address in all Hellos that An LSR MUST advertise the same transport address in all Hellos that
advertise the same label space. This requirement ensures that two advertise the same label space. This requirement ensures that two
LSRs linked by multiple Hello adjacencies using the same label spaces LSRs linked by multiple Hello adjacencies using the same label spaces
play the same connection establishment role for each adjacency. play the same connection establishment role for each adjacency.
2.5.3. Session Initialization 2.5.3. Session Initialization
After LSR1 and LSR2 establish a transport connection they negotiate After LSR1 and LSR2 establish a transport connection they negotiate
session parameters by exchanging LDP Initialization messages. The session parameters by exchanging LDP Initialization messages. The
parameters negotiated include LDP protocol version, label distribu- parameters negotiated include LDP protocol version, label distribu-
tion method, timer values, VPI/VCI ranges for label controlled ATM, tion method, timer values, VPI/VCI (Virtual Path Identifier/ Virtual
DLCI ranges for label controlled Frame Relay, etc. Channel Identifier) ranges for label controlled ATM, DLCI (Data Link
Connection Identifier) ranges for label controlled Frame Relay, etc.
Successful negotiation completes establishment of an LDP session Successful negotiation completes establishment of an LDP session
between LSR1 and LSR2 for the advertisement of label spaces LSR1:a between LSR1 and LSR2 for the advertisement of label spaces LSR1:a
and LSR2:b. and LSR2:b.
The following describes the session initialization from LSR1's point The following describes the session initialization from LSR1's point
of view. of view.
After the connection is established, if LSR1 is playing the active After the connection is established, if LSR1 is playing the active
role, it initiates negotiation of session parameters by sending an role, it initiates negotiation of session parameters by sending an
skipping to change at page 18, line 17 skipping to change at page 18, line 17
d. When LSR1 has received both an acceptable Initialization d. When LSR1 has received both an acceptable Initialization
message and a KeepAlive message the session is operational message and a KeepAlive message the session is operational
from LSR1's point of view. from LSR1's point of view.
Until the LDP session is established, no other messages Until the LDP session is established, no other messages
except those listed in the procedures above may be except those listed in the procedures above may be
exchanged, and the rules for processing the U-bit in LDP exchanged, and the rules for processing the U-bit in LDP
messages are overridden. If a message other than those messages are overridden. If a message other than those
listed in the procedures above is received, a Shutdown msg listed in the procedures above is received, a Shutdown msg
MUST be tranmitted and the transport connection MUST be MUST be transmitted and the transport connection MUST be
closed. closed.
It is possible for a pair of incompatibly configured LSRs that It is possible for a pair of incompatibly configured LSRs that
disagree on session parameters to engage in an endless sequence disagree on session parameters to engage in an endless sequence
of messages as each NAKs the other's Initialization messages with of messages as each NAKs the other's Initialization messages with
Error Notification messages. Error Notification messages.
An LSR MUST throttle its session setup retry attempts with an An LSR MUST throttle its session setup retry attempts with an
exponential backoff in situations where Initialization messages exponential backoff in situations where Initialization messages
are being NAK'd. It is also recommended that an LSR detecting are being NAK'd. It is also recommended that an LSR detecting
such a situation take action to notify an operator. such a situation take action to notify an operator.
The session establishment setup attempt following a NAK'd Ini- The session establishment setup attempt following a NAK'd Ini-
tialization message must be delayed no less than 15 seconds, and tialization message MUST be delayed no less than 15 seconds, and
subsequent delays must grow to a maximum delay of no less than 2 subsequent delays MUST grow to a maximum delay of no less than 2
minutes. The specific session establishment action that must be minutes. The specific session establishment action that must be
delayed is the attempt to open the session transport connection delayed is the attempt to open the session transport connection
by the LSR playing the active role. by the LSR playing the active role.
The throttled sequence of Initialization NAKs is unlikely to The throttled sequence of Initialization NAKs is unlikely to
cease until operator intervention reconfigures one of the LSRs. cease until operator intervention reconfigures one of the LSRs.
After such a configuration action there is no further need to After such a configuration action there is no further need to
throttle subsequent session establishment attempts (until their throttle subsequent session establishment attempts (until their
initialization messages are NAK'd). initialization messages are NAK'd).
skipping to change at page 22, line 7 skipping to change at page 22, line 7
LSR may send any protocol message to meet this requirement. In cir- LSR may send any protocol message to meet this requirement. In cir-
cumstances where an LSR has no other information to communicate to cumstances where an LSR has no other information to communicate to
its peer, it sends a KeepAlive message. its peer, it sends a KeepAlive message.
An LSR may choose to terminate an LDP session with a peer at any An LSR may choose to terminate an LDP session with a peer at any
time. Should it choose to do so, it informs the peer with a Shutdown time. Should it choose to do so, it informs the peer with a Shutdown
message. message.
2.6. Label Distribution and Management 2.6. Label Distribution and Management
The MPLS architecture [RF3031] allows an LSR to distribute a FEC The MPLS architecture [RFC3031] allows an LSR to distribute a FEC
label binding in response to an explicit request from another LSR. label binding in response to an explicit request from another LSR.
This is known as Downstream On Demand label distribution. It also This is known as Downstream On Demand label distribution. It also
allows an LSR to distribute label bindings to LSRs that have not allows an LSR to distribute label bindings to LSRs that have not
explicitly requested them. [RFC3031] calls this method of label dis- explicitly requested them. [RFC3031] calls this method of label dis-
tribution Unsolicited Downstream; this document uses the term Down- tribution Unsolicited Downstream; this document uses the term Down-
stream Unsolicited. stream Unsolicited.
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
skipping to change at page 23, line 17 skipping to change at page 23, line 17
1. The FEC refers to the LSR itself (including one of its directly 1. The FEC refers to the LSR itself (including one of its directly
attached interfaces). attached interfaces).
2. The next hop router for the FEC is outside of the Label Switch- 2. The next hop router for the FEC is outside of the Label Switch-
ing Network. ing Network.
3. FEC elements are reachable by crossing a routing domain bound- 3. FEC elements are reachable by crossing a routing domain bound-
ary, such as another area for OSPF summary networks, or another ary, such as another area for OSPF summary networks, or another
autonomous system for OSPF AS externals and BGP routes autonomous system for OSPF AS externals and BGP routes
[RFC2328] [RFC1771]. [RFC2328] [RFC4271].
Note that whether an LSR is an egress for a given FEC may change over Note that whether an LSR is an egress for a given FEC may change over
time, depending on the state of the network and LSR configuration time, depending on the state of the network and LSR configuration
settings. settings.
2.6.2. Label Retention Mode 2.6.2. Label Retention Mode
The MPLS architecture [RFC3031] introduces the notion of label reten- The MPLS architecture [RFC3031] introduces the notion of label reten-
tion mode which specifies whether an LSR maintains a label binding tion mode which specifies whether an LSR maintains a label binding
for a FEC learned from a neighbor that is not its next hop for the for a FEC learned from a neighbor that is not its next hop for the
skipping to change at page 25, line 47 skipping to change at page 25, line 47
ing a Hop Count TLV it increments the count. An LSR that detects ing a Hop Count TLV it increments the count. An LSR that detects
a Hop Count has reached a configured maximum value behaves as if a Hop Count has reached a configured maximum value behaves as if
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. The following paragraphs describes LDP loop detection procedures.
For these paragraphs, and only these paragraphs, "MUST" is redefined For these paragraphs, and only these paragraphs, "MUST" is redefined
to mean "MUST if configured for loop detection". The paragraphs to mean "MUST if configured for loop detection". The paragraphs
specify messages that must carry Path Vector and Hop Count TLVs. specify messages that MUST carry Path Vector and Hop Count TLVs.
Note that the Hop Count TLV and its procedures are used without the Note that the Hop Count TLV and its procedures are used without the
Path Vector TLV in situations when loop detection is not configured Path Vector TLV in situations when loop detection is not configured
(see [RFC3035] and [RFC3034]). (see [RFC3035] and [RFC3034]).
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.
skipping to change at page 29, line 42 skipping to change at page 29, line 42
in conjunction with ordered label distribution, to minimize the num- in conjunction with ordered label distribution, to minimize the num-
ber of Label Mapping update messages. ber of Label Mapping update messages.
2.9. Authenticity and Integrity of LDP Messages 2.9. Authenticity and Integrity of LDP Messages
This section specifies a mechanism to protect against the introduc- This section specifies a mechanism to protect against the introduc-
tion of spoofed TCP segments into LDP session connection streams. tion of spoofed TCP segments into LDP session connection streams.
The use of this mechanism MUST be supported as a configurable option. The use of this mechanism MUST be supported as a configurable option.
The mechanism is based on use of the TCP MD5 Signature Option speci- The mechanism is based on use of the TCP MD5 Signature Option speci-
fied in [RFC2385] for use by BGP. See [RFC1321] for a specification fied in [RFC2385] for use by BGP [RFC4271]. See [RFC1321] for a
of the MD5 hash function. specification of the MD5 hash function. From a standards maturity
point of view, the current document relates to [RFC2385] the same way
as [RFC4271] relates to [RFC2385]. This is explained in [RFC4278].
2.9.1. TCP MD5 Signature Option 2.9.1. 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 current existing practice for securing This document describes current existing practice for securing
skipping to change at page 30, line 46 skipping to change at page 30, line 52
TCP implementations with changing passwords). TCP implementations with changing passwords).
Finally, there is no negotiation for the use of this option in Finally, there is no negotiation for the use of this option in
a connection, rather it is purely a matter of site policy a connection, rather it is purely a matter of site policy
whether or not its connections use the option." whether or not its connections use the option."
"MD5 as a Hashing Algorithm "MD5 as a Hashing Algorithm
Since this memo was first issued (under a different title), the Since this memo was first issued (under a different title), the
MD5 algorithm has been found to be vulnerable to collision MD5 algorithm has been found to be vulnerable to collision
search attacks [Dobb], and is considered by some to be insuffi- search attacks [Dobb], and is considered by some to be
ciently strong for this type of application. insufficiently strong for this type of application.
This memo still specifies the MD5 algorithm, however, since the This memo still specifies the MD5 algorithm, however, since the
option has already been deployed operationally, and there was option has already been deployed operationally, and there was
no "algorithm type" field defined to allow an upgrade using the no "algorithm type" field defined to allow an upgrade using the
same option number. The original document did not specify a same option number. The original document did not specify a
type field since this would require at least one more byte, and type field since this would require at least one more byte, and
it was felt at the time that taking 19 bytes for the complete it was felt at the time that taking 19 bytes for the complete
option (which would probably be padded to 20 bytes in TCP option (which would probably be padded to 20 bytes in TCP
implementations) would be too much of a waste of the already implementations) would be too much of a waste of the already
limited option space. limited option space.
skipping to change at page 33, line 16 skipping to change at page 33, line 16
Two octet integer specifying the total length of this PDU in octets, Two octet integer specifying the total length of this PDU in octets,
excluding the Version and PDU Length fields. excluding the Version and PDU Length fields.
The maximum allowable PDU Length is negotiable when an LDP session is The maximum allowable PDU Length is negotiable when an LDP session is
initialized. Prior to completion of the negotiation the maximum initialized. Prior to completion of the negotiation the maximum
allowable length is 4096 bytes. allowable length is 4096 bytes.
LDP Identifier LDP Identifier
Six octet field that uniquely identifies the label space of the send- Six octet field that uniquely identifies the label space of the send-
ing LSR for which this PDU applies. The first four octets identify ing LSR for which this PDU applies. The first four octets identify
the LSR and must be a globally unique value. It should be a 32-bit the LSR and MUST be a globally unique value. It SHOULD be a 32-bit
router Id assigned to the LSR and also used to identify it in loop router Id assigned to the LSR and also used to identify it in loop
detection Path Vectors. The last two octets identify a label space detection Path Vectors. The last two octets identify a label space
within the LSR. For a platform-wide label space, these should both be within the LSR. For a platform-wide label space, these SHOULD both be
zero. zero.
Note that there is no alignment requirement for the first octet of an Note that there is no alignment requirement for the first octet of an
LDP PDU. LDP PDU.
3.2. LDP Procedures 3.2. LDP Procedures
LDP defines messages, TLVs and procedures in the following areas: LDP defines messages, TLVs and procedures in the following areas:
- Peer discovery; - Peer discovery;
skipping to change at page 37, line 20 skipping to change at page 37, line 20
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (2) | Address Family | PreLen | | Prefix (2) | Address Family | PreLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix | | Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Family Address Family
Two octet quantity containing a value from ADDRESS FAMILY NUM- Two octet quantity containing a value from ADDRESS FAMILY NUM-
BERS in [RFC1700] that encodes the address family for the BERS in [ASSIGNED_AF] that encodes the address family for the
address prefix in the Prefix field. address prefix in the Prefix field.
PreLen PreLen
One octet unsigned integer containing the length in bits of the One octet unsigned integer containing the length in bits of the
address prefix that follows. A length of zero indicates a pre- address prefix that follows. A length of zero indicates a pre-
fix that matches all addresses (the default destination); in fix that matches all addresses (the default destination); in
this case the Prefix itself is zero octets). this case the Prefix itself is zero octets).
Prefix Prefix
An address prefix encoded according to the Address Family An address prefix encoded according to the Address Family
skipping to change at page 38, line 28 skipping to change at page 38, line 28
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| Generic Label (0x0200) | Length | |0|0| Generic Label (0x0200) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | | Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label Label
This is a 20-bit label value as specified in [RFC3032] represented This is a 20-bit label value represented as a 20-bit number in a 4
as a 20-bit number in a 4 octet field. octet field as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For further information, see [RFC3032].
3.4.2.2. ATM Label TLV 3.4.2.2. ATM Label TLV
An LSR uses ATM Label TLVs to encode labels for use on ATM links. An LSR uses ATM Label TLVs to encode labels for use on ATM links.
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| ATM Label (0x0201) | Length | |0|0| ATM Label (0x0201) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 39, line 44 skipping to change at page 40, line 6
Len Len
This field specifies the number of bits of the DLCI. The follow- This field specifies the number of bits of the DLCI. The follow-
ing values are supported: ing values are supported:
0 = 10 bits DLCI 0 = 10 bits DLCI
2 = 23 bits DLCI 2 = 23 bits DLCI
Len values 1 and 3 are reserved. Len values 1 and 3 are reserved.
DLCI DLCI
The Data Link Connection Identifier. Refer to [RFC3034] for the The Data Link Connection Identifier
label values and formats.
For a 10bit DLCI, the encoding is:
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|0| Frame Relay Label (0x0202)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Len| 0 | 10 bit DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For a 23bit DLCI, the encoding is:
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|0| Frame Relay Label (0x0202)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Len| 23 bit DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For further information, see [RFC3034].
3.4.3. Address List TLV 3.4.3. Address List TLV
The Address List TLV appears in Address and Address Withdraw mes- The Address List TLV appears in Address and Address Withdraw mes-
sages. sages.
Its encoding is: Its encoding 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 40, line 26 skipping to change at page 41, line 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | | | Address Family | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Addresses | | Addresses |
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Family Address Family
Two octet quantity containing a value from ADDRESS FAMILY NUMBERS Two octet quantity containing a value from ADDRESS FAMILY NUMBERS
in [RFC1700] that encodes the addresses contained in the Addresses in [ASSIGNED_AF] that encodes the addresses contained in the
field. Addresses field.
Addresses Addresses
A list of addresses from the specified Address Family. The A list of addresses from the specified Address Family. The
encoding of the individual addresses depends on the Address Family. encoding of the individual addresses depends on the Address
Family.
The following address encodings are defined by this version of the The following address encodings are defined by this version of the
protocol: protocol:
Address Family Address Encoding Address Family Address Encoding
IPv4 4 octet full IPv4 address IPv4 4 octet full IPv4 address
IPv6 16 octet full IPv6 address IPv6 16 octet full IPv6 address
3.4.4. Hop Count TLV 3.4.4. Hop Count TLV
skipping to change at page 42, line 18 skipping to change at page 42, line 46
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.
These updates are useless overhead since they don't reflect the hop These updates are useless overhead since they don't reflect the hop
count to the egress. count to the egress.
>From the perspective of the ingress node, the fact that the hop >From the perspective of the ingress node, the fact that the hop
count is unknown implies nothing about whether a packet sent on the count is unknown implies nothing about whether a packet sent on the
LSP will actually make it to the egress. All it implies is that the LSP will actually make it to the egress. All it implies is that the
hop count update from the egress has not yet reached the ingress. hop count update from the egress has not yet reached the ingress.
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
of the message. of the message.
If Loop Detection is configured, the LSR MUST follow the procedures If Loop Detection is configured, the LSR MUST follow the procedures
specified in Section "Loop Detection". specified in Section "Loop Detection".
3.4.5. Path Vector TLV 3.4.5. Path Vector TLV
skipping to change at page 47, line 18 skipping to change at page 48, line 14
specifications in the sections that follow. specifications in the sections that follow.
Optional Parameters Optional Parameters
Variable length set of optional message parameters. Many messages Variable length set of optional message parameters. Many messages
have no optional parameters. have no optional parameters.
For messages that have optional parameters, the optional parame- For messages that have optional parameters, the optional parame-
ters may appear in any order. ters may appear in any order.
Note that there is no alignment requirement for the first octet of an Note that there is no alignment requirement for the first octet of an
LDP message. LDP message and that there is no padding at the end of a message;
that is, parameters can end at odd-byte boundaries.
The following message types are defined in this version of LDP: The following message types are defined in this version of LDP:
Message Name Section Title Message Name Section Title
Notification "Notification Message" Notification "Notification Message"
Hello "Hello Message" Hello "Hello Message"
Initialization "Initialization Message" Initialization "Initialization Message"
KeepAlive "KeepAlive Message" KeepAlive "KeepAlive Message"
Address "Address Message" Address "Address Message"
skipping to change at page 50, line 50 skipping to change at page 51, line 50
- The Message Length is too large, that is, indicates that the - The Message Length is too large, that is, indicates that the
message extends beyond the end of the containing LDP PDU. This message extends beyond the end of the containing LDP PDU. This
is a fatal error signaled by the Bad Message Length Status is a fatal error signaled by the Bad Message Length Status
Code. Code.
- The Message Length is too small, that is, smaller than the - The Message Length is too small, that is, smaller than the
smallest possible value component. This is a fatal error sig- smallest possible value component. This is a fatal error sig-
naled by the Bad Message Length Status Code. naled by the Bad Message Length Status Code.
- The message is missing one or more Mandatory Parameters. This - The message is missing one or more Mandatory Parameters. This
is a non-fatal error signalled by the Missing Message Parame- is a non-fatal error signaled by the Missing Message Parameters
ters Status Code. Status Code.
3.5.1.2.2. Unknown or Malformed TLV 3.5.1.2.2. Unknown or Malformed TLV
Malformed TLVs contained in LDP messages that are part of the LDP Malformed TLVs contained in LDP messages that are part of the LDP
Discovery mechanism are handled by silently discarding the containing Discovery mechanism are handled by silently discarding the containing
message. message.
A TLV contained in an LDP message received on a TCP connection of an A TLV contained in an LDP message received on a TCP connection of an
LDP is malformed if: LDP is malformed if:
skipping to change at page 59, line 44 skipping to change at page 60, line 44
- 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 non- - The interoperability of VP-merge-capable switches with non-
VP-merge-capable switches is a subject for future study. VP-merge-capable switches is a subject for future study.
When the LSRs differ on the use of VP-merge, the session is When the LSRs differ on the use of VP-merge, the session is
established, but VP merge is not used. established, but VP merge is not used.
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 (see [ATM-VP]). 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.
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 (within a given VPI) support the use of a given VCI as LSR can (within a given VPI) support the use of a given VCI as
a label for both link directions independently. A value of 1 a label for both link directions independently. A value of 1
specifies unidirectional VC capability, meaning (within a given specifies unidirectional VC capability, meaning (within a given
skipping to change at page 61, line 32 skipping to change at page 62, line 32
Virtual Connection Identifiers that is supported on the Virtual Connection Identifiers that is supported on the
originating switch. If the VCI is less than 16-bits it originating switch. If the VCI is less than 16-bits it
SHOULD be right justified in this field and preceding bits SHOULD be right justified in this field and preceding bits
SHOULD be set to 0. SHOULD be set to 0.
When peer LSRs are connected indirectly by means of an ATM VP, the When peer LSRs are connected indirectly by means of an ATM VP, the
sending LSR SHOULD set the Minimum and Maximum VPI fields to 0, sending LSR SHOULD set the Minimum and Maximum VPI fields to 0,
and the receiving LSR MUST ignore the Minimum and Maximum VPI and the receiving LSR MUST ignore the Minimum and Maximum VPI
fields. fields.
See [ATM-VP] for specification of the fields for ATM Label Range
Components to be used with VP merge LSRs.
Frame Relay Session Parameters Frame Relay Session Parameters
Used when an LDP session manages label exchange for a Frame Used when an LDP session manages label exchange for a Frame
Relay link to specify Frame Relay-specific session parameters. Relay link to specify Frame Relay-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| FR Sess Parms (0x0502) | Length | |0|0| FR Sess Parms (0x0502) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| M | N |D| Reserved | | M | N |D| Reserved |
skipping to change at page 64, line 46 skipping to change at page 65, line 46
No optional parameters are defined for the KeepAlive message. No optional parameters are defined for the KeepAlive message.
3.5.4.1. KeepAlive Message Procedures 3.5.4.1. KeepAlive Message Procedures
The KeepAlive Timer mechanism described in Section "Maintaining LDP The KeepAlive Timer mechanism described in Section "Maintaining LDP
Sessions" resets a session KeepAlive timer every time an LDP PDU is Sessions" resets a session KeepAlive timer every time an LDP PDU is
received on the session TCP connection. The KeepAlive Message is received on the session TCP connection. The KeepAlive Message is
provided to allow reset of the KeepAlive Timer in circumstances where provided to allow reset of the KeepAlive Timer in circumstances where
an LSR has no other information to communicate to an LDP peer. an LSR has no other information to communicate to an LDP peer.
An LSR must arrange that its peer receive an LDP Message from it at An LSR MUST arrange that its peer receive an LDP Message from it at
least every KeepAlive Time period. Any LDP protocol message will do least every KeepAlive Time period. Any LDP protocol message will do
but, in circumstances where no other LDP protocol messages have been but, in circumstances where no other LDP protocol messages have been
sent within the period, a KeepAlive message MUST be sent. sent within the period, a KeepAlive message MUST be sent.
3.5.5. Address Message 3.5.5. Address Message
An LSR sends the Address Message to an LDP peer to advertise its An LSR sends the Address Message to an LDP peer to advertise its
interface addresses. interface addresses.
The encoding for the Address Message is: The encoding for the Address Message is:
skipping to change at page 65, line 32 skipping to change at page 66, line 32
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters | | Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID Message ID
32-bit value used to identify this message. 32-bit value used to identify this message.
Address List TLV Address List TLV
The list of interface addresses being advertised by the sending The list of interface addresses being advertised by the sending
LSR. The encoding for the Address List TLV is specified in Section LSR. The encoding for the Address List TLV is specified in
"Address List TLV". Section "Address List TLV".
Optional Parameters Optional Parameters
No optional parameters are defined for the Address message. No optional parameters are defined for the Address message.
3.5.5.1. Address Message Procedures 3.5.5.1. Address Message Procedures
An LSR that receives an Address Message message uses the addresses it An LSR that receives an Address Message message uses the addresses it
learns to maintain a database for mapping between peer LDP Identi- learns to maintain a database for mapping between peer LDP Identi-
fiers and next hop addresses; see Section "LDP Identifiers and Next fiers and next hop addresses; see Section "LDP Identifiers and Next
Hop Addresses". Hop Addresses".
skipping to change at page 79, line 36 skipping to change at page 80, line 36
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 Appendix 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 handles 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
Vendor-private TLVs and messages are used to convey vendor-private Vendor-private TLVs and messages are used to convey vendor-private
information between LSRs. information between LSRs.
3.6.1.1. LDP Vendor-private TLVs 3.6.1.1. LDP Vendor-private TLVs
skipping to change at page 80, line 32 skipping to change at page 81, line 32
U bit U bit
Unknown TLV bit. Upon receipt of an unknown TLV, if U is clear Unknown TLV bit. Upon receipt of an unknown TLV, if U is clear
(=0), a notification MUST be returned to the message originator (=0), a notification MUST be returned to the message originator
and the entire message MUST be ignored; if U is set (=1), the and the entire message MUST be ignored; if U is set (=1), the
unknown TLV is silently ignored and the rest of the message is unknown TLV is silently ignored and the rest of the message is
processed as if the unknown TLV did not exist. processed as if the unknown TLV did not exist.
The determination as to whether a vendor-private message is under- The determination as to whether a vendor-private message is under-
stood is based on the Type and the mandatory Vendor ID field. stood is based on the Type and the mandatory Vendor ID field.
Implementations that support vendor-private TLVs MUST support a
user-accessible configuration interface that causes the U-bit to
be set on all transmitted vendor-private TLVs; this requirement
MAY be satisfied by a user-accessible configuration interface that
prevents transmission of all vendor-private TLVs for which the U-
bit is clear.
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 TLV 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 inter- and Vendor Id field specify how the Data field is to be inter-
skipping to change at page 81, line 40 skipping to change at page 82, line 47
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U bit U bit
Unknown message bit. Upon receipt of an unknown message, if U is Unknown message bit. Upon receipt of an unknown message, if U is
clear (=0), a notification is returned to the message originator; clear (=0), a notification is returned to the message originator;
if U is set (=1), the unknown message is silently ignored. if U is set (=1), the unknown message is silently ignored.
The determination as to whether a vendor-private message is under- The determination as to whether a vendor-private message is under-
stood is based on the Msg Type and the Vendor ID parameter. stood is based on the Msg Type and the Vendor ID parameter.
Implementations that support vendor-private messages MUST support
a user-accessible configuration interface that causes the U-bit to
be set on all transmitted vendor-private messages; this require-
ment MAY be satisfied by a user-accessible configuration interface
that prevents transmission of all vendor-private messages for
which the U-bit is clear.
Msg Type Msg Type
Message type value in the range 0x3E00 through 0x3EFF. Together, Message type value in the range 0x3E00 through 0x3EFF. Together,
the Msg Type and the Vendor ID specify how the message is to be the Msg Type and the Vendor ID specify how the message is to be
interpreted. interpreted.
Message Length Message Length
Specifies the cumulative length in octets of the Message ID, Ven- Specifies the cumulative length in octets of the Message ID, Ven-
dor ID, Remaining Mandatory Parameters and Optional Parameters. dor ID, Remaining Mandatory Parameters and Optional Parameters.
Message ID Message ID
skipping to change at page 85, line 15 skipping to change at page 86, line 30
3.10. Well-known Numbers 3.10. Well-known Numbers
3.10.1. UDP and TCP Ports 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 3.10.2. Implicit NULL Label
The Implicit NULL label (see [RFC3031]) is represented as a Generic The Implicit NULL label is defined in [RFC3031] as follows:
Label TLV with a Label field value as specified by [RFC3032].
"The Implicit NULL label is a label with special semantics which an
LSR can bind to an address prefix. If LSR Ru, by consulting its ILM
(Incoming Label Map) sees that labeled packet P must be forwarded
next to Rd, but that Rd has distributed a binding of Implicit NULL to
the corresponding address prefix, then instead of replacing the value
of the label on top of the label stack, Ru pops the label stack, and
then forwards the resulting packet to Rd."
The implicit NULL label is represented in LDP as a Generic Label TLV
with a Label field value of 3, as defined in [RFC3032].
4. IANA Considerations 4. IANA Considerations
LDP defines the following name spaces which require management: LDP defines the following name spaces which require management:
- Message Type Name Space. - Message Type Name Space.
- TLV Type Name Space. - TLV Type Name Space.
- FEC Type Name Space. - FEC Type Name Space.
- Status Code Name Space. - Status Code Name Space.
- Experiment ID Name Space. - Experiment ID Name Space.
skipping to change at page 87, line 36 skipping to change at page 89, line 17
This section identifies threats to which LDP may be vulnerable and This section identifies threats to which LDP may be vulnerable and
discusses means by which those threats might be mitigated. discusses means by which those threats might be mitigated.
5.1. Spoofing 5.1. Spoofing
There are two types of LDP communication that could be the target of There are two types of LDP communication that could be the target of
a spoofing attack. a spoofing attack.
1. Discovery exchanges carried by UDP. 1. Discovery exchanges carried by UDP.
LSRs indicate their willingness to establish and maintain LDP ses-
sions by periodically sending Hello messages. Receipt of a Hello
serves to create a new "Hello adjacency", if one does not already
exist, or to refresh an existing one. Spoofing a Hello packet for
an existing adjacency can cause the adjacency to time out and that
can result in termination of the associated session. This can
occur when the spoofed Hello specifies a small Hold Time, causing
the receiver to expect Hellos within this interval, while the true
neighbor continues sending Hellos at the lower, previously agreed
to, frequency.
LSRs directly connected at the link level exchange Basic Hello LSRs directly connected at the link level exchange Basic Hello
messages over the link. The threat of spoofed Basic Hellos can be messages over the link. The threat of spoofed Basic Hellos can be
reduced by: reduced by:
o Accepting Basic Hellos only on interfaces to which LSRs that o Accepting Basic Hellos only on interfaces to which LSRs that
can be trusted are directly connected. can be trusted are directly connected.
o Ignoring Basic Hellos not addressed to the All Routers on o Ignoring Basic Hellos not addressed to the All Routers on
this Subnet multicast group. this Subnet multicast group.
skipping to change at page 89, line 47 skipping to change at page 91, line 30
2. Well known TCP port for LDP Session Establishment 2. Well known TCP port for LDP Session Establishment
Like other control plane protocols that use TCP, LDP may be the Like other control plane protocols that use TCP, LDP may be the
target of DoS attacks, such a SYN attacks. LDP is no more or less target of DoS attacks, such a SYN attacks. LDP is no more or less
vulnerable to such attacks than other control plane protocols that vulnerable to such attacks than other control plane protocols that
use TCP. use TCP.
The threat of such attacks can be mitigated somewhat by the fol- The threat of such attacks can be mitigated somewhat by the fol-
lowing: lowing:
o An LSR should avoid promiscuous TCP listens for LDP session o An LSR SHOULD avoid promiscuous TCP listens for LDP session
establishment. It should use only listens that are specific establishment. It SHOULD use only listens that are specific
to discovered peers. This enables it to drop attack packets to discovered peers. This enables it to drop attack packets
early in their processing since they are less likely to early in their processing since they are less likely to
match existing or in-progress connections. match existing or in-progress connections.
o The use of the MD5 option helps somewhat since it prevents a o The use of the MD5 option helps somewhat since it prevents a
SYN from being accepted unless the MD5 segment checksum is SYN from being accepted unless the MD5 segment checksum is
valid. However, the receiver must compute the checksum valid. However, the receiver must compute the checksum
before it can decide to discard an otherwise acceptable SYN before it can decide to discard an otherwise acceptable SYN
segment. segment.
skipping to change at page 90, line 30 skipping to change at page 92, line 19
- Section 2.16 of the MPLS architecture [RFC3031] requires that - Section 2.16 of the MPLS architecture [RFC3031] requires that
the initial label distribution protocol negotiation between the initial label distribution protocol negotiation between
peer LSRs enable each LSR to determine whether its peer is peer LSRs enable each LSR to determine whether its peer is
capable of popping the label stack. This version of LDP capable of popping the label stack. This version of LDP
assumes that LSRs support label popping for all link types assumes that LSRs support label popping for all link types
except ATM and Frame Relay. A future version may specify means except ATM and Frame Relay. A future version may specify means
to make this determination part of the session initiation nego- to make this determination part of the session initiation nego-
tiation. tiation.
- LDP support for CoS is not specified in this version. CoS sup- - LDP support for CoS (class of service) is not specified in this
port may be addressed in a future version. version. CoS support may be 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.
Multicast support may be addressed in a future version. Multicast support may be addressed in a future version.
- LDP support for multipath label switching is not specified in - LDP support for multipath label switching is not specified in
this version. Multipath support may be addressed in a future this version. Multipath support may be addressed in a future
version. version.
- LDP support for signalling the maximum transmission unit is not - LDP support for signalling the maximum transmission unit is not
specified in this version. It is discussed in the experimental specified in this version. It is discussed in the experimental
skipping to change at page 91, line 41 skipping to change at page 93, line 28
for a separate document. for a separate document.
7. Changes from RFC3036 7. Changes from RFC3036
Here is a list of changes from RFC3036 Here is a list of changes from RFC3036
1. Removed the Host Address FEC and references to it, since it is 1. Removed the Host Address FEC and references to it, since it is
not used by any implementation. not used by any implementation.
2. Split the reference list into normative and non-normative ref- 2. Split the reference list into normative and non-normative ref-
erences erences
3. Removed "MPLS using ATM VP Switching" from the list of norma- 3. Removed "MPLS using ATM VP Switching" from the list of norma-
tive references. tive references, and references to it.
4. Clarified the use of the F bit. 4. Removed reference to RFC 1700 and replaced it with a link to
5. Added option to allow split horizon when doing ordered control. http://www.iana.org/assignments/address-family-numbers.
6. Clarified the processing of messages with the U-bit set during 5. Removed reference to RFC 1771 and replaced it with a reference
to RFC 4271.
6. Clarified the use of the F bit.
7. Added option to allow split horizon when doing ordered control.
8. Clarified the processing of messages with the U-bit set during
the session initialization procedures the session initialization procedures
7. Clarified the processing of the E-bit during session initial- 9. Clarified the processing of the E-bit during session initial-
ization procedures. ization procedures.
8. Added text explaining that the shutdown message in the state 10. Added text explaining that the shutdown message in the state
transition diagram is implemented as as a notification message transition diagram is implemented as as a notification message
with a status TLV indicating a fatal error. with a status TLV indicating a fatal error.
11. Added case for TLV length too short in the specification for
9. Added case for TLV length too short in the specification for
handling malformed TLVs. handling malformed TLVs.
10. In the section describing handling of unknown TLV, removed ref- 12. Explained the security threat posed by hello spoofing.
erence to inexistent section (errata in original document) 13. Added reference to 4271 and 4278 and text for standards matu-
11. In the "receive label request" procedures, if a loop is rity variance with regards to the MD5 option.
14. Added text from 3031 explaining the handling of implicit NULL
label.
15. Included the encoding of DLCIs to remove normative reference to
3034.
16. Moved references to 3031, 3032 and 3034 to informative.
17. In the section describing handling of unknown TLV, removed ref-
erence to inexistent section (errata in original document).
18. Added text clarifying how to achieve interoperability when
sending vendor-private TLVs and messages.
19. In the "receive label request" procedures, if a loop is
detected, changed the procedure to send a notification before detected, changed the procedure to send a notification before
aborting the rest of the processing. aborting the rest of the processing.
12. In "receive label release" procedures, clarified the behavior 20. In "receive label release" procedures, clarified the behavior
for merge-capable LSRs. for merge-capable LSRs.
13. In "receive label release" procedures, clarified the behavior 21. In "receive label release" procedures, clarified the behavior
for receipt of an unknown FEC. for receipt of an unknown FEC.
14. In note 4 of "Detect Change in FEC Next Hop", modified the text 22. In note 4 of "Detect Change in FEC Next Hop", modified the text
to reference the correct set of conditions for sending a label to reference the correct set of conditions for sending a label
request procedure (typo in the original document). request procedure (typo in the original document).
15. In the procedures for "LSR decides to no longer label switch a 23. In the procedures for "LSR decides to no longer label switch a
FEC", clarified the fact that the label must not be reused FEC", clarified the fact that the label must not be reused
until a label release is received. until a label release is received.
16. In the routine "Prepare_Label_Mapping_Attributes" added a note 24. In the routine "Prepare_Label_Mapping_Attributes" added a note
regarding the treatment of unknown TLVs according to their U regarding the treatment of unknown TLVs according to their U
and F bits. and F bits.
17. In the address message processing procedures, clarified the 25. In the address message processing procedures, clarified the
behavior for the case where an LSR receives re-advertisement of behavior for the case where an LSR receives re-advertisement of
an address previously advertised it, or withdrawal of an an address previously advertised it, or withdrawal of an
address from an LSR that has not previously advertised that address from an LSR that has not previously advertised that
address. address.
18. In the routine "Receive Label Mapping" clarified the meaning of 26. In the routine "Receive Label Mapping" clarified the meaning of
PrevAdvLabel when no label advertisement message has been sent PrevAdvLabel when no label advertisement message has been sent
previously. previously.
19. In the "receive label mapping" procedures, if a loop is 27. In the "Receive Label Mapping" procedures, if a loop is
detected, modified the procedure to send a notification before detected, modified the procedure to send a notification before
aborting the rest of the processing. aborting the rest of the processing.
20. In the "receive label mapping" procedures, corrected step 28. In the "Receive Label Mapping" procedures, corrected step
LMp.10 to handle label mapping messages for additional (non- LMp.10 to handle label mapping messages for additional (non-
merged) LSPs for the FEC. merged) LSPs for the FEC.
21. In the routine "Receive Label Abort Request" clarified the 29. In the "Receive Label Mapping" procedures, clarified behavior
when receiving a duplicate label for the same FEC.
30. In the routine "Receive Label Abort Request" clarified the
behavior for non-merging LSRs. behavior for non-merging LSRs.
22. Added the following items to the section discussing areas for 31. Added the following items to the section discussing areas for
future study: future study:
o extensions for communicating the maximum transmission unit o extensions for communicating the maximum transmission unit
o basic peer discovery on NBMA media o basic peer discovery on NBMA media
o option of shutting down an adjacency o option of shutting down an adjacency
o mechanisms for securing Hello messages o mechanisms for securing Hello messages
o detection of a stateless fast control plane restart o detection of a stateless fast control plane restart
o support of "end of LIB" message o support of "end of LIB" message
o mechanisms for dealing with the case where different LSRs advertise o mechanisms for dealing with the case where different LSRs
the same address. advertise the same address.
8. Acknowledgments 8. Acknowledgments
This document was originally published as RFC 3036 in January 2001. This document was originally published as RFC 3036 in January 2001.
It was produced by the MPLS working of the IETF and was jointly It was produced by the MPLS working of the IETF and was jointly
authored by Loa Andersson, Paul Doolan, Nancy Feldman, Andre Fredette authored by Loa Andersson, Paul Doolan, Nancy Feldman, Andre Fredette
and Bob Thomas. and Bob Thomas.
The ideas and text in RFC3036 were collected from a number of The ideas and text in RFC3036 were collected from a number of
sources. We would like to thank Rick Boivie, Ross Callon, Alex 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 for their input for RFC3036. Rekhter, and Arun Viswanathan for their input for RFC3036.
The editors would like to thank Eric Gray for his insight and input The editors would like to thank Eric Gray, David Black and Sam Hart-
to the current document. man for their input to and review of the current document.
In addition, the editors would like to thank the members of the mpls In addition, the editors would like to thank the members of the mpls
working group for their ideas and the support they have given to this working group for their ideas and the support they have given to this
document, and in particular to Eric Rosen, Luca Martini, Markus Jork, document, and in particular to Eric Rosen, Luca Martini, Markus Jork,
Mark Duffy, Vach Kompella, Kishore Tiruveedhula. Rama Ramakrishnan, Mark Duffy, Vach Kompella, Kishore Tiruveedhula. Rama Ramakrishnan,
Nick Weeds and Adrian Farrel. Nick Weeds, Adrian Farrel and Andy Malis.
9. References 9. References
9.1. Normative references 9.1. Normative references
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 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] Heinanen, J., "Multiprotocol Encapsulation over ATM Adap- [RFC1483] Heinanen, J., "Multiprotocol Encapsulation over ATM Adap-
tation Layer 5", RFC 1483, July 1993. tation Layer 5", RFC 1483, July 1993.
[RFC1700] Reynolds, J. and J. Postel, "ASSIGNED NUMBERS", STD 2, [ASSIGNED_AF] http://www.iana.org/assignments/address-family-numbers
RFC 1700, October 1994.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP
Label Switching Architecture", RFC 3031, January 2001. MD5 Signature Option", RFC 2385, August 1998.
[RFC3032] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D.,
Fedorkow, G., Li, T. and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[RFC3034] Conta, A., Doolan, P. and A. Malis, "Use of Label Switch-
ing on Frame Relay Networks Specification", RFC 3034,
January 2001.
[RFC3035] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., [RFC3035] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y.,
Rosen, E., Swallow, G. and P. Doolan, "MPLS using LDP and Rosen, E., Swallow, G. and P. Doolan, "MPLS using LDP and
ATM VC Switching", RFC 3035, January 2001. ATM VC Switching", RFC 3035, January 2001.
[RFC3037] Thomas, B. and E. Gray, "LDP Applicability", RFC 3037, [RFC3037] Thomas, B. and E. Gray, "LDP Applicability", RFC 3037,
January 2001. January 2001.
9.2. Non-normative references 9.2. Non-normative references
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP
MD5 Signature Option", RFC 2385, August 1998.
[CRLDP] L. Andersson, A. Fredette, B. Jamoussi, R. Callon, P. [CRLDP] L. Andersson, A. Fredette, B. Jamoussi, R. Callon, P.
Doolan, N. Feldman, E. Gray, J. Halpern, J. Heinanen T. E. Kilty, A. Doolan, N. Feldman, E. Gray, J. Halpern, J. Heinanen T.
G. Malis, M. Girish, K. Sundell, P. Vaananen, T. Worster, L. Wu, R. E. Kilty, A. G. Malis, M. Girish, K. Sundell, P. Vaana-
Dantu, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002 nen, T. Worster, L. Wu, R. Dantu, "Constraint-Based LSP
Setup using LDP", RFC 3212, January 2002
[DIFFSERV] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. [DIFFSERV] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
and W. Weiss, "An Architecture for Differentiated Services", RFC and W. Weiss, "An Architecture for Differentiated Ser-
2475, December 1998. vices", RFC 2475, December 1998.
[LDP-MTU] Black, B. and Kompella, K. "Maximum Transmission Unit Sig- [LDP-MTU] Black, B. and Kompella, K. "Maximum Transmission Unit
nalling Extensions for the Label Distribution Protocol", draft-ietf- Signalling Extensions for the Label Distribution Proto-
mpls-ldp-mtu-extensions-03.txt, April 2004. col", draft-ietf-mpls-ldp-mtu-extensions-03.txt, April
2004.
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
(BGP-4)", RFC 1771, March 1995.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J.
McManus, "Requirements for Traffic Engineering over MPLS", RFC 2702, McManus, "Requirements for Traffic Engineering over
September 1999. MPLS", RFC 2702, September 1999.
[RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3032] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D.,
Fedorkow, G., Li, T. and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[RFC3034] Conta, A., Doolan, P. and A. Malis, "Use of Label Switch-
ing on Frame Relay Networks Specification", RFC 3034,
January 2001.
[RFC4271] Rekhter, Y., Li, T. and Hares, S. "A Border Gateway Pro-
tocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4278] Bellovin, S., Zinin, A., "Standards Maturity Variance
Regarding the TCP MD5 Signature Option (RFC 2385) and the
BGP-4 Specification", RFC 4278, January 2006.
10. Intellectual Property Statement 10. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 104, line 21 skipping to change at page 107, line 21
LMp.9 Does LSR have a previously received label mapping for FEC LMp.9 Does LSR have a previously received label mapping for FEC
from MsgSource for the LSP in question? (See Note 6.) from MsgSource for the LSP in question? (See Note 6.)
If not, goto LMp.11. If not, goto LMp.11.
LMp.10 Does the label previously received from MsgSource match LMp.10 Does the label previously received from MsgSource match
Label (i.e., the label received in the message)? Label (i.e., the label received in the message)?
(See Note 3.) (See Note 3.)
OR OR
Is the received label mapping in response to a previously Is the received label mapping in response to a previously
outstanding label request sent to MsgSource? (See Note 12). outstanding label request sent to MsgSource?
(See Note 12.)
If so, goto LMp.11. If so, goto LMp.11.
LMp.10a Is LSR operating in Downstream Unsolicited mode with Liberal LMp.10a Is LSR operating in Downstream Unsolicited mode?
Label retention? If so, delete the label mapping for the label previously
If not, goto LMp.32. (See Note 4.) received from MsgSource and remove it from
forwarding/switching use.
Execute procedure Send_Message (MsgSource, Label Release,
FEC, label previously received from MsgSource).
LMp.11 Determine the Next Hop for FEC. LMp.11 Determine the Next Hop for FEC.
LMp.12 Is MsgSource the Next Hop for FEC? LMp.12 Is MsgSource the Next Hop for FEC?
If so, goto LMp.14. If so, goto LMp.14.
LMp.13 Perform LSR Label Release procedure: LMp.13 Perform LSR Label Release procedure:
For Conservative Label retention: For Conservative Label retention:
skipping to change at page 105, line 20 skipping to change at page 108, line 25
LMp.19 Is the Downstream Unsolicited Ordered Control Label LMp.19 Is the Downstream Unsolicited Ordered Control Label
Distribution procedure being used by LSR? Distribution procedure being used by LSR?
If not, goto LMp.28. If not, goto LMp.28.
LMp.20 Execute procedure Prepare_Label_Mapping_Attributes(Peer, LMp.20 Execute procedure Prepare_Label_Mapping_Attributes(Peer,
FEC, RAttributes, SAttributes, IsPropagating, FEC, RAttributes, SAttributes, IsPropagating,
StoredHopCount). StoredHopCount).
LMp.21 Execute procedure Send_Message (Peer, Label Mapping, FEC, LMp.21 Execute procedure Send_Message (Peer, Label Mapping, FEC,
PrevAdvLabel, SAttributes). (See note 13.) PrevAdvLabel, SAttributes). (See Note 13.)
Goto LMp.28 Goto LMp.28
LMp.22 Iterate through LMp.27 for each label mapping for FEC LMp.22 Iterate through LMp.27 for each label mapping for FEC
previously sent to Peer. previously sent to Peer.
LMp.23 Are RAttributes in the received label mapping consistent LMp.23 Are RAttributes in the received label mapping consistent
with those previously sent to Peer? with those previously sent to Peer?
If so, continue iteration from LMp.22 for next label If so, continue iteration from LMp.22 for next label
mapping. (See Note 9.) mapping. (See Note 9.)
skipping to change at page 109, line 43 skipping to change at page 112, line 47
LAbR.5 Does LSR have a label mapping for FEC? LAbR.5 Does LSR have a label mapping for FEC?
If not, goto LAbR.11 If not, goto LAbR.11
LAbR.6 Generate Event: Received Label Release Message for FEC LAbR.6 Generate Event: Received Label Release Message for FEC
from MsgSource. (See Note 2.) from MsgSource. (See Note 2.)
Goto LAbR.11. Goto LAbR.11.
LAbR.7 Is LSR merging the LSP for FEC? LAbR.7 Is LSR merging the LSP for FEC?
If not, goto LAbR.9. If not, goto LAbR.9.
LAbR.8 Are there outstanding label requrests for this FEC? LAbR.8 Are there outstanding label requests for this FEC?
If so, goto LAbR.11. If so, goto LAbR.11.
LAbR.9 Execute procedure Send_Message (Next Hop, Label Abort LAbR.9 Execute procedure Send_Message (Next Hop, Label Abort
Request, FEC, TLV), where TLV is a Label Request Message Request, FEC, TLV), where TLV is a Label Request Message
ID TLV containing the Message ID used by the LSR in the ID TLV containing the Message ID used by the LSR in the
outstanding Label Request message. outstanding Label Request message.
LAbR.10 Record that a label abort request for FEC is pending. LAbR.10 Record that a label abort request for FEC is pending.
LAbR.11 Delete record of label request for FEC from MsgSource. LAbR.11 Delete record of label request for FEC from MsgSource.
skipping to change at page 111, line 8 skipping to change at page 114, line 12
LRl.3 Does message match an outstanding label withdraw for FEC LRl.3 Does message match an outstanding label withdraw for FEC
previously sent to MsgSource? previously sent to MsgSource?
If not, goto LRl.5 If not, goto LRl.5
LRl.4 Delete record of outstanding label withdraw for FEC LRl.4 Delete record of outstanding label withdraw for FEC
previously sent to MsgSource. previously sent to MsgSource.
LRl.5 Is LSR merging labels for this FEC? LRl.5 Is LSR merging labels for this FEC?
If not, goto LRl.7. (See Note 2.) If not, goto LRl.7. (See Note 2.)
LRl.6 Does LSR have outstanding label advertisements for this FEC? LRl.6 Does LSR have outstanding label advertisements for this
If so, goto LRl.11. FEC? If so, goto LRl.11.
LRl.7 Is LSR egress for the FEC? LRl.7 Is LSR egress for the FEC?
If so, goto LRl.11 If so, goto LRl.11
LRl.8 Is there a Next Hop for FEC? AND LRl.8 Is there a Next Hop for FEC? AND
Does LSR have a previously received label mapping for FEC Does LSR have a previously received label mapping for FEC
from Next Hop? from Next Hop?
If not, goto LRl.11. If not, goto LRl.11.
LRl.9 Is LSR configured to propagate releases? LRl.9 Is LSR configured to propagate releases?
skipping to change at page 123, line 32 skipping to change at page 127, line 10
1. Iteration ResA.5 through ResA.8 handles the situation where the 1. Iteration ResA.5 through ResA.8 handles the situation where the
LSR is using Downstream Unsolicited label distribution and was LSR is using Downstream Unsolicited label distribution and was
previously unable to allocate a label for a FEC. previously unable to allocate a label for a FEC.
A.1.14. LSR decides to no longer label switch a FEC A.1.14. LSR decides to no longer label switch a FEC
Summary: Summary:
An LSR may unilaterally decide to no longer label switch a FEC for An LSR may unilaterally decide to no longer label switch a FEC for
an LDP peer. An LSR that does so MUST send a label withdraw message an LDP peer. An LSR that does so MUST send a label withdraw
for the FEC to the peer. message for the FEC to the peer.
Context: Context:
- Peer. The peer. - Peer. The peer.
- FEC. The FEC. - FEC. The FEC.
- PrevAdvLabel. The label for FEC previously advertised to Peer. - PrevAdvLabel. The label for FEC previously advertised to Peer.
Algorithm: Algorithm:
skipping to change at page 124, line 10 skipping to change at page 127, line 33
NoLS.1 Execute procedure Send_Label_Withdraw (Peer, FEC, NoLS.1 Execute procedure Send_Label_Withdraw (Peer, FEC,
PrevAdvLabel). (See Note 1.) PrevAdvLabel). (See Note 1.)
NoLS.2 DONE. NoLS.2 DONE.
Notes: Notes:
1. The LSR may remove the label from forwarding/switching use as 1. The LSR may remove the label from forwarding/switching use as
part of this event or as part of processing the label release part of this event or as part of processing the label release
from the peer in response to the label withdraw. If the LSR from the peer in response to the label withdraw. If the LSR
doesn't wait for the label reelase message from the peer it doesn't wait for the label release message from the peer it
SHOULD NOT reuse the label until it receives the label release. SHOULD NOT reuse the label until it receives the label release.
A.1.15. Timeout of deferred label request A.1.15. Timeout of deferred label request
Summary: Summary:
Label requests are deferred in response to No Route and Loop Label requests are deferred in response to No Route and Loop
Detected notifications. When a deferred FEC label request for a Detected notifications. When a deferred FEC label request for a
peer times out, the LSR sends the label request. peer times out, the LSR sends the label request.
Context: Context:
- LSR. The LSR handling the event. - LSR. The LSR handling the event.
- FEC. The FEC associated with the timeout event. - FEC. The FEC associated with the timeout event.
- Peer. The LDP peer associated with the timeout event. - Peer. The LDP peer associated with the timeout event.
- Attributes. Attributes stored with deferred Label Request mes- - Attributes. Attributes stored with deferred Label Request
sage. message.
Algorithm: Algorithm:
TO.1 Retrieve the record of the deferred label request. TO.1 Retrieve the record of the deferred label request.
TO.2 Is Peer the next hop for FEC? TO.2 Is Peer the next hop for FEC?
If not, goto TO.4. If not, goto TO.4.
TO.3 Execute procedure Send_Label_Request (Peer, FEC). TO.3 Execute procedure Send_Label_Request (Peer, FEC).
skipping to change at page 127, line 27 skipping to change at page 130, line 52
SLRq.6 Postpone the label request by recording label mapping for SLRq.6 Postpone the label request by recording label mapping for
FEC and Attributes from Peer is needed but that no label FEC and Attributes from Peer is needed but that no label
resources are available. resources are available.
SLRq.7 Return failure. SLRq.7 Return failure.
Notes: Notes:
1. If the LSR is a non-merging LSR it must distinguish between 1. If the LSR is a non-merging LSR it must distinguish between
attempts to send label requests for a FEC triggered by differ- attempts to send label requests for a FEC triggered by
ent upstream LDP peers from duplicate requests. This procedure different upstream LDP peers from duplicate requests. This
will not send a duplicate label request. procedure will not send a duplicate label request.
A.2.3. Send_Label_Withdraw A.2.3. Send_Label_Withdraw
Summary: Summary:
An LSR uses the Send_Label_Withdraw procedure to withdraw a label An LSR uses the Send_Label_Withdraw procedure to withdraw a label
for a FEC from an LDP peer. To do this the LSR sends a Label for a FEC from an LDP peer. To do this the LSR sends a Label
Withdraw message to the peer. Withdraw message to the peer.
Parameters: Parameters:
skipping to change at page 132, line 45 skipping to change at page 136, line 11
- PrevHopCount. The Hop Count, if any, this LSR associates with - PrevHopCount. The Hop Count, if any, this LSR associates with
the LSP for the FEC. the LSP for the FEC.
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 Do the RAttributes include any unknown TLVs? If not, goto PMpA.4. PMpA.1 Do the RAttributes include any unknown TLVs?
If not, goto PMpA.4.
PMpA.2 Do the settings of the U and F bits require forwarding of PMpA.2 Do the settings of the U and F bits require forwarding of
these TLVs? If not, goto PMpA.4. these TLVs? If not, goto PMpA.4.
PMpA.3 Copy the unknown TLVs in SAttributes. PMpA.3 Copy the unknown TLVs in SAttributes.
PMpA.4 Is Hop Count required for this Peer (see Note 1.) ? OR PMpA.4 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.24. If not, goto PMpA.24.
skipping to change at page 135, line 7 skipping to change at page 138, line 7
form TTL-decrement and it is propagating the Label Mapping mes- form TTL-decrement and it is propagating the Label Mapping mes-
sage upstream into the cloud, it sets the Hop Count to 1 so sage upstream into the cloud, it sets the Hop Count to 1 so
that Hop Count across the cloud is calculated properly. This that Hop Count across the cloud is calculated properly. This
ensures proper TTL management for packets forwarded across the ensures proper TTL management for packets forwarded across the
part of the LSP that passes through the cloud. part of the LSP that passes through the cloud.
3. For hop count arithmetic, unknown + 1 = unknown. 3. For hop count arithmetic, unknown + 1 = unknown.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Additional copyright notices are not permitted in IETF Documents Additional copyright notices are not permitted in IETF Documents
except in the case where such document is the product of a joint except in the case where such document is the product of a joint
development effort between the IETF and another standards development development effort between the IETF and another standards development
organization or the document is a republication of the work of organization or the document is a republication of the work of
another standards organization. Such exceptions must be approved on another standards organization. Such exceptions must be approved on
an individual basis by the IAB. an individual basis by the IAB.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR-
MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 80 change blocks. 
221 lines changed or deleted 315 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/