Network Working Group Daniele Ceccarelli
Internet Draft Ericsson
Intended status: Informational Luyuan Fang
Expires: April 2015 Microsoft
Young Lee
Huawei
Diego Lopez
Telefonica
Sergio Belotti
Alcatel-Lucent
Daniel King
Lancaster University
October 20, 2014
Framework for Abstraction and Control of Transport Networks
draft-ceccarelli-actn-framework-04.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.
Ceccarelli, et al. Expires April 20, 2015 [Page 1]
Internet-DraftAbstraction and Control of Transport Networks October 2014
This Internet-Draft will expire on April 20, 2015.
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.
Abstract
This draft provides a framework for abstraction and control of
transport networks.
Table of Contents
1. Terminology....................................................3
2. Introduction...................................................4
3. Business Model of ACTN.........................................6
3.1. Customers.................................................7
3.2. Service Providers.........................................8
3.3. Network Providers........................................10
4. Multi-Domain Model............................................10
5. Computation Model of ACTN.....................................13
5.1. Request Processing.......................................13
5.2. Computing Time...........................................13
5.3. Path Constraints.........................................13
5.4. Types of Network Resources...............................14
5.5. Accuracy of Network Resource Representation..............14
5.6. Resource Sharing and Efficiency..........................14
5.7. Guarantee of Client Isolation............................15
6. Architecture Model for ACTN...................................15
6.1. ACTN Interfaces..........................................15
6.1.1. ACTN Interface Scope................................18
6.2. Key ACTN Entities........................................18
6.2.1. Customer Network Controller.........................18
Ceccarelli, et al. Expires April20,2015 [Page 2]
Internet-DraftAbstraction and Control of Transport Networks October 2014
6.2.2. Virtual Network Controller..........................19
6.2.3. Physical Network Controller.........................20
6.3. Abstracted Topology Illustration.........................21
6.4. ACTN Interface Interaction...............................25
7. Design Principles of ACTN.....................................28
7.1. Network Security.........................................28
7.2. Privacy and Isolation....................................28
7.3. Scalability..............................................28
7.4. Manageability and Orchestration..........................29
7.5. Programmability..........................................29
7.6. Network Stability........................................29
8. References....................................................29
8.1. Informative References...................................29
Appendix A.......................................................30
Contributors' Addresses..........................................30
Authors' Addresses...............................................31
1. Terminology
This document uses the terminology defined in [RFC4655], and
[RFC5440]. The following terminology is defined in this draft while
PCE, PCC and PCEP are borrowed from [RFC4655] and [RFC5440].
ABNO Application-Based Network Operations
CNC Customer Network Controller
CVI Customer-VNC Interface
PCC Path Computation Client
PCE Path Computation Entity
PCEP Path Computation Protocol
PNC Physical Network Controller
VL Virtual Link
VN Virtual Network
VNM Virtual Network Mapping
VNC Virtual Network Controller
Ceccarelli, et al. Expires April20,2015 [Page 3]
Internet-DraftAbstraction and Control of Transport Networks October 2014
VNE Virtual Network Element
VNS Virtual Network Service
VPI VNC-PNC Interface
2. Introduction
Transport networks have a variety of mechanisms to facilitate
separation of data plane and control plane including distributed
signaling for path setup and protection, centralized path
computation for planning and traffic engineering, and a range of
management and provisioning protocols to configure and activate
network resources. These mechanisms represent key technologies for
enabling flexible and dynamic networking.
Transport networks in this draft refer to a set of different type of
connection-oriented networks, primarily 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)
and Layer 0 (L0) optical networks (e.g., Optical Transport Network
(OTN), Optical Channel Data Unit (ODU), Optical Channel
(OCh)/Wavelength Switched Optical Network (WSON)), Multi-Protocol
Label Switching - Transport Profile (MPLS-TP), Multi-Protocol Label
Switching - Traffic Engineering (MPLS-TE), as well as other emerging
technologies with connection-oriented behavior. One of the
characteristics of these network types is the ability of dynamic
provisioning and traffic engineering such that resource guarantee
can be provided to their clients.
One of the main drivers for Software Defined Networking (SDN) is a
decoupling of the network control plane from the data plane. This
separation of the control plane from the data plane has been already
achieved with the development of MPLS/GMPLS [GMPLS] and PCE [PCE]
for TE-based transport networks. In fact, in transport networks such
separation of data and control plane was dictated at the onset due
to the very different natures of the data plane (circuit switched
Time Division Multiplexing (TDM) or Wavelength Division Multiplexing
(WDM)) and a packet switched control plane. The decoupling of the
control plane and the data plane is a major step towards allowing
operators to gain the full control for optimized network design and
operation. Moreover, another advantage of SDN is its logically
centralized control regime that allows a global view of the
underlying network under its control. Centralized control in SDN
helps improve network resources utilization from a distributed
network control. For TE-based transport network control, PCE is
Ceccarelli, et al. Expires April20,2015 [Page 4]
Internet-DraftAbstraction and Control of Transport Networks October 2014
essentially equivalent to a logically centralized control for path
computation function.
As transport networks evolve, the need to provide network
abstraction has emerged as a key requirement for operators; this
implies in effect the virtualization of network resources so that
the network is "sliced" for different uses.
Network slicing may be utilized for specific services and requested
by higher-layer "applications", in this context types of application
include management components such as Network Management Systems
(NMS) and Operations Support Systems (OSS). Each customer is given a
different partial view of the total topology and considering that it
is operating with a single, stand-alone and consistent network.
Particular attention needs to be paid to the multi-domain case,
where Abstraction and Control of Transport Networks (ACTN) can
facilitate virtual network operation via the creation of a single
virtualized network. This supports operators in viewing and
controlling different domains (at any dimension: applied technology,
administrative zones, or vendor-specific technology islands) as a
single virtualized network.
Network virtualization, in general, refers to allowing the customers
to utilize a certain amount of network resources as if they own them
and thus control their allocated resources in a way most optimal
with higher layer or application processes. This empowerment of
customer control facilitates introduction of new services and
applications as the customers are permitted to create, modify, and
delete their virtual network services. The level of virtual control
given to the customers can vary from a tunnel connecting two end-
points to virtual network elements that consist of a set of virtual
nodes and virtual links in a mesh network topology. More flexible,
dynamic customer control capabilities are added to the traditional
VPN along with a customer specific virtual network view. Customers
control a view of virtual network resources, specifically allocated
to each one of them. This view is called an abstracted network
topology. Such a view may be specific to the set of consumed
services as well as to a particular customer. As the Customer
Network Controller is envisioned to support a plethora of distinct
applications, there would be another level of virtualization from
the customer to individual applications.
The virtualization framework described in this draft is named
Abstraction and Control of Transport Network (ACTN) and facilitates:
Ceccarelli, et al. Expires April20,2015 [Page 5]
Internet-DraftAbstraction and Control of Transport Networks October 2014
- Abstraction of the underlying network resources to higher-layer
applications and users (customers); abstraction for a specific
application or customer is referred to as virtualization in the
ONF SDN architecture. [SDN-ARCH]
- Slicing infrastructure to connect multiple customers to meet
specific application and users requirements;
- Creation of a virtualized environment allowing operators to
view and control multi-subnet multi-technology networks into a
single virtualized network;
- A computation scheme, via an information model, to serve
various customers that request network connectivity and
properties associated with it;
- A virtual network controller that adapts customer requests to
the virtual resources (allocated to them) to the supporting
physical network control and performs the necessary mapping,
translation, isolation and security/policy enforcement, etc.;
This function is often referred to as orchestration.
- The coordination of the underlying transport topology,
presenting it as an abstracted topology to the customers via
open and programmable interfaces. This allows for the recursion
of controllers in a customer-provider relationship.
The organization of this draft is as follows. Section 3 provides a
discussion for a Business Model, Section 4 a Computation Model,
Section 5 a Control and Interface model and Section 6 Design
Principles.
3. Business Model of ACTN
The traditional Virtual Private Network (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.
The ACTN model is built upon entities that reflect the current
landscape of network virtualization environments. There are three
key entities in the ACTN model [ACTN-PS]:
Ceccarelli, et al. Expires April20,2015 [Page 6]
Internet-DraftAbstraction and Control of Transport Networks October 2014
- Customers
- Service Providers
- Network Providers
3.1. Customers
Within the ACTN framework, different types of customers may be taken
into account depending on the type of their resource needs, on their
number and type of access. As example, it is possible to group them
into two main categories:
Basic Customer: Basic customers include fixed residential users,
mobile users and small enterprises. Usually the number of basic
customers is high; they require small amounts of resources and are
characterized by steady requests (relatively time invariant). A
typical request for a basic customer is for a bundle of voice
service and internet access. Moreover basic customers do not modify
their services themselves; if a service change is needed, it is
performed by the provider as proxy and they generally has very few
dedicated resources (subscriber drop), with everything else shared
on the basis of some SLA, which is usually best-efforts.
Advanced Customer: Advanced customers typically include enterprises,
governments and utilities. Such customers can ask for both point to
point and multipoint connectivity with high resource demand
significantly varying in time and from customer to customer. This is
one of reasons why a bundled services offer is not enough but it is
desirable to provide each of them with customized virtual network
services. Advanced customers may own dedicated virtual resources, or
share resources, but shared resources are likely to be governed by
more complex SLA agreements; moreover they may have the ability to
modify their service parameters directly (within the scope of their
virtualized environments).As customers are geographically spread
over multiple network provider domains, the necessary control and
data interfaces to support such customer needs is no longer a single
interface between the customer and one single network provider. With
this premise, customers have to interface multiple providers to get
their end-to-end network connectivity service and the associated
topology information. Customers may have to support multiple virtual
network services with differing service objectives and QoS
requirements. For flexible and dynamic applications, customers may
want to control their allocated virtual network resources in a
dynamic fashion. To allow that, customers should be given an
abstracted view of topology on which they can perform the necessary
control decisions and take the corresponding actions. ACTN's primary
focus is Advanced Customers.
Ceccarelli, et al. Expires April20,2015 [Page 7]
Internet-DraftAbstraction and Control of Transport Networks October 2014
Customers of a given service provider can in turn offer a service to
other customers in a recursive way. An example of recursiveness with
2 service providers is shown below.
- Customer (of service B)
- Customer (of service A) & Service Provider (of service B)
- Service Provider (of service A)
- Network Provider
+-----------------------------------------------------------------+ ---
| | ^
| Customer (of service B)| .
| +-------------------------------------------------------------+ | B
| | | |--- .
| | Customer (of service A) & Service Provider(of service B)| | ^ .
| | +--------------------------------------------------------+ | | . .
| | | | | | . .
| | | Service Provider (of service A)| | | A .
| | |+-----------------------------------------------+ | | | . .
| | || | | | | . .
| | || Network provider| | | | v v
| | |+-----------------------------------------------+ | | |------
| | +--------------------------------------------------------+ | |
| +-------------------------------------------------------------+ |
+-----------------------------------------------------------------+
Figure 1: Network Recursiveness.
3.2. Service Providers
Service providers are the providers of virtual network services to
their customers. Service providers may or may not own physical
network resources. When a service provider is the same as the
network provider, this is similar to traditional VPN models. This
model works well when the customer maintains a single interface with
a single provider. When customer location spans across multiple
independent network provider domains, then it becomes hard to
facilitate the creation of end-to-end virtual network services with
this model.
A more interesting case arises when network providers only provide
infrastructure while service providers directly interface their
customers. In this case, service providers themselves are customers
Ceccarelli, et al. Expires April20,2015 [Page 8]
Internet-DraftAbstraction and Control of Transport Networks October 2014
of the network infrastructure providers. One service provider may
need to keep multiple independent network providers as its end-users
span geographically across multiple network provider domains.
Customer X -----------------------------------X
Service Provider A X -----------------------------------X
Network Provider B X-----------------X
Network Provider A X------------------X
The ACTN network model is predicated upon this three tier model and
is summarized in figure below:
+----------------------+
| customer |
+----------------------+
|
| /\ Service/Customer specific
| || Abstract Topology
| ||
+----------------------+
| VNC | E2E abstract
| Service Provider | topology creation
+----------------------+
/ | \
/ | \ Network Topology
/ | \ (raw or abstract)
/ | \
+------------------+ +------------------+ +------------------+
|Network Provider 1| |Network Provider 2| |Network Provider 3|
+------------------+ +------------------+ +------------------+
Figure 2: Three tier model.
There can be multiple types of service providers.
Ceccarelli, et al. Expires April20,2015 [Page 9]
Internet-DraftAbstraction and Control of Transport Networks October 2014
. Data Center providers: can be viewed as a service provider type
as they own and operate data center resources to various WAN
clients, they can lease physical network resources from network
providers.
. Internet Service Providers (ISP): can be a service provider of
internet services to their customers while leasing physical
network resources from network providers.
. Mobile Virtual Network Operators (MVNO): provide mobile
services to their end-users without owning the physical network
infrastructure.
The network provider space is the one where recursiveness occurs. A
customer-provider relationship between multiple service providers
can be established leading to a hierarchical architecture of service
provider controllers (NVCs).
3.3. Network Providers
Network Providers are the infrastructure providers that own the
physical network resources and provide network resources to their
customers. The layered model proposed by this draft separates the
concerns of network providers and customers, with service providers
acting as aggregators of customer requests.
4. Multi-Domain Model
Network operators build and operate multi-domain networks and these
domains may be technology, administrative or vendor specific (vendor
islands). Interoperability for dealing with different domains is a
perpetual problem for operators. Due to these issues, new service
introduction, often requiring connections that traverse multiple
domains, need significant planning, and several manual operations to
interface different vendor equipment and technology.
The creation of a virtualized environment allowing operators to view
and control multi-subnet multi-technology networks into a single
virtualized network highly facilitates network operators and will
accelerate rapid service deployment of new services, including more
dynamic and elastic services, and improve overall network operations
and scaling of existing services.
From Section 3 in which the generic ACTN business model was
discussed, this section provides the application of the generic ACTN
business model into multi-domain management context within a single
Ceccarelli, et al. Expires April20,2015 [Page 10]
Internet-DraftAbstraction and Control of Transport Networks October 2014
operator's Administrative Control. Thus, the following mapping is
applied here:
--------------------------------------------------------------------
Generic Business Model | Multi-domain Model
--------------------------------------------------------------------
Customers | Multi-tenant Service Departments
Service Provider | Virtual Network Control Coordinator
Network Providers | Domain Networks
--------------------------------------------------------------------
Figure 3 depicts the three-tier relationship of multi-domain model.
+----------------+ +---------------+ +--------------+
| Service 1 | | Service 2 | ... | Service M |
+----------------+ +---------------+ +--------------+
\ | /
\ | / /\ Service-Specific
\ | / || Abstract Topology
\ | / ||
+----------------------+
| VNC | E2E abstract
| Coordination | topology creation
+----------------------+
/ | \
/ | \ Network Topology
/ | \ (raw or abstract)
/ | \
+------------------+ +------------------+ +------------------+
| Network Domain 1 | | Network Domain 2 | .. | Network Domain N |
+------------------+ +------------------+ +------------------+
Figure 3: Multi-domain three-tier relationship
Figure 3 depicts the three entities that are internal to a single
operator's control. Different services the operator support are
sharing network resources via virtual network slicing. Each service
has its own virtual network and manages based on this virtual
network sliced for it. The VNC Coordination function facilitates the
allocation of resources between the physical and the virtual.
Ceccarelli, et al. Expires April20,2015 [Page 11]
Internet-DraftAbstraction and Control of Transport Networks October 2014
Figure 4 depict a common scenario in which two different domains can
be managed by a single VNC, which is in charge of acting as
coordinator between them and presenting them as a single entity to
its clients. For brevity's sake, the client is not depicted in the
figure.
+-------------------------+
| VNC |
| |
+-------------------------+
*
+------------+---------+--+ * +-----------+---------+--+
| +---------+ | * | +---------+ |
| | PNC ************************* PNC | |
| +---------+---------+ | * | +---------+---------+ |
| | | | * | | | |
| | | | * | | | |
| | | | * | | | |
| | Packet | | * | | Packet | |
| +-------------------+ | * | +-------------------+ |
| | * | |
| | * | |
| | * | |
| | * | |
| | * | |
| +---------+ | * | +---------+ |
| | PNC ************************* PNC | |
| +---------+---------+ | | +---------+---------+ |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | Optical | | | | Optical | |
| +-------------------+ | | +-------------------+ |
+---+-------------------+-+ +--+-------------------+-+
Domain 1 Domain 2
Figure 4: Multi-domain management for POI
Ceccarelli, et al. Expires April20,2015 [Page 12]
Internet-DraftAbstraction and Control of Transport Networks October 2014
In this figure the case of packet and optical domains controlled by
different PNCs is shown but any combination can be considered, like
e.g. a single PNC controlling the packet+optical domain 1 and
different PNCs for domains 2.
5. Computation Model of ACTN
This section discusses ACTN framework from a computational point of
view. As multiple customers run their virtualized network on a
shared infrastructure (with either dedicated or shared resources),
making efficient use of the underlying resources requires effective
computational models and algorithms. This general problem space is
known as Virtual Network Mapping or Embedding (VNM or VNE) [VNM-OP].
As VNM/VNE issues impose some additional compute models and
algorithms for virtual network path computation, this section
discusses key issues and constraints for virtual network path
computation. Sections 5.1-5.3 discuss real-time processing aspect of
computation model while the rest discuss policy-related or non real-
time aspect of computation model.
5.1. Request Processing
This is concerned about whether a set of customer requests for VN
creation can be dealt with in real-time or off line, and in the
latter case, simultaneously or not. This depends on the nature of
applications the customer support. There are applications and use
cases, like e.g. management of catastrophic events or real time SLA
negotiation, that require a real-time VN creation. If the customer
does not require real-time instantiation of VN creation, the
computation engine can process a set of VN creation requests
simultaneously to improve network efficiency.
5.2. Computing Time
Depending on the nature of applications, how quickly a VN is
instantiated from the time of request is an important factor. For
dynamic applications that require instantaneous VN creation or VN
changes from the existing one, the computation model/algorithm
should support this constraint.
5.3. Path Constraints
There may be some factors of path constraints that can affect the
overall efficiency. Path Split can lower VN request blocking if the
underlying network can support such capability. A packet-based TE
Ceccarelli, et al. Expires April20,2015 [Page 13]
Internet-DraftAbstraction and Control of Transport Networks October 2014
network can support path split while circuit-based transport may
have limitations.
Path migration is a technique that allows changes of nodes or link
assignments of the established paths in an effort to accommodate new
requests that would not be accepted without such path migration(s).
This can improve overall efficiency, yet additional care needs to be
applied to avoid any adverse impacts associated with changing the
existing paths.
Re-optimization is a global process to re-shuffle all existing path
assignments to minimize network resource fragmentation. Again, an
extra care needs to be applied for re-optimization.
5.4. Types of Network Resources
When a customer makes a VN creation request to the substrate
network, what kind of network resources is consumed is of concern of
both the customer and service/network providers. The customer needs
to put constraints (e.g. TE parameters, resiliency) for the
provisioning of the VN, while the service and network providers need
to choose which resources meet such constraints and possibly have
fewest impact on the capability of serving other customers. For
transport network virtualization, the network resource consumed is
primarily network bandwidth that the required paths would occupy on
the physical link(s). However, there may be other resource types
such as CPU and memory that need to be considered for certain
applications. These resource types shall be part of the VN request
made by the customer.
5.5. Accuracy of Network Resource Representation
As the underlying transport network in itself may consist of a
layered structure, it is a challenge how to represent these
underlying physical network resources and topology into a form that
can be reliably used by the computation engine that assigns customer
requests into the physical network resource and topology.
5.6. Resource Sharing and Efficiency
Related to the accuracy of network resource representation is
resource efficiency. As a set of independent customer VN is created
and mapped onto physical network resources, the overall network
resource utilization is the primary concern of the network provider.
In order to provide an efficient utilization of the resources of the
provider network, it should be possible to share given physical
Ceccarelli, et al. Expires April20,2015 [Page 14]
Internet-DraftAbstraction and Control of Transport Networks October 2014
resources among a number of different VNs. Whether a virtual
resource is sharable among a set of VNs (and hence of customers) is
something the service provider needs to agree with each customer.
Preemption and priority management are tools that could help provide
an efficient sharing of physical resources among different VNs.
5.7. Guarantee of Client Isolation
While network resource sharing across a set of customers for
efficient utilization is an important aspect of network
virtualization, customer isolation has to be guaranteed. Admissions
of new customer requests or any changes of other existing customer
VNs must not affect any particular customer in terms of resource
guarantee, security constraints, and other performance constraints.
Admission Control
To coordinate the request process of multiple customers, an
admission control will help maximize an overall efficiency.
6. Architecture Model for ACTN
This section provides a high-level control and interface model of
ACTN.
6.1. ACTN Interfaces
To allow virtualization, the network has to provide open,
programmable interfaces, in which customer applications can create,
replace and modify virtual network resources in an interactive,
flexible and dynamic fashion while having no impact on other
customers. Direct customer control of transport network elements
over existing interfaces (control or management plane) is not
perceived as a viable proposition for transport network providers
due to security and policy concerns among other reasons. In
addition, as discussed in the previous section, the network control
plane for transport networks has been separated from data plane and
as such it is not viable for the customer to directly interface with
transport network elements.
While the current network control plane is well suited for control
of physical network resources via dynamic provisioning, path
computation, etc., a virtual network controller needs to be built on
top of physical network controller to support network
virtualization. On a high-level, virtual network control refers to a
mediation layer that performs several functions:
Ceccarelli, et al. Expires April20,2015 [Page 15]
Internet-DraftAbstraction and Control of Transport Networks October 2014
- Computation of customer resource requests into virtual network
paths based on the global network-wide abstracted topology;
- Mapping and translation of customer virtual network slices into
physical network resources;
- Creation of an abstracted view of network slices allocated to each
customer, according to customer-specific objective functions, and
to the customer traffic profile.
In order to facilitate the above-mentioned virtual control
functions, the virtual network controller (aka., "virtualizer")
needs to maintain two interfaces:
- One interface with the physical network controller functions which
is termed as the Virtual Network Controller (VNC)-Physical Network
Controller (PNC) Interface (VPI).
- Another interface with the Customer Network Controller for the
virtual network, which is termed as Customer Network Controller
(CNC) - Virtual Network Controller (VNC) Interface (CVI).
Figure 5 depicts a high-level control and interface architecture for
ACTN. A number of key ACTN interfaces exist for deployment and
operation of ACTN-based networks. These are highlighted in Figure 5
(ACTN Interfaces) below:
.--------------
------------- |
| Application |--
-------------
Figure 1 ^
Ceccarelli, et al. Expires April20,2015 [Page 16]
Internet-DraftAbstraction and Control of Transport Networks October 2014
| I/F A --------
v ( )
-------------- - -
| Customer | ( Customer )
| Network |--------->( Network )
| Controller | ( )
-------------- - -
^ ( )
| I/F B --------
v ^ ^
-------------- : :
| Virtual | : .
| Network | : .
| Controller | -------- . I/F E
-------------- ( ) .
^ - - .
| I/F C ( Physical ) .
v ( Network ) .
--------------- ( ) --------
| |<----> - - ( )
-------------- | ( ) - -
| Physical |-- -------- ( Physical )
| Network |<---------------------->( Network )
| Controller | I/F D ( )
-------------- - -
( )
--------
Figure 5. ACTN Interfaces
The interfaces and functions are described below:
. Interface A: A north-bound interface (NBI) that will
communicate the service request or application demand. A
request will include specific service properties, including:
service topology, bandwidth and constraint information.
. Interface B: The CNC-VNC Interface (CVI) is an interface
between a Customer Network Controller and a Virtual Network
Controller. It requests the creation of the network resources
and topology for the service or application. The Virtual
Network Controller may also report potential network topology
availability if queried for current capability from the
Customer Network Controller.
Ceccarelli, et al. Expires April20,2015 [Page 17]
Internet-DraftAbstraction and Control of Transport Networks October 2014
. Interface C: The VNC-PNC Interface (VPI) is an interface
between a Virtual Network Controller and a Physical Network
Controller. It communicates the creation request, if required,
of new connectivity of bandwidth changes in the physical
network, via the Physical Network Controller. In multi-domain
environments, the VNC needs to establish multiple VPIs, one for
each PNC, as there are multiple PNCs responsible for its domain
control.
. Interface D: The provisioning interface for creating forwarding
state in the physical network, requested via the Physical
Network Controller.
. Interface E: A mapping of physical resources to overlay
resources.
6.1.1. ACTN Interface Scope
The north-bound interface (NBI) interfaces, direct control
interfaces to NEs (Interface D) and Interface E are outside of the
scope of ACTN.
The interfaces within scope of ACTN are:
- Interface B: The CNC-VNC Interface (CVI)
The CVI interface should allow programmability, first of all, to the
customer so they can create, modify and delete virtual network
service instances. This interface should also support open standard
information and data models that can transport abstracted topology.
- Interface C: The VNC-PNC Interface (VPI)
The VPI interface should allow programmability to service
provider(s) (through VNCs) in such ways that control functions such
as path computation, provisioning, and restoration can be
facilitated. Seamless mapping and translation between physical
resources and virtual resources should also be facilitated via this
interface.
6.2. Key ACTN Entities
6.2.1. Customer Network Controller
A Virtual Network Service is instantiated by the Customer Network
Controller via the CVI. As the Customer Network Controller directly
interfaces the application stratum, it understands multiple
Ceccarelli, et al. Expires April20,2015 [Page 18]
Internet-DraftAbstraction and Control of Transport Networks October 2014
application requirements and their service needs. It is assumed that
the Customer Network Controller and the VNC have a common knowledge
on the end-point interfaces based on their business negotiation
prior to service instantiation. End-point interfaces refer to
customer-network physical interfaces that connect customer premise
equipment to network provider equipment. Figure 6 shows an example
physical network topology that supports multiple customers. In this
example, customer A has three end-points A.1, A.2 and A.3. The
interfaces between customers and transport networks are assumed to
be 40G OTU links. For simplicity's sake, all network interfaces are
assumed to be 40G OTU links and all network ports support ODU
switching and grooming on the level of ODU1 and ODU2. Customer
Network Controller for A provides its traffic demand matrix that
describes bandwidth requirements and other optional QoS parameters
(e.g., latency, diversity requirement, etc.) for each pair of end-
point connections.
6.2.2. Virtual Network Controller
The virtual network controller sits between the customer network
controller (the one issuing connectivity requests) and the physical
network controller (the one managing the resources). The Virtual
Network controller can be collocated with the physical network
controller, especially in those cases where the service provider and
the network provider are the same entity.
The architecture and building blocks of the VNC are out of the scope
of ACTN. Some examples can be found in the Application Based Network
Operations (ABNO) architecture [ABNO] and the ONF SDN architecture
[SDN-ARCH].
The following blocks do not identify the VNC architecture but only
the functionalities required by the ACNT framework. Such
functionalities could be implemented by functional blocks already
defined in the existing SDN controller architectures:
+------------------------------------------------------------------+
| |
| Virtual +-------------+ +------------------------+ |
| Network | VNS Proxy | | Abstract Topology DB | |
| Controller +-------------+ +------------------------+ |
| |
| +-------------------+ +-------------------+ +---------------+ |
| | Resource Manager | | vConnection Agent | |VNC OAM handler| |
| +-------------------+ +-------------------+ +---------------+ |
+------------------------------------------------------------------+
Ceccarelli, et al. Expires April20,2015 [Page 19]
Internet-DraftAbstraction and Control of Transport Networks October 2014
. VNS proxy: The VNS proxy is the functional module in charge of
performing policy management and AAA (Authentication,
authorization, and accounting) functions. It is the one that
receives that VN instantiation and resource allocation requests
from the Customer Network Controllers.
. Abstract Topology DB: This is the database where the abstract
topology, generated by the VNC or received from the PNC, is
stored. A different VN instance is kept for every different
customer.
. Resource Manager: The resource manager is in charge of
receiving VNS instantiation requests from the Customer Network
Controller and, as a consequence, triggering a concurrent path
computation request to the PCE in the PNC based on the traffic
matrix. The Resource manager is also in charge of generating
the abstract topology for the customer. It may request abstract
network topology to PNC.
. vConnection Agent: This module is in charge of mapping VN setup
commands into network provisioning requests to the PNC.
. VNC OAM handler: The VNC OAM handler is the module that is in
charge of understanding how the network is operating, detecting
faults and reacting to problems related to the abstract
topology.
6.2.3. Physical Network Controller
The physical network controller is the one in charge of configuring
the network elements, monitoring the physical topology of the
network and passing it, either raw or abstracted, to the VNC.
The architecture and building blocks of the PNC are out of the scope
of ACTN. Some examples can be found in the Application Based Network
Operations (ABNO) architecture [ABNO] and the ONF SDN architecture
[SDN-ARCH].
The following blocks do not identify the PNC architecture but only
the functionalities required by the ACNT framework. Such
functionalities could be implemented by functional blocks already
defined in the existing SDN controller architectures:
Ceccarelli, et al. Expires April20,2015 [Page 20]
Internet-DraftAbstraction and Control of Transport Networks October 2014
+------------------------------------------------------------------+
| |
| Physical +-----------+ +-----+ +------------------------+ |
| Network | VNC Proxy | | PCE | | Abstract Topology Gen. | |
| Controller +-----------+ +-----+ +------------------------+ |
| |
| +---------------+ +--------------------+ +--------------------+ |
| |PNC OAM Handler| |Provisioning Manager| |Physical Topology DB| |
| +---------------+ +--------------------+ +--------------------+ |
+------------------------------------------------------------------+
. VNC proxy: The VNC proxy is the functional module in charge of
performing policy management and AAA (Authentication,
authorization, and accounting) functions on requests coming
from the VNC.
. PCE: This is the stateful PCE performing the path computation
over the physical topology and that provides the vConnection
agent with the network topology/network paths (LSPs).
. Abstract topology generator: the network topology can be passed
to the VNC as raw or abstract. In case the topology is passed
as abstract topology, this module is in charge of generating it
from the physical topology DB. The module is optional.
. PNC OAM handler: it verifies that connections exists,
implements monitoring functions to see if failures occurs. It
is the proxy to an OSS/NMS system but does not duplicate any of
OSS/NMS functionalities.
. Physical topology database: The physical topology database is
mainly composed by two databases: the Traffic Engineering
Database (TED) and the LSP Database (LSP-DB).
. Provisioning Manager: The Provisioning Manager is responsible
for initiating direct requests, or relaying requests, for the
establishment of connections. These direct requests might
include instructions to the control plane running in the
underlay networks, or may involve the programming of individual
network devices to establish forwarding state in the network.
This functional component and role is described in more detail
in the Application-Based Network Operations (ABNO) architecture
[ABNO], other controllers include the OpenFlow Controller
[ONF].
6.3. Abstracted Topology Illustration
There are two levels of abstracted topology that needs to be
maintained and supported for ACTN. Customer-specific Abstracted
Topology refers to the abstracted view of network resources
Ceccarelli, et al. Expires April20,2015 [Page 21]
Internet-DraftAbstraction and Control of Transport Networks October 2014
allocated (shared or dedicated) to the customer. The granularity of
this abstraction varies depending on the nature of customer
applications. Figure 6 illustrates this.
Figure 6 shows how three independent customers A, B and C provide
its respective traffic demand matrix to the VNC. The physical
network topology shown in Figure 6 is the provider's network
topology generated by the PNC topology creation engine such as the
link state database (LSDB) and Traffic Engineering DB (TEDB) based
on control plane discovery function. This topology is internal to
PNC and not available to customers. What is available to them is an
abstracted network topology (a virtual network topology) based on
the negotiated level of abstraction. This is a part of VNS
instantiation between a client control and VNC.
Ceccarelli, et al. Expires April20,2015 [Page 22]
Internet-DraftAbstraction and Control of Transport Networks October 2014
+------+ +------+ +------+
A.1 ------o o-----------o o----------o o------- A.2
B.1 ------o 1 | | 2 | | 3 |
C.1 ------o o-----------o o----------o o------- B.2
+-o--o-+ +-o--o-+ +-o--o-+
| | | | | |
| | | | | |
| | | | | |
| | +-o--o-+ +-o--o-+
| `-------------o o----------o o------- B.3
| | 4 | | 5 |
`----------------o o----------o o------- C.3
+-o--o-+ +------+
| |
| |
C.2 A.3
Traffic Matrix Traffic Matrix Traffic Matrix
for Customer A for Customer B for Customer C
A.1 A.2 A.3 B.1 B.2 B.3 C.1 C.2 C.3
------------------- ------------------ -----------------
A.1 - 20G 20G B.1 - 40G 40G C.1 - 20G 20G
A.2 20G - 10G B.2 40G - 20G C.2 20G - 10G
A.3 20G 10G - B.3 40G 20G - C.3 20G 10G -
Figure 6: Physical network topology shared with multiple customers
Figure 7 depicts illustrative examples of different level of
topology abstractions that can be provided by the VNC topology
abstraction engine based on the physical topology base maintained by
the PNC. The level of topology abstraction is expressed in terms of
the number of virtual nodes (VNs) and virtual links (VLs). For
example, the abstracted topology for customer A shows there are 5
VNEs and 10 VLs. This is by far the most detailed topology
abstraction with a minimal link hiding compared to other abstracted
topologies in Figure 7.
Ceccarelli, et al. Expires April20,2015 [Page 23]
Internet-DraftAbstraction and Control of Transport Networks October 2014
(a) Abstracted Topology for Customer A (5 VNEs and 10 VLs)
+------+ +------+ +------+
A.1 ------o o-----------o o----------o o------- A.2
| 1 | | 2 | | 3 |
| | | | | |
+-o----+ +-o----+ +-o----+
| | |
| | |
| | |
| +-o----+ +-o--o-+
| | | | |
| | 4 | | 5 |
`----------------o o----------o |
+----o-+ +------+
|
|
A.3
(b) Abstracted Topology for Customer B (3 VNEs and 6 VLs)
+------+ +------+
B.1 ------o o-----------------------------o o------ B.2
| 1 | | 3 |
| | | |
+-o----+ +-o----+
\ |
\ |
\ |
`------------------- |
` +-o----+
\ | o------ B.3
\ | 5 |
`-------o |
+------+
(c) Abstracted Topology for Customer C (1 VNE and 3 VLs)
Ceccarelli, et al. Expires April20,2015 [Page 24]
Internet-DraftAbstraction and Control of Transport Networks October 2014
+-------------------------------------------+
| |
| |
C.1 ------o |
| |
| |
| |
| o--------C.3
| |
+--------------------o----------------------+
|
|
|
|
C.2
Figure 7: Topology Abstraction Examples for Customers
As different customers have different control/application needs,
abstracted topologies for customers B and C, respectively show a
much higher degree of abstraction. The level of abstraction is
determined by the policy (e.g., the granularity level) placed for
the customer and/or the path computation results by the PCE operated
by the PNC. The more granular the abstraction topology is, the more
control is given to the Customer Network Controller. If the Customer
Network Controller has applications that require more granular
control of virtual network resources, then the abstracted topology
shown for customer A may be the right abstraction level for such
controller. For instance, if the customer is a third-party virtual
service broker/provider, then it would desire much more
sophisticated control of virtual network resources to support
different application needs. On the other hand, if the customer were
only to support simple tunnel services to its applications, then the
abstracted topology shown for customer C (one VNE and three VLs)
would suffice.
6.4. ACTN Interface Interaction
The following list provides examples on the type of interaction and
communication exchange between key ACTN interfaces:
Ceccarelli, et al. Expires April20,2015 [Page 25]
Internet-DraftAbstraction and Control of Transport Networks October 2014
- Interface B: Customer Network Controller to Virtual Network
Controller.
1. Security/Policy Negotiation (Who are you?)
a. External Entity vs. Internal Service Department
b. Push/Pull support
2. VN Query (Can you give me VN?)
a. VN end-points (CE end points)
b. VN service requirement
- Latency only
- B/W guarantee
- Latency and B/W guarantee together
c. VN diversity
- Node/Link disjoint from other VNs
- VN level diversity (e.g., VN1 and VN2 must be disjoint)
d. VN type
- Path vector (tunnel)
- Node/Links (graph)
3. VN Query Response (Available VNs)
a. For VN,
- This is what can be reserved for you
- This is what is available beyond what is given to you
(potential)
4. VN Instantiation Request (I need VN for my service, please
instantiate my VN) - with or without VN Query
a. VN end-points
b. VN service requirement
- Latency only
- B/W guarantee
- Latency and B/W guarantee together
c. VN diversity
- Node/Link disjoint from other VNs
- VN level diversity (e.g., VN1 and VN2 must be disjoint)
d. VN type
- Path vector (tunnel)
- Node/Links (graph)
e. VN instance ID per service (unique ID to identify VNs)
f. VN level policy
- On-demand VN creation (time/day)
5. VN Instantiation Confirmation (VN instantiated to my physical
networks)
a. VN instance ID
Ceccarelli, et al. Expires April20,2015 [Page 26]
Internet-DraftAbstraction and Control of Transport Networks October 2014
b. Abstraction topology (with data model)
c. If failed to instantiate the requested VN, say why
6. VN lifecycle management/operation
a. Create (same as VN instantiate Request)
b. Delete
c. Modify
d. Update (VN level Performance Monitoring) under policy
agreement
- Interface C: Virtual Network Controller to Physical Network
Controller.
1. Security/Policy negotiation (who are you?)
a. Exchange of key, etc.
b. Domain preference + local policy exchange
- Push/Pull support
- Preferred peering points
- Preferred route
2. Topology Query /Response (Pull Model: Please give me your
domain topology)
a. TED Abstraction level negotiation
- Physical topology (per policy)
- Abstract topology (per policy)
b. Node/Link metrics
- Node/Link Type (Border/Gateway, etc.)
- All TE metrics (SRLG, etc.)
3. Topology Update (Push Model from PNC to VNC)
a. Under policy agreement, topology changes to be pushed to
VNC from PNC
4. VN Path Computation Request (Please give me a path)
a. VN Instance ID (Note: this is passed from CC to VNC)
b. End-point information
- CE ends
- Border points (if applicable)
c. All other PCE request info (PCEP)
5. VN Path Computation Reply (here's the path info per your
request)
a. Path level abstraction - LSP DB like
6. VN Path Setup Request / Reply (please setup my paths)
a. Per domain path request
- Single request
Ceccarelli, et al. Expires April20,2015 [Page 27]
Internet-DraftAbstraction and Control of Transport Networks October 2014
- Multiple requests - diversity path request, etc.
b. Domain sequence kept at VNC
c. Coordination of signaling (multi-domain)
7. VN Path Modification/Rerouting/re-grooming (please change these
paths)
a. VN Instance ID
8. VN Performance Monitoring
a. VN Instance ID
b. VN Connection Failure and other degradation report
c. Pull/Push Models
7. Design Principles of ACTN
7.1. Network Security
Network security concerns are always one of the primary principles
of any network design. ACTN is no exception. Due to the nature of
heterogeneous VNs that are to be created, maintained and deleted
flexibly and dynamically and the anticipated interaction with
physical network control components, secure programming models and
interfaces have to be available beyond secured tunnels, encryption
and other network security tools.
7.2. Privacy and Isolation
As physical network resources are shared with and controlled by
multiple independent customers, isolation and privacy for each
customer has to be guaranteed.
Policy should be applied per client.
7.3. Scalability
As multiple VNs need to be supported seamlessly, there are
potentially several scaling issues associated with ACTN. The VN
Controller system should be scalable in supporting multiple parallel
computation requests from multiple customers. New VN request should
not affect the control and maintenance of the existing VNs. Any VN
request should also be satisfied within a time-bound of the customer
application request.
Interfaces should also be scalable as a large amount of data needs
to be transported across customers to virtual network controllers
and across virtual network controllers and physical network
controllers.
Ceccarelli, et al. Expires April20,2015 [Page 28]
Internet-DraftAbstraction and Control of Transport Networks October 2014
7.4. Manageability and Orchestration
As there are multiple entities participating in network
virtualization, seamless manageability has to be provided across
every layer of network virtualization. Orchestration is an important
aspect of manageability as the ACTN design should allow
orchestration capability.
ACTN orchestration should encompass network provider multi-domains,
relationships between service provider(s) and network provider(s),
and relationships between customers and service/network providers.
Ease of deploying end-to-end virtual network services across
heterogeneous network environments is a challenge.
7.5. Programmability
As discussed earlier in Section 5.5, the ACTN interfaces should
support open standard interfaces to allow flexible and dynamic
virtual service creation environments.
7.6. Network Stability
As multiple VNs are envisioned to share the same physical network
resources, combining many resources into one should not cause any
network instability. Provider network oscillation can affect readily
both on virtual networks and the end-users.
Part of network instability can be caused when virtual network
mapping is done on an inaccurate or unreliable resource data. Data
base synchronization is one of the key issues that need to be
ensured in ACTN design.
8. References
8.1. Informative References
[PCE] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", IETF RFC
4655, August 2006.
[PCE-S] Crabbe, E, et. al., "PCEP extension for stateful
PCE",draft-ietf-pce-stateful-pce, work in progress.
Ceccarelli, et al. Expires April20,2015 [Page 29]
Internet-DraftAbstraction and Control of Transport Networks October 2014
[GMPLS] Manning, E., et al., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3945, October 2004.
[NFV-AF] "Network Functions Virtualization (NFV); Architectural
Framework", ETSI GS NFV 002 v1.1.1, October 2013.
[ACTN-PS] Y. Lee, D. King, M. Boucadair, R. Jing, L. Contreras
Murillo, "Problem Statement for Abstraction and Control of
Transport Networks", draft-leeking-actn-problem-statement,
work in progress.
[ONF] Open Networking Foundation, "OpenFlow Switch Specification
Version 1.4.0 (Wire Protocol 0x05)", October 2013.
[ABNO] King, D., and Farrel, A., "A PCE-based Architecture for
Application-based Network Operations", draft-farrkingel-
pce-abno-architecture, work in progress.
[VNM-OP] Melo, M, et al. "Virtual Network Mapping - An Optimization
Problem", Springer Berlin Heidelberg, January 2012.
[SDN-ARCH] Open Networking Foundation, "SDN Architecture", Issue 1,
June 2014.
Appendix A
Contributors' Addresses
Dhruv Dhoddy
Huawei Technologies
dhruv.ietf@gmail.com
Dave Hood
Ericsson
dave.hood@ericsson.com
Ceccarelli, et al. Expires April20,2015 [Page 30]
Internet-DraftAbstraction and Control of Transport Networks October 2014
Authors' Addresses
Daniele Ceccarelli
Ericsson
Torshamnsgatan,48
Stockholm, Sweden
Email: daniele.ceccarelli@ericsson.com
Luyuan Fang
Email: luyuanf@gmail.com
Young Lee
Huawei Technologies
5340 Legacy Drive
Plano, TX 75023, USA
Phone: (469)277-5838
Email: leeyoung@huawei.com
Diego Lopez
Telefonica I+D
Don Ramon de la Cruz, 82
28006 Madrid, Spain
Email: diego@tid.es
Sergio Belotti
Alcatel Lucent
Via Trento, 30
Vimercate, Italy
Email: sergio.belotti@alcatel-lucent.com
Daniel King
Lancaster University
Email: d.king@lancaster.ac.uk
Ceccarelli, et al. Expires April20,2015 [Page 31]