Skip to main content

An SDN Framework with Software-Defined Pricing (SDP)
draft-zhuge-sdnrg-sdn-sdp-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Bin Zhuge , Yining Wang , Hua Zhu , Weiming Wang
Last updated 2015-09-23
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-zhuge-sdnrg-sdn-sdp-00
Internet Engineering Task Force                                 B. Zhuge
Internet-Draft                             Zhejiang Gongshang University
Intended status: Standards Track                                 Y. Wang
Expires: March 26, 2016                          Simon Fraser University
                                                                  H. Zhu
                                                                 W. Wang
                                           Zhejiang Gongshang University
                                                      September 23, 2015

          An SDN Framework with Software-Defined Pricing (SDP)
                      draft-zhuge-sdnrg-sdn-sdp-00

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 March 26, 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

Zhuge, et al.            Expires March 26, 2016                 [Page 1]
Internet-Draft              Abbreviated Title             September 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.  Informative References  . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

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
   to price specific services and use of network resources.  An SDP

Zhuge, et al.            Expires March 26, 2016                 [Page 2]
Internet-Draft              Abbreviated Title             September 2015

   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

   To fulfill above process, an SDP protocol header may usually include
   fields like shown in Figure 2, where:

Zhuge, et al.            Expires March 26, 2016                 [Page 3]
Internet-Draft              Abbreviated Title             September 2015

   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.

   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

Zhuge, et al.            Expires March 26, 2016                 [Page 4]
Internet-Draft              Abbreviated Title             September 2015

   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.

   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.

Zhuge, et al.            Expires March 26, 2016                 [Page 5]
Internet-Draft              Abbreviated Title             September 2015

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)

Zhuge, et al.            Expires March 26, 2016                 [Page 6]
Internet-Draft              Abbreviated Title             September 2015

              +----------------------------------------------------------------------------------+
  SDN         |      +----------------+       +----------------+        +-----------------+      |
Application   |      | App (With SDP) |       | App (With SDP) |        | App (With SDP)  |      |
  Layer       |      +----------------+       +----------------+        +-----------------+      |
              +----------------------------------------------------------------------------------+
                                                        A
                                                        |
                         +---------------------------------------------------------------+
                         |                                                               |
                         |      API or SDN Northern Interface Protocols to be defined    |
                         |                                                               |
                         +---------------------------------------------------------------+
                                                        |
                                                        v
              +----------------------------------------------------------------------------------+
  SDN         |       +----------------------------+        +----------------------------+       |
Control       |       | Network Service(With SDP)  |        | Network Service(With SDP)  |       |
  Layer       |       +----------------------------+        +----------------------------+       |
              +----------------------------------------------------------------------------------+
                                                        A
                                                        |
                         +----------------------------------------------------------------+
                         |                                                                |
                         |  SDN southern interface protocols like ForCES, OpenFlow, et al.|
                         |                                                                |
                         +----------------------------------------------------------------+
                                                        |
                                                        v
               +---------------------------------------------------------------------------------+
  SDN          |     +--------------------------------+   +--------------------------------+     |
Infrastructure |     | Network Element (With SDP)     |   | Network Element (With SDP)     |     |
(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
   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,

Zhuge, et al.            Expires March 26, 2016                 [Page 7]
Internet-Draft              Abbreviated Title             September 2015

   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.

                                    +---------------------+
                                    |   '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

Zhuge, et al.            Expires March 26, 2016                 [Page 8]
Internet-Draft              Abbreviated Title             September 2015

4.  Security

   TBD

5.  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.

   [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

Zhuge, et al.            Expires March 26, 2016                 [Page 9]
Internet-Draft              Abbreviated Title             September 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

   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 March 26, 2016                [Page 10]