idnits 2.17.1 draft-chang-mpls-rsvpte-path-protection-ext-01.txt: -(72): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(202): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(248): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == There are 4 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 8) being 112 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 169 instances of too long lines in the document, the longest one being 65 characters in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 393 has weird spacing: '... values for ...' -- 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 (November 2000) is 8563 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) -- No information found for draft-ietf-mpls-revp-lsp-tunnel - is the name correct? -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-03) exists of draft-chang-mpls-path-protection-02 -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-08) exists of draft-ietf-mpls-recovery-frmwrk-00 ** Downref: Normative reference to an Informational draft: draft-ietf-mpls-recovery-frmwrk (ref. '3') -- Possible downref: Non-RFC (?) normative reference: ref. '4' == Outdated reference: A later version (-01) exists of draft-swallow-rsvp-bypass-label-00 -- Possible downref: Normative reference to a draft: ref. '5' == Outdated reference: A later version (-03) exists of draft-many-ip-optical-framework-01 -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: A later version (-01) exists of draft-hellstrand-mpls-recovery-merge-00 -- Possible downref: Normative reference to a draft: ref. '7' == Outdated reference: A later version (-01) exists of draft-kini-restoration-shared-backup-00 -- Possible downref: Normative reference to a draft: ref. '8' -- Possible downref: Normative reference to a draft: ref. '9' Summary: 9 errors (**), 0 flaws (~~), 11 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF Draft Vishal Sharma 2 Multi-Protocol Label Switching Srinivas Makam 3 Expires: May 2001 Ken Owens 4 Ben Mack-Crane 5 Tellabs Operations, Inc. 7 Changcheng Huang 8 Carleton University 10 Bora Akyol 11 Pluris, Inc. 13 November 2000 14 Extensions to RSVP-TE for MPLS Path Protection 16 18 Status of this memo 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other documents 30 at any time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Abstract 41 To deliver reliable service, multi-protocol label switching (MPLS) 42 requires a set of procedures to enable -protection of the traffic 43 carried on - label switched paths (LSPs). Thus existing signaling 44 mechanisms must be extended appropriately to support such 45 functionality. Recently, RSVP-TE [1] has introduced extensions to 46 RSVP to support the establishment of LSP tunnels. This draft extends 47 RSVP-TE to support path protection [2] in MPLS. Specifically, we 48 provide signaling support for establishing backup LSPs and for 49 propagating fault notification upon LSP failure. 51 Huang, et al [Page 1] IETF Draft Extensions to RSVP-TE for MPLS Path Protection 52 November 2000 54 Table of Contents Page 55 1. Motivation 2 56 2. Purpose of this Document 2 57 3. Background 3 58 4. Terminology 4 59 5. Extensions to Support Protection Domain Configuration 4 60 5.1 EXPLICIT ROUTE PROTECTION sub-object 5 61 5.2 PATH PROTECTION object 6 62 5.2.1 RNT Type 7 63 5.2.2 Hold-off and Wait-to-rstore Timer Options 7 64 5.2.3 Flags 8 65 5.3 Error Codes for ERO 8 66 6. Fault Notification Message 9 67 6.1 Extensions to Support Hop-by-Hop Fault Notification 10 68 6.2 Extensions to Support Notification Via Dedicated LSPs 11 69 7. Open Issues 12 70 8. Security Concerns 13 71 9. Acknowledgements 13 72 10. Authors� Addresses 13 73 11. References 13 75 1. Motivation 77 Recently, there has been considerable standards activity within the 78 IETF towards establishing a recovery framework for MPLS [3], and 79 towards devising recovery mechanisms for MPLS-based networks [2], 80 [4], [5], [7], [8], [9] and, lately, also for intelligent optical 81 networks [6]. A number of these proposals have considered path-based 82 recovery. There is, therefore, a need to appropriately extend 83 existing signaling protocols to facilitate the operation of these 84 path-based recovery mechanisms. 86 Since RSVP-TE has been devised specifically to support the 87 establishment of LSP tunnels and provides some limited support for 88 local repair, a logical choice is to extend it to support path 89 protection as well. 91 2. Purpose of this Document 93 The purpose of this document is to extend RSVP-TE to support path 94 protection in MPLS networks. Although we focus here on the path 95 protection mechanism proposed in [2], several of the extensions that 96 we introduce are general, and are applicable to any path-based 97 recovery scheme; for example, optical lightpath recovery. The major 98 differences between this 01 version and the previous 00 version are: 100 IETF Draft Extensions to RSVP-TE for MPLS Path Protection 101 November 2000 103 -- Bits defined in the ERO subject replaced by a new ERO sub- 104 object 106 -- Define new Protection Object that is embeded in the ERO sub- 107 object 109 -- More encoding details 111 3. Background 113 RSVP-TE [1] extends the RSVP protocol to support the establishment 114 of LSP tunnels. New objects that have been added for this purpose 115 include RECORD-ROUTE, SESSION-ATTRIBUTE, EXPLICIT-ROUTE, LABEL- 116 REQUEST and LABEL. To create an LSP tunnel, the sender node creates 117 an RSVP Path message with a LABEL-REQUEST object. If the sender 118 wishes the Path message to follow a pre-determined route, it uses an 119 EXPLICIT-ROUTE object to identify the route. The destination node of 120 a label-switched path responds to a LABEL-REQUEST by allocating a 121 label and including a LABEL object in the RSVP Resv message that it 122 sends in response to the Path message. The Resv message is sent back 123 upstream by following, in reverse order, the path state that was 124 created by the Path message on its way downstream. 126 Although RSVP-TE offers some support for reliability, such as a 127 Hello message for detecting link failures and an option in the 128 SESSION-ATTRIBUTE object that allows for local repair, it still does 129 not provide adequate support to allow for the operation of a path 130 protection mechanism [2]. In this draft, we introduce extensions to 131 RSVP-TE to enable support of MPLS path protection. Specifically, we 132 propose the following: 134 -- Adding an Explicit Route PROTECTION sub-object to the ERO to 135 allow for the identification of the endpoints (the path switch 136 LSR (PSL) and the path merge LSR (PML)) of a protected path or 137 path segment (protection domain). 139 -- Adding PATH PROTECTION object to the path message to help 140 configure a protection domain. 142 -- Adding Path Protection Error Codes 144 -- Adding a LABEL-REQUEST object in the Resv message and a LABEL 145 object in the Confirmation message to support the establishment 146 of a layer 2 path for propagating fault related 147 notification(s). This is needed because RSVP-TE does not 148 currently provide a mechanism to implement a reverse 149 notification tree (RNT) [2] via the establishment of point-to- 150 multi-point LSPs. As will be seen later, in some circumstances 151 having a RNT implementation based on layer 2 forwarding can 152 substantially speed up notification by eliminating the need to 153 process the notification message at intermediate nodes. 155 IETF Draft Extensions to RSVP-TE for MPLS Path Protection 156 November 2000 158 -- Adding a Notification message to carry the fault information 159 signal (FIS) and the fault recovery signal (FRS). 161 4. Terminology 163 The terminology used in our draft follows that defined in [1], [2] 164 and [3]. We will repeat some of the important terms here for the 165 convenience of the reader. 167 PSL: Path Switch LSR. A PSL is defined as an LSR that originates 168 both the working and the recovery paths of a protected LSP. The PSL 169 is the source of the recovery path. 171 PML: Path Merge LSR. A PML is defined as an LSR that receives both 172 the working and the recovery paths of a protected LSP. The PML is 173 the destination of the recovery path. 175 RNT: Reverse Notification Tree. An RNT is used to notify all 176 upstream neighbors of a node that has detected a fault. 178 Virtually Merged LSPs: A collection of LSPs that belong to the same 179 RSVP session, and all of which terminate at the same destination, 180 and share a common route from some point towards that destination. 182 5. Extensions to Support Protection Domain Configuration 184 One of the first requirements for a path-based protection scheme is 185 the configuration of a protection domain [3], namely the 186 identification and configuration of the set of LSRs (or OXCs in an 187 agile optical network) that are the end-points of the protected LSP 188 or LSP segment (or optical trail). In addition, for a path-based 189 protection mechanism [2] it is also necessary to identify the 190 node(s) that will serve as the root(s) of the reverse notification 191 tree(s) (RNT), and to identify the node(s) (PMLs) that will merge 192 traffic from the working and protection paths [2]. The configuration 193 of the protection domain ideally occurs in conjunction with the 194 establishment of the working path. (Note that in a path-based 195 scheme, the protection path may be pre-configured or may be 196 configured after the fault is detected and a notification 197 communicated to the path switch LSR (PSL), which is responsible for 198 switching traffic from the failed working path to the 199 protection/backup path.) 201 RSVP allows the path to be specified loosely (each node determines 202 it�s next hop) or explicitly (each node has been given it�s next 203 hop). In either case, the ERO object is used. An Explicit Route 204 Protection sub-object is being defined as an extension to the 205 existing RSVP ERO message fields. The origination or PSL node in the 206 MPLS network participates in setting up the working and protection 207 paths. The destination or PML point node in the MPLS network 209 Huang et al. Expires December 2000 [Page 4] IETF Draft Extensions to RSVP-TE for MPLS Path Protection 210 November 2000 212 participates in setting up a recovery path as a merging network 213 switch element. The PSL learns the working and protection paths 214 that are merged to the same outgoing network switch element during 215 signaling or working/protection path configuration process. 217 5.1 EXPLICIT ROUTE PROTECTION sub-object 219 A new sub-object of the ERO is used to identify the PSL and PML. The 220 PATH PROTECTION sub-object has the following format: 222 0 1 2 3 223 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 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 |L| Type | Length |P| Prot. Type | Reserved | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Router ID (32 bits) | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | PATH PROTECTION Object | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 This subobject could be strict or loose (i.e., the L bit could be 0 233 or 1). The Type is 5 (Explicit Route Protection). The Length is 12 235 P 237 Whether this element is the PSL or PML. 0 denotes PSL. 239 Protection Type 241 The protection type this particular working and protection path 242 pair supports. The current values) are (future values are for FFS): 243 0000000 1+1 244 0000001 1:1 246 Router ID 248 The element�s Router ID. The EXPLICIT ROUTE PROTECTION sub-object 249 must follow the appropriate ERO Subobject to identify the 250 PSL/PML[2]. 252 PATH PROTECTION 254 The PSL, after processing the EXPLICIT ROUTE PROTECTION sub-object, 255 will add the PATH PROTECTION Object to the Path Message. The PML, 256 after processing the EXPLICIT ROUTE PROTECTION sub-object, will 257 remove the PATH PROTECTION Object from the Path Message. 259 IETF Draft Extensions to RSVP-TE for MPLS Path Protection 260 November 2000 262 5.2 PATH PROTECTION object 264 A Path message travels from a sender to receiver(s) along the same 265 path(s) used by the data packets. The IP source address of a Path 266 message must be an address of the sender it describes, while the 267 destination address must be the DestAddress for the session. These 268 addresses assure that the message will be correctly routed through a 269 non-RSVP cloud. 271 The nodes that the Path message travels from a sender to receiver(s) 272 may not need path protection for the entire path. The PSL, after 273 processing the EXPLICIT ROUTE PROTECTION sub-object, will insert the 274 PATH PROTECTION object into the Path message. Therefore, only the 275 nodes that are part of the protection domain receive informational 276 elements in regard to protection. The PML, after processing the 277 EXPLICIT ROUTE PROTECTION sub-object, will remove the PATH PROTECTION 278 object from the Path message. 280 The format of an RSVP Path message with the Path Protection Object 281 extension is: 283 ::= [ ] 284 285 [ ] 286 [ ] 287 [ ] 288 289 [ ] 290 [ ... ] 291 293 The presence of this object specifies that protection is supported. 294 The following table illustrates the structure of the Path Protection 295 Object. 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 |RNTT |Holdoff Option | WTR Option |R|Flags | RESVD | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 Where the attibutes are equal to: 305 Length is 8, Class is 0bbbbbbb (TBD), C-type is 1. 307 RNTT 309 Specifies how the notification is implemented . 311 IETF Draft Extensions to RSVP-TE for MPLS Path Protection 312 November 2000 314 Hold-off Timer Option 316 Specifies the hold-off time requirements. 318 Wait-to-Restore Timer Option 320 Specifies the wait-to-restore time requirements. 322 Revertive Option 324 Specifies whether the recovery action is revertive. 326 Flags 328 Specifies whether the Path message is for the working path or 329 protection path. 331 RESVD 333 Reserved for Future Use 335 5.2.1 RNT Type 337 Specifies whether the RNT is implemented as a Hop-by-hop (Layer 3) 338 LSP, as an MPLS (Layer 2) LSP, or over SONET K1/K2 bytes.The default 339 is Hop-by-hop, 000. Other valid values: 341 001 MPLS LSP 342 010 SONET K1/K2 344 5.2.2 Hold-off and Wait-to-restore Timer Options 346 In order to give lower layers (i.e. SONET) time to perform 347 restoration, the timer options specify the hold-off and wait-to- 348 restore time requirements. Since each element along the path must be 349 able to support the timer options when specified, the options must 350 be specified in the PATH message. The defaults (although could be 351 operator defined) for the timer options are: 353 00000000 No timer requirements 354 00000001 50ms timer requirements 355 00000010 100ms timer requirements 356 00001011 1s timer requirements 357 00001100 2s timer requirements 358 00010100 10s timer requirements 359 01000110 1m timer requirements 360 01001111 10m timer requirements 361 11111111 Policy Derived Timer Requirements 363 Huang et al. Expires December 2000 [Page 7] IETF Draft Extensions to RSVP-TE for MPLS Path Protection 364 November 2000 366 5.2.3 Flags 368 The following flags are defined: 370 0x01 Working Path Enabled 372 This flag permits the ingress node or the PSL to identify that 373 the Path Message is for the working path 375 0x02 Protection Path Enabled 377 This flag permits the ingress node or the PSL to identify that 378 the Path Message is for the protection/recovery path. 380 0x04 Extra Traffic 382 This flag permits the protection links to carry extra traffic. 383 This flag is an indication that any resourvces allocated to 384 this protection path are available to be used by other traffic, 385 however it does not necessarly mean that the extra traffic will 386 use the same labels as the protection path. 388 5.3 Error Codes for ERO 389 In the processing described above, certain errors must be reported 390 as a "Routing Problem". The value of the "Routing Problem" error 391 code is 24. 393 The following defines error values for the Routing Problem 394 Error Code: 396 Value Error: 398 11 Bad EXPLICIT_ROUTE Protection sub-object 400 12 Bad PSL node 402 13 Bad PML node 404 14 Protection Mechanism not supported 406 IETF Draft Extensions to RSVP-TE for MPLS Path Protection 407 November 2000 409 6. Fault Notification Message 411 A second requirement for a path protection mechanism is to have an 412 appropriately defined message that is used to convey fault 413 information from the point of failure to the node responsible for 414 initiating recovery action(s). The notification information should 415 enable each intermediate node (lying between the point of failure 416 and the protection switch LSR) to unambiguously identify the LSPs 417 affected by the failure, and enable it to forward this information 418 to the appropriate nodes further upstream. Ideally, MPLS would have 419 some sort of OAM functionality for this purpose. Since MPLS lacks 420 OAM functionality, this section presents a solution. 422 Although the PathErr message could be enhanced to support fault 423 notification, such enhancements may require significant changes to 424 the format and behavior of the PathErr message, as explained below. 425 -- A PathErr message is typically sent in response to a Path 426 message. A notification message, on the other hand, needs to be sent 427 as soon as the fault is detected, and should not need to wait for 428 the arrival of the next Path message. Thus, adapting Path Err for 429 notification would require a change in the way the Path Err message 430 is currently handled. Although it is possible to change the 431 semantics of the PathErr message to be sent as soon as a fault is 432 detected, this unnecessarily overloads the meaning of the PathErr 433 message. 435 -- Furthermore, as per the current RSVP specifications,a Path Err 436 message is forwarded hop-by-hop (with attendant processing). This 437 limits the notification mechanism to the hop-by-hop approach. As we 438 explain in Section 5, for a faster response, it may be advantageous 439 to have the option to set up a point-to-multipoint LSP as a 440 realization of an RNT. 442 -- Yet another observation is that merely extending the Error 443 Value field of the ERROR SPEC object in the Path Err message is not 444 sufficient to convey the required fault notification-related 445 information. Thus, a new object needs to be defined to carry this 446 additional information in any case. Adding this to the Path Err 447 message would require an intermediate node to differentiate between 448 a normal Path Err message and one carrying fault notification 449 information. Thus, it is cleaner to have a separate message for 450 doing so, since it provides a general notification structure that 451 can be used by either hop-by-hop or LSP-based forwarding. 453 Therefore, we define a new notification message as follows: 455 ::= [ ] 456 457 [] 458 [] 459 ::= 461 IETF Draft Extensions to RSVP-TE for MPLS Path Protection 462 November 2000 464 The NOTIFICATION objects are defined as follows: 466 Class =? C-type =1 for IPv4 failure notification 467 C-type =2 for Ipv4 recovery notification 468 +---------+----------+----------+----------+ 469 | Ipv4 Failure Detection Node ID | 470 +------------------------------------------| 471 | MPLS Label of a Working Path | 472 +---------+----------+----------+----------+ 473 | | 474 // Labels of Other Working Paths // 475 | | 476 +---------+----------+----------+----------+ 478 Class =? C-type =3 for Ipv6 failure notification 479 C-type =4 for Ipv6 recovery notification 480 +---------+----------+----------+----------+ 481 | | 482 | Ipv6 Failure Detection Node ID | 483 | | 484 | | 485 +---------+----------+----------+----------+ 486 | MPLS Label of a Working Path | 487 +---------+----------+----------+----------+ 488 | | 489 // Labels of Other Working Paths // 490 | | 491 +---------+----------+----------+----------+ 492 on message may either be conveyed hop-by-hop (involving some amount 493 of processing and modification at each hop) or it may be conveyed by 494 using a layer 2 label switched path, which we call the MPLS LSP 495 approach. 496 Observe that in essence what the notification objects describe, is 497 the content and format of the fault notification information. When 498 using RSVP-TE they are sent as RSVP messages, but when using a 499 different signaling protocol or method, they could as easily be sent 500 by encapsulating them in a format appropriate for the signaling 501 protocol or method (for example, SONET overhead bytes) used. 503 6.1 Extensions to support hop-by-hop fault notification 505 The hop-by-hop approach of transporting a notification message can 506 be supported with minimal changes, and multiple sessions can share 507 the same message on a particular link. In this case, however, 508 notification messages have to be processed at each node and 509 therefore introduce extra delay. Upon the occurrence of a failure 510 the propagation of LSAs may cause unstable states. Observe that a 511 hop-by-hop notification message has to compete with the propagation 512 of routing information, which can potentially result in an 514 IETF Draft Extensions to RSVP-TE for MPLS Path Protection 515 November 2000 517 unpredictable situation (this could be mitigated by delaying the 518 propagation of LSAs via some holdoff mechanism). 520 The easiest way to support hop-by-hop fault notification is to send 521 a Notification message hop-by-hop. A node detecting a fault 522 generates a Notification message. The node must identify all of the 523 working LSPs affected by the fault (which may not be in the same 524 session), insert in the Notification object(s) the labels used by 525 the upstream node(s) to identify these LSPs, and forward the 526 Notification message to the corresponding upstream node(s). Each 527 intermediate node examines the NOTIFICATION object list to learn of 528 all the affected working paths and their corresponding upstream 529 interfaces. Those interfaces will then repack their own Notification 530 messages with the labels used by their upstream neighbors to 531 identify these LSPs, and in turn forward the Notification message to 532 their own upstream neighbors. This process continues at successive 533 nodes, until a PSL is reached. The PSL removes the labels of the 534 working paths that it originates, and itself forwards the message as 535 an intermediate node, until the last NOTIFICATION object has been 536 removed. Notification messages should be encapsulated in a raw IP 537 packet, with their destination address set equal to the RSVP PHOP. 539 6.2 Extensions to Support Notification Via Dedicated LSPs 541 Currently, RSVP-TE supports two styles of reservation, namely FF and 542 SE. While FF can only support point-to-point LSPs (because it 543 creates a distinct reservation for the traffic from each sender that 544 is not shared by other senders), SE can have different options, such 545 as supporting an LSP per sender or a multipoint-to-point (merged) 546 LSP. Although there is a single reservation on a link for all the 547 senders in SE, since each sender is explicitly listed in the RESV 548 message, different labels may be assigned to different senders, 549 thereby creating different LSPs. In the latter case, these different 550 LSPs (which share some links in common) maybe diversely routed at 551 the downstream links. It is, therefore, difficult to share a 552 notification message for different LSPs on a particular link without 553 examining the payload of the notification message at each hop. This 554 is because not all LSPs sharing a link may need to be notified if a 555 failure (which may have occurred upstream of this shared link on a 556 diversely routed segment) does not affect all LSPs. Therefore, the 557 RNT is a general mechanism that can support either a single point- 558 to-point LSP or a merged LSP. In general, therefore, for 559 notification via dedicated LSPs, different working LSPs must use 560 different RNTs. But if LSPs that belong to the same session form a 561 tree structure (without necessarily merging at the point of 562 convergence), they too can share an RNT. We will call such LSPs 563 virtually merged. 565 To setup a dedicated LSP (point-to-point or merged) for suporting a 566 RNT, the root of the RNT should insert LABEL-REQUEST object and 567 RESV-CONFIRM object in the Resv message that it receives from the 568 down stream node before forwarding it to the upstream node. (Recall 570 IETF Draft Extensions to RSVP-TE for MPLS Path Protection 571 November 2000 573 that the root of the RNT need not be the destination of the LSPs, 574 nor need it be a PML.) 576 The PSL receiving this message will allocate a label, generate a 577 Confirmation message, insert a LABEL object in that message and 578 forward it to the downstream node. Each intermediate node will 579 replace the label with a newly allocated label and forward it to the 580 next downstream node. The root of the RNT will terminate the 581 message. 583 Since a multipoint-to-point LSP should share the same RNT, when an 584 intermediate node finds that the labels of the working path are 585 merged on the downstream link, and a label has already been 586 allocated for the protection path on that downstream link (by a 587 Confirmation message from a different source on the multi-point to 588 point LSP that passed through this node earlier), it should 589 terminate the Confirmation message. 591 Virtually merged LSPs should also share the same RNT. When an 592 intermediate node finds that a label for the protection path is 593 already allocated for the same working session (by a Confirmation 594 message from the source of a different virtually merged LSP), it too 595 should terminate the Confirmation message. 597 Each node on the protected path should maintain an inverse cross- 598 connect table [2] The key used to index the inverse-crossconnect 599 table depends on whether the node lies on a single point-to-point or 600 point-to-multipoint working LSP, or on several virtually merged 601 working LSPs. For a single point-to-point LSP or for a point-to- 602 multipoint LSP, the node can use the egress label as an index. 603 Similarly for virtually merged LSPs it can reference the session ID 604 as an index into the inverse crossconnect table. 606 Upon the occurrence of a fault, the node detecting the fault 607 identifies the working paths affected by the fault. It then uses its 608 inverse cross-connect table to identify their corresponding RNTs. 609 The node then generates a Notification message for each RNT and 610 sends it over the LSP dedicated to that RNT. The Notification 611 message should at least carry the Node ID of the node detecting the 612 fault. Intermediate nodes forward the message as normal MPLS 613 packets, using normal label swapping. The PSL that terminates an RNT 614 path also terminates the Notification message and starts protection 615 switching process. The Notification message should be encapsulated 616 by an MPLS layer frame (e.g. the shim header). No extra IP 617 encapsulation is required. 619 7. Open Issues 621 Extensions to support using SONET or WDM layer for notification need 622 further study. 624 Huang et al. Expires December 2000 [Page 12] IETF Draft Extensions to RSVP-TE for MPLS Path Protection 625 November 2000 627 8. Security Concerns 629 This Internet Draft does not introduce additional security concerns 630 to signaling in MPLS networks other than those identified in [1]. 632 9. Acknowledgements 634 We would like to thank Neil Harrison, Dave Allan, and J. Noel 635 Chiappa, and Ben Mack-Crane for useful discussions on MPLS 636 protection, which were helpful in articulating some of the ideas in 637 this draft. 639 10. Authors� Addresses 641 Changcheng Huang Vishal Sharma 642 Department of Systems and Tellabs Research Center 643 Computer Engineering 644 Carleton University One Kendall Square 645 1125 Colonel By Drive Bldg. 100, Ste. 121 646 Ottawa, Ontario K1S 5B6 Cambridge, MA 02139-1562 647 Phone: (613) 520-2600 ext. 2477 Vishal.Sharma@tellabs.com 648 Phone: 617-577-8760 650 Srinivas Makam Ken Owens 651 Tellabs Operations, Inc. Tellabs Operations, Inc. 652 4951 Indiana Avenue 1106 Fourth Street 653 Lisle, IL 60532 St. Louis, MO 63126 654 Srinivas.Makam@tellabs.com Ken.Owens@tellabs.com 655 Ph: 630-512-7217 Phone: 314-918-1579 657 Bora Akyol 658 Pluris, Inc. 659 10455 Bandley Drive 660 Cupertino, CA 95014 661 Akyol@pluris.com 662 Ph: 408-861-3302 664 11. References 666 [1] Awduche, D, et al, "RSVP-TE: Extensions to RSVP for LSP 667 Tunnels", Internet Draft, Work in Progress, draft-ietf-mpls-revp- 668 lsp-tunnel-07.txt, August 2000. 670 [2] Huang, C., Sharma, V., Makam, V., and Owens, K., "A Path 671 Protection Mechanism for MPLS networks", Internet Draft, Work in 672 Progress, draft-chang-mpls-path-protection-02.txt, November 2000. 674 IETF Draft Extensions to RSVP-TE for MPLS Path Protection 675 November 2000 677 [3] Makam, S. et al, "A Framework for MPLS-based Recovery", Work in 678 Progress, Internet Draft, draft-ietf-mpls-recovery-frmwrk-00.txt, 679 September 2000. 681 [4] Shew, S. "Fast Restoration of MPLS Label Switched Paths", Work 682 in Progress, Internet Draft, , 683 October 1999. 685 [5] Goguen, R. and Swallow, G., "RSVP Label Allocation for Backup 686 Tunnels", draft-swallow-rsvp-bypass-label-00.txt, work in 687 progress, October 1999. 689 [6] Luciani, J., et al, "IP over Optical Networks : A Framework," 690 Work in Progress, Internet Draft, draft-many-ip-optical- 691 framework-01.txt, July 2000. 693 [7] Hellstrand, F. and Andersson, L.,"Extensions to CR-LDP and RSVP- 694 TE for setup of pre-established recovery tunnels", Work in 695 Progress, Internet Draft, draft-hellstrand-mpls-recovery-merge- 696 00.txt, July 2000. 698 [8] Kini, S., et al, "Shared backup Label Switched Path 699 restoration", Work in Progress, Internet Draft, draft-kini- 700 restoration-shared-backup-00.txt, November 2000. 702 [9] Kini, S., et al, "ReSerVation Protocol with Traffic Engineering 703 extensions. Extension for Label Switched Path restoration", Work 704 in Progress, Internet Draft, draft-kini-rsvp-lsp-restoration- 705 00.txt, November 2000.