idnits 2.17.1 draft-ietf-pce-enhanced-errors-03.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 (February 28, 2018) is 2250 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) == Outdated reference: A later version (-10) exists of draft-ietf-pce-association-group-04 == Outdated reference: A later version (-10) exists of draft-ietf-pce-lsp-setup-type-08 ** Obsolete normative reference: RFC 6006 (Obsoleted by RFC 8306) Summary: 2 errors (**), 0 flaws (~~), 3 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: September 1, 2018 Marben Products 6 J. Meuric 7 France Telecom Orange 8 H. Zheng (Editor) 9 X. Zhang 10 Huawei Technologies 11 February 28, 2018 13 Extensions to the Path Computation Element Communication Protocol for 14 Enhanced Errors and Notifications 15 draft-ietf-pce-enhanced-errors-03.txt 17 Abstract 19 This document defines new error and notification TLVs for the PCE 20 Communication Protocol (PCEP) [RFC5440]. It identifies the possible 21 PCEP behaviors in case of error or notification. Thus, this draft 22 defines types of errors and notifications and how they are disclosed 23 to other PCEs in order to support predefined PCEP behaviors. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 1, 2018. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions used in this document . . . . . . . . . . . . . . 3 61 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.1.1. Error use-case . . . . . . . . . . . . . . . . . . . . . 4 64 3.1.2. Notification use-case . . . . . . . . . . . . . . . . . . 4 65 4. PCEP Behaviors . . . . . . . . . . . . . . . . . . . . . . . 4 66 4.1. PCEP Behaviors in Case of Error . . . . . . . . . . . . . . 5 67 4.2. PCEP Behaviors in Case of Notification . . . . . . . . . . 6 68 4.3. PCE Peer Identification . . . . . . . . . . . . . . . . . . 6 69 5. PCEP Extensions for Error and Notification Handling . . . . . 6 70 5.1. Propagation TLV . . . . . . . . . . . . . . . . . . . . . . 7 71 5.2. Error-criticality TLV . . . . . . . . . . . . . . . . . . . 7 72 5.3. Notification type TLV . . . . . . . . . . . . . . . . . . . 7 73 5.4. Behaviors and TLV combinations . . . . . . . . . . . . . . 8 74 5.5. Propagation Restrictions Objects . . . . . . . . . . . . . 9 75 5.5.1. Time-To-Live Object (TTL) . . . . . . . . . . . . . . . . 10 76 5.5.2. DIFFUSION-LIST Object (DLO) . . . . . . . . . . . . . . . 10 77 5.5.3. Rules Applied to Existing Errors and Notifications . . . 12 78 6. Error and Notification Scenarios . . . . . . . . . . . . . . 16 79 6.1. Error Behavior Type 1 . . . . . . . . . . . . . . . . . . . 16 80 6.2. Error Behavior Type 2 . . . . . . . . . . . . . . . . . . . 17 81 6.3. Error Behavior Type 4 . . . . . . . . . . . . . . . . . . . 17 82 6.4. Error Behavior Type 5 . . . . . . . . . . . . . . . . . . . 18 83 6.5. Notification Behavior Type 1 . . . . . . . . . . . . . . . 19 84 6.6. Notification Behavior Type 2 . . . . . . . . . . . . . . . 19 85 6.7. Notification Behavior Type 3 . . . . . . . . . . . . . . . 20 86 6.8. Notification Behavior Type 4 . . . . . . . . . . . . . . . 20 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 89 8.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 21 90 8.2. New DLO object . . . . . . . . . . . . . . . . . . . . . . 21 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 92 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 93 9.2. Informational References . . . . . . . . . . . . . . . . . 24 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 96 1. Terminology 98 PCE terminology is defined in [RFC4655]. 100 PCEP Peer: An element involved in a PCEP session (i.e. a PCC or a 101 PCE). 103 Source PCC: the PCC, for a given path computation query, initiating 104 the first PCEP request, which may then trigger a chain of successive 105 requests. 107 Target PCE: the PCE that can compute a path to the destination 108 without having to query any other PCE. 110 2. Conventions used in this document 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 3. Introduction 118 The PCE Communication Protocol [RFC5440] is designed to be flexible 119 and extensible in order to allow future evolutions or specific 120 constraint support such as proposed in [RFC7470]. Crossing different 121 PCE implementations (e.g. from different providers or due to 122 different 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-layer and multi-domain contexts. 136 Thus, extending such error codes and PCEP behaviors accordingly would 137 improve interoperability among different PCEP implementations and 138 would solve some of these issues. However, some of them would still 139 remain (e.g. the divergences in request treatment introduced by 140 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 TBD (Suggested 41). 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], [RFC8231], [RFC8232],[RFC8253], [RFC8281], 521 [RFC8306], [I-D.ietf-pce-lsp-setup-type], 522 [I-D.ietf-pce-association-group]). According to the definitions 523 provided in this document, the follwoing rules are applicable: 525 Error-type 1, described in [RFC5440], relates to PCEP session 526 establishement failures. All errors of this type are local (not 527 to be propagated). Hence, if a "Propagation" TLV is added to the 528 error message it MUST be set to value 0. Error-values 1,2,6,7 529 have a high level of criticality. Hence, if the "Error- 530 criticality" TLV is included within a PCErr message of type 1 and 531 value 1,2,6 or 7, it MUST have a value of 2. 533 Error-type 2,3,4, "Capability not supported", "Unknown object" and 534 "Not supported object" respectively, described in [RFC5440]: 535 errors of this type MAY be propagated using the TLV "Propagation". 536 Their level of criticality is defined as leading to cancel the 537 path computation request (cf. [RFC5440]). Hence, if the "Error- 538 criticality" TLV is included, it MUST have a value of 1. The 539 error-value 4 of error-type 4 ("Unsupported parameter") associated 540 to the BRPC procedure [RFC5441] SHOULD contain the "Propagation" 541 TLV with a DIFFUSION-LIST object requesting a propagation to the 542 PCC at the origin of the request. 544 Error-type 5 refers to "Policy violation", error values for this 545 type have been defined in [RFC5440], [RFC5541], [RFC5557], 546 [RFC5886] and [RFC6006]. In [RFC5440], it is specified that the 547 path computation request MUST be cancelled when an error of type 5 548 occurs. Hence, if the "Error-criticality" TLV is included, it 549 MUST have a value of 1. As such errors might be conveyed to 550 several PCEs, the "Propagation" TLV MAY be used. 552 Error-type 6 described as "Mandatory object missing" in [RFC5440], 553 leads to the cancellation of the path computation request. Hence, 554 if the "Error-criticality" TLV is included, it MUST have a value 555 of 1. The "Propagation" TLV MAY be used with such errors. The 556 error-value of 4 for Monitoring object missing defined in 557 [RFC5886] is no exception to the rule. 559 Error-type 7 is described as "synchronized path computation 560 request missing". In [RFC5440], it is specified that the reffered 561 synchronized path computation request MUST be cancelled when an 562 error of type 5 occurs. Hence, if the "Error-criticality" TLV is 563 included, it MUST have a value of 1. The "Propagation" TLV MAY be 564 used with such errors. 566 Error-type 8 is raised when a PCE receives a PCRep with an unknown 567 request reference. If the "Propagation" TLV is used with error- 568 type 8, it SHOULD be set at a value of 0. The "Error-criticality" 569 TLV is not particularly relevant for error-type 8. Hence, if it 570 used, it MUST have the value of 0. 572 Error-type 9 is raised when a PCE attempts to establish a second 573 PCEP session. The existing session must be preserved. Hence, if 574 the "Error-criticality" TLV is included, it MUST have a value of 575 0. By definition, such an error message SHOULD NOT be propagated. 576 Thus, if the "Propagation" TLV is used with error-type 9, it 577 SHOULD be set at a value of 0. 579 Error-type 10 which refers to the reception of an invalid object 580 as described in [RFC5440] no indication is provided on the 581 cancellation of the path computation request. Hence, if the 582 "Error-criticality" TLV is included, it MUST have a value of 0. 583 The "Propagation" TLV MAY be used with such errors with any value 584 depending on the expected behavior. 586 Error-type 11 relates to "Unrecognized EXRS subobject" and is 587 described in [RFC5521]. No path computation request cancellation 588 is required by [RFC5521]. Hence, if the "Error-criticality" TLV 589 is included, it MUST have a value of 0. The "Propagation" TLV MAY 590 be used with such errors with any value depending on the expected 591 behavior. 593 Error-type 12 refers to "Diffserv-aware TE error" and is described 594 in [RFC5455]. Such errors are raised when the CLASSTYPE object of 595 a PCReq is recognized but not supported by a PCE. [RFC5455] does 596 not state about the path computation request when such errors are 597 met. Hence, both "Propagation" and "Error-criticality" TLVs COULD 598 be used within such error-types' messages and set to any specified 599 values. 601 Error-type 13 on "BRPC procedure completion failure" is described 602 in [RFC5441]. [RFC5441] states that in such cases, the PCErr 603 message MUST be relayed to the PCC. Hence, such messages SHOULD 604 contain a "Propagation" TLV and a DIFFUSION-LIST object with a 605 Target-Type of 0 and corresponding adresses or with a Target-Type 606 of 2. It is not specified in [RFC5441] whether the path 607 computation request should be canceled or not. If the procedure 608 is not supported, it does not necessarily imply to cancel the path 609 computation request if another procedure is able to read and write 610 VSPT objects. Thus, the "Error-criticality" TLV MAY be used with 611 any value depending on the expected behavior. 613 Error-type 15 refers to "Global Concurrent Optimization Error" 614 defined in [RFC5557]. [RFC5557] states that the corresponding 615 global concurrent path optimization MUST be cancelled at the PCC. 616 Hence, if the "Error-criticality" TLV is included, it MUST have a 617 value of 1. The "Propagation" TLV MAY be used with such errors. 619 Error-type 16 relates to "P2MP Capability Error" defined in 620 [RFC6006]. Such errors lead to the cancellation of the path 621 computation request. Hence, if the "Error-criticality" TLV is 622 included, it MUST have a value of 1. The "Propagation" TLV MAY be 623 used with such errors. 625 Error-type 17, titled "P2MP END-POINTS Error" is defined 626 [RFC6006]. Such errors are thrown when a PCE tries to add or 627 prune nodes to or from a P2MP Tree. [RFC6006] does not specify if 628 such errors lead to cancel the path computation request. Hence, 629 the "Error-criticality" and "Propagation" TLVs MAY be used with 630 this type of error with any value depending on the expected 631 behavior. 633 Error-type 18 of "P2MP Fragmentation Error" is described [RFC6006] 634 which does not specify whether the path computation request should 635 be cancelled. But, as messages are fragmented, it is natural to 636 think that the PCE should wait at least a bit for further 637 messages. The "Error-criticality" TLV MAY be included in such 638 error messages and is particularly adapted to differ the semantic 639 of the same error-type message: if it is included with a value of 640 0 then the PCE will still wait for further fragmented messages, 641 when this waiting time ends, the TLV can be included with a value 642 of 1 in order to finally cancel the request. The "Propagation" 643 TLV MAY also be used with such errors. 645 Error-type 19 of "Invalid Operation" is described in [RFC8231] and 646 [RFC8281], which implies a wrong capability description for PCEP 647 session. In this case, the PCErr message MUST be returned to PCC, 648 and this message should contain a "Propagation" TLV and a 649 DIFFUSION-LIST object with a Target-Type of 0 or 2. The "Error- 650 criticality" TLV should be set to 2 in order to guanrantee the 651 termination of PCEP session. 653 Error-type 20 of "LSP State Synchronization Error" is described in 654 [RFC8231] and [RFC8232], which cannot successfully sync up the LSP 655 states. In this case, the "Error-criticality" TLV should be set 656 to 2 in order to guanrantee the termination of PCEP session. The 657 "Propagation" TLV MAY also be used with such errors. 659 Error-type 21 of "Invalid traffic engineering path setup type" is 660 described in [I-D.ietf-pce-lsp-setup-type] . Such errors failed to 661 find a matched path setup type and the PCEP sessions MUST be 662 closed. In this case, the "Error-criticality" TLV should be set 663 to 2 in order to guanrantee the termination of PCEP session. The 664 "Propagation" TLV MAY also be used with such errors. 666 Error-type 23 of "Bad parameter value" is described in [RFC8281] . 667 Such errors occur when there is a conflict in path name of C flag 668 not set for PCE initiation. In this case, the "Error-criticality" 669 TLV may be set to either 0 or 1 to indicate whether the request is 670 still valid, with the PCEP session open. The "Propagation" TLV 671 MAY also be used with such errors. 673 Error-type 24 of "LSP instantiation error" is described in 674 [RFC8281] . Such errors occur when PCC detects problems when 675 establishing the path, the message MUST relay to the PCE, 676 therefore the "Propogation" TLV must be contained. The "Error- 677 criticality" TLV may be set to either 0 or 1 to indicate whether 678 the request is still valid, with the PCEP session open. 680 Error-type 25 of "PCEP StartTLS failure" is described in 681 [RFC8253]. Such errors indicate the security issue in transport 682 layer. In this case, the "Error-criticality" TLV should be set to 683 2 in order to close the PCEP session. The "Propagation" TLV MAY 684 also be used with such errors, depending on the detailed security 685 conditions. 687 Error-type 26 of "Association Error " is described in 688 [I-D.ietf-pce-association-group] . Such errors occur when there is 689 problem for LSP association. In this case, the "Error- 690 criticality" TLV should be set to either 0 or 1 to indicate 691 whether the request is still valid, with the PCEP session open. 692 The "Propagation" TLV MAY also be used with such errors. 694 Among the existing normative references, only the [RFC5440] defines 695 some notification-types and values. The recommendations with respect 696 to the TLVs definitions provided in this document are the followings: 698 Notitification-type=1, Notification-value=1 or 2: a PCC, 699 respectively a PCE, cancels a set of pending requests, such a 700 notification SHOULD be propagated to the list of PCEP peers which 701 were implied in the path computation requests. Hence, the 702 NOTIFICATION object SHOULD contains the "Propagation" TLV with 703 value 1 and the "Notification Type" TLV with value 1, together 704 with a DIFFUSION-LIST object containing the list of PCEP peers. 706 Notitification-type=2, Notification-value=1 or 2: indicates to the 707 PCC that the PCE is, respectively is no longer, in an overloaded 708 state. Such a notification can be propagated or stay local. It 709 is therefore RECOMMENDED to specify this behavior using the 710 "Propagation" TLV and associated restriction mechanims. 712 6. Error and Notification Scenarios 714 This section provides some examples depicting how the error and 715 notification types described above can be used in a PCEP session. 716 The origin of the errors or notifications is only illustrative and 717 has no normative purpose. Sometimes the PCE features behind may be 718 implementation-specific (e.g. detection of flooding). This section 719 does not provide scenarios for errors with a high-level of critcity 720 (i.e., Error behaviors 3 and 6) since such errors are very specific 721 and until now have been normalized only during the session 722 establishment (error-type of 1). 724 6.1. Error Behavior Type 1 726 In this example, a PCC attempts to establish a second PCEP session 727 with the same PCE for another request. Consequently the PCE sends 728 back an error message with error-type 9. This error stays local and 729 does not affect the former session. The second session is ignored. 730 If the "Propagation" TLV and "Error-criticality" TLV are used, they 731 should be both set to value 0. 733 +-+-+ +-+-+ 734 |PCC| |PCE| 735 +-+-+ +-+-+ 736 1) Path computation | | 737 event | | 738 2) PCE selection |----- Open Message--->| 739 |<--- Open message ----| 740 3) Path computation |---- PCReq message--->| 741 request X sent to | |4) Path computation 742 the selected PCE | | request queued 743 | | 744 5) Path computation | | 745 event | | 746 6) PCE selection | | 747 |----- Open Message--->|8) Session already 748 | |opened 749 |<--- PCErr message----| Error-type=9 750 | | 752 6.2. Error Behavior Type 2 754 In this example, the PCC sends a DiffServ-aware path computation 755 request. If the PCE receiving the request does not support the 756 indicated class-type, it thus sends back a PCErr message with error- 757 type=12 and error-value=1. If the "Propagation" TLV and "Error- 758 criticality" TLV are present, they should carry value 0 and value 1 759 respectively. Consequently, the request is cancelled. 761 +-+-+ +-+-+ 762 |PCC| |PCE| 763 +-+-+ +-+-+ 764 1) Path computation | | 765 event | | 766 2) PCE selection | | 767 3) Path computation |---- PCReq message--->| 768 request X sent to | |4) Path computation 769 the selected PCE | | request queued 770 | | 771 | |5) DiffServ class-type 772 | | not supported 773 | |6) Path computation 774 | | request X 775 | | cancelled 776 |<--- PCErr message----| Error-type=12 777 | | 779 6.3. Error Behavior Type 4 781 In this example, a PCC sends a path computation requests with no P 782 flag set (e.g. END-POINT object with P-flag cleared). This is 783 detected by another PCE in the sequence. The path computation 784 request can thus be treated but the P-Flag will be ignored. Hence, 785 this error is not critical but the source PCC should be informed of 786 this fact. So, a PCErr message with error-type 10 ("Reception of an 787 invalid object"). The PCEP-ERROR object of the message contains a 788 "Propagation" TLV at value 1 and a "Error-criticality" TLV at value 789 0. It is hence propagated backwardly to the source PCC. 791 +-+-+ +-+-+-+-+ +-+-+ 792 |PCC| |PCE|PCC| |PCE| 793 +-+-+ +-+-+-+-+ +-+-+ 794 |---- PCReq message-->| | 795 | | | 796 | |---- PCReq message--->| 797 | | | 798 | | |1) Parameter is 799 | | | not supported 800 | | | 801 | |<--- PCErr message----| Error-type=10 802 |<--- PCErr message---| | 803 | | | 805 6.4. Error Behavior Type 5 807 In this example, PCEs are using the BRPC procedure to treat a path 808 computation request [RFC5441]. However, one of the PCEs does not 809 support a parameter of the request. Hence, a PCErr message with 810 error-type 4 and error-value 4 is sent by this PCE and has to be 811 forwarded to the source PCC. The PCEP-ERROR object includes a 812 "Propagation" TLV at value 1 and "Error-criticality" TLV at value 1 813 and the message is propagated backwardly to the source PCC. 814 Consequently, the request is cancelled. 816 +-+-+ +-+-+-+-+ +-+-+ 817 |PCC| |PCE|PCC| |PCE| 818 +-+-+ +-+-+-+-+ +-+-+ 819 |---- PCReq message-->| | 820 | | | 821 | |---- PCReq message--->| 822 | | | 823 | | |1) Unsupported 824 | | | Parameter BRPC 825 | | |2) Path 826 | | | computation 827 | | | request X 828 | | | cancelled 829 | |<--- PCErr message----| Error-type=4 830 |<--- PCErr message---| | 831 | | | 833 6.5. Notification Behavior Type 1 835 In this example, a PCE sends a non request-specific notification 836 indicating that, due to multiple sendings (or for other reasons), 837 further requests from this PCC will be ignored. Hence, a PCNtf 838 message is sent to the PCC with a NOTIFICATION object including the 839 "Propagation" TLV at value 0 and a "Notification Type" TLV at value 840 0. 842 +-+-+ +-+-+ 843 |PCC| |PCE| 844 +-+-+ +-+-+ 845 | | 846 | |1) Further requests 847 | | will be ignored 848 | | 849 |<--- PCNtf message----| 850 | | 852 6.6. Notification Behavior Type 2 854 In this example, a PCE sends a request-specific notification 855 indicating that, a set of pending requests are cancelled (e.g. 856 notification-type=1, notification-value=1 as described in [RFC5440]). 857 Hence, a PCNtf message is sent to the PCC with a NOTIFICATION object 858 including a "Propagation" TLV at value 0 and a "Notification Type" 859 TLV at value 1. 861 +-+-+ +-+-+ 862 |PCC| |PCE| 863 +-+-+ +-+-+ 864 1) Path computation | | 865 event | | 866 2) PCE selection | | 867 3) Path computation |---- PCReq message--->| 868 request X sent to | |4) Path 869 the selected PCE | | computation 870 | | request queued 871 | | 872 | |5) Pending requests 873 | | cancelled 874 | | 875 |<--- PCNtf message----|Notification-Type=1 876 | | 878 6.7. Notification Behavior Type 3 880 In this example, a PCE is temporarily congested. A PCNtf message 881 with a NOTIFICATION object containing a "Propagation" TLV at value 1 882 and a "Notification Type" TLV at value 0 is send to a PCEP peer. 883 This notification messge is propagated to a sequence of PCEs if 884 necessary. Here, PCEk is congested and send a PCNtf message to PCEi 885 with the approapriate TLVs, an OVERLOAD object as described in 886 [RFC5886], and a DIFFUSION-LIST object indicating PCEj as a target of 887 the notification. 889 +-+--+ +-+--+ +-+--+ 890 |PCEj| |PCEi| |PCEk| 891 +-+--+ +-+--+ +-+--+ 892 | | | 893 | | |1)PCE is busy 894 | | | for M minutes 895 | | | (time-out update) 896 | |<--- PCNtf message----| Notification-type=2 897 |<--- PCNtf message---| | 899 6.8. Notification Behavior Type 4 901 In this example, a PCE receives a request but it is temporarily 902 congested. However, it can treat the request after few minutes which 903 might cause some time-out in the predecessor PCE(s). Hence, a PCNtf 904 message with a NOTIFICATION object containing a "Propagation" TLV at 905 value 1 and a "Notification Type" TLV at value 1 is sent to the PCC 906 and propagated backwardly in the sequence. Such a notification could 907 include an OVERLOAD object as described in [RFC5886]. 909 +-+-+ +-+-+-+-+ +-+-+ 910 |PCC| |PCE|PCC| |PCE| 911 +-+-+ +-+-+-+-+ +-+-+ 912 |---- PCReq message-->| | 913 | | | 914 | |---- PCReq message--->| 915 | | | 916 | | |1)PCE is busy but 917 | | | will answer to X 918 | | | in M minutes 919 | | | (time-out update) 920 | |<--- PCNtf message----| Notification-type=2 921 |<--- PCNtf message---| | 923 7. Security Considerations 925 Within the introduced set of TLVs, the "Propagation" TLV affects PCEP 926 security considerations since it forces propagation behaviors. Thus, 927 a PCEP implementation SHOULD activate stateful mechanism when 928 receiving PCEP-ERROR or NOTIFICATION object including this TLV in 929 order to avoid DoS attacks. 931 8. IANA Considerations 933 IANA maintains a registry of PCEP parameters. This includes a sub- 934 registry for PCEP Objects. 936 IANA is requested to make an allocation from the sub-registry as 937 follows. The values here are suggested for use by IANA. 939 8.1. PCEP TLV Type Indicators 941 As described in Section 5.5 the newly defined TLVs allows a PCE to 942 enforce specific error and notification behaviors within PCEP-ERROR 943 and NOTIFICATION objects. IANA is requested to make the following 944 allocations from the "PCEP TLV Type Indicators" sub-registry. 946 Value Description Reference 947 TBD(suggest 33) Propagation this document 949 TBD(suggest 34) Error-criticality this document 951 TBD(suggest 35) Notification type this document 953 8.2. New DLO object 954 Object-class Value Object-Type and Name Reference 955 TBD(suggest 41) 1: Diffusion list object this document 957 Target-Type Value Meaning Reference 958 0 Any PCEP peers this document 960 1 PCEs but excludes 961 PCC-only peers this document 963 2 PCEs and PCCs this document 964 with which a session 965 is still opened 967 Subobjects Reference 968 1: IPv4 prefix this document 969 2: IPv6 prefix this document 970 4: Unnumbered Interface ID this document 971 5: OSPF Area ID this document 972 32: Autonomous system number this document 973 33: Explicit Exclusion Route subobject (EXRS) this document 975 9. References 977 9.1. Normative References 979 [I-D.ietf-pce-association-group] 980 Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 981 Dhody, D., and Y. Tanaka, "PCEP Extensions for 982 Establishing Relationships Between Sets of LSPs", draft- 983 ietf-pce-association-group-04 (work in progress), August 984 2017. 986 [I-D.ietf-pce-lsp-setup-type] 987 Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 988 Hardwick, "Conveying path setup type in PCEP messages", 989 draft-ietf-pce-lsp-setup-type-08 (work in progress), 990 January 2018. 992 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 993 Requirement Levels", BCP 14, RFC 2119, 994 DOI 10.17487/RFC2119, March 1997, 995 . 997 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 998 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 999 DOI 10.17487/RFC5440, March 2009, 1000 . 1002 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 1003 "A Backward-Recursive PCE-Based Computation (BRPC) 1004 Procedure to Compute Shortest Constrained Inter-Domain 1005 Traffic Engineering Label Switched Paths", RFC 5441, 1006 DOI 10.17487/RFC5441, April 2009, 1007 . 1009 [RFC5455] Sivabalan, S., Ed., Parker, J., Boutros, S., and K. 1010 Kumaki, "Diffserv-Aware Class-Type Object for the Path 1011 Computation Element Communication Protocol", RFC 5455, 1012 DOI 10.17487/RFC5455, March 2009, 1013 . 1015 [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the 1016 Path Computation Element Communication Protocol (PCEP) for 1017 Route Exclusions", RFC 5521, DOI 10.17487/RFC5521, April 1018 2009, . 1020 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 1021 Objective Functions in the Path Computation Element 1022 Communication Protocol (PCEP)", RFC 5541, 1023 DOI 10.17487/RFC5541, June 2009, 1024 . 1026 [RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path 1027 Computation Element Communication Protocol (PCEP) 1028 Requirements and Protocol Extensions in Support of Global 1029 Concurrent Optimization", RFC 5557, DOI 10.17487/RFC5557, 1030 July 2009, . 1032 [RFC5886] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of 1033 Monitoring Tools for Path Computation Element (PCE)-Based 1034 Architecture", RFC 5886, DOI 10.17487/RFC5886, June 2010, 1035 . 1037 [RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T., 1038 Ali, Z., and J. Meuric, "Extensions to the Path 1039 Computation Element Communication Protocol (PCEP) for 1040 Point-to-Multipoint Traffic Engineering Label Switched 1041 Paths", RFC 6006, DOI 10.17487/RFC6006, September 2010, 1042 . 1044 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1045 Computation Element Communication Protocol (PCEP) 1046 Extensions for Stateful PCE", RFC 8231, 1047 DOI 10.17487/RFC8231, September 2017, 1048 . 1050 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 1051 and D. Dhody, "Optimizations of Label Switched Path State 1052 Synchronization Procedures for a Stateful PCE", RFC 8232, 1053 DOI 10.17487/RFC8232, September 2017, 1054 . 1056 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1057 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1058 Path Computation Element Communication Protocol (PCEP)", 1059 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1060 . 1062 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1063 Computation Element Communication Protocol (PCEP) 1064 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1065 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1066 . 1068 [RFC8306] Zhao, Q., Dhody, D., Ed., Palleti, R., and D. King, 1069 "Extensions to the Path Computation Element Communication 1070 Protocol (PCEP) for Point-to-Multipoint Traffic 1071 Engineering Label Switched Paths", RFC 8306, 1072 DOI 10.17487/RFC8306, November 2017, 1073 . 1075 9.2. Informational References 1077 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1078 Element (PCE)-Based Architecture", RFC 4655, 1079 DOI 10.17487/RFC4655, August 2006, 1080 . 1082 [RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific 1083 Constraints in the Path Computation Element Communication 1084 Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015, 1085 . 1087 Authors' Addresses 1088 Helia Pouyllau 1089 Alcatel-Lucent 1090 Route de Villejust 1091 NOZAY 91620 1092 FRANCE 1094 Phone: + 33 (0)1 30 77 63 11 1095 Email: helia.pouyllau@alcatel-lucent.com 1097 Remi Theillaud 1098 Marben Products 1099 176 rue Jean Jaures 1100 Puteaux 92800 1101 FRANCE 1103 Phone: + 33 (0)1 79 62 10 22 1104 Email: remi.theillaud@marben-products.com 1106 Julien Meuric 1107 France Telecom Orange 1108 2, avenue Pierre Marzin 1109 Lannion 22307 1110 FRANCE 1112 Email: julien.meuric@orange-ftgroup.com 1114 Haomian Zheng (Editor) 1115 Huawei Technologies 1116 F3-1B, Huawei Industrial Base, Bantian, Longgang District 1117 Shenzhen, Guangdong 518129 1118 P.R.China 1120 Email: zhenghaomian@huawei.com 1122 Xian Zhang 1123 Huawei Technologies 1124 G1-2, Huawei Industrial Base, Bantian, Longgang District 1125 Shenzhen, Guangdong 518129 1126 P.R.China 1128 Email: zhang.xian@huawei.com