idnits 2.17.1 draft-ietf-mpls-generalized-rsvp-te-04.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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 7 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: During the recovery period, new Path state being advertised to the restarted neighbor SHOULD not include the SUGGESTED_LABEL object in the corresponding outgoing Path message. This will prevent the restarting node from erroneously reusing a saved forwarding entry. == 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 that node. 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 (July 2001) is 8320 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 519, but not defined == Missing Reference: 'MPLS-BUNDLE' is mentioned on line 861, but not defined == 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-01 == 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 (~~), 10 warnings (==), 3 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: January 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 (Jasmine Networks) 16 George Swallow (Cisco Systems) 17 Z. Bo Tang (Tellium, Inc.) 19 July 2001 21 Generalized MPLS Signaling - RSVP-TE Extensions 23 draft-ietf-mpls-generalized-rsvp-te-04.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 ................................................ 3 56 2 Label Related Formats ...................................... 3 57 2.1 Generalized Label Request Object ............................ 4 58 2.2 Generalized Label Object .................................... 5 59 2.3 Waveband Switching .......................................... 6 60 2.4 Suggested Label ............................................. 7 61 2.5 Label Set ................................................... 7 62 3 Bidirectional LSPs .......................................... 9 63 3.1 Procedures .................................................. 9 64 3.2 Contention Resolution ....................................... 9 65 4 Notification ................................................ 10 66 4.1 Acceptable Label Set Object ................................. 10 67 4.2 Notify Request Objects ...................................... 11 68 4.3 Notify Message .............................................. 12 69 4.4 Removing State with a PathErr message ....................... 14 70 5 Explicit Label Control ...................................... 15 71 5.1 Procedures .................................................. 16 72 6 Protection Object ........................................... 17 73 6.1 Procedures .................................................. 17 74 7 Administrative Status Information ........................... 17 75 7.1 Admin Status Object ......................................... 17 76 7.2 Path and Resv Message Procedures ............................ 18 77 7.3 Notify Message Procedures ................................... 19 78 8 Control Channel Separation .................................. 20 79 8.1 Interface Identification .................................... 20 80 9 Fault Handling .............................................. 22 81 9.1 RESTART_CAP Object .......................................... 22 82 9.2 Processing of RESTART_CAP Object ............................ 23 83 9.3 Modification to Hello Processing to Support State Recovery .. 23 84 9.4 Control Channel Faults ...................................... 24 85 9.5 Nodal Faults ................................................ 24 86 10 RSVP Message Formats and Handling ........................... 27 87 10.1 RSVP Message Formats ........................................ 27 88 10.2 Addressing Path and PathTear Messages ...................... 29 89 11 Acknowledgments ............................................. 29 90 12 Security Considerations ..................................... 29 91 13 References .................................................. 30 92 14 Authors' Addresses .......................................... 31 93 Changes from previous version: 95 o Fixed Label Set format (for LDP) 96 o Added Switching type of LSP being requested 97 o Added Administrative Status Information (based on last call comments) 98 o Added section on Control Channel Separation 99 (based on last call comments) 100 Covers: 101 - Separation of control and data channels 102 - Restoration of state post control channel failures 104 1. Introduction 106 Generalized MPLS extends MPLS from supporting packet (PSC) interfaces 107 and switching to include support of three new classes of interfaces 108 and switching: Time-Division Multiplex (TDM), Lambda Switch (LSC) and 109 Fiber-Switch (FSC). A functional description of the extensions to 110 MPLS signaling needed to support the new classes of interfaces and 111 switching is provided in [GMPLS-SIG]. This document presents RSVP-TE 112 specific formats and mechanisms needed to support all four classes of 113 interfaces. CR-LDP extensions can be found in [GMPLS-LDP]. 115 [GMPLS-SIG] should be viewed as a companion document to this 116 document. The format of this document parallels [GMPLS-SIG]. In 117 addition to the other features of Generalized MPLS, this document 118 also defines RSVP-TE specific features to support rapid failure 119 notification, see Sections 4.2 and 4.3. 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 2. Label Related Formats 127 This section defines formats for a generalized label request, a 128 generalized label, support for waveband switching, suggested label 129 and label sets. 131 2.1. Generalized Label Request Object 133 A Path message SHOULD contain as specific an LSP Encoding Type as 134 possible to allow the maximum flexibility in switching by transit 135 LSRs. A Generalized Label Request object is set by the ingress node, 136 transparently passed by transit nodes, and used by the egress node. 138 The format of a Generalized Label Request object is: 140 0 1 2 3 141 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 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Length | Class-Num (19)|C-Type (4)[TBA]| 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | LSP Enc. Type |Switching Type | G-PID | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 See [GMPLS-SIG] for a description of parameters. 150 2.1.1. Procedures 152 A node processing a Path message containing a Generalized Label 153 Request must verify that the requested parameters can be satisfied by 154 the interface on which the incoming label is to be allocated, the 155 node itself, and by the interface on which the traffic will be 156 transmitted. The node may either directly support the LSP or it may 157 use a tunnel (FA), i.e., another class of switching. In either case, 158 each parameter must be checked. 160 Note that local node policy dictates when tunnels may be used and 161 when they may be created. Local policy may allow for tunnels to be 162 dynamically established or may be solely administratively controlled. 163 For more information on tunnels and processing of ER hops when using 164 tunnels see [MPLS-HIERARCHY]. 166 Transit and egress nodes MUST verify that the node itself and, where 167 appropriate, that the interface or tunnel on which the traffic will 168 be transmitted can support the requested LSP Encoding Type. If 169 encoding cannot be supported, the node MUST generate a PathErr 170 message, with a "Routing problem/Unsupported Encoding" indication. 172 The G-PID parameter is normally only examined at the egress. If the 173 indicated G-PID cannot be supported then the egress MUST generate a 174 PathErr message, with a "Routing problem/Unsupported L3PID" 175 indication. In the case of PSC and when penultimate hop popping 176 (PHP) is requested, the penultimate hop also examines the (stored) G- 177 PID during the processing of the Resv message. In this case if the 178 G-PID is not supported, then the penultimate hop MUST generate a 179 ResvErr message with a "Routing problem/Unacceptable label value" 180 indication. The generated ResvErr message MAY include an Acceptable 181 Label Set, see Section 4.1. 183 When an error message is not generated, normal processing occurs. In 184 the transit case this will typically result in a Path message being 185 propagated. In the egress case and PHP special case this will 186 typically result in a Resv message being generated. 188 2.1.2. Bandwidth Encoding 190 Bandwidth encodings are carried in the SENDER_TSPEC and FLOWSPEC 191 objects. See [GMPLS-SIG] for a definition of values to be used for 192 specific signal types. These values are set in the Peak Data Rate 193 field of Int-Serv objects. Other bandwidth/service related 194 parameters in the object are ignored and carried transparently. 196 2.2. Generalized Label Object 198 The format of a Generalized Label object is: 200 0 1 2 3 201 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 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Length | Class-Num (16)| C-Type (2) | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Label | 206 | ... | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 See [GMPLS-SIG] for a description of parameters and encoding of 210 labels. 212 2.2.1. Procedures 214 The Generalized Label travels in the upstream direction in Resv 215 messages. 217 The presence of both a generalized and normal label object in a Resv 218 message is a protocol error and should treated as a malformed message 219 by the recipient. 221 The recipient of a Resv message containing a Generalized Label 222 verifies that the values passed are acceptable. If the label is 223 unacceptable then the recipient MUST generate a ResvErr message with 224 a "Routing problem/MPLS label allocation failure" indication. 226 2.3. Waveband Switching 228 Waveband switching uses the same format as the generalized label, see 229 section 2.2. For compatibility reasons, a new RSVP c-type (3) is 230 assigned for the Waveband Label. 232 In the context of waveband switching, the generalized label has the 233 following format: 235 0 1 2 3 236 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 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Length | Class-Num (16)| C-Type (3) | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Waveband Id | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Start Label | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | End Label | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 See [GMPLS-SIG] for a description of parameters. 249 2.3.1. Procedures 251 The procedures defined in Section 2.2.1 apply to waveband switching. 252 This includes generating a ResvErr message with a "Routing 253 problem/MPLS label allocation failure" indication if any of the label 254 fields are unrecognized or unacceptable. 256 Additionally, when a waveband is switched to another waveband, it is 257 possible that the wavelengths within the waveband will be mirrored 258 about a center frequency. When this type of switching is employed, 259 the start and end label in the waveband label object MUST be flipped 260 before forwarding the label object with the new waveband Id. In this 261 manner an egress/ingress LSR which receives a waveband label which 262 has these values inverted, knows that it must also invert its egress 263 association to pick up the proper wavelengths. 265 This operation MUST be performed in both directions when a 266 bidirectional waveband tunnel is being established. 268 2.4. Suggested Label 270 The format of a suggested label is identical to a generalized label. 271 It is used in Path messages. Suggested Label uses Class-Number TBA 272 (of form 10bbbbbb) and the C-type of the label being suggested. 274 Errors in received Suggested Labels MUST be ignored. This includes 275 any received inconsistent or unacceptable values. 277 2.5. Label Set 279 The Label_Set object uses Class-Number TBA (of form 0bbbbbbb) and the 280 C-type of 1. 282 The format of a Label_Set is: 284 0 1 2 3 285 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 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Length | Class-Num(TBA)| C-Type (1) | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Action | Reserved | Label Type | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Subchannel 1 | 292 | ... | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 : : : 295 : : : 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Subchannel N | 298 | ... | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 Label Type: 14 bits 303 Indicates the type and format of the labels carried in the 304 object. Values match the C-Type of the appropriate Label 305 object. Only the low order 8 bits are used in this field. 307 See [GMPLS-SIG] for a description of other parameters. 309 2.5.1. Procedures 311 A Label Set is defined via one or more Label_Set objects. Specific 312 labels/subchannels can be added to or excluded from a Label Set via 313 Action zero (0) and one (1) objects respectively. Ranges of 314 labels/subchannels can be added to or excluded from a Label Set via 315 Action two (2) and three (3) objects respectively. When the 316 Label_Set objects only list labels/subchannels to exclude, this 317 implies that all other labels are acceptable. 319 The absence of any Label_Set objects implies that all labels are 320 acceptable. A Label Set is included when a node wishes to restrict 321 the label(s) that may be used downstream. 323 On reception of a Path message, the receiving node will restrict its 324 choice of labels to one which is in the Label Set. Nodes capable of 325 performing label conversion may also remove the Label Set prior to 326 forwarding the Path message. If the node is unable to pick a label 327 from the Label Set or if there is a problem parsing the Label_Set 328 objects, then the request is terminated and a PathErr message with a 329 "Routing problem/Label Set" indication MUST be generated. It is a 330 local matter if the Label Set is stored for later selection on the 331 Resv or if the selection is made immediately for propagation in the 332 Resv. 334 On reception of a Path message, the Label Set represented in the 335 message is compared against the set of available labels at the 336 downstream interface and the resulting intersecting Label Set is 337 forwarded in a Path message. When the resulting Label Set is empty, 338 the Path must be terminated, and a PathErr message, and a "Routing 339 problem/Label Set" indication MUST be generated. Note that 340 intersection is based on the physical labels (actual wavelength/band 341 values) which may have different logical values on different links, 342 as a result it is the responsibility of the node to map these values 343 so that they have a consistent physical meaning, or to drop the 344 particular values from the set if no suitable logical label value 345 exists. 347 When processing a Resv message at an intermediate node, the label 348 propagated upstream MUST fall within the Label Set. 350 Note, on reception of a Resv message a node that is incapable of 351 performing label conversion has no other choice than to use the same 352 physical label (wavelength/band) as received in the Resv message. In 353 this case, the use and propagation of a Label Set will significantly 354 reduce the chances that this allocation will fail. 356 3. Bidirectional LSPs 358 Bidirectional LSP setup is indicated by the presence of an Upstream 359 Label in the Path message. An Upstream Label has the same format as 360 the generalized label, see Section 2.2. The Upstream Label uses 361 Class-Number TBA (of form 0bbbbbbb) and the C-type of the label being 362 suggested. 364 3.1. Procedures 366 The process of establishing a bidirectional LSP follows the 367 establishment of a unidirectional LSP with some additions. To 368 support bidirectional LSPs an Upstream Label is added to the Path 369 message. The Upstream Label MUST indicate a label that is valid for 370 forwarding at the time the Path message is sent. 372 When a Path message containing an Upstream Label is received, the 373 receiver first verifies that the upstream label is acceptable. If 374 the label is not acceptable, the receiver MUST issue a PathErr 375 message with a "Routing problem/Unacceptable label value" indication. 376 The generated PathErr message MAY include an Acceptable Label Set, 377 see Section 4.1. 379 An intermediate node must also allocate a label on the outgoing 380 interface and establish internal data paths before filling in an 381 outgoing Upstream Label and propagating the Path message. If an 382 intermediate node is unable to allocate a label or internal 383 resources, then it MUST issue a PathErr message with a "Routing 384 problem/Label allocation failure" indication. 386 Terminator nodes process Path messages as usual, with the exception 387 that the upstream label can immediately be used to transport data 388 traffic associated with the LSP upstream towards the initiator. 390 When a bidirectional LSP is removed, both upstream and downstream 391 labels are invalidated and it is no longer valid to send data using 392 the associated labels. 394 3.2. Contention Resolution 396 There are two additional contention resolution related considerations 397 when controlling bidirectional LSP setup via RSVP-TE. The first is 398 that for the purposes of RSVP contention resolution, the node ID is 399 the IP address used in the RSVP_HOP object. The second is that a 400 neighbor's node ID might not be known when sending an initial Path 401 message. When this case occurs, a node should suggest a label chosen 402 at random from the available label space. 404 4. Notification 406 This section covers several notification related extensions. The 407 first extension defines the Acceptable Label Set object to support 408 Notification on Label Error, per [GMPLS-SIG]. The second and third 409 extensions enable expedited notification of failures and other events 410 to nodes responsible for restoring failed LSPs. (The second 411 extension, the Notify Request object, identifies where event 412 notifications are to be sent. The third extension, the Notify 413 message, provides for general event notification.) The final 414 notification related extension allows for the removal of Path state 415 on handling of PathErr messages. 417 4.1. Acceptable Label Set Object 419 Acceptable_Label_Set objects use a Class-Number TBA (of form 420 10bbbbbb). The remaining contents of the object, including C-type, 421 have the identical format as the Label_Set object, see Section 2.5. 423 Acceptable_Label_Set objects may be carried in PathErr and ResvErr 424 messages. The procedures for defining an Acceptable Label Set follow 425 the procedures for defining a Label Set, see Section 2.5.1. 426 Specifically, an Acceptable Label Set is defined via one or more 427 Acceptable_Label_Set objects. Specific labels/subchannels can be 428 added to or excluded from an Acceptable Label Set via Action zero 429 (0) and one (1) objects respectively. Ranges of labels/subchannels 430 can be added to or excluded from an Acceptable Label Set via Action 431 two (2) and three (3) objects respectively. When the 432 Acceptable_Label_Set objects only list labels/subchannels to exclude, 433 this implies that all other labels are acceptable. 435 The inclusion of Acceptable_Label_Set objects is optional. If 436 included, the PathErr or ResvErr message SHOULD contain a "Routing 437 problem/Unacceptable label value" indication. The absence of 438 Acceptable_Label_Set objects does not have any specific meaning. 440 4.2. Notify Request Objects 442 Notifications may be sent via the Notify message defined below. The 443 Notify Request object is used to request the generation of 444 notifications. Notifications, i.e., the sending of a Notify message, 445 may be requested in both the upstream and downstream directions. 447 4.2.1. Required Information 449 The Notify Request Object may be carried in Path or Resv Messages, 450 see Section 7. The NOTIFY_REQUEST Class-Number is TBA (of form 451 11bbbbbb). The format of a Notify Request is: 453 o IPv4 Notify Request Object 454 0 1 2 3 455 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 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Length | Class-Num(TBA)| C-Type (1) | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | IPv4 Notify Node Address | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 IPv4 Notify Node Address: 32 bits 464 The IP address of the node that should be notified when 465 generating an error message. 467 o IPv6 Notify Request Object 468 0 1 2 3 469 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 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | Length | Class-Num(TBA)| C-Type (2) | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | | 474 | IPv6 Notify Node Address | 475 | | 476 | | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 IPv6 Notify Node Address: 16 bytes 481 The IP address of the node that should be notified when 482 generating an error message. 484 If a message contains multiple NOTIFY_REQUEST objects, only the first 485 object is meaningful. Subsequent NOTIFY_REQUEST objects MAY be 486 ignored and SHOULD NOT be propagated. 488 4.2.2. Procedures 490 A Notify Request object may be inserted in Path or Resv messages to 491 indicate the address of a node that should be notified of an LSP 492 failure. As previously mentioned, notifications may be requested in 493 both the upstream and downstream directions. Upstream notification is 494 indicated via the inclusion of a Notify Request Object in the 495 corresponding Path message. Downstream notification is indicated via 496 the inclusion of a Notify Request Object in the corresponding Resv 497 message. 499 A node receiving a message containing a Notify Request object SHOULD 500 store the Notify Node Address in the corresponding state block. If 501 the node is a transit node, it SHOULD also included a Notify Request 502 object in the outgoing Path or Resv message. The outgoing Notify 503 Node Address MAY be updated based on local policy. 505 Note that the inclusion of a Notify Request object does not guarantee 506 that a Notify message will be generated. 508 4.3. Notify Message 510 The Notify message provides a mechanism to inform non-adjacent nodes 511 of LSP related events. Notify messages are only generated after a 512 Notify Request object has been received. The Notify message differs 513 from the currently defined error messages (i.e., PathErr and ResvErr 514 messages) in that it can be "targeted" to a node other than the 515 immediate upstream or downstream neighbor and that it is a 516 generalized notification mechanism. The Notify message does not 517 replace existing error messages. The Notify message may be sent 518 either (a) normally, where non-target nodes just forward the Notify 519 message to the target node, similar to ResvConf processing in [RSVP]; 520 or (b) encapsulated in a new IP header whose destination is equal to 521 the target IP address. Regardless of the transmission mechanism, 522 nodes receiving a Notify message not destined to the node forward the 523 message, unmodified, towards the target. 525 To support reliable delivery of the Notify message, an Ack Message 526 [RSVP-RR] is used to acknowledge the receipt of a Notify Message. 527 See [RSVP-RR] for details on reliable RSVP message delivery. 529 4.3.1. Required Information 531 The Notify message is a generalized notification message. The IP 532 destination address is set to the IP address of the intended 533 receiver. The Notify message is sent without the router alert 534 option. A single Notify message may contain notifications being 535 sent, with respect to each listed session, both upstream and 536 downstream. 538 The Notify message has a Msg Type of TBA (by IANA). The Notify 539 message format is as follows: 541 ::= [] 542 [ [ | ] ... ] 543 [ ] 544 546 ::= [ ] 547 | 548 550 ::= [ ] 551 [...] 552 554 ::= [...] 555 557 The ERROR_SPEC object specifies the error and includes the IP address 558 of either the node that detected the error or the link that has 559 failed. See ERROR_SPEC definition in [RFC2205]. The MESSAGE_ID and 560 related objects are defined in [RSVP-RR] and are used when refresh 561 reductions is supported. 563 4.3.2. Procedures 565 Notify messages are generated at nodes that detect an error that will 566 trigger the generation of a PathErr or ResvErr message. If a PathErr 567 message is to be generated and a Notify Request object has been 568 received in the corresponding Path message, then a Notify message 569 destined to the recorded node SHOULD be generated. If a ResvErr 570 message is to be generated and a Notify Request object has been 571 received in the corresponding Resv message, then a Notify message 572 destined to the recorded node SHOULD be generated. As previously 573 mentioned, a single error may generate a Notify message in both the 574 upstream and downstream directions. Note that a Notify message MUST 575 NOT be generated unless an appropriate Notify Request object has been 576 received. 578 When generating Notify messages, a node SHOULD attempt to combine 579 notifications being sent to the same Notify Node and that share the 580 same ERROR_SPEC into a single Notify message. The means by which a 581 node determines which information may be combined is implementation 582 dependent. Implementations may use event, timer based or other 583 approaches. If using a timer based approach, the implementation 584 SHOULD allow the user to configure the interval over which 585 notifications are combined. When using a timer based approach, a 586 default "notification interval" of 1 ms SHOULD be used. Notify 587 messages SHOULD be delivered using the reliable message delivery 588 mechanisms defined in [RSVP-RR]. 590 Upon receiving a Notify message, the Notify Node SHOULD send a 591 corresponding Ack message. 593 4.4. Removing State with a PathErr message 595 The PathErr message as defined in [RFC2205] is sent hop-by-hop to the 596 source of the associated Path message. Intermediate nodes may 597 inspect this message, but take no action upon it. In an environment 598 where Path messages are routed according to an IGP and that route may 599 change dynamically, this behavior is a fine design choice. 601 However, when RSVP is used with explicit routes, it is often the case 602 that errors can only be corrected at the source node or some other 603 node further upstream. In order to clean up resources, the source 604 must receive the PathErr and then either send a PathTear (or wait for 605 the messages to timeout). This causes idle resources to be held 606 longer than necessary and increases control message load. In a 607 situation where the control plane is attempting to recover from a 608 serious outage, both the message load and the delay in freeing 609 resources hamper the ability to rapidly reconverge. 611 The situation can be greatly improved by allowing state to be removed 612 by intermediate nodes on certain error conditions. To facilitate 613 this a new flag is defined in the ERROR_SPEC object. The two 614 currently defined ERROR_SPEC objects (IPv4 and IPv6 error spec 615 objects) each contain a one byte flag field. Within that field two 616 flags are defined. This specification defines a third flag, 0x04, 617 Path_State_Removed. 619 The semantics of the Path_State_Removed flag are simply that the node 620 forwarding the error message has removed the Path state associated 621 with the PathErr. By default, the Path_State_Removed flag is always 622 set to zero when generating or forwarding a PathErr message. A node 623 which encounters an error MAY set this flag if the error results in 624 the associated Path state being discarded. If the node setting the 625 flag is not the session endpoint, the node SHOULD generate a 626 corresponding PathTear. A node receiving a PathErr message 627 containing an ERROR_SPEC object with the Path_State_Removed flag set 628 MAY also remove the associated Path state. If the Path state is 629 removed the Path_State_Removed flag SHOULD be set in the outgoing 630 PathErr message. A node which does not remove the associated Path 631 state MUST NOT set the Path_State_Removed flag. A node that receives 632 an error with the Path_State_Removed flag set to zero MUST NOT set 633 this flag unless it also generates a corresponding PathTear message. 635 Note that the use of this flag does not result in any 636 interoperability incompatibilities. 638 5. Explicit Label Control 640 The Label ERO subobject is defined as follows: 642 0 1 2 3 643 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 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 |L| Type | Length |U| Reserved | C-Type | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Label | 648 | ... | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 See [GMPLS-SIG] for a description of L, U and Label parameters. 653 Type 655 3 Label 657 Length 659 The Length contains the total length of the subobject in bytes, 660 including the Type and Length fields. The Length is always 661 divisible by 4. 663 C-Type 665 The C-Type of the included Label Object. Copied from the Label 666 Object. 668 5.1. Procedures 670 The Label subobject follows a subobject containing the IP address, or 671 the interface identifier [MPLS-UNNUM], associated with the link on 672 which it is to be used. The preceding subobject must be a strict 673 object. Up to two label subobjects may be present, one for the 674 downstream label and one for the upstream label. The following 675 SHOULD result in "Bad EXPLICIT_ROUTE object" errors: 676 - If the first label subobject is not preceded by a subobject 677 containing an IP address, or a interface identifier 678 [MPLS-UNNUM], associated with an output link. 679 - For a label subobject to follow a subobject that has the L-bit 680 set 681 - On unidirectional LSP setup, for there to be a label subobject 682 with the U-bit set 683 - For there to be two label subobjects with the same U-bit values 685 To support the label subobject, a node must check to see if the 686 subobject following its associate address/interface is a label 687 subobject. If it is, one subobject is examined for unidirectional 688 LSPs and two subobjects for bidirectional LSPs. If the U-bit of the 689 subobject being examined is clear (0), then value of the label is 690 copied into a new Label_Set object. This Label_Set object MUST be 691 included on the corresponding outgoing Path message. 693 If the U-bit of the subobject being examined is set (1), then value 694 of the label is label to be used for upstream traffic associated with 695 the bidirectional LSP. If this label is not acceptable, a "Bad 696 EXPLICIT_ROUTE object" error SHOULD be generated. If the label is 697 acceptable, the label is copied into a new Upstream Label object. 698 This Upstream Label object MUST be included on the corresponding 699 outgoing Path message. 701 After processing, the label subobjects are removed from the ERO. 703 Note an implication of the above procedures is that the label 704 subobject should never be the first subobject in a newly received 705 message. If the label subobject is the the first subobject an a 706 received ERO, then it SHOULD be treated as a "Bad strict node" error. 708 Procedures by which an LSR at the head-end of an LSP obtains the 709 information needed to construct the Label subobject are outside the 710 scope of this document. 712 6. Protection Object 714 The use of the Protection Object is optional. The object is included 715 to indicate specific protection attributes of an LSP. The Protection 716 Object uses Class-Number TBA (of form 0bbbbbbb). 718 The format of the Protection Object is: 720 0 1 2 3 721 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 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | Length | Class-Num(TBA)| C-Type (1) | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 |S| Reserved | Link Flags| 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 See [GMPLS-SIG] for a description of parameters. 730 6.1. Procedures 732 Transit nodes processing a Path message containing a Protection 733 Object MUST verify that the requested protection can be satisfied by 734 the outgoing interface or tunnel (FA). If it cannot, the node MUST 735 generate a PathErr message, with a "Routing problem/Unsupported Link 736 Protection" indication. 738 7. Administrative Status Information 740 Administrative Status Information is carried in the Admin Status 741 Object. The object provides information related to the 742 administrative state of a particular LSP. The information is used in 743 two ways. In the first, the object is carried in Path and Resv 744 messages to indicate the administrative state of an LSP. In the 745 second, the object is carried in a Notification message to request 746 that the ingress node change the administrative state of an LSP. 748 7.1. Admin Status Object 750 The use of the Admin Status Object is optional. It uses Class-Number 751 TBA (of form 11bbbbbb). 753 The format of the Admin Status Object is: 755 0 1 2 3 756 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 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | Length | Class-Num(TBA)| C-Type (1) | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | Reserved |T|D| 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 See [GMPLS-SIG] for a description of parameters. 765 7.2. Path and Resv Message Procedures 767 The Admin Status Object is used to notify each node along the path of 768 the status of the LSP. Status information is processed by each node 769 based on local policy and then propagated in the corresponding 770 outgoing messages. The object is inserted in Path messages at the 771 discretion of the ingress node. 773 Transit nodes receiving a non-refresh Path message containing an 774 Admin Status Object, update their local state, take any appropriate 775 local action based on the indicated status and then propagate the 776 received Admin Status Object in the outgoing Path message. 778 Egress nodes receiving a non-refresh Path message containing an Admin 779 Status Object, also update their local state and take any appropriate 780 local action based on the indicated status. If an egress node has 781 issued a Resv message corresponding to the Path message it MUST send 782 an updated Resv message containing an Admin Status Object with the 783 same values set as received in the corresponding Path message. The 784 egress node MUST also ensure that all subsequent Resv messages sent 785 by the node contain the same Admin Status Objects matching the 786 corresponding Path message. 788 Transit nodes receiving a non-refresh Resv message containing an 789 Admin Status Object, update their local state, take any appropriate 790 local action based on the indicated status and then propagate the 791 received Admin Status Object in the outgoing Resv message. 793 7.2.1. Deletion procedure 795 In some circumstances, particularly optical networks, it is useful to 796 set the administrative status of an LSP before tearing it down. In 797 such circumstances the procedure SHOULD be followed when deleting an 798 LSP: 800 1. The ingress node precedes an LSP deletion by inserting an Admin 801 Status Object in Path message and setting the Down (D) bit. 803 2. Transit and egress nodes process the Admin Status Object as 804 described above. 806 3. Upon receiving the Admin Status Object with the Down (D) bit set in 807 the Resv message, the ingress node sends a PathTear message 808 downstream to remove the LSP and normal RSVP processing takes place. 810 7.2.2. Compatibility 812 It is possible that some nodes along an LSP will not support the 813 Admin Status Object. In the case of a non-supporting transit node, 814 the object will pass through the node unmodified and normal 815 processing can continue. In the case of a non-supporting egress 816 node, the Admin Status Object will not be reflected back in the Resv 817 Message. In this case, the ingress SHOULD continue to set the 818 contents of the object normally but, when processing an LSP deletion, 819 it MUST NOT wait for an updated Admin Status Object in a Resv message 820 before issuing a PathTear message. 822 7.3. Notify Message Procedures 824 Intermediate and egress nodes may trigger the setting of 825 administrative status before a deletion via the use of Notify 826 messages. To accomplish this, an intermediate or egress node 827 generates a Notify message with the corresponding upstream notify 828 session information. The Admin Status Object MUST be included in the 829 session information, with the Down (D) bit set. The Notify message 830 may, but is not required to be, encapsulated, see Section 4.3. 832 An ingress node receiving a Notify message containing an Admin Status 833 Object with the Down (D) bit set, SHOULD initiate the deletion 834 procedure described in the previous section. 836 7.3.1. Compatibility and Error Procedures 838 Some special processing is required in order to cover the case of 839 nodes that do not support the Admin Status Object and other error 840 conditions. Specifically, a node that sends a Notify message 841 containing an Admin Status Object with the Down (D) bit set MUST 842 verify that it receives a corresponding Path message with the Down 843 (D) bit set within a configurable period of time. By default this 844 period of time SHOULD be 30 seconds. If the node does not receive 845 such a Path message, it SHOULD send a ResvTear message upstream and a 846 PathTear message downstream. 848 8. Control Channel Separation 850 This section provides the protocol specific formats and procedures to 851 required support a control channel not being in-band with a data 852 channel. 854 8.1. Interface Identification 856 The choice of the data interface to use is always made by the sender 857 of the Path message. The choice of the data interface is indicated by 858 the sender of the Path message by including the data channel's 859 interface identifier in the message using a new RSVP_HOP object sub- 860 type. For bidirectional LSPs, the sender chooses the data interface 861 in each direction. In all cases but bundling [MPLS-BUNDLE] the 862 upstream interface is implied by the downstream interface. For 863 bundling, the path sender explicitly identifies the component 864 interface used in each direction. The new RSVP_HOP object is used in 865 Resv message to indicate the downstream node's usage of the indicated 866 interface(s). 868 8.1.1. IF_ID RSVP_HOP Objects 870 The format of the IPv4 IF_ID RSVP_HOP Object is: 872 0 1 2 3 873 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 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | Length | Class-Num (3) | C-Type (3)TBA | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | IPv4 Next/Previous Hop Address | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | Logical Interface Handle | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | | 882 ~ TLVs ~ 883 | | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 The format of the IPv6 IF_ID RSVP_HOP Object is: 888 0 1 2 3 889 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 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 | Length | Class-Num (3) | C-Type (3)TBA | 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | | 894 | IPv6 Next/Previous Hop Address | 895 | | 896 | | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | Logical Interface Handle | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | | 901 ~ TLVs ~ 902 | | 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 See [RFC2205] for a description of hop address and handle fields. 906 See [GMPLS-SIG] for a description of parameters and encoding of 907 TLVs. 909 8.1.2. Procedures 911 An IF_ID RSVP_HOP object is used in place of previously defined 912 RSVP_HOP objects. It is used on links where there is not a one-to- 913 one association of a control channel to a data channel, see [GMPLS- 914 SIG]. The Hop Address and Logical Interface Handle fields are used 915 per standard RSVP [RFC2205]. 917 TLVs are used to identify the data channel(s) associated with the 918 LSP. For a unidirectional LSP, a forward channel MUST be indicated. 919 For a bidirectional LSP that uses bundled links, a reverse channel 920 MUST be indicated. Data channels are specified from the view point 921 of the sender of the Path message. The IF_ID RSVP_HOP object SHOULD 922 NOT be used when no TLVs are needed. 924 A node receiving one or more TLVs in a Path message saves their 925 values and returns them in the HOP objects of subsequent Resv 926 messages sent to the node that originated the TLVs. 928 9. Fault Handling 930 The handling of two types of control communication faults are 931 described in this section. The first, referred to as nodal faults, 932 relates to the case where a node losses its control state (e.g., 933 after a restart) but does not loose its data forwarding state. In 934 the second, referred to as control channel faults, relates to the 935 case where control communication is lost between two nodes. The 936 handling of both faults are supported by a the RESTART_CAP object 937 defined below and require the use of Hello messages. 939 Please note this section is derived from [PAN-RESTART]. 941 9.1. RESTART_CAP Object 943 The RESTART_CAP Object is carried in Hello messages. The modified 944 Hello message format is: 946 ::= [ ] 947 [ ] 949 The format of the RESTART_CAP Object is: 951 0 1 2 3 952 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 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 | Length | Class-Num(TBD)| C-Type (1) | 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 | Restart Time | 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 | Recovery Time | 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 Restart Time: 32 bits 963 Restart Time is measured in milliseconds. Restart Time SHOULD 964 be set to the sum of the time it takes the sender of the object 965 to restart its RSVP-TE component (to the point where it can 966 exchange RSVP Hello with its neighbors) and the communication 967 channel that is used for RSVP communication. 969 Recovery Time: 32 bits 971 The period of time, in milliseconds, that the sender desires 972 for the recipient to resyncronize RSVP and MPLS forwarding 973 state with the sender after the re-establishment of Hello 974 synchronization. A value of zero (0) indicates that MPLS 975 forwarding state was not preserved across a particular reboot. 976 A value of 0xffffffff indicates that resynchronization may 977 occur at a rate selected by the receiver. 979 9.2. Processing of RESTART_CAP Object 981 Nodes supporting state recovery MUST advertise this capability by 982 carrying the RESTART_CAP object in the Hello messages it sends to the 983 neighbors. Usage of the special case Recovery Time values is 984 described in greater detail below. 986 When a node receives a Hello message with the RESTART_CAP object, it 987 SHOULD record the values of the parameters received. Note that the 988 RESTART_CAP Object will only be present when the Dst_Instance value 989 is set to zero (0). 991 9.3. Modification to Hello Processing to Support State Recovery 993 Nodes supporting state recovery MUST include the RESTART_CAP object 994 in all Hello messages which are sent with Dst_Instance value set to 995 zero (0). 997 When an LSR determines that RSVP communication with a neighbor has 998 been lost, and the LSR previously learned that the neighbor supports 999 state recovery, the LSR SHOULD wait at least the amount of time 1000 indicated by the Restart Time indicated by the neighbor before 1001 invoking procedures related to communication loss. An LSR MAY wait 1002 longer based on local policy or configuration information. 1004 During this waiting period, all Hello messages MUST be sent with a 1005 Dst_Instance value set to zero (0), and Src_Instance should be 1006 unchanged. While waiting, the LSR SHOULD also preserve the RSVP and 1007 MPLS forwarding state for (already) established LSPs that traverse 1008 the link(s) between the LSR and the neighbor. In a sense with 1009 respect to established LSPs the LSR behaves as if it continues to 1010 receive periodic RSVP refresh messages from the neighbor. The LSR 1011 MAY clear RSVP and forwarding state for the LSPs that are in the 1012 process of being established when their refresh timers expire. 1013 Refreshing of Resv state SHOULD be suppressed during this waiting 1014 period. 1016 During this waiting period, the LSR MAY inform other nodes of the 1017 communication loss via send a PathErr and/or upstream Notify message 1018 with "Control Channel Degraded State" indication. If such 1019 notification has been sent, then upon restoration of the control 1020 channel the LSR MUST inform other nodes of the restoration via a 1021 PathErr and/or upstream Notify message with "Control Channel Active 1022 State" indication. (Specific error codes are to be assigned IANA.) 1024 When a new Hello message is received from the neighbor, the LSR must 1025 determine if the fault was limited to the control channel or was a 1026 nodal fault. This determination is based on the Src_Instance 1027 received from the neighbor. If the value is different than the value 1028 that was received from the neighbor prior to the fault, then the 1029 neighbor should be treated as if it has restarted. Otherwise, the 1030 the fault was limited control channel. Procedures for handling each 1031 case are described below. 1033 9.4. Control Channel Faults 1035 In the case of control channel faults, the LSR SHOULD refresh all 1036 state shared with the neighbor. Summary Refreshes [RSVP-RR] with the 1037 ACK_Desired flag set SHOULD be used, if supported. Note that if a 1038 large number of messages are need, some pacing should be applied. 1039 All state SHOULD be refreshed within the Recovery time advertised by 1040 the neighbor. 1042 9.5. Nodal Faults 1044 Recovering from nodal faults primarily relies on existing protocol 1045 messages and objects. 1047 9.5.1. Procedures for the Restarting LSR 1049 After an LSR restarts its control plane, an LSR that supports state 1050 recovery SHOULD check whether it was able to preserve its MPLS 1051 forwarding state. If no forwarding state from prior to the restart 1052 was preserved, then the LSR MUST set the Recovery Time to 0 in the 1053 Hello message the LSR sends to its neighbors. 1055 If the forwarding state was preserved, then the LSR initiates the 1056 state recovery process. The LSR MUST be prepared to support the 1057 recovery process for at least the time it advertised in the Recovery 1058 Time in the Hello messages used during initial Hello message 1059 exchange, i.e., when the Dst_Instance that the LSR advertises to the 1060 neighbor was 0. The period during which a node is prepared to 1061 support the recovery process is referred to as the Recovery Period. 1062 Note, a Recovery Time value of 0xffffffff indicates that the Recovery 1063 Period is effectively infinite. State that is not resynchronized 1064 during the Recovery Period SHOULD be removed at the end of the 1065 Period. Note that if during Hello synchronization the restarting 1066 LSR determines that a neighbor does not support state recovery, and 1067 the restarting LSR maintains its MPLS forwarding state on a per 1068 neighbor basis, the restarting LSR should immediately consider the 1069 Recovery Period with that neighbor completed. Note forwarding state 1070 can be considered to be maintained on a per neighbor basis when per 1071 interface labels are used on point-to-point interfaces. 1073 When an LSR receives a Path message during the Recovery Period, the 1074 LSR first checks if it has an RSVP state associated with the message. 1075 If the state is found, then the LSR handles this message according to 1076 previously defined procedures. 1078 If the RSVP state is not found, and the message does not carry a 1079 SUGGESTED_LABEL object, the LSR treats this as a setup for a new LSP, 1080 and handles it according to previously defined procedures. 1082 If the RSVP state is not found, and the message carries the 1083 SUGGESTED_LABEL object, the LSR searches its MPLS forwarding table 1084 (the one that was preserved across the restart) for an entry whose 1085 incoming interface matches the Path message and whose incoming label 1086 is equal to the label carried in the SUGGESTED_LABEL object. 1088 If the MPLS forwarding table entry is not found, the LSR treats this 1089 as a setup for a new LSP, and handles it according to previously 1090 defined procedures. 1092 If the MPLS forwarding table entry is found, the appropriate RSVP 1093 state is created, the entry is bound to the LSP associated with the 1094 message, and related forwarding state should be considered as valid 1095 and refreshed. Normal Path message processing should also be 1096 conducted. When sending the corresponding outgoing Path message the 1097 node SHOULD include a SUGGESTED_LABEL object with a label value 1098 matching the outgoing label from the now restored forwarding entry. 1099 The outgoing interface SHOULD also be selected based on the 1100 forwarding entry. 1102 Additionally, for bidirectional LSPs, the LSR extracts the label from 1103 the UPSTREAM_LABEL object carried in the received Path message, and 1104 searches its MPLS forwarding table for an entry whose outgoing label 1105 is equal to the label carried in the object (in the case of link 1106 bundling, this may also involved first identifying the appropriate 1107 incoming component link). 1109 If the MPLS forwarding table entry is not found, the LSR treats this 1110 as a setup for a new LSP, and handles it according to previously 1111 defined procedures. 1113 If the MPLS forwarding table entry is found, the entry is bound to 1114 the LSP associated with the Path message, and the entry is no longer 1115 considered as stale. In addition, if the LSR is not the tail-end of 1116 the LSP, the corresponding outgoing Path messages is sent with the 1117 incoming label from that entry carried in the UPSTREAM_LABEL object. 1119 During the Recovery Period, Resv messages are processed normally with 1120 two exceptions. In the case that a forwarding entry is recovered, no 1121 new label or resource allocation is required while processing the 1122 Resv message. The second exception applies only if the Recovery Time 1123 is not 0xffffffff. In this case, ResvErr messages SHOULD NOT be 1124 generated when a Resv message with no matching Path state is 1125 received. In this case the Resv message SHOULD just be sighlently 1126 discarded. 1128 9.5.2. Procedures for the Neighbor of a Restarting LSR 1130 The following specifies the procedures that apply when the LSR 1131 reestablishes communication with the neighbor's control plane within 1132 the Restart Time, the LSR determines (using the procedures defined in 1133 Section 5 of [RSVP-TE]) that the neighbor's control plane has 1134 restarted, and the neighbor was able to preserve its forwarding state 1135 across the restart (as was indicated by a non-zero Recovery Time 1136 carried in the RESTART_CAP object of the RSVP Hello messages received 1137 from the neighbor). 1139 Upon detecting a restart with a neighbor that supports state 1140 recovery, an LSR SHOULD refresh all Path state shared with that 1141 neighbor. The outgoing Path messages MUST include the 1142 SUGGESTED_LABEL object containing the label value received in the 1143 most recently received corresponding Resv message. All Path state 1144 SHOULD be refreshed within approximately 1/2 of the Recovery time 1145 advertised by the restarted neighbor. If there are many LSP's going 1146 through the restarting LSR, the neighbor LSR should avoid sending 1147 Path messages in a short time interval, as to avoid unnecessary 1148 stressing the restarting LSR's CPU. Instead, it should spread the 1149 messages across 1/2 the Recovery Time interval. 1151 During the recovery period, new Path state being advertised to the 1152 restarted neighbor SHOULD not include the SUGGESTED_LABEL object in 1153 the corresponding outgoing Path message. This will prevent the 1154 restarting node from erroneously reusing a saved forwarding entry. 1156 After detecting a restart of a neighbor that supports state recovery, 1157 all Resv state shared with the restarting node MUST NOT be refreshed 1158 until a corresponding Path message is received. This requires 1159 suppression of normal Resv and Summary Refresh processing to the 1160 neighbor during the Recovery Time advertised by the restarted 1161 neighbor. As soon as a corresponding Path message is received a Resv 1162 message SHOULD be generated and normal state processing may be re- 1163 enabled. 1165 10. RSVP Message Formats and Handling 1167 This message summarizes RSVP message formats and handling as modified 1168 by GMPLS. 1170 10.1. RSVP Message Formats 1172 This section presents the RSVP message related formats as modified by 1173 this document. Where they differ, formats for unidirectional LSPs 1174 are presented separately from bidirectional LSPs. Unmodified formats 1175 are not listed. Again, MESSAGE_ID and related objects are defined in 1176 [RSVP-RR]. 1178 The format of a Path message is as follows: 1180 ::= [ ] 1181 [ [ | ] ... ] 1182 [ ] 1183 1184 1185 [ ] 1186 1187 [ ] 1188 [ ... ] 1189 [ ] 1190 [ ] 1191 [ ] 1192 [ ... ] 1193 1195 The format of the sender description for unidirectional LSPs is: 1197 ::= 1198 [ ] 1199 [ ] 1200 [ ] 1202 The format of the sender description for bidirectional LSPs is: 1204 ::= 1205 [ ] 1206 [ ] 1207 [ ] 1208 1210 The format of a PathErr message is as follows: 1212 ::= [ ] 1213 [ [ | ] ... ] 1214 [ ] 1215 1216 [ ... ] 1217 [ ... ] 1218 1220 The format of a Resv message is as follows: 1222 ::= [ ] 1223 [ [ | ] ... ] 1224 [ ] 1225 1226 1227 [ ] [ ] 1228 [ ] 1229 [ ] 1230 [ ... ] 1231