One document matched: draft-karagiannis-supa-problem-statement-02.txt
Differences from draft-karagiannis-supa-problem-statement-01.txt
Network Working Group G. Karagiannis
Internet-Draft W. Liu
Intended status: Informational T. Tsou
Expires: April 25, 2015 Huawei Technologies
Q. Sun
China Telecom
Luis M. Contreras
Telefonica
P. Yegani
Juniper Networks
JF Tremblay
Viagenie
October 25, 2014
Problem Statement for Shared Unified Policy Automation (SUPA)
draft-karagiannis-supa-problem-statement-02
Abstract
As modern network management applications grow in scale
and complexity, their demands and requirements on the supporting
communication network increase.
This is the root cause of one of the major challenges that network
operators (service providers, SME, etc) are facing today. The
operators are obliged to create a simplified view of their network
infrastructure that can help network engineers to use such a
simplified model rather than manipulating individual devices. In this
context, providing network operators with a set of standard
interfaces to configure and set policies at various points on their
network is essential.
This document describes what has to be addressed in order to equip
service providers with the means to quickly and dynamically
create/query/scale/update/ delete/ the services they want to offer.
This may include a variety of different service enabling scenarios
and in particular VPN and Inter-DC traffic steering and tunneling.
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 April 25, 2015.
Karagiannis, et al. Expires April 25, 2015 [Page 1]
Internet-Draft SUPA Problem Statement October 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Inter-Data Center (DC) and VPN Use Cases . . . . . . . . . . . 5
4. Requirements/Objectives . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
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.
Providing means 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 services 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 April 25, 2015 [Page 2]
Internet-Draft SUPA Problem Statement October 2014
1.1 Motivation
As the underlying network infrastructure continues to grow, due to
increasingly new services and applications, it becomes significantly
more challenging than ever to maintain the network and deploy new
services. Nowadays, network configuration, optimization and
automation using software-defined networking tools and techniques,
are being considered by many network operators in order to provide
significant benefits in deployment agility and fast time to market.
Shared Unified Policy Automation (SUPA) attempts to achieve this
configuration automation by introducing multi-level and
multi-technology network abstractions. It plans to create YANG
model of general network topology and YANG model of service specific
configuration to provide topology information as applications demand
and map the network-wide configuration/topology into individual
device-recognized configuration.
This entails to defining standardized interfaces between applications
and network domains (via network controllers) to enable automatic and
programmable configuration required for proper operation of the
network to deliver the target services.
Several working groups in IETF such as I2RS (L3/ routing topologies),
ALTO (cost maps), SFC (service chain), have already defined various
schemes for the configuration of network devices and specific network
controllers. However, none of these efforts offer a vendor-neutral
standardized scheme for applications to transmit their needs to
controllers.
Figure 1 shows the SUPA architecture where applications can
communicate with network controllers of all types, which can be
for example single or multiple controllers. These network
controllers can use any type of mechanisms for excahning information
to and from NEs. In this architecture NEs can interact with local or
remote network controllers (e.g., exchange configuration information,
status, etc).
Network controllers, exchange configuration information with NEs and
derive the actual and detailed network topology model. When an
application needs to use this network topology it applies NETCONF
[RFC6241] or RESTCONF [ID.draft-ietf-netconf-restconf] and it sends a
request to receive a service specific abstraction from the network
controller(s). Subsequently, the network controller(s) provides, a
service specific abstraction of the network topology to the
application, which should be able to meet the requirements imposed by
this application. Different types of applications may get different
service specific abstractions of the same network topology from the
network controller(s). For example, for the same actual network
topology, a VPN network service will receive a different service
specific abstraction of the network topology, than an inter Data
Center (DC) network service. By using policies, e.g., for traffic
steering, the application can instruct the network controller(s) to
map the service specific abstractions to the actual (detailed)
network topology and NE specific configuration.
Karagiannis, et al. Expires April 25, 2015 [Page 3]
Internet-Draft SUPA Problem Statement October 2014
The main goal of SUPA is to provide YANG models [RFC6020], [RFC6991]
of vendor-neutral service specific abstractions for the VPN and
Inter-DC traffic steering and tunneling network services. This is to
allow applications to request these network services from network
controller(s) of all types, e.g., single or multiple controllers.
Such services can be quickly and dynamically created/deleted/updated,
using proper mechanisms for exchanging information between the
appropriate NEs.
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 high-level configuration and policy
information into device-level configuration.
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 provides the list of references.
-----------------------------------
| Applications |
-----------------------------------
| \ |
| \ | <------- service specific
| \ | YANG models /NETCONF
| \ | northbound interface
| \ |
------------- -------------- mapping
| | | | <--- service specific
| Controller | | Controller | abstractions to
| | | | network topology and
--------------- ------------- configuration
| | | | | |
| | | | | | <------- NE/feature
| | | | | | specific YANG
| | | | | | models / NETCONF
| | | | | | southbound interface
NE1 NE2 NEn NE1 NE2 NEn
Figure 1: SUPA architecture overview
2. Terminology
Network Service: is the composition of network functions and defined
by its functional and behavioural specification. The network service
contributes to the behaviour of the higher layer service, which is
characterized by at least performance, dependability, and security
specifications.
Karagiannis, et al. Expires April 25, 2015 [Page 4]
Internet-Draft SUPA Problem Statement October 2014
Network Element: a physical or virtual entity that implements one or
more network function(s). NEs can interact with local or remote
network controllers in order to exchange information, such as
configuration information and status.
Service specific abstraction: an abstract view of the actual topology
of a network, which is associated with a specific network service
type, e.g., VPN or Inter-DC.
3. Inter-Data Center (DC) and VPN 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).
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 networks, 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 has the ability to request load balancing between
data centers and links, and direct customer traffic via network
management policies. Path optimization can be accomplished using data
models or software programs routines to differentiate customer based
on their service class and/or QoS requirements.
Moreover, when VPN tunnels are interconnecting DCs, SUPA can be used
to dynamically reconfigure these VPN tunnels, e.g., L2VPN or L3VPN in
order to avoid possible congested communication paths and improve
end to end latency. Detailed descriptions of these use cases are
provided in [ID.draft-cheng-supa-ddc-use-cases].
4. Requirements/Objectives
The SUPA architectural framework must support the following
capabilities:
o) Define network abstractions using Yang models for L0-L7 Network
topologies with bi-directional and uni-directional links
o) Map Service-Specific Yang models of both VPN tunneling and
Inter-DC virtual links Network Configuration to NE-Specific
configuration (i.e., Tunnel Policy and Traffic Steering Policy,
etc.)
Karagiannis, et al. Expires April 25, 2015 [Page 5]
Internet-Draft SUPA Problem Statement October 2014
o) Specify how NEs can interact with local or remote network
controllers (e.g., exchange configuration information, status,
etc.).
5. Security Considerations
Security is a key aspect of any protocol that allows state
installation and extracting detailed configuration states of network
elements. This places additional security measures on SUPA (e.g.,
authorization, and authentication of network services) that needs
further investigation.
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, Juergen Schoenwaelder, Eric Voit.
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-01, October 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-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-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-03, October 2014
Karagiannis, et al. Expires April 25, 2015 [Page 6]
Internet-Draft SUPA Problem Statement October 2014
[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
Luis M. Contreras
Telefonica I+D
Ronda de la Comunicacion, Sur-3 building, 3rd floor
Madrid 28050
Spain
Email: luismiguel.contrerasmurillo@telefonica.com
URI: http://people.tid.es/LuisM.Contreras/
Parviz Yegani
JUNIPER NETWORKS
1133 Innovation Way
Sunnyvale, CA 94089
Email: pyegani@juniper.net
Karagiannis, et al. Expires April 25, 2015 [Page 7]
Internet-Draft SUPA Problem Statement October 2014
Jean-Francois Tremblay
Viagenie inc.
Email: jean-francois.tremblay@viagenie.ca
Karagiannis, et al. Expires April 25, 2015 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-23 20:42:54 |