idnits 2.17.1 draft-carrozzo-pce-pcep-route-price-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([G]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 4, 2012) is 4430 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-ietf-pce-hierarchy-fwk-00 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group G. Carrozzo 3 Internet-Draft G. Bernini 4 Intended status: Experimental G. Landi 5 Expires: September 5, 2012 Nextworks 6 March 4, 2012 8 PCEP extensions for the computation of route offers with price 9 draft-carrozzo-pce-pcep-route-price-00 11 Abstract 13 The PCE defined in RFC4655 is a functional entity generally confined 14 in the control plane to elaborate explicit optimal routes with 15 related costs to be installed as [G]MPLS tunnels/LSPs. The resulting 16 route cost(s)/metric(s) are Traffic Engineering indicators used by 17 the network administrator (carrier) to optimize the usage of its 18 network resources. 20 In this document a framework for the usage of PCE in cooperation with 21 the Network Service and Business Plane (NSBP) is proposed, along with 22 related PCEP extensions. The NSBP invokes this extended PCE (service 23 PCE) to trigger the computation of network service offers with 24 related price information. The price of a network connectivity 25 service generally depends on strategic factors, but it could also be 26 influenced by the amount of mobilized network resources (along the 27 route), the ingress/egress interfaces/PoPs, etc. Therefore, it could 28 be provided by an extended service-PCE as an additional route 29 information. 31 This document focuses on the extensions to the PCEP protocol in 32 support of the computation of route prices for intra- and inter- 33 domain network connectivity services. Mechanisms for elaborating and 34 retrieving price information in the PCE are vendor-specific and out 35 of the scope of this document. 37 Status of this Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on September 5, 2012. 54 Copyright Notice 56 Copyright (c) 2012 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Conventions and Terminology used in this document . . . . . . 4 73 3. Service-PCE framework . . . . . . . . . . . . . . . . . . . . 6 74 3.1. Route cost vs. route price . . . . . . . . . . . . . . . . 8 75 4. PCEP protocol extensions . . . . . . . . . . . . . . . . . . . 8 76 4.1. Price Request bit . . . . . . . . . . . . . . . . . . . . 8 77 4.1.1. Processing rules . . . . . . . . . . . . . . . . . . . 10 78 4.2. PRICE-INFO Object . . . . . . . . . . . . . . . . . . . . 10 79 4.2.1. Processing rules . . . . . . . . . . . . . . . . . . . 14 80 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 82 6.1. PRICE INFO Object . . . . . . . . . . . . . . . . . . . . 14 83 6.2. RP Object Flag . . . . . . . . . . . . . . . . . . . . . . 15 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 87 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 90 1. Introduction 92 Carriers usually deploy traffic engineering (TE) technologies coupled 93 with network control plane (CP) protocol suites, such as the Multi- 94 Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS), to 95 offer value added network connectivity services to their customers. 97 The constraint-based route computation is a key function for these 98 connectivity services, and it is executed by the Path Computation 99 Element (PCE) functional entity. The PCE architecture is defined in 100 [RFC4655] and allows the computation of network routes based on a 101 network graph; the graph is derived from the controlled network with 102 various means (e.g. IGP/EGP, other proprietary interfaces, etc.), 103 and can contain multi-domain, multi-region/multi-layer topology 104 information. 106 In general, the PCE function is completely confined in the control 107 plane to compute optimal inter-domain constrained explicit routes 108 (ERO) for (G)MPLS TE LSPs/tunnels. However, the computation and 109 instantiation of these tunnels in the Transport Plane (TP) is 110 preceded by mandatory phases of service/product offering, offer 111 composition and negotiation, which involve the service supplier(s) 112 and the final service end-customer (see TMF IPSPHERE Framework 113 [IPSPHERE]). These service phases are generally handled at the 114 management and business planes (OSS/BSS) only. However, control 115 plane functionalities like the PCE ones can definitely support in the 116 definition/specification of network connectivity offers within a 117 carrier network domain. 119 This document briefly introduces a framework for the usage of a PCE 120 for route offers (Service-PCE) and describes some extensions to the 121 PCEP protocol that allow the Network Service and Business Plane 122 (NSBP) to request the Service-PCE for the computation of network 123 service offers with related price information. 125 Mechanisms for elaborating and retrieving price information in the 126 Service-PCE are assumed to be vendor-specific and out of the scope of 127 this I-D. 129 2. Conventions and Terminology used in this document 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 Moreover, the following terminology is used in this document. 137 BSS: Business Support System. 139 Control Plane (CP): The CP performs the basic functions of 140 signaling, routing and resource discovery. These are essential 141 operations which allow for the automation of higher-level network 142 functions like connection establishment (i.e., path computation, 143 resource availability, verification and connection set-up and 144 tear-down), reconfiguration of signaled connections, and 145 connection restoration. 147 FCAPS: Fault, Configuration, Accounting, Performance, and Security 148 management. 150 GMPLS: Generalized Multiprotocol Label Switching. 152 Management Plane: The network management plane performs functions 153 like alarm reporting, system configuration and connection 154 provisioning for the network data and network control planes. The 155 complexity of the network management plane strongly depends on the 156 capabilities of the network control plane. In general the network 157 management plane performs FCAPS functionalities (Fault, 158 Configuration, Accounting, Performance, and Security management). 159 Where applicable the network management plane follows the TMN 160 architecture as described in [ITU-T M.3010]. 162 NMS: Network Management System. 164 Network Service and Business Plane (NSBP): This plane refers to 165 functions related to the management and handling of network 166 product offerings, service specifications and service instances. 167 This can range from service specification and offer creation, to 168 their publishing, service instance request and handling. 169 Functions of this plane may also include customer-relationship 170 management and various functions related to operations support. 172 OSS: Operation Support System. 174 Parent PCE: As per [I-D.ietf-pce-hierarchy-fwk], a PCE responsible 175 for selecting a path across a parent domain and any number of 176 child domains by coordinating with child PCEs and examining a 177 topology map that shows domain inter-connectivity. 179 PCC: Path Computation Client: any client application requesting a 180 path computation to be performed by a Path Computation Element. 182 PCE: Path Computation Element. An entity (component, application, 183 or network node) that is capable of computing a network path or 184 route based on a network graph and applying computational 185 constraints. 187 PCEP: Path Computation Element Communication Protocol. 189 Service PCE: A parent PCE interfaced to the NSBP for the computation 190 of route offers with price information. PCEP protocol is used to 191 implement the interface between NSBP and the Service PCE. 193 TE: Traffic Engineering. 195 TED: Traffic Engineering Database. 197 Transport Plane (TP): The transport plane performs various framing, 198 forwarding or switching, and the transportation of data blocks to 199 specific destinations. This plane identifies the set of data 200 bearing transport resources (possibly grouped into domains on a 201 policy or technology basis). 203 3. Service-PCE framework 205 The NSBP includes all the functions related to the management and 206 handling of network connectivity product offers, service 207 specifications and service instances from an operational and business 208 perspective ([IPSPHERE] [ETICS]). In particular, the NSBP controls/ 209 coordinates the service specification and offer creation, publishes 210 these product offers, composes different offers for an end-to-end 211 service, and eventually triggers the instantiation and operation of 212 the final service 214 The constraint-based route computation functions provided by a PCE 215 can be very useful for the network connectivity offer creation. In 216 fact, the PCE can implement constraint-based route selection 217 procedures providing the requesting client also with route price 218 information tight to the route to be followed, the ingress/egress 219 endpoints, some policy data, etc. 221 A Path Computation Client (PCC) could be integrated in the NSBP, to 222 request route offer computation either on-demand (i.e. connectivity 223 offer tailored to a specific customer request at the NSBP interfaces) 224 or in-advance (i.e. pre-computation of a connectivity offer to be 225 stored in a catalogue-like function of the NSBP). 227 The standard PCE route request/response mechanisms based on PCEP is 228 applied in the Service- PCE as per [RFC4655] and [RFC5440]. 230 Moreover, the Service-PCE better adapts to extend the concept and 231 functionalities of a parent PCE ([I-D.ietf-pce-hierarchy-fwk]), as it 232 can be used for a group of child technological/administrative domains 233 within a carrier/Autonomous System, and the produced route offers can 234 be in the form of sparse multi-domain EROs. 236 ----------------------------------------------------------------- 237 | | 238 | NETWORK SERVICE AND BUSINESS PLANE | 239 | ------- | 240 | | PCC | | 241 | ------- | 242 --------------------------------|-------------------------------- 243 | 244 | PCEP 245 --------------------------------|-------------------------------- 246 | Domain 4 (AS) | | 247 | ------------- | 248 | | Service-PCE | | 249 | ------------- | 250 | / | \ | 251 | PCEP ~~~~/~~~~~~~~~~~~|~~~~~\~~~~ PCEP | 252 | / | \ | 253 | ---------------- / ------------|--- \ --------------- | 254 | | Domain 1 |/ | Domain 2 | | |\ Domain 3 | | 255 | | / | | | | \ | | 256 | | ----- /| | ----- | | \ ----- | | 257 | | |PCE 1|/ | | |PCE 2| | | \|PCE 3| | | 258 | | ----- | | ----- | | ----- | | 259 | | | | | | | | 260 | | ----| |---- ----| |---- | | 261 | | |BN11+---+BN21| |BN23+---+BN31| | | 262 | | - ----| |---- ----| |---- - | | 263 | | |S| | | | | |D| | | 264 | | - ----| |---- ----| |---- - | | 265 | | |BN12+---+BN22| |BN24+---+BN32| | | 266 | | ----| |---- ----| |---- | | 267 | ---------------- ---------------- ---------------- | 268 ----------------------------------------------------------------- 270 Figure 1: Service-PCE and NSBP in the hierarchical model 272 3.1. Route cost vs. route price 274 The route cost(s)/metric(s) are Traffic Engineering indicators used 275 by the network administrator (carrier) to optimize the usage of its 276 network resources. 278 The route price is a different information with respect to the route 279 cost, as it refers to the customer-supplier interaction at the 280 business level for offering, negotiating and, eventually, 281 instantiating a network connectivity service (e.g. a [G]MPLS LSP). 282 The price of a network connectivity service generally depends on 283 strategic factors, but it could also be influenced by the amount of 284 mobilized network resources (along the route), the ingress/egress 285 interfaces/PoPs, etc. 287 Therefore, it could be provided by an extended PCE (i.e. the Service- 288 PCE) as an optional route information, by using a mix of topology 289 data, explicit route and policy data (both local and external to the 290 service-PCE). 292 4. PCEP protocol extensions 294 The procedures and encoding adopted by a PCC and a service-PCE to 295 handle the route offer computation with price information are 296 described in this section. 298 Two different set of extensions are defined for the PCEP for route 299 offer computations: one for the PCEP Request (PCReq) message, and 300 another for the PCEP Reply (PCRep) message. 302 4.1. Price Request bit 304 The format of a PCReq message for the request of a route offer 305 computation is unchanged with respect to [RFC5440] and subsequent 306 extensions. 308 ::= 309 [] 310 312 where: 313 ::=[] 314 ::=[] 316 ::= 317 | 319 where: 321 ::= 322 [] 323 [] 324 [] 325 [] 326 [] 327 [] 328 ::= 330 The route offer computation is identified by a new flag in the RP 331 Object, the Price Request bit (P) (to be assigned by IANA, 332 recommended bit 2). The PCC requesting the PCE for a route offer 333 computation will set the P bit in the corresponding RP object in the 334 PCReq. 336 Since all the other PCReq objects and parameters are left unchanged, 337 the route offer computation constraints and parameters are similar to 338 the ones defined for standard path computations. 340 0 1 2 3 341 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 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | |P| Flags |O|B|R| Pri | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Request-ID-number | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | | 348 // Optional TLVs // 349 | | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 Figure 2: Modified RP object with P bit (Price Request bit) 354 4.1.1. Processing rules 356 A PCC sets the Price Request bit in the PCReq RP object to inform the 357 PCE that the incoming PCReq message is requesting for a price 358 computation. On the other hand, when a PCE receives a PCReq message 359 it checks the Price Request bit in the RP object to distinguish 360 between a price computation and a standard path computation. 362 When the Price Request bit is set, the PCE computes a set of route 363 offers for the given endpoints by also calculating the respective 364 route prices according to the constraints specified by the PCC in 365 terms of end points, bandwidth, metrics, load balancing, etc. and the 366 policies configured within the PCE. In case the Price Request bit is 367 set, but the PCE does not support the price computation function, it 368 must return a PCErr message with Error-Type "Capability not 369 supported" as per [RFC5440]. 371 4.2. PRICE-INFO Object 373 The price computation performed by the PCE is delivered to the PCC in 374 a new defined optional object, the PRICE-INFO object, carried in the 375 path attribute-list section of the PCRep message. The PRICE-INFO 376 object, when present, encodes the set of route offers computed by the 377 PCE for the end-to-end connectivity service requested by the PCC. 378 More PRICE-INFO objects can be included in a PCRep message to provide 379 more than one price for the same service. 381 ::= 382 384 where: 386 ::=[] 388 ::= 389 [] 390 [] 391 [] 393 ::=[] 395 ::= 397 where: 399 ::= [] 400 [] 401 [] 402 [] 403 [] 404 ::=[] 405 ::=[PRICE-INFO-list] 407 The PRICE-INFO Object-Class is to be assigned by IANA (recommended 408 value is 202). 410 The PRICE-INFO Object-Type is to be assigned by IANA (recommended 411 value is 1). 413 The PRICE-INFO object format is shown in the following figure. 415 0 1 2 3 416 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 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | priceModel | currencyType | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 |priceUnitTime |priceUnitData | capUnitTime | capUnitData | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | priceValue | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | capValue | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 EDITOR NOTE: Usage of TLVs within PRICE-INFO could be considered, e.g 428 to make the object more flexible and/or add multiple caps. For the 429 applicability to inter-carrier frameworks one cap is commonly enough, 430 and usage of TLVs would just increase overhead on the object. 432 Figure 3: PRICE-INFO object 434 priceModel (8 bits): Indicates the cost model applied to compute the 435 price. The following types of price models are currently defined: 437 o Pay-as-you-go (0x01) 439 o Flat (0x02) 441 currencyType (24 bits): Indicates the currency used to express the 442 price. It is expressed with the 3 characters of the currency codes 443 specified by the ISO-4217 standard ([ISO4217], e.g. EUR, USD, etc.). 445 priceUnitTime (8 bits): Indicates the time interval for a unitary 446 price value. The following types are currently defined for the time 447 unit: 449 o None (0x00) 451 o Minute (0x01) 453 o Hour (0x02) 455 o Day (0x03) 457 o Week (0x04) 459 o Month (0x05) 460 o Year (0x06) 462 priceUnitData (8 bits): Indicates the data volume for a unitary price 463 value. The following types are currently defined for the data unit: 465 o None (0x00) 467 o KB (0x01) 469 o MB (0x02) 471 o GB (0x03) 473 o TB (0x04) 475 capUnitTime (8 bits): Indicates the time unit used to express the Cap 476 Value (same types of priceUnitTime are defined). 478 capUnitData (8 bits): Indicates the data volume unit used to express 479 the Cap Value (same types of priceUnitData are defined). 481 priceValue (32 bits): Indicates the value of the price. 483 capValue (32 bits): Indicates the value of the upper bound for this 484 service offer (e.g. max data volume or time length) for which the 485 given offer is valid at the specified price. For example, a 10 EUR/ 486 month price with 15GB cap in Flat model would correspond to: 488 o priceModel = 2 (Flat) 490 o currencyType = "EUR" 492 o priceUnitTime = 5 (Month) 494 o priceUnitData = 0 (None) 496 o priceValue = 10 498 o capUnitTime = 5 (Month) 500 o capUnitData = 3 (GB) 502 o capValue = 15 504 4.2.1. Processing rules 506 In case of successful route offers computation, the requested PCE 507 replies to the requesting PCC with a PCRep message that must include 508 at least one PRICE-INFO object. Multiple PRICE-INFO objects can be 509 included in the PCReq when more than one route offer is identified by 510 the PCE for the requested end-to-end connectivity service. In 511 particular each PRICE-INFO object identifies a specific route offer: 512 for instance, for the same carrier connectivity services two 513 different route offers could be identified by the PCE, one for a with 514 a Flat Price Model, and another with a Pay-as-you-go Price Model. 515 All the PRICE-INFO objects carried in the PCReq message refer to the 516 same ERO computed by the PCE: the ERO object, as a mandatory PCEP 517 object, is always included in the PCReq message and along with the 518 route offers identification build the extended PCReq path section in 519 case of price computation (ref. Figure 3). On the other hand, in 520 the case of unsuccessful price computation, the PCRep message must 521 not carry any PRICE-object, while a NO-PATH object is included as 522 specified in [RFC5440] for the standard path computation procedure. 524 5. Acknowledgements 526 This work has been partially supported by the European Commission 527 through the FP7 ICT Integrated Project ETICS (Economics and 528 Technologies for Inter-Carrier Services, contract no: INFSO-ICT- 529 248567). 531 Authors would like to thank R. Douville and N. Le Sauze from Alcatel- 532 Lucent, and J. Meuric and O. Dugeon from France Telecom for the 533 preliminary discussions of this work. 535 6. IANA Considerations 537 6.1. PRICE INFO Object 539 IANA manages the PCEP Objects code point registry (see [RFC5440]). 540 This is maintained as the "PCEP Objects" sub-registry of the "Path 541 Computation Element Protocol (PCEP) Numbers" registry. This document 542 defines a new PCEP object, the PRICE-INFO object, to be carried in 543 PCRep messages. 545 IANA should make the following allocation for PRICE-INFO object: 547 Object Name Object Name Reference 548 Class Type 549 -------------------------------------------------------------------- 550 202 PRICE-INFO 1 PRICE-INFO This Doc 552 6.2. RP Object Flag 554 A new flag of the RP object (specified in [RFC5440]) is defined in 555 this document. IANA maintains a registry of RP object flags in the 556 "RP Object Flag Field" sub-registry of the "Path Computation Element 557 Protocol (PCEP) Numbers" registry. 559 IANA should make the following allocation: 561 Bit Description Reference 562 ------------------------------------------------ 563 2 Supply PRICE INFO on response This Doc 565 7. Security Considerations 567 PCEP security mechanisms are described in [RFC5440] and are used to 568 secure entire PCEP messages. Nothing in this document changes the 569 message flows or introduces any new messages; therefore, the security 570 mechanisms set out in [RFC5440] continue to be applicable. This 571 document introduces a single new object that may optionally be 572 carried on PCEP messages and will be automatically secured using the 573 mechanisms described in [RFC5440]. If a PCEP message is vulnerable 574 to attack (for example, because the security mechanisms are not 575 used), then the price request bit in RP and the PRICE-INFO object 576 could be used as part of an attack; however, it is likely that other 577 objects will provide far more significant ways of attacking a PCE or 578 PCC in this case. 580 8. References 582 8.1. Normative References 584 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 585 Requirement Levels", BCP 14, RFC 2119, March 1997. 587 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 588 (PCE) Communication Protocol (PCEP)", RFC 5440, 589 March 2009. 591 8.2. Informative References 593 [ETICS] FP7 ICT ETICS project, "Deliverable D5.2 - ETICS Draft 594 Detailed specification of the inter-carrier service 595 delivery system", https://www.ict-etics.eu/fileadmin/ 596 documents/publications/deliverables/D5_2-V5_0-final.pdf, 597 2011. 599 [I-D.ietf-pce-hierarchy-fwk] 600 Farrel, A. and D. King, "The Application of the Path 601 Computation Element Architecture to the Determination of a 602 Sequence of Domains in MPLS and GMPLS", 603 draft-ietf-pce-hierarchy-fwk-00 (work in progress), 604 October 2011. 606 [IPSPHERE] 607 TMFORUM, "IPsphere Framework: General Requirements and 608 Technical Architecture (Release 2.0)", TR158 version 1.1, 609 July 2010. 611 [ISO4217] ISO 4217, "Currency and funds name and code elements", 612 International Organization for Standardization 613 (ISO) http://www.iso.org/iso/currency_codes_list-1. 615 [ITU-T M.3010] 616 ITU-T M.3010, "Principles for a telecommunications 617 management network", ITU-T Recommendation M.3010 , 618 February 2000. 620 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 621 Element (PCE)-Based Architecture", RFC 4655, August 2006. 623 Authors' Addresses 625 Gino Carrozzo 626 Nextworks 627 via Livornese 1027 628 Pisa, 56122 629 Italy 631 Phone: +39 050 3871 600 632 Email: g.carrozzo@nextworks.it 633 Giacomo Bernini 634 Nextworks 635 via Livornese 1027 636 Pisa, 56122 637 Italy 639 Phone: +39 050 3871 600 640 Email: g.bernini@nextworks.it 642 Giada Landi 643 Nextworks 644 via Livornese 1027 645 Pisa, 56122 646 Italy 648 Phone: +39 050 3871 600 649 Email: g.landi@nextworks.it