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]
