Internet Engineering Task Force Y. Wang Internet-Draft Simon Fraser University Intended status: Standards Track B. Zhuge Expires: May 5, 2016 H. Zhu Zhejiang Gongshang University C. Wu Zhejiang University November 2, 2015 An SDN Framework with Software-Defined Pricing (SDP) draft-zhuge-sdnrg-sdn-sdp-01 Abstract This document defines a notion called Software-Defined Pricing (SDP) and introduces it into a Software-Defined Networks (SDN) framework. The SDN system with SDP inside is expected to promote the efficiency on SDN resources usage and ease management for service providers. 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 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 May 5, 2016. Copyright Notice Copyright (c) 2015 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 Wang, et al. Expires May 5, 2016 [Page 1] Internet-Draft Abbreviated Title November 2015 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Software-Defined Pricing (SDP) . . . . . . . . . . . . . . . 2 3. SDN with SDP . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Adopting SDP in SDN . . . . . . . . . . . . . . . . . . . 4 3.2. Framework of SDN with SDP . . . . . . . . . . . . . . . . 6 4. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Informative References . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction Software-Defined Networks(SDN) is in the research process. With the idea of SDN, networking resources like switches, routers and types of Network Elements (NEs)are managed as kinds of virtual resources, forming virtual networks so as to provide rather flexible services to network users. In this research process, we noticed that how to price the services and the use of virtual network resources in an SDN is as critical as how the SDN is defined. We consider that it seems a precious idea to treat a service pricing mechanism as part of the SDN framework and to manage it in a software-defined way. Network service prices are traditionally determined by service providers in a rather rigid way, which lacks of flexibility and sometimes even fairness to resources users. By means of the idea of SDP, it is able to treat service pricing as a part of SDN, forming a service pricing model flexible to time, traffic and other network factors and status. In this way, it is expected to promote the efficiency of SDN resources usage and ease the management for service providers. 2. Software-Defined Pricing (SDP) Software-Defined Pricing (SDP) is an idea specific to network management, whose core is that the service prices of network resources are determined by means of software-defined algorithms and/ or mechanisms, which figure the prices according to various factors and status of the network resources. In contrast to SDP, service prices may be pre-determined rigidly by service providers. An SDP Protocol is an instance of SDP implementation shown in a way of protocol, which specifically defines algorithms and/or mechanisms Wang, et al. Expires May 5, 2016 [Page 2] Internet-Draft Abbreviated Title November 2015 to price specific services and use of network resources. An SDP protocol may be a private protocol if it is defined by a service provider personally, or a public protocol if defined publicly by standardization organizations. By use of the software-defined mechanism, SDP essentially supports automatic negotiations of prices in a pricing process. Automatic resource and price negotiation features a Guaranteed Service (GS). As a result, SDN with SDP essentially supports GS services. Network users must accept and abide by the network SDP protocol when they use the network resources and the services. An SDP protocol usually includes trading partners, trading content, obligations and other transaction costs. Service providers can make provisions for users in terms of workload and resource use. As an example, we present a typical process for an SDP protocol. When users expect to use resources from a virtual network by a service provider, users first query prices of various resources and services by means of the SDP protocol. The service provider returns the resource prices to users. Then, users will start up a price negotiation process with the service provider by use of the SDP protocol. Both the user and the service provider will proceed the price negotiation process based on their specific price negotiation algorithms. The negotiation process will be ended only from the user with the SDP protocol. It will end with an agreement is either met or not. The SDP protocol process is shown in Figure 1. Usually, in a negotiation algorithm, the user or the service provider are able to take into consideration of current network status and other network factors, which make the price negotiation process much more efficient and flexible than traditional pricing methods. +------+ + + +-----------+ | | | -----SDP protocol---->| -----------------+ | | | | | | search price | | | | | | <----SDP protocol-----|<-----------------+ | | | | | -----SDP protocol---->|------------------+ | service | | user | | | price negotiation| | sprovider | | | | <----SDP protocol-----|<-----------------+ | | | | | -----SDP protocol---->|------------------+ | | | | | | negotiation ends | | | | | | <----SDP protocol-----|<-----------------+ | | +------+ + + +-----------+ Figure 1: Process of an SDP Protocol Wang, et al. Expires May 5, 2016 [Page 3] Internet-Draft Abbreviated Title November 2015 To fulfill above process, an SDP protocol header may usually include fields like shown in Figure 2, where: o ID: the unique identifier of the protocol header. o Level: service priorities identified. o Expression: including one or more ITP(ID-Type-Properties) formats, where ID is the unique identifier of a resource, Type is the type of resource, Properties is the attributes of the resource. o TimeSpec: a structure of service time, mainly refers to the selection of the service period. o Price: the price of the transaction. o ContractTime: trading hours. o State: trading status with success or failure. +-----------------------------------------------------+ |ID|Level|Expression|TimeSpec|Price|ContractTime|State| +--------|----------|--------|------------------------+ | | | +-----------------+ V | +------------------------+ | | ID | Type | Properties | | +-----------|------------+ V | +------------------------------------+ | | Y/M/D | Mon-Fri/Weekend | 8:00-0:00| V +------------------------------------+ +----------------------------+ | rate | delay | shake | etc.| +----------------------------+ Figure 2: An SDP Protocol Header (TBD) 3. SDN with SDP 3.1. Adopting SDP in SDN SDP can be applied to SDN architecture well because of its natural software-defined feature. Wang, et al. Expires May 5, 2016 [Page 4] Internet-Draft Abbreviated Title November 2015 In SDN architecture, control plane and data plane are separated to achieve the segregation of the control and forwarding. A typical SDN architecture usually includes: application layer, control layer, and infrastructure (forwarding) layer. To adopt SDP in SDN, an SDP module is applied. An SDP module implements the SDP protocol and corresponding negotiation algorithms/mechanisms. An SDP module can be applied to any layer in the SDN, where resources need to be priced. In this way, theoretically, all kinds of network resources and services can be programmed in terms of use prices as well as resources functions. This makes SDN more complete regarding its software-defining characters. In SDN application market, resource providers and resource consumers actually hardly know each other fully for the value of resources and services. Hence, the trade between them is an information asymmetry game. To take this into consideration, an SDP module with its protocol and associated negotiation mechanisms applied to an SDN system is usually of the following features: o 1) An SDP module can be distributed across parts of SDN system, to get the optimal level of service quality under budget constraints of service consumers. As a result, the SDP module usually further contains a pricing module and a trading module, used for pricing and trading of resources respectively. With an SDP module, users can submit their requirements according to their budgets at the SDN application layer to SDN control layer. Then, the SDN control layer can get results of optimal resource services based on user's budget. o 2) An SDP module usually includes an auto-negotiation mechanism. During the trading process, resource providers first get the price based on the price algorithm and/or mechanism, and present them to resources consumers. If consumers are not satisfied with the prices, process of negotiation with auto-negotiation algorithm or mechanism will be triggered. o 3) With SDP, use of resources and their prices are not unique anymore. Different resources providers may provide different prices even for the same resources. SDP module may query different resources providers for optimal prices. This process usually takes place at the SDP protocol stage of searching prices. o 4) In an SDP transaction, an SDN application usually act as a resource provider to end users. Whereas, at the same time, it can also act as resource consumers to SDN control plane as well as SDN forwarding plane. It sells resources to end users. At the same time, it may buy or hire resources from SDN core systems. All these can be done by use of SDP module. Wang, et al. Expires May 5, 2016 [Page 5] Internet-Draft Abbreviated Title November 2015 o 5) With a time attribute, SDP can respectively support SDN applications well for temporary term users or long term users regarding optimal use prices. 3.2. Framework of SDN with SDP As mentioned, a typical SDN framework usually includes Application Layer, Control Layer, and Infrastructure (forwarding) Layer. In SDN Application Layer, things like virtual servers and other SDN personalized services will be presented as individual SDN Apps. Based on the idea above on adopting SDP to SDN, a typical framework of an SDN system which adopts SDP module is as shown in Figure 3. In this framework, an SDN module is "with SDP" actually represents that this module includes an SDP module inside and makes the module support software-defined pricing function. SDP modules may exist in each SDN App module, each SDN network service module, and each SDN network elements. Note that, SDN Apps communicate with SDN controllers via an uniform public SDN northern interface protocol (to be defined by SDN communities or IETF?) or via private individual APIs. Either should require that the northern interface protocol or the API must support SDP protocol to support the SDN with SDP. Also note that, SDN control layer is defined to communicate with SDN infrastructural forwarding layer by means of uniformly defined SDN southern interface protocols like ForCES, OpenFlow, etc. To support SDN with SDP, SDP protocol must be designed supportable by these protocols for messaging purpose. This may become a key question for the design of an SDP protocol. (TBD) Wang, et al. Expires May 5, 2016 [Page 6] Internet-Draft Abbreviated Title November 2015 +------------------------------------------------------+ SDN |+----------------++----------------++----------------+| Application|| App (With SDP) || App (With SDP) || App (With SDP) || Layer |+----------------++----------------++----------------+| +------------------------------------------------------+ A | V +-----------------------------------------------------+ | | |API or SDN Northern Interface Protocols to be defined| | | +-----------------------------------------------------+ A | V +------------------------------------------------------+ SDN |+-------------------------++-------------------------+| Control ||Network Service(With SDP)||Network Service(With SDP)|| Layer |+-------------------------++-------------------------+| +------------------------------------------------------+ A | V +-----------------------------------------------------+ | | | SDN southern interface protocols like | | ForCES, OpenFlow, et al. | | | +-----------------------------------------------------+ A | V +------------------------------------------------------+ SDN |+-------------------------++-------------------------+| Forwarding ||Network Element(With SDP)||Network Element(With SDP)|| Layer |+-------------------------++-------------------------+| +------------------------------------------------------+ Figure 3: An SDN Framework with SDP As another example, we try to present an SDN application which uses SDP to access network resources so as to get optimal resources use price. We call the SDN application a 'Chat' App, which is to construct a social App platform to connect, communicate and share among people and things by means of Guaranteed-Service (GS) rather than Best-Efforts (BE) services to users. Hence, the App needs to Wang, et al. Expires May 5, 2016 [Page 7] Internet-Draft Abbreviated Title November 2015 hire network resources from cloud network service providers to provide virtual server and Guaranteed Service (GS) resources. Fig 4 shown the process for 'Chat' to access the GS Resources by use of SDP. 'Chat' client and 'Chat' Server makes service agreement via SDP module. 'Chat' server may be implemented as a virtual server, whose pricing is also implemented by SDP module. Further more, resources to support the virtual server and the 'chat' message forwarding are used based on SDP negotiations. As shown inFigure 4 , in this case, SDN controller inside the virtual server of 'chat' may send requests to multiple cloud platforms by SDP module(such as Sina cloud, Baidu cloud and Ali cloud in the figure). All the cloud service providers return with resource prices, and SDN controller inside the 'chat' server select or negotiate with the cloud service providers. SDN controller finally may select or get a successful or failed negotiation results and returns to the 'chat' client via SDP protocols. As a result, a transaction for a GS service pricing ends. Wang, et al. Expires May 5, 2016 [Page 8] Internet-Draft Abbreviated Title November 2015 +---------------------+ | 'Chat' client | | ( With SDP ) | +---------------------+ A | V +---------------------+ | 'Chat' server | | ( With SDP ) | +---------------------+ A | V +---------------------+ | virtual server | | ( With SDP ) | +---------------------+ A | V +---------------------+ | SDN controller | | ( With SDP ) | +---------------------+ A | +----------------------------------------------+ | | | V V V +----------------+ +---------------+ +-------------+ | Sina cloud | | Baidu cloud | | Ali cloud | | (With SDP) | | (With SDP ) | | (With SDP | +----------------+ +---------------+ +-------------+ Figure 4: The process for 'Chat' accessing resources by use of SDP 4. Security TBD 5. IANA Considerations This document has no actions for IANA. Wang, et al. Expires May 5, 2016 [Page 9] Internet-Draft Abbreviated Title November 2015 6. Informative References [China-Communications] Zhuge, B., Deng, L., Dai, G., Wan, L., Wang, W., and J. Lan, "Resource Scheduling Algorithm and Ecnomic Model in ForCES Networks.China Communications", 2014. [ONF-White-Paper] Fundation O N., "Software-defined networking: The new norm for networks", 2012. [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, DOI 10.17487/RFC7426, January 2015, . [Telecommunications-Science] Zhuge, B., Wang, B., and Y. Wang, "Architecture of SDN applications based on Software-Defined price", 2015. Authors' Addresses Yining Wang Simon Fraser University 8888 University Drive Burnaby Canada Phone: +1 (778) 885-0009 Email: ywa165@sfu.ca Bin Zhuge Zhejiang Gongshang University 18 Xuezheng Str., Xiasha University Town Hangzhou 310018 P.R.China Phone: +86 571 28877723 Email: zhugebin@zjsu.edu.cn Wang, et al. Expires May 5, 2016 [Page 10] Internet-Draft Abbreviated Title November 2015 Hua Zhu Zhejiang Gongshang University 18 Xuezheng Str., Xiasha University Town Hangzhou 310018 P.R.China Phone: +86 571 28877723 Email: zhuhua9114@163.com Chunming Wu Zhejiang University 866 Yuhangtang Road Hangzhou 310027 P.R.China Phone: +86 571 87951916 Email: wuchunming@zju.edu.cn Wang, et al. Expires May 5, 2016 [Page 11]