idnits 2.17.1 draft-chen-mpls-p2mp-egress-protection-03.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 (July 11, 2011) is 4673 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 399, but no explicit reference was found in the text == Unused Reference: 'RFC3692' is defined on line 402, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 405, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 409, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 412, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 416, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 420, but no explicit reference was found in the text == Unused Reference: 'RFC4875' is defined on line 424, but no explicit reference was found in the text == Unused Reference: 'RFC4461' is defined on line 431, 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: January 12, 2012 Verizon Inc. 6 July 11, 2011 8 Extensions to RSVP-TE for P2MP LSP Egress Local Protection 9 draft-chen-mpls-p2mp-egress-protection-03.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 January 12, 2012. 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 sub LSP . . . . . . . . . . . . . . . . . 5 59 4.3. Forwarding State for Backup sub LSP(s) . . . . . . . . . . 5 60 4.4. Detection of Egress Node Failure . . . . . . . . . . . . . 5 61 5. Representation of a backup Sub LSP . . . . . . . . . . . . . . 6 62 5.1. EGRESS_BACKUP_SUB_LSP Object . . . . . . . . . . . . . . . 6 63 5.1.1. EGRESS_BACKUP_SUB_LSP IPv4 Object . . . . . . . . . . 6 64 5.1.2. EGRESS_BACKUP_SUB_LSP IPv6 Object . . . . . . . . . . 7 65 5.2. EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE Object . . . . . . 8 66 6. Path Message . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 6.1. Format of Path Message . . . . . . . . . . . . . . . . . . 8 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 LSP. The first method is a one-to-one protection method, where a 83 detour backup P2P LSP for each protected P2P LSP is created at each 84 potential point of local repair. The second method is a facility 85 bypass backup protection method, where a bypass backup P2P LSP tunnel 86 is created using MPLS label stacking to protect a potential failure 87 point for a set of P2P LSP tunnels. The bypass backup tunnel can 88 protect a set of P2P LSPs having similar backup constraints. 90 RFC 4875 "Extensions to RSVP-TE for P2MP TE LSPs" describes how to 91 use the one-to-one protection method and facility bypass backup 92 protection method to protect a link or intermediate node failure on 93 the path of a P2MP LSP. However, there is no mention of locally 94 protecting any egress node failure in a protected P2MP LSP. 96 This document defines extensions to RSVP-TE for locally protecting an 97 egress node of a Traffic Engineered (TE) point-to-multipoint (P2MP) 98 Label Switched Path through using a backup P2MP sub LSP. The same 99 extensions and mechanism can also be used to protect the egress node 100 of a RSVP-TE P2P LSP. 102 2. Terminology 104 This document uses terminologies defined in RFC 2205, RFC 3031, RFC 105 3209, RFC 3473, RFC 4090, RFC 4461, and RFC 4875. 107 3. Conventions Used in This Document 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119. 113 4. Mechanism 115 This section briefly describes a solution that locally protects an 116 egress node of a P2MP LSP through using a backup P2MP sub LSP. We 117 first show an example, and then present different parts of the 118 solution, which includes the creation of the backup sub LSP, the 119 forwarding state for the backup sub LSP, and the detection of a 120 failure in the egress node(s). 122 4.1. An Example of Egress Local Protection 124 Figure 1 below illustrates an example of using backup sub LSPs to 125 locally protect egress nodes of a P2MP LSP. The P2MP LSP to be 126 protected is from ingress node R1 to three egress/leaf nodes: L1, L2 127 and L3. The P2MP LSP is represented by double lines in the figure. 129 La, Lb and Lc are the designated backup egress/leaf nodes for the 130 egress/leaf nodes L1, L2 and L3 of the P2MP LSP respectively. The 131 backup sub LSP used to protect egress node L1 is from its previous 132 hop node R3 to the backup node La. The backup sub LSP used to 133 protect the egress node L2 is from its previous hop node R5 to the 134 backup egress node Lb. The backup sub LSP used to protect the egress 135 node L3 is from its previous hop node R5 to the backup egress node Lc 136 via intermediate node Rc. 138 During normal operation, the traffic transported by the P2MP LSP is 139 forwarded through R3 to L1, then delivered to its destination CE1. 140 When the failure of L1 is detected, R3 forwards the traffic to the 141 backup egress node La, which then delivers the traffic to its 142 destination CE1. L1's failure CAN be detected by a BFD session 143 between L1 and R3. 145 [R2]=====[R3]=====[L1]----[CE1] 146 // \ / 147 // \ / 148 // \___[La]_/ 149 // 150 // 151 // 152 // 153 +---[R1]====[R4]====[R5]=====[L2]----[CE2] 154 | |\\ \ / 155 | | \\ \ / 156 [S]--| | \\ \__[Lb]_/ 157 | | \\ 158 | | \\ 159 | \\ 160 | \\ 161 | \\ 162 | [L3]----[CE3] 163 | / 164 | / 165 [Rc]_______[Lc]_/ 167 Figure 1: P2MP sub LSP for Locally Protecting Egress 169 4.2. Set up of Backup sub LSP 171 A backup egress node is designated for every protected egress node of 172 a LSP. The previous hop node of the protected egress node sets up a 173 backup sub LSP from itself to the backup egress node after receiving 174 the information about the backup egress node. 176 The previous hop node sets up the backup sub LSP, creates and 177 maintains its state in the same way as of setting up a source to leaf 178 (S2L) sub LSP from the signalling's point of view. It constructs and 179 sends a RSVP-TE PATH message along the path for the backup sub LSP, 180 receives and processes a RSVP-TE RESV message that responses to the 181 PATH message. 183 4.3. Forwarding State for Backup sub LSP(s) 185 The forwarding state for the backup sub LSP is different from that 186 for a P2MP S2L sub LSP. After receiving the RSVP-TE RESV message for 187 the backup sub LSP, the previous hop node creates a forwarding entry 188 with an inactive state or flag called inactive forwarding entry. 189 This inactive forwarding entry is not used to forward any data 190 traffic during normal operations. It SHALL only be used after the 191 failure of the protected egress node. 193 Upon detection of the egress node failure, the state or flag of the 194 forwarding entry for the backup sub LSP is set to be active. Thus, 195 the previous hop node of the protected egress node will forward the 196 traffic to the backup egress node through the backup sub LSP, which 197 then send the traffic to its destination. 199 4.4. Detection of Egress Node Failure 201 The previous hop node of the protected egress node SHALL detect four 202 types of failures described below: 204 o The failure of the protected egress node (e.g. L1 in Figure 1) 206 o The failure of the link between the protected egress node and its 207 previous hop node (e.g. the link between R3 and L1 in Figure 1) 209 o The failure of the destination node for the protected egress node 210 (e.g. CE1 in Figure 1) 212 o The failure of the link between the protected egress node and its 213 destination node (e.g. the failure of the link between L1 and CE1 214 in Figure 1). 216 Failure of the protected egress node and the link between itself and 217 its previous hop node CAN be detected through a BFD session between 218 itself and its previous hop node. 220 Failure of the destination node and the link between the protected 221 egress node and the destination node CAN be detected by a BFD session 222 between the previous hop node and the destination node. 224 Upon detecting any above mentioned failures, the previous hop node 225 imports the traffic from the LSP into the backup sub LSP. The 226 traffic is then delivered to its destination through the backup 227 egress node. 229 5. Representation of a backup Sub LSP 231 A backup sub LSP exists within the context of a P2MP LSP in a way 232 similar to a S2L sub LSP. It is identified by the P2MP LSP ID, 233 Tunnel ID, and Extended Tunnel ID in the SESSION object, the tunnel 234 sender address and LSP ID in the SENDER_TEMPLATE object, and the 235 backup sub LSP destination address in the EGRESS_BACKUP_SUB_LSP 236 object. The EGRESS_BACKUP_SUB_LSP object is defined in the section 237 below. 239 An EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE Object (EB-SERO) is used to 240 optionally specify the explicit route of a backup sub LSP that is 241 from a previous hop node to a backup egress node. The EB-SERO is 242 defined in the following section. 244 5.1. EGRESS_BACKUP_SUB_LSP Object 246 An EGRESS_BACKUP_SUB_LSP object identifies a particular backup sub 247 LSP belonging to the LSP. 249 5.1.1. EGRESS_BACKUP_SUB_LSP IPv4 Object 250 EGRESS_BACKUP_SUB_LSP Class = 50, 251 EGRESS_BACKUP_SUB_LSP_IPv4 C-Type = 3 253 0 1 2 3 254 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 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Egress Backup Sub LSP IPv4 destination address | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Egress IPv4 address | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 Egress Backup Sub LSP IPv4 destination address 262 IPv4 address of the backup sub LSP destination is the backup 263 egress node. 264 Egress IPv4 address 265 IPv4 address of the egress node 267 The class of the EGRESS_BACKUP_SUB_LSP IPv4 object is the same as 268 that of the S2L_SUB_LSP IPv4 object defined in RFC 4875. The C-Type 269 of the EGRESS_BACKUP_SUB_LSP IPv4 object is a new number 3, or may be 270 another number assigned by Internet Assigned Numbers Authority 271 (IANA). 273 5.1.2. EGRESS_BACKUP_SUB_LSP IPv6 Object 275 EGRESS_BACKUP_SUB_LSP Class = 50, 276 EGRESS_BACKUP_SUB_LSP_IPv6 C-Type = 4 278 0 1 2 3 279 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 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Egress Backup Sub LSP IPv6 destination address | 282 | (16 bytes) | 283 | .... | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Egress IPv6 address | 286 | (16 bytes) | 287 | .... | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 Egress Backup Sub LSP IPv6 destination address 291 IPv6 address of the backup sub LSP destination is the backup 292 egress node. 293 Egress IPv6 address 294 IPv6 address of the egress node 296 The class of the EGRESS_BACKUP_SUB_LSP IPv6 object is the same as 297 that of the S2L_SUB_LSP IPv6 object defined in RFC 4875. The C-Type 298 of the EGRESS_BACKUP_SUB_LSP IPv6 object is a new number 4, or may be 299 another number assigned by Internet Assigned Numbers Authority 300 (IANA). 302 5.2. EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE Object 304 The format of an EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE (EB-SERO) 305 object is defined as identical to that of the ERO. The class of the 306 EB-SERO is the same as the SERO defined in RFC 4873. The EB-SERO 307 uses a new C-Type = 3, or may use another number assigned by Internet 308 Assigned Numbers Authority (IANA). The formats of sub-objects in an 309 EB-SERO are identical to those of sub-objects in an ERO defined in 310 RFC 3209. 312 6. Path Message 314 This section describes extensions to the Path message defined in RFC 315 4875. The Path message is enhanced to transport the information 316 about a backup egress node to the previous hop node of an egress node 317 of a P2MP LSP through including an egress backup sub LSP descriptor 318 list. 320 6.1. Format of Path Message 322 The format of the enhanced Path message is illustrated below. 324 ::= [ ] 325 [ [ | ] ...] 326 [ ] 327 328 329 [ ] 330 331 [ ] 332 [ ... ] 333 [ ] 334 [ ] 335 [ ] 336 [ ... ] 337 338 [] 339 [] 341 The format of the egress backup sub LSP descriptor list in the 342 enhanced Path message is defined as follows. 344 ::= 345 346 [ ] 348 ::= 349 350 [ ] 352 6.2. Processing of Path Message 354 The ingress node of a LSP initiates a Path message with an egress 355 backup sub LSP descriptor list for protecting egress nodes of the 356 LSP. In order to protect egress node(s) of the LSP, the ingress node 357 MUST add an EGRESS_BACKUP_SUB_LSP object into the Path message. The 358 object contains the information about the backup egress node to be 359 used to protect the failure of the egress node. An 360 EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE object (EB-SERO), which 361 describes an explicit path to the backup egress node, SHALL follow 362 the EGRESS_BACKUP_SUB_LSP. 364 An intermediate node (a transit or branch node) receives the Path 365 message with an egress backup sub LSP descriptor list. Then it MUST 366 put the EGRESS_BACKUP_SUB_LSP (according to EB-SERO if exists) into 367 the Path message. This SHALL be done for each EGRESS_BACKUP_SUB_LSP 368 containing a backup egress node in the list. After that, the message 369 is sent to the previous hop node of the protected egress node. If 370 the intermediate node is the previous hop node of the protected 371 egress node, it generates a new Path message based on the information 372 in the EGRESS_BACKUP_SUB_LSP (and according to EB-SERO if exists) 373 upon receiving the Path message with the EGRESS_BACKUP_SUB_LSP 374 containing the backup egress node. 376 The format of this new Path message is the same as that of the Path 377 message defined in RFC 4875. This new Path message is used to signal 378 the segment of a special S2L sub-LSP from the previous hop node to 379 the backup egress node. The new Path message is sent to the next-hop 380 node along the path for the backup sub LSP. 382 When an egress node of the LSP receives the Path message with an 383 egress backup sub LSP descriptor list, it SHOULD ignore the egress 384 backup sub LSP descriptor list and generate a PathErr message. 386 7. IANA Considerations 388 TBD 390 8. Acknowledgement 392 The author would like to thank Richard Li and Quintin Zhao for their 393 valuable comments on this draft. 395 9. References 397 9.1. Normative References 399 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 400 Requirement Levels", BCP 14, RFC 2119, March 1997. 402 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 403 Considered Useful", BCP 82, RFC 3692, January 2004. 405 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 406 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 407 Functional Specification", RFC 2205, September 1997. 409 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 410 Label Switching Architecture", RFC 3031, January 2001. 412 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 413 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 414 Tunnels", RFC 3209, December 2001. 416 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 417 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 418 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 420 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 421 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 422 May 2005. 424 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 425 "Extensions to Resource Reservation Protocol - Traffic 426 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 427 Switched Paths (LSPs)", RFC 4875, May 2007. 429 9.2. Informative References 431 [RFC4461] Yasukawa, S., "Signaling Requirements for Point-to- 432 Multipoint Traffic-Engineered MPLS Label Switched Paths 433 (LSPs)", RFC 4461, April 2006. 435 Authors' Addresses 437 Huaimo Chen 438 Huawei Technologies 439 Boston, MA 440 USA 442 Email: Huaimochen@huawei.com 444 Ning So 445 Verizon Inc. 446 2400 North Glenville Drive 447 Richardson, TX 75082 448 USA 450 Email: Ning.So@verizonbusiness.com