idnits 2.17.1 draft-ietf-mpls-generalized-rsvp-te-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 11 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([GMPLS-LDP], [GMPLS-SIG]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: When a node is sending a Path or PathTear message to a node that it knows to be adjacent at the data plane (i.e. along the path of the LSP) it SHOULD address the message directly to an address associated with the adjacent node's control plane. In this case the router-alert option SHOULD not be included. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2001) is 8229 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RSVP' is mentioned on line 537, but not defined == Missing Reference: 'MPLS-TE' is mentioned on line 1026, but not defined ** Obsolete normative reference: RFC 2434 (ref. 'BCP26') (Obsoleted by RFC 5226) -- Possible downref: Normative reference to a draft: ref. 'MPLS-BUNDLE' == Outdated reference: A later version (-08) exists of draft-ietf-mpls-lsp-hierarchy-02 == Outdated reference: A later version (-08) exists of draft-ietf-mpls-rsvp-unnum-02 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-generalized-cr-ldp-01 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-signaling-02 -- Possible downref: Normative reference to a draft: ref. 'PAN-RESTART' == Outdated reference: A later version (-09) exists of draft-ietf-mpls-rsvp-lsp-tunnel-08 Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Peter Ashwood-Smith (Nortel Networks Corp.) 2 Internet Draft Ayan Banerjee (Calient Networks) 3 Expiration Date: April 2002 Lou Berger (Movaz Networks) 4 Greg Bernstein (Ciena Corporation) 5 John Drake (Calient Networks) 6 Yanhe Fan (Axiowave Networks) 7 Kireeti Kompella (Juniper Networks, Inc.) 8 Jonathan P. Lang (Calient Networks) 9 Fong Liaw (Zaffire Inc.) 10 Eric Mannie (EBONE) 11 Ping Pan (Juniper Networks, Inc.) 12 Bala Rajagopalan (Tellium, Inc.) 13 Yakov Rekhter (Juniper Networks, Inc.) 14 Debanjan Saha (Tellium, Inc.) 15 Vishal Sharma (Metanoia, Inc.) 16 George Swallow (Cisco Systems) 17 Z. Bo Tang (Tellium, Inc.) 19 October 2001 21 Generalized MPLS Signaling - RSVP-TE Extensions 23 draft-ietf-mpls-generalized-rsvp-te-05.txt 25 Status of this Memo 27 This document is an Internet-Draft and is in full conformance with 28 all provisions of Section 10 of RFC2026. Internet-Drafts are working 29 documents of the Internet Engineering Task Force (IETF), its areas, 30 and its working groups. Note that other groups may also distribute 31 working documents as Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 To view the current status of any Internet-Draft, please check the 39 "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow 40 Directory, see http://www.ietf.org/shadow.html. 42 Abstract 44 This document describes extensions to RSVP-TE signaling required to 45 support Generalized MPLS. Generalized MPLS extends MPLS to encompass 46 time-division (e.g. SONET ADMs), wavelength (optical lambdas) and 47 spatial switching (e.g. incoming port or fiber to outgoing port or 48 fiber). This document presents an RSVP-TE specific description of 49 the extensions. A CR-LDP specific description can be found in 50 [GMPLS-LDP]. A generic functional description is presented in 51 [GMPLS-SIG]. 53 Contents 55 1 Introduction ................................................ 4 56 2 Label Related Formats ...................................... 5 57 2.1 Generalized Label Request Object ............................ 5 58 2.2 Generalized Label Object .................................... 6 59 2.3 Waveband Switching .......................................... 7 60 2.4 Suggested Label ............................................. 8 61 2.5 Label Set ................................................... 8 62 3 Bidirectional LSPs .......................................... 10 63 3.1 Procedures .................................................. 10 64 3.2 Contention Resolution ....................................... 11 65 4 Notification ................................................ 11 66 4.1 Acceptable Label Set Object ................................. 12 67 4.2 Notify Request Objects ...................................... 12 68 4.3 Notify Message .............................................. 14 69 4.4 Removing State with a PathErr message ....................... 15 70 5 Explicit Label Control ...................................... 16 71 5.1 Label ERO subobject ......................................... 17 72 5.2 Label RRO subobject ......................................... 18 73 6 Protection Object ........................................... 19 74 6.1 Procedures .................................................. 20 75 7 Administrative Status Information ........................... 20 76 7.1 Admin Status Object ......................................... 20 77 7.2 Path and Resv Message Procedures ............................ 20 78 7.3 Notify Message Procedures ................................... 22 79 8 Control Channel Separation .................................. 23 80 8.1 Interface Identification .................................... 23 81 8.2 Errored Interface Identification ............................ 25 82 9 Fault Handling .............................................. 27 83 9.1 Restart_Cap Object .......................................... 27 84 9.2 Processing of Restart_Cap Object ............................ 28 85 9.3 Modification to Hello Processing to Support State Recovery .. 28 86 9.4 Control Channel Faults ...................................... 29 87 9.5 Nodal Faults ................................................ 29 88 10 RSVP Message Formats and Handling ........................... 32 89 10.1 RSVP Message Formats ........................................ 32 90 10.2 Addressing Path and PathTear Messages ...................... 34 91 11 Acknowledgments ............................................. 35 92 12 Security Considerations ..................................... 35 93 13 IANA Considerations ......................................... 35 94 14 References .................................................. 36 95 15 Authors' Addresses .......................................... 37 96 [Editor's note: changes to be removed prior to publication as an RFC.] 97 Changes from previous version: 99 o Revised Admin Status Usage 100 (per comments and also removed potential race condition) 101 o Clarified text related to interface bundling 102 (To be consistent with updated bundling draft.) 103 o Added IF_ID ERROR_SPEC Object 104 (Per comments, supports Control Channel Separation by allowing 105 identification of errored interface.) 106 o Added U bit to Label RRO subobject 107 (Per comment, to match defined ERO.) 108 o Clarified usage of Restart_Cap 109 o Replaced use of Suggested_Label during recovery with new Recovery_Label 110 (Per last WG session) 111 o Added IANA Considerations 112 o Minor editorial changes and clarifications 114 1. Introduction 116 Generalized MPLS extends MPLS from supporting packet (PSC) interfaces 117 and switching to include support of three new classes of interfaces 118 and switching: Time-Division Multiplex (TDM), Lambda Switch (LSC) and 119 Fiber-Switch (FSC). A functional description of the extensions to 120 MPLS signaling needed to support the new classes of interfaces and 121 switching is provided in [GMPLS-SIG]. This document presents RSVP-TE 122 specific formats and mechanisms needed to support all four classes of 123 interfaces. CR-LDP extensions can be found in [GMPLS-LDP]. 125 [GMPLS-SIG] should be viewed as a companion document to this 126 document. The format of this document parallels [GMPLS-SIG]. In 127 addition to the other features of Generalized MPLS, this document 128 also defines RSVP-TE specific features to support rapid failure 129 notification, see Sections 4.2 and 4.3. 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 2. Label Related Formats 137 This section defines formats for a generalized label request, a 138 generalized label, support for waveband switching, suggested label 139 and label sets. 141 2.1. Generalized Label Request Object 143 A Path message SHOULD contain as specific an LSP Encoding Type as 144 possible to allow the maximum flexibility in switching by transit 145 LSRs. A Generalized Label Request object is set by the ingress node, 146 transparently passed by transit nodes, and used by the egress node. 148 The format of a Generalized Label Request object is: 150 0 1 2 3 151 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 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Length | Class-Num (19)|C-Type (4)[TBA]| 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | LSP Enc. Type |Switching Type | G-PID | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 See [GMPLS-SIG] for a description of parameters. 160 2.1.1. Procedures 162 A node processing a Path message containing a Generalized Label 163 Request must verify that the requested parameters can be satisfied by 164 the interface on which the incoming label is to be allocated, the 165 node itself, and by the interface on which the traffic will be 166 transmitted. The node may either directly support the LSP or it may 167 use a tunnel (FA), i.e., another class of switching. In either case, 168 each parameter must be checked. 170 Note that local node policy dictates when tunnels may be used and 171 when they may be created. Local policy may allow for tunnels to be 172 dynamically established or may be solely administratively controlled. 173 For more information on tunnels and processing of ER hops when using 174 tunnels see [MPLS-HIERARCHY]. 176 Transit and egress nodes MUST verify that the node itself and, where 177 appropriate, that the interface or tunnel on which the traffic will 178 be transmitted can support the requested LSP Encoding Type. If 179 encoding cannot be supported, the node MUST generate a PathErr 180 message, with a "Routing problem/Unsupported Encoding" indication. 182 The G-PID parameter is normally only examined at the egress. If the 183 indicated G-PID cannot be supported then the egress MUST generate a 184 PathErr message, with a "Routing problem/Unsupported L3PID" 185 indication. In the case of PSC and when penultimate hop popping 186 (PHP) is requested, the penultimate hop also examines the (stored) G- 187 PID during the processing of the Resv message. In this case if the 188 G-PID is not supported, then the penultimate hop MUST generate a 189 ResvErr message with a "Routing problem/Unacceptable label value" 190 indication. The generated ResvErr message MAY include an Acceptable 191 Label Set, see Section 4.1. 193 When an error message is not generated, normal processing occurs. In 194 the transit case this will typically result in a Path message being 195 propagated. In the egress case and PHP special case this will 196 typically result in a Resv message being generated. 198 2.1.2. Bandwidth Encoding 200 Bandwidth encodings are carried in the SENDER_TSPEC and FLOWSPEC 201 objects. See [GMPLS-SIG] for a definition of values to be used for 202 specific signal types. These values are set in the Peak Data Rate 203 field of Int-Serv objects. Other bandwidth/service related 204 parameters in the object are ignored and carried transparently. 206 2.2. Generalized Label Object 208 The format of a Generalized Label object is: 210 0 1 2 3 211 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 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Length | Class-Num (16)| C-Type (2) | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Label | 216 | ... | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 See [GMPLS-SIG] for a description of parameters and encoding of 220 labels. 222 2.2.1. Procedures 224 The Generalized Label travels in the upstream direction in Resv 225 messages. 227 The presence of both a generalized and normal label object in a Resv 228 message is a protocol error and should treated as a malformed message 229 by the recipient. 231 The recipient of a Resv message containing a Generalized Label 232 verifies that the values passed are acceptable. If the label is 233 unacceptable then the recipient MUST generate a ResvErr message with 234 a "Routing problem/MPLS label allocation failure" indication. 236 2.3. Waveband Switching 238 Waveband switching uses the same format as the generalized label, see 239 section 2.2. For compatibility reasons, a new RSVP C-Type (3) is 240 assigned for the Waveband Label. 242 In the context of waveband switching, the generalized label has the 243 following format: 245 0 1 2 3 246 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 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Length | Class-Num (16)| C-Type (3) | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Waveband Id | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Start Label | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | End Label | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 See [GMPLS-SIG] for a description of parameters. 259 2.3.1. Procedures 261 The procedures defined in Section 2.2.1 apply to waveband switching. 262 This includes generating a ResvErr message with a "Routing 263 problem/MPLS label allocation failure" indication if any of the label 264 fields are unrecognized or unacceptable. 266 Additionally, when a waveband is switched to another waveband, it is 267 possible that the wavelengths within the waveband will be mirrored 268 about a center frequency. When this type of switching is employed, 269 the start and end label in the waveband label object MUST be flipped 270 before forwarding the label object with the new waveband Id. In this 271 manner an egress/ingress LSR which receives a waveband label which 272 has these values inverted, knows that it must also invert its egress 273 association to pick up the proper wavelengths. 275 This operation MUST be performed in both directions when a 276 bidirectional waveband tunnel is being established. 278 2.4. Suggested Label 280 The format of a Suggested_Label object is identical to a generalized 281 label. It is used in Path messages. A Suggested_Label object uses 282 Class-Number TBA (of form 10bbbbbb) and the C-Type of the label being 283 suggested. 285 Errors in received Suggested_Label objects MUST be ignored. This 286 includes any received inconsistent or unacceptable values. 288 Per [GMPLS-SIG], if a downstream node passes a label value that 289 differs from the suggested label upstream, the upstream LSR MUST 290 either reconfigure itself so that it uses the label specified by the 291 downstream node or generate a ResvErr message with a "Routing 292 problem/Unacceptable label value" indication. Furthermore, an 293 ingress node SHOULD NOT transmit data traffic using a suggested label 294 until the downstream node passes a corresponding label upstream. 296 2.5. Label Set 298 The Label_Set object uses Class-Number TBA (of form 0bbbbbbb) and the 299 C-Type of 1. It is used in Path messages. 301 The format of a Label_Set is: 303 0 1 2 3 304 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 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Length | Class-Num(TBA)| C-Type (1) | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Action | Reserved | Label Type | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Subchannel 1 | 311 | ... | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 : : : 314 : : : 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Subchannel N | 317 | ... | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 Label Type: 14 bits 322 Indicates the type and format of the labels carried in the 323 object. Values match the C-Type of the appropriate Label 324 object. Only the low order 8 bits are used in this field. 326 See [GMPLS-SIG] for a description of other parameters. 328 2.5.1. Procedures 330 A Label Set is defined via one or more Label_Set objects. Specific 331 labels/subchannels can be added to or excluded from a Label Set via 332 Action zero (0) and one (1) objects respectively. Ranges of 333 labels/subchannels can be added to or excluded from a Label Set via 334 Action two (2) and three (3) objects respectively. When the 335 Label_Set objects only list labels/subchannels to exclude, this 336 implies that all other labels are acceptable. 338 The absence of any Label_Set objects implies that all labels are 339 acceptable. A Label Set is included when a node wishes to restrict 340 the label(s) that may be used downstream. 342 On reception of a Path message, the receiving node will restrict its 343 choice of labels to one which is in the Label Set. Nodes capable of 344 performing label conversion may also remove the Label Set prior to 345 forwarding the Path message. If the node is unable to pick a label 346 from the Label Set or if there is a problem parsing the Label_Set 347 objects, then the request is terminated and a PathErr message with a 348 "Routing problem/Label Set" indication MUST be generated. It is a 349 local matter if the Label Set is stored for later selection on the 350 Resv or if the selection is made immediately for propagation in the 351 Resv. 353 On reception of a Path message, the Label Set represented in the 354 message is compared against the set of available labels at the 355 downstream interface and the resulting intersecting Label Set is 356 forwarded in a Path message. When the resulting Label Set is empty, 357 the Path must be terminated, and a PathErr message, and a "Routing 358 problem/Label Set" indication MUST be generated. Note that 359 intersection is based on the physical labels (actual wavelength/band 360 values) which may have different logical values on different links, 361 as a result it is the responsibility of the node to map these values 362 so that they have a consistent physical meaning, or to drop the 363 particular values from the set if no suitable logical label value 364 exists. 366 When processing a Resv message at an intermediate node, the label 367 propagated upstream MUST fall within the Label Set. 369 Note, on reception of a Resv message a node that is incapable of 370 performing label conversion has no other choice than to use the same 371 physical label (wavelength/band) as received in the Resv message. In 372 this case, the use and propagation of a Label Set will significantly 373 reduce the chances that this allocation will fail. 375 3. Bidirectional LSPs 377 Bidirectional LSP setup is indicated by the presence of an Upstream 378 Label in the Path message. An Upstream_Label object has the same 379 format as the generalized label, see Section 2.2. The Upstream_Label 380 object uses Class-Number TBA (of form 0bbbbbbb) and the C-Type of the 381 label being used. 383 3.1. Procedures 385 The process of establishing a bidirectional LSP follows the 386 establishment of a unidirectional LSP with some additions. To 387 support bidirectional LSPs an Upstream_Label object is added to the 388 Path message. The Upstream_Label object MUST indicate a label that 389 is valid for forwarding at the time the Path message is sent. 391 When a Path message containing an Upstream_Label object is received, 392 the receiver first verifies that the upstream label is acceptable. 393 If the label is not acceptable, the receiver MUST issue a PathErr 394 message with a "Routing problem/Unacceptable label value" indication. 395 The generated PathErr message MAY include an Acceptable Label Set, 396 see Section 4.1. 398 An intermediate node must also allocate a label on the outgoing 399 interface and establish internal data paths before filling in an 400 outgoing upstream label and propagating the Path message. If an 401 intermediate node is unable to allocate a label or internal 402 resources, then it MUST issue a PathErr message with a "Routing 403 problem/Label allocation failure" indication. 405 Terminator nodes process Path messages as usual, with the exception 406 that the upstream label can immediately be used to transport data 407 traffic associated with the LSP upstream towards the initiator. 409 When a bidirectional LSP is removed, both upstream and downstream 410 labels are invalidated and it is no longer valid to send data using 411 the associated labels. 413 3.2. Contention Resolution 415 There are two additional contention resolution related considerations 416 when controlling bidirectional LSP setup via RSVP-TE. The first is 417 that for the purposes of RSVP contention resolution, the node ID is 418 the IP address used in the RSVP_HOP object. The second is that a 419 neighbor's node ID might not be known when sending an initial Path 420 message. When this case occurs, a node should suggest a label chosen 421 at random from the available label space. 423 4. Notification 425 This section covers several notification related extensions. The 426 first extension defines the Acceptable Label Set object to support 427 Notification on Label Error, per [GMPLS-SIG]. The second and third 428 extensions enable expedited notification of failures and other events 429 to nodes responsible for restoring failed LSPs. (The second 430 extension, the Notify Request object, identifies where event 431 notifications are to be sent. The third extension, the Notify 432 message, provides for general event notification.) The final 433 notification related extension allows for the removal of Path state 434 on handling of PathErr messages. 436 4.1. Acceptable Label Set Object 438 Acceptable_Label_Set objects use a Class-Number TBA (of form 439 10bbbbbb). The remaining contents of the object, including C-Type, 440 have the identical format as the Label_Set object, see Section 2.5. 442 Acceptable_Label_Set objects may be carried in PathErr and ResvErr 443 messages. The procedures for defining an Acceptable Label Set follow 444 the procedures for defining a Label Set, see Section 2.5.1. 445 Specifically, an Acceptable Label Set is defined via one or more 446 Acceptable_Label_Set objects. Specific labels/subchannels can be 447 added to or excluded from an Acceptable Label Set via Action zero 448 (0) and one (1) objects respectively. Ranges of labels/subchannels 449 can be added to or excluded from an Acceptable Label Set via Action 450 two (2) and three (3) objects respectively. When the 451 Acceptable_Label_Set objects only list labels/subchannels to exclude, 452 this implies that all other labels are acceptable. 454 The inclusion of Acceptable_Label_Set objects is optional. If 455 included, the PathErr or ResvErr message SHOULD contain a "Routing 456 problem/Unacceptable label value" indication. The absence of 457 Acceptable_Label_Set objects does not have any specific meaning. 459 4.2. Notify Request Objects 461 Notifications may be sent via the Notify message defined below. The 462 Notify Request object is used to request the generation of 463 notifications. Notifications, i.e., the sending of a Notify message, 464 may be requested in both the upstream and downstream directions. 466 4.2.1. Required Information 468 The Notify Request Object may be carried in Path or Resv Messages, 469 see Section 7. The Notify_Request Class-Number is TBA (of form 470 11bbbbbb). The format of a Notify Request is: 472 o IPv4 Notify Request Object 473 0 1 2 3 474 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 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | Length | Class-Num(TBA)| C-Type (1) | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | IPv4 Notify Node Address | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 IPv4 Notify Node Address: 32 bits 482 The IP address of the node that should be notified when 483 generating an error message. 485 o IPv6 Notify Request Object 486 0 1 2 3 487 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 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Length | Class-Num(TBA)| C-Type (2) | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | | 492 | IPv6 Notify Node Address | 493 | | 494 | | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 IPv6 Notify Node Address: 16 bytes 499 The IP address of the node that should be notified when 500 generating an error message. 502 If a message contains multiple Notify_Request objects, only the first 503 object is meaningful. Subsequent Notify_Request objects MAY be 504 ignored and SHOULD NOT be propagated. 506 4.2.2. Procedures 508 A Notify Request object may be inserted in Path or Resv messages to 509 indicate the address of a node that should be notified of an LSP 510 failure. As previously mentioned, notifications may be requested in 511 both the upstream and downstream directions. Upstream notification is 512 indicated via the inclusion of a Notify Request Object in the 513 corresponding Path message. Downstream notification is indicated via 514 the inclusion of a Notify Request Object in the corresponding Resv 515 message. 517 A node receiving a message containing a Notify Request object SHOULD 518 store the Notify Node Address in the corresponding state block. If 519 the node is a transit node, it SHOULD also included a Notify Request 520 object in the outgoing Path or Resv message. The outgoing Notify 521 Node Address MAY be updated based on local policy. 523 Note that the inclusion of a Notify Request object does not guarantee 524 that a Notify message will be generated. 526 4.3. Notify Message 528 The Notify message provides a mechanism to inform non-adjacent nodes 529 of LSP related events. Notify messages are normally generated only 530 after a Notify Request object has been received. The Notify message 531 differs from the currently defined error messages (i.e., PathErr and 532 ResvErr messages) in that it can be "targeted" to a node other than 533 the immediate upstream or downstream neighbor and that it is a 534 generalized notification mechanism. The Notify message does not 535 replace existing error messages. The Notify message may be sent 536 either (a) normally, where non-target nodes just forward the Notify 537 message to the target node, similar to ResvConf processing in [RSVP]; 538 or (b) encapsulated in a new IP header whose destination is equal to 539 the target IP address. Regardless of the transmission mechanism, 540 nodes receiving a Notify message not destined to the node forward the 541 message, unmodified, towards the target. 543 To support reliable delivery of the Notify message, an Ack Message 544 [RSVP-RR] is used to acknowledge the receipt of a Notify Message. 545 See [RSVP-RR] for details on reliable RSVP message delivery. 547 4.3.1. Required Information 549 The Notify message is a generalized notification message. The IP 550 destination address is set to the IP address of the intended 551 receiver. The Notify message is sent without the router alert 552 option. A single Notify message may contain notifications being 553 sent, with respect to each listed session, both upstream and 554 downstream. 556 The Notify message has a Message Type of TBA (by IANA). The Notify 557 message format is as follows: 559 ::= [] 560 [ [ | ] ... ] 561 [ ] 562 564 ::= [ ] 565 | 566 568 ::= [ ] 569 [...] 570 572 ::= [...] 573 575 The ERROR_SPEC object specifies the error and includes the IP address 576 of either the node that detected the error or the link that has 577 failed. See ERROR_SPEC definition in [RFC2205]. The MESSAGE_ID and 578 related objects are defined in [RSVP-RR] and are used when refresh 579 reductions is supported. 581 4.3.2. Procedures 583 Notify messages are most commonly generated at nodes that detect an 584 error that will trigger the generation of a PathErr or ResvErr 585 message. If a PathErr message is to be generated and a Notify 586 Request object has been received in the corresponding Path message, 587 then a Notify message destined to the recorded node SHOULD be 588 generated. If a ResvErr message is to be generated and a Notify 589 Request object has been received in the corresponding Resv message, 590 then a Notify message destined to the recorded node SHOULD be 591 generated. As previously mentioned, a single error may generate a 592 Notify message in both the upstream and downstream directions. Note 593 that a Notify message MUST NOT be generated unless an appropriate 594 Notify Request object has been received. 596 When generating Notify messages, a node SHOULD attempt to combine 597 notifications being sent to the same Notify Node and that share the 598 same ERROR_SPEC into a single Notify message. The means by which a 599 node determines which information may be combined is implementation 600 dependent. Implementations may use event, timer based or other 601 approaches. If using a timer based approach, the implementation 602 SHOULD allow the user to configure the interval over which 603 notifications are combined. When using a timer based approach, a 604 default "notification interval" of 1 ms SHOULD be used. Notify 605 messages SHOULD be delivered using the reliable message delivery 606 mechanisms defined in [RSVP-RR]. 608 Upon receiving a Notify message, the Notify Node SHOULD send a 609 corresponding Ack message. 611 4.4. Removing State with a PathErr message 613 The PathErr message as defined in [RFC2205] is sent hop-by-hop to the 614 source of the associated Path message. Intermediate nodes may 615 inspect this message, but take no action upon it. In an environment 616 where Path messages are routed according to an IGP and that route may 617 change dynamically, this behavior is a fine design choice. 619 However, when RSVP is used with explicit routes, it is often the case 620 that errors can only be corrected at the source node or some other 621 node further upstream. In order to clean up resources, the source 622 must receive the PathErr and then either send a PathTear (or wait for 623 the messages to timeout). This causes idle resources to be held 624 longer than necessary and increases control message load. In a 625 situation where the control plane is attempting to recover from a 626 serious outage, both the message load and the delay in freeing 627 resources hamper the ability to rapidly reconverge. 629 The situation can be greatly improved by allowing state to be removed 630 by intermediate nodes on certain error conditions. To facilitate 631 this a new flag is defined in the ERROR_SPEC object. The two 632 currently defined ERROR_SPEC objects (IPv4 and IPv6 error spec 633 objects) each contain a one byte flag field. Within that field two 634 flags are defined. This specification defines a third flag, 0x04, 635 Path_State_Removed. 637 The semantics of the Path_State_Removed flag are simply that the node 638 forwarding the error message has removed the Path state associated 639 with the PathErr. By default, the Path_State_Removed flag is always 640 set to zero when generating or forwarding a PathErr message. A node 641 which encounters an error MAY set this flag if the error results in 642 the associated Path state being discarded. If the node setting the 643 flag is not the session endpoint, the node SHOULD generate a 644 corresponding PathTear. A node receiving a PathErr message 645 containing an ERROR_SPEC object with the Path_State_Removed flag set 646 MAY also remove the associated Path state. If the Path state is 647 removed the Path_State_Removed flag SHOULD be set in the outgoing 648 PathErr message. A node which does not remove the associated Path 649 state MUST NOT set the Path_State_Removed flag. A node that receives 650 an error with the Path_State_Removed flag set to zero MUST NOT set 651 this flag unless it also generates a corresponding PathTear message. 653 Note that the use of this flag does not result in any 654 interoperability incompatibilities. 656 5. Explicit Label Control 658 The Label ERO and RRO subobjects are defined to support Explicit 659 Label Control. Note that the Label RRO subobject was defined in 660 [RSVP-TE] and is being revised to support bidirectional LSPs. 662 5.1. Label ERO subobject 664 The Label ERO subobject is defined as follows: 666 0 1 2 3 667 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 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 |L| Type | Length |U| Reserved | C-Type | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | Label | 672 | ... | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 See [GMPLS-SIG] for a description of L, U and Label parameters. 677 Type 679 3 Label 681 Length 683 The Length contains the total length of the subobject in bytes, 684 including the Type and Length fields. The Length is always 685 divisible by 4. 687 C-Type 689 The C-Type of the included Label Object. Copied from the Label 690 Object. 692 5.1.1. Procedures 694 The Label subobject follows a subobject containing the IP address, or 695 the interface identifier [MPLS-UNNUM], associated with the link on 696 which it is to be used. The preceding subobject must be a strict 697 object. Up to two label subobjects may be present, one for the 698 downstream label and one for the upstream label. The following 699 SHOULD result in "Bad EXPLICIT_ROUTE object" errors: 700 - If the first label subobject is not preceded by a subobject 701 containing an IP address, or a interface identifier 702 [MPLS-UNNUM], associated with an output link. 703 - For a label subobject to follow a subobject that has the L-bit 704 set 705 - On unidirectional LSP setup, for there to be a label subobject 706 with the U-bit set 707 - For there to be two label subobjects with the same U-bit values 709 To support the label subobject, a node must check to see if the 710 subobject following its associate address/interface is a label 711 subobject. If it is, one subobject is examined for unidirectional 712 LSPs and two subobjects for bidirectional LSPs. If the U-bit of the 713 subobject being examined is clear (0), then value of the label is 714 copied into a new Label_Set object. This Label_Set object MUST be 715 included on the corresponding outgoing Path message. 717 If the U-bit of the subobject being examined is set (1), then value 718 of the label is label to be used for upstream traffic associated with 719 the bidirectional LSP. If this label is not acceptable, a "Bad 720 EXPLICIT_ROUTE object" error SHOULD be generated. If the label is 721 acceptable, the label is copied into a new Upstream_Label object. 722 This Upstream_Label object MUST be included on the corresponding 723 outgoing Path message. 725 After processing, the label subobjects are removed from the ERO. 727 Note an implication of the above procedures is that the label 728 subobject should never be the first subobject in a newly received 729 message. If the label subobject is the the first subobject an a 730 received ERO, then it SHOULD be treated as a "Bad strict node" error. 732 Procedures by which an LSR at the head-end of an LSP obtains the 733 information needed to construct the Label subobject are outside the 734 scope of this document. 736 5.2. Label RRO subobject 738 The Label RRO subobject is defined as follows: 740 0 1 2 3 741 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 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | Type | Length |U| Flags | C-Type | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | Label | 746 | ... | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 See [GMPLS-SIG] for a description of U and Label parameters. 751 Type 753 3 Label 755 Length 757 See [RSVP-TE]. 759 Flags 761 See [RSVP-TE]. 763 C-Type 765 The C-Type of the included Label Object. Copied from the Label 766 Object. 768 5.2.1. Procedures 770 Label RRO subobjects are included in RROs as described in [RSVP-TE]. 771 The only modification to usage and processing from [RSVP-TE] is that 772 when labels are recorded for bidirectional LSPs, label ERO subobjects 773 for both downstream and upstream labels MUST be included. 775 6. Protection Object 777 The use of the Protection Object is optional. The object is included 778 to indicate specific protection attributes of an LSP. The Protection 779 Object uses Class-Number TBA (of form 0bbbbbbb). 781 The format of the Protection Object is: 783 0 1 2 3 784 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 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | Length | Class-Num(TBA)| C-Type (1) | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 |S| Reserved | Link Flags| 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 See [GMPLS-SIG] for a description of parameters. 793 6.1. Procedures 795 Transit nodes processing a Path message containing a Protection 796 Object MUST verify that the requested protection can be satisfied by 797 the outgoing interface or tunnel (FA). If it cannot, the node MUST 798 generate a PathErr message, with a "Routing problem/Unsupported Link 799 Protection" indication. 801 7. Administrative Status Information 803 Administrative Status Information is carried in the Admin_Status 804 object. The object provides information related to the 805 administrative state of a particular LSP. The information is used in 806 two ways. In the first, the object is carried in Path and Resv 807 messages to indicate the administrative state of an LSP. In the 808 second, the object is carried in a Notification message to request 809 that the ingress node change the administrative state of an LSP. 811 7.1. Admin Status Object 813 The use of the Admin_Status Object is optional. It uses Class-Number 814 TBA (of form 11bbbbbb). 816 The format of the Admin_Status Object is: 818 0 1 2 3 819 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 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | Length | Class-Num(TBA)| C-Type (1) | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 |R| Reserved |T|A|D| 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 See [GMPLS-SIG] for a description of parameters. 828 7.2. Path and Resv Message Procedures 830 The Admin_Status object is used to notify each node along the path of 831 the status of the LSP. Status information is processed by each node 832 based on local policy and then propagated in the corresponding 833 outgoing messages. The object may be inserted in either Path or Resv 834 messages at the discretion of the ingress (for Path messages) or 835 egress (for Resv messages) nodes. The absence of the object is 836 equivalent to receiving an object containing values all set to zero 837 (0). 839 Transit nodes receiving a non-refresh Path or Resv message containing 840 an Admin_Status object, update their local state, take any 841 appropriate local action based on the indicated status and then 842 propagate the received Admin_Status object in the corresponding 843 outgoing Path or Resv message. If the values of an Admin_Status 844 object received in a Resv message differs from the values received in 845 a Path message then, with one exception, no local action should be 846 taken but the values should still be propagated. The one case where 847 values received in the Resv message should result in local action is 848 when both the received R and D bits are set, i.e., are one (1). 850 Edge nodes receiving a non-refresh Path or Resv message containing an 851 Admin_Status object, also update their local state and take any 852 appropriate local action based on the indicated status. When an 853 Admin Status object is received with the R bit set, the receiving 854 edge node should reflect the received values in a corresponding 855 outgoing message. Specifically, if an egress node receives a Path 856 message with the R bit of the Admin_Status object set and the node 857 has previously issued a Resv message corresponding to the Path 858 message, the node SHOULD send an updated Resv message containing an 859 Admin_Status object with the same values set, with the exception of 860 the R bit, as received in the corresponding Path message. 861 Furthermore, the egress node SHOULD also ensure that subsequent Resv 862 messages sent by the node contain the same Admin Status Object. 863 Additionally, if an ingress node receives a Resv message with the R 864 bit of the Admin_Status object set, the node SHOULD send an updated 865 Path message containing an Admin_Status object with the same values 866 set, with the exception of the R bit, as received in the 867 corresponding Resv message. Furthermore, the ingress node SHOULD 868 also ensure that subsequent Path messages sent by the node contain 869 the same Admin Status Object. 871 7.2.1. Deletion procedure 873 In some circumstances, particularly optical networks, it is useful to 874 set the administrative status of an LSP before tearing it down. In 875 such circumstances the procedure SHOULD be followed when deleting an 876 LSP from the ingress: 878 1. The ingress node precedes an LSP deletion by inserting an Admin 879 Status Object in a Path message and setting the Reflect (R) and 880 Delete (D) bits. 882 2. Transit and egress nodes process the Admin Status Object as 883 described above. (Alternatively, the egress MAY respond with 884 a PathErr message with the Path_State_Removed flag set, see 885 section 4.4.) 887 3. Upon receiving the Admin Status Object with the Delete (D) bit set 888 in the Resv message, the ingress node sends a PathTear message 889 downstream to remove the LSP and normal RSVP processing takes place. 891 In such circumstances the procedure SHOULD be followed when deleting 892 an LSP from the egress: 894 1. The egress node indicates its desire for deletion by inserting 895 an Admin Status Object in a Resv message and setting the Reflect (R) 896 and Delete (D) bits. 898 2. Transit nodes process the Admin Status Object as described above. 900 3. Upon receiving the Admin Status Object with the Delete (D) bit set 901 in the Resv message, the ingress node sends a PathTear message 902 downstream to remove the LSP and normal RSVP processing takes place. 904 7.2.2. Compatibility and Error Procedures 906 It is possible that some nodes along an LSP will not support the 907 Admin Status Object. In the case of a non-supporting transit node, 908 the object will pass through the node unmodified and normal 909 processing can continue. In the case of a non-supporting egress 910 node, the Admin Status Object will not be reflected back in the Resv 911 Message. To support the case of a non-supporting egress node, the 912 ingress SHOULD only wait a configurable period of time for the 913 updated Admin Status Object in a Resv message. Once the period of 914 time has elapsed, the ingress node sends a PathTear message. By 915 default this period of time SHOULD be 30 seconds. 917 7.3. Notify Message Procedures 919 Intermediate and egress nodes may trigger the setting of 920 administrative status via the use of Notify messages. To accomplish 921 this, an intermediate or egress node generates a Notify message with 922 the corresponding upstream notify session information. The Admin 923 Status Object MUST be included in the session information, with the 924 appropriate bit or bits set. The Reflect (R) bit MUST NOT be set. 925 The Notify message may be, but is not required to be, encapsulated, 926 see Section 4.3. 928 An ingress node receiving a Notify message containing an Admin Status 929 Object with the Delete (D) bit set, SHOULD initiate the deletion 930 procedure described in the previous section. Other bits SHOULD be 931 propagated in an outgoing Path message as normal. 933 7.3.1. Compatibility and Error Procedures 935 Some special processing is required in order to cover the case of 936 nodes that do not support the Admin Status Object and other error 937 conditions. Specifically, a node that sends a Notify message 938 containing an Admin Status Object with the Down (D) bit set MUST 939 verify that it receives a corresponding Path message with the Down 940 (D) bit set within a configurable period of time. By default this 941 period of time SHOULD be 30 seconds. If the node does not receive 942 such a Path message, it SHOULD send a PathTear message downstream and 943 either a ResvTear message or a PathErr message with the 944 Path_State_Removed flag set upstream. 946 8. Control Channel Separation 948 This section provides the protocol specific formats and procedures to 949 required support a control channel not being in-band with a data 950 channel. 952 8.1. Interface Identification 954 The choice of the data interface to use is always made by the sender 955 of the Path message. The choice of the data interface is indicated by 956 the sender of the Path message by including the data channel's 957 interface identifier in the message using a new RSVP_HOP object sub- 958 type. For bidirectional LSPs, the sender chooses the data interface 959 in each direction. In all cases but bundling, see [MPLS-BUNDLE], the 960 upstream interface is implied by the downstream interface. For 961 bundling, the path sender explicitly identifies the component 962 interface used in each direction. The new RSVP_HOP object is used in 963 Resv message to indicate the downstream node's usage of the indicated 964 interface(s). 966 8.1.1. IF_ID RSVP_HOP Objects 968 The format of the IPv4 IF_ID RSVP_HOP Object is: 970 0 1 2 3 971 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 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 | Length | Class-Num (3) | C-Type (3)TBA | 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 | IPv4 Next/Previous Hop Address | 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 | Logical Interface Handle | 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 | | 980 ~ TLVs ~ 981 | | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 The format of the IPv6 IF_ID RSVP_HOP Object is: 986 0 1 2 3 987 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 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 | Length | Class-Num (3) | C-Type (4)TBA | 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 | | 992 | IPv6 Next/Previous Hop Address | 993 | | 994 | | 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 | Logical Interface Handle | 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 | | 999 ~ TLVs ~ 1000 | | 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1003 See [RFC2205] for a description of hop address and handle fields. 1004 See [GMPLS-SIG] for a description of parameters and encoding of 1005 TLVs. 1007 8.1.2. Procedures 1009 An IF_ID RSVP_HOP object is used in place of previously defined 1010 RSVP_HOP objects. It is used on links where there is not a one-to- 1011 one association of a control channel to a data channel, see [GMPLS- 1012 SIG]. The Hop Address and Logical Interface Handle fields are used 1013 per standard RSVP [RFC2205]. 1015 TLVs are used to identify the data channel(s) associated with the 1016 LSP. For a unidirectional LSP, a forward channel MUST be indicated. 1017 For a bidirectional LSP that uses bundled links, a reverse channel 1018 MUST be indicated. Data channels are specified from the view point 1019 of the sender of the Path message. The IF_ID RSVP_HOP object SHOULD 1020 NOT be used when no TLVs are needed. 1022 A node receiving one or more TLVs in a Path message saves their 1023 values and returns them in the HOP objects of subsequent Resv 1024 messages sent to the node that originated the TLVs. 1026 As with [MPLS-TE], the node originating an IF_ID object must ensure 1027 that the selected outgoing interface is consistent with the outgoing 1028 ERO. A node that receives an IF_ID object SHOULD check whether the 1029 information carried in this object is consistent with the information 1030 carried in a received ERO, and if not it MUST send a PathErr with the 1031 error code "Routing Error" and error value of "Bad Explicit Route 1032 Object" toward the sender. 1034 8.2. Errored Interface Identification 1036 There are cases where it is useful to indicate a specific interface 1037 associated with an error. To support these cases the IF_ID 1038 ERROR_SPEC Objects are defined. 1040 8.2.1. IF_ID ERROR_SPEC Objects 1042 The format of the IPv4 IF_ID ERROR_SPEC Object is: 1044 0 1 2 3 1045 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 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 | Length | Class-Num (6) | C-Type (3)TBA | 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 | IPv4 Error Node Address | 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 | Flags | Error Code | Error Value | 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 | | 1054 ~ TLVs ~ 1055 | | 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1058 The format of the IPv6 IF_ID ERROR_SPEC Object is: 1060 0 1 2 3 1061 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 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 | Length | Class-Num (6) | C-Type (4)TBA | 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | | 1066 | IPv6 Error Node Address | 1067 | | 1068 | | 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 | Flags | Error Code | Error Value | 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 | | 1073 ~ TLVs ~ 1074 | | 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 See [RFC2205] for a description of address, flags, error code and 1078 error value fields. See [GMPLS-SIG] for a description of 1079 parameters and encoding of TLVs.n 1081 8.2.2. Procedures 1083 Nodes wishing to indicate that an error is related to a specific 1084 interface SHOULD use the appropriate IF_ID ERROR_SPEC Object in the 1085 corresponding PathErr or ResvErr message. IF_ID ERROR_SPEC Objects 1086 SHOULD be generated and processed as any other ERROR_SPEC Object, see 1087 [RFC2205]. 1089 9. Fault Handling 1091 The handling of two types of control communication faults is 1092 described in this section. The first, referred to as nodal faults, 1093 relates to the case where a node losses its control state (e.g., 1094 after a restart) but does not loose its data forwarding state. In 1095 the second, referred to as control channel faults, relates to the 1096 case where control communication is lost between two nodes. The 1097 handling of both faults is supported by the Restart_Cap object 1098 defined below and require the use of Hello messages. 1100 Note, the Restart_Cap object MUST NOT be sent when there is no 1101 mechanism to detect data channel failures independent of control 1102 channel failures. 1104 Please note this section is derived from [PAN-RESTART]. 1106 9.1. Restart_Cap Object 1108 The Restart_Cap Object is carried in Hello messages. 1110 The format of the Restart_Cap Object is: 1112 0 1 2 3 1113 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 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 | Length | Class-Num(TBA)| C-Type (1) | 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 | Restart Time | 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 | Recovery Time | 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 Restart Time: 32 bits 1123 Restart Time is measured in milliseconds. Restart Time SHOULD 1124 be set to the sum of the time it takes the sender of the object 1125 to restart its RSVP-TE component (to the point where it can 1126 exchange RSVP Hello with its neighbors) and the communication 1127 channel that is used for RSVP communication. 1129 Recovery Time: 32 bits 1131 The period of time, in milliseconds, that the sender desires 1132 for the recipient to resyncronize RSVP and MPLS forwarding 1133 state with the sender after the re-establishment of Hello 1134 synchronization. A value of zero (0) indicates that MPLS 1135 forwarding state was not preserved across a particular reboot. 1136 A value of 0xffffffff indicates that resynchronization may 1137 occur at a rate selected by the receiver. 1139 9.2. Processing of Restart_Cap Object 1141 Nodes supporting state recovery advertise this capability by carrying 1142 the Restart_Cap object in Hello messages. Such nodes MUST include 1143 the Restart_Cap object in all Hello messages. (Note that this 1144 includes Hello messages containing ACK objects.) Usage of the 1145 special case Recovery Time values is described in greater detail 1146 below. 1148 When a node receives a Hello message with the Restart_Cap object, it 1149 SHOULD record the values of the parameters received. 1151 9.3. Modification to Hello Processing to Support State Recovery 1153 When a node determines that RSVP communication with a neighbor has 1154 been lost, and the node previously learned that the neighbor supports 1155 state recovery, the node SHOULD wait at least the amount of time 1156 indicated by the Restart Time indicated by the neighbor before 1157 invoking procedures related to communication loss. A node MAY wait 1158 longer based on local policy or configuration information. 1160 During this waiting period, all Hello messages MUST be sent with a 1161 Dst_Instance value set to zero (0), and Src_Instance should be 1162 unchanged. While waiting, the node SHOULD also preserve the RSVP and 1163 MPLS forwarding state for (already) established LSPs that traverse 1164 the link(s) between the node and the neighbor. In a sense with 1165 respect to established LSPs the node behaves as if it continues to 1166 receive periodic RSVP refresh messages from the neighbor. The node 1167 MAY clear RSVP and forwarding state for the LSPs that are in the 1168 process of being established when their refresh timers expire. 1169 Refreshing of Resv and Path state SHOULD be suppressed during this 1170 waiting period. 1172 During this waiting period, the node MAY inform other nodes of the 1173 communication loss via a PathErr and/or upstream Notify message with 1174 "Control Channel Degraded State" indication. If such notification 1175 has been sent, then upon restoration of the control channel the node 1176 MUST inform other nodes of the restoration via a PathErr and/or 1177 upstream Notify message with "Control Channel Active State" 1178 indication. (Specific error codes are to be assigned IANA.) 1180 When a new Hello message is received from the neighbor, the node must 1181 determine if the fault was limited to the control channel or was a 1182 nodal fault. This determination is based on the Src_Instance 1183 received from the neighbor. If the value is different than the value 1184 that was received from the neighbor prior to the fault, then the 1185 neighbor should be treated as if it has restarted. Otherwise, the 1186 the fault was limited control channel. Procedures for handling each 1187 case are described below. 1189 9.4. Control Channel Faults 1191 In the case of control channel faults, the node SHOULD refresh all 1192 state shared with the neighbor. Summary Refreshes [RSVP-RR] with the 1193 ACK_Desired flag set SHOULD be used, if supported. Note that if a 1194 large number of messages are need, some pacing should be applied. 1195 All state SHOULD be refreshed within the Recovery time advertised by 1196 the neighbor. 1198 9.5. Nodal Faults 1200 Recovering from nodal faults uses one new object and other existing 1201 protocol messages and objects. 1203 9.5.1. Recovery Label 1205 The Recovery_Label object is used during the nodal fault recovery 1206 process. The format of a Recovery_Label object is identical to a 1207 generalized label. A Recovery_Label object uses Class-Number TBA (of 1208 form 0bbbbbbb) and the C-Type of the label being suggested. 1210 9.5.2. Procedures for the Restarting node 1212 After a node restarts its control plane, a node that supports state 1213 recovery SHOULD check whether it was able to preserve its MPLS 1214 forwarding state. If no forwarding state from prior to the restart 1215 was preserved, then the node MUST set the Recovery Time to 0 in the 1216 Hello message the node sends to its neighbors. 1218 If the forwarding state was preserved, then the node initiates the 1219 state recovery process. The period during which a node is prepared 1220 to support the recovery process is referred to as the Recovery 1221 Period. The total duration of the Recovery Period is advertised by 1222 the recovering node in the Recovery Time parameter of the Restart_Cap 1223 object. The Recovery Time MUST be set to the duration of the 1224 Recovery Period in all Hello messages sent during the Recovery 1225 Period. A Recovery Time value of 0xffffffff indicates that the 1226 Recovery Period is effectively infinite. State that is not 1227 resynchronized during the Recovery Period SHOULD be removed at the 1228 end of the Period. 1230 Note that if during Hello synchronization the restarting node 1231 determines that a neighbor does not support state recovery, and the 1232 restarting node maintains its MPLS forwarding state on a per neighbor 1233 basis, the restarting node should immediately consider the Recovery 1234 Period with that neighbor completed. Note forwarding state can be 1235 considered to be maintained on a per neighbor basis when per 1236 interface labels are used on point-to-point interfaces. 1238 When a node receives a Path message during the Recovery Period, the 1239 node first checks if it has an RSVP state associated with the 1240 message. If the state is found, then the node handles this message 1241 according to previously defined procedures. 1243 If the RSVP state is not found, and the message does not carry a 1244 Recovery_Label object, the node treats this as a setup for a new LSP, 1245 and handles it according to previously defined procedures. 1247 If the RSVP state is not found, and the message carries a 1248 Recovery_Label object, the node searches its MPLS forwarding table 1249 (the one that was preserved across the restart) for an entry whose 1250 incoming interface matches the Path message and whose incoming label 1251 is equal to the label carried in the Recovery_Label object. 1253 If the MPLS forwarding table entry is not found, the node treats this 1254 as a setup for a new LSP, and handles it according to previously 1255 defined procedures. 1257 If the MPLS forwarding table entry is found, the appropriate RSVP 1258 state is created, the entry is bound to the LSP associated with the 1259 message, and related forwarding state should be considered as valid 1260 and refreshed. Normal Path message processing should also be 1261 conducted. When sending the corresponding outgoing Path message the 1262 node SHOULD include a Suggested_Label object with a label value 1263 matching the outgoing label from the now restored forwarding entry. 1264 The outgoing interface SHOULD also be selected based on the 1265 forwarding entry. 1267 Additionally, for bidirectional LSPs, the node extracts the label 1268 from the UPSTREAM_LABEL object carried in the received Path message, 1269 and searches its MPLS forwarding table for an entry whose outgoing 1270 label is equal to the label carried in the object (in the case of 1271 link bundling, this may also involved first identifying the 1272 appropriate incoming component link). 1274 If the MPLS forwarding table entry is not found, the node treats this 1275 as a setup for a new LSP, and handles it according to previously 1276 defined procedures. 1278 If the MPLS forwarding table entry is found, the entry is bound to 1279 the LSP associated with the Path message, and the entry should be 1280 considered to be resyncronized. In addition, if the node is not the 1281 tail-end of the LSP, the corresponding outgoing Path messages is sent 1282 with the incoming label from that entry carried in the UPSTREAM_LABEL 1283 object. 1285 During the Recovery Period, Resv messages are processed normally with 1286 two exceptions. In the case that a forwarding entry is recovered, no 1287 new label or resource allocation is required while processing the 1288 Resv message. The second exception applies only if the Recovery Time 1289 is not 0xffffffff. In this case, ResvErr messages SHOULD NOT be 1290 generated when a Resv message with no matching Path state is 1291 received. In this case the Resv message SHOULD just be silently 1292 discarded. 1294 9.5.3. Procedures for the Neighbor of a Restarting node 1296 The following specifies the procedures that apply when the node 1297 reestablishes communication with the neighbor's control plane within 1298 the Restart Time, the node determines (using the procedures defined 1299 in Section 5 of [RSVP-TE]) that the neighbor's control plane has 1300 restarted, and the neighbor was able to preserve its forwarding state 1301 across the restart (as was indicated by a non-zero Recovery Time 1302 carried in the Restart_Cap object of the RSVP Hello messages received 1303 from the neighbor). 1305 Upon detecting a restart with a neighbor that supports state 1306 recovery, a node SHOULD refresh all Path state shared with that 1307 neighbor. The outgoing Path messages MUST include the Recovery_Label 1308 object containing the label value received in the most recently 1309 received corresponding Resv message. All Path state SHOULD be 1310 refreshed within approximately 1/2 of the Recovery time advertised by 1311 the restarted neighbor. If there are many LSP's going through the 1312 restarting node, the neighbor node should avoid sending Path messages 1313 in a short time interval, as to avoid unnecessary stressing the 1314 restarting node's CPU. Instead, it should spread the messages across 1315 1/2 the Recovery Time interval. 1317 After detecting a restart of a neighbor that supports state recovery, 1318 all Resv state shared with the restarting node MUST NOT be refreshed 1319 until a corresponding Path message is received. This requires 1320 suppression of normal Resv and Summary Refresh processing to the 1321 neighbor during the Recovery Time advertised by the restarted 1322 neighbor. As soon as a corresponding Path message is received a Resv 1323 message SHOULD be generated and normal state processing SHOULD be re- 1324 enabled. 1326 10. RSVP Message Formats and Handling 1328 This message summarizes RSVP message formats and handling as modified 1329 by GMPLS. 1331 10.1. RSVP Message Formats 1333 This section presents the RSVP message related formats as modified by 1334 this document. Where they differ, formats for unidirectional LSPs 1335 are presented separately from bidirectional LSPs. Unmodified formats 1336 are not listed. Again, MESSAGE_ID and related objects are defined in 1337 [RSVP-RR]. 1339 The format of a Path message is as follows: 1341 ::= [ ] 1342 [ [ | ] ... ] 1343 [ ] 1344 1345 1346 [ ] 1347 1348 [ ] 1349 [ ... ] 1350 [ ] 1351 [ ] 1352 [ ] 1353 [ ... ] 1354 1356 The format of the sender description for unidirectional LSPs is: 1358 ::= 1359 [ ] 1360 [ ] 1361 [ ] 1362 [ ] 1364 The format of the sender description for bidirectional LSPs is: 1366 ::= 1367 [ ] 1368 [ ] 1369 [ ] 1370 [ ] 1371 1373 The format of a PathErr message is as follows: 1375 ::= [ ] 1376 [ [ | ] ... ] 1377 [ ] 1378 1379 [ ... ] 1380 [ ... ] 1381 1383 The format of a Resv message is as follows: 1385 ::= [ ] 1386 [ [ | ] ... ] 1387 [ ] 1388 1389 1390 [ ] [ ] 1391 [ ] 1392 [ ] 1393 [ ... ] 1394