Internet Engineering Task Force B. Zhuge
Internet-Draft Zhejiang Gongshang University
Intended status: Standards Track Y. Wang
Expires: November 4, 2016 Simon Fraser University
H. Zhu
W. Wang
Zhejiang Gongshang University
May 3, 2016
An SDN Framework with Software-Defined Pricing (SDP)
draft-zhuge-sdnrg-sdn-sdp-02
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 November 4, 2016.
Copyright Notice
Copyright (c) 2016 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
Zhuge, et al. Expires November 4, 2016 [Page 1]
Internet-Draft Abbreviated Title May 2016
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. The Trading between the Layers . . . . . . . . . . . . . . . 9
5. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Informative References . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
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.
Zhuge, et al. Expires November 4, 2016 [Page 2]
Internet-Draft Abbreviated Title May 2016
An SDP Protocol is an instance of SDP implementation shown in a way
of protocol, which specifically defines algorithms and/or mechanisms
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
Zhuge, et al. Expires November 4, 2016 [Page 3]
Internet-Draft Abbreviated Title May 2016
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.
Zhuge, et al. Expires November 4, 2016 [Page 4]
Internet-Draft Abbreviated Title May 2016
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.
Zhuge, et al. Expires November 4, 2016 [Page 5]
Internet-Draft Abbreviated Title May 2016
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
Applications. 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, the SDP-App includes an SDP
module inside and makes the module support software-defined pricing
function.
SDP-App may exist in each layer of the SDN framework. Note that, SDN
Application communicates with SDN controllers via the AD-SAL and
Service Interface.Either should require that the AD-SAL and Service
Interface must support SDP protocol to support the SDN with SDP.
Also note that, SDN Control Layer includes the network service, SDP-
App, and control abstraction Layer(CAL), it is defined to communicate
with SDN forwarding layer by means of the resource abstraction
layer(RAL) and the 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. The SDN Forwarding Layer includes the network element, and
SDP-App. It is exposed via the Resource Abstraction Layer (RAL),
which may be expressed by one or more abstraction models.
(TBD)
Zhuge, et al. Expires November 4, 2016 [Page 6]
Internet-Draft Abbreviated Title May 2016
o--------------------------------o
| |
| +-------------+ +----------+ |
| | Application | | SDP-App | |
| +-------------+ +----------+ |
| Application Layer |
o---------------Y----------------o
|
*-----------------------------Y---------------------------------*
| Application-Driven Services Abstraction Layer (AD-SAL) |
*-----------------------------Y---------------------------------*
|
|Service
|Interface
|
o-----------------------------Y--------------------------------o
| Control | Layer |
| +----------Y--------+ +---------+ |
| | Network Service | | SDP-App | |
| +----------Y--------+ +----Y----+ |
| | | |
| *------------Y----------------Y------* |
| | Control Abstraction Layer (CAL) | |
| *------------Y-----------------------* |
| | |
o-----------------------------|--------------------------------o
|
| Southbound
| Interface
|
*-----------------------------Y---------------------------------*
| Resource Abstraction Layer (RAL) |
*-----------------------------Y---------------------------------*
| | |
| o--------Y-----------o +----------+ |
| | Network Element | | SDP-App | |
| o--------------------o +----------+ |
| Forwarding 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
Zhuge, et al. Expires November 4, 2016 [Page 7]
Internet-Draft Abbreviated Title May 2016
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.
Zhuge, et al. Expires November 4, 2016 [Page 8]
Internet-Draft Abbreviated Title May 2016
+---------------------+
| '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. The Trading between the Layers
As shown in Figure 5A complete SDN environment is made up of
application layer, control layer, data forwarding plane, if regard
SDN environment as an economy market ,Then corresponding to the three
layers structure of SDN environment, the economy market can be
divided into: user layer, trading platform and provider layer. But
each layer is embedded with the pricing model and consumption pattern
which is apply to this layer , the communication between each other
is accomplished by special protocol, each of them is independent but
closely linked.In application layer, there are many users, the users
Zhuge, et al. Expires November 4, 2016 [Page 9]
Internet-Draft Abbreviated Title May 2016
were independent of each other, and they belonged to different
platforms.In control layer there are multiple platforms, on the two
ends of platform respectively connected to different users and
providers, the existence of multiple platforms can solve the monopoly
of a single platform and the problem that users and providers'choice
unicity.In fowarding layer,there are many providers, they can offer
different types of resources for each platform.
*------------------------------------------------------------------------*
|Application +--------------+ +---------------+ +---------------+ |
| Layer | Application 1| | Application 2 | ... | Application n | |
| +--------------+ +---------------+ +---------------+ |
*--------------Y-Y-Y---------------Y-Y--Y--------------------Y--Y--Y-----*
| | | +-------------+ | | +---------------+ | |
| | | | +-----------|--|----|------------------+ |
| | +-|---|-----------|--|----|----------------+ |
| +---|---|-------+ | +----|-----------+ | |
| | | | | | | | |
*--------------V-----V---V-------V---V-------V-----------V----V----V-----*
| Control +--------------+ +---------------+ +---------------+ |
| Layer |Control Plane1| |Control Plane2 | ... |Control Plane n| |
| +--------------+ +---------------+ +---------------+ |
*--------------Y-Y-Y---------------Y-Y--Y--------------------Y--Y--Y-----*
| | | +-------------+ | | +---------------+ | |
| | | | +-----------|--|----|------------------+ |
| | +-|---|-----------|--|----|----------------+ |
| +---|---|-------+ | +----|-----------+ | |
| | | | | | | | |
*--------------V-----V---V-------V---V-------V-----------V----V----V---------*
|Forwarding +-----------------+ +-----------------+ +------------------+ |
| Layer |Forwarding Plane1| |Forwarding Plane2| ... |Forwarding Plane n| |
| +-----------------+ +-----------------+ +------------------+ |
*----------------------------------------------------------------------------*
Figure 5: Multi-Ownership Combinatorial Double Auction Model
We summarize the differences of three kinds of trading pattern and
the position of SDN architecture which applied them , as shown in
Figure 6:
Zhuge, et al. Expires November 4, 2016 [Page 10]
Internet-Draft Abbreviated Title May 2016
-----------------------------------------------------------------------------------
Trading | Product | Trading| Trading Risk | Trading price | Location
Pattern | Pattern | market | | | of SDN
-----------|------------|--------|---------------|-----------------|---------------
spot | Retail | No |Greater risk | Negotiation | Application
trading | Commodity| | |non-standard | layer
-----------|------------|--------|---------------|-----------------|---------------
Futures | A kind of | Future | Has margin, |Settlement based |
trading | products as| | less risk |on the price |Data forwarding
| a unit | | |of the exchange |layer
-----------|------------|--------|---------------|-----------------|---------------
Planned |Goods in any| Overall|PlannedSpending| Control price, | Entire
trading | combination| market |almost no risk |according to |architecture
| | | |supply and demand|
-----------|------------|--------|---------------|-----------------|---------------
Figure 6: the Differences among Three Trading Patterns
The commodities mode, trading market and other factors of planned
trading decides it apply to the entire SDN market; the commodities
mode of spot trading determines which is suitable for small number of
resources trading, and it has some risks, therefore it works in the
application layer of SDN architecture; the commodities mode of
futures trading trade in a kind of resource as a unit, and the risk
is small, possess the futures market, so it works in data forwarding
layer of SDN architecture.
5. Security
TBD
6. IANA Considerations
This document has no actions for IANA.
7. 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.
Zhuge, et al. Expires November 4, 2016 [Page 11]
Internet-Draft Abbreviated Title May 2016
[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, <http://www.rfc-editor.org/info/rfc7426>.
[Telecommunications-Science]
Zhuge, B., Wang, B., and Y. Wang, "Architecture of SDN
applications based on Software-Defined price", 2015.
Authors' Addresses
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
Yining Wang
Simon Fraser University
8888 University Drive
Burnaby
Canada
Phone: +1 (778) 885-0009
Email: ywa165@sfu.ca
Hua Zhu
Zhejiang Gongshang University
18 Xuezheng Str., Xiasha University Town
Hangzhou 310018
P.R.China
Phone: +86 571 28877723
Email: zhuhua9114@163.com
Zhuge, et al. Expires November 4, 2016 [Page 12]
Internet-Draft Abbreviated Title May 2016
Weiming Wang
Zhejiang Gongshang University
18 Xuezheng Str., Xiasha University Town
Hangzhou 310018
P.R.China
Phone: +86 571 28877761
Email: wmwang@zjsu.edu.cn
Zhuge, et al. Expires November 4, 2016 [Page 13]