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