idnits 2.17.1 draft-dong-ccamp-rsvp-te-plr-designation-00.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 : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 1 character in excess of 72. 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 5167 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: 'RFC2205' is defined on line 246, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 250, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 254, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network working group J. Dong 2 Internet Draft M. Chen 3 Intended status: Standards Track C. Liu 4 Expires: September 1, 2010 Huawei Technologies 6 March 1, 2010 8 Designation of PLRs in RSVP-TE Fast Reroute 9 draft-dong-ccamp-rsvp-te-plr-designation-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on September 1, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents carefully, 42 as they describe your rights and restrictions with respect to this 43 document. 45 Abstract 46 This document defines RSVP-TE extensions which enable the ingress 47 node to designate particular LSRs along the path as Points of Local 48 Repair (PLRs) of the protected LSP, and further indicate the 49 protection type of each PLR. These mechanisms could enhance the 50 control over the establishment of backup LSPs, and also could save 51 the resources needed for establishing and maintaining unnecessary 52 backup LSPs. 54 Table of Contents 56 1. Introduction.................................................2 57 2. Conventions used in this document............................3 58 3. Problem Statement............................................3 59 4. RSVP-TE Extensions...........................................3 60 4.1. Extensions to IPv4 Prefix Subobject.....................3 61 4.2. Extensions to IPv6 Prefix Subobject.....................4 62 4.3. Backward Compatibility..................................5 63 5. Selection of PLRs............................................5 64 6. Operations...................................................5 65 6.1. Operation of Head End...................................5 66 6.2. Operation of Other LSRs.................................5 67 7. Security Considerations......................................6 68 8. IANA Considerations..........................................6 69 9. References...................................................6 70 9.1. Normative References....................................6 71 9.2. Informative References..................................6 72 Authors' Addresses..............................................7 74 1. Introduction 76 Currently the fast reroute mechanisms of RSVP-TE enable the ingress 77 node of protected LSP to indicate whether local protection is desired 78 and whether node protection is desired for this LSP. However, such 79 indication is relevant to the whole LSP, the ingress node cannot 80 indicate which LSRs on the path are desired to be PLRs, and the 81 protection type of each PLR. 83 This document defines RSVP-TE extensions to enable an ingress node to 84 designate particular nodes along the path as Points of Local Repair 85 (PLRs) of the protected LSP, and further indicate the protection type 86 of the PLRs. 88 These mechanisms could enhance the control of the ingress node of the 89 protected LSP on the establishment of backup LSPs. It is useful when 90 only a subset of the LSRs on the path are required to operate as PLRs, 91 and only some of them are required to provide node protection. Since 92 in such cases not all of the LSRs need to perform as PLRs, these 93 mechanisms could save the resources of establishing and maintaining 94 unnecessary backup LSPs. 96 2. Conventions used in this document 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 3. Problem Statement 104 RFC 4090 has defined mechanisms to establish local protection for a 105 particular LSP. The fast reroute mechanisms of RFC 4090 enable the 106 ingress node of the protected LSP to indicate whether local 107 protection is desired and what protection type is needed for this LSP. 108 However, such indication is at the granularity of LSP level, the 109 ingress node cannot explicitly indicate which subset of LSRs along 110 the path are desired to be PLRs, and the protection type of each PLR. 112 In some scenarios the ingress node may need to specify particular 113 LSRs as PLRs, and the protection type of each particular PLR. This 114 can be helpful in many aspects. Firstly, this enables the ingress 115 node to setup the backup LSPs in a more controllable way. Secondly, 116 this could avoid making LSRs which do not have enough resources to 117 provide local protections work as PLRs. Thirdly, this could save 118 bandwidth reserved for unnecessary backup LSPs. 120 The subsequent sections define extensions to RSVP-TE to meet the 121 requirements in such scenarios, and describe operations needed for 122 these extensions. 124 4. RSVP-TE Extensions 126 The Explicit Route Object (ERO) is extended to carry information of 127 PLR designation and type of local protection. The low order bits of 128 the Reserved field in IPv4 prefix and IPv6 prefix subobjects are used 129 as flags to indicate whether the LSR represented by the subobject 130 should operate as a PLR and the desired type of local protection. 132 4.1. Extensions to IPv4 Prefix Subobject 134 Two new flags are defined in this subobject. The structure of 135 extended IPv4 prefix subobject is as below: 137 0 1 2 3 138 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 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 |L| Type | Length | IPv4 address (4 bytes) | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | IPv4 address (continued) | Prefix Length | Reserved |P|N| 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 P: Local Protection flag. The P bit represents whether this subobject 146 is designated as a PLR. It will be set to 0 if the node is designated 147 to be a PLR for the protected LSP, and set to 1 otherwise. If the 148 "Local Protection Desired" flag in the SESSION_ATTRIBUTE Object is 149 not set, no local protection will be used for the whole LSP, and the 150 value of the P bit is insignificant. 152 N: Node Protection flag. The N bit represents whether node protection 153 is required for this subobject. It will be set to 1 if node 154 protection is desired, and set to zero if the protection type is 155 indicated by the Node Protection Flag in the SESSION_ATTRIBUTE Object. 156 Note the N bit makes sense only when the "Local Protection Desired" 157 flag in the SESSION_ATTRIBUTE Object is set and the above P bit is 158 set to 0. 160 4.2. Extensions to IPv6 Prefix Subobject 162 Two new flags are defined in this subobject. The structure of 163 extended IPv6 prefix subobject is as below: 165 0 1 2 3 166 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 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 |L| Type | Length | IPv6 address (16 bytes) | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | IPv6 address (continued) | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | IPv6 address (continued) | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | IPv6 address (continued) | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | IPv6 address (continued) | Prefix Length | Reserved |P|N| 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 P: Local Protection flag. The P bit represents whether this subobject 180 is designated as a PLR. It will be set to 0 if the node is designated 181 to be a PLR for the protected LSP, and set to 1 otherwise. If the 182 "Local Protection Desired" flag in the SESSION_ATTRIBUTE Object is 183 not set, no local protection will be used for the whole LSP, and the 184 value of the P bit is insignificant. 186 N: Node Protection flag. The N bit represents whether node protection 187 is required for this subobject. It will be set to 1 if node 188 protection is desired, and set to zero if the protection type is 189 indicated by the Node Protection Flag in the SESSION_ATTRIBUTE Object. 190 Note the N bit makes sense only when the "Local Protection Desired" 191 flag in the SESSION ATTRIBUTE Object is set and the P bit is set to 0. 193 4.3. Backward Compatibility 195 The P bit and N bit are designed to be backward compatible with 196 current protection mechanisms. LSRs which do not support this 197 extension will treat these bits as reserved bit and ignore the value 198 of them. When both the 2 bits are set to 0 by head end LSR, the 199 protection behavior of all other LSRs on the path (no matter support 200 this extension or not) is the same as current mechanisms. 202 5. Selection of PLRs 204 The selection of PLRs and the protection type are determined by the 205 tunnel ingress node. Normally it can be based on local policy of the 206 ingress node and information about the network. For example, the 207 ingress node may decide to choose a subset of LSRs on the path as 208 PLRs and specify particular protection type to protect critical nodes 209 and/or links, or it may exclude some nodes from being PLRs to reduce 210 burden on these nodes and save bandwith. 212 6. Operations 214 6.1. Operation of Head End 216 If the head-end LSR needs to control the protection of the LSP, it 217 SHOULD set the P bit and N bit in corresponding ERO subobjects of the 218 PATH message properly based on the result of PLR selection. 220 6.2. Operation of Other LSRs 222 If a PATH message is received, the LSR SHOULD check the "Local 223 Protection Desired" and "Node protection desired" flags in the 224 SESSION Attribute Object along with the P bit and N bit in 225 corresponding ERO subobjects, then perform protection based on the 226 flags. 228 If some LSR on the path needs to add subobjects to the ERO, it MAY 229 set the P bit and N bit of the subobjects according to local policy. 231 7. Security Considerations 233 This document does not introduce new security issues. 235 8. IANA Considerations 237 There is no IANA action required by this draft. 239 9. References 241 9.1. Normative References 243 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 244 Requirement Levels", BCP 14, RFC 2119, March 1997. 246 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, 247 "Resource ReSerVation Protocol (RSVP) -- Version 1 248 Functional Specification", RFC 2205, September 1997. 250 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 251 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 252 Tunnels", RFC 3209, December 2001. 254 [RFC4090] Pan, P., Swallow, G. and Atlas, A., "Fast Reroute 255 Extensions to RSVP-TE for LSP Tunnels", RFC4090, May 2005. 257 9.2. Informative References 258 Authors' Addresses 260 Jie Dong 261 Huawei Technologies Co.,Ltd 262 KuiKe Building, No.9 Xinxi Rd., 263 Hai-Dian District 264 Beijing, 100085 265 P.R. China 267 EMail: dongjie_dj@huawei.com 269 Mach(Guoyi) Chen 271 Huawei Technologies Co.,Ltd 272 KuiKe Building, No.9 Xinxi Rd., 273 Hai-Dian District 274 Beijing, 100085 275 P.R. China 277 EMail: mach@huawei.com 279 Chun Liu 281 Huawei Technologies Co.,Ltd 282 Huawei Building, No.156 Beiqing Rd. 283 Hai-Dian District 284 Beijing, 100095 285 P.R. China 287 EMail: liuchuner1981@huawei.com