One document matched: draft-karagiannis-supa-problem-statement-05.txt
Differences from draft-karagiannis-supa-problem-statement-04.txt
Network Working Group G. Karagiannis
Internet-Draft Huawei Technologies
Intended status: Informational Q. Sun
Expires: August 4, 2015 China Telecom
Luis M. Contreras
Telefonica
P. Yegani
Juniper Networks
JF Tremblay
Viagenie
J.Bi
Tsinghua University
February 4, 2015
Problem Statement for Simplified Use of Policy Abstractions (SUPA)
draft-karagiannis-supa-problem-statement-05
Abstract
The raise in complexity and size of modern networks makes it
significantly more challenging to deploy new services and to keep
networks up to date while maintaining stability and availability for
critical business services. This is a major challenge that network
operators (service providers, SME, etc) face today. The operators aim
at streamlining operations and the deployment of new services by
relying increasingly on programmatic control of network elements and
the use of various virtualization technologies. In this context,
providing network operators with a set of standard generic YANG-based
data models that enable management and automation of services on
their network is essential. This document describes the set of
related problems addressed by the SUPA (Simplified Use of Policy
Abstractions ) working group.
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."
Karagiannis, et al. Expires August 4, 2015 [Page 1]
Internet-Draft SUPA Problem Statement February 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
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
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . .3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 China Unicom and Telefonica on Inter Data Centers (IDC) . . .4
3.2 China Telecom on DTS (DC Traffic Schedule) . . . . . . . . .4
3.3 CERNET and Tsinghua University . . . . . . . . . . . . . . . 5
3.4 Harvard on VPNs connecting VPCs (Virtual Private Clouds) and
data centers . . . . . . . . . . . . . . . . . . . . . . . . 5
3.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Requirements/Challenges . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1 Normative References . . . . . . . . . . . . . . . . . . 7
8.2 Informative References . . . . . . . . . . . . . . . . . 7
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 business services depend on them. Programmatic ways to
configure networks, often called software-defined, are considered by
many network operators an essential tool toward the management of
that complexity.
Currently, the separation of development and operation of network
technologies leads to slow deployment of network functions/devices,
additional costs and .inevitable downtime. This situation has lead to
the raise of new paradigms such as the DevOps movement.
Karagiannis, et al. Expires August 4, 2015 [Page 2]
Internet-Draft SUPA Problem Statement February 2015
Providing means of exposing a view of the network to applications
provides significant improvements in configuration agility, error
detection and uptime for operators.
This document describes the problem addressed by the SUPA (Simplified
Use of Policy Abstractions ) working group in order to equip service
providers with the means to quickly and dynamically manage their
offering of network services.
1.1 Motivation
The rapid increase in volume and variety of traffic makes it
significantly more challenging to operate and improve networks. This
is a significant challenges network operators (service providers,
SME, etc) face today.
Two complementary mechanisms can be used to deal with this
growing complexity:
o) the use of software abstractions. This mechanism enables the
construction of the simplified views of networks, which hides
complexity from applications while allowing them to configure
common functions within a domain.
o) the increase in programmatic control over the configuration and
operation of networks. This mechanism uses the software
abstractions and control points to more quickly define and
manage network services.
Combining these two mechanisms provides additional and significant
benefits in design and deployment agility.
Moreover, policy-based management can be used to define the
operational aspects of the service environment, but better
abstractions of network resources and services are needed to achieve
these goals.
The SUPA (Simplified Use of Policy Abstractions) working group will
address these two main challenges by developing a methodology and
YANG based data models [RFC6020], [RFC6991], by which management of
network services can be done using standardized and generic policy
rules.
2. Terminology
Network Service: the composition of network functions as defined
by its functional and behavioral specification. The network service
contributes to the behavior of the higher layer service, which is
characterized by performance, dependability, and security
specifications.
Karagiannis, et al. Expires August 4, 2015 [Page 3]
Internet-Draft SUPA Problem Statement February 2015
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 service
topology, associated with a specific network service type, e.g., VPN
or Inter-DC.
3. Use Cases
This section briefly describes the use cases that are associated with
different types of network services. A more detailed description of
these use cases is provided in [ID.draft-cheng-supa-ddc-use-cases].
3.1 China Unicom and Telefonica on Inter Data Centers (IDC)
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 routing policies and adjusting route prioritization to
prefer specific links. Link bandwidth in the data centers are often
overprovisioned and therefore not efficiently utilized. Services
usually have variable bandwidth requirements depending of the time of
day, e.g. video ISP usually require more bandwidth at non-working
hours but require less bandwidth at working hours. Some customers
have high QoS requirement for their services, e.g. IM (Instant
Messaging). Such scenarios are worth modeling because static
bandwidth allocations and manual QoS provisioning for all services is
not a cost-effective solution on the long term.
3.2 China Telecom on DTS (Datacenter Traffic Schedule)
China Telecom is part of a group of operators testing and
implementing a new management schema called Datacenter Traffic
Schedule (DTS). Due to the rapid development of Internet services,
each single datacenter location cannot meet all the requirements of
a given service. A general model has been developed to host service
instances in multiple collaborating datacenters. More specifically,
client systems can request resources from a single virtual
datacenter, making the service more flexible and scalable. This also
provides for more reliability and security of services. As a result,
inter datacenter traffic has increased dramatically during the last
years. Service instances located in different datacenters will
exchange large volume of data for backup and storage, which may
occur at a fixed or variant times each day. In such an environment, a
management system is able to monitor traffic volume on the links
between datacenters and react accordingly to prevent synchronization
and resource exhaustion. When the volume exceeds the threshold set
Karagiannis, et al. Expires August 4, 2015 [Page 4]
Internet-Draft SUPA Problem Statement February 2015
by the system, it requests traffic adjustments to move
overflowing traffic on other links. Such scenarios are well worth
modeling as operators need to design flexible adjustment policies for
optimizing the throughput of datacenter edge routers.
3.3 CERNET and Tsinghua University
There are requirements from campus network operators to flexibly
manage traffic for multiple functions in a building, such as traffic
for network operation, traffic for building monitoring network,
traffic for professor working on test-bed/data for different research
projects. Traditionally, the operation staffs manually set up VLANs
for different users. However, the increasing number of projects/users
makes it very hard to manually set up those different
network/test-beds in the shared building LAN, because sometimes one
office having multiple rights to access different networks/projects.
Therefore, SUPA could potentially proving flexible VPN set up on the
shared infrastructure (based on IP/MAC address, VLAN ID, etc.). In
this case, a controller and standardized northbound APIs could serve
for an application for operators to flexibly set up the access to
different resources. In general, SUPA will help operators or service
providers to design flexible adjustment policies for optimizing the
throughput of layer two devices.
3.4 Harvard on VPNs connecting VPCs (Virtual Private Clouds) and data
centers
Harward currently uses a number of Virtual Private Clouds (VPCs) to
provide capacity for various internal applications. The VPCs need to
securely exchange data with the local data center, which is not
exposed to the general Internet. Inter-site IPsec VPNs have been the
mechanism of choice to secure these connections in the past. However
the complexity of managing the VPNs increases exponentially as the
number of VPCs and the data centres becomes larger. SUPA would be
used to model, monitor and manage such VPNs.
3.5 Conclusion
SUPA can be used to address the requirements imposed by these use
Cases. SUPA can 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 datacenters, SUPA can be used to
dynamically reconfigure these VPNs in order to avoid
possible congested communication paths and improve end to end
latency.
In particular, the first use case that the SUPA working group will
focus on will be the inter-datacenter traffic management, in the use
case of a Distributed Data Center, including the automated
provisioning of site-to-site VPNs of various types, e.g., IPSec, MPLS
L2VPN and L3VPN tunnels.
Karagiannis, et al. Expires August 4, 2015 [Page 5]
Internet-Draft SUPA Problem Statement February 2015
4. Requirements and Challenges
In order to satisfy the requirements imposed by the use cases
described in Section 3, three main challenges have to be addressed:
1) the support of service deployment over the network
topology requires a YANG based data model of
the network topology that includes the resources
(e.g., data rate or latency of links) and operational parameters.
2) in order to correctly execute, deploy and perform the network
service in the physical and/or virtual topology a YANG based data
model of the specific network service and the network resources is
required.
3) the management of a network service and the dynamical mapping of
the network service to the network topology and network resources
requires the specification and implementation of a YANG based data
model of policy rules.
Several working groups in IETF such as I2RS, BGP, PCE focus on data
models that describe the network element centric view. Furthermore,
some published Individual Internet drafts associated with some of
these IETF WGs focus on data models of physical and virtual
network topology. However, none of these IETF WGs focus on:
o) models of the network service and the network resources required
by the network service to be correctly executed in the physical
and/or virtual topology to deploy and perform the service
o) models of policy rules for managing the network service and
mapping services dynamically to the network topology and network
resources including the resources
SUPA can address the above listed requirements/challenges by
developing a methodology and YANG based data models by which
management of network services can be done using standardized policy
rules. In particular, the network is first defined as a topology.
Depending on IESG decisions, the YANG based data model required for
the specification of the network topology can be selected to be
either the output work of existing IETF WGs or a data model specified
within SUPA WG.
A service is then defined as a service topology layered above the
network topology.
Subsequently, a set of policy rules is then defined to manage the
service. In this approach, service specific policy data models will
be derived from a generic policy model, ensuring that policies have a
common structure and can be easily reused as managed objects.
The SUPA working group will communicate with other SDOs (MEF, ETSI)
Working on related issues.
Karagiannis, et al. Expires August 4, 2015 [Page 6]
Internet-Draft SUPA Problem Statement February 2015
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, Scott O.
Bradner.
Tina Tsou and Will Liu contributed to an early version of this draft.
8. References
8.1. Normative References
8.2. Informative References
[ID.draft-cheng-supa-ddc-use-cases] Y. Cheng, JF. Tremblay, J. Bi,
"Use Cases for Distributed Data Center Applications in SUPA", IETF
Internet draft (Work in progress), draft-cheng-supa-ddc-use-cases-03,
February 2, 2015
[RFC6020] M. Bjorklund, "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
[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
Karagiannis, et al. Expires August 4, 2015 [Page 7]
Internet-Draft SUPA Problem Statement February 2015
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
Jean-Francois Tremblay
Viagenie inc.
Email: jean-francois.tremblay@viagenie.ca
Jun Bi
Tsinghua University
Network Research Center, Tsinghua University
Beijing 100084
China
EMail: junbi@tsinghua.edu.cn
Karagiannis, et al. Expires August 4, 2015 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-23 20:58:37 |