Problem Statement for Shared Unified Policy Automation (SUPA)
draft-karagiannis-supa-problem-statement-01
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-25 | ||
| Replaced by | draft-klyus-supa-value-proposition, draft-bi-supa-problem-statement | ||
| RFC stream | (None) | ||
| Formats | |||
| 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-01
Network Working Group G. Karagiannis
Internet-Draft W. Liu
Intended status: Informational T. Tsou
Expires: March 25, 2015 Huawei Technologies
Q. Sun
China Telecom
D. Lopez
Telefonica
P. Yegani
Juniper Networks
JF Tremblay
Viagenie
September 25, 2014
Problem Statement for Shared Unified Policy Automation (SUPA)
draft-karagiannis-supa-problem-statement-01
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 a vendor neutral standardized application-
based interfaces used to expose and define policies and n abstract
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 25, 2015.
Karagiannis, et al. Expires March 25, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Requirements/Objectives . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
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.
However the real value behind central configuration schemes lies
within the possible simplification through abstract 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.
Karagiannis, et al. Expires March 25, 2015 [Page 2]
Internet-Draft SUPA Problem Statement September 2014
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
network 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.
Moreover, 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 none of these groups aim (1) at offering truly
generic topology models for the standard northbound interface, and
(2) that an application can communicate with network boxes, such as
network controllers, and NEs, developed by different vendors.
SUPA will work on defining vendor-neutral standardized 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 network graph describes (1) topologies at different levels of
abstraction, (2) the relationships between the abstraction levels and
(3) applied service based policy, which are actions and constraints
applied on these topologies. SUPA may also define any mappings to any
other network topology data models defined within the IETF.
Examples of YANG based data models for network topologies are
provided in [ID.draft-contreras-supa-yang-network-topo].
A YANG Data model for SUPA configuration is provided in
[ID.draft-zaalouk-supa-configuration-model].
The document [ID.draft-pentikousis-supa-mapping] describes
guidelines for mapping configuration and policy into device-level
configuration.
In particular, SUPA will focus on service specific models that allow
applications to request certain network services to be
created/deleted/modified. A network service can for example be a
virtual link between two endpoints that uses certain properties,
traffic engineering, implementation of IPv6 transition mechanism and
their enforcement to users.
Each network service can be represented by a service based POLICY
Karagiannis, et al. Expires March 25, 2015 [Page 3]
Internet-Draft SUPA Problem Statement September 2014
model that can model a group of demands (i.e., actions and
constraints) that are being initiated by applications that impose
similar requirements on the communication network. The terms
"UNIFIED" and "SHARED" used in the SUPA abbreviation, relate to the
way of how the service policy model is generated, since it groups,
unifies and shares the similar requirements imposed by a bulk of
applications. SUPA will provide guidelines for mechanisms that can
dynamically and on an interoperable manner, AUTOMATICALLY map
services and policies defined on an abstract topology graph down to
more detailed network graphs and specific network management and
controlling policies.
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 service
based demands and possibly update its associated network service
attributes.
For each network service instance a network graph needs to be
generated and maintained up to date.
The up-to-date network graph needs to be communicated between
"Applications", see Figure 1, and the "Management and Control"
system. Applications" represent an entity that generates and
maintains network services and is administrated by a communication
service provider. The "Management and Control" represents a
controller that supports the management and control of a
communication network.
The services and policies defined on an abstract topology
graph are automatically mapped down to more detailed network graphs
and specific network management and controlling policies.
The main goal of SUPA is to provide service specific models that
allow applications to request network services to be
created/deleted/modified. This can be realized by:
o) use YANG [RFC6020], [RFC6991] to model multiple topologies at
different levels of abstraction using a network graph,
o) use YANG to model the relationships between the abstraction
levels.
o) transporting model instances using either NETCONF [RFC6241] or
RESTCONF [ID.draft-ietf-netconf-restconf].
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 25, 2015 [Page 4]
Internet-Draft SUPA Problem Statement September 2014
---------------------------------------
| Applications |
---------------------------------------
|
| <-------------- network service
| YANG models /NETCONF
northbound interface
--------------------------------------|
| |
| Controller |
| (Management and Control) | <--- mapping
| | network services to
| | topology
--------------------------------------
| | |
| | | <------------ device/feature
| | | specific YANG
| | | models / NETCONF
southbound interface
NE1 NE2 NEn
Figure 1: SUPA architecture
2. Terminology
Network graph: a graph that describes (1) topologies at different
levels of abstraction, (2) the relationships between the abstraction
levels and (3) applied service based policy, which are actions and
constraints applied on these topologies.
Network Service: a service, that helps a communication service
provider to monitor, control, analyze and manage a communication
network.
Network topology model: describes the topology of a multi-layer
network.
Network graph: entity describing an arbitrary topology of nodes and
links at any level of granularity. Such a network graph describes (1)
topologies at different levels of abstraction, (2) the relationships
between the abstraction levels and (3) applied service based policy,
which are actions and constraints applied on these topologies.
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).
Karagiannis, et al. Expires March 25, 2015 [Page 5]
Internet-Draft SUPA Problem Statement September 2014
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
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].
3.3 IPv6 transition
The IPv6 transition has been an ongoing process throughout the world
due to the exhaustion of the IPv4 address space. However, this
transition leads to costly end-to-end network upgrades and poses new
challenges of managing a large number of devices with a variety of
transitioning protocols. While IPv6 transition tools exist, there
are still new challenges to be solved. Operators may need various
types of IPv6 transition technologies depending on performance
requirements, deployment scenarios, etc.
To address these difficulties, SUPA can be used as the software
Karagiannis, et al. Expires March 25, 2015 [Page 6]
Internet-Draft SUPA Problem Statement September 2014
defined unifying approach that can provide a unified way to deploy
IPv6 in a cost-effective, flexible manner. A detailed description of
this use case is provided in [ID.draft-sun-supa-openv6-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.
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:
Spencer Dawkins, Jun Bi, Xing Li, Chongfeng Xie, Benoit
Claise, Ian Farrer, Marc Blancet, Zhen Cao, Hosnieh Rafiee, Mehmet
Karagiannis, et al. Expires March 25, 2015 [Page 7]
Internet-Draft SUPA Problem Statement September 2014
Ersue, Simon Perreault, Fernando Gont, Jose Saldana, Tom Taylor,
Kostas Pentikousis, Juergen Schoenwaelder.
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-sun-supa-openv6-use-cases] C. Xie, Q. Sun, JF. Tremblay,
"Use case of IPv6 transition in SUPA", IETF draft, draft-sun-supa-
openv6-use-cases-00, 25 September 2014.
[ID. draft-pentikousis-supa-mapping] K. Pentikousis, Junru Lin,
Yiyong Zha, "SUPA Configuration and Policy Mapping", IETF Internet
draft, draft-pentikousis-supa-mapping-00, September 23, 2014
[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-zaalouk-supa-configuration-model] A. Zaalouk,
K. Pentikousis, W. Liu, "YANG Data Model for Configuration of Shared
Unified Policy Automation (SUPA)", IETF draft, draft-zaalouk-supa-
configuration-model-00, 22 September, 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
[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.
Karagiannis, et al. Expires March 25, 2015 [Page 8]
Internet-Draft SUPA Problem Statement September 2014
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
1133 Innovation Way
Sunnyvale, CA 94089
Email: pyegani@juniper.net
Jean-Francois Tremblay
Viagenie inc.
Email: jean-francois.tremblay@viagenie.ca
Karagiannis, et al. Expires March 25, 2015 [Page 9]