Internet DRAFT - draft-leeking-teas-actn-problem-statement

draft-leeking-teas-actn-problem-statement





Network Working Group                                         Young Lee
Internet Draft                                                   Huawei
Intended status: Informational                              Daniel King
Expires: December 10, 2015                         Lancaster University
                                                           M. Boucadair
                                                         France Telecom
                                                                R. Jing
                                                          China Telecom
                                                   L. Contreras Murillo
                                                             Telefonica
                                                           June 9, 2015


  Problem Statement for Abstraction and Control of Transport Networks
           draft-leeking-teas-actn-problem-statement-00.txt


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with
   the provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire December 10, 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


Lee & King              Expires December 10, 2015               [Page 1]
Internet-Draft                   ACTN PS                      June 2015

   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.

Abstract

   Transport networks that provide connectivity and bandwidth for
   customer services have typically been static, lacking
   flexibility, and requiring long planning times when deploying new
   services. Network Providers and Service Providers have embraced
   technologies that allow separation of data plane and control plane,
   distributed signaling for path setup and protection, and centralized
   path computation for service planning and traffic engineering.
   Although these technologies provide significant benefits, they do
   not meet the growing need for network programmability, automation,
   resource sharing, and service elasticity necessary to meet
   operators' requirements for virtual network operation.

   Virtual network operation refers to the creation of a
   virtualized environment allowing operators to view the
   abstraction of the underlying multi-administration, multi-
   vendor, multi-technology networks and to operate, control, and
   manage these multiple networks as if a single virtualized network.    
   Another dimension of virtual network operation is the use of     
   common core transport network resources by multi-tenant service 
   networks as a way of providing a virtualized infrastructure to 
   flexibly offer new services and applications.

   The work effort investigating this problem space is known as
   Abstraction and Control of Transport Networks (ACTN). This
   document provides an ACTN problem description, a scope of work,
   and outlines the core objectives and requirements to facilitate
   virtual network operation.


Table of Contents

   1. Introduction..................................................4
      1.1. Terminology..............................................5
   2. Objectives and Functional Requirements........................7
      2.1. Use Cases................................................7
          2.1.1 Packet Transport Networks (PTN) in Mobile Backhaul 
            Networks................................................7
          2.1.2 Packet Optical Integration (POI)....................7
          2.1.3 Multi-domain Data Center Interconnect...............7         
          2.1.4 On-demand E2E Connectivity Services in Multiple Vendor
            Domain Transport Networks...............................8
          2.1.5 Multi Tenant Virtual Network Operators..............9


Lee & King              Expires December 10, 2015               [Page 2]
Internet-Draft                   ACTN PS                      June 2015


          2.1.6 Virtual Network Operation for Multiple Domains in a 
            Single Operator Network.................................10
          2.1.7 Mobile Virtual Network Operation for Multiple Domains
            in a Single Operator Network............................10
          2.1.8  Dynamic Service Control based on Performance 
            Monitoring..............................................11
   3. Relationship with Existing Technologies & Other Industry
            Initiatives.............................................11
      3.1. Virtual Private Networks.................................11
      3.2. Overlay Networks.........................................12
      3.3. Other Industry Initiatives...............................12
   4. Motivations for Additional Functionality......................13
      4.1. Business Objectives......................................13
      4.2. Network Resource Recursiveness...........................14
      4.3. Customer-Initiated Programmability.......................14
      4.4. Resource Partitioning....................................14
      4.5. Service Orchestration....................................14
   5. ACTN Objectives and Requirements..............................15
      5.1. Capability and Resource Visibility.......................15
      5.2. Network Programmability..................................16
      5.3. Common Data Models.......................................16
      5.4. Scheduling...............................................17
      5.5. Slicing..................................................17
      5.6. Adaptability.............................................17
      5.7. Allocation...............................................17
      5.8. Isolation................................................18
      5.9. Manageability............................................18
      5.10. Resilience..............................................19
      5.11. Security................................................19
      5.12. Policy..................................................20
      5.13. Technology Independence.................................20
      5.14. Optimization............................................20
      5.15. Multi-domain Support....................................20
      5.16. Architecture Principles.................................20
         5.16.1. Network Partitioning...............................21
         5.16.2. Orchestration......................................21
         5.16.3. Recursion..........................................21
         5.16.4. Legacy Support and Interoperability................21
      5.17. Other Related Work......................................21
         5.17.1. Requirements for Automated (Configuration) Management
         ...........................................................21
         5.17.2. Connectivity Provisioning Negotiation Protocol (CPNP)
         ...........................................................21
   6. References....................................................22
      6.1. Informative References...................................22
   7. Acknowledgements..............................................24
   8. IANA Considerations...........................................24
   9. Authors' Addresses............................................24



Lee & King              Expires December 10, 2015               [Page 3]
Internet-Draft                   ACTN PS                      June 2015


1. Introduction

   Customers continue to demand new services that are time scheduled,
   dynamic, and underpinned by a Pay As You Go billing model.  These
   services are provided to customers by network operators and service
   providers and give rise to a variety of applications for office
   automation, data backup and retrieval, distributed computing, and
   high-quality media broadcasting. They offer Network and Service
   Providers new revenue generation opportunities, and these services
   typically have different traffic characteristics from established
   network services such as file hosting, web, and email. Deploying and
   operating these new applications and services using existing network
   technologies and architectures limits network efficiency,
   scalability, and elasticity (i.e., they do not offer sufficient
   capability to adapt to customer and application demands).

   Network virtualization has been a significant innovation towards
   meeting customer demands and enabling new applications and services.
   Separating network resources, and representing resources and
   topologies via abstracted concepts, facilitates effective sharing
   (or 'slicing') of physical infrastructure into virtual network
   service instances corresponding to multiple virtual network
   topologies that may be used by specific applications, services, and
   users. Further development is required to allow customers to create,
   modify, and delete virtual network services dynamically.

   Transport networks that provide connectivity and bandwidth for
   customer services have typically been static, lacking flexibility,
   and requiring long planning times when deploying new services.
   Network Providers and Service Providers have embraced technologies
   that allow separation of data plane and control plane, distributed
   signaling for path setup and protection, and centralized path
   computation for service planning and traffic engineering. Although
   these technologies provide significant benefits, they do not meet
   the growing need for network programmability, automation, resource
   sharing, and service elasticity necessary to meet operators'
   requirements for virtual network operation.

   Virtual network operation refers to the creation of a virtualized
   environment allowing operators to view the abstraction of the
   underlying multi-administration, multi-vendor, multi-technology
   networks and to operate, control and manage these multiple networks
   as single virtualized network. Another dimension of virtual network
   operation is the use of common core transport network resources by
   multi-tenant service networks as a way of providing a virtualized
   infrastructure to flexibly offer new services and applications.

   Abstraction and Control of Transport Networks (ACTN) defines new
   methods and capabilities for the deployment and operation of


Lee & King              Expires December 10, 2015               [Page 4]
Internet-Draft                   ACTN PS                      June 2015


   transport network resource. These are summarized as follows.

     o Coordination and abstraction of underlying transport network
     resources to higher-layer applications and customers. Note      
     that higher-layer applications and customers could be 
     internal users of the core transport network resource such as        
     various service networks.

     o Multi-domain virtual network operation that facilitates
       multi-administration, multi-vendor, and multi-technology    
       networks as a single virtualized network.

     o Multi-tenant virtual network operation that consolidates
       different network services and applications to allow slicing
       of network resources to meet specific service, application
       and customer requirements.

     o Provision of a computation scheme and virtual control
       capability via a data model to customers who request
       virtual network services. Note that these customers could,    
       themselves, be service providers.

   This document first presents the summary of ACTN use-cases, then
   provides an ACTN problem description and scope of work, and
   outlines the core objectives and requirements to facilitate  
   virtual network operation.

1.1. Terminology

   This document uses the terminology defined in [RFC4655] and
   [RFC5440]. Additional terms are defined below.

     o Customers:

   Customers are users of virtual network services. They are       
   provided with an abstract view of the network resource (known as 
   "a slice") to support their users and applications. In some 
   cases, customers may have to support multiple virtual network 
   services with different service objectives and QoS requirements 
   to enable multiple types of users and applications. Customers 
   may also be considered to be trusted parties with respect to 
   the provider wholesale service department. A trust model will 
   be required and is discussed further later in this document.

     o Service Providers (also Virtual Network Service Provider):

   Service Providers are the providers of virtual network services       
   to their customers. Service Providers typically lease resources      
   from one or more Network Provider to create virtual network      


Lee & King              Expires December 10, 2015               [Page 5]
Internet-Draft                   ACTN PS                      June 2015


   services or offer end-to-end services to their customers. A      
   Service Provider may be a Network Provider such that some or      
   all of the resources used are owned by the Service Provider. A       
   Virtual Network Service Provider is a special type of   
   Service Provider in that they might own no physical equipment    
   or infrastructure, or might have only limited physical  
   infrastructure and require virtual resources to be supplied to 
   them by another Service Provider to offer the final service. A 
   Virtual Network Service Provider only provide services built     
   upon a virtual network infrastructure. The rest of this   
   document does not distinguish between a Virtual Network Service 
   Provider and Service Provider.

     o Network Providers:

   Network Providers are the infrastructure providers that own the       
   physical network resources and provide transport network     
   resources to their customers. Service Providers can be the    
   customers of Network Providers or can be the Network Providers       
   themselves.

     o Network Virtualization:

   Network virtualization, refers to allowing the customers to     
   utilize certain network resources as if they owned them, and thus     
   allows the customers to control their allocated resources in a     
   way most optimal for higher layer or application processes.          
   This customer control facilitates the introduction of new    
   applications (on top of available services) as the customers    
   are given programmable interfaces to create, modify, and delete 
   their virtual network services.

     o Transport Networks:

   Transport networks are defined as network infrastructure that       
   provides connectivity and bandwidth for customer services. They       
   are characterized by their ability to support server layer   
   resources providing connectivity bandwidth and traffic engineering       
   for client layer services, such that resource guarantees may be 
   provided to customers. Transport networks discussed in this 
   document different types of connection-oriented networks 
   including both Connection-Oriented Circuit Switched (CO-CS) 
   networks and Connection-Oriented Packet Switched (CO-PS) 
   networks. This implies that at least the following transport 
   networks are in scope: Layer 1 (L1) and Layer 0 (L0) optical 
   networks (e.g., OTN, ODU, OCh/WSON), MPLS-TP, MPLS-TE, as well 
   as other emerging network technologies with connection-oriented 
   behavior.



Lee & King              Expires December 10, 2015               [Page 6]
Internet-Draft                   ACTN PS                      June 2015


2. Objectives and Functional Requirements

2.1 Use Cases

   A group of Service Providers and Network Providers have identified 
   a number of key use cases that identify key application scenarios for 
   how ACTN may be used. 

2.1.1 Packet Transport Networks (PTN) in Mobile Backhaul Networks 

   The Packet Transport Networks (PTN) Network Provider may use ACTN to 
   improve efficiency of provision and operation, optimize the 
   resources utilization, and promote the customer's experiences. 
   The Internet-Draft [CHENG] discusses the key requirements for ACTN in 
   a PTN environment, these include:

      o Faster End-to-End Enterprise services Provisioning
      
      o Multi-layer coordination in L2/L3 Packet Transport Networks
      
      o Optimizing the network resources utilization (supporting
        various performances monitoring matrix, such as traffic flow
        statistics, packet delay, delay variation, throughput and
        packet-loss rate)
      
      o Virtual Networks Operations for Multi-domain Packet Transport
        Networks

2.1.2 Packet Optical Integration (POI)

   Increasingly there is a need for packet and optical transport
   networks to work together to provide accelerated services.  Transport
   networks can provide useful information to the packet network
   allowing it to make intelligent decisions and control its allocated
   resources. The Internet-Draft [DHODY] outlines the Packet Optical 
   Integration (POI) use case for ACTN, 

   The Internet-Draft [DHODY] discusses the key requirements for ACTN 
   for the Packet Optical Integration (POI) environment, requirements 
   include:

       o Packet Optical Integration to support Traffic Planning,
         performance Monitoring, automated congestion management and
         Automatic Network Adjustments.
         
       o Protection and Restoration Synergy in Packet Optical Multi-
         layer network.
         



Lee & King              Expires December 10, 2015               [Page 7]
Internet-Draft                   ACTN PS                      June 2015

       o Service Awareness and Coordination between Multiple Network
         Domains.
          
2.1.3 Multi-domain Data Center Interconnect   

   Data center operators need to interface multi-domain transport 
   networks to offer their global data center applications and 
   services. As data center providers face multi-domain and diverse 
   transport technology, interoperability based on standard-based 
   abstraction is required for dynamic and flexible applications and 
   services.

   The Internet-Draft [FANG] discusses the key requirements for ACTN 
   for the data center interconnect environment, requirements 
   include:

       o Multi-domain Data Center Interconnection to support VM
         Migration, Global Load Balancing, Disaster Recovery, On-
         demand Virtual Connection/Circuit Services.
         
       o The interfaces between the Data Center Operation and each
         transport network domain should support standards-based
         abstraction with a common information/data model to support
         the following:
         
            - Network Query (Pull Model) from the Data Center
              Operation to each transport network domain to collect
              potential resource availability (e.g., BW availability,
              latency range, etc.) between a few data center
              locations.
             
            - Network Path Computation Request from the Data Center
              Operation to each transport network domain to estimate
              the path availability.
            
            - Network Virtual Connections/Circuits Request from the
              Data Center Operation to each transport domain to
              establish end-to-end virtual connections/circuits (with
              type, concurrency, duration, SLA.QoS parameters,
              protection.reroute policy options, policy constraints
              such as peering preference, etc.).
            
            - Network Virtual Connections/Circuits Modification
              Request.
               
2.1.4 On-demand E2E Connectivity Services in Multiple Vendor             
Domain Transport Networks

   There is a need for creation and operation of a virtualized 
   environment supporting the viewing and controlling different 
   vendor domains, including on-demand network connectivity 


Lee & King              Expires December 10, 2015               [Page 8]
Internet-Draft                   ACTN PS                      June 2015


   service across a single operator environment. This will accelerate 
   rapid service deployment of new services, including more dynamic 
   and elastic services, and improve overall network operations and 
   scaling of existing services.

   The Internet-Draft [KLEE] highlights on-demand edge-to-edge (E2E)   
   connectivity service requirements in multiple vendor domain  
   transport networks, which include:

       o Two-stage path computation capability in a hierarchical
          control architecture (MDSC-PNC) and a hierarchical
          composition of integrated network views.

       o Coordination of signal flow for E2E connections.
       
       o Abstraction of:

            - Inter-connection data between domains

            - Customer Endpoint data

            - The multiple levels/granularities of the abstraction of
              network resource (which is subject to policy and service
              need).

            - Any physical network constraints (such as SRLG, link
              distance, etc.) should be reflected in abstraction.

            - Domain preference and local policy (such as preferred
              peering point(s), preferred route, etc.), Domain network
              capability (e.g., support of push/pull model).

2.1.5 Multi-Tenant Virtual Network Operators

   Creation and operation of multi-tenant virtual networks that use 
   the common core network resources is important to facilitate rapid 
   deployment of new services, including more dynamic and elastic 
   services, and improve overall network operations and scaling of 
   existing services.  
   
   The Internet-Draft [KUMAKI] discusses multi-tenant virtual networks 
   that use the common core network resources, requirements include:

       o On-demand Virtual Network Service Creation
       o Domain Control Plane/Routing Layer Separation
       o Independent service Operation for Virtual Services from
          control of other domains
       o Multiple service level support for each VN (e.g., bandwidth
          and latency for each VN service).


Lee & King              Expires December 10, 2015               [Page 9]
Internet-Draft                   ACTN PS                      June 2015


       o VN diversity/survivability should be met in physical network
          mapping.
       o VN confidentiality and sharing constraint should be supported.

2.1.6 Virtual Network Operation for Multiple Domains in a Single 
Operator Network

   Virtual network operation for multiple domains in a single   
   operator network is required. This would facilitate the 
   application of virtual network abstractions to network operations. 
   These abstractions will create a virtualized environment 
   supporting the viewing and controlling different domains as a 
   single virtualized network.  
   
   This use case is discussed in more detail in [LOPEZ], requirements 
   include:

       o Creation of a global abstraction of network topology: The VNO
          Coordinator assembles each domain level abstraction of
          network topology into a global abstraction of the end-to-end
          network.
          
       o End-to-end connection lifecycle management.
       
       o Invocation of path provisioning request to each domain
          (including optimization requests).
       
       o Invocation of path protection/reroute to the affected
          domain(s).
          
       o End-to-end network monitoring and fault management. This could
          imply potential KPIs and alarm correlation capabilities.
       
       o End-to-end accounting and generation of detailed records for
          resource usage.
       
       o End-to-end policy enforcement

2.1.7 Mobile Virtual Network Operation for Multiple Domains           
in a Single Operator Network

   The use-case for mobile virtual networks with single operator 
   Networks is discuss edin [SHIN]. 

       o Resource abstraction: operational mechanisms in mobile
          backhaul network to give the current network usage
          information for dynamic and elastic applications be
          provisioned dynamically with QoS guarantee.



Lee & King              Expires December 10, 2015              [Page 10]
Internet-Draft                   ACTN PS                      June 2015


       o Load balancing or for recovery, the selection of core DC
          location from edge constitutes a data center selection
          problem.

       o Multi-layer routing and optimization, coordination between
          these two layers.

2.1.8  Dynamic Service Control based on Performance     
       Monitoring

   Transport networks support various performance monitoring 
   mechanisms, such as traffic flow statistics, packet delay, delay 
   variation, throughput and packet-loss rate for MPLS-TP and packet 
   OTN networks, BER, FEC error correction counters for OTN and DWDM 
   networks, etc. These mechanisms may be used to support
   dynamic service control of network resources based on the 
   aforementioned performance monitoring. This use case is discussed in 
   [XU], requirements include: 
   
       o Dynamic Service Control Policy enforcement and Traffic/SLA
          Monitoring:
            - Customer service performance monitoring strategy,
               including the traffic monitoring object (the service
               need to be monitored)
            - monitoring parameters (e.g., transmitted and received
               bytes per unit time),
            - traffic monitoring cycle (e.g., 15 minutes, 24 hours),
            - threshold of traffic monitoring (e.g., high and low
               threshold), etc.


3. Relationship with Existing Technologies & Other Industry Initiatives

3.1. Virtual Private Networks

   A Virtual Private Network (VPN) is a well-known concept
   [RFC4110], [RFC4664], and [RFC4847], and may be used to connect
   multiple distributed sites via a variety of transport
   technologies, sometimes over shared network infrastructure.

   Typically VPNs are managed and provisioned directly by the
   Network Provider or a VPN Service Provider. VPN systems may be
   Classified by:

      o Protocol mechanisms used to tunnel the traffic;

      o Tunnel termination point and/or location;

      o Type of connectivity, site-to-site or remote-access;


Lee & King              Expires December 10, 2015              [Page 11]
Internet-Draft                   ACTN PS                      June 2015


      o Quality of Service (QoS) capabilities;

      o Level of security provided;

      o Emulated service connectivity layer  (layer 1, layer 2,
        layer 3);

   Existing VPN solutions are largely technology specific and offer       
   limited elasticity, although some technologies offer greater      
   flexibility (i.e., layer 2 VPNs [RFC4664] and layer 3 VPNs      
   [RFC4110]) when compared with layer 1 VPNs [RFC4847], all     
   technologies are often deployed using pre-defined configurations.      
   [RFC4847] describes virtual networks in terms of ITU-T [Y.1312]       
   and [Y.1313]. Those Recommendations address both the data plane 
   and control plane aspects of VPNs. Concepts of private and 
   shared VPNs are described.

   The transport layer is achieved by utilizing a variety of      
   technology-specific interfaces - e.g. Gigabit Ethernet (GE),      
   Synchronous Digital Hierarchy (SDH), or Asynchronous Transfer      
   Mode (ATM) for wireless back-hauling, or optical networks OTN and      
   WSON.

   VPNs offer a scalable tunnel solution for customer traffic;      
   However, they are wholly dependent on the Service Provider to      
   setup and manage the VPNs, lacking customer-initiated service      
   programmability: creation, resizing, and deletion.


3.2. Overlay Networks

   An overlay network [RFC4208] provides an enhanced network      
   virtualization technique, with the overlay network providing a      
   topology comprised of virtual or logical links and nodes, which      
   are built on top of physical nodes and links, providing a           
   topology in which some of the links and nodes are virtual or
   logical and are built from multiple nodes or links in a server     
   network.

   Overlay networks are typically used in the multi-layer context      
   in which the packet layer is a client to the server transport      
   layer. The scope of network virtualization in overlay networks is      
   somewhat limited. Customers and applications which need      
   visibility or programmability, and the ability to resize or add      
   resources, may find that overlay network technologies do meet      
   their requirements.

3.3. Other Industry Initiatives



Lee & King              Expires December 10, 2015              [Page 12]
Internet-Draft                   ACTN PS                      June 2015


   ONF Architecture [ONF-SDN-ARCH] describes various arrangements of      
   SDN controllers.

   TM Forum's [TR215] and [TR225] addresses a common information model      
   that can be applied to transport network in particular.

   ITU-T [Y.1312] and [Y.1313] are a good reference to review for      
   Layer 1 VPN in terms of terminology and architecture.


4. Motivations for Additional Functionality

4.1. Business Objectives

   The VPN and overlay network (ON) models are built on the premise 
   that one single Network Provider provides all virtual private or 
   overlay networks to its customers. This model is simple to 
   operate but has some disadvantages in accommodating the    
   increasing need for flexible and dynamic network virtualization      
   capabilities.

   A Network Provider may provide end-to-end services and content 
   (i.e., web and email) to its customers. Other services, 
   applications, and content are typically provided via Service 
   Providers and Over the Top (OTT) (i.e., Video-on-demand, Social 
   Media) providers. We can further categorize Service Providers 
   as:

      o A fixed or mobile Internet Service Provider (ISP) which
        provides Internet connectivity and bandwidth to users;

      o A service provider that leases network resources from one or
        more network providers to create virtual network services
        between ISPs and the core Internet.

      o Data Center (DC)/content Network Provider and Service Providers
        who provide connectivity and bandwidth to content servers and
        application servers.

   Network Providers and Service Providers of every type, all share       
   The common business and revenue objectives:

      o Minimize time to plan and deploy new services;

      o Reduce the reliance on highly skilled personnel to operate
        their network;

      o Reduce time to react to changing business demands and customer
        applications;


Lee & King              Expires December 10, 2015              [Page 13]
Internet-Draft                   ACTN PS                      June 2015


      o Offer new, much more flexible services to their customers;

      o Maximize network resource usage and efficiency.

   All aforementioned objectives have the capability to      
   significantly increase revenue and reduce operational costs.

   Network and Service Providers require capabilities that extend      
   the current landscape of network virtualization capabilities and      
   overall business objectives of the Network Provider, Service      
   Provider, and ultimately the Customer and their Applications.
   
4.2. Network Resource Recursiveness

   A newly emerged network virtualization environment is a      
   collection of heterogeneous network architectures from different            
   players. VPNs and overlay networks are somewhat limited in      
   addressing programmable interfaces for application or customer      
   layers as well as for the service layer. The model must be      
   extended to address a recursive nature of layer interactions in      
   network virtualization across transport networks, service      
   networks, and customers/applications.

4.3. Customer-Initiated Programmability

   Network-driven technologies such as VPNs and overlay networks      
   provide customers with a set of pre-defined programmatic      
   parameters to enable virtual networks. However, this model is      
   limited to only allow programmable interfaces in which customers      
   initiate and define virtual network services. This model must be      
   extended to allow customer-initiated network programmability.

4.4. Resource Partitioning

   The ability to slice and allocate transport resources for Service     
   Providers would be beneficial. It would improve transport network      
   resource efficiency and provide a method for the transport      
   Network Provider to offer resource flexibility and control to      
   Service Providers and users.

4.5. Service Orchestration

   Another dimension is diversity on the customer side. Customers in      
   this newly emerged network virtualization environment bring      
   different dynamics than the traditional VPNs or Overlay Networks.      
   There may be a multiple virtual slices that need to be created,      
   managed and deleted, each interfacing to a number of Service      
   Providers and Network Providers as the end-points of the clients      
   span across multiple network domains. Thus, multiple components      


Lee & King              Expires December 10, 2015              [Page 14]
Internet-Draft                   ACTN PS                      June 2015


   will require automated co-ordination and management, this is      
   known as service orchestration and is therefore one of the key      
   capabilities that should be provided.


5. ACTN Objectives 

   The overall goal of enabling network abstraction and multiple      
   concurrent virtual networks to coexist on a shared physical 
   infrastructure comprised of multiple physical layers may 
   be subdivided into several smaller objectives. These are     
   outlined below and are required in order to fulfill the design     
   goals of ACTN.

   The ACTN effort should utilize existing physical layer monitoring       
   capabilities, algorithmic representation, and modelling of    
   physical layer resources to consider transport metrics and 
   constraints. Moreover, the model of the physical layer resources 
   may need dynamic collection of the status and availability of 
   the underlying transport network infrastructure.

5.1. Capability and Resource Visibility

   It may be necessary for the application or Customer to obtain      
   Information about available capabilities and available network   
   resources, for example, a view and control of abstracted resource. 
   The visibility of the capabilities and the resources can be 
   obtained either by resource discovery or by resource publishing. 
   In the former case, the customer performs resource collection 
   directly from the provider network by using discovery 
   mechanisms to get total information about the available resources 
   to be consumed. In the latter case, the network provider exposes 
   available resources to potential customers (e.g., through a 
   resource catalog) reducing the amount of detail of the 
   underlying network.

   Furthermore, capabilities and resources will also include:

      o Peering Points (may be based on business SLAs or policies);

      o Transport Topology (i.e., transport switching type, topology
        and connection points);

      o Transport Capacity (i.e., current bandwidth and maximum
        bandwidth).

      o Policy Management (i.e., what resources and capabilities are
        available, and what may be requested and by whom).



Lee & King              Expires December 10, 2015              [Page 15]
Internet-Draft                   ACTN PS                      June 2015


      o Information about the provider (i.e., informative data about
        the resource owner)

      o Geographical information about the resources to be
        consumed (i.e., geolocation of the resources for preventing
        legal concerns that could appear in the provision of some
        services).

      o Information about resource cost, consumption, etc. (i.e.,
        energy efficiency per transmitted bit, monetary cost of the
        resource usage per time unit, etc.).

      o Information about achievable resiliency (i.e.,
        protection/restoration capabilities, recovery time, etc.).

5.2. Network Programmability

   The creation of a programmable abstraction layer for physical
   network devices would provide information models which
   would allow operators to manipulate the network resources. By
   utilizing open programmable north-bound network interfaces, it
   would enable access to virtual control layer by customer
   interfaces and applications.

   A programmable interface should provide customers with the
   capabilities to dynamically create, deploy, and operate services
   in response to customer and application demands. 

5.3. Common Data Models

   The data model that describes the abstraction of the underlying
   transport network should be agnostic to each technology
   type within the ACTN framework. The model will provide a uniform
   structure which is extensible to support any future
   technologies.

   The model will represent the physical resources as a set of
   attributes, characteristics and functionality, while adaptively
   capturing the true real-time and dynamic (real-time) properties
   of underlying physical resources.

   The data model can be decomposed into the following elements.

      o Attributes

      o Metrics

      o Control Actions



Lee & King              Expires December 10, 2015              [Page 16]
Internet-Draft                   ACTN PS                      June 2015


      o Semantics

      o Administrative information (resource ownership)

   Virtual infrastructure requests from ACTN customers will be
   translated into network parameters according to aforementioned
   network abstraction model. Utilizing this mechanism, a request is
   translated into topology and multi-dimensional nodes, interfaces
   and spectrum space with specific attributes such as bandwidth,
   QoS, and node capability.

   Apart from facilitating the request of resources, these data
   models could be used for other tasks like network operation
   (e.g., the management of the abstracted transport infrastructure
   by the customer), configuration (e.g., the control of the
   resources), monitoring (e.g., the uniform view of different
   infrastructures in use), Service Level Agreements (SLA) customization 
   (e.g., the particularization of the collected metrics according to 
   the customer interests), etc.

5.4. Scheduling

   When requesting network slices it should be possible to request
   an immediate or scheduled service.

   To enable such on-demand consumption of resources, the Network
   Providers would be capable of employing appropriate scheduling 
   algorithms in a centralized entity, or alternatively distributed 
   across all of the network elements.

5.5. Slicing 

   It should be possible for transport network infrastructure to be
   partitioned into multiple independent virtual networks through a
   process known as "slicing". This partitioning is based on 
   provider service types, customers and application requirements.

5.6. Adaptability

   Adaptability of services would allow the Service Provider, user,
   and application to request modification of existing virtual network
   resources that have been assigned. This may include resizing of 
   bandwidth, modification of the underlying topology, and 
   adding/removing connectivity points to modify the virtual network 
   topology itself.

5.7. Allocation




Lee & King              Expires December 10, 2015              [Page 17]
Internet-Draft                   ACTN PS                      June 2015


   When establishing a network slice, a customer may require
   specific guarantees for the virtual node and link attributes.
   This might include a request that guarantees minimum packet
   processing times on a virtual node, and fixed loss and delay
   characteristics on the virtual links. This should be governed by
   SLAs and can have implications in the supportive transport 
   technologies, and in the properties of the service to be offered 
   to the customer (e.g., protected versus non-protected).

   To provide such guarantees and to create an illusion of an
   isolated and dedicated network slice to each customer, the
   Network Providers must employ the necesssary scheduling capability. 

5.8. Isolation

   Isolation, both of physical underlay infrastructure and of co-
   existing virtual networks, is required for management and
   confidentiality reasons. Additionally there must be no leakage of
   traffic between different customers.
   Furthermore, there must be mechanisms that ensure that once
   network slices are assigned, Customer and Application services do
   not compete for the transport resources that support their
   virtual networks.

   Within their virtual networks, each customer or application
   should be able to use arbitrary network topology, routing, or 
   forwarding functions as well as customized control mechanisms 
   independent of the underlying physical network and of other 
   coexisting virtual networks.

   It must also be possible for many virtual networks to share the
   underlying infrastructure (multi-tenant), without impacting 
   the performance of applications utilizing the virtual networks.

5.9. Manageability

   A broad range of capabilities will need to be provided
   through a set of well-defined interfaces. These capabilities
   apply to the management of end-to-end services and include the
   ability to request, control, provisioning, monitoring, resilience,
   adapt,and re-optimize those services. Specifically it should
   be possible to provide the following funcitons.

      o Control of virtual network resources. This control must be
        capable of delivering end-to-end services with optimization of
        connectivity and virtual infrastructure. Such optimization is 
        based on client interface and application demands, 
        technology constraints (bandwidth, latency, jitter,       
        function, etc.), and commercial constraints (energy, customer          


Lee & King              Expires December 10, 2015              [Page 18]
Internet-Draft                   ACTN PS                      June 2015


        SLA, etc.).

       o Automation of virtual service and function requests and
         objectives, and providing on-demand and self-service network
         slicing subject to policy constraints set by the operators of
         the underlying physical networks, and under the control of
         commercial agreements between all parties.

       o Infrastructure elasticity to allow rapid provisioning,
         automatic scaling out, or in, of virtual resources.

       o Virtual resource monitoring
       
       o Control of bandwidth, energy consumption and quality of 
       service/packet scheduling.


5.10. Resilience

   The resilience of the transport service provided to the customer
   will depend on the requirements expressed by the customer. Two
   different resilience scenarios may be considered: (i) the
   resilience as observed from the point of view of the customer;
   and (ii) the resilience as observed from the point of view of the
   provider.

   The former case refers to the situation in which the customer
   requests specific resilience requirements on the offered
   transport service. For instance, the customer can request
   transport protection through the provision of disjoint paths
   connecting service end-points. This specific requirement forces 
   the provider to explicitly assign transport resources to a 
   customer.

   However there are other situations in which the provider has to
   allocate resources for implicit resilience. For instance, the
   customer could request a service with certain QoS or availability
   for a single connection between service end-points according to
   an SLA. In that case, the provider could trigger recovery actions
   in the network, e.g. during a network outage, and according to
   the conditions of the SLA. These measures may not be perceived by
   the customer.

5.11. Security

   Network programmability may introduce new security and
   misconfiguration vulnerabilities. These must be investigated and
   discussed, and then solved. ACTN-based
   networks must be resilient to existing, and new, faults and
   attacks.

Lee & King              Expires December 10, 2015              [Page 19]
Internet-Draft                   ACTN PS                      June 2015


   Failure or security breach in one ACTN slice should not impact
   another virtual network. It must also be possible to separate
   untrusted services and applications, along with confidential
   services and applications that must be secured.

   Some other aspects are relevant to security within the context of
   ACTN are as follows.

     o Security aspects from the service point of view. For instance,
       encryption capabilities as part of the service capabilities that
       could be requested by the customer.

     o Security aspects from the customer/provider relationship point
       of view. For instance aspects like authentication,
       authorization, logging, etc.

5.12. Policy

   To be discussed. 

5.13. Technology Independence

   ACTN must support a variety of underlay transport technologies,
   providing the flexibility to manage a variety of heterogeneous
   network technologies.

5.14. Optimization

   The service provider must be able to
   optimize the provided transport infrastructure without impacting
   the customer services. As the resources become consumed some
   fragmentation in the usage of the underlying infrastructure could
   occur. The provider then can be interested in optimizing the
   usage of its resources for several reasons (e.g., energy
   consumption, re-utilization of vacant resources, etc.).

5.15. Multi-domain Support

   A given customer could required to compose an end-to-end
   transport service by using network capabilities from different
   service providers that may be internal organizations or external
   entities. Reasons for that could be geographical coverage of the
   service (not fully served by a unique provider), resource
   availability (not enough resources from a given provider), or
   simply resiliency (provider diversity). ACTN should allow the
   multi-domain approach to give the customer the possibility of
   composing multi-provider transport services.

5.16. Architectural Principles


Lee & King              Expires December 10, 2015              [Page 20]
Internet-Draft                   ACTN PS                      June 2015


5.16.1. Network Partitioning

   Coexistence of multiple network slices will need to be supported.
   It should also be possible for multiple network slices used by
   different customers to coexist, spanning part or
   all of the underlying physical networks.

5.16.2. Orchestration

   ACTN should allow orchestration (automated co-ordination of
   functions) for managing and controlling virtual network services
   that may span multiple Service Providers and Network Providers.

5.16.3. Recursion

   It should be possible for a network slice to be segmented to
   allow a slicing hierarchy with parent child relationships.
   Allowing a customer to become a virtual provider is known
   as "recursion" or "nesting" of network slices.

5.16.4. Legacy Support and Interoperability

   The ability to deploy ACTN should be transparent to existing
   physical network control and management mechanisms and protocols.
   Additionally, interoperability with non-ACTN based (i.e.,
   conventional) networks should be guaranteed, thus allowing for
   the coexistence of both kinds of network solutions from the
   perspective of either the customer or the provider.

5.17. Other Related Work

5.17.1. Requirements for Automated (Configuration) Management

   Given the ever-increasing complexity of the configuration tasks
   required for the dynamic provisioning of IP networks and
   services, [I-D.boucadair-network-automation-requirements] aims at
   listing the requirements to drive the specification of an
   automated configuration management framework, including the
   requirements for a protocol to convey configuration information
   towards the managed entities.

5.17.2. Connectivity Provisioning Negotiation Protocol (CPNP)

   [I-D.boucadair-connectivity-provisioning-protocol] specifies
   the Connectivity Provisioning Negotiation Protocol (CPNP) which
   could be used to facilitate the dynamic negotiation of service
   parameters between a Customer and a Provider.  As such, CPNP is a
   generic protocol that can be used for various negotiation
   purposes that include (but are not necessarily limited to)


Lee & King              Expires December 10, 2015              [Page 21]
Internet-Draft                   ACTN PS                      June 2015


   connectivity provisioning services, storage facilities, CDN
   (Content Delivery Networks) footprint, etc.

   The generic Connectivity Provisioning Profile (CPP) template
   allows for:

      o  Automating the process of service negotiation and activation,
         thus accelerating service provisioning;

      o  Setting the (traffic) objectives of Traffic Engineering
         functions and service management functions.

      o  Enriching service and network management systems with
         'decision-making' capabilities based on negotiated/offered
         CPPs.


6. References

6.1. Informative References


      [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
                "Generalized Multiprotocol Label Switching (GMPLS)
                User-Network Interface (UNI): Resource ReserVation
                Protocol-Traffic Engineering (RSVP-TE) Support for the
                Overlay Model", RFC 4208, October 2005.


      [RFC4110] R. Callon and M. Suzuki, "A Framework for Layer 3
                Provider-Provisioned Virtual Private Networks
                (PPVPNs)", RFC 4110, July 2005.

      [RFC4847] T. Takeda, Ed., "Framework and Requirements for Layer 1
                Virtual Private Networks", RFC 4847, April 2007.

      [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path
                 Computation Element (PCE)-Based Architecture", RFC
                 4655, August 2006.

      [RFC4664] L. Andersson, and E. Rosen, Eds., "Framework for Layer
                2 Virtual Private Networks (L2VPNs)", RFC 4664, Sep
                2006.

      [RFC5440] JP. Vasseur, Ed. And JL. Le Roux, Ed. "Path Computation
                Element (PCE) Communication Protocol (PCEP)", RFC 5440,
                March 2009.

      [I-D.boucadair-connectivity-provisioning-protocol]


Lee & King              Expires December 10, 2015              [Page 22]
Internet-Draft                   ACTN PS                      June 2015


                Boucadair, M. and C. Jacquenet, "Connectivity
                Provisioning Negotiation Protocol (CPNP)", draft-
                boucadair-connectivity-provisioning-protocol-09 (work
                in progress), March 2015.

      [I-D.boucadair-network-automation-requirements]
                Boucadair, M. and C. Jacquenet, "Requirements for
                Automated (Configuration) Management", draft-
                boucadair-network-automation-requirements-05 (work in
                progress), February 2015.

      [CHENG] W. Cheng, et. al., "ACTN Use-cases for Packet Transport
             Networks in Mobile Backhaul Networks", draft-cheng-actn-
             ptn-requirements, work in progress.

      [DHODY] D. Dhody, et. al., "Packet Optical Integration (POI) Use
             Cases for Abstraction and Control of Transport Networks
             (ACTN)", draft-dhody-actn-poi-use-case, work in progress.

      [FANG] L. Fang, "ACTN Use Case for Multi-domain Data Center
             Interconnect", draft-fang-actn-multidomain-dci, work in
             progress.

      [KLEE] K. Lee, H. Lee, R. Vilata, V. Lopez, "ACTN Use-case for
             On-demand E2E Connectivity Services in Multiple Vendor
             Domain Transport Networks", draft-klee-actn-connectivity-
             multi-vendor-domains, work in progress.

      [KUMAKI] K. Kumaki, T. Miyasaka, "ACTN : Use case for Multi
             Tenant VNO ", draft-kumaki-actn-multitenant-vno, work in
             progress.

      [LOPEZ] D. Lopez (Ed), "ACTN Use-case for Virtual Network
             Operation for Multiple Domains in a Single Operator
             Network", draft-lopez-actn-vno-multidomains, work in
             progress.

      [SHIN] J. Shin, R. Hwang, J. Lee, "ACTN Use-case for Mobile
             Virtual Network Operation for Multiple Domains in a Single
             Operator Network", draft-shin-actn-mvno-multi-domain, work
             in progress.

      [XU]   Y. Xu, et. al., "Use Cases and Requirements of Dynamic
             Service Control based on Performance Monitoring in ACTN
             Architecture", draft-xu-actn-perf-dynamic-service-control,
             work in progress.
             
      [Y.1312] Y.1312 - Layer 1 Virtual Private Network Generic
             requirements and architecture elements, ITU-T


Lee & King              Expires December 10, 2015              [Page 23]
Internet-Draft                   ACTN PS                      June 2015


             Recommendation, September 2003, available from
             <http://www.itu.int>.
      
      [Y.1313] Y.1313 - Layer 1 Virtual Private Network service and
             network architectures, ITU-T Recommendation, July 2004,
             available from <http://www.itu.int>.

      [TR215] TM Forum TR251, Logical Resource Network Model    
             Advancements and Insights, August 2014, 
             <https://www.tmforum.org>.

      [TR225] TM Forum TR225, Logical Resource: Network Function         
             Model, June 2015, <https://www.tmforum.org>.
      
      [ONF-SDN-ARCH] Software Defined Network Architcture, ONF TR-502,
             June 2014, <https://www.opennetworking.org/>.

7. Acknowledgements

   The authors wish to thank the contributions on the IETF ACTN
   mailing list.


8. IANA Considerations

   This problem statement document makes no requests for IANA action.


9. Authors' Addresses


      Young Lee
      Huawei Technologies
      5340 Legacy Drive
      Plano, TX 75023, USA
      Phone: (469)277-5838
      Email: leeyoung@huawei.com

      Daniel King
      Lancaster University
      Email: d.king@lancaster.ac.uk

      Mohamed Boucadair
      France Telecom
      Rennes  35000
      France
      Email: mohamed.boucadair@orange.com




Lee & King              Expires December 10, 2015              [Page 24]
Internet-Draft                   ACTN PS                      June 2015

      Ruiquan Jing,
      China Telecom Corporation Limited,
      No. 118, Xizhimenneidajie, Xicheng District, Beijing, China
      Email: jingrq@ctbri.com.cn

      Luis Miguel Contreras Murillo
      Telefonica I+D
      Email: lmcm@tid.es












































Lee & King              Expires December 10, 2015              [Page 25]
Internet-Draft                   ACTN PS                      June 2015