draft-ietf-teas-actn-framework-08.txt   draft-ietf-teas-actn-framework-09.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 3, 2018 Huawei Expires: April 16, 2018 Huawei
October 4, 2017 October 16, 2017
Framework for Abstraction and Control of Traffic Engineered Networks Framework for Abstraction and Control of Traffic Engineered Networks
draft-ietf-teas-actn-framework-08 draft-ietf-teas-actn-framework-09
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 key technologies for enabling flexible and dynamic represent key technologies for enabling flexible and dynamic
networking. networking.
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 3, 2018. This Internet-Draft will expire on April 16, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
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.........................................7 2.2. VNS Model of ACTN.........................................8
2.2.1. Customers............................................9 2.2.1. Customers............................................9
2.2.2. Service Providers....................................9 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. Physical 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
4.2. Functional Split of MDSC Functions in Orchestrators......16 4.2. Functional Split of MDSC Functions in Orchestrators......16
5. Topology Abstraction Methods..................................17 5. Topology Abstraction Methods..................................17
5.1. Abstraction Factors......................................17 5.1. Abstraction Factors......................................17
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
skipping to change at page 3, line 16 skipping to change at page 3, line 16
5.4. Hierarchical Topology Abstraction Example................22 5.4. Hierarchical Topology Abstraction Example................22
6. Access Points and Virtual Network Access Points...............23 6. Access Points and Virtual Network Access Points...............23
6.1. Dual-Homing Scenario.....................................25 6.1. Dual-Homing Scenario.....................................25
7. Advanced ACTN Application: Multi-Destination Service..........26 7. Advanced ACTN Application: Multi-Destination Service..........26
7.1. Pre-Planned End Point Migration..........................27 7.1. Pre-Planned End Point Migration..........................27
7.2. On the Fly End-Point Migration...........................28 7.2. On the Fly End-Point Migration...........................28
8. Manageability Considerations..................................28 8. Manageability Considerations..................................28
8.1. Policy...................................................29 8.1. Policy...................................................29
8.2. Policy Applied to the Customer Network Controller........30 8.2. Policy Applied to the Customer Network Controller........30
8.3. Policy Applied to the Multi Domain Service Coordinator...30 8.3. Policy Applied to the Multi Domain Service Coordinator...30
8.4. Policy Applied to the Physical Network Controller........30 8.4. Policy Applied to the Provisioning Network Controller....31
9. Security Considerations.......................................31 9. Security Considerations.......................................31
9.1. CNC-MDSC Interface (CMI).................................32 9.1. CNC-MDSC Interface (CMI).................................32
9.2. MDSC-PNC Interface (MPI).................................32 9.2. MDSC-PNC Interface (MPI).................................32
10. References...................................................32 10. IANA Considerations..........................................32
10.1. Informative References..................................32 11. References...................................................33
11. Contributors.................................................33 11.1. Informative References..................................33
12. Contributors.................................................34
Authors' Addresses...............................................35 Authors' Addresses...............................................35
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.....................................35 Service/Network Orchestrator.....................................35
APPENDIX B - Example of IP + Optical network with L3VPN service..36
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
data plane and control plane including distributed signaling for data plane and control plane including distributed signaling for
path setup and protection, centralized path computation for planning path setup and protection, centralized path computation for planning
skipping to change at page 7, line 34 skipping to change at page 7, line 34
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.
. Access Point (AP): An AP is a logical identifier shared between . Access Point (AP): An AP is a logical identifier shared between
the customer and the provider used to identify an access link. the customer and the provider used to identify an access link.
The AP is used by the customer when requesting a VNS. The AP is used by the customer when requesting a VNS. Note that
the term "TE Link Termination Point" (LTP) defined in [TE-Topo]
describes the end points of links, while an AP is a common
identifier for the link itself.
. 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
network that provides connectivity for another network (the
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. There are three types of VNS
defined in this document. 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
skipping to change at page 8, line 43 skipping to change at page 8, line 52
- 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 || | /\ VN |
Request || | || Reply
\/ | || VNS || | /\ VNS
Request || | || Reply
\/ | ||
+----------------------+ +----------------------+
| Service Provider | | Service Provider |
+----------------------+ +----------------------+
/ | \ / | \
/ | \ / | \
/ | \ / | \
/ | \
/ | \ +------------------+ +------------------+ +------------------+
+------------------+ +------------------+ +------------------+ |Network Provider 1| |Network Provider 2| |Network Provider 3|
|Network Provider 1| |Network Provider 2| |Network Provider 3| +------------------+ +------------------+ +------------------+
+------------------+ +------------------+ +------------------+
Figure 1: The Three Tier Model. Figure 1: The Three Tier Model.
The commercial roles of these entities are described in the The commercial roles of these entities are described in the
following sections. following sections.
2.2.1. Customers 2.2.1. Customers
Basic customers include fixed residential users, mobile users, and Basic customers include fixed residential users, mobile users, and
small enterprises. Each requires a small amount of resources and is small enterprises. Each requires a small amount of resources and is
skipping to change at page 10, line 19 skipping to change at page 10, line 28
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 own the
physical network resources and provide network resources to their physical network resources and provide network resources to their
customers. The layered model described in this architecture customers. The network operated by a network provider may be a
separates the concerns of network providers and customers, with virtual network created by a service provider and supplied to the
service providers acting as aggregators of customer requests. network provider in its role as a customer. The layered model
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:
skipping to change at page 11, line 7 skipping to change at page 11, line 18
controller entity. This function includes network path controller entity. This function includes network path
computation based on customer service connectivity request computation based on customer service connectivity request
constraints, path computation based on the global network-wide constraints, path computation based on the global network-wide
abstracted topology, and the creation of an abstracted view of abstracted topology, and the creation of an abstracted view of
network resources allocated to each customer. These operations network resources allocated to each customer. These operations
depend on customer-specific network objective functions and depend on customer-specific network objective functions and
customer traffic profiles. customer 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 Physical Network Controller (PNC) according to be sent to the Provisioning Network Controller (PNC) according
business policies provisioned statically or dynamically at the to business policies provisioned statically or dynamically at
OSS/NMS. Specifically, it provides mapping and translation of the OSS/NMS. Specifically, it provides mapping and translation
a customer's service request into a set of parameters that are of a customer's service request into a set of parameters that
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.
. Virtual service coordination: This function translates customer . Virtual service coordination: This function translates customer
service-related information into virtual network service service-related information into virtual network service
operations in order to seamlessly operate virtual networks operations in order to seamlessly operate virtual networks
while meeting a customer's service requirements. In the while meeting a customer's service requirements. In the
context of ACTN, service/virtual service coordination includes context of ACTN, service/virtual service coordination includes
a number of service orchestration functions such as multi- a number of service orchestration functions such as multi-
destination load balancing, guarantees of service quality, destination load balancing, guarantees of service quality,
bandwidth and throughput. It also includes notifications for bandwidth and throughput. It also includes notifications for
service fault and performance degradation and so forth. service fault and performance degradation and so forth.
The base ACTN architecture defines three controller types and the The base ACTN architecture defines three controller types and the
corresponding interfaces between these controllers. The following corresponding interfaces between these controllers. The following
types of controller are shown in Figure 2: types of controller are shown in Figure 2:
. CNC - Customer Network Controller . CNC - Customer Network Controller
. MDSC - Multi Domain Service Coordinator . MDSC - Multi Domain Service Coordinator
. PNC - Physical Network Controller . PNC - Provisioning Network Controller
Figure 2 also shows the following interfaces: Figure 2 also shows the following interfaces:
. CMI - CNC-MDSC Interface . CMI - CNC-MDSC Interface
. MPI - MDSC-PNC Interface . MPI - MDSC-PNC Interface
. SBI - South Bound Interface . SBI - South Bound Interface
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+
| CNC | | CNC | | CNC | | CNC | | CNC | | CNC |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+
\ | / \ | /
Business \ | / Business \ | /
Boundary =============\==================|=====================/======= Boundary =============\==============|==============/============
Between \ | / Between \ | /
Customer & ----------- | CMI -------------- Customer & ------- | CMI -------
Network Provider \ | / Network Provider \ | /
+---------------+ +---------------+
| MDSC | | MDSC |
+---------------+ +---------------+
/ | \ / | \
------------ | MPI --------------- ------------ | MPI -------------
/ | \ / | \
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
| PNC | | PNC | | PNC | | PNC | | PNC | | PNC |
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
| 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 )
----- ----- ----- -----
Figure 2: ACTN Base Architecture Figure 2: ACTN Base Architecture
Note that this is a functional architecture: an implementation and Note that this is a functional architecture: an implementation and
deployment might collocate one or more of the functional components. deployment might collocate one or more of the functional components.
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-
skipping to change at page 13, line 13 skipping to change at page 13, line 13
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.
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 MDSC sits at the center of described further in Section 4.2. The two functions of the MDSC,
the ACTN model between the CNC that issues connectivity requests and namely, multi domain coordination and virtualization/abstraction are
the Physical Network Controllers (PNCs) that manage the physical referred to as network-related functions while the other two
network resources. functions, namely, customer mapping/translation and virtual service
coordination are referred to as service-related functions. The MDSC
sits at the center of the ACTN model between the CNC that issues
connectivity requests and the Provisioning Network Controllers
(PNCs) that manage the network resources.
The key point of the MDSC (and of the whole ACTN framework) is The key point of the MDSC (and of the whole ACTN framework) is
detaching the network and service control from underlying technology detaching the network and service control from underlying technology
to help the customer express the network as desired by business to help the customer express the network as desired by business
needs. The MDSC envelopes the instantiation of the right technology needs. The MDSC envelopes the instantiation of the right technology
and network control to meet business criteria. In essence it and network control to meet business criteria. In essence it
controls and manages the primitives to achieve functionalities as controls and manages the primitives to achieve functionalities as
desired by the CNC. desired by the CNC.
In order to allow for multi-domain coordination a 1:N relationship In order to allow for multi-domain coordination a 1:N relationship
must be allowed between MDSCs and PNCs. must be allowed between MDSCs and PNCs.
In addition to that, it could also be possible to have an M:1 In addition to that, it could also be possible to have an M:1
relationship between MDSCs and PNC to allow for network resource relationship between MDSCs and PNC to allow for network resource
partitioning/sharing among different customers not necessarily partitioning/sharing among different customers not necessarily
connected to the same MDSC (e.g., different service providers) but connected to the same MDSC (e.g., different service providers) but
all using the resources of a common network infrastructure provider. all using the resources of a common network infrastructure provider.
3.3. Physical Network Controller 3.3. Provisioning Network Controller
The Physical Network Controller (PNC) oversees configuring the The Provisioning Network Controller (PNC) oversees configuring the
network elements, monitoring the topology (physical or virtual) of network elements, monitoring the topology (physical or virtual) of
the network, and collecting information about the topology (either the network, and collecting information about the topology (either
raw or abstracted). raw or abstracted).
The PNC functions can be implemented as part of an SDN domain The PNC functions can be implemented as part of an SDN domain
controller, a Network Management System (NMS), an Element Management controller, a Network Management System (NMS), an Element Management
System (EMS), an active PCE-based controller [Centralized] or any System (EMS), an active PCE-based controller [Centralized] or any
other means to dynamically control a set of nodes and that is other means to dynamically control a set of nodes and that is
implementing an NBI compliant with ACTN specification. implementing an NBI compliant with ACTN specification.
skipping to change at page 15, line 33 skipping to change at page 15, line 37
are scalability, administrative choices, or putting together are scalability, administrative choices, or putting together
different layers and technologies in the network. In the case where different layers and technologies in the network. In the case where
there is a hierarchy of MDSCs, we introduce the terms higher-level there is a hierarchy of MDSCs, we introduce the terms higher-level
MDSC (MDSC-H) and lower-level MDSC (MDSC-L). The interface between MDSC (MDSC-H) and lower-level MDSC (MDSC-L). The interface between
them is a recursion of the MPI. An implementation of an MDSC-H them is a recursion of the MPI. An implementation of an MDSC-H
makes provisioning requests as normal using the MPI, but an MDSC-L makes provisioning requests as normal using the MPI, but an MDSC-L
must be able to receive requests as normal at the CMI and also at must be able to receive requests as normal at the CMI and also at
the MPI. The hierarchy of MDSCs can be seen in Figure 4. the MPI. The hierarchy of MDSCs can be seen in Figure 4.
Another implementation choice could foresee the usage of an MDSC-L Another implementation choice could foresee the usage of an MDSC-L
for all the PNCs related to a given network layer or technology for all the PNCs related to a given technology (e.g. IP/MPLS) and a
(e.g. IP/MPLS) a different MDSC-L for the PNCs related to another different MDSC-L for the PNCs related to another technology (e.g.
layer/technology (e.g. OTN/WDM) and an MDSC-H to coordinate them. OTN/WDM) and an MDSC-H to coordinate them.
+--------+ +--------+
| CNC | | CNC |
+--------+ +--------+
| +-----+ | +-----+
| CMI | CNC | | CMI | CNC |
+----------+ +-----+ +----------+ +-----+
-------| MDSC-H |---- | -------| MDSC-H |---- |
| +----------+ | | CMI | +----------+ | | CMI
MPI | MPI | | MPI | MPI | |
skipping to change at page 16, line 23 skipping to change at page 16, line 26
An implementation choice could separate the MDSC functions into two An implementation choice could separate the MDSC functions into two
groups, one group for service-related functions and the other for groups, one group for service-related functions and the other for
network-related functions. This enables the implementation of a network-related functions. This enables the implementation of a
service orchestrator that provides the service-related functions of service orchestrator that provides the service-related functions of
the MDSC and a network orchestrator that provides the network- the MDSC and a network orchestrator that provides the network-
related functions of the MDSC. This split is consistent with the related functions of the MDSC. This split is consistent with the
YANG service model architecture described in [Service-YANG]. Figure YANG service model architecture described in [Service-YANG]. Figure
5 depicts this and shows how the ACTN interfaces may map to YANG 5 depicts this and shows how the ACTN interfaces may map to YANG
models. models.
+--------------------+ +--------------------+
| Customer | | Customer |
| +-----+ | | +-----+ |
| | CNC | | | | CNC | |
| +-----+ | | +-----+ |
+--------------------+ +--------------------+
CMI | Customer Service Model CMI | Customer Service Model
| |
+---------------------------------------+ +---------------------------------------+
| Service | | Service |
********|*********************** Orchestrator | ********|*********************** Orchestrator |
* MDSC | +-----------------+ * | * MDSC | +-----------------+ * |
* | | Service-related | * | * | | Service-related | * |
* | | Functions | * | * | | Functions | * |
* | +-----------------+ * | * | +-----------------+ * |
* +----------------------*----------------+ * +----------------------*----------------+
* * | Service Delivery Model * * | Service Delivery Model
* * | * * |
* +----------------------*----------------+ * +----------------------*----------------+
* | * Network | * | * Network |
* | +-----------------+ * Orchestrator | * | +-----------------+ * Orchestrator |
* | | Network-related | * | * | | Network-related | * |
* | | Functions | * | * | | Functions | * |
* | +-----------------+ * | * | +-----------------+ * |
********|*********************** | ********|*********************** |
+---------------------------------------+ +---------------------------------------+
MPI | Network Configuration Model MPI | Network Configuration Model
| |
+------------------------+ +------------------------+
| Domain | | Domain |
| +------+ Controller | | +------+ Controller |
| | PNC | | | | PNC | |
| +------+ | | +------+ |
+------------------------+ +------------------------+
SBI | Device Configuration Model SBI | Device Configuration Model
| |
+--------+ +--------+
| Device | | Device |
+--------+ +--------+
Figure 5: ACTN Architecture in the Context of the YANG Service Figure 5: ACTN Architecture in the Context of the YANG Service
Models Models
5. Topology Abstraction Methods 5. Topology Abstraction Methods
Topology abstraction is described in [RFC7926]. This section Topology abstraction is described in [RFC7926]. This section
discusses topology abstraction factors, types, and their context in discusses topology abstraction factors, types, and their context in
the ACTN architecture. the ACTN architecture.
Abstraction in ACTN is performed by the PNC when presenting Abstraction in ACTN is performed by the PNC when presenting
skipping to change at page 23, line 6 skipping to change at page 23, line 6
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 24, line 13 skipping to change at page 24, line 13
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 10. Access Point (AP) construct as shown in Figure 10.
------------- -------------
( ) ( )
- - - -
+---+ X ( ) Z +---+ +---+ X ( ) Z +---+
|CE1|---+----( )---+---|CE2| |CE1|---+----( )---+---|CE2|
+---+ | ( ) | +---+ +---+ | ( ) | +---+
AP1 - - AP2 AP1 - - AP2
( ) ( )
------------- -------------
Figure 10: Customer View of APs Figure 10: Customer View of APs
Let's take as an example a scenario shown in Figure 10. CE1 is Let's take as an example a scenario shown in Figure 10. CE1 is
connected to the network via a 10Gb link and CE2 via a 40Gb link. connected to the network via a 10Gb link and CE2 via a 40Gb link.
Before the creation of any VN between AP1 and AP2 the customer view Before the creation of any VN between AP1 and AP2 the customer view
can be summarized as shown in Table 1. can be summarized as shown in Table 1.
skipping to change at page 24, line 38 skipping to change at page 24, line 38
+-----+----------+----------+-------------+ +-----+----------+----------+-------------+
| AP1 |CE1,portX | 10Gb | 10Gb | | AP1 |CE1,portX | 10Gb | 10Gb |
+-----+----------+----------+-------------+ +-----+----------+----------+-------------+
| AP2 |CE2,portZ | 40Gb | 40Gb | | AP2 |CE2,portZ | 40Gb | 40Gb |
+-----+----------+----------+-------------+ +-----+----------+----------+-------------+
Table 1: AP - Customer View Table 1: AP - Customer View
On the other hand, what the provider sees is shown in Figure 11. On the other hand, what the provider sees is shown in Figure 11.
------- ------- ------- -------
( ) ( ) ( ) ( )
- - - - - - - -
W (+---+ ) ( +---+) Y W (+---+ ) ( +---+) Y
-+---( |PE1| Dom.X )----( Dom.Y |PE2| )---+- -+---( |PE1| Dom.X )---( Dom.Y |PE2| )---+-
| (+---+ ) ( +---+) | | (+---+ ) ( +---+) |
AP1 - - - - AP2 AP1 - - - - AP2
( ) ( ) ( ) ( )
------- ------- ------- -------
Figure 11: Provider view of the AP Figure 11: 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 |
+-----+----------+----------+-------------+ +-----+----------+----------+-------------+
skipping to change at page 27, line 34 skipping to change at page 27, line 34
would select the best destination AP based on the constraints, would select the best destination AP based on the constraints,
optimization criteria, policies, etc., and setup the connectivity optimization criteria, policies, etc., and setup the connectivity
service (virtual network). service (virtual network).
------- ------- ------- -------
( ) ( ) ( ) ( )
- - - - - - - -
+---+ ( ) ( ) +----+ +---+ ( ) ( ) +----+
|CE1|---+---( Domain X )----( Domain Y )---+---|DC-A| |CE1|---+---( Domain X )----( Domain Y )---+---|DC-A|
+---+ | ( ) ( ) | +----+ +---+ | ( ) ( ) | +----+
AP1 - - - - AP2 AP1 - - - - AP2
( ) ( ) ( ) ( )
---+--- ---+--- ---+--- ---+---
| | | |
AP3-+ AP4-+ AP3-+ AP4-+
| | | |
+----+ +----+ +----+ +----+
|DC-B| |DC-C| |DC-B| |DC-C|
+----+ +----+ +----+ +----+
Figure 13: End-Point Selection Based on Network Status Figure 13: End-Point Selection Based on Network Status
skipping to change at page 28, line 11 skipping to change at page 28, line 11
Furthermore, in case of Data Center selection, customer could Furthermore, in case of Data Center selection, customer could
request for a backup DC to be selected, such that in case of request for a backup DC to be selected, such that in case of
failure, another DC site could provide hot stand-by protection. As failure, another DC site could provide hot stand-by protection. As
shown in Figure 14 DC-C is selected as a backup for DC-A. Thus, the shown in Figure 14 DC-C is selected as a backup for DC-A. Thus, the
VN should be setup by the MDSC to include primary connectivity VN should be setup by the MDSC to include primary connectivity
between AP1 (CE1) and AP2 (DC-A) as well as protection connectivity between AP1 (CE1) and AP2 (DC-A) as well as protection connectivity
between AP1 (CE1) and AP4 (DC-C). between AP1 (CE1) and AP4 (DC-C).
------- ------- ------- -------
( ) ( ) ( ) ( )
- - __ - - - - - -
+---+ ( ) ( ) +----+ +---+ ( ) ( ) +----+
|CE1|---+----( Domain X )----( Domain Y )---+---|DC-A| |CE1|---+----( Domain X )----( Domain Y )---+---|DC-A|
+---+ | ( ) ( ) | +----+ +---+ | ( ) ( ) | +----+
AP1 - - - - AP2 | AP1 - - - - AP2 |
( ) ( ) | ( ) ( ) |
---+--- ---+--- | ---+--- ---+--- |
| | | | | |
AP3-+ AP4-+ HOT STANDBY AP3-+ AP4-+ HOT STANDBY
| | | | | |
+----+ +----+ | +----+ +----+ |
skipping to change at page 29, line 12 skipping to change at page 29, line 12
response, and reservations of client and network layer connectivity. response, and reservations of client and network layer connectivity.
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
engineering for virtual networks. Network operators may have other
Operations, Administration, and Maintenance (OAM) tasks for service
fulfillment, optimization, and assurance beyond traffic engineering.
The realization of OAM beyond 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 30, line 43 skipping to change at page 31, line 5
service reachability a request may require an interconnection point service reachability a request may require an interconnection point
between multiple physical networks; however, this might break a between multiple physical networks; however, this might break a
confidentially policy requirement of specific type of end-to-end confidentially policy requirement of specific type of end-to-end
service. Thus an MDSC may have to balance a number of the service. Thus an MDSC may have to balance a number of the
constraints on a service request and between different requested constraints on a service request and between different requested
services. It may also have to balance requested services with services. It may also have to balance requested services with
operational norms for the underlying physical networks. This operational norms for the underlying physical networks. This
balancing may be resolved using configured policy and using hard and balancing may be resolved using configured policy and using hard and
soft policy constraints. soft policy constraints.
8.4. Policy Applied to the Physical Network Controller 8.4. Policy Applied to the Provisioning Network Controller
The PNC is responsible for configuring the network elements, The PNC is responsible for configuring the network elements,
monitoring physical network resources, and exposing connectivity monitoring physical network resources, and exposing connectivity
(direct or abstracted) to the MDSC. It is therefore expected that (direct or abstracted) to the MDSC. It is therefore expected that
policy will dictate what connectivity information will be exported policy will dictate what connectivity information will be exported
between the PNC, via the MDSC-PNC Interface (MPI), and MDSC. between the PNC, via the MDSC-PNC Interface (MPI), and MDSC.
Policy interactions may arise when a PNC determines that it cannot Policy interactions may arise when a PNC determines that it cannot
compute a requested path from the MDSC, or notices that (per a compute a requested path from the MDSC, or notices that (per a
locally configured policy) the network is low on resources (for locally configured policy) the network is low on resources (for
skipping to change at page 31, line 39 skipping to change at page 31, line 47
regardless these data flows are on external or internal network regardless these data flows are on external or internal network
interfaces. interfaces.
The ACTN security discussion is further split into two specific The ACTN security discussion is further split into two specific
categories described in the following sub-sections: categories described in the following sub-sections:
. Interface between the Customer Network Controller and Multi . Interface between the Customer Network Controller and Multi
Domain Service Coordinator (MDSC), CNC-MDSC Interface (CMI) Domain Service Coordinator (MDSC), CNC-MDSC Interface (CMI)
. Interface between the Multi Domain Service Coordinator and . Interface between the Multi Domain Service Coordinator and
Physical Network Controller (PNC), MDSC-PNC Interface (MPI) Provisioning Network Controller (PNC), MDSC-PNC Interface (MPI)
From a security and reliability perspective, ACTN may encounter many From a security and reliability perspective, ACTN may encounter many
risks such as malicious attack and rogue elements attempting to risks such as malicious attack and rogue elements attempting to
connect to various ACTN components. Furthermore, some ACTN connect to various ACTN components. Furthermore, some ACTN
components represent a single point of failure and threat vector, components represent a single point of failure and threat vector,
and must also manage policy conflicts, and eavesdropping of and must also manage policy conflicts, and eavesdropping of
communication between different ACTN components. communication between different ACTN components.
The conclusion is that all protocols used to realize the ACTN The conclusion is that all protocols used to realize the ACTN
framework should have rich security features, and customer, framework should have rich security features, and customer,
skipping to change at page 32, line 40 skipping to change at page 32, line 48
Where the MDSC must interact with multiple (distributed) PNCs, a Where the MDSC must interact with multiple (distributed) PNCs, a
PKI-based mechanism is suggested, such as building a TLS or HTTPS PKI-based mechanism is suggested, such as building a TLS or HTTPS
connection between the MDSC and PNCs, to ensure trust between the connection between the MDSC and PNCs, to ensure trust between the
physical network layer control components and the MDSC. physical network layer control components and the MDSC.
Which MDSC the PNC exports topology information to, and the level of Which MDSC the PNC exports topology information to, and the level of
detail (full or abstracted) should also be authenticated and detail (full or abstracted) should also be authenticated and
specific access restrictions and topology views, should be specific access restrictions and topology views, should be
configurable and/or policy-based. configurable and/or policy-based.
10. References 10. IANA Considerations
10.1. Informative References This document has no actions for IANA.
11. 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, September 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
skipping to change at page 33, line 27 skipping to change at page 33, line 38
[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.
[Centralized] Farrel, A., et al., "An Architecture for Use of PCE [Centralized] Farrel, A., et al., "An Architecture for Use of PCE
and PCEP in a Network with Central Control", draft-ietf- and PCEP in a Network with Central Control", draft-ietf-
teas-pce-central-control, work in progress. teas-pce-central-control, work in progress.
[Service-YANG] Lee, Y., Dhody, D., and Ceccarrelli, C., "Traffic [Service-YANG] Lee, Y., Dhody, D., and Ceccarelli, C., "Traffic
Engineering and Service Mapping Yang Model", draft-lee- Engineering and Service Mapping Yang Model", draft-lee-
teas-te-service-mapping-yang, work in progress. teas-te-service-mapping-yang, work in progress.
[ACTN-YANG] Lee, Y., et al., "A Yang Data Model for ACTN VN [ACTN-YANG] Lee, Y., et al., "A Yang Data Model for ACTN VN
Operation", draft-lee-teas-actn-vn-yang, work in progress. Operation", draft-lee-teas-actn-vn-yang, work in progress.
[ACTN-REQ] Lee, Y., et al., "Requirements for Abstraction and [ACTN-REQ] Lee, Y., et al., "Requirements for Abstraction and
Control of TE Networks", draft-ietf-teas-actn- Control of TE Networks", draft-ietf-teas-actn-
requirements, work in progress. requirements, work in progress.
11. Contributors [TE-Topo] X. Liu et al., "YANG Data Model for TE Topologies", draft-
ietf-teas-yang-te-topo, work in progress.
12. Contributors
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
Email: adrian@olddog.co.uk Email: adrian@olddog.co.uk
Italo Busi Italo Busi
Huawei Huawei
Email: Italo.Busi@huawei.com Email: Italo.Busi@huawei.com
Khuzema Pithewan Khuzema Pithewan
skipping to change at page 36, line 4 skipping to change at page 36, line 9
+-------|------------------|-----+ +-------|------------------|-----+
| MPI | | MPI |
Domain Controller | | Domain Controller | |
+-------|-----+ | +-------|-----+ |
| +-----+ | | SBI | +-----+ | | SBI
| |PNC1 | | | | |PNC1 | | |
| +-----+ | | | +-----+ | |
+-------|-----+ | +-------|-----+ |
v SBI v v SBI v
------- ------- ------- -------
( ) ( ) ( ) ( )
- - - - - - - -
( ) ( ) ( ) ( )
( Domain 1 )----( Domain 2 ) ( Domain 1 )----( Domain 2 )
( ) ( ) ( ) ( )
- - - - - - - -
( ) ( ) ( ) ( )
------- ------- ------- -------
APPENDIX B - Example of IP + Optical network with L3VPN service
This section provides a more complex deployment scenario in which
ACTN hierarchy is deployed to control a multi-layer network via an
IP/MPLS PNC and an Optical PNC. The scenario is further enhanced by
the introduction of an upper layer service configuration (e.g.
L3VPN). The provisioning of the L3VPN service is outside ACTN scope
but it is worth showing how the two parts are integrated for the end
to end service fulfilment. An example of service configuration
function in the Service/Network Orchestrator is discussed in [I-
D.dhjain-bess-bgp-l3vpn-yang].
Customer
+-------------------------------+
| +-----+ |
| | CNC | |
| +-----+ |
+-------|--------+--------------+
| | Customer Service Model
| CMI | (non-ACTN interface)
Service/Network | |
Orchestrator | |
+-------|--------|--------------------------+
| | +-------------------------+ |
| | |Service Mapping Function | |
| | +-------------------------+ |
| | | | |
| +------+ | +---------------+ |
| | MDSC |--- |Service Config.| |
| +------+ +---------------+ |
+------|------------------|-----------------+
MPI | +------------+ (non-ACTN Interf.)
| /
+-----------/------------+
IP/MPLS | / |
Domain | / | Optical Domain
Controller | / | Controller
+--------|-------/----+ +---|--------------+
| +-----+ +-----+ | | +-----+ |
| |PNC1 | |Serv.| | | |PNC2 | |
| +-----+ +-----+ | | +-----+ |
+---------------------+ +------------------+
SBI | |
v |
+---------------------------------+ | SBI
/ IP/MPLS Network \ |
+-------------------------------------+ |
v
+--------------------------------------+
/ Optical Network \
+------------------------------------------+
 End of changes. 37 change blocks. 
133 lines changed or deleted 162 lines changed or added

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