draft-ietf-mpls-ldp-06.txt   draft-ietf-mpls-ldp-07.txt 
Network Working Group Loa Andersson Network Working Group Loa Andersson
Internet Draft Nortel Networks Inc. Internet Draft Nortel Networks Inc.
Expiration Date: April 2000 Expiration Date: December 2000
Paul Doolan Paul Doolan
Ennovate Networks Ennovate Networks
Nancy Feldman Nancy Feldman
IBM Corp IBM Corp
Andre Fredette Andre Fredette
Nortel Networks Inc. Nortel Networks Inc.
Bob Thomas Bob Thomas
Cisco Systems, Inc. Cisco Systems, Inc.
October 1999 June 2000
LDP Specification LDP Specification
draft-ietf-mpls-ldp-06.txt draft-ietf-mpls-ldp-07.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 14 skipping to change at page 2, line 14
Abstract Abstract
An overview of Multi Protocol Label Switching (MPLS) is provided in An overview of Multi Protocol Label Switching (MPLS) is provided in
[FRAMEWORK] and a proposed architecture in [ARCH]. A fundamental [FRAMEWORK] and a proposed architecture in [ARCH]. A fundamental
concept in MPLS is that two Label Switching Routers (LSRs) must agree concept in MPLS is that two Label Switching Routers (LSRs) must agree
on the meaning of the labels used to forward traffic between and on the meaning of the labels used to forward traffic between and
through them. This common understanding is achieved by using a set through them. This common understanding is achieved by using a set
of procedures, called a label distribution protocol, by which one LSR of procedures, called a label distribution protocol, by which one LSR
informs another of label bindings it has made. This document defines informs another of label bindings it has made. This document defines
a set of such procedures called LDP (for Label Distribution a set of such procedures called LDP (for Label Distribution Protocol)
Protocol). by which LSRs distribute labels to support MPLS forwarding along
normally routed paths [LDPAPPLIC].
Table of Contents Table of Contents
1 LDP Overview ....................................... 6 1 LDP Overview ....................................... 7
1.1 LDP Peers .......................................... 6 1.1 LDP Peers .......................................... 7
1.2 LDP Message Exchange ............................... 7 1.2 LDP Message Exchange ............................... 8
1.3 LDP Message Structure .............................. 7 1.3 LDP Message Structure .............................. 8
1.4 LDP Error Handling ................................. 8 1.4 LDP Error Handling ................................. 9
1.5 LDP Extensibility and Future Compatibility ......... 8 1.5 LDP Extensibility and Future Compatibility ......... 9
2 LDP Operation ...................................... 8 1.6 Specification Language ............................. 9
2.1 FECs ............................................... 8 2 LDP Operation ...................................... 9
2.2 Label Spaces, Identifiers, Sessions and Transport .. 10 2.1 FECs ............................................... 9
2.2.1 Label Spaces ....................................... 10 2.2 Label Spaces, Identifiers, Sessions and Transport .. 11
2.2.2 LDP Identifiers .................................... 11 2.2.1 Label Spaces ....................................... 11
2.2.3 LDP Sessions ....................................... 11 2.2.2 LDP Identifiers .................................... 12
2.2.4 LDP Transport ...................................... 11 2.2.3 LDP Sessions ....................................... 12
2.3 LDP Sessions between non-Directly Connected LSRs ... 12 2.2.4 LDP Transport ...................................... 12
2.4 LDP Discovery ..................................... 12 2.3 LDP Sessions between non-Directly Connected LSRs ... 13
2.4.1 Basic Discovery Mechanism .......................... 12 2.4 LDP Discovery ..................................... 13
2.4.2 Extended Discovery Mechanism ....................... 13 2.4.1 Basic Discovery Mechanism .......................... 13
2.5 Establishing and Maintaining LDP Sessions .......... 14 2.4.2 Extended Discovery Mechanism ....................... 14
2.5.1 LDP Session Establishment .......................... 14 2.5 Establishing and Maintaining LDP Sessions .......... 15
2.5.2 Transport Connection Establishment ................. 14 2.5.1 LDP Session Establishment .......................... 15
2.5.3 Session Initialization ............................. 15 2.5.2 Transport Connection Establishment ................. 15
2.5.4 Initialization State Machine ....................... 17 2.5.3 Session Initialization ............................. 16
2.5.5 Maintaining Hello Adjacencies ...................... 20 2.5.4 Initialization State Machine ....................... 19
2.5.6 Maintaining LDP Sessions ........................... 20 2.5.5 Maintaining Hello Adjacencies ...................... 22
2.6 Label Distribution and Management .................. 21 2.5.6 Maintaining LDP Sessions ........................... 22
2.6.1 Label Distribution Control Mode .................... 21 2.6 Label Distribution and Management .................. 23
2.6.1.1 Independent Label Distribution Control ............. 21 2.6.1 Label Distribution Control Mode .................... 23
2.6.1.2 Ordered Label Distribution Control ................. 21 2.6.1.1 Independent Label Distribution Control ............. 23
2.6.2 Label Retention Mode ............................... 22 2.6.1.2 Ordered Label Distribution Control ................. 23
2.6.2.1 Conservative Label Retention Mode .................. 22 2.6.2 Label Retention Mode ............................... 24
2.6.2.2 Liberal Label Retention Mode ....................... 22 2.6.2.1 Conservative Label Retention Mode .................. 24
2.6.3 Label Advertisement Mode ........................... 23 2.6.2.2 Liberal Label Retention Mode ....................... 25
2.7 LDP Identifiers and Next Hop Addresses ............. 23 2.6.3 Label Advertisement Mode ........................... 25
2.8 Loop Detection ..................................... 24 2.7 LDP Identifiers and Next Hop Addresses ............. 25
2.8.1 Label Request Message .............................. 25 2.8 Loop Detection ..................................... 26
2.8.2 Label Mapping Message .............................. 26 2.8.1 Label Request Message .............................. 27
2.8.3 Discussion ......................................... 28 2.8.2 Label Mapping Message .............................. 28
2.9 Label Distribution for Explicitly Routed LSPs ...... 28 2.8.3 Discussion ......................................... 30
3 Protocol Specification ............................. 29 2.9 Authenticity and Integrity of LDP Messages ......... 30
3.1 LDP PDUs ........................................... 29 2.9.1 TCP MD5 Signature Option ........................... 31
3.2 LDP Procedures ..................................... 30 2.9.2 LDP Use of TCP MD5 Signature Option ................ 32
3.3 Type-Length-Value Encoding ......................... 30 2.10 Label Distribution for Explicitly Routed LSPs ...... 33
3.4 TLV Encodings for Commonly Used Parameters ......... 32 3 Protocol Specification ............................. 33
3.4.1 FEC TLV ............................................ 32 3.1 LDP PDUs ........................................... 33
3.4.1.1 FEC Procedures ..................................... 35 3.2 LDP Procedures ..................................... 34
3.4.2 Label TLVs ......................................... 35 3.3 Type-Length-Value Encoding ......................... 35
3.4.2.1 Generic Label TLV .................................. 35 3.4 TLV Encodings for Commonly Used Parameters ......... 36
3.4.2.2 ATM Label TLV ...................................... 35 3.4.1 FEC TLV ............................................ 36
3.4.2.3 Frame Relay Label TLV .............................. 36 3.4.1.1 FEC Procedures ..................................... 39
3.4.3 Address List TLV ................................... 37 3.4.2 Label TLVs ......................................... 39
3.4.4 Hop Count TLV ...................................... 38 3.4.2.1 Generic Label TLV .................................. 39
3.4.4.1 Hop Count Procedures ............................... 38 3.4.2.2 ATM Label TLV ...................................... 40
3.4.5 Path Vector TLV .................................... 39 3.4.2.3 Frame Relay Label TLV .............................. 40
3.4.5.1 Path Vector Procedures ............................. 40 3.4.3 Address List TLV ................................... 41
3.4.5.1.1 Label Request Path Vector .......................... 40 3.4.4 Hop Count TLV ...................................... 42
3.4.5.1.2 Label Mapping Path Vector .......................... 41 3.4.4.1 Hop Count Procedures ............................... 42
3.4.6 Status TLV ......................................... 42 3.4.5 Path Vector TLV .................................... 44
3.5 LDP Messages ....................................... 43 3.4.5.1 Path Vector Procedures ............................. 44
3.5.1 Notification Message ............................... 45 3.4.5.1.1 Label Request Path Vector .......................... 44
3.5.1.1 Notification Message Procedures .................... 47 3.4.5.1.2 Label Mapping Path Vector .......................... 45
3.5.1.2 Events Signaled by Notification Messages ........... 47 3.4.6 Status TLV ......................................... 46
3.5.1.2.1 Malformed PDU or Message ........................... 47 3.5 LDP Messages ....................................... 47
3.5.1.2.2 Unknown or Malformed TLV ........................... 48 3.5.1 Notification Message ............................... 50
3.5.1.2.3 Session KeepAlive Timer Expiration ................. 49 3.5.1.1 Notification Message Procedures .................... 51
3.5.1.2.4 Unilateral Session Shutdown ........................ 49 3.5.1.2 Events Signaled by Notification Messages ........... 51
3.5.1.2.5 Initialization Message Events ...................... 49 3.5.1.2.1 Malformed PDU or Message ........................... 51
3.5.1.2.6 Events Resulting From Other Messages ............... 49 3.5.1.2.2 Unknown or Malformed TLV ........................... 52
3.5.1.2.7 Miscellaneous Events ............................... 49 3.5.1.2.3 Session KeepAlive Timer Expiration ................. 53
3.5.2 Hello Message ...................................... 50 3.5.1.2.4 Unilateral Session Shutdown ........................ 53
3.5.2.1 Hello Message Procedures ........................... 52 3.5.1.2.5 Initialization Message Events ...................... 53
3.5.3 Initialization Message ............................. 53 3.5.1.2.6 Events Resulting From Other Messages ............... 53
3.5.3.1 Initialization Message Procedures .................. 61 3.5.1.2.7 Internal Errors .................................... 54
3.5.4 KeepAlive Message .................................. 61 3.5.1.2.8 Miscellaneous Events ............................... 54
3.5.4.1 KeepAlive Message Procedures ....................... 62 3.5.2 Hello Message ...................................... 54
3.5.5 Address Message .................................... 62 3.5.2.1 Hello Message Procedures ........................... 56
3.5.5.1 Address Message Procedures ......................... 63 3.5.3 Initialization Message ............................. 58
3.5.6 Address Withdraw Message ........................... 63 3.5.3.1 Initialization Message Procedures .................. 66
3.5.6.1 Address Withdraw Message Procedures ................ 64 3.5.4 KeepAlive Message .................................. 66
3.5.7 Label Mapping Message .............................. 64 3.5.4.1 KeepAlive Message Procedures ....................... 66
3.5.7.1 Label Mapping Message Procedures ................... 65 3.5.5 Address Message .................................... 67
3.5.7.1.1 Independent Control Mapping ........................ 66 3.5.5.1 Address Message Procedures ......................... 67
3.5.7.1.2 Ordered Control Mapping ............................ 66 3.5.6 Address Withdraw Message ........................... 68
3.5.7.1.3 Downstream on Demand Label Advertisement ........... 67 3.5.6.1 Address Withdraw Message Procedures ................ 69
3.5.7.1.4 Downstream Unsolicited Label Advertisement ......... 67 3.5.7 Label Mapping Message .............................. 69
3.5.8 Label Request Message .............................. 68 3.5.7.1 Label Mapping Message Procedures ................... 70
3.5.8.1 Label Request Message Procedures ................... 69 3.5.7.1.1 Independent Control Mapping ........................ 70
3.5.9 Label Abort Request Message ........................ 70 3.5.7.1.2 Ordered Control Mapping ............................ 71
3.5.9.1 Label Abort Request Message Procedures ............. 71 3.5.7.1.3 Downstream on Demand Label Advertisement ........... 71
3.5.10 Label Withdraw Message ............................. 73 3.5.7.1.4 Downstream Unsolicited Label Advertisement ......... 72
3.5.10.1 Label Withdraw Message Procedures .................. 74 3.5.8 Label Request Message .............................. 73
3.5.11 Label Release Message .............................. 74 3.5.8.1 Label Request Message Procedures ................... 74
3.5.11.1 Label Release Message Procedures ................... 75 3.5.9 Label Abort Request Message ........................ 75
3.6 Messages and TLVs for Extensibility ................ 76 3.5.9.1 Label Abort Request Message Procedures ............. 76
3.6.1 LDP Vendor-private Extensions ...................... 76 3.5.10 Label Withdraw Message ............................. 77
3.6.1.1 LDP Vendor-private TLVs ............................ 77 3.5.10.1 Label Withdraw Message Procedures .................. 78
3.6.1.2 LDP Vendor-private Messages ........................ 78 3.5.11 Label Release Message .............................. 79
3.6.2 LDP Experimental Extensions ........................ 79 3.5.11.1 Label Release Message Procedures ................... 80
3.7 Message Summary .................................... 80 3.6 Messages and TLVs for Extensibility ................ 81
3.8 TLV Summary ........................................ 80 3.6.1 LDP Vendor-private Extensions ...................... 81
3.9 Status Code Summary ................................ 81 3.6.1.1 LDP Vendor-private TLVs ............................ 81
3.10 Well-known Numbers ................................. 82 3.6.1.2 LDP Vendor-private Messages ........................ 82
3.10.1 UDP and TCP Ports .................................. 82 3.6.2 LDP Experimental Extensions ........................ 84
3.10.2 Implicit NULL Label ................................ 82 3.7 Message Summary .................................... 84
4 Security Considerations ............................ 82 3.8 TLV Summary ........................................ 85
4.1 The TCP MD5 Signature Option ....................... 82 3.9 Status Code Summary ................................ 86
4.2 LDP Use of the TCP MD5 Signature Option ............ 84 3.10 Well-known Numbers ................................. 87
5 Areas for Future Study ............................. 84 3.10.1 UDP and TCP Ports .................................. 87
6 Intellectual Property Considerations ............... 85 3.10.2 Implicit NULL Label ................................ 87
7 Acknowledgments .................................... 85 4 IANA Considerations ................................ 87
8 References ......................................... 85 4.1 Message Type Name Space ............................ 88
9 Author Information ................................. 87 4.2 TLV Type Name Space ................................ 88
4.3 FEC Type Name Space ................................ 89
4.4 Status Code Space .................................. 89
4.5 Experiment ID Name Space ........................... 89
5 Security Considerations ............................ 89
5.1 Spoofing ........................................... 89
5.2 Privacy ............................................ 90
5.3 Denial of Service .................................. 91
6 Areas for Future Study ............................. 92
7 Intellectual Property Considerations ............... 93
8 Acknowledgments .................................... 93
9 References ......................................... 93
10 Author Information ................................. 95
Appendix.A LDP Label Distribution Procedures .................. 88 Appendix.A LDP Label Distribution Procedures .................. 96
A.1 Handling Label Distribution Events ................. 90 A.1 Handling Label Distribution Events ................. 98
A.1.1 Receive Label Request .............................. 91 A.1.1 Receive Label Request .............................. 99
A.1.2 Receive Label Mapping .............................. 94 A.1.2 Receive Label Mapping .............................. 102
A.1.3 Receive Label Abort Request ........................ 98 A.1.3 Receive Label Abort Request ........................ 108
A.1.4 Receive Label Release .............................. 100 A.1.4 Receive Label Release .............................. 110
A.1.5 Receive Label Withdraw ............................. 102 A.1.5 Receive Label Withdraw ............................. 112
A.1.6 Recognize New FEC .................................. 104 A.1.6 Recognize New FEC .................................. 113
A.1.7 Detect Change in FEC Next Hop ...................... 106 A.1.7 Detect Change in FEC Next Hop ...................... 116
A.1.8 Receive Notification / Label Request Aborted ....... 109 A.1.8 Receive Notification / Label Request Aborted ....... 119
A.1.9 Receive Notification / No Label Resources .......... 110 A.1.9 Receive Notification / No Label Resources .......... 119
A.1.10 Receive Notification / No Route .................... 110 A.1.10 Receive Notification / No Route .................... 120
A.1.11 Receive Notification / Loop Detected ............... 111 A.1.11 Receive Notification / Loop Detected ............... 121
A.1.12 Receive Notification / Label Resources Available ... 112 A.1.12 Receive Notification / Label Resources Available ... 122
A.1.13 Detect local label resources have become available . 112 A.1.13 Detect local label resources have become available . 122
A.1.14 LSR decides to no longer label switch a FEC ........ 113 A.1.14 LSR decides to no longer label switch a FEC ........ 123
A.1.15 Timeout of deferred label request .................. 114 A.1.15 Timeout of deferred label request .................. 124
A.2 Common Label Distribution Procedures ............... 115 A.2 Common Label Distribution Procedures ............... 125
A.2.1 Send_Label ......................................... 115 A.2.1 Send_Label ......................................... 125
A.2.2 Send_Label_Request ................................. 116 A.2.2 Send_Label_Request ................................. 126
A.2.3 Send_Label_Withdraw ................................ 118 A.2.3 Send_Label_Withdraw ................................ 128
A.2.4 Send_Notification .................................. 118 A.2.4 Send_Notification .................................. 128
A.2.5 Send_Message ....................................... 119 A.2.5 Send_Message ....................................... 129
A.2.6 Check_Received_Attributes .......................... 119 A.2.6 Check_Received_Attributes .......................... 129
A.2.7 Prepare_Label_Request_Attributes ................... 120 A.2.7 Prepare_Label_Request_Attributes ................... 131
A.2.8 Prepare_Label_Mapping_Attributes ................... 122 A.2.8 Prepare_Label_Mapping_Attributes ................... 132
1. LDP Overview 1. LDP Overview
Section 2.6 of the MPLS architecture [ARCH] defines a label The MPLS architecture [ARCH] defines a label distribution protocol as
distribution protocol as a set of procedures by which one Label a set of procedures by which one Label Switched Router (LSR) informs
Switched Router (LSR) informs another of the meaning of labels used another of the meaning of labels used to forward traffic between and
to forward traffic between and through them. through them.
The MPLS architecture does not assume a single label distribution The MPLS architecture does not assume a single label distribution
protocol. In fact, a number of different label distribution protocol. In fact, a number of different label distribution
protocols are being standardized. Existing protocols have been protocols are being standardized. Existing protocols have been
extended so that label distribution can be piggybacked on them. New extended so that label distribution can be piggybacked on them. New
protocols have also been defined for the explicit purpose of protocols have also been defined for the explicit purpose of
distributing labels. Section 2.29 of the architecture [ARCH] distributing labels. The MPLS architecture discusses some of the
discusses some of the considerations when choosing a label considerations when choosing a label distribution protocol for use in
distribution protocol for use in particular MPLS applications such as particular MPLS applications such as Traffic Engineering [TE].
Traffic Engineering [TE].
The Label Distribution Protocol (LDP) defined in this document is a The Label Distribution Protocol (LDP) defined in this document is a
new protocol defined for distributing labels. It is the set of new protocol defined for distributing labels. It is the set of
procedures and messages by which Label Switched Routers (LSRs) procedures and messages by which Label Switched Routers (LSRs)
establish Label Switched Paths (LSPs) through a network by mapping establish Label Switched Paths (LSPs) through a network by mapping
network-layer routing information directly to data-link layer network-layer routing information directly to data-link layer
switched paths. These LSPs may have an endpoint at a directly switched paths. These LSPs may have an endpoint at a directly
attached neighbor (comparable to IP hop-by-hop forwarding), or may attached neighbor (comparable to IP hop-by-hop forwarding), or may
have an endpoint at a network egress node, enabling switching via all have an endpoint at a network egress node, enabling switching via all
intermediary nodes. intermediary nodes.
LDP associates a Forwarding Equivalence Class (FEC) [ARCH] with each LDP associates a Forwarding Equivalence Class (FEC) [ARCH] with each
LSP it creates. The FEC associated with an LSP specifies which LSP it creates. The FEC associated with an LSP specifies which
packets are "mapped" to that LSP. LSPs are extended through a packets are "mapped" to that LSP. LSPs are extended through a
network as each LSR "splices" incoming labels for a FEC to the network as each LSR "splices" incoming labels for a FEC to the
outgoing label assigned to the next hop for the given FEC. outgoing label assigned to the next hop for the given FEC.
More information about the applicability of LDP can be found in
[LDPAPPLIC].
This document assumes familiarity with the MPLS architecture [ARCH]. This document assumes familiarity with the MPLS architecture [ARCH].
Note that [ARCH] includes a glossary of MPLS terminology, such as Note that [ARCH] includes a glossary of MPLS terminology, such as
ingress, label switched path, etc. ingress, label switched path, etc.
1.1. LDP Peers 1.1. LDP Peers
Two LSRs which use LDP to exchange label/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 allows each peer to learn the other's label mappings; i.e., the
skipping to change at page 7, line 22 skipping to change at page 8, line 22
2. Session messages, used to establish, maintain, and terminate 2. Session messages, used to establish, maintain, and terminate
sessions between LDP peers. sessions between LDP peers.
3. Advertisement messages, used to create, change, and delete 3. Advertisement messages, used to create, change, and delete
label mappings for FECs. label mappings for FECs.
4. Notification messages, used to provide advisory information and 4. Notification messages, used to provide advisory information and
to signal error information. to signal error information.
Discovery messages provide a mechanism whereby LSRs indicate their Discovery messages provide a mechanism whereby LSRs indicate their
presence in a network by sending the Hello message periodically. presence in a network by sending a Hello message periodically. This
This is transmitted as a UDP packet to the LDP port at the `all is transmitted as a UDP packet to the LDP port at the `all routers on
routers on this subnet' group multicast address. When an LSR chooses this subnet' group multicast address. When an LSR chooses to
to establish a session with another LSR learned via the Hello establish a session with another LSR learned via the Hello message,
message, it uses the LDP initialization procedure over TCP transport. it uses the LDP initialization procedure over TCP transport. Upon
Upon successful completion of the initialization procedure, the two successful completion of the initialization procedure, the two LSRs
LSRs are LDP peers, and may exchange advertisement messages. are LDP peers, and may exchange advertisement messages.
When to request a label or advertise a label mapping to a peer is When to request a label or advertise a label mapping to a peer is
largely a local decision made by an LSR. In general, the LSR largely a local decision made by an LSR. In general, the LSR
requests a label mapping from a neighboring LSR when it needs one, requests a label mapping from a neighboring LSR when it needs one,
and advertises a label mapping to a neighboring LSR when it wishes and advertises a label mapping to a neighboring LSR when it wishes
the neighbor to use a label. the neighbor to use a label.
Correct operation of LDP requires reliable and in order delivery of Correct operation of LDP requires reliable and in order delivery of
messages. To satisfy these requirements LDP uses the TCP transport messages. To satisfy these requirements LDP uses the TCP transport
for session, advertisement and notification messages; i.e., for for session, advertisement and notification messages; i.e., for
skipping to change at page 8, line 33 skipping to change at page 9, line 33
Functionality may be added to LDP in the future. It is likely that Functionality may be added to LDP in the future. It is likely that
future functionality will utilize new messages and object types future functionality will utilize new messages and object types
(TLVs). It may be desirable to employ such new messages and TLVs (TLVs). It may be desirable to employ such new messages and TLVs
within a network using older implementations that do not recognize within a network using older implementations that do not recognize
them. While it is not possible to make every future enhancement them. While it is not possible to make every future enhancement
backwards compatible, some prior planning can ease the introduction backwards compatible, some prior planning can ease the introduction
of new capabilities. This specification defines rules for handling of new capabilities. This specification defines rules for handling
unknown message types and unknown TLVs for this purpose. unknown message types and unknown TLVs for this purpose.
1.6. Specification Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [rfc2119].
2. LDP Operation 2. LDP Operation
2.1. FECs 2.1. FECs
It is necessary to precisely specify which packets may be mapped to It is necessary to precisely specify which packets may be mapped to
each LSP. This is done by providing a FEC specification for each each LSP. This is done by providing a FEC specification for each
LSP. The FEC identifies the set of IP packets which may be mapped to LSP. The FEC identifies the set of IP packets which may be mapped to
that LSP. that LSP.
Each FEC is specified as a set of one or more FEC elements. Each FEC Each FEC is specified as a set of one or more FEC elements. Each FEC
skipping to change at page 9, line 30 skipping to change at page 10, line 36
matches the packet as the "matching prefix". matches the packet as the "matching prefix".
The procedure for mapping a particular packet to a particular LSP The procedure for mapping a particular packet to a particular LSP
uses the following rules. Each rule is applied in turn until the uses the following rules. Each rule is applied in turn until the
packet can be mapped to an LSP. packet can be mapped to an LSP.
- If there is exactly one LSP which has a Host Address FEC element - If there is exactly one LSP which has a Host Address FEC element
that is identical to the packet's destination address, then the that is identical to the packet's destination address, then the
packet is mapped to that LSP. packet is mapped to that LSP.
- If there multiple LSPs, each containing a Host Address FEC - If there are multiple LSPs, each containing a Host Address FEC
element that is identical to the packet's destination address, element that is identical to the packet's destination address,
then the packet is mapped to one of those LSPs. The procedure then the packet is mapped to one of those LSPs. The procedure
for selecting one of those LSPs is beyond the scope of this for selecting one of those LSPs is beyond the scope of this
document. document.
- If a packet matches exactly one LSP, the packet is mapped to that - If a packet matches exactly one LSP, the packet is mapped to that
LSP. LSP.
- If a packet matches multiple LSPs, it is mapped to the LSP whose - If a packet matches multiple LSPs, it is mapped to the LSP whose
matching prefix is the longest. If there is no one LSP whose matching prefix is the longest. If there is no one LSP whose
skipping to change at page 11, line 8 skipping to change at page 12, line 11
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
An LDP identifier is a six octet quantity used to identify an LSR An LDP identifier is a six octet quantity used to identify an LSR
label space. The first four octets encode an IP address assigned to label space. The first four octets identify the LSR and must be a
the LSR, and the last two octets identify a specific label space globally unique value, such as a 32-bit router Id assigned to the
within the LSR. The last two octets of LDP Identifiers for LSR. The last two octets identify a specific label space within the
platform-wide label spaces are always both zero. This document uses LSR. The last two octets of LDP Identifiers for platform-wide label
the following print representation for LDP Identifiers: spaces are always both zero. This document uses the following print
representation for LDP Identifiers:
<IP address> : <label space id> <LSR Id> : <label space id>
e.g., 171.32.27.28:0, 192.0.3.5:2. e.g., lsr171:0, lsr19:2.
Note that an LSR that manages and advertises multiple label spaces Note that an LSR that manages and advertises multiple label spaces
uses a different LDP Identifier for each such label space. uses a different LDP Identifier for each such label space.
A situation where an LSR would need to advertise more than one label A situation where an LSR would need to advertise more than one label
space to a peer and hence use more than one LDP Identifier occurs space to a peer and hence use more than one LDP Identifier occurs
when the LSR has two links to the peer and both are ATM (and use per when the LSR has two links to the peer and both are ATM (and use per
interface labels). Another situation would be where the LSR had two interface labels). Another situation would be where the LSR had two
links to the peer, one of which is ethernet (and uses per platform links to the peer, one of which is ethernet (and uses per platform
labels) and the other of which is ATM. labels) and the other of which is ATM.
skipping to change at page 13, line 20 skipping to change at page 14, line 20
adjacency" with a potential LDP peer reachable at the link level on adjacency" with a potential LDP peer reachable at the link level on
the interface as well as the label space the peer intends to use for the interface as well as the label space the peer intends to use for
the interface. the interface.
2.4.2. Extended Discovery Mechanism 2.4.2. Extended Discovery Mechanism
LDP sessions between non-directly connected LSRs are supported by LDP LDP sessions between non-directly connected LSRs are supported by LDP
Extended Discovery. Extended Discovery.
To engage in LDP Extended Discovery an LSR periodically sends LDP To engage in LDP Extended Discovery an LSR periodically sends LDP
Targeted Hellos to a specific IP address. LDP Targeted Hellos are Targeted Hellos to a specific address. LDP Targeted Hellos are sent
sent as UDP packets addressed to the well-known LDP discovery port at as UDP packets addressed to the well-known LDP discovery port at the
the specific address. specific address.
An LDP Targeted Hello sent by an LSR carries the LDP Identifier for An LDP Targeted Hello sent by an LSR carries the LDP Identifier for
the label space the LSR intends to use and possibly additional the label space the LSR intends to use and possibly additional
optional information. optional information.
Extended Discovery differs from Basic Discovery in the following Extended Discovery differs from Basic Discovery in the following
ways: ways:
- A Targeted Hello is sent to a specific IP address rather than to - A Targeted Hello is sent to a specific address rather than to the
the "all routers" group multicast address for the outgoing "all routers" group multicast address for the outgoing interface.
interface.
- Unlike Basic Discovery, which is symmetric, Extended Discovery is - Unlike Basic Discovery, which is symmetric, Extended Discovery is
asymmetric. asymmetric.
One LSR initiates Extended Discovery with another targeted LSR, One LSR initiates Extended Discovery with another targeted LSR,
and the targeted LSR decides whether to respond to or ignore the and the targeted LSR decides whether to respond to or ignore the
Targeted Hello. A targeted LSR that chooses to respond does so Targeted Hello. A targeted LSR that chooses to respond does so
by periodically sending Targeted Hellos to the initiating LSR. by periodically sending Targeted Hellos to the initiating LSR.
Receipt of an LDP Targeted Hello identifies a "Hello adjacency" with Receipt of an LDP Targeted Hello identifies a "Hello adjacency" with
skipping to change at page 14, line 39 skipping to change at page 15, line 39
LSR1 determines the transport addresses to be used at its end LSR1 determines the transport addresses to be used at its end
(A1) and LSR2's end (A2) of the LDP TCP connection. Address A1 (A1) and LSR2's end (A2) of the LDP TCP connection. Address A1
is determined as follows: is determined as follows:
a. If LSR1 uses the Transport Address optional object (TLV) in a. If LSR1 uses the Transport Address optional object (TLV) in
Hello's it sends to LSR2 to advertise an address, A1 is the Hello's it sends to LSR2 to advertise an address, A1 is the
address LSR1 advertises via the optional object; address LSR1 advertises via the optional object;
b. If LSR1 does not use the Transport Address optional object, b. If LSR1 does not use the Transport Address optional object,
A1 is the source IP address used in Hellos it sends to A1 is the source address used in Hellos it sends to LSR2.
LSR2.
Similarly, address A2 is determined as follows: Similarly, address A2 is determined as follows:
a. If LSR2 uses the Transport Address optional object, A2 is a. If LSR2 uses the Transport Address optional object, A2 is
the address LSR2 advertises via the optional object; the address LSR2 advertises via the optional object;
b. If LSR2 does not use the Transport Address optional object, b. If LSR2 does not use the Transport Address optional object,
A2 is the source IP address in Hellos received from LSR2. A2 is the source address in Hellos received from LSR2.
2. LSR1 determines whether it will play the active or passive role 2. LSR1 determines whether it will play the active or passive role
in session establishment by comparing addresses A1 and A2 as in session establishment by comparing addresses A1 and A2 as
unsigned integers. If A1 > A2, LSR1 plays the active role; unsigned integers. If A1 > A2, LSR1 plays the active role;
otherwise it is passive. otherwise it is passive.
The procedure for comparing A1 and A2 as unsigned integers is:
- If A1 and A2 are not in the same address family, they are
incomparable, and no session can be established.
- Let U1 be the abstract unsigned integer obtained by
treating A1 as a sequence of bytes, where the byte which
appears earliest in the message is the most significant
byte of the integer and the byte which appears latest in
the message is the least significant byte of the integer.
Let U2 be the abstract unsigned integer obtained from A2 in
a similar manner.
- Compare U1 with U2. If U1 > U2, then A1 > A2; if U1 < U2,
then A1 < A2.
3. If LSR1 is active, it attempts to establish the LDP TCP 3. If LSR1 is active, it attempts to establish the LDP TCP
connection by connecting to the well-known LDP port at address connection by connecting to the well-known LDP port at address
A2. If LSR1 is passive, it waits for LSR2 to establish the LDP A2. If LSR1 is passive, it waits for LSR2 to establish the LDP
TCP connection to its well-known LDP port. TCP connection to its well-known LDP port.
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 parameters negotiated include LDP protocol version, label
skipping to change at page 15, line 35 skipping to change at page 17, line 4
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
Initialization message to LSR2. If LSR1 is passive, it waits for Initialization message to LSR2. If LSR1 is passive, it waits for
LSR2 to initiate the parameter negotiation. LSR2 to initiate the parameter negotiation.
In general when there are multiple links between LSR1 and LSR2 and In general when there are multiple links between LSR1 and LSR2 and
multiple label spaces to be advertised by each, the passive LSR multiple label spaces to be advertised by each, the passive LSR
cannot know which label space to advertise over a newly established cannot know which label space to advertise over a newly established
TCP connection until it receives the first LDP PDU on the connection. TCP connection until it receives the LDP Initialization message on
the connection. The Initialization message carries both the LDP
Identifier for the sender's (active LSR's) label space and the LDP
Identifier for the receiver's (passive LSR's) label space.
By waiting for the Initialization message from its peer the passive By waiting for the Initialization message from its peer the passive
LSR can match the label space to be advertised by the peer (as LSR can match the label space to be advertised by the peer (as
determined from the LDP Identifier in the PDU header for the determined from the LDP Identifier in the PDU header for the
Initialization message) with a Hello adjacency previously created Initialization message) with a Hello adjacency previously created
when Hellos were exchanged. when Hellos were exchanged.
1. When LSR1 plays the passive role: 1. When LSR1 plays the passive role:
a. If LSR1 receives an Initialization message it attempts to a. If LSR1 receives an Initialization message it attempts to
skipping to change at page 21, line 11 skipping to change at page 23, line 11
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 [ARCH] allows an LSR to distribute a FEC label The MPLS architecture [ARCH] allows an LSR to distribute a FEC label
binding in response to an explicit request from another LSR. This is binding in response to an explicit request from another LSR. This is
known as Downstream On Demand label distribution. It also allows an known as Downstream On Demand label distribution. It also allows an
LSR to distribute label bindings to LSRs that have not explicitly LSR to distribute label bindings to LSRs that have not explicitly
requested them. This is known as Downstream Unsolicited label requested them. [ARCH] calls this method of label distribution
distribution. Unsolicited Downstream; this document uses the term Downstream
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
in order to avoid situations where one peer using Downstream in order to avoid situations where one peer using Downstream
Unsolicited label distribution assumes its peer is also. See Section Unsolicited label distribution assumes its peer is also. See Section
"Downstream on Demand label Advertisement". "Downstream on Demand label Advertisement".
2.6.1. Label Distribution Control Mode 2.6.1. Label Distribution Control Mode
skipping to change at page 22, line 25 skipping to change at page 24, line 26
boundary, such as another area for OSPF summary networks, or boundary, such as another area for OSPF summary networks, or
another autonomous system for OSPF AS externals and BGP routes another autonomous system for OSPF AS externals and BGP routes
[rfc1583] [rfc1771]. [rfc1583] [rfc1771].
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 [ARCH] introduces the notion of label retention
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 FEC.
2.6.2.1. Conservative Label Retention Mode 2.6.2.1. Conservative Label Retention Mode
In Downstream Unsolicited advertisement mode, label mapping In Downstream Unsolicited advertisement mode, label mapping
advertisements for all routes may be received from all peer LSRs. advertisements for all routes may be received from all peer LSRs.
When using conservative label retention, advertised label mappings When using conservative label retention, advertised label mappings
are retained only if they will be used to forward packets (i.e., if are retained only if they will be used to forward packets (i.e., if
they are received from a valid next hop according to routing). If they are received from a valid next hop according to routing). If
operating in Downstream on Demand mode, an LSR will request label operating in Downstream on Demand mode, an LSR will request label
mappings only from the next hop LSR according to routing. Since mappings only from the next hop LSR according to routing. Since
Downstream on Demand mode is primarily used when label conservation Downstream on Demand mode is primarily used when label conservation
skipping to change at page 24, line 21 skipping to change at page 26, line 26
Loop detection is a configurable option which provides a mechanism Loop detection is a configurable option which provides a mechanism
for finding looping LSPs and for preventing Label Request messages for finding looping LSPs and for preventing Label Request messages
from looping in the presence of non-merge capable LSRs. from looping in the presence of non-merge capable LSRs.
The mechanism makes use of Path Vector and Hop Count TLVs carried by The mechanism makes use of Path Vector and Hop Count TLVs carried by
Label Request and Label Mapping messages. It builds on the following Label Request and Label Mapping messages. It builds on the following
basic properties of these TLVs: basic properties of these TLVs:
- A Path Vector TLV contains a list of the LSRs that its containing - A Path Vector TLV contains a list of the LSRs that its containing
message has traversed. An LSR is identified in a Path Vector message has traversed. An LSR is identified in a Path Vector
list by its unique LSR Identifier (Id), which is the IP address list by its unique LSR Identifier (Id), which is the first four
component of its LDP Identifier. When an LSR propagates a octets of its LDP Identifier. When an LSR propagates a message
message containing a Path Vector TLV it adds its LSR Id to the containing a Path Vector TLV it adds its LSR Id to the Path
Path Vector list. An LSR that receives a message with a Path Vector list. An LSR that receives a message with a Path Vector
Vector that contains its LSR Id detects that the message has that contains its LSR Id detects that the message has traversed a
traversed a loop. LDP supports the notion of a maximum allowable loop. LDP supports the notion of a maximum allowable Path Vector
Path Vector length; an LSR that detects a Path Vector has reached length; an LSR that detects a Path Vector has reached the maximum
the maximum length behaves as if the containing message has length behaves as if the containing message has traversed a loop.
traversed a loop.
- A Hop Count TLV contains a count of the LSRS that the containing - A Hop Count TLV contains a count of the LSRS that the containing
message has traversed. When an LSR propagates a message message has traversed. When an LSR propagates a message
containing a Hop Count TLV it increments the count. An LSR that containing a Hop Count TLV it increments the count. An LSR that
detects a Hop Count has reached a configured maximum value detects a Hop Count has reached a configured maximum value
behaves as if the containing message has traversed a loop. By behaves as if the containing message has traversed a loop. By
convention a count of 0 is interpreted to mean the hop count is convention a count of 0 is interpreted to mean the hop count is
unknown. Incrementing an unknown hop count value results in an unknown. Incrementing an unknown hop count value results in an
unknown hop count value (0). unknown hop count value (0).
The following paragraphs describes LDP loop detection procedures. In The following paragraphs describes LDP loop detection procedures.
these paragraphs, "MUST" means "MUST if configured for loop For these paragraphs, and only these paragraphs, "MUST" is redfined
detection". The paragraphs specify messages that must carry Path to mean "MUST if configured for loop detection". The paragraphs
Vector and Hop Count TLVs. Note that the Hop Count TLV and its specify messages that must carry Path Vector and Hop Count TLVs.
procedures are used without the Path Vector TLV in situations when Note that the Hop Count TLV and its procedures are used without the
loop detection is not configured (see [ATM] and [FR]). Path Vector TLV in situations when loop detection is not configured
(see [ATM] and [FR]).
2.8.1. Label Request Message 2.8.1. Label Request Message
The use of the Path Vector TLV and Hop Count TLV prevent Label The use of the Path Vector TLV and Hop Count TLV prevent Label
Request messages from looping in environments that include non-merge Request messages from looping in environments that include non-merge
capable LSRs. capable LSRs.
The rules that govern use of the Hop Count TLV in Label Request The rules that govern use of the Hop Count TLV in Label Request
messages by LSR R when Loop Detection is enabled are the following: messages by LSR R when Loop Detection is enabled are the following:
skipping to change at page 27, line 44 skipping to change at page 29, line 44
received message upstream, the Label Mapping message MUST include a received message upstream, the Label Mapping message MUST include a
Path Vector of length 1 containing R's LSR Id. Path Vector of length 1 containing R's LSR Id.
If R receives a Label Mapping message from its next hop with a Hop If R receives a Label Mapping message from its next hop with a Hop
Count TLV which exceeds the configured maximum value, or with a Path Count TLV which exceeds the configured maximum value, or with a Path
Vector TLV containing its own LSR Id or which exceeds the maximum Vector TLV containing its own LSR Id or which exceeds the maximum
allowable length, then R detects that the corresponding LSP contains allowable length, then R detects that the corresponding LSP contains
a loop. a loop.
When R detects a loop, it MUST stop using the label for forwarding, When R detects a loop, it MUST stop using the label for forwarding,
drop the Label Mapping message. and send a Loop Detected Notification drop the Label Mapping message, and signal Loop Detected status to
message to the source of the Label Mapping message. the source of the Label Mapping message.
2.8.3. Discussion 2.8.3. Discussion
If loop detection is desired in an MPLS domain, then it should be
turned on in ALL LSRs within that MPLS domain, else loop detection
will not operate properly and may result in undetected loops or in
falsely detected loops.
LSRs which are configured for loop detection are NOT expected to LSRs which are configured for loop detection are NOT expected to
store the path vectors as part of the LSP state. store the path vectors as part of the LSP state.
Note that in a network where only non-merge capable LSRs are present, Note that in a network where only non-merge capable LSRs are present,
Path Vectors are passed downstream from ingress to egress, and are Path Vectors are passed downstream from ingress to egress, and are
not passed upstream. Even when merge is supported, Path Vectors need not passed upstream. Even when merge is supported, Path Vectors need
not be passed upstream along an LSP which is known to reach the not be passed upstream along an LSP which is known to reach the
egress. When an LSR experiences a change of next hop, it need pass egress. When an LSR experiences a change of next hop, it need pass
Path Vectors upstream only when it cannot tell from the hop count Path Vectors upstream only when it cannot tell from the hop count
that the change of next hop does not result in a loop. that the change of next hop does not result in a loop.
skipping to change at page 28, line 30 skipping to change at page 30, line 35
Vector along the way. In the case of independent label distribution, Vector along the way. In the case of independent label distribution,
an LSR may originate a Label Mapping message for an FEC before an LSR may originate a Label Mapping message for an FEC before
receiving a Label Mapping message from its downstream peer for that receiving a Label Mapping message from its downstream peer for that
FEC. In this case, the subsequent Label Mapping message for the FEC FEC. In this case, the subsequent Label Mapping message for the FEC
received from the downstream peer is treated as an update to LSP received from the downstream peer is treated as an update to LSP
attributes, and the Label Mapping message must be propagated attributes, and the Label Mapping message must be propagated
upstream. Thus, it is recommended that loop detection be configured upstream. Thus, it is recommended that loop detection be configured
in conjunction with ordered label distribution, to minimize the in conjunction with ordered label distribution, to minimize the
number of Label Mapping update messages. number of Label Mapping update messages.
If loop detection is desired in an MPLS domain, then it should be 2.9. Authenticity and Integrity of LDP Messages
turned on in ALL LSRs within that MPLS domain, else loop detection
will not operate properly.
2.9. Label Distribution for Explicitly Routed LSPs This section specifies a mechanism to protect against the
introduction of spoofed TCP segments into LDP session connection
streams. The use of this mechanism MUST be supported as a
configurable option.
The mechanism is based on use of the TCP MD5 Signature Option
specified in [rfc2385] for use by BGP. See [rfc1321] for a
specification of the MD5 hash function.
2.9.1. TCP MD5 Signature Option
The following quotes from [rfc2385] outline the security properties
achieved by using the TCP MD5 Signature Option and summarizes its
operation:
"IESG Note
This document describes current existing practice for securing
BGP against certain simple attacks. It is understood to have
security weaknesses against concerted attacks."
"Abstract
This memo describes a TCP extension to enhance security for
BGP. It defines a new TCP option for carrying an MD5 [RFC1321]
digest in a TCP segment. This digest acts like a signature for
that segment, incorporating information known only to the
connection end points. Since BGP uses TCP as its transport,
using this option in the way described in this paper
significantly reduces the danger from certain security attacks
on BGP."
"Introduction
The primary motivation for this option is to allow BGP to
protect itself against the introduction of spoofed TCP segments
into the connection stream. Of particular concern are TCP
resets.
To spoof a connection using the scheme described in this paper,
an attacker would not only have to guess TCP sequence numbers,
but would also have had to obtain the password included in the
MD5 digest. This password never appears in the connection
stream, and the actual form of the password is up to the
application. It could even change during the lifetime of a
particular connection so long as this change was synchronized
on both ends (although retransmission can become problematical
in some TCP implementations with changing passwords).
Finally, there is no negotiation for the use of this option in
a connection, rather it is purely a matter of site policy
whether or not its connections use the option."
"MD5 as a Hashing Algorithm
Since this memo was first issued (under a different title), the
MD5 algorithm has been found to be vulnerable to collision
search attacks [Dobb], and is considered by some to be
insufficiently strong for this type of application.
This memo still specifies the MD5 algorithm, however, since the
option has already been deployed operationally, and there was
no "algorithm type" field defined to allow an upgrade using the
same option number. The original document did not specify a
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
option (which would probably be padded to 20 bytes in TCP
implementations) would be too much of a waste of the already
limited option space.
This does not prevent the deployment of another similar option
which uses another hashing algorithm (like SHA-1). Also, if
most implementations pad the 18 byte option as defined to 20
bytes anyway, it would be just as well to define a new option
which contains an algorithm type field.
This would need to be addressed in another document, however."
End of quotes from [rfc2385].
2.9.2. LDP Use of TCP MD5 Signature Option
LDP uses the TCP MD5 Signature Option as follows:
- Use of the MD5 Signature Option for LDP TCP connections is a
configurable LSR option.
- An LSR that uses the MD5 Signature Option is configured with a
password (shared secret) for each potential LDP peer.
- The LSR applies the MD5 algorithm as specified in [RFC2385] to
compute the MD5 digest for a TCP segment to be sent to a peer.
This computation makes use of the peer password as well as the
TCP segment.
- When the LSR receives a TCP segment with an MD5 digest, it
validates the segment by calculating the MD5 digest (using its
own record of the password) and compares the computed digest with
the received digest. If the comparison fails, the segment is
dropped without any response to the sender.
- The LSR ignores LDP Hellos from any LSR for which a password has
not been configured. This ensures that the LSR establishes LDP
TCP connections only with LSRs for which a password has been
configured.
2.10. Label Distribution for Explicitly Routed LSPs
Traffic Engineering [TE] is expected to be an important MPLS Traffic Engineering [TE] is expected to be an important MPLS
application. MPLS support for Traffic Engineering uses explicitly application. MPLS support for Traffic Engineering uses explicitly
routed LSPs, which need not follow normally-routed (hop-by-hop) paths routed LSPs, which need not follow normally-routed (hop-by-hop) paths
as determined by destination-based routing protocols. CR-LDP [CRLDP] as determined by destination-based routing protocols. CR-LDP [CRLDP]
defines extensions to LDP to use LDP to set up explicitly routed defines extensions to LDP to use LDP to set up explicitly routed
LSPs. LSPs.
3. Protocol Specification 3. Protocol Specification
skipping to change at page 30, line 6 skipping to change at page 34, line 20
Two octet integer specifying the total length of this PDU in Two octet integer specifying the total length of this PDU in
octets, excluding the Version and PDU Length fields. octets, excluding the Version and PDU Length fields.
The maximum allowable PDU Length is negotiable when an LDP session The maximum allowable PDU Length is negotiable when an LDP session
is initialized. Prior to completion of the negotiation the maximum is 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 Six octet field that uniquely identifies the label space of the
sending LSR for which this PDU applies. The first four octets sending LSR for which this PDU applies. The first four octets
encode an IP address assigned to the LSR. This address should be identify the LSR and must be a globally unique value. It should be
the router-id, also used to identify the LSR in loop detection Path a 32-bit router Id assigned to the LSR and also used to identify it
Vectors. The last two octets identify a label space within the in loop detection Path Vectors. The last two octets identify a
LSR. For a platform-wide label space, these should both be zero. label space within the LSR. For a platform-wide label space, these
should both be 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;
- Session management; - Session management;
skipping to change at page 35, line 8 skipping to change at page 39, line 8
address prefix in the Prefix field. address prefix in the Prefix field.
Host Addr Len Host Addr Len
Length of the Host address in octets. Length of the Host address in octets.
Host Addr Host Addr
An address encoded according to the Address Family field. An address encoded according to the Address Family field.
3.4.1.1. FEC Procedures 3.4.1.1. FEC Procedures
If in decoding a FEC TLV an LSR encounters a FEC Element type it If in decoding a FEC TLV an LSR encounters a FEC Element with an
cannot decode, it should stop decoding the FEC TLV, abort processing Address Family it does not support, it should stop decoding the FEC
the message containing the TLV, and send an Notification message to TLV, abort processing the message containing the TLV, and send an
its LDP peer signaling an error. "Unsupported Address Family" Notification message to its LDP peer
signaling an error.
If it encounters a FEC Element type it cannot decode, it should stop
decoding the FEC TLV, abort processing the message containing the
TLV, and send an "Unknown FEC" Notification message to its LDP peer
signaling an error.
3.4.2. Label TLVs 3.4.2. Label TLVs
Label TLVs encode labels. Label TLVs are carried by the messages Label TLVs encode labels. Label TLVs are carried by the messages
used to advertise, request, release and withdraw label mappings. used to advertise, request, release and withdraw label mappings.
There are several different kinds of Label TLVs which can appear in There are several different kinds of Label TLVs which can appear in
situations that require a Label TLV. situations that require a Label TLV.
3.4.2.1. Generic Label TLV 3.4.2.1. Generic Label TLV
skipping to change at page 40, line 24 skipping to change at page 44, line 32
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR Id n | | LSR Id n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
One or more LSR Ids One or more LSR Ids
A list of router-ids indicating the path of LSRs the message has A list of router-ids indicating the path of LSRs the message has
traversed. Each LSR Id is the IP address (router-id) component of traversed. Each LSR Id is the first four octets (router-id) of the
the LDP identifier for the corresponding LSR. This ensures it is LDP identifier for the corresponding LSR. This ensures it is
unique within the LSR network. unique within the LSR network.
3.4.5.1. Path Vector Procedures 3.4.5.1. Path Vector Procedures
The Path Vector TLV is carried in Label Mapping and Label Request The Path Vector TLV is carried in Label Mapping and Label Request
messages when loop detection is configured. messages when loop detection is configured.
3.4.5.1.1. Label Request Path Vector 3.4.5.1.1. Label Request Path Vector
Section "Loop Detection" specifies situations when an LSR must Section "Loop Detection" specifies situations when an LSR must
skipping to change at page 41, line 28 skipping to change at page 45, line 33
Section "Loop Detection" specifies the situations when an LSR must Section "Loop Detection" specifies the situations when an LSR must
include a Path Vector TLV in a Label Mapping message. include a Path Vector TLV in a Label Mapping message.
An LSR that receives a Path Vector in a Label Mapping message must An LSR that receives a Path Vector in a Label Mapping message must
perform the procedures described in Section "Loop Detection". perform the procedures described in Section "Loop Detection".
If the LSR detects a loop, it must reject the Label Mapping message If the LSR detects a loop, it must reject the Label Mapping message
in order to prevent a forwarding loop. The LSR must: in order to prevent a forwarding loop. The LSR must:
1. Transmit a Notification message to the sending LSR signaling 1. Transmit a Label Release message carrying a Status TLV to the
"Loop Detected". sending LSR to signal "Loop Detected".
2. Not propagate the message further. 2. Not propagate the message further.
3. Check whether the Label Mapping message is for an existing LSP. 3. Check whether the Label Mapping message is for an existing LSP.
If so, the LSR must unsplice any upstream labels which are If so, the LSR must unsplice any upstream labels which are
spliced to the downstream label for the FEC. spliced to the downstream label for the FEC.
Note that a Label Mapping message with a Path Vector TLV is forwarded Note that a Label Mapping message with a Path Vector TLV is forwarded
until: until:
skipping to change at page 42, line 15 skipping to change at page 46, line 17
3.4.6. Status TLV 3.4.6. Status TLV
Notification messages carry Status TLVs to specify events being Notification messages carry Status TLVs to specify events being
signaled. signaled.
The encoding for the Status TLV is: The encoding for the Status TLV is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Status (0x0300) | Length | |U|F| Status (0x0300) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code | | Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID | | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | | Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U bit
Should be 0 when the Status TLV is sent in a Notification message.
Should be 1 when the Status TLV is sent in some other message.
F bit
Should be the same as the setting of the F-bit in the Status Code
field.
Status Code Status Code
32-bit unsigned integer encoding the event being signaled. The 32-bit unsigned integer encoding the event being signaled. The
structure of a Status Code is: structure of a Status Code 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|F| Status Data | |E|F| Status Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 44, line 18 skipping to change at page 48, line 43
Identifies the type of message Identifies the type of message
Message Length Message Length
Specifies the cumulative length in octets of the Message ID, Specifies the cumulative length in octets of the Message ID,
Mandatory Parameters, and Optional Parameters. Mandatory Parameters, and Optional Parameters.
Message ID Message ID
32-bit value used to identify this message. Used by the sending 32-bit value used to identify this message. Used by the sending
LSR to facilitate identifying notification messages that may apply LSR to facilitate identifying notification messages that may apply
to this message. An LSR sending a notification message in response to this message. An LSR sending a notification message in response
to this message should include this Message Id in the notification to this message should include this Message Id in the Status TLV
message; see Section "Notification Message". carried by the notification message; see Section "Notification
Message".
Mandatory Parameters Mandatory Parameters
Variable length set of required message parameters. Some messages Variable length set of required message parameters. Some messages
have no required parameters. have no required parameters.
For messages that have required parameters, the required parameters For messages that have required parameters, the required parameters
MUST appear in the order specified by the individual message MUST appear in the order specified by the individual message
specifications in the sections that follow. specifications in the sections that follow.
Optional Parameters Optional Parameters
skipping to change at page 47, line 16 skipping to change at page 51, line 25
type and length fields and as much message data following the type and length fields and as much message data following the
type and length fields as appropriate for the condition being type and length fields as appropriate for the condition being
signaled by the Notification message. signaled by the Notification message.
3.5.1.1. Notification Message Procedures 3.5.1.1. Notification Message Procedures
If an LSR encounters a condition requiring it to notify its peer with If an LSR encounters a condition requiring it to notify its peer with
advisory or error information it sends the peer a Notification advisory or error information it sends the peer a Notification
message containing a Status TLV that encodes the information and message containing a Status TLV that encodes the information and
optionally additional TLVs that provide more information about the optionally additional TLVs that provide more information about the
event. condition.
If the condition is one that is a fatal error the Status Code carried If the condition is one that is a fatal error the Status Code carried
in the notification will indicate that. In this case, after sending in the notification will indicate that. In this case, after sending
the Notification message the LSR should terminate the LDP session by the Notification message the LSR should terminate the LDP session by
closing the session TCP connection and discard all state associated closing the session TCP connection and discard all state associated
with the session, including all label-FEC bindings learned via the with the session, including all label-FEC bindings learned via the
session. session.
When an LSR receives a Notification message that carries a Status When an LSR receives a Notification message that carries a Status
Code that indicates a fatal error, it should terminate the LDP Code that indicates a fatal error, it should terminate the LDP
skipping to change at page 48, line 29 skipping to change at page 52, line 37
If the Message Type is < 0x8000 (high order bit = 0) it is an If the Message Type is < 0x8000 (high order bit = 0) it is an
error signaled by the Unknown Message Type Status Code. error signaled by the Unknown Message Type Status Code.
If the Message Type is >= 0x8000 (high order bit = 1) it is If the Message Type is >= 0x8000 (high order bit = 1) it is
silently discarded. silently discarded.
- 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 Code. is a fatal error signaled by the Bad Message Length Status Code.
- The message is missing one or more Mandatory Parameters. This is
a non-fatal error signalled by the Missing Message Parameters
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:
- The TLV Length is too large, that is, indicates that the TLV - The TLV Length is too large, that is, indicates that the TLV
extends beyond the end of the containing message. This is a extends beyond the end of the containing message. This is a
fatal error signaled by the Bad TLV Length Status Code. fatal error signaled by the Bad TLV Length Status Code.
- The TLV type is unknown. - The TLV type is unknown.
If the TLV type is < 0x8000 (high order bit 0) it is an error If the TLV type is < 0x8000 (high order bit 0) it is an error
signaled by the Unknown TLV Status Code. signaled by the Unknown TLV Status Code.
If the TLV type is >= 08000 (high order bit 1) the TLV is If the TLV type is >= 0x8000 (high order bit 1) the TLV is
silently dropped. Section "Unknown TLV in Known Message Type" silently dropped. Section "Unknown TLV in Known Message Type"
elaborates on this behavior. elaborates on this behavior.
- The TLV Value is malformed. This occurs when the receiver - The TLV Value is malformed. This occurs when the receiver
handles the TLV but cannot decode the TLV Value. This is handles the TLV but cannot decode the TLV Value. This is
interpreted as indicative of a bug in either the sending or interpreted as indicative of a bug in either the sending or
receiving LSR. It is a fatal error signaled by the Malformed TLV receiving LSR. It is a fatal error signaled by the Malformed TLV
Value Status Code. Value Status Code.
3.5.1.2.3. Session KeepAlive Timer Expiration 3.5.1.2.3. Session KeepAlive Timer Expiration
skipping to change at page 49, line 39 skipping to change at page 54, line 7
and is defined in Sections "Initialization Message". and is defined in Sections "Initialization Message".
3.5.1.2.6. Events Resulting From Other Messages 3.5.1.2.6. Events Resulting From Other Messages
Messages other than the Initialization message may result in events Messages other than the Initialization message may result in events
that must be signaled to LDP peers via Notification Messages. These that must be signaled to LDP peers via Notification Messages. These
events and the Status Codes used in the Notification Messages to events and the Status Codes used in the Notification Messages to
signal them are described in the sections that describe these signal them are described in the sections that describe these
messages. messages.
3.5.1.2.7. Miscellaneous Events 3.5.1.2.7. Internal Errors
An LDP implementation may be capable of detecting problem conditions
specific to its implementation. When such a condition prevents an
implementation from interacting correctly with a peer, the
implementation should, when capable of doing so, use the Internal
Error Status Code to signal the peer. This is a fatal error.
3.5.1.2.8. Miscellaneous Events
These are events that fall into none of the categories above. There These are events that fall into none of the categories above. There
are no miscellaneous events defined in this version of the protocol. are no miscellaneous events defined in this version of the protocol.
3.5.2. Hello Message 3.5.2. Hello Message
LDP Hello Messages are exchanged as part of the LDP Discovery LDP Hello Messages are exchanged as part of the LDP Discovery
Mechanism; see Section "LDP Discovery". Mechanism; see Section "LDP Discovery".
The encoding for the Hello Message is: The encoding for the Hello Message is:
skipping to change at page 51, line 31 skipping to change at page 56, line 4
source. source.
Reserved Reserved
This field is reserved. It must be set to zero on transmission This field is reserved. It must be set to zero on transmission
and ignored on receipt. and ignored on receipt.
Optional Parameters Optional Parameters
This variable length field contains 0 or more parameters, each This variable length field contains 0 or more parameters, each
encoded as a TLV. The optional parameters defined by this encoded as a TLV. The optional parameters defined by this
version of the protocol are version of the protocol are
Optional Parameter Type Length Value Optional Parameter Type Length Value
Transport Address 0x0401 4 See below IPv4 Transport Address 0x0401 4 See below
Configuration 0x0402 4 See below Configuration 0x0402 4 See below
Sequence Number Sequence Number
IPv6 Transport Address 0x0403 8 See below
Transport Address IPv4 Transport Address
Specifies the IPv4 address to be used for the sending LSR when Specifies the IPv4 address to be used for the sending LSR when
opening the LDP session TCP connection. If this optional TLV opening the LDP session TCP connection. If this optional TLV
is not present the IPv4 source address for the UDP packet is not present the IPv4 source address for the UDP packet
carrying the Hello should be used. carrying the Hello should be used.
Configuration Sequence Number Configuration Sequence Number
Specifies a 4 octet unsigned configuration sequence number that Specifies a 4 octet unsigned configuration sequence number that
identifies the configuration state of the sending LSR. Used by identifies the configuration state of the sending LSR. Used by
the receiving LSR to detect configuration changes on the the receiving LSR to detect configuration changes on the
sending LSR. sending LSR.
IPv6 Transport Address
Specifies the IPv6 address to be used for the sending LSR when
opening the LDP session TCP connection. If this optional TLV
is not present the IPv6 source address for the UDP packet
carrying the Hello should be used.
3.5.2.1. Hello Message Procedures 3.5.2.1. Hello Message Procedures
An LSR receiving Hellos from another LSR maintains a Hello adjacency An LSR receiving Hellos from another LSR maintains a Hello adjacency
corresponding to the Hellos. The LSR maintains a hold timer with the corresponding to the Hellos. The LSR maintains a hold timer with the
Hello adjacency which it restarts whenever it receives a Hello that Hello adjacency which it restarts whenever it receives a Hello that
matches the Hello adjacency. If the hold timer for a Hello adjacency matches the Hello adjacency. If the hold timer for a Hello adjacency
expires the LSR discards the Hello adjacency: see sections expires the LSR discards the Hello adjacency: see sections
"Maintaining Hello Adjacencies" and "Maintaining LDP Sessions". "Maintaining Hello Adjacencies" and "Maintaining LDP Sessions".
We recommend that the interval between Hello transmissions be at most We recommend that the interval between Hello transmissions be at most
skipping to change at page 52, line 44 skipping to change at page 57, line 26
specified by the LDP identifier in the PDU header for the specified by the LDP identifier in the PDU header for the
Hello, it follows the procedures of Section "LDP Session Hello, it follows the procedures of Section "LDP Session
Establishment". Establishment".
The following are examples of acceptability criteria for Link and The following are examples of acceptability criteria for Link and
Targeted Hellos: Targeted Hellos:
A Link Hello is acceptable if the interface on which it was A Link Hello is acceptable if the interface on which it was
received has been configured for label switching. received has been configured for label switching.
A Targeted Hello from IP source address a.b.c.d is acceptable if A Targeted Hello from source address A is acceptable if either:
either:
- The LSR has been configured to accept Targeted Hellos, or - The LSR has been configured to accept Targeted Hellos, or
- The LSR has been configured to send Targeted Hellos to - The LSR has been configured to send Targeted Hellos to A.
a.b.c.d.
The following describes how an LSR processes Hello optional TLVs: The following describes how an LSR processes Hello optional TLVs:
Transport Address Transport Address
The LSR associates the specified transport address with the The LSR associates the specified transport address with the
Hello adjacency. Hello adjacency.
Configuration Sequence Number Configuration Sequence Number
The Configuration Sequence Number optional parameter is used by The Configuration Sequence Number optional parameter is used by
the sending LSR to signal configuration changes to the the sending LSR to signal configuration changes to the
skipping to change at page 57, line 15 skipping to change at page 61, line 40
1 VP Merge supported 1 VP Merge supported
2 VC Merge supported 2 VC Merge supported
3 VP & VC Merge supported 3 VP & VC Merge supported
If the merge capabilities of the LSRs differ, then: If the merge capabilities of the LSRs differ, then:
- Non-merge and VC-merge LSRs may freely interoperate. - Non-merge and VC-merge LSRs may freely interoperate.
- The interoperability of VP-merge-capable switches with - The interoperability of VP-merge-capable switches with
non-VP-merge-capable switches is a subject for future non-VP-merge-capable switches is a subject for future
study. study. When the LSRs differ on the use of VP-merge, the
session is 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 (see [ATM-VP]).
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
skipping to change at page 63, line 28 skipping to change at page 68, line 16
Mapping or Label Request messages an LSR should advertise its Mapping or Label Request messages an LSR should advertise its
interface addresses with one or more Address messages. interface addresses with one or more Address messages.
Whenever an LSR "activates" a new interface address, it should Whenever an LSR "activates" a new interface address, it should
advertise the new address with an Address message. advertise the new address with an Address message.
Whenever an LSR "de-activates" a previously advertised address, it Whenever an LSR "de-activates" a previously advertised address, it
should withdraw the address with an Address Withdraw message; see should withdraw the address with an Address Withdraw message; see
Section "Address Withdraw Message". Section "Address Withdraw Message".
If an LSR does not support the Address Family specified in the
Address List TLV, it should send an "Unsupported Address Family"
Notification to its LDP signalling an error and abort processing the
message.
3.5.6. Address Withdraw Message 3.5.6. Address Withdraw Message
An LSR sends the Address Withdraw Message to an LDP peer to withdraw An LSR sends the Address Withdraw Message to an LDP peer to withdraw
previously advertised interface addresses. previously advertised interface addresses.
The encoding for the Address Withdraw Message is: The encoding for the Address Withdraw Message is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 72, line 38 skipping to change at page 77, line 20
abort; abort;
- A Label Mapping message in response to the Label Request message - A Label Mapping message in response to the Label Request message
being aborted; being aborted;
- A Notification message in response to the Label Request message - A Notification message in response to the Label Request message
being aborted (e.g., Loop Detected, No Label Resources, etc.). being aborted (e.g., Loop Detected, No Label Resources, etc.).
To protect itself against tardy peers or faulty peer implementations To protect itself against tardy peers or faulty peer implementations
an LSR may choose to time out receipt of the above. The time out an LSR may choose to time out receipt of the above. The time out
period should be relatively long (several minutes). period should be relatively long (several minutes). If the time out
period elapses with no reply from the peer the LSR may reuse the
Message Id of the Label Request message; if it does so, it should
also discard any record of the outstanding Label Request and Label
Abort messages.
Note that the response to a Label Abort Request message is never Note that the response to a Label Abort Request message is never
"ordered". That is, the response does not depend on the downstream "ordered". That is, the response does not depend on the downstream
state of the LSP setup being aborted. An LSR receiving a Label Abort state of the LSP setup being aborted. An LSR receiving a Label Abort
Request message must process it immediately, regardless of the Request message must process it immediately, regardless of the
downstream state of the LSP, responding with a Label Request Aborted downstream state of the LSP, responding with a Label Request Aborted
Notification or ignoring it, as appropriate. Notification or ignoring it, as appropriate.
3.5.10. Label Withdraw Message 3.5.10. Label Withdraw Message
skipping to change at page 80, line 47 skipping to change at page 85, line 42
Path Vector 0x0104 "Path Vector TLV" Path Vector 0x0104 "Path Vector TLV"
Generic Label 0x0200 "Generic Label TLV" Generic Label 0x0200 "Generic Label TLV"
ATM Label 0x0201 "ATM Label TLV" ATM Label 0x0201 "ATM Label TLV"
Frame Relay Label 0x0202 "Frame Relay Label TLV" Frame Relay Label 0x0202 "Frame Relay Label TLV"
Status 0x0300 "Status TLV" Status 0x0300 "Status TLV"
Extended Status 0x0301 "Notification Message" Extended Status 0x0301 "Notification Message"
Returned PDU 0x0302 "Notification Message" Returned PDU 0x0302 "Notification Message"
Returned Message 0x0303 "Notification Message" Returned Message 0x0303 "Notification Message"
Common Hello 0x0400 "Hello Message" Common Hello 0x0400 "Hello Message"
Parameters Parameters
Transport Address 0x0401 "Hello Message" IPv4 Transport Address 0x0401 "Hello Message"
Configuration 0x0402 "Hello Message" Configuration 0x0402 "Hello Message"
Sequence Number Sequence Number
IPv6 Transport Address 0x0403 "Hello Message"
Common Session 0x0500 "Initialization Message" Common Session 0x0500 "Initialization Message"
Parameters Parameters
ATM Session Parameters 0x0501 "Initialization Message" ATM Session Parameters 0x0501 "Initialization Message"
Frame Relay Session 0x0502 "Initialization Message" Frame Relay Session 0x0502 "Initialization Message"
Parameters Parameters
Label Request 0x0600 "Label Mapping Message" Label Request 0x0600 "Label Mapping Message"
Message ID Message ID
Vendor-Private 0x3E00- "LDP Vendor-private Extensions" Vendor-Private 0x3E00- "LDP Vendor-private Extensions"
0x3EFF 0x3EFF
Experimental 0x3F00- "LDP Experimental Extensions" Experimental 0x3F00- "LDP Experimental Extensions"
skipping to change at page 82, line 11 skipping to change at page 87, line 7
No Hello No Hello
Session Rejected/ 1 0x00000011 "Session Initialization" Session Rejected/ 1 0x00000011 "Session Initialization"
Parameters Advertisement Mode Parameters Advertisement Mode
Session Rejected/ 1 0x00000012 "Session Initialization" Session Rejected/ 1 0x00000012 "Session Initialization"
Parameters Max PDU Length Parameters Max PDU Length
Session Rejected/ 1 0x00000013 "Session Initialization" Session Rejected/ 1 0x00000013 "Session Initialization"
Parameters Label Range Parameters Label Range
KeepAlive Timer 1 0x00000014 "Events Signaled by ..." KeepAlive Timer 1 0x00000014 "Events Signaled by ..."
Expired Expired
Label Request Aborted 0 0x00000015 "Label Request Abort ..." Label Request Aborted 0 0x00000015 "Label Request Abort ..."
Missing Message 0 0x00000016 "Events Signaled by ..."
Parameters
Unsupported Address 0 0x00000017 "FEC Procedures"
Family "Address Message Proc ..."
Session Rejected/ 1 0x00000018 "Session Initialization"
Bad KeepAlive Time
Internal Error 1 0x00000019 "Events Signaled by ..."
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 [ARCH]) is represented as a Generic The Implicit NULL label (see [ARCH]) is represented as a Generic
Label TLV with a Label field value as specified by [ENCAP]. Label TLV with a Label field value as specified by [ENCAP].
4. Security Considerations 4. IANA Considerations
This section specifies an optional mechanism to protect against the LDP defines the following name spaces which require management:
introduction of spoofed TCP segments into LDP session connection
streams.
It is based on use of the TCP MD5 Signature Option specified in - Message types.
[rfc2385] for use by BGP. See [rfc1321] for a specification of the - TLV types.
MD5 hash function. - FEC types.
- Status codes.
- Experiment Ids.
4.1. The TCP MD5 Signature Option The following sections provide guidelines for managing these name
spaces.
The following quotes from [rfc2385] outline the security properties 4.1. Message Type Name Space
achieved by using the TCP MD5 Signature Option and summarizes its
operation:
"IESG Note LDP divides the name space for message types into three ranges. The
following are the guidelines for managing these ranges:
This document describes current existing practice for securing - Message Types 0x0000 - 0x3DFF. Message types in this range are
BGP against certain simple attacks. It is understood to have part of the LDP base protocol. Following the policies outlined
security weaknesses against concerted attacks." in [IANA], Message types in this range are allocated through an
IETF Consensus action.
"Abstract - Message Types 0x3E00 - 0x3EFF. Message types in this range are
This memo describes a TCP extension to enhance security for reserved for Vendor Private extensions and are the responsibility
BGP. It defines a new TCP option for carrying an MD5 [RFC1321] of the individual vendors (see Section "LDP Vendor-private
digest in a TCP segment. This digest acts like a signature for Messages").
that segment, incorporating information known only to the
connection end points. Since BGP uses TCP as its transport,
using this option in the way described in this paper
significantly reduces the danger from certain security attacks
on BGP."
"Introduction - Message Types 0x3F00 - 0x3FFF. Message types in this range are
reserved for Experimental extensions and are the responsibility
of the individual experimenters (see Sections "LDP Experimental
Extensions" and "Experiment ID Name Space").
The primary motivation for this option is to allow BGP to 4.2. TLV Type Name Space
protect itself against the introduction of spoofed TCP segments
into the connection stream. Of particular concern are TCP
resets.
To spoof a connection using the scheme described in this paper, LDP divides the name space for TLV types into three ranges. The
an attacker would not only have to guess TCP sequence numbers, following are the guidelines for managing these ranges:
but would also have had to obtain the password included in the
MD5 digest. This password never appears in the connection
stream, and the actual form of the password is up to the
application. It could even change during the lifetime of a
particular connection so long as this change was synchronized
on both ends (although retransmission can become problematical
in some TCP implementations with changing passwords).
Finally, there is no negotiation for the use of this option in - TLV Types 0x0000 - 0x3DFF. TLV types in this range are part of
a connection, rather it is purely a matter of site policy the LDP base protocol. Following the policies outlined in
whether or not its connections use the option." [IANA], TLV types in this range are allocated through an IETF
Consensus action.
"MD5 as a Hashing Algorithm - TLV Types 0x3E00 - 0x3EFF. TLV types in this range are reserved
for Vendor Private extensions and are the responsibility of the
individual vendors (see Section "LDP Vendor-private TLVs").
Since this memo was first issued (under a different title), the - TLV Types 0x3F00 - 0x3FFF. TLV types in this range are reserved
MD5 algorithm has been found to be vulnerable to collision for Experimental extensions and are the responsibility of the
search attacks [Dobb], and is considered by some to be individual experimenters (see Sections "LDP Experimental
insufficiently strong for this type of application. Extensions" and "Experiment ID Name Space").
This memo still specifies the MD5 algorithm, however, since the 4.3. FEC Type Name Space
option has already been deployed operationally, and there was
no "algorithm type" field defined to allow an upgrade using the
same option number. The original document did not specify a
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
option (which would probably be padded to 20 bytes in TCP
implementations) would be too much of a waste of the already
limited option space.
This does not prevent the deployment of another similar option The range for FEC types is 0 - 255.
which uses another hashing algorithm (like SHA-1). Also, if
most implementations pad the 18 byte option as defined to 20
bytes anyway, it would be just as well to define a new option
which contains an algorithm type field.
This would need to be addressed in another document, however." Following the policies outlined in [IANA], FEC types in the range 0 -
127 are allocated through an IETF Consensus action, types in the
range 128 - 191 are allocated as First Come First Served, and types
in the range 192 - 255 are reserved for Private Use.
End of quotes from [rfc2385]. 4.4. Status Code Space
4.2. LDP Use of the TCP MD5 Signature Option The range for Status Codes is 0x00000000 - 0x3FFFFFFF.
LDP uses the TCP MD5 Signature Option as follows: Following the policies outlined in [IANA], Status Codes in the range
0x00000000 - 0x1FFFFFFF are allocated through an IETF Consensus
action, codes in the range 0x20000000 - 0x3EFFFFFF are allocated as
First Come First Served, and codes in the range 0x3F000000 -
0x3FFFFFFF are reserved for Private Use.
- Use of the MD5 Signature Option for LDP TCP connections is a 4.5. Experiment ID Name Space
configurable LSR option.
- An LSR that uses the MD5 Signature Option is configured with a The range for Experiment Ids is 0x00000000 - 0xffffffff.
password for each potential LDP peer.
- The LSR applies the MD5 algorithm as specified in [RFC2385] to Following the policies outlined in [IANA], Experiment Ids in the
compute the MD5 digest for a TCP segment to be sent to a peer. range 0x00000000 - 0xefffffff are allocated as First Come First
This computation makes use of the peer password as well as the Served and Experiment Ids in the range 0xf0000000 are reserved for
TCP segment. Private Use.
- When the LSR receives a TCP segment with an MD5 digest, it 5. Security Considerations
validates the segment by calculating the MD5 digest (using its
own record of the password) and compares the computed digest with
the received digest. If the comparison fails, the segment is
dropped without any response to the sender.
- The LSR ignores LDP Hellos from any LSR for which a password has This section identifies threats to which LDP may be vulnerable and
not been configured. This ensures that the LSR establishes LDP discusses means by which those threats might be mitigated.
TCP connections only with LSRs for which a password has been
configured.
5. Areas for Future Study 5.1. Spoofing
There are two types of LDP communication that could be the target of
a spoofing attack.
1. Discovery exchanges carried by UDP.
LSRs directly connected at the link level exchange Basic Hello
messages over the link. The threat of spoofed Basic Hellos can
be reduced by:
o Accepting Basic Hellos only on interfaces to which LSRs that
can be trusted are directly connected.
o Ignoring Basic Hellos not addressed to the All Routers on
this Subnet multicast group.
LSRs not directly connected at the link level may use Extended
Hello messages to indicate willingness to establish an LDP
session. An LSR can reduce the threat of spoofed Extended Hellos
by filtering them and accepting only those originating at sources
permitted by an access list.
2. Session communication carried by TCP.
LDP specifies use of the TCP MD5 Signature Option to provide for
the authenticity and integrity of session messages.
[rfc2385] asserts that MD5 authentication is now considered by
some to be too weak for this application. It also points out
that a similar TCP option with a stronger hashing algorithm (it
cites SHA-1 as an example) could be deployed. To our knowledge
no such TCP option has been defined and deployed. However, we
note that LDP can use whatever TCP message digest techniques are
available, and when one stronger than MD5 is specified and
implemented, upgrading LDP to use it would be relatively
straightforward.
5.2. Privacy
LDP provides no mechanism for protecting the privacy of label
distribution.
The security requirements of label distribution protocols are
essentially identical to those of the protocols which distribute
routing information. By providing a mechanism to ensure the
authenticity and integrity of its messages LDP provides a level of
security which is at least as good as, though no better than, that
which can be provided by the routing protocols themselves. The more
general issue of whether privacy should be required for routing
protocols is beyond the scope of this document.
One might argue that label distribution requires privacy to address
the threat of label spoofing. However, that privacy would not
protect against label spoofing attacks since data packets carry
labels in the clear. Furthermoe, label spoofing attacks can be made
without knowledge of the FEC bound to a label.
To avoid label spoofing attacks, it is necessary to ensure that
labeled data packets are labeled by trusted LSRs and that the labels
placed on the packets are properly learned by the labeling LSRs.
5.3. Denial of Service
LDP provides two potential targets for denial of service (DoS)
attacks:
1. Well known UDP Port for LDP Discovery
An LSR adminstrator can address the threat of DoS attacks via
Basic Hellos by ensuring that the LSR is directly connected only
to peers which can be trusted to not initiate such an attack.
Interfaces to peers interior to the administrator's domain should
not represent a threat since interior peers are under the
administrator's control. Interfaces to peers exterior to the
domain represent a potential threat since exterior peers are not.
An adminstrator can reduce that threat by connecting the LSR only
to exterior peers that can be trusted to not initiate a Basic
Hello attack.
DoS attacks via Extended Hellos are potentially a more serious
threat. This threat can be addressed by filtering Extended
Hellos using access lists that define addresses with which
extended discovery is permitted. However, performing the
filering requires LSR resource.
In an environment where a trusted MPLS cloud can be identified,
LSRs at the edge of the cloud can be used to protect interior
LSRs against DoS attacks via Extended Hellos by filtering out
Extended Hellos originating outside of the trusted MPLS cloud,
accepting only those originating at addresses permitted by access
lists. This filtering protects LSRs in the interior of the cloud
but consumes resoures at the edges.
2. Well known TCP port for LDP Session Establishment
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 vulnerable to such attacks than other control plane
protocols that use TCP.
The threat of such attacks can be mitigated somewhat by the
following:
o An LSR should avoid promiscuous TCP listens for LDP session
establishment. It should use only listens that are specific
to discovered peers. This enables it to drop attack packets
early in their processing since they are less likely to match
existing or in-progress connections.
o The use of the MD5 option helps somewhat since it prevents a
SYN from being accepted unless the MD5 segment checksum is
valid. However, the receiver must compute the checksum
before it can decide to discard an otherwise acceptable SYN
segment.
o The use of access list mechanisms applied at the boundary of
the MPLS cloud in a manner similar to that suggested above
for Extended Hellos can protect the interior against attacks
originating from outside the cloud.
6. Areas for Future Study
The following topics not addressed in this version of LDP are The following topics not addressed in this version of LDP are
possible areas for future study: possible areas for future study:
- Section 2.16 of the MPLS architecture [ARCH] requires that the - Section 2.16 of the MPLS architecture [ARCH] requires that the
initial label distribution protocol negotiation between peer LSRs initial label distribution protocol negotiation between peer LSRs
enable each LSR to determine whether its peer is capable of enable each LSR to determine whether its peer is capable of
popping the label stack. This version of LDP assumes that LSRs popping the label stack. This version of LDP assumes that LSRs
support label popping for all link types except ATM and Frame support label popping for all link types except ATM and Frame
Relay. A future version may specify means to make this Relay. A future version may specify means to make this
skipping to change at page 85, line 16 skipping to change at page 93, line 5
- LDP support for CoS is not specified in this version. CoS - LDP support for CoS is not specified in this version. CoS
support may be addressed in a future version. 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.
6. Intellectual Property Considerations 7. Intellectual Property Considerations
The IETF has been notified of intellectual property rights claimed in The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this regard to some or all of the specification contained in this
document. For more information consult the online list of claimed document. For more information consult the online list of claimed
rights. rights.
7. Acknowledgments 8. Acknowledgments
The ideas and text in this document have been collected from a number The ideas and text in this document have been collected from a number
of sources. We would like to thank Rick Boivie, Ross Callon, Alex of sources. We would like to thank Rick Boivie, Ross Callon, Alex
Conta, Eric Gray, Yoshihiro Ohba, Eric Rosen, Bernard Suter, Yakov Conta, Eric Gray, Yoshihiro Ohba, Eric Rosen, Bernard Suter, Yakov
Rekhter, and Arun Viswanathan. Rekhter, and Arun Viswanathan.
8. References 9. References
[ARCH] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label [ARCH] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label
Switching Architecture", Work in Progress, July 1998. Switching Architecture", Work in Progress, July 1998.
[ATM] B. Davie, J. Lawrence, K. McCloghrie, Y. Rekhter, E. Rosen, G. [ATM] B. Davie, J. Lawrence, K. McCloghrie, Y. Rekhter, E. Rosen, G.
Swallow, P. Doolan, "Use of Label Switching With ATM", Work in Swallow, P. Doolan, "Use of Label Switching With ATM", Work in
Progress, September, 1998. Progress, September, 1998.
[ATM-VP] N. Feldman, B. Jamoussi, S. Komandur, A, Viswanathan, T [ATM-VP] N. Feldman, B. Jamoussi, S. Komandur, A, Viswanathan, T
Worster, "MPLS using ATM VP Switching", Work in Progress, February, Worster, "MPLS using ATM VP Switching", Work in Progress, February,
skipping to change at page 86, line 20 skipping to change at page 94, line 6
T. Li, A. Conta, "MPLS Label Stack Encoding", Work in Progress, July, T. Li, A. Conta, "MPLS Label Stack Encoding", Work in Progress, July,
1998. 1998.
[FR] A. Conta, P. Doolan, A. Malis, "Use of Label Switching on Frame [FR] A. Conta, P. Doolan, A. Malis, "Use of Label Switching on Frame
Relay Networks", Work in Progress, October, 1998. Relay Networks", Work in Progress, October, 1998.
[FRAMEWORK] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. [FRAMEWORK] R. Callon, P. Doolan, N. Feldman, A. Fredette, G.
Swallow, A. Viswanathan, "A Framework for Multiprotocol Label Swallow, A. Viswanathan, "A Framework for Multiprotocol Label
Switching", Work in Progress, November 1997. Switching", Work in Progress, November 1997.
[IANA] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, October 1998.
[LDPAPPLIC] B. Thomas, E. Gray, "LDP Applicability", Work in
Progress, June 2000.
[LSPTUN] D. Awduche, L. Berger, D. Gan, T. Li, G. Swallow, Vijay [LSPTUN] D. Awduche, L. Berger, D. Gan, T. Li, G. Swallow, Vijay
Srinivasan, "Extensions to RSVP for LSP Tunnels", Work in Progress, Srinivasan, "Extensions to RSVP for LSP Tunnels", Work in Progress,
November 1998. November 1998.
[rfc1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321, [rfc1321] R. Rivest, "The MD5 Message-Digest Algorithm," RFC 1321,
April 1992. April 1992.
[rfc1483] J. Heinanen, "Multiprotocol Encapsulation over ATM [rfc1483] J. Heinanen, "Multiprotocol Encapsulation over ATM
Adaptation Layer 5", RFC 1483, Telecom Finland, July 1993. Adaptation Layer 5", RFC 1483, Telecom Finland, July 1993.
[rfc1583] J. Moy, "OSPF Version 2", RFC 1583, Proteon Inc, March [rfc1583] J. Moy, "OSPF Version 2", RFC 1583, Proteon Inc, March
1994. 1994.
[rfc1700] J. Reynolds, J.Postel, "ASSIGNED NUMBERS", October 1994. [rfc1700] J. Reynolds, J.Postel, "ASSIGNED NUMBERS", October 1994.
[rfc1771] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)", [rfc1771] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771, March 1995. RFC 1771, March 1995.
[rfc2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[rfc2205] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, [rfc2205] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997. Specification", RFC 2205, September 1997.
[rfc2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [rfc2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998. Signature Option", RFC 2385, August 1998.
[TE] D. Awduche, J. Malcolm, J Agogbua, M. O'Dell, J. McManus, " [TE] D. Awduche, J. Malcolm, J Agogbua, M. O'Dell, J. McManus, "
Requirements for Traffic Engineering over MPLS", Work in Progress, Requirements for Traffic Engineering over MPLS", Work in Progress,
October 1998. October 1998.
9. Author Information 10. Author Information
Loa Andersson Andre Fredette Loa Andersson Andre Fredette
Nortel Networks Inc Nortel Networks Inc Nortel Networks Inc Nortel Networks Inc
St Eriksgatan 115, PO Box 6701 600 Technology Park Drive St Eriksgatan 115, PO Box 6701 600 Technology Park Drive
113 85 Stockholm Billerica, MA 01821 113 85 Stockholm Billerica, MA 01821
Sweden Phone: 978-288-8524 Sweden Phone: 978-288-8524
Phone: +46 8 5088 36 34 email: Phone: +46 8 5088 36 34 email: fredette@nortelnetworks.com
fredette@nortelnetworks.com
Mobile: +46 70 522 78 34 Mobile: +46 70 522 78 34
email: loa.andersson@nortelnetworks.com email: loa.andersson@nortelnetworks.com
Paul Doolan Bob Thomas Paul Doolan Bob Thomas
Ennovate Networks Cisco Systems, Inc. Ennovate Networks Cisco Systems, Inc.
330 Codman Hill Rd 250 Apollo Dr. 330 Codman Hill Rd 250 Apollo Dr.
Marlborough MA 01719 Chelmsford, MA 01824 Marlborough MA 01719 Chelmsford, MA 01824
Phone: 978-263-2002 Phone: 978-244-8078 Phone: 978-263-2002 Phone: 978-244-8078
email: pdoolan@ennovatenetworks.com email: rhthomas@cisco.com email: pdoolan@ennovatenetworks.com email: rhthomas@cisco.com
skipping to change at page 91, line 45 skipping to change at page 99, line 45
- SAttributes. Attributes to be included in Label Request message, - SAttributes. Attributes to be included in Label Request message,
if any, propagated to FEC Next Hop. if any, propagated to FEC Next Hop.
- StoredHopCount. The hop count, if any, previously recorded for - StoredHopCount. The hop count, if any, previously recorded for
the FEC. the FEC.
Algorithm: Algorithm:
LRq.1 Execute procedure Check_Received_Attributes (MsgSource, LRq.1 Execute procedure Check_Received_Attributes (MsgSource,
RAttributes). LabelRequest, RAttributes).
If Loop Detected, goto LRq.13. If Loop Detected, goto LRq.13.
LRq.2 Is there a Next Hop for FEC? LRq.2 Is there a Next Hop for FEC?
If not, goto LRq.5. If not, goto LRq.5.
LRq.3 Is MsgSource the Next Hop? LRq.3 Is MsgSource the Next Hop?
Ifnot, goto LRq.6. Ifnot, goto LRq.6.
LRq.4 Execute procedure Send_Notification (MsgSource, Loop LRq.4 Execute procedure Send_Notification (MsgSource, Loop
Detected). Detected).
skipping to change at page 95, line 26 skipping to change at page 103, line 26
- RAttributes. Attributes received with the message. E.g., Hop - RAttributes. Attributes received with the message. E.g., Hop
Count, Path Vector. Count, Path Vector.
- SAttributes to be included in Label Mapping message, if any, - SAttributes to be included in Label Mapping message, if any,
propagated to upstream peers. propagated to upstream peers.
Algorithm: Algorithm:
LMp.1 Does the received label mapping match an outstanding label LMp.1 Does the received label mapping match an outstanding label
request for FEC previously sent to MsgSource. request for FEC previously sent to MsgSource.
If not, goto LMp.9. If not, goto LMp.3.
LMp.2 Delete record of outstanding FEC label request. LMp.2 Delete record of outstanding FEC label request.
LMp.3 Execute procedure Check_Received_Attributes (MsgSource, LMp.3 Execute procedure Check_Received_Attributes (MsgSource,
RAttributes). LabelMapping, RAttributes).
If No Loop Detected, goto LMp.9. If No Loop Detected, goto LMp.9.
LMp.4 Does the LSR have a previously received label mapping for FEC LMp.4 Does the LSR have a previously received label mapping for FEC
from MsgSource? from MsgSource? (See Note 1.)
If not, goto LMp.8. (See Note 1.). If not, goto LMp.8. (See Note 2.)
LMp.5 Does the label previously received from MsgSource match Label LMp.5 Does the label previously received from MsgSource match Label
(i.e., the label received in the message)? (i.e., the label received in the message)? (See Note 3.)
If not, goto LMp.8. (See Note 2.) If not, goto LMp.8. (See Note 4.)
LMp.6 Delete matching label mapping for FEC previously received LMp.6 Delete matching label mapping for FEC previously received
from MsgSource. from MsgSource.
LMp.7 Remove Label from forwarding/switching use. (See Note 3.). LMp.7 Remove Label from forwarding/switching use. (See Note 5.)
Goto LMp.26. Goto LMp.33.
LMp.8 Execute procedure Send_Message (MsgSource, Label Release, LMp.8 Execute procedure Send_Message (MsgSource, Label Release,
FEC, Label). Goto LMp.26. FEC, Label, Loop Detected Status code). Goto LMp.33.
LMp.9 Determine the Next Hop for FEC. LMp.9 Does LSR have a previously received label mapping for FEC
from MsgSource for the LSP in question? (See Note 6.)
If not, goto LMp.11.
LMp.10 Is MsgSource the Next Hop for FEC? LMp.10 Does the label previously received from MsgSource match Label
If so, goto LMp.12. (i.e., the label received in the message)? (See Note 3.)
If not, goto LMp.32. (See Note 4.)
LMp.11 Perform LSR Label Release procedure: LMp.11 Determine the Next Hop for FEC.
LMp.12 Is MsgSource the Next Hop for FEC?
If so, goto LMp.14.
LMp.13 Perform LSR Label Release procedure:
For Conservative Label retention: For Conservative Label retention:
1. Execute procedure Send_Message (MsgSource, Label 1. Goto LMp.32.
Release, FEC, Label).
Goto LMp.26.
For Liberal Label retention: For Liberal Label retention:
1. Record label mapping for FEC with Label and 1. Record label mapping for FEC with Label and
RAttributes has been received from MsgSource. RAttributes has been received from MsgSource.
Goto LMp.26. Goto LMp.33.
LMp.12 Does LSR have a previously received label mapping for FEC
from MsgSource?
If not, goto LMp.14
LMp.13 Does the label previously received from MsgSource match Label
(i.e., the label received in the message)?
If not, goto LMp.8. (See Note 2.)
LMp.14 Is LSR an ingress for FEC? LMp.14 Is LSR an ingress for FEC?
If not, goto LMp.16. If not, goto LMp.16.
LMp.15 Install Label for forwarding/switching use. LMp.15 Install Label for forwarding/switching use.
LMp.16 Record label mapping for FEC with Label and RAttributes has LMp.16 Record label mapping for FEC with Label and RAttributes has
been received from MsgSource. been received from MsgSource.
LMp.17 Iterate through for LMp.25 for each Peer, other than LMp.17 Iterate through LMp.31 for each Peer. (See Note 7).
MsgSource.
LMp.18 Has LSR previously sent a label mapping for FEC to Peer? LMp.18 Has LSR previously sent a label mapping for FEC to Peer for
If not, goto LMp.23. the LSP in question? (See Note 8.)
If so, goto LMp.22.
LMp.19 Are RAttributes in the received label mapping consistent with LMp.19 Is the Downstream Unsolicited Ordered Control Label
those previously sent to Peer? Distribution procedure being used by LSR? If not, goto
If so, goto LMp.24. (See Note 4.) LMp.28.
LMp.20 Execute procedure Prepare_Label_Mapping_Attributes(Peer, FEC, LMp.20 Execute procedure Prepare_Label_Mapping_Attributes(Peer, FEC,
RAttributes, SAttributes, IsPropagating, StoredHopCount). RAttributes, SAttributes, IsPropagating, 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 5.) PrevAdvLabel, SAttributes).
LMp.22 Update record of label mapping for FEC previously sent to Goto LMp.28
LMp.22 Iterate through LMp.27 for each label mapping for FEC
previously sent to Peer.
LMp.23 Are RAttributes in the received label mapping consistent with
those previously sent to Peer?
If so, continue iteration from LMp.22 for next label mapping.
(See Note 9.)
LMp.24 Execute procedure Prepare_Label_Mapping_Attributes(Peer, FEC,
RAttributes, SAttributes, IsPropagating, StoredHopCount).
LMp.25 Execute procedure Send_Message (Peer, Label Mapping, FEC,
PrevAdvLabel, SAttributes). (See Note 10.)
LMp.26 Update record of label mapping for FEC previously sent to
Peer to include the new attributes sent. Peer to include the new attributes sent.
Goto LMp.24.
LMp.23 Perform LSR Label Distribution procedure: LMp.27 End iteration from LMp.22.
LMp.28 Does LSR have any label requests for FEC from Peer marked as
pending?
If not, goto LMp.30.
LMp.29 Perform LSR Label Distribution procedure:
For Downstream Unsolicited Independent Control OR For Downstream Unsolicited Independent Control OR
For Downstream Unsolicited Ordered Control For Downstream Unsolicited Ordered Control
1. Execute procedure 1. Execute procedure
Prepare_Label_Mapping_Attributes(Peer, FEC, Prepare_Label_Mapping_Attributes(Peer, FEC,
RAttributes, SAttributes, IsPropagating, RAttributes, SAttributes, IsPropagating,
UnknownHopCount). UnknownHopCount).
2. Execute procedure Send_Label (Peer, FEC, 2. Execute procedure Send_Label (Peer, FEC,
SAttributes). SAttributes).
If the procedure fails, continue iteration for next If the procedure fails, continue iteration for next
Peer at LMp.17. Peer at LMp.17.
3. Goto LMp.24. 3. If no pending requests exist for Peer goto LMp.30.
(See Note 11.)
For Downstream On Demand Independent Control OR For Downstream On Demand Independent Control OR
For Downstream On Demand Ordered Control For Downstream On Demand Ordered Control
1. Does LSR have a label request for FEC from Peer 1. Iterate through Step 5 for each pending label request
marked as pending? for FEC from Peer marked as pending.
If not, continue iteration for next Peer at LMp.17.
2. Execute procedure 2. Execute procedure
Prepare_Label_Mapping_Attributes(Peer, FEC, Prepare_Label_Mapping_Attributes(Peer, FEC,
RAttributes, SAttributes, IsPropagating, RAttributes, SAttributes, IsPropagating,
UnknownHopCount) UnknownHopCount)
3. Execute procedure Send_Label (Peer, FEC, 3. Execute procedure Send_Label (Peer, FEC,
SAttributes). SAttributes).
If the procedure fails, continue iteration for next If the procedure fails, continue iteration for next
Peer at LMp.17. Peer at LMp.17.
4. Goto LMp.24. 4. Delete record of pending request.
LMp.24 Perform LSR Label Use procedure: 5. End iteration from Step 1.
6. Goto LMp.30.
LMp.30 Perform LSR Label Use procedure:
For Use Immediate OR For Use Immediate OR
For Use If Loop Not Detected For Use If Loop Not Detected
1. Install label received and label sent to Peer for 1. Iterate through Step 3 for each label mapping for FEC
previously sent to Peer.
2. Install label received and label sent to Peer for
forwarding/switching use. forwarding/switching use.
Goto LMp.25.
LMp.25 End iteration from LMp.17. 3. End iteration from Step 1.
LMp.26 DONE. 4. Goto LMp.31.
LMp.31 End iteration from LMp.17.
Go to LMp.33.
LMp.32 Execute procedure Send_Message (MsgSource, Label Release,
FEC, Label).
LMp.33 DONE.
Notes: Notes:
1. If LSR has detected a loop and it has not previously received a 1. If the LSR is merging there should be at most 1 received
mapping for the FEC for the LSP in question. In the non-merging
case there could be multiple received mappings for the FEC for
the LSP in question.
2. If LSR has detected a loop and it has not previously received a
label mapping from MsgSource for the FEC, it simply releases label mapping from MsgSource for the FEC, it simply releases
the label. the label.
2. A mapping with a different label from the same peer would be an 3. Does the Label received in the message match any of the 1 or
attempt to establish multipath label switching, which is not more label mappings identified in the previous step (LMp.4 or
supported in this version of LDP. LMp.9)?
3. If Label is not in forwarding/switching use, LMp.7 has no 4. An unsolicited mapping with a different label from the same
peer would be an attempt to establish multipath label
switching, which is not supported in this version of LDP.
5. If Label is not in forwarding/switching use, LMp.7 has no
effect. effect.
4. The loop detection Path Vector attribute is considered in this 6. If the received label mapping message matched an outstanding
label request in LMp.1, then (by definition) LSR has not
previously received a label mapping for FEC for the LSP in
question. If the LSR is merging upstream labels for the LSP in
question, there should be at most 1 received mapping. In the
non-merging case, there could be multiple received label
mappings for the same FEC, one for each resulting LSP.
7. The LMp.17 iteration includes MsgSource in order to handle the
case where LSR is operating in Downstream Unsolicited ordered
control mode. Ordered control prevents LSR from advertising a
label for FEC until it has received a label mapping from its
next hop (MsgSource) for FEC.
8. If LSR is merging the LSP it may have previously sent label
mappings for the FEC LSP to one or more peers. If LSR is not
merging, it may have sent a label mapping for the LSP in
question to at most one LSR.
9. The loop detection Path Vector attribute is considered in this
check. If the received RAttributes include a Path Vector and check. If the received RAttributes include a Path Vector and
no Path Vector had been previously sent to the Peer, or if the no Path Vector had been previously sent to the Peer, or if the
received Path Vector is inconsistent with the Path Vector received Path Vector is inconsistent with the Path Vector
previously sent to the Peer, then the attributes are considered previously sent to the Peer, then the attributes are considered
to be inconsistent. Note that an LSR is not required to store to be inconsistent. Note that an LSR is not required to store
a received Path Vector after it propagates the Path Vector in a a received Path Vector after it propagates the Path Vector in a
mapping message. If an LSR does not store the Path Vector, it mapping message. If an LSR does not store the Path Vector, it
has no way to check the consistency of a newly received Path has no way to check the consistency of a newly received Path
Vector. This means that whenever such an LSR receives a Vector. This means that whenever such an LSR receives a
mapping message carrying a Path Vector it must always propagate mapping message carrying a Path Vector it must always propagate
the Path Vector. the Path Vector.
5. LMp.19 through LMp.21 deal with a situation that can arise when 10. LMp.22 through LMp.27 deal with a situation that can arise when
the LSR is using independent control and it receives a mapping the LSR is using independent control and it receives a mapping
from the downstream peer after it has sent a mapping to an from the downstream peer after it has sent a mapping to an
upstream peer. In this situation the LSR needs to propagate any upstream peer. In this situation the LSR needs to propagate any
changed attributes, such as Hop Count, upstream. If Loop changed attributes, such as Hop Count, upstream. If Loop
Detection is configured on, the propagated attributes must Detection is configured on, the propagated attributes must
include the Path Vector include the Path Vector
11. An LSR operating in Downstream Unsolicited mode must process
any Label Request messages it receives. If there are pending
label requests, fall through into the Downstream on Demand
procedures in order to satisfy the pending requests.
A.1.3. Receive Label Abort Request A.1.3. Receive Label Abort Request
Summary: Summary:
When an LSR receives a label abort request message from a peer, it When an LSR receives a label abort request message from a peer, it
checks whether it has already responded to the label request in checks whether it has already responded to the label request in
question. If it has, it silently ignores the message. If it has question. If it has, it silently ignores the message. If it has
not, it sends the peer a Label Request Aborted Notification. In not, it sends the peer a Label Request Aborted Notification. In
addition, if it has a label request outstanding for the LSP in addition, if it has a label request outstanding for the LSP in
question to a downstream peer, it sends a Label Abort Request to question to a downstream peer, it sends a Label Abort Request to
skipping to change at page 109, line 6 skipping to change at page 118, line 37
Notes: Notes:
1. If Label is not in forwarding/switching use, NH.2 has no 1. If Label is not in forwarding/switching use, NH.2 has no
effect. effect.
2. If the LSR has a label for the FEC from the New Next Hop, it 2. If the LSR has a label for the FEC from the New Next Hop, it
should behave as if it had just received the label from the New should behave as if it had just received the label from the New
Next Hop. Next Hop.
3. The purpose of the check on label retention mode is to avoid a 3. The purpose of the check on label retention mode is to avoid a
race with steps LMp.10-LMp.11 of the procedure for handling a race with steps LMp.12-LMp.13 of the procedure for handling a
Label Mapping message where the LSR operating in Conservative Label Mapping message where the LSR operating in Conservative
Label retention mode may have released a label mapping received Label retention mode may have released a label mapping received
from the New Next Hop before it detected the FEC next hop had from the New Next Hop before it detected the FEC next hop had
changed. changed.
4. Regardless of the Label Request procedure in use by the LSR, it 4. Regardless of the Label Request procedure in use by the LSR, it
must send a label request if the conditions in NH.8 hold. must send a label request if the conditions in NH.8 hold.
Therefore it executes the Send_Label_Request procedure directly Therefore it executes the Send_Label_Request procedure directly
rather than perform LSR Label Request procedure. rather than perform LSR Label Request procedure.
skipping to change at page 111, line 35 skipping to change at page 121, line 29
to be sent to MsgSource. to be sent to MsgSource.
2. Start timeout. Goto NoNH.3. 2. Start timeout. Goto NoNH.3.
NoNH.3 DONE. NoNH.3 DONE.
A.1.11. Receive Notification / Loop Detected A.1.11. Receive Notification / Loop Detected
Summary: Summary:
When an LSR receives a Loop Detected notification from an LDP peer When an LSR receives a Loop Detected Status Code from an LDP peer
in response to a Label Request message, it behaves as if it had in response to a Label Request message or a Label Mapping message,
received a No Route notification. it behaves as if it had received a No Route notification.
Context: Context:
See "Receive Notification / No Route". See "Receive Notification / No Route".
Algorithm: Algorithm:
See "Receive Notification / No Route" See "Receive Notification / No Route"
Notes:
1. When the Loop Detected notification is in response to a
Label Request message, it arrives in a Status Code TLV in a
Notification message. When it is in response to a Label
Mapping message, it arrives in a Status Code TLV in a Label
Release message.
A.1.12. Receive Notification / Label Resources Available A.1.12. Receive Notification / Label Resources Available
Summary: Summary:
When an LSR receives a Label Resources Available notification from When an LSR receives a Label Resources Available notification from
an LDP peer, it resumes sending label requests to the peer. an LDP peer, it resumes sending label requests to the peer.
Context: Context:
- LSR. The LSR handling the event. - LSR. The LSR handling the event.
skipping to change at page 119, line 43 skipping to change at page 129, line 43
This procedure is the means by which an LSR sends an LDP message of This procedure is the means by which an LSR sends an LDP message of
the specified type to the specified LDP peer. the specified type to the specified LDP peer.
A.2.6. Check_Received_Attributes A.2.6. Check_Received_Attributes
Summary: Summary:
Check the attributes received in a Label Mapping or Label Request Check the attributes received in a Label Mapping or Label Request
message. If the attributes include a Hop Count or Path Vector, message. If the attributes include a Hop Count or Path Vector,
perform a loop detection check. If a loop is detected, send a Loop perform a loop detection check. If a loop is detected, cause a Loop
Detected Notification message to MsgSource. Detected Notification message to be sent to MsgSource.
Parameters: Parameters:
- MsgSource. The LDP peer that sent the message. - MsgSource. The LDP peer that sent the message.
- MsgType. The type of message received.
- RAttributes. The attributes in the message. - RAttributes. The attributes in the message.
Additional Context: Additional Context:
- LSR Id. The unique LSR Id of this LSR. - LSR Id. The unique LSR Id of this LSR.
- Hop Count. The Hop Count, if any, in the received attributes. - Hop Count. The Hop Count, if any, in the received attributes.
- Path Vector. The Path Vector, if any in the received attributes. - Path Vector. The Path Vector, if any in the received attributes.
skipping to change at page 120, line 36 skipping to change at page 130, line 38
CRa.3 Do RAttributes include Path Vector? CRa.3 Do RAttributes include Path Vector?
If not, goto CRa.5. If not, goto CRa.5.
CRa.4 Does Path Vector Include LSR Id? OR CRa.4 Does Path Vector Include LSR Id? OR
Does length of Path Vector exceed Max allowable length? Does length of Path Vector exceed Max allowable length?
If so, goto CRa.6 If so, goto CRa.6
CRa.5 Return No Loop Detected. CRa.5 Return No Loop Detected.
CRa.6 Execute procedure Send_Notification (MsgSource, Loop CRa.6 Is MsgType LabelMapping?
If so, goto CRa.8. (See Note 1.)
CRa.7 Execute procedure Send_Notification (MsgSource, Loop
Detected) Detected)
CRa.7 Return Loop Detected. CRa.8 Return Loop Detected.
CRa.8 DONE CRa.9 DONE
Notes:
1. When the attributes being checked were received in a Label
Mapping message, the LSR sends the Loop Detected notification
in a Status Code TLV in a Label Release message. (See Section
"Receive Label Mapping").
A.2.7. Prepare_Label_Request_Attributes A.2.7. Prepare_Label_Request_Attributes
Summary: Summary:
This procedure is used whenever a Label Request is to be sent to a This procedure is used whenever a Label Request is to be sent to a
Peer to compute the Hop Count and Path Vector, if any, to include Peer to compute the Hop Count and Path Vector, if any, to include
in the message. in the message.
Parameters: Parameters:
 End of changes. 

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