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

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

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

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 service requirements.  SDN controller would compile
   these service requirements 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 January 5, 2015.

Copyright Notice

   Copyright (c) 2014 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 January 5, 2015                [Page 1]
Internet-Draft       Service Description Language PS           July 2014

   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 Service Demands  . . . . . . .   4
     3.1.  An Example of Service Requirements  . . . . . . . . . . .   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 demands.  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 January 5, 2015                [Page 2]
Internet-Draft       Service Description Language PS           July 2014

   receive abstracted service demands from customers, and compile/
   translate the demands 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 nature demands.  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 demands 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 January 5, 2015                [Page 3]
Internet-Draft       Service Description Language PS           July 2014

3.  Analysis of Network Customer's Service Demands

   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 Service Requirements

   A typical network customer's demand would firstly start from
   connectivities: connect the two datacenters that locate in two
   cities.  For security reasons, the customer normally want to organize
   all their connectivities as a virtual network. {add the example of
   link}

   Then, the customer normally need to appoint the quality of service or
   choose from certain Service Level Agreement (SLA) for this
   connectivity.

   Typically, traffics of customers could be categorized into several
   classes, which match with different SLAs.

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

   The customer may want to organize his few demands together with
   certain choosing circumstances

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

4.  Design Consideration

   The purpose of a service description language is to describe the
   network customer's requirements.  The SDN controller or network
   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;

Xia, et al.              Expires January 5, 2015                [Page 4]
Internet-Draft       Service Description Language PS           July 2014

   o  be able to describe access node, virtual network, servers, and
      other network entities that the network customers apperceive;

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

   o  be able to describe logic that combines 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 requirements 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.

  {
     Link Link1_id
        Endnodes (DC1_node_id, DC2_node_id)
        Property "NAME","DC1_DC2_link_one","Bandwith",40G, "Delay",400ms

     Link Link2_id
        Endnodes (DC1_node_id, DC2_node_id)
        Property "NAME","DC1_DC2_link_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 January 5, 2015                [Page 5]
Internet-Draft       Service Description Language PS           July 2014

  {
     Flow flow1_id
        Match "srcip","10.0.1.1/24","dstip",?20.0.1.1/24","Port","55555"
        Property "NAME", "CDN sync flow", "Bidirection","true?

     Flow flow2_id
        Match "srcip","10.0.1.1/24","dstip",?20.0.1.1/24","Port","56663"
        Property "NAME", "online Game", "Bidirection","true?

     Policy policy1_id
        Appliesto flow1_id
        Action "forwardto", link1_id

     Policy policy2_id
        Appliesto flow2_id
        Action "gothrough", link2_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 ,link2_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.

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

Xia, et al.              Expires January 5, 2015                [Page 6]
Internet-Draft       Service Description Language PS           July 2014

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 January 5, 2015                [Page 7]