Network Working Group Peter Ashwood-Smith (Nortel Networks Corp.) Internet Draft Ayan Banerjee (Calient Networks) Expiration Date: May 2001 Lou Berger (Movaz Networks) Greg Bernstein (Ciena Corporation) John Drake (Calient Networks) Yanhe Fan (Axiowave Networks) Kireeti Kompella (Juniper Networks, Inc.) Eric Mannie (GTS) Jonathan P. Lang (Calient Networks) Bala Rajagopalan (Tellium, Inc.) Yakov Rekhter (Cisco Systems) Debanjan Saha (Tellium, Inc.) Vishal Sharma (Tellabs) George Swallow (Cisco Systems) Z. Bo Tang (Tellium, Inc.) November 2000 Generalized MPLS Signaling - RSVP-TE Extensions draft-ietf-mpls-generalized-rsvp-te-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. To view the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow Directory, see http://www.ietf.org/shadow.html. Abstract This document describes extensions to RSVP-TE signaling required to support Generalized MPLS. Generalized MPLS extends MPLS to encompass time-division (e.g. SONET ADMs), wavelength (optical lambdas) and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). This document presents an RSVP-TE specific description of the extensions. A CR-LDP specific description can be found in [GMPLS-LDP]. A generic functional description is presented in [GMPLS-SIG]. Berger, Ashwood-Smith, editors [Page 1] Internet Draft draft-ietf-mpls-generalized-rsvp-te-00.txt November 2000 Contents 1 Introduction .............................................. 3 2 Label Related Formats .................................... 3 2.1 Generalized Label Request ................................ 3 2.1.1 Generalized Label Request with SONET/SDH Label Range ...... 4 2.1.2 Procedures ................................................ 4 2.1.3 Bandwidth Encoding ........................................ 5 2.2 Generalized Label ......................................... 5 2.2.1 Procedures ................................................ 6 2.3 Waveband Switching ........................................ 6 2.3.1 Procedures ................................................ 7 2.4 Suggested Label ........................................... 7 2.5 Label Set ................................................. 7 2.5.1 Procedures ................................................ 8 3 Bidirectional LSPs ........................................ 9 3.1 Procedures ................................................ 9 3.2 Contention Resolution ..................................... 10 4 Notification .............................................. 10 4.1 Notify Request Object ..................................... 10 4.1.1 Required Information ...................................... 11 4.1.2 Procedures ................................................ 11 4.2 Notify Message ............................................ 12 4.2.1 Required Information ...................................... 12 4.2.2 Procedures ................................................ 13 4.3 Removing State with a PathErr message ..................... 13 5 Explicit Label Control .................................... 14 5.1 Procedures ................................................ 15 6 RSVP Message Formats ...................................... 16 7 Acknowledgments ........................................... 17 8 Security Considerations ................................... 17 9 References ................................................ 18 10 Authors' Addresses ........................................ 18 Berger, Ashwood-Smith, editors [Page 2] Internet Draft draft-ietf-mpls-generalized-rsvp-te-00.txt November 2000 Changes from previous version: o Moved protocol specific details into two documents, one for RSVP-TE and one for CR-LDP. o Fixed bandwidth encodings o Revised Notify message format to disambiguate upstream and downstream notifications. o Minor text cleanup 1. Introduction Generalized MPLS extends MPLS from supporting packet (PSC) interfaces and switching to include support of three new classes of interfaces and switching: Time-Division Multiplex (TDM), Lambda Switch (LSC) and Fiber-Switch (FSC). A functional description of the extensions to MPLS signaling needed to support the new classes of interfaces and switching is provided in [GMPLS-SIG]. This document presents RSVP-TE specific formats and mechanisms needed to support all four classes of interfaces. CR-LDP extensions can be found in [GMPLS-LDP]. [GMPLS-SIG] should be viewed as a companion document to this document. The format of this document parallels [GMPLS-SIG]. In addition to the other features of Generalized MPLS, this document also defines RSVP-TE specific features to support rapid failure notification, see Section 4. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Label Related Formats This section defines formats for a generalized label request, a generalized label, support for waveband switching, suggested label and label sets. 2.1. Generalized Label Request A Path message SHOULD contain as specific an LSP Encoding Type as possible to allow the maximum flexibility in switching by transit LSRs. A Generalized Label Request object is set by the ingress node, transparently passed by transit nodes, and used by the egress node. Berger, Ashwood-Smith, editors [Page 3] Internet Draft draft-ietf-mpls-generalized-rsvp-te-00.txt November 2000 The format of a Generalized Label Request 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num (19)|C-Type (4)[TBA]| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP Enc. Type |Link Prot.Flags| G-PID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ See [GMPLS-SIG] for a description of parameters. 2.1.1. Generalized Label Request with SONET/SDH Label Range The format of a Generalized Label Request with SONET/SDH Label Range (in RSVP) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num (19)|C-Type (5)[TBA]| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP Enc. Type |Link Prot.Flags| G-PID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RGT | RT | Reserved | RNC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ See [GMPLS-SIG] for a description of parameters. 2.1.2. Procedures A node processing the Path message containing the Generalized Label Request must verify that the requested parameters can be satisfied by the incoming interface, the node and by the outgoing interface. The node may either directly support the LSP or it may use a tunnel (FA), i.e., another class of switching. In either case, each parameter must be checked. Note that local node policy dictates when tunnels may be used and when they may be created. Local policy may allow for tunnels to be dynamically established or may be solely administratively controlled. For more information on tunnels and processing of ER hops when using tunnels see [MPLS-HIERARCHY]. Transit and egress nodes MUST verify that the node itself and, where appropriate, that the outgoing interface or tunnel can support the Berger, Ashwood-Smith, editors [Page 4] Internet Draft draft-ietf-mpls-generalized-rsvp-te-00.txt November 2000 requested LSP Encoding Type. If encoding cannot be supported, the node MUST generate a PathErr message, with a "Routing problem/Unsupported Encoding" indication. Transit nodes MUST verify that the outgoing interface or tunnel can support the requested Link Protection Flags. If it cannot, the node MUST generate a PathErr message, with a "Routing problem/Unsupported Link Protection" indication. The G-PID parameter is normally only examined at the egress. If the indicated G-PID cannot be supported then the egress MUST generate a PathErr message, with a "Routing problem/Unsupported GPID" indication. In the case of PSC and when penultimate hop popping (PHP) is requested, the penultimate hop also examines the (stored) G- PID during the processing of the Resv message. In this case if the G-PID is not supported, then the penultimate hop MUST generate a ResvErr message with a "Routing problem/Unacceptable label value" indication. When an error message is not generated, normal processing occurs. In the transit case this will typically result in a Path message being propagated. In the egress case and PHP special case this will typically result in a Resv message being generated. 2.1.3. Bandwidth Encoding Bandwidth encodings are carried in the SENDER_TSPEC and FLOWSPEC objects. See [GMPLS-SIG] for a definition of values to be used for specific signal types. These values are set in the Peak Data Rate field of Int-Serv objects. Other bandwidth/service related parameters in the object are ignored and carried transparently. 2.2. Generalized Label The format of a Generalized Label 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num (16)| C-Type (2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Berger, Ashwood-Smith, editors [Page 5] Internet Draft draft-ietf-mpls-generalized-rsvp-te-00.txt November 2000 See [GMPLS-SIG] for a description of parameters and encoding of SDH, SONET, port, wavelength and other labels. 2.2.1. Procedures The Generalized Label travels in the upstream direction in Resv messages. The presence of both a generalized and normal label object in a Resv message is a protocol error and should treated as a malformed message by the recipient. The recipient of a Resv message containing a Generalized Label verifies that the values passed are acceptable. If the label is unacceptable then the recipient MUST generate a ResvErr message with a "Routing problem/MPLS label allocation failure" indication. 2.3. Waveband Switching Waveband switching uses the same format as the generalized label, see section 2.2. For compatibility reasons, a new RSVP c-type (3) is assigned for the Waveband Label. In the context of waveband switching, the generalized label has 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num (16)| C-Type (3) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Waveband Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ See [GMPLS-SIG] for a description of parameters. Berger, Ashwood-Smith, editors [Page 6] Internet Draft draft-ietf-mpls-generalized-rsvp-te-00.txt November 2000 2.3.1. Procedures The procedures defined in Section 2.2.1 apply to waveband switching. This includes generating a ResvErr message with a "Routing problem/MPLS label allocation failure" indication if any of the label fields are unrecognized or unacceptable. Additionally, when a waveband is switched to another waveband, it is possible that the wavelengths within the waveband will be mirrored about a center frequency. When this type of switching is employed, the start and end label in the waveband label object MUST be flipped before forwarding the label object with the new waveband Id. In this manner an egress/ingress LSR which receives a waveband label which has these values inverted, knows that it must also invert its egress association to pick up the proper wavelengths. Without this mechanism and with an odd number of mirrored switching operations, the egress LSRs will not know that an input wavelength of say L1 will emerge from the waveband tunnel as L100. This operation MUST be performed in both directions when a bidirectional waveband tunnel is being established. 2.4. Suggested Label The format of a suggested label is identical to a generalized label. It is used in Path messages. Suggested Label uses a new Class-Number (TBD of form 10bbbbbb) and the C-type of the label being suggested. Errors in received Suggested Labels MUST be ignored. This includes any received inconsistent or unacceptable values. 2.5. Label Set The Label_Set object uses a Class-Number TBA (of form 0bbbbbbb) and the C-type of the label type being described. Berger, Ashwood-Smith, editors [Page 7] Internet Draft draft-ietf-mpls-generalized-rsvp-te-00.txt November 2000 The format of a Label_Set 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num(TBA)| C-Type (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Label Type | Action | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subchannel 1 | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subchannel N | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label Type: 8 bits Indicates the type and format of the labels carried in the object. Values match the C-Type of the appropriate Label object. See [GMPLS-SIG] for a description of other parameters. 2.5.1. Procedures A Label Set is defined via one or more Label_Set objects. Specific labels/subchannels can be added to or excluded from a Label Set via Action zero (0) and one (1) objects respectively. Ranges of labels/subchannels can be added to or excluded from a Label Set via Action two (2) and three (3) objects respectively. When the Label_Set objects only list labels/subchannels to exclude, this implies that all other labels are acceptable. The absence of any Label_Set objects implies that all labels are acceptable. A Label Set is included when a node wishes to restrict the label(s) that may be used downstream. On reception of a Path message a CI-capable interface will restrict its choice of labels to one which is in the Label Set. The CI- capable receiver may also remove the Label Set prior to forwarding the Path message. If the node is unable to pick a label from the Label Set or if there is a problem parsing the Label_Set objects, then the request is terminated and a PathErr message with a "Routing Berger, Ashwood-Smith, editors [Page 8] Internet Draft draft-ietf-mpls-generalized-rsvp-te-00.txt November 2000 problem/Label Set" indication MUST be generated. It is a local matter if the Label Set is stored for later selection on the Resv or if the selection is made immediately for propagation in the Resv. On reception of a Path message for a CI-incapable interface, the Label Set represented in the message is compared against the set of available labels at the downstream interface and the resulting intersecting Label Set is forwarded in a Path message. When the resulting Label Set is empty, the Path must be terminated, and a PathErr message, and a "Routing problem/Label Set" indication MUST be generated. Note that intersection is based on the physical labels (actual wavelength/band values) which may have different logical values on different links, as a result it is the responsibility of the node to map these values so that they have a consistent physical meaning, or to drop the particular values from the set if no suitable logical label value exists. When processing a Resv message at an intermediate node, the label propagated upstream MUST fall within the Label Set. Note, on reception of a Resv message for an interface which is CI- incapable it has no other choice than to use the same physical label (wavelength/band) as received in the Resv. In this case, the use and propagation of a Label Set will significantly reduce the chances that this allocation will fail when CI-incapable nodes are traversed. 3. Bidirectional LSPs Bidirectional LSP setup is indicated by the presence of an Upstream Label in the Path message. An Upstream Label has the same format as the generalized label, see Section 2.2. The Upstream Label uses Class-Number TBD (of form 0bbbbbbb) and the C-type of the label being suggested. 3.1. Procedures The process of establishing a bidirectional LSP follows the establishment of a unidirectional LSP with some additions. To support bidirectional LSPs an Upstream Label is added to the Path message. The Upstream Label MUST indicate a label that is valid for forwarding at the time the Path message is sent. When a Path message containing an Upstream Label is received, the receiver first verifies that the upstream label is acceptable. If the label is not acceptable, the receiver MUST issue a PathErr message with a "Routing problem/Unacceptable label value" indication. Berger, Ashwood-Smith, editors [Page 9] Internet Draft draft-ietf-mpls-generalized-rsvp-te-00.txt November 2000 An intermediate node must also allocate a label on the outgoing interface and establish internal data paths before filling in an outgoing Upstream Label and propagating the Path message. If an intermediate node is unable to allocate a label or internal resources, then it MUST issue a PathErr message with a "Routing problem/Label allocation failure" indication. Terminator nodes process Path messages as usual, with the exception that the upstream label can immediately be used to transport data traffic associated with the LSP upstream towards the initiator. When a bidirectional LSP is removed, both upstream and downstream labels are invalidated and it is no longer valid to send data using the associated labels. 3.2. Contention Resolution There are two additional contention resolution related considerations when controlling bidirectional LSPs setup via RSVP-TE. The first is that for the purposes of RSVP contention resolution, the node ID is the IP address used in the RSVP_HOP object. The second is that a neighbor's node ID might not be known when sending an initial Path message. When this case occurs, a node should suggest a label chosen at random from the available label space. 4. Notification This section defines three signaling extensions that modify error handling, enable expedited notification of failures and other events to nodes responsible for restoring failed LSPs. The first extension, the Notify Request object, identifies where event notifications are to be sent. The second, the Notify message, provides for general event notification. The final extension allows for the removal of Path state on handling of PathErr messages. 4.1. Notify Request Object Notifications may be sent via the Notify message defined below. The Notify Request object is used to request the generation of notifications. Notifications, i.e., the sending of a Notify message, may be requested in both the upstream and downstream directions. Berger, Ashwood-Smith, editors [Page 10] Internet Draft draft-ietf-mpls-generalized-rsvp-te-00.txt November 2000 4.1.1. Required Information The Notify Request Object may be carried in Path or Resv Messages, see Section 6. The NOTIFY_REQUEST Class-Number is TBA (of form 11bbbbbb). The format of a Notify Request 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num(TBD)| C-Type (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Notify Node Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv4 Notify Node Address: 32 bits The IP address of the node that should be notified when generating an error message. If a message contains multiple NOTIFY_REQUEST objects, only the first object is meaningful. Subsequent NOTIFY_REQUEST objects MAY be ignored and SHOULD NOT be propagated. 4.1.2. Procedures A Notify Request object may be inserted in Path or Resv messages to indicate the address of a node that should be notified of an LSP failure. As previously mentioned, notifications may be requested in both the upstream and downstream directions. Upstream notification is indicated via the inclusion of a Notify Request Object in the corresponding Path message. Downstream notification is indicated via the inclusion of a Notify Request Object in the corresponding Resv message. A node receiving a message containing a Notify Request object SHOULD store the Notify Node Address in the corresponding state block. If the node is a transit node, it SHOULD also included a Notify Request object in the outgoing Path or Resv message. The outgoing Notify Node Address MAY be updated based on local policy. Note that the inclusion of a Notify Request object does not guarantee that a Notify message will be generated. Berger, Ashwood-Smith, editors [Page 11] Internet Draft draft-ietf-mpls-generalized-rsvp-te-00.txt November 2000 4.2. Notify Message The Notify message provides a mechanism to inform non-adjacent nodes of LSP related events. Notify messages are only generated after a Notify Request object has been received. The Notify message differs from the currently defined error messages (i.e., PathErr and ResvErr messages of RSVP) in that it can be "targeted" to a node other than the immediate upstream or downstream neighbor and that it is a generalized notification mechanism. The Notify message does not replace existing error messages. The Notify message may be sent either (a) normally, where non-target nodes just forward the Notify message to the target node, similar to ResvConf processing in [RSVP]; or (b) encapsulated in a new IP header whose destination is equal to the target IP address. Regardless of the transmission mechanism, nodes receiving a Notify message not destined to the node forward the message, unmodified, towards the target. To support reliable delivery of the Notify message, an Ack Message [RSVP-RR] is used to acknowledge the receipt of a Notify Message. See [RSVP-RR] for details on reliable RSVP message delivery. 4.2.1. Required Information The Notify message is a generalized notification message. The IP destination address is set to the IP address of the intended receiver. The Notify message is sent without the router alert option. A single Notify message may contain notifications being sent, with respect to each listed session, both upstream and downstream. ::= [] ::= [ ] | ::= [...] ::= [...] The ERROR_SPEC object specifies the error and includes the IP address of either the node that detected the error or the link that has failed. See ERROR_SPEC definition in [RFC2205]. The MESSAGE_ID object is defined in [RSVP-RR]. Berger, Ashwood-Smith, editors [Page 12] Internet Draft draft-ietf-mpls-generalized-rsvp-te-00.txt November 2000 4.2.2. Procedures Notify messages are generated at nodes that detect an error that will trigger the generation of a PathErr or ResvErr message. If a PathErr message is to be generated and a Notify Request object has been received in the corresponding Path message, then a Notify message destined to the recorded node SHOULD be generated. If a ResvErr message is to be generated and a Notify Request object has been received in the corresponding Resv message, then a Notify message destined to the recorded node SHOULD be generated. As previously mentioned, a single error may generate a Notify message in both the upstream and downstream directions. Note a Notify message MUST NOT be generated unless an appropriate Notify Request object has been received. When generating Notify messages, a node SHOULD attempt to combine notifications being sent to the same Notify Node and that share the same ERROR_SPEC into a single Notify message. The means by which a node determines which information may be combined is implementation dependent. Implementations may use event, timer based or other approaches. If using a timer based approach, the implementation SHOULD allow the user to configure the interval over which notifications are combined. When using a timer based approach, a default "notification interval" of 1 ms SHOULD be used. Notify messages SHOULD be delivered using the reliable message delivery mechanisms defined in [RSVP-RR]. Upon receiving a Notify message, the Notify Node SHOULD send a corresponding Ack message. 4.3. Removing State with a PathErr message The PathErr message as defined in [RFC2205] is sent hop-by-hop to the source of the associated Path message. Intermediate nodes may inspect this message, but take no action upon it. In an environment where Path messages are routed according to an IGP and that route may change dynamically, this behavior is a fine design choice. However, when RSVP is used with explicit routes, it is often the case that errors can only be corrected at the source node or some other node further upstream. In order to clean up resources, the source must receive the PathErr and then either send a PathTear (or wait for the messages to timeout). This causes idle resources to be held longer than necessary increases control message load. In a situation where the control plane is attempting to recover from a serious outage, both the message load and the delay in freeing resources hamper the ability to rapidly reconverge. Berger, Ashwood-Smith, editors [Page 13] Internet Draft draft-ietf-mpls-generalized-rsvp-te-00.txt November 2000 The situation can be greatly improved by allowing state to be removed by intermediate nodes on certain error conditions. To facilitate this a new flag is defined in the ERROR_SPEC object. The two currently defined ERROR_SPEC objects (IPv4 and IPv6 error spec objects) each contain a one byte flag field. Within that field two flags are defined. This specification defines a third flag, 0x04, Path_State_Removed. The semantics of the Path_State_Removed flag are simply that the node forwarding the error message has removed the Path state associated with the PathErr. By default, the Path_State_Removed flag is always set to zero when generating or forwarding a PathErr message. A node which encounters an error MAY set this flag if the error results in the associated Path state being discarded. If the node setting the flag is not the session endpoint, the node SHOULD generate a corresponding PathTear. A node receiving a PathErr message containing an ERROR_SPEC object with the Path_State_Removed flag set MAY also remove the associated Path state. If the Path state is removed the Path_State_Removed flag SHOULD be set in the outgoing PathErr message. A node which does not remove the associated Path state MUST NOT set the Path_State_Removed flag. A node that receives an error with the Path_State_Removed flag set to zero MUST NOT set this flag unless it also generates a corresponding PathTear message. Note that the use of this flag does not result in any interoperability incompatibilities. 5. Explicit Label Control The Label ERO subobject is defined 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | Length |U| Reserved | C-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ See [GMPLS-SIG] for a description of L, U and Label parameters. Type 3 Label Berger, Ashwood-Smith, editors [Page 14] Internet Draft draft-ietf-mpls-generalized-rsvp-te-00.txt November 2000 Length The Length contains the total length of the subobject in bytes, including the Type and Length fields. The Length is always divisible by 4. C-Type The C-Type of the included Label Object. Copied from the Label Object. 5.1. Procedures The Label subobject follows a subobject containing the IP address, or the interface identifier [MPLS-UNNUM], associated with the link on which it is to be used. The preceding subobject must be a strict object. Up to two label subobjects may be present, one for the downstream label and one for the upstream label. The following SHOULD result in "Bad EXPLICIT_ROUTE object" errors: - If the first label subobject is not preceded by a subobject containing an IP address, or a interface identifier [MPLS-UNNUM], associated with an output link. - For a label subobject to follow a subobject that has the L-bit set - On unidirectional LSP setup, for there to be a label subobject with the U-bit set - For there to be two label subobjects with the same U-bit values To support the label subobject, a node must check to see if the subobject following it's associate address/interface is a label subobject. If it is, one subobject is examined for unidirectional LSPs and two subobjects for bidirectional LSPs. If the U-bit of the subobject being examined is clear (0), then value of the label is copied into a new Label_Set object. This Label_Set object MUST be included on the corresponding outgoing Path message. If the U-bit of the subobject being examined is set (1), then value of the label is label to be used for upstream traffic associated with the bidirectional LSP. If this label is not acceptable, a "Bad EXPLICIT_ROUTE object" error SHOULD be generated. If the label is acceptable, the label is copied into a new Upstream Label object. This Upstream Label object MUST be included on the corresponding outgoing Path message. After processing, the label subobjects are removed from the ERO. Note an implication of the above procedures is that the label Berger, Ashwood-Smith, editors [Page 15] Internet Draft draft-ietf-mpls-generalized-rsvp-te-00.txt November 2000 subobject should never be the first subobject in a newly received message. If the label subobject is the the first subobject an a received ERO, then it SHOULD be treated as a "Bad strict node" error. Procedures by which an LSR at the head-end of an LSP obtains the information needed to construct the Label subobject are outside the scope of this document. 6. RSVP Message Formats This section presents the RSVP message related formats as modified by this document. Where they differ, formats for unidirectional LSPs are presented separately from bidirectional LSPs. Unmodified formats are not listed. The format of a Path message is as follows: ::= [ ] [ ] [ ... ] [ ] [ ] [ ... ] The format of the sender description for unidirectional LSPs is: ::= [ ] [ ] [ ] The format of the sender description for bidirectional LSPs is: ::= [ ] [ ] [ ] Berger, Ashwood-Smith, editors [Page 16] Internet Draft draft-ietf-mpls-generalized-rsvp-te-00.txt November 2000 The format of a Resv message is as follows: ::= [ ] [ ] [ ] [ ] [ ... ]