idnits 2.17.1 draft-chen-mpls-p2mp-egress-protection-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 11, 2011) is 4851 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) == Unused Reference: 'RFC2119' is defined on line 411, but no explicit reference was found in the text == Unused Reference: 'RFC3692' is defined on line 414, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 417, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 421, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 424, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 428, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 432, but no explicit reference was found in the text == Unused Reference: 'RFC4875' is defined on line 436, but no explicit reference was found in the text == Unused Reference: 'RFC4461' is defined on line 443, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Chen 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track N. So 5 Expires: July 15, 2011 Verison Business 6 January 11, 2011 8 Extensions to RSVP-TE for P2MP LSP Egress Local Protection 9 draft-chen-mpls-p2mp-egress-protection-02.txt 11 Abstract 13 This document describes extensions to Resource Reservation Protocol - 14 Traffic Engineering (RSVP-TE) for locally protecting egress nodes of 15 a Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched 16 Path (LSP) in a Multi-Protocol Label Switching (MPLS) and Generalized 17 MPLS (GMPLS) network. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 15, 2011. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Conventions Used in This Document . . . . . . . . . . . . . . 3 56 4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4.1. An Example of Egress Local Protection . . . . . . . . . . 4 58 4.2. Set up of Backup P2MP sub LSP . . . . . . . . . . . . . . 5 59 4.3. Forwarding State for Backup P2MP sub LSP . . . . . . . . . 5 60 4.4. Detection of Failure in Egress . . . . . . . . . . . . . . 6 61 5. Representation of a backup P2MP Sub LSP . . . . . . . . . . . 6 62 5.1. EGRESS_BACKUP_P2MP_SUB_LSP Object . . . . . . . . . . . . 7 63 5.1.1. EGRESS_BACKUP_P2MP_SUB_LSP IPv4 Object . . . . . . . . 7 64 5.1.2. EGRESS_BACKUP_P2MP_SUB_LSP IPv6 Object . . . . . . . . 8 65 5.2. EGRESS_BACKUP_P2MP_SECONDARY_EXPLICIT_ROUTE Object . . . . 8 66 6. Path Message . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 6.1. Format of Path Message . . . . . . . . . . . . . . . . . . 9 68 6.2. Processing of Path Message . . . . . . . . . . . . . . . . 9 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 73 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 76 1. Introduction 78 RFC 4090 "Fast Reroute Extensions to RSVP-TE for LSP Tunnels" 79 describes two methods for protecting P2P LSP tunnels or paths at 80 local repair points. For a P2P LSP, the local repair points are the 81 intermediate nodes between the ingress node and the egress node of 82 the P2P LSP. The first method is a one-to-one protection method, 83 where a detour backup P2P LSP for each protected P2P LSP is created 84 at each potential point of local repair. The second method is a 85 facility bypass backup protection method, where a bypass backup P2P 86 LSP tunnel is created using MPLS label stacking to protect a 87 potential failure point for a set of P2P LSP tunnels. The bypass 88 backup tunnel can protect a set of P2P LSPs that have similar backup 89 constraints. 91 RFC 4875 "Extensions to RSVP-TE for P2MP TE LSPs" describes how to 92 use the one-to-one protection method and facility bypass backup 93 protection method to protect a link or intermediate node failure on 94 the path of a P2MP LSP. However, there is no mention of locally 95 protecting any egress node failure in a protected P2MP LSP. 97 This document defines extensions to RSVP-TE for locally protecting an 98 egress node of a Traffic Engineered (TE) point-to-multipoint (P2MP) 99 Label Switched Path through using a backup P2MP sub LSP. 101 2. Terminology 103 This document uses terminologies defined in RFC 2205, RFC 3031, RFC 104 3209, RFC 3473, RFC 4090, RFC 4461, and RFC 4875. 106 3. Conventions Used in This Document 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119. 112 4. Mechanism 114 This section briefly describes a solution that locally protects an 115 egress node of a P2MP LSP through using a backup P2MP sub LSP. We 116 first show an example, and then present different parts of the 117 solution, which includes the creation of the backup P2MP sub LSP, the 118 forwarding state for the backup P2MP sub LSP, and the detection of a 119 failure in the egress node. 121 4.1. An Example of Egress Local Protection 123 The figure 1 illustrates an example of using a backup P2MP sub LSP to 124 locally protect an egress of a P2MP LSP. The P2MP LSP to be 125 protected is from ingress node R1 to three egress/leaf nodes: L1, L2 126 and L3. The P2MP LSP is represented by double lines in the figure. 128 La, Lb and Lc are the designated backup egress/leaf nodes for the 129 egress/leaf nodes L1, L2 and L3 of the P2MP LSP respectively. The 130 backup P2MP sub LSP used to protect the egress node L1 is from the 131 previous hop node R3 of L1 to the backup egress node La. The backup 132 P2MP sub LSP used to protect the egress node L2 is from the previous 133 hop node R5 of L2 to the backup egress node Lb. The backup P2MP sub 134 LSP used to protect the egress node L3 is from the previous hop node 135 R5 of L3 to the backup egress node Lc via intermediate node Rc. 137 At a previous hop node such as R3 of an egress node such as L1 of the 138 P2MP LSP, the traffic transported by the P2MP LSP is forwarded to the 139 egress node such as L1 in a normal operation, which delivers the 140 traffic towards its destination such as CE1. When the failure in an 141 egress node such as L1 is detected, the previous hop node such as R3 142 of the egress node such as L1 forwards the traffic toward the 143 corresponding backup egress node such as La, which delivers the 144 traffic towards its destination such as CE1. 146 There may be a BFD session between an egress node such as L1 and the 147 previous hop node such as R3 of the egress node such as L1. The 148 previous hop node uses this BFD session to detect the failure of the 149 egress node. When it detects the failure of the egress node, it 150 forwards the traffic carried by the P2MP LSP into the backup P2MP sub 151 LSP to the corresponding backup egress node. The traffic from the 152 sub LSP is delivered from the backup egress node towards its 153 destination. 155 [R2]=====[R3]=====[L1]----[CE1] 156 // \ / 157 // \ / 158 // \___[La]_/ 159 // 160 // 161 // 162 // 163 +---[R1]====[R4]====[R5]=====[L2]----[CE2] 164 | |\\ \ / 165 | | \\ \ / 166 [S]--| | \\ \__[Lb]_/ 167 | | \\ 168 | | \\ 169 | \\ 170 | \\ 171 | \\ 172 | [L3]----[CE3] 173 | / 174 | / 175 [Rc]_______[Lc]_/ 177 Figure 1: P2MP sub LSP for Locally Protecting Egress 179 4.2. Set up of Backup P2MP sub LSP 181 For an egress node of a P2MP LSP, a backup egress node is designated 182 to protect the egress node. The previous-hop node of the egress node 183 of the P2MP LSP sets up a backup P2MP sub LSP from itself to the 184 backup egress node after receiving the information about the backup 185 egress node. 187 The previous-hop node sets up the backup P2MP sub LSP, creates and 188 maintains its state in the same way as setting up a P2MP S2L sub LSP 189 from the signalling's point of view. It constructs and sends a 190 RSVP-TE PATH message along the path for the backup P2MP sub LSP, 191 receives and processes a RSVP-TE RESV message that responses to the 192 PATH message. 194 4.3. Forwarding State for Backup P2MP sub LSP 196 The forwarding state for the backup P2MP sub LSP is different from 197 that for a P2MP S2L sub LSP. After receiving the RSVP-TE RESV 198 message for the backup P2MP sub LSP, the previous-hop node creates a 199 forwarding entry with an inactive state or flag. This forwarding 200 entry with an inactive state or flag is called an inactive forwarding 201 entry. In a normal operation, this inactive forwarding entry is not 202 used to forward any data traffic. However, the forwarding entry for 203 a P2MP S2L sub LSP is with an active state or flag, and used to 204 forward the data traffic if the failure of the egress is detected. 206 When a failure of the egress node happens, the state or flag of the 207 forwarding entry for the backup P2MP sub LSP is set to be active. 208 Thus, on the previous-hop node of the egress node, the data traffic 209 will be forwarded to the backup egress node instead of to the egress 210 node through the backup P2MP sub LSP from the P2MP LSP. From the 211 backup egress node, the data traffic is sent towards its destination. 213 4.4. Detection of Failure in Egress 215 There are a number of failures in an egress node of a P2MP LSP. The 216 failures in the egress that the previous hop node of the egress node 217 should detect include two classes of failures. One class of failures 218 is such a failure that the traffic can not be delivered to the egress 219 node of the P2MP LSP. The death of the egress node and the failure 220 of the link between the egress node and the previous hop node belong 221 to this class of failures. 223 Another class of failures are such failures that the egress node can 224 not deliver the traffic from the P2MP LSP towards its destination. 225 The failure of the link over which the traffic is delivered towards 226 its destination such as CE1 is such a failure. 228 After a previous hop node detects any above failure in the egress 229 node, it imports the traffic from the P2MP LSP into the backup P2MP 230 sub LSP. The traffic from the backup P2MP sub LSP is delivered 231 towards its destination at the backup egress node. 233 5. Representation of a backup P2MP Sub LSP 235 A backup P2MP sub LSP exists within the context of a P2MP LSP in a 236 way similar to a P2MP S2L sub LSP. It is identified by the P2MP ID, 237 Tunnel ID, and Extended Tunnel ID in the P2MP SESSION object, the 238 tunnel sender address and LSP ID in the P2MP SENDER_TEMPLATE object, 239 and the backup P2MP sub LSP destination address in the 240 EGRESS_BACKUP_P2MP_SUB_LSP object. The EGRESS_BACKUP_P2MP_SUB_LSP 241 object is defined in the section below. 243 An EGRESS_BACKUP_P2MP_SECONDARY_EXPLICIT_ROUTE Object (EB-SERO) is 244 used to optionally specify the explicit route of a backup P2MP sub 245 LSP that is from a previous-hop node to a backup egress node. The 246 EGRESS_BACKUP_P2MP_SECONDARY_EXPLICIT_ROUTE object is defined in the 247 following section. 249 5.1. EGRESS_BACKUP_P2MP_SUB_LSP Object 251 An EGRESS_BACKUP_P2MP_SUB_LSP object identifies a particular backup 252 P2MP sub LSP belonging to the P2MP LSP. 254 5.1.1. EGRESS_BACKUP_P2MP_SUB_LSP IPv4 Object 256 EGRESS_BACKUP_P2MP_SUB_LSP Class = 50, 257 EGRESS_BACKUP_P2MP_SUB_LSP_IPv4 C-Type = 3 259 0 1 2 3 260 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 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Egress Backup P2MP Sub LSP IPv4 destination address | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Egress IPv4 address | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 Egress Backup P2MP Sub LSP IPv4 destination address 268 IPv4 address of the backup P2MP sub LSP destination, which is the 269 backup egress node. 270 Egress IPv4 address 271 IPv4 address of the egress node 273 The class of the EGRESS_BACKUP_P2MP_SUB_LSP IPv4 object is the same 274 as that of the S2L_SUB_LSP IPv4 object defined in RFC 4875. The 275 C-Type of the EGRESS_BACKUP_P2MP_SUB_LSP IPv4 object is a new number 276 3, or may be another number assigned by Internet Assigned Numbers 277 Authority (IANA). 279 5.1.2. EGRESS_BACKUP_P2MP_SUB_LSP IPv6 Object 281 EGRESS_BACKUP_P2MP_SUB_LSP Class = 50, 282 EGRESS_BACKUP_P2MP_SUB_LSP_IPv6 C-Type = 4 284 0 1 2 3 285 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 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Egress Backup P2MP Sub LSP IPv6 destination address | 288 | (16 bytes) | 289 | .... | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Egress IPv6 address | 292 | (16 bytes) | 293 | .... | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 Egress Backup P2MP Sub LSP IPv6 destination address 297 IPv6 address of the backup P2MP sub LSP destination, which is the 298 backup egress node. 299 Egress IPv6 address 300 IPv6 address of the egress node 302 The class of the EGRESS_BACKUP_P2MP_SUB_LSP IPv6 object is the same 303 as that of the S2L_SUB_LSP IPv6 object defined in RFC 4875. The 304 C-Type of the EGRESS_BACKUP_P2MP_SUB_LSP IPv6 object is a new number 305 4, or may be another number assigned by Internet Assigned Numbers 306 Authority (IANA). 308 5.2. EGRESS_BACKUP_P2MP_SECONDARY_EXPLICIT_ROUTE Object 310 The format of an EGRESS_BACKUP_P2MP_SECONDARY_EXPLICIT_ROUTE (EB- 311 SERO) object is defined as identical to that of the ERO. The class 312 of the EB-SERO is the same as the SERO defined in RFC 4873. The EB- 313 SERO uses a new C-Type = 3, or may use another number assigned by 314 Internet Assigned Numbers Authority (IANA). The formats of sub- 315 objects in an EB-SERO are identical to those of sub-objects in an ERO 316 defined in RFC 3209. 318 6. Path Message 320 This section describes extensions to the Path message defined in RFC 321 4875. The Path message is enhanced to transport the information 322 about a backup egress node to the previous-hop node of an egress node 323 of a P2MP LSP through including an egress backup P2MP sub LSP 324 descriptor list. 326 6.1. Format of Path Message 328 The format of the enhanced Path message is illustrated below. 330 ::= [ ] 331 [ [ | ] ...] 332 [ ] 333 334 335 [ ] 336 337 [ ] 338 [ ... ] 339 [ ] 340 [ ] 341 [ ] 342 [ ... ] 343 344 [] 345 [] 347 The format of the egress backup P2MP sub LSP descriptor list in the 348 enhanced Path message is defined as follows. 350 ::= 351 352 [ ] 354 ::= 355 356 [ ] 358 6.2. Processing of Path Message 360 The ingress node of a P2MP LSP initiates a Path message with an 361 egress backup P2MP sub LSP descriptor list for protecting egress 362 nodes of the P2MP LSP. In order to protect an egress node of the 363 P2MP LSP, the ingress node MUST add an EGRESS_BACKUP_P2MP_SUB_LSP 364 object into the Path message. The object contains the information 365 about the backup egress node to be used to protect the failure of the 366 egress node. An EGRESS_BACKUP_P2MP_SECONDARY_EXPLICIT_ROUTE object, 367 which describes an explicit path to the backup egress node, SHOULD 368 follow the EGRESS_BACKUP_P2MP_SUB_LSP. 370 After an intermediate node (a transit or branch node) receives the 371 Path message with an egress backup P2MP sub LSP descriptor list, for 372 each EGRESS_BACKUP_P2MP_SUB_LSP containing a backup egress node in 373 the list, the intermediate node of the P2MP LSP MUST put the 374 EGRESS_BACKUP_P2MP_SUB_LSP with the directly following 375 EGRESS_BACKUP_P2MP_SECONDARY_EXPLICIT_ROUTE into the Path message 376 that is to be sent toward the direction to the previous-hop node of 377 the egress node that is to be protected by the backup egress node if 378 the intermediate node is not the previous-hop node of the egress 379 node. 381 If the intermediate node is the previous-hop node of an egress node, 382 when it receives the Path message with the EGRESS_BACKUP_P2MP_SUB_LSP 383 containing the backup egress node to be assigned for protecting the 384 egress node, the intermediate node generates a new Path message based 385 on the information in the EGRESS_BACKUP_P2MP_SUB_LSP and the possible 386 directly following EGRESS_BACKUP_P2MP_SECONDARY_EXPLICIT_ROUTE. The 387 format of this new Path message is the same as that of the Path 388 message defined in RFC 4875. This new Path message is used to signal 389 the segment of a special S2L sub-LSP of the P2MP LSP from the 390 previous-hop node to the backup egress node. The new Path message is 391 sent to the next-hop node along the path for the backup P2MP sub LSP. 393 When an egress node of the P2MP LSP receives the Path message with an 394 egress backup P2MP sub LSP descriptor list, it SHOULD ignore the 395 egress backup P2MP sub LSP descriptor list and generate a PathErr 396 message. 398 7. IANA Considerations 400 TBD 402 8. Acknowledgement 404 The author would like to thank Richard Li and Quintin Zhao for their 405 valuable comments on this draft. 407 9. References 409 9.1. Normative References 411 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 412 Requirement Levels", BCP 14, RFC 2119, March 1997. 414 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 415 Considered Useful", BCP 82, RFC 3692, January 2004. 417 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 418 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 419 Functional Specification", RFC 2205, September 1997. 421 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 422 Label Switching Architecture", RFC 3031, January 2001. 424 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 425 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 426 Tunnels", RFC 3209, December 2001. 428 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 429 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 430 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 432 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 433 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 434 May 2005. 436 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 437 "Extensions to Resource Reservation Protocol - Traffic 438 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 439 Switched Paths (LSPs)", RFC 4875, May 2007. 441 9.2. Informative References 443 [RFC4461] Yasukawa, S., "Signaling Requirements for Point-to- 444 Multipoint Traffic-Engineered MPLS Label Switched Paths 445 (LSPs)", RFC 4461, April 2006. 447 Authors' Addresses 449 Huaimo Chen 450 Huawei Technologies 451 Boston, MA 452 USA 454 Email: Huaimochen@huawei.com 455 Ning So 456 Verison Business 457 2400 North Glenville Drive 458 Richardson, TX 75082 459 USA 461 Email: Ning.So@verizonbusiness.com