--- 1/draft-ietf-mpls-rfc3036bis-02.txt 2006-02-04 17:26:21.000000000 +0100 +++ 2/draft-ietf-mpls-rfc3036bis-03.txt 2006-02-04 17:26:21.000000000 +0100 @@ -1,21 +1,21 @@ Network Working Group Loa Andersson Internet Draft Ina Minei -Expiration Date: January 2006 Bob Thomas +Expiration Date: April 2006 Bob Thomas Editors - July 2005 + October 2005 LDP Specification - draft-ietf-mpls-rfc3036bis-02.txt + draft-ietf-mpls-rfc3036bis-03.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 @@ -36,25 +36,25 @@ This document is produced as part of advancing the LDP specification to draft standard status. The LDP specification 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. Abstract The architecture for Multi Protocol Label Switching (MPLS) is - described in RFC 3031. A fundamental concept in MPLS is that two - Label Switching Routers (LSRs) must agree on the meaning of the - labels used to forward traffic between and through them. This common - understanding is achieved by using a set of procedures, called a - label distribution protocol, by which one LSR informs another of + described in RFC 3031 [RFC3031]. A fundamental concept in MPLS is + that two Label Switching Routers (LSRs) must agree on the meaning of + the labels used to forward traffic between and through them. This + common understanding is achieved by using a set of procedures, called + a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. Table of Contents Source of this document ............................... 1 1 LDP Overview .......................................... 7 1.1 LDP Peers ............................................. 8 @@ -709,28 +709,31 @@ c. If LSR1 receives a KeepAlive message, LSR2 has accepted its proposed session parameters. 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. + 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 + 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 + 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 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. @@ -1457,23 +1460,23 @@ | | | Value | ~ ~ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 + (=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 MUST be silently ignored and the rest of the message processed as if the unknown TLV did not exist. The sections fol- lowing that define TLVs specify a value for the U-bit. F bit 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- 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- warded with the containing message. The sections following that define TLVs specify a value for the F-bit. By setting both the U @@ -1602,26 +1605,26 @@ this case the Prefix itself is zero octets). Prefix An address prefix encoded according to the Address Family field, whose length, in bits, was specified in the PreLen field, padded to a byte boundary. 3.4.1.1. FEC Procedures 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 "Unsupported Address Family" Notification message to its LDP peer signaling an error. - If it encounters a FEC Element type it cannot decode, it should stop + If it encounters a FEC Element type it cannot decode, it SHOULD stop decoding the FEC TLV, abort processing the message containing the TLV, and send an "Unknown FEC" Notification message to its LDP peer signaling an error. 3.4.2. Label TLVs Label TLVs encode labels. Label TLVs are carried by the messages used to advertise, request, release and withdraw label mappings. There are several different kinds of Label TLVs which can appear in @@ -1651,56 +1654,56 @@ 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Res| V | VPI | VCI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Res - This field is reserved. It must be set to zero on transmission - and must be ignored on receipt. + This field is reserved. It MUST be set to zero on transmission + and MUST be ignored on receipt. V-bits Two-bit switching indicator. If V-bits is 00, both the VPI and VCI are significant. If V-bits is 01, only the VPI field is sig- nificant. If V-bit is 10, only the VCI is significant. VPI - Virtual Path Identifier. If VPI is less than 12-bits it should be - right justified in this field and preceding bits should be set to + Virtual Path Identifier. If VPI is less than 12-bits it SHOULD be + right justified in this field and preceding bits SHOULD be set to 0. VCI Virtual Channel Identifier. If the VCI is less than 16- bits, it - should be right justified in the field and the preceding bits must + SHOULD be right justified in the field and the preceding bits MUST be set to 0. If Virtual Path switching is indicated in the V-bits - field, then this field must be ignored by the receiver and set to + field, then this field MUST be ignored by the receiver and set to 0 by the sender. 3.4.2.3. Frame Relay Label TLV An LSR uses Frame Relay Label TLVs to encode labels for use on Frame Relay 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| Frame Relay Label (0x0202)| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |Len| DLCI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Res - This field is reserved. It must be set to zero on transmission - and must be ignored on receipt. + This field is reserved. It MUST be set to zero on transmission + and MUST be ignored on receipt. 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. @@ -1764,42 +1767,42 @@ | HC Value | +-+-+-+-+-+-+-+-+ HC Value 1 octet unsigned integer hop count value. 3.4.4.1. Hop Count Procedures During setup of an LSP an LSR R may receive a Label Mapping or Label Request message for the LSP that contains the Hop Count TLV. If it - does, it should record the hop count value. + does, it SHOULD record the hop count value. If LSR R then propagates the Label Mapping message for the LSP to an upstream peer or the Label Request message to a downstream peer to - continue the LSP setup, it must must determine a hop count to include - in the propagated message as follows: + continue the LSP setup, it must determine a hop count to include in + the propagated message as follows: - - If the message is a Label Request message, R must increment the + - If the message is a Label Request message, R MUST increment the received hop count; - If the message is a Label Mapping message, R determines the hop count as follows: o If R is a member of the edge set of an LSR domain whose LSRs do not perform 'TTL-decrement' and the upstream peer is within - that domain, R must reset the hop count to 1 before propagating + that domain, R MUST reset the hop count to 1 before propagating the message. - o Otherwise, R must increment the received hop count. + o Otherwise, R MUST increment the received hop count. The first LSR in the LSP (ingress for a Label Request message, egress - for a Label Mapping message) should set the hop count value to 1. + for a Label Mapping message) SHOULD set the hop count value to 1. By convention a value of 0 indicates an unknown hop count. The result of incrementing an unknown hop count is itself an unknown hop count (0). Use of the unknown hop count value greatly reduces the signaling overhead when independent control is used. When a new LSP is estab- lished, each LSR starts with unknown hop count. Addition of a new LSR whose hop count is also unknown does not cause a hop count update to be propagated upstream since the hop count remains unknown. When @@ -1812,26 +1815,26 @@ 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 check the hop count value to determine whether the hop count has - exceeded its configured maximum allowable value. If so, it must + exceeded its configured maximum allowable value. If so, it MUST behave as if the containing message has traversed a loop by sending a Notification message signaling Loop Detected in reply to the sender of the message. - If Loop Detection is configured, the LSR must follow the procedures + If Loop Detection is configured, the LSR MUST follow the procedures specified in Section "Loop Detection". 3.4.5. Path Vector TLV 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- tion mechanism. See Section "Loop Detection". Its use in the Label 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 advertisement has traversed to setup an LSP. Its encoding is: @@ -1859,26 +1862,26 @@ 3.4.5.1. Path Vector Procedures The Path Vector TLV is carried in Label Mapping and Label Request messages when loop detection is configured. 3.4.5.1.1. Label Request Path Vector Section "Loop Detection" specifies situations when an LSR must include a Path Vector TLV in a Label Request message. - An LSR that receives a Path Vector in a Label Request message must + An LSR that receives a Path Vector in a Label Request message MUST perform the procedures described in Section "Loop Detection". - If the LSR detects a loop, it must reject the Label Request message. + If the LSR detects a loop, it MUST reject the Label Request message. - The LSR must: + The LSR MUST: 1. Transmit a Notification message to the sending LSR signaling "Loop Detected". 2. Not propagate the Label Request message further. Note that a Label Request message with Path Vector TLV is forwarded until: 1. A loop is found, @@ -1886,25 +1889,25 @@ 2. The LSP egress is reached, 3. The maximum Path Vector limit or maximum Hop Count limit is reached. This is treated as if a loop had been detected. 3.4.5.1.2. Label Mapping Path Vector Section "Loop Detection" specifies the situations when an LSR must include a Path Vector TLV in a Label Mapping message. - An LSR that receives a Path Vector in a Label Mapping message must + An LSR that receives a Path Vector in a Label Mapping message MUST perform the procedures described in Section "Loop Detection". - If the LSR detects a loop, it must reject the Label Mapping message - in order to prevent a forwarding loop. The LSR must: + If the LSR detects a loop, it MUST reject the Label Mapping message + in order to prevent a forwarding loop. The LSR MUST: 1. Transmit a Label Release message carrying a Status TLV to the sending LSR to signal "Loop Detected". 2. Not propagate the message further. 3. Check whether the Label Mapping message is for an existing LSP. If so, the LSR must unsplice any upstream labels which are spliced to the downstream label for the FEC. @@ -1931,46 +1934,46 @@ |U|F| Status (0x0300) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U bit - Should be 0 when the Status TLV is sent in a Notification message. - Should be 1 when the Status TLV is sent in some other message. + SHOULD be 0 when the Status TLV is sent in a Notification message. + SHOULD be 1 when the Status TLV is sent in some other message. F bit - Should be the same as the setting of the F-bit in the Status Code + SHOULD be the same as the setting of the F-bit in the Status Code field. Status Code 32-bit unsigned integer encoding the event being signaled. The structure of a Status Code 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E|F| Status Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E bit Fatal error bit. If set (=1), this is a fatal error notifica- tion. If clear (=0), this is an advisory notification. F bit - Forward bit. If set (=1), the notification should be forwarded + Forward bit. If set (=1), the notification SHOULD be forwarded to the LSR for the next-hop or previous-hop for the LSP, if any, associated with the event being signaled. If clear (=0), - the notification should not be forwarded. + the notification SHOULD NOT be forwarded. Status Data 30-bit unsigned integer which specifies the status information. This specification defines Status Codes (32-bit unsigned integers with the above encoding). A Status Code of 0 signals success. Message ID @@ -1979,22 +1982,22 @@ being identified. Message Type If non-zero, the type of the peer message to which the Status TLV refers. If zero, the Status TLV does not refer to any specific message type. Note that use of the Status TLV is not limited to Notification mes- sages. A message other than a Notification message may carry a Sta- tus TLV as an Optional Parameter. When a message other than a Noti- - fication carries a Status TLV the U-bit of the Status TLV should be - set to 1 to indicate that the receiver should silently discard the + fication carries a Status TLV the U-bit of the Status TLV SHOULD be + set to 1 to indicate that the receiver SHOULD silently discard the TLV if unprepared to handle it. 3.5. LDP Messages All LDP messages have the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U| Message Type | Message Length | @@ -2025,21 +2028,21 @@ Identifies the type of message Message Length Specifies the cumulative length in octets of the Message ID, Mandatory Parameters, and Optional Parameters. Message ID 32-bit value used to identify this message. Used by the sending LSR to facilitate identifying notification messages that may apply to this message. An LSR sending a notification message in - response to this message should include this Message Id in the + response to this message SHOULD include this Message Id in the Status TLV carried by the notification message; see Section "Noti- fication Message". Mandatory Parameters Variable length set of required message parameters. Some messages have no required parameters. For messages that have required parameters, the required parame- ters MUST appear in the order specified by the individual message specifications in the sections that follow. @@ -2151,35 +2154,35 @@ 3.5.1.1. Notification Message Procedures If an LSR encounters a condition requiring it to notify its peer with advisory or error information it sends the peer a Notification mes- sage containing a Status TLV that encodes the information and option- ally additional TLVs that provide more information about the condi- tion. If the condition is one that is a fatal error the Status Code carried in the notification will indicate that. In this case, after sending - the Notification message the LSR should terminate the LDP session by + the Notification message the LSR SHOULD terminate the LDP session by closing the session TCP connection and discard all state associated with the session, including all label-FEC bindings learned via the session. 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 all state associated with the session, including all label-FEC bind- 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 - a shutdown message during session initialization, it should transmit - a shutdown message and then close the transport connection. + a Shutdown message during session initialization, it SHOULD transmit + a Shutdown message and then close the transport connection. 3.5.1.2. Events Signaled by Notification Messages It is useful for descriptive purpose to classify events signaled by Notification Messages into the following categories. 3.5.1.2.1. Malformed PDU or Message Malformed LDP PDUs or Messages that are part of the LDP Discovery mechanism are handled by silently discarding them. @@ -2353,52 +2356,52 @@ request. An LSR initiating Extended Discovery sets R to 1. If R is 1, the receiving LSR checks whether it has been configured to send Targeted Hellos to the Hello source in response to Hellos with this request. If not, it ignores the request. If so, it ini- tiates periodic transmission of Targeted Hellos to the Hello source. 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. Optional Parameters This variable length field contains 0 or more parameters, each encoded as a TLV. The optional parameters defined by this ver- sion of the protocol are Optional Parameter Type Length Value IPv4 Transport Address 0x0401 4 See below Configuration 0x0402 4 See below Sequence Number IPv6 Transport Address 0x0403 16 See below IPv4 Transport Address Specifies the IPv4 address to be used for the sending LSR when opening the LDP session TCP connection. If this optional TLV is not present the IPv4 source address for the UDP packet car- - rying the Hello should be used. + rying the Hello SHOULD be used. Configuration Sequence Number Specifies a 4 octet unsigned configuration sequence number that identifies the configuration state of the sending LSR. Used by the receiving LSR to detect configuration changes on the send- ing LSR. IPv6 Transport Address Specifies the IPv6 address to be used for the sending LSR when opening the LDP session TCP connection. If this optional TLV is not present the IPv6 source address for the UDP packet car- - rying the Hello should be used. + rying the Hello SHOULD be used. 3.5.2.1. Hello Message Procedures An LSR receiving Hellos from another LSR maintains a Hello adjacency corresponding to the Hellos. The LSR maintains a hold timer with the Hello adjacency which it restarts whenever it receives a Hello that matches the Hello adjacency. If the hold timer for a Hello adjacency expires the LSR discards the Hello adjacency: see sections "Maintain- ing Hello Adjacencies" and "Maintaining LDP Sessions". @@ -2522,75 +2525,75 @@ Indicates the type of Label advertisement. A value of 0 means Downstream Unsolicited advertisement; a value of 1 means Down- stream On Demand. If one LSR proposes Downstream Unsolicited and the other pro- poses Downstream on Demand, the rules for resolving this dif- ference is: - If the session is for a label-controlled ATM link or a label-controlled Frame Relay link, then Downstream on Demand - must be used. + MUST be used. - - Otherwise, Downstream Unsolicited must be used. + - Otherwise, Downstream Unsolicited MUST be used. If the label advertisement discipline determined in this way is - unacceptable to an LSR, it must send a Session Rejected/Parame- + unacceptable to an LSR, it MUST send a Session Rejected/Parame- ters Advertisement Mode Notification message in response to the Initialization message and not establish the session. D, Loop Detection Indicates whether loop detection based on path vectors is enabled. A value of 0 means loop detection is disabled; a value of 1 means that loop detection is enabled. PVLim, Path Vector Limit - The configured maximum path vector length. Must be 0 if loop + The configured maximum path vector length. MUST be 0 if loop detection is disabled (D = 0). If the loop detection proce- dures would require the LSR to send a path vector that exceeds this limit, the LSR will behave as if a loop had been detected for the FEC in question. When Loop Detection is enabled in a portion of a network, it is recommended that all LSRs in that portion of the network be configured with the same path vector limit. Although knowledge of a peer's path vector limit will not change an LSR's behav- ior, it does enable the LSR to alert an operator to a possible misconfiguration. 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. Max PDU Length Two octet unsigned integer that proposes the maximum allowable length for LDP PDUs for the session. A value of 255 or less specifies the default maximum length of 4096 octets. The receiving LSR MUST calculate the maximum PDU length for the session by using the smaller of its and its peer's proposals for Max PDU Length. The default maximum PDU length applies before session initialization completes. If the maximum PDU length determined this way is unacceptable - to an LSR, it must send a Session Rejected/Parameters Max PDU + to an LSR, it MUST send a Session Rejected/Parameters Max PDU Length Notification message in response to the Initialization message and not establish the session. Receiver LDP Identifier Identifies the receiver's label space. This LDP Identifier, together with the sender's LDP Identifier in the PDU header enables the receiver to match the Initialization message with one of its Hello adjacencies; see Section "Hello Message Proce- dures". - If there is no matching Hello adjacency, the LSR must send a + If there is no matching Hello adjacency, the LSR MUST send a Session Rejected/No Hello Notification message in response to the Initialization message and not establish the session. Optional Parameters This variable length field contains 0 or more parameters, each encoded as a TLV. The optional parameters are: Optional Parameter Type Length Value ATM Session Parameters 0x0501 var See below @@ -2655,81 +2658,81 @@ tion on the link only. When either or both of the peers speci- fies unidirectional VC capability, both LSRs use unidirectional VC label assignment for the link as follows. The LSRs compare their LDP Identifiers as unsigned integers. The LSR with the larger LDP Identifier may assign only odd-numbered VCIs in the VPI/VCI range as labels. The system with the smaller LDP Iden- tifier may assign only even-numbered VCIs in the VPI/VCI range as labels. 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. One or more ATM Label Range Components A list of ATM Label Range Components which together specify the Label range supported by the transmitting LSR. A receiving LSR MUST calculate the intersection between the received range and its own supported label range. The inter- section is the range in which the LSR may allocate and accept labels. LSRs MUST NOT establish a session with neighbors for which the intersection of ranges is NULL. In this case, the - LSR must send a Session Rejected/Parameters Label Range Notifi- + LSR MUST send a Session Rejected/Parameters Label Range Notifi- cation message in response to the Initialization message and not establish the session. The encoding for an ATM Label Range Component 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Res | Minimum VPI | Minimum VCI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Res | Maximum VPI | Maximum VCI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Res - This field is reserved. It must be set to zero on transmis- - sion and must be ignored on receipt. + This field is reserved. It MUST be set to zero on transmis- + sion and MUST be ignored on receipt. Minimum VPI (12 bits) This 12 bit field specifies the lower bound of a block of Virtual Path Identifiers that is supported on the originat- - ing switch. If the VPI is less than 12-bits it should be - right justified in this field and preceding bits should be + ing switch. If the VPI is less than 12-bits it SHOULD be + right justified in this field and preceding bits SHOULD be set to 0. Minimum VCI (16 bits) This 16 bit field specifies the lower bound of a block of 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. + SHOULD be right justified in this field and preceding bits + SHOULD be set to 0. Maximum VPI (12 bits) This 12 bit field specifies the upper bound of a block of Virtual Path Identifiers that is supported on the originat- - ing switch. If the VPI is less than 12-bits it should be - right justified in this field and preceding bits should be + ing switch. If the VPI is less than 12-bits it SHOULD be + right justified in this field and preceding bits SHOULD be set to 0. Maximum VCI (16 bits) This 16 bit field specifies the upper bound of a block of 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. + 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 + 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 @@ -2771,72 +2774,72 @@ label mapping for one direction on the link only. Wheneither or both of the peers specifies unidirectional VC capability, both LSRs use unidirectional VC label assignment for the link as follows. The LSRs compare their LDP Identifiers as unsigned integers. The LSR with the larger LDP Identifier may assign only odd-numbered DLCIs in the range as labels. The system with the smaller LDP Identifier may assign only even-numbered DLCIs in the range as labels. 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. One or more Frame Relay Label Range Components A list of Frame Relay Label Range Components which together specify the Label range supported by the transmitting LSR. A receiving LSR MUST calculate the intersection between the received range and its own supported label range. The inter- section is the range in which the LSR may allocate and accept labels. LSRs MUST NOT establish a session with neighbors for which the intersection of ranges is NULL. In this case, the - LSR must send a Session Rejected/Parameters Label Range Notifi- + LSR MUST send a Session Rejected/Parameters Label Range Notifi- cation message in response to the Initialization message and not establish the session. The encoding for a Frame Relay Label Range Component 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |Len| Minimum DLCI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Maximum DLCI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved - This field is reserved. It must be set to zero on transmis- + This field is reserved. It MUST be set to zero on transmis- sion and ignored on receipt. Len This field specifies the number of bits of the DLCI. The following values are supported: Len DLCI bits 0 10 2 23 Len values 1 and 3 are reserved. Minimum DLCI This 23-bit field specifies the lower bound of a block of Data Link Connection Identifiers (DLCIs) that is supported - on the originating switch. The DLCI should be right justi- - fied in this field and unused bits should be set to 0. + on the originating switch. The DLCI SHOULD be right justi- + fied in this field and unused bits SHOULD be set to 0. Maximum DLCI This 23-bit field specifies the upper bound of a block of Data Link Connection Identifiers (DLCIs) that is supported - on the originating switch. The DLCI should be right - justified in this field and unused bits should be set to 0. + on the originating switch. The DLCI SHOULD be right + justified in this field and unused bits SHOULD be set to 0. Note that there is no Generic Session Parameters TLV for sessions which advertise Generic Labels. 3.5.3.1. Initialization Message Procedures See Section "LDP Session Establishment" and particularly Section "Session Initialization" for general procedures for handling the Ini- tialization Message. @@ -2867,21 +2870,21 @@ 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 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. + 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: 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 @@ -2909,42 +2912,42 @@ 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". 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. - Whenever an LSR "activates" a new interface address, it should + Whenever an LSR "activates" a new interface address, it SHOULD advertise the new address with an Address message. 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". 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 message. An LSR may re-advertise an address (A) that it has previously adver- 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. 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. 3.5.6. Address Withdraw Message An LSR sends the Address Withdraw Message to an LDP peer to withdraw previously advertised interface addresses. The encoding for the Address Withdraw Message is: 0 1 2 3 @@ -3018,21 +3021,21 @@ Label Request 4 See below Message ID TLV Hop Count TLV 1 See below Path Vector TLV variable See below The encodings for the Hop Count, and Path Vector TLVs can be found in Section "TLV Encodings for Commonly Used Parameters". Label Request Message ID If this Label Mapping message is a response to a Label Request - message it must include the Request Message Id optional parame- + message it MUST include the Request Message Id optional parame- ter. The value of this optional parameter is the Message Id of the corresponding Label Request Message. Hop Count Specifies the running total of the number of LSR hops along the LSP being setup by the Label Message. Section "Hop Count Pro- cedures" describes how to handle this TLV. Path Vector Specifies the LSRs along the LSP being setup by the Label Mes- @@ -3044,21 +3047,21 @@ 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 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 whether it uses a different mapping for each of its peers. An LSR is responsible for the consistency of the label mappings it has distributed, and that its peers have these mappings. An LSR receiving a Label Mapping message from a downstream LSR for a - Prefix should not use the label for forwarding unless its routing ta- + Prefix SHOULD NOT use the label for forwarding unless its routing ta- ble contains an entry that exactly matches the FEC Element. See Appendix A "LDP Label Distribution Procedures" for more details. 3.5.7.1.1. Independent Control Mapping If an LSR is configured for independent control, a mapping message is transmitted by the LSR upon any of the following conditions: 1. The LSR recognizes a new FEC via the forwarding table, and the @@ -3109,21 +3112,21 @@ everything is functioning properly, but no labels are distributed. For example, consider two LSRs Ru and Rd where Ru is the upstream LSR and Rd is the downstream LSR for a particular FEC. In this example, Ru is using Downstream Unsolicited advertisement mode and Rd is using Downstream on Demand mode. In this case, Rd may assume that Ru will request a label mapping when it wants one and Ru may assume that Rd will advertise a label if it wants Ru to use one. If Rd and Ru oper- ate as suggested, no labels will be distributed from Rd to Ru. This livelock situation can be avoided if the following rule is - observed: an LSR operating in Downstream on Demand mode should not be + observed: an LSR operating in Downstream on Demand mode SHOULD NOT be expected to send unsolicited mapping advertisements. Therefore, if the downstream LSR is operating in Downstream on Demand mode, the upstream LSR is responsible for requesting label mappings as needed. 3.5.7.1.4. Downstream Unsolicited Label Advertisement In general, the downstream LSR is responsible for advertising a label mapping when it wants an upstream LSR to use the label. An upstream LSR may issue a mapping request if it so desires. @@ -3210,67 +3213,67 @@ ditions: 1. The LSR recognizes a new FEC via the forwarding table, and the next hop is an LDP peer, and the LSR doesn't already have a mapping from the next hop for the given FEC. 2. The next hop to the FEC changes, and the LSR doesn't already have a mapping from that next hop for the given FEC. Note that if the LSR already has a pending Label Request mes- - sage for the new next hop it should not issue an additional + sage for the new next hop it SHOULD NOT issue an additional Label Request in response to the next hop change. 3. The LSR receives a Label Request for a FEC from an upstream LDP peer, the FEC next hop is an LDP peer, and the LSR doesn't already have a mapping from the next hop. Note that since a non-merge LSR must setup a separate LSP for each upstream peer requesting a label, it must send a separate Label Request for each such peer. A consequence of this is that a non-merge LSR may have multiple Label Request messages 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 indicating why it cannot satisfy the request. When the FEC for which a label is requested is a Prefix FEC Element, the receiving LSR uses its routing table to determine its response. Unless its routing table includes an entry that exactly matches the - requested Prefix, the LSR must respond with a No Route Notification + requested Prefix, the LSR MUST respond with a No Route Notification message. The message ID of the Label Request message serves as an identifier 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 includes the message ID of the Label Request message. Note that 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. This version of the protocol defines the following Status Codes for the Notification message that signals a request cannot be satisfied: No Route The FEC for which a label was requested includes a FEC Element for which the LSR does not have a route. No Label Resources The LSR cannot provide a label because of resource limitations. - When resources become available the LSR must notify the + When resources become available the LSR MUST notify the requesting LSR by sending a Notification message with the Label Resources Available Status Code. An LSR that receives a No Label Resources response to a Label - Request message must not issue further Label Request messages + Request message MUST NOT issue further Label Request messages until it receives a Notification message with the Label Resources Available Status code. Loop Detected The LSR has detected a looping Label Request message. See Appendix A "LDP Label Distribution Procedures" for more details. 3.5.9. Label Abort Request Message @@ -3322,23 +3325,23 @@ Request for FEC from an upstream peer Y and Y is the only (last) upstream LSR requesting a label for FEC. There may be other situations where an LSR may choose to abort an outstanding Label Request message in order to reclaim resource asso- ciated with the pending LSP. However, specification of general strategies for using the abort mechanism is beyond the scope of LDP. When an LSR receives a Label Abort Request message, if it has not previously responded to the Label Request being aborted with a Label - Mapping message or some other Notification message, it must acknowl- + Mapping message or some other Notification message, it MUST acknowl- edge the abort by responding with a Label Request Aborted Notifica- - tion message. The Notification must include a Label Request Message + tion message. The Notification MUST include a Label Request Message ID TLV that carries the message ID of the aborted Label Request mes- sage. If an LSR receives a Label Abort Request Message after it has responded to the Label Request in question with a Label Mapping mes- sage or a Notification message, it ignores the abort request. If an LSR receives a Label Mapping message in response to a Label Request message after it has sent a Label Abort Request message to abort the Label Request, the label in the Label Mapping message is @@ -3362,21 +3365,21 @@ an LSR may choose to time out receipt of the above. The time out period should be relatively long (several minutes). If the time out period elapses with no reply from the peer the LSR may reuse the Mes- sage Id of the Label Request message; if it does so, it should also discard any record of the outstanding Label Request and Label Abort messages. Note that the response to a Label Abort Request message is never "ordered". That is, the response does not depend on the downstream state of the LSP setup being aborted. An LSR receiving a Label Abort - Request message must process it immediately, regardless of the down- + Request message MUST process it immediately, regardless of the down- stream state of the LSP, responding with a Label Request Aborted Notification or ignoring it, as appropriate. 3.5.10. Label Withdraw Message An LSR sends a Label Withdraw Message to an LDP peer to signal the peer that the peer may not continue to use specific FEC-label map- pings the LSR had previously advertised. This breaks the mapping between the FECs and the labels. @@ -3435,21 +3438,21 @@ optional Label TLV is to be withdrawn. The FEC TLV may contain the Wildcard FEC Element; if so, it may con- tain no other FEC Elements. In this case, if the Label Withdraw mes- sage contains an optional Label TLV, then the label is to be with- drawn from all FECs to which it is bound. If there is not an optional Label TLV in the Label Withdraw message, then the sending LSR is withdrawing all label mappings previously advertised to the receiving LSR. - An LSR that receives a Label Withdraw message must respond with a + An LSR that receives a Label Withdraw message MUST respond with a Label Release message. See Appendix A "LDP Label Distribution Procedures" for more details. 3.5.11. Label Release Message An LSR sends a Label Release message to an LDP peer to signal the peer that the LSR no longer needs specific FEC-label mappings previ- ously requested of and/or advertised by the peer. @@ -3488,21 +3491,21 @@ Label If present, the label being released (see procedures below). 3.5.11.1. Label Release Message Procedures An LSR transmits a Label Release message to a peer when it is no longer needs a label previously received from or requested of that peer. - An LSR must transmit a Label Release message under any of the follow- + An LSR MUST transmit a Label Release message under any of the follow- ing conditions: 1. The LSR which sent the label mapping is no longer the next hop for the mapped FEC, and the LSR is configured for conservative operation. 2. The LSR receives a label mapping from an LSR which is not the next hop for the FEC, and the LSR is configured for conserva- tive operation. @@ -3560,22 +3563,22 @@ | | | Data.... | ~ ~ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 + (=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. 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 @@ -4153,22 +4156,22 @@ 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. 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 - and Nick Weeds. + Mark Duffy, Vach Kompella, Kishore Tiruveedhula. Rama Ramakrishnan, + Nick Weeds and Adrian Farrel. 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, @@ -4330,21 +4333,21 @@ . Downstream On Demand Independent Control, called PulledUnconditional in [RFC3031]. . Downstream On Demand Ordered Control, called PulledConditional in [RFC3031]. - Label Withdrawal procedure, which is performed by a downstream LSR to determine when to withdraw a FEC label mapping previ- ously distributed to LDP peers. The architecture defines a single Label Withdrawal procedure. Whenever an LSR breaks the - binding between a label and a FEC, it must withdraw the FEC + binding between a label and a FEC, it MUST withdraw the FEC label mapping from all LDP peers to which it has previously sent the mapping. - Label Request procedure, which is performed by an upstream LSR to determine when to explicitly request that a downstream LSR bind a label to a FEC and send it the corresponding label map- ping. The architecture defines three Label Request procedures: . Request Never. The LSR never requests a label. @@ -4562,33 +4565,33 @@ distinguish such requests from a non-label merging MsgSource from duplicate label requests. The LSR uses the message ID of received Label Request messages to detect duplicate requests. This means that an LSR (the upstream peer) may not reuse the message ID used for a Label Request until the Label Request transaction has completed. 2. When an LSR sends a label request to a peer it records that the request has been sent and marks it as outstanding. As long as - the request is marked outstanding the LSR should not send + the request is marked outstanding the LSR SHOULD NOT send another request for the same label to the peer. Such a second request would be a duplicate. The Send_Label_Request procedure described below obeys this rule. A duplicate label request is considered a protocol error and - should be dropped by the receiving LSR (perhaps with a suitable + SHOULD be dropped by the receiving LSR (perhaps with a suitable notification returned to MsgSource). 3. If LSR is not merge-capable, this test will fail. 4. The Send_Label procedure may fail due to lack of label - resources, in which case the LSR should not perform the Label + resources, in which case the LSR SHOULD NOT perform the Label Use procedure. A.1.2. Receive Label Mapping Summary: The response by an LSR to receipt of a FEC label mapping from an LDP peer may involve one or more of the following actions: - Transmission of a label release message for the FEC label to @@ -4849,21 +4852,21 @@ gate the Path Vector. 10. LMp.22 through LMp.27 deal with a situation that can arise when the LSR is using independent control and it receives a mapping from the downstream peer after it has sent a mapping to an upstream peer. In this situation the LSR needs to prop- agate any changed attributes, such as Hop Count, upstream. If Loop Detection is configured on, the propagated attributes 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 label requests, fall through into the Downstream on Demand procedures in order to satisfy the pending requests. 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. @@ -5006,21 +5009,21 @@ LRl.12 Do any peers still hold Label for FEC? If so, goto LRl.14. LRl.13 Free the Label. LRl.14 DONE. Notes: 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. 2. LRl.5 through LRl.9 deal with determining whether where the LSR should propagate the label release to a downstream peer (LRl.9). 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. The LSR could propagate the Label Release to the Next Hop. By propagating the Label Release the LSR releases a potentially @@ -5357,21 +5360,21 @@ Next Hop. 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 Label Mapping message where the LSR operating in Conservative Label retention mode may have released a label mapping received from the New Next Hop before it detected the FEC next hop had changed. 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. Therefore it executes the Send_Label_Request procedure directly rather than perform LSR Label Request procedure. A.1.8. Receive Notification / Label Request Aborted Summary: When an LSR receives a Label Request Aborted notification from an @@ -5583,21 +5586,21 @@ 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 + 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. @@ -5607,21 +5610,21 @@ 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 - should not reuse the label until it receives the label release. + SHOULD NOT reuse the label until it receives the label release. A.1.15. Timeout of deferred label request 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: