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]