draft-ietf-teas-actn-framework-11.txt   draft-ietf-teas-actn-framework-12.txt 
TEAS Working Group Daniele Ceccarelli (Ed) TEAS Working Group Daniele Ceccarelli (Ed)
Internet Draft Ericsson Internet Draft Ericsson
Intended status: Informational Young Lee (Ed) Intended status: Informational Young Lee (Ed)
Expires: April 27, 2018 Huawei Expires: October 3, 2018 Huawei
October 27, 2017 April 3, 2018
Framework for Abstraction and Control of Traffic Engineered Networks Framework for Abstraction and Control of Traffic Engineered Networks
draft-ietf-teas-actn-framework-11 draft-ietf-teas-actn-framework-12
Abstract Abstract
Traffic Engineered networks have a variety of mechanisms to Traffic Engineered networks have a variety of mechanisms to
facilitate the separation of the data plane and control plane. They facilitate the separation of the data plane and control plane. They
also have a range of management and provisioning protocols to also have a range of management and provisioning protocols to
configure and activate network resources. These mechanisms configure and activate network resources. These mechanisms represent
represent key technologies for enabling flexible and dynamic key technologies for enabling flexible and dynamic networking. The
networking. term "Traffic Engineered network" refers to a network that uses any
connection-oriented technology under the control of a distributed or
centralized control plane to support dynamic provisioning of end-to-
end connectivity.
Abstraction of network resources is a technique that can be applied Abstraction of network resources is a technique that can be applied
to a single network domain or across multiple domains to create a to a single network domain or across multiple domains to create a
single virtualized network that is under the control of a network single virtualized network that is under the control of a network
operator or the customer of the operator that actually owns operator or the customer of the operator that actually owns
the network resources. the network resources.
This document provides a framework for Abstraction and Control of This document provides a framework for Abstraction and Control of
Traffic Engineered Networks (ACTN). Traffic Engineered Networks (ACTN) to support virtual network
services and connectivity services.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 45 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 27, 2018. This Internet-Draft will expire on October 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
2. Overview.......................................................4 2. Overview.......................................................4
2.1. Terminology...............................................5 2.1. Terminology...............................................5
2.2. VNS Model of ACTN.........................................8 2.2. VNS Model of ACTN.........................................7
2.2.1. Customers............................................9 2.2.1. Customers............................................9
2.2.2. Service Providers...................................10 2.2.2. Service Providers...................................10
2.2.3. Network Providers...................................10 2.2.3. Network Providers...................................10
3. ACTN Base Architecture........................................10 3. ACTN Base Architecture........................................10
3.1. Customer Network Controller..............................12 3.1. Customer Network Controller..............................12
3.2. Multi-Domain Service Coordinator.........................13 3.2. Multi-Domain Service Coordinator.........................13
3.3. Provisioning Network Controller..........................13 3.3. Provisioning Network Controller..........................13
3.4. ACTN Interfaces..........................................14 3.4. ACTN Interfaces..........................................14
4. Advanced ACTN Architectures...................................15 4. Advanced ACTN Architectures...................................15
4.1. MDSC Hierarchy...........................................15 4.1. MDSC Hierarchy...........................................15
skipping to change at page 3, line 7 skipping to change at page 3, line 9
5.2. Abstraction Types........................................18 5.2. Abstraction Types........................................18
5.2.1. Native/White Topology...............................18 5.2.1. Native/White Topology...............................18
5.2.2. Black Topology......................................18 5.2.2. Black Topology......................................18
5.2.3. Grey Topology.......................................19 5.2.3. Grey Topology.......................................19
5.3. Methods of Building Grey Topologies......................20 5.3. Methods of Building Grey Topologies......................20
5.3.1. Automatic Generation of Abstract Topology by 5.3.1. Automatic Generation of Abstract Topology by
Configuration..............................................21 Configuration..............................................21
5.3.2. On-demand Generation of Supplementary Topology via Path 5.3.2. On-demand Generation of Supplementary Topology via Path
Compute Request/Reply......................................21 Compute Request/Reply......................................21
5.4. Hierarchical Topology Abstraction Example................22 5.4. Hierarchical Topology Abstraction Example................22
5.5. VN Recursion with Network Layers.........................23 5.5. VN Recursion with Network Layers.........................24
6. Access Points and Virtual Network Access Points...............25 6. Access Points and Virtual Network Access Points...............25
6.1. Dual-Homing Scenario.....................................27 6.1. Dual-Homing Scenario.....................................27
7. Advanced ACTN Application: Multi-Destination Service..........28 7. Advanced ACTN Application: Multi-Destination Service..........28
7.1. Pre-Planned End Point Migration..........................29 7.1. Pre-Planned End Point Migration..........................29
7.2. On the Fly End-Point Migration...........................30 7.2. On the Fly End-Point Migration...........................30
8. Manageability Considerations..................................30 8. Manageability Considerations..................................30
8.1. Policy...................................................30 8.1. Policy...................................................31
8.2. Policy Applied to the Customer Network Controller........31 8.2. Policy Applied to the Customer Network Controller........31
8.3. Policy Applied to the Multi Domain Service Coordinator...31 8.3. Policy Applied to the Multi Domain Service Coordinator...32
8.4. Policy Applied to the Provisioning Network Controller....32 8.4. Policy Applied to the Provisioning Network Controller....32
9. Security Considerations.......................................32 9. Security Considerations.......................................33
9.1. CNC-MDSC Interface (CMI).................................33 9.1. CNC-MDSC Interface (CMI).................................33
9.2. MDSC-PNC Interface (MPI).................................34 9.2. MDSC-PNC Interface (MPI).................................34
10. IANA Considerations..........................................34 10. IANA Considerations..........................................34
11. References...................................................34 11. References...................................................34
11.1. Informative References..................................34 11.1. Informative References..................................34
12. Contributors.................................................35 12. Contributors.................................................35
Authors' Addresses...............................................36 Authors' Addresses...............................................37
APPENDIX A - Example of MDSC and PNC Functions Integrated in A APPENDIX A - Example of MDSC and PNC Functions Integrated in A
Service/Network Orchestrator.....................................37 Service/Network Orchestrator.....................................37
1. Introduction 1. Introduction
The term "Traffic Engineered network" refers to a network that uses The term "Traffic Engineered network" refers to a network that uses
any connection-oriented technology under the control of a any connection-oriented technology under the control of a
distributed or centralized control plane to support dynamic distributed or centralized control plane to support dynamic
provisioning of end-to-end connectivity. Traffic Engineered (TE) provisioning of end-to-end connectivity. Traffic Engineered (TE)
networks have a variety of mechanisms to facilitate separation of networks have a variety of mechanisms to facilitate separation of
skipping to change at page 5, line 10 skipping to change at page 5, line 10
server network, a network operator needs to partition (or "slice") server network, a network operator needs to partition (or "slice")
or manage sharing of the network resources. Network slices can be or manage sharing of the network resources. Network slices can be
assigned to each customer for guaranteed usage which is a step assigned to each customer for guaranteed usage which is a step
further than shared use of common network resources. further than shared use of common network resources.
Furthermore, each network represented to a customer can be built Furthermore, each network represented to a customer can be built
from virtualization of the underlying networks so that, for example, from virtualization of the underlying networks so that, for example,
a link in the customer's network is constructed from a path or a link in the customer's network is constructed from a path or
collection of paths in the underlying network. collection of paths in the underlying network.
We call the set of management and control functions used to provide
these features Abstraction and Control of Traffic Engineered
Networks (ACTN).
ACTN can facilitate virtual network operation via the creation of a ACTN can facilitate virtual network operation via the creation of a
single virtualized network or a seamless service. This supports single virtualized network or a seamless service. This supports
operators in viewing and controlling different domains (at any operators in viewing and controlling different domains (at any
dimension: applied technology, administrative zones, or vendor- dimension: applied technology, administrative zones, or vendor-
specific technology islands) and presenting virtualized networks to specific technology islands) and presenting virtualized networks to
their customers. their customers.
The ACTN framework described in this document facilitates: The ACTN framework described in this document facilitates:
. Abstraction of the underlying network resources to higher-layer . Abstraction of the underlying network resources to higher-layer
applications and customers [RFC7926]. applications and customers [RFC7926].
. Virtualization of particular underlying resources, whose . Virtualization of particular underlying resources, whose
selection criterion is the allocation of those resources to a selection criterion is the allocation of those resources to a
particular customer, application or service [ONF-ARCH]. particular customer, application or service [ONF-ARCH].
. Network slicing of infrastructure to meet specific customers' . Network slicing of infrastructure to meet specific customers'
service requirements. service requirements.
. Creation of a virtualized environment allowing operators to . Creation of an abstract environment allowing operators to view
view and control multi-domain networks as a single virtualized and control multi-domain networks as a single abstract network.
network.
. The presentation to customers of networks as a virtual network . The presentation to customers of networks as a virtual network
via open and programmable interfaces. via open and programmable interfaces.
2.1. Terminology 2.1. Terminology
The following terms are used in this document. Some of them are The following terms are used in this document. Some of them are
newly defined, some others reference existing definitions: newly defined, some others reference existing definitions:
. Domain: A domain [RFC4655] is any collection of network . Domain: A domain [RFC4655] is any collection of network
elements within a common sphere of address management or path elements within a common sphere of address management or path
computation responsibility. Specifically within this document computation responsibility. Specifically within this document
we mean a part of an operator's network that is under common we mean a part of an operator's network that is under common
management. Network elements will often be grouped into management. Network elements will often be grouped into
domains based on technology types, vendor profiles, and domains based on technology types, vendor profiles, and
geographic proximity. geographic proximity.
. Abstraction: This process is defined in [RFC7926]. . Abstraction: This process is defined in [RFC7926].
. Network Slicing: In the context of ACTN, a network slice is a . TE Network Slicing: In the context of ACTN, a TE network slice
collection of resources that is used to establish a logically is a collection of resources that is used to establish a
dedicated virtual network over one or more TE network. Network logically dedicated virtual network over one or more TE
slicing allows a network provider to provide dedicated virtual network. TE Network slicing allows a network provider to
networks for applications/customers over a common network provide dedicated virtual networks for applications/customers
infrastructure. The logically dedicated resources are a part over a common network infrastructure. The logically dedicated
of the larger common network infrastructures that are shared resources are a part of the larger common network
among various network slice instances which are the end-to-end infrastructures that are shared among various TE network slice
realization of network slicing, consisting of the combination instances which are the end-to-end realization of TE network
of physically or logically dedicated resources. slicing, consisting of the combination of physically or
logically dedicated resources.
. Node: A node is a vertex on the graph representation of a TE . Node: A node is a vertex on the graph representation of a TE
topology. In a physical network topology, a node corresponds topology. In a physical network topology, a node corresponds
to a physical network element (NE) such as a router. In an to a physical network element (NE) such as a router. In an
abstract network topology, a node (sometimes called an abstract abstract network topology, a node (sometimes called an abstract
node) is a representation as a single vertex of one or more node) is a representation as a single vertex of one or more
physical NEs and their connecting physical connections. The physical NEs and their connecting physical connections. The
concept of a node represents the ability to connect from any concept of a node represents the ability to connect from any
access to the node (a link end) to any other access to that access to the node (a link end) to any other access to that
node, although "limited cross-connect capabilities" may also be node, although "limited cross-connect capabilities" may also be
defined to restrict this functionality. Just as network defined to restrict this functionality. Network abstraction
slicing and network abstraction may be applied recursively, so may be applied recursively, so a node in one topology may be created by applying abstraction to the nodes in the underlying topology.
a node in one topology may be created by applying slicing or
abstraction to the nodes in the underlying topology.
. Link: A link is an edge on the graph representation of a TE . Link: A link is an edge on the graph representation of a TE
topology. Two nodes connected by a link are said to be topology. Two nodes connected by a link are said to be
"adjacent" in the TE topology. In a physical network topology, "adjacent" in the TE topology. In a physical network topology,
a link corresponds to a physical connection. In an abstract a link corresponds to a physical connection. In an abstract
network topology, a link (sometimes called an abstract link) is network topology, a link (sometimes called an abstract link) is
a representation of the potential to connect a pair of points a representation of the potential to connect a pair of points
with certain TE parameters (see [RFC7926] for details). with certain TE parameters (see [RFC7926] for details).
Network slicing/virtualization and network abstraction may be Network abstraction may be applied recursively, so a link in
applied recursively, so a link in one topology may be created one topology may be created by applying abstraction to the
by applying slicing and/or abstraction to the links in the links in the underlying topology.
underlying topology.
. Abstract Link: The term "abstract link" is defined in . Abstract Link: The term "abstract link" is defined in
[RFC7926]. [RFC7926].
. Abstract Topology: The topology of abstract nodes and abstract . Abstract Topology: The topology of abstract nodes and abstract
links presented through the process of abstraction by a lower links presented through the process of abstraction by a lower
layer network for use by a higher layer network. layer network for use by a higher layer network.
. A Virtual Network (VN) is a network provided by a service . A Virtual Network (VN) is a network provided by a service
provider to a customer for the customer to use in any way it provider to a customer for the customer to use in any way it
wants as though it was a physical network. There are two views wants as though it was a physical network. There are two views
of a VN as follows: of a VN as follows:
a) The VN can be seen as a set of edge-to-edge links (a Type 1 a) The VN can be abstracted as a set of edge-to-edge links (a
VN). Each link is referred as a VN member and is formed as Type 1 VN). Each link is referred as a VN member and is
an end-to-end tunnel across the underlying networks. Such formed as an end-to-end tunnel across the underlying
tunnels may be constructed by recursive slicing or networks. Such tunnels may be constructed by recursive
abstraction of paths in the underlying networks and can slicing or abstraction of paths in the underlying networks
encompass edge points of the customer's network, access and can encompass edge points of the customer's network,
links, intra-domain paths, and inter-domain links. access links, intra-domain paths, and inter-domain links.
b) The VN can also be seen as a topology of virtual nodes and b) The VN can also be abstracted as a topology of virtual nodes
virtual links (a Type 2 VN). The provider needs to map the and virtual links (a Type 2 VN). The provider needs to map
VN to actual resource assignment, which is known as virtual the VN to actual resource assignment, which is known as
network embedding. The nodes in this case include physical virtual network embedding. The nodes in this case include
end points, border nodes, and internal nodes as well as physical end points, border nodes, and internal nodes as well
abstracted nodes. Similarly the links include physical as abstracted nodes. Similarly the links include physical
access links, inter-domain links, and intra-domain links as access links, inter-domain links, and intra-domain links as
well as abstract links. well as abstract links.
Clearly a Type 1 VN is a special case of a Type 2 VN. Clearly a Type 1 VN is a special case of a Type 2 VN.
. Access link: A link between a customer node and a provider . Access link: A link between a customer node and a provider
node. node.
. Inter-domain link: A link between domains under distinct . Inter-domain link: A link between domains under distinct
management administration. management administration.
skipping to change at page 8, line 8 skipping to change at page 7, line 47
. VN Access Point (VNAP): A VNAP is the binding between an AP and . VN Access Point (VNAP): A VNAP is the binding between an AP and
a given VN. a given VN.
. Server Network: As defined in [RFC7926], a server network is a . Server Network: As defined in [RFC7926], a server network is a
network that provides connectivity for another network (the network that provides connectivity for another network (the
Client Network) in a client-server relationship. Client Network) in a client-server relationship.
2.2. VNS Model of ACTN 2.2. VNS Model of ACTN
A Virtual Network Service (VNS) is the service agreement between a A Virtual Network Service (VNS) is the service agreement between a
customer and provider to provide a VN. There are three types of VNS customer and provider to provide a VN. When a VN is a simple
defined in this document. connectivity between two points, the difference between VNS and
connectivity service becomes blurred.
There are three types of VNS defined in this document.
o Type 1 VNS refers to a VNS in which the customer is allowed o Type 1 VNS refers to a VNS in which the customer is allowed
to create and operate a Type 1 VN. to create and operate a Type 1 VN.
o Type 2a and 2b VNS refer to VNSs in which the customer is o Type 2a and 2b VNS refer to VNSs in which the customer is
allowed to create and operates a Type 2 VN. With a Type allowed to create and operates a Type 2 VN. With a Type
2a VNS, the VN is statically created at service 2a VNS, the VN is statically created at service
configuration time and the customer is not allowed to configuration time and the customer is not allowed to
change the topology (e.g., by adding or deleting abstract change the topology (e.g., by adding or deleting abstract
nodes and links). A Type 2b VNS is the same as a Type 2a nodes and links). A Type 2b VNS is the same as a Type 2a
skipping to change at page 8, line 52 skipping to change at page 8, line 46
- Service Providers - Service Providers
- Network Providers - Network Providers
These entities are related in a three tier model as shown in Figure These entities are related in a three tier model as shown in Figure
1. 1.
+----------------------+ +----------------------+
| Customer | | Customer |
+----------------------+ +----------------------+
| |
|
VNS || | /\ VNS VNS || | /\ VNS
Request || | || Reply Request || | || Reply
\/ | || \/ | ||
+----------------------+ +----------------------+
| Service Provider | | Service Provider |
+----------------------+ +----------------------+
/ | \ / | \
/ | \ / | \
/ | \ / | \
/ | \ / | \
skipping to change at page 10, line 26 skipping to change at page 10, line 24
When network providers supply only infrastructure, while distinct When network providers supply only infrastructure, while distinct
service providers interface to the customers, the service providers service providers interface to the customers, the service providers
are themselves customers of the network infrastructure providers. are themselves customers of the network infrastructure providers.
One service provider may need to keep multiple independent network One service provider may need to keep multiple independent network
providers because its end-users span geographically across multiple providers because its end-users span geographically across multiple
network provider domains. network provider domains.
2.2.3. Network Providers 2.2.3. Network Providers
Network Providers are the infrastructure providers that own the Network Providers are the infrastructure providers that provision
physical network resources and provide network resources to their the network resources and provide network resources to their
customers. The network operated by a network provider may be a customers. The layered model described in this architecture
virtual network created by a service provider and supplied to the separates the concerns of network providers and customers, with
network provider in its role as a customer. The layered model service providers acting as aggregators of customer requests.
described in this architecture separates the concerns of network
providers and customers, with service providers acting as
aggregators of customer requests.
3. ACTN Base Architecture 3. ACTN Base Architecture
This section provides a high-level model of ACTN showing the This section provides a high-level model of ACTN showing the
interfaces and the flow of control between components. interfaces and the flow of control between components.
The ACTN architecture is based on a 3-tier reference model and The ACTN architecture is based on a 3-tier reference model and
allows for hierarchy and recursion. The main functionalities within allows for hierarchy and recursion. The main functionalities within
an ACTN system are: an ACTN system are:
. Multi-domain coordination: This function oversees the specific . Multi-domain coordination: This function oversees the specific
aspects of different domains and builds a single abstracted aspects of different domains and builds a single abstracted
end-to-end network topology in order to coordinate end-to-end end-to-end network topology in order to coordinate end-to-end
path computation and path/service provisioning. Domain path computation and path/service provisioning. Domain
sequence path calculation/determination is also a part of this sequence path calculation/determination is also a part of this
function. function.
. Virtualization/Abstraction: This function provides an . Abstraction: This function provides an abstracted view of the
abstracted view of the underlying network resources for use by underlying network resources for use by the customer - a
the customer - a customer may be the client or a higher level customer may be the client or a higher level controller entity.
controller entity. This function includes network path This function includes network path computation based on
computation based on customer service connectivity request customer service connectivity request constraints, path
constraints, path computation based on the global network-wide computation based on the global network-wide abstracted
abstracted topology, and the creation of an abstracted view of topology, and the creation of an abstracted view of network
network resources allocated to each customer. These operations resources allocated to each customer. These operations depend
depend on customer-specific network objective functions and on customer-specific network objective functions and customer
customer traffic profiles. traffic profiles.
. Customer mapping/translation: This function is to map customer . Customer mapping/translation: This function is to map customer
requests/commands into network provisioning requests that can requests/commands into network provisioning requests that can
be sent to the Provisioning Network Controller (PNC) according be sent to the Provisioning Network Controller (PNC) according
to business policies provisioned statically or dynamically at to business policies provisioned statically or dynamically at
the OSS/NMS. Specifically, it provides mapping and translation the OSS/NMS. Specifically, it provides mapping and translation
of a customer's service request into a set of parameters that of a customer's service request into a set of parameters that
are specific to a network type and technology such that network are specific to a network type and technology such that network
configuration process is made possible. configuration process is made possible.
skipping to change at page 12, line 23 skipping to change at page 12, line 23
+---------------+ +---------------+
| MDSC | | MDSC |
+---------------+ +---------------+
/ | \ / | \
------------ | MPI ------------- ------------ | MPI -------------
/ | \ / | \
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
| PNC | | PNC | | PNC | | PNC | | PNC | | PNC |
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
| SBI / | / \ | SBI / | / \
| / | SBI / \ | / | SBI SBI / \
--------- ----- | / \ --------- ----- | / \
( ) ( ) | / \ ( ) ( ) | / \
- Control - ( Phys. ) | / ----- - Control - ( Phys. ) | / -----
( Plane ) ( Net ) | / ( ) ( Plane ) ( Net ) | / ( )
( Physical ) ----- | / ( Phys. ) ( Physical ) ----- | / ( Phys. )
( Network ) ----- ----- ( Net ) ( Network ) ----- ----- ( Net )
- - ( ) ( ) ----- - - ( ) ( ) -----
( ) ( Phys. ) ( Phys. ) ( ) ( Phys. ) ( Phys. )
--------- ( Net ) ( Net ) --------- ( Net ) ( Net )
----- ----- ----- -----
skipping to change at page 12, line 50 skipping to change at page 13, line 4
3.1. Customer Network Controller 3.1. Customer Network Controller
A Customer Network Controller (CNC) is responsible for communicating A Customer Network Controller (CNC) is responsible for communicating
a customer's VNS requirements to the network provider over the CNC- a customer's VNS requirements to the network provider over the CNC-
MDSC Interface (CMI). It has knowledge of the end-points associated MDSC Interface (CMI). It has knowledge of the end-points associated
with the VNS (expressed as APs), the service policy, and other QoS with the VNS (expressed as APs), the service policy, and other QoS
information related to the service. information related to the service.
As the Customer Network Controller directly interfaces to the As the Customer Network Controller directly interfaces to the
applications, it understands multiple application requirements and applications, it understands multiple application requirements and
their service needs. their service needs. The capability of a CNC beyond its CMI role is
outside the scope of ACTN and may be implemented in different ways.
The capability of a CNC beyond its CMI role is outside the scope of For example, the CNC may in fact be a controller or part of a
ACTN and may be implemented in different ways. For example, the CNC controller in the customer's domain, or the CNC functionality could
may in fact be a controller or part of a controller in the customer's also be implemented as part of a provisioning portal.
domain, or the CNC functionality could also be implemented as part of
a provisioning portal.
3.2. Multi-Domain Service Coordinator 3.2. Multi-Domain Service Coordinator
A Multi-Domain Service Coordinator (MDSC) is a functional block that A Multi-Domain Service Coordinator (MDSC) is a functional block that
implements all of the ACTN functions listed in Section 3 and implements all of the ACTN functions listed in Section 3 and
described further in Section 4.2. The two functions of the MDSC, described further in Section 4.2. The two functions of the MDSC,
namely, multi domain coordination and virtualization/abstraction are namely, multi domain coordination and virtualization/abstraction are
referred to as network-related functions while the other two referred to as network-related functions while the other two
functions, namely, customer mapping/translation and virtual service functions, namely, customer mapping/translation and virtual service
coordination are referred to as service-related functions. The MDSC coordination are referred to as service-related functions. The MDSC
skipping to change at page 14, line 35 skipping to change at page 14, line 37
3.4. ACTN Interfaces 3.4. ACTN Interfaces
Direct customer control of transport network elements and Direct customer control of transport network elements and
virtualized services is not a viable proposition for network virtualized services is not a viable proposition for network
providers due to security and policy concerns. In addition, some providers due to security and policy concerns. In addition, some
networks may operate a control plane and as such it is not practical networks may operate a control plane and as such it is not practical
for the customer to directly interface with network elements. for the customer to directly interface with network elements.
Therefore, the network has to provide open, programmable interfaces, Therefore, the network has to provide open, programmable interfaces,
through which customer applications can create, replace and modify through which customer applications can create, replace and modify
virtual network resources and services in an interactive, flexible virtual network resources and services in an interactive, flexible
and dynamic fashion while having no impact on other customers. and dynamic fashion.
Three interfaces exist in the ACTN architecture as shown in Figure Three interfaces exist in the ACTN architecture as shown in Figure
2. 2.
. CMI: The CNC-MDSC Interface (CMI) is an interface between a CNC . CMI: The CNC-MDSC Interface (CMI) is an interface between a CNC
and an MDSC. The CMI is a business boundary between customer and an MDSC. The CMI is a business boundary between customer
and network provider. It is used to request a VNS for an and network provider. It is used to request a VNS for an
application. All service-related information is conveyed over application. All service-related information is conveyed over
this interface (such as the VNS type, topology, bandwidth, and this interface (such as the VNS type, topology, bandwidth, and
service constraints). Most of the information over this service constraints). Most of the information over this
interface is technology agnostic (the customer is unaware of interface is agnostic of the technology used by Network
the network technologies used to deliver the service), but Providers, but there are some cases (e.g., access link
there are some cases (e.g., access link configuration) where it configuration) where it is necessary to specify technology-
is necessary to specify technology-specific details. specific details.
. MPI: The MDSC-PNC Interface (MPI) is an interface between an . MPI: The MDSC-PNC Interface (MPI) is an interface between an
MDSC and a PNC. It communicates requests for new connectivity MDSC and a PNC. It communicates requests for new connectivity
or for bandwidth changes in the physical network. In multi- or for bandwidth changes in the physical network. In multi-
domain environments, the MDSC needs to communicate with domain environments, the MDSC needs to communicate with
multiple PNCs each responsible for control of a domain. The multiple PNCs each responsible for control of a domain. The
MPI presents an abstracted topology to the MDSC hiding MPI presents an abstracted topology to the MDSC hiding
technology specific aspects of the network and hiding topology technology specific aspects of the network and hiding topology
according to policy. according to policy.
skipping to change at page 17, line 38 skipping to change at page 17, line 41
topology to an MDSC-H. This function is different to the creation topology to an MDSC-H. This function is different to the creation
of a VN (and particularly a Type 2 VN) which is not abstraction but of a VN (and particularly a Type 2 VN) which is not abstraction but
construction of virtual resources. construction of virtual resources.
5.1. Abstraction Factors 5.1. Abstraction Factors
As discussed in [RFC7926], abstraction is tied with policy of the As discussed in [RFC7926], abstraction is tied with policy of the
networks. For instance, per an operational policy, the PNC would networks. For instance, per an operational policy, the PNC would
not provide any technology specific details (e.g., optical not provide any technology specific details (e.g., optical
parameters for WSON) in the abstract topology it provides to the parameters for WSON) in the abstract topology it provides to the
MDSC. MDSC. Similarly, policy of the networks may determine the
abstraction type as described in Section 5.2.
There are many factors that may impact the choice of abstraction: There are many factors that may impact the choice of abstraction:
- Abstraction depends on the nature of the underlying domain - Abstraction depends on the nature of the underlying domain
networks. For instance, packet networks may be abstracted with networks. For instance, packet networks may be abstracted with
fine granularity while abstraction of optical networks depends on fine granularity while abstraction of optical networks depends on
the switching units (such as wavelengths) and the end-to-end the switching units (such as wavelengths) and the end-to-end
continuity and cross-connect limitations within the network. continuity and cross-connect limitations within the network.
- Abstraction also depends on the capability of the PNCs. As - Abstraction also depends on the capability of the PNCs. As
skipping to change at page 19, line 41 skipping to change at page 19, line 45
| Node | | Node |
---+ +--- ---+ +---
+----------+ +----------+
Figure 6: Native Topology with Corresponding Black Topology Expressed Figure 6: Native Topology with Corresponding Black Topology Expressed
as an Abstract Node as an Abstract Node
5.2.3. Grey Topology 5.2.3. Grey Topology
A grey topology represents a compromise between black and white A grey topology represents a compromise between black and white
topologies from a granularity point of view. In this case the PNC topologies from a granularity point of view. In this case, the PNC
exposes an abstract topology that comprises nodes and links. The exposes an abstract topology containing all PNC domains border nodes
nodes and links may be physical of abstract while the abstract and an abstraction of the connectivity between those border nodes.
topology represents the potential of connectivity across the PNC This abstraction may contain either physical or abstract
domain. nodes/links.
Two modes of grey topology are identified: Two modes of grey topology are identified:
. In a type A grey topology type border nodes are connected by a . In a type A grey topology type border nodes are connected by a
full mesh of TE links (see Figure 7). full mesh of TE links (see Figure 7).
. In a type B grey topology border nodes are connected over a . In a type B grey topology border nodes are connected over a
more detailed network comprising internal abstract nodes and more detailed network comprising internal abstract nodes and
abstracted links. This mode of abstraction supplies the MDSC abstracted links. This mode of abstraction supplies the MDSC
with more information about the internals of the PNC domain and with more information about the internals of the PNC domain and
allows it to make more informed choices about how to route allows it to make more informed choices about how to route
connectivity over the underlying network. connectivity over the underlying network.
..................................... .....................................
: PNC Domain : : PNC Domain :
: +--+ +--+ +--+ +--+ : : +--+ +--+ +--+ +--+ :
skipping to change at page 23, line 6 skipping to change at page 23, line 10
Virtual Network Delivered to CNC Virtual Network Delivered to CNC
CE A o==============o CE B CE A o==============o CE B
Topology operated on by MDSC-H Topology operated on by MDSC-H
CE A o----o==o==o===o----o CE B CE A o----o==o==o===o----o CE B
Topology operated on by MDSC-L1 Topology operated on by MDSC-L2 Topology operated on by MDSC-L1 Topology operated on by MDSC-L2
_ _ _ _ _ _ _ _
( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )
( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )
CE A o--(o---o)==(o---o)==Dom.3 Dom.2==(o---o)==(o---o)--o CE B CE A o--(o---o)==(o---o)==Dom.3 Dom.2==(o---o)==(o---o)--o CE B
( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )
(_) (_) (_) (_) (_) (_) (_) (_)
Actual Topology Actual Topology
___ ___ ___ ___ ___ ___ ___ ___
( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )
( o ) ( o ) ( o--o) ( o ) ( o ) ( o ) ( o--o) ( o )
( / \ ) ( |\ ) ( | | ) ( / \ ) ( / \ ) ( |\ ) ( | | ) ( / \ )
CE A o---(o-o---o-o)==(o-o-o-o-o)==(o--o--o-o)==(o-o-o-o-o)---o CE B CE A o---(o-o---o-o)==(o-o-o-o-o)==(o--o--o-o)==(o-o-o-o-o)---o CE B
( \ / ) ( | |/ ) ( | | ) ( \ / ) ( \ / ) ( | |/ ) ( | | ) ( \ / )
( o ) (o-o ) ( o--o) ( o ) ( o ) (o-o ) ( o--o) ( o )
(___) (___) (___) (___) (___) (___) (___) (___)
skipping to change at page 25, line 13 skipping to change at page 25, line 17
| ------ | | ------ |
| : | | : |
| ------- | | ------- |
| | PNC | | | | PNC | |
| ------- | | ------- |
\ : : : / \ : : : /
Lower \v v v/ Lower \v v v/
Layer X--Y--Z Layer X--Y--Z
Network Network
Figure 10: VN Recursion with Network Layers Figure 10: VN recursion with Network Layers
6. Access Points and Virtual Network Access Points 6. Access Points and Virtual Network Access Points
In order to map identification of connections between the customer's In order to map identification of connections between the customer's
sites and the TE networks and to scope the connectivity requested in sites and the TE networks and to scope the connectivity requested in
the VNS, the CNC and the MDSC refer to the connections using the the VNS, the CNC and the MDSC refer to the connections using the
Access Point (AP) construct as shown in Figure 11. Access Point (AP) construct as shown in Figure 11.
------------- -------------
( ) ( )
skipping to change at page 25, line 35 skipping to change at page 25, line 39
+---+ X ( ) Z +---+ +---+ X ( ) Z +---+
|CE1|---+----( )---+---|CE2| |CE1|---+----( )---+---|CE2|
+---+ | ( ) | +---+ +---+ | ( ) | +---+
AP1 - - AP2 AP1 - - AP2
( ) ( )
------------- -------------
Figure 11: Customer View of APs Figure 11: Customer View of APs
Let's take as an example a scenario shown in Figure 11. CE1 is Let's take as an example a scenario shown in Figure 11. CE1 is
connected to the network via a 10Gb link and CE2 via a 40Gb link. connected to the network via a 10Gbps link and CE2 via a 40Gbps
Before the creation of any VN between AP1 and AP2 the customer view link. Before the creation of any VN between AP1 and AP2 the
can be summarized as shown in Table 1. customer view can be summarized as shown in Table 1.
+----------+------------------------+ +----------+------------------------+
|End Point | Access Link Bandwidth | |End Point | Access Link Bandwidth |
+-----+----------+----------+-------------+ +-----+----------+----------+-------------+
|AP id| CE,port | MaxResBw | AvailableBw | |AP id| CE,port | MaxResBw | AvailableBw |
+-----+----------+----------+-------------+ +-----+----------+----------+-------------+
| AP1 |CE1,portX | 10Gb | 10Gb | | AP1 |CE1,portX | 10Gbps | 10Gbps |
+-----+----------+----------+-------------+ +-----+----------+----------+-------------+
| AP2 |CE2,portZ | 40Gb | 40Gb | | AP2 |CE2,portZ | 40Gbps | 40Gbps |
+-----+----------+----------+-------------+ +-----+----------+----------+-------------+
Table 1: AP - Customer View Table 1: AP - Customer View
On the other hand, what the provider sees is shown in Figure 12. On the other hand, what the provider sees is shown in Figure 12.
------- ------- ------- -------
( ) ( ) ( ) ( )
- - - - - - - -
W (+---+ ) ( +---+) Y W (+---+ ) ( +---+) Y
skipping to change at page 26, line 26 skipping to change at page 26, line 38
Figure 12: Provider view of the AP Figure 12: Provider view of the AP
Which results in a summarization as shown in Table 2. Which results in a summarization as shown in Table 2.
+----------+------------------------+ +----------+------------------------+
|End Point | Access Link Bandwidth | |End Point | Access Link Bandwidth |
+-----+----------+----------+-------------+ +-----+----------+----------+-------------+
|AP id| PE,port | MaxResBw | AvailableBw | |AP id| PE,port | MaxResBw | AvailableBw |
+-----+----------+----------+-------------+ +-----+----------+----------+-------------+
| AP1 |PE1,portW | 10Gb | 10Gb | | AP1 |PE1,portW | 10Gbps | 10Gbps |
+-----+----------+----------+-------------+ +-----+----------+----------+-------------+
| AP2 |PE2,portY | 40Gb | 40Gb | | AP2 |PE2,portY | 40Gbps | 40Gbps |
+-----+----------+----------+-------------+ +-----+----------+----------+-------------+
Table 2: AP - Provider View Table 2: AP - Provider View
A Virtual Network Access Point (VNAP) needs to be defined as binding A Virtual Network Access Point (VNAP) needs to be defined as binding
between the AP that is linked to a VN and that is used to allow for between an AP and a VN. It is used to allow for different VNs to
different VNs to start from the same AP. It also allows for traffic start from the same AP. "It also allows for traffic engineering on
engineering on the access and/or inter-domain links (e.g., keeping the access and/or inter-domain links (e.g., keeping track of
track of bandwidth allocation). A different VNAP is created on an bandwidth allocation). A different VNAP is created on an AP for
AP for each VN. each VN.
In this simple scenario we suppose we want to create two virtual In this simple scenario we suppose we want to create two virtual
networks. The first with VN identifier 9 between AP1 and AP2 with networks. The first with VN identifier 9 between AP1 and AP2 with
bandwidth of 1Gbps, while the second with VN identifier 5, again bandwidth of 1Gbps, while the second with VN identifier 5, again
between AP1 and AP2 and with bandwidth 2Gbps. between AP1 and AP2 and with bandwidth 2Gbps.
The provider view would evolve as shown in Table 3. The provider view would evolve as shown in Table 3.
+----------+------------------------+ +----------+------------------------+
|End Point | Access Link/VNAP Bw | |End Point | Access Link/VNAP Bw |
skipping to change at page 28, line 28 skipping to change at page 28, line 32
+---------+----------+----------+-------------+-----------+ +---------+----------+----------+-------------+-----------+
Table 4: Dual-Homing - Customer View after VN Creation Table 4: Dual-Homing - Customer View after VN Creation
7. Advanced ACTN Application: Multi-Destination Service 7. Advanced ACTN Application: Multi-Destination Service
A further advanced application of ACTN is in the case of Data Center A further advanced application of ACTN is in the case of Data Center
selection, where the customer requires the Data Center selection to selection, where the customer requires the Data Center selection to
be based on the network status; this is referred to as Multi- be based on the network status; this is referred to as Multi-
Destination in [ACTN-REQ]. In terms of ACTN, a CNC could request a Destination in [ACTN-REQ]. In terms of ACTN, a CNC could request a
connectivity service (virtual network) between a set of source Aps VNS between a set of source APs and destination APs and leave it up
and destination APs and leave it up to the network (MDSC) to decide to the network (MDSC) to decide which source and destination access
which source and destination access points to be used to set up the points to be used to set up the VNS. The candidate list of
connectivity service (virtual network). The candidate list of
source and destination APs is decided by a CNC (or an entity outside source and destination APs is decided by a CNC (or an entity outside
of ACTN) based on certain factors which are outside the scope of of ACTN) based on certain factors which are outside the scope of
ACTN. ACTN.
Based on the AP selection as determined and returned by the network Based on the AP selection as determined and returned by the network
(MDSC), the CNC (or an entity outside of ACTN) should further take (MDSC), the CNC (or an entity outside of ACTN) should further take
care of any subsequent actions such as orchestration or service care of any subsequent actions such as orchestration or service
setup requirements. These further actions are outside the scope of setup requirements. These further actions are outside the scope of
ACTN. ACTN.
skipping to change at page 30, line 38 skipping to change at page 30, line 40
It will also need to provide performance monitoring and control of It will also need to provide performance monitoring and control of
traffic engineered resources. The management requirements may be traffic engineered resources. The management requirements may be
categorized as follows: categorized as follows:
. Management of external ACTN protocols . Management of external ACTN protocols
. Management of internal ACTN interfaces/protocols . Management of internal ACTN interfaces/protocols
. Management and monitoring of ACTN components . Management and monitoring of ACTN components
. Configuration of policy to be applied across the ACTN system . Configuration of policy to be applied across the ACTN system
The ACTN framework and interfaces are defined to enable traffic The ACTN framework and interfaces are defined to enable traffic
engineering for virtual networks. Network operators may have other engineering for virtual network services and connectivity services.
Operations, Administration, and Maintenance (OAM) tasks for service Network operators may have other Operations, Administration, and
fulfillment, optimization, and assurance beyond traffic engineering. Maintenance (OAM) tasks for service fulfillment, optimization, and
The realization of OAM beyond abstraction and control of traffic assurance beyond traffic engineering. The realization of OAM beyond
engineered networks is not considered in this document. abstraction and control of traffic engineered networks is not
considered in this document.
8.1. Policy 8.1. Policy
Policy is an important aspect of ACTN control and management. Policy is an important aspect of ACTN control and management.
Policies are used via the components and interfaces, during Policies are used via the components and interfaces, during
deployment of the service, to ensure that the service is compliant deployment of the service, to ensure that the service is compliant
with agreed policy factors and variations (often described in SLAs), with agreed policy factors and variations (often described in SLAs),
these include, but are not limited to: connectivity, bandwidth, these include, but are not limited to: connectivity, bandwidth,
geographical transit, technology selection, security, resilience, geographical transit, technology selection, security, resilience,
and economic cost. and economic cost.
skipping to change at page 34, line 34 skipping to change at page 34, line 39
10. IANA Considerations 10. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
11. References 11. References
11.1. Informative References 11.1. Informative References
[RFC2702] Awduche, D., et. al., "Requirements for Traffic [RFC2702] Awduche, D., et. al., "Requirements for Traffic
Engineering Over MPLS", RFC 2702, September 1999. Engineering Over MPLS", RFC 2702, October 1999.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", IETF RFC Computation Element (PCE)-Based Architecture", IETF RFC
4655, August 2006. 4655, August 2006.
[RFC5654] Niven-Jenkins, B. (Ed.), D. Brungard (Ed.), and M. Betts [RFC5654] Niven-Jenkins, B. (Ed.), D. Brungard (Ed.), and M. Betts
(Ed.), "Requirements of an MPLS Transport Profile", RFC (Ed.), "Requirements of an MPLS Transport Profile", RFC
5654, September 2009. 5654, October 2009.
[RFC7149] Boucadair, M. and Jacquenet, C., "Software-Defined [RFC7149] Boucadair, M. and Jacquenet, C., "Software-Defined
Networking: A Perspective from within a Service Provider Networking: A Perspective from within a Service Provider
Environment", RFC 7149, March 2014. Environment", RFC 7149, April 2014.
[RFC7926] A. Farrel (Ed.), "Problem Statement and Architecture for [RFC7926] A. Farrel (Ed.), "Problem Statement and Architecture for
Information Exchange between Interconnected Traffic- Information Exchange between Interconnected Traffic-
Engineered Networks", RFC 7926, July 2016. Engineered Networks", RFC 7926, July 2016.
[RFC3945] Manning, E., et al., "Generalized Multi-Protocol Label [RFC3945] Manning, E., et al., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture2, RFC 3945, October 2004. Switching (GMPLS) Architecture2, RFC 3945, October 2004.
[ONF-ARCH] Open Networking Foundation, "SDN architecture", Issue [ONF-ARCH] Open Networking Foundation, "SDN architecture", Issue
1.1, ONF TR-521, June 2016. 1.1, ONF TR-521, June 2016.
 End of changes. 46 change blocks. 
127 lines changed or deleted 121 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/