idnits 2.17.1 draft-bao-pce-backup-route-computation-reqs-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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 28, 2010) is 5171 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5440' is defined on line 229, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Yuanlin Bao 3 Internet-Draft Xihua Fu 4 Intended status: Informational Gang. Xie 5 Expires: September 1, 2010 ZTE Corporation 6 February 28, 2010 8 The Requirements for Path Computation Element (PCE) Application for 9 Backup Route 10 draft-bao-pce-backup-route-computation-reqs-00.txt 12 Abstract 14 Backup route is another route for a service which will be used when 15 working path fails. Traditionally, this route is configured by 16 operator manually and can't be updated when LSA changes. This 17 document improves this traditional usage, and PCE (Path Computation 18 Element) is applied for backup route. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on September 1, 2010. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the BSD License. 58 Table of Contents 60 1. Conventions used in this document . . . . . . . . . . . . . . . 3 61 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Application Model . . . . . . . . . . . . . . . . . . . . . . . 3 63 4. Architecture Analysis and Requirements . . . . . . . . . . . . 4 64 4.1. Architecture Analysis . . . . . . . . . . . . . . . . . . . 4 65 4.2. Requirements to PCC and PCE . . . . . . . . . . . . . . . . 5 66 4.3. Requirements to PCEP . . . . . . . . . . . . . . . . . . . 5 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 68 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 69 7. Normative References . . . . . . . . . . . . . . . . . . . . . 6 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 72 1. Conventions used in this document 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in [RFC2119]. 78 2. Introduction 80 Backup route is a very useful approach to achieve service 81 restoration. Traditionally, except primary route, operator also sets 82 a group of routes (usually with priority), i.e. backup route set, for 83 a service. When the primary route fails, LSR can select a proper 84 restoration route from backup route set. By this way, faster 85 restoration can be achieved. 87 Since backup routes are pre-configured by management plane, it can't 88 be updated when network state changes dynamically. In some cases, 89 e.g. a fiber on the backup route is cut, if operator can't update 90 backup routes in time, the backup routes will become unavailable. 91 Otherwise, generally the backup routes will be verified whether it is 92 available before it is used to signal a connection. This is also due 93 to the problem that backup routes can't be updated timely. And this 94 will introduce another problem that time delay will affect service 95 recovery. 97 This document introduces a PCE-based backup route method, which uses 98 PCE to update backup route at the policy of network management. This 99 method helps provider to offer better service for customer and avoids 100 the unavailablity of backup routes. 102 3. Application Model 104 Figure 1 is an application model of pce-based backup route 105 computation. A user requests ingress LSR (PCC) for a service with 106 backup route. Then PCC requests PCE to compute a working path and a 107 backup path. PCE returns the results to PCC, and records that a 108 backup route service is requested by the PCC. When PCE receives a 109 LSA change from IGP, it'll check if the backup route computed 110 previously is affected. If the backup route is affected, it will re- 111 compute a new backup route, and send it to the PCC. 113 +-------------+ +---------+ 114 | | Change | | Change 115 | PCE |<---------| IGP |<---------- 116 | | of LSA | | of LSA 117 +-------------+ +---------+ 118 ^ | 119 |Path(W+B) |Path 120 |Request/ |Refresh 121 |Response | 122 V V 123 +------+ +-------------+ +-------------+ 124 | | Service | LSR | Signaling | | 125 | USER |--------->| (PCC) |---------->| LSR | 126 | | Request | | | | 127 +------+ +-------------+ +-------------+ 129 Figure 1: Backup Route Application Model 131 4. Architecture Analysis and Requirements 133 4.1. Architecture Analysis 135 [RFC4655] introduced 5 PCE models which can be categorized according 136 to whether PCE functionality is integrated into the network element. 137 Under this methodology, two groups of PCE model, i.e. composite PCE 138 and external PCE, is generated. 140 For composite PCE, due to the resource limitation of the card, the 141 power of CPU is relatively weak, so the PCE capability is also 142 limited. However, compared to composite PCE, external PCE has more 143 resources (i.e. memory and CPU power etc), and it even can be 144 presented as a dedicated server. Therefore, external PCE is more 145 powerful than composite PCE. The application of backup route will 146 increase compuataion burden to PCE. Due to its powerful computation 147 capability, external PCE is more adequate than composite PCE. 148 However, if there is not much application of backup route, composite 149 PCE can also operate well. 151 [RFC4655] also describes stateful PCE and stateless PCE. For 152 statefull PCE, there is a strict synchronization between the PCE and 153 not only the network states (in term of topology and resource 154 information), but also the set of computed paths and reserved 155 resources in use in the network. Since stateful PCE can perceive the 156 network state chang, so it can determine which computed path is 157 affected. Therefore, it is easier to applying backup route on 158 stateful PCE. 160 Furthermore, considering the PCE failure, if an implementation has a 161 backup PCE, then the primary and backup PCE MUST keep strict 162 synchronization. And switching to the backup PCE can't affect the 163 correctness of path computation 165 However, the selection of PCE model, stateful PCE or stateless PCE is 166 out of this document. And the synchronization between primary and 167 backup PCE is also out of this document, the operator can make a 168 selection according to the network deployment. 170 4.2. Requirements to PCC and PCE 172 In order to support the backup route, PCC SHOULD be able to let PCE 173 know that it needs backup route service. Thereby, PCE can start 174 backup service. Otherwise, PCC SHOULD also be able to notify PCE 175 that backup route service is cancelled, so PCE can stop backup route 176 services. 178 As for PCE, it SHOULD record backup route information, and maintain 179 its state. When network state changes, PCE SHOULD compute the 180 affected backup routes and send a new route to PCC. However, PCE MAY 181 also compute backup routes in idle state to obtain the optimized 182 paths. The policy for PCE to compute backup routes SHOULD be able to 183 be configured. 185 4.3. Requirements to PCEP 187 [RFC4657] gives detailed generic requirements for PCE communication 188 protocol. However, in order to support backup route, specific 189 extensions to PCEP is required. For PCReq, it SHOULD be possible for 190 PCC to request backup route. That is a mechanism is needed to make 191 PCE know that PCC want a backup route service. 193 When PCE receives a PCReq message with a backup route serivce 194 request, it SHOULD perform path computation accroding to the required 195 policy, e.g. node disjoint, link disjoint and SRLG disjoint etc. And 196 in the PCRep message, PCE SHOULD able to specify which one is pre- 197 exsiting route, if PCC requests both primary route and backup route 198 at the same time. If PCE doesn't support backup route it SHOULD give 199 a negative response, and the reason of the computation failure. When 200 network state changes, PCE SHOULD re-compute backup routes according 201 the configured policy. If a better backup route is found, PCE should 202 send it to PCC. 204 When PCC wants to cancel the backup route service, it can send a 205 notify message to PCE. Since current PCNtf message can't achieve 206 this function, some extensions is needed. 208 5. Security Considerations 210 This document has no requirement for a change to the security models 211 within associated protocols. 213 6. Acknowledgements 215 The RFC text was produced using Marshall Rose's xml2rfc tool. 217 7. Normative References 219 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 220 Requirement Levels", BCP 14, RFC 2119, March 1997. 222 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 223 Element (PCE)-Based Architecture", RFC 4655, August 2006. 225 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 226 Communication Protocol Generic Requirements", RFC 4657, 227 September 2006. 229 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 230 (PCE) Communication Protocol (PCEP)", RFC 5440, 231 March 2009. 233 Authors' Addresses 235 Yuanlin Bao 236 ZTE Corporation 237 5F, R&D Building 3, ZTE Industrial Park, XiLi LiuXian Road 238 Nanshan District, Shenzhen 518055 239 P.R.China 241 Phone: +86 755 26773731 242 Email: bao.yuanlin@zte.com.cn 243 URI: http://www.zte.com.cn/ 244 Xihua Fu 245 ZTE Corporation 246 West District,ZTE Plaza,No.10,Tangyan South Road,Gaoxin District 247 Xi An 710065 248 P.R.China 250 Phone: +8613798412242 251 Email: fu.xihua@zte.com.cn 252 URI: http://www.zte.com.cn/ 254 Gang Xie 255 ZTE Corporation 256 ZTE Plaza, No.19, Huayuan Road East, Haidian District 257 Bei Jing 100191 258 P.R.China 260 Phone: +8613798412242 261 Email: xie.gang@zte.com.cn 262 URI: http://www.zte.com.cn/