idnits 2.17.1 draft-ietf-mpls-generalized-rsvp-te-02.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. == 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 Abstract section. ** 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 5 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 2001) is 8383 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 512, 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 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-rsvp-lsp-tunnel-08 Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 2 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: October 2001 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 Eric Mannie (EBONE) 9 Jonathan P. Lang (Calient Networks) 10 Bala Rajagopalan (Tellium, Inc.) 11 Yakov Rekhter (Juniper Networks, Inc.) 12 Debanjan Saha (Tellium, Inc.) 13 Vishal Sharma (Jasmine Networks) 14 George Swallow (Cisco Systems) 15 Z. Bo Tang (Tellium, Inc.) 17 April 2001 19 Generalized MPLS Signaling - RSVP-TE Extensions 21 draft-ietf-mpls-generalized-rsvp-te-02.txt 23 Status of this Memo 25 This document is an Internet-Draft and is in full conformance with 26 all provisions of Section 10 of RFC2026. Internet-Drafts are working 27 documents of the Internet Engineering Task Force (IETF), its areas, 28 and its working groups. Note that other groups may also distribute 29 working documents as Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/1id-abstracts.html 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 41 Abstract 43 This document describes extensions to RSVP-TE signaling required to 44 support Generalized MPLS. Generalized MPLS extends MPLS to encompass 45 time-division (e.g. SONET ADMs), wavelength (optical lambdas) and 46 spatial switching (e.g. incoming port or fiber to outgoing port or 47 fiber). This document presents an RSVP-TE specific description of 48 the extensions. A CR-LDP specific description can be found in 49 [GMPLS-LDP]. A generic functional description is presented in 50 [GMPLS-SIG]. 52 Contents 54 1 Introduction .............................................. 3 55 2 Label Related Formats .................................... 3 56 2.1 Generalized Label Request ................................ 3 57 2.1.1 Procedures ................................................ 4 58 2.1.2 Bandwidth Encoding ........................................ 5 59 2.2 Generalized Label ......................................... 5 60 2.2.1 Procedures ................................................ 5 61 2.3 Waveband Switching ........................................ 6 62 2.3.1 Procedures ................................................ 6 63 2.4 Suggested Label ........................................... 7 64 2.5 Label Set ................................................. 7 65 2.5.1 Procedures ................................................ 8 66 3 Bidirectional LSPs ........................................ 9 67 3.1 Procedures ................................................ 9 68 3.2 Contention Resolution ..................................... 9 69 4 Notification .............................................. 10 70 4.1 Acceptable Label Set Object ............................... 10 71 4.2 Notify Request Objects .................................... 11 72 4.2.1 Required Information ...................................... 11 73 4.2.2 Procedures ................................................ 12 74 4.3 Notify Message ............................................ 12 75 4.3.1 Required Information ...................................... 13 76 4.3.2 Procedures ................................................ 13 77 4.4 Removing State with a PathErr message ..................... 14 78 5 Explicit Label Control .................................... 15 79 5.1 Procedures ................................................ 16 80 6 Protection Object ......................................... 17 81 6.1 Procedures ................................................ 17 82 7 RSVP Message Formats ...................................... 17 83 8 Acknowledgments ........................................... 19 84 9 Security Considerations ................................... 20 85 10 References ................................................ 20 86 11 Authors' Addresses ........................................ 21 87 Changes from previous version: 89 o Fixed format of notification message. Had 90 and reversed. 91 o Added Acceptable Label Set 92 o Removed SONET/SDH specifics. 94 1. Introduction 96 Generalized MPLS extends MPLS from supporting packet (PSC) interfaces 97 and switching to include support of three new classes of interfaces 98 and switching: Time-Division Multiplex (TDM), Lambda Switch (LSC) and 99 Fiber-Switch (FSC). A functional description of the extensions to 100 MPLS signaling needed to support the new classes of interfaces and 101 switching is provided in [GMPLS-SIG]. This document presents RSVP-TE 102 specific formats and mechanisms needed to support all four classes of 103 interfaces. CR-LDP extensions can be found in [GMPLS-LDP]. 105 [GMPLS-SIG] should be viewed as a companion document to this 106 document. The format of this document parallels [GMPLS-SIG]. In 107 addition to the other features of Generalized MPLS, this document 108 also defines RSVP-TE specific features to support rapid failure 109 notification, see Sections 4.2 and 4.3. 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 2. Label Related Formats 117 This section defines formats for a generalized label request, a 118 generalized label, support for waveband switching, suggested label 119 and label sets. 121 2.1. Generalized Label Request 123 A Path message SHOULD contain as specific an LSP Encoding Type as 124 possible to allow the maximum flexibility in switching by transit 125 LSRs. A Generalized Label Request object is set by the ingress node, 126 transparently passed by transit nodes, and used by the egress node. 128 The format of a Generalized Label Request is: 130 0 1 2 3 131 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 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Length | Class-Num (19)|C-Type (4)[TBA]| 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | LSP Enc. Type | Reserved | G-PID | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 See [GMPLS-SIG] for a description of parameters. 140 2.1.1. Procedures 142 A node processing a Path message containing a Generalized Label 143 Request must verify that the requested parameters can be satisfied by 144 the interface on which the incoming label is to be allocated, the 145 node itself, and by the interface on which the traffic will be 146 transmitted. The node may either directly support the LSP or it may 147 use a tunnel (FA), i.e., another class of switching. In either case, 148 each parameter must be checked. 150 Note that local node policy dictates when tunnels may be used and 151 when they may be created. Local policy may allow for tunnels to be 152 dynamically established or may be solely administratively controlled. 153 For more information on tunnels and processing of ER hops when using 154 tunnels see [MPLS-HIERARCHY]. 156 Transit and egress nodes MUST verify that the node itself and, where 157 appropriate, that the interface or tunnel on which the traffic will 158 be transmitted can support the requested LSP Encoding Type. If 159 encoding cannot be supported, the node MUST generate a PathErr 160 message, with a "Routing problem/Unsupported Encoding" indication. 162 The G-PID parameter is normally only examined at the egress. If the 163 indicated G-PID cannot be supported then the egress MUST generate a 164 PathErr message, with a "Routing problem/Unsupported L3PID" 165 indication. In the case of PSC and when penultimate hop popping 166 (PHP) is requested, the penultimate hop also examines the (stored) G- 167 PID during the processing of the Resv message. In this case if the 168 G-PID is not supported, then the penultimate hop MUST generate a 169 ResvErr message with a "Routing problem/Unacceptable label value" 170 indication. The generated ResvErr message MAY include an Acceptable 171 Label Set, see Section 4.1. 173 When an error message is not generated, normal processing occurs. In 174 the transit case this will typically result in a Path message being 175 propagated. In the egress case and PHP special case this will 176 typically result in a Resv message being generated. 178 2.1.2. Bandwidth Encoding 180 Bandwidth encodings are carried in the SENDER_TSPEC and FLOWSPEC 181 objects. See [GMPLS-SIG] for a definition of values to be used for 182 specific signal types. These values are set in the Peak Data Rate 183 field of Int-Serv objects. Other bandwidth/service related 184 parameters in the object are ignored and carried transparently. 186 2.2. Generalized Label 188 The format of a Generalized Label is: 190 0 1 2 3 191 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 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Length | Class-Num (16)| C-Type (2) | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Label | 196 | ... | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 See [GMPLS-SIG] for a description of parameters and encoding of 200 labels. 202 2.2.1. Procedures 204 The Generalized Label travels in the upstream direction in Resv 205 messages. 207 The presence of both a generalized and normal label object in a Resv 208 message is a protocol error and should treated as a malformed message 209 by the recipient. 211 The recipient of a Resv message containing a Generalized Label 212 verifies that the values passed are acceptable. If the label is 213 unacceptable then the recipient MUST generate a ResvErr message with 214 a "Routing problem/MPLS label allocation failure" indication. 216 2.3. Waveband Switching 218 Waveband switching uses the same format as the generalized label, see 219 section 2.2. For compatibility reasons, a new RSVP c-type (3) is 220 assigned for the Waveband Label. 222 In the context of waveband switching, the generalized label has the 223 following format: 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Length | Class-Num (16)| C-Type (3) | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Waveband Id | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Start Label | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | End Label | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 See [GMPLS-SIG] for a description of parameters. 239 2.3.1. Procedures 241 The procedures defined in Section 2.2.1 apply to waveband switching. 242 This includes generating a ResvErr message with a "Routing 243 problem/MPLS label allocation failure" indication if any of the label 244 fields are unrecognized or unacceptable. 246 Additionally, when a waveband is switched to another waveband, it is 247 possible that the wavelengths within the waveband will be mirrored 248 about a center frequency. When this type of switching is employed, 249 the start and end label in the waveband label object MUST be flipped 250 before forwarding the label object with the new waveband Id. In this 251 manner an egress/ingress LSR which receives a waveband label which 252 has these values inverted, knows that it must also invert its egress 253 association to pick up the proper wavelengths. Without this 254 mechanism and with an odd number of mirrored switching operations, 255 the egress LSRs will not know that an input wavelength of say L1 will 256 emerge from the waveband tunnel as L100. 258 This operation MUST be performed in both directions when a 259 bidirectional waveband tunnel is being established. 261 2.4. Suggested Label 263 The format of a suggested label is identical to a generalized label. 264 It is used in Path messages. Suggested Label uses a new Class-Number 265 (TBA of form 10bbbbbb) and the C-type of the label being suggested. 267 Errors in received Suggested Labels MUST be ignored. This includes 268 any received inconsistent or unacceptable values. 270 2.5. Label Set 272 The Label_Set object uses a Class-Number TBA (of form 0bbbbbbb) and 273 the C-type of 1. 275 The format of a Label_Set is: 277 0 1 2 3 278 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 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Length | Class-Num(TBA)| C-Type (1) | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Reserved | Label Type | Action | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Subchannel 1 | 285 | ... | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 : : : 288 : : : 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Subchannel N | 291 | ... | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 Label Type: 8 bits 296 Indicates the type and format of the labels carried in the 297 object. Values match the C-Type of the appropriate Label 298 object. 300 See [GMPLS-SIG] for a description of other parameters. 302 2.5.1. Procedures 304 A Label Set is defined via one or more Label_Set objects. Specific 305 labels/subchannels can be added to or excluded from a Label Set via 306 Action zero (0) and one (1) objects respectively. Ranges of 307 labels/subchannels can be added to or excluded from a Label Set via 308 Action two (2) and three (3) objects respectively. When the 309 Label_Set objects only list labels/subchannels to exclude, this 310 implies that all other labels are acceptable. 312 The absence of any Label_Set objects implies that all labels are 313 acceptable. A Label Set is included when a node wishes to restrict 314 the label(s) that may be used downstream. 316 On reception of a Path message, the receiving node will restrict its 317 choice of labels to one which is in the Label Set. Nodes capable of 318 performing label conversion may also remove the Label Set prior to 319 forwarding the Path message. If the node is unable to pick a label 320 from the Label Set or if there is a problem parsing the Label_Set 321 objects, then the request is terminated and a PathErr message with a 322 "Routing problem/Label Set" indication MUST be generated. It is a 323 local matter if the Label Set is stored for later selection on the 324 Resv or if the selection is made immediately for propagation in the 325 Resv. 327 On reception of a Path message, the Label Set represented in the 328 message is compared against the set of available labels at the 329 downstream interface and the resulting intersecting Label Set is 330 forwarded in a Path message. When the resulting Label Set is empty, 331 the Path must be terminated, and a PathErr message, and a "Routing 332 problem/Label Set" indication MUST be generated. Note that 333 intersection is based on the physical labels (actual wavelength/band 334 values) which may have different logical values on different links, 335 as a result it is the responsibility of the node to map these values 336 so that they have a consistent physical meaning, or to drop the 337 particular values from the set if no suitable logical label value 338 exists. 340 When processing a Resv message at an intermediate node, the label 341 propagated upstream MUST fall within the Label Set. 343 Note, on reception of a Resv message a node that is incapable of 344 performing label conversion has no other choice than to use the same 345 physical label (wavelength/band) as received in the Resv message. In 346 this case, the use and propagation of a Label Set will significantly 347 reduce the chances that this allocation will fail. 349 3. Bidirectional LSPs 351 Bidirectional LSP setup is indicated by the presence of an Upstream 352 Label in the Path message. An Upstream Label has the same format as 353 the generalized label, see Section 2.2. The Upstream Label uses 354 Class-Number TBA (of form 0bbbbbbb) and the C-type of the label being 355 suggested. 357 3.1. Procedures 359 The process of establishing a bidirectional LSP follows the 360 establishment of a unidirectional LSP with some additions. To 361 support bidirectional LSPs an Upstream Label is added to the Path 362 message. The Upstream Label MUST indicate a label that is valid for 363 forwarding at the time the Path message is sent. 365 When a Path message containing an Upstream Label is received, the 366 receiver first verifies that the upstream label is acceptable. If 367 the label is not acceptable, the receiver MUST issue a PathErr 368 message with a "Routing problem/Unacceptable label value" indication. 369 The generated PathErr message MAY include an Acceptable Label Set, 370 see Section 4.1. 372 An intermediate node must also allocate a label on the outgoing 373 interface and establish internal data paths before filling in an 374 outgoing Upstream Label and propagating the Path message. If an 375 intermediate node is unable to allocate a label or internal 376 resources, then it MUST issue a PathErr message with a "Routing 377 problem/Label allocation failure" indication. 379 Terminator nodes process Path messages as usual, with the exception 380 that the upstream label can immediately be used to transport data 381 traffic associated with the LSP upstream towards the initiator. 383 When a bidirectional LSP is removed, both upstream and downstream 384 labels are invalidated and it is no longer valid to send data using 385 the associated labels. 387 3.2. Contention Resolution 389 There are two additional contention resolution related considerations 390 when controlling bidirectional LSP setup via RSVP-TE. The first is 391 that for the purposes of RSVP contention resolution, the node ID is 392 the IP address used in the RSVP_HOP object. The second is that a 393 neighbor's node ID might not be known when sending an initial Path 394 message. When this case occurs, a node should suggest a label chosen 395 at random from the available label space. 397 4. Notification 399 This section covers several notification related extensions. The 400 first extension defines the Acceptable Label Set object to support 401 Notification on Label Error, per [GMPLS-SIG]. The second and third 402 extensions enable expedited notification of failures and other events 403 to nodes responsible for restoring failed LSPs. (The second 404 extension, the Notify Request object, identifies where event 405 notifications are to be sent. The third extension, the Notify 406 message, provides for general event notification.) The final 407 extension allows for the removal of Path state on handling of PathErr 408 messages. 410 4.1. Acceptable Label Set Object 412 Acceptable_Label_Set objects use a Class-Number TBA (of form 413 11bbbbbb). The remaining contents of the object, including C-type, 414 have the identical format as the Label_Set object, see Section 2.5. 416 Acceptable_Label_Set objects may be carried in PathErr and ResvErr 417 messages. The procedures for defining an Acceptable Label Set follow 418 the procedures for defining a Label Set, see Section 2.5.1. 419 Specifically, an Acceptable Label Set is defined via one or more 420 Acceptable_Label_Set objects. Specific labels/subchannels can be 421 added to or excluded from an Acceptable Label Set via Action zero 422 (0) and one (1) objects respectively. Ranges of labels/subchannels 423 can be added to or excluded from an Acceptable Label Set via Action 424 two (2) and three (3) objects respectively. When the 425 Acceptable_Label_Set objects only list labels/subchannels to exclude, 426 this implies that all other labels are acceptable. 428 The inclusion of Acceptable_Label_Set objects is optional. If 429 included, the PathErr or ResvErr message SHOULD contain a "Routing 430 problem/Unacceptable label value" indication. The absence of 431 Acceptable_Label_Set objects does not have any specific meaning. 433 4.2. Notify Request Objects 435 Notifications may be sent via the Notify message defined below. The 436 Notify Request object is used to request the generation of 437 notifications. Notifications, i.e., the sending of a Notify message, 438 may be requested in both the upstream and downstream directions. 440 4.2.1. Required Information 442 The Notify Request Object may be carried in Path or Resv Messages, 443 see Section 7. The NOTIFY_REQUEST Class-Number is TBA (of form 444 11bbbbbb). The format of a Notify Request is: 446 o IPv4 Notify Request Object 447 0 1 2 3 448 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 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Length | Class-Num(TBA)| C-Type (1) | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | IPv4 Notify Node Address | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 IPv4 Notify Node Address: 32 bits 457 The IP address of the node that should be notified when 458 generating an error message. 460 o IPv6 Notify Request Object 461 0 1 2 3 462 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 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Length | Class-Num(TBA)| C-Type (2) | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | | 467 | IPv6 Notify Node Address | 468 | | 469 | | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 IPv6 Notify Node Address: 16 bytes 474 The IP address of the node that should be notified when 475 generating an error message. 477 If a message contains multiple NOTIFY_REQUEST objects, only the first 478 object is meaningful. Subsequent NOTIFY_REQUEST objects MAY be 479 ignored and SHOULD NOT be propagated. 481 4.2.2. Procedures 483 A Notify Request object may be inserted in Path or Resv messages to 484 indicate the address of a node that should be notified of an LSP 485 failure. As previously mentioned, notifications may be requested in 486 both the upstream and downstream directions. Upstream notification is 487 indicated via the inclusion of a Notify Request Object in the 488 corresponding Path message. Downstream notification is indicated via 489 the inclusion of a Notify Request Object in the corresponding Resv 490 message. 492 A node receiving a message containing a Notify Request object SHOULD 493 store the Notify Node Address in the corresponding state block. If 494 the node is a transit node, it SHOULD also included a Notify Request 495 object in the outgoing Path or Resv message. The outgoing Notify 496 Node Address MAY be updated based on local policy. 498 Note that the inclusion of a Notify Request object does not guarantee 499 that a Notify message will be generated. 501 4.3. Notify Message 503 The Notify message provides a mechanism to inform non-adjacent nodes 504 of LSP related events. Notify messages are only generated after a 505 Notify Request object has been received. The Notify message differs 506 from the currently defined error messages (i.e., PathErr and ResvErr 507 messages) in that it can be "targeted" to a node other than the 508 immediate upstream or downstream neighbor and that it is a 509 generalized notification mechanism. The Notify message does not 510 replace existing error messages. The Notify message may be sent 511 either (a) normally, where non-target nodes just forward the Notify 512 message to the target node, similar to ResvConf processing in [RSVP]; 513 or (b) encapsulated in a new IP header whose destination is equal to 514 the target IP address. Regardless of the transmission mechanism, 515 nodes receiving a Notify message not destined to the node forward the 516 message, unmodified, towards the target. 518 To support reliable delivery of the Notify message, an Ack Message 519 [RSVP-RR] is used to acknowledge the receipt of a Notify Message. 520 See [RSVP-RR] for details on reliable RSVP message delivery. 522 4.3.1. Required Information 524 The Notify message is a generalized notification message. The IP 525 destination address is set to the IP address of the intended 526 receiver. The Notify message is sent without the router alert 527 option. A single Notify message may contain notifications being 528 sent, with respect to each listed session, both upstream and 529 downstream. 531 The Notify message has a Msg Type of TBA (by IANA). The Notify 532 message format is as follows: 534 ::= [] 535 [ [ | ] ... ] 536 [ ] 537 539 ::= [ ] 540 | 541 543 ::= [...] 544 546 ::= [...] 547 549 The ERROR_SPEC object specifies the error and includes the IP address 550 of either the node that detected the error or the link that has 551 failed. See ERROR_SPEC definition in [RFC2205]. The MESSAGE_ID and 552 related objects are defined in [RSVP-RR] and are used when refresh 553 reductions is supported. 555 4.3.2. Procedures 557 Notify messages are generated at nodes that detect an error that will 558 trigger the generation of a PathErr or ResvErr message. If a PathErr 559 message is to be generated and a Notify Request object has been 560 received in the corresponding Path message, then a Notify message 561 destined to the recorded node SHOULD be generated. If a ResvErr 562 message is to be generated and a Notify Request object has been 563 received in the corresponding Resv message, then a Notify message 564 destined to the recorded node SHOULD be generated. As previously 565 mentioned, a single error may generate a Notify message in both the 566 upstream and downstream directions. Note that a Notify message MUST 567 NOT be generated unless an appropriate Notify Request object has been 568 received. 570 When generating Notify messages, a node SHOULD attempt to combine 571 notifications being sent to the same Notify Node and that share the 572 same ERROR_SPEC into a single Notify message. The means by which a 573 node determines which information may be combined is implementation 574 dependent. Implementations may use event, timer based or other 575 approaches. If using a timer based approach, the implementation 576 SHOULD allow the user to configure the interval over which 577 notifications are combined. When using a timer based approach, a 578 default "notification interval" of 1 ms SHOULD be used. Notify 579 messages SHOULD be delivered using the reliable message delivery 580 mechanisms defined in [RSVP-RR]. 582 Upon receiving a Notify message, the Notify Node SHOULD send a 583 corresponding Ack message. 585 4.4. Removing State with a PathErr message 587 The PathErr message as defined in [RFC2205] is sent hop-by-hop to the 588 source of the associated Path message. Intermediate nodes may 589 inspect this message, but take no action upon it. In an environment 590 where Path messages are routed according to an IGP and that route may 591 change dynamically, this behavior is a fine design choice. 593 However, when RSVP is used with explicit routes, it is often the case 594 that errors can only be corrected at the source node or some other 595 node further upstream. In order to clean up resources, the source 596 must receive the PathErr and then either send a PathTear (or wait for 597 the messages to timeout). This causes idle resources to be held 598 longer than necessary and increases control message load. In a 599 situation where the control plane is attempting to recover from a 600 serious outage, both the message load and the delay in freeing 601 resources hamper the ability to rapidly reconverge. 603 The situation can be greatly improved by allowing state to be removed 604 by intermediate nodes on certain error conditions. To facilitate 605 this a new flag is defined in the ERROR_SPEC object. The two 606 currently defined ERROR_SPEC objects (IPv4 and IPv6 error spec 607 objects) each contain a one byte flag field. Within that field two 608 flags are defined. This specification defines a third flag, 0x04, 609 Path_State_Removed. 611 The semantics of the Path_State_Removed flag are simply that the node 612 forwarding the error message has removed the Path state associated 613 with the PathErr. By default, the Path_State_Removed flag is always 614 set to zero when generating or forwarding a PathErr message. A node 615 which encounters an error MAY set this flag if the error results in 616 the associated Path state being discarded. If the node setting the 617 flag is not the session endpoint, the node SHOULD generate a 618 corresponding PathTear. A node receiving a PathErr message 619 containing an ERROR_SPEC object with the Path_State_Removed flag set 620 MAY also remove the associated Path state. If the Path state is 621 removed the Path_State_Removed flag SHOULD be set in the outgoing 622 PathErr message. A node which does not remove the associated Path 623 state MUST NOT set the Path_State_Removed flag. A node that receives 624 an error with the Path_State_Removed flag set to zero MUST NOT set 625 this flag unless it also generates a corresponding PathTear message. 627 Note that the use of this flag does not result in any 628 interoperability incompatibilities. 630 5. Explicit Label Control 632 The Label ERO subobject is defined as follows: 634 0 1 2 3 635 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 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 |L| Type | Length |U| Reserved | C-Type | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | Label | 640 | ... | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 See [GMPLS-SIG] for a description of L, U and Label parameters. 645 Type 647 3 Label 649 Length 651 The Length contains the total length of the subobject in bytes, 652 including the Type and Length fields. The Length is always 653 divisible by 4. 655 C-Type 657 The C-Type of the included Label Object. Copied from the Label 658 Object. 660 5.1. Procedures 662 The Label subobject follows a subobject containing the IP address, or 663 the interface identifier [MPLS-UNNUM], associated with the link on 664 which it is to be used. The preceding subobject must be a strict 665 object. Up to two label subobjects may be present, one for the 666 downstream label and one for the upstream label. The following 667 SHOULD result in "Bad EXPLICIT_ROUTE object" errors: 668 - If the first label subobject is not preceded by a subobject 669 containing an IP address, or a interface identifier 670 [MPLS-UNNUM], associated with an output link. 671 - For a label subobject to follow a subobject that has the L-bit 672 set 673 - On unidirectional LSP setup, for there to be a label subobject 674 with the U-bit set 675 - For there to be two label subobjects with the same U-bit values 677 To support the label subobject, a node must check to see if the 678 subobject following it's associate address/interface is a label 679 subobject. If it is, one subobject is examined for unidirectional 680 LSPs and two subobjects for bidirectional LSPs. If the U-bit of the 681 subobject being examined is clear (0), then value of the label is 682 copied into a new Label_Set object. This Label_Set object MUST be 683 included on the corresponding outgoing Path message. 685 If the U-bit of the subobject being examined is set (1), then value 686 of the label is label to be used for upstream traffic associated with 687 the bidirectional LSP. If this label is not acceptable, a "Bad 688 EXPLICIT_ROUTE object" error SHOULD be generated. If the label is 689 acceptable, the label is copied into a new Upstream Label object. 690 This Upstream Label object MUST be included on the corresponding 691 outgoing Path message. 693 After processing, the label subobjects are removed from the ERO. 695 Note an implication of the above procedures is that the label 696 subobject should never be the first subobject in a newly received 697 message. If the label subobject is the the first subobject an a 698 received ERO, then it SHOULD be treated as a "Bad strict node" error. 700 Procedures by which an LSR at the head-end of an LSP obtains the 701 information needed to construct the Label subobject are outside the 702 scope of this document. 704 6. Protection Object 706 The use of the Protection Object is optional. The object is included 707 to indicate specific protection attributes of an LSP. The Protection 708 Object uses a Class-Number TBA (of form 0bbbbbbb). 710 The format of Protection Information Object is: 712 0 1 2 3 713 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 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | Length | Class-Num(TBA)| C-Type (1) | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 |S| Reserved | Link Flags| 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 See [GMPLS-SIG] for a description of parameters. 722 6.1. Procedures 724 Transit nodes processing a Path message containing a Protection 725 Object MUST verify that the requested protection can be satisfied by 726 the outgoing interface or tunnel (FA). If it cannot, the node MUST 727 generate a PathErr message, with a "Routing problem/Unsupported Link 728 Protection" indication. 730 7. RSVP Message Formats 732 This section presents the RSVP message related formats as modified by 733 this document. Where they differ, formats for unidirectional LSPs 734 are presented separately from bidirectional LSPs. Unmodified formats 735 are not listed. Again, MESSAGE_ID and related objects are defined in 736 [RSVP-RR]. 738 The format of a Path message is as follows: 740 ::= [ ] 741 [ [ | ] ... ] 742 [ ] 743 744 745 [ ] 746 747 [ ] 748 [ ... ] 749 [ ] 750 [ ] 751 [ ... ] 752 754 The format of the sender description for unidirectional LSPs is: 756 ::= 757 [ ] 758 [ ] 759 [ ] 761 The format of the sender description for bidirectional LSPs is: 763 ::= 764 [ ] 765 [ ] 766 [ ] 767 769 The format of a PathErr message is as follows: 771 ::= [ ] 772 [ [ | ] ... ] 773 [ ] 774 775 [ ... ] 776 [ ... ] 777 779 The format of a Resv message is as follows: 781 ::= [ ] 782 [ [ | ] ... ] 783 [ ] 784 785 786 [ ] [ ] 787 [ ] 788 [ ... ] 789