idnits 2.17.1 draft-bao-pce-pre-configured-routing-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2009) is 5300 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y.L. Bao 3 Internet-Draft X.H. Fu 4 Intended status: Informational G. Xie 5 Expires: April 22, 2010 ZTE Corporation 6 October 19, 2009 8 A Path Computation Element (PCE) Application for Pre-configured Routing 9 draft-bao-pce-pre-configured-routing-00 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 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 22, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 Pre-configured routing is a routing scheme that except primary route 48 operator configures one or multiple routes which will be used as 49 recovery route when the primary route fails for a service previously. 50 This document improves this traditional routing shceme, and PCE (Paht 51 Computation Element) is applied for pre-configured routing. 52 Furthermore, this document also presents a detailed set of PCC-PCE 53 (Path Computation Client) communication protocol requirements and 54 defines PCEP (Path Computation Element Communication Protocol) 55 extensions for PCEP. 57 Table of Contents 59 1. Conventions used in this document . . . . . . . . . . . . . . . 3 60 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Application of pre-configured Routing . . . . . . . . . . . . . 3 62 4. Architecture Analysis and Requirement . . . . . . . . . . . . . 4 63 4.1. Architecture Analysis . . . . . . . . . . . . . . . . . . . 4 64 4.2. Requirements to PCE . . . . . . . . . . . . . . . . . . . . 5 65 4.3. Requirements to PCEP . . . . . . . . . . . . . . . . . . . 5 66 5. Extensions to PCEP and Procedures . . . . . . . . . . . . . . . 6 67 5.1. New Flag Of The LSPA Object . . . . . . . . . . . . . . . . 6 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 70 7.1. New Flag Of The LSPA Object . . . . . . . . . . . . . . . . 6 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 72 9. Normative References . . . . . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 75 1. Conventions used in this document 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in [RFC2119]. 81 2. Introduction 83 Pre-configured routing is a very useful approach to achieve service 84 resteration. Generally, except primary route, operator also sets a 85 group of routes (usually with priority), i.e. pre-configured route 86 set,for a service. When the primary route fails, router can select a 87 proper resteration route from pre-configured route set. By this way, 88 faster resteration can be achieved. 90 Since pre-configured routes are pre-configured by management plane, 91 it can't be updated when network state changes dynamically. In some 92 cases, e.g. a fiber on the pre-configured route is cut, if operator 93 can't update pre-configured routes in time, the pre-configured routes 94 will become unavailable. Otherwise, generally the pre-configured 95 routes will be verified whether it is available before it is used to 96 signal a connection. This is also due to the problem that pre- 97 configured routes can't be updated timely. So this will introduce 98 another problem that time delay will affect service recovery. 100 This document introduces a PCE-based pre-configured routing method, 101 which uses PCE to update pre-configured route at the policy of 102 network management. This method helps to optimize network resources 103 and avoid the unavailablity of pre-configured routes. 105 3. Application of pre-configured Routing 107 As illustrated in figure 1, an example network is comprised of 9 108 nodes and an external PCE. Suppose there is a service between A and 109 I. In order to create the connection, source node A request a working 110 path. And PCE responds node A with path A-D-I. However, to provide 111 fast recovery when primary path A-D-I fails, node A can also request 112 additional pre-configured routes. And PCE reponds with path A-B-C-I 113 and A-E-F-G-H-I providing node A requested 2 pre-configured routes. 115 To provide the availability of pre-configured routes, PCE can 116 dynamically upade these routes according to the local policy. For 117 example, PCE can be configured to update Pre-configured route when 118 network status changes, or a 30 seconds timer expires etc. 120 In figure 1, Assume PCE is configured to update pre-configured route 121 as network status changes, when link BC failed, PCE will 122 aucomatically compute and send route A-B-D-I to source node A to 123 refresh previously requested pre-configured route. 125 If primary path fails, e.g. the fiber on link AD is cut, node A can 126 use pre-configured route A-B-C-I to recovery service between A and I 127 without requesting PCE again. 129 +=====+ 130 | PCE | 131 +=====+ 132 +---+ +---+ 133 .--------+ B +----------+ C + 134 / +-+-+ +-+-+ 135 / \ \ 136 / \ `--------. 137 / \ \ 138 +-+-+ +-+-+ +-+-+ 139 | A +---------------+ D +-------------------+ I | 140 +-+-+ +-+-+ +-+-+ 141 \ / / 142 \ / / 143 \ / / 144 +-+-+ +-+-+ +-+-+ +-+-+ 145 | E +-------+ F +-------+ G +-------+ H | 146 +---+ +---+ +---+ +---+ 148 Figure 1: Example of Application of Pre-configured Routing 150 4. Architecture Analysis and Requirement 152 4.1. Architecture Analysis 154 [RFC4655] introduced 5 PCE models which can be categorized according 155 to whether PCE functionality is integrated into the network element. 156 Under this methodology, two groups of PCE model, i.e. composite PCE 157 and external PCE, is generated. 159 For composite PCE, due to the resource limitation of the card, the 160 power of CPU is relatively weak, so the PCE capability is also 161 limited. However, compared to composite PCE, external PCE has more 162 resources (i.e. memory and CPU power etc), and it even can be 163 presented as a dedicated server. Therefore, external PCE is more 164 powerful than composite PCE. The application of pre-configured 165 routing will increase compuataion burden to PCE. Due to its powerful 166 computation capability, external PCE is more adequate than composite 167 PCE. However, if there is not much application of pre-configured 168 routing, composite PCE can also operate well. 170 [RFC4655] also describes stateful PCE and stateless PCE. For 171 statefull PCE, there is a strict synchronization between the PCE and 172 not only the network states (in term of topology and resource 173 information), but also the set of computed paths and reserved 174 resources in use in the network. So, it is easier to applying pre- 175 configured routing on stateful PCE. 177 Furthermore, considering the PCE failure, if an implementation has a 178 backup PCE, then the primary and backup PCE MUST keep strict 179 synchronization. And switching to the backup PCE can't affect the 180 correctness of path computation 182 However, the selection of PCE model, stateful PCE or stateless PCE is 183 out of this document. And the synchronizt between primary and backup 184 PCE is also out of this document, the operator can make a selection 185 according to network deployment. 187 4.2. Requirements to PCE 189 In order to support pre-configured routing, PCE SHOULD record pre- 190 configured route information, and maintain its status. When network 191 status changes, PCE SHOULD compute the affected pre-configured 192 routes. However, PCE MAY also compute pre-configured routes in idle 193 state to obtain the optimized pathes. The policy for PCE compute 194 pre-configured routes SHOULD be able to configured. 196 4.3. Requirements to PCEP 198 [RFC4657] gives detailed generic requirements for PCE communication 199 protocol. However, in orderto support pre-configured routing, 200 specific extensions to PCEP is required. For PCReq, it SHOULD be 201 possible for PCC to request pre-configured route. When PCE receives 202 a request identified with pre-configured routing, it SHOULD perform 203 path computation accroding to the required policy, e.g. node 204 disjoint, link disjoint and SRLG disjoint etc. And in the response 205 message, PCE SHOULD able to specify which one is pre-exsiting route. 206 If mulitple pre-configured routes are requested, PCE SHOULD give each 207 pre-configured route a priority in PCRep message. If PCE doesn't 208 support pre-configured routing it SHOULD give a negative response, 209 and the reason for computation failure. 211 When network status changes, PCE SHOULD re-compute pre-configured 212 routes according the configured policy. If new better pre-configured 213 route is computed, PCE should send it to PCC. There are two options 214 for PCE to send pre-configured route as follows: 216 PCRep is used to respond route computation result naturally. If it 217 is used to send pre-configured route, a new flag SHOULD be defined to 218 indicate the route carried is pre-configured route. 220 5. Extensions to PCEP and Procedures 222 5.1. New Flag Of The LSPA Object 224 The LSPA (LSP Attributes defined in [RFC5440]) object specifies 225 various TE LSP attributes to be taken into account by the PCE during 226 path computation. The LSPA object can be carried within a PCReq 227 message, or a PCRep message. 229 In order to support pre-configured route in PCReq and PCRep message, 230 a new flag, Pre-Configured Route flag, is defined in LSPA (LSP 231 Attributes) object. The definition of Pre-Configured Route flag is: 233 Bit Number Name Flag 234 22 Pre-Configured Route 236 When PCC requests pre-configured route, it SHOULD set Pre-Configured 237 Route flag in LSPA object. And PCE SHOULD also set this flag, when 238 it sends computed pre-configured route to PCC. If PCE can't 239 recognize Pre-Configured Route flag, a PCErr message SHOULD be sent 240 with an Error-Type=2 (Capability not supported). 242 6. Security Considerations 244 This document has no requirement for a change to the security models 245 within PCEP and associated protocols. 247 7. IANA Considerations 249 7.1. New Flag Of The LSPA Object 251 A new flag of the LSPA object (specified in [RFC5440]) is defined in 252 this document. 254 Pre-Configured Route Flag 255 Bit Number Name Flag Reference 256 22 Pre-Configured Route This document 258 8. Acknowledgements 260 The RFC text was produced using Marshall Rose's xml2rfc tool. 262 9. Normative References 264 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 265 Requirement Levels", BCP 14, RFC 2119, March 1997. 267 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 268 Element (PCE)-Based Architecture", RFC 4655, August 2006. 270 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 271 Communication Protocol Generic Requirements", RFC 4657, 272 September 2006. 274 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 275 (PCE) Communication Protocol (PCEP)", RFC 5440, 276 March 2009. 278 Authors' Addresses 280 Yuanlin Bao 281 ZTE Corporation 282 5F, R&D Building 3, ZTE Industrial Park, XiLi LiuXian Road 283 Nanshan District, Shenzhen 518055 284 P.R.China 286 Phone: +86 755 26773731 287 Email: bao.yuanlin@zte.com.cn 288 URI: http://www.zte.com.cn/ 290 Xihua Fu 291 ZTE Corporation 292 West District,ZTE Plaza,No.10,Tangyan South Road,Gaoxin District 293 Xi An 710065 294 P.R.China 296 Phone: +8613798412242 297 Email: fu.xihua@zte.com.cn 298 URI: http://www.zte.com.cn/ 299 Gang Xie 300 ZTE Corporation 301 ZTE Plaza, No.19, Huayuan Road East, Haidian District 302 Bei Jing 100191 303 P.R.China 305 Phone: +8613798412242 306 Email: xie.gang@zte.com.cn 307 URI: http://www.zte.com.cn/