Problem Statement for Shared Unified Policy Automation (SUPA)
draft-karagiannis-supa-problem-statement-02

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]