< draft-xia-sdnrg-service-description-language-00.txt   draft-xia-sdnrg-service-description-language-01.txt >
SDNRG Y. Xia, Ed. SDNRG Y. Xia, Ed.
Internet-Draft S. Jiang, Ed. Internet-Draft S. Jiang, Ed.
Intended status: Informational S. Hares Intended status: Informational S. Hares
Expires: January 5, 2015 Huawei Technologies Co., Ltd Expires: April 30, 2015 Huawei Technologies Co., Ltd
July 4, 2014 October 27, 2014
Requirements for a Service Description Language and Design Requirements for a Service Description Language and Design
Considerations Considerations
draft-xia-sdnrg-service-description-language-00 draft-xia-sdnrg-service-description-language-01
Abstract Abstract
The more and more complicated IP networks require a new interaction The more and more complicated IP networks require a new interaction
mechanism between their customers and their networks. A service mechanism between their customers and their networks. A service
description language is needed to enable customers to easily describe description language is needed to enable customers to easily describe
their diverse service requirements. SDN controller would compile their diverse intent. SDN controller would compile the user intent
these service requirements into device configurations. This document into device configurations. This document analyzes requirements for
analyzes requirements for such service description language and gives such service description language and gives considerations for
considerations for designing such service description language. designing such service description language.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 5, 2015. This Internet-Draft will expire on April 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Analysis of Network Customer's Service Demands . . . . . . . 4 3. Analysis of Network Customer's Intent . . . . . . . . . . . . 4
3.1. An Example of Service Requirements . . . . . . . . . . . 4 3.1. An Example of User Intent . . . . . . . . . . . . . . . . 4
4. Design Consideration . . . . . . . . . . . . . . . . . . . . 4 4. Design Consideration . . . . . . . . . . . . . . . . . . . . 4
4.1. A Description Example of Service Requirements . . . . . . 5 4.1. A Description Example of Service Requirements . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
8. Informative References . . . . . . . . . . . . . . . . . . . 7 8. Informative References . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
skipping to change at page 2, line 45 skipping to change at page 2, line 45
devices and networks. Today, there are many open APIs from different devices and networks. Today, there are many open APIs from different
vendors, such as OnePK from Cisco, OPS from Huawei, and etc. They vendors, such as OnePK from Cisco, OPS from Huawei, and etc. They
are mainly device-oriented interfaces. Interface to the Routing are mainly device-oriented interfaces. Interface to the Routing
System (I2RS) WG is working to allow information, policies, and System (I2RS) WG is working to allow information, policies, and
operational parameters to be injected into and retrieved from the operational parameters to be injected into and retrieved from the
routing system. It makes possible for user application to directly routing system. It makes possible for user application to directly
intervene in the running routes, or deploy specific demands. intervene in the running routes, or deploy specific demands.
However, such open interfaces are bottom-up designed according to the However, such open interfaces are bottom-up designed according to the
devices. One has to be very familiar with devices in order to devices. One has to be very familiar with devices in order to
correctly "programming" his demands. Such interfaces are far from correctly "programming" his intent. Such interfaces are far from
user-friendly. Particularly, for many upper layer applications, user-friendly. Particularly, for many upper layer applications,
their demands may involve hundreds and thousands devices. It is very their demands may involve hundreds and thousands devices. It is very
difficult for a network customer to direct program network devices. difficult for a network customer to direct program network devices.
Software-Defined Networking (SDN) controller has taken such Software-Defined Networking (SDN) controller has taken such
responsibility: hide the complexity of networks from customers, responsibility: hide the complexity of networks from customers,
receive abstracted service demands from customers, and compile/ receive abstracted intent from customers, and compile/translate the
translate the demands into detailed control operations that can intent into detailed control operations that can directly execute on
directly execute on network devices. This would allow network network devices. This would allow network customers to be released
customers to be released them the burden of selecting useful them the burden of selecting useful information and capability from
information and capability from vast information and capability of vast information and capability of the infrastructure network.
the infrastructure network.
The interactions between SDN controller and network customers should The interactions between SDN controller and network customers should
be as simple as possible. The network customers should be allowed to be as simple as possible. The network customers should be allowed to
describe their demands in their own way, which is as close as describe their demands in their own way, which is as close as
possible to their nature demands. Consequently, the northbound possible to their intent. Consequently, the northbound interface of
interface of SDN controller must be different from the northbound SDN controller must be different from the northbound interface of
interface of network devices, which actually matches the southbound network devices, which actually matches the southbound interface of
interface of SDN controller. This northbound interface of SDN SDN controller. This northbound interface of SDN controller should
controller should be designed using top-domain methodology, so that be designed using top-domain methodology, so that network customers
network customers can use it as easy as possible. can use it as easy as possible.
This document starts from analyzing the demands from network This document starts from analyzing the intent from network
customers, tries to epurate technical requirements for a service customers, tries to epurate technical requirements for a service
description language and the design consideration for a such description language and the design consideration for a such
language. A few typical examples of network customers' demands and language. A few typical examples of network customers' demands and
their description examples are also given. their description examples are also given.
The interaction between the SDN controller and the IP infrastructure The interaction between the SDN controller and the IP infrastructure
network, such as how the information and capability of infrastructure network, such as how the information and capability of infrastructure
networks are abstracted, how network capabilities are executed and networks are abstracted, how network capabilities are executed and
how the service logic is translated, are out of scope of this how the service logic is translated, are out of scope of this
document. document.
skipping to change at page 4, line 5 skipping to change at page 4, line 5
between SDN controller and network customers. It receives the between SDN controller and network customers. It receives the
customer orders in both data form or service logic form. customer orders in both data form or service logic form.
Northbound Interface of Network Device An interactive interface that Northbound Interface of Network Device An interactive interface that
allows SDN controller, or network management system to directly allows SDN controller, or network management system to directly
operate the network devices. operate the network devices.
Service Description Language A language used to describe specific Service Description Language A language used to describe specific
service demands by the network customers. service demands by the network customers.
3. Analysis of Network Customer's Service Demands 3. Analysis of Network Customer's Intent
The network customers do not care the detailed configurations of each The network customers do not care the detailed configurations of each
device, or flow entries in each device, even when their service flows 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 go through these devices. They do not want to be bored the detailed
device-oriented operations, such as tunnel management, isolation with device-oriented operations, such as tunnel management, isolation with
other services, PBR configurations of different devices. What the other services, PBR configurations of different devices. What the
network customers care about is the service demand they require and network customers care about is the service demand they require and
the service quality they receive. the service quality they receive.
3.1. An Example of Service Requirements 3.1. An Example of User Intent
A typical network customer's demand would firstly start from A typical network customer's intent would firstly start from
connectivities: connect the two datacenters that locate in two connectivities: connect the two datacenters that locate in two
cities. For security reasons, the customer normally want to organize cities. For security reasons, the customer normally want to organize
all their connectivities as a virtual network. {add the example of all their connectivities as a virtual network. For example, a tenant
link} needs two connections to carry different service flows between two
datacenters.
Then, the customer normally need to appoint the quality of service or Then, the customer normally need to appoint the quality of service or
choose from certain Service Level Agreement (SLA) for this choose from certain Service Level Agreement (SLA) for this
connectivity. 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 Typically, traffics of customers could be categorized into several
classes, which match with different SLAs. 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 Furthermore, the customer may demand some flows go through a certain
intermedia server, such as firewall. intermedia server, such as firewall or WOC.
The customer may want to organize his few demands together with The customer may want to organize his few demands together with
certain choosing circumstances 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 In some scenarios, the customer flows may be needed to be presented
by various form. For example, client/server flows are normally come by various form. For example, client/server flows normally come from
from different and distributed sources. different and distributed sources.
4. Design Consideration 4. Design Consideration
The purpose of a service description language is to describe the The purpose of a service description language is to describe the
network customer's requirements. The SDN controller or network network customer's intent. The SDN controller or network
administration system then compile them into the operations of administration system then compile them into the operations of
network devices. network devices.
The language should have the below ability: The language should have the below ability:
o be able to describe customer traffics which can be identified as o be able to describe customer traffics which can be identified as
flows; flows;
o be able to describe access node, virtual network, servers, and o be able to describe access node, virtual network, servers, and
other network entities that the network customers apperceive; other network entities that the network customers apperceive;
o be able to describe QoS, SLAs and other relevant properties; o be able to describe QoS, SLAs and other relevant properties;
o be able to describe logic that combines a few demands together o be able to describe logic that combine a few demands together with
with certain choosing circumstances; certain choosing circumstances;
o be able to describe the necessary information from the network o be able to describe the necessary information from the network
(e.g. SDN controller), so that the network customer can describe (e.g. SDN controller), so that the network customer can describe
their requirements accordingly; their intent accordingly;
o easy to extend in order to support various new services or demands o easy to extend in order to support various new services or demands
that may appear in the future. that may appear in the future.
4.1. A Description Example of Service Requirements 4.1. A Description Example of Service Requirements
A tenant needs two connections to carry different service flows A tenant needs two connections to carry different service flows
between two datacenters. one connection of the tenant is 40G between two datacenters. one connection of the tenant is 40G
bandwidth with less than 400ms delay, another connection is 100M bandwidth with less than 400ms delay, another connection is 100M
bandwidth with less than 50ms delay. bandwidth with less than 50ms delay.
 End of changes. 21 change blocks. 
39 lines changed or deleted 46 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/