idnits 2.17.1 draft-ietf-pce-enhanced-errors-02.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 abstract seems to contain references ([RFC5440]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 3, 2016) is 2847 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) ** Obsolete normative reference: RFC 6006 (Obsoleted by RFC 8306) == Outdated reference: A later version (-11) exists of draft-ietf-pce-vendor-constraints-05 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group H. Pouyllau 3 Internet-Draft Alcatel-Lucent 4 Intended status: Standards Track R. Theillaud 5 Expires: January 4, 2017 Marben Products 6 J. Meuric 7 France Telecom Orange 8 X. Zhang (Editor) 9 Huawei Technologies 10 July 3, 2016 12 Extensions to the Path Computation Element Communication Protocol for 13 Enhanced Errors and Notifications 14 draft-ietf-pce-enhanced-errors-02.txt 16 Abstract 18 his document defines new error and notification TLVs for the PCE 19 Communication Protocol (PCEP) [RFC5440]. It identifies the possible 20 PCEP behaviors in case of error or notification. Thus, this draft 21 defines types of errors and notifications and how they are disclosed 22 to other PCEs in order to support predefined PCEP behaviors. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 4, 2017. 41 Copyright Notice 43 Copyright (c) 2016 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 Simplified BSD License. 56 Table of Contents 58 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Conventions used in this document . . . . . . . . . . . . . . 3 60 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1.1. Error use-case . . . . . . . . . . . . . . . . . . . . . 4 63 3.1.2. Notification use-case . . . . . . . . . . . . . . . . . . 4 64 4. PCEP Behaviors . . . . . . . . . . . . . . . . . . . . . . . 4 65 4.1. PCEP Behaviors in Case of Error . . . . . . . . . . . . . . 5 66 4.2. PCEP Behaviors in Case of Notification . . . . . . . . . . 6 67 4.3. PCE Peer Identification . . . . . . . . . . . . . . . . . . 6 68 5. PCEP Extensions for Error and Notification Handling . . . . . 6 69 5.1. Propagation TLV . . . . . . . . . . . . . . . . . . . . . . 7 70 5.2. Error-criticality TLV . . . . . . . . . . . . . . . . . . . 7 71 5.3. Notification type TLV . . . . . . . . . . . . . . . . . . . 7 72 5.4. Behaviors and TLV combinations . . . . . . . . . . . . . . 8 73 5.5. Propagation Restrictions Objects . . . . . . . . . . . . . 9 74 5.5.1. Time-To-Live Object (TTL) . . . . . . . . . . . . . . . . 10 75 5.5.2. DIFFUSION-LIST Object (DLO) . . . . . . . . . . . . . . . 10 76 5.5.3. Rules Applied to Existing Errors and Notifications . . . 12 77 6. Error and Notification Scenarios . . . . . . . . . . . . . . 15 78 6.1. Error Behavior Type 1 . . . . . . . . . . . . . . . . . . . 15 79 6.2. Error Behavior Type 2 . . . . . . . . . . . . . . . . . . . 16 80 6.3. Error Behavior Type 4 . . . . . . . . . . . . . . . . . . . 16 81 6.4. Error Behavior Type 5 . . . . . . . . . . . . . . . . . . . 17 82 6.5. Notification Behavior Type 1 . . . . . . . . . . . . . . . 18 83 6.6. Notification Behavior Type 2 . . . . . . . . . . . . . . . 18 84 6.7. Notification Behavior Type 3 . . . . . . . . . . . . . . . 19 85 6.8. Notification Behavior Type 4 . . . . . . . . . . . . . . . 19 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 88 8.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 20 89 8.2. New DLO object . . . . . . . . . . . . . . . . . . . . . . 20 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 91 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 92 9.2. Informational References . . . . . . . . . . . . . . . . . 22 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 95 1. Terminology 97 PCE terminology is defined in [RFC4655]. 99 PCEP Peer: An element involved in a PCEP session (i.e. a PCC or a 100 PCE). 102 Source PCC: the PCC, for a given path computation query, initiating 103 the first PCEP request, which may then trigger a chain of successive 104 requests. 106 Target PCE: the PCE that can compute a path to the destination 107 without having to query any other PCE. 109 2. Conventions used in this document 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 3. Introduction 117 The PCE Communication Protocol [RFC5440] is designed to be flexible 118 and extensible in order to allow future evolutions or specific 119 constraint support such as proposed in 120 [I-D.ietf-pce-vendor-constraints]. Crossing different PCE 121 implementations (e.g. from different providers or due to different 122 releases), a PCEP request may encounter unknown errors or 123 notification messages. In such a case, the PCEP RFC [RFC5440] 124 specifies to send a specific error code to the PCEP peer. 126 In the context of path computation crossing different routing domains 127 or autonomous systems, the number of different PCE system 128 specificities is potentially high, thus possibly leading to divergent 129 and unstable situations. Such phenomenon can also occur in 130 homogeneous cases since PCE systems have their own policies that can 131 introduce differences in requests treatment even for requests having 132 the same destination. In order to generalize PCEP behaviors in the 133 case of heterogeneous PCE systems, new objects have to be defined. 134 Dealing with heterogeneity is a major challenge considering PCE 135 applicability, particularly in multi-domain contexts. Thus, 136 extending such error codes and PCEP behaviors accordingly would 137 improve interoperability among different PCEP implementations and 138 would solve some of these unstable issues. However, some of them 139 would still remain (e.g. the divergences in request treatment 140 introduced by different policies). 142 The purpose of this draft is to identify and specify new optional 143 TLVs and objects in order to generalize PCEP behaviors. 145 3.1. Examples 147 The two following scenarios underline the need for a normalization of 148 the PCEP behaviors according to existing error or notification types. 150 3.1.1. Error use-case 152 PCE(i-1) has sent a request to PCE(i) which has also sent a request 153 to PCE(i+1). PCE(i-1) and PCE(i+1) have the same error semantic but 154 not PCE(i). If PCE(i+1) throws an error type and value unknown by 155 PCE(i). PCE(i) could then adopt any other behaviors and sends back 156 to PCE(i-1) an error of type 2 (Capability not supported), 3 (Unknown 157 Object) or 4 (Not supported Object) for instance. As a consequence, 158 the path request would be cancelled but the error has no meaning for 159 PCE(i-1) whereas if PCE(i) had simply forwarded the error sent by 160 PCE(i+1), it would have been understood by PCE(i-1). 162 3.1.2. Notification use-case 164 PCE(i-1) has sent a request to PCE(i) which has also sent a request 165 to PCE(i+1) but PCE(i+1) is overloaded. Without extensions, PCE(i+1) 166 should send a notification of type 2 and a value flag giving its 167 estimated congestion duration. PCE(i) can choose to stop the path 168 computation and send a NO_PATH reply to PCE(i-1). Hence, PCE(i-1) 169 ignores the congestion duration on PCE(i+1) and could seek it for 170 further requests. 172 4. PCEP Behaviors 174 One of the purposes of the PCE architecture is to compute paths 175 across networks, but an added value is to compute such paths in 176 inter-area/layer/domain environments. The PCE Communication Protocol 177 [RFC5440] is based on the Transport Communication Protocol (TCP). 178 Thus, to compute a path within the PCE architecture, several TCP/PCEP 179 sessions have to be set up, in a peer-to-peer manner, along a set of 180 identified PCEs. 182 When the PCEP session is up for two PCEP peers, the PCC of the first 183 PCE System (the source PCC) sends a PCReq message. If the PCC does 184 not receive any reply before the dead timer is out, then it goes back 185 to the idle state. A PCC can expect two kinds of replies: a PCRep 186 message containing one or more valid paths (EROs) or a negative PCRep 187 message containing a NO-PATH object. 189 Beside PCReq and PCRep messages, notification and error messages, 190 named respectively PCNtf and PCErr, can be sent. There are two types 191 of notification messages: type 1 is for cancelling pending requests 192 and type 2 for signaling a congestion of the PCE. Several error 193 values are described in [RFC5440]. The error types concerning the 194 session phase begin at 2, error type 1 values are dedicated to the 195 initialization phase. 197 As the PCE Communication Protocol is built to work in a peer-to-peer 198 manner (i.e. supported by a TCP Connection), it supposes that the 199 "deadtimer" of the source PCC is long enough to support the end-to- 200 end distributed path computation process. 202 The exchange of messages in the PCE Communication Protocol is 203 described in details when PCEP is in states OpenWait and KeepWait in 204 [RFC5440]. When the session is up, message exchange is defined in 205 [RFC5440]. [RFC5441] describes the Backward Recursive Path 206 Computation (BRPC) procedure, and, because it considers an inter- 207 domain path computation, gives a bigger picture of the possible 208 behaviors when the session is up. Detailed behavior is mostly let 209 free to any specific implementation. The following sections 210 identifies the PCEP behaviors in case of error or notification and 211 also introduce the requirement of PCEP peer identification in both 212 cases. 214 4.1. PCEP Behaviors in Case of Error 216 [RFC5440] specifies that "a PCEP Error message is sent in several 217 situations: when a protocol error condition is met or the request is 218 not compliant with the PCEP specification". On this basis, and 219 according to the other RFCs, the identified PCEP behaviors are the 220 followings: 222 o "Propagation": the received message requires to be propagated 223 forwardly or backwardly (depending on which PCEP peer has sent the 224 message) to a set of PCEP peers; 226 o "Criticality level": in different RFCs, error-types affects the 227 state of the PCEP request or session in different manners; hence, 228 different level of criticality can be observed: 230 o 232 * Low-level of criticality: the received message does not affect 233 the PCEP connection and further answer can still be expected; 235 * Medium-level of criticality: the received message does not 236 affect the PCEP connection but the request(s) is(are) 237 cancelled; 239 * High-level of criticality: the received message indicates that 240 the PCEP peer will close the session with its peer (and so 241 pending requests associated by the error, if any, are 242 cancelled.) 244 The high-level of criticality has been extracted from [RFC5440] which 245 associates such a behavior to error-type of 1 (errors raised during 246 the PCEP session establishment). Hence, such errors are quite 247 specific. For the sake of completeness, they have been included in 248 this document. 250 4.2. PCEP Behaviors in Case of Notification 252 Notification messages can be employed in two different manners: 253 during the treatment of a PCEP request, or independently from it to 254 advertise information (in [RFC5440], the request ID list within a 255 PCNtf message is optional). Hence, three different types of 256 behaviors can be identified: 258 o "Local": the notification does not imply any forward or backward 259 propagation of the message; 261 o "Request-specific propagation": the received message requires to 262 be propagated forwardly or backwardly (depending on which peer has 263 sent the message) to the PCEP peers; 265 o "Non request-specific propagation": the received message must be 266 propagated to any known peers (e.g. if PCE discovery is activated) 267 or to a list of identified peers. 269 4.3. PCE Peer Identification 271 The propagation of errors and notifications affects the state of the 272 PCEP peers along the chain. In some cases, for instance a 273 notification that a PCE is overloaded, the identification of the PCEP 274 peer - or that the sender PCE is not the direct neighbor - might be 275 an important information for the PCEP peers receiving the message. 277 5. PCEP Extensions for Error and Notification Handling 279 This section describes extensions to support error and notification 280 with respect to the PCEP behavior description defined in Section 4. 281 This document does not intend to modify errors and notification types 282 previously defined in existing documents (e.g. [RFC5440], [RFC5441], 283 etc.). 285 5.1. Propagation TLV 287 To support the propagation behavior mentioned in Section 4.1 and 288 Section 4.2, a new optional TLV is defined, which can be carried in 289 PCEP-ERROR and NOTIFICATION objects, to indicate whether a message 290 has to be propagateed or not. The allocation from the "PCEP TLV Type 291 Indicators" sub-registry will be assigned by IANA and the request is 292 documented in Section 8. 294 The description is "Propagation", the length value is 2 bytes and the 295 value field is 1 byte. The value field is set to default value 0 296 meaning that the message MUST NOT be propagated. If the value field 297 is set to 1, the message MUST be propagated. Section 5.5 specifies 298 the destination and to limit the number of messages. 300 5.2. Error-criticality TLV 302 To support the shutdown behavior mentioned in Section 4.1, we extend 303 the PCEP-ERROR object by creating a new optional TLV to indicate 304 whether an error is recoverable or not. The allocation from the 305 "PCEP TLV Type Indicators" sub-registry will be assigned by IANA and 306 the request is documented in Section 8. 308 The description is "Error-criticality", the length value is 2 bytes 309 and the value field is 1 byte. The value field is set to default 310 value 0 meaning that the error has a low-level of criticality (so 311 further messages can be expected for this request). If the value 312 field is set to 1, the error has a medium-level of criticality and 313 requests whose identifiers appear in the same message MUST be 314 cancelled (so no further messages can be expected for these 315 requests). If the value field is set to 2, the error has a high- 316 level of criticality, the connection for this PCEP session is closed 317 by the sender PCE peer. 319 5.3. Notification type TLV 321 To support the request-specific behavior mentioned in Section 4.2, we 322 extend the NOTIFICATION object by creating a new optional TLV to 323 indicate whether the notification is request-specific or not. The 324 allocation from the "PCEP TLV Type Indicators" sub-registry will be 325 assigned by IANA and the request is documented in Section 8. 327 The description is "Notification Type", the length value is 2 bytes 328 and the value field is 1 byte. The value field is set to default 329 value 0 meaning that the notification is not request-specific. If 330 the value field is set to 1, the notification is request-specific. 332 If according to RFC5440 a notification contains a request-id, then 333 the value field of the Notification type TLV MUST be set to 1. 335 5.4. Behaviors and TLV combinations 337 The propagation behavior MAY be combined with all criticality levels, 338 thus leading to 6 different behaviors. In the case of a criticality 339 level of 2, the session is closed by the PCE peer which sends the 340 message. Hence, the criticality level is purely informative for the 341 PCE peer which receives the message. If it is combined with a 342 propagation behavior, then the PCE propagating the message MUST 343 indicate the same level of criticality if it closes the session. 344 Otherwise, it MUST use a criticality level of 1 if it does not close 345 the session. 347 For a PCErr message, all the possible behaviors described in 348 Section 4.1 can be covered with TLVs included in a PCEP-ERROR object. 349 The following table captures all combinations of error behaviors: 351 | Error \Propogation| 0 | 1 | 352 | criticallity\ Value | ( No |(Propogation | 353 | value \ | Propagation) | Required) | 354 |------------------------------------------------------| 355 | 0 (low) | Type 1 | Type 4 | 356 | 1 (medium) | Type 2 | Type 5 | 357 | 2 (high) | Type 3 | Type 6 | 358 |------------------------------------------------------| 360 o "Error Behavior Type 1" : Local Error with a low level of 361 criticality; 363 o "Error Behavior Type 2": Local Error with a medium level of 364 criticality; 366 o "Error Behavior Type 3": Local Error with a high level of 367 criticality; 369 o "Error Behavior Type 4": Propagated Error with a low level of 370 criticality; 372 o "Error Behavior Type 5": Propagated Error with a medium level of 373 criticality; 375 o "Error Behavior Type 6": Propagated Error with a high level of 376 criticality; 378 For a notification message, the behaviors are covered as ensued, with 379 TLVs included in a NOTIFICATION object: 381 | \Propogation | 0 | 1 | 382 | Notification\ Value | (No | (Propogation | 383 | type value \ | Propagation) | Required) | 384 |--------------------------------------------------------| 385 | 0 (non request-specific)| Type 1 | Type 3 | 386 | 1 (request-specific) | Type 2 | Type 4 | 387 |--------------------------------------------------------| 389 o "Notification Behavior Type 1": TLV "Propagation" with value 0 and 390 TLV "Notification Type" with value 0; 392 o "Notification Behavior Type 2": TLV "Propagation" with value 0 and 393 TLV "Notification Type" with value 1; 395 o "Notification Behavior Type 3": TLV "Propagation" with value 1 and 396 TLV "Notification Type" with value 0; 398 o "Notification Behavior Type 4": TLV "Propagation" with value 1 and 399 TLV "Notification Type" with value 1; 401 5.5. Propagation Restrictions Objects 403 In order to limit the propagation of errors and notifications, the 404 following mechanisms SHOULD be used: 406 A Time-To-Live(TTL) object: to limit the number of PCEP peers that 407 will recursively receive the message; 409 A DIFFUSION-LIST object (DLO): to specify the PCEP peer addresses 410 or domains of PCEP peers the message must be propagate to; 412 History mechanism: if a PCEP peer keeps track of the messages it 413 has relayed, it could avoid propagating an error or notification 414 it has already received. 416 Such mechanisms SHOULD be used jointly or independently depending the 417 error or notification behaviors they are associated to. Note that, a 418 non request-specific propagated notification (i.e., "Notification 419 Behavior Type 3") MUST include a DLO and SHOULD include a TTL. The 420 conditions of use for the TTL and DIFFUSION-LIST object are described 421 in sections below. 423 5.5.1. Time-To-Live Object (TTL) 425 The TTL value is set to any integer value to indicate the number of 426 PCEP peers that will recursively receive the message. The TLL object 427 SHOULD be used with propagated errors or notifications ("Propagation" 428 TLV with value 1 in PCEP-ERROR or NOTIFICATION objects). Each PCEP 429 peer MUST decrement the TTL value before propagating the message. 430 When the TTL value becomes 0, the message is no more propagated. 432 If the message to be propagated is request-specific ("Propagation" 433 TLV with value 1 in PCEP-ERROR or NOTIFICATION objects, and 434 "Notification Type" TLV with value 1 in a NOTIFICATION object), and 435 there is no TTL or DIFFUSION-LIST object included, the message MUST 436 reach the source PCC (or alternatively the target PCE). 438 5.5.2. DIFFUSION-LIST Object (DLO) 440 The DIFFUSION-LIST Object can be carried within a PCErr and a PCNtf 441 message and can either be used in a message sent by a PCC to a PCE or 442 vice versa. The DLO MAY be used with propagated errors (TLV 443 "Propagation"at value 1 in PCEP-ERROR object) and request-specific 444 propagated notifications (i.e., "Notification Behavior Type 4"). 445 Furtheremore, it MUST be used with non request-specific propagated 446 notifications (i.e., "Notification Behavior Type 3"). 448 DIFFUSION-LIST Object-Class is 25. 450 DIFFUSION-LIST Object-Type is 1. 452 The format of the DIFFUSION-LIST object body is as follows: 454 0 1 2 3 455 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 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Reserved | Flags | Target-type | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | | 460 // (Sub-objects) // 461 | | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 Reserved (8 bits): This field MUST be set to zero on transmission and 465 MUST be ignored on receipt. 467 Flags (16 bits): No flags are currently defined. Unassigned flags 468 MUST be set to zero on transmission and MUST be ignored on receipt. 470 Target-type (8 bits): restricts the diffusion to certain peers. The 471 following values are currently defined: 473 0: Any PCEP peer indicated in the list must be reached. 475 1: Only PCEs must be reached (and not PCC). 477 2: All PCEP peers with which a session is still opened must be 478 reached. 480 The DLO is made of sub-objects similar to the IRO defined in 481 [RFC5440]. The following sub-object types are supported. 483 Type Sub-object 485 1 IPv4 address 486 2 IPv6 address 487 4 Unnumbered Interface ID 488 5 OSPF area ID 489 32 Autonomous System number 490 33 Explicit eXclusion Route Sub-object (EXRS) 492 If the error or notification codes target specific PCEP peers, a 493 DIFFUSION-LIST object avoids partially flooding all PCEP peers. Any 494 PCEP peer receiving a PCErr or PCNTf message containing a PCEP-ERROR 495 or a NOTIFICATION object with a TLV "Propagation" at value 1 and 496 where a DLO appears, MUST remove from the DLO the addresses of the 497 PCEP peers to whom it will propagate the message, before sending them 498 the message. This is performed by adding the PCEP peer addresses to 499 the Explicit eXclusion Route Sub-object of the DLO. If a DIFFUSION- 500 LIST object is empty, the PCEP peer MUST NOT propagate the message to 501 any peer. 503 Note that, a Diffusion List Object could contain strict or loose 504 addresses to refer to a network domain (e.g. an Autonomous System 505 number, an OSPF area, an IP address). Hence, the PCEP peers targeted 506 by the message would be the PCEP peers covering the corresponding 507 domain. If an address is loose, each time a PCEP peer forwards a 508 message to another PCEP peer of this address, it MUST add it own 509 address to the Explicit eXclusion Route Sub-object (EXRS) of the DLO 510 for any forwarded messages. Hence, a PCE SHOULD avoid forwarding the 511 same message repeated to the same set of peers. Finally, when an 512 address is loose, the forwarding SHOULD be restrained indicating what 513 type of PCEP peers are targeted (i.e. PCE and/or PCC). Hence, a 514 Target-Type is specified. 516 5.5.3. Rules Applied to Existing Errors and Notifications 518 Many existing normative references states on error definitions (see 519 for instance [RFC5440], [RFC5441],[RFC5455], [RFC5521], [RFC5557], 520 [RFC5886], [RFC6006]). According to the definitions provided in this 521 document, the follwoing rules are applicable: 523 Error-type 1, described in [RFC5440], relates to PCEP session 524 establishement failures. All errors of this type are local (not 525 to be propagated). Hence, if a "Propagation" TLV is added to the 526 error message it MUST be set to value 0. Error-values 1,2,6,7 527 have a high level of criticality. Hence, if the "Error- 528 criticality" TLV is included within a PCErr message of type 1 and 529 value 1,2,6 or 7, it MUST have a value of 2. 531 Error-type 2,3,4, "Capability not supported", "Unknown object" and 532 "Not supported object" respectively, described in [RFC5440]: 533 errors of this type MAY be propagated using the TLV "Propagation". 534 Their level of criticality is defined as leading to cancel the 535 path computation request (cf. [RFC5440]). Hence, if the "Error- 536 criticality" TLV is included, it MUST have a value of 1. The 537 error-value 4 of error-type 4 ("Unsupported parameter") associated 538 to the BRPC procedure [RFC5441] SHOULD contain the "Propagation" 539 TLV with a DIFFUSION-LIST object requesting a propagation to the 540 PCC at the origin of the request. 542 Error-type 5 refers to "Policy violation", error values for this 543 type have been defined in [RFC5440], [RFC5541], [RFC5557], 544 [RFC5886] and [RFC6006]. In [RFC5440], it is specified that the 545 path computation request MUST be cancelled when an error of type 5 546 occurs. Hence, if the "Error-criticality" TLV is included, it 547 MUST have a value of 1. As such errors might be conveyed to 548 several PCEs, the "Propagation" TLV MAY be used. 550 Error-type 6 described as "Mandatory object missing" in [RFC5440], 551 leads to the cancellation of the path computation request. Hence, 552 if the "Error-criticality" TLV is included, it MUST have a value 553 of 1. The "Propagation" TLV MAY be used with such errors. The 554 error-value of 4 for Monitoring object missing defined in 555 [RFC5886] is no exception to the rule. 557 Error-type 7 is described as "synchronized path computation 558 request missing". In [RFC5440], it is specified that the reffered 559 synchronized path computation request MUST be cancelled when an 560 error of type 5 occurs. Hence, if the "Error-criticality" TLV is 561 included, it MUST have a value of 1. The "Propagation" TLV MAY be 562 used with such errors. 564 Error-type 8 is raised when a PCE receives a PCRep with an unknown 565 request reference. If the "Propagation" TLV is used with error- 566 type 8, it SHOULD be set at a value of 0. The "Error-criticality" 567 TLV is not particularly relevant for error-type 8. Hence, if it 568 used, it MUST have the value of 0. 570 Error-type 9 is raised when a PCE attempts to establish a second 571 PCEP session. The existing session must be preserved. Hence, if 572 the "Error-criticality" TLV is included, it MUST have a value of 573 0. By definition, such an error message SHOULD NOT be propagated. 574 Thus, if the "Propagation" TLV is used with error-type 9, it 575 SHOULD be set at a value of 0. 577 Error-type 10 which refers to the reception of an invalid object 578 as described in [RFC5440] no indication is provided on the 579 cancellation of the path computation request. Hence, if the 580 "Error-criticality" TLV is included, it MUST have a value of 0. 581 The "Propagation" TLV MAY be used with such errors with any value 582 depending on the expected behavior. 584 Error-type 11 relates to "Unrecognized EXRS subobject" and is 585 described in [RFC5521]. No path computation request cancellation 586 is required by [RFC5521]. Hence, if the "Error-criticality" TLV 587 is included, it MUST have a value of 0. The "Propagation" TLV MAY 588 be used with such errors with any value depending on the expected 589 behavior. 591 Error-type 12 refers to "Diffserv-aware TE error" and is described 592 in [RFC5455]. Such errors are raised when the CLASSTYPE object of 593 a PCReq is recognized but not supported by a PCE. [RFC5455] does 594 not state about the path computation request when such errors are 595 met. Hence, both "Propagation" and "Error-criticality" TLVs COULD 596 be used within such error-types' messages and set to any specified 597 values. 599 Error-type 13 on "BRPC procedure completion failure" is described 600 in [RFC5441]. [RFC5441] states that in such cases, the PCErr 601 message MUST be relayed to the PCC. Hence, such messages SHOULD 602 contain a "Propagation" TLV and a DIFFUSION-LIST object with a 603 Target-Type of 0 and corresponding adresses or with a Target-Type 604 of 2. It is not specified in [RFC5441] whether the path 605 computation request should be canceled or not. If the procedure 606 is not supported, it does not necessarily imply to cancel the path 607 computation request if another procedure is able to read and write 608 VSPT objects. Thus, the "Error-criticality" TLV MAY be used with 609 any value depending on the expected behavior. 611 Error-type 15 refers to "Global Concurrent Optimization Error" 612 defined in [RFC5557]. [RFC5557] states that the corresponding 613 global concurrent path optimization MUST be cancelled at the PCC. 614 Hence, if the "Error-criticality" TLV is included, it MUST have a 615 value of 1. The "Propagation" TLV MAY be used with such errors. 617 Error-type 16 relates to "P2MP Capability Error" defined in 618 [RFC6006]. Such errors lead to the cancellation of the path 619 computation request. Hence, if the "Error-criticality" TLV is 620 included, it MUST have a value of 1. The "Propagation" TLV MAY be 621 used with such errors. 623 Error-type 17, titled "P2MP END-POINTS Error" is defined 624 [RFC6006]. Such errors are thrown when a PCE tries to add or 625 prune nodes to or from a P2MP Tree. [RFC6006] does not specify if 626 such errors lead to cancel the path computation request. Hence, 627 the "Error-criticality" and "Propagation" TLVs MAY be used with 628 this type of error with any value depending on the expected 629 behavior. 631 Error-type 18 of "P2MP Fragmentation Error" is described [RFC6006] 632 which does not specify whether the path computation request should 633 be cancelled. But, as messages are fragmented, it is natural to 634 think that the PCE should wait at least a bit for further 635 messages. The "Error-criticality" TLV MAY be included in such 636 error messages and is particularly adapted to differ the semantic 637 of the same error-type message: if it is included with a value of 638 0 then the PCE will still wait for further fragmented messages, 639 when this waiting time ends, the TLV can be included with a value 640 of 1 in order to finally cancel the request. The "Propagation" 641 TLV MAY also be used with such errors. 643 Among the existing normative references, only the [RFC5440] defines 644 some notification-types and values. The recommendations with respect 645 to the TLVs definitions provided in this document are the followings: 647 Notitification-type=1, Notification-value=1 or 2: a PCC, 648 respectively a PCE, cancels a set of pending requests, such a 649 notification SHOULD be propagated to the list of PCEP peers which 650 were implied in the path computation requests. Hence, the 651 NOTIFICATION object SHOULD contains the "Propagation" TLV with 652 value 1 and the "Notification Type" TLV with value 1, together 653 with a DIFFUSION-LIST object containing the list of PCEP peers. 655 Notitification-type=2, Notification-value=1 or 2: indicates to the 656 PCC that the PCE is, respectively is no longer, in an overloaded 657 state. Such a notification can be propagated or stay local. It 658 is therefore RECOMMENDED to specify this behavior using the 659 "Propagation" TLV and associated restriction mechanims. 661 6. Error and Notification Scenarios 663 This section provides some examples depicting how the error and 664 notification types described above can be used in a PCEP session. 665 The origin of the errors or notifications is only illustrative and 666 has no normative purpose. Sometimes the PCE features behind may be 667 implementation-specific (e.g. detection of flooding). This section 668 does not provide scenarios for errors with a high-level of critcity 669 (i.e., Error behaviors 3 and 6) since such errors are very specific 670 and until now have been normalized only during the session 671 establishment (error-type of 1). 673 6.1. Error Behavior Type 1 675 In this example, a PCC attempts to establish a second PCEP session 676 with the same PCE for another request. Consequently the PCE sends 677 back an error message with error-type 9. This error stays local and 678 does not affect the former session. The second session is ignored. 679 If the "Propagation" TLV and "Error-criticality" TLV are used, they 680 should be both set to value 0. 682 +-+-+ +-+-+ 683 |PCC| |PCE| 684 +-+-+ +-+-+ 685 1) Path computation | | 686 event | | 687 2) PCE selection |----- Open Message--->| 688 |<--- Open message ----| 689 3) Path computation |---- PCReq message--->| 690 request X sent to | |4) Path computation 691 the selected PCE | | request queued 692 | | 693 5) Path computation | | 694 event | | 695 6) PCE selection | | 696 |----- Open Message--->|8) Session already 697 | |opened 698 |<--- PCErr message----| Error-type=9 699 | | 701 6.2. Error Behavior Type 2 703 In this example, the PCC sends a DiffServ-aware path computation 704 request. If the PCE receiving the request does not support the 705 indicated class-type, it thus sends back a PCErr message with error- 706 type=12 and error-value=1. If the "Propagation" TLV and "Error- 707 criticality" TLV are present, they should carry value 0 and value 1 708 respectively. Consequently, the request is cancelled. 710 +-+-+ +-+-+ 711 |PCC| |PCE| 712 +-+-+ +-+-+ 713 1) Path computation | | 714 event | | 715 2) PCE selection | | 716 3) Path computation |---- PCReq message--->| 717 request X sent to | |4) Path computation 718 the selected PCE | | request queued 719 | | 720 | |5) DiffServ class-type 721 | | not supported 722 | |6) Path computation 723 | | request X 724 | | cancelled 725 |<--- PCErr message----| Error-type=12 726 | | 728 6.3. Error Behavior Type 4 730 In this example, a PCC sends a path computation requests with no P 731 flag set (e.g. END-POINT object with P-flag cleared). This is 732 detected by another PCE in the sequence. The path computation 733 request can thus be treated but the P-Flag will be ignored. Hence, 734 this error is not critical but the source PCC should be informed of 735 this fact. So, a PCErr message with error-type 10 ("Reception of an 736 invalid object"). The PCEP-ERROR object of the message contains a 737 "Propagation" TLV at value 1 and a "Error-criticality" TLV at value 738 0. It is hence propagated backwardly to the source PCC. 740 +-+-+ +-+-+-+-+ +-+-+ 741 |PCC| |PCE|PCC| |PCE| 742 +-+-+ +-+-+-+-+ +-+-+ 743 |---- PCReq message-->| | 744 | | | 745 | |---- PCReq message--->| 746 | | | 747 | | |1) Parameter is 748 | | | not supported 749 | | | 750 | |<--- PCErr message----| Error-type=10 751 |<--- PCErr message---| | 752 | | | 754 6.4. Error Behavior Type 5 756 In this example, PCEs are using the BRPC procedure to treat a path 757 computation request [RFC5441]. However, one of the PCEs does not 758 support a parameter of the request. Hence, a PCErr message with 759 error-type 4 and error-value 4 is sent by this PCE and has to be 760 forwarded to the source PCC. The PCEP-ERROR object includes a 761 "Propagation" TLV at value 1 and "Error-criticality" TLV at value 1 762 and the message is propagated backwardly to the source PCC. 763 Consequently, the request is cancelled. 765 +-+-+ +-+-+-+-+ +-+-+ 766 |PCC| |PCE|PCC| |PCE| 767 +-+-+ +-+-+-+-+ +-+-+ 768 |---- PCReq message-->| | 769 | | | 770 | |---- PCReq message--->| 771 | | | 772 | | |1) Unsupported 773 | | | Parameter BRPC 774 | | |2) Path 775 | | | computation 776 | | | request X 777 | | | cancelled 778 | |<--- PCErr message----| Error-type=4 779 |<--- PCErr message---| | 780 | | | 782 6.5. Notification Behavior Type 1 784 In this example, a PCE sends a non request-specific notification 785 indicating that, due to multiple sendings (or for other reasons), 786 further requests from this PCC will be ignored. Hence, a PCNtf 787 message is sent to the PCC with a NOTIFICATION object including the 788 "Propagation" TLV at value 0 and a "Notification Type" TLV at value 789 0. 791 +-+-+ +-+-+ 792 |PCC| |PCE| 793 +-+-+ +-+-+ 794 | | 795 | |1) Further requests 796 | | will be ignored 797 | | 798 |<--- PCNtf message----| 799 | | 801 6.6. Notification Behavior Type 2 803 In this example, a PCE sends a request-specific notification 804 indicating that, a set of pending requests are cancelled (e.g. 805 notification-type=1, notification-value=1 as described in [RFC5440]). 806 Hence, a PCNtf message is sent to the PCC with a NOTIFICATION object 807 including a "Propagation" TLV at value 0 and a "Notification Type" 808 TLV at value 1. 810 +-+-+ +-+-+ 811 |PCC| |PCE| 812 +-+-+ +-+-+ 813 1) Path computation | | 814 event | | 815 2) PCE selection | | 816 3) Path computation |---- PCReq message--->| 817 request X sent to | |4) Path 818 the selected PCE | | computation 819 | | request queued 820 | | 821 | |5) Pending requests 822 | | cancelled 823 | | 824 |<--- PCNtf message----|Notification-Type=1 825 | | 827 6.7. Notification Behavior Type 3 829 In this example, a PCE is temporarily congested. A PCNtf message 830 with a NOTIFICATION object containing a "Propagation" TLV at value 1 831 and a "Notification Type" TLV at value 0 is send to a PCEP peer. 832 This notification messge is propagated to a sequence of PCEs if 833 necessary. Here, PCEk is congested and send a PCNtf message to PCEi 834 with the approapriate TLVs, an OVERLOAD object as described in 835 [RFC5886], and a DIFFUSION-LIST object indicating PCEj as a target of 836 the notification. 838 +-+--+ +-+--+ +-+--+ 839 |PCEj| |PCEi| |PCEk| 840 +-+--+ +-+--+ +-+--+ 841 | | | 842 | | |1)PCE is busy 843 | | | for M minutes 844 | | | (time-out update) 845 | |<--- PCNtf message----| Notification-type=2 846 |<--- PCNtf message---| | 848 6.8. Notification Behavior Type 4 850 In this example, a PCE receives a request but it is temporarily 851 congested. However, it can treat the request after few minutes which 852 might cause some time-out in the predecessor PCE(s). Hence, a PCNtf 853 message with a NOTIFICATION object containing a "Propagation" TLV at 854 value 1 and a "Notification Type" TLV at value 1 is sent to the PCC 855 and propagated backwardly in the sequence. Such a notification could 856 include an OVERLOAD object as described in [RFC5886]. 858 +-+-+ +-+-+-+-+ +-+-+ 859 |PCC| |PCE|PCC| |PCE| 860 +-+-+ +-+-+-+-+ +-+-+ 861 |---- PCReq message-->| | 862 | | | 863 | |---- PCReq message--->| 864 | | | 865 | | |1)PCE is busy but 866 | | | will answer to X 867 | | | in M minutes 868 | | | (time-out update) 869 | |<--- PCNtf message----| Notification-type=2 870 |<--- PCNtf message---| | 872 7. Security Considerations 874 Within the introduced set of TLVs, the "Propagation" TLV affects PCEP 875 security considerations since it forces propagation behaviors. Thus, 876 a PCEP implementation SHOULD activate stateful mechanism when 877 receiving PCEP-ERROR or NOTIFICATION object including this TLV in 878 order to avoid DoS attacks. 880 8. IANA Considerations 882 IANA maintains a registry of PCEP parameters. This includes a sub- 883 registry for PCEP Objects. 885 IANA is requested to make an allocation from the sub-registry as 886 follows. The values here are suggested for use by IANA. 888 8.1. PCEP TLV Type Indicators 890 As described in Section 5.5 the newly defined TLVs allows a PCE to 891 enforce specific error and notification behaviors within PCEP-ERROR 892 and NOTIFICATION objects. IANA is requested to make the following 893 allocations from the "PCEP TLV Type Indicators" sub-registry. 895 Value Description Reference 896 7 Propagation this document 898 8 Error-criticality this document 900 9 Notification type this document 902 8.2. New DLO object 903 Object-class Value Object-Type and Name Reference 904 25 1: Diffusion list object this document 906 Target-Type Value Meaning Reference 907 0 Any PCEP peers this document 909 1 PCEs but excludes 910 PCC-only peers this document 912 2 PCEs and PCCs this document 913 with which a session 914 is still opened 916 Subobjects Reference 917 1: IPv4 prefix this document 918 2: IPv6 prefix this document 919 4: Unnumbered Interface ID this document 920 5: OSPF Area ID this document 921 32: Autonomous system number this document 922 33: Explicit Exclusion Route subobject (EXRS) this document 924 9. References 926 9.1. Normative References 928 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 929 Requirement Levels", BCP 14, RFC 2119, 930 DOI 10.17487/RFC2119, March 1997, 931 . 933 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 934 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 935 DOI 10.17487/RFC5440, March 2009, 936 . 938 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 939 "A Backward-Recursive PCE-Based Computation (BRPC) 940 Procedure to Compute Shortest Constrained Inter-Domain 941 Traffic Engineering Label Switched Paths", RFC 5441, 942 DOI 10.17487/RFC5441, April 2009, 943 . 945 [RFC5455] Sivabalan, S., Ed., Parker, J., Boutros, S., and K. 946 Kumaki, "Diffserv-Aware Class-Type Object for the Path 947 Computation Element Communication Protocol", RFC 5455, 948 DOI 10.17487/RFC5455, March 2009, 949 . 951 [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the 952 Path Computation Element Communication Protocol (PCEP) for 953 Route Exclusions", RFC 5521, DOI 10.17487/RFC5521, April 954 2009, . 956 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 957 Objective Functions in the Path Computation Element 958 Communication Protocol (PCEP)", RFC 5541, 959 DOI 10.17487/RFC5541, June 2009, 960 . 962 [RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path 963 Computation Element Communication Protocol (PCEP) 964 Requirements and Protocol Extensions in Support of Global 965 Concurrent Optimization", RFC 5557, DOI 10.17487/RFC5557, 966 July 2009, . 968 [RFC5886] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of 969 Monitoring Tools for Path Computation Element (PCE)-Based 970 Architecture", RFC 5886, DOI 10.17487/RFC5886, June 2010, 971 . 973 [RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T., 974 Ali, Z., and J. Meuric, "Extensions to the Path 975 Computation Element Communication Protocol (PCEP) for 976 Point-to-Multipoint Traffic Engineering Label Switched 977 Paths", RFC 6006, DOI 10.17487/RFC6006, September 2010, 978 . 980 9.2. Informational References 982 [I-D.ietf-pce-vendor-constraints] 983 Zhang, F., Farrel, A., and G. Bernstein, "Conveying 984 Vendor-Specific Constraints in the Path Computation 985 Element Protocol", draft-ietf-pce-vendor-constraints-05 986 (work in progress), December 2011. 988 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 989 Element (PCE)-Based Architecture", RFC 4655, 990 DOI 10.17487/RFC4655, August 2006, 991 . 993 Authors' Addresses 995 Helia Pouyllau 996 Alcatel-Lucent 997 Route de Villejust 998 NOZAY 91620 999 FRANCE 1001 Phone: + 33 (0)1 30 77 63 11 1002 Email: helia.pouyllau@alcatel-lucent.com 1004 Remi Theillaud 1005 Marben Products 1006 176 rue Jean Jaures 1007 Puteaux 92800 1008 FRANCE 1010 Phone: + 33 (0)1 79 62 10 22 1011 Email: remi.theillaud@marben-products.com 1013 Julien Meuric 1014 France Telecom Orange 1015 2, avenue Pierre Marzin 1016 Lannion 22307 1017 FRANCE 1019 Email: julien.meuric@orange-ftgroup.com 1021 Xian Zhang (Editor) 1022 Huawei Technologies 1023 F3-5-B R&D Center, Huawei Base Bantian, Longgang District 1024 Shenzhen, Guangdong 518129 1025 P.R.China 1027 Email: zhang.xian@huawei.com