idnits 2.17.1 draft-ietf-mpls-generalized-rsvp-te-07.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 : ---------------------------------------------------------------------------- ** There are 17 instances of too long lines in the document, the longest one being 3 characters in excess of 72. 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 (April 2002) is 8046 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 535, but not defined == Missing Reference: 'MPLS-TE' is mentioned on line 1026, but not defined == Outdated reference: A later version (-08) exists of draft-ietf-mpls-rsvp-unnum-02 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-signaling-08 -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. 'BCP26') (Obsoleted by RFC 5226) == Outdated reference: A later version (-08) exists of draft-ietf-mpls-lsp-hierarchy-02 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-generalized-cr-ldp-06 Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Lou Berger - Editor (Movaz Networks) 2 Internet Draft Peter Ashwood-Smith (Nortel Networks) 3 Expiration Date: October 2002 Ayan Banerjee (Calient Networks) 4 Greg Bernstein (Ciena Corporation) 5 John Drake (Calient Networks) 6 Yanhe Fan (Axiowave Networks) 7 Kireeti Kompella (Juniper Networks) 8 Jonathan P. Lang (Calient Networks) 9 Fong Liaw (Solas Research) 10 Eric Mannie (KPNQwest) 11 Ping Pan (Juniper Networks, Inc.) 12 Bala Rajagopalan (Tellium) 13 Yakov Rekhter (Juniper Networks) 14 Debanjan Saha (Tellium) 15 Vishal Sharma (Metanoia) 16 George Swallow (Cisco Systems) 17 Z. Bo Tang (Tellium) 19 April 2002 21 Generalized MPLS Signaling - RSVP-TE Extensions 23 draft-ietf-mpls-generalized-rsvp-te-07.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/SDH 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 generic functional description and a CR-LDP 50 specific description can be found in separate documents. 52 Contents 54 1 Introduction ................................................ 3 55 2 Label Related Formats ...................................... 3 56 2.1 Generalized Label Request Object ............................ 3 57 2.2 Generalized Label Object .................................... 5 58 2.3 Waveband Switching .......................................... 6 59 2.4 Suggested Label ............................................. 7 60 2.5 Label Set ................................................... 7 61 3 Bidirectional LSPs .......................................... 9 62 3.1 Procedures .................................................. 9 63 3.2 Contention Resolution ....................................... 10 64 4 Notification ................................................ 10 65 4.1 Acceptable Label Set Object ................................. 10 66 4.2 Notify Request Objects ...................................... 11 67 4.3 Notify Message .............................................. 12 68 4.4 Removing State with a PathErr message ....................... 14 69 5 Explicit Label Control ...................................... 15 70 5.1 Label ERO subobject ......................................... 15 71 5.2 Label RRO subobject ......................................... 17 72 6 Protection Object ........................................... 18 73 6.1 Procedures .................................................. 18 74 7 Administrative Status Information ........................... 18 75 7.1 Admin Status Object ......................................... 18 76 7.2 Path and Resv Message Procedures ............................ 19 77 7.3 Notify Message Procedures ................................... 21 78 8 Control Channel Separation .................................. 22 79 8.1 Interface Identification .................................... 22 80 8.2 Errored Interface Identification ............................ 24 81 9 Fault Handling .............................................. 25 82 9.1 Restart_Cap Object .......................................... 26 83 9.2 Processing of Restart_Cap Object ............................ 27 84 9.3 Modification to Hello Processing to Support State Recovery .. 27 85 9.4 Control Channel Faults ...................................... 28 86 9.5 Nodal Faults ................................................ 28 87 10 RSVP Message Formats and Handling ........................... 31 88 10.1 RSVP Message Formats ........................................ 31 89 10.2 Addressing Path and PathTear Messages ...................... 33 90 11 Acknowledgments ............................................. 33 91 12 Security Considerations ..................................... 33 92 13 IANA Considerations ......................................... 34 93 13.1 IANA [Suggestions /] Assignments ............................ 35 94 14 References .................................................. 36 95 14.1 Normative References ........................................ 37 96 14.2 Informative References ...................................... 37 97 15 Authors' Addresses .......................................... 38 98 [Editor's note: changes to be removed prior to publication as an RFC.] 99 Changes from previous version: 101 o Reorder author's list to indicate primary contact 102 o Fixed indication of infinite restart time 103 o Added IANA [Suggestions /] Assignments Section 104 o Split references section 105 o Minor editorial changes and clarifications 107 1. Introduction 109 Generalized MPLS extends MPLS from supporting packet (PSC) interfaces 110 and switching to include support of three new classes of interfaces 111 and switching: Time-Division Multiplex (TDM), Lambda Switch (LSC) and 112 Fiber-Switch (FSC). A functional description of the extensions to 113 MPLS signaling needed to support the new classes of interfaces and 114 switching is provided in [GMPLS-SIG]. This document presents RSVP-TE 115 specific formats and mechanisms needed to support all four classes of 116 interfaces. CR-LDP extensions can be found in [GMPLS-LDP]. 118 [GMPLS-SIG] should be viewed as a companion document to this 119 document. The format of this document parallels [GMPLS-SIG]. In 120 addition to the other features of Generalized MPLS, this document 121 also defines RSVP-TE specific features to support rapid failure 122 notification, see Sections 4.2 and 4.3. 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [RFC2119]. 128 2. Label Related Formats 130 This section defines formats for a generalized label request, a 131 generalized label, support for waveband switching, suggested label 132 and label sets. 134 2.1. Generalized Label Request Object 136 A Path message SHOULD contain as specific an LSP Encoding Type as 137 possible to allow the maximum flexibility in switching by transit 138 LSRs. A Generalized Label Request object is set by the ingress node, 139 transparently passed by transit nodes, and used by the egress node. 140 The Switching Type field may also be updated hop-by-hop. 142 The format of a Generalized Label Request object is: 144 0 1 2 3 145 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 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Length | Class-Num (19)|C-Type (4)[TBA]| 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | LSP Enc. Type |Switching Type | G-PID | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 See [GMPLS-SIG] for a description of parameters. 154 2.1.1. Procedures 156 A node processing a Path message containing a Generalized Label 157 Request must verify that the requested parameters can be satisfied by 158 the interface on which the incoming label is to be allocated, the 159 node itself, and by the interface on which the traffic will be 160 transmitted. The node may either directly support the LSP or it may 161 use a tunnel (FA), i.e., another class of switching. In either case, 162 each parameter must be checked. 164 Note that local node policy dictates when tunnels may be used and 165 when they may be created. Local policy may allow for tunnels to be 166 dynamically established or may be solely administratively controlled. 167 For more information on tunnels and processing of ER hops when using 168 tunnels see [MPLS-HIERARCHY]. 170 Transit and egress nodes MUST verify that the node itself and, where 171 appropriate, that the interface or tunnel on which the traffic will 172 be transmitted can support the requested LSP Encoding Type. If 173 encoding cannot be supported, the node MUST generate a PathErr 174 message, with a "Routing problem/Unsupported Encoding" indication. 176 Nodes MUST verify that the type indicated in the Switching Type 177 parameter is supported on the corresponding incoming interface. If 178 the type cannot be supported, the node MUST generate a PathErr 179 message with a "Routing problem/Switching Type" indication. 181 The G-PID parameter is normally only examined at the egress. If the 182 indicated G-PID cannot be supported then the egress MUST generate a 183 PathErr message, with a "Routing problem/Unsupported L3PID" 184 indication. In the case of PSC and when penultimate hop popping 185 (PHP) is requested, the penultimate hop also examines the (stored) G- 186 PID during the processing of the Resv message. In this case if the 187 G-PID is not supported, then the penultimate hop MUST generate a 188 ResvErr message with a "Routing problem/Unacceptable label value" 189 indication. The generated ResvErr message MAY include an Acceptable 190 Label Set, see Section 4.1. 192 When an error message is not generated, normal processing occurs. In 193 the transit case this will typically result in a Path message being 194 propagated. In the egress case and PHP special case this will 195 typically result in a Resv message being generated. 197 2.1.2. Bandwidth Encoding 199 Bandwidth encodings are carried in the SENDER_TSPEC and FLOWSPEC 200 objects. See [GMPLS-SIG] for a definition of values to be used for 201 specific signal types. These values are set in the Peak Data Rate 202 field of Int-Serv objects. Other bandwidth/service related 203 parameters in the object are ignored and carried transparently. 205 2.2. Generalized Label Object 207 The format of a Generalized Label object is: 209 0 1 2 3 210 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 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Length | Class-Num (16)| C-Type (2) | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Label | 215 | ... | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 See [GMPLS-SIG] for a description of parameters and encoding of 219 labels. 221 2.2.1. Procedures 223 The Generalized Label travels in the upstream direction in Resv 224 messages. 226 The presence of both a generalized and normal label object in a Resv 227 message is a protocol error and should treated as a malformed message 228 by the recipient. 230 The recipient of a Resv message containing a Generalized Label 231 verifies that the values passed are acceptable. If the label is 232 unacceptable then the recipient MUST generate a ResvErr message with 233 a "Routing problem/MPLS label allocation failure" indication. 235 2.3. Waveband Switching 237 Waveband switching uses the same format as the generalized label, see 238 section 2.2. Waveband Label uses C-Type (3), 240 In the context of waveband switching, the generalized label has the 241 following format: 243 0 1 2 3 244 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 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Length | Class-Num (16)| C-Type (3) | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Waveband Id | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Start Label | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | End Label | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 See [GMPLS-SIG] for a description of parameters. 257 2.3.1. Procedures 259 The procedures defined in Section 2.2.1 apply to waveband switching. 260 This includes generating a ResvErr message with a "Routing 261 problem/MPLS label allocation failure" indication if any of the label 262 fields are unrecognized or unacceptable. 264 Additionally, when a waveband is switched to another waveband, it is 265 possible that the wavelengths within the waveband will be mirrored 266 about a center frequency. When this type of switching is employed, 267 the start and end label in the waveband label object MUST be flipped 268 before forwarding the label object with the new waveband Id. In this 269 manner an egress/ingress LSR which receives a waveband label which 270 has these values inverted, knows that it must also invert its egress 271 association to pick up the proper wavelengths. 273 This operation MUST be performed in both directions when a 274 bidirectional waveband tunnel is being established. 276 2.4. Suggested Label 278 The format of a Suggested_Label object is identical to a generalized 279 label. It is used in Path messages. A Suggested_Label object uses 280 Class-Number TBA (of form 10bbbbbb) and the C-Type of the label being 281 suggested. 283 Errors in received Suggested_Label objects MUST be ignored. This 284 includes any received inconsistent or unacceptable values. 286 Per [GMPLS-SIG], if a downstream node passes a label value that 287 differs from the suggested label upstream, the upstream LSR MUST 288 either reconfigure itself so that it uses the label specified by the 289 downstream node or generate a ResvErr message with a "Routing 290 problem/Unacceptable label value" indication. Furthermore, an 291 ingress node SHOULD NOT transmit data traffic using a suggested label 292 until the downstream node passes a corresponding label upstream. 294 2.5. Label Set 296 The Label_Set object uses Class-Number TBA (of form 0bbbbbbb) and the 297 C-Type of 1. It is used in Path messages. 299 The format of a Label_Set is: 301 0 1 2 3 302 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 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Length | Class-Num(TBA)| C-Type (1) | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Action | Reserved | Label Type | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Subchannel 1 | 309 | ... | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 : : : 312 : : : 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Subchannel N | 315 | ... | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 Label Type: 14 bits 319 Indicates the type and format of the labels carried in the 320 object. Values match the C-Type of the appropriate Label 321 object. Only the low order 8 bits are used in this field. 323 See [GMPLS-SIG] for a description of other parameters. 325 2.5.1. Procedures 327 A Label Set is defined via one or more Label_Set objects. Specific 328 labels/subchannels can be added to or excluded from a Label Set via 329 Action zero (0) and one (1) objects respectively. Ranges of 330 labels/subchannels can be added to or excluded from a Label Set via 331 Action two (2) and three (3) objects respectively. When the 332 Label_Set objects only list labels/subchannels to exclude, this 333 implies that all other labels are acceptable. 335 The absence of any Label_Set objects implies that all labels are 336 acceptable. A Label Set is included when a node wishes to restrict 337 the label(s) that may be used downstream. 339 On reception of a Path message, the receiving node will restrict its 340 choice of labels to one which is in the Label Set. Nodes capable of 341 performing label conversion may also remove the Label Set prior to 342 forwarding the Path message. If the node is unable to pick a label 343 from the Label Set or if there is a problem parsing the Label_Set 344 objects, then the request is terminated and a PathErr message with a 345 "Routing problem/Label Set" indication MUST be generated. It is a 346 local matter if the Label Set is stored for later selection on the 347 Resv or if the selection is made immediately for propagation in the 348 Resv. 350 On reception of a Path message, the Label Set represented in the 351 message is compared against the set of available labels at the 352 downstream interface and the resulting intersecting Label Set is 353 forwarded in a Path message. When the resulting Label Set is empty, 354 the Path must be terminated, and a PathErr message, and a "Routing 355 problem/Label Set" indication MUST be generated. Note that 356 intersection is based on the physical labels (actual wavelength/band 357 values) which may have different logical values on different links, 358 as a result it is the responsibility of the node to map these values 359 so that they have a consistent physical meaning, or to drop the 360 particular values from the set if no suitable logical label value 361 exists. 363 When processing a Resv message at an intermediate node, the label 364 propagated upstream MUST fall within the Label Set. 366 Note, on reception of a Resv message a node that is incapable of 367 performing label conversion has no other choice than to use the same 368 physical label (wavelength/band) as received in the Resv message. In 369 this case, the use and propagation of a Label Set will significantly 370 reduce the chances that this allocation will fail. 372 3. Bidirectional LSPs 374 Bidirectional LSP setup is indicated by the presence of an Upstream 375 Label in the Path message. An Upstream_Label object has the same 376 format as the generalized label, see Section 2.2. The Upstream_Label 377 object uses Class-Number TBA (of form 0bbbbbbb) and the C-Type of the 378 label being used. 380 3.1. Procedures 382 The process of establishing a bidirectional LSP follows the 383 establishment of a unidirectional LSP with some additions. To 384 support bidirectional LSPs an Upstream_Label object is added to the 385 Path message. The Upstream_Label object MUST indicate a label that 386 is valid for forwarding at the time the Path message is sent. 388 When a Path message containing an Upstream_Label object is received, 389 the receiver first verifies that the upstream label is acceptable. 390 If the label is not acceptable, the receiver MUST issue a PathErr 391 message with a "Routing problem/Unacceptable label value" indication. 392 The generated PathErr message MAY include an Acceptable Label Set, 393 see Section 4.1. 395 An intermediate node must also allocate a label on the outgoing 396 interface and establish internal data paths before filling in an 397 outgoing upstream label and propagating the Path message. If an 398 intermediate node is unable to allocate a label or internal 399 resources, then it MUST issue a PathErr message with a "Routing 400 problem/MPLS label allocation failure" indication. 402 Terminator nodes process Path messages as usual, with the exception 403 that the upstream label can immediately be used to transport data 404 traffic associated with the LSP upstream towards the initiator. 406 When a bidirectional LSP is removed, both upstream and downstream 407 labels are invalidated and it is no longer valid to send data using 408 the associated labels. 410 3.2. Contention Resolution 412 There are two additional contention resolution related considerations 413 when controlling bidirectional LSP setup via RSVP-TE. The first is 414 that for the purposes of RSVP contention resolution, the node ID is 415 the IP address used in the RSVP_HOP object. The second is that a 416 neighbor's node ID might not be known when sending an initial Path 417 message. When this case occurs, a node should suggest a label chosen 418 at random from the available label space. 420 4. Notification 422 This section covers several notification related extensions. The 423 first extension defines the Acceptable Label Set object to support 424 Notification on Label Error, per [GMPLS-SIG]. The second and third 425 extensions enable expedited notification of failures and other events 426 to nodes responsible for restoring failed LSPs. (The second 427 extension, the Notify Request object, identifies where event 428 notifications are to be sent. The third extension, the Notify 429 message, provides for general event notification.) The final 430 notification related extension allows for the removal of Path state 431 on handling of PathErr messages. 433 4.1. Acceptable Label Set Object 435 Acceptable_Label_Set objects use a Class-Number TBA (of form 436 10bbbbbb). The remaining contents of the object, including C-Type, 437 have the identical format as the Label_Set object, see Section 2.5. 439 Acceptable_Label_Set objects may be carried in PathErr and ResvErr 440 messages. The procedures for defining an Acceptable Label Set follow 441 the procedures for defining a Label Set, see Section 2.5.1. 442 Specifically, an Acceptable Label Set is defined via one or more 443 Acceptable_Label_Set objects. Specific labels/subchannels can be 444 added to or excluded from an Acceptable Label Set via Action zero 445 (0) and one (1) objects respectively. Ranges of labels/subchannels 446 can be added to or excluded from an Acceptable Label Set via Action 447 two (2) and three (3) objects respectively. When the 448 Acceptable_Label_Set objects only list labels/subchannels to exclude, 449 this implies that all other labels are acceptable. 451 The inclusion of Acceptable_Label_Set objects is optional. If 452 included, the PathErr or ResvErr message SHOULD contain a "Routing 453 problem/Unacceptable label value" indication. The absence of 454 Acceptable_Label_Set objects does not have any specific meaning. 456 4.2. Notify Request Objects 458 Notifications may be sent via the Notify message defined below. The 459 Notify Request object is used to request the generation of 460 notifications. Notifications, i.e., the sending of a Notify message, 461 may be requested in both the upstream and downstream directions. 463 4.2.1. Required Information 465 The Notify Request Object may be carried in Path or Resv Messages, 466 see Section 7. The Notify_Request Class-Number is TBA (of form 467 11bbbbbb). The format of a Notify Request is: 469 o IPv4 Notify Request Object 470 0 1 2 3 471 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 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | Length | Class-Num(TBA)| C-Type (1) | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | IPv4 Notify Node Address | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 IPv4 Notify Node Address: 32 bits 480 The IP address of the node that should be notified when 481 generating an error message. 483 o IPv6 Notify Request Object 484 0 1 2 3 485 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 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Length | Class-Num(TBA)| C-Type (2) | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | | 490 | IPv6 Notify Node Address | 491 | | 492 | | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 IPv6 Notify Node Address: 16 bytes 497 The IP address of the node that should be notified when 498 generating an error message. 500 If a message contains multiple Notify_Request objects, only the first 501 object is meaningful. Subsequent Notify_Request objects MAY be 502 ignored and SHOULD NOT be propagated. 504 4.2.2. Procedures 506 A Notify Request object may be inserted in Path or Resv messages to 507 indicate the address of a node that should be notified of an LSP 508 failure. As previously mentioned, notifications may be requested in 509 both the upstream and downstream directions. Upstream notification is 510 indicated via the inclusion of a Notify Request Object in the 511 corresponding Path message. Downstream notification is indicated via 512 the inclusion of a Notify Request Object in the corresponding Resv 513 message. 515 A node receiving a message containing a Notify Request object SHOULD 516 store the Notify Node Address in the corresponding state block. If 517 the node is a transit node, it SHOULD also included a Notify Request 518 object in the outgoing Path or Resv message. The outgoing Notify 519 Node Address MAY be updated based on local policy. 521 Note that the inclusion of a Notify Request object does not guarantee 522 that a Notify message will be generated. 524 4.3. Notify Message 526 The Notify message provides a mechanism to inform non-adjacent nodes 527 of LSP related events. Notify messages are normally generated only 528 after a Notify Request object has been received. The Notify message 529 differs from the currently defined error messages (i.e., PathErr and 530 ResvErr messages) in that it can be "targeted" to a node other than 531 the immediate upstream or downstream neighbor and that it is a 532 generalized notification mechanism. The Notify message does not 533 replace existing error messages. The Notify message may be sent 534 either (a) normally, where non-target nodes just forward the Notify 535 message to the target node, similar to ResvConf processing in [RSVP]; 536 or (b) encapsulated in a new IP header whose destination is equal to 537 the target IP address. Regardless of the transmission mechanism, 538 nodes receiving a Notify message not destined to the node forward the 539 message, unmodified, towards the target. 541 To support reliable delivery of the Notify message, an Ack Message 542 [RFC2961] is used to acknowledge the receipt of a Notify Message. 543 See [RFC2961] for details on reliable RSVP message delivery. 545 4.3.1. Required Information 547 The Notify message is a generalized notification message. The IP 548 destination address is set to the IP address of the intended 549 receiver. The Notify message is sent without the router alert 550 option. A single Notify message may contain notifications being 551 sent, with respect to each listed session, both upstream and 552 downstream. 554 The Notify message has a Message Type of TBA (by IANA). The Notify 555 message format is as follows: 557 ::= [] 558 [ [ | ] ... ] 559 [ ] 560 562 ::= [ ] 563 | 564 566 ::= [ ] 567 [...] 568 570 ::= [...] 571 573 The ERROR_SPEC object specifies the error and includes the IP address 574 of either the node that detected the error or the link that has 575 failed. See ERROR_SPEC definition in [RFC2205]. The MESSAGE_ID and 576 related objects are defined in [RFC2961] and are used when refresh 577 reductions is supported. 579 4.3.2. Procedures 581 Notify messages are most commonly generated at nodes that detect an 582 error that will trigger the generation of a PathErr or ResvErr 583 message. If a PathErr message is to be generated and a Notify 584 Request object has been received in the corresponding Path message, 585 then a Notify message destined to the recorded node SHOULD be 586 generated. If a ResvErr message is to be generated and a Notify 587 Request object has been received in the corresponding Resv message, 588 then a Notify message destined to the recorded node SHOULD be 589 generated. As previously mentioned, a single error may generate a 590 Notify message in both the upstream and downstream directions. Note 591 that a Notify message MUST NOT be generated unless an appropriate 592 Notify Request object has been received. 594 When generating Notify messages, a node SHOULD attempt to combine 595 notifications being sent to the same Notify Node and that share the 596 same ERROR_SPEC into a single Notify message. The means by which a 597 node determines which information may be combined is implementation 598 dependent. Implementations may use event, timer based or other 599 approaches. If using a timer based approach, the implementation 600 SHOULD allow the user to configure the interval over which 601 notifications are combined. When using a timer based approach, a 602 default "notification interval" of 1 ms SHOULD be used. Notify 603 messages SHOULD be delivered using the reliable message delivery 604 mechanisms defined in [RFC2961]. 606 Upon receiving a Notify message, the Notify Node SHOULD send a 607 corresponding Ack message. 609 4.4. Removing State with a PathErr message 611 The PathErr message as defined in [RFC2205] is sent hop-by-hop to the 612 source of the associated Path message. Intermediate nodes may 613 inspect this message, but take no action upon it. In an environment 614 where Path messages are routed according to an IGP and that route may 615 change dynamically, this behavior is a fine design choice. 617 However, when RSVP is used with explicit routes, it is often the case 618 that errors can only be corrected at the source node or some other 619 node further upstream. In order to clean up resources, the source 620 must receive the PathErr and then either send a PathTear (or wait for 621 the messages to timeout). This causes idle resources to be held 622 longer than necessary and increases control message load. In a 623 situation where the control plane is attempting to recover from a 624 serious outage, both the message load and the delay in freeing 625 resources hamper the ability to rapidly reconverge. 627 The situation can be greatly improved by allowing state to be removed 628 by intermediate nodes on certain error conditions. To facilitate 629 this a new flag is defined in the ERROR_SPEC object. The two 630 currently defined ERROR_SPEC objects (IPv4 and IPv6 error spec 631 objects) each contain a one byte flag field. Within that field two 632 flags are defined. This specification defines a third flag, 0x04, 633 Path_State_Removed. 635 The semantics of the Path_State_Removed flag are simply that the node 636 forwarding the error message has removed the Path state associated 637 with the PathErr. By default, the Path_State_Removed flag is always 638 set to zero when generating or forwarding a PathErr message. A node 639 which encounters an error MAY set this flag if the error results in 640 the associated Path state being discarded. If the node setting the 641 flag is not the session endpoint, the node SHOULD generate a 642 corresponding PathTear. A node receiving a PathErr message 643 containing an ERROR_SPEC object with the Path_State_Removed flag set 644 MAY also remove the associated Path state. If the Path state is 645 removed the Path_State_Removed flag SHOULD be set in the outgoing 646 PathErr message. A node which does not remove the associated Path 647 state MUST NOT set the Path_State_Removed flag. A node that receives 648 an error with the Path_State_Removed flag set to zero MUST NOT set 649 this flag unless it also generates a corresponding PathTear message. 651 Note that the use of this flag does not result in any 652 interoperability incompatibilities. 654 5. Explicit Label Control 656 The Label ERO and RRO subobjects are defined to support Explicit 657 Label Control. Note that the Label RRO subobject was defined in 658 [RFC3209] and is being revised to support bidirectional LSPs. 660 5.1. Label ERO subobject 662 The Label ERO subobject is defined as follows: 664 0 1 2 3 665 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 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 |L| Type | Length |U| Reserved | C-Type | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | Label | 670 | ... | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 See [GMPLS-SIG] for a description of L, U and Label parameters. 675 Type 677 3 Label 679 Length 681 The Length contains the total length of the subobject in bytes, 682 including the Type and Length fields. The Length is always 683 divisible by 4. 685 C-Type 687 The C-Type of the included Label Object. Copied from the Label 688 Object. 690 5.1.1. Procedures 692 The Label subobject follows a subobject containing the IP address, or 693 the interface identifier [MPLS-UNNUM], associated with the link on 694 which it is to be used. Up to two label subobjects may be present, 695 one for the downstream label and one for the upstream label. The 696 following SHOULD result in "Bad EXPLICIT_ROUTE object" errors: 697 - If the first label subobject is not preceded by a subobject 698 containing an IP address, or a interface identifier 699 [MPLS-UNNUM], associated with an output link. 700 - For a label subobject to follow a subobject that has the L-bit 701 set 702 - On unidirectional LSP setup, for there to be a label subobject 703 with the U-bit set 704 - For there to be two label subobjects with the same U-bit values 706 To support the label subobject, a node must check to see if the 707 subobject following its associate address/interface is a label 708 subobject. If it is, one subobject is examined for unidirectional 709 LSPs and two subobjects for bidirectional LSPs. If the U-bit of the 710 subobject being examined is clear (0), then value of the label is 711 copied into a new Label_Set object. This Label_Set object MUST be 712 included on the corresponding outgoing Path message. 714 If the U-bit of the subobject being examined is set (1), then value 715 of the label is label to be used for upstream traffic associated with 716 the bidirectional LSP. If this label is not acceptable, a "Bad 717 EXPLICIT_ROUTE object" error SHOULD be generated. If the label is 718 acceptable, the label is copied into a new Upstream_Label object. 719 This Upstream_Label object MUST be included on the corresponding 720 outgoing Path message. 722 After processing, the label subobjects are removed from the ERO. 724 Note an implication of the above procedures is that the label 725 subobject should never be the first subobject in a newly received 726 message. If the label subobject is the the first subobject an a 727 received ERO, then it SHOULD be treated as a "Bad strict node" error. 729 Procedures by which an LSR at the head-end of an LSP obtains the 730 information needed to construct the Label subobject are outside the 731 scope of this document. 733 5.2. Label RRO subobject 735 The Label RRO subobject is defined as follows: 737 0 1 2 3 738 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 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Type | Length |U| Flags | C-Type | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | Label | 743 | ... | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 See [GMPLS-SIG] for a description of U and Label parameters. 748 Type 750 3 Label 752 Length 754 See [RFC3209]. 756 Flags 758 See [RFC3209]. 760 C-Type 762 The C-Type of the included Label Object. Copied from the Label 763 Object. 765 5.2.1. Procedures 767 Label RRO subobjects are included in RROs as described in [RFC3209]. 768 The only modification to usage and processing from [RFC3209] is that 769 when labels are recorded for bidirectional LSPs, label ERO subobjects 770 for both downstream and upstream labels MUST be included. 772 6. Protection Object 774 The use of the Protection Object is optional. The object is included 775 to indicate specific protection attributes of an LSP. The Protection 776 Object uses Class-Number TBA (of form 0bbbbbbb). 778 The format of the Protection Object is: 780 0 1 2 3 781 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 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | Length | Class-Num(TBA)| C-Type (1) | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 |S| Reserved | Link Flags| 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 See [GMPLS-SIG] for a description of parameters. 790 6.1. Procedures 792 Transit nodes processing a Path message containing a Protection 793 Object MUST verify that the requested protection can be satisfied by 794 the outgoing interface or tunnel (FA). If it cannot, the node MUST 795 generate a PathErr message, with a "Routing problem/Unsupported Link 796 Protection" indication. 798 7. Administrative Status Information 800 Administrative Status Information is carried in the Admin_Status 801 object. The object provides information related to the 802 administrative state of a particular LSP. The information is used in 803 two ways. In the first, the object is carried in Path and Resv 804 messages to indicate the administrative state of an LSP. In the 805 second, the object is carried in a Notification message to request 806 that the ingress node change the administrative state of an LSP. 808 7.1. Admin Status Object 810 The use of the Admin_Status Object is optional. It uses Class-Number 811 TBA (of form 11bbbbbb). 813 The format of the Admin_Status Object is: 815 0 1 2 3 816 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 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | Length | Class-Num(TBA)| C-Type (1) | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 |R| Reserved |T|A|D| 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 See [GMPLS-SIG] for a description of parameters. 825 7.2. Path and Resv Message Procedures 827 The Admin_Status object is used to notify each node along the path of 828 the status of the LSP. Status information is processed by each node 829 based on local policy and then propagated in the corresponding 830 outgoing messages. The object may be inserted in either Path or Resv 831 messages at the discretion of the ingress (for Path messages) or 832 egress (for Resv messages) nodes. The absence of the object is 833 equivalent to receiving an object containing values all set to zero 834 (0). 836 Transit nodes receiving a non-refresh Path or Resv message containing 837 an Admin_Status object, update their local state, take any 838 appropriate local action based on the indicated status and then 839 propagate the received Admin_Status object in the corresponding 840 outgoing Path or Resv message. If the values of an Admin_Status 841 object received in a Resv message differs from the values received in 842 a Path message then, with one exception, no local action should be 843 taken but the values should still be propagated. The one case where 844 values received in the Resv message should result in local action is 845 when both the received R and D bits are set, i.e., are one (1). 847 Edge nodes receiving a non-refresh Path or Resv message containing an 848 Admin_Status object, also update their local state and take any 849 appropriate local action based on the indicated status. When an 850 Admin Status object is received with the R bit set, the receiving 851 edge node should reflect the received values in a corresponding 852 outgoing message. Specifically, if an egress node receives a Path 853 message with the R bit of the Admin_Status object set and the node 854 has previously issued a Resv message corresponding to the Path 855 message, the node SHOULD send an updated Resv message containing an 856 Admin_Status object with the same values set, with the exception of 857 the R bit, as received in the corresponding Path message. 858 Furthermore, the egress node SHOULD also ensure that subsequent Resv 859 messages sent by the node contain the same Admin Status Object. 861 Additionally, if an ingress node receives a Resv message with the R 862 bit of the Admin_Status object set, the node SHOULD send an updated 863 Path message containing an Admin_Status object with the same values 864 set, with the exception of the R bit, as received in the 865 corresponding Resv message. Furthermore, the ingress node SHOULD 866 also ensure that subsequent Path messages sent by the node contain 867 the same Admin Status Object. 869 7.2.1. Deletion procedure 871 In some circumstances, particularly optical networks, it is useful to 872 set the administrative status of an LSP before tearing it down. In 873 such circumstances the procedure SHOULD be followed when deleting an 874 LSP from the ingress: 876 1. The ingress node precedes an LSP deletion by inserting an Admin 877 Status Object in a Path message and setting the Reflect (R) and 878 Delete (D) bits. 880 2. Transit and egress nodes process the Admin Status Object as 881 described above. (Alternatively, the egress MAY respond with 882 a PathErr message with the Path_State_Removed flag set, see 883 section 4.4.) 885 3. Upon receiving the Admin Status Object with the Delete (D) bit set 886 in the Resv message, the ingress node sends a PathTear message 887 downstream to remove the LSP and normal RSVP processing takes place. 889 In such circumstances the procedure SHOULD be followed when deleting 890 an LSP from the egress: 892 1. The egress node indicates its desire for deletion by inserting 893 an Admin Status Object in a Resv message and setting the Reflect (R) 894 and Delete (D) bits. 896 2. Transit nodes process the Admin Status Object as described above. 898 3. Upon receiving the Admin Status Object with the Delete (D) bit set 899 in the Resv message, the ingress node sends a PathTear message 900 downstream to remove the LSP and normal RSVP processing takes place. 902 7.2.2. Compatibility and Error Procedures 904 It is possible that some nodes along an LSP will not support the 905 Admin Status Object. In the case of a non-supporting transit node, 906 the object will pass through the node unmodified and normal 907 processing can continue. In the case of a non-supporting egress 908 node, the Admin Status Object will not be reflected back in the Resv 909 Message. To support the case of a non-supporting egress node, the 910 ingress SHOULD only wait a configurable period of time for the 911 updated Admin Status Object in a Resv message. Once the period of 912 time has elapsed, the ingress node sends a PathTear message. By 913 default this period of time SHOULD be 30 seconds. 915 7.3. Notify Message Procedures 917 Intermediate and egress nodes may trigger the setting of 918 administrative status via the use of Notify messages. To accomplish 919 this, an intermediate or egress node generates a Notify message with 920 the corresponding upstream notify session information. The Admin 921 Status Object MUST be included in the session information, with the 922 appropriate bit or bits set. The Reflect (R) bit MUST NOT be set. 923 The Notify message may be, but is not required to be, encapsulated, 924 see Section 4.3. 926 An ingress node receiving a Notify message containing an Admin Status 927 Object with the Delete (D) bit set, SHOULD initiate the deletion 928 procedure described in the previous section. Other bits SHOULD be 929 propagated in an outgoing Path message as normal. 931 7.3.1. Compatibility and Error Procedures 933 Some special processing is required in order to cover the case of 934 nodes that do not support the Admin Status Object and other error 935 conditions. Specifically, a node that sends a Notify message 936 containing an Admin Status Object with the Down (D) bit set MUST 937 verify that it receives a corresponding Path message with the Down 938 (D) bit set within a configurable period of time. By default this 939 period of time SHOULD be 30 seconds. If the node does not receive 940 such a Path message, it SHOULD send a PathTear message downstream and 941 either a ResvTear message or a PathErr message with the 942 Path_State_Removed flag set upstream. 944 8. Control Channel Separation 946 This section provides the protocol specific formats and procedures to 947 required support a control channel not being in-band with a data 948 channel. 950 8.1. Interface Identification 952 The choice of the data interface to use is always made by the sender 953 of the Path message. The choice of the data interface is indicated by 954 the sender of the Path message by including the data channel's 955 interface identifier in the message using a new RSVP_HOP object sub- 956 type. For bidirectional LSPs, the sender chooses the data interface 957 in each direction. In all cases but bundling, the upstream interface 958 is implied by the downstream interface. For bundling, the path 959 sender explicitly identifies the component interface used in each 960 direction. The new RSVP_HOP object is used in Resv message to 961 indicate the downstream node's usage of the indicated interface(s). 963 8.1.1. IF_ID RSVP_HOP Objects 965 The format of the IPv4 IF_ID RSVP_HOP Object is: 967 0 1 2 3 968 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 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 | Length | Class-Num (3) | C-Type (3)TBA | 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 | IPv4 Next/Previous Hop Address | 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 | Logical Interface Handle | 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 | | 977 ~ TLVs ~ 978 | | 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 The format of the IPv6 IF_ID RSVP_HOP Object is: 983 0 1 2 3 984 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 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 | Length | Class-Num (3) | C-Type (4)TBA | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 | | 989 | IPv6 Next/Previous Hop Address | 990 | | 991 | | 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 | Logical Interface Handle | 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 | | 996 ~ TLVs ~ 997 | | 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 See [RFC2205] for a description of hop address and handle fields. 1001 See [GMPLS-SIG] for a description of parameters and encoding of 1002 TLVs. 1004 8.1.2. Procedures 1006 An IF_ID RSVP_HOP object is used in place of previously defined 1007 RSVP_HOP objects. It is used on links where there is not a one-to- 1008 one association of a control channel to a data channel, see [GMPLS- 1009 SIG]. The Hop Address and Logical Interface Handle fields are used 1010 per standard RSVP [RFC2205]. 1012 TLVs are used to identify the data channel(s) associated with an LSP. 1013 For a unidirectional LSP, a downstream data channel MUST be 1014 indicated. For bidirectional LSPs, a common downstream and upstream 1015 data channel is normally indicated. In the special case where a 1016 bidirectional LSP that traverses a bundled link, it is possible to 1017 specify a downstream data channel that differs from the upstream data 1018 channel. Data channels are specified from the view point of the 1019 sender of the Path message. The IF_ID RSVP_HOP object SHOULD NOT be 1020 used when no TLVs are needed. 1022 A node receiving one or more TLVs in a Path message saves their 1023 values and returns them in the HOP objects of subsequent Resv 1024 messages sent to the node that originated the TLVs. 1026 As with [MPLS-TE], the node originating an IF_ID object must ensure 1027 that the selected outgoing interface is consistent with the outgoing 1028 ERO. A node that receives an IF_ID object SHOULD check whether the 1029 information carried in this object is consistent with the information 1030 carried in a received ERO, and if not it MUST send a PathErr with the 1031 error code "Routing Error" and error value of "Bad Explicit Route 1032 Object" toward the sender. 1034 8.2. Errored Interface Identification 1036 There are cases where it is useful to indicate a specific interface 1037 associated with an error. To support these cases the IF_ID 1038 ERROR_SPEC Objects are defined. 1040 8.2.1. IF_ID ERROR_SPEC Objects 1042 The format of the IPv4 IF_ID ERROR_SPEC Object is: 1044 0 1 2 3 1045 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 | Length | Class-Num (6) | C-Type (3)TBA | 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 | IPv4 Error Node Address | 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 | Flags | Error Code | Error Value | 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 | | 1054 ~ TLVs ~ 1055 | | 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1058 The format of the IPv6 IF_ID ERROR_SPEC Object is: 1060 0 1 2 3 1061 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 | Length | Class-Num (6) | C-Type (4)TBA | 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | | 1066 | IPv6 Error Node Address | 1067 | | 1068 | | 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 | Flags | Error Code | Error Value | 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 | | 1073 ~ TLVs ~ 1074 | | 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 See [RFC2205] for a description of address, flags, error code and 1078 error value fields. See [GMPLS-SIG] for a description of 1079 parameters and encoding of TLVs.n 1081 8.2.2. Procedures 1083 Nodes wishing to indicate that an error is related to a specific 1084 interface SHOULD use the appropriate IF_ID ERROR_SPEC Object in the 1085 corresponding PathErr or ResvErr message. IF_ID ERROR_SPEC Objects 1086 SHOULD be generated and processed as any other ERROR_SPEC Object, see 1087 [RFC2205]. 1089 9. Fault Handling 1091 The handling of two types of control communication faults is 1092 described in this section. The first, referred to as nodal faults, 1093 relates to the case where a node losses its control state (e.g., 1094 after a restart) but does not loose its data forwarding state. In 1095 the second, referred to as control channel faults, relates to the 1096 case where control communication is lost between two nodes. The 1097 handling of both faults is supported by the Restart_Cap object 1098 defined below and require the use of Hello messages. 1100 Note, the Restart_Cap object MUST NOT be sent when there is no 1101 mechanism to detect data channel failures independent of control 1102 channel failures. 1104 Please note this section is derived from [PAN-RESTART]. 1106 9.1. Restart_Cap Object 1108 The Restart_Cap Object is carried in Hello messages. 1110 The format of the Restart_Cap Object is: 1112 0 1 2 3 1113 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 | Length | Class-Num(TBA)| C-Type (1) | 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 | Restart Time | 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 | Recovery Time | 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 Restart Time: 32 bits 1124 Restart Time is measured in milliseconds. Restart Time SHOULD 1125 be set to the sum of the time it takes the sender of the object 1126 to restart its RSVP-TE component (to the point where it can 1127 exchange RSVP Hello with its neighbors) and the communication 1128 channel that is used for RSVP communication. A value of 1129 0xffffffff indicates that the restart of the sender's control 1130 plane may occur over an indeterminate interval and that the 1131 operation of its data plane is unaffected by control plane 1132 failures. The method used to ensure continued data plane 1133 operation is outside the scope of this document. 1135 Recovery Time: 32 bits 1137 The period of time, in milliseconds, that the sender desires 1138 for the recipient to re-synchronize RSVP and MPLS forwarding 1139 state with the sender after the re-establishment of Hello 1140 synchronization. A value of zero (0) indicates that MPLS 1141 forwarding state was not preserved across a particular reboot. 1143 9.2. Processing of Restart_Cap Object 1145 Nodes supporting state recovery advertise this capability by carrying 1146 the Restart_Cap object in Hello messages. Such nodes MUST include 1147 the Restart_Cap object in all Hello messages. (Note that this 1148 includes Hello messages containing ACK objects.) Usage of the 1149 special case Recovery Time values is described in greater detail 1150 below. 1152 When a node receives a Hello message with the Restart_Cap object, it 1153 SHOULD record the values of the parameters received. 1155 9.3. Modification to Hello Processing to Support State Recovery 1157 When a node determines that RSVP communication with a neighbor has 1158 been lost, and the node previously learned that the neighbor supports 1159 state recovery, the node SHOULD wait at least the amount of time 1160 indicated by the Restart Time indicated by the neighbor before 1161 invoking procedures related to communication loss. A node MAY wait 1162 longer based on local policy or configuration information. 1164 During this waiting period, all Hello messages MUST be sent with a 1165 Dst_Instance value set to zero (0), and Src_Instance should be 1166 unchanged. While waiting, the node SHOULD also preserve the RSVP and 1167 MPLS forwarding state for (already) established LSPs that traverse 1168 the link(s) between the node and the neighbor. In a sense with 1169 respect to established LSPs the node behaves as if it continues to 1170 receive periodic RSVP refresh messages from the neighbor. The node 1171 MAY clear RSVP and forwarding state for the LSPs that are in the 1172 process of being established when their refresh timers expire. 1173 Refreshing of Resv and Path state SHOULD be suppressed during this 1174 waiting period. 1176 During this waiting period, the node MAY inform upstream nodes of the 1177 communication loss via a PathErr and/or upstream Notify message with 1178 "Control Channel Degraded State" indication. If such notification 1179 has been sent, then upon restoration of the control channel the node 1180 MUST inform other nodes of the restoration via a PathErr and/or 1181 upstream Notify message with "Control Channel Active State" 1182 indication. (Specific error codes are to be assigned IANA.) 1184 When a new Hello message is received from the neighbor, the node must 1185 determine if the fault was limited to the control channel or was a 1186 nodal fault. This determination is based on the Src_Instance 1187 received from the neighbor. If the value is different than the value 1188 that was received from the neighbor prior to the fault, then the 1189 neighbor should be treated as if it has restarted. Otherwise, the 1190 the fault was limited control channel. Procedures for handling each 1191 case are described below. 1193 9.4. Control Channel Faults 1195 In the case of control channel faults, the node SHOULD refresh all 1196 state shared with the neighbor. Summary Refreshes [RFC2961] with the 1197 ACK_Desired flag set SHOULD be used, if supported. Note that if a 1198 large number of messages are need, some pacing should be applied. 1199 All state SHOULD be refreshed within the Recovery time advertised by 1200 the neighbor. 1202 9.5. Nodal Faults 1204 Recovering from nodal faults uses one new object and other existing 1205 protocol messages and objects. 1207 9.5.1. Recovery Label 1209 The Recovery_Label object is used during the nodal fault recovery 1210 process. The format of a Recovery_Label object is identical to a 1211 generalized label. A Recovery_Label object uses Class-Number TBA (of 1212 form 0bbbbbbb) and the C-Type of the label being suggested. 1214 9.5.2. Procedures for the Restarting node 1216 After a node restarts its control plane, a node that supports state 1217 recovery SHOULD check whether it was able to preserve its MPLS 1218 forwarding state. If no forwarding state from prior to the restart 1219 was preserved, then the node MUST set the Recovery Time to 0 in the 1220 Hello message the node sends to its neighbors. 1222 If the forwarding state was preserved, then the node initiates the 1223 state recovery process. The period during which a node is prepared 1224 to support the recovery process is referred to as the Recovery 1225 Period. The total duration of the Recovery Period is advertised by 1226 the recovering node in the Recovery Time parameter of the Restart_Cap 1227 object. The Recovery Time MUST be set to the duration of the 1228 Recovery Period in all Hello messages sent during the Recovery 1229 Period. State that is not resynchronized during the Recovery Period 1230 SHOULD be removed at the end of the Period. 1232 Note that if during Hello synchronization the restarting node 1233 determines that a neighbor does not support state recovery, and the 1234 restarting node maintains its MPLS forwarding state on a per neighbor 1235 basis, the restarting node should immediately consider the Recovery 1236 Period with that neighbor completed. Forwarding state may be 1237 considered to be maintained on a per neighbor basis when per 1238 interface labels are used on point-to-point interfaces. 1240 When a node receives a Path message during the Recovery Period, the 1241 node first checks if it has an RSVP state associated with the 1242 message. If the state is found, then the node handles this message 1243 according to previously defined procedures. 1245 If the RSVP state is not found, and the message does not carry a 1246 Recovery_Label object, the node treats this as a setup for a new LSP, 1247 and handles it according to previously defined procedures. 1249 If the RSVP state is not found, and the message carries a 1250 Recovery_Label object, the node searches its MPLS forwarding table 1251 (the one that was preserved across the restart) for an entry whose 1252 incoming interface matches the Path message and whose incoming label 1253 is equal to the label carried in the Recovery_Label object. 1255 If the MPLS forwarding table entry is not found, the node treats this 1256 as a setup for a new LSP, and handles it according to previously 1257 defined procedures. 1259 If the MPLS forwarding table entry is found, the appropriate RSVP 1260 state is created, the entry is bound to the LSP associated with the 1261 message, and related forwarding state should be considered as valid 1262 and refreshed. Normal Path message processing should also be 1263 conducted. When sending the corresponding outgoing Path message the 1264 node SHOULD include a Suggested_Label object with a label value 1265 matching the outgoing label from the now restored forwarding entry. 1266 The outgoing interface SHOULD also be selected based on the 1267 forwarding entry. In the special case where a restarting node also 1268 has a restating downstream neighbor, a Recovery_Label object should 1269 be used instead of a Suggested_Label object. 1271 Additionally, for bidirectional LSPs, the node extracts the label 1272 from the UPSTREAM_LABEL object carried in the received Path message, 1273 and searches its MPLS forwarding table for an entry whose outgoing 1274 label is equal to the label carried in the object (in the case of 1275 link bundling, this may also involved first identifying the 1276 appropriate incoming component link). 1278 If the MPLS forwarding table entry is not found, the node treats this 1279 as a setup for a new LSP, and handles it according to previously 1280 defined procedures. 1282 If the MPLS forwarding table entry is found, the entry is bound to 1283 the LSP associated with the Path message, and the entry should be 1284 considered to be re-synchronized. In addition, if the node is not 1285 the tail-end of the LSP, the corresponding outgoing Path messages is 1286 sent with the incoming label from that entry carried in the 1287 UPSTREAM_LABEL object. 1289 During the Recovery Period, Resv messages are processed normally with 1290 two exceptions. In the case that a forwarding entry is recovered, no 1291 new label or resource allocation is required while processing the 1292 Resv message. The second exception is that ResvErr messages SHOULD 1293 NOT be generated when a Resv message with no matching Path state is 1294 received. In this case the Resv message SHOULD just be silently 1295 discarded. 1297 9.5.3. Procedures for the Neighbor of a Restarting node 1299 The following specifies the procedures that apply when the node 1300 reestablishes communication with the neighbor's control plane within 1301 the Restart Time, the node determines (using the procedures defined 1302 in Section 5 of [RFC3209]) that the neighbor's control plane has 1303 restarted, and the neighbor was able to preserve its forwarding state 1304 across the restart (as was indicated by a non-zero Recovery Time 1305 carried in the Restart_Cap object of the RSVP Hello messages received 1306 from the neighbor). Note, a Restart Time value of 0xffffffff 1307 indicates an infinite Restart Time interval. 1309 Upon detecting a restart with a neighbor that supports state 1310 recovery, a node SHOULD refresh all Path state shared with that 1311 neighbor. The outgoing Path messages MUST include the Recovery_Label 1312 object containing the label value received in the most recently 1313 received corresponding Resv message. All Path state SHOULD be 1314 refreshed within approximately 1/2 of the Recovery time advertised by 1315 the restarted neighbor. If there are many LSP's going through the 1316 restarting node, the neighbor node should avoid sending Path messages 1317 in a short time interval, as to avoid unnecessary stressing the 1318 restarting node's CPU. Instead, it should spread the messages across 1319 1/2 the Recovery Time interval. 1321 After detecting a restart of a neighbor that supports state recovery, 1322 all Resv state shared with the restarting node MUST NOT be refreshed 1323 until a corresponding Path message is received. This requires 1324 suppression of normal Resv and Summary Refresh processing to the 1325 neighbor during the Recovery Time advertised by the restarted 1326 neighbor. As soon as a corresponding Path message is received a Resv 1327 message SHOULD be generated and normal state processing SHOULD be re- 1328 enabled. 1330 10. RSVP Message Formats and Handling 1332 This message summarizes RSVP message formats and handling as modified 1333 by GMPLS. 1335 10.1. RSVP Message Formats 1337 This section presents the RSVP message related formats as modified by 1338 this document. Where they differ, formats for unidirectional LSPs 1339 are presented separately from bidirectional LSPs. Unmodified formats 1340 are not listed. Again, MESSAGE_ID and related objects are defined in 1341 [RFC2961]. 1343 The format of a Path message is as follows: 1345 ::= [ ] 1346 [ [ | ] ... ] 1347 [ ] 1348 1349 1350 [ ] 1351 1352 [ ] 1353 [ ... ] 1354 [ ] 1355 [ ] 1356 [ ] 1357 [ ... ] 1358 1360 The format of the sender description for unidirectional LSPs is: 1362 ::= 1363 [ ] 1364 [ ] 1365 [ ] 1366 [ ] 1368 The format of the sender description for bidirectional LSPs is: 1370 ::= 1371 [ ] 1372 [ ] 1373 [ ] 1374 [ ] 1375 1377 The format of a PathErr message is as follows: 1379 ::= [ ] 1380 [ [ | ] ... ] 1381 [ ] 1382 1383 [ ... ] 1384 [ ... ] 1385 1387 The format of a Resv message is as follows: 1389 ::= [ ] 1390 [ [ | ] ... ] 1391 [ ] 1392 1393 1394 [ ] [ ] 1395 [ ] 1396 [ ] 1397 [ ... ] 1398