Problem Statement for Shared Unified Policy Automation (SUPA)
draft-karagiannis-supa-problem-statement-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Georgios Karagiannis , Will (Shucheng) LIU , Tina Tsou (Ting ZOU) , Qiong Sun , Diego R. Lopez , Parviz Yegani | ||
| Last updated | 2014-09-22 | ||
| Replaced by | draft-klyus-supa-value-proposition, draft-bi-supa-problem-statement | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-karagiannis-supa-problem-statement-00
Network Working Group G. Karagiannis
Internet-Draft W. Liu
Intended status: Informational T. Tsou
Expires: March 20, 2015 Huawei Technologies
Q. Sun
China Telecom
D. Lopez
Telefonica
P. Yegani
Juniper Networks
JF Tremblay
Viagenie
September 20, 2014
Problem Statement for Shared Unified Policy Automation (SUPA)
draft-karagiannis-supa-problem-statement-00
Abstract
As modern network management applications grow in scale
and complexity, their demands and requirements on the supporting
communication network increase.
In particular, network operators are challenged to create a
simplified view of their network infrastructure and help service
developers on using and programming this simplified view rather than
manipulating individual devices. In this context, providing service
developers with a set of standard interfaces to configure and set
policies on the network is essential.
This document describes what has to be addressed in order to equip
service providers with standardized application-based interfaces used
to expose and define policies and a simplified view of network
infrastructure.
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 March 20, 2015.
Karagiannis, et al. Expires March 20, 2015 [Page 1]
Internet-Draft SUPA Problem Statement September 2014
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Requirements/Objectives . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Network operators are faced with networks of increasing size and
complexity while trying to improve their quality and availability, as
more and more services depend on them. Programmatic ways to configure
networks, often called software-defined, are considered by many
network operators in order to shift the balance in their favor.
Currently, the separation of development and operation of network
technologies leads to slow deployment of network functions/devices
and poor user experiences.
Automating the way of exposing a view of the network to applications
may provide significant improvements in configuration agility, error
detection and uptime for operators.
Karagiannis, et al. Expires March 20, 2015 [Page 2]
Internet-Draft SUPA Problem Statement September 2014
However the real value behind central configuration schemes lies
within the possible simplification through simplified models
provided by such systems to applications and network zervices running
above them (on the so-called northbound side). Well-designed
simplified models are able to provide a wide range of granularity for
various applications and network services needs, from the lower-level
physical network to high-level application services.
1.1 Motivation
Although several organizations outside of the IETF have defined
various schemes for the configuration of network devices and specific
network controllers, none of them offer a vendor-neutral standardized
way for applications and network services to transmit their needs to
controllers. The SUPA (Shared Unified Policy Automation) working
group will work on the definition of such as standardized interface
for applications and network services to communicate with network
controllers of all types.
The specification of the interface towards end user apllications is
initially not in the scope of SUPA. In particular, as starting point,
SUPA will only focus on network services, which are enhanced
Operational Support System (OSS) like services that help a
communication service provider to monitor, control, analyze and
manage a communication network. The systems that are runniung such
network services are denoted in this document as Network Service
Systems (NSS).
Each network service can be represented by a classified application
based POLICY model, since it can model the group of demands which are
SHARED and UNIFIED and are coming from a bundle of applications that
impose similar requirements on the communication network.
Although some IETF working groups have started work relating to the
description of various topologies such as I2RS (L3and routing
topologies), ALTO (cost maps), SFC (service chain), none of these
groups aim at offering truly generic topology models for the standard
northbound interface. An example of a YANG based data model for
network topologies is provided in
[ID. draft-contreras-supa-yang-network-topo].
SUPA will work on defining interfaces based on the concept of network
graph, an entity describing an arbitrary topology of nodes and links
at any level of granularity. Such a graph may describe, for example,
a physical topology, a service topology or the relationships between
datacenters. Any network topology data models or policy models that
have been defined (or are being defined) within the IETF will be
reused in SUPA as much as possible.
In addition to the above, policies may be defined and applied to a
network graph. These application based policies are actions or
constraints generated by network service systems. They are then
mapped from the network graph instance into specific network
management policies toward network components. Such application based
demands are of the following types:
Karagiannis, et al. Expires March 20, 2015 [Page 3]
Internet-Draft SUPA Problem Statement September 2014
*) Configuration requests:
o) Dynamically configure e.g., a L3VPN inter-connecting
DCs, a service topology, the relationships between
datacentres
*) Data plane requests:
o) Traffic flow steering
o) Traffic flow prioritizing
o) Encapsulate/de-capsulate a traffic flow
o) Block or admit a traffic flow
*) Control plane / Routing plane requests:
o) Change the routing state on a service or
network function
In this context, network services can be used to provide the required
configuration and application programming interfaces to such service
developers. Subsequently, a network service can use the application
based demands and possibly update its associated network service
attributes.
For each network service instance a network graph needs to be
generated and maintained.
The up-to-date network graph needs to be communicated
between the network service systems and the network
management and controlling systems. The attributes of the network
graph need to be mapped into specific network management policies,
i.e., device level configuration models.
The main goal of SUPA is to provide a way for applications and
for network services to specify SHARED application based POLICIES to
the network infrastructure using a simplified view of the network.
This can be realized by: (1) modeling the network infrastructure as
a simplified network graph using a modeling language such as YANG
[RFC6020], [RFC6991], (2) transporting model instances either using
NETCONF [RFC6241] or RESTCONF [ID.draft-ietf-netconf-restconf] and
(3) providing guidelines on AUTOMATICALLY mapping policies to
attributes of the network graphs. Figure 1 shows the SUPA goal and
scope.
This document is organized as follows. Section 2 presents the
terminology. Section 3 provides a brief overview of the use cases
associated with SUPA. The requirements/objectives are provided in
Section 4. Section 5 provides the security considerations. The IANA
considerations are given in Section 6. Section 7 gives the
acknowledgements and Section 8 lists the used references.
Karagiannis, et al. Expires March 20, 2015 [Page 4]
Internet-Draft SUPA Problem Statement September 2014
+--------------+ +--------------+
| Applications | | Applications |
+--------------+ +--------------+
| |
+--------------------------+ +--------------------------+ -
| +-----------------+ | | +-----------------+ | ^
| | Network service | | | | Network service | | |
| +-----------------+ | | +-----------------+ | |
| | Network Graph | ... | | | Network Graph | | |
| | | | | | | | |
| +-----------------+ | ... | +-----------------+ | |
| | | | |
| | | | |
| | | | |
| Network service | | Network service | |
| system | | system | |
+----------^---------------+ +----------^---------------+ |
| | |
+-----------------+--------------------+ SUPA
| scope
| |
| NETCONF/RESTCONF/YANG |
| +----------------------+ |
| | Network Graph | |
| +----------------------+ |
+---------v--------------+ |
| Network management & | |
| control systems | |
| | |
| | |
| | |
| | V
+--------------^---------+ -----
|
+-------------------+------------------+
| |
| |
| |
+-------------v---------------+ +------------v-------------+
| | | |
| | ... | |
| Network Element | | Network Element |
+-----------------------------+ +--------------------------+
Figure 1: SUPA goal and scope
2. Terminology
Device level configuration model: supports the description of the
network management policies and it describes the configuration
details at the device level.
Network service dependencies: dependencies between different service
functions/nodes.
Karagiannis, et al. Expires March 20, 2015 [Page 5]
Internet-Draft SUPA Problem Statement September 2014
Network Service: enhanced Operational Support System (OSS) like
service that help a communication service provider to monitor,
control, analyze and manage a communication network. Each network
service can be represented by a classified application based policy
model, since it can model the group of demands coming from a bundle
of end user applications that impose similar requirements on the
communication network.
Network service systems: Systems or platforms that
run the network service. The interface between NSS and end user
applications is out of the scope of this document.
Network configuration model: provides a declarative configuration of
the network
Network topology model: describes the topology of a multi-layer
network.
Network graph: an entity describing an arbitrary topology of nodes
and links at any level of granularity. Such a graph
may describe, for example, a physical topology, a L2 network, a
service topology or the relationships between datacenters.
Network element: a physical entity or a virtual entity that can be
locally managed and operated.
3. Use Cases
This section briefly describes the use cases that are associated with
different types of network services. The detailed description of
these use cases is provided in other Internet draft(s).
3.1 Distributed Data Center
A large-scale IDC (Inter Data Center) operator provides server
hosting, bandwidth, and value-added services to enterprises and ISPs,
and has more than 10 data centers and more than 1Tbs bandwidth in a
capital city. In current IDC network, traffic is routed by
configuring policy routes and adjusting routes prioritization to
choose an outgoing link. This type of static provisioning comes with
high costs and poor operability. Furthermore, the link bandwidth
resources in the data centers are not efficiently utilized.
Services usually do not have consistent bandwidth requirements at
all times of a day, e.g. video ISP usually require more
Karagiannis, et al. Expires March 20, 2015 [Page 6]
Internet-Draft SUPA Problem Statement September 2014
bandwidth at non-working hours but require less bandwidth at working
hours. Some customers have relative high QoS requirement for their
services, e.g. IM (Instant Messaging). Static bandwidth and QoS
provisioning for all the customers and services is not reasonable and
not a cost-effective solution.
SUPA can be used to request the optimization of the traffic paths
dynamically and have the ability to request the load balance between
data centers and links, and direct customer traffic via network
management policies (e.g., models, software programs routines) based
on customer grade and QoS requirements. A detailed description of
this use case is provided in [ID.draft-cheng-supa-ddc-use-cases].
3.2 Mobile Networks
GiLAN is another important application of network function
virtualization. In mobile core networks, it is preferable that QoS
provisioning and network function requirements are different for
subscribers with different profiles. In such scenarios, specialized
network services such as BSS/OSS can send application based demands
to a policy decision point, which further map these application based
demands to GiLAN specific policies, and realize
the required QoS and with appropriate network functions, for example,
for dynamic path reconfiguration.
A detailed description of this use case is provided in
[ID.draft-huang-aponf-use-cases].
4. Requirements/Objectives
The requirements/objectives that need to be supported by the SUPA
methods, models and protocol solutions are the following ones:
Work items for SUPA include:
o) The definition of a standardized model for a network graph, using
YANG. This model may be used to describe topologies at any
functional layer, from physical networks to network services.
Any network topology data models or policy models that have been
defined (or are being defined) within the IETF will be reused in
SUPA as much as possible.
o) The definition and standardization of a number of basic policy and
data models using network graphs. These might include, but are not
limited to L3VPNs, datacenters, traffic engineering,
implementation of IPv6 transition mechanism and their enforcement
to users.
o) Guidelines on how to use NETCONF (or RESTCONF) authentication and
authorization mechanisms to achieve protection and isolation
o) Guidelines for automatic mapping policies to attributes of the
network graphs.
Karagiannis, et al. Expires March 20, 2015 [Page 7]
Internet-Draft SUPA Problem Statement September 2014
The following items are out of the SUPA scope:
o) specification of the network management and controlling policies
and their associated device configuration models
5. Security Considerations
Security is a key aspect of any protocol that allows state
installation and extracting of detailed configuration states. More
investigation remains to fully define the security requirements, such
as authorization and authentication levels. SUPA document how to use
either the NETCONF or RESTCONF authentication and authorization
mechanisms to achieve necessary security protection and isolation
6. IANA Considerations
This document has no actions for IANA.
7. Acknowledgements
The authors of this draft would like to thank the following
persons for the provided valuable feedback and contributions: Diego
Lopez, Spencer Dawkins, Jun Bi, Xing Li, Chongfeng Xie, Benoit
Claise, Ian Farrer, Marc Blancet, Zhen Cao, Hosnieh Rafiee, Mehmet
Ersue, Simon Perreault, Fernando Gont, Jose Saldana, Tom Taylor,
Kostas Pentikousis.
8. References
8.1. Normative References
8.2. Informative References
[ID.draft-cheng-supa-ddc-use-cases] Y. Cheng, C. Zhou,
G. Karagiannis, JF. Tremblay, "Use Cases for Distributed Data Center
Applicatinos in APONF", IETF Internet draft (Work in progress),
draft-cheng-supa-ddc-use-cases-00, September 17, 2014
[ID. draft-contreras-supa-yang-network-topo] L.Contreras, Andrew Qu,
"A YANG Data Model for Network Topologies", IETF draft (work in
progress), draft-contreras-supa-yang-network-topo, September 18,
2004.
[ID.draft-huang-aponf-use-cases] C. Huang, Jiafeng Zhu, Peng He,
Shucheng (Will) Liu, G. Karagiannis, "Use Cases on Application-
centric Network Management and Service Provision" IETF Internet draft
(Work in progress), draft-huang-aponf-use-cases-01, Juy 2014
[ID.draft-ietf-netconf-restconf] A. Bierman, M. Bjorklund, K. Watsen,
R. Fernando, "RESTCONF Protocol", IETF Internet draft (work in
progress), draft-ietf-netconf-restconf-01, July 2014
Karagiannis, et al. Expires March 20, 2015 [Page 8]
Internet-Draft SUPA Problem Statement September 2014
[NIST SP 800-146] Badger et al.: "Draft Cloud Computing Synopsis and
recommendations", NIST specifications, May 2011.
[RFC6020] M. Bjorklund, "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
[RFC6241] R. Enns, M. Bjorklund, J. Schoenwaelder, A. Bierman,
"Network Configuration Protocol (NETCONF)", RFC 6241, June 2011.
[RFC6991] J. Schoenwaelder, "Common YANG Data Types", RFC 6991,
July 2013.
Authors' Addresses
Georgios Karagiannis
Huawei Technologies
Hansaallee 205,
40549 Dusseldorf,
Germany
Email: Georgios.Karagiannis@huawei.com
Will(Shucheng) Liu
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Email: liushucheng@huawei.com
Tina Tsou
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Email: Tina.Tsou.Zouting@huawei.com
Qiong Sun
China Telecom
No.118 Xizhimennei street, Xicheng District
Beijing 100035
P.R. China
Email: sunqiong@ctbri.com.cn
Diego Lopez
Telefonica
Email: diego@tid.es
Parviz Yegani
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, California 94089
U.S.A
Phone: +1 408-759-1973
Email: pyegani@juniper.net
Karagiannis, et al. Expires March 20, 2015 [Page 9]
Internet-Draft SUPA Problem Statement September 2014
Jean-Francois Tremblay
Viagenie inc.
Email: jean-francois.tremblay@viagenie.ca
Karagiannis, et al. Expires March 20, 2015 [Page 10]