draft-ietf-teas-actn-yang-01.txt   draft-ietf-teas-actn-yang-02.txt 
TEAS WG Young Lee TEAS WG Young Lee
Internet Draft Haomian Zheng Haomian Zheng
Intended status: Informational Huawei Internet Draft Huawei
Expires: August 28, 2018 Intended status: Informational
Daniel Ceccarelli Daniele Ceccarelli
Ericsson Expires: February 23, 2019 Ericsson
Bin Yeong Yoon Bin Yeong Yoon
ETRI ETRI
Oscar Gonzalez de Dios
Telefonica
Jong Yoon Shin
SKT
Sergio Belotti Sergio Belotti
Nokia Nokia
February 28, 2018 August 22, 2018
Applicability of YANG models for Abstraction and Control of Traffic Applicability of YANG models for Abstraction and Control of Traffic
Engineered Networks Engineered Networks
draft-ietf-teas-actn-yang-01 draft-ietf-teas-actn-yang-02
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 39 skipping to change at page 2, line 4
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 August 28, 2018. This Internet-Draft will expire on February 23, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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.
Abstract Abstract
Abstraction and Control of TE Networks (ACTN) refers to the set of Abstraction and Control of TE Networks (ACTN) refers to the set of
virtual network operations needed to orchestrate, control and manage virtual network operations needed to orchestrate, control and manage
large-scale multi-domain TE networks, so as to facilitate network large-scale multi-domain TE networks, so as to facilitate network
programmability, automation, efficient resource sharing, and end-to- programmability, automation, efficient resource sharing, and end-to-
end virtual service aware connectivity and network function end virtual service aware connectivity and network function
virtualization services. virtualization services.
This document explains how the different types of YANG models This document explains how the different types of YANG models
defined in the Operations and Management Area and in the Routing defined in the Operations and Management Area and in the Routing
Area are applicable to the ACTN framework. This document also shows Area are applicable to the ACTN framework. This document also shows
how the ACTN architecture can be satisfied using classes of data how the ACTN architecture can be satisfied using classes of data
model that have already been defined, and discusses the model that have already been defined, and discusses the
applicability of specific data models that are under development. It applicability of specific data models that are under development. It
also highlights where new data models may need to be developed. also highlights where new data models may need to be developed.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
2. Abstraction and Control of TE Networks (ACTN) Architecture.....3 2. Abstraction and Control of TE Networks (ACTN) Architecture.....3
3. Service Models.................................................5 3. Service Models.................................................5
4. Service Model Mapping to ACTN..................................6 4. Service Model Mapping to ACTN..................................7
4.1. Customer Service Models in the ACTN Architecture (CMI)....7 4.1. Customer Service Models in the ACTN Architecture (CMI)....7
4.2. Service Delivery Models in ACTN Architecture..............8 4.2. Service Delivery Models in ACTN Architecture..............8
4.3. Network Configuration Models in ACTN Architecture (MPI)...8 4.3. Network Configuration Models in ACTN Architecture (MPI)...8
4.4. Device Models in ACTN Architecture (SBI)..................9 4.4. Device Models in ACTN Architecture (SBI)..................9
5. Examples of Using Different Types of YANG Models...............9 5. Examples of Using Different Types of YANG Models..............10
5.1. Topology Collection.......................................9 5.1. Topology Collection......................................10
5.2. Connectivity over Two Client Nodes.......................10 5.2. Connectivity over Two Nodes .............................10
5.3. VN service example.......................................11 5.3. VN Service Example.......................................11
5.4. Data Center-Interconnection Example......................11 5.4. Data Center-Interconnection Example......................12
5.4.1. CMI (CNC-MDSC Interface)............................13 5.4.1. CMI (CNC-MDSC Interface)............................14
5.4.2. MPI (MDSC-PNC Interface)............................13 5.4.2. MPI (MDSC-PNC Interface)............................14
6. Security......................................................14 5.4.3. SBI (Southbound interface between PNC and devices)..14
7. Acknowledgements..............................................14 6. Security......................................................15
8. References....................................................14 7. Acknowledgements..............................................15
8.1. Informative References...................................14 8. References....................................................15
9. Contributors..................................................16 8.1. Informative References...................................15
Authors' Addresses...............................................17 9. Contributors..................................................18
Authors' Addresses...............................................18
1. Introduction 1. Introduction
Abstraction and Control of TE Networks (ACTN) describes a method for Abstraction and Control of TE Networks (ACTN) describes a method for
operating a Traffic Engineered (TE) network (such as an MPLS-TE operating a Traffic Engineered (TE) network (such as an MPLS-TE
network or a layer 1 transport network) to provide connectivity and network or a layer 1 transport network) to provide connectivity and
virtual network services for customers of the TE network. The virtual network services for customers of the TE network. The
services provided can be tuned to meet the requirements (such as services provided can be tuned to meet the requirements (such as
traffic patterns, quality, and reliability) of the applications traffic patterns, quality, and reliability) of the applications
hosted by the customers. More details about ACTN can be found in hosted by the customers. More details about ACTN can be found in
Section 2. Section 2.
Data models are a representation of objects that can be configured Data models are a representation of objects that can be configured
or monitored within a system. Within the IETF, YANG [RFC6020] is the or monitored within a system. Within the IETF, YANG [RFC7950] is the
language of choice for documenting data models, and YANG models have language of choice for documenting data models, and YANG models have
been produced to allow configuration or modelling of a variety of been produced to allow configuration or modelling of a variety of
network devices, protocol instances, and network services. YANG data network devices, protocol instances, and network services. YANG data
models have been classified in [Netmod-Yang-Model-Classification] models have been classified in [RFC8199] and [RFC8309].
and [Service-YANG].
This document shows how the ACTN architecture can be satisfied using This document shows how the ACTN architecture can be satisfied using
classes of data model that have already been defined, and discusses various classes of data model that have already been defined, and
the applicability of specific data models that are under discusses the applicability of specific data models that are under
development. It also highlights where new data models may need to be development. It also highlights where new data models may need to be
developed. developed.
2. Abstraction and Control of TE Networks (ACTN) Architecture 2. Abstraction and Control of TE Networks (ACTN) Architecture
[ACTN-Requirements] describes the high-level ACTN requirements. [ACTN-Frame] describes the architecture model for ACTN including the
[ACTN-Frame] describes the architecture model for ACTN including the
entities (Customer Network Controller (CNC), Multi-domain Service entities (Customer Network Controller (CNC), Multi-domain Service
Coordinator (MDSC), and Physical Network Controller (PNC)) and their Coordinator (MDSC), and Provisioning Network Controller (PNC)) and
interfaces. their interfaces.
Figure 1 depicts a high-level control and interface architecture for Figure 1 depicts a high-level control and interface architecture for
ACTN and is a reproduction of Figure 3 from [ACTN-Frame]. A number ACTN and is a reproduction of Figure 3 from [ACTN-Frame]. A number
of key ACTN interfaces exist for deployment and operation of ACTN- of key ACTN interfaces exist for deployment and operation of ACTN-
based networks. These are highlighted in Figure 1 (ACTN Interfaces) based networks. These are highlighted in Figure 1 (ACTN Interfaces)
below: below:
+--------------+ +---------------+ +--------------+ +--------------+ +---------------+ +--------------+
| CNC-A | | CNC-B | | CNC-C | | CNC-A | | CNC-B | | CNC-C |
|(DC provider) | | (ISP) | | (MVNO) | |(DC provider) | | (ISP) | | (MVNO) |
+--------------+ +---------------+ +--------------+ +--------------+ +---------------+ +--------------+
\ | / \ | /
Business \ | / Business \ | /
Boundary =======\========================|=========================/======= Boundary =======\========================|=========================/=======
Between \ | CMI / Between \ | CMI /
Customer & ----------- | -------------- Customer & ----------- | --------------
Network Provider \ | / Network Operator \ | /
+-----------------------+ +-----------------------+
| MDSC | | MDSC |
+-----------------------+ +-----------------------+
/ | \ / | \
------------ |MPI ---------------- ------------ |MPI ----------------
/ | \ / | \
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
| PNC | | PNC | | PNC | | PNC | | PNC | | PNC |
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
| GMPLS / | / \ | GMPLS / | / \
skipping to change at page 4, line 48 skipping to change at page 5, line 5
- - ( ) ( ) ----- - - ( ) ( ) -----
( ) ( Phys. ) ( Phys. ) ( ) ( Phys. ) ( Phys. )
-------- ( Net ) ( Net ) -------- ( Net ) ( Net )
----- ----- ----- -----
Figure 1 : ACTN Interfaces Figure 1 : ACTN Interfaces
The interfaces and functions are described below (without modifying The interfaces and functions are described below (without modifying
the definitions) in [ACTN-Frame]: the definitions) in [ACTN-Frame]:
. The CNC-MDSC Interface (CMI) is an interface between a Customer . The CNC-MDSC Interface (CMI) is an interface between a CNC and
Network Controller and a Multi Domain Service Controller. The an MDSC. This interface is used to communicate the service
interface will communicate the service request or application request or application demand. A request will include specific
demand. A request will include specific service properties, for service properties, for example, services type, bandwidth and
example, services type, bandwidth and constraint information. constraint information. These constraints SHOULD be measurable
These constraints SHOULD be measurable by MDSC and therefore by MDSC and therefore visible to CNC via CMI. The CNC can also
visible to CNC via CMI. The CNC can also request the creation request the creation of the virtual network service based on
of the virtual network based on underlying physical resources underlying physical resources to provide network services for
to provide network services for the applications. The CNC can the applications. The CNC can provide the end-point
provide the end-point information/characteristics, traffic information/characteristics together with traffic matrix
matrix specifying specific customer constraints. The MDSC may specifying specific customer constraints. The MDSC may also
also report potential network topology availability if queried report potential network topology availability if queried for
for current capability from the Customer Network Controller. current capability from the Customer Network Controller.
Performance monitoring is also applicable in CMI, which enables
the MDSC to report network parameters/telemetries that may
guide the CNC to create/change their services.
. The MDSC-PNC Interface (MPI) is an interface between a Multi . The MDSC-PNC Interface (MPI) is an interface between an MDSC
Domain Service Coordinator and a Physical Network Controller. and a PNC. It allows the MDSC to communicate requests to
It allows the MDSC to communicate requests to create/delete create/delete connectivity or to modify bandwidth reservations
connectivity or to modify bandwidth reservations in the in the physical network. In multi-domain environments, each PNC
physical network. In multi-domain environments, each PNC is is responsible for a separate domain. The MDSC needs to
responsible for a separate domain. The MDSC needs to establish establish multiple MPIs, one for each PNC and perform
multiple MPIs, one for each PNC and perform coordination coordination between them to provide cross-domain connectivity.
between them to provide cross-domain connectivity. MPI plays an important role for multi-vendor operations; inter-
operability can be achieved by standardized interface modules.
. The South-Bound Interface (SBI) is the provisioning interface . The South-Bound Interface (SBI) is the provisioning interface
for creating forwarding state in the physical network, for creating forwarding state in the physical network,
requested via the Physical Network Controller. The SBI is not requested via the PNC. The SBI is not in the scope of ACTN,
in the scope of ACTN, however, it is included in this document however, it is included in this document so that it can be
so that it can be compared to models in [Service-Yang]. compared to models in [Service-Yang].
3. Service Models 3. Service Models
[Service-YANG] introduces a reference architecture to explain the [RFC8309] introduces a reference architecture to explain the nature
nature and usage of service YANG models in the context of service and usage of service YANG models in the context of service
orchestration. Figure 2 below depicts this relationship and is a orchestration. Figure 2 below depicts this relationship and is a
reproduction of Figure 2 from [Service-YANG]. Four models depicted reproduction of Figure 2 from [RFC8309]. Four models depicted in
in Figure 2 are defined as follows: Figure 2 are defined as follows:
. Customer Service Model: A customer service model is used to . Customer Service Model: A customer service model is used to
describe a service as offer or delivered to a customer by a describe a service as offer or delivered to a customer by a
network operator. network operator.
. Service Delivery Model: A service delivery model is used by a . Service Delivery Model: A service delivery model is used by a
network operator to define and configure how a service is network operator to define and configure how a service is
provided by the network. provided by the network.
. Network Configuration Model: A network configuration model is . Network Configuration Model: A network configuration model is
used by a network orchestrator to provide network-level used by a network orchestrator to provide network-level
configuration model to a controller. configuration model to a controller.
. Device Configuration Model: A device configuration model is . Device Configuration Model: A device configuration model is
used by a controller to configure physical network elements. used by a controller to configure physical network elements.
Customer Customer
------------------ Service ---------- ------------------ Service ----------
| | Model | | | | Model | |
| Service |<-------->| Customer | | Service |<-------->| Customer |
skipping to change at page 6, line 46 skipping to change at page 7, line 8
--------- --------- --------- --------- --------- --------- --------- --------- --------- ---------
| Network | | Network | | Network | | Network | | Network | | Network | | Network | | Network | | Network | | Network |
| Element | | Element | | Element | | Element | | Element | | Element | | Element | | Element | | Element | | Element |
--------- --------- --------- --------- --------- --------- --------- --------- --------- ---------
Figure 2: An SDN Architecture with a Service Orchestrator Figure 2: An SDN Architecture with a Service Orchestrator
4. Service Model Mapping to ACTN 4. Service Model Mapping to ACTN
YANG models coupled with the RESTCONF/NETCONF protocol YANG models coupled with the RESTCONF/NETCONF protocol
[Netconf][Restconf] provides solutions for the ACTN framework. This [RFC6241][RFC8040] provides solutions for the ACTN framework. This
section explains which types of YANG models apply to each of the section explains which types of YANG models apply to each of the
ACTN interfaces. ACTN interfaces.
Refer to Figure 5 of [ACTN-Frame] for details of the mapping between Refer to Figure 5 of [ACTN-Frame] for details of the mapping between
ACTN functions and service models. In summary, the following ACTN functions and service models. In summary, the following
mappings are held between and Service Yang Models and the ACTN mappings are held between and Service Yang Models and the ACTN
interfaces. interfaces.
o Customer Service Model <-> CMI o Customer Service Model <-> CMI
o Network Configuration Model <-> MPI o Network Configuration Model <-> MPI
skipping to change at page 7, line 28 skipping to change at page 7, line 38
Among the key functions of Customer Service Models on the CMI is the Among the key functions of Customer Service Models on the CMI is the
service request. A request will include specific service properties, service request. A request will include specific service properties,
including: service type and its characteristics, bandwidth, including: service type and its characteristics, bandwidth,
constraint information, and end-point characteristics. constraint information, and end-point characteristics.
The following table provides a list of functions needed to build the The following table provides a list of functions needed to build the
CMI. They are mapped with Customer Service Models. CMI. They are mapped with Customer Service Models.
Function Yang Model Function Yang Model
----------------------------------------------------------- -----------------------------------------------------------
VN Service Request [ACTN-VN-YANG] VN Service Request [ACTN-VN-YANG]
VN Computation Request [ACTN-VN-YANG]* VN Computation Request [ACTN-VN-YANG]*
TE & Service Mapping [TE-Service-Mapping]** TE & Service Mapping [TE-Service-Mapping]**
VN Performance Monitoring Telemetry [ACTN-PM-Telemetry]*** VN Performance Monitoring Telemetry [ACTN-PM-Telemetry]***
Topology Abstraction [TE-topology]**** Topology Abstraction [TE-topology]****
Layer 1 Connectivity Service Model [L1CSM]
Layer 2 VPN Service Model [L2SM]
Layer 3 VPN Service Model [RFC8299]
*VN computation request in the CMI context means network path *VN computation request in the CMI context means network path
computation request based on customer service connectivity request computation request based on customer service connectivity request
constraints prior to the instantiation of a VN creation. constraints prior to the instantiation of a VN creation.
**[TE-Service-Mapping] provides a mapping and cross-references **[TE-Service-Mapping] provides a mapping and cross-references
between service models (e.g., L3SM, L2SM, L1CSM) and TE model via between service models (e.g., L3SM, L2SM, L1CSM) and TE models via
[ACTN-VN-YANG] and [TE-topology]. [ACTN-VN-YANG] and [TE-topology]. This model can be used as either
Customer Service Models, or Service Delivery model described in
Section 4.2.
***ietf-actn-te-kpi-telemetry model describes performance telemetry ***[ACTN-PM-Telemetry] describes performance telemetry for e2e
for ACTN VN model. This module also allows autonomic traffic tunnels and VNs. This module also allows autonomic traffic
engineering scaling intent configuration mechanism on the VN level. engineering scaling intent configuration mechanism on both the e2e
Scale in/out criteria might be used for network autonomics in order tunnel and the VN level. Scale in/out criteria might be used for
the controller to react to a certain set of variations in monitored network automation in order the controller to react to a certain set
parameters. Moreover, this module also provides mechanism to define of variations in monitored parameters. Moreover, this module also
aggregated telemetry parameters as a grouping of underlying VN level provides mechanism to define aggregated telemetry parameters as a
telemetry parameters. grouping of underlying Tunnel and VN level telemetry parameters.
****TE-Topology's Connectivity Matrices/Matrix construct can be used ****TE-Topology's Connectivity Matrices/Matrix construct can be used
to instantiate VN Service via a suitable referencing and mapping to instantiate VN Service via a suitable referencing and mapping
with [ACTN-VN-YANG]. with [ACTN-VN-YANG].
4.2. Service Delivery Models in ACTN Architecture 4.2. Service Delivery Models in ACTN Architecture
The Service Delivery Models where the service orchestration and the The Service Delivery Models where the service orchestration and the
network orchestration could be implemented as separate components as network orchestration could be implemented as separate components as
seen in [Service-YANG]. This is also known as Network Service seen in [RFC8309]. On the other hand, from an ACTN architecture
Models. On the other hand, from an ACTN architecture point of view, point of view, the service delivery model between the service
the service delivery model between the service orchestrator and the orchestrator and the network orchestrator is an internal interface
network orchestrator is an internal interface between sub-components between sub-components of the MDSC in a single MDSC model.
of the MDSC in a single MDSC model.
In the MDSC hierarchical model where there are multiple MDSCs, the In the MDSC hierarchical model where there are multiple MDSCs, the
interface between the top MDSC and the bottom MDSC can be mapped to interface between the top MDSC and the bottom MDSC can be mapped to
service delivery models. service delivery models.
4.3. Network Configuration Models in ACTN Architecture (MPI) 4.3. Network Configuration Models in ACTN Architecture (MPI)
The Network Configuration Models is used between the network The Network Configuration Models is used between the network
orchestrator and the controller in [Service-YANG]. In ACTN, this orchestrator and the controller in [Service-YANG]. In ACTN, this
model is used primarily between a MDSC and a PNC. The Network model is used primarily between a MDSC and a PNC. The Network
skipping to change at page 9, line 6 skipping to change at page 9, line 20
Function Yang Model Function Yang Model
-------------------------------------------------------- --------------------------------------------------------
Configuration Scheduling [Schedule] Configuration Scheduling [Schedule]
Path computation [PATH_COMPUTATION-API] Path computation [PATH_COMPUTATION-API]
Tunnel/LSP Provisioning [TE-Tunnel] Tunnel/LSP Provisioning [TE-Tunnel]
Topology Abstraction [TE-topology] Topology Abstraction [TE-topology]
Client Signal Description [Client-signal] Client Signal Description [Client-signal]
Service Provisioning TBD* Service Provisioning TBD*
OTN Topology Abstraction [OTN-YANG] OTN Topology Abstraction [OTN-topo]
WSON Topology Abstraction [WSON-YANG] WSON Topology Abstraction [WSON-topo]
Flexi-grid Topology Abstraction [Flexi-YANG] Flexi-grid Topology Abstraction [Flexi-topo]
Microwave Topology Abstraction [MW-topo]
OTN Tunnel Model [OTN-Tunnel] OTN Tunnel Model [OTN-Tunnel]
WSON TE Tunnel Model [WSON-Tunnel] WSON TE Tunnel Model [WSON-Tunnel]
Flexi-grid Tunnel Model [Flexigrid-Tunnel] Flexi-grid Tunnel Model [Flexigrid-Tunnel]
* This function needs to be investigated further. This can be a part * This function needs to be investigated further. This can be a part
of [TE-Tunnel] which is to be determined. Service provisioning is an of [TE-Tunnel] which is to be determined. Service provisioning is an
optional function that builds on top the path provisioning one. optional function that builds on top the path provisioning one.
[T-NBI Applicability] provides a summary on the applicability of [TE-topo-tunnel] provides tutorials for the clarification and
existing YANG model usage in the current network configuration, example usage for TE topology model [TE-topology] and TE tunnel
especially for transport network. model [TE-Tunnel]. [T-NBI Applicability] provides a summary on the
applicability of existing YANG model usage in the current network
configuration, especially for transport network.
4.4. Device Models in ACTN Architecture (SBI) 4.4. Device Models in ACTN Architecture (SBI)
Note that SBI is not in the scope of ACTN, as there are already Note that SBI is not in the scope of ACTN, as there is already
mature protocol solutions for various purpose on the device level of mature protocol solutions for various purpose on the device level of
ACTN architecture, such as RSVP-TE, OSPF-TE and so on. The ACTN architecture, such as RSVP-TE, OSPF-TE and so on. The
interworking of such protocols and ACTN controller hierarchies can interworking of such protocols and ACTN controller hierarchies can
be found in [gmpls-controller-inter-work]. be found in [gmpls-controller-inter-work].
For the device YANG models are used for per-device configuration For the device YANG models are used for per-device configuration
purpose, they can be used between the PNC and the physical purpose, they can be used between the PNC and the physical
network/devices. One example of Device Models is ietf-te-device yang network/devices. One example of Device Models is ietf-te-device yang
module defined in [TE-tunnel]. module defined in [TE-tunnel].
skipping to change at page 10, line 5 skipping to change at page 10, line 20
in the network operation. A few typical generic scenarios are in the network operation. A few typical generic scenarios are
involved. In [T-NBI Applicability], there are more transport-related involved. In [T-NBI Applicability], there are more transport-related
scenarios and examples. scenarios and examples.
5.1. Topology Collection 5.1. Topology Collection
Before any connection is requested and delivered, the controller Before any connection is requested and delivered, the controller
needs to understand the network topology. The topology information needs to understand the network topology. The topology information
is exchanged among controllers with topology models, such as [te- is exchanged among controllers with topology models, such as [te-
topology]. Moreover, technology-specific topology reporting may use topology]. Moreover, technology-specific topology reporting may use
the model described in [OTN-YANG] [WSON-YANG], and [Flexi-YANG] for the model described in [OTN-topo] [WSON-topo], and [Flexi-topo] for
OTN, WSON and Flexi-grid, respectively. By collecting the network OTN, WSON and Flexi-grid, respectively. By collecting the network
topology, each controller can therefore construct a local database, topology, each controller can therefore construct a local database,
which can be used for the further service deployment. which can be used for the further service deployment.
There can be different types of abstraction applied between each There can be different types of abstraction applied between each
pair of controllers as discussed in in [ACTN-frame]. The technology- pair of controllers, corresponding method can be found in [ACTN-
specific features may be hidden after abstraction to make the frame]. The technology-specific features may be hidden after
network operation easier. abstraction, to make the network easier for the user to operate.
When there are topology changes in the physical network, the PNC When there is a topology change in the physical network, the PNC
should report the change to upper level of controllers via updating should report the change to upper level of controllers via updating
messages using topology models. Accordingly, such changes are messages using topology models. Accordingly, such changes is
propagated between different controllers for further propagated between different controllers for further
synchronization. synchronization.
5.2. Connectivity over Two Client Nodes 5.2. Connectivity over Two Nodes
The service models, such as described in [RFC8049], [L2SM] and The service models, such as described in [RFC8299], [L2SM] and
[L1CSM], provide a connectivity service model which can be used in [L1CSM] provide a connectivity service model which can be used in
connection-oriented networks. connection-oriented networks.
It would be used as follows in the ACTN architecture: It would be used as follows in the ACTN architecture:
. A CNC uses the service models to specify the two client nodes . A CNC uses the service models to specify the two client nodes
that are to be connected, and also indicates the amount of that are to be connected, and also indicates the amount of
traffic (i.e., the bandwidth required) and payload type. What traffic (i.e., the bandwidth required) and payload type. What
may be additionally specified is the SLA/Policy that describes may be additionally specified is the SLA that describes the
the required quality and resilience of the service especially required quality and resilience of the service.
on TE binding with the service (e.g., soft isolation, hard
isolation, etc.) as defined in [TE-Service-Mapping].
. The MDSC uses the information in the request to pick the right . The MDSC uses the information in the request to pick the right
network (domain) and also to select the provider edge nodes network (domain) and also to select the provider edge nodes
corresponding to the customer edge nodes. corresponding to the customer edge nodes.
If there are multiple domains, then the MDSC needs to If there are multiple domains, then the MDSC needs to
coordinate across domains to set up network tunnels to deliver coordinate across domains to set up network tunnels to deliver
a service. Thus coordination includes, but is not limited to, a service. Thus coordination includes, but is not limited to,
picking the right domain sequence to deliver a service. picking the right domain sequence to deliver a service.
skipping to change at page 11, line 4 skipping to change at page 11, line 19
If there are multiple domains, then the MDSC needs to If there are multiple domains, then the MDSC needs to
coordinate across domains to set up network tunnels to deliver coordinate across domains to set up network tunnels to deliver
a service. Thus coordination includes, but is not limited to, a service. Thus coordination includes, but is not limited to,
picking the right domain sequence to deliver a service. picking the right domain sequence to deliver a service.
Additionally, an MDSC can initiate the creation of a tunnel (or Additionally, an MDSC can initiate the creation of a tunnel (or
tunnel segment) in order to fulfill the service request from tunnel segment) in order to fulfill the service request from
CNC based on path computation upon the overall topology CNC based on path computation upon the overall topology
information it synthesized from different PNCs. The based model information it synthesized from different PNCs. The based model
that can cater this purpose is the TE tunnel model specified in that can cater this purpose is the TE tunnel model specified in
[te-tunnel]. Technology-specific tunnel configuration may use [te-tunnel]. Technology-specific tunnel configuration may use
the model described in [OTN-Tunnel] [WSON-Tunnel], and the model described in [OTN-Tunnel] [WSON-Tunnel], and
[Flexigrid-Tunnel] for OTN, WSON and Flexi-grid, respectively. [Flexigrid-Tunnel] for OTN, WSON and Flexi-grid, respectively.
. Then, the PNCs need to decide the explicit route of such a . Then, the PNCs need to decide the explicit route of such a
tunnel or tunnel segment (in case of multiple domains) for each tunnel or tunnel segment (in case of multiple domains) for each
domain, and then create such a tunnel using protocols such as domain, and then create such a tunnel using protocols such as
PCEP and RSVP-TE or using per-hop configuration. PCEP and RSVP-TE or using per-hop configuration.
5.3. VN service example 5.3. VN Service Example
The service model defined in [ACTN-VN-YANG] describes a virtual The service model defined in [ACTN-VN-YANG] describes a virtual
network (VN) as a service which is a set of multiple connectivity network (VN) as a service which is a set of multiple connectivity
services: services:
. A CNC will request VN to the MDSC by specifying a list of VN . A CNC will request VN to the MDSC by specifying a list of VN
members. Each VN member specifies either a single connectivity members. Each VN member specifies either a single connectivity
service, or a source with multiple potential destination points service, or a source with multiple potential destination points
in the case that the precise destination sites are to be in the case that the precise destination sites are to be
determined by MDSC. determined by MDSC.
skipping to change at page 13, line 35 skipping to change at page 14, line 35
Data Center to another Data Center, etc. This service model is used Data Center to another Data Center, etc. This service model is used
between the CNC and the MDSC (CMI). The CNC in this use-case is an between the CNC and the MDSC (CMI). The CNC in this use-case is an
external entity that wants to create a VN and operates on the VN. external entity that wants to create a VN and operates on the VN.
5.4.2. MPI (MDSC-PNC Interface) 5.4.2. MPI (MDSC-PNC Interface)
The Network Configuration Model is used between the MDSC and the The Network Configuration Model is used between the MDSC and the
PNCs. Based on the Customer Service Model's request, the MDSC will PNCs. Based on the Customer Service Model's request, the MDSC will
need to translate the service model into the network configuration need to translate the service model into the network configuration
model to instantiate a set of multi-domain connections between the model to instantiate a set of multi-domain connections between the
prescribed DC sources and DC destinations. The MDSC will also need prescribed sources and the destinations. The MDSC will also need to
to dynamically interact with the CNC for dynamic policy changes dynamically interact with the CNC for dynamic policy changes
initiated by the CNC. Upon the determination of the multi-domain initiated by the CNC. Upon the determination of the multi-domain
connections, the MDSC will need to use the network configuration connections, the MDSC will need to use the network configuration
model such as [TE-Tunnel] to interact with each PNC involved on the model such as [TE-Tunnel] to interact with each PNC involved on the
path. [TE-Topology] is used to for the purpose of underlying domain path. [TE-Topology] is used to for the purpose of underlying domain
network abstraction from the PNC to the MDSC. network abstraction from the PNC to the MDSC.
5.4.3. SBI (Southbound interface between PNC and devices)
The Device Model can be used between the PNC and its underlying
devices that are controlled by the PNC. The PNC will need to trigger
signaling using any mechanisms it employees (e.g. [RSVP-TE-YANG]) to
provision its domain path segment. There can be a plethora of
choices how to control/manage its domain network. The PNC is
responsible to abstract its domain network resources and update it
to the MDSC. Note that this interface is not in the scope of ACTN.
This section is provided just for an illustration purpose.
6. Security 6. Security
This document is an informational draft. When the models mentioned This document is an informational draft. When the models mentioned
in this draft are implemented, detailed security consideration will in this draft are implemented, detailed security consideration will
be given in such work. be given in such work.
How security fits into the whole architecture has the following How security fits into the whole architecture has the following
components: components:
- the use of Restconf security between components - the use of Restconf security between components
skipping to change at page 14, line 32 skipping to change at page 15, line 34
7. Acknowledgements 7. Acknowledgements
We thank Adrian Farrel for providing useful comments and suggestions We thank Adrian Farrel for providing useful comments and suggestions
for this draft. for this draft.
8. References 8. References
8.1. Informative References 8.1. Informative References
[Service-YANG] Q. Wu, W. Liu and A. Farrel, "Service Models [RFC8309] Q. Wu, W. Liu and A. Farrel, "Service Models Explained",
Explained", draft-wu-opsawg-service-model-explained, work RFC 8309.
in progress.
[Netmod-Yang-Model-Classification] D. Bogdanovic, B. Claise, and C. [RFC8199] D. Bogdanovic, B. Claise, and C. Moberg, "YANG Module
Moberg, "YANG Module Classification", draft-ietf-netmod- Classification", RFC 8199.
yang-model-classification, work in progress.
[Netconf] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241. (NETCONF)", RFC 6241.
[Restconf] A. Bierman, M. Bjorklund, and K. Watsen, "RESTCONF [RFC8040] A. Bierman, M. Bjorklund, and K. Watsen, "RESTCONF
Protocol", draft-ietf-netconf-restconf, work in progress. Protocol", RFC 8040.
[ACTN-Requirements] Y. Lee, et al., "ACTN Requirements for
Abstraction and Control of TE Networks", draft-ietf-teas-
actn-requirements, work in progress.
[ACTN-Frame] D. Cecarelli and Y. Lee, "Framework for Abstraction and [ACTN-Frame] D. Ceccarelli and Y. Lee, "Framework for Abstraction
Control of Traffic Engineered Networks", draft-ietf-teas- and Control of Traffic Engineered Networks", draft-ietf-
actn-framework, work in progress. teas-actn-framework, work in progress.
[TE-Topology] X. Liu, et. al., "YANG Data Model for TE Topologies", [TE-Topology] X. Liu, et. al., "YANG Data Model for TE Topologies",
draft-ietf-teas-yang-te-topo, work in progress. draft-ietf-teas-yang-te-topo, work in progress.
[TE-Tunnel] T. Saad (Editor), "A YANG Data Model for Traffic [TE-Tunnel] T. Saad (Editor), "A YANG Data Model for Traffic
Engineering Tunnels and Interfaces", draft-ietf-teas-yang- Engineering Tunnels and Interfaces", draft-ietf-teas-yang-
te, work in progress. te, work in progress.
[ACTN-VN-YANG] Y. Lee (Editor), "A Yang Data Model for ACTN VN [ACTN-VN-YANG] Y. Lee (Editor), "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-Info] Y. Lee & S. Belotti, "Information Model for Abstraction [L1CSM] G. Fioccola, K. Lee, Y. Lee, D. Dhody, O. Gonzalez de-Dios,
and Control of TE Networks (ACTN)", draft-leebelotti-teas- D. Ceccarelli, "A Yang Data Model for L1 Connectivity
actn-info, work in progress. Service Model (L1CSM)", draft-ietf-ccamp-l1csm-yang, work
in progress.
[Transport-Service-Model] X. Zhang (Editor), "A Service YANG Model [L2SM] B. Wen, G. Fioccola, C. Xie, L. Jalil, "A YANG Data Model for
for Connection-oriented Transport Networks", draft-zhang- L2VPN Service Delivery", draft-ietf-l2sm-l2vpn-service-
teas-transport-service-model, work in progress. model, work in progress.
[RFC8299] Q. Wu, S. Litkowski, L. Tomotaki, K.Ogaki, "YANG Data
Model for L3VPN Service Delivery", RFC8299.
[ACTN-Info] Y. Lee & S. Belotti, "Information Model for Abstraction
and Control of TE Networks (ACTN)", draft-ietf-teas-actn-
info, work in progress.
[PATH-COMPUTATION-API] I.Busi/S.Belotti et al. "Path Computation [PATH-COMPUTATION-API] I.Busi/S.Belotti et al. "Path Computation
API", draft-busibel-ccamp-path-computation-api-00.txt, API", draft-ietf-teas-yang-path-computation, work in
work in progress progress
[RSVP-TE-YANG] T. Saad (Editor), "A YANG Data Model for Resource [RSVP-TE-YANG] T. Saad (Editor), "A YANG Data Model for Resource
Reservation Protocol (RSVP)", draft-ietf-teas-yang-rsvp, Reservation Protocol (RSVP)", draft-ietf-teas-yang-rsvp,
work in progress. work in progress.
[Schedule] X. Liu, et. al., "A YANG Data Model for Configuration [Schedule] X. Liu, et. al., "A YANG Data Model for Configuration
Scheduling", draft-liu-netmod-yang-schedule, work in Scheduling", draft-liu-netmod-yang-schedule, work in
progress. progress.
[ACTN-Abstraction] Y. Lee, D. Dhody, and D. Ceccarelli, "ACTN [OTN-topo] H. Zheng, et. al., "A YANG Data Model for Optical
Abstraction Methods", draft-lee-tease-actn-abstraction, Transport Network Topology", draft-ietf-ccamp-otn-topo-
work in progress. yang, work in progress.
[OTN-YANG] X. Zhang, A. Sharma, and X. Liu, "A YANG Data Model for
Optical Transport Network Topology", draft-zhang-ccamp-l1-
topo-yang, work in progress.
[WSON-YANG] Y. Lee, et. al., "A Yang Data Model for WSON Optical [WSON-topo] Y. Lee, et. al., "A Yang Data Model for WSON Optical
Networks", draft-ietf-ccamp-wson-yang, work in progress. Networks", draft-ietf-ccamp-wson-yang, work in progress.
[Flexi-YANG] J.E. Lopez de Vergara, et. al., "YANG data model for [Flexi-topo] J.E. Lopez de Vergara, et. al., "YANG data model for
Flexi-Grid Optical Networks", draft-vergara-ccamp-flexigrid- Flexi-Grid Optical Networks", draft-vergara-ccamp-flexigrid-
yang, work in progress.[ODU-Tunnel] Sharma, R. Rao, and yang, work in progress.
X. Zhang, "OTN Service YANG Model", draft-sharma-ccamp-
otn-service-model, work in progress. [MW-topo] M. Ye, et. al., "A YANG Data Model for Microwave
Topology", draft-ye-ccamp-mw-topo-yang, work in progress.
[OTN-Tunnel] H. Zheng, et. al., "OTN Tunnel YANG Model", draft-
ietf-ccamp-otn-tunnel-model, work in progress.
[ACTN-PM-Telemetry] Y. Lee, D. Dhody, S. Karunanithi, R. Vilalta, D. [ACTN-PM-Telemetry] Y. Lee, D. Dhody, S. Karunanithi, R. Vilalta, D.
King, and D. Ceccarelli, "YANG models for ACTN TE King, and D. Ceccarelli, "YANG models for ACTN TE
Performance Monitoring Telemetry and Network Autonomics", Performance Monitoring Telemetry and Network Autonomics",
draft-lee-teas-actn-pm-telemetry-autonomics, work in draft-lee-teas-actn-pm-telemetry-autonomics, work in
progress. progress.
[WSON-Tunnel] Y. Lee, D. Dhody, V. Lopez, D. King, B. Yoon, and R. [WSON-Tunnel] Y. Lee, D. Dhody, V. Lopez, D. King, B. Yoon, and R.
Vilalta, "A Yang Data Model for WSON Tunnel", draft-ietf- Vilalta, "A Yang Data Model for WSON Tunnel", draft-ietf-
ccamp-wson-tunnel-model, work in progress. ccamp-wson-tunnel-model, work in progress.
skipping to change at page 16, line 34 skipping to change at page 17, line 38
[Flexigrid-Tunnel] J. Vergara, D. Perdices, V. Lopez, O. Gonzalez de [Flexigrid-Tunnel] J. Vergara, D. Perdices, V. Lopez, O. Gonzalez de
Dios, D. King, Y. Lee, and G. Galimberti, "YANG data model Dios, D. King, Y. Lee, and G. Galimberti, "YANG data model
for Flexi-Grid media-channels", draft-ietf-ccamp- for Flexi-Grid media-channels", draft-ietf-ccamp-
flexigrid-media-channel-yang, work in progress. flexigrid-media-channel-yang, work in progress.
[TE-Service-Mapping] Y. Lee, et al, "Traffic Engineering and Service [TE-Service-Mapping] Y. Lee, et al, "Traffic Engineering and Service
Mapping Yang Model", draft-lee-teas-te-service-mapping- Mapping Yang Model", draft-lee-teas-te-service-mapping-
yang, work in progress. yang, work in progress.
[Client-signal] H. Zheng, et al, "A YANG Data Model for Optical [Client-signal] H. Zheng, et al, "A YANG Data Model for Optical
Transport Network Client Signals", draft-zheng-ccamp-otn- Transport Network Client Signals", draft-zheng-ccamp-
client-signal-yang, work in progress. client-signal-yang, work in progress.
[TE-topo-Tunnel] I.Bryskin, et. al., "TE Topology and Tunnel
Modeling for Transport Networks", draft-ietf-teas-te-topo-
and-tunnel-modeling, work in progress.
[T-NBI Applicability] I. Busi, et al, "Transport Northbound [T-NBI Applicability] I. Busi, et al, "Transport Northbound
Interface Applicability Statement and Use Cases", draft- Interface Applicability Statement and Use Cases", draft-
ietf-ccamp-transport-nbi-app-statement, work in progress. ietf-ccamp-transport-nbi-app-statement, work in progress.
[gmpls-controller-inter-work] H. Zheng, et al, "Interworking of [gmpls-controller-inter-work] H. Zheng, et al, "Interworking of
GMPLS Control and Centralized Controller System", draft- GMPLS Control and Centralized Controller System", draft-
zheng-ccamp-gmpls-controller-inter-work, work in progress. zheng-ccamp-gmpls-controller-inter-work, work in progress.
9. Contributors 9. Contributors
 End of changes. 55 change blocks. 
145 lines changed or deleted 174 lines changed or added

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