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