PCE Working Group G. Carrozzo Internet-Draft G. Bernini Intended status: Experimental G. Landi Expires: September 5, 2012 Nextworks March 4, 2012 PCEP extensions for the computation of route offers with price draft-carrozzo-pce-pcep-route-price-00 Abstract The PCE defined in RFC4655 is a functional entity generally confined in the control plane to elaborate explicit optimal routes with related costs to be installed as [G]MPLS tunnels/LSPs. The resulting route cost(s)/metric(s) are Traffic Engineering indicators used by the network administrator (carrier) to optimize the usage of its network resources. In this document a framework for the usage of PCE in cooperation with the Network Service and Business Plane (NSBP) is proposed, along with related PCEP extensions. The NSBP invokes this extended PCE (service PCE) to trigger the computation of network service offers with related price information. The price of a network connectivity service generally depends on strategic factors, but it could also be influenced by the amount of mobilized network resources (along the route), the ingress/egress interfaces/PoPs, etc. Therefore, it could be provided by an extended service-PCE as an additional route information. This document focuses on the extensions to the PCEP protocol in support of the computation of route prices for intra- and inter- domain network connectivity services. Mechanisms for elaborating and retrieving price information in the PCE are vendor-specific and out of the scope of this document. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any Carrozzo, et al. Expires September 5, 2012 [Page 1] Internet-Draft PCEP PRICE INFO March 2012 time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 5, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Carrozzo, et al. Expires September 5, 2012 [Page 2] Internet-Draft PCEP PRICE INFO March 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology used in this document . . . . . . 4 3. Service-PCE framework . . . . . . . . . . . . . . . . . . . . 6 3.1. Route cost vs. route price . . . . . . . . . . . . . . . . 8 4. PCEP protocol extensions . . . . . . . . . . . . . . . . . . . 8 4.1. Price Request bit . . . . . . . . . . . . . . . . . . . . 8 4.1.1. Processing rules . . . . . . . . . . . . . . . . . . . 10 4.2. PRICE-INFO Object . . . . . . . . . . . . . . . . . . . . 10 4.2.1. Processing rules . . . . . . . . . . . . . . . . . . . 14 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6.1. PRICE INFO Object . . . . . . . . . . . . . . . . . . . . 14 6.2. RP Object Flag . . . . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Carrozzo, et al. Expires September 5, 2012 [Page 3] Internet-Draft PCEP PRICE INFO March 2012 1. Introduction Carriers usually deploy traffic engineering (TE) technologies coupled with network control plane (CP) protocol suites, such as the Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS), to offer value added network connectivity services to their customers. The constraint-based route computation is a key function for these connectivity services, and it is executed by the Path Computation Element (PCE) functional entity. The PCE architecture is defined in [RFC4655] and allows the computation of network routes based on a network graph; the graph is derived from the controlled network with various means (e.g. IGP/EGP, other proprietary interfaces, etc.), and can contain multi-domain, multi-region/multi-layer topology information. In general, the PCE function is completely confined in the control plane to compute optimal inter-domain constrained explicit routes (ERO) for (G)MPLS TE LSPs/tunnels. However, the computation and instantiation of these tunnels in the Transport Plane (TP) is preceded by mandatory phases of service/product offering, offer composition and negotiation, which involve the service supplier(s) and the final service end-customer (see TMF IPSPHERE Framework [IPSPHERE]). These service phases are generally handled at the management and business planes (OSS/BSS) only. However, control plane functionalities like the PCE ones can definitely support in the definition/specification of network connectivity offers within a carrier network domain. This document briefly introduces a framework for the usage of a PCE for route offers (Service-PCE) and describes some extensions to the PCEP protocol that allow the Network Service and Business Plane (NSBP) to request the Service-PCE for the computation of network service offers with related price information. Mechanisms for elaborating and retrieving price information in the Service-PCE are assumed to be vendor-specific and out of the scope of this I-D. 2. Conventions and Terminology used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Moreover, the following terminology is used in this document. Carrozzo, et al. Expires September 5, 2012 [Page 4] Internet-Draft PCEP PRICE INFO March 2012 BSS: Business Support System. Control Plane (CP): The CP performs the basic functions of signaling, routing and resource discovery. These are essential operations which allow for the automation of higher-level network functions like connection establishment (i.e., path computation, resource availability, verification and connection set-up and tear-down), reconfiguration of signaled connections, and connection restoration. FCAPS: Fault, Configuration, Accounting, Performance, and Security management. GMPLS: Generalized Multiprotocol Label Switching. Management Plane: The network management plane performs functions like alarm reporting, system configuration and connection provisioning for the network data and network control planes. The complexity of the network management plane strongly depends on the capabilities of the network control plane. In general the network management plane performs FCAPS functionalities (Fault, Configuration, Accounting, Performance, and Security management). Where applicable the network management plane follows the TMN architecture as described in [ITU-T M.3010]. NMS: Network Management System. Network Service and Business Plane (NSBP): This plane refers to functions related to the management and handling of network product offerings, service specifications and service instances. This can range from service specification and offer creation, to their publishing, service instance request and handling. Functions of this plane may also include customer-relationship management and various functions related to operations support. OSS: Operation Support System. Parent PCE: As per [I-D.ietf-pce-hierarchy-fwk], a PCE responsible for selecting a path across a parent domain and any number of child domains by coordinating with child PCEs and examining a topology map that shows domain inter-connectivity. PCC: Path Computation Client: any client application requesting a path computation to be performed by a Path Computation Element. Carrozzo, et al. Expires September 5, 2012 [Page 5] Internet-Draft PCEP PRICE INFO March 2012 PCE: Path Computation Element. An entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints. PCEP: Path Computation Element Communication Protocol. Service PCE: A parent PCE interfaced to the NSBP for the computation of route offers with price information. PCEP protocol is used to implement the interface between NSBP and the Service PCE. TE: Traffic Engineering. TED: Traffic Engineering Database. Transport Plane (TP): The transport plane performs various framing, forwarding or switching, and the transportation of data blocks to specific destinations. This plane identifies the set of data bearing transport resources (possibly grouped into domains on a policy or technology basis). 3. Service-PCE framework The NSBP includes all the functions related to the management and handling of network connectivity product offers, service specifications and service instances from an operational and business perspective ([IPSPHERE] [ETICS]). In particular, the NSBP controls/ coordinates the service specification and offer creation, publishes these product offers, composes different offers for an end-to-end service, and eventually triggers the instantiation and operation of the final service The constraint-based route computation functions provided by a PCE can be very useful for the network connectivity offer creation. In fact, the PCE can implement constraint-based route selection procedures providing the requesting client also with route price information tight to the route to be followed, the ingress/egress endpoints, some policy data, etc. A Path Computation Client (PCC) could be integrated in the NSBP, to request route offer computation either on-demand (i.e. connectivity offer tailored to a specific customer request at the NSBP interfaces) or in-advance (i.e. pre-computation of a connectivity offer to be stored in a catalogue-like function of the NSBP). The standard PCE route request/response mechanisms based on PCEP is applied in the Service- PCE as per [RFC4655] and [RFC5440]. Carrozzo, et al. Expires September 5, 2012 [Page 6] Internet-Draft PCEP PRICE INFO March 2012 Moreover, the Service-PCE better adapts to extend the concept and functionalities of a parent PCE ([I-D.ietf-pce-hierarchy-fwk]), as it can be used for a group of child technological/administrative domains within a carrier/Autonomous System, and the produced route offers can be in the form of sparse multi-domain EROs. ----------------------------------------------------------------- | | | NETWORK SERVICE AND BUSINESS PLANE | | ------- | | | PCC | | | ------- | --------------------------------|-------------------------------- | | PCEP --------------------------------|-------------------------------- | Domain 4 (AS) | | | ------------- | | | Service-PCE | | | ------------- | | / | \ | | PCEP ~~~~/~~~~~~~~~~~~|~~~~~\~~~~ PCEP | | / | \ | | ---------------- / ------------|--- \ --------------- | | | Domain 1 |/ | Domain 2 | | |\ Domain 3 | | | | / | | | | \ | | | | ----- /| | ----- | | \ ----- | | | | |PCE 1|/ | | |PCE 2| | | \|PCE 3| | | | | ----- | | ----- | | ----- | | | | | | | | | | | | ----| |---- ----| |---- | | | | |BN11+---+BN21| |BN23+---+BN31| | | | | - ----| |---- ----| |---- - | | | | |S| | | | | |D| | | | | - ----| |---- ----| |---- - | | | | |BN12+---+BN22| |BN24+---+BN32| | | | | ----| |---- ----| |---- | | | ---------------- ---------------- ---------------- | ----------------------------------------------------------------- Figure 1: Service-PCE and NSBP in the hierarchical model Carrozzo, et al. Expires September 5, 2012 [Page 7] Internet-Draft PCEP PRICE INFO March 2012 3.1. Route cost vs. route price The route cost(s)/metric(s) are Traffic Engineering indicators used by the network administrator (carrier) to optimize the usage of its network resources. The route price is a different information with respect to the route cost, as it refers to the customer-supplier interaction at the business level for offering, negotiating and, eventually, instantiating a network connectivity service (e.g. a [G]MPLS LSP). The price of a network connectivity service generally depends on strategic factors, but it could also be influenced by the amount of mobilized network resources (along the route), the ingress/egress interfaces/PoPs, etc. Therefore, it could be provided by an extended PCE (i.e. the Service- PCE) as an optional route information, by using a mix of topology data, explicit route and policy data (both local and external to the service-PCE). 4. PCEP protocol extensions The procedures and encoding adopted by a PCC and a service-PCE to handle the route offer computation with price information are described in this section. Two different set of extensions are defined for the PCEP for route offer computations: one for the PCEP Request (PCReq) message, and another for the PCEP Reply (PCRep) message. 4.1. Price Request bit The format of a PCReq message for the request of a route offer computation is unchanged with respect to [RFC5440] and subsequent extensions. Carrozzo, et al. Expires September 5, 2012 [Page 8] Internet-Draft PCEP PRICE INFO March 2012 ::= [] where: ::=[] ::=[] ::= | where: ::= [] [] [] [] [] [] ::= The route offer computation is identified by a new flag in the RP Object, the Price Request bit (P) (to be assigned by IANA, recommended bit 2). The PCC requesting the PCE for a route offer computation will set the P bit in the corresponding RP object in the PCReq. Since all the other PCReq objects and parameters are left unchanged, the route offer computation constraints and parameters are similar to the ones defined for standard path computations. Carrozzo, et al. Expires September 5, 2012 [Page 9] Internet-Draft PCEP PRICE INFO March 2012 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |P| Flags |O|B|R| Pri | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request-ID-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLVs // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Modified RP object with P bit (Price Request bit) 4.1.1. Processing rules A PCC sets the Price Request bit in the PCReq RP object to inform the PCE that the incoming PCReq message is requesting for a price computation. On the other hand, when a PCE receives a PCReq message it checks the Price Request bit in the RP object to distinguish between a price computation and a standard path computation. When the Price Request bit is set, the PCE computes a set of route offers for the given endpoints by also calculating the respective route prices according to the constraints specified by the PCC in terms of end points, bandwidth, metrics, load balancing, etc. and the policies configured within the PCE. In case the Price Request bit is set, but the PCE does not support the price computation function, it must return a PCErr message with Error-Type "Capability not supported" as per [RFC5440]. 4.2. PRICE-INFO Object The price computation performed by the PCE is delivered to the PCC in a new defined optional object, the PRICE-INFO object, carried in the path attribute-list section of the PCRep message. The PRICE-INFO object, when present, encodes the set of route offers computed by the PCE for the end-to-end connectivity service requested by the PCC. More PRICE-INFO objects can be included in a PCRep message to provide more than one price for the same service. Carrozzo, et al. Expires September 5, 2012 [Page 10] Internet-Draft PCEP PRICE INFO March 2012 ::= where: ::=[] ::= [] [] [] ::=[] ::= where: ::= [] [] [] [] [] ::=[] ::=[PRICE-INFO-list] The PRICE-INFO Object-Class is to be assigned by IANA (recommended value is 202). The PRICE-INFO Object-Type is to be assigned by IANA (recommended value is 1). The PRICE-INFO object format is shown in the following figure. Carrozzo, et al. Expires September 5, 2012 [Page 11] Internet-Draft PCEP PRICE INFO March 2012 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | priceModel | currencyType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |priceUnitTime |priceUnitData | capUnitTime | capUnitData | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | priceValue | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | capValue | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ EDITOR NOTE: Usage of TLVs within PRICE-INFO could be considered, e.g to make the object more flexible and/or add multiple caps. For the applicability to inter-carrier frameworks one cap is commonly enough, and usage of TLVs would just increase overhead on the object. Figure 3: PRICE-INFO object priceModel (8 bits): Indicates the cost model applied to compute the price. The following types of price models are currently defined: o Pay-as-you-go (0x01) o Flat (0x02) currencyType (24 bits): Indicates the currency used to express the price. It is expressed with the 3 characters of the currency codes specified by the ISO-4217 standard ([ISO4217], e.g. EUR, USD, etc.). priceUnitTime (8 bits): Indicates the time interval for a unitary price value. The following types are currently defined for the time unit: o None (0x00) o Minute (0x01) o Hour (0x02) o Day (0x03) o Week (0x04) o Month (0x05) Carrozzo, et al. Expires September 5, 2012 [Page 12] Internet-Draft PCEP PRICE INFO March 2012 o Year (0x06) priceUnitData (8 bits): Indicates the data volume for a unitary price value. The following types are currently defined for the data unit: o None (0x00) o KB (0x01) o MB (0x02) o GB (0x03) o TB (0x04) capUnitTime (8 bits): Indicates the time unit used to express the Cap Value (same types of priceUnitTime are defined). capUnitData (8 bits): Indicates the data volume unit used to express the Cap Value (same types of priceUnitData are defined). priceValue (32 bits): Indicates the value of the price. capValue (32 bits): Indicates the value of the upper bound for this service offer (e.g. max data volume or time length) for which the given offer is valid at the specified price. For example, a 10 EUR/ month price with 15GB cap in Flat model would correspond to: o priceModel = 2 (Flat) o currencyType = "EUR" o priceUnitTime = 5 (Month) o priceUnitData = 0 (None) o priceValue = 10 o capUnitTime = 5 (Month) o capUnitData = 3 (GB) o capValue = 15 Carrozzo, et al. Expires September 5, 2012 [Page 13] Internet-Draft PCEP PRICE INFO March 2012 4.2.1. Processing rules In case of successful route offers computation, the requested PCE replies to the requesting PCC with a PCRep message that must include at least one PRICE-INFO object. Multiple PRICE-INFO objects can be included in the PCReq when more than one route offer is identified by the PCE for the requested end-to-end connectivity service. In particular each PRICE-INFO object identifies a specific route offer: for instance, for the same carrier connectivity services two different route offers could be identified by the PCE, one for a with a Flat Price Model, and another with a Pay-as-you-go Price Model. All the PRICE-INFO objects carried in the PCReq message refer to the same ERO computed by the PCE: the ERO object, as a mandatory PCEP object, is always included in the PCReq message and along with the route offers identification build the extended PCReq path section in case of price computation (ref. Figure 3). On the other hand, in the case of unsuccessful price computation, the PCRep message must not carry any PRICE-object, while a NO-PATH object is included as specified in [RFC5440] for the standard path computation procedure. 5. Acknowledgements This work has been partially supported by the European Commission through the FP7 ICT Integrated Project ETICS (Economics and Technologies for Inter-Carrier Services, contract no: INFSO-ICT- 248567). Authors would like to thank R. Douville and N. Le Sauze from Alcatel- Lucent, and J. Meuric and O. Dugeon from France Telecom for the preliminary discussions of this work. 6. IANA Considerations 6.1. PRICE INFO Object IANA manages the PCEP Objects code point registry (see [RFC5440]). This is maintained as the "PCEP Objects" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry. This document defines a new PCEP object, the PRICE-INFO object, to be carried in PCRep messages. IANA should make the following allocation for PRICE-INFO object: Carrozzo, et al. Expires September 5, 2012 [Page 14] Internet-Draft PCEP PRICE INFO March 2012 Object Name Object Name Reference Class Type -------------------------------------------------------------------- 202 PRICE-INFO 1 PRICE-INFO This Doc 6.2. RP Object Flag A new flag of the RP object (specified in [RFC5440]) is defined in this document. IANA maintains a registry of RP object flags in the "RP Object Flag Field" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry. IANA should make the following allocation: Bit Description Reference ------------------------------------------------ 2 Supply PRICE INFO on response This Doc 7. Security Considerations PCEP security mechanisms are described in [RFC5440] and are used to secure entire PCEP messages. Nothing in this document changes the message flows or introduces any new messages; therefore, the security mechanisms set out in [RFC5440] continue to be applicable. This document introduces a single new object that may optionally be carried on PCEP messages and will be automatically secured using the mechanisms described in [RFC5440]. If a PCEP message is vulnerable to attack (for example, because the security mechanisms are not used), then the price request bit in RP and the PRICE-INFO object could be used as part of an attack; however, it is likely that other objects will provide far more significant ways of attacking a PCE or PCC in this case. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, Carrozzo, et al. Expires September 5, 2012 [Page 15] Internet-Draft PCEP PRICE INFO March 2012 March 2009. 8.2. Informative References [ETICS] FP7 ICT ETICS project, "Deliverable D5.2 - ETICS Draft Detailed specification of the inter-carrier service delivery system", https://www.ict-etics.eu/fileadmin/ documents/publications/deliverables/D5_2-V5_0-final.pdf, 2011. [I-D.ietf-pce-hierarchy-fwk] Farrel, A. and D. King, "The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS", draft-ietf-pce-hierarchy-fwk-00 (work in progress), October 2011. [IPSPHERE] TMFORUM, "IPsphere Framework: General Requirements and Technical Architecture (Release 2.0)", TR158 version 1.1, July 2010. [ISO4217] ISO 4217, "Currency and funds name and code elements", International Organization for Standardization (ISO) http://www.iso.org/iso/currency_codes_list-1. [ITU-T M.3010] ITU-T M.3010, "Principles for a telecommunications management network", ITU-T Recommendation M.3010 , February 2000. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. Authors' Addresses Gino Carrozzo Nextworks via Livornese 1027 Pisa, 56122 Italy Phone: +39 050 3871 600 Email: g.carrozzo@nextworks.it Carrozzo, et al. Expires September 5, 2012 [Page 16] Internet-Draft PCEP PRICE INFO March 2012 Giacomo Bernini Nextworks via Livornese 1027 Pisa, 56122 Italy Phone: +39 050 3871 600 Email: g.bernini@nextworks.it Giada Landi Nextworks via Livornese 1027 Pisa, 56122 Italy Phone: +39 050 3871 600 Email: g.landi@nextworks.it Carrozzo, et al. Expires September 5, 2012 [Page 17]