Internet DRAFT - draft-xia-sdnrg-service-description-language

draft-xia-sdnrg-service-description-language







SDNRG                                                        Y. Xia, Ed.
Internet-Draft                                             S. Jiang, Ed.
Intended status: Informational                                  S. Hares
Expires: November 5, 2015                   Huawei Technologies Co., Ltd
                                                             May 4, 2015


       Requirements for a Service Description Language and Design
                             Considerations
            draft-xia-sdnrg-service-description-language-02

Abstract

   The more and more complicated IP networks require a new interaction
   mechanism between their customers and their networks.  A service
   description language is needed to enable customers to easily describe
   their diverse intent.  SDN controller would compile the user intent
   into device configurations.  This document analyzes requirements for
   such service description language and gives considerations for
   designing such service description language.

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

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



Xia, et al.             Expires November 5, 2015                [Page 1]

Internet-Draft       Service Description Language PS            May 2015


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Analysis of Network Customer's Intent . . . . . . . . . . . .   4
     3.1.  An Example of User Intent . . . . . . . . . . . . . . . .   4
   4.  Design Consideration  . . . . . . . . . . . . . . . . . . . .   4
     4.1.  A Description Example of Service Requirements . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   8.  Informative References  . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   The IP networks of the Internet Service Providers (ISPs) and data
   centers are becoming more and more big and complicated.
   Simultaneously, the services that are demanded by their customers,
   particularly the upper layer applications, are also becoming more and
   more complicated.  The rigid service models are lacking the
   flexibility to meet the various requirements/scenarios.  A better
   form would be that the network customers are allowed to customize
   their own services as they need.

   Recently, there are many efforts have been made on opening the IP
   devices and networks.  Today, there are many open APIs from different
   vendors, such as OnePK from Cisco, OPS from Huawei, and etc.  They
   are mainly device-oriented interfaces.  Interface to the Routing
   System (I2RS) WG is working to allow information, policies, and
   operational parameters to be injected into and retrieved from the
   routing system.  It makes possible for user application to directly
   intervene in the running routes, or deploy specific demands.

   However, such open interfaces are bottom-up designed according to the
   devices.  One has to be very familiar with devices in order to
   correctly "programming" his intent.  Such interfaces are far from
   user-friendly.  Particularly, for many upper layer applications,
   their demands may involve hundreds and thousands devices.  It is very
   difficult for a network customer to direct program network devices.

   Software-Defined Networking (SDN) controller has taken such
   responsibility: hide the complexity of networks from customers,



Xia, et al.             Expires November 5, 2015                [Page 2]

Internet-Draft       Service Description Language PS            May 2015


   receive abstracted intent from customers, and compile/translate the
   intent into detailed control operations that can directly execute on
   network devices.  This would allow network customers to be released
   them the burden of selecting useful information and capability from
   vast information and capability of the infrastructure network.

   The interactions between SDN controller and network customers should
   be as simple as possible.  The network customers should be allowed to
   describe their demands in their own way, which is as close as
   possible to their intent.  Consequently, the northbound interface of
   SDN controller must be different from the northbound interface of
   network devices, which actually matches the southbound interface of
   SDN controller.  This northbound interface of SDN controller should
   be designed using top-domain methodology, so that network customers
   can use it as easy as possible.

   This document starts from analyzing the intent from network
   customers, tries to epurate technical requirements for a service
   description language and the design consideration for a such
   language.  A few typical examples of network customers' demands and
   their description examples are also given.

   The interaction between the SDN controller and the IP infrastructure
   network, such as how the information and capability of infrastructure
   networks are abstracted, how network capabilities are executed and
   how the service logic is translated, are out of scope of this
   document.

2.  Terminology

   SDN Controller  An application in Software-Defined Networking (SDN)
        that manages flow control.  It controls manages a number of
        network devices in the infrastructure network, regarding how to
        forwarding IP packets.

   Northbound Interface of SDN Controller  An interactive interface
        between SDN controller and network customers.  It receives the
        customer orders in both data form or service logic form.

   Northbound Interface of Network Device  An interactive interface that
        allows SDN controller, or network management system to directly
        operate the network devices.

   Service Description Language  A language used to describe specific
        service demands by the network customers.






Xia, et al.             Expires November 5, 2015                [Page 3]

Internet-Draft       Service Description Language PS            May 2015


3.  Analysis of Network Customer's Intent

   The network customers do not care the detailed configurations of each
   device, or flow entries in each device, even when their service flows
   go through these devices.  They do not want to be bored the detailed
   device-oriented operations, such as tunnel management, isolation with
   other services, PBR configurations of different devices.  What the
   network customers care about is the service demand they require and
   the service quality they receive.

3.1.  An Example of User Intent

   A typical network customer's intent would firstly start from
   connectivities: connect the two datacenters that locate in two
   cities.  For security reasons, the customer normally wants to
   organize all their connectivities as a virtual network.  For example,
   a tenant needs two connections to carry different service flows
   between two datacenters.

   Then, the customer normally need to appoint the quality of service or
   choose from certain Service Level Agreement (SLA) for this
   connectivity.  For example, one connection of the tenant is 40G
   bandwidth with less than 400ms delay, another connection is 100M
   bandwidth with less than 50ms delay.

   Typically, traffics of customers could be categorized into several
   classes, which match with different SLAs.  For example, the tenant
   has two types of traffic, CDN sync traffic and online game traffic.
   CDN Sync traffic uses high bandwidth connection and online game
   traffic uses low latency connection.

   Furthermore, the customer may demand some flows go through a certain
   intermediate server, such as firewall or WOC.

   The customer may want to organize his few demands together with
   certain choosing circumstances, for example the tenant wants the
   online game traffic to go through WOC in nighttime before it is
   carried by low latency connection.

   In some scenarios, the customer flows may be needed to be presented
   by various form.  For example, client/server flows normally come from
   different and distributed sources.

4.  Design Consideration

   The purpose of a service description language is to describe the
   network customer's intent.  The SDN controller or network




Xia, et al.             Expires November 5, 2015                [Page 4]

Internet-Draft       Service Description Language PS            May 2015


   administration system then compile them into the operations of
   network devices.

   The language should have the below ability:

   o  be able to describe customer traffics which can be identified as
      flows;

   o  be able to describe business group, and function group, that the
      network customers apperceive, such as, virtual network, firewall,
      load balance, etc.;

   o  be able to describe QoS, SLAs and other relevant properties;

   o  be able to describe logic that combine a few demands together with
      certain choosing circumstances;

   o  be able to describe the necessary information from the network
      (e.g.  SDN controller), so that the network customer can describe
      their intent accordingly;

   o  easy to extend in order to support various new services or demands
      that may appear in the future.

4.1.  A Description Example of Service Requirements

   A tenant needs two connections to carry different service flows
   between two datacenters. one connection of the tenant is 40G
   bandwidth with less than 400ms delay, another connection is 100M
   bandwidth with less than 50ms delay.

{
   Connection connection1_id
      Endnodes (DC1_node_id, DC2_node_id)
      Property "NAME","DC1_DC2_connection_one","Bandwith",40G, "Delay",
               400ms

   Connection connection2_id
      Endnodes (DC1_node_id, DC2_node_id)
      Property "NAME","DC1_DC2_connection_two","Bandwith",100M, "Delay",
               50ms
}

   The tenant has two types of traffic, CDN sync traffic uses high
   bandwidth connection and online game traffic uses low latency
   connection.





Xia, et al.             Expires November 5, 2015                [Page 5]

Internet-Draft       Service Description Language PS            May 2015


   {
      Flow flow1_id
         Match "srcip","192.0.2.0/24","dstip","198.51.100.0/24","Port",
               "55555"
         Property "NAME", "CDN sync flow", "Bidirection","true"

      Flow flow2_id
         Match "srcip","192.0.2.0/24","dstip","198.51.100.0/24","Port",
               "56663"
         Property "NAME", "online Game", "Bidirection","true"

      Policy policy1_id
         Appliesto flow1_id
         Action "forwardto", connection1_id

      Policy policy2_id
         Appliesto flow2_id
         Action "gothrough", connection2_id
   }

   the tenant wants the online game traffic to go through WOC in
   nighttime before it is carried by low latency connection.

   {
      Policy policy3_id
         Appliesto flow2_id
         Condition {Time>18:00 or Time< 2:00}
         Action "gothrough", {woc_node_id ,connection2_id}
   }

5.  Security Considerations

   Because the network customers are allowed to customize their own
   services, they may bring potentially big impacts to a running IP
   network.  A strong user authentication mechanism is needed for the
   northbound interface of the SDN controller.  User authorization
   should be carefully managed by the network administrator to avoid any
   dangerous operations and prevent any abuse of network resources.

6.  IANA Considerations

   This memo includes no request to IANA.

7.  Acknowledgements

   The authors would like to thanks the valuable comments made by Wei
   Cao, Xiaofei Xu, Fuyou Miao and Wenyang Lei.




Xia, et al.             Expires November 5, 2015                [Page 6]

Internet-Draft       Service Description Language PS            May 2015


   This document was produced using the xml2rfc tool [RFC2629].

8.  Informative References

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

Authors' Addresses

   Yinben Xia (editor)
   Huawei Technologies Co., Ltd
   Q14, Huawei Campus, No.156 Beiqing Road
   Hai-Dian District, Beijing, 100095
   P.R. China

   Email: xiayinben@huawei.com


   Sheng Jiang (editor)
   Huawei Technologies Co., Ltd
   Q14, Huawei Campus, No.156 Beiqing Road
   Hai-Dian District, Beijing, 100095
   P.R. China

   Email: jiangsheng@huawei.com


   Susan Hares
   Huawei Technologies Co., Ltd
   7453 Hickory Hill
   Saline, CA  48176
   USA

   Email: shares@ndzh.com

















Xia, et al.             Expires November 5, 2015                [Page 7]