| 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
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.
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 (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 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.
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, 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.
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.
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.
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:
{
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
}
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.
The tenant has two types of traffic, CDN sync traffic uses high bandwidth connection and online game traffic uses low latency connection.
{
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
}
{
Policy policy3_id
Appliesto flow2_id
Condition {Time>18:00 or Time< 2:00}
Action "gothrough", {woc_node_id ,link2_id}
}
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.
This memo includes no request to IANA.
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].
| [RFC2629] | Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. |