idnits 2.17.1 draft-ietf-mpls-generalized-rsvp-te-06.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 10 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 (November 2001) is 8197 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 529, but not defined == Missing Reference: 'MPLS-TE' is mentioned on line 1021, 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-05 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-signaling-07 -- 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: May 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 November 2001 21 Generalized MPLS Signaling - RSVP-TE Extensions 23 draft-ietf-mpls-generalized-rsvp-te-06.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 ...................................... 4 57 2.1 Generalized Label Request Object ............................ 4 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 ................................. 11 67 4.2 Notify Request Objects ...................................... 12 68 4.3 Notify Message .............................................. 13 69 4.4 Removing State with a PathErr message ....................... 15 70 5 Explicit Label Control ...................................... 16 71 5.1 Label ERO subobject ......................................... 16 72 5.2 Label RRO subobject ......................................... 18 73 6 Protection Object ........................................... 19 74 6.1 Procedures .................................................. 19 75 7 Administrative Status Information ........................... 19 76 7.1 Admin Status Object ......................................... 19 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 .............................................. 26 83 9.1 Restart_Cap Object .......................................... 27 84 9.2 Processing of Restart_Cap Object ............................ 27 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 ............................................. 34 92 12 Security Considerations ..................................... 34 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 Minor editorial changes and clarifications 101 1. Introduction 103 Generalized MPLS extends MPLS from supporting packet (PSC) interfaces 104 and switching to include support of three new classes of interfaces 105 and switching: Time-Division Multiplex (TDM), Lambda Switch (LSC) and 106 Fiber-Switch (FSC). A functional description of the extensions to 107 MPLS signaling needed to support the new classes of interfaces and 108 switching is provided in [GMPLS-SIG]. This document presents RSVP-TE 109 specific formats and mechanisms needed to support all four classes of 110 interfaces. CR-LDP extensions can be found in [GMPLS-LDP]. 112 [GMPLS-SIG] should be viewed as a companion document to this 113 document. The format of this document parallels [GMPLS-SIG]. In 114 addition to the other features of Generalized MPLS, this document 115 also defines RSVP-TE specific features to support rapid failure 116 notification, see Sections 4.2 and 4.3. 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 2. Label Related Formats 124 This section defines formats for a generalized label request, a 125 generalized label, support for waveband switching, suggested label 126 and label sets. 128 2.1. Generalized Label Request Object 130 A Path message SHOULD contain as specific an LSP Encoding Type as 131 possible to allow the maximum flexibility in switching by transit 132 LSRs. A Generalized Label Request object is set by the ingress node, 133 transparently passed by transit nodes, and used by the egress node. 135 The format of a Generalized Label Request object is: 137 0 1 2 3 138 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 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Length | Class-Num (19)|C-Type (4)[TBA]| 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | LSP Enc. Type |Switching Type | G-PID | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 See [GMPLS-SIG] for a description of parameters. 147 2.1.1. Procedures 149 A node processing a Path message containing a Generalized Label 150 Request must verify that the requested parameters can be satisfied by 151 the interface on which the incoming label is to be allocated, the 152 node itself, and by the interface on which the traffic will be 153 transmitted. The node may either directly support the LSP or it may 154 use a tunnel (FA), i.e., another class of switching. In either case, 155 each parameter must be checked. 157 Note that local node policy dictates when tunnels may be used and 158 when they may be created. Local policy may allow for tunnels to be 159 dynamically established or may be solely administratively controlled. 160 For more information on tunnels and processing of ER hops when using 161 tunnels see [MPLS-HIERARCHY]. 163 Transit and egress nodes MUST verify that the node itself and, where 164 appropriate, that the interface or tunnel on which the traffic will 165 be transmitted can support the requested LSP Encoding Type. If 166 encoding cannot be supported, the node MUST generate a PathErr 167 message, with a "Routing problem/Unsupported Encoding" indication. 169 Nodes MUST verify that the type indicated in the Switching Type 170 parameter is supported on the corresponding incoming interface. If 171 the type cannot be supported, the node MUST generate a PathErr 172 message with a "Routing problem/Switching Type" indication. 174 The G-PID parameter is normally only examined at the egress. If the 175 indicated G-PID cannot be supported then the egress MUST generate a 176 PathErr message, with a "Routing problem/Unsupported L3PID" 177 indication. In the case of PSC and when penultimate hop popping 178 (PHP) is requested, the penultimate hop also examines the (stored) G- 179 PID during the processing of the Resv message. In this case if the 180 G-PID is not supported, then the penultimate hop MUST generate a 181 ResvErr message with a "Routing problem/Unacceptable label value" 182 indication. The generated ResvErr message MAY include an Acceptable 183 Label Set, see Section 4.1. 185 When an error message is not generated, normal processing occurs. In 186 the transit case this will typically result in a Path message being 187 propagated. In the egress case and PHP special case this will 188 typically result in a Resv message being generated. 190 2.1.2. Bandwidth Encoding 192 Bandwidth encodings are carried in the SENDER_TSPEC and FLOWSPEC 193 objects. See [GMPLS-SIG] for a definition of values to be used for 194 specific signal types. These values are set in the Peak Data Rate 195 field of Int-Serv objects. Other bandwidth/service related 196 parameters in the object are ignored and carried transparently. 198 2.2. Generalized Label Object 200 The format of a Generalized Label object is: 202 0 1 2 3 203 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 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Length | Class-Num (16)| C-Type (2) | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Label | 208 | ... | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 See [GMPLS-SIG] for a description of parameters and encoding of 212 labels. 214 2.2.1. Procedures 216 The Generalized Label travels in the upstream direction in Resv 217 messages. 219 The presence of both a generalized and normal label object in a Resv 220 message is a protocol error and should treated as a malformed message 221 by the recipient. 223 The recipient of a Resv message containing a Generalized Label 224 verifies that the values passed are acceptable. If the label is 225 unacceptable then the recipient MUST generate a ResvErr message with 226 a "Routing problem/MPLS label allocation failure" indication. 228 2.3. Waveband Switching 230 Waveband switching uses the same format as the generalized label, see 231 section 2.2. For compatibility reasons, a new RSVP C-Type (3) is 232 assigned for the Waveband Label. 234 In the context of waveband switching, the generalized label has the 235 following format: 237 0 1 2 3 238 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 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Length | Class-Num (16)| C-Type (3) | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Waveband Id | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Start Label | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | End Label | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 See [GMPLS-SIG] for a description of parameters. 251 2.3.1. Procedures 253 The procedures defined in Section 2.2.1 apply to waveband switching. 254 This includes generating a ResvErr message with a "Routing 255 problem/MPLS label allocation failure" indication if any of the label 256 fields are unrecognized or unacceptable. 258 Additionally, when a waveband is switched to another waveband, it is 259 possible that the wavelengths within the waveband will be mirrored 260 about a center frequency. When this type of switching is employed, 261 the start and end label in the waveband label object MUST be flipped 262 before forwarding the label object with the new waveband Id. In this 263 manner an egress/ingress LSR which receives a waveband label which 264 has these values inverted, knows that it must also invert its egress 265 association to pick up the proper wavelengths. 267 This operation MUST be performed in both directions when a 268 bidirectional waveband tunnel is being established. 270 2.4. Suggested Label 272 The format of a Suggested_Label object is identical to a generalized 273 label. It is used in Path messages. A Suggested_Label object uses 274 Class-Number TBA (of form 10bbbbbb) and the C-Type of the label being 275 suggested. 277 Errors in received Suggested_Label objects MUST be ignored. This 278 includes any received inconsistent or unacceptable values. 280 Per [GMPLS-SIG], if a downstream node passes a label value that 281 differs from the suggested label upstream, the upstream LSR MUST 282 either reconfigure itself so that it uses the label specified by the 283 downstream node or generate a ResvErr message with a "Routing 284 problem/Unacceptable label value" indication. Furthermore, an 285 ingress node SHOULD NOT transmit data traffic using a suggested label 286 until the downstream node passes a corresponding label upstream. 288 2.5. Label Set 290 The Label_Set object uses Class-Number TBA (of form 0bbbbbbb) and the 291 C-Type of 1. It is used in Path messages. 293 The format of a Label_Set is: 295 0 1 2 3 296 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 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Length | Class-Num(TBA)| C-Type (1) | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Action | Reserved | Label Type | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Subchannel 1 | 303 | ... | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 : : : 306 : : : 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Subchannel N | 309 | ... | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 Label Type: 14 bits 313 Indicates the type and format of the labels carried in the 314 object. Values match the C-Type of the appropriate Label 315 object. Only the low order 8 bits are used in this field. 317 See [GMPLS-SIG] for a description of other parameters. 319 2.5.1. Procedures 321 A Label Set is defined via one or more Label_Set objects. Specific 322 labels/subchannels can be added to or excluded from a Label Set via 323 Action zero (0) and one (1) objects respectively. Ranges of 324 labels/subchannels can be added to or excluded from a Label Set via 325 Action two (2) and three (3) objects respectively. When the 326 Label_Set objects only list labels/subchannels to exclude, this 327 implies that all other labels are acceptable. 329 The absence of any Label_Set objects implies that all labels are 330 acceptable. A Label Set is included when a node wishes to restrict 331 the label(s) that may be used downstream. 333 On reception of a Path message, the receiving node will restrict its 334 choice of labels to one which is in the Label Set. Nodes capable of 335 performing label conversion may also remove the Label Set prior to 336 forwarding the Path message. If the node is unable to pick a label 337 from the Label Set or if there is a problem parsing the Label_Set 338 objects, then the request is terminated and a PathErr message with a 339 "Routing problem/Label Set" indication MUST be generated. It is a 340 local matter if the Label Set is stored for later selection on the 341 Resv or if the selection is made immediately for propagation in the 342 Resv. 344 On reception of a Path message, the Label Set represented in the 345 message is compared against the set of available labels at the 346 downstream interface and the resulting intersecting Label Set is 347 forwarded in a Path message. When the resulting Label Set is empty, 348 the Path must be terminated, and a PathErr message, and a "Routing 349 problem/Label Set" indication MUST be generated. Note that 350 intersection is based on the physical labels (actual wavelength/band 351 values) which may have different logical values on different links, 352 as a result it is the responsibility of the node to map these values 353 so that they have a consistent physical meaning, or to drop the 354 particular values from the set if no suitable logical label value 355 exists. 357 When processing a Resv message at an intermediate node, the label 358 propagated upstream MUST fall within the Label Set. 360 Note, on reception of a Resv message a node that is incapable of 361 performing label conversion has no other choice than to use the same 362 physical label (wavelength/band) as received in the Resv message. In 363 this case, the use and propagation of a Label Set will significantly 364 reduce the chances that this allocation will fail. 366 3. Bidirectional LSPs 368 Bidirectional LSP setup is indicated by the presence of an Upstream 369 Label in the Path message. An Upstream_Label object has the same 370 format as the generalized label, see Section 2.2. The Upstream_Label 371 object uses Class-Number TBA (of form 0bbbbbbb) and the C-Type of the 372 label being used. 374 3.1. Procedures 376 The process of establishing a bidirectional LSP follows the 377 establishment of a unidirectional LSP with some additions. To 378 support bidirectional LSPs an Upstream_Label object is added to the 379 Path message. The Upstream_Label object MUST indicate a label that 380 is valid for forwarding at the time the Path message is sent. 382 When a Path message containing an Upstream_Label object is received, 383 the receiver first verifies that the upstream label is acceptable. 384 If the label is not acceptable, the receiver MUST issue a PathErr 385 message with a "Routing problem/Unacceptable label value" indication. 386 The generated PathErr message MAY include an Acceptable Label Set, 387 see Section 4.1. 389 An intermediate node must also allocate a label on the outgoing 390 interface and establish internal data paths before filling in an 391 outgoing upstream label and propagating the Path message. If an 392 intermediate node is unable to allocate a label or internal 393 resources, then it MUST issue a PathErr message with a "Routing 394 problem/Label allocation failure" indication. 396 Terminator nodes process Path messages as usual, with the exception 397 that the upstream label can immediately be used to transport data 398 traffic associated with the LSP upstream towards the initiator. 400 When a bidirectional LSP is removed, both upstream and downstream 401 labels are invalidated and it is no longer valid to send data using 402 the associated labels. 404 3.2. Contention Resolution 406 There are two additional contention resolution related considerations 407 when controlling bidirectional LSP setup via RSVP-TE. The first is 408 that for the purposes of RSVP contention resolution, the node ID is 409 the IP address used in the RSVP_HOP object. The second is that a 410 neighbor's node ID might not be known when sending an initial Path 411 message. When this case occurs, a node should suggest a label chosen 412 at random from the available label space. 414 4. Notification 416 This section covers several notification related extensions. The 417 first extension defines the Acceptable Label Set object to support 418 Notification on Label Error, per [GMPLS-SIG]. The second and third 419 extensions enable expedited notification of failures and other events 420 to nodes responsible for restoring failed LSPs. (The second 421 extension, the Notify Request object, identifies where event 422 notifications are to be sent. The third extension, the Notify 423 message, provides for general event notification.) The final 424 notification related extension allows for the removal of Path state 425 on handling of PathErr messages. 427 4.1. Acceptable Label Set Object 429 Acceptable_Label_Set objects use a Class-Number TBA (of form 430 10bbbbbb). The remaining contents of the object, including C-Type, 431 have the identical format as the Label_Set object, see Section 2.5. 433 Acceptable_Label_Set objects may be carried in PathErr and ResvErr 434 messages. The procedures for defining an Acceptable Label Set follow 435 the procedures for defining a Label Set, see Section 2.5.1. 436 Specifically, an Acceptable Label Set is defined via one or more 437 Acceptable_Label_Set objects. Specific labels/subchannels can be 438 added to or excluded from an Acceptable Label Set via Action zero 439 (0) and one (1) objects respectively. Ranges of labels/subchannels 440 can be added to or excluded from an Acceptable Label Set via Action 441 two (2) and three (3) objects respectively. When the 442 Acceptable_Label_Set objects only list labels/subchannels to exclude, 443 this implies that all other labels are acceptable. 445 The inclusion of Acceptable_Label_Set objects is optional. If 446 included, the PathErr or ResvErr message SHOULD contain a "Routing 447 problem/Unacceptable label value" indication. The absence of 448 Acceptable_Label_Set objects does not have any specific meaning. 450 4.2. Notify Request Objects 452 Notifications may be sent via the Notify message defined below. The 453 Notify Request object is used to request the generation of 454 notifications. Notifications, i.e., the sending of a Notify message, 455 may be requested in both the upstream and downstream directions. 457 4.2.1. Required Information 459 The Notify Request Object may be carried in Path or Resv Messages, 460 see Section 7. The Notify_Request Class-Number is TBA (of form 461 11bbbbbb). The format of a Notify Request is: 463 o IPv4 Notify Request Object 464 0 1 2 3 465 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 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Length | Class-Num(TBA)| C-Type (1) | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | IPv4 Notify Node Address | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 IPv4 Notify Node Address: 32 bits 474 The IP address of the node that should be notified when 475 generating an error message. 477 o IPv6 Notify Request Object 478 0 1 2 3 479 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 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Length | Class-Num(TBA)| C-Type (2) | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | | 484 | IPv6 Notify Node Address | 485 | | 486 | | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 IPv6 Notify Node Address: 16 bytes 491 The IP address of the node that should be notified when 492 generating an error message. 494 If a message contains multiple Notify_Request objects, only the first 495 object is meaningful. Subsequent Notify_Request objects MAY be 496 ignored and SHOULD NOT be propagated. 498 4.2.2. Procedures 500 A Notify Request object may be inserted in Path or Resv messages to 501 indicate the address of a node that should be notified of an LSP 502 failure. As previously mentioned, notifications may be requested in 503 both the upstream and downstream directions. Upstream notification is 504 indicated via the inclusion of a Notify Request Object in the 505 corresponding Path message. Downstream notification is indicated via 506 the inclusion of a Notify Request Object in the corresponding Resv 507 message. 509 A node receiving a message containing a Notify Request object SHOULD 510 store the Notify Node Address in the corresponding state block. If 511 the node is a transit node, it SHOULD also included a Notify Request 512 object in the outgoing Path or Resv message. The outgoing Notify 513 Node Address MAY be updated based on local policy. 515 Note that the inclusion of a Notify Request object does not guarantee 516 that a Notify message will be generated. 518 4.3. Notify Message 520 The Notify message provides a mechanism to inform non-adjacent nodes 521 of LSP related events. Notify messages are normally generated only 522 after a Notify Request object has been received. The Notify message 523 differs from the currently defined error messages (i.e., PathErr and 524 ResvErr messages) in that it can be "targeted" to a node other than 525 the immediate upstream or downstream neighbor and that it is a 526 generalized notification mechanism. The Notify message does not 527 replace existing error messages. The Notify message may be sent 528 either (a) normally, where non-target nodes just forward the Notify 529 message to the target node, similar to ResvConf processing in [RSVP]; 530 or (b) encapsulated in a new IP header whose destination is equal to 531 the target IP address. Regardless of the transmission mechanism, 532 nodes receiving a Notify message not destined to the node forward the 533 message, unmodified, towards the target. 535 To support reliable delivery of the Notify message, an Ack Message 536 [RSVP-RR] is used to acknowledge the receipt of a Notify Message. 537 See [RSVP-RR] for details on reliable RSVP message delivery. 539 4.3.1. Required Information 541 The Notify message is a generalized notification message. The IP 542 destination address is set to the IP address of the intended 543 receiver. The Notify message is sent without the router alert 544 option. A single Notify message may contain notifications being 545 sent, with respect to each listed session, both upstream and 546 downstream. 548 The Notify message has a Message Type of TBA (by IANA). The Notify 549 message format is as follows: 551 ::= [] 552 [ [ | ] ... ] 553 [ ] 554 556 ::= [ ] 557 | 558 560 ::= [ ] 561 [...] 562 564 ::= [...] 565 567 The ERROR_SPEC object specifies the error and includes the IP address 568 of either the node that detected the error or the link that has 569 failed. See ERROR_SPEC definition in [RFC2205]. The MESSAGE_ID and 570 related objects are defined in [RSVP-RR] and are used when refresh 571 reductions is supported. 573 4.3.2. Procedures 575 Notify messages are most commonly generated at nodes that detect an 576 error that will trigger the generation of a PathErr or ResvErr 577 message. If a PathErr message is to be generated and a Notify 578 Request object has been received in the corresponding Path message, 579 then a Notify message destined to the recorded node SHOULD be 580 generated. If a ResvErr message is to be generated and a Notify 581 Request object has been received in the corresponding Resv message, 582 then a Notify message destined to the recorded node SHOULD be 583 generated. As previously mentioned, a single error may generate a 584 Notify message in both the upstream and downstream directions. Note 585 that a Notify message MUST NOT be generated unless an appropriate 586 Notify Request object has been received. 588 When generating Notify messages, a node SHOULD attempt to combine 589 notifications being sent to the same Notify Node and that share the 590 same ERROR_SPEC into a single Notify message. The means by which a 591 node determines which information may be combined is implementation 592 dependent. Implementations may use event, timer based or other 593 approaches. If using a timer based approach, the implementation 594 SHOULD allow the user to configure the interval over which 595 notifications are combined. When using a timer based approach, a 596 default "notification interval" of 1 ms SHOULD be used. Notify 597 messages SHOULD be delivered using the reliable message delivery 598 mechanisms defined in [RSVP-RR]. 600 Upon receiving a Notify message, the Notify Node SHOULD send a 601 corresponding Ack message. 603 4.4. Removing State with a PathErr message 605 The PathErr message as defined in [RFC2205] is sent hop-by-hop to the 606 source of the associated Path message. Intermediate nodes may 607 inspect this message, but take no action upon it. In an environment 608 where Path messages are routed according to an IGP and that route may 609 change dynamically, this behavior is a fine design choice. 611 However, when RSVP is used with explicit routes, it is often the case 612 that errors can only be corrected at the source node or some other 613 node further upstream. In order to clean up resources, the source 614 must receive the PathErr and then either send a PathTear (or wait for 615 the messages to timeout). This causes idle resources to be held 616 longer than necessary and increases control message load. In a 617 situation where the control plane is attempting to recover from a 618 serious outage, both the message load and the delay in freeing 619 resources hamper the ability to rapidly reconverge. 621 The situation can be greatly improved by allowing state to be removed 622 by intermediate nodes on certain error conditions. To facilitate 623 this a new flag is defined in the ERROR_SPEC object. The two 624 currently defined ERROR_SPEC objects (IPv4 and IPv6 error spec 625 objects) each contain a one byte flag field. Within that field two 626 flags are defined. This specification defines a third flag, 0x04, 627 Path_State_Removed. 629 The semantics of the Path_State_Removed flag are simply that the node 630 forwarding the error message has removed the Path state associated 631 with the PathErr. By default, the Path_State_Removed flag is always 632 set to zero when generating or forwarding a PathErr message. A node 633 which encounters an error MAY set this flag if the error results in 634 the associated Path state being discarded. If the node setting the 635 flag is not the session endpoint, the node SHOULD generate a 636 corresponding PathTear. A node receiving a PathErr message 637 containing an ERROR_SPEC object with the Path_State_Removed flag set 638 MAY also remove the associated Path state. If the Path state is 639 removed the Path_State_Removed flag SHOULD be set in the outgoing 640 PathErr message. A node which does not remove the associated Path 641 state MUST NOT set the Path_State_Removed flag. A node that receives 642 an error with the Path_State_Removed flag set to zero MUST NOT set 643 this flag unless it also generates a corresponding PathTear message. 645 Note that the use of this flag does not result in any 646 interoperability incompatibilities. 648 5. Explicit Label Control 650 The Label ERO and RRO subobjects are defined to support Explicit 651 Label Control. Note that the Label RRO subobject was defined in 652 [RSVP-TE] and is being revised to support bidirectional LSPs. 654 5.1. Label ERO subobject 656 The Label ERO subobject is defined as follows: 658 0 1 2 3 659 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 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 |L| Type | Length |U| Reserved | C-Type | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | Label | 664 | ... | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 See [GMPLS-SIG] for a description of L, U and Label parameters. 669 Type 671 3 Label 673 Length 675 The Length contains the total length of the subobject in bytes, 676 including the Type and Length fields. The Length is always 677 divisible by 4. 679 C-Type 681 The C-Type of the included Label Object. Copied from the Label 682 Object. 684 5.1.1. Procedures 686 The Label subobject follows a subobject containing the IP address, or 687 the interface identifier [MPLS-UNNUM], associated with the link on 688 which it is to be used. Up to two label subobjects may be present, 689 one for the downstream label and one for the upstream label. The 690 following SHOULD result in "Bad EXPLICIT_ROUTE object" errors: 691 - If the first label subobject is not preceded by a subobject 692 containing an IP address, or a interface identifier 693 [MPLS-UNNUM], associated with an output link. 694 - For a label subobject to follow a subobject that has the L-bit 695 set 696 - On unidirectional LSP setup, for there to be a label subobject 697 with the U-bit set 698 - For there to be two label subobjects with the same U-bit values 700 To support the label subobject, a node must check to see if the 701 subobject following its associate address/interface is a label 702 subobject. If it is, one subobject is examined for unidirectional 703 LSPs and two subobjects for bidirectional LSPs. If the U-bit of the 704 subobject being examined is clear (0), then value of the label is 705 copied into a new Label_Set object. This Label_Set object MUST be 706 included on the corresponding outgoing Path message. 708 If the U-bit of the subobject being examined is set (1), then value 709 of the label is label to be used for upstream traffic associated with 710 the bidirectional LSP. If this label is not acceptable, a "Bad 711 EXPLICIT_ROUTE object" error SHOULD be generated. If the label is 712 acceptable, the label is copied into a new Upstream_Label object. 713 This Upstream_Label object MUST be included on the corresponding 714 outgoing Path message. 716 After processing, the label subobjects are removed from the ERO. 718 Note an implication of the above procedures is that the label 719 subobject should never be the first subobject in a newly received 720 message. If the label subobject is the the first subobject an a 721 received ERO, then it SHOULD be treated as a "Bad strict node" error. 723 Procedures by which an LSR at the head-end of an LSP obtains the 724 information needed to construct the Label subobject are outside the 725 scope of this document. 727 5.2. Label RRO subobject 729 The Label RRO subobject is defined as follows: 731 0 1 2 3 732 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 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | Type | Length |U| Flags | C-Type | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | Label | 737 | ... | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 See [GMPLS-SIG] for a description of U and Label parameters. 742 Type 744 3 Label 746 Length 748 See [RSVP-TE]. 750 Flags 752 See [RSVP-TE]. 754 C-Type 756 The C-Type of the included Label Object. Copied from the Label 757 Object. 759 5.2.1. Procedures 761 Label RRO subobjects are included in RROs as described in [RSVP-TE]. 762 The only modification to usage and processing from [RSVP-TE] is that 763 when labels are recorded for bidirectional LSPs, label ERO subobjects 764 for both downstream and upstream labels MUST be included. 766 6. Protection Object 768 The use of the Protection Object is optional. The object is included 769 to indicate specific protection attributes of an LSP. The Protection 770 Object uses Class-Number TBA (of form 0bbbbbbb). 772 The format of the Protection Object is: 774 0 1 2 3 775 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 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | Length | Class-Num(TBA)| C-Type (1) | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 |S| Reserved | Link Flags| 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 See [GMPLS-SIG] for a description of parameters. 784 6.1. Procedures 786 Transit nodes processing a Path message containing a Protection 787 Object MUST verify that the requested protection can be satisfied by 788 the outgoing interface or tunnel (FA). If it cannot, the node MUST 789 generate a PathErr message, with a "Routing problem/Unsupported Link 790 Protection" indication. 792 7. Administrative Status Information 794 Administrative Status Information is carried in the Admin_Status 795 object. The object provides information related to the 796 administrative state of a particular LSP. The information is used in 797 two ways. In the first, the object is carried in Path and Resv 798 messages to indicate the administrative state of an LSP. In the 799 second, the object is carried in a Notification message to request 800 that the ingress node change the administrative state of an LSP. 802 7.1. Admin Status Object 804 The use of the Admin_Status Object is optional. It uses Class-Number 805 TBA (of form 11bbbbbb). 807 The format of the Admin_Status Object is: 809 0 1 2 3 810 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 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | Length | Class-Num(TBA)| C-Type (1) | 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 |R| Reserved |T|A|D| 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 See [GMPLS-SIG] for a description of parameters. 819 7.2. Path and Resv Message Procedures 821 The Admin_Status object is used to notify each node along the path of 822 the status of the LSP. Status information is processed by each node 823 based on local policy and then propagated in the corresponding 824 outgoing messages. The object may be inserted in either Path or Resv 825 messages at the discretion of the ingress (for Path messages) or 826 egress (for Resv messages) nodes. The absence of the object is 827 equivalent to receiving an object containing values all set to zero 828 (0). 830 Transit nodes receiving a non-refresh Path or Resv message containing 831 an Admin_Status object, update their local state, take any 832 appropriate local action based on the indicated status and then 833 propagate the received Admin_Status object in the corresponding 834 outgoing Path or Resv message. If the values of an Admin_Status 835 object received in a Resv message differs from the values received in 836 a Path message then, with one exception, no local action should be 837 taken but the values should still be propagated. The one case where 838 values received in the Resv message should result in local action is 839 when both the received R and D bits are set, i.e., are one (1). 841 Edge nodes receiving a non-refresh Path or Resv message containing an 842 Admin_Status object, also update their local state and take any 843 appropriate local action based on the indicated status. When an 844 Admin Status object is received with the R bit set, the receiving 845 edge node should reflect the received values in a corresponding 846 outgoing message. Specifically, if an egress node receives a Path 847 message with the R bit of the Admin_Status object set and the node 848 has previously issued a Resv message corresponding to the Path 849 message, the node SHOULD send an updated Resv message containing an 850 Admin_Status object with the same values set, with the exception of 851 the R bit, as received in the corresponding Path message. 852 Furthermore, the egress node SHOULD also ensure that subsequent Resv 853 messages sent by the node contain the same Admin Status Object. 855 Additionally, if an ingress node receives a Resv message with the R 856 bit of the Admin_Status object set, the node SHOULD send an updated 857 Path message containing an Admin_Status object with the same values 858 set, with the exception of the R bit, as received in the 859 corresponding Resv message. Furthermore, the ingress node SHOULD 860 also ensure that subsequent Path messages sent by the node contain 861 the same Admin Status Object. 863 7.2.1. Deletion procedure 865 In some circumstances, particularly optical networks, it is useful to 866 set the administrative status of an LSP before tearing it down. In 867 such circumstances the procedure SHOULD be followed when deleting an 868 LSP from the ingress: 870 1. The ingress node precedes an LSP deletion by inserting an Admin 871 Status Object in a Path message and setting the Reflect (R) and 872 Delete (D) bits. 874 2. Transit and egress nodes process the Admin Status Object as 875 described above. (Alternatively, the egress MAY respond with 876 a PathErr message with the Path_State_Removed flag set, see 877 section 4.4.) 879 3. Upon receiving the Admin Status Object with the Delete (D) bit set 880 in the Resv message, the ingress node sends a PathTear message 881 downstream to remove the LSP and normal RSVP processing takes place. 883 In such circumstances the procedure SHOULD be followed when deleting 884 an LSP from the egress: 886 1. The egress node indicates its desire for deletion by inserting 887 an Admin Status Object in a Resv message and setting the Reflect (R) 888 and Delete (D) bits. 890 2. Transit nodes process the Admin Status Object as described above. 892 3. Upon receiving the Admin Status Object with the Delete (D) bit set 893 in the Resv message, the ingress node sends a PathTear message 894 downstream to remove the LSP and normal RSVP processing takes place. 896 7.2.2. Compatibility and Error Procedures 898 It is possible that some nodes along an LSP will not support the 899 Admin Status Object. In the case of a non-supporting transit node, 900 the object will pass through the node unmodified and normal 901 processing can continue. In the case of a non-supporting egress 902 node, the Admin Status Object will not be reflected back in the Resv 903 Message. To support the case of a non-supporting egress node, the 904 ingress SHOULD only wait a configurable period of time for the 905 updated Admin Status Object in a Resv message. Once the period of 906 time has elapsed, the ingress node sends a PathTear message. By 907 default this period of time SHOULD be 30 seconds. 909 7.3. Notify Message Procedures 911 Intermediate and egress nodes may trigger the setting of 912 administrative status via the use of Notify messages. To accomplish 913 this, an intermediate or egress node generates a Notify message with 914 the corresponding upstream notify session information. The Admin 915 Status Object MUST be included in the session information, with the 916 appropriate bit or bits set. The Reflect (R) bit MUST NOT be set. 917 The Notify message may be, but is not required to be, encapsulated, 918 see Section 4.3. 920 An ingress node receiving a Notify message containing an Admin Status 921 Object with the Delete (D) bit set, SHOULD initiate the deletion 922 procedure described in the previous section. Other bits SHOULD be 923 propagated in an outgoing Path message as normal. 925 7.3.1. Compatibility and Error Procedures 927 Some special processing is required in order to cover the case of 928 nodes that do not support the Admin Status Object and other error 929 conditions. Specifically, a node that sends a Notify message 930 containing an Admin Status Object with the Down (D) bit set MUST 931 verify that it receives a corresponding Path message with the Down 932 (D) bit set within a configurable period of time. By default this 933 period of time SHOULD be 30 seconds. If the node does not receive 934 such a Path message, it SHOULD send a PathTear message downstream and 935 either a ResvTear message or a PathErr message with the 936 Path_State_Removed flag set upstream. 938 8. Control Channel Separation 940 This section provides the protocol specific formats and procedures to 941 required support a control channel not being in-band with a data 942 channel. 944 8.1. Interface Identification 946 The choice of the data interface to use is always made by the sender 947 of the Path message. The choice of the data interface is indicated by 948 the sender of the Path message by including the data channel's 949 interface identifier in the message using a new RSVP_HOP object sub- 950 type. For bidirectional LSPs, the sender chooses the data interface 951 in each direction. In all cases but bundling, see [MPLS-BUNDLE], the 952 upstream interface is implied by the downstream interface. For 953 bundling, the path sender explicitly identifies the component 954 interface used in each direction. The new RSVP_HOP object is used in 955 Resv message to indicate the downstream node's usage of the indicated 956 interface(s). 958 8.1.1. IF_ID RSVP_HOP Objects 960 The format of the IPv4 IF_ID RSVP_HOP Object is: 962 0 1 2 3 963 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 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 | Length | Class-Num (3) | C-Type (3)TBA | 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 | IPv4 Next/Previous Hop Address | 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 | Logical Interface Handle | 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 | | 972 ~ TLVs ~ 973 | | 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 The format of the IPv6 IF_ID RSVP_HOP Object is: 978 0 1 2 3 979 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 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 | Length | Class-Num (3) | C-Type (4)TBA | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 | | 984 | IPv6 Next/Previous Hop Address | 985 | | 986 | | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 | Logical Interface Handle | 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 | | 991 ~ TLVs ~ 992 | | 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 See [RFC2205] for a description of hop address and handle fields. 996 See [GMPLS-SIG] for a description of parameters and encoding of 997 TLVs. 999 8.1.2. Procedures 1001 An IF_ID RSVP_HOP object is used in place of previously defined 1002 RSVP_HOP objects. It is used on links where there is not a one-to- 1003 one association of a control channel to a data channel, see [GMPLS- 1004 SIG]. The Hop Address and Logical Interface Handle fields are used 1005 per standard RSVP [RFC2205]. 1007 TLVs are used to identify the data channel(s) associated with an LSP. 1008 For a unidirectional LSP, a downstream data channel MUST be 1009 indicated. For bidirectional LSPs, a common downstream and upstream 1010 data channel is normally indicated. In the special case where a 1011 bidirectional LSP that traverses a bundled link, it is possible to 1012 specify a downstream data channel that differs from the upstream data 1013 channel. Data channels are specified from the view point of the 1014 sender of the Path message. The IF_ID RSVP_HOP object SHOULD NOT be 1015 used when no TLVs are needed. 1017 A node receiving one or more TLVs in a Path message saves their 1018 values and returns them in the HOP objects of subsequent Resv 1019 messages sent to the node that originated the TLVs. 1021 As with [MPLS-TE], the node originating an IF_ID object must ensure 1022 that the selected outgoing interface is consistent with the outgoing 1023 ERO. A node that receives an IF_ID object SHOULD check whether the 1024 information carried in this object is consistent with the information 1025 carried in a received ERO, and if not it MUST send a PathErr with the 1026 error code "Routing Error" and error value of "Bad Explicit Route 1027 Object" toward the sender. 1029 8.2. Errored Interface Identification 1031 There are cases where it is useful to indicate a specific interface 1032 associated with an error. To support these cases the IF_ID 1033 ERROR_SPEC Objects are defined. 1035 8.2.1. IF_ID ERROR_SPEC Objects 1037 The format of the IPv4 IF_ID ERROR_SPEC Object is: 1039 0 1 2 3 1040 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 1041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 | Length | Class-Num (6) | C-Type (3)TBA | 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1044 | IPv4 Error Node Address | 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1046 | Flags | Error Code | Error Value | 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 | | 1049 ~ TLVs ~ 1050 | | 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 The format of the IPv6 IF_ID ERROR_SPEC Object is: 1055 0 1 2 3 1056 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 1057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1058 | Length | Class-Num (6) | C-Type (4)TBA | 1059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 | | 1061 | IPv6 Error Node Address | 1062 | | 1063 | | 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | Flags | Error Code | Error Value | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 | | 1068 ~ TLVs ~ 1069 | | 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 See [RFC2205] for a description of address, flags, error code and 1073 error value fields. See [GMPLS-SIG] for a description of 1074 parameters and encoding of TLVs.n 1076 8.2.2. Procedures 1078 Nodes wishing to indicate that an error is related to a specific 1079 interface SHOULD use the appropriate IF_ID ERROR_SPEC Object in the 1080 corresponding PathErr or ResvErr message. IF_ID ERROR_SPEC Objects 1081 SHOULD be generated and processed as any other ERROR_SPEC Object, see 1082 [RFC2205]. 1084 9. Fault Handling 1086 The handling of two types of control communication faults is 1087 described in this section. The first, referred to as nodal faults, 1088 relates to the case where a node losses its control state (e.g., 1089 after a restart) but does not loose its data forwarding state. In 1090 the second, referred to as control channel faults, relates to the 1091 case where control communication is lost between two nodes. The 1092 handling of both faults is supported by the Restart_Cap object 1093 defined below and require the use of Hello messages. 1095 Note, the Restart_Cap object MUST NOT be sent when there is no 1096 mechanism to detect data channel failures independent of control 1097 channel failures. 1099 Please note this section is derived from [PAN-RESTART]. 1101 9.1. Restart_Cap Object 1103 The Restart_Cap Object is carried in Hello messages. 1105 The format of the Restart_Cap Object is: 1107 0 1 2 3 1108 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 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 | Length | Class-Num(TBA)| C-Type (1) | 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 | Restart Time | 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 | Recovery Time | 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 Restart Time: 32 bits 1119 Restart Time is measured in milliseconds. Restart Time SHOULD 1120 be set to the sum of the time it takes the sender of the object 1121 to restart its RSVP-TE component (to the point where it can 1122 exchange RSVP Hello with its neighbors) and the communication 1123 channel that is used for RSVP communication. 1125 Recovery Time: 32 bits 1127 The period of time, in milliseconds, that the sender desires 1128 for the recipient to resyncronize RSVP and MPLS forwarding 1129 state with the sender after the re-establishment of Hello 1130 synchronization. A value of zero (0) indicates that MPLS 1131 forwarding state was not preserved across a particular reboot. 1132 A value of 0xffffffff indicates that resynchronization may 1133 occur at a rate selected by the receiver. 1135 9.2. Processing of Restart_Cap Object 1137 Nodes supporting state recovery advertise this capability by carrying 1138 the Restart_Cap object in Hello messages. Such nodes MUST include 1139 the Restart_Cap object in all Hello messages. (Note that this 1140 includes Hello messages containing ACK objects.) Usage of the 1141 special case Recovery Time values is described in greater detail 1142 below. 1144 When a node receives a Hello message with the Restart_Cap object, it 1145 SHOULD record the values of the parameters received. 1147 9.3. Modification to Hello Processing to Support State Recovery 1149 When a node determines that RSVP communication with a neighbor has 1150 been lost, and the node previously learned that the neighbor supports 1151 state recovery, the node SHOULD wait at least the amount of time 1152 indicated by the Restart Time indicated by the neighbor before 1153 invoking procedures related to communication loss. A node MAY wait 1154 longer based on local policy or configuration information. 1156 During this waiting period, all Hello messages MUST be sent with a 1157 Dst_Instance value set to zero (0), and Src_Instance should be 1158 unchanged. While waiting, the node SHOULD also preserve the RSVP and 1159 MPLS forwarding state for (already) established LSPs that traverse 1160 the link(s) between the node and the neighbor. In a sense with 1161 respect to established LSPs the node behaves as if it continues to 1162 receive periodic RSVP refresh messages from the neighbor. The node 1163 MAY clear RSVP and forwarding state for the LSPs that are in the 1164 process of being established when their refresh timers expire. 1165 Refreshing of Resv and Path state SHOULD be suppressed during this 1166 waiting period. 1168 During this waiting period, the node MAY inform other nodes of the 1169 communication loss via a PathErr and/or upstream Notify message with 1170 "Control Channel Degraded State" indication. If such notification 1171 has been sent, then upon restoration of the control channel the node 1172 MUST inform other nodes of the restoration via a PathErr and/or 1173 upstream Notify message with "Control Channel Active State" 1174 indication. (Specific error codes are to be assigned IANA.) 1176 When a new Hello message is received from the neighbor, the node must 1177 determine if the fault was limited to the control channel or was a 1178 nodal fault. This determination is based on the Src_Instance 1179 received from the neighbor. If the value is different than the value 1180 that was received from the neighbor prior to the fault, then the 1181 neighbor should be treated as if it has restarted. Otherwise, the 1182 the fault was limited control channel. Procedures for handling each 1183 case are described below. 1185 9.4. Control Channel Faults 1187 In the case of control channel faults, the node SHOULD refresh all 1188 state shared with the neighbor. Summary Refreshes [RSVP-RR] with the 1189 ACK_Desired flag set SHOULD be used, if supported. Note that if a 1190 large number of messages are need, some pacing should be applied. 1191 All state SHOULD be refreshed within the Recovery time advertised by 1192 the neighbor. 1194 9.5. Nodal Faults 1196 Recovering from nodal faults uses one new object and other existing 1197 protocol messages and objects. 1199 9.5.1. Recovery Label 1201 The Recovery_Label object is used during the nodal fault recovery 1202 process. The format of a Recovery_Label object is identical to a 1203 generalized label. A Recovery_Label object uses Class-Number TBA (of 1204 form 0bbbbbbb) and the C-Type of the label being suggested. 1206 9.5.2. Procedures for the Restarting node 1208 After a node restarts its control plane, a node that supports state 1209 recovery SHOULD check whether it was able to preserve its MPLS 1210 forwarding state. If no forwarding state from prior to the restart 1211 was preserved, then the node MUST set the Recovery Time to 0 in the 1212 Hello message the node sends to its neighbors. 1214 If the forwarding state was preserved, then the node initiates the 1215 state recovery process. The period during which a node is prepared 1216 to support the recovery process is referred to as the Recovery 1217 Period. The total duration of the Recovery Period is advertised by 1218 the recovering node in the Recovery Time parameter of the Restart_Cap 1219 object. The Recovery Time MUST be set to the duration of the 1220 Recovery Period in all Hello messages sent during the Recovery 1221 Period. A Recovery Time value of 0xffffffff indicates that the 1222 Recovery Period is effectively infinite. State that is not 1223 resynchronized during the Recovery Period SHOULD be removed at the 1224 end of the Period. 1226 Note that if during Hello synchronization the restarting node 1227 determines that a neighbor does not support state recovery, and the 1228 restarting node maintains its MPLS forwarding state on a per neighbor 1229 basis, the restarting node should immediately consider the Recovery 1230 Period with that neighbor completed. Note forwarding state can be 1231 considered to be maintained on a per neighbor basis when per 1232 interface labels are used on point-to-point interfaces. 1234 When a node receives a Path message during the Recovery Period, the 1235 node first checks if it has an RSVP state associated with the 1236 message. If the state is found, then the node handles this message 1237 according to previously defined procedures. 1239 If the RSVP state is not found, and the message does not carry a 1240 Recovery_Label object, the node treats this as a setup for a new LSP, 1241 and handles it according to previously defined procedures. 1243 If the RSVP state is not found, and the message carries a 1244 Recovery_Label object, the node searches its MPLS forwarding table 1245 (the one that was preserved across the restart) for an entry whose 1246 incoming interface matches the Path message and whose incoming label 1247 is equal to the label carried in the Recovery_Label object. 1249 If the MPLS forwarding table entry is not found, the node treats this 1250 as a setup for a new LSP, and handles it according to previously 1251 defined procedures. 1253 If the MPLS forwarding table entry is found, the appropriate RSVP 1254 state is created, the entry is bound to the LSP associated with the 1255 message, and related forwarding state should be considered as valid 1256 and refreshed. Normal Path message processing should also be 1257 conducted. When sending the corresponding outgoing Path message the 1258 node SHOULD include a Suggested_Label object with a label value 1259 matching the outgoing label from the now restored forwarding entry. 1260 The outgoing interface SHOULD also be selected based on the 1261 forwarding entry. In the special case where a restarting node also 1262 has a restating downstream neighbor, a Recovery_Label object should 1263 be used instead of a Suggested_Label object. 1265 Additionally, for bidirectional LSPs, the node extracts the label 1266 from the UPSTREAM_LABEL object carried in the received Path message, 1267 and searches its MPLS forwarding table for an entry whose outgoing 1268 label is equal to the label carried in the object (in the case of 1269 link bundling, this may also involved first identifying the 1270 appropriate incoming component link). 1272 If the MPLS forwarding table entry is not found, the node treats this 1273 as a setup for a new LSP, and handles it according to previously 1274 defined procedures. 1276 If the MPLS forwarding table entry is found, the entry is bound to 1277 the LSP associated with the Path message, and the entry should be 1278 considered to be resyncronized. In addition, if the node is not the 1279 tail-end of the LSP, the corresponding outgoing Path messages is sent 1280 with the incoming label from that entry carried in the UPSTREAM_LABEL 1281 object. 1283 During the Recovery Period, Resv messages are processed normally with 1284 two exceptions. In the case that a forwarding entry is recovered, no 1285 new label or resource allocation is required while processing the 1286 Resv message. The second exception applies only if the Recovery Time 1287 is not 0xffffffff. In this case, ResvErr messages SHOULD NOT be 1288 generated when a Resv message with no matching Path state is 1289 received. In this case the Resv message SHOULD just be silently 1290 discarded. 1292 9.5.3. Procedures for the Neighbor of a Restarting node 1294 The following specifies the procedures that apply when the node 1295 reestablishes communication with the neighbor's control plane within 1296 the Restart Time, the node determines (using the procedures defined 1297 in Section 5 of [RSVP-TE]) that the neighbor's control plane has 1298 restarted, and the neighbor was able to preserve its forwarding state 1299 across the restart (as was indicated by a non-zero Recovery Time 1300 carried in the Restart_Cap object of the RSVP Hello messages received 1301 from the neighbor). 1303 Upon detecting a restart with a neighbor that supports state 1304 recovery, a node SHOULD refresh all Path state shared with that 1305 neighbor. The outgoing Path messages MUST include the Recovery_Label 1306 object containing the label value received in the most recently 1307 received corresponding Resv message. All Path state SHOULD be 1308 refreshed within approximately 1/2 of the Recovery time advertised by 1309 the restarted neighbor. If there are many LSP's going through the 1310 restarting node, the neighbor node should avoid sending Path messages 1311 in a short time interval, as to avoid unnecessary stressing the 1312 restarting node's CPU. Instead, it should spread the messages across 1313 1/2 the Recovery Time interval. 1315 After detecting a restart of a neighbor that supports state recovery, 1316 all Resv state shared with the restarting node MUST NOT be refreshed 1317 until a corresponding Path message is received. This requires 1318 suppression of normal Resv and Summary Refresh processing to the 1319 neighbor during the Recovery Time advertised by the restarted 1320 neighbor. As soon as a corresponding Path message is received a Resv 1321 message SHOULD be generated and normal state processing SHOULD be re- 1322 enabled. 1324 10. RSVP Message Formats and Handling 1326 This message summarizes RSVP message formats and handling as modified 1327 by GMPLS. 1329 10.1. RSVP Message Formats 1331 This section presents the RSVP message related formats as modified by 1332 this document. Where they differ, formats for unidirectional LSPs 1333 are presented separately from bidirectional LSPs. Unmodified formats 1334 are not listed. Again, MESSAGE_ID and related objects are defined in 1335 [RSVP-RR]. 1337 The format of a Path message is as follows: 1339 ::= [ ] 1340 [ [ | ] ... ] 1341 [ ] 1342 1343 1344 [ ] 1345 1346 [ ] 1347 [ ... ] 1348 [ ] 1349 [ ] 1350 [ ] 1351 [ ... ] 1352 1354 The format of the sender description for unidirectional LSPs is: 1356 ::= 1357 [ ] 1358 [ ] 1359 [ ] 1360 [ ] 1362 The format of the sender description for bidirectional LSPs is: 1364 ::= 1365 [ ] 1366 [ ] 1367 [ ] 1368 [ ] 1369 1371 The format of a PathErr message is as follows: 1373 ::= [ ] 1374 [ [ | ] ... ] 1375 [ ] 1376 1377 [ ... ] 1378 [ ... ] 1379 1381 The format of a Resv message is as follows: 1383 ::= [ ] 1384 [ [ | ] ... ] 1385 [ ] 1386 1387 1388 [ ] [ ] 1389 [ ] 1390 [ ] 1391 [ ... ] 1392