Skip to main content

Problem Statement for Simplified Use of Policy Abstractions (SUPA)
draft-karagiannis-supa-problem-statement-05

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 , Qiong Sun , Luis M. Contreras , Parviz Yegani , Jun Bi
Last updated 2015-02-04
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-05
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]