idnits 2.17.1 draft-chen-mpls-p2mp-egress-protection-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 (March 1, 2010) is 5169 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 322, but no explicit reference was found in the text == Unused Reference: 'RFC3692' is defined on line 325, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 328, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 332, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 335, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 339, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 343, but no explicit reference was found in the text == Unused Reference: 'RFC4875' is defined on line 347, but no explicit reference was found in the text == Unused Reference: 'RFC4461' is defined on line 354, but no explicit reference was found in the text Summary: 2 errors (**), 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 Technology, Inc. 4 Intended status: Standards Track March 1, 2010 5 Expires: September 2, 2010 7 Extensions to RSVP-TE for P2MP LSP Egress Local Protection 8 draft-chen-mpls-p2mp-egress-protection-00.txt 10 Abstract 12 This document describes extensions to Resource Reservation Protocol - 13 Traffic Engineering (RSVP-TE) for locally protecting egress nodes of 14 Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched 15 Paths (LSPs) in Multi-Protocol Label Switching (MPLS) and Generalized 16 MPLS (GMPLS) networks. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 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 months 29 and may be updated, replaced, or obsoleted by other documents at any 30 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 This Internet-Draft will expire on September 2, 2010. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Conventions Used in This Document . . . . . . . . . . . . . . . 3 61 4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 5. Representation of a backup P2MP Sub LSP . . . . . . . . . . . . 4 63 5.1. EGRESS_BACKUP_P2MP_SUB_LSP Object . . . . . . . . . . . . . 4 64 5.1.1. EGRESS_BACKUP_P2MP_SUB_LSP IPv4 Object . . . . . . . . 5 65 5.1.2. EGRESS_BACKUP_P2MP_SUB_LSP IPv6 Object . . . . . . . . 6 66 5.2. EGRESS_BACKUP_P2MP_SECONDARY_EXPLICIT_ROUTE Object . . . . 6 67 6. Path Message . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 6.1. Format of Path Message . . . . . . . . . . . . . . . . . . 7 69 6.2. Processing of Path Message . . . . . . . . . . . . . . . . 7 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 71 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 8 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 74 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 1. Introduction 79 "Fast Reroute Extensions to RSVP-TE for LSP Tunnels" RFC 4090 80 describes two methods for protecting P2P LSP tunnels or paths at 81 local repair points. For a P2P LSP, the local repair points are the 82 intermediate nodes between the ingress node and the egress node of 83 the P2P LSP. The first method is a one-to-one protection method, 84 where a detour backup P2P LSP for each protected P2P LSP is created 85 at each potential point of local repair. The second method is a 86 facility bypass backup protection method, where a bypass backup P2P 87 LSP tunnel is created using MPLS label stacking to protect a 88 potential failure point for a set of P2P LSP tunnels. The bypass 89 backup tunnel can protect a set of P2P LSPs that have similar backup 90 constraints. 92 "Extensions to RSVP-TE for P2MP TE LSPs" RFC 4875 describes how to 93 use the one-to-one protection method and facility bypass backup 94 protection method to protect a link or intermediate node failure on 95 the path of a P2MP LSP. However, there is no mention of locally 96 protecting an egress node failure in a protected P2MP LSP. 98 This document defines extensions to RSVP-TE for locally protecting an 99 egress node of a Traffic Engineered (TE) point-to-multipoint (P2MP) 100 Label Switched Path through using a backup P2MP sub 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. For 117 an egress node of a P2MP LSP, a backup egress node is designated to 118 protect the egress node. The previous-hop node of the egress node of 119 the P2MP LSP sets up a backup P2MP sub LSP from itself to the backup 120 egress node after receiving the information about the backup egress 121 node. 123 The previous-hop node sets up the backup P2MP sub LSP, creates and 124 maintains its state in the same way as setting up a P2MP S2L sub LSP 125 from the signalling's point of view. It constructs and sends a 126 RSVP-TE PATH message along the path for the backup P2MP sub LSP, and 127 receives and processes a RSVP-TE RESV message that responses to the 128 PATH message. 130 The forwarding state for the backup P2MP sub LSP is different from 131 that for a P2MP S2L sub LSP. After receiving the RSVP-TE RESV 132 message for the backup P2MP sub LSP, the previous-hop node creates a 133 forwarding entry with an inactive state or flag. This forwarding 134 entry with an inactive state or flag is called an inactive forwarding 135 entry. In a normal operation, this inactive forwarding entry is not 136 used to forward any data traffic. However, the forwarding entry for 137 a P2MP S2L sub LSP is with an active state or flag. 139 When a failure of the egress node happens, the state or flag of the 140 forwarding entry for the backup P2MP sub LSP is set to be active. 141 Thus, on the previous-hop node of the egress node, the data traffic 142 will be forwarded to the backup egress node instead of to the egress 143 node through the backup P2MP sub LSP from the P2MP LSP. From the 144 backup egress node, the data traffic is sent to its destination. 146 5. Representation of a backup P2MP Sub LSP 148 A backup P2MP sub LSP exists within the context of a P2MP LSP in a 149 way similar to a P2MP S2L sub LSP. It is identified by the P2MP ID, 150 Tunnel ID, and Extended Tunnel ID in the P2MP SESSION object, the 151 tunnel sender address and LSP ID in the P2MP SENDER_TEMPLATE object, 152 and the backup P2MP sub LSP destination address in the 153 EGRESS_BACKUP_P2MP_SUB_LSP object. The EGRESS_BACKUP_P2MP_SUB_LSP 154 object is defined in the section below. 156 An EGRESS_BACKUP_P2MP_SECONDARY_EXPLICIT_ROUTE Object (EB-SERO) is 157 used to optionally specify the explicit route of a backup P2MP sub 158 LSP that is from a previous-hop node to a backup egress node. The 159 EGRESS_BACKUP_P2MP_SECONDARY_EXPLICIT_ROUTE object is defined in the 160 following section. 162 5.1. EGRESS_BACKUP_P2MP_SUB_LSP Object 164 An EGRESS_BACKUP_P2MP_SUB_LSP object identifies a particular backup 165 P2MP sub LSP belonging to the P2MP LSP. 167 5.1.1. EGRESS_BACKUP_P2MP_SUB_LSP IPv4 Object 169 EGRESS_BACKUP_P2MP_SUB_LSP Class = 50, 170 EGRESS_BACKUP_P2MP_SUB_LSP_IPv4 C-Type = 3 172 0 1 2 3 173 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 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Egress Backup P2MP Sub LSP IPv4 destination address | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Egress IPv4 address | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 Egress Backup P2MP Sub LSP IPv4 destination address 181 IPv4 address of the backup P2MP sub LSP destination. 182 Egress IPv4 address 183 IPv4 address of the egress node 185 The class of the EGRESS_BACKUP_P2MP_SUB_LSP IPv4 object is the same 186 as that of the S2L_SUB_LSP IPv4 object defined in RFC 4875. The 187 C-Type of the EGRESS_BACKUP_P2MP_SUB_LSP IPv4 object is a new number 188 3, or may be another number assigned by Internet Assigned Numbers 189 Authority (IANA). 191 5.1.2. EGRESS_BACKUP_P2MP_SUB_LSP IPv6 Object 193 EGRESS_BACKUP_P2MP_SUB_LSP Class = 50, 194 EGRESS_BACKUP_P2MP_SUB_LSP_IPv6 C-Type = 4 196 0 1 2 3 197 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 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Egress Backup P2MP Sub LSP IPv6 destination address | 200 | (16 bytes) | 201 | .... | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Egress IPv6 address | 204 | (16 bytes) | 205 | .... | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 Egress Backup P2MP Sub LSP IPv6 destination address 209 IPv6 address of the backup P2MP sub LSP destination. 210 Egress IPv6 address 211 IPv6 address of the egress node 213 The class of the EGRESS_BACKUP_P2MP_SUB_LSP IPv6 object is the same 214 as that of the S2L_SUB_LSP IPv6 object defined in RFC 4875. The 215 C-Type of the EGRESS_BACKUP_P2MP_SUB_LSP IPv6 object is a new number 216 4, or may be another number assigned by Internet Assigned Numbers 217 Authority (IANA). 219 5.2. EGRESS_BACKUP_P2MP_SECONDARY_EXPLICIT_ROUTE Object 221 The format of an EGRESS_BACKUP_P2MP_SECONDARY_EXPLICIT_ROUTE (EB- 222 SERO) object is defined as identical to that of the ERO. The class 223 of the EB-SERO is the same as the SERO defined in RFC 4873. The EB- 224 SERO uses a new C-Type = 3, or may use another number assigned by 225 Internet Assigned Numbers Authority (IANA). The formats of sub- 226 objects in an EB-SERO are identical to those of sub-objects in an ERO 227 defined in RFC 3209. 229 6. Path Message 231 This section describes extensions to the Path message defined in RFC 232 4875. The Path message is enhanced to transport the information 233 about a backup egress node to the previous-hop node of an egress node 234 of a P2MP LSP through including an egress backup P2MP sub LSP 235 descriptor list. 237 6.1. Format of Path Message 239 The format of the enhanced Path message is illustrated below. 241 ::= [ ] 242 [ [ | ] ...] 243 [ ] 244 245 246 [ ] 247 248 [ ] 249 [ ... ] 250 [ ] 251 [ ] 252 [ ] 253 [ ... ] 254 255 [] 256 [] 258 The format of the egress backup P2MP sub LSP descriptor list in the 259 enhanced Path message is defined as follows. 261 ::= 262 263 [ ] 265 ::= 266 267 [ ] 269 6.2. Processing of Path Message 271 The ingress node of a P2MP LSP initiates a Path message with an 272 egress backup P2MP sub LSP descriptor list for protecting egress 273 nodes of the P2MP LSP. In order to protect an egress node of the 274 P2MP LSP, the ingress node MUST add an EGRESS_BACKUP_P2MP_SUB_LSP 275 object into the Path message. The object contains the information 276 about the backup egress node to be used to protect the failure of the 277 egress node. An EGRESS_BACKUP_P2MP_SECONDARY_EXPLICIT_ROUTE object, 278 which describes an explicit path to the backup egress node, SHOULD 279 follow the EGRESS_BACKUP_P2MP_SUB_LSP. 281 After an intermediate node (a transit or branch node) receives the 282 Path message with an egress backup P2MP sub LSP descriptor list, for 283 each EGRESS_BACKUP_P2MP_SUB_LSP containing a backup egress node in 284 the list, the intermediate node of the P2MP LSP MUST put the 285 EGRESS_BACKUP_P2MP_SUB_LSP with the directly following 286 EGRESS_BACKUP_P2MP_SECONDARY_EXPLICIT_ROUTE into the Path message 287 that is to be sent toward the direction to the previous-hop node of 288 the egress node that is to be protected by the backup egress node if 289 the intermediate node is not the previous-hop node of the egress 290 node. 292 If the intermediate node is the previous-hop node of an egress node, 293 when it receives the Path message with the EGRESS_BACKUP_P2MP_SUB_LSP 294 containing the backup egress node to be assigned for protecting the 295 egress node, the intermediate node generates a new Path message based 296 on the information in the EGRESS_BACKUP_P2MP_SUB_LSP and the possible 297 directly following EGRESS_BACKUP_P2MP_SECONDARY_EXPLICIT_ROUTE. The 298 format of this new Path message is the same as that of the Path 299 message defined in RFC 4875. This new Path message is used to signal 300 the segment of a special S2L sub-LSP of the P2MP LSP from the 301 previous-hop node to the backup egress node. The new Path message is 302 sent to the next-hop node along the path for the backup P2MP sub LSP. 304 When an egress node of the P2MP LSP receives the Path message with an 305 egress backup P2MP sub LSP descriptor list, it SHOULD ignore the 306 egress backup P2MP sub LSP descriptor list and generate a PathErr 307 message. 309 7. IANA Considerations 311 TBD 313 8. Acknowledgement 315 The author would like to thank Quintin Zhao for his valuable comments 316 on this draft. 318 9. References 320 9.1. Normative References 322 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 323 Requirement Levels", BCP 14, RFC 2119, March 1997. 325 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 326 Considered Useful", BCP 82, RFC 3692, January 2004. 328 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 329 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 330 Functional Specification", RFC 2205, September 1997. 332 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 333 Label Switching Architecture", RFC 3031, January 2001. 335 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 336 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 337 Tunnels", RFC 3209, December 2001. 339 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 340 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 341 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 343 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 344 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 345 May 2005. 347 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 348 "Extensions to Resource Reservation Protocol - Traffic 349 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 350 Switched Paths (LSPs)", RFC 4875, May 2007. 352 9.2. Informative References 354 [RFC4461] Yasukawa, S., "Signaling Requirements for Point-to- 355 Multipoint Traffic-Engineered MPLS Label Switched Paths 356 (LSPs)", RFC 4461, April 2006. 358 Author's Address 360 Huaimo Chen 361 Huawei Technology, Inc. 362 125 Nagog Technology Park 363 Acton, MA 01719 364 US 366 Email: Huaimochen@huawei.com