idnits 2.17.1 draft-lazzeri-pce-residual-bw-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 139: '...rting this draft MUST have the capabil...' RFC 2119 keyword, line 141: '...constraints. It MUST also support the...' RFC 2119 keyword, line 146: '... 2. A PCC MUST be able to specif...' RFC 2119 keyword, line 150: '... 3. A PCC MUST be able to reques...' RFC 2119 keyword, line 158: '... Therefore, it MUST be possible for ...' (19 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 407 has weird spacing: '...menting abstr...' -- The document date (February 26, 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) == Missing Reference: 'RFC3630' is mentioned on line 117, but not defined == Missing Reference: 'PCEP-SERV-AWARE' is mentioned on line 144, but not defined == Unused Reference: 'RFC7420' is defined on line 510, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-pce-pceps-11 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.754.1985' == Outdated reference: A later version (-15) exists of draft-ietf-teas-actn-framework-03 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PCE Working Group Francesco Lazzeri 2 Internet Draft Daniele Ceccarelli 3 Intended status: Standard Track Ericsson 4 Expires: August 2018 Young Lee 5 Dhruv Dhody 6 Huawei 7 February 26, 2018 9 Extensions to the Path Computation Element Protocol (PCEP) for residual 10 path bandwidth support 12 draft-lazzeri-pce-residual-bw-01 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with 17 the provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as 27 reference material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 26, 2018. 37 Copyright Notice 39 Copyright (c) 2018 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with 47 respect to this document. Code Components extracted from this 48 document must include Simplified BSD License text as described in 49 Section 4.e of the Trust Legal Provisions and are provided without 50 warranty as described in the Simplified BSD License. 52 Abstract 54 The PCEP protocol has objective functions to optimize path 55 attributes like the residual bandwidth. While this is enough for 56 some applications, it's not possible to return the computed values 57 of such attributes to the PCC, or put bounds on them. 58 This document describes extensions to the PCE Communication 59 Protocol (PCEP) providing new path-related bandwidth metrics 60 allowing a PCE to compute paths taking into account and returning to 61 the PCC information about the remaining bandwidth along the computed 62 paths. 64 Table of Contents 66 1. Requirements for managing the residual bandwidth as a metric...4 67 2. New metrics definition.........................................5 68 2.1. Link and Path Unreserved bandwidth........................5 69 2.2. Link and Path Residual bandwidth..........................5 70 3. PCEP protocol extensions.......................................6 71 4. Non-Understanding/Non-Support Residual Bandwidth...............8 72 4.1. Mode of Operation.........................................9 73 5. Procedures....................................................10 74 5.1. Use cases................................................10 75 6. IANA considerations...........................................11 76 6.1. METRIC types.............................................11 77 6.2. New Error-Values.........................................12 78 7. Security Considerations.......................................12 79 8. References....................................................13 80 8.1. Normative References.....................................13 81 8.2. Informative References...................................14 82 9. Contributors..................................................15 83 Authors' Addresses...............................................15 84 Intellectual Property Statement..................................15 85 Disclaimer of Validity...........................................16 86 Introduction 88 The objective of this document is to define an extension to the PCEP 89 [RFC5440] providing information about the bandwidth still available 90 for future reservations on a given path, that is the minimum 91 unreserved bandwidth and the minimum residual bandwidth among all 92 the links of that path. 93 This is not a new concept to PCEP. In [RFC5541] two objective 94 functions are defined, called minimum load path (MLP) and maximum 95 residual bandwidth path (MBP). Both of them allow to find paths with 96 optimal value of bandwidth-related metrics, defined on a per-link 97 basis, considering the links traversed by that path. 98 For example, the residual bandwidth of a path is defined as the 99 minimum value of the residual bandwidth on each link in the path. 100 Specifying that OF inside the SVEC object of a PCReq message, the 101 PCE tries and finds the path with the maximum value of the path 102 residual bandwidth. 103 Unfortunately, being an objective function, MBP can only be used to 104 find a path that optimizes the residual bandwidth, but its value 105 cannot be returned for a path computed with some other objectives 106 (and also when MBP itself is used), or used as a bound. 107 The same applies to the unreserved bandwidth. The difference between 108 residual and unreserved bandwidth is well described in [RFC7471]: 109 "The calculation of Residual Bandwidth is different than that of 110 Unreserved Bandwidth [RFC3630]. Residual Bandwidth subtracts 111 tunnel reservations from Maximum Bandwidth (i.e., the link 112 capacity) [RFC3630] and provides an aggregated remainder across 113 priorities. Unreserved Bandwidth, on the other hand, is 114 subtracted from the Maximum Reservable Bandwidth (the bandwidth 115 that can theoretically be reserved) and provides per priority 116 remainders. Residual Bandwidth and Unreserved Bandwidth 117 [RFC3630] can be used concurrently, and each has a separate use 118 case (e.g., the former can be used for applications like Weighted 119 ECMP while the latter can be used for call admission control)". 120 Having this information would allow a PCC to reuse a path resulting 121 from a path computation to route additional LSPs without requesting 122 new path computations(with the same end-points and constraints), 123 until the maximum path unreserved bandwidth is taken (or a path 124 deployment fails). 126 1. Requirements for managing the residual bandwidth as a metric 128 Path computation with optimization of the load or of the residual 129 bandwidth has been defined as important objective functions in 130 [RFC5541]. 132 Managing the unreserved bandwidth (related to the load) and the 133 residual bandwidth of a path as additional metrics, adds the 134 capability to return their value, or putting a bound on their value. 135 This is an added value in distributed PCE applications, like e.g. in 136 ACTN architecture [ACTN-FW] and [PCE-APP]. The following associated 137 key requirements are identified for PCEP: 139 1. A PCE supporting this draft MUST have the capability to 140 compute end-to-end (E2E) paths with either unreserved bandwidth or 141 with residual bandwidth constraints. It MUST also support the 142 combination of these new constraints with existing constraints, like 143 IGP metric, TE metric, hop limit, and network performance 144 constraints as defined in [RFC5440] and [PCEP-SERV-AWARE]. 146 2. A PCC MUST be able to specify either unreserved bandwidth or 147 residual bandwidth constraints in a Path Computation Request (PCReq) 148 message to be applied during the path computation. 150 3. A PCC MUST be able to request that a PCE optimizes a path 151 using either unreserved bandwidth or residual bandwidth as objective 152 metric. 154 4. A PCE that supports this specification is not required to 155 provide unreserved bandwidth or residual bandwidth path computation 156 to any PCC at any time. 158 Therefore, it MUST be possible for a PCE to reject a PCReq 159 message with reason codes that indicate unreserved bandwidth or 160 residual bandwidth is not supported. Furthermore, a PCE that does 161 not support this specification will either ignore or reject such 162 requests using pre-existing mechanisms, therefore the requests MUST 163 be identifiable to legacy PCEs and rejections by legacy PCEs MUST be 164 acceptable within this specification. 166 5. A PCE that supports this specification MUST be able to return 167 unreserved or residual bandwidth information of the computed path in 168 a Path Computation Reply (PCRep) message. 170 2. New metrics definition 172 2.1. Link and Path Unreserved bandwidth 174 The unreserved bandwidth of a link is the bandwidth available for 175 future allocation on the link at a given priority, that is the 176 difference between the Maximum Reservable Bandwidth of the link and 177 total bandwidth used on that link by LSPs with priority equal or 178 lower (higher value) than the specified priority. In order to define 179 the path unreserved bandwidth, the following concepts and notation 180 need to be introduced: 182 o A network comprises of a set of N links {Li, (i=1...N)}. 184 o A path of a point to point (P2P) LSP is a list of K links 185 {Lpi,(i=1...K)}. 187 o The maximum reservable bandwidth of the link Li, named Ri. 189 o The bandwidth allocated to LSPs at priority p on the link Li is 190 the sum of the bandwidth of all the LSPs passing through the 191 link Li with priority >= p, named Bi(p). 193 o The unreserved bandwidth at priority p of the link Li is 194 Ui(p) = Ri - Bi(p) 196 The path unreserved bandwidth at a given priority k is defined 197 as the minimum value of the unreserved bandwidth at priority k among 198 all the links along the P2P path. Specifically, extending on the 199 above mentioned terminology: 200 o Path unreserved bandwidth metric at priority is defined as: 201 PU(p) = min {Ui(p), (i=1...K)} 203 2.2. Link and Path Residual bandwidth 205 The residual bandwidth of a link is the bandwidth physically left 206 free for future allocation on the link. In order to define the path 207 residual bandwidth, the following concepts and notation need to be 208 introduced: 210 o A network comprises of a set of N links {Li, (i=1...N)}. 212 o A path of a point to point (P2P) LSP is a list of K links 213 {Lpi,(i=1...K)} 215 o The maximum bandwidth of the link Li, named Bi. 217 o The sum of the bandwidth of all the LSPs passing through the 218 link Li, that is the bandwidth allocated on the link, named Ai. 220 o The residual bandwidth of the link Li is r(i) = Bi - Ai. 222 The path residual bandwidth is defined as the minimum value of the 223 residual bandwidth among all the links along the P2P path. 224 Specifically, extending on the above mentioned terminology: 226 o Path residual bandwidth metric for the P2P path is defined as: 227 PB = min {r(Lpi), (i=1...K)} 229 3. PCEP protocol extensions 231 This section defines PCEP extensions to fulfill the requirements 232 outlined in Section 2. The proposed solution is used to support 233 path unreserved bandwidth and path residual bandwidth as additional 234 metrics of the PCEP protocol. 235 The METRIC object is defined in section 7.8 of [RFC5440], comprising 236 metric-value, metric-type (T field) and a flags field comprising a 237 number of bit-flags. 239 This document defines two new types for the METRIC object: 241 T = TBD1: Path Unreserved Bandwidth 243 When the T field is set to TBD1, the value of the metric-value field 244 is set to the Path Unreserved Bandwidth for the traffic type and 245 priority requested in the PCReq message. 246 The same format used by [RFC5440] for the BANDWIDTH object body is 247 used here to represent the value of a path unreserved bandwidth 248 bound or returned value, as shown in the following: 250 0 1 2 3 251 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 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Path Unreserved Bandwidth | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 Figure 1: PATH UNRESERVED BANDWIDTH value format 257 Path Unreserved Bandwidth (32 bits): The path unreserved 258 bandwidth is encoded in 32 bits in IEEE floating point format (see 259 [IEEE.754.1985]), expressed in bytes per second. 260 The PATH UNRESERVED BANDWIDTH value has a fixed length of 4 261 bytes. 263 T = TBD2: Path Residual Bandwidth 265 When the T field is set to TBD2, the value of the metric-value field 266 is set to the Path Residual Bandwidth for the traffic type requested 267 in the PCReq message. 268 When the T field is set to TBD2, the value of the metric-value field 269 is set to the Path Residual Bandwidth for the traffic type requested 270 in the PCReq message. 271 The same format used by [RFC5440] for the BANDWIDTH object body is 272 used here to represent the value of a path residual bandwidth bound 273 or returned value, as shown in the following: 275 0 1 2 3 276 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 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Path Residual Bandwidth | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 Figure 1: PATH RESIDUAL BANDWIDTH value format 282 Path Residual Bandwidth (32 bits): The path residual bandwidth 283 is encoded in 32 bits in IEEE floating point format (see 284 [IEEE.754.1985]), expressed in bytes per second. 285 The PATH RESIDUAL BANDWIDTH value has a fixed length of 4 bytes. 287 Editor NOTE: these definitions provide support only of PSC signal 288 type. For other signal types (e.g. ODU, WDM) these fields can be 289 filled with the number of unreserved or residual fixed containers 290 (e.g. 3 ODU0) related to the type of traffic specified in the PCReq. 291 This has to be discussed. 293 A PCC MAY use the path unreserved or residual bandwidth in a PCReq 294 message to request a path meeting the end to end unreserved or 295 residual bandwidth requirement. In this case, the B bit MUST be set 296 to suggest a bound (a minimum) for the path residual bandwidth 297 metric that must be guaranteed for the PCC to consider the computed 298 path as acceptable. The path unreserved or residual bandwidth 299 metrics must be greater than or equal to the value specified in the 300 metric-value field. 301 The P bit MAY be set to specify the constraint as mandatory, or MAY 302 be left cleared to specify the bound as optional. 304 A PCC can also use this metric to ask PCE to optimize (that is 305 maximize) the path residual bandwidth during path computation. 306 In this case, the B bit MUST be cleared. 308 A PCE MAY use the path residual bandwidth metric in a PCRep 309 message along with a NO-PATH object in the case where the PCE cannot 310 compute a path meeting this constraint. 311 A PCE can also use this metric to send the computed path residual 312 bandwidth metric to the PCC. 314 4. Non-Understanding/Non-Support Residual Bandwidth 316 If a PCE receives a PCReq message containing a METRIC object with 317 type PATH UNRESERVED BANDWIDTH or PATH RESIDUAL BANDWIDTH and the 318 PCE does not understand or support those metric types, and the P bit 319 is clear in the METRIC object header then the PCE SHOULD simply 320 ignore the METRIC object as per the processing specified in 321 [RFC5440]. 322 If the PCE does not understand the new METRIC types, and the P 323 bit is set in the METRIC object header, then the PCE MUST send a 324 PCErr message containing a PCEP-ERROR Object with Error-Type = 4 325 (Not supported object) and Error-value = 4 (Unsupported parameter) 326 [RFC5440][RFC5541]. 327 If the PCE understands but does not support the new METRIC type, 328 and the P bit is set in the METRIC object header, then the PCE MUST 329 send a PCErr message containing a PCEP-ERROR Object with Error-Type 330 = 4 (Not supported object) with Error-value = TBD3 (Unsupported path 331 unreserved bandwidth constraint) or TBD4 (Unsupported path residual 332 bandwidth constraint). 333 The path computation request MUST then be cancelled. 334 If the PCE understands the new METRIC type, but the local policy 335 has been configured on the PCE to not allow network performance 336 constraint, and the P bit is set in the METRIC object header, then 337 the PCE MUST send a PCErr message containing a PCEP-ERROR Object 338 with Error-Type = 5 (Policy violation) with Error-value = TBD5 (Not 339 Allowed path unreserved bandwidth constraint) or TBD6 (Not 340 Allowed path residual bandwidth constraint). The path computation 341 request MUST then be cancelled. 343 4.1. Mode of Operation 345 As explained in [RFC5440], the METRIC object is optional and can 346 be used for several purposes. In a PCReq message, a PCC MAY insert 347 one or more METRIC objects: 348 o To indicate the metric (path unreserved or path residual 349 bandwidth) that MUST be optimized by the path computation 350 algorithm. 352 o To indicate a bound on the METRIC (path unreserved or path 353 residual bandwidth) that MUST NOT be exceeded for the path to be 354 considered as acceptable by the PCC. 356 In a PCRep message, the PCE MAY insert the METRIC object with an 357 Explicit Route Object (ERO) so as to provide the METRIC (residual 358 bandwidth) for the computed path. 359 The PCE MAY also insert the METRIC object with a NO-PATH object to 360 indicate that the metric constraint could not be satisfied. 361 The path computation algorithmic aspects used by the PCE to 362 optimize a path with respect to a specific metric are outside the 363 scope of this document. 364 All the rules of processing the METRIC object as explained in 365 [RFC5440] are applicable to the new metric types as well. 367 5. Procedures 369 The new metrics defined in this document don't add or change the 370 procedures already defined for PCEP protocol in [RFC5440] and 371 [RFC5541]. 373 In particular, the existing objective function MBP is still usable 374 as appropriate, being equivalent to the usage of the Path Residual 375 Bandwidth metric with the B bit cleared. 377 The new metric can be used to define new procedures especially in 378 the scope of SDN and ACTN, which are out of the scope of this 379 document. 381 5.1. Use cases 383 The first use case is the application of the residual bandwidth 384 to simplify the computation of an end-to-end path across a multi- 385 domain network. 386 The ability of a hierarchy of PCEs to compute accurate end-to-end 387 paths across multiple domains is recognized as an important 388 requirement in many applications. 389 In particular, this is a key requirement for networks with a 390 centralized path computation function (e.g. hierarchical PCE or SDN. 391 In such scenarios, a hierarchy of PCEs is often implemented, where, 392 as illustrated in [RFC6805], a parent H-PCE coordinates the 393 operations of a set of child (domain) PCEs in order to compute end- 394 to-end paths across the network. 395 An H-PCE (either stateful or stateless) can make the best of 396 residual bandwidth metrics, using paths from erstwhile path 397 computations to deploy multiple LSPs (having the same end-points and 398 constraints) without additional requests, until either the remaining 399 In a hierarchical architecture of PCEs, domain PCEs just know the 400 topology of their domains, while the parent PCE has in general 401 detailed information about the managed domains and the relevant 402 inter-domain links, but not necessarily enough information about the 403 internals of each domain, so that it's capable to compute accurately 404 an end-to-end path. 406 The residual bandwidth information would also be beneficial for 407 implementing abstractions of the domain topology, building the 408 abstract connectivity incrementally, based only on really used 409 constraints, as soon as path computation results are returned. 410 One of the key features of SDN is the support of network 411 abstraction, that is, as described in [RFC7926], the capability of 412 applying policy to a set of information about a network, in order to 413 produce selective information that represents the potential ability 414 to connect across the domain. 415 The process of abstraction produces a connectivity graph, which can 416 be used by the parent PCE to compute an accurate path based on the 417 abstracted topology. The main issue is that the connectivity graph 418 can be huge, depending on the size of the domain topology and the 419 number of end-points defined on the edge of the domain. 420 One way to provide similar information is to store the result of 421 path computations requested to the child PCEs (performed by e.g. TE- 422 tunnels "compute only") and try reusing them if possible to save 423 further path computation iterations between parent and child PCEs. 424 In any case a selection of path computation constraints has to be 425 defined against the abstract topology in order to reduce the number 426 of the abstract links or TE-tunnels exported by the connectivity 427 graph, as it's impractical to compute or pre-compute all the 428 constraints combinations. It's also very important to reduce the 429 number of updates of such connectivity information to the parent PCE 430 in order not to flood it with a continuous stream of updates. 432 6. IANA considerations 434 6.1. METRIC types 436 IANA maintains the "Path Computation Element Protocol (PCEP) 437 Numbers" at . Within this 438 registry IANA maintains one sub-registry for "METRIC object T 439 field". 440 Two new metric types are defined in this document for the METRIC 441 object (specified in [RFC5440]). 443 IANA is requested to make the following allocations: 445 Value Description Reference 446 ---------------------------------------------------------- 447 TBD1 Path unreserved bandwidth metric [This I.D.] 448 TBD2 Path residual bandwidth metric [This I.D.] 450 6.2. New Error-Values 452 IANA maintains a registry of Error-Types and Error-values for use 453 in PCEP messages. This is maintained as the "PCEP-ERROR Object 454 Error Types and Values" sub-registry of the "Path Computation 455 Element Protocol (PCEP) Numbers" registry. 456 IANA is requested to make the following allocations: 457 Four new Error-values are defined for the Error-Type "Not 458 supported object" (type 4) and "Policy violation" (type 5). 460 Error-Type Meaning and error values Reference 461 4 Not supported object 462 Error-value=TBD3 Unsupported [This I.D.] 463 Path unreserved bandwidth constraint 464 Error-value=TBD4 Unsupported 465 Path residual bandwidth constraint 467 5 Policy violation 468 Error-value=TBD5 Not allowed [This I.D.] 469 Path unreserved bandwidth constraint 470 Error-value=TBD6 Not allowed 471 Path residual bandwidth constraint 473 7. Security Considerations 475 This document defines new METRIC types, which do not add any new 476 security concerns beyond those discussed in [RFC5440] and [RFC5541] 477 in itself. 478 In some scenarios, path unreserved bandwidth and path residual 479 bandwidth information could be considered sensitive and could be 480 used to influence path computation and setup with adverse effect. 482 Snooping of PCEP messages with such data, or using PCEP messages for 483 network reconnaissance, may give an attacker sensitive information 484 about the capabilities of the network. Thus, such deployment should 485 employ suitable PCEP security mechanisms like TCP Authentication 486 Option (TCP-AO) [RFC5925] or [PCEPS]. 487 The Transport Layer Security (TLS) based procedure in [PCEPS] is 488 considered as a security enhancement and thus much better suited for 489 the sensitive residual bandwidth information. 491 8. References 493 8.1. Normative References 495 [RFC5440] Vasseur JP., Ed. and JL. Le Roux, Ed., 496 "Path Computation Element (PCE) Communication 497 Protocol(PCEP)", RFC 5440, 498 DOI 10.17487/RFC5440, March 2009, 499 . 500 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, 501 "Encoding of Objective Functions in the Path 502 Computation Element Communication Protocol (PCEP)", 503 RFC 5541, 504 DOI 10.17487/RFC5541, June 2009, 505 . 506 [RFC5925] Touch, J., Mankin, A., and R. Bonica, 507 "The TCP Authentication Option", RFC 5925, 508 DOI 10.17487/RFC5925, June 2010, 509 . 510 [RFC7420] Koushik A.,Stephan E.,Zhao Q.,King D. and J.Hardwick, 511 "Path Computation Element Communication Protocol 512 (PCEP) Management Information Base (MIB) Module", 513 RFC 7420, DOI 10.17487/RFC7420, December 2014, 514 . 515 [PCEPS] Lopez, D.Lopez, D., Dios, O., Wu, W., and D. Dhody, 516 "Secure Transport for PCEP", draft-ietf-pce-pceps-11 517 (work in progress), January 2017. 518 [IEEE.754.1985] IEEE, "Standard for Binary Floating-Point Arithmetic", 519 IEEE 754, August 1985 521 8.2. Informative References 523 [RFC6805] King, D., Ed., and A. Farrel, Ed., 524 "The Application of the Path Computation Element 525 Architecture to the Determination of a Sequence of 526 Domains in MPLS and GMPLS", RFC 6805, November 2012, 527 . 528 [RFC7471] Giacalone S., Ward D., Drake J., Atlas A. and S. 529 Previdi, "OSPF Traffic Engineering (TE) Metric 530 Extensions", RFC 7471, 531 DOI 10.17487/RFC7471, March 2015, 532 533 [RFC7926] Farrel, A. et al., "Problem Statement and Architecture 534 for Information Exchange Between Interconnected 535 Traffic Engineered Networks", RFC 7926, July 2016. 536 [ACTN-FW] Ceccarelli, D. and Y. Lee, "Framework for Abstraction 537 and Control of Traffic Engineered Networks", draft- 538 ietf-teas-actn-framework-03 (work in progress), 539 February 2017. 540 [PCE-APP] Dhody, D. Lee, Y. Ceccarelli, D. "Applicability of 541 Path Computation Element (PCE) for Abstraction and 542 Control of TE Networks (ACTN)" draft-dhody-pce- 543 applicability-actn-02 545 9. Contributors 547 Authors' Addresses 549 Francesco Lazzeri 550 Ericsson 551 Via Melen 77 552 Genova - Italy 553 Email: francesco.lazzeri@ericsson.com 555 Daniele Ceccarelli 556 Ericsson AB 557 Gronlandsgatan 21 558 Kista - Sweden 559 Email: daniele.ceccarelli@ericsson.com 561 Young Lee 562 Huawei Technologies 563 5340 Legacy Drive 564 Plano, TX 75023, USA 565 Phone: (469)277-5838 566 Email: leeyoung@huawei.com 568 Dhruv Dhody 569 Huawei Technologies, 570 Divyashree Technopark, Whitefield 571 Bangalore, India 572 Email: dhruv.ietf@gmail.com 574 Intellectual Property Statement 576 The IETF Trust takes no position regarding the validity or scope of 577 any Intellectual Property Rights or other rights that might be 578 claimed to pertain to the implementation or use of the technology 579 described in any IETF Document or the extent to which any license 580 under such rights might or might not be available; nor does it 581 represent that it has made any independent effort to identify any 582 such rights. 584 Copies of Intellectual Property disclosures made to the IETF 585 Secretariat and any assurances of licenses to be made available, or 586 the result of an attempt made to obtain a general license or 587 permission for the use of such proprietary rights by implementers or 588 users of this specification can be obtained from the IETF on-line 589 IPR repository at http://www.ietf.org/ipr 591 The IETF invites any interested party to bring to its attention any 592 copyrights, patents or patent applications, or other proprietary 593 rights that may cover technology that may be required to implement 594 any standard or specification contained in an IETF Document. Please 595 address the information to the IETF at ietf-ipr@ietf.org. 597 Disclaimer of Validity 599 All IETF Documents and the information contained therein are 600 provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 601 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 602 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 603 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 604 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 605 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 606 FOR A PARTICULAR PURPOSE. 608 Acknowledgment 610 Funding for the RFC Editor function is currently provided by the 611 Internet Society.