idnits 2.17.1 draft-ietf-mpls-generalized-rsvp-te-01.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. ** 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: ---------------------------------------------------------------------------- == Line 695 has weird spacing: '... Object is:...' -- 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 (March 2001) is 8443 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 503, but not defined == Missing Reference: 'MPLS-UNNUM' is mentioned on line 655, but not defined == Outdated reference: A later version (-08) exists of draft-ietf-mpls-lsp-hierarchy-00 == 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: 5 errors (**), 0 flaws (~~), 9 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: September 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 March 2001 19 Generalized MPLS Signaling - RSVP-TE Extensions 21 draft-ietf-mpls-generalized-rsvp-te-01.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/ietf/1id-abstracts.txt 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 Generalized Label Request with SONET/SDH Label Range ...... 4 63 2.1.2 Procedures ................................................ 4 64 2.1.3 Bandwidth Encoding ........................................ 5 65 2.2 Generalized Label ......................................... 5 66 2.2.1 Procedures ................................................ 6 67 2.3 Waveband Switching ........................................ 6 68 2.3.1 Procedures ................................................ 6 69 2.4 Suggested Label ........................................... 7 70 2.5 Label Set ................................................. 7 71 2.5.1 Procedures ................................................ 8 72 3 Bidirectional LSPs ........................................ 9 73 3.1 Procedures ................................................ 9 74 3.2 Contention Resolution ..................................... 10 75 4 Notification .............................................. 10 76 4.1 Notify Request Objects .................................... 10 77 4.1.1 Required Information ...................................... 11 78 4.1.2 Procedures ................................................ 11 79 4.2 Notify Message ............................................ 12 80 4.2.1 Required Information ...................................... 12 81 4.2.2 Procedures ................................................ 13 82 4.3 Removing State with a PathErr message ..................... 14 83 5 Explicit Label Control .................................... 15 84 5.1 Procedures ................................................ 15 85 6 Protection Object ......................................... 16 86 6.1 Procedures ................................................ 17 87 7 RSVP Message Formats ...................................... 17 88 8 Acknowledgments ........................................... 18 89 9 Security Considerations ................................... 18 90 10 References ................................................ 19 91 11 Authors' Addresses ........................................ 19 92 Changes from previous version: 94 o Revised label request 95 o Moved protection flags to separate object 96 o Added IPv6 support to Notify message 97 o Minor text cleanup 99 1. Introduction 101 Generalized MPLS extends MPLS from supporting packet (PSC) interfaces 102 and switching to include support of three new classes of interfaces 103 and switching: Time-Division Multiplex (TDM), Lambda Switch (LSC) and 104 Fiber-Switch (FSC). A functional description of the extensions to 105 MPLS signaling needed to support the new classes of interfaces and 106 switching is provided in [GMPLS-SIG]. This document presents RSVP-TE 107 specific formats and mechanisms needed to support all four classes of 108 interfaces. CR-LDP extensions can be found in [GMPLS-LDP]. 110 [GMPLS-SIG] should be viewed as a companion document to this 111 document. The format of this document parallels [GMPLS-SIG]. In 112 addition to the other features of Generalized MPLS, this document 113 also defines RSVP-TE specific features to support rapid failure 114 notification, see Section 4. 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [RFC2119]. 120 2. Label Related Formats 122 This section defines formats for a generalized label request, a 123 generalized label, support for waveband switching, suggested label 124 and label sets. 126 2.1. Generalized Label Request 128 A Path message SHOULD contain as specific an LSP Encoding Type as 129 possible to allow the maximum flexibility in switching by transit 130 LSRs. A Generalized Label Request object is set by the ingress node, 131 transparently passed by transit nodes, and used by the egress node. 133 The format of a Generalized Label Request is: 135 0 1 2 3 136 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 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | Length | Class-Num (19)|C-Type (4)[TBA]| 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | LSP Enc. Type | Reserved | G-PID | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 See [GMPLS-SIG] for a description of parameters. 145 2.1.1. Generalized Label Request with SONET/SDH Label Range 147 The format of a Generalized Label Request with SONET/SDH Label Range 148 (in RSVP) is: 150 0 1 2 3 151 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 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Length | Class-Num (19)|C-Type (5)[TBA]| 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | LSP Enc. Type | Reserved | G-PID | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | RNC | Signal Type |Rsrved.| RGT | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 See [GMPLS-SIG] for a description of parameters. 162 2.1.2. Procedures 164 A node processing a Path message containing a Generalized Label 165 Request must verify that the requested parameters can be satisfied by 166 the incoming interface, the node and by the outgoing interface. The 167 node may either directly support the LSP or it may use a tunnel (FA), 168 i.e., another class of switching. In either case, each parameter 169 must be checked. 171 Note that local node policy dictates when tunnels may be used and 172 when they may be created. Local policy may allow for tunnels to be 173 dynamically established or may be solely administratively controlled. 174 For more information on tunnels and processing of ER hops when using 175 tunnels see [MPLS-HIERARCHY]. 177 Transit and egress nodes MUST verify that the node itself and, where 178 appropriate, that the outgoing interface or tunnel can support the 179 requested LSP Encoding Type. If encoding cannot be supported, the 180 node MUST generate a PathErr message, with a "Routing 181 problem/Unsupported Encoding" indication. 183 The G-PID parameter is normally only examined at the egress. If the 184 indicated G-PID cannot be supported then the egress MUST generate a 185 PathErr message, with a "Routing problem/Unsupported GPID" 186 indication. In the case of PSC and when penultimate hop popping 187 (PHP) is requested, the penultimate hop also examines the (stored) G- 188 PID during the processing of the Resv message. In this case if the 189 G-PID is not supported, then the penultimate hop MUST generate a 190 ResvErr message with a "Routing problem/Unacceptable label value" 191 indication. 193 When an error message is not generated, normal processing occurs. In 194 the transit case this will typically result in a Path message being 195 propagated. In the egress case and PHP special case this will 196 typically result in a Resv message being generated. 198 2.1.3. Bandwidth Encoding 200 Bandwidth encodings are carried in the SENDER_TSPEC and FLOWSPEC 201 objects. See [GMPLS-SIG] for a definition of values to be used for 202 specific signal types. These values are set in the Peak Data Rate 203 field of Int-Serv objects. Other bandwidth/service related 204 parameters in the object are ignored and carried transparently. 206 2.2. Generalized Label 208 The format of a Generalized Label is: 210 0 1 2 3 211 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 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Length | Class-Num (16)| C-Type (2) | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Label | 216 | ... | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 See [GMPLS-SIG] for a description of parameters and encoding of 220 SDH, SONET, port, wavelength and other labels. 222 2.2.1. Procedures 224 The Generalized Label travels in the upstream direction in Resv 225 messages. 227 The presence of both a generalized and normal label object in a Resv 228 message is a protocol error and should treated as a malformed message 229 by the recipient. 231 The recipient of a Resv message containing a Generalized Label 232 verifies that the values passed are acceptable. If the label is 233 unacceptable then the recipient MUST generate a ResvErr message with 234 a "Routing problem/MPLS label allocation failure" indication. 236 2.3. Waveband Switching 238 Waveband switching uses the same format as the generalized label, see 239 section 2.2. For compatibility reasons, a new RSVP c-type (3) is 240 assigned for the Waveband Label. 242 In the context of waveband switching, the generalized label has the 243 following format: 245 0 1 2 3 246 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 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Length | Class-Num (16)| C-Type (3) | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Waveband Id | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Start Label | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | End Label | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 See [GMPLS-SIG] for a description of parameters. 259 2.3.1. Procedures 261 The procedures defined in Section 2.2.1 apply to waveband switching. 262 This includes generating a ResvErr message with a "Routing 263 problem/MPLS label allocation failure" indication if any of the label 264 fields are unrecognized or unacceptable. 266 Additionally, when a waveband is switched to another waveband, it is 267 possible that the wavelengths within the waveband will be mirrored 268 about a center frequency. When this type of switching is employed, 269 the start and end label in the waveband label object MUST be flipped 270 before forwarding the label object with the new waveband Id. In this 271 manner an egress/ingress LSR which receives a waveband label which 272 has these values inverted, knows that it must also invert its egress 273 association to pick up the proper wavelengths. Without this 274 mechanism and with an odd number of mirrored switching operations, 275 the egress LSRs will not know that an input wavelength of say L1 will 276 emerge from the waveband tunnel as L100. 278 This operation MUST be performed in both directions when a 279 bidirectional waveband tunnel is being established. 281 2.4. Suggested Label 283 The format of a suggested label is identical to a generalized label. 284 It is used in Path messages. Suggested Label uses a new Class-Number 285 (TBD of form 10bbbbbb) and the C-type of the label being suggested. 287 Errors in received Suggested Labels MUST be ignored. This includes 288 any received inconsistent or unacceptable values. 290 2.5. Label Set 292 The Label_Set object uses a Class-Number TBA (of form 0bbbbbbb) and 293 the C-type of the label type being described. 295 The format of a Label_Set is: 297 0 1 2 3 298 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 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Length | Class-Num(TBA)| C-Type (1) | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Reserved | Label Type | Action | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Subchannel 1 | 305 | ... | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 : : : 308 : : : 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Subchannel N | 311 | ... | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 Label Type: 8 bits 316 Indicates the type and format of the labels carried in the 317 object. Values match the C-Type of the appropriate Label 318 object. 320 See [GMPLS-SIG] for a description of other parameters. 322 2.5.1. Procedures 324 A Label Set is defined via one or more Label_Set objects. Specific 325 labels/subchannels can be added to or excluded from a Label Set via 326 Action zero (0) and one (1) objects respectively. Ranges of 327 labels/subchannels can be added to or excluded from a Label Set via 328 Action two (2) and three (3) objects respectively. When the 329 Label_Set objects only list labels/subchannels to exclude, this 330 implies that all other labels are acceptable. 332 The absence of any Label_Set objects implies that all labels are 333 acceptable. A Label Set is included when a node wishes to restrict 334 the label(s) that may be used downstream. 336 On reception of a Path message a CI-capable interface will restrict 337 its choice of labels to one which is in the Label Set. The CI- 338 capable receiver may also remove the Label Set prior to forwarding 339 the Path message. If the node is unable to pick a label from the 340 Label Set or if there is a problem parsing the Label_Set objects, 341 then the request is terminated and a PathErr message with a "Routing 342 problem/Label Set" indication MUST be generated. It is a local matter 343 if the Label Set is stored for later selection on the Resv or if the 344 selection is made immediately for propagation in the Resv. 346 On reception of a Path message for a CI-incapable interface, the 347 Label Set represented in the message is compared against the set of 348 available labels at the downstream interface and the resulting 349 intersecting Label Set is forwarded in a Path message. When the 350 resulting Label Set is empty, the Path must be terminated, and a 351 PathErr message, and a "Routing problem/Label Set" indication MUST be 352 generated. Note that intersection is based on the physical labels 353 (actual wavelength/band values) which may have different logical 354 values on different links, as a result it is the responsibility of 355 the node to map these values so that they have a consistent physical 356 meaning, or to drop the particular values from the set if no suitable 357 logical label value exists. 359 When processing a Resv message at an intermediate node, the label 360 propagated upstream MUST fall within the Label Set. 362 Note, on reception of a Resv message for an interface which is CI- 363 incapable it has no other choice than to use the same physical label 364 (wavelength/band) as received in the Resv. In this case, the use and 365 propagation of a Label Set will significantly reduce the chances that 366 this allocation will fail when CI-incapable nodes are traversed. 368 3. Bidirectional LSPs 370 Bidirectional LSP setup is indicated by the presence of an Upstream 371 Label in the Path message. An Upstream Label has the same format as 372 the generalized label, see Section 2.2. The Upstream Label uses 373 Class-Number TBD (of form 0bbbbbbb) and the C-type of the label being 374 suggested. 376 3.1. Procedures 378 The process of establishing a bidirectional LSP follows the 379 establishment of a unidirectional LSP with some additions. To 380 support bidirectional LSPs an Upstream Label is added to the Path 381 message. The Upstream Label MUST indicate a label that is valid for 382 forwarding at the time the Path message is sent. 384 When a Path message containing an Upstream Label is received, the 385 receiver first verifies that the upstream label is acceptable. If 386 the label is not acceptable, the receiver MUST issue a PathErr 387 message with a "Routing problem/Unacceptable label value" indication. 389 An intermediate node must also allocate a label on the outgoing 390 interface and establish internal data paths before filling in an 391 outgoing Upstream Label and propagating the Path message. If an 392 intermediate node is unable to allocate a label or internal 393 resources, then it MUST issue a PathErr message with a "Routing 394 problem/Label allocation failure" indication. 396 Terminator nodes process Path messages as usual, with the exception 397 that the upstream label can immediately be used to transport data 398 traffic associated with the LSP upstream towards the initiator. 400 When a bidirectional LSP is removed, both upstream and downstream 401 labels are invalidated and it is no longer valid to send data using 402 the associated labels. 404 3.2. Contention Resolution 406 There are two additional contention resolution related considerations 407 when controlling bidirectional LSPs setup via RSVP-TE. The first is 408 that for the purposes of RSVP contention resolution, the node ID is 409 the IP address used in the RSVP_HOP object. The second is that a 410 neighbor's node ID might not be known when sending an initial Path 411 message. When this case occurs, a node should suggest a label chosen 412 at random from the available label space. 414 4. Notification 416 This section defines three signaling extensions that modify error 417 handling, enable expedited notification of failures and other events 418 to nodes responsible for restoring failed LSPs. The first extension, 419 the Notify Request object, identifies where event notifications are 420 to be sent. The second, the Notify message, provides for general 421 event notification. The final extension allows for the removal of 422 Path state on handling of PathErr messages. 424 4.1. Notify Request Objects 426 Notifications may be sent via the Notify message defined below. The 427 Notify Request object is used to request the generation of 428 notifications. Notifications, i.e., the sending of a Notify message, 429 may be requested in both the upstream and downstream directions. 431 4.1.1. Required Information 433 The Notify Request Object may be carried in Path or Resv Messages, 434 see Section 6. The NOTIFY_REQUEST Class-Number is TBA (of form 435 11bbbbbb). The format of a Notify Request is: 437 o IPv4 Notify Request Object 438 0 1 2 3 439 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 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Length | Class-Num(TBD)| C-Type (1) | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | IPv4 Notify Node Address | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 IPv4 Notify Node Address: 32 bits 448 The IP address of the node that should be notified when 449 generating an error message. 451 o IPv6 Notify Request Object 452 0 1 2 3 453 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 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Length | Class-Num(TBD)| C-Type (2) | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | | 458 | IPv6 Notify Node Address | 459 | | 460 | | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 IPv6 Notify Node Address: 16 bytes 465 The IP address of the node that should be notified when 466 generating an error message. 468 If a message contains multiple NOTIFY_REQUEST objects, only the first 469 object is meaningful. Subsequent NOTIFY_REQUEST objects MAY be 470 ignored and SHOULD NOT be propagated. 472 4.1.2. Procedures 474 A Notify Request object may be inserted in Path or Resv messages to 475 indicate the address of a node that should be notified of an LSP 476 failure. As previously mentioned, notifications may be requested in 477 both the upstream and downstream directions. Upstream notification is 478 indicated via the inclusion of a Notify Request Object in the 479 corresponding Path message. Downstream notification is indicated via 480 the inclusion of a Notify Request Object in the corresponding Resv 481 message. 483 A node receiving a message containing a Notify Request object SHOULD 484 store the Notify Node Address in the corresponding state block. If 485 the node is a transit node, it SHOULD also included a Notify Request 486 object in the outgoing Path or Resv message. The outgoing Notify 487 Node Address MAY be updated based on local policy. 489 Note that the inclusion of a Notify Request object does not guarantee 490 that a Notify message will be generated. 492 4.2. Notify Message 494 The Notify message provides a mechanism to inform non-adjacent nodes 495 of LSP related events. Notify messages are only generated after a 496 Notify Request object has been received. The Notify message differs 497 from the currently defined error messages (i.e., PathErr and ResvErr 498 messages of RSVP) in that it can be "targeted" to a node other than 499 the immediate upstream or downstream neighbor and that it is a 500 generalized notification mechanism. The Notify message does not 501 replace existing error messages. The Notify message may be sent 502 either (a) normally, where non-target nodes just forward the Notify 503 message to the target node, similar to ResvConf processing in [RSVP]; 504 or (b) encapsulated in a new IP header whose destination is equal to 505 the target IP address. Regardless of the transmission mechanism, 506 nodes receiving a Notify message not destined to the node forward the 507 message, unmodified, towards the target. 509 To support reliable delivery of the Notify message, an Ack Message 510 [RSVP-RR] is used to acknowledge the receipt of a Notify Message. 511 See [RSVP-RR] for details on reliable RSVP message delivery. 513 4.2.1. Required Information 515 The Notify message is a generalized notification message. The IP 516 destination address is set to the IP address of the intended 517 receiver. The Notify message is sent without the router alert 518 option. A single Notify message may contain notifications being 519 sent, with respect to each listed session, both upstream and 520 downstream. 522 ::= [] 523 525 ::= [ ] 526 | 527 529 ::= [...] 530 532 ::= [...] 533 535 The ERROR_SPEC object specifies the error and includes the IP address 536 of either the node that detected the error or the link that has 537 failed. See ERROR_SPEC definition in [RFC2205]. The MESSAGE_ID 538 object is defined in [RSVP-RR]. 540 4.2.2. Procedures 542 Notify messages are generated at nodes that detect an error that will 543 trigger the generation of a PathErr or ResvErr message. If a PathErr 544 message is to be generated and a Notify Request object has been 545 received in the corresponding Path message, then a Notify message 546 destined to the recorded node SHOULD be generated. If a ResvErr 547 message is to be generated and a Notify Request object has been 548 received in the corresponding Resv message, then a Notify message 549 destined to the recorded node SHOULD be generated. As previously 550 mentioned, a single error may generate a Notify message in both the 551 upstream and downstream directions. Note a Notify message MUST NOT 552 be generated unless an appropriate Notify Request object has been 553 received. 555 When generating Notify messages, a node SHOULD attempt to combine 556 notifications being sent to the same Notify Node and that share the 557 same ERROR_SPEC into a single Notify message. The means by which a 558 node determines which information may be combined is implementation 559 dependent. Implementations may use event, timer based or other 560 approaches. If using a timer based approach, the implementation 561 SHOULD allow the user to configure the interval over which 562 notifications are combined. When using a timer based approach, a 563 default "notification interval" of 1 ms SHOULD be used. Notify 564 messages SHOULD be delivered using the reliable message delivery 565 mechanisms defined in [RSVP-RR]. 567 Upon receiving a Notify message, the Notify Node SHOULD send a 568 corresponding Ack message. 570 4.3. Removing State with a PathErr message 572 The PathErr message as defined in [RFC2205] is sent hop-by-hop to the 573 source of the associated Path message. Intermediate nodes may 574 inspect this message, but take no action upon it. In an environment 575 where Path messages are routed according to an IGP and that route may 576 change dynamically, this behavior is a fine design choice. 578 However, when RSVP is used with explicit routes, it is often the case 579 that errors can only be corrected at the source node or some other 580 node further upstream. In order to clean up resources, the source 581 must receive the PathErr and then either send a PathTear (or wait for 582 the messages to timeout). This causes idle resources to be held 583 longer than necessary increases control message load. In a situation 584 where the control plane is attempting to recover from a serious 585 outage, both the message load and the delay in freeing resources 586 hamper the ability to rapidly reconverge. 588 The situation can be greatly improved by allowing state to be removed 589 by intermediate nodes on certain error conditions. To facilitate 590 this a new flag is defined in the ERROR_SPEC object. The two 591 currently defined ERROR_SPEC objects (IPv4 and IPv6 error spec 592 objects) each contain a one byte flag field. Within that field two 593 flags are defined. This specification defines a third flag, 0x04, 594 Path_State_Removed. 596 The semantics of the Path_State_Removed flag are simply that the node 597 forwarding the error message has removed the Path state associated 598 with the PathErr. By default, the Path_State_Removed flag is always 599 set to zero when generating or forwarding a PathErr message. A node 600 which encounters an error MAY set this flag if the error results in 601 the associated Path state being discarded. If the node setting the 602 flag is not the session endpoint, the node SHOULD generate a 603 corresponding PathTear. A node receiving a PathErr message 604 containing an ERROR_SPEC object with the Path_State_Removed flag set 605 MAY also remove the associated Path state. If the Path state is 606 removed the Path_State_Removed flag SHOULD be set in the outgoing 607 PathErr message. A node which does not remove the associated Path 608 state MUST NOT set the Path_State_Removed flag. A node that receives 609 an error with the Path_State_Removed flag set to zero MUST NOT set 610 this flag unless it also generates a corresponding PathTear message. 612 Note that the use of this flag does not result in any 613 interoperability incompatibilities. 615 5. Explicit Label Control 617 The Label ERO subobject is defined as follows: 619 0 1 2 3 620 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 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 |L| Type | Length |U| Reserved | C-Type | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | Label | 625 | ... | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 See [GMPLS-SIG] for a description of L, U and Label parameters. 630 Type 632 3 Label 634 Length 636 The Length contains the total length of the subobject in bytes, 637 including the Type and Length fields. The Length is always 638 divisible by 4. 640 C-Type 642 The C-Type of the included Label Object. Copied from the Label 643 Object. 645 5.1. Procedures 647 The Label subobject follows a subobject containing the IP address, or 648 the interface identifier [MPLS-UNNUM], associated with the link on 649 which it is to be used. The preceding subobject must be a strict 650 object. Up to two label subobjects may be present, one for the 651 downstream label and one for the upstream label. The following 652 SHOULD result in "Bad EXPLICIT_ROUTE object" errors: 653 - If the first label subobject is not preceded by a subobject 654 containing an IP address, or a interface identifier 655 [MPLS-UNNUM], associated with an output link. 656 - For a label subobject to follow a subobject that has the L-bit 657 set 658 - On unidirectional LSP setup, for there to be a label subobject 659 with the U-bit set 660 - For there to be two label subobjects with the same U-bit values 662 To support the label subobject, a node must check to see if the 663 subobject following it's associate address/interface is a label 664 subobject. If it is, one subobject is examined for unidirectional 665 LSPs and two subobjects for bidirectional LSPs. If the U-bit of the 666 subobject being examined is clear (0), then value of the label is 667 copied into a new Label_Set object. This Label_Set object MUST be 668 included on the corresponding outgoing Path message. 670 If the U-bit of the subobject being examined is set (1), then value 671 of the label is label to be used for upstream traffic associated with 672 the bidirectional LSP. If this label is not acceptable, a "Bad 673 EXPLICIT_ROUTE object" error SHOULD be generated. If the label is 674 acceptable, the label is copied into a new Upstream Label object. 675 This Upstream Label object MUST be included on the corresponding 676 outgoing Path message. 678 After processing, the label subobjects are removed from the ERO. 680 Note an implication of the above procedures is that the label 681 subobject should never be the first subobject in a newly received 682 message. If the label subobject is the the first subobject an a 683 received ERO, then it SHOULD be treated as a "Bad strict node" error. 685 Procedures by which an LSR at the head-end of an LSP obtains the 686 information needed to construct the Label subobject are outside the 687 scope of this document. 689 6. Protection Object 691 The use of the Protection Object is optional. The object is included 692 to indicate specific protection attributes of an LSP. The Protection 693 Object uses a Class-Number TBA (of form 0bbbbbbb). 695 The format of Protection Flags Object is: 697 0 1 2 3 698 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 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | Length | Class-Num(TBA)| C-Type (1) | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 |S| Reserved | Link Flags| 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 See [GMPLS-SIG] for a description of parameters. 707 6.1. Procedures 709 Transit nodes processing a Path message containing a Protection 710 Object MUST verify that the requested protection can be satisfied by 711 the outgoing interface or tunnel (FA). If it cannot, the node MUST 712 generate a PathErr message, with a "Routing problem/Unsupported Link 713 Protection" indication. 715 7. RSVP Message Formats 717 This section presents the RSVP message related formats as modified by 718 this document. Where they differ, formats for unidirectional LSPs 719 are presented separately from bidirectional LSPs. Unmodified formats 720 are not listed. 722 The format of a Path message is as follows: 724 ::= [ ] 725 726 727 [ ] 728 729 [ ] 730 [ ... ] 731 [ ] 732 [ ] 733 [ ... ] 734 736 The format of the sender description for unidirectional LSPs is: 738 ::= 739 [ ] 740 [ ] 741 [ ] 743 The format of the sender description for bidirectional LSPs is: 745 ::= 746 [ ] 747 [ ] 748 [ ] 749 751 The format of a Resv message is as follows: 753 ::= [ ] 754 755 756 [ ] [ ] 757 [ ] 758 [ ... ] 759