idnits 2.17.1 draft-ietf-pce-gmpls-pcep-extensions-10.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 : ---------------------------------------------------------------------------- == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1262 has weird spacing: '...ded bit routi...' -- The document date (October 06, 2014) is 3483 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'I-D.ietf-pce-pceps' is mentioned on line 1613, but not defined == Outdated reference: A later version (-12) exists of draft-ietf-pce-inter-layer-ext-08 == Outdated reference: A later version (-15) exists of draft-ietf-pce-wson-routing-wavelength-13 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Margaria, Ed. 3 Internet-Draft 4 Intended status: Standards Track O. Gonzalez de Dios, Ed. 5 Expires: April 9, 2015 Telefonica Investigacion y Desarrollo 6 F. Zhang, Ed. 7 Huawei Technologies 8 October 06, 2014 10 PCEP extensions for GMPLS 11 draft-ietf-pce-gmpls-pcep-extensions-10 13 Abstract 15 This memo provides extensions for the Path Computation Element 16 communication Protocol (PCEP) for the support of GMPLS control plane. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 9, 2015. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Contributing Authors . . . . . . . . . . . . . . . . . . 3 54 1.2. PCEP requirements for GMPLS . . . . . . . . . . . . . . . 3 55 1.3. Current GMPLS support and limitation of existing PCEP 56 objects . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 5 58 2. PCEP objects and extensions . . . . . . . . . . . . . . . . . 6 59 2.1. GMPLS capability advertisement . . . . . . . . . . . . . 6 60 2.1.1. GMPLS Computation TLV in the Existing PCE Discovery 61 Protocol . . . . . . . . . . . . . . . . . . . . . . 6 62 2.1.2. OPEN Object extension GMPLS-CAPABILITY TLV . . . . . 6 63 2.2. RP object extension . . . . . . . . . . . . . . . . . . . 7 64 2.3. BANDWIDTH object extensions . . . . . . . . . . . . . . . 7 65 2.4. LOAD-BALANCING object extensions . . . . . . . . . . . . 9 66 2.5. END-POINTS Object extensions . . . . . . . . . . . . . . 12 67 2.5.1. Generalized Endpoint Object Type . . . . . . . . . . 13 68 2.5.2. END-POINTS TLVs extensions . . . . . . . . . . . . . 16 69 2.6. IRO extension . . . . . . . . . . . . . . . . . . . . . . 19 70 2.7. XRO extension . . . . . . . . . . . . . . . . . . . . . . 20 71 2.8. LSPA extensions . . . . . . . . . . . . . . . . . . . . . 21 72 2.9. NO-PATH Object Extension . . . . . . . . . . . . . . . . 22 73 2.9.1. Extensions to NO-PATH-VECTOR TLV . . . . . . . . . . 22 74 3. Additional Error Type and Error Values Defined . . . . . . . 23 75 4. Manageability Considerations . . . . . . . . . . . . . . . . 24 76 4.1. Control of Function through Configuration and Policy . . 25 77 4.2. Information and Data Models . . . . . . . . . . . . . . . 25 78 4.3. Liveness Detection and Monitoring . . . . . . . . . . . . 25 79 4.4. Verifying Correct Operation . . . . . . . . . . . . . . . 25 80 4.5. Requirements on Other Protocols and Functional Components 26 81 4.6. Impact on Network Operation . . . . . . . . . . . . . . . 26 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 83 5.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 26 84 5.2. END-POINTS object, Object Type Generalized Endpoint . . . 27 85 5.3. New PCEP TLVs . . . . . . . . . . . . . . . . . . . . . . 28 86 5.4. RP Object Flag Field . . . . . . . . . . . . . . . . . . 29 87 5.5. New PCEP Error Codes . . . . . . . . . . . . . . . . . . 29 88 5.6. New NO-PATH-VECTOR TLV Fields . . . . . . . . . . . . . 30 89 5.7. New Subobject for the Include Route Object . . . . . . . 31 90 5.8. New Subobject for the Exclude Route Object . . . . . . . 31 91 6. Security Considerations . . . . . . . . . . . . . . . . . . . 31 92 7. Contributing Authors . . . . . . . . . . . . . . . . . . . . 33 93 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 95 9.1. Normative References . . . . . . . . . . . . . . . . . . 34 96 9.2. Informative References . . . . . . . . . . . . . . . . . 36 97 9.3. Experimental References . . . . . . . . . . . . . . . . . 37 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 101 1. Introduction 103 Although [RFC4655] defines the PCE architecture and framework for 104 both MPLS and GMPLS networks, current PCEP RFCs [RFC5440], [RFC5521], 105 [RFC5541], [RFC5520] are focused on MPLS networks, and do not cover 106 the wide range of GMPLS networks. This document complements these 107 RFCs by addressing the extensions required for GMPLS applications and 108 routing requests, for example for OTN and WSON networks. 110 The functional requirements to be considered by the PCEP extensions 111 to support those application are described in [RFC7025] and 112 [I-D.ietf-pce-wson-routing-wavelength]. 114 1.1. Contributing Authors 116 Elie Sfeir, Franz Rambach (Nokia Siemens Networks) Francisco Javier 117 Jimenez Chico (Telefonica Investigacion y Desarrollo) Suresh BR, 118 Young Lee, SenthilKumar S, Jun Sun (Huawei Technologies), Ramon 119 Casellas (CTTC) 121 1.2. PCEP requirements for GMPLS 123 The document [RFC7025] describes the set of PCEP requirements to 124 support GMPLS TE-LSPs. When a PCC requests a PCE to perform a path 125 computation (by means of a PCReq message), the PCC should be able to 126 indicate the following additional information: 128 o Which data flow is switched by the LSP: a combination of Switching 129 type (for instance L2SC or TDM), LSP Encoding type (e.g., 130 Ethernet, SONET/SDH) and sometimes the Signal Type (e.g. in case 131 of TDM/LSC switching capability) 133 o Data flow specific traffic parameters, which are technology 134 specific. For instance, in SDH/SONET and G.709 OTN networks the 135 Concatenation Type and the Concatenation Number have an influence 136 on the switched data and on which link it can be supported 138 o Support for asymmetric bandwidth requests. 140 o Support for unnumbered interface identifiers, as defined in 141 [RFC3477] 143 o Label information and technology specific label(s) such as 144 wavelength labels as defined in [RFC6205]. A PCC should also be 145 able to specify a Label restriction similar to the one supported 146 by RSVP-TE (Resource Reservation Protocol - Traffic Engineering). 148 o Ability to indicate the requested granularity for the path ERO: 149 node, link or label. This is to allow the use of the explicit 150 label control feature of RSVP-TE. 152 We describe in this document a set of PCEP protocol extensions, 153 including new object types, TLVs, encodings, error codes and 154 procedures, in order to fulfill the aforementioned requirements. 156 1.3. Current GMPLS support and limitation of existing PCEP objects 158 PCEP as of [RFC5440], [RFC5521] and [I-D.ietf-pce-inter-layer-ext], 159 supports the following objects, included in requests and responses 160 related to the described requirements. 162 From [RFC5440]: 164 o END-POINTS: only numbered endpoints are considered. The context 165 specifies whether they are node identifiers or numbered 166 interfaces. 168 o BANDWIDTH: the data rate is encoded in the bandwidth object (as 169 IEEE 32 bit float). [RFC5440] does not include the ability to 170 convey an encoding proper to any GMPLS networks. 172 o ERO : Unnumbered endpoints are supported. 174 o LSPA: LSP attributes (setup and holding priorities) 176 From [RFC5521] : 178 o XRO object : 180 * This object allows excluding (strict or not) resources, and 181 includes the requested diversity (node, link or SRLG). 183 * When the F bit is set, the request indicates that the existing 184 route has failed and the resources present in the RRO can be 185 reused. 187 From [I-D.ietf-pce-inter-layer-ext]: 189 o INTER-LAYER : indicates whether inter-layer computation is allowed 191 o SWITCH-LAYER : indicates which layer(s) should be considered, can 192 be used to represent the RSVP-TE generalized label request 194 o REQ-ADAP-CAP : indicates the adaptation capabilities requested, 195 can also be used for the endpoints in case of mono-layer 196 computation 198 The shortcomings of the existing PCEP object are: 200 The BANDWIDTH and LOAD-BALANCING objects do not describe the 201 details of the traffic request (for example NVC, multiplier) in 202 the context of GMPLS networks, for instance TDM or OTN networks. 204 The END-POINTS object does not allow specifying an unnumbered 205 interface, nor potential label restrictions on the interface. 206 Those parameters are of interest in case of switching constraints. 208 The IRO/XRO objects do not allow the inclusion/exclusion of labels 210 Current attributes do not allow expressing the requested link 211 protection level and/or the end-to-end protection attributes. 213 The covered PCEP extensions are: 215 Two new object types are introduced for the BANDWIDTH 216 object(Generalized-Bandwidth, Generalized Bandwidth of existing 217 TE-LSP). 219 A new object type is introduced for the LOAD-BALANCING object 220 (Generalized LOAD-BALANCING). 222 A new object type is introduced for the END-POINTS object 223 (GENERALIZED-ENDPOINT). 225 A new TLV is added to the OPEN message for capability negotiation. 227 A new TLV is added to the LSPA object. 229 A new TLV type for label is allowed in IRO and XRO objects. 231 In order to indicate the used routing granularity in the response, 232 a new flag in the RP object is added. 234 1.4. Requirements Language 236 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 237 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 238 document are to be interpreted as described in RFC 2119 [RFC2119]. 240 2. PCEP objects and extensions 242 This section describes the required PCEP objects and extensions. The 243 PCReq and PCRep messages are defined in [RFC5440]. This document 244 does not change the existing grammars 246 2.1. GMPLS capability advertisement 248 2.1.1. GMPLS Computation TLV in the Existing PCE Discovery Protocol 250 IGP-based PCE Discovery (PCED) is defined in [RFC5088] and [RFC5089] 251 for the OSPF and IS-IS protocols. Those documents have defined bit 0 252 in PCE-CAP-FLAGS Sub-TLV of the PCED TLV as "Path computation with 253 GMPLS link constraints". This capability can be used to detect 254 GMPLS-capable PCEs. 256 2.1.2. OPEN Object extension GMPLS-CAPABILITY TLV 258 In addition to the IGP advertisement, a PCEP speaker should be able 259 to discover the other peer GMPLS capabilities during the Open message 260 exchange. This capability is also useful to avoid misconfigurations. 261 This document defines a new optional GMPLS-CAPABILITY TLV for use in 262 the OPEN object to negotiate the GMPLS capability. The inclusion of 263 this TLV in the OPEN message indicates that the PCC/PCE support the 264 PCEP extensions defined in the document. A PCE that is able to 265 support the GMPLS extensions defined in this document SHOULD include 266 the GMPLS-CAPABILITY TLV on the OPEN message. If the PCE does not 267 include the GMPLS-CAPABILITY TLV in the OPEN message and PCC does 268 include the TLV, it is RECOMMENDED that the PCC indicates a mismatch 269 of capabilities. Moreover , in case that the PCC does not receive 270 the GMPLS-CAPABILITY TLV it is RECOMMENDED that the PCC does not make 271 use of the objects and TLVs defined in this document. 273 IANA has allocated value TBA from the "PCEP TLV Type Indicators" sub- 274 registry, as documented in Section 5.3 ("New PCEP TLVs"). The 275 description is "GMPLS-CAPABILITY". Its format is shown in the 276 following figure. 278 0 1 2 3 279 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 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Type=14 | Length | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Flags | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 No Flags are defined in this document, they are reserved for future 287 use. 289 2.2. RP object extension 291 Explicit label control (ELC) is a procedure supported by RSVP-TE, 292 where the outgoing label(s) is(are) encoded in the ERO. In 293 consequence, the PCE may be able to provide such label(s) directly in 294 the path ERO. The PCC, depending on policies or switching layer, may 295 be required to use explicit label control or expect explicit link, 296 thus it need to indicate in the PCReq which granularity it is 297 expecting in the ERO. This correspond to requirement 12 of [RFC7025] 298 The possible granularities can be node, link or label. The 299 granularities are inter-dependent, in the sense that link granularity 300 implies the presence of node information in the ERO; similarly, a 301 label granularity implies that the ERO contains node, link and label 302 information. 304 A new 2-bit routing granularity (RG) flag is defined in the RP 305 object. The values are defined as follows 307 0 : reserved 308 1 : node 309 2 : link 310 3 : label 312 The flag in the RP object indicates the requested route granularity. 313 The PCE MAY try to follow this granularity and MAY return a NO-PATH 314 if the requested granularity cannot be provided. The PCE MAY return 315 any granularity it likes on the route based on its policy. The PCC 316 can decide if the ERO is acceptable based on its content. 318 If a PCE honored the requested routing granularity for a request, it 319 MUST indicate the selected routing granularity in the RP object 320 included in the response. Otherwise, the PCE MAY use the reserved RG 321 to leave the check of the ERO to the PCC. The RG flag is backward- 322 compatible with [RFC5440]: the value sent by an implementation (PCC 323 or PCE) not supporting it will indicate a reserved value. 325 2.3. BANDWIDTH object extensions 327 From [RFC5440] the object carrying the request size for the TE-LSP is 328 the BANDWIDTH object. The object types 1 and 2 defined in [RFC5440] 329 do not describe enough information to describe the TE-LSP bandwidth 330 in GMPLS networks. The BANDWIDTH object encoding should be extended 331 to allow to express the bandwidth as described in [RFC7025]. RSVP-TE 332 extensions for GMPLS provide a set of encoding allowing such 333 representation in an unambiguous way, this is encoded in the RSVP-TE 334 TSpec and FlowSpec objects. This document extends the BANDIDTH 335 object with new object types reusing the RSVP-TE encoding. 337 The following possibilities should be supported by the new encoding : 339 o Asymmetric bandwidth (different bandwidth in forward and reverse 340 direction), as described in [RFC6387] 342 o GMPLS (SDH/SONET, G.709, ATM, MEF etc) parameters. 344 This correspond to requirement 3, 4, 5 and 11 of [RFC7025] section 345 3.1. 347 This document defines two Object Types for the BANDWIDTH object: 349 TBA Requested generalized bandwidth 351 TBA Generalized bandwidth of an existing TE LSP for which a 352 reoptimization is requested 354 The definitions below apply for Object Type TBA and TBA. The payload 355 is as follows: 357 0 1 2 3 358 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 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Bandwidth Spec Length | Rev. Bandwidth Spec Length | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Bw Spec Type | Reserved | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | | 365 ~ generalized bandwidth ~ 366 | | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | | 369 ~ Optional : reverse generalized bandwidth ~ 370 | | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | | 373 ~ Optional TLVs ~ 374 | | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 The BANDWIDTH object type TBA and TBA have a variable length. The 16 378 bit bandwidth spec length field indicates the length of the bandwidth 379 spec field. The bandwidth spec length MUST be strictly greater than 380 0. The 16 bit reverse bandwidth spec length field indicates the 381 length of the reverse bandwidth spec field. The reverse bandwidth 382 spec length MAY be equal to 0. 384 The Bw Spec Type field determines which type of bandwidth is 385 represented by the object. 387 The Bw Spec Type correspond to the RSVPT-TE SENDER_TSPEC (Object 388 Class 12) C-Types 390 The encoding of the field generalized bandwidth and reverse 391 generalized bandwidth is the same as in RSVP-TE, it can be found in 392 the following references. 394 Object Type Name Reference 396 2 Intserv [RFC2210] 397 4 SONET/SDH [RFC4606] 398 5 G.709 [RFC4328] 399 6 Ethernet [RFC6003] 401 Traffic Spec field encoding 403 When a PCC requests a bi-directional path with symetric bandwidth, it 404 MUST specify the generalized bandwidth field, MUST NOT specify the 405 reverse generalized bandwidth and MUST set the Reverse Bandwidth Spec 406 Length to 0. When a PCC needs to request a bi-directional path with 407 asymmetric bandwidth, it SHOULD specify the different bandwidth in 408 the forward and reverse directions with a generalized bandwidth and 409 reverse generalized bandwidth fields. 411 The procedures described in [RFC5440] for the PCRep is unchanged, a 412 PCE MAY include the BANDWIDTH objects in the response to indicate the 413 BANDWIDTH of the path 415 As specified in [RFC5440] in the case of the reoptimization of a TE 416 LSP, the bandwidth of the existing TE LSP MUST also be included in 417 addition to the requested bandwidth if and only if the two values 418 differ. The Object Type TBA MAY be used instead of object type 2 to 419 indicate the existing TE-LSP bandwidth. A PCC that requested a path 420 with a BANDWIDTH object of object type 1 SHOULD use object type 2 to 421 represent the existing TE-LSP BANDWIDTH. 423 Optional TLVs may be included within the object body to specify more 424 specific bandwidth requirements. No TLVs for the Object Type TBA and 425 TBA are defined by this document. 427 2.4. LOAD-BALANCING object extensions 429 The LOAD-BALANCING object [RFC5440] is used to request a set of 430 maximum Max-LSP TE-LSP having in total the bandwidth specified in 431 BANDWIDTH, each TE-LSP having a minimum of bandwidth. The LOAD- 432 BALANCING follows the bandwidth encoding of the BANDWIDTH object, and 433 thus the existing definition from [RFC5440] does not describe enough 434 details for the bandwidth specification expected by GMPLS. A PCC 435 should be allowed to request a set of TE-LSP also in case of GMPLS 436 bandwidth specification. 438 The LOAD-BALANCING has the same limitation as the BANDWIDTH for GMPLS 439 networks. Similarly to the BANDWIDTH object a new object type is 440 defined to allow a PCC to represent the bandwidth types supported by 441 GMPLS networks. 443 This document defines the generalized load balancing object type TBA 444 for the LOAD-BALANCING object. The generalized load balancing object 445 type has a variable length. 447 The format of the generalized load balancing object type is as 448 follows: 450 0 1 2 3 451 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 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Bandwidth spec length | Reverse Bandwidth spec length | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Bw Spec Type | Max-LSP | Reserved | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Min Bandwidth Spec | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Min reverse Bandwidth Spec (optional) | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | | 462 ~ Optional TLVs ~ 463 | | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 Bandwidth spec length (16 bits): the total length of the min 467 bandwidth specification. It should be noted that the RSVP-TE traffic 468 specification may also include TLV different than the PCEP TLVs. The 469 length MUST be strictly greater than 0. 471 Reverse bandwidth spec length (16 bits): the total length of the 472 reverse min bandwidth specification. It MAY be equal to 0. 474 Bw Spec Type (8 bits) : the bandwidth specification type, it 475 correspond to the RSVPT-TE SENDER_TSPEC (Object Class 12) C-Types 477 Max-LSP (8 bits): maximum number of TE LSPs in the set. 479 Min Bandwidth spec (variable): Specifies the minimum bandwidth spec 480 of each element of the set of TE LSPs. 482 Min Reverse Bandwidth spec (variable): Specifies the minimum reverse 483 bandwidth spec of each element of the set of TE LSPs. 485 The encoding of the field Min Bandwidth Spec and Min Reverse 486 Bandwidth spec is the same as in RSVP-TE SENDER_TSPEC object, it can 487 be found in the following references. 489 Object Type Name Reference 491 2 Intserv [RFC2210] 492 4 SONET/SDH [RFC4606] 493 5 G.709 [RFC4328] 494 6 Ethernet [RFC6003] 496 Traffic Spec field encoding 498 When a PCC requests a bi-directional path with symetric bandwidth 499 while specifying load balancing constraints it MUST specify the min 500 Bandwidth spec field, MUST NOT specify the min reverse bandwidth and 501 MUST set the Reverse Bandwidth spec length to 0. When a PCC needs to 502 request a bi-directional path with asymmetric bandwidth while 503 specifying load balancing constraints, it SHOULD specify the 504 different bandwidth in forward and reverse directions through a min 505 Bandwidth spec and min reverse bandwidth fields. 507 Optional TLVs may be included within the object body to specify more 508 specific bandwidth requirements. No TLVs for the generalized load 509 balancing object type are defined by this document. 511 The semantic of the LOAD-BALANCING object is not changed. If a PCC 512 requests the computation of a set of TE LSPs so that the total of 513 their generalized bandwidth is X, the maximum number of TE LSPs is N, 514 and each TE LSP must at least have a bandwidth of B, it inserts a 515 BANDWIDTH object specifying X as the required bandwidth and a LOAD- 516 BALANCING object with the Max-LSP and Min-traffic spec fields set to 517 N and B, respectively. 519 For example a request for one co-signaled n x VC-4 TE-LSP will not 520 use the LOAD-BALANCING. In case the V4 components can use different 521 paths, the BANDWIDTH with object type 3 will contain a traffic 522 specification indicating the complete n x VC4 traffic specification 523 and the LOAD-BALANCING the minimum co-signaled VC4. For a SDH 524 network, a request to have a TE-LSP group with 10 VC4 container, each 525 path using at minimum 2 x VC4 container, can be represented with a 526 BANDWIDTH object with OT=3, Bandwidth spec type set to 4, the content 527 of the bandwidth specification is ST=6,RCC=0,NCC=0,NVC=10,MT=1. The 528 LOAD-BALANCING, OT=2 with Bandwidth spec set to 4,Max-LSP=5, min 529 Traffic spec is (ST=6,RCC=0,NCC=0,NVC=2,MT=1). The PCE can respond 530 with a response with maximum 5 path, each of them having a BANDWIDTH 531 OT=3 and traffic spec matching the minimum traffic spec from the 532 LOAD-BALANCING object of the corresponding request. 534 2.5. END-POINTS Object extensions 536 The END-POINTS object is used in a PCEP request message to specify 537 the source and the destination of the path for which a path 538 computation is requested. From [RFC5440]the source IP address and 539 the destination IP address are used to identify those. A new Object 540 Type is defined to address the following possibilities: 542 o Different source and destination endpoint types. 544 o Label restrictions on the endpoint. 546 o Specification of unnumbered endpoints type as seen in GMPLS 547 networks. 549 The Object encoding is described in the following sections. 551 In path computation within a GMPLS context the endpoints can: 553 o Be unnumbered as described in [RFC3477]. 555 o Have label(s) associated to them, specifying a set of constraints 556 in the allocation of labels. 558 o May have different switching capabilities 560 The IPv4 and IPv6 endpoints are used to represent the source and 561 destination IP addresses. The scope of the IP address (Node or 562 numbered Link) is not explicitly stated. It is also possible to 563 request a Path between a numbered link and an unnumbered link, or a 564 P2MP path between different type of endpoints. 566 This new C-Type also supports the specification of constraints on the 567 endpoint label to be use. The PCE might know the interface 568 restrictions but this is not a requirement. This corresponds to 569 requirements 6 and 10 of [RFC7025]. 571 2.5.1. Generalized Endpoint Object Type 573 The Generalized Endpoint object type format consists of a body and a 574 list of TLVs scoped to this object type object. The TLVs give the 575 details of the endpoints and are described in Section 2.5.2. For 576 each endpoint type, a different grammar is defined. The TLVs defined 577 to describe an endpoint are: 579 1. IPv4 address endpoint. 581 2. IPv6 address endpoint. 583 3. Unnumbered endpoint. 585 4. Label request. 587 5. Label set restriction. 589 6. Suggested label set restriction. 591 The Label Set and Suggested label set TLVs are used to restrict the 592 label allocation in the PCE. Those TLVs express the set of 593 restrictions provided by signaling. Label restriction support can be 594 an explicit value (Label set describing one label), mandatory range 595 restrictions (Label set), optional range restriction (suggested label 596 set) and single suggested value is using the suggested label set. 597 Endpoints label restriction may not be part of the RRO or IRO, they 598 may be included when following [RFC4003] in signaling for egress 599 endpoint, but ingress endpoint properties may be local to the PCC and 600 not signaled. To support this case the label set allows to indicate 601 which label are used in case of reoptimization. The label range 602 restrictions are valid in GMPLS networks, either by PCC policy or 603 depending on the switching technology used, for instance on given 604 Ethernet or ODU equipment having limited hardware capabilities 605 restricting the label range. Label set restriction also applies to 606 WSON networks where the optical sender and receivers are limited in 607 their frequency tunability ranges, restricting then in GMPLS the 608 possible label ranges on the interface. The END-POINTS Object with 609 Generalized Endpoint object type is encoded as follow: 611 0 1 2 3 612 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 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Reserved | endpoint type | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | | 617 ~ TLVs ~ 618 | | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 Reserved bits should be set to 0 when a message is sent and ignored 622 when the message is received 624 the endpoint type is defined as follow: 626 Value Type Meaning 628 0 Point-to-Point 629 1 Point-to-Multipoint New leaves to add 630 2 Old leaves to remove 631 3 Old leaves whose path can be 632 modified/reoptimized 633 4 Old leaves whose path must be 634 left unchanged 635 5-244 Reserved 636 245-255 Experimental range 638 The endpoint type is used to cover both point-to-point and different 639 point-to-multipoint endpoints. Endpoint type 0 MAY be accepted by 640 the PCE, other endpoint type MAY be supported if the PCE 641 implementation supports P2MP path calculation. A PCE not supporting 642 a given endpoint type MUST respond with a PCErr with error code "Path 643 computation failure", error type "Unsupported endpoint type in END- 644 POINTS Generalized Endpoint object type". The TLVs present in the 645 request object body MUST follow the following grammar: 647 ::= 648 | 650 ::= 651 652 654 ::= 655 656 [] 658 ::= 659 660 [] 662 ::= 663 [] 664 [ []]... 666 For endpoint type Point-to-Multipoint, several endpoint objects may 667 be present in the message and each represents a leave, exact meaning 668 depend on the endpoint type defined of the object. 670 An endpoint is defined as follows: 672 ::=|| 673 ::= 674 [] 676 ::= 677 679 ::= 680 [] 681 ::= | 682 684 The different TLVs are described in the following sections. A PCE 685 MAY support IPV4-ADDRESS,IPV6-ADDRESS or UNNUMBERED-ENDPOINT TLV. A 686 PCE not supporting one of those TLVs in a PCReq MUST respond with a 687 PCRep with NO-PATH with the bit "Unknown destination" or "Unknown 688 source" in the NO-PATH-VECTOR TLV, the response SHOULD include the 689 ENDPOINT object in the response with only the TLV it did not 690 understood. 692 A PCE MAY support LABEL-REQUEST, LABEL-SET or SUGGESTED-LABEL-SET 693 TLV. If a PCE finds a non-supported TLV in the END-POINTS the PCE 694 MUST respond with a PCErr message with error type="Path computation 695 failure" error value="Unsupported TLV present in END-POINTS 696 Generalized Endpoint object type" and the message SHOULD include the 697 ENDPOINT object in the response with only the endpoint and endpoint 698 restriction TLV it did not understand. A PCE supporting those TLVs 699 but not being able to fulfil the label restriction MUST send a 700 response with a NO-PATH object which has the bit "No endpoint label 701 resource" or "No endpoint label resource in range" set in the NO- 702 PATH- VECTOR TLV. The response SHOULD include an ENDPOINT object 703 containing only the TLV where the PCE could not meet the constraint. 705 2.5.2. END-POINTS TLVs extensions 707 All endpoint TLVs have the standard PCEP TLV header as defined in 708 [RFC5440] section 7.1. In this object type the order of the TLVs 709 MUST be followed according to the object type definition. 711 2.5.2.1. IPV4-ADDRESS 713 This TLV represent a numbered endpoint using IPv4 numbering, the 714 format of the IPv4-ADDRESS TLV value (TLV-Type=TBA) is as follows: 716 0 1 2 3 717 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 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | IPv4 address | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 This TLV MAY be ignored, in which case a PCRep with NO-PATH should be 723 responded, as described in Section 2.5.1. 725 2.5.2.2. IPV6-ADDRESS TLV 727 This TLV represent a numbered endpoint using IPV6 numbering, the 728 format of the IPv6-ADDRESS TLV value (TLV-Type=TBA) is as follows: 730 0 1 2 3 731 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 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | IPv6 address (16 bytes) | 734 | | 735 | | 736 | | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 This TLV MAY be ignored, in which case a PCRep with NO-PATH should be 740 responded, as described in Section 2.5.1. 742 2.5.2.3. UNNUMBERED-ENDPOINT TLV 744 This TLV represent an unnumbered interface. This TLV has the same 745 semantic as in [RFC3477] The TLV value is encoded as follow (TLV- 746 Type=TBA) 748 0 1 2 3 749 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 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | LSR's Router ID | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | Interface ID (32 bits) | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 This TLV MAY be ignored, in which case a PCRep with NO-PATH should be 757 responded, as described in Section 2.5.1. 759 2.5.2.4. LABEL-REQUEST TLV 761 The LABEL-REQUEST TLV indicates the switching capability and encoding 762 type of the following label restriction list for the endpoint. Its 763 format and encoding is the same as described in [RFC3471] Section 3.1 764 Generalized label request. The LABEL-REQUEST TLV use TLV-Type=TBA. 765 The Encoding Type indicates the encoding type, e.g., SONET/SDH/GigE 766 etc., of the LSP with which the data is associated. The Switching 767 type indicates the type of switching that is being requested on the 768 endpoint. G-PID identifies the payload. This TLV and the following 769 one are introduced to satisfy requirement 13 for the endpoint. It is 770 not directly related to the TE-LSP label request, which is expressed 771 by the SWITCH-LAYER object. 773 On the path calculation request only the Tspec and switch layer need 774 to be coherent, the endpoint labels could be different (supporting a 775 different Tspec). Hence the label restrictions include a Generalized 776 label request in order to interpret the labels. This TLV MAY be 777 ignored, in which case a PCRep with NO-PATH should be responded, as 778 described in Section 2.5.1. 780 2.5.2.5. Labels TLV 782 Label or label range restrictions may be specified for the TE-LSP 783 endpoints. Those are encoded using the LABEL-SET TLV. The label 784 value need to be interpreted with a description on the Encoding and 785 switching type. The REQ-ADAP-CAP object from 786 [I-D.ietf-pce-inter-layer-ext] can be used in case of mono-layer 787 request, however in case of multilayer it is possible to have in the 788 future more than one object, so it is better to have a dedicated TLV 789 for the label and label request (the scope is then more clear). 791 Those TLV MAY be ignored, in which case a response with NO-PATH 792 should be responded, as described in Section 2.5.1. TLVs are encoded 793 as follow (following [RFC5440]) : 795 o LABEL-SET TLV, Type=TBA. The TLV Length is variable, Encoding 796 follows [RFC3471] Section 3.5 "Label set" with the addition of a U 797 bit and O Bit. The U bit is set for upstream direction in case of 798 bidirectional LSP and the O bit is used to represent an old label. 800 0 1 2 3 801 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 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 | Action | Reserved |O|U| Label Type | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | Subchannel 1 | 806 | ... | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 : : : 809 : : : 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | Subchannel N | 812 | ... | 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 o SUGGESTED-LABEL-SET TLV Set, Type=TBA. The TLV length is variable 816 and its encoding is as LABEL-SET TLV. The 0 bit SHOULD be set to 817 0. 819 A LABEL-SET TLV represents a set of possible labels that can be used 820 on an interface. The label allocated on the first link SHOULD be 821 within the label set range. The action parameter in the Label set 822 indicates the type of list provided. Those parameters are described 823 by [RFC3471] section 3.5.1 A SUGGESTED-LABEL-SET TLV has the same 824 encoding as the LABEL-SET TLV, it indicates to the PCE a set of 825 preferred (ordered) set of labels to be used. The PCE MAY use those 826 labels for label allocation. 828 The U and 0 bits have the following meaning: 830 U: Upstream direction: set when the label or label set is in the 831 reverse direction 832 O: Old Label: set when the TLV represent the old label in case of re- 833 optimization. This Bit SHOULD be set to 0 in a SUGGESTED-LABEL-SET 834 TLV Set and ignored on receipt. This Label MAY be reused. The R 835 bit of the RP object MUST be set. When this bit is set the Action 836 field MUST be set to 0 (Inclusive List) and the Label Set MUST 837 contain one subchannel. 839 Several LABEL_SET TLVs MAY be present with the 0 bit cleared. At 840 most 2 LABEL_SET TLV SHOULD be present with the 0 bit set, at most 841 one with the U bit set and at most one with the U bit cleared. For a 842 given U bit value if more than one LABEL_SET TLV with the O bit set 843 is present, the first TLV SHOULD be processed and the following TLV 844 with the same U and O bit SHOULD be ignored. 846 A SUGGESTED-LABEL-SET TLV with the O bit set MUST trigger a PCErr 847 message with error type="Reception of an invalid object" error 848 value="Wrong LABEL-SET or SUGGESTED-LABEL-SET TLV present with 0 bit 849 set". 851 A LABEL-SET TLV with the O bit set and an Action Field not set to 0 852 (Inclusive list) or containing more than one subchannel MUST trigger 853 a PCErr message with error type="Reception of an invalid object" 854 error value="Wrong LABEL-SET or SUGGESTED-LABEL-SET TLV present with 855 0 bit set". 857 If a LABEL-SET TLV is present with O bit set, the R bit of the RP 858 object MUST be set or a PCErr message with error type="Reception of 859 an invalid object" error value="LABEL-SET TLV present with 0 bit set 860 but without R bit set in RP". 862 2.6. IRO extension 864 The IRO as defined in [RFC5440] is used to include specific objects 865 in the path. RSVP-TE allows to include label definition, in order to 866 fulfill requirement 13 the IRO should support the new subobject type 867 as defined in [RFC3473]: 869 Type Sub-object 870 TBA, recommended value 3 LABEL 872 The L bit of such sub-object has no meaning within an IRO. 874 The Label subobject MUST follow a subobject identifying a link, 875 currently an IP address subobject (Type 1 or 2) or an interface id 876 (type 4) subobject. If an IP address subobject is used, then the IP 877 address given MUST be associated with a link. More than one label 878 subobject MAY follow each link subobject. The procedure associated 879 with this subobject is as follows. 881 If the PCE allocates labels (e.g via explicit label control) the PCE 882 MUST allocate one label from within the set of label values for the 883 given link. If the PCE does not assign labels then it sends a 884 response with a NO-PATH object, containing a NO-PATH-VECTOR-TLV with 885 the bit 'No label resource in range' set. 887 2.7. XRO extension 889 The XRO as defined in [RFC5521] is used to exclude specific objects 890 in the path. RSVP-TE allows to exclude labels ([RFC6001], in order 891 to fulfill requirement 13 of [RFC7025] section 3.1, the XRO should 892 support a new subobject to support label exclusion. 894 The encoding of the XRO Label subobject follows the encoding of the 895 Label ERO subobject defined in [RFC3473] and XRO subobject defined in 896 [RFC5521]. The XRO Label subobject represent one Label and is 897 defined as follows: 899 XRO Subobject Type TBA, recommended value 3: Label Subobject. 901 0 1 2 3 902 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 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 |X| Type=3 | Length |U| Reserved | C-Type | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | Label | 907 | ... | 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 X (1 bit) 912 As per [RFC5521]. The X-bit indicates whether the exclusion is 913 mandatory or desired. 0 indicates that the resource specified 914 MUST be excluded from the path computed by the PCE. 1 915 indicates that the resource specified SHOULD be excluded from 916 the path computed by the PCE, but MAY be included subject to 917 PCE policy and the absence of a viable path that meets the 918 other constraints and excludes the resource. 920 Type (7 bits) 922 The Type of the XRO Label subobject is TBA, recommended value 923 3. 925 Length (8 bits) 926 See [RFC5521],The total length of the subobject in bytes 927 (including the Type and Length fields). The Length is always 928 divisible by 4. 930 U (1 bit) 932 See [RFC3471]. 934 C-Type (8 bits) 936 The C-Type of the included Label Object as defined in 937 [RFC3471]. 939 Label 941 See [RFC3471]. 943 The Label subobject MUST follow a subobject identifying a link, 944 currently an IP address subobject (Type 1 or 2) or an interface id 945 (type 4) subobject. If an IP address subobject is used, then the IP 946 address given MUST be associated with a link. More than one label 947 subobject MAY follow each link subobject. 949 Type Sub-object 950 3 LABEL 952 The L bit of such sub-object has no meaning within an XRO. 954 2.8. LSPA extensions 956 The LSPA carries the LSP attributes. In the end-to-end protection 957 context this also includes the protection state information. This 958 object is introduced to fulfill requirement 7 of [RFC7025] section 959 3.1 and requirement 3 of [RFC7025] section 3.2. This object contains 960 the information of the PROTECTION object defined by [RFC4872] and 961 may be used as a policy input. The LSPA object MAY carry a 962 PROTECTION-ATTRIBUTE TLV defined as : Type TBA: PROTECTION-ATTRIBUTE 963 0 1 2 3 964 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 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 | Type | Length | 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 |S|P|N|O| Reserved | LSP Flags | Reserved | Link Flags| 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 |I|R| Reserved | Seg.Flags | Reserved | 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 The content is as defined in [RFC4872], [RFC4873]. 975 LSP (protection) Flags or Link flags field can be used by 976 implementation for routing policy input. The other attributes are 977 only meaningful for a stateful PCE. 979 This TLV is optional and MAY be ignored by the PCE, in which case it 980 MUST NOT include the TLV in the LSPA, if present, of the response. 981 When the TLV is used by the PCE, a LSPA object and the PROTECTION- 982 ATTRIBUTE TLV MUST be included in the response. Fields that were not 983 considered MUST be set to 0. 985 2.9. NO-PATH Object Extension 987 The NO-PATH object is used in PCRep messages in response to an 988 unsuccessful path computation request (the PCE could not find a path 989 satisfying the set of constraints). In this scenario, PCE MUST 990 include a NO-PATH object in the PCRep message. The NO-PATH object 991 may carries the NO-PATH-VECTOR TLV that specifies more information on 992 the reasons that led to a negative reply. In case of GMPLS networks 993 there could be some more additional constraints that led to the 994 failure like protection mismatch, lack of resources, and so on. Few 995 new flags have been introduced in the 32-bit flag field of the NO- 996 PATH-VECTOR TLV and no modifications have been made in the NO-PATH 997 object. 999 2.9.1. Extensions to NO-PATH-VECTOR TLV 1001 The modified NO-PATH-VECTOR TLV carrying the additional information 1002 is as follows: 1004 Bit number TBA - Protection Mismatch (1-bit). Specifies the 1005 mismatch of the protection type in the PROTECTION-ATTRIBUTE TLV in 1006 the request. 1008 Bit number TBA - No Resource (1-bit). Specifies that the 1009 resources are not currently sufficient to provide the path. 1011 Bit number TBA - Granularity not supported (1-bit). Specifies 1012 that the PCE is not able to provide a route with the requested 1013 granularity. 1015 Bit number TBA - No endpoint label resource (1-bit). Specifies 1016 that the PCE is not able to provide a route because of the 1017 endpoint label restriction. 1019 Bit number TBA - No endpoint label resource in range (1-bit). 1020 Specifies that the PCE is not able to provide a route because of 1021 the endpoint label set restriction. 1023 Bit number TBA - No label resource in range (1-bit). Specifies 1024 that the PCE is not able to provide a route because of the label 1025 set restriction. 1027 3. Additional Error Type and Error Values Defined 1029 A PCEP-ERROR object is used to report a PCEP error and is 1030 characterized by an Error-Type that specifies the type of error while 1031 Error-value that provides additional information about the error. An 1032 additional error type and few error values are defined to represent 1033 some of the errors related to the newly identified objects related to 1034 GMPLS networks. For each PCEP error, an Error-Type and an Error- 1035 value are defined. Error-Type 1 to 10 are already defined in 1036 [RFC5440]. Additional Error- values are defined for Error-Type 10 1037 and A new Error-Type is introduced (value TBA). 1039 Error-Type Error-value 1041 10 Reception of 1042 an invalid 1043 object 1044 value=TBA: Bad Bandwidth Object type TBA(Generalized 1045 bandwidth) or TBA(Generalized 1046 bandwidth,reoptimization). 1047 value=TBA: Bandwidth Object type TBA or TBA not 1048 supported. 1049 value=TBA: Unsupported LSP Protection Type in 1050 PROTECTION-ATTRIBUTE TLV. 1051 value=TBA: Unsupported LSP Protection Flags in 1052 PROTECTION-ATTRIBUTE TLV. 1053 value=TBA: Unsupported Secondary LSP Protection Flags 1054 in PROTECTION-ATTRIBUTE TLV. 1055 value=TBA: Unsupported Link Protection Type in 1056 PROTECTION-ATTRIBUTE TLV. 1057 value=TBA: Unsupported Link Protection Type in 1058 PROTECTION-ATTRIBUTE TLV. 1059 value=TBA: LABEL-SET TLV present with 0 bit set but 1060 without R bit set in RP. 1061 value=TBA: Wrong LABEL-SET or 1062 SUGGESTED-LABEL-SET TLV present with 1063 0 bit set. 1064 TBA Path 1065 computation 1066 failure 1067 value=TBA: Unacceptable request message. 1068 value=TBA: Generalized bandwidth value not supported. 1069 value=TBA: Label Set constraint could not be 1070 met. 1071 value=TBA: Label constraint could not be 1072 met. 1073 value=TBA: Unsupported endpoint type in 1074 END-POINTS Generalized Endpoint 1075 object type. 1076 value=TBA: Unsupported TLV present in END-POINTS 1077 Generalized Endpoint object type. 1078 value=TBA: Unsupported granularity in the RP object 1079 flags. 1081 4. Manageability Considerations 1083 This section follows the guidance of [RFC6123]. 1085 4.1. Control of Function through Configuration and Policy 1087 This document makes no change to the basic operation of PCEP and so 1088 the requirements described in [RFC5440] Section 8.1. also apply to 1089 this document. In addition to those requirements a PCEP 1090 implementation MAY allow the configuration of the following 1091 parameters: 1093 Accepted RG in the RP object. 1095 Default RG to use (overriding the one present in the PCReq) 1097 Accepted BANDWIDTH object type TBA and TBA (Generalized 1098 Bandwidth)parameters in request, default mapping to use when not 1099 specified in the request 1101 Accepted LOAD-BALANCING object type TBA parameters in request. 1103 Accepted endpoint type and allowed TLVs in object END-POINTS with 1104 object type Generalized Endpoint. 1106 Accepted range for label restrictions in label restriction in END- 1107 POINTS, or IRO or XRO objects 1109 PROTECTION-ATTRIBUTE TLV acceptance and suppression. 1111 Those parameters configuration are applicable to the different 1112 sessions as described in [RFC5440] Section 8.1 (by default, per PCEP 1113 peer, ..etc). 1115 4.2. Information and Data Models 1117 This document makes no change to the basic operation of PCEP and so 1118 the requirements described in [RFC5440] Section 8.2. also apply to 1119 this document. This document does not introduces new ERO sub object, 1120 ERO information model is already covered in [RFC4802]. 1122 4.3. Liveness Detection and Monitoring 1124 This document makes no change to the basic operation of PCEP and so 1125 there are no changes to the requirements for liveness detection and 1126 monitoring set out in [RFC4657] and [RFC5440] Section 8.3. 1128 4.4. Verifying Correct Operation 1130 This document makes no change to the basic operations of PCEP and 1131 considerations described in [RFC5440] Section 8.4. New errors 1132 introduced by this document should be covered by the requirement to 1133 log error events. 1135 4.5. Requirements on Other Protocols and Functional Components 1137 No new Requirements on Other Protocols and Functional Components are 1138 made by this document. This document does not require ERO object 1139 extensions. Any new ERO subobject defined in CCAMP working group can 1140 be adopted without modifying the operations defined in this document. 1142 4.6. Impact on Network Operation 1144 This document makes no change to the basic operations of PCEP and 1145 considerations described in [RFC5440] Section 8.6. In addition to 1146 the limit on the rate of messages sent by a PCEP speaker, a limit MAY 1147 be placed on the size of the PCEP messages. 1149 5. IANA Considerations 1151 IANA assigns values to the PCEP protocol objects and TLVs. IANA is 1152 requested to make some allocations for the newly defined objects and 1153 TLVs introduced in this document. Also, IANA is requested to manage 1154 the space of flags that are newly added in the TLVs. 1156 5.1. PCEP Objects 1158 As described in Section 2.3, Section 2.4 and Section 2.5.1 new 1159 Objects types are defined. IANA is requested to make the following 1160 Object-Type allocations from the "PCEP Objects" sub-registry. 1162 Object 5 1163 Class 1164 Name BANDWIDTH 1165 Object-Type TBA : Generalized bandwidth 1166 TBA: Generalized bandwidth of an existing TE LSP for 1167 which a reoptimization is requested 1168 5-15: Unassigned 1169 Reference This document (section Section 2.3) 1171 Object 14 1172 Class 1173 Name LOAD-BALANCING 1174 Object-Type TBA: Generalized load balancing 1175 3-15: Unassigned 1177 Reference This document (section Section 2.4) 1178 Object 4 1179 Class 1180 Name END-POINTS 1181 Object-Type TBA: Generalized Endpoint 1182 6-15: unassigned 1183 Reference This document (section Section 2.5) 1185 5.2. END-POINTS object, Object Type Generalized Endpoint 1187 IANA is requested to create a registry to manage the endpoint type 1188 field of the END-POINTS object, Object Type Generalized Endpoint and 1189 manage the code space. 1191 New endpoint type in the Reserved range may be allocated by an IETF 1192 consensus action. Each endpoint type should be tracked with the 1193 following qualities: 1195 o endpoint type 1197 o Description 1199 o Defining RFC 1201 New endpoint type in the Experimental range are for experimental use; 1202 these will not be registered with IANA and MUST NOT be mentioned by 1203 RFCs. 1205 The following values have been defined by this document. 1206 (Section 2.5.1, Table 4): 1208 Value Type Meaning 1210 TBA, recommended Point-to-Point 1211 valude 0 1212 TBA, recommended Point-to-Multipoint New leaves to add 1213 valude 1 1214 TBA, recommended Old leaves to remove 1215 valude 2 1216 TBA, recommended Old leaves whose path can be 1217 valude 3 modified/reoptimized 1218 TBA, recommended Old leaves whose path must be 1219 valude 4 1220 left unchanged 1221 TBA, recommended Reserved 1222 valude 5-244 1223 TBA, recommended Experimental range 1224 valude 245-255 1226 5.3. New PCEP TLVs 1228 IANA manages the PCEP TLV code point registry (see [RFC5440]). This 1229 is maintained as the "PCEP TLV Type Indicators" sub-registry of the 1230 "Path Computation Element Protocol (PCEP) Numbers" registry. This 1231 document defines new PCEP TLVs, to be carried in the END-POINTS 1232 object with Generalized Endpoint object Type. IANA is requested to 1233 do the following allocation. The values here are suggested for use 1234 by IANA. 1236 Value Meaning Reference 1238 TBA IPv4 endpoint This document (section Section 1239 2.5.2.1) 1240 TBA IPv6 endpoint This document (section Section 1241 2.5.2.2) 1242 TBA Unnumbered endpoint This document (section Section 1243 2.5.2.3) 1244 TBA Label request This document (section Section 1245 2.5.2.4) 1246 TBA Requested GMPLS Label This document (section Section 1247 Set 2.5.2.5) 1248 TBA Suggested GMPLS Label This document (section Section 1249 Set 2.5.2.5) 1250 TBA PROTECTION-ATTRIBUTE This document (section Section 2.8) 1251 TBA GMPLS-CAPABILITY This document (section Section 2.1.2) 1253 5.4. RP Object Flag Field 1255 As described in Section 2.2 new flag are defined in the RP Object 1256 Flag IANA is requested to make the following Object-Type allocations 1257 from the "RP Object Flag Field" sub-registry. The values here are 1258 suggested for use by IANA. 1260 Bit Description Reference 1262 TBA (recommended bit routing granularity This document, Section 1263 17-16) (RG) 2.2 1265 5.5. New PCEP Error Codes 1267 As described in Section 3, new PCEP Error-Type and Error Values are 1268 defined. IANA is requested to make the following allocation in the 1269 "PCEP-ERROR Object Error Types and Values" registry. The values here 1270 are suggested for use by IANA. 1272 Error name Reference 1274 Type=10 Reception of an invalid object [RFC5440] 1275 Value=TBA: Bad Bandwidth Object type TBA(Generalized This Document 1276 bandwidth) or TBA(Generalized 1277 bandwidth,reoptimization). 1278 Value=TBA: Bandwidth Object type TBA or TBA not This Document 1279 supported. 1280 Value=TBA: Unsupported LSP Protection Type in This Document 1281 PROTECTION-ATTRIBUTE TLV. 1282 Value=TBA: Unsupported LSP Protection Flags in This Document 1283 PROTECTION-ATTRIBUTE TLV. 1284 Value=TBA: Unsupported Secondary LSP Protection Flags This Document 1285 in PROTECTION-ATTRIBUTE TLV. 1286 Value=TBA: Unsupported Link Protection Type in This Document 1287 PROTECTION-ATTRIBUTE TLV. 1288 Value=TBA: Unsupported Link Protection Type in This Document 1289 PROTECTION-ATTRIBUTE TLV. 1290 Value=TBA: LABEL-SET TLV present with 0 bit set but This Document 1291 without R bit set in RP. 1292 Value=TBA: Wrong LABEL-SET or SUGGESTED-LABEL-SET TLV This Document 1293 present with 0 bit set. 1294 Type=TBA Path computation failure This Document 1295 Value=TBA: Unacceptable request message. This Document 1296 Value=TBA: Generalized bandwidth value not supported. This Document 1297 Value=TBA: Label Set constraint could not be met. This Document 1298 Value=TBA: Label constraint could not be met. This Document 1299 Value=TBA: Unsupported endpoint type in END-POINTS This Document 1300 Generalized Endpoint object type 1301 Value=TBA: Unsupported TLV present in END-POINTS This Document 1302 Generalized Endpoint object type 1303 Value=TBA: Unsupported granularity in the RP object This Document 1304 flags 1306 5.6. New NO-PATH-VECTOR TLV Fields 1308 As described in Section 2.9.1, new NO-PATH-VECTOR TLV Flag Fields 1309 have been defined. IANA is requested to do the following allocations 1310 in the "NO-PATH-VECTOR TLV Flag Field" sub-registry. The values here 1311 are suggested for use by IANA. 1313 Bit number TBA - Protection Mismatch (1-bit). Specifies the 1314 mismatch of the protection type of the PROTECTION-ATTRIBUTE TLV in 1315 the request. 1317 Bit number TBA - No Resource (1-bit). Specifies that the 1318 resources are not currently sufficient to provide the path. 1320 Bit number TBA - Granularity not supported (1-bit). Specifies 1321 that the PCE is not able to provide a route with the requested 1322 granularity. 1324 Bit number TBA - No endpoint label resource (1-bit). Specifies 1325 that the PCE is not able to provide a route because of the 1326 endpoint label restriction. 1328 Bit number TBA - No endpoint label resource in range (1-bit). 1329 Specifies that the PCE is not able to provide a route because of 1330 the endpoint label set restriction. 1332 Bit number TBA - No label resource in range (1-bit). Specifies 1333 that the PCE is not able to provide a route because of the label 1334 set restriction. 1336 5.7. New Subobject for the Include Route Object 1338 The "PCEP Parameters" registry contains a subregistry "PCEP Objects" 1339 with an entry for the Include Route Object (IRO). 1341 IANA is requested to add a further subobject that can be carried in 1342 the IRO as follows: 1344 Subobject type Reference 1346 TBA, recommended value 3 Label subobject [RFC3473] 1348 5.8. New Subobject for the Exclude Route Object 1350 The "PCEP Parameters" registry contains a subregistry "PCEP Objects" 1351 with an entry for the XRO object (Exclude Route Object). 1353 IANA is requested to add a further subobject that can be carried in 1354 the XRO as follows: 1356 Subobject type Reference 1358 TBA, recommended value 3 Label subobject [RFC3473] 1360 6. Security Considerations 1362 GMPLS controls multiple technologies and types of network elements. 1363 The LSPs that are established using GMPLS, whose paths can be 1364 computed using the PCEP extensions to support GMPLS described in this 1365 document, can carry a high amount of traffic and can be a critical 1366 part of a network infrastructure. The PCE can then play a key role 1367 in the use of the resources and in determining the physical paths of 1368 the LSPs and thus it is important to ensure the identity of PCE and 1369 PCC, as well as the communication channel. In many deployments there 1370 will be a completely isolated network where an external attack is of 1371 very low probability. However, there are other deployment cases in 1372 which the PCC-PCE communication may be more exposed and there could 1373 be more security considerations. Three main situations in case of an 1374 attack in the GMPLS PCE context could happen: 1376 o PCE Identity theft: A legitimate PCC could requests a path for a 1377 GMPLS LSP to a malicious PCE, which poses as a legitimate PCE. 1378 The answer can make that the LSP traverses some geographical place 1379 known to the attacker where some sniffing devices could be 1380 installed. Also, the answer can omit constraints given in the 1381 requests (e.g. excluding certain fibers, avoiding some SRLGs) 1382 which could make that the LSP which will be later set-up may look 1383 perfectly fine, but will be in a risky situation. Also, the 1384 answer can lead to provide a LSP that does not provide the desired 1385 quality and gives less resources tan necessary. 1387 o PCC Identity theft: A malicious PCC, acting as a legitimate PCC, 1388 requesting LSP paths to a legitimate PCE can obtain a good 1389 knowledge of the physical topology of a critical infrastructure. 1390 It could get to know enough details to plan a later physical 1391 attack. 1393 o Message deciphering: As in the previous case, knowledge of an 1394 infrastructure can be obtained by sniffing PCEP messages. 1396 The security mechanisms can provide authentication and 1397 confidentiality for those scenarios where the PCC-PCE communication 1398 cannot be completely trusted. Authentication can provide origin 1399 verification, message integrity and replay protection, while 1400 confidentiality ensures that a third party cannot decipher the 1401 contents of a message. 1403 The document [I-D.ietf-pce-pceps] describes the usage of Transport 1404 Layer Security (TLS) to enhance PCEP security. The document 1405 describes the initiation of the TLS procedures, the TLS handshake 1406 mechanisms, the TLS methods for peer authentication, the applicable 1407 TLS ciphersuites for data exchange, and the handling of errors in the 1408 security checks. 1410 Finally, as mentioned by [RFC7025] the PCEP extensions to support 1411 GMPLS should be considered under the same security as current PCE 1412 work and this extension will not change the underlying security 1413 issues. However, given the critical nature of the network 1414 infrastructures under control by GMPLS, the security issues described 1415 above should be seriously considered when deploying a GMPLS-PCE based 1416 control plane for such networks. For more information on the 1417 security considerations on a GMPLS control plane, not only related to 1418 PCE/PCEP, [RFC5920] provides an overview of security vulnerabilities 1419 of a GMPLS control plane. 1421 7. Contributing Authors 1423 Elie Sfeir 1424 Coriant 1425 St Martin Strasse 76 1426 Munich, 81541 1427 Germany 1429 Email: elie.sfeir@coriant.com 1431 Franz Rambach 1432 Nockherstrasse 2-4, 1433 Munich 81541 1434 Germany 1436 Phone: +49 178 8855738 1437 Email: franz.rambach@cgi.com 1439 Francisco Javier Jimenez Chico 1440 Telefonica Investigacion y Desarrollo 1441 C/ Emilio Vargas 6 1442 Madrid, 28043 1443 Spain 1445 Phone: +34 91 3379037 1446 Email: fjjc@tid.es 1448 Huawei Technologies 1450 Suresh BR 1451 Shenzhen 1452 China 1453 Email: sureshbr@huawei.com 1455 Young Lee 1456 1700 Alma Drive, Suite 100 1457 Plano, TX 75075 1458 USA 1460 Phone: (972) 509-5599 (x2240) 1461 Email: ylee@huawei.com 1462 SenthilKumar S 1463 Shenzhen 1464 China 1465 Email: senthilkumars@huawei.com 1467 Jun Sun 1468 Shenzhen 1469 China 1470 Email: johnsun@huawei.com 1472 CTTC - Centre Tecnologic de Telecomunicacions de Catalunya 1474 Ramon Casellas 1475 PMT Ed B4 Av. Carl Friedrich Gauss 7 1476 08860 Castelldefels (Barcelona) 1477 Spain 1478 Phone: (34) 936452916 1479 Email: ramon.casellas@cttc.es 1481 8. Acknowledgments 1483 The research of Ramon Casellas, Francisco Javier Jimenez Chico, Oscar 1484 Gonzalez de Dios, Cyril Margaria, and Franz Rambach leading to these 1485 results has received funding from the European Community's Seventh 1486 Framework Program FP7/2007-2013 under grant agreement no 247674 and 1487 no 317999. 1489 The authors would like to thank Lyndon Ong, Giada Lander, Jonathan 1490 Hardwick and Diego Lopez for their useful comments to the document. 1492 9. References 1494 9.1. Normative References 1496 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1497 Requirement Levels", BCP 14, RFC 2119, March 1997. 1499 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 1500 Services", RFC 2210, September 1997. 1502 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 1503 (GMPLS) Signaling Functional Description", RFC 3471, 1504 January 2003. 1506 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 1507 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 1508 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 1510 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1511 in Resource ReSerVation Protocol - Traffic Engineering 1512 (RSVP-TE)", RFC 3477, January 2003. 1514 [RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress 1515 Control", RFC 4003, February 2005. 1517 [RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label 1518 Switching (GMPLS) Signaling Extensions for G.709 Optical 1519 Transport Networks Control", RFC 4328, January 2006. 1521 [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi- 1522 Protocol Label Switching (GMPLS) Extensions for 1523 Synchronous Optical Network (SONET) and Synchronous 1524 Digital Hierarchy (SDH) Control", RFC 4606, August 2006. 1526 [RFC4802] Nadeau, T. and A. Farrel, "Generalized Multiprotocol Label 1527 Switching (GMPLS) Traffic Engineering Management 1528 Information Base", RFC 4802, February 2007. 1530 [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE 1531 Extensions in Support of End-to-End Generalized Multi- 1532 Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 1533 2007. 1535 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 1536 "GMPLS Segment Recovery", RFC 4873, May 2007. 1538 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 1539 "OSPF Protocol Extensions for Path Computation Element 1540 (PCE) Discovery", RFC 5088, January 2008. 1542 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 1543 "IS-IS Protocol Extensions for Path Computation Element 1544 (PCE) Discovery", RFC 5089, January 2008. 1546 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 1547 (PCE) Communication Protocol (PCEP)", RFC 5440, March 1548 2009. 1550 [RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving 1551 Topology Confidentiality in Inter-Domain Path Computation 1552 Using a Path-Key-Based Mechanism", RFC 5520, April 2009. 1554 [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the 1555 Path Computation Element Communication Protocol (PCEP) for 1556 Route Exclusions", RFC 5521, April 2009. 1558 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 1559 Objective Functions in the Path Computation Element 1560 Communication Protocol (PCEP)", RFC 5541, June 2009. 1562 [RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard, 1563 D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol 1564 Extensions for Multi-Layer and Multi-Region Networks (MLN/ 1565 MRN)", RFC 6001, October 2010. 1567 [RFC6003] Papadimitriou, D., "Ethernet Traffic Parameters", RFC 1568 6003, October 2010. 1570 [RFC6205] Otani, T. and D. Li, "Generalized Labels for Lambda- 1571 Switch-Capable (LSC) Label Switching Routers", RFC 6205, 1572 March 2011. 1574 [RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J. 1575 Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label 1576 Switched Paths (LSPs)", RFC 6387, September 2011. 1578 9.2. Informative References 1580 [I-D.ietf-pce-inter-layer-ext] 1581 Oki, E., Takeda, T., Farrel, A., and F. Zhang, "Extensions 1582 to the Path Computation Element communication Protocol 1583 (PCEP) for Inter-Layer MPLS and GMPLS Traffic 1584 Engineering", draft-ietf-pce-inter-layer-ext-08 (work in 1585 progress), January 2014. 1587 [I-D.ietf-pce-wson-routing-wavelength] 1588 Lee, Y., Bernstein, G., Martensson, J., Takeda, T., 1589 Tsuritani, T., and O. Dios, "PCEP Requirements for WSON 1590 Routing and Wavelength Assignment", draft-ietf-pce-wson- 1591 routing-wavelength-13 (work in progress), August 2014. 1593 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1594 Element (PCE)-Based Architecture", RFC 4655, August 2006. 1596 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 1597 Communication Protocol Generic Requirements", RFC 4657, 1598 September 2006. 1600 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 1601 Networks", RFC 5920, July 2010. 1603 [RFC6123] Farrel, A., "Inclusion of Manageability Sections in Path 1604 Computation Element (PCE) Working Group Drafts", RFC 6123, 1605 February 2011. 1607 [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. 1608 Margaria, "Requirements for GMPLS Applications of PCE", 1609 RFC 7025, September 2013. 1611 9.3. Experimental References 1613 [I-D.ietf-pce-pceps] 1614 Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure 1615 Transport for PCEP", draft-ietf-pce-pceps-02 (work in 1616 progress), October 2014. 1618 Authors' Addresses 1620 Cyril Margaria (editor) 1621 145 Valley Road 1622 Princeton, NJ 08540 1623 USA 1625 Email: cyril.margaria@gmail.com 1627 Oscar Gonzalez de Dios (editor) 1628 Telefonica Investigacion y Desarrollo 1629 C/ Ronda de la Comunicacion 1630 Madrid 28050 1631 Spain 1633 Phone: +34 91 4833441 1634 Email: oscar.gonzalezdedios@telefonica.com 1636 Fatai Zhang (editor) 1637 Huawei Technologies 1638 F3-5-B R&D Center, Huawei Base 1639 Bantian, Longgang District 1640 Shenzhen 518129 1641 P.R.China 1643 Email: zhangfatai@huawei.com