draft-ietf-mpls-rfc3036bis-01.txt   draft-ietf-mpls-rfc3036bis-02.txt 
Network Working Group Loa Andersson Network Working Group Loa Andersson
Internet Draft Ina Minei Internet Draft Ina Minei
Expiration Date: May 2005 Bob Thomas Expiration Date: January 2006 Bob Thomas
Editors Editors
November 2004 July 2005
LDP Specification LDP Specification
draft-ietf-mpls-rfc3036bis-01.txt draft-ietf-mpls-rfc3036bis-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, we certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which we are aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
or will be disclosed, and any of which we become aware will be have been or will be disclosed, and any of which he or she becomes
disclosed, in accordance with RFC 3668. aware will be disclosed, in accordance with Section 6 of BCP 79.
This document is an Internet-Draft and is in full conformance with
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 other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
How to read this document
This section will be removed prior to publication.
This document is produced as part of advancing the LDP specification
to draft standard status. This document contains the original text
of RFC3036, with a few changes that are the result of the experience
gained with the protocol.
Sections that changed from RFC3036 are marked ### in the body of this
document, to facilitate the review process. The marking will be
removed prior to publication.
A list of changes from RFC 3036 is also included. This list will
remain in the final version of the document, but will move towards
the end of the document.
Source of this document Source of this document
###
This document is produced as part of advancing the LDP specification This document is produced as part of advancing the LDP specification
to draft standard status. The LDP specification was originally to draft standard status. The LDP specification was originally
published as RFC 3036 in January 2001. It was produced by the MPLS published as RFC 3036 in January 2001. It was produced by the MPLS
working of the IETF and was jointly authored by Loa Andersson, Paul working of the IETF and was jointly authored by Loa Andersson, Paul
Doolan, Nancy Feldman, Andre Fredette and Bob Thomas. Doolan, Nancy Feldman, Andre Fredette and Bob Thomas.
###
###
Changes from version 00
1. Removed the host address fec and the references to it.
2. Removed the text added in version 00 regarding use of wildcard
fec in label request messages, as it contradicts section 3.4.1.
3. Reversed the change from version 00: In the "receive label
mapping" procedures, removed unnecessary checks in step LMp.29.
The checks are left in place since they make the code more
readable.
Changes from RFC3036
Here is a list of changes from RFC3036
1. Removed the Host Address FEC and references to it, since it is
not used by any implementation.
2. Split the reference list into normative and non-normative
references
3. Removed "MPLS using ATM VP Switching" from the list of
normative references.
4. Clarified the use of the F bit.
5. Added option to allow split horizon when doing ordered control.
6. Clarified the processing of messages with the U-bit set during
the session initialization procedures
7. Clarified the processing of the E-bit during session
initialization procedures.
8. Added case for TLV length too short in the specification for
handling malformed TLVs.
9. In the section describing handling of unknown TLV, removed
reference to inexistent section (errata in original document)
10. In the "receive label request" procedures, if a loop is
detected, changed the procedure to send a notification before
aborting the rest of the processing.
11. In "receive label release" procedures, clarified the behavior
for merge-capable LSRs.
12. In "receive label release" procedures, clarified the behavior
for receipt of an unknown FEC.
13. In note 4 of "Detect Change in FEC Next Hop", modified the text
to reference the correct set of conditions for sending a label
request procedure (typo in the original document)
14. In the procedures for "LSR decides to no longer label switch a
FEC", clarified the fact that the label must not be reused
until a label release is received.
15. In the routine "Prepare_Label_Mapping_Attributes" added a note
regarding the treatment of unknown TLVs according to their U
and F bits.
16. In the address message processing procedures, clarified the
behavior for the case where an LSR receives re-advertisement of
an address previously advertised it, or withdrawal of an
address from an LSR that has not previously advertised that
address.
17. In the routine "Receive Label Mapping" clarified the meaning
of PrevAdvLabel when no label advertisement message has been
sent previously.
18. In the "receive label mapping" procedures, if a loop is
detected, modified the procedure to send a notification before
aborting the rest of the processing.
19. In the "receive label mapping" procedures, corrected step
LMp.10 to handle label mapping messages for additional (non-
merged) LSPs for the FEC.
20. In the routine "Receive Label Abort Request" clarified the
behavior for non-merging LSRs.
21. Added the following items to the section discussing areas for
future study:
o extensions for communicating the maximum transmission unit
o basic peer discovery on NBMA media
o option of shutting down an adjacency
o mechanisms for securing Hello messages
o detection of a stateless fast control plane restart
o o support of "end of LIB" message
o mechanisms for dealing with the case where different LSRs
advertise the same address.
####
Abstract Abstract
The architecture for Multi Protocol Label Switching (MPLS) is The architecture for Multi Protocol Label Switching (MPLS) is
described in RFC 3031. A fundamental concept in MPLS is that two described in RFC 3031. A fundamental concept in MPLS is that two
Label Switching Routers (LSRs) must agree on the meaning of the Label Switching Routers (LSRs) must agree on the meaning of the
labels used to forward traffic between and through them. This common labels used to forward traffic between and through them. This common
understanding is achieved by using a set of procedures, called a understanding is achieved by using a set of procedures, called a
label distribution protocol, by which one LSR informs another of label distribution protocol, by which one LSR informs another of
label bindings it has made. This document defines a set of such label bindings it has made. This document defines a set of such
procedures called LDP (for Label Distribution Protocol) by which LSRs procedures called LDP (for Label Distribution Protocol) by which LSRs
distribute labels to support MPLS forwarding along normally routed distribute labels to support MPLS forwarding along normally routed
paths. paths.
Table of Contents Table of Contents
How to read this document ............................. 1 Source of this document ............................... 1
Source of this document ............................... 2 1 LDP Overview .......................................... 7
Changes from version 00 ............................... 2 1.1 LDP Peers ............................................. 8
Changes from RFC3036 .................................. 2 1.2 LDP Message Exchange .................................. 8
1 LDP Overview .......................................... 9 1.3 LDP Message Structure ................................. 9
1.1 LDP Peers ............................................. 10 1.4 LDP Error Handling .................................... 9
1.2 LDP Message Exchange .................................. 10 1.5 LDP Extensibility and Future Compatibility ............ 9
1.3 LDP Message Structure ................................. 11 1.6 Specification Language ................................ 9
1.4 LDP Error Handling .................................... 11 2 LDP Operation ......................................... 10
1.5 LDP Extensibility and Future Compatibility ............ 11 2.1 FECs .................................................. 10
1.6 Specification Language ................................ 11 2.2 Label Spaces, Identifiers, Sessions and Transport ..... 11
2 LDP Operation ......................................... 12 2.2.1 Label Spaces .......................................... 11
2.1 FECs .................................................. 12 2.2.2 LDP Identifiers ....................................... 11
2.2 Label Spaces, Identifiers, Sessions and Transport ..... 13 2.2.3 LDP Sessions .......................................... 12
2.2.1 Label Spaces .......................................... 13 2.2.4 LDP Transport ......................................... 12
2.2.2 LDP Identifiers ....................................... 14 2.3 LDP Sessions between non-Directly Connected LSRs ...... 12
2.2.3 LDP Sessions .......................................... 14 2.4 LDP Discovery ......................................... 13
2.2.4 LDP Transport ......................................... 14 2.4.1 Basic Discovery Mechanism ............................. 13
2.3 LDP Sessions between non-Directly Connected LSRs ...... 15 2.4.2 Extended Discovery Mechanism .......................... 13
2.4 LDP Discovery ......................................... 15 2.5 Establishing and Maintaining LDP Sessions ............ 14
2.4.1 Basic Discovery Mechanism ............................. 15 2.5.1 LDP Session Establishment ............................. 14
2.4.2 Extended Discovery Mechanism .......................... 16 2.5.2 Transport Connection Establishment .................... 15
2.5 Establishing and Maintaining LDP Sessions ............ 17 2.5.3 Session Initialization ................................ 16
2.5.1 LDP Session Establishment ............................. 17 2.5.4 Initialization State Machine .......................... 19
2.5.2 Transport Connection Establishment .................... 17 2.5.5 Maintaining Hello Adjacencies ......................... 21
2.5.3 Session Initialization ................................ 18 2.5.6 Maintaining LDP Sessions .............................. 21
2.5.4 Initialization State Machine .......................... 21 2.6 Label Distribution and Management ..................... 22
2.5.5 Maintaining Hello Adjacencies ......................... 24 2.6.1 Label Distribution Control Mode ....................... 22
2.5.6 Maintaining LDP Sessions .............................. 24 2.6.1.1 Independent Label Distribution Control ................ 22
2.6 Label Distribution and Management ..................... 25 2.6.1.2 Ordered Label Distribution Control .................... 22
2.6.1 Label Distribution Control Mode ....................... 25 2.6.2 Label Retention Mode .................................. 23
2.6.1.1 Independent Label Distribution Control ................ 25 2.6.2.1 Conservative Label Retention Mode ..................... 23
2.6.1.2 Ordered Label Distribution Control .................... 25 2.6.2.2 Liberal Label Retention Mode .......................... 24
2.6.2 Label Retention Mode .................................. 26 2.6.3 Label Advertisement Mode .............................. 24
2.6.2.1 Conservative Label Retention Mode ..................... 26 2.7 LDP Identifiers and Next Hop Addresses ................ 24
2.6.2.2 Liberal Label Retention Mode .......................... 27 2.8 Loop Detection ........................................ 25
2.6.3 Label Advertisement Mode .............................. 27 2.8.1 Label Request Message ................................. 26
2.7 LDP Identifiers and Next Hop Addresses ................ 27 2.8.2 Label Mapping Message ................................. 27
2.8 Loop Detection ........................................ 28 2.8.3 Discussion ............................................ 29
2.8.1 Label Request Message ................................. 29 2.9 Authenticity and Integrity of LDP Messages ............ 29
2.8.2 Label Mapping Message ................................. 30 2.9.1 TCP MD5 Signature Option .............................. 29
2.8.3 Discussion ............................................ 32 2.9.2 LDP Use of TCP MD5 Signature Option ................... 31
2.9 Authenticity and Integrity of LDP Messages ............ 32 2.10 Label Distribution for Explicitly Routed LSPs ......... 32
2.9.1 TCP MD5 Signature Option .............................. 33 3 Protocol Specification ................................ 32
2.9.2 LDP Use of TCP MD5 Signature Option ................... 34 3.1 LDP PDUs .............................................. 32
2.10 Label Distribution for Explicitly Routed LSPs ......... 35 3.2 LDP Procedures ........................................ 33
3 Protocol Specification ................................ 35 3.3 Type-Length-Value Encoding ............................ 34
3.1 LDP PDUs .............................................. 35 3.4 TLV Encodings for Commonly Used Parameters ............ 35
3.2 LDP Procedures ........................................ 36 3.4.1 FEC TLV ............................................... 36
3.3 Type-Length-Value Encoding ............................ 37 3.4.1.1 FEC Procedures ........................................ 37
3.4 TLV Encodings for Commonly Used Parameters ............ 39 3.4.2 Label TLVs ............................................ 38
3.4.1 FEC TLV ............................................... 39 3.4.2.1 Generic Label TLV ..................................... 38
3.4.1.1 FEC Procedures ........................................ 42 3.4.2.2 ATM Label TLV ......................................... 38
3.4.2 Label TLVs ............................................ 43 3.4.2.3 Frame Relay Label TLV ................................. 39
3.4.2.1 Generic Label TLV ..................................... 43 3.4.3 Address List TLV ...................................... 40
3.4.2.2 ATM Label TLV ......................................... 44 3.4.4 Hop Count TLV ......................................... 40
3.4.2.3 Frame Relay Label TLV ................................. 44 3.4.4.1 Hop Count Procedures .................................. 41
3.4.3 Address List TLV ...................................... 45 3.4.5 Path Vector TLV ....................................... 42
3.4.4 Hop Count TLV ......................................... 46 3.4.5.1 Path Vector Procedures ................................ 43
3.4.4.1 Hop Count Procedures .................................. 46 3.4.5.1.1 Label Request Path Vector ............................. 43
3.4.5 Path Vector TLV ....................................... 48 3.4.5.1.2 Label Mapping Path Vector ............................. 43
3.4.5.1 Path Vector Procedures ................................ 48 3.4.6 Status TLV ............................................ 44
3.4.5.1.1 Label Request Path Vector ............................. 48 3.5 LDP Messages .......................................... 46
3.4.5.1.2 Label Mapping Path Vector ............................. 50 3.5.1 Notification Message .................................. 48
3.4.6 Status TLV ............................................ 51 3.5.1.1 Notification Message Procedures ....................... 49
3.5 LDP Messages .......................................... 53 3.5.1.2 Events Signaled by Notification Messages .............. 49
3.5.1 Notification Message .................................. 55 3.5.1.2.1 Malformed PDU or Message .............................. 50
3.5.1.1 Notification Message Procedures ....................... 56 3.5.1.2.2 Unknown or Malformed TLV .............................. 51
3.5.1.2 Events Signaled by Notification Messages .............. 57 3.5.1.2.3 Session KeepAlive Timer Expiration .................... 51
3.5.1.2.1 Malformed PDU or Message .............................. 57 3.5.1.2.4 Unilateral Session Shutdown ........................... 51
3.5.1.2.2 Unknown or Malformed TLV .............................. 59 3.5.1.2.5 Initialization Message Events ......................... 51
3.5.1.2.3 Session KeepAlive Timer Expiration .................... 60 3.5.1.2.6 Events Resulting From Other Messages .................. 52
3.5.1.2.4 Unilateral Session Shutdown ........................... 61 3.5.1.2.7 Internal Errors ....................................... 52
3.5.1.2.5 Initialization Message Events ......................... 61 3.5.1.2.8 Miscellaneous Events .................................. 52
3.5.1.2.6 Events Resulting From Other Messages .................. 61 3.5.2 Hello Message ......................................... 52
3.5.1.2.7 Internal Errors ....................................... 61 3.5.2.1 Hello Message Procedures .............................. 54
3.5.1.2.8 Miscellaneous Events .................................. 61 3.5.3 Initialization Message ................................ 56
3.5.2 Hello Message ......................................... 61 3.5.3.1 Initialization Message Procedures ..................... 64
3.5.2.1 Hello Message Procedures .............................. 64 3.5.4 KeepAlive Message ..................................... 64
3.5.3 Initialization Message ................................ 65 3.5.4.1 KeepAlive Message Procedures .......................... 64
3.5.3.1 Initialization Message Procedures ..................... 73 3.5.5 Address Message ....................................... 65
3.5.4 KeepAlive Message ..................................... 73 3.5.5.1 Address Message Procedures ............................ 65
3.5.4.1 KeepAlive Message Procedures .......................... 74 3.5.6 Address Withdraw Message .............................. 66
3.5.5 Address Message ....................................... 74 3.5.6.1 Address Withdraw Message Procedures ................... 67
3.5.5.1 Address Message Procedures ............................ 75 3.5.7 Label Mapping Message ................................. 67
3.5.6 Address Withdraw Message .............................. 75 3.5.7.1 Label Mapping Message Procedures ...................... 68
3.5.6.1 Address Withdraw Message Procedures ................... 76 3.5.7.1.1 Independent Control Mapping ........................... 69
3.5.7 Label Mapping Message ................................. 76 3.5.7.1.2 Ordered Control Mapping ............................... 69
3.5.7.1 Label Mapping Message Procedures ...................... 78 3.5.7.1.3 Downstream on Demand Label Advertisement .............. 70
3.5.7.1.1 Independent Control Mapping ........................... 78 3.5.7.1.4 Downstream Unsolicited Label Advertisement ............ 70
3.5.7.1.2 Ordered Control Mapping ............................... 79 3.5.8 Label Request Message ................................. 71
3.5.7.1.3 Downstream on Demand Label Advertisement .............. 79 3.5.8.1 Label Request Message Procedures ...................... 72
3.5.7.1.4 Downstream Unsolicited Label Advertisement ............ 81 3.5.9 Label Abort Request Message ........................... 73
3.5.8 Label Request Message ................................. 81 3.5.9.1 Label Abort Request Message Procedures ................ 74
3.5.8.1 Label Request Message Procedures ...................... 82 3.5.10 Label Withdraw Message ................................ 76
3.5.9 Label Abort Request Message ........................... 84 3.5.10.1 Label Withdraw Message Procedures ..................... 77
3.5.9.1 Label Abort Request Message Procedures ................ 85 3.5.11 Label Release Message ................................. 77
3.5.10 Label Withdraw Message ................................ 86 3.5.11.1 Label Release Message Procedures ...................... 78
3.5.10.1 Label Withdraw Message Procedures ..................... 87 3.6 Messages and TLVs for Extensibility ................... 79
3.5.11 Label Release Message ................................. 89 3.6.1 LDP Vendor-private Extensions ......................... 79
3.5.11.1 Label Release Message Procedures ...................... 90 3.6.1.1 LDP Vendor-private TLVs ............................... 79
3.6 Messages and TLVs for Extensibility ................... 91 3.6.1.2 LDP Vendor-private Messages ........................... 81
3.6.1 LDP Vendor-private Extensions ......................... 91 3.6.2 LDP Experimental Extensions ........................... 82
3.6.1.1 LDP Vendor-private TLVs ............................... 91 3.7 Message Summary ....................................... 82
3.6.1.2 LDP Vendor-private Messages ........................... 94 3.8 TLV Summary ........................................... 83
3.6.2 LDP Experimental Extensions ........................... 95 3.9 Status Code Summary ................................... 84
3.7 Message Summary ....................................... 95 3.10 Well-known Numbers .................................... 85
3.8 TLV Summary ........................................... 96 3.10.1 UDP and TCP Ports ..................................... 85
3.9 Status Code Summary ................................... 97 3.10.2 Implicit NULL Label ................................... 85
3.10 Well-known Numbers .................................... 99 4 IANA Considerations ................................... 85
3.10.1 UDP and TCP Ports ..................................... 99 4.1 Message Type Name Space ............................... 85
3.10.2 Implicit NULL Label ................................... 99 4.2 TLV Type Name Space ................................... 86
4 IANA Considerations ................................... 99 4.3 FEC Type Name Space ................................... 86
4.1 Message Type Name Space ............................... 99 4.4 Status Code Name Space ................................ 87
4.2 TLV Type Name Space ................................... 101 4.5 Experiment ID Name Space .............................. 87
4.3 FEC Type Name Space ................................... 101 5 Security Considerations ............................... 87
4.4 Status Code Name Space ................................ 102 5.1 Spoofing .............................................. 87
4.5 Experiment ID Name Space .............................. 102 5.2 Privacy ............................................... 88
5 Security Considerations ............................... 102 5.3 Denial of Service ..................................... 89
5.1 Spoofing .............................................. 102 6 Areas for Future Study ................................ 90
5.2 Privacy ............................................... 104 7 Changes from RFC3036 .................................. 91
5.3 Denial of Service ..................................... 104 8 Acknowledgments ....................................... 93
6 Areas for Future Study ................................ 106 9 References ............................................ 93
7 Acknowledgments ....................................... 107 9.1 Normative references .................................. 93
8 References ............................................ 108 9.2 Non-normative references .............................. 94
8.1 Normative references .................................. 108 10 Intellectual Property Statement ....................... 95
8.2 Non-normative references .............................. 109 11 Editors' Addresses .................................... 95
9 Intellectual Property Statement ....................... 111 Appendix A LDP Label Distribution Procedures ..................... 96
10 Editors' Addresses .................................... 111 A.1 Handling Label Distribution Events .................... 98
Appendix A LDP Label Distribution Procedures ..................... 113 A.1.1 Receive Label Request ................................. 99
A.1 Handling Label Distribution Events .................... 115 A.1.2 Receive Label Mapping ................................. 102
A.1.1 Receive Label Request ................................. 116 A.1.3 Receive Label Abort Request ........................... 108
A.1.2 Receive Label Mapping ................................. 120 A.1.4 Receive Label Release ................................. 110
A.1.3 Receive Label Abort Request ........................... 130 A.1.5 Receive Label Withdraw ................................ 112
A.1.4 Receive Label Release ................................. 133 A.1.6 Recognize New FEC ..................................... 113
A.1.5 Receive Label Withdraw ................................ 135 A.1.7 Detect Change in FEC Next Hop ......................... 116
A.1.6 Recognize New FEC ..................................... 137 A.1.8 Receive Notification / Label Request Aborted .......... 119
A.1.7 Detect Change in FEC Next Hop ......................... 140 A.1.9 Receive Notification / No Label Resources ............. 119
A.1.8 Receive Notification / Label Request Aborted .......... 143 A.1.10 Receive Notification / No Route ....................... 120
A.1.9 Receive Notification / No Label Resources ............. 144 A.1.11 Receive Notification / Loop Detected .................. 121
A.1.10 Receive Notification / No Route ....................... 144 A.1.12 Receive Notification / Label Resources Available ...... 121
A.1.11 Receive Notification / Loop Detected .................. 146 A.1.13 Detect local label resources have become available .... 122
A.1.12 Receive Notification / Label Resources Available ...... 146 A.1.14 LSR decides to no longer label switch a FEC ........... 123
A.1.13 Detect local label resources have become available .... 147 A.1.15 Timeout of deferred label request ..................... 124
A.1.14 LSR decides to no longer label switch a FEC ........... 148 A.2 Common Label Distribution Procedures .................. 124
A.1.15 Timeout of deferred label request ..................... 149 A.2.1 Send_Label ............................................ 125
A.2 Common Label Distribution Procedures .................. 150 A.2.2 Send_Label_Request .................................... 126
A.2.1 Send_Label ............................................ 150 A.2.3 Send_Label_Withdraw ................................... 127
A.2.2 Send_Label_Request .................................... 151 A.2.4 Send_Notification ..................................... 128
A.2.3 Send_Label_Withdraw ................................... 153 A.2.5 Send_Message .......................................... 128
A.2.4 Send_Notification ..................................... 154 A.2.6 Check_Received_Attributes ............................. 129
A.2.5 Send_Message .......................................... 154 A.2.7 Prepare_Label_Request_Attributes ...................... 130
A.2.6 Check_Received_Attributes ............................. 155 A.2.8 Prepare_Label_Mapping_Attributes ...................... 132
A.2.7 Prepare_Label_Request_Attributes ...................... 156 Full Copyright Statement .............................. 135
A.2.8 Prepare_Label_Mapping_Attributes ...................... 158
Full Copyright Statement .............................. 162
1. LDP Overview 1. LDP Overview
The MPLS architecture [RFC3031] defines a label distribution protocol The MPLS architecture [RFC3031] defines a label distribution protocol
as a set of procedures by which one Label Switched Router (LSR) as a set of procedures by which one Label Switched Router (LSR)
informs another of the meaning of labels used to forward traffic informs another of the meaning of labels used to forward traffic
between and through them. between and through them.
The MPLS architecture does not assume a single label distribution The MPLS architecture does not assume a single label distribution
protocol. In fact, a number of different label distribution proto- protocol. In fact, a number of different label distribution proto-
cols are being standardized. Existing protocols have been extended cols are being standardized. Existing protocols have been extended
so that label distribution can be piggybacked on them. New protocols so that label distribution can be piggybacked on them. New protocols
have also been defined for the explicit purpose of distributing have also been defined for the explicit purpose of distributing
labels. The MPLS architecture discusses some of the considerations labels. The MPLS architecture discusses some of the considerations
when choosing a label distribution protocol for use in particular when choosing a label distribution protocol for use in particular
MPLS applications such as Traffic Engineering [RFC2702]. MPLS applications such as Traffic Engineering [RFC2702].
### New text to reflect that this document builds on 3036
The Label Distribution Protocol (LDP) is a protocol defined for dis- The Label Distribution Protocol (LDP) is a protocol defined for dis-
tributing labels. It was originally published as RFC3036 in January tributing labels. It was originally published as RFC3036 in January
2001. It was produced by the MPLS working of the IETF and was jointly 2001. It was produced by the MPLS working of the IETF and was jointly
authored by Loa Andersson, Paul Doolan, Nancy Feldman, Andre Fredette authored by Loa Andersson, Paul Doolan, Nancy Feldman, Andre Fredette
and Bob Thomas. and Bob Thomas.
###
LDP is a protocol defined for distributing labels. It is the set of LDP is a protocol defined for distributing labels. It is the set of
procedures and messages by which Label Switched Routers (LSRs) estab- procedures and messages by which Label Switched Routers (LSRs) estab-
lish Label Switched Paths (LSPs) through a network by mapping net- lish Label Switched Paths (LSPs) through a network by mapping net-
work-layer routing information directly to data-link layer switched work-layer routing information directly to data-link layer switched
paths. These LSPs may have an endpoint at a directly attached neigh- paths. These LSPs may have an endpoint at a directly attached neigh-
bor (comparable to IP hop-by-hop forwarding), or may have an endpoint bor (comparable to IP hop-by-hop forwarding), or may have an endpoint
at a network egress node, enabling switching via all intermediary at a network egress node, enabling switching via all intermediary
nodes. nodes.
LDP associates a Forwarding Equivalence Class (FEC) [RFC3031] with LDP associates a Forwarding Equivalence Class (FEC) [RFC3031] with
skipping to change at page 12, line 20 skipping to change at page 10, line 20
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
element identifies a set of packets which may be mapped to the corre- element identifies a set of packets which may be mapped to the corre-
sponding LSP. When an LSP is shared by multiple FEC elements, that sponding LSP. When an LSP is shared by multiple FEC elements, that
LSP is terminated at (or before) the node where the FEC elements can LSP is terminated at (or before) the node where the FEC elements can
no longer share the same path. no longer share the same path.
###
Changed the text to the end of the section to reflect removal of the
host address fec. This includes changing the processing rules (remov-
ing the unnecessary ones).
###
This specification defines a single type of FEC element, the "Address This specification defines a single type of FEC element, the "Address
Prefix FEC element". This element is an address prefix of any length Prefix FEC element". This element is an address prefix of any length
from 0 to a full address, inclusive. from 0 to a full address, inclusive.
Additional FEC elements may be defined, as needed, by other specifi- Additional FEC elements may be defined, as needed, by other specifi-
cations. cations.
In the remainder of this section we give the rules to be used for In the remainder of this section we give the rules to be used for
mapping packets to LSPs that have been set up using an Address Prefix mapping packets to LSPs that have been set up using an Address Prefix
FEC element. FEC element.
skipping to change at page 19, line 51 skipping to change at page 17, line 33
ters it wishes to use and a KeepAlive message to signal ters it wishes to use and a KeepAlive message to signal
acceptance of LSR2's parameters. If the parameters are not acceptance of LSR2's parameters. If the parameters are not
acceptable, LSR1 responds by sending a Session acceptable, LSR1 responds by sending a Session
Rejected/Parameters Error Notification message and closing Rejected/Parameters Error Notification message and closing
the TCP connection. the TCP connection.
c. If LSR1 cannot find a matching Hello adjacency it sends a c. If LSR1 cannot find a matching Hello adjacency it sends a
Session Rejected/No Hello Error Notification message and Session Rejected/No Hello Error Notification message and
closes the TCP connection. closes the TCP connection.
d. If LSR1 receives a KeepAlive in response to its d. If LSR1 receives a KeepAlive in response to its Initializa-
Initialization message, the session is operational from tion message, the session is operational from LSR1's point
LSR1's point of view. of view.
e. If LSR1 receives an Error Notification message, LSR2 has e. If LSR1 receives an Error Notification message, LSR2 has
rejected its proposed session and LSR1 closes the TCP con- rejected its proposed session and LSR1 closes the TCP con-
nection. nection.
2. When LSR1 plays the active role: 2. When LSR1 plays the active role:
a. If LSR1 receives an Error Notification message, LSR2 has a. If LSR1 receives an Error Notification message, LSR2 has
rejected its proposed session and LSR1 closes the TCP con- rejected its proposed session and LSR1 closes the TCP con-
nection. nection.
skipping to change at page 20, line 30 skipping to change at page 18, line 12
ters are unacceptable, LSR1 sends a Session Rejected/Param- ters are unacceptable, LSR1 sends a Session Rejected/Param-
eters Error Notification message and closes the connection. eters Error Notification message and closes the connection.
c. If LSR1 receives a KeepAlive message, LSR2 has accepted its c. If LSR1 receives a KeepAlive message, LSR2 has accepted its
proposed session parameters. proposed session parameters.
d. When LSR1 has received both an acceptable Initialization d. When LSR1 has received both an acceptable Initialization
message and a KeepAlive message the session is operational message and a KeepAlive message the session is operational
from LSR1's point of view. from LSR1's point of view.
###
Until the LDP session is established, no other messages Until the LDP session is established, no other messages
except those listed in the procedures above may be except those listed in the procedures above may be
exchanged, and the rules for processing the U-bit in LDP exchanged, and the rules for processing the U-bit in LDP
messages are overridden. messages are overridden.
###
It is possible for a pair of incompatibly configured LSRs that It is possible for a pair of incompatibly configured LSRs that
disagree on session parameters to engage in an endless sequence disagree on session parameters to engage in an endless sequence
of messages as each NAKs the other's Initialization messages with of messages as each NAKs the other's Initialization messages with
Error Notification messages. Error Notification messages.
An LSR must throttle its session setup retry attempts with an An LSR must throttle its session setup retry attempts with an
exponential backoff in situations where Initialization messages exponential backoff in situations where Initialization messages
are being NAK'd. It is also recommended that an LSR detecting are being NAK'd. It is also recommended that an LSR detecting
such a situation take action to notify an operator. such a situation take action to notify an operator.
skipping to change at page 21, line 25 skipping to change at page 19, line 10
ration of the passive LSR will go unnoticed by the active LSR ration of the passive LSR will go unnoticed by the active LSR
without some further action. Section "Hello Message" describes without some further action. Section "Hello Message" describes
an optional mechanism an LSR can use to signal potential LDP an optional mechanism an LSR can use to signal potential LDP
peers that it has been reconfigured. peers that it has been reconfigured.
2.5.4. Initialization State Machine 2.5.4. Initialization State Machine
It is convenient to describe LDP session negotiation behavior in It is convenient to describe LDP session negotiation behavior in
terms of a state machine. We define the LDP state machine to have terms of a state machine. We define the LDP state machine to have
five possible states and present the behavior as a state transition five possible states and present the behavior as a state transition
table and as a state transition diagram. table and as a state transition diagram. Note that a shutdown message
is implemented as a notification message with a status TLV indicating
a fatal error.
Session Initialization State Transition Table Session Initialization State Transition Table
STATE EVENT NEW STATE STATE EVENT NEW STATE
NON EXISTENT Session TCP connection established INITIALIZED NON EXISTENT Session TCP connection established INITIALIZED
established established
INITIALIZED Transmit Initialization msg OPENSENT INITIALIZED Transmit Initialization msg OPENSENT
(Active Role) (Active Role)
skipping to change at page 33, line 52 skipping to change at page 30, line 46
TCP implementations with changing passwords). TCP implementations with changing passwords).
Finally, there is no negotiation for the use of this option in Finally, there is no negotiation for the use of this option in
a connection, rather it is purely a matter of site policy a connection, rather it is purely a matter of site policy
whether or not its connections use the option." whether or not its connections use the option."
"MD5 as a Hashing Algorithm "MD5 as a Hashing Algorithm
Since this memo was first issued (under a different title), the Since this memo was first issued (under a different title), the
MD5 algorithm has been found to be vulnerable to collision MD5 algorithm has been found to be vulnerable to collision
search attacks [Dobb], and is considered by some to be search attacks [Dobb], and is considered by some to be insuffi-
insufficiently strong for this type of application. ciently strong for this type of application.
This memo still specifies the MD5 algorithm, however, since the This memo still specifies the MD5 algorithm, however, since the
option has already been deployed operationally, and there was option has already been deployed operationally, and there was
no "algorithm type" field defined to allow an upgrade using the no "algorithm type" field defined to allow an upgrade using the
same option number. The original document did not specify a same option number. The original document did not specify a
type field since this would require at least one more byte, and type field since this would require at least one more byte, and
it was felt at the time that taking 19 bytes for the complete it was felt at the time that taking 19 bytes for the complete
option (which would probably be padded to 20 bytes in TCP option (which would probably be padded to 20 bytes in TCP
implementations) would be too much of a waste of the already implementations) would be too much of a waste of the already
limited option space. limited option space.
skipping to change at page 38, line 31 skipping to change at page 34, line 41
and the entire message must be ignored; if U is set (=1), the and the entire message must be ignored; if U is set (=1), the
unknown TLV is silently ignored and the rest of the message is unknown TLV is silently ignored and the rest of the message is
processed as if the unknown TLV did not exist. The sections fol- processed as if the unknown TLV did not exist. The sections fol-
lowing that define TLVs specify a value for the U-bit. lowing that define TLVs specify a value for the U-bit.
F bit F bit
Forward unknown TLV bit. This bit applies only when the U bit is Forward unknown TLV bit. This bit applies only when the U bit is
set and the LDP message containing the unknown TLV is to be for- set and the LDP message containing the unknown TLV is to be for-
warded. If F is clear (=0), the unknown TLV is not forwarded with warded. If F is clear (=0), the unknown TLV is not forwarded with
the containing message; if F is set (=1), the unknown TLV is for- the containing message; if F is set (=1), the unknown TLV is for-
warded with the containing message. warded with the containing message. The sections following that
define TLVs specify a value for the F-bit. By setting both the U
### and F bits, a TLV can be propagated as opaque data through nodes
that do not recognize the TLV.
Thus, by setting both the U and F bits, a TLV can be propagated as
opaque data through nodes that do not recognize the TLV.
###
The sections following that define TLVs specify a value for the F-
bit.
Type Type
Encodes how the Value field is to be interpreted. Encodes how the Value field is to be interpreted.
Length Length
Specifies the length of the Value field in octets. Specifies the length of the Value field in octets.
Value Value
Octet string of Length octets that encodes information to be Octet string of Length octets that encodes information to be
interpreted as specified by the Type field. interpreted as specified by the Type field.
skipping to change at page 40, line 39 skipping to change at page 36, line 44
itself is one where standard LDP TLV encoding is not used. itself is one where standard LDP TLV encoding is not used.
The FEC Element value encoding is: The FEC Element value encoding is:
FEC Element Type Value FEC Element Type Value
type name type name
Wildcard 0x01 No value; i.e., 0 value octets; Wildcard 0x01 No value; i.e., 0 value octets;
see below. see below.
Prefix 0x02 See below. Prefix 0x02 See below.
###
Removed reference to host address fec
###
Note that this version of LDP supports the use of multiple FEC Note that this version of LDP supports the use of multiple FEC
Elements per FEC for the Label Mapping message only. The use of Elements per FEC for the Label Mapping message only. The use of
multiple FEC Elements in other messages is not permitted in this multiple FEC Elements in other messages is not permitted in this
version, and is a subject for future study. version, and is a subject for future study.
Wildcard FEC Element Wildcard FEC Element
To be used only in the Label Withdraw and Label Release Mes-
sages. Indicates the withdraw/release is to be applied to all To be used only in the Label Withdraw and Label Release
FECs associated with the label within the following label TLV. Messages. Indicates the withdraw/release is to be applied to
Must be the only FEC Element in the FEC TLV. all FECs associated with the label within the following label
TLV. Must be the only FEC Element in the FEC TLV.
Prefix FEC Element value encoding: Prefix FEC Element value encoding:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (2) | Address Family | PreLen | | Prefix (2) | Address Family | PreLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix | | Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 42, line 31 skipping to change at page 37, line 34
One octet unsigned integer containing the length in bits of the One octet unsigned integer containing the length in bits of the
address prefix that follows. A length of zero indicates a pre- address prefix that follows. A length of zero indicates a pre-
fix that matches all addresses (the default destination); in fix that matches all addresses (the default destination); in
this case the Prefix itself is zero octets). this case the Prefix itself is zero octets).
Prefix Prefix
An address prefix encoded according to the Address Family An address prefix encoded according to the Address Family
field, whose length, in bits, was specified in the PreLen field, whose length, in bits, was specified in the PreLen
field, padded to a byte boundary. field, padded to a byte boundary.
###
Removed Host address FEC element encoding
###
3.4.1.1. FEC Procedures 3.4.1.1. FEC Procedures
If in decoding a FEC TLV an LSR encounters a FEC Element with an If in decoding a FEC TLV an LSR encounters a FEC Element with an
Address Family it does not support, it should stop decoding the FEC Address Family it does not support, it should stop decoding the FEC
TLV, abort processing the message containing the TLV, and send an TLV, abort processing the message containing the TLV, and send an
"Unsupported Address Family" Notification message to its LDP peer "Unsupported Address Family" Notification message to its LDP peer
signaling an error. signaling an error.
If it encounters a FEC Element type it cannot decode, it should stop If it encounters a FEC Element type it cannot decode, it should stop
decoding the FEC TLV, abort processing the message containing the decoding the FEC TLV, abort processing the message containing the
skipping to change at page 48, line 12 skipping to change at page 42, line 35
If Loop Detection is configured, the LSR must follow the procedures If Loop Detection is configured, the LSR must follow the procedures
specified in Section "Loop Detection". specified in Section "Loop Detection".
3.4.5. Path Vector TLV 3.4.5. Path Vector TLV
The Path Vector TLV is used with the Hop Count TLV in Label Request The Path Vector TLV is used with the Hop Count TLV in Label Request
and Label Mapping messages to implement the optional LDP loop detec- and Label Mapping messages to implement the optional LDP loop detec-
tion mechanism. See Section "Loop Detection". Its use in the Label tion mechanism. See Section "Loop Detection". Its use in the Label
Request message records the path of LSRs the request has traversed. Request message records the path of LSRs the request has traversed.
Its use in the Label Mapping message records the path of LSRs a label Its use in the Label Mapping message records the path of LSRs a label
advertisement has traversed to setup an LSP. advertisement has traversed to setup an LSP. Its encoding is:
Its encoding is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Path Vector (0x0104) | Length | |0|0| Path Vector (0x0104) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR Id 1 | | LSR Id 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ ~ ~ ~
skipping to change at page 57, line 18 skipping to change at page 49, line 39
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 ses- Code that indicates a fatal error, it should terminate the LDP ses-
sion immediately by closing the session TCP connection and discard sion immediately by closing the session TCP connection and discard
all state associated with the session, including all label-FEC bind- all state associated with the session, including all label-FEC bind-
ings learned via the session. ings learned via the session.
###
The above statement does not apply to the processing of the shutdown The above statement does not apply to the processing of the shutdown
message in the session initialization procedure. When an LSR receives message in the session initialization procedure. When an LSR receives
a shutdown message during session initialization, it should transmit a shutdown message during session initialization, it should transmit
a shutdown message and then close the transport connection. a shutdown message and then close the transport connection.
###
3.5.1.2. Events Signaled by Notification Messages 3.5.1.2. Events Signaled by Notification Messages
It is useful for descriptive purpose to classify events signaled by It is useful for descriptive purpose to classify events signaled by
Notification Messages into the following categories. Notification Messages into the following categories.
3.5.1.2.1. Malformed PDU or Message 3.5.1.2.1. Malformed PDU or Message
Malformed LDP PDUs or Messages that are part of the LDP Discovery Malformed LDP PDUs or Messages that are part of the LDP Discovery
mechanism are handled by silently discarding them. mechanism are handled by silently discarding them.
skipping to change at page 59, line 13 skipping to change at page 50, line 45
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 is a fatal error signaled by the Bad Message Length Status
Code. Code.
###
- The Message Length is too small, that is, smaller than the - The Message Length is too small, that is, smaller than the
smallest possible value component. This is a fatal error sig- smallest possible value component. This is a fatal error sig-
naled by the Bad Message Length Status Code. naled by the Bad Message Length Status Code.
###
- The message is missing one or more Mandatory Parameters. This - The message is missing one or more Mandatory Parameters. This
is a non-fatal error signalled by the Missing Message Parame- is a non-fatal error signalled by the Missing Message Parame-
ters Status Code. ters 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.
skipping to change at page 59, line 46 skipping to change at page 51, line 26
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 >= 0x8000 (high order bit 1) the TLV is If the TLV type is >= 0x8000 (high order bit 1) the TLV is
silently dropped. silently dropped.
### Remove the following line
Section "Unknown TLV in Known Message Type" elaborates on this
behavior.
Here is why: http://www.rfc-editor.org/cgi-
bin/errataSearch.pl?rfc=3036& The referenced section does not
exist. This behavior is covered in section 3.3.
###
- The TLV Value is malformed. This occurs when the receiver han- - The TLV Value is malformed. This occurs when the receiver han-
dles the TLV but cannot decode the TLV Value. This is inter- dles the TLV but cannot decode the TLV Value. This is inter-
preted as indicative of a bug in either the sending or receiv- preted as indicative of a bug in either the sending or receiv-
ing LSR. It is a fatal error signaled by the Malformed TLV ing 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
This is a fatal error signaled by the KeepAlive Timer Expired Status This is a fatal error signaled by the KeepAlive Timer Expired Status
Code. Code.
skipping to change at page 71, line 35 skipping to change at page 62, line 33
following values are supported in this version of the specifi- following values are supported in this version of the specifi-
cation: cation:
Value Meaning Value Meaning
0 Merge not supported 0 Merge not supported
1 Merge supported 1 Merge supported
Non-merge and merge Frame Relay LSRs may freely interoperate. Non-merge and merge Frame Relay LSRs may freely interoperate.
N, Number of label range components N, Number of label range components Specifies the number of Frame
Specifies the number of Frame Relay Label Range Components Relay Label Range Components included in the TLV.
included in the TLV.
D, VC Directionality D, VC Directionality
A value of 0 specifies bidirectional VC capability, meaning the A value of 0 specifies bidirectional VC capability, meaning the
LSR can support the use of a given DLCI as a label for both LSR can support the use of a given DLCI as a label for both
link directions independently. A value of 1 specifies unidi- link directions independently. A value of 1 specifies unidi-
rectional VC capability, meaning a given DLCI may appear in a rectional VC capability, meaning a given DLCI may appear in a
label mapping for one direction on the link only. When either label mapping for one direction on the link only. When either
or both of the peers specifies unidirectional VC capability, or both of the peers specifies unidirectional VC capability,
both LSRs use unidirectional VC label assignment for the link both LSRs use unidirectional VC label assignment for the link
as follows. The LSRs compare their LDP Identifiers as unsigned as follows. The LSRs compare their LDP Identifiers as unsigned
integers. The LSR with the larger LDP integers. The LSR with the larger LDP Identifier may assign
Identifier may assign only odd-numbered DLCIs in the range as only odd-numbered DLCIs in the range as labels. The system
labels. The system with the smaller LDP Identifier may assign with the smaller LDP Identifier may assign only even-numbered
only even-numbered DLCIs in the range as labels. DLCIs in the range as labels.
Reserved Reserved
This field is reserved. It must be set to zero on transmission This field is reserved. It must be set to zero on transmission
and ignored on receipt. and ignored on receipt.
One or more Frame Relay Label Range Components One or more Frame Relay Label Range Components
A list of Frame Relay Label Range Components which together A list of Frame Relay Label Range Components which together
specify the Label range supported by the transmitting LSR. specify the Label range supported by the transmitting LSR.
A receiving LSR MUST calculate the intersection between the A receiving LSR MUST calculate the intersection between the
skipping to change at page 73, line 14 skipping to change at page 63, line 52
Minimum DLCI Minimum DLCI
This 23-bit field specifies the lower bound of a block of This 23-bit field specifies the lower bound of a block of
Data Link Connection Identifiers (DLCIs) that is supported Data Link Connection Identifiers (DLCIs) that is supported
on the originating switch. The DLCI should be right justi- on the originating switch. The DLCI should be right justi-
fied in this field and unused bits should be set to 0. fied in this field and unused bits should be set to 0.
Maximum DLCI Maximum DLCI
This 23-bit field specifies the upper bound of a block of This 23-bit field specifies the upper bound of a block of
Data Link Connection Identifiers (DLCIs) that is supported Data Link Connection Identifiers (DLCIs) that is supported
on the originating switch. The DLCI should be right justi- on the originating switch. The DLCI should be right
fied in this field and unused bits should be set to 0. justified in this field and unused bits should be set to 0.
Note that there is no Generic Session Parameters TLV for sessions Note that there is no Generic Session Parameters TLV for sessions
which advertise Generic Labels. which advertise Generic Labels.
3.5.3.1. Initialization Message Procedures 3.5.3.1. Initialization Message Procedures
See Section "LDP Session Establishment" and particularly Section See Section "LDP Session Establishment" and particularly Section
"Session Initialization" for general procedures for handling the Ini- "Session Initialization" for general procedures for handling the Ini-
tialization Message. tialization Message.
skipping to change at page 75, line 16 skipping to change at page 65, line 49
An LSR that receives an Address Message message uses the addresses it An LSR that receives an Address Message message uses the addresses it
learns to maintain a database for mapping between peer LDP Identi- learns to maintain a database for mapping between peer LDP Identi-
fiers and next hop addresses; see Section "LDP Identifiers and Next fiers and next hop addresses; see Section "LDP Identifiers and Next
Hop Addresses". Hop Addresses".
When a new LDP session is initialized and before sending Label Map- When a new LDP session is initialized and before sending Label Map-
ping or Label Request messages an LSR should advertise its interface ping or Label Request messages an LSR should advertise its interface
addresses with one or more Address messages. addresses with one or more Address messages.
Whenever an LSR "activates" a new interface address, it should adver- Whenever an LSR "activates" a new interface address, it should
tise 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 If an LSR does not support the Address Family specified in the
Address List TLV, it should send an "Unsupported Address Family" Address List TLV, it should send an "Unsupported Address Family"
Notification to its LDP signalling an error and abort processing the Notification to its LDP signalling an error and abort processing the
message. message.
###
An LSR may re-advertise an address (A) that it has previously adver- An LSR may re-advertise an address (A) that it has previously adver-
tised without explicitly withdrawing the address. If the receiver tised without explicitly withdrawing the address. If the receiver
already has address binding (LSR, A) it should take no further already has address binding (LSR, A) it should take no further
action. action.
An LSR may withdraw an address (A) without having previously adver- An LSR may withdraw an address (A) without having previously adver-
tised it. If the receiver has no address binding (LSR, A), it should tised it. If the receiver has no address binding (LSR, A), it should
take no further action. take no further action.
###
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 76, line 19 skipping to change at page 66, line 50
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters | | Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID Message ID
32-bit value used to identify this message. 32-bit value used to identify this message.
Address list TLV Address list TLV
The list of interface addresses being withdrawn by the sending The list of interface addresses being withdrawn by the sending
LSR. The encoding for the Address list TLV is specified in Sec- LSR. The encoding for the Address list TLV is specified in
tion "Address List TLV". Section "Address List TLV".
Optional Parameters Optional Parameters
No optional parameters are defined for the Address Withdraw mes- No optional parameters are defined for the Address Withdraw mes-
sage. sage.
3.5.6.1. Address Withdraw Message Procedures 3.5.6.1. Address Withdraw Message Procedures
See Section "Address Message Procedures" See Section "Address Message Procedures"
3.5.7. Label Mapping Message 3.5.7. Label Mapping Message
skipping to change at page 78, line 35 skipping to change at page 68, line 43
The Mapping message is used by an LSR to distribute a label mapping The Mapping message is used by an LSR to distribute a label mapping
for a FEC to an LDP peer. If an LSR distributes a mapping for a FEC for a FEC to an LDP peer. If an LSR distributes a mapping for a FEC
to multiple LDP peers, it is a local matter whether it maps a single to multiple LDP peers, it is a local matter whether it maps a single
label to the FEC, and distributes that mapping to all its peers, or label to the FEC, and distributes that mapping to all its peers, or
whether it uses a different mapping for each of its peers. whether it uses a different mapping for each of its peers.
An LSR is responsible for the consistency of the label mappings it An LSR is responsible for the consistency of the label mappings it
has distributed, and that its peers have these mappings. has distributed, and that its peers have these mappings.
An LSR receiving a Label Mapping message from a downstream LSR for a An LSR receiving a Label Mapping message from a downstream LSR for a
Prefix ### Removed mention of the Host Address FEC Element ### should Prefix should not use the label for forwarding unless its routing ta-
not use the label for forwarding unless its routing table contains an ble contains an entry that exactly matches the FEC Element.
entry that exactly matches the FEC Element.
See Appendix A "LDP Label Distribution Procedures" for more details. See Appendix A "LDP Label Distribution Procedures" for more details.
3.5.7.1.1. Independent Control Mapping 3.5.7.1.1. Independent Control Mapping
If an LSR is configured for independent control, a mapping message is If an LSR is configured for independent control, a mapping message is
transmitted by the LSR upon any of the following conditions: transmitted by the LSR upon any of the following conditions:
1. The LSR recognizes a new FEC via the forwarding table, and the 1. The LSR recognizes a new FEC via the forwarding table, and the
label advertisement mode is Downstream Unsolicited advertise- label advertisement mode is Downstream Unsolicited advertise-
skipping to change at page 83, line 34 skipping to change at page 72, line 44
each upstream peer requesting a label, it must send a separate each upstream peer requesting a label, it must send a separate
Label Request for each such peer. A consequence of this is Label Request for each such peer. A consequence of this is
that a non-merge LSR may have multiple Label Request messages that a non-merge LSR may have multiple Label Request messages
for a given FEC outstanding at the same time. for a given FEC outstanding at the same time.
The receiving LSR should respond to a Label Request message with a The receiving LSR should respond to a Label Request message with a
Label Mapping for the requested label or with a Notification message Label Mapping for the requested label or with a Notification message
indicating why it cannot satisfy the request. indicating why it cannot satisfy the request.
When the FEC for which a label is requested is a Prefix FEC Element, When the FEC for which a label is requested is a Prefix FEC Element,
### Removed mention of the host address fec ### the receiving LSR the receiving LSR uses its routing table to determine its response.
uses its routing table to determine its response. Unless its routing Unless its routing table includes an entry that exactly matches the
table includes an entry that exactly matches the requested Prefix, requested Prefix, the LSR must respond with a No Route Notification
the LSR must respond with a No Route Notification message. message.
The message ID of the Label Request message serves as an identifier The message ID of the Label Request message serves as an identifier
for the Label Request transaction. When the receiving LSR responds for the Label Request transaction. When the receiving LSR responds
with a Label Mapping message, the mapping message must include a with a Label Mapping message, the mapping message must include a
Label Request/Returned Message ID TLV optional parameter which Label Request/Returned Message ID TLV optional parameter which
includes the message ID of the Label Request message. Note that includes the message ID of the Label Request message. Note that
since LSRs use Label Request message IDs as transaction identifiers since LSRs use Label Request message IDs as transaction identifiers
an LSR should not reuse the message ID of a Label Request message an LSR should not reuse the message ID of a Label Request message
until the corresponding transaction completes. until the corresponding transaction completes.
skipping to change at page 97, line 14 skipping to change at page 84, line 12
Experimental 0x3F00- "LDP Experimental Extensions" Experimental 0x3F00- "LDP Experimental Extensions"
0x3FFF 0x3FFF
3.9. Status Code Summary 3.9. Status Code Summary
The following are the Status Codes defined in this version of the The following are the Status Codes defined in this version of the
protocol. protocol.
The "E" column is the required setting of the Status Code E-bit; the The "E" column is the required setting of the Status Code E-bit; the
"Status Data" column is the value of the 30-bit Status Data field in "Status Data" column is the value of the 30-bit Status Data field in
the Status Code TLV. the Status Code TLV. Note that the setting of the Status Code F-bit
is at the discretion of the LSR originating the Status TLV.
Note that the setting of the Status Code F-bit is at the discretion
of the LSR originating the Status TLV.
Status Code E Status Data Section Title Status Code E Status Data Section Title
Success 0 0x00000000 "Status TLV" Success 0 0x00000000 "Status TLV"
Bad LDP Identifier 1 0x00000001 "Events Signaled by ..." Bad LDP Identifier 1 0x00000001 "Events Signaled by ..."
Bad Protocol Version 1 0x00000002 "Events Signaled by ..." Bad Protocol Version 1 0x00000002 "Events Signaled by ..."
Bad PDU Length 1 0x00000003 "Events Signaled by ..." Bad PDU Length 1 0x00000003 "Events Signaled by ..."
Unknown Message Type 0 0x00000004 "Events Signaled by ..." Unknown Message Type 0 0x00000004 "Events Signaled by ..."
Bad Message Length 1 0x00000005 "Events Signaled by ..." Bad Message Length 1 0x00000005 "Events Signaled by ..."
Unknown TLV 0 0x00000006 "Events Signaled by ..." Unknown TLV 0 0x00000006 "Events Signaled by ..."
skipping to change at page 106, line 31 skipping to change at page 90, line 40
- LDP support for CoS is not specified in this version. CoS sup- - LDP support for CoS is not specified in this version. CoS sup-
port may be addressed in a future version. port may be addressed in a future version.
- LDP support for multicast is not specified in this version. - LDP support for multicast is not specified in this version.
Multicast support may be addressed in a future version. Multicast support may be addressed in a future version.
- LDP support for multipath label switching is not specified in - LDP support for multipath label switching is not specified in
this version. Multipath support may be addressed in a future this version. Multipath support may be addressed in a future
version. version.
### - LDP support for signalling the maximum transmission unit is not
specified in this version. It is discussed in the experimental
- LDP support for signalling the maximum transmission unit is document [LDP-MTU].
not specified in this version. It is discussed in the experi-
mental document [LDP-MTU].
###
### - The current specification does not address basic peer dis- - The current specification does not address basic peer discovery
covery on non-broadcast multi access (NBMA) media. The solution on non-broadcast multi access (NBMA) media. The solution avail-
available in the current specification is to use extended peer able in the current specification is to use extended peer dis-
discovery in such setups. The issue of defining a mechanism covery in such setups. The issue of defining a mechanism seman-
semantically similar to basic discovery (1 hop limit, bind the tically similar to basic discovery (1 hop limit, bind the hello
hello adjacency to an interface) that uses a preconfigured adjacency to an interface) that uses a preconfigured neighbor
neighbor addresses, is left for further study. ### addresses, is left for further study.
### - The current specification does not support shutting down an - The current specification does not support shutting down an
adjacency. The motivation for doing it, and the mechanisms for adjacency. The motivation for doing it, and the mechanisms for
achieving it are left for further study. ### achieving it are left for further study.
### - The current specification does not include a method for
securing Hello messages, to detect spoofing of Hellos. The sce-
narios where this is necessary, as well as the mechanism for
achieving it are left for future study. ###
### - The current specification does not have the ability to - The current specification does not include a method for secur-
detect a stateless fast control plane restart. The method for ing Hello messages, to detect spoofing of Hellos. The scenarios
achieving this, possibly through an "incarnation/instance" num- where this is necessary, as well as the mechanism for achieving
ber carried in the Hello message is left for future study. ### it are left for future study.
### - The current specification does not support an "end of LIB" - The current specification does not have the ability to detect a
message, analogous to BGP's end of RIB message which an LDP LSR stateless fast control plane restart. The method for achieving
this, possibly through an "incarnation/instance" number carried
in the Hello message is left for future study.
- The current specification does not support an "end of LIB" mes-
sage, analogous to BGP's end of RIB message which an LDP LSR
(operating in DU mode) would use following session establish- (operating in DU mode) would use following session establish-
ment. The discussion on the need for such a mechanism and its ment. The discussion on the need for such a mechanism and its
implementation are left for future study. ### implementation are left for future study.
### - The current specification does not deal with situations - The current specification does not deal with situations where
where different LSRs advertise the same address. Such situa- different LSRs advertise the same address. Such situations
tions typically occur as the result of configuration errors, typically occur as the result of configuration errors, and the
and the goal in this case is to provide the LSRs advertising goal in this case is to provide the LSRs advertising the same
the same address with enough information to enable operators to address with enough information to enable operators to take
take corrective action. The specification of this mechanism is corrective action. The specification of this mechanism is left
left for a separate document. ### for a separate document.
7. Acknowledgments 7. Changes from RFC3036
### Here is a list of changes from RFC3036
1. Removed the Host Address FEC and references to it, since it is
not used by any implementation.
2. Split the reference list into normative and non-normative ref-
erences
3. Removed "MPLS using ATM VP Switching" from the list of norma-
tive references.
4. Clarified the use of the F bit.
5. Added option to allow split horizon when doing ordered control.
6. Clarified the processing of messages with the U-bit set during
the session initialization procedures
7. Clarified the processing of the E-bit during session initial-
ization procedures.
8. Added text explaining that the shutdown message in the state
transition diagram is implemented as as a notification message
with a status TLV indicating a fatal error.
9. Added case for TLV length too short in the specification for
handling malformed TLVs.
10. In the section describing handling of unknown TLV, removed ref-
erence to inexistent section (errata in original document)
11. In the "receive label request" procedures, if a loop is
detected, changed the procedure to send a notification before
aborting the rest of the processing.
12. In "receive label release" procedures, clarified the behavior
for merge-capable LSRs.
13. In "receive label release" procedures, clarified the behavior
for receipt of an unknown FEC.
14. In note 4 of "Detect Change in FEC Next Hop", modified the text
to reference the correct set of conditions for sending a label
request procedure (typo in the original document).
15. In the procedures for "LSR decides to no longer label switch a
FEC", clarified the fact that the label must not be reused
until a label release is received.
16. In the routine "Prepare_Label_Mapping_Attributes" added a note
regarding the treatment of unknown TLVs according to their U
and F bits.
17. In the address message processing procedures, clarified the
behavior for the case where an LSR receives re-advertisement of
an address previously advertised it, or withdrawal of an
address from an LSR that has not previously advertised that
address.
18. In the routine "Receive Label Mapping" clarified the meaning of
PrevAdvLabel when no label advertisement message has been sent
previously.
19. In the "receive label mapping" procedures, if a loop is
detected, modified the procedure to send a notification before
aborting the rest of the processing.
20. In the "receive label mapping" procedures, corrected step
LMp.10 to handle label mapping messages for additional (non-
merged) LSPs for the FEC.
21. In the routine "Receive Label Abort Request" clarified the
behavior for non-merging LSRs.
22. Added the following items to the section discussing areas for
future study:
o extensions for communicating the maximum transmission unit
o basic peer discovery on NBMA media
o option of shutting down an adjacency
o mechanisms for securing Hello messages
o detection of a stateless fast control plane restart
o support of "end of LIB" message
o mechanisms for dealing with the case where different LSRs advertise
the same address.
8. Acknowledgments
This document was originally published as RFC 3036 in January 2001. This document was originally published as RFC 3036 in January 2001.
It was produced by the MPLS working of the IETF and was jointly It was produced by the MPLS working of the IETF and was jointly
authored by Loa Andersson, Paul Doolan, Nancy Feldman, Andre Fredette authored by Loa Andersson, Paul Doolan, Nancy Feldman, Andre Fredette
and Bob Thomas. and Bob Thomas.
The ideas and text in RFC3036 were collected from a number of The ideas and text in RFC3036 were collected from a number of
sources. We would like to thank Rick Boivie, Ross Callon, Alex sources. We would like to thank Rick Boivie, Ross Callon, Alex
Conta, Eric Gray, Yoshihiro Ohba, Eric Rosen, Bernard Suter, Yakov Conta, Eric Gray, Yoshihiro Ohba, Eric Rosen, Bernard Suter, Yakov
Rekhter, and Arun Viswanathan for their input for RFC3036. Rekhter, and Arun Viswanathan for their input for RFC3036.
The editors would like to thank Eric Gray for his insight and input The editors would like to thank Eric Gray for his insight and input
to the current document. to the current document.
In addition, the editors would like to thank the members of the mpls In addition, the editors would like to thank the members of the mpls
working group for their ideas and the support they have given to this working group for their ideas and the support they have given to this
document, and in particular to Eric Rosen, Luca Martini, Markus Jork, document, and in particular to Eric Rosen, Luca Martini, Markus Jork,
Mark Duffy, Vach Kompella, Kishore Tiruveedhula. Rama Ramakrishnan Mark Duffy, Vach Kompella, Kishore Tiruveedhula. Rama Ramakrishnan
and Nick Weeds. and Nick Weeds.
### 9. References
8. References
8.1. Normative references
### Remove the following reference, it never went past the -00 stage.
[ATM-VP] N. Feldman, B. Jamoussi, S. Komandur, A, 9.1. Normative references
Viswanathan, T Worster, "MPLS using ATM VP Switching",
Work in Progress. ###
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321,
April 1992. April 1992.
[RFC1483] Heinanen, J., "Multiprotocol Encapsulation over ATM Adap- [RFC1483] Heinanen, J., "Multiprotocol Encapsulation over ATM Adap-
tation Layer 5", RFC 1483, July 1993. tation Layer 5", RFC 1483, July 1993.
skipping to change at page 109, line 12 skipping to change at page 94, line 16
ing on Frame Relay Networks Specification", RFC 3034, ing on Frame Relay Networks Specification", RFC 3034,
January 2001. January 2001.
[RFC3035] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., [RFC3035] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y.,
Rosen, E., Swallow, G. and P. Doolan, "MPLS using LDP and Rosen, E., Swallow, G. and P. Doolan, "MPLS using LDP and
ATM VC Switching", RFC 3035, January 2001. ATM VC Switching", RFC 3035, January 2001.
[RFC3037] Thomas, B. and E. Gray, "LDP Applicability", RFC 3037, [RFC3037] Thomas, B. and E. Gray, "LDP Applicability", RFC 3037,
January 2001. January 2001.
8.2. Non-normative references 9.2. Non-normative references
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Jamin, "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 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP
MD5 Signature Option", RFC 2385, August 1998. MD5 Signature Option", RFC 2385, August 1998.
[CRLDP] L. Andersson, A. Fredette, B. Jamoussi, R. Callon, P. [CRLDP] L. Andersson, A. Fredette, B. Jamoussi, R. Callon, P.
Doolan, N. Feldman, E. Gray, J. Halpern, J. Heinanen T. E. Kilty, A. Doolan, N. Feldman, E. Gray, J. Halpern, J. Heinanen T. E. Kilty, A.
skipping to change at page 111, line 5 skipping to change at page 95, line 5
nalling Extensions for the Label Distribution Protocol", draft-ietf- nalling Extensions for the Label Distribution Protocol", draft-ietf-
mpls-ldp-mtu-extensions-03.txt, April 2004. mpls-ldp-mtu-extensions-03.txt, April 2004.
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995. (BGP-4)", RFC 1771, March 1995.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J.
McManus, "Requirements for Traffic Engineering over MPLS", RFC 2702, McManus, "Requirements for Traffic Engineering over MPLS", RFC 2702,
September 1999. September 1999.
9. Intellectual Property Statement 10. Intellectual Property Statement
###
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 111, line 31 skipping to change at page 95, line 29
proprietary rights by implementers or users of this specification can proprietary rights by implementers or users of this specification can
be obtained from the IETF on-line IPR repository at be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
### 11. Editors' Addresses
10. Editors' Addresses
###
Loa Andersson Loa Andersson
Acreo AB Acreo AB
Isafjordsgatan 22 Isafjordsgatan 22
Kista, Sweden Kista, Sweden
email: loa.andersson@acreo.se email: loa.andersson@acreo.se
loa@pi.se loa@pi.se
Ina Minei Ina Minei
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
email: ina@juniper.net email: ina@juniper.net
Bob Thomas Bob Thomas
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Ave 1414 Massachusetts Ave
Boxborough, MA 01719 Boxborough, MA 01719
email: rhthomas@cisco.com email: rhthomas@cisco.com
###
Appendix A. LDP Label Distribution Procedures Appendix A. LDP Label Distribution Procedures
This section specifies label distribution behavior in terms of LSR This section specifies label distribution behavior in terms of LSR
response to the following events: response to the following events:
- Receive Label Request Message; - Receive Label Request Message;
- Receive Label Mapping Message; - Receive Label Mapping Message;
- Receive Label Abort Request Message; - Receive Label Abort Request Message;
- Receive Label Release Message; - Receive Label Release Message;
- Receive Label Withdraw Message; - Receive Label Withdraw Message;
skipping to change at page 117, line 10 skipping to change at page 100, line 10
sage, if any, propagated to FEC Next Hop. sage, 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,
LabelRequest, RAttributes). LabelRequest, RAttributes).
If Loop Detected, goto LRq.4. If Loop Detected, goto LRq.4.
###
In the "goto" statement above, changed to LRq.4 from LRq.13,
see mpls archive june 01 "error in RFC33036"
###
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).
Goto LRq.13 Goto LRq.13
skipping to change at page 121, line 18 skipping to change at page 103, line 18
- LSR. The LSR handling the event. - LSR. The LSR handling the event.
- MsgSource. The LDP peer that sent the message. - MsgSource. The LDP peer that sent the message.
- FEC. The FEC specified in the message. - FEC. The FEC specified in the message.
- Label. The label specified in the message. - Label. The label specified in the message.
- PrevAdvLabel. The label for FEC, if any, previously advertised - PrevAdvLabel. The label for FEC, if any, previously advertised
to an upstream peer. to an upstream peer. Assuming no label was previously adver-
###
Add the following text: Assuming no label was previously adver-
tised, this is the same label as the one in the Label Mapping tised, this is the same label as the one in the Label Mapping
Message being processed. Message being processed.
THis is the reason why: This would have to be done both to
allow for later re-use of the value (in the event that a later
Label Mapping is received - possibly with a different hop-count
or path vector) and so that it can be immediately re-used in
step LMp.25 (if needed). The procedure, as it currently is,
seems to assume that this has been done apriori (before step
LMp.18).
###
- StoredHopCount. The hop count previously recorded for the FEC. - StoredHopCount. The hop count previously recorded for the FEC.
- 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:
skipping to change at page 122, line 17 skipping to change at page 104, line 4
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 LMp.4 Does the LSR have a previously received label mapping for
FEC from MsgSource? (See Note 1.) FEC from MsgSource? (See Note 1.)
If not, goto LMp.8. (See Note 2.) If not, goto LMp.8. (See Note 2.)
LMp.5 Does the label previously received from MsgSource match LMp.5 Does the label previously received from MsgSource match
Label (i.e., the label received in the message)? Label (i.e., the label received in the message)?
(See Note 3.) (See Note 3.)
If not, goto LMp.8. (See Note 4.) If not, goto LMp.8. (See Note 4.)
LMp.6 Delete matching label mapping for FEC previously LMp.6 Delete matching label mapping for FEC previously
received from MsgSource. received from MsgSource.
LMp.7 Remove Label from forwarding/switching use. (See Note 5.) LMp.7 Remove Label from forwarding/switching use. (See Note 5.)
###
Remove this goto: Goto LMp.33.
###
LMp.8 Execute procedure Send_Message (MsgSource, Label Release, LMp.8 Execute procedure Send_Message (MsgSource, Label Release,
FEC, Label, Loop Detected Status code). Goto LMp.33. FEC, Label, Loop Detected Status code). Goto LMp.33.
LMp.9 Does LSR have a previously received label mapping for FEC LMp.9 Does LSR have a previously received label mapping for FEC
from MsgSource for the LSP in question? (See Note 6.) from MsgSource for the LSP in question? (See Note 6.)
If not, goto LMp.11. If not, goto LMp.11.
LMp.10 Does the label previously received from MsgSource match LMp.10 Does the label previously received from MsgSource match
Label (i.e., the label received in the message)? Label (i.e., the label received in the message)?
(See Note 3.) (See Note 3.)
###
Add:
OR OR
Is the received label mapping in response to a previously Is the received label mapping in response to a previously
outstanding label request sent to MsgSource? (See Note 12). outstanding label request sent to MsgSource? (See Note 12).
If so, goto LMp.11. If so, goto LMp.11.
LMp.10a Is LSR operating in Downstream Unsolicited mode with Liberal LMp.10a Is LSR operating in Downstream Unsolicited mode with Liberal
Label retention? Label retention?
If not, goto LMp.32. (See Note 4.) If not, goto LMp.32. (See Note 4.)
###
LMp.11 Determine the Next Hop for FEC. LMp.11 Determine the Next Hop for FEC.
LMp.12 Is MsgSource the Next Hop for FEC? LMp.12 Is MsgSource the Next Hop for FEC?
If so, goto LMp.14. If so, goto LMp.14.
LMp.13 Perform LSR Label Release procedure: LMp.13 Perform LSR Label Release procedure:
For Conservative Label retention: For Conservative Label retention:
1. Goto LMp.32. 1. Goto LMp.32.
skipping to change at page 124, line 7 skipping to change at page 105, line 13
has been received from MsgSource. has been received from MsgSource.
LMp.17 Iterate through LMp.31 for each Peer. (See Note 7). LMp.17 Iterate through LMp.31 for each Peer. (See Note 7).
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 the LSP in question? (See Note 8.) for the LSP in question? (See Note 8.)
If so, goto LMp.22. If so, goto LMp.22.
LMp.19 Is the Downstream Unsolicited Ordered Control Label LMp.19 Is the Downstream Unsolicited Ordered Control Label
Distribution procedure being used by LSR? Distribution procedure being used by LSR?
If not, goto LMp.28.
###
(formatting only) If not, goto LMp.28.
###
LMp.20 Execute procedure Prepare_Label_Mapping_Attributes(Peer, LMp.20 Execute procedure Prepare_Label_Mapping_Attributes(Peer,
FEC, RAttributes, SAttributes, IsPropagating, FEC, RAttributes, SAttributes, IsPropagating,
StoredHopCount). StoredHopCount).
LMp.21 Execute procedure Send_Message (Peer, Label Mapping, FEC, LMp.21 Execute procedure Send_Message (Peer, Label Mapping, FEC,
PrevAdvLabel, SAttributes). (See note 9.) PrevAdvLabel, SAttributes). (See note 13.)
Goto LMp.28 Goto LMp.28
LMp.22 Iterate through LMp.27 for each label mapping for FEC LMp.22 Iterate through LMp.27 for each label mapping for FEC
previously sent to Peer. previously sent to Peer.
LMp.23 Are RAttributes in the received label mapping consistent LMp.23 Are RAttributes in the received label mapping consistent
with those previously sent to Peer? with those previously sent to Peer?
If so, continue iteration from LMp.22 for next label If so, continue iteration from LMp.22 for next label
mapping. (See Note 9.) mapping. (See Note 9.)
skipping to change at page 126, line 12 skipping to change at page 106, line 16
RAttributes, SAttributes, IsPropagating, RAttributes, SAttributes, IsPropagating,
UnknownHopCount). UnknownHopCount).
2. Execute procedure Send_Label (Peer, FEC, SAttributes). 2. Execute procedure Send_Label (Peer, FEC, SAttributes).
If the procedure fails, continue iteration for If the procedure fails, continue iteration for
next Peer at LMp.17. next Peer at LMp.17.
3. If no pending requests exist for Peer goto LMp.30. 3. If no pending requests exist for Peer goto LMp.30.
(See Note 11.) (See Note 11.)
###
Remove the following two lines, since the behavior is the same.
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. Iterate through Step 5 for each pending label 1. Iterate through Step 5 for each pending label
request for FEC from Peer marked as pending. request for FEC from Peer marked as pending.
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).
skipping to change at page 128, line 51 skipping to change at page 108, line 5
case where LSR is operating in Downstream Unsolicited ordered case where LSR is operating in Downstream Unsolicited ordered
control mode. Ordered control prevents LSR from advertising a control mode. Ordered control prevents LSR from advertising a
label for FEC until it has received a label mapping from its label for FEC until it has received a label mapping from its
next hop (MsgSource) for FEC. next hop (MsgSource) for FEC.
8. If LSR is merging the LSP it may have previously sent label 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 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 ques- merging, it may have sent a label mapping for the LSP in ques-
tion to at most one LSR. tion to at most one LSR.
###
9. An LSR operating in ordered control mode may choose to skip
at this stage the peer from which it received the advertise-
ment that caused it to generate the label-map message. Doing
so will in effect provide a form of split-horizon.
###
9. The loop detection Path Vector attribute is considered in this 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 pre- received Path Vector is inconsistent with the Path Vector pre-
viously sent to the Peer, then the attributes are considered viously 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 received Path Vector after it propagates the Path Vector in
a mapping message. If an LSR does not store the Path Vector, a mapping message. If an LSR does not store the Path Vector,
it has no way to check the consistency of a newly received it has no way to check the consistency of a newly received
Path Vector. This means that whenever such an LSR receives a Path Vector. This means that whenever such an LSR receives a
skipping to change at page 130, line 30 skipping to change at page 108, line 31
to an upstream peer. In this situation the LSR needs to prop- to an upstream peer. In this situation the LSR needs to prop-
agate any changed attributes, such as Hop Count, upstream. If agate any changed attributes, such as Hop Count, upstream. If
Loop Detection is configured on, the propagated attributes Loop Detection is configured on, the propagated attributes
must include the Path Vector must include the Path Vector
11. An LSR operating in Downstream Unsolicited mode must process 11. An LSR operating in Downstream Unsolicited mode must process
any Label Request messages it receives. If there are pending any Label Request messages it receives. If there are pending
label requests, fall through into the Downstream on Demand label requests, fall through into the Downstream on Demand
procedures in order to satisfy the pending requests. procedures in order to satisfy the pending requests.
###
12. As determined by step LMp.1. 12. As determined by step LMp.1.
### 13. An LSR operating in ordered control mode may choose to skip at
this stage the peer from which it received the advertisement
that caused it to generate the label-map message. Doing so
will in effect provide a form of split-horizon.
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
skipping to change at page 131, line 43 skipping to change at page 109, line 43
LAbR.5 Does LSR have a label mapping for FEC? LAbR.5 Does LSR have a label mapping for FEC?
If not, goto LAbR.11 If not, goto LAbR.11
LAbR.6 Generate Event: Received Label Release Message for FEC LAbR.6 Generate Event: Received Label Release Message for FEC
from MsgSource. (See Note 2.) from MsgSource. (See Note 2.)
Goto LAbR.11. Goto LAbR.11.
LAbR.7 Is LSR merging the LSP for FEC? LAbR.7 Is LSR merging the LSP for FEC?
If not, goto LAbR.9. If not, goto LAbR.9.
#### LAbR.8 Are there outstanding label requrests for this FEC?
LAbR.8 Are there upstream peers other than MsgSource that have
requested a label for FEC? The condition must be changed
to read: "Are there outstanding label requrests for this FEC?"
This is because if there are outstanding requests for MsgSource,
the test wil fail, and LAbR.9 will be executed, resulting in
killing the downstream propagation of these other requests.
###
If so, goto LAbR.11. If so, goto LAbR.11.
LAbR.9 Execute procedure Send_Message (Next Hop, Label Abort LAbR.9 Execute procedure Send_Message (Next Hop, Label Abort
Request, FEC, TLV), where TLV is a Label Request Message Request, FEC, TLV), where TLV is a Label Request Message
ID TLV containing the Message ID used by the LSR in the ID TLV containing the Message ID used by the LSR in the
outstanding Label Request message. outstanding Label Request message.
LAbR.10 Record that a label abort request for FEC is pending. LAbR.10 Record that a label abort request for FEC is pending.
LAbR.11 Delete record of label request for FEC from MsgSource. LAbR.11 Delete record of label request for FEC from MsgSource.
skipping to change at page 133, line 36 skipping to change at page 110, line 41
- LSR. The LSR handling the event. - LSR. The LSR handling the event.
- MsgSource. The LDP peer that sent the message. - MsgSource. The LDP peer that sent the message.
- Label. The label specified in the message. - Label. The label specified in the message.
- FEC. The FEC specified in the message. - FEC. The FEC specified in the message.
Algorithm: Algorithm:
### LRl.1 Does FEC match a known FEC? If not, goto LRl.14
LRl.0 Does FEC match a known FEC? If not, goto LRl.13
###
LRl.1 Remove MsgSource from record of peers that hold Label for LRl.2 Remove MsgSource from record of peers that hold Label for
FEC. (See Note 1.) FEC. (See Note 1.)
LRl.2 Does message match an outstanding label withdraw for FEC LRl.3 Does message match an outstanding label withdraw for FEC
previously sent to MsgSource? previously sent to MsgSource?
If not, goto LRl.4 If not, goto LRl.5
LRl.3 Delete record of outstanding label withdraw for FEC LRl.4 Delete record of outstanding label withdraw for FEC
previously sent to MsgSource. previously sent to MsgSource.
LRl.4 Is LSR merging labels for this FEC? LRl.5 Is LSR merging labels for this FEC?
If not, goto LRl.6. (See Note 2.) If not, goto LRl.7. (See Note 2.)
LRl.5
###
REPLACE :
Has LSR previously advertised a label for this FEC to
other peers?
WITH
Does LSR have outstanding label advertisements for this FEC?
See
MPLS WG archive, May 01, "Label Release receive doubt !!"
### LRl.6 Does LSR have outstanding label advertisements for this FEC?
If so, goto LRl.10. If so, goto LRl.11.
LRl.6 Is LSR egress for the FEC? LRl.7 Is LSR egress for the FEC?
If so, goto LRl.10 If so, goto LRl.11
LRl.7 Is there a Next Hop for FEC? AND LRl.8 Is there a Next Hop for FEC? AND
Does LSR have a previously received label mapping for FEC Does LSR have a previously received label mapping for FEC
from Next Hop? from Next Hop?
If not, goto LRl.10. If not, goto LRl.11.
LRl.8 Is LSR configured to propagate releases? LRl.9 Is LSR configured to propagate releases?
If not, goto LRl.10. (See Note 3.) If not, goto LRl.11. (See Note 3.)
LRl.9 Execute procedure Send_Message (Next Hop, Label Release, LRl.10 Execute procedure Send_Message (Next Hop, Label Release,
FEC, Label from Next Hop). FEC, Label from Next Hop).
LRl.10 Remove Label from forwarding/switching use for traffic LRl.11 Remove Label from forwarding/switching use for traffic
from MsgSource. from MsgSource.
LRl.11 Do any peers still hold Label for FEC? LRl.12 Do any peers still hold Label for FEC?
If so, goto LRl.13. If so, goto LRl.14.
LRl.12 Free the Label. LRl.13 Free the Label.
LRl.13 DONE. LRl.14 DONE.
Notes: Notes:
1. If LSR is using Downstream Unsolicited label distribution, it 1. If LSR is using Downstream Unsolicited label distribution, it
should not re-advertise a label mapping for FEC to MsgSource should not re-advertise a label mapping for FEC to MsgSource
until MsgSource requests it. until MsgSource requests it.
2. LRl.4 through LRl.8 deal with determining whether where the LSR 2. LRl.5 through LRl.9 deal with determining whether where the LSR
should propagate the label release to a downstream peer should propagate the label release to a downstream peer
(LRl.9). (LRl.9).
3. If LRl.8 is reached, no upstream LSR holds a label for the FEC, 3. If LRl.9 is reached, no upstream LSR holds a label for the FEC,
and the LSR holds a label for the FEC from the FEC Next Hop. and the LSR holds a label for the FEC from the FEC Next Hop.
The LSR could propagate the Label Release to the Next Hop. By The LSR could propagate the Label Release to the Next Hop. By
propagating the Label Release the LSR releases a potentially propagating the Label Release the LSR releases a potentially
scarce label resource. In doing so, it also increases the scarce label resource. In doing so, it also increases the
latency for re-establishing the LSP should MsgSource or some latency for re-establishing the LSP should MsgSource or some
other upstream LSR send it a new Label Request for FEC. other upstream LSR send it a new Label Request for FEC.
Whether or not to propagate the release is not a protocol Whether or not to propagate the release is not a protocol
issue. Label distribution will operate properly whether or not issue. Label distribution will operate properly whether or not
the release is propagated. The decision to propagate or not the release is propagated. The decision to propagate or not
skipping to change at page 142, line 51 skipping to change at page 118, line 51
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.12-LMp.13 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 must send a label request if the conditions in
### NH.13 hold.
REPLACE
NH.8 hold.
WITH
NH.13.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.
A.1.8. Receive Notification / Label Request Aborted A.1.8. Receive Notification / Label Request Aborted
Summary: Summary:
When an LSR receives a Label Request Aborted notification from an When an LSR receives a Label Request Aborted notification from an
LDP peer it records that the corresponding label request LDP peer it records that the corresponding label request
skipping to change at page 149, line 9 skipping to change at page 124, line 9
NoLS.1 Execute procedure Send_Label_Withdraw (Peer, FEC, NoLS.1 Execute procedure Send_Label_Withdraw (Peer, FEC,
PrevAdvLabel). (See Note 1.) PrevAdvLabel). (See Note 1.)
NoLS.2 DONE. NoLS.2 DONE.
Notes: Notes:
1. The LSR may remove the label from forwarding/switching use as 1. The LSR may remove the label from forwarding/switching use as
part of this event or as part of processing the label release part of this event or as part of processing the label release
from the peer in response to the label withdraw. ### from the peer in response to the label withdraw. If the LSR
doesn't wait for the label reelase message from the peer it
If the LSR doesn't wait for the label reelase message from the should not reuse the label until it receives the label release.
peer it should not reuse the label until it receives the label
release.
###
A.1.15. Timeout of deferred label request A.1.15. Timeout of deferred label request
Summary: Summary:
Label requests are deferred in response to No Route and Loop Label requests are deferred in response to No Route and Loop
Detected notifications. When a deferred FEC label request for a Detected notifications. When a deferred FEC label request for a
peer times out, the LSR sends the label request. peer times out, the LSR sends the label request.
Context: Context:
skipping to change at page 158, line 37 skipping to change at page 132, line 45
- PrevHopCount. The Hop Count, if any, this LSR associates with - PrevHopCount. The Hop Count, if any, this LSR associates with
the LSP for the FEC. the LSP for the FEC.
Additional Context: Additional Context:
- LSR Id. The unique LSR Id of this LSR. - LSR Id. The unique LSR Id of this LSR.
Algorithm: Algorithm:
### PMpA.1 Do the RAttributes include any unknown TLVs? If not, goto PMpA.4.
Add the following and renumber all the lines:
PMpA.0 Do the RAttributes include any unknown TLVs? If not, goto PMpA.1. PMpA.2 Do the settings of the U and F bits require forwarding of
PMpA.0a Do the settings of the U and F bits require forwarding of these TLVs? If not, goto PMpA.4.
these TLVs? If not, goto PMpA.1.
PMpA.0b Copy the unknown TLVs in SAttributes.
#### PMpA.3 Copy the unknown TLVs in SAttributes.
PMpA.1 Is Hop Count required for this Peer (see Note 1.) ? OR PMpA.4 Is Hop Count required for this Peer (see Note 1.) ? OR
Do RAttributes include a Hop Count? OR Do RAttributes include a Hop Count? OR
Is Loop Detection configured on LSR? Is Loop Detection configured on LSR?
If not, goto PMpA.21. If not, goto PMpA.24.
PMpA.2 Is LSR egress for FEC? PMpA.5 Is LSR egress for FEC?
If not, goto PMpA.4. If not, goto PMpA.7.
PMpA.3 Include Hop Count of 1 in SAttributes. Goto PMpA.21. PMpA.6 Include Hop Count of 1 in SAttributes. Goto PMpA.24.
PMpA.4 Do RAttributes have a Hop Count? PMpA.7 Do RAttributes have a Hop Count?
If not, goto PMpA.8. If not, goto PMpA.11.
PMpA.5 Is LSR member of edge set for an LSR domain whose LSRs do PMpA.8 Is LSR member of edge set for an LSR domain whose LSRs do
not perform TTL decrement AND not perform TTL decrement AND
Is Peer in that domain (See Note 2.). Is Peer in that domain (See Note 2.).
If not, goto PMpA.7. If not, goto PMpA.10.
PMpA.6 Include Hop Count of 1 in SAttributes. Goto PMpA.9. PMpA.9 Include Hop Count of 1 in SAttributes. Goto PMpA.12.
PMpA.7 Increment RAttributes Hop Count and copy the resulting PMpA.10 Increment RAttributes Hop Count and copy the resulting
Hop Count to SAttributes. See Note 2. Goto PMpA.9. Hop Count to SAttributes. See Note 2. Goto PMpA.12.
PMpA.8 Include Hop Count of unknown (0) in SAttributes. PMpA.11 Include Hop Count of unknown (0) in SAttributes.
PMpA.9 Is Loop Detection configured on LSR? PMpA.12 Is Loop Detection configured on LSR?
If not, goto PMpA.21. If not, goto PMpA.24.
PMpA.10 Do RAttributes have a Path Vector? PMpA.13 Do RAttributes have a Path Vector?
If so, goto PMpA.19. If so, goto PMpA.22.
PMpA.11 Is LSR propagating a received Label Mapping? PMpA.14 Is LSR propagating a received Label Mapping?
If not, goto PMpA.20. If not, goto PMpA.23.
PMpA.12 Does LSR support merging? PMpA.15 Does LSR support merging?
If not, goto PMpA.14. If not, goto PMpA.17.
PMpA.13 Has LSR previously sent a Label Mapping for FEC to Peer? PMpA.16 Has LSR previously sent a Label Mapping for FEC to Peer?
If not, goto PMpA.20. If not, goto PMpA.23.
PMpA.14 Do RAttributes include a Hop Count? PMpA.17 Do RAttributes include a Hop Count?
If not, goto PMpA.21. If not, goto PMpA.24.
PMpA.15 Is Hop Count in Rattributes unknown(0)? PMpA.18 Is Hop Count in Rattributes unknown(0)?
If so, goto PMpA.20. If so, goto PMpA.23.
PMpA.16 Has LSR previously sent a Label Mapping for FEC to Peer? PMpA.19 Has LSR previously sent a Label Mapping for FEC to Peer?
If not goto PMpA.21. If not goto PMpA.24.
PMpA.17 Is Hop Count in RAttributes different from PrevHopCount ? PMpA.20 Is Hop Count in RAttributes different from PrevHopCount ?
If not goto PMpA.21. If not goto PMpA.24.
PMpA.18 Is the Hop Count in RAttributes > PrevHopCount? OR PMpA.21 Is the Hop Count in RAttributes > PrevHopCount? OR
Is PrevHopCount unknown(0) Is PrevHopCount unknown(0)
If not, goto PMpA.21. If not, goto PMpA.24.
PMpA.19 Add LSR Id to beginning of Path Vector from RAttributes PMpA.22 Add LSR Id to beginning of Path Vector from RAttributes
and copy the resulting Path Vector into SAttributes. and copy the resulting Path Vector into SAttributes.
Goto PMpA.21. Goto PMpA.24.
PMpA.20 Include Path Vector of length 1 containing LSR Id in PMpA.23 Include Path Vector of length 1 containing LSR Id in
SAttributes. SAttributes.
PMpA.21 DONE. PMpA.24 DONE.
Notes: Notes:
1. The link with Peer may require that Hop Count be included in 1. The link with Peer may require that Hop Count be included in
Label Mapping messages; for example, see [RFC3035] and Label Mapping messages; for example, see [RFC3035] and
[RFC3034]. [RFC3034].
2. If the LSR is at the edge of a cloud of LSRs that do not per- 2. If the LSR is at the edge of a cloud of LSRs that do not per-
form TTL-decrement and it is propagating the Label Mapping mes- form TTL-decrement and it is propagating the Label Mapping mes-
sage upstream into the cloud, it sets the Hop Count to 1 so sage upstream into the cloud, it sets the Hop Count to 1 so
that Hop Count across the cloud is calculated properly. This that Hop Count across the cloud is calculated properly. This
ensures proper TTL management for packets forwarded across the ensures proper TTL management for packets forwarded across the
part of the LSP that passes through the cloud. part of the LSP that passes through the cloud.
3. For hop count arithmetic, unknown + 1 = unknown. 3. For hop count arithmetic, unknown + 1 = unknown.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (year). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Additional copyright notices are not permitted in IETF Documents Additional copyright notices are not permitted in IETF Documents
except in the case where such document is the product of a joint except in the case where such document is the product of a joint
development effort between the IETF and another standards development development effort between the IETF and another standards development
organization or the document is a republication of the work of organization or the document is a republication of the work of
another standards organization. Such exceptions must be approved on another standards organization. Such exceptions must be approved on
an individual basis by the IAB. an individual basis by the IAB.
 End of changes. 

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