Network Working Group Young Lee
Internet Draft Huawei
Daniel King
Intended status: Informational Lancaster University
Expires: August 5,2014
February 5, 2014
Problem Statement for Abstraction and Control of Transport Networks
draft-leeking-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 on August 5, 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
Lee and King Expires August 5, 2014 [Page 1]
Internet-Draft ACTN Problem Statement February 2014
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.
Abstract
Previously transport networks were typically static, lacked
flexibility, and required 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 for meeting
customer demands and evolving Internet applications
By combining the aforementioned capabilities with network resource
virtualization and abstraction mechanisms, available via well-
defined customer interfaces, providing significant operational
benefits to meet the growing demands from customers 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, scope of work,
and outlines the core requirements to facilitate network resource
virtualization and resource slicing for customers and applications,
across Service Provider and Network Provider transport network
infrastructure.
Table of Contents
1. Introduction...................................................3
1.1. Terminology...............................................4
2. Relationship with Existing Technologies........................6
2.1. Virtual Private Networks..................................6
2.2. Overlay Networks..........................................7
3. Motivations for Additional Functionality.......................7
3.1. Business Objectives.......................................7
3.2. Network Resource Recursiveness............................8
3.3. Customer-Initiated Programmability........................8
Lee & King Expires August 5, 2014 [Page 2]
Internet-Draft ACTN Problem Statement February 2014
3.4. Resource Partitioning.....................................8
3.5. Service Orchestration.....................................9
4. ACTN Objectives and Requirements...............................9
4.1. Capability and Resource Discovery.........................9
4.2. Network Programmability..................................10
4.3. Common Data Models.......................................10
4.4. Scheduling and Allocation................................11
4.5. Adaptability.............................................11
4.6. Slicing..................................................11
4.7. Isolation................................................11
4.8. Manageability............................................12
4.9. Resilience...............................................12
4.10. Security................................................13
4.11. Policy..................................................13
4.12. Technology Independence.................................13
4.13. Architecture Principles.................................13
4.13.1. Network Partitioning...............................13
4.13.2. Orchestration......................................13
4.13.3. Recursion..........................................13
4.13.4. Legacy Support.....................................14
5. References....................................................14
5.1. Informative References...................................14
6. Contributors........................Error! Bookmark not defined.
Authors' Addresses...............................................15
Intellectual Property Statement..................................15
Disclaimer of Validity...........................................15
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 Providers 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 traditional
network architectures limits network efficiency, scalability, and
elasticity (i.e., capable of adapting 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
Lee & King Expires August 5, 2014 [Page 3]
Internet-Draft ACTN Problem Statement February 2014
and topologies via abstracted concepts, facilitate 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 and services.
Further development is required to allow customers to create,
modify, and delete virtual network services dynamically.
Abstraction and Control of Transport Networks (ACTN) defines new
methods and capabilities for the deployment and operation of
transport network resource. These are summarized as:
o Abstraction of underlying network resources to higher-layer
applications and customers;
o Slicing of network resources to meet specific application and
customer requirements;
o Provision of a computation scheme and virtual control
capability, via an data model, to customers who request virtual
network services;
o Coordination of underlying transport layers and presentation as
an abstracted topology to the customer.
This document provides an ACTN problem description and scope of
work, and outlines the core requirements to facilitate network
resource virtualization and resource slicing for Network Providers,
Service Providers, Customers, and applications.
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 resource 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 support
multiple types of users and applications.
Lee & King Expires August 5, 2014 [Page 4]
Internet-Draft ACTN Problem Statement February 2014
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
single or multiple Network Providers' facilities to create virtual
network services and offer end-to-end services to their customers.
A Virtual Network Service Provider is a type of Service Provider,
except that they own no physical equipment or infrastructure, and
only provide services built upon virtual network infrastructure. In
general, 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
a certain network resources as if they own them and thus allows them
to control their allocated resources in a way most optimal with
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 provisioning
and traffic engineering for client layer services, such that
resource guarantees may be provided to their customers. Transport
networks in this document refer to a set of different type of
connection-oriented networks, which include 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 of the discussion of this draft:
Layer 1 (L1) optical networks (e.g., Optical Transport Networks
(OTN) and Wavelength Switched Optical Networks (WSON)), MPLS-TP,
MPLS-TE, as well as other emerging network technologies with
connection-oriented behavior.
Lee & King Expires August 5, 2014 [Page 5]
Internet-Draft ACTN Problem Statement February 2014
2. Relationship with Existing Technologies
2.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;
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.
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.
Lee & King Expires August 5, 2014 [Page 6]
Internet-Draft ACTN Problem Statement February 2014
2.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. Motivations for Additional Functionality
3.1. Business Objectives
The traditional 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 traditional end-to-end services and
content (i.e., web and email) to its customers. Emerging 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 Providers (ISPs) which provide
Internet connectivity and bandwidth to uses;
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:
Lee & King Expires August 5, 2014 [Page 7]
Internet-Draft ACTN Problem Statement February 2014
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;
o Offer new, much more flexible services to their customers;
o Maximize network resource usage and efficiency.
All aforementioned objectives have the capability to significant
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.
3.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.
3.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.
3.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.
Lee & King Expires August 5, 2014 [Page 8]
Internet-Draft ACTN Problem Statement February 2014
3.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 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.
4. ACTN Objectives and Requirements
The overall goal of enabling network abstraction and multiple
concurrent virtual networks to coexist together on a shared physical
infrastructure, comprised on multiple physical layers, and 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 appropriate metrics and
constraints. Moreover, the model may want to support dynamic
collection of the statistics (i.e., status and availability) of the
underlying transport network infrastructure.
4.1. Capability and Resource Discovery
It may be necessary for the application or Customer to discover
available capabilities and available network resources, for example,
abstracted resource view and control. 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 August 5, 2014 [Page 9]
Internet-Draft ACTN Problem Statement February 2014
4.2. Network Programmability
A programmable interface should provide customers with the
capabilities to dynamically create, deploy, and operate services in
response to customer and application demands. To enable the on-
demand services, the separation of control and forwarding is a
fundamental requirement. Once this separation is achieved the
network layer may be programmed irrespective of the underlying
forwarding mechanism.
The creation of a programmable abstraction layer for physical
network devices would provide distributed computing objects 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.
4.3. Common Data Models
The abstraction of the underlay transport, and resource information
representation model should describe each technology type within the
ACTN framework; they will all follow a uniform structure, which is
extensible to support any future technologies.
Such models 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.
For future discussion, abstraction and the technology agnostic
virtualization requirements may benefit from being split into new
sub-sections, suggested below:
o Attributes
o Metrics
o Control Actions
o Semantics
Resources will be described with semantic methods so that the
resource description models can be exposed in a uniformly structured
manner to the upper layers.
Lee & King Expires August 5, 2014 [Page 10]
Internet-Draft ACTN Problem Statement February 2014
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.
4.4. Scheduling and Allocation
When requesting network slices it should be possible to request an
immediate or scheduled service. 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 on a virtual node, and fixed loss and
delay characteristics on the virtual links.
To provide such guarantees and to create an illusion of an isolated
and dedicated network slice to each customer, Network Providers must
employ appropriate scheduling algorithms in all of the network
elements.
4.5. Adaptability
Adaptability of services would allow the Service Provider, user, and
application to request modification of exist network resource that
has been assigned. This may include resizing of bandwidth,
modification of the topology, and adding/removing connectivity
points.
4.6. Slicing
It should be possible for transport network infrastructure to be
partitioned into multiple independent virtual networks known as
"slicing", based on provider service types, customers and
application requirements.
4.7. Isolation
Isolation, both of physical underlay infrastructure and of co-
existing virtual networks, and ensure no leakage of traffic.
Furthermore, there must be mechanisms that ensure that once network
slices are assigned Customer and Application services are not
competing for independent transport resources.
Lee & King Expires August 5, 2014 [Page 11]
Internet-Draft ACTN Problem Statement February 2014
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 other coexisting virtual networks.
It must also be possible for many virtual networks to share the
underlying infrastructure, without significantly impacting the
performance of applications utilizing the virtual networks.
4.8. Manageability
A broad range of capabilities, including: request, control,
provisioning, monitoring, resilience, adaptation and re-optimisation
of end-to-end services will need to be provided through a set of
well-defined interfaces, specifically it should be possible to
provide:
o Control of virtual network resources, capable of delivering end-
to-en services optimisation of connectivity and virtual
infrastructure based on client interface and application
demands, technology constraints (bandwidth, latency, jitter,
function, etc.) and commercial constraints (energy, customer
SLA, etc.).
o Automation of virtual service and function requests and
objectives, and providing on-demand and self-service network
slicing.
o Infrastructure elasticity to allow rapid provisioning, automatic
scaling out, or in, of virtual resources.
o Virtual resource monitoring [Editor's Note: Control of
bandwidth, energy consumption and quality of service/packet
scheduling.]
[Editor's Note: The requirements on the technology driver from both
sides need to be analysed, e.g. the information update frequency.]
4.9. Resilience
[To be discussed.]
Lee & King Expires August 5, 2014 [Page 12]
Internet-Draft ACTN Problem Statement February 2014
4.10. Security
Network programmability may introduce new security and
misconfiguration vulnerabilities. These must be investigated and
discussed, and then solved with suitable solutions. ACTN-based
networks must be resilient to existing, and new, faults and attacks.
Failure or security breach in one ACTN slice should not impact
another virtual network. It must also be possible for separation of
untrusted services and applications, along with confidential
services and applications that must be secured.
4.11. Policy
[To be discussed.]
4.12. Technology Independence
ACTN must support a variety of underlay transport technologies,
providing the flexibility to manage a variety of heterogeneous
network technologies.
4.13. Architecture Principles
4.13.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 together, spanning over part or full
of the underlying physical networks.
4.13.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.
4.13.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, this is known as recursion as
well as nesting of network slices.
Lee & King Expires August 5, 2014 [Page 13]
Internet-Draft ACTN Problem Statement February 2014
4.13.4. Legacy Support
Capability to deploy ACTN should be transparent to existing physical
network control and management mechanisms and protocols.
5. References
5.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.
[RFC4664] L. Andersson, and E. Rosen, Eds., "Framework for Layer 2
Virtual Private Networks (L2VPNs)", RFC 4664, Sep 2006.
[RFC4665] W. Augustyn, Ed. and Y. Serbest, Ed., "Service
Requirements for Layer 2 Provider-Provisioned Virtual
Private Networks", RFC 4665, September 2006.
[RFC5440] JP. Vasseur, Ed. And JL. Le Roux, Ed. "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009.
6. Acknowledgements
The authors wish to thank the contributions on the IETF ACTN mailing
list.
Lee & King Expires August 5, 2014 [Page 14]
Internet-Draft ACTN Problem Statement February 2014
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
Intellectual Property Statement
The IETF Trust takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology
described in any IETF Document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights.
Copies of Intellectual Property disclosures made to the IETF
Secretariat and any assurances of licenses to be made available, or
the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers or
users of this specification can be obtained from the IETF on-line
IPR repository at http://www.ietf.org/ipr
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
Disclaimer of Validity
All IETF Documents and the information contained therein are
provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION
HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY,
THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
Lee & King Expires August 5, 2014 [Page 15]
Internet-Draft ACTN Problem Statement February 2014
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Lee & King Expires August 5, 2014 [Page 16]