idnits 2.17.1 draft-gonzalezdedios-pce-reservation-state-01.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 both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 266: '...the given reservation period SHOULD be...' RFC 2119 keyword, line 270: '... policy, a PCE MAY limit the period ...' RFC 2119 keyword, line 271: '...rnatively, a PCE MAY be configured to ...' RFC 2119 keyword, line 274: '... o The PCE MAY decide to apply a di...' RFC 2119 keyword, line 276: '...this case, the PCE MUST reply with the...' (15 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: o Perform the Path Computation using the local Traffic Engineering Database which has been extended to account for resources that have been marked reserved or blocked and which SHOULD not be used while blocked. This includes both synchronized / dependent path computations via SVEC or individual Path Computations requested in the request_list. -- The document date (March 9, 2012) is 4431 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) == Missing Reference: 'PCEP-MIB' is mentioned on line 709, but not defined == Missing Reference: 'MONITORING' is mentioned on line 717, but not defined ** Downref: Normative reference to an Informational RFC: RFC 4655 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group O. Gonzalez de Dios, Ed. 3 Internet-Draft Telefonica I+D 4 Intended status: Standards Track R. Casellas 5 Expires: September 10, 2012 CTTC 6 C. Margaria 7 Nokia Siemens Networks 8 Y. Lee 9 F. Zhang 10 Huawei 11 March 9, 2012 13 PCEP Extensions for Temporary Reservation of Computed Path Resources and 14 Support for Limited Context State in PCE 15 draft-gonzalezdedios-pce-reservation-state-01 17 Abstract 19 The Path Computation Element (PCE) provides path computation 20 functions in support of traffic engineering in Multi-Protocol Label 21 Switching (MPLS) and Generalized MPLS (GMPLS) networks. 23 A limited form of statefulness is useful to improve PCE functionality 24 in situations in which the local TED might not be up to date, or in 25 the case of concurrent requests where most of the LSPs are computed 26 before the end of the set-up of the LSPs, when the TED is updated. 27 The PCC is responsible to setup or not the TE-Path computed by the 28 PCE. By providing an indication that it intends to use the resources 29 on the TE-Path a PCC can help the PCE to get a more accurate dynamic 30 TED view and thus the PCE can avoid suggesting the use of the same 31 resources for subsequent TE LSPs. 33 This document proposes an extension to the PCEP protocol to allow the 34 PCC to indicate to the PCE to block or reserve the resources computed 35 in a path request of a TE LSP for subsequent requests for a certain 36 time and can help to reduce the number of crankbacks. 38 Status of this Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on September 10, 2012. 55 Copyright Notice 57 Copyright (c) 2012 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. PCEP Requirements . . . . . . . . . . . . . . . . . . . . . . 6 74 3. PCEP Extensions (Encoding) . . . . . . . . . . . . . . . . . . 8 75 3.1. Requesting a Reservation of Resources . . . . . . . . . . 8 76 3.2. Replying a reservation status . . . . . . . . . . . . . . 10 77 3.3. Cancelling a Reservation . . . . . . . . . . . . . . . . . 10 78 3.4. RESERVATION object format . . . . . . . . . . . . . . . . 11 79 3.5. RESERVATION_CONF object format . . . . . . . . . . . . . . 12 80 3.6. RESERVATION_ID TLV . . . . . . . . . . . . . . . . . . . . 13 81 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 5.1. Multiple LSP restoration in a WSON network . . . . . . . . 14 84 5.2. Domain path selection . . . . . . . . . . . . . . . . . . 15 85 5.3. Multidomain path computation . . . . . . . . . . . . . . . 16 86 6. Manageability Considerations . . . . . . . . . . . . . . . . . 16 87 6.1. Control of Function and Policy . . . . . . . . . . . . . . 16 88 6.2. Information and Data Models . . . . . . . . . . . . . . . 16 89 6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 17 90 6.4. Verifying Correct Operation . . . . . . . . . . . . . . . 17 91 6.5. Requirements for Other Protocols and Functional 92 Components . . . . . . . . . . . . . . . . . . . . . . . . 17 93 6.6. Impact on Network Operation . . . . . . . . . . . . . . . 17 94 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 96 8.1. RESERVATION object . . . . . . . . . . . . . . . . . . . . 18 97 8.2. RESERVATION_CONF object . . . . . . . . . . . . . . . . . 18 98 8.3. RESERVATION_ID TLV . . . . . . . . . . . . . . . . . . . . 18 99 8.4. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 18 100 9. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 18 101 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 102 11. Normative References . . . . . . . . . . . . . . . . . . . . . 19 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 105 1. Introduction 107 According to [RFC4655], a PCE can be either stateful or stateless. 108 In the former case, there is a strict synchronization between the 109 PCE, the network state (in terms of topology and per link aggregated 110 resource information such as unreserved bandwidth), and also the set 111 of computed paths, active Label Switched Paths (LSPs) and resources 112 in use in the network. 114 In other words, a stateful PCE utilizes information from the TED as 115 well as information about existing paths (for example, TE LSPs) in 116 the network when processing new requests. However, the maintenance 117 and synchronization of a stateful LSP database (LSP-DB) can be non- 118 trivial, not only because it should verify the actual establishment 119 of computed paths, and because it might not be the unique element to 120 compute paths. 122 In addition, it can be argued that maintaining such a stateful 123 database is not a function of the PCE, but rather of a Network 124 Management System (NMS). 126 On the other hand, a stateless PCE does not typically keep track of 127 computed paths, and each set of request(s) is processed independently 128 of each other, typically using a local copy of the TED. Since a 129 stateless PCE typically operates on a graph with computation 130 constraints and without tracking the current state of paths, 131 independent requests will be processed on the same TED graph, until 132 the graph is updated. 134 With a stateless PCE, there is a 'potential window of TED 135 inaccuracy', where a stateless PCE may compute paths based on current 136 TED information, which could be out-of-sync with the actual or 137 potential network state changes given other recent PCE-computed 138 paths. 140 For example, some sources for this potential TED inaccuracy are: 142 o Control Plane link latencies may increase due to several factors 143 such as: a) the time required for a PCC to obtain the paths after 144 a successful computation, requiring several Round-Trip-Times (RTT) 145 as per TCP; b) the setup delay and c) the time it takes for the 146 PCE to update the local TED given IGP update times. 148 o The routing and topology dissemination protocol (i.e. OSPF-TE) ), 149 which may operate with timers for LSA updates, to avoid excessive 150 control plane overhead. 152 o Concurrent requests that arrive during the time window, between a 153 response is sent and the LSP is setup and the topology changes 154 flooded. Even for very fast networks with low latency, there may 155 be 'batched' requests: several path computation requests within a 156 PCReq message or, in dynamic restoration without pre-planning, 157 several LSPs that need to be rerouted avoiding a failed link. 159 o Local PCE contention, where the PCE needs to concurrently serve 160 path computation requests and update the LSA (e.g. parsing OSPF-TE 161 LSA updates). A PCE implementation may need to find a trade-off, 162 when synchronizing access to the local TED: favor OSPF-TE parsing 163 which means that some path computations are slightly delayed to 164 allow an 'update' to be processed, or give strict priority to 165 computation requests. 167 In consequence, a stateless PCE may assign the same (or a subset of 168 the same) resources to several requests, which may result in 169 contention and degraded network performance. The effects are 170 detected late, typically during path signaling, causing path blocking 171 and excessive crank-backs and retries. 173 Note that, as per RFC 5440 [RFC5440], a PCC may include a set of 174 previously computed paths in A given request, in order to take them 175 into account, for instance, to avoid double bandwidth accounting or 176 to try to minimize changes (minimum perturbation problem). 178 Section 6.8 of RFC 4655 [RFC4655] suggests that a limited form of 179 statefulness might be applied within an otherwise stateless PCE. The 180 PCE may retain some context from paths it has recently computed so 181 that it avoids suggesting the use of the same resources for other TE 182 LSPs, using heuristics / statistic or forecasting for improved 183 resource (i.e. wavelength) allocation. In other words, a given PCE 184 implementation may decide to perform additional book-keeping and 185 management of resources, deploying policies that prevent sub-optimal 186 allocations. For instance a PCE may compute the mean time used to 187 update the TED based on the previous calculated TE-LSPs and TED 188 updates. Those kinds of mechanisms may reduce the TED inaccuracy but 189 in all cases they cannot infer the PCC use of the TE-path. 191 This document proposes a set of extensions to the PCEP protocol to 192 allow a PCC to request a PCE to block or reserve the resources 193 associated with a path computation for a given path request. By 194 reservation, it is implied that a set of resources which have been 195 associated to such computation are excluded for subsequent path 196 computations for a given time period. This time-based temporary 197 reservation PCE system would be a compromise between a full-blown 198 stateful PCE and a stateless PCE to achieve efficiency without 199 costing and excessive resource commitment associated with the 200 maintenance and synchronization of a stateful PCE system. Due to the 201 fact that the PCC is explicitly indicating this reservation, the PCE 202 can get a more accurate view of the dynamic of the TED and thus 203 increase the accuracy of its routing. In addition having an explicit 204 input may simplify how a PCE take into account the fact that the TED 205 may be outdated. 207 In the cases where the resource is uniquely identified in the 208 topology update (such as receiving an OSPF-TE TE LSA with a bitmap 209 encoded wavelength availability reflecting a change in the link 210 status)), the reservation can still hold after a topology update, as 211 there is a correspondence between the resource in both reservation 212 and traffic engineering update, and the PCE can infer whether a given 213 reserved resource has actually been committed. Otherwise, when the 214 traffic engineering update reaches the PCE, there is no way to 215 distinguish the resource in the reservation among the resources shown 216 in the TE update. Thus, to assure a coherent behavior, the general 217 rule is that as soon as the PCE gets updated traffic engineering 218 information, all the reservations are deleted, save the the cases 219 where the resource is uniquely identified and the PCE can infer 220 whether a given reserved resource has actually been committed. 222 Examples of resources potentially subject to reservations are: the 223 bandwidth computed for the path in PSC or L2SC layers, a specific 224 time slot (SDH) or tributary slot (OTN ODU-k) in TDM networks or a 225 given wavelength or regenerator (WSON or OTN OCh). 227 This document also presents some illustrative use cases where the PCC 228 would want the PCE to retain some context or state, like multiple LSP 229 restoration, and counterexamples where the PCC does not have the 230 intention to immediately set up the LSP, i.e., multidomain cases 231 where the PCE is probing different paths to decide the sequence of 232 domains. 234 2. PCEP Requirements 236 This section provides a set of requirements, both for PCCs and PCEs, 237 to support context awareness. 239 When requesting a path computation (PCReq) to a PCE, a PCC should be 240 able to indicate: 242 o Whether the resources computed in the request should be made 243 unavailable for further requests. 245 o The amount of time the resources should be commited/reserved for 246 the current computation request so that keeps subsequent requests 247 from taking. 249 o The type and granularity of the resources to be blocked in the 250 request. The type refers to the actual resources blocked such as 251 path bandwidth or timeslot, wavelength, fiber... The granularity 252 refers to the possibility of not only reserving the resource 253 computed for the path but whether the associated links/nodes/SRLGs 254 may need to be reserved too. 256 A PCE should be able to: 258 o Apply policies whether a reservation request can be applied or 259 not. 261 o Compute one or more paths according to the request parameters and, 262 based on the PCC indications, prevent (part of) the resources 263 commited in the computed route from being used for subsequent 264 computation requests for a given period. 266 o If the request is allowed, the given reservation period SHOULD be 267 no less than the requested period by the PCC (e.g. for the cases 268 where the PCE is only able to reserve for multiples of a given 269 value). This does not preclude the fact that, if configured by 270 policy, a PCE MAY limit the period to a lower period. 271 Alternatively, a PCE MAY be configured to reply with a PCEP_ERROR 272 stating the cause of the failed computation/reservation. 274 o The PCE MAY decide to apply a different granularity for the 275 reservation request (e.g. block a given Time Slot or wavelength 276 but not the TE links). In this case, the PCE MUST reply with the 277 actual reservation. 279 Note that, the means by which a PCE can perform the reservation/ 280 commitment of the resources are out of the scope of the present 281 document but could include, for example, marking the resources as 282 'reserved', applying internal exclude objects etc. 284 A PCE should be able to respond (PCRep) to the PCC the following: 286 o If the resources have been effectively locked, and the effective 287 allocated reservation period (if different from the requested 288 one). 290 o The granularity of the reservation, which may be different from 291 the requested one. 293 o Provide a means to allow a PCC to request the cancellation of an 294 active reservation (for example an identification of the 295 reservation to allow its cancellation). 297 The PCC should be able to request the cancellation of an active 298 resource reservation. 300 3. PCEP Extensions (Encoding) 302 3.1. Requesting a Reservation of Resources 304 EDITORS NOTE: OPTION WITH PCC-ID-REQ 306 A PCC that wants to indicate a PCE to temporarily reserve or block 307 resources does so by including a RESERVATION object along with a 308 client PCC_ID_REQ in a request within a PCReq message. 310 Analogously to [RFC5886] the PCC-ID-REQ object is used to specify the 311 IP address of the requesting PCC. The PCC-ID-REQ MUST be inserted 312 within a PCReq message to specify the IP address of the requesting 313 PCC. In [RFC5886] two PCC-ID-REQ objects (for IPv4 and IPv6) are 314 defined. 316 EDITORS NOTE: OPTION WITHOUT PCC-ID-REQ 318 A PCC that wants to indicate a PCE to temporarily reserve or block 319 resources does so by including a RESERVATION object in a request 320 within a PCReq message. 322 A PCE that processes a PCEP request with a RESERVATION object MUST 323 act according to the P-bit in the object header: if the P-bit is set, 324 the object MUST be treated as mandatory and the request must either 325 be processed using the contents of the object or rejected as defined 326 in [RFC5440]. If the P-bit is clear, the object MAY be used by the 327 PCE or MAY be ignored. 329 The RESERVATION object is optional in a PCEP request. Multiple 330 instances of the object MUST NOT be used on a single PCEP request and 331 if a PCE finds multiple instances of the object it MUST use the first 332 one and discard the rest (Editors note: alternatively, it could send 333 a PCErr, OR it could allow several RESERVATION objects, and let the 334 PCE choose which one will be used). The RESERVATION object may 335 appear either at an individual request level or within a SVEC. The 336 latter means that the RESERVATION object applies to all requests 337 involved in the SVEC object. 339 The PCReq ([RFC5440][RFC5541][RFC5557]) message is 340 ::= 342 [svec_list] 344 346 where 348 ::= 350 [] 352 [] 354 [] 356 [] 358 [ ] 360 [] 362 ::= 364 [] 366 ::= 368 [] 370 ::= 372 374 [] 376 [] 378 [] 380 [] 382 [ ] 384 [ []] 386 [] 388 [] 390 3.2. Replying a reservation status 392 If the PCE that receives the request applies the reservation, it 393 indicates so using a RESERVATION_CONF object in the PCRep message. 395 EDITOR'S NOTE: Alternatively a RESERVATION object can be used in the 396 PCReq message 398 The PCRep message is extended with regard to the one defined in 399 [RFC5440] as follows: 401 ::=[] 403 [] 405 [] 407 [] 409 [] 411 Note that the reservation applies at PATH level, and a 412 RESERVATION_CONF object is included within every path in a given PCEP 413 response. This means distinct reservations for each path, which can 414 be cancelled independently (Editor's Note: TDB, the PCC could 415 indicate whether to have a single reservation or multiple 416 reservation). 418 It is RECOMMENDED that the RESERVATION_CONF object appears the last 419 attribute for a Path (or as an optional object in the attribute-list 420 associated to a NO_PATH object. 422 3.3. Cancelling a Reservation 424 A PCC that wishes to cancel a reservation may send an unsolicited 425 notification to the PCE, including the identifier of the reservation. 427 The PCNtf message used for one or more cancellations has no RP 428 object. As with [RFC5440], the PCNtf message MUST carry at least one 429 NOTIFICATION object and MAY contain several NOTIFICATION objects 430 should the PCE or the PCC intend to notify of multiple events: 432 ::= 434 436 ::= [] 438 ::= 440 ::=[] 442 NOTIFICATION objects used for the purposes of cancelling an active 443 reservation MUST include the RESERVATION_ID TLV. It is RECOMMENDED 444 to use dedicated PCNtf messages for the purposes of cancelling 445 reservations. 447 Both the Notification-type and Notification-value are TBD by IANA 449 The following Notification-type and Notification-value values are 450 currently defined: 452 o Notification-type=TBD: Pending Reservation cancelled 454 o Notification-value=TBD (sug 1): PCC cancels a set of reservation 455 requests. 457 3.4. RESERVATION object format 459 RESERVATION Object-Class is to be assigned by IANA. 461 RESERVATION Object-Type is to be assigned by IANA (recommended 462 value=1) 464 The RESERVATION object indicates the intention of the PCC to set up 465 the requested path and request the PCE to reserve the resources of 466 the computed path to avoid being used by other requests. 468 0 1 2 3 469 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 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | Timer | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 |S N L| Resource Type | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Optional TLVs | 476 ... 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 o Timer is the value in ms of the time that the resources should be 480 blocked, encoded as a 32 bit unsigned integer. 482 o Resource Type indicates the type of resource to be reserved. A 483 value of 0 means the default resource type: 485 * Bandwidth (PSC, L2SC, ...) 487 * Time Slot (Sonet/SDH TDM) 489 * Tributary Slot (G709 OTN ODU-k TDM) 491 * Wavelength (G709 OTN OCh or WSON LSC) 493 o Bit L: if set, TE Links should be part of the reservation, and 494 excluded from subsequent request. 496 o Bit N: if set, Nodes should be part of the reservation. 498 o Bit S: if set, the set of SRLG (Shared Risk Link Group) deduced 499 from the associated resources (i.e., the union of SRLGs of the 500 links) should be part of the reservation. 502 Currently no TLVs are defined. 504 3.5. RESERVATION_CONF object format 506 The RESERVATION_CONF object is optional. The RESERVATION_CONF object 507 indicates that the PCE has reserved the resources of computed path to 508 avoid being used by other requests. The RESERVATION_CONF object is 509 sent in the PCRep. 511 The RESERVATION_CONF Object-Class is to be assigned by IANA. 513 The RESERVATION_CONF Object-Type is to be assigned by IANA 514 (recommended value=1) 516 The format of the RESERVATION_CONF object body is: 518 0 1 2 3 519 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 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Reservation ID | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Reservation timer | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 |S N L| Reservation Type | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 Timer is the value in ms of the time that the resources are blocked. 529 The PCE May decide to apply a different value that the one requested 530 by the PCC. 532 A PCC MUST NOT send a RESERVE_RESPONSE object if the client has not 533 requested a RESERVATION in the PCReq message. A PCE MAY apply 534 reservations as a means of internal policy and/or operation. 536 3.6. RESERVATION_ID TLV 538 The TLV indicates the reservation ID (Type TBA by IANA). 540 0 1 2 3 541 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 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Reservation ID | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 4. Procedures 548 A client that wishes to request a path computation with reservation 549 shall: 551 o Include a PCC_REQ_ID and RESERVATION objects in the involved 552 Request within the PCReq message. 554 o Specify what level of reservation to apply after the request. 556 Upon receiving a PCReq with a Resource Reservation object, the PCE 557 may: 559 o Perform the Path Computation using the local Traffic Engineering 560 Database which has been extended to account for resources that 561 have been marked reserved or blocked and which SHOULD not be used 562 while blocked. This includes both synchronized / dependent path 563 computations via SVEC or individual Path Computations requested in 564 the request_list. 566 o For the successful path computations, and for all paths 567 corresponding to a given Request, determine the type of resources 568 to be blocked (marked as reserved) with the granularity requested 569 by the client once mapped to PCE policies. 571 o It will start a local timer associated with this blocking action. 573 o Send the Responses (successful or not) using PCRep message(s) and, 574 where appropriate, indicate the level of reservation and 575 associated period. 577 o For subsequent requests, perform path computation as detailed 578 above, updating the local TED with potential new reservations. 580 Whenever a timer expires, the PCE will: 582 o Remove the reservation status / blocking that affected the 583 reservation (e.g. add the previously substracted unreserved 584 bandwidth, mark the label, wavelength or time slot as available, 585 etc). 587 o Delete any data related with this blocking action. 589 Whenever a traffic engineering update reaches the PCE, the PCE will: 591 o If the reserved resource can be uniquely identified in the traffic 592 engineering update, keep the reservation 594 o If the reserved resource cannot be uniquely identified in the 595 traffic engineering update, delete the reservation 597 5. Use cases 599 This section aims to show the use cases of the proposed possibility 600 to activate the limited context awareness. 602 5.1. Multiple LSP restoration in a WSON network 604 One of the most challenging scenarios for a PCE-based architecture is 605 the one of PCE-based dynamic multiple LSP restoration in a WSON 606 network without pre-planning. In the event of a network failure 607 affecting a high number of LSPs (e.g. a fiber cut), a PCE could 608 potentially receive a significant amount of restoration requests in a 609 short period of time from different PCCs. 611 One of the various challenges in this scenario is the fact that the 612 PCE needs to sequentially perform multiple independent path 613 computations including routing and wavelength assignment. In this 614 scenario, a stateless PCE would rely on TED information, which could 615 potentially be up-to-date before the first incoming request (e.g. in 616 case the routing algorithm has disseminated the failure event), but 617 will definitely be outdated for subsequent requests. 619 It might be expected that the paths calculated for different 620 connections would rely on the same nodes, TE links or even labels 621 (lambdas). It might occur at the signaling phase that multiple 622 connection requests are contending for the same resources. After the 623 eventual failure in the establishment of some of the connections, 624 subsequent requests to the PCE would be triggered. After a number of 625 loops, the PCE-based restoration would be eventually solved, but the 626 potential number of retries could be significantly high. 628 The main issue is that the stateless PCE relied on an outdated TED to 629 perform path computation. As the subsequent connection request is 630 expected to be computed immediately, there is either no time for the 631 routing algorithm to update the TED after a successful signaling or 632 for the signaling process to successfully finish. 634 In this context, the availability of a limited context aware PCE 635 could potentially solve the issue in a graceful fashion. Each of the 636 restoration path requests will have an associated Resource 637 Reservation object, which will state the kind of resources and the 638 amount of time they should be blocked. 640 The PCE will then temporarily 'mark' the resources as blocked, so as 641 not to consider them in subsequent connection requests, and thus 642 avoiding the contention at the signaling phase. The timer should be 643 in line with the LSP set up time and TED time to update. 645 This use case might be solved in the PCE by having a policy to 646 implicitly pre-reserve the resources for a given time, which can be 647 based on the mean time between a PCRep and a TED update indicating 648 that the labels are not available. The drawback of this implicit 649 reservation is that path establishment time may depend and a variety 650 of factor that may be strongly depend on the chosen path and 651 technology used (e.g. power equalization algorithms). In this case 652 the PCC have a better view on those aspects and can provide more 653 accurate view on when the TED will be updated. 655 5.2. Domain path selection 657 When selecting the set of domains of a multidomain path, a PCE may 658 request paths to several PCEs of different domains. Thus, the 659 intention of the request is not to establish a LSP, but to obtain a 660 hint on the domain path. Thus, in this case, no Reservation Object 661 would be sent. 663 Here implicit policies in PCE will be inaccurate as they cannot 664 determine if the PCC will setup the path or not. 666 5.3. Multidomain path computation 668 Once the domain path is known, when computing the actual path, the 669 reservation object can be used. Note that multidomain paths may take 670 a long time to be established, as it involves several AS or domains 671 with different behavior and policies. Thus, it is a way to guarantee 672 the availability of resources. 674 6. Manageability Considerations 676 Standard PCEP [RFC5440] describes various manageability 677 considerations in PCEP, and most of the manageability requirements 678 are already covered there. Specific aspects are detailed in this 679 section. 681 6.1. Control of Function and Policy 683 In addition to PCE configuration parameters listed in [RFC5440], the 684 following additional parameters might be required: 686 o The ability to enable or disable reservations on the PCE. 688 o The ability to retrieve a list of reservations currently active in 689 the PCE. 691 o The ability to configure which PCCs are allowed to perform 692 reservations and the ability to configure limits on the timer 693 periods requested. This includes, for example, the configuration 694 of IP based access lists for PCCs. 696 o The ability to configure which PCCs are allowed to perform 697 reservations for single-domain and multi-domain scenarios, 698 typically according to pre-defined agreements. 700 o The ability to configure which reservation granularity a given PCC 701 group is able to request, and the associated action (error or 702 downgrade). 704 o TDB: Advertisements of capabilities via IGP and configurability 706 6.2. Information and Data Models 708 A number of MIB objects have been defined for general PCEP control 709 and monitoring of P2P computations in [PCEP-MIB]. For the time 710 being, no extra models are considered although it could be possible 711 that current means to retrieve information from the PCE be extended 712 to include eventual resource reservations. 714 6.3. Liveness Detection and Monitoring 716 Other than the considerations expressed in [RFC5440], a PCE could 717 provide extensions to [MONITORING] to verify reservation status, and 718 to obtain statistics on the system. 720 6.4. Verifying Correct Operation 722 There are no additional requirements for verifying the correct 723 operation of the PCEP sessions. Future MIB objects could facilitate 724 verification of correct operation and reporting of reservations and 725 errors. 727 6.5. Requirements for Other Protocols and Functional Components 729 The method for the PCC to obtain information about a PCE capable of 730 reservation may include extensions to IGP protocols. 732 6.6. Impact on Network Operation 734 It is expected that the use of PCEP extensions specified in this 735 document will not significantly increase the level of operational 736 traffic. However, mis-configured, excessive reservation requests, 737 excessive reservation periods, or excessive granularity may increase 738 the number of failed requests or cause the PCE to provide sub-optimal 739 routes due to existing reservations. Coarse reservations may also 740 limit the resources that are available for a a PCE in order to serve 741 requests. 743 An excessive number of reservation requests and reservation 744 cancellations may degrade server performance. A PCE SHOULD provide a 745 means to control the rate of messages with reservation, extending the 746 proposed mechanism of [RFC5440]. 748 7. Security Considerations 750 In the event of an unauthorized path computation request with 751 mandatory resource reservation, or in case of a (distributed) denial 752 of service attack, the subsequent state/context managed within the 753 PCE may be disruptive to the network, resulting in performance 754 degradation or sub-optimal computed routes. Implementations should 755 conform to the relevant security requirements of [RFC5440] that 756 specifically help to control unauthorized requests. These mechanisms 757 include securing the PCEP session requests and responses using TCP 758 security techniques, authenticating the PCEP requests and responses 759 to ensure the message is intact and sent from an authorized node, 760 providing policy control by explicitly defining which PCCs are 761 allowed to perform resource reservations to the PCE and disallowing 762 reservation requests that may block an excessive amount of resources. 764 8. IANA Considerations 766 IANA maintains a registry of PCEP parameters. A number of IANA 767 considerations have been highlighted in previous sections of this 768 document. 770 8.1. RESERVATION object 772 8.2. RESERVATION_CONF object 774 8.3. RESERVATION_ID TLV 776 8.4. PCEP Errors 778 For the RESERVATION object, the default error procedures regarding 779 supported unknown objects defined in [RFC5440] apply 781 o Unsupported Reservation Option 783 o Reservation Forbidden by Policy 785 o Unknown Reservation Request 787 9. Contributing Authors 789 Telefonica I+D 791 Victor Lopez 793 Don Ramon de la Cruz 795 email: vlopez@tid.es 797 Francisco Javier Jimenez Chico 799 10. Acknowledgements 801 The authors thank Meral Sherazipur for the discussions and 802 suggestions in the topic. 804 11. Normative References 806 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 807 Element (PCE)-Based Architecture", RFC 4655, August 2006. 809 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 810 (PCE) Communication Protocol (PCEP)", RFC 5440, 811 March 2009. 813 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 814 Objective Functions in the Path Computation Element 815 Communication Protocol (PCEP)", RFC 5541, June 2009. 817 [RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path 818 Computation Element Communication Protocol (PCEP) 819 Requirements and Protocol Extensions in Support of Global 820 Concurrent Optimization", RFC 5557, July 2009. 822 [RFC5886] Vasseur, JP., Le Roux, JL., and Y. Ikejiri, "A Set of 823 Monitoring Tools for Path Computation Element (PCE)-Based 824 Architecture", RFC 5886, June 2010. 826 Authors' Addresses 828 Oscar Gonzalez de Dios (editor) 829 Telefonica I+D 830 Don Ramon de la Cruz 831 Madrid, 28006 832 Spain 834 Phone: +34 913328832 835 Email: ogondio@tid.es 837 Ramon Casellas 838 CTTC 839 Av. Carl Friedrich Gauss n7 840 Castelldefels, Barcelona 08860 841 Spain 843 Phone: 844 Email: ramon.casellas@cttc.es 845 Cyril Margaria 846 Nokia Siemens Networks 847 St Martin Strasse 76 848 Munich, 81541 849 Germany 851 Phone: +49 89 5159 16934 852 Email: cyril.margaria@nsn.com 854 Young Lee 855 Huawei 856 1700 Alma Drive, Suite 100 857 Plano, TX 75075 858 U.S. 860 Phone: (972) 509-5599 861 Email: leeyoung@huawei.com 863 Fatai Zhang 864 Huawei 865 F3-5-B RD Center 866 Bantian, Longgang District, Shenzhen 518129 867 P.R.China 869 Phone: 870 Email: zhangfatai@huawei.com