One document matched: draft-xia-sdnrg-service-description-language-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-xia-sdnrg-service-description-language-00"
     ipr="trust200902">
  <front>
    <title abbrev="Service Description Language PS">Requirements for a Service
    Description Language and Design Considerations</title>

    <author fullname="Yinben Xia" initials="Y." role="editor" surname="Xia">
      <organization>Huawei Technologies Co., Ltd</organization>

      <address>
        <postal>
          <street>Q14, Huawei Campus, No.156 Beiqing Road</street>

          <city>Hai-Dian District, Beijing, 100095</city>

          <country>P.R. China</country>
        </postal>

        <email>xiayinben@huawei.com</email>
      </address>
    </author>

    <author fullname="Sheng Jiang" initials="S." role="editor" surname="Jiang">
      <organization>Huawei Technologies Co., Ltd</organization>

      <address>
        <postal>
          <street>Q14, Huawei Campus, No.156 Beiqing Road</street>

          <city>Hai-Dian District, Beijing, 100095</city>

          <country>P.R. China</country>
        </postal>

        <email>jiangsheng@huawei.com</email>
      </address>
    </author>

    <author fullname="Susan Hares" initials="S." surname="Hares">
      <organization>Huawei Technologies Co., Ltd</organization>

      <address>
        <postal>
          <street>7453 Hickory Hill</street>

          <!-- Reorder these if your country does things differently -->

          <city>Saline</city>

          <region>CA</region>

          <code>48176</code>

          <country>USA</country>
        </postal>

        <email>shares@ndzh.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <!--<Sheng> It is actually network service orchestration interface.-->

    <date month="" year="2014" />

    <area>IRTF</area>

    <workgroup>SDNRG</workgroup>

    <keyword>SDN Controller Northbound Interface, Service Description
    Language</keyword>

    <abstract>
      <t>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.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>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.</t>

      <t>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.</t>

      <t>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.</t>

      <t>Software-Defined Networking (SDN) controller has taken such
      responsibility: hide the complexity of networks from customers, 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.</t>

      <t>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.</t>

      <t>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.</t>

      <t>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.</t>
    </section>

    <section title="Terminology">
      <t><list hangIndent="5" style="hanging">
          <t hangText="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.</t>

          <t hangText="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.</t>

          <t hangText="Northbound Interface of Network Device">An interactive
          interface that allows SDN controller, or network management system
          to directly operate the network devices.</t>

          <t hangText="Service Description Language">A language used to
          describe specific service demands by the network customers.</t>
        </list></t>
    </section>

    <section title="Analysis of Network Customer's Service Demands">
      <t>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.</t>

      <t></t>

      <section anchor="reqExample" title="An Example of Service Requirements">
        <t>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}</t>

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

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

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

        <t>The customer may want to organize his few demands together with
        certain choosing circumstances</t>

        <t>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.</t>
      </section>
    </section>

    <section title="Design Consideration">
      <t>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.</t>

      <t>The language should have the below ability:</t>

      <t><list style="symbols">
          <t>be able to describe customer traffics which can be identified as
          flows;</t>

          <t>be able to describe access node, virtual network, servers, and
          other network entities that the network customers apperceive;</t>

          <t>be able to describe QoS, SLAs and other relevant properties;</t>

          <t>be able to describe logic that combines a few demands together
          with certain choosing circumstances;</t>

          <t>be able to describe the necessary information from the network
          (e.g. SDN controller), so that the network customer can describe
          their requirements accordingly;</t>

          <t>easy to extend in order to support various new services or
          demands that may appear in the future.</t>
        </list></t>

      <t></t>

      <section title="A Description Example of Service Requirements">
        <t>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.<figure>
            <artwork><![CDATA[{
   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 
}
]]></artwork>
          </figure></t>

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

        <t><figure>
            <artwork><![CDATA[{
   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
}
]]></artwork>
          </figure>the tenant wants the online game traffic to go through WOC
        in nighttime before it is carried by low latency connection.</t>

        <t><figure>
            <artwork><![CDATA[{
   Policy policy3_id 
      Appliesto flow2_id 
      Condition {Time>18:00 or Time< 2:00} 
      Action "gothrough", {woc_node_id ,link2_id}
}
]]></artwork>
          </figure></t>
      </section>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>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.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo includes no request to IANA.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thanks the valuable comments made by Wei
      Cao, Xiaofei Xu, Fuyou Miao and Wenyang Lei.</t>

      <t>This document was produced using the xml2rfc tool <xref
      target="RFC2629"></xref>.</t>
    </section>
  </middle>

  <back>
    <references title="Informative References">
      <?rfc include='reference.RFC.2629'?>
    </references>
  </back>
</rfc>