draft-ietf-ccamp-transport-nbi-app-statement-04.txt   draft-ietf-ccamp-transport-nbi-app-statement-05.txt 
CCAMP Working Group I. Busi CCAMP Working Group I. Busi
Internet Draft Huawei Internet Draft Huawei
Intended status: Informational D. King Intended status: Informational D. King
Lancaster University Old Dog Consulting
H. Zheng H. Zheng
Huawei Huawei
Y. Xu Y. Xu
CAICT CAICT
Expires: May 2019 November 4, 2018 Expires: September 2019 March 11, 2019
Transport Northbound Interface Applicability Statement Transport Northbound Interface Applicability Statement
draft-ietf-ccamp-transport-nbi-app-statement-04 draft-ietf-ccamp-transport-nbi-app-statement-05
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. 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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other documents
time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as
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 May 4, 2019. This Internet-Draft will expire on September 11, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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 respect carefully, as they describe your rights and restrictions with
to this document. Code Components extracted from this document must respect to this document. Code Components extracted from this
include Simplified BSD License text as described in Section 4.e of document must include Simplified BSD License text as described in
the Trust Legal Provisions and are provided without warranty as Section 4.e of the Trust Legal Provisions and are provided without
described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Abstract Abstract
Transport network domains, including Optical Transport Network (OTN) Transport network domains, including Optical Transport Network (OTN)
and Wavelength Division Multiplexing (WDM) networks, are typically and Wavelength Division Multiplexing (WDM) networks, are typically
deployed based on a single vendor or technology platforms. They are deployed based on a single vendor or technology platforms. They are
often managed using proprietary interfaces to dedicated Element often managed using proprietary interfaces to dedicated Element
Management Systems (EMS), Network Management Systems (NMS) and Management Systems (EMS), Network Management Systems (NMS) and
increasingly Software Defined Network (SDN) controllers. increasingly Software Defined Network (SDN) controllers.
A well-defined open interface to each domain management system or A well-defined open interface to each domain management system or
controller is required for network operators to facilitate control controller is required for network operators to facilitate control
automation and orchestrate end-to-end services across multi-domain automation and orchestrate end-to-end services across multi-domain
networks. These functions may be enabled using standardized data networks. These functions may be enabled using standardized data
models (e.g. YANG), and appropriate protocol (e.g., RESTCONF). models (e.g. YANG), and appropriate protocol (e.g., RESTCONF).
This document analyses the applicability of the YANG models being This document analyses the applicability of the YANG models being
defined by IETF (TEAS and CCAMP WGs in particular) to support OTN defined by the IETF (Traffic Engineering Architecture and Signaling
single and multi-domain scenarios. (TEAS) and Common Control and Measurement Plane (CCAMP) WGs in
particular) to support OTN single and multi-domain scenarios.
Table of Contents Table of Contents
1. Introduction...................................................4 1. Introduction...................................................4
1.1. The scope of this document................................4 1.1. The scope of this document................................4
1.2. Assumptions...............................................5 1.2. Assumptions...............................................5
2. Terminology....................................................6 2. Terminology....................................................6
3. Conventions used in this document..............................7 3. Conventions used in this document..............................7
3.1. Topology and traffic flow processing......................7 3.1. Topology and traffic flow processing......................7
3.2. JSON code.................................................8 3.2. JSON code.................................................8
skipping to change at page 2, line 48 skipping to change at page 3, line 4
Table of Contents Table of Contents
1. Introduction...................................................4 1. Introduction...................................................4
1.1. The scope of this document................................4 1.1. The scope of this document................................4
1.2. Assumptions...............................................5 1.2. Assumptions...............................................5
2. Terminology....................................................6 2. Terminology....................................................6
3. Conventions used in this document..............................7 3. Conventions used in this document..............................7
3.1. Topology and traffic flow processing......................7 3.1. Topology and traffic flow processing......................7
3.2. JSON code.................................................8 3.2. JSON code.................................................8
4. Scenarios Description..........................................9 4. Scenarios Description..........................................9
4.1. Reference Network.........................................9 4.1. Reference Network.........................................9
4.1.1. Single-Domain Scenario..............................12 4.2. Topology Abstractions....................................13
4.2. Topology Abstractions....................................12 4.3. Service Configuration....................................15
4.3. Service Configuration....................................14 4.3.1. ODU Transit.........................................16
4.3.1. ODU Transit.........................................15 4.3.2. EPL over ODU........................................17
4.3.2. EPL over ODU........................................16 4.3.3. Other OTN Clients Services..........................18
4.3.3. Other OTN Clients Services..........................17 4.3.4. EVPL over ODU.......................................19
4.3.4. EVPL over ODU.......................................18 4.4. Multi-function Access Links..............................20
4.3.5. EVPLAN and EVPTree Services.........................19 4.5. Protection and Restoration Configuration.................21
4.3.6. Dynamic Service Configuration.......................20 4.5.1. Linear Protection (end-to-end)......................21
4.4. Multi-function Access Links..............................21
4.5. Protection and Restoration Configuration.................22
4.5.1. Linear Protection (end-to-end)......................22
4.5.2. Segmented Protection................................23 4.5.2. Segmented Protection................................23
4.5.3. End-to-End Dynamic restoration......................24 4.6. Notification.............................................23
4.5.4. Segmented Dynamic Restoration.......................25 4.7. Path Computation with Constraint.........................24
4.6. Service Modification and Deletion........................25 5. YANG Model Analysis...........................................24
4.7. Notification.............................................25 5.1. YANG Models for Topology Abstraction.....................25
4.8. Path Computation with Constraint.........................26 5.1.1. Domain 1 Black Topology Abstraction.................26
5. YANG Model Analysis...........................................27
5.1. YANG Models for Topology Abstraction.....................27
5.1.1. Domain 1 Black Topology Abstraction.................28
5.1.2. Domain 2 Black Topology Abstraction.................30 5.1.2. Domain 2 Black Topology Abstraction.................30
5.1.3. Domain 3 White Topology Abstraction.................30 5.1.3. Domain 3 White Topology Abstraction.................31
5.1.4. Multi-domain Topology Stitching.....................31 5.1.4. Multi-domain Topology Merging.......................31
5.1.5. Access Links........................................33 5.2. YANG Models for Service Configuration....................33
5.2. YANG Models for Service Configuration....................35 5.2.1. ODU Transit Service.................................36
5.2.1. ODU Transit Service.................................37 5.2.1.1. Single Domain Example..........................38
5.2.1.1. Single Domain Example..........................39 5.2.2. EPL over ODU Service................................38
5.2.2. EPL over ODU Service................................40 5.2.2.1. Single Domain Example..........................40
5.2.3. Other OTN Client Services...........................42 5.2.3. Other OTN Client Services...........................41
5.2.3.1. Single Domain Example..........................42
5.2.4. EVPL over ODU Service...............................42 5.2.4. EVPL over ODU Service...............................42
5.3. YANG Models for Protection Configuration.................43 5.3. YANG Models for Protection Configuration.................44
5.3.1. Linear Protection (end-to-end)......................43 5.3.1. Linear Protection (end-to-end)......................44
5.3.2. Segmented Protection................................43 5.4. Notifications............................................44
6. Security Considerations.......................................43 5.5. Path Computation with Constraints........................44
7. IANA Considerations...........................................44 6. Security Considerations.......................................44
8. References....................................................44 7. IANA Considerations...........................................45
8.1. Normative References.....................................44 8. References....................................................45
8.2. Informative References...................................45 8.1. Normative References.....................................45
9. Acknowledgments...............................................46 8.2. Informative References...................................46
Appendix A. Validating a JSON fragment against a YANG Model...47 9. Acknowledgments...............................................47
A.1. Manipulation of JSON fragments..........................47 Appendix A. Validating a JSON fragment against a YANG Model...49
A.2. Comments in JSON fragments..............................48 A.1. Manipulation of JSON fragments..........................49
A.3. Validation of JSON fragments: DSDL-based approach.......48 A.2. Comments in JSON fragments..............................50
A.3. Validation of JSON fragments: DSDL-based approach.......50
A.4. Validation of JSON fragments: why not using a XSD-based A.4. Validation of JSON fragments: why not using a XSD-based
approach......................................................49 approach......................................................51
Appendix B. Detailed JSON Examples............................50
B.1. JSON Examples for Topology Abstractions.................50 Appendix B. Detailed JSON Examples............................52
B.1.1. JSON Code: mpi1-otn-topology.json.................50 B.1. JSON Examples for Topology Abstractions.................52
B.2. JSON Examples for Service Configuration.................66 B.1.1. JSON Code: mpi1-otn-topology.json.................52
B.2.1. JSON Code: mpi1-odu2-service-config.json..........66 B.2. JSON Examples for Service Configuration.................68
B.2.2. JSON Code: mpi1-odu2-tunnel-config.json...........70 B.2.1. JSON Code: mpi1-odu2-service-config.json..........68
B.2.3. JSON Code: mpi1-epl-service-config.json...........70 B.2.2. JSON Code: mpi1-odu2-tunnel-config.json...........72
B.2.3. JSON Code: mpi1-epl-service-config.json...........72
1. Introduction 1. Introduction
Transport of packet services are critical for a wide-range of Transport of packet services are critical for a wide-range of
applications and services, including data center and LAN applications and services, including data center and LAN
interconnects, Internet service backhauling mobile backhaul and interconnects, Internet service backhauling mobile backhaul and
enterprise Carrier Ethernet Services. These services are typically enterprise Carrier Ethernet services. These services are typically
setup using stovepipe NMS and EMS platforms, often requiring setup using stovepipe NMS and EMS platforms, often requiring
propriety management platforms and legacy management interfaces. A propriety management platforms and legacy management interfaces. A
clear goal of operators will be to automate the setup of transport clear goal of operators is to automate the setup of transport
services across multiple transport technology domains. services across multiple transport technology domains.
A common open interface (API) to each domain controller and or A common open interface (API) to each domain controller and or
management system is pre-requisite for network operators to control management system is pre-requisite for network operators to control
multi-vendor and multi-domain networks and also enable service multi-vendor and multi-domain networks and also enable service
provisioning coordination/automation. This can be achieved by using provisioning coordination/automation. This can be achieved by using
standardized YANG models, used together with an appropriate protocol standardized YANG models, used together with an appropriate protocol
(e.g., [RFC8040]). (e.g., RESTCONF [RFC8040]).
This document analyses the applicability of the YANG models being This document analyses the applicability of the YANG models being
defined by IETF (TEAS and CCAMP WGs in particular) to support OTN defined by IETF (Traffic Engineering Architecture and Signaling
single and multi-domain scenarios. (TEAS) and Common Control and Measurement Plane (CCAMP) WGs in
particular) to support Optical Transport Networks (OTN) single and
multi-domain scenarios.
1.1. The scope of this document 1.1. The scope of this document
This document assumes a reference architecture, including interfaces, This document assumes a reference architecture, including
based on the Abstraction and Control of Traffic-Engineered Networks interfaces, based on the Abstraction and Control of Traffic-
(ACTN), defined in [RFC8453]. Engineered Networks (ACTN), defined in [RFC8453].
The focus of this document is on the MPI (interface between the Multi The focus of this document is on the MPI (interface between the
Domain Service Coordinator (MDSC) and a Physical Network Controller Multi Domain Service Coordinator (MDSC) and a Physical Network
(PNC), controlling a transport network domain). Controller (PNC), controlling a transport network domain).
It is worth noting that the same MPI analyzed in this document could It is worth noting that the same MPI analyzed in this document could
be used between hierarchical MDSC controllers, as shown in Figure 4 be used between hierarchical MDSC controllers, as shown in Figure 4
of [RFC8453]. of [RFC8453].
Detailed analysis of the CMI (interface between the Customer Network Detailed analysis of the CMI (interface between the Customer Network
Controller (CNC) and the MDSC) as well as of the interface between Controller (CNC) and the MDSC) as well as of the interface between
service and network orchestrators are outside the scope of this service and network orchestrators are outside the scope of this
document. However, some considerations and assumptions about the document. However, some considerations and assumptions about the
information could be described when needed. information are described when needed.
The relationship between the current IETF YANG models and the type of The relationship between the current IETF YANG models and the type
ACTN interfaces can be found in [ACTN-YANG]. Therefore, it considers of ACTN interfaces can be found in [ACTN-YANG]. Therefore, it
the TE Topology YANG model defined in [TE-TOPO], with the OTN considers the TE Topology YANG model defined in [TE-TOPO], with the
Topology augmentation defined in [OTN-TOPO] and the TE Tunnel YANG OTN Topology augmentation defined in [OTN-TOPO] and the TE Tunnel
model defined in [TE-TUNNEL], with the OTN Tunnel augmentation YANG model defined in [TE-TUNNEL], with the OTN Tunnel augmentation
defined in [OTN-TUNNEL]. defined in [OTN-TUNNEL]. It also considers the Ethernet Client
Topology augmentation defined in [CLIENT-TOPO] as well as the Client
Signal YANG models defined in [CLIENT-SIGNAL] for both Transparent
and Ethernet clients.
The ONF Technical Recommendations for Functional Requirements for the The ONF Technical Recommendations for Functional Requirements for
transport API in [ONF TR-527] and the ONF transport API multi-domain the transport API in [ONF TR-527] and the ONF transport API multi-
examples in [ONF GitHub] have been considered as input for defining domain examples in [ONF GitHub] have been considered as input for
the reference scenarios analyzed in this document. defining the reference scenarios analyzed in this document.
1.2. Assumptions 1.2. Assumptions
This document is making the following assumptions, still to be This document is making the following assumptions:
validated with TEAS WG:
1. The MDSC can request, at the MPI, a PNC to setup a Transit Tunnel 1. The MDSC can request, at the MPI, a PNC to setup a Transit Tunnel
Segment using the TE Tunnel YANG model: in this case, since the Segment using the TE Tunnel YANG model: in this case, since the
endpoints of the E2E Tunnel are outside the domain controlled by endpoints of the E2E Tunnel are outside the domain controlled by
that PNC, the MDSC would not specify any source or destination TTP that PNC, the MDSC would not specify any source or destination TE
(i.e., it would leave the source, destination, src-tp-id and dst- Tunnel Termination Point (TTP), i.e., it would leave empty the
tp-id attributes empty) for the tunnel and it would use the source, destination, src-tp-id and dst-tp-id attributes of the TE
explicit-route-object/route-object-include-exclude list to specify tunnel instance, and it would use the explicit-route-object (ERO)
the ingress and egress links for each path of the Transit Tunnel or route-object-include-exclude list to specify the ingress and
Segment. egress links for each path of the Transit Tunnel Segment.
2. Each PNC provides to the MDSC, at the MPI, the list of available 2. Each PNC provides to the MDSC, at the MPI, the list of available
timeslots on the inter-domain links using the TE Topology YANG timeslots on the inter-domain links using the TE Topology YANG
model and OTN Topology augmentation. The TE Topology YANG model in model and OTN Topology augmentation. The TE Topology YANG model
[TE-TOPO] is being updated to report the label set information. in [TE-TOPO] is being updated to report the label set
information.
This document is also making the following assumptions, still to be See section 1.7 of [TE-TUTORIAL] for more details.
validated with CCAMP WG:
1. The topology information for the Ethernet access links is modelled This document has made the following assumptions:
using the YANG model defined in [CLIENT-TOPO].
2. The service information for Ethernet and other OTN client layer 1. The topology information for the Ethernet Client access links is
services are modelled using the YANG model defined in [Client- modelled using the YANG model defined in [CLIENT-TOPO];
Signal].
2. The topology information for the OTN and Transparent Client
access links is modelled using the YANG model defined in [OTN-
TOPO];
3. The mapping information for Ethernet and Transparent Client
signals are modelled using the YANG model defined in [CLIENT-
SIGNAL].
Finally, the Network Elements (NEs) described in the scenarios used Finally, the Network Elements (NEs) described in the scenarios used
in document are using ODU switching. It is assumed that the ODU links in the document are using ODU switching. It is assumed that the ODU
are pre-configured and using mechanisms such as WDM wavelength, which links are pre-configured and using mechanisms such as WDM
are outside the scope of this document. wavelength, which are outside the scope of this document.
2. Terminology 2. Terminology
Domain: defined as a collection of network elements within a common Domain: A domain as defined by [RFC4655] is "any collection of
realm of address space or path computation responsibility [RFC5151] network elements within a common sphere of address management or
path computation responsibility". Specifically, within this
document we mean a part of an operator's network that is under
common management (i.e., under shared operational management using
the same instances of a tool and the same policies). Network
elements will often be grouped into domains based on technology
types, vendor profiles, and geographic proximity.
E-LINE: Ethernet Line E-LINE: Ethernet Line
EPL: Ethernet Private Line EPL: Ethernet Private Line
EVPL: Ethernet Virtual Private Line EVPL: Ethernet Virtual Private Line
OTN: Optical Transport Network OTN: Optical Transport Network
Service: A service in the context of this document can be considered Service: A service in the context of this document can be considered
as some form of connectivity between customer sites across the as some form of connectivity between customer sites across the
network operator's network [RFC8309] network operator's network [RFC8309].
Service Model: As described in [RFC8309] it describes a service and Service Model: As described in [RFC8309] it describes a service and
the parameters of the service in a portable way that can be used the parameters of the service in a portable way that can be used
uniformly and independent of the equipment and operating environment. uniformly and independent of the equipment and operating
environment.
UNI: User Network Interface UNI: User Network Interface
MDSC: Multi-Domain Service Coordinator MDSC: Multi-Domain Service Coordinator
CNC: Customer Network Controller CNC: Customer Network Controller
PNC: Provisioning Network Controller PNC: Provisioning Network Controller
MAC Bridging: Virtual LANs (VLANs) on IEEE 802.3 Ethernet network
3. Conventions used in this document 3. Conventions used in this document
3.1. Topology and traffic flow processing 3.1. Topology and traffic flow processing
The traffic flow between different nodes is specified as an ordered The traffic flow between different nodes is specified as an ordered
list of nodes, separated with commas, indicating within the brackets list of nodes, separated with commas, indicating within the brackets
the processing within each node: the processing within each node:
<node> (<processing>){, <node> (<processing>)} <node> [<processing>]{, <node> [<processing>]}
The order represents the order of traffic flow being forwarded The order represents the order of traffic flow being forwarded
through the network. through the network.
The processing can be either an adaptation of a client layer into a The processing can be just switching at a given layer
server layer "(client -> server)" or switching at a given layer "[(switching)]" or also having an adaptation of a client layer into
"([switching])". Multi-layer switching is indicated by two layer a server layer "[(client) -> server]" or [client -> (server)],
switching with client/server adaptation: "([client] -> [server])". depending on whether the node is switching in the client or in the
server layer.
For example, the following traffic flow: For example, the following traffic flow:
R1 ([PKT] -> ODU2), S3 ([ODU2]), S5 ([ODU2]), S6 ([ODU2]), R1 [(PKT) -> ODU2], S3 [(ODU2)], S5 [(ODU2)], S6 [(ODU2)],
R3 (ODU2 -> [PKT]) R3 [ODU2 -> (PKT)]
Node R1 is switching at the packet (PKT) layer and mapping packets Node R1 is switching at the packet (PKT) layer and mapping packets
into an ODU2 before transmission to node S3. Nodes S3, S5 and S6 are into an ODU2 before transmission to node S3. Nodes S3, S5 and S6 are
switching at the ODU2 layer: S3 sends the ODU2 traffic to S5 which switching at the ODU2 layer: S3 sends the ODU2 traffic to S5 which
then sends it to S6 which finally sends to R3. Node R3 terminates the then sends it to S6 which finally sends to R3. Node R3 terminates
ODU2 from S6 before switching at the packet (PKT) layer. the ODU2 from S6 before switching at the packet (PKT) layer.
The paths of working and protection transport entities are specified The paths of working and protection transport entities are specified
as an ordered list of nodes, separated with commas: as an ordered list of nodes, separated with commas:
<node> {, <node>} <node> {, <node>}
The order represents the order of traffic flow being forwarded The order represents the order of traffic flow being forwarded
through the network in the forward direction. In case of through the network in the forward direction. In the case of
bidirectional paths, the forward and backward directions are selected bidirectional paths, the forward and backward directions are
arbitrarily, but the convention is consistent between selected arbitrarily, but the convention is consistent between
working/protection path pairs as well as across multiple domains. working/protection path pairs, as well as across multiple domains.
3.2. JSON code 3.2. JSON code
This document provides some detailed JSON code examples to describe This document provides some detailed JSON code examples to describe
how the YANG models being developed by IETF (TEAS and CCAMP WG in how the YANG models being developed by the IETF (TEAS and CCAMP WG
particular) can be used. in particular) may be used. The scenario examples are provided using
JSON to facilitate readability.
The examples are provided using JSON because JSON code is easier for
humans to read and write.
Different objects need to have an identifier. The convention used to Different objects need to have an identifier. The convention used to
create mnemonic identifiers is to use the object name (e.g., S3 for create mnemonic identifiers is to use the object name (e.g., S3 for
node S3), followed by its type (e.g., NODE), separated by an "-", node S3), followed by its type (e.g., NODE), separated by an "-",
followed by "-ID". For example, the mnemonic identifier for node S3 followed by "-ID". For example, the mnemonic identifier for node S3
would be S3-NODE-ID. would be S3-NODE-ID.
JSON language does not support the insertion of comments that have The JSON language does not support the insertion of comments that
been instead found to be useful when writing the examples. This have been instead found to be useful when writing the examples. This
document will insert comments into the JSON code as JSON name/value document will insert comments into the JSON code as JSON name/value
pair with the JSON name string starting with the "//" characters. For pair with the JSON name string starting with the "//" characters.
example, when describing the example of a TE Topology instance For example, when describing the example of a TE Topology instance
representing the ODU Abstract Topology exposed by the Transport PNC, representing the ODU Abstract Topology exposed by the Transport PNC,
the following comment has been added to the JSON code: the following comment has been added to the JSON code:
"// comment": "ODU Abstract Topology @ MPI", "// comment": "ODU Abstract Topology @ MPI",
The JSON code examples provided in this document have been validated The JSON code examples provided in this document have been validated
against the YANG models following the validation process described in against the YANG models following the validation process described
Appendix A, which would not consider the comments. in Appendix A, which would not consider the comments.
In order to have successful validation of the examples, some In order to have successful validation of the examples, some
numbering scheme has been defined to assign identifiers to the numbering scheme has been defined to assign identifiers to the
different entities which would pass the syntax checks. In that case, different entities which would pass the syntax checks. In that case,
to simplify the reading, another JSON name/value pair formatted as a to simplify the reading, another JSON name/value pair formatted as a
comment and using the mnemonic identifiers is also provided. For comment and using the mnemonic identifiers is also provided. For
example, the identifier of node S3 (S3-NODE-ID) has been assumed to example, the identifier of node S3 (S3-NODE-ID) has been assumed to
be "10.0.0.3" and would be shown in the JSON code example using the be "10.0.0.3" and would be shown in the JSON code example using the
two JSON name/value pair: two JSON name/value pair:
"// te-node-id": "S3-NODE-ID", "// te-node-id": "S3-NODE-ID",
"te-node-id": "10.0.0.3", "te-node-id": "10.0.0.3",
The first JSON name/value pair will be automatically removed in the The first JSON name/value pair will be automatically removed in the
first step of the validation process while the second JSON name/value first step of the validation process while the second JSON
pair will be validated against the YANG model definitions. name/value pair will be validated against the YANG model
definitions.
4. Scenarios Description 4. Scenarios Description
4.1. Reference Network 4.1. Reference Network
The physical topology of the reference network is shown in Figure 1. The physical topology of the reference network is shown in Figure 1.
It represents an OTN network composed of three transport network It represents an OTN network composed of three transport network
domains providing transport services to an IP customer network domains which provide transport connectivity services to an IP
through eight access links: customer network through eight access links:
........................ ........................
.......... : : ......... : :
: : Network domain 1 : ............. : : Network domain 1 : .............
Customer: : : : : Customer: : : : :
domain : : S1 -------+ : : Network : domain : : S1 -------+ : : Network :
: : / \ : : domain 3 : .......... : : / \ : : domain 3 : ..........
R1 ------- S3 ----- S4 \ : : : : R1 ------- S3 ----- S4 \ : : : :
: : \ \ S2 --------+ : :Customer : : \ \ S2 --------+ : :Customer
: : \ \ | : : \ : : domain : : \ \ | : : \ : : domain
: : S5 \ | : : \ : : : : S5 \ | : : \ : :
R2 ------+ / \ \ | : : S31 --------- R7 R2 ------+ / \ \ | : : S31 --------- R5
: : \ / \ \ | : : / \ : : : : \ / \ \ | : : / \ : :
: : S6 ---- S7 ---- S8 ------ S32 S33 ------ R8 R3 ------- S6 ---- S7 ---- S8 ------ S32 S33 ------ R6
: : / | | : : / \ / : :....... : : / | | : : / \ / : :.......
R3 ------+ | | : :/ S34 : : R4 ------+ | | : :/ S34 : :
: :..........|.......|...: / / : : : :..........|.......|...: / / : :
........: | | /:.../.......: : ........: | | /:.../.......: :
| | / / : | | / / :
...........|.......|..../..../... : ...........|.......|..../..../... :
: | | / / : .............. : | | / / : ..............
: Network | | / / : : : Network | | / / : :
: domain 2 | | / / : :Customer : domain 2 | | / / : :Customer
: S11 ---- S12 / : : domain : S11 ---- S12 / : : domain
: / | \ / : : : / | \ / : :
: S13 S14 | S15 ------------- R4 : S13 S14 | S15 ------------- R7
: | \ / \ | \ : : : | \ / \ | \ : :
: | S16 \ | \ : : : | S16 \ | \ : :
: | / S17 -- S18 --------- R5 : | / S17 -- S18 --------- R8
: | / \ / : : : | / \ / : :
: S19 ---- S20 ---- S21 ------------ R6 : S19 ---- S20 ---- S21 ------------ R9
: : : : : :
:...............................: :............. :...............................: :.............
Figure 1 - Reference network Figure 1 - Reference network
This document assumes that all the transport network switching nodes This document assumes that all the transport network switching nodes
Si are OTN switching nodes capable of switching in the electrical Si are capable of switching in the electrical domain (ODU switching)
domain (ODU switching) and that all the Si-Sj OTN links within the and that all the Si-Sj OTN links within the transport network
transport network (intra-domain or inter-domain) are 100G links while (intra-domain or inter-domain) are 100G links while the access Ri-Sj
the access Ri-Sj links are 10G links. Different technologies can be links are 10G links.
used at the access links (e.g., Ethernet, STM-n, OTN).
It is also assumed that, within the transport network, the It is also assumed that, within the transport network, the
physical/optical interconnections supporting the Si-Sj OTN links (up physical/optical interconnections supporting the Si-Sj OTN links (up
to the OTU4 trail), are pre-configured using mechanisms which are to the OTU4 trail), are pre-configured using mechanisms which are
outside the scope of this document and are not exposed at the MPIs to outside the scope of this document and are not exposed at the MPIs
the MDSC. to the MDSC.
The transport domain control architecture, shown in Figure 2, follows Different technologies can be used on the access links (e.g.,
the ACTN architecture and framework document [RFC8453], and Ethernet, STM-N and OTU). Section 4.3 provides more details about
the different assumptions on the access links for different services
types and section 4.4 describes the control of access links which
can support different technology configuration (e.g., STM-64, 10GE
or OTU2) depending on the type of service being configured (multi-
function access links).
The transport domain control architecture, shown in Figure 2,
follows the ACTN architecture and framework document [RFC8453], and
functional components: functional components:
-------------- --------------
| | | |
| CNC | | CNC |
| | | |
-------------- --------------
| |
....................|....................... CMI ....................|....................... CMI
| |
skipping to change at page 11, line 47 skipping to change at page 12, line 40
( ) ( Domain 2 ) | ( ) ( Domain 2 ) |
( ) ( ) ----- ( ) ( ) -----
( Network ) ( ) ( ) ( Network ) ( ) ( )
( Domain 1 ) ----- ( ) ( Domain 1 ) ----- ( )
( ) ( Network ) ( ) ( Network )
( ) ( Domain 3 ) ( ) ( Domain 3 )
----- ( ) ----- ( )
( ) ( )
----- -----
Figure 2 - Controlling Hierarchy Figure 2 - Controlling Hierarchies
The ACTN framework facilitates the detachment of the network and The ACTN framework facilitates the detachment of the network and
service control from the underlying technology and helps the customer service control from the underlying technology. It helps the
express the network as desired by business needs. Therefore, care customer define the network as desired by business needs. Therefore,
must be taken to keep a minimal dependency on the CMI (or no care must be taken to keep a minimal level of dependency on the CMI
dependency at all) with respect to the network domain technologies. (or no dependency at all) with respect to the network domain
The MPI instead requires some specialization according to the domain technologies. The MPI instead requires some specialization according
technology. to the domain technology.
This document assumes that the CNC controls the customer IP network
and requests, at the CMI, transport connectivity between IP routers.
The MDSC coordinates, via three MPIs, the control of a multi-domain
transport network through three PNCs.
The control interfaces within the scope of this document are the The control interfaces within the scope of this document are the
three MPIs, while the control interface(s) between the CNC and the IP three MPIs shown in Figure 2.
routers is outside the scope of this document. It is also assumed
that the CMI allows the CNC to provide all the information that is
required by the MDSC to properly configure the transport connectivity
requested by the customer.
In case the CNC requests transport connectivity between IP routers It is worth noting that the split of functionality at the MPI in the
attached to different transport domains (e.g., between R1 and R5), ACTN architecture between the MDSC and the PNCs is
the MDSC coordinates the setup of a multi-domain end-to-end OTN equivalent/analogous to the split of functionality which is assumed
connection across multiple PNCs (e.g., PNC1, PNC2 and PNC3 in in for the ONF T-API interface when used between a multi-domain
Figure 2) as well as the configuration of the client signal mapping controller and domain controllers, as described in the ONF T-API
at the PNCs controlling the edge domains (e.g., PNC1 and PNC2 in multi-domain use cases [ONF TR-527], as well as at the MEF PRESTO
Figure 2). interface between the Service Orchestration Functionality (SOF) and
the Infrastructure Control and Management (ICM) in the MEF LSO
Architecture [MEF 55].
4.1.1. Single-Domain Scenario This document does not make any assumption about the control
architecture of the customer IP network: in line with [RFC8453], the
CNC is just a functional component within the customer control
architecture which is capable of requesting, at the CMI, transport
connectivity between IP routers, when needed.
In case the CNC requests transport connectivity between IP routers The CNC can request transport connectivity services between IP
attached to the same transport domain (e.g., between R1 and R3 in routers which can be attached to different transport domains (e.g.,
Figure 1), the MDSC can request the PNC controlling that domain between R1 and R8 in Figure 1) or to the same transport domain
(e.g., PNC1 in Figure 2) to setup an intra-domain end-to-end OTN (e.g., between R1 and R3 in Figure 1). Since the CNC is not aware of
connection and configure the client signal mapping. the transport network controlling hierarchy, the mechanisms used by
the CNC to request, at the CMI, transport connectivity services are
independent on whether the service request is single-domain or
multi-domain.
Alternatively, the MDSC can just configure the client signal mapping It is assumed that the CMI allows the CNC to provide all the
and let the PNC take decisions about how to implement the service information that is required by the MDSC to understand the
(e.g., setting up the intra-domain end-to-end OTN connection). connectivity service request and to decide the network
configurations to be requested, at the MPIs, to its underlying PNCs
to support the requested connectivity service.
When a single-domain service is requested by the CNC at the CMI
(e.g., between R1 and R3 in Figure 1), the MDSC can follow the same
procedures, described above for the multi-domain service, and decide
the network configuration to request only at the MPI of the PNC
controlling that domain (e.g., MPI1 of PNC1 in Figure 2).
4.2. Topology Abstractions 4.2. Topology Abstractions
Abstraction provides a selective method for representing connectivity Abstraction provides a selective method for representing
information within a domain. There are multiple methods to abstract a connectivity information within a domain. There are multiple methods
network topology. This document assumes the abstraction method to abstract a network topology. This document assumes the
defined in [RFC7926]: abstraction method defined in [RFC7926]:
"Abstraction is the process of applying the policy to the available "Abstraction is the process of applying the policy to the
TE information within a domain, to produce selective information available TE information within a domain, to produce selective
that represents the potential ability to connect across the domain. information that represents the potential ability to connect
Thus, abstraction does not necessarily offer all possible across the domain. Thus, abstraction does not necessarily offer
connectivity options, but presents a general view of potential all possible connectivity options, but presents a general view of
connectivity according to the policies that determine how the potential connectivity according to the policies that determine
domain's administrator wants to allow the domain resources to be how the domain's administrator wants to allow the domain resources
used." to be used."
[RFC8453] Provides the context of topology abstraction in the ACTN [RFC8453] Provides the context of topology abstraction in the ACTN
architecture and discusses a few alternatives for the abstraction architecture and discusses a few alternatives for the abstraction
methods for both packet and optical networks. This is an important methods for both packet and optical networks. This is an important
consideration since the choice of the abstraction method impacts consideration since the choice of the abstraction method impacts
protocol design and the information it carries. According to protocol design and the information it carries. According to
[RFC8453], there are three types of topology: [RFC8453], there are three types of topology:
o White topology: This is a case where the PNC provides the actual o White topology: This is a case where the PNC provides the actual
network topology to the MDSC without any hiding or filtering. In network topology to the MDSC without any hiding or filtering. In
skipping to change at page 13, line 44 skipping to change at page 14, line 44
abstraction of TE tunnels for all pairs of border nodes. We may abstraction of TE tunnels for all pairs of border nodes. We may
further differentiate from a perspective of how to abstract further differentiate from a perspective of how to abstract
internal TE resources between the pairs of border nodes: internal TE resources between the pairs of border nodes:
- Grey topology type A: border nodes with TE links between them - Grey topology type A: border nodes with TE links between them
in a full mesh fashion; in a full mesh fashion;
- Grey topology type B: border nodes with some internal - Grey topology type B: border nodes with some internal
abstracted nodes and abstracted links. abstracted nodes and abstracted links.
Each PNC should provide the MDSC with a topology abstraction of the Each PNC should provide the MDSC with a network topology
domain's network topology. abstractions hiding the internal details of the physical domain
network topology controlled by the PNC and this abstraction is
Each PNC provides topology abstraction of its own domain topology independent of the abstractions provided by other PNCs. Therefore it
independently from each other, and therefore it is possible that is possible that different PNCs provide different types of topology
different PNCs provide different types of topology abstractions. abstractions and each MPI operates on the abstract topology
regardless of, and independently from, the type of abstraction
The MPI operates on the abstract topology regardless of, and provided by the PNC.
independently from, the type of abstraction provided by the PNC.
To analyze how the MPI operates on abstract topologies independently
from the topology abstraction provided by each PNC and, therefore,
that different PNCs can provide different topology abstractions, that
the following examples are assumed:
o PNC1 provides a black topology abstraction which exposes at MPI1 a To analyze how the MDSC can operate on abstract topologies
single virtual node (representing the whole network domain 1). independently from the topology abstraction provided by each PNC
and, therefore, that different PNCs can provide different topology
abstractions, that the following examples are assumed:
o PNC2 provides a black topology abstraction which exposes at MPI2 a o PNC1 and PNC2 provide black topology abstractions which expose at
single virtual node (representing the whole network domain 2). MPI1, and MPI2 respectively, a single virtual node (representing
the whole network domain 1, and domain 2 respectively).
o PNC3 provides a white topology abstraction which exposes at MPI3 o PNC3 provides a white topology abstraction which exposes at MPI3
all the physical nodes and links within network domain 3. all the physical nodes and links within network domain 3.
The MDSC should be capable of stitching together each abstracted The MDSC should be capable of stitching together the abstracted
topology to build its own view of the multi-domain network topology. topologies provided by each PNC to build its own view of the
The process may require suitable oversight, including administrative multi-domain network topology. The process may require suitable
configuration and trust models, but this is out of scope for this oversight, including administrative configuration and trust models,
document. a method of how to achieve this is out of scope for this document.
The MDSC can also provide topology abstraction of its own view of the The MDSC can also provide topology abstraction of its own view of
multi-domain network topology at its CMIs depending on the customers' the multi-domain network topology at its CMIs depending on the
needs: it can provide different types of topology abstractions at customers' needs: it can provide different types of topology
different CMIs. abstractions at different CMIs. Analyzing the topology abstractions
provided by the MDSC to its CMIs is outside the scope of this
document.
4.3. Service Configuration 4.3. Service Configuration
In the following scenarios, it is assumed that the CNC is capable of In the following scenarios, it is assumed that the CNC is capable of
requesting service connectivity from the MDSC to support IP routers requesting service connectivity from the MDSC to support IP routers
connectivity. connectivity.
The type of services could depend on the type of physical links (e.g. The type of services could depend on the type of physical links
OTN link, ETH link or SDH link) between the routers and transport (e.g. OTN link, ETH link or SDH link) between the routers and
network. transport network.
The control of different adaptations inside IP routers, Ri (PKT -> The control of different adaptations inside IP routers, Ri (PKT ->
foo) and Rj (foo -> PKT), are assumed to be performed by means that foo) and Rj (foo -> PKT), are assumed to be performed by means that
are not under the control of, and not visible to, the MDSC nor to the are not under the control of, and not visible to, the MDSC nor to
PNCs. Therefore, these mechanisms are outside the scope of this the PNCs. Therefore, these mechanisms are outside the scope of this
document.
It is just assumed that the CNC is capable of requesting the proper
configuration of the different adaptation functions inside the
customer's IP routers, by means which are outside the scope of this
document. document.
4.3.1. ODU Transit 4.3.1. ODU Transit
The physical links interconnecting the IP routers and the transport The physical links interconnecting the IP routers and the transport
network can be 10G OTN links. In this case, it is assumed that the network can be 10G OTN links.
physical/optical interconnections below the ODU layer (up to the OTU2
trail) are pre-configured using mechanisms which are outside the
scope of this document and not exposed at the MPIs between the PNCs
and the MDSC. For simplicity of the description, it is also assumed
that these interfaces are not channelized (i.e., they can only
support one ODU2).
To setup a 10Gb IP link between R1 and R5, an ODU2 end-to-end In this case, it is assumed that the physical/optical
connection needs be created in the data plane between R1 and R5, interconnections below the ODU layer (up to the OTU2 trail) are
through transport nodes S3, S1, S2, S31, S33, S34, S15 and S18 which pre-configured using mechanisms which are outside the scope of this
belong to different PNC domains (multi-domain service request): document and not exposed at the MPIs between the PNCs and the MDSC.
R1 ([PKT] -> ODU2), S3 ([ODU2]), S1 ([ODU2]), S2 ([ODU2]), For simplicity of the description, it is also assumed that these
S31 ([ODU2]), S33 ([ODU2]), S34 ([ODU2]), interfaces are not channelized (i.e., they can only support one
S15 ([ODU2]), S18 ([ODU2]), R5 (ODU2 -> [PKT]) ODU2).
It is assumed that, at the CMI, the CNC requests, using mechanisms To setup a 10Gb IP link between R1 and R8, an ODU2 end-to-end
which are outside the scope of this document, the MDSC to setup of an connection needs to be created, passing through transport nodes S3,
ODU2 transit service between the access links on S3 and S8 and that S1, S2, S31, S33, S34, S15 and S18 which belong to different PNC
the MDSC understands that it shall setup an ODU2 segment connection domains (multi-domain service request):
between the access links on S3 and S18, which belongs to different
PNC domains (multi-domain service request). R1 [(PKT) -> ODU2], S3 [(ODU2]), S1 [(ODU2]), S2 [(ODU2]),
S31 [(ODU2)], S33 [(ODU2)], S34 [(ODU2)],
S15 [(ODU2)], S18 [(ODU2)], R8 [ODU2 -> (PKT)]
The MDSC understands that it needs to establish an ODU2 transit
service between the access links on S3 and S18, which belong to
different PNC domains (multi-domain service request). It also
decides the network configurations to request, at the MPIs, to its
underlying PNCs, to coordinate the setup of a multi-domain ODU2
segment connection between the access links on S3 and S18.
To setup of a 10Gb IP link between R1 and R3, an ODU2 end-to-end To setup of a 10Gb IP link between R1 and R3, an ODU2 end-to-end
connection needs are created in the data plane between R1 and R3, connection needs to be created, passing through transport nodes S3,
through transport nodes S3, S5 and S6 which belong to the same PNC S5 and S6 which belong to the same PNC domain (single-domain service
domain (single-domain service request): request):
R1 ([PKT] -> ODU2), S3 ([ODU2]), S5 ([ODU2]), S6 ([ODU2]), R1 [(PKT) -> ODU2], S3 [(ODU2)], S5 [(ODU2)], S6 [(ODU2)],
R3 (ODU2 -> [PKT]) R3 [ODU2 -> (PKT)]
Since the CNC is not aware of the transport network controlling As described in section 4.1, the mechanisms used by the CNC at the
hierarchy, the mechanisms used by the CNC to request at the CMI the CMI are independent on whether the service request is single-domain
MDSC to setup an ODU2 transit service are independent on whether the service or multi-domain.
service request is single-domain or multi-domain.
Based on the assumption above, the MDSC understands that it shall The MDSC can understand that it needs to setup an ODU2 transit
setup an ODU2 segment connection between the access links on S3 and service between the access links on S3 and S6, which belong to the
S6, which belong to the same PNC domain (single-domain service same PNC domain (single-domain service request) and it decides the
request) and it can just pass the request at the MPI to PNC1 to setup proper network configuration to request PNC1.
a single-domain ODU2 segment connection between its access links on
S3 and S6.
4.3.2. EPL over ODU 4.3.2. EPL over ODU
The physical links interconnecting the IP routers and the transport The physical links interconnecting the IP routers and the transport
network can be Ethernet physical links. network can be 10G Ethernet physical links (10GE).
To setup a 10Gb IP link between R1 and R5, an EPL service needs to be In this case, it is assumed that the Ethernet physical interfaces
created between R1 and R5, supported by an ODU2 end-to-end connection (up to the MAC layer) are pre-configured using mechanisms which are
in the data plane between transport nodes S3 and S18, through outside the scope of this document and not exposed at the MPIs
transport nodes S1, S2, S31, S33, S34 and S15, which belong to between the PNCs and the MDSC.
different PNC domains (multi-domain service request:
R1 ([PKT] -> ETH), S3 (ETH -> [ODU2]), S1 ([ODU2]), To setup a 10Gb IP link between R1 and R8, an EPL service needs to
S2 ([ODU2]), S31 ([ODU2]), S33 ([ODU2]), S34 ([ODU2]), be created, supported by an ODU2 end-to-end connection, between
S15 ([ODU2]), S18 ([ODU2] -> ETH), R5 (ETH -> [PKT]) transport nodes S3 and S18, passing through transport nodes S1, S2,
S31, S33, S34 and S15, which belong to different PNC domains (multi-
domain service request):
Based on the assumptions described in section 4.3.1, the CNC requests R1 [(PKT) -> ETH], S3 [ETH -> (ODU2)], S1 [(ODU2)],
at the CMI the MDSC to setup an EPL service between the access links S2 [(ODU2)], S31 [(ODU2)), S33 [(ODU2)], S34 [(ODU2)],
on S3 and S8 and the MDSC understands that it shall setup an ODU2 S15 [(ODU2)], S18 [(ODU2) -> ETH], R8 [ETH -> (PKT)]
end-to-end connection between nodes S3 and S18, which belongs to
different PNC domains (multi-domain service request). The MDSC also
understands how the adaptation functions inside nodes S3 and S18
(i.e., S3 (ETH -> [ODU2]), S18 ([ODU2] -> ETH), S18 (ETH -> [ODU2])
and S3 ([ODU2] -> ETH)) should be configured.
To setup a 10Gb IP link between R1 and R3, an EPL service needs to be The MDSC understands that it needs to setup an EPL service between
created between R1 and R3, supported by an ODU2 end-to-end connection the access links on S3 and S18, which belong to different PNC
in the data plane between transport nodes S3 and S6, through the domains (multi-domain service request). It also decides the network
transport node S5, which belong to the same PNC domain (single-domain configurations to request, at the MPIs, to its underlying PNCs, to
service request): coordinate the setup of an end-to-end ODU2 connection between the
nodes S3 and S8, including the configuration of the adaptation
functions inside these edge nodes, such as S3 [ETH -> (ODU2)] and
S18 [(ODU2) -> ETH].
R1 ([PKT] -> ETH), S3 (ETH -> [ODU2]), S5 ([ODU2]), To setup a 10Gb IP link between R1 and R2, an EPL service needs to
S6 ([ODU2] -> ETH), R3 (ETH-> [PKT]) be created, supported by an ODU2 end-to-end connection between
transport nodes S3 and S6, passing through the transport node S5,
which belong to the same PNC domain (single-domain service request):
As described in section 4.3.1, the mechanisms used by the CNC at the R1 [(PKT) -> ETH], S3 [ETH -> (PKT)] S5 [(ODU2)],
S6 [(ODU2) -> ETH], R2 [ETH -> (PKT)]
As described in section 4.1, the mechanisms used by the CNC at the
CMI are independent on whether the service request is single-domain CMI are independent on whether the service request is single-domain
service or multi-domain. service or multi-domain.
Based on the assumption above, the MDSC understands that it shall Based on the assumption above, in this case, the MDSC can understand
setup an EPL service between the access links on S3 and S6, which that it needs to setup an EPL service between the access links on S3
belong to the same PNC domain (single-domain service request) and it and S6, which belong to the same PNC domain (single-domain service
can just pass the request at the MPI to PNC1 to setup a single-domain request) and it decides the proper network configuration to request
EPL service its access links on S3 and S6. In this case, PNC1 can PNC1.
take care of setting up the single-domain ODU2 end-to-end connection
between nodes S3 and S6 as well as of configuring the adaptation
functions on these edge nodes.
4.3.3. Other OTN Clients Services 4.3.3. Other OTN Clients Services
[ITU-T G.709] defines mappings of different client layers into ODU. [ITU-T G.709] defines mappings of different Transparent Client
Most of them are used to provide Private Line services over an OTN layers into ODU. Most of them are used to provide Private Line
transport network supporting a variety of types of physical access services over an OTN transport network supporting a variety of types
links (e.g., Ethernet, SDH STM-N, Fibre Channel, InfiniBand, etc.). of physical access links (e.g., Ethernet, SDH STM-N, Fibre Channel,
InfiniBand, etc.) interconnecting the IP routers and the transport
The physical links interconnecting the IP routers and the transport network.
network can be any of these types.
In order to setup a 10Gb IP link between R1 and R5 using, for example In order to setup a 10Gb IP link between R1 and R8 using, with for
SDH physical links between the IP routers and the transport network, example SDH physical links between the IP routers and the transport
an STM-64 Private Line service needs to be created between R1 and R5, network, an STM-64 Private Line service needs to be created,
supported by an ODU2 end-to-end connection in the data plane between supported by an ODU2 end-to-end connection, between transport nodes
transport nodes S3 and S18, through transport nodes S1, S2, S31, S33, S3 and S18, passing through transport nodes S1, S2, S31, S33, S34
S34 and S15, which belong to different PNC domains (multi-domain and S15, which belong to different PNC domains (multi-domain service
service request): request):
R1 ([PKT] -> STM-64), S3 (STM-64 -> [ODU2]), S1 ([ODU2]), R1 [(PKT) -> STM-64], S3 [STM-64 -> (ODU2)], S1 [(ODU2)],
S2 ([ODU2]), S31 ([ODU2]), S33 ([ODU2]), S34 ([ODU2]), S2 [(ODU2)], S31 [(ODU2)], S33 [(ODU2)], S34[(ODU2)],
S15 ([ODU2]), S18 ([ODU2] -> STM-64), R5 (STM-64 -> [PKT]) S15 [(ODU2)], S18 [(ODU2) -> STM-64], R8 [STM-64 -> (PKT)]
Based on the assumptions described in section 4.3.1, the CNC requests As already described (section 4.1) CNC provides the essential
the CMI the MDSC to setup an STM-64 Private Line service between the information to permit the MDSC to understand which type of service
access links on S3 and S8 and the MDSC understands what to do as is needed, in this case, an STM-64 Private Line service between the
described in section 4.3.2 (multi-domain service request). access links on S3 and S8, and it also decides the network
configurations, including the configuration of the adaptation
functions inside these edge nodes, such as S3 [STM-64 -> (ODU2)] and
S18 [(ODU2) -> STM-64].
To setup a 10Gb IP link between R1 and R3), an STM-64 Private Line To setup a 10Gb IP link between R1 and R3), an STM-64 Private Line
service needs to be created between R1 and R3 (single-domain service service needs to be created between R1 and R3 (single-domain service
request): request):
R1 ([PKT] -> STM-64), S3 (STM-64 -> [ODU2]), S5 ([ODU2]), R1 [(PKT) -> STM-64], S3[STM-64 -> (ODU2)], S5 [(ODU2)],
S6 ([ODU2] -> STM-64), R3 (STM-64 -> [PKT]) S6 [(ODU2) -> STM-64], R3[STM-64 -> (PKT)]
As described in section 4.3.1, the mechanisms used by the CNC at the As described in section 4.1, the mechanisms used by the CNC at the
CMI are independent on whether the service request is single-domain CMI are independent on whether the service request is single-domain
or multi-domain. service or multi-domain.
As described in section 4.3.2, the MDSC can just pass the request at Based on the assumption above, in this case, the MDSC can understand
the MPI to PNC1 to setup a single-domain STM-64 Private Line service that it needs to setup an STM-64 Private Line service between the
between it access links on S3 and S6. access links on S3 and S6, which belong to the same PNC domain
(single-domain service request) and it decides the proper network
configuration to request PNC1.
4.3.4. EVPL over ODU 4.3.4. EVPL over ODU
When the physical links interconnecting the IP routers and the When the physical links interconnecting the IP routers and the
transport network are Ethernet physical links, it is also possible transport network are Ethernet physical links, it is also possible
that different Ethernet services (e.g., EVPL) can share the same that different Ethernet services (e.g., EVPL) can share the same
physical access link using different VLANs. physical access link using different VLANs.
To setup two 1Gb IP links between R1 to R3 and between R1 and R5, two As described in section 4.3.2, it is assumed that the Ethernet
EVPL services need to be created, supported by two ODU0 end-to-end physical interfaces (up to the MAC layer) are pre-configured.
connections in the data plane respectively between transport nodes S3
and S6, through transport node S5, which belong ot the same PNC
domain (single-domain service request) and between transport nodes S3
and S18, through transport nodes S1, S2, S31, S33, S34 and S15, which
belong to different PNC domains (multi-domain service request):
R1 ([PKT] -> VLAN), S3 (VLAN -> [ODU0]), S1 ([ODU0]), To setup two 1Gb IP links between R1 to R2 and between R1 and R8,
S2 ([ODU0]), S31 ([ODU0]), S33 ([ODU0]), S34 ([ODU0]), two EVPL services need to be created, supported by two ODU0 end-to-
S15 ([ODU0]), S18 ([ODU0] -> VLAN), R5 (VLAN -> [PKT]) end connections:
R1 ([PKT] -> VLAN), S3 (VLAN -> [ODU0]), S5 ([ODU0]), R1 [(PKT) -> VLAN], S3 [VLAN -> (ODU0)], S5 [(ODU0)],
S6 ([ODU0] -> VLAN), R3 (VLAN -> [PKT]) S6 [(ODU0) -> VLAN], R2 [VLAN -> (PKT)]
R1 [(PKT) -> VLAN], S3[VLAN -> (ODU0)], S1 [(ODU0)],
S2 [(ODU0)], S31 [(ODU0)], S33 [(ODU0)], S34 [(ODU0)],
S15 [(ODU0)], S18 [(ODU0) -> VLAN], R8[VLAN -> (PKT)]
It is worth noting that the fist EVPL service is required between
access links which belong to the same PNC domain (single-domain
service request) while the second EVPL service is required between
access links which belong to different PNC domains (multi-domain
service request).
Since the two EVPL services are sharing the same Ethernet physical Since the two EVPL services are sharing the same Ethernet physical
link between R1 and S3, different VLAN IDs are associated with link between R1 and S3, different VLAN IDs are associated with
different EVPL services: for example, VLAN IDs 10 and 20 different EVPL services: for example, VLAN IDs 10 and 20
respectively. respectively.
Based on the assumptions described in section 4.3.1, the CNC requests Based on the assumptions described in section 4.3.2, the CNC
at the CMI the MDSC to setup these EVPL services and the MDSC requests at the CMI the MDSC to setup these EVPL services and the
understands what to do as described in section 4.3.2. MDSC understands the network configurations to request to the
underlying PNCs, as described in section 4.3.2.
4.3.5. EVPLAN and EVPTree Services
When the physical links interconnecting the IP routers and the
transport network are Ethernet links, multipoint Ethernet services
(e.g., EPLAN and EPTree) can also be supported. It is also possible
that multiple Ethernet services (e.g., EVPL, EVPLAN and EVPTree)
share the same physical link using different VLANs.
Note - it is assumed that EPLAN and EPTree services can be supported
by configuring EVPLAN and EVPTree with port mapping.
Since this EVPLAN/EVPTree service can share the same Ethernet
physical links between IP routers and transport nodes (e.g., with the
EVPL services described in section 4.3.4), a different VLAN ID (e.g.,
30) can be associated with this EVPLAN/EVPTree service.
In order to setup an IP subnet between R1, R2, R3 and R5, an
EVPLAN/EVPTree service needs to be created, supported by two ODUflex
end-to-end connections respectively between S3 and S6, crossing
transport node S5, and between S3 and S18, crossing transport nodes
S1, S2, S31, S33, S34 and S15 which belong to different PNC domains.
Some MAC Bridging capabilities are also required on some nodes at the
edge of the transport network: for example, Ethernet Bridging
capabilities can be configured in nodes S3 and S6:
o MAC Bridging in node S3 is needed to select, based on the MAC
Destination Address, whether received Ethernet frames should be
forwarded to R1 or to the ODUflex terminating on node S6 or to the
other ODUflex terminating on node S18;
o MAC bridging function in node S6 is needed to select, based on the
MAC Destination Address, whether received Ethernet frames should
be sent to R2 or to R3 or to the ODUflex terminating on node S3.
In order to support an EVPTree service instead of an EVPLAN,
additional configuration of the Ethernet Bridging capabilities on the
nodes at the edge of the transport network is required.
The traffic flows between R1 and R3, between R3 and R5 and between R1
and R5 can be summarized as:
R1 ([PKT] -> VLAN), S3 (VLAN -> [MAC] -> [ODUflex]),
S5 ([ODUflex]), S6 ([ODUflex] -> [MAC] -> VLAN),
R3 (VLAN -> [PKT])
R3 ([PKT] -> VLAN), S6 (VLAN -> [MAC] -> [ODUflex]),
S5 ([ODUflex]), S3 ([ODUflex] -> [MAC] -> [ODUflex]),
S1 ([ODUflex]), S2 ([ODUflex]), S31 ([ODUflex]),
S33 ([ODUflex]), S34 ([ODUflex]),
S15 ([ODUflex]), S18 ([ODUflex] -> VLAN), R5 (VLAN -> [PKT])
R1 ([PKT] -> VLAN), S3 (VLAN -> [MAC] -> [ODUflex]),
S1 ([ODUflex]), S2 ([ODUflex]), S31 ([ODUflex]),
S33 ([ODUflex]), S34 ([ODUflex]),
S15 ([ODUflex]), S18 ([ODUflex] -> VLAN), R5 (VLAN -> [PKT])
As described in section 4.3.2, it is assumed that the CNC is capable,
via the CMI, to request the setup of this EVPLAN/EVPTree service,
providing all the information that the MDSC needs to understand that
it need to request PNC1 to setup an ODUflex connection between nodes
S3 and S6 (single-domain service request) and it also needs to
coordinate the setup of a multi-domain ODUflex connection between
nodes S3 and S16 as well as the MAC bridging and the adaptation
functions on these edge nodes.
In case the CNC needs the setup of an EVPLAN/EVPTree service only
between R1, R2 and R3 (single-domain service request), it would
request the setup of this service in the same way as before and the
information provided at the CMI is sufficient for the MDSC to
understand that this is a single-domain service request.
The MDSC can then just request PNC1 to setup a single-domain
EVPLAN/EVPTree service between nodes S3 and S6. PNC1 can take care of
setting up the single-domain ODUflex end-to-end connection between
nodes S3 and S6 as well as of configuring the MAC bridging and the
adaptation functions on these edge nodes.
4.3.6. Dynamic Service Configuration
Given the service established in the previous sections, there is a
demand for an update of some service characteristics. A
straightforward approach would be terminate the current service and
replace with a new one. Another more advanced approach would be a
dynamic configuration, in which case there will be no interruption
for the connection.
An example application would be updating the SLA information for a
certain connection. For example, an ODU transit connection is set up
according to section 4.3.1, with the corresponding SLA level of 'no
protection'. After the establishment of this connection, the user
would like to enhance this service by providing a restoration after
potential failure, and a request is generated on the CMI. In this
case, after receiving the request, the MDSC would need to send an
update message to the PNC, changing the SLA parameters in TE Tunnel
model. Then the connection characteristic would be changed by PNC,
and a notification would be sent to MDSC for acknowledgement.
4.4. Multi-function Access Links 4.4. Multi-function Access Links
Some physical links interconnecting the IP routers and the transport Some physical links interconnecting the IP routers and the transport
network can be configured in different modes, e.g., as OTU2 or STM-64 network can be configured in different modes, e.g., as OTU2 trail or
or 10GE. STM-64 or 10GE physical links.
This configuration can be done a-priori by means outside the scope of This configuration can be done a-priori by means which are outside
this document. In this case, these links will appear at the MPI the scope of this document. In this case, these links will appear at
either as an ODU Link or as an STM-64 Link or as a 10GE Link the MPI as links supporting only one mode (depending on the a-priori
(depending on the a-priori configuration) and will be controlled at configuration) and will be controlled at the MPI as discussed in
the MPI as discussed in section 4.3. section 4.3: for example, a 10G multi-function access link can be
pre-configured as an OTU2 trail (section 4.3.1), a 10GE physical
link (section 4.3.2) or an STM-64 physical link (section 4.3.3).
It is also possible not to configure these links a-priori and give It is also possible not to configure these links a-priori and let
the control to the MPI to decide, based on the service configuration, the MDSC (or, in case of a single-domain service request, the PNC)
how to configure it. decide how to configure these links, based on the service
configuration.
For example, if the physical link between R1 and S3 is a multi- For example, if the physical link between R1 and S3 is a
functional access link while the physical links between R7 and S31 multi-functional access link while the physical links between R4 and
and between R5 and S18 are STM-64 and 10GE physical links S6 and between R8 and S18 are STM-64 and 10GE physical links
respectively, it is possible to configure either an STM-64 Private respectively, it is possible to configure either an STM-64 Private
Line service between R1 and R7 or an EPL service between R1 and R5. Line service between R1 and R4 or an EPL service between R1 and R8.
The traffic flow between R1 and R7 can be summarized as: The traffic flow between R1 and R4 can be summarized as:
R1 ([PKT] -> STM-64), S3 (STM-64 -> [ODU2]), S1 ([ODU2]), R1 [(PKT) -> STM-64], S3 [STM-64 -> (ODU2)], S5 [(ODU2)],
S2 ([ODU2]), S31 ([ODU2] -> STM-64), R3 (STM-64 -> [PKT]) S6 [(ODU2) -> STM-64], R4 [STM-64 -> (PKT)]
The traffic flow between R1 and R5 can be summarized as: The traffic flow between R1 and R8 can be summarized as:
R1 ([PKT] -> ETH), S3 (ETH -> [ODU2]), S1 ([ODU2]), R1 [(PKT) -> ETH], S3 [ETH -> (ODU2)], S1 [(ODU2)],
S2 ([ODU2]), S31 ([ODU2]), S33 ([ODU2]), S34 ([ODU2]), S2 [(ODU2)], S31 [(ODU2)), S33 [(ODU2)], S34 [(ODU2)],
S15 ([ODU2]), S18 ([ODU2] -> ETH), R5 (ETH -> [PKT]) S15 [(ODU2)], S18 [(ODU2) -> ETH], R8 [ETH -> (PKT)]
As described in section 4.3.2, it is assumed that the CNC is capable, The CNC is capable to request at the CMI the setup either an STM-64
via the CMI, to request the setup either an STM-64 Private Line Private Line service, between R1 and R4, or an EPL service, between
service between R1 and R7 or an EPL service between R1 and R5, R1 and R8.
providing all the information that the MDSC needs to understand that
it needs to coordinate the setup of a multi-domain ODU2 connection, The MDSC, based on the service being request, decides the network
either between nodes S3 and S31, or between nodes S3 and S18, as well configurations to request, at the MPIs, to its underlying PNCs, to
as the adaptation functions on these edge nodes, and in particular coordinate the setup of an end-to-end ODU2 connection, either
whether the multi-function access link on between R1 and S3 should between nodes S3 and S6, or between nodes S3 and S18, including the
operate as an STM-64 or as a 10GE link. configuration of the adaptation functions on these edge nodes, and
in particular whether the multi-function access link between R1 and
S3 should operate as an STM-64 or as a 10GE physical link.
4.5. Protection and Restoration Configuration 4.5. Protection and Restoration Configuration
Protection switching provides a pre-allocated survivability Protection switching provides a pre-allocated survivability
mechanism, typically provided via linear protection methods and would mechanism, typically provided via linear protection methods and
be configured to operate as 1+1 unidirectional (the most common OTN would be configured to operate as 1+1 unidirectional (the most
protection method), 1+1 bidirectional or 1:n bidirectional. This common OTN protection method), 1+1 bidirectional or 1:n
ensures fast and simple service survivability. bidirectional. This ensures fast and simple service survivability.
Restoration methods would provide the capability to reroute and Restoration methods would provide the capability to reroute and
restore connectivity traffic around network faults, without the restore connectivity traffic around network faults, without the
network penalty imposed with dedicated 1+1 protection schemes. network penalty imposed with dedicated 1+1 protection schemes.
This section describes only services which are protected with linear This section describes only services which are protected with linear
protection and with dynamic restoration. protection. The description of services using dynamic restoration is
outside the scope of this document.
The MDSC needs to be capable of coordinating different PNCs to The MDSC needs to be capable of deciding the network configuration
configure protection switching when requesting the setup of the to request different PNCs to coordinate the protection switching
protected connectivity services described in section 4.3. configuration to support protected connectivity services described
in section 4.3.
Since in these service examples, switching within the transport Since in these service examples, switching within the transport
network domain is performed only in the OTN ODU layer. Also network domain is performed only in the OTN ODU layer. It may also
protection switching within the transport network domain can only be be assumed that protection switching within the transport network
provided at the OTN ODU layer. domain is provided at the OTN ODU layer.
4.5.1. Linear Protection (end-to-end) 4.5.1. Linear Protection (end-to-end)
In order to protect any service defined in section 4.3 from failures In order to protect the connectivity services described in section
within the OTN multi-domain transport network, the MDSC should be 4.3 from failures within the OTN multi-domain transport network, the
capable of coordinating different PNCs to configure and control OTN MDSC can decide to request its underlying PNCs to configure ODU2
linear protection in the data plane between nodes S3 and node S18. linear protection between the access nodes (e.g., nodes S3 and S18
for the services setup between R1 and R8).
It is assumed that the OTN linear protection is configured to with It is assumed that the OTN linear protection is configured to with
1+1 unidirectional protection switching type, as defined in [ITU-T 1+1 unidirectional protection switching type, as defined in [ITU-T
G.808.1] and [ITU-T G.873.1], as well as in [RFC4427]. G.808.1] and [ITU-T G.873.1], as well as in [RFC4427].
In these scenarios, a working transport entity and a protection In these scenarios, a working transport entity and a protection
transport entity, as defined in [ITU-T G.808.1], (or a working LSP transport entity, as defined in [ITU-T G.808.1], (or a working LSP
and a protection LSP, as defined in [RFC4427]) should be configured and a protection LSP, as defined in [RFC4427]) should be configured
in the data plane. in the data plane.
skipping to change at page 23, line 23 skipping to change at page 22, line 27
through the same PNC domains: through the same PNC domains:
Working transport entity: S3, S1, S2, Working transport entity: S3, S1, S2,
S31, S33, S34, S31, S33, S34,
S15, S18 S15, S18
Protection transport entity: S3, S4, S8, Protection transport entity: S3, S4, S8,
S32, S32,
S12, S17, S18 S12, S17, S18
o In another case, the working and protection transport entities can o In another case, the working and protection transport entities
pass through different PNC domains: can pass through different PNC domains:
Working transport entity: S3, S5, S7, Working transport entity: S3, S5, S7,
S11, S12, S17, S18 S11, S12, S17, S18
Protection transport entity: S3, S1, S2, Protection transport entity: S3, S1, S2,
S31, S33, S34, S31, S33, S34,
S15, S18 S15, S18
The PNCs should be capable to report to the MDSC which is the active The PNCs should be capable to report to the MDSC which is the active
transport entity, as defined in [ITU-T G.808.1], in the data plane. transport entity, as defined in [ITU-T G.808.1], in the data plane.
Given the fast dynamic of protection switching operations in the data Given the fast dynamic of protection switching operations in the
plane (50ms recovery time), this reporting is not expected to be in data plane (50ms recovery time), this reporting is not expected to
real-time. be in real-time.
It is also worth noting that with unidirectional protection It is also worth noting that with unidirectional protection
switching, e.g., 1+1 unidirectional protection switching, the active switching, e.g., 1+1 unidirectional protection switching, the active
transport entity may be different in the two directions. transport entity may be different in the two directions.
4.5.2. Segmented Protection 4.5.2. Segmented Protection
To protect any service defined in section 4.3 from failures within To protect the connectivity services defined in section 4.3 from
the OTN multi-domain transport network, the MDSC should be capable of failures within the OTN multi-domain transport network, the MDSC can
requesting each PNC to configure OTN intra-domain protection when decide to request its underlying PNCs to configure ODU2 linear
requesting the setup of the ODU2 data plane connection segment. protection between the edge nodes of each domain.
If PNC1 provides linear protection, the working and protection For example, MDSC can request PNC1 to configure linear protection
transport entities could be: between its edge nodes S3 and S2:
Working transport entity: S3, S1, S2 Working transport entity: S3, S1, S2
Protection transport entity: S3, S4, S8, S2 Protection transport entity: S3, S4, S8, S2
If PNC2 provides linear protection, the working and protection MDSC can also request PNC2 to configure linear protection between
transport entities could be: its edge nodes S15 and S18:
Working transport entity: S15, S18 Working transport entity: S15, S18
Protection transport entity: S15, S12, S17, S18 Protection transport entity: S15, S12, S17, S18
If PNC3 provides linear protection, the working and protection MDSC can also request PNC3 to configure linear protection between
transport entities could be: its edge nodes S31 and S34:
Working transport entity: S31, S33, S34 Working transport entity: S31, S33, S34
Protection transport entity: S31, S32, S34 Protection transport entity: S31, S32, S34
4.5.3. End-to-End Dynamic restoration 4.6. Notification
To restore any service defined in section 4.3 from failures within
the OTN multi-domain transport network, the MDSC should be capable of
coordinating different PNCs to configure and control OTN end-to-end
dynamic Restoration in the data plane between nodes S3 and node S18.
For example, the MDSC can request the PNC1, PNC2 and PNC3 to create a
service with no-protection, MDSC set the end-to-end service with the
dynamic restoration.
Working transport entity: S3, S1, S2,
S31, S33, S34,
S15, S18
When a link failure between S1 and s2 occurred in network domain 1,
PNC1 does not restore the tunnel and send the alarm notification to
the MDSC, MDSC will perform the end-to-end restoration.
Restored transport entity: S3, S4, S8,
S12, S15, S18
4.5.4. Segmented Dynamic Restoration
To restore any service defined in section 4.3 from failures within
the OTN multi-domain transport network, the MDSC should be capable of
coordinating different PNCs to configure and control OTN segmented
dynamic Restoration in the data plane between nodes S3 and node S18.
Working transport entity: S3, S1, S2,
S31, S33, S34,
S15, S18
When a link failure between S1 and s2 occurred in network domain 1,
PNC1 will restore the tunnel and send the alarm or tunnel update
notification to the MDSC, MDSC will update the restored tunnel.
Restored transport entity: S3, S4, S8, S2
S31, S33, S34,
S15, S18
When a link failure between network domain 1 and network domain 2
occurred, PNC1 and PNC2 will send the alarm notification to the MDSC,
MDSC will update the restored tunnel.
Restored transport entity: S3, S4, S8,
S12, S15, S18
In order to improve the efficiency of recovery, the controller can
establish a recovery path in a concurrent way. When the recovery
fails in one domain or one network element, the rollback operation
should be supported.
The creation of the recovery path by the controller can use the
method of "make-before-break", in order to reduce the impact of the
recovery operation on the services.
4.6. Service Modification and Deletion
To be discussed in future versions of this document.
4.7. Notification
To realize the topology update, service update and restoration To realize the topology update, service update and restoration
function, following notification type should be supported. function, following notification type should be supported:
1. Object create 1. Object create
2. Object delete 2. Object delete
3. Object state change 3. Object state change
4. Alarm 4. Alarm
Because there are three types of topology abstraction type defined in There are three types of topology abstraction type defined in
section 4.2, the notification should also be abstracted. The PNC and section 4.2, the notification should also be abstracted. The PNC and
MDSC should coordinate together to determine the notification policy, MDSC should coordinate together to determine the notification
such as when an intra-domain alarm occurred, the PNC may not report policy, such as when an intra-domain alarm occurred, the PNC may not
the alarm but the service state change notification to the MDSC. report the alarm but the service state change notification to the
MDSC.
4.8. Path Computation with Constraint 4.7. Path Computation with Constraint
It is possible to have constraint during path computation procedure; It is possible to define constraints to be taken into account during
typical cases include IRO/XRO and so on. This information is carried path computation procedures (e.g., IRO/XRO).
in the TE Tunnel model and used when there is a request with
constraint. Consider the example in section 4.3.1. , the request can
be a Tunnel from R1 to R5 with an IRO from S2 to S31, then qualified
feedback would become:
R1 ([PKT] -> ODU2), S3 ([ODU2]), S1 ([ODU2]), S2 ([ODU2]), For example, the CNC can request, at the CMI, an ODU transit
S31 ([ODU2]), S33 ([ODU2]), S34 ([ODU2]), service, as described in section 4.3.1, between R1 and R8 with the
S15 ([ODU2]), S18 ([ODU2]), R5 (ODU2 -> [PKT]) constraint to pass through the link from S2 to S31 (IRO), such that
a qualified path could be:
If the request covers the IRO from S8 to S12, then the above path R1 [(PKT) -> ODU2], S3 [(ODU2]), S1 [(ODU2]), S2 [(ODU2]),
would not be qualified, while a possible computation result may be: S31 [(ODU2)], S33 [(ODU2)], S34 [(ODU2)],
S15 [(ODU2)], S18 [(ODU2)], R8 [ODU2 -> (PKT)]
R1 ([PKT] -> ODU2), S3 ([ODU2]), S1 ([ODU2]), S2 ([ODU2]), If the CNC instead requested to pass through the link from S8 to
S8 ([ODU2]), S12 ([ODU2]), S15 ([ODU2]), S18 ([ODU2]), R5 (ODU2 -> S12, then the above path would not be qualified, while the following
[PKT]) would be:
Similarly, the XRO can be represented by the TE tunnel model as well. R1 [(PKT) -> ODU2], S3[(ODU2]), S1 [(ODU2]), S2[(ODU2]),
S8 [(ODU2]), S12[(ODU2]), S15 [(ODU2]), S18[(ODU2]), R8 [ODU2 ->
(PKT)]
When there is a technology specific network (e.g., OTN), the The mechanisms used by the CNC to provide path constraints at the
corresponding technology (OTN) model should also be used to specify CMI are outside the scope of this document. It is assumed that the
the tunnel information on MPI, with the constraint included in TE MDSC can understand these constraints and take them into account in
Tunnel model. its path computation procedures (which would decide at least which
domains and inter-domain links) and in the path constraints to
provide to its underlying PNCs, to be taken into account in the path
computation procedures implemented by the PNCs (with a more detailed
view of topology).
5. YANG Model Analysis 5. YANG Model Analysis
This section provides a high-level overview of how IETF YANG models This section analyses how the IETF YANG models can be used at the
can be used at the MPIs, between the MDSC and the PNCs, to support MPIs, between the MDSC and the PNCs, to support the scenarios
the scenarios described in section 4. described in section 4.
Section 5.1 describes the different topology abstractions provided to The YANG models described in [ACTN-YANG] are assumed to be used at
the MDSC by each PNC via its own MPI. the MPI.
Section 5.2 describes how the MDSC can coordinate different requests Section 5.1 describes the different topology abstractions provided
to different PNCs, via their own MPIs, to setup the different to the MDSC by each PNC via its own MPI.
services described in section 4.3.
Section 5.2 describes how the MDSC can request different PNCs, via
their own MPIs, the network configuration needed to setup the
different services described in section 4.3.
Section 5.3 describes how the protection scenarios can be deployed, Section 5.3 describes how the protection scenarios can be deployed,
including end-to-end protection and segment protection, for both including end-to-end protection and segment protection, for both
intra-domain and inter-domain scenario. intra-domain and inter-domain scenario.
5.1. YANG Models for Topology Abstraction 5.1. YANG Models for Topology Abstraction
Each PNC reports its respective abstract topology to the MDSC, as Each PNC reports its respective OTN abstract topology to the MDSC,
described in section 4.2. as described in section 4.2, using the Topology YANG models, defined
in [RFC8345], with the TE Topology YANG augmentations, provided in
[TE-TOPO], and the OTN technology-specific YANG augmentations,
defined in [OTN-TOPO].
The [OTN-TOPO] model allows reporting within the OTN abstract
topology also the access links which are capable of supporting the
transparent client layers, defined in section 4.3.3 and in
[CLIENT-SIGNAL]. These links can also be multi-function access links
that can be configured as a transparent client physical links (e.g.,
STM-64 physical link) as an OTUk trail.
In order to support the EPL and EVPL services, described in sections
4.3.2 and 4.3.4, the access links, which are capable to be
configured as Ethernet physical links, are reported by each PNC
within its respective Ethernet abstract topology, using the Topology
YANG models, defined in [RFC8345], with the TE Topology YANG
augmentations, defined in [TE-TOPO], and the Ethernet client
technology-specific YANG augmentations, defined in [CLIENT-TOPO].
These links can also be multi-function access links that can be
configured as an Ethernet physical link or as an OTUk trail and/or
as transparent client physical links (e.g., STM-64 physical link).
In this case, these physical access links are represented in both
the OTN and Ethernet abstract topologies.
It is worth noting that in the network scenarios analyzed in this
document (where switching is performed only in the ODU layer), the
Ethernet abstract topologies reported by the PNCs describes only the
Ethernet client access links: no Ethernet TE switching capabilities
are reported in these Ethernet abstract topologies.
5.1.1. Domain 1 Black Topology Abstraction 5.1.1. Domain 1 Black Topology Abstraction
PNC1 provides the required black topology abstraction, as described PNC1 provides the required black topology abstraction, as described
in section 4.2, to expose to the MDSC, at MPI1, one TE Topology in section 4.2. It exposes at MPI1 to the MDSC, two TE Topology
instance for the ODU layer (MPI1 OTN Topology) containing only one instances with only one TE node each.
abstract TE node (i.e., AN1) and only inter-domain and access
abstract TE links (which represent the inter-domain and access The first TE Topology instance reports the domain 1 OTN abstract
physical links), as shown in Figure 3 below. topology view (MPI1 OTN Topology), using the OTN technology-specific
augmentations [OTN-TOPO], with only one abstract TE node (i.e., AN1)
and only inter-domain and access abstract TE links (which represent
the inter-domain physical links and the access physical links which
can support ODU and/or transparent client layers), as shown in
Figure 3 below.
................................... ...................................
: : : :
: +-----------------+ : : +-----------------+ :
: | | : : | | :
(R1)- - --------| |-------- - -(S31) (R1)- - --------| |-------- - -(S31)
: AN1-1 | | AN1-2 : : AN1-1 | | AN1-7 :
: | | : : | | :
(R2)- - --------| | : (R3)- - --------| | :
: AN1-3 | AN1 | : : AN1-2 | AN1 | :
: | | : : | | :
(R3)- - --------| |-------- - -(S32) (R4)- - --------| |-------- - -(S32)
: AN1-7 | | AN1-4 : : AN1-3 | | AN1-6 :
: | | : : | | :
: +-----------------+ : : +-----------------+ :
: | | : : | | :
: AN1-6 | | AN1-5 : : AN1-4 | | AN1-5 :
:..........|..........|...........: :..........|..........|...........:
| | | |
(S11) (S12) (S11) (S12)
Figure 3 - Abstract Topology exposed at MPI1 (MPI1 OTN Topology) Figure 3 - OTN Abstract Topology exposed at MPI1 (MPI1 OTN Topology)
As described in section 4.1, it is assumed that the physical links The second TE Topology instance reports the domain 1 Ethernet
between the physical nodes are pre-configured and therefore PNC1 abstract topology view (MPI1 ETH Topology), using the Ethernet
exports at MPI1 one abstract TE Link, within the MPI1 OTN topology, technology-specific augmentations [CLIENT-TOPO], with only one
for each OTU2 or OTU4 trail which support an abstract TE link in the abstract TE node (i.e., AN1) and only access abstract TE links
MPI1 ODU Topology. (which represent the access physical links which can support
Ethernet client layers), as shown in Figure 4 below.
...................................
: :
: +-----------------+ :
: | | :
(R1)- - --------| | :
: AN1-1 | | :
: | | :
(R2)- - --------| | :
: AN1-8 | AN1 | :
: | | :
: | | :
: | | :
: | | :
: +-----------------+ :
: :
:.................................:
Figure 4 - ETH Abstract Topology exposed at MPI1 (MPI1 ETH Topology)
As described in section 4.1, it is assumed that the OTU4 trails on
the inter-domain physical links (e.g., the link between S2 and S31)
are pre-configured and exposed as external TE Links, within the MPI1
OTN topology (e.g., the external TE Link terminating on AN1-7 TE
Link Termination Point (LTP) abstracting the OTU4 trail between S2
and S31).
In order to analyze the service scenarios of sections 4.3 and 4.4:
o the access link between S3 and R1 is assumed to be a
multi-function access link, which can be configured as an OTU2
trail or as an STM-64 or a 10GE physical link;
o the access link between S6 and R2 is assumed to be pre-configured
as a 10GE physical link, up to the MAC layer;
o the access link between S6 and R3 is assumed to be a
multi-function access link which can be configured as an OTU2
trail or as an STM-64 physical link;
o the access link connected to router R4 is assumed to be
pre-configured as an STM-64 physical link.
Therefore PNC1 exports at MPI1 the following external TE Links,
within the MPI1 OTN topology:
o two abstract TE Links, terminating on LTP AN1-1 and AN1-2
respectively, abstracting the physical access link between S3 and
R1 and the access link between S6 and R3 respectively, reporting
that they can support STM-64 client signals as well as ODU2
connections;
o one abstract TE Link, terminating on LTP AN1-3, abstracting the
physical access link between S6 and R4, reporting that it can
support STM-64 client signals but no ODU2 connections.
The information about the 10GE access link between S6 and R2 as well
as the fact that the access link between S3 and R1 can also be
configured as a 10GE link cannot be exposed by PNC1 within the MPI1
OTN topology.
Therefore, PNC1 exports at MPI1, within the MPI1 ETH topology, two
abstract TE Links, terminating on LTP AN1-1 and AN1-8 respectively,
abstracting the physical access link between S3 and R1 and the
access link between S6 and R2 respectively, reporting that they can
support Ethernet client signal with port-based and VLAN-based
classifications. The PNC1 native topology would represent the
physical network topology of the domain controlled by the PNC, as
shown in Figure 5.
.................................. ..................................
: : : :
: ODU Abstract Topology @ MPI : : Physical Topology @ PNC1 :
: Gotham City Area :
: Metro Transport Network :
: : : :
: +----+ +----+ : : +----+ +----+ :
: | |S1-1 | |S2-1: : | |S1-1 | |S2-3:
: | S1 |--------| S2 |----- - -(S31) : | S1 |--------| S2 |----- - -(S31)
: +----+ S2-2+----+ : : +----+ S2-1+----+ :
: S1-2/ |S2-3 : : S1-2/ |S2-2 :
: S3-2/ Robinson Park | : : S3-4/ | :
: +----+ +----+ | : : +----+ +----+ | :
: | |3 1| | | : : | |3 1| | | :
(R1)- - -----| S3 |---| S4 | | : (R1)- - -----| S3 |---| S4 | | :
:S3-1+----+ +----+ | : :S3-1+----+ +----+ | :
: S3-4 \ \S4-2 | : : S3-2 \ \S4-2 | :
: \S5-1 \ | : : \S5-1 \ | :
: +----+ \ | : : +----+ \ | :
: | | \S8-3| : : | | \S8-2| :
: | S5 | \ | : : | S5 | \ | :
: +----+ Metro \ |S8-2 : : +----+ \ |S8-1 :
(R2)- - ------ 2/ E \3 Main \ | : (R2)- - ------ 2/ \3 \ | :
:S6-1 \ /3 a E \1 Ring \| : :S6-1 \ /5 \1 \| :
: +----+s-n+----+ +----+ : : +----+ +----+ +----+ :
: | |t d| | | |S8-1: : | | | | | |S8-5:
: | S6 |---| S7 |---| S8 |----- - -(S32) (R3)- - -----| S6 |---| S7 |---| S8 |----- - -(S32)
: +----+4 2+----+3 4+----+ : :S6-2+----+4 2+----+4 3+----+ :
: / | | : : / | | :
(R3)- - ------ S7-4 | | S8-5 : (R3)- - ------ S7-3 | | S8-4 :
:S6-2 | | : :S6-3 | | :
:...............|........|.......: :...............|........|.......:
| | | |
(S11) (S12) (S11) (S12)
Figure 4 - Physical Topology discovered by PNC1 Figure 5 - Physical Topology controlled by PNC1
LTP mapping table:
AN1-1 -> S3-1
AN1-2 -> S2-1
AN1-3 -> S6-1
AN1-4 -> S8-1
AN1-5 -> S8-5
AN1-6 -> S7-4 The PNC1 native topology is not exposed and therefore it under PNC
responsibility to abstract the whole domain physical topology as a
single TE node and to maintain a mapping between the LTPs exposed at
MPI abstract topologies and the associated physical interfaces
controlled by the PNC:
AN1-7 -> S6-2 Physical Interface OTN Topology LTP ETH Topology LTP
(Figure 5) (Figure 3) (Figure 4)
S2-3 AN1-7
S3-1 AN1-1 AN1-1
S6-1 AN1-8
S6-2 AN1-2
S6-3 AN1-3
S7-3 AN1-4
S8-4 AN1-5
S8-5 AN1-6
Appendix B.1.1 provides the detailed JSON code example ("mpi1-otn- Appendix B.1.1 provides the detailed JSON code example ("mpi1-otn-
topology.json") describing how this ODU Topology is reported by the topology.json") describing how the MPI1 ODU Topology is reported by
PNC, using the [TE-TOPO] and [OTN-TOPO] YANG models at MPI1. the PNC1, using the [RFC8345], [TE-TOPO] and [OTN-TOPO] YANG models,
at MPI1.
It is worth noting that this JSON code example does not provide all It is worth noting that this JSON code example does not provide all
the attributes defined in the relevant YANG models: the attributes defined in the relevant YANG models, including:
o YANG attributes which are outside the scope of this document are o YANG attributes which are outside the scope of this document are
not shown not shown;
o The attributes describing the label restrictions are also not o The attributes describing the set of label values that are
shown to simplify the JSON code example available at the inter-domain links (label-restriction container)
are also not shown to simplify the JSON code example;
o The comments describing the rationale for not including some o The comments describing the rationale for not including some
attributes in this JSON code example even if in the scope of this attributes in this JSON code example even if in the scope of this
document are identified with the prefix "// __COMMENT__" and document are identified with the prefix "// __COMMENT" and
included only in the first object instance (e.g., in the Access included only in the first object instance (e.g., in the Access
Link from the AN1-1 description or in the AN1-1 LTP description) Link from the AN1-1 description or in the AN1-1 LTP description).
5.1.2. Domain 2 Black Topology Abstraction 5.1.2. Domain 2 Black Topology Abstraction
PNC2 provides the required black topology abstraction, as described PNC2 provides the required black topology abstraction, as described
in section 4.2, to expose to the MDSC, at MPI2, one TE Topology in section 4.2, to expose to the MDSC, at MPI2, two TE Topology
instance for the ODU layer (MPI2 OTN Topology) containing only one instances with only one TE node each:
abstract node (i.e., AN2) and only inter-domain and access abstract
TE links (which represent the inter-domain and access physical o the first instance reports the domain 2 OTN abstract topology
links). view (MPI2 OTN Topology), with only one abstract node (i.e., AN2)
and only inter-domain and access abstract TE links (which
represent the inter-domain physical links and the access physical
links which can support ODU and/or transparent client layers);
o the instance reports the domain 2 Ethernet abstract topology view
(MPI2 ETH Topology), with only one abstract TE node (i.e., AN2)
and only access abstract TE links (which represent the access
physical links which can support Ethernet client layers).
5.1.3. Domain 3 White Topology Abstraction 5.1.3. Domain 3 White Topology Abstraction
PNC3 provides the required white topology abstraction, as described PNC3 provides the required white topology abstraction, as described
in section 4.2, to expose to the MDSC, at MPI3, one TE Topology in section 4.2, to expose to the MDSC, at MPI3, two TE Topology
instance for the ODU layer (MPI3 OTN Topology) containing one instances with multiple TE nodes, one for each physical node:
abstract TE node for each physical node and one abstract TE link for
each physical link (internal links, inter-domain links or access
links).
5.1.4. Multi-domain Topology Stitching o the first instance reports the domain 3 OTN topology view (MPI3
OTN Topology), with four TE nodes, which represent the four
physical nodes (i.e. S31, S32, S33 and S34), and abstract TE
links, which represent the inter-domain and internal physical
links;
o the second instance reports the domain 3 Ethernet abstract
topology view (MPI3 ETH Topology), with only two TE nodes, which
represent the two edge physical nodes (i.e., S31 and S33) and
only the two access TE links which represent the access physical
links.
5.1.4. Multi-domain Topology Merging
As assumed at the beginning of this section, MDSC does not have any As assumed at the beginning of this section, MDSC does not have any
knowledge of the topologies of each domain until each PNC reports its knowledge of the topologies of each domain until each PNC reports
own abstraction topology, so the MDSC needs to merge together the its own abstract topologies, so the MDSC needs to merge together
abstract topologies provided by different PNCs, at the MPIs, to build these abstract topologies, provided by different PNCs, to build its
its own topology view, as described in section 4.3 of [TE-TOPO]. own topology view of the multi-domain network (MDSC multi-domain
native topology), as described in section 4.3 of [TE-TOPO].
Given the topologies reported from multiple PNCs, the MDSC need to Given the topologies reported from multiple PNCs, the MDSC need to
stitch the multi-domain topology and obtain the full map of topology. merge them into its multi-domain native topology. The topology of
The topology of each domain may be in an abstracted shape (refer to each domain may be in an abstracted shape (refer to section 5.2 of
section 5.2 of [RFC8453] for a different level of abstraction), while [RFC8453] for a different level of abstraction), while the inter-
the inter-domain link information must be complete and fully domain link information must be complete and fully configured by the
configured by the MDSC. MDSC.
The inter-domain link information is reported to the MDSC by the two The inter-domain link information is reported to the MDSC by the two
PNCs, controlling the two ends of the inter-domain link. PNCs, controlling the two ends of the inter-domain link.
The MDSC needs to understand how to "stitch" together these inter- The MDSC needs to understand how to merge together these inter-
domain links. domain links.
One possibility is to use the plug-id information, defined in [TE- One possibility is to use the plug-id information, defined in [TE-
TOPO]: two inter-domain links reporting the same plug-id value can be TOPO]: two inter-domain TE links, within two different MPI abstract
merged as a single intra-domain link within any MDSC native topology. topologies, terminating on two LTPs reporting the same plug-id value
can be merged as a single intra-domain link, within any MDSC native
topology.
The value of the reported plug-id information can be either assigned The value of the reported plug-id information can be either assigned
by a central network authority, and configured within the two PNC by a central network authority, and configured within the two PNC
domains, or it can be discovered using automatic discovery mechanisms domains. Alternatively, it may be discovered using an automatic
(e.g., LMP-based, as defined in [RFC6898]). discovery mechanisms (e.g., LMP-based, as defined in [RFC6898]).
In case the plug-id values are assigned by a central authority, it is In case the plug-id values are assigned by a central authority, it
under the central authority responsibility to assign unique values. is under the central authority responsibility to assign unique
values.
In case the plug-id values are automatically discovered, the In case the plug-id values are automatically discovered, the
information discovered by the automatic discovery mechanisms needs to information discovered by the automatic discovery mechanisms needs
be encoded as a bit string within the plug-id value. This encoding is to be encoded as a bit string within the plug-id value. This
implementation specific, but the encoding rules need to be consistent encoding is implementation specific, but the encoding rules need to
across all the PNCs. be consistent across all the PNCs.
In case of co-existence within the same network of multiple sources In case of co-existence within the same network of multiple sources
for the plug-id (e.g., central authority and automatic discovery or for the plug-id (e.g., central authority and automatic discovery or
even different automatic discovery mechanisms), it is needed that the even different automatic discovery mechanisms), it is needed that
plug-id namespace is partitioned to avoid that different sources the plug-id namespace is partitioned to avoid that different sources
assign the same plug-id value to different inter-domain link. The assign the same plug-id value to different inter-domain links. Also,
encoding of the plug-id namespace within the plug-id value is the encoding of the plug-id namespace within the plug-id value is
implementation specific but needs to be consistent across all the implementation specific and will need to be consistent across all
PNCs. the PNCs.
Another possibility is to pre-configure, either in the adjacent PNCs This document assumes that the plug-id is assigned by a central
or in the MDSC, the association between the inter-domain link authority, with the first octet set to 0x00 to represent the central
identifiers (topology-id, node-id and tp-id) assigned by the two authority namespace. The configuration method used, within each PNC
adjacent PNCs to the same inter-domain link. domain, are outside the scope of this document.
This last scenario requires further investigation and will be Based on the plug-id values, the MDSC can merge together the
discussed in a future version of this document. abstract topologies exposed by the underlying PNCs, as described in
sections 5.1.1, 5.1.2 and 5.1.3 above, into its multi-domain native
TE topology as shown in Figure 6.
........................ ........................
: : : :
: Network domain 1 : ............. : Network domain 1 : .............
: Grey Topology : : : : Black Topology : : :
: Abstraction : : Network : : Abstraction : : Network :
: : : domain 3 : : AN1-1 : : domain 3 :
(R1)- - -------+ : : (White) : (R1)- - ----------+ : : (White) :
: \ +--------------+ : : \ +--------------+ :
: \ / : : \ : (R2)- - ---------+ + / : : \ :
: \ / : : \ : : \| / : : \ :
(R2)- - --------- AN1 --+ : : S31 ---- - (R7) (R3)- - --------- AN1 --+ : : S31 ---- - (R5)
: /|\ \ : : / \ : : : /|\ \ : : / \ : :
: / | \ +--------- S32 S33 - - (R8) (R4)- - ---------+ | \ +--------- S32 S33 - - (R6)
: / | \ : :/ \ / : : | \ : :/ \ / :
(R3)- - -------+ | +---+ : / S34 : : | +---+ : / S34 :
:..........|.......|...: /: / : :..........|.......|...: /: / :
| | / :../........: | | / :../........:
| | / / | | / /
...........|.......|.../..../.... ...........|.......|.../..../....
: | | / / : : | | / / :
: Network | + / / : : Network | + / / :
: domain 2 | / / / : : domain 2 | / / / :
: | / / / : : | / / / :
: | + / +--+ : : | + / +--+ :
: | |/ / +--- - -(R4) : | |/ / :
: Black +--- AN2 ---------+ : : Black +--- AN2 ------------- - -(R7)
: Topology | | : : Topology | | AN2-1 :
: Abstraction | +-------------- - -(R5) : Abstraction | +-------------- - -(R8)
: | : : | :
: +---------------- - -(R6) : +---------------- - -(R9)
: : : :
:...............................: :...............................:
Figure 5 - Multi-domain Abstract Topology discovered by MDSC Figure 6 - Multi-domain Abstract Topology controlled by an MDSC
5.1.5. Access Links
Access links in Figure 3 are shown as ODU Links: the modeling of the
access links for other access technologies is currently an open
issue.
The modeling of the access link in case of non-ODU access technology
has also an impact on the need to model ODU TTPs and layer transition
capabilities on the edge nodes (e.g., nodes S2, S3, S6 and S8 in
Figure 3).
If, for example, the physical NE S6 is implemented in a "pizza box",
the data plane would have only set of ODU termination resources
(where up to 2xODU4, 4xODU3, 20xODU2, 80xODU1, 160xODU0 and
160xODUflex can be terminated). The traffic coming from each of the
10GE access links can be mapped into any of these ODU terminations.
Instead if, for example, the physical NE S6 can be implemented as a
multi-board system where access links reside on different/dedicated
access cards with a separated set of ODU termination resources (where
up to 1xODU4, 2xODU3, 10xODU2, 40xODU1, 80xODU0 and 80xODUflex for
each resource can be terminated). The traffic coming from one 10GE
access links can be mapped only into the ODU terminations which
reside on the same access card.
The more generic implementation option for a physical NE (e.g., S6)
would be the case is of a multi-board system with multiple access
cards with separated sets of access links and ODU termination
resources (where up to 1xODU4, 2xODU3, 10xODU2, 40xODU1, 80xODU0 and
80xODUflex for each resource can be terminated). The traffic coming
from each of the 10GE access links on one access card can be mapped
only into any of the ODU terminations which reside on the same access
card.
In the last two cases, only the ODUs terminated on the same access
card where the access links reside can carry the traffic coming from
that 10GE access link. Terminated ODUs can instead be sent to any of
the OTU4 interfaces
In all these cases, terminated ODUs can be sent to any of the OTU4
interfaces assuming the implementation is based on a non-blocking ODU
cross-connect.
If the access links are reported via MPI in some, still to be
defined, client topology, it is possible to report each set of ODU
termination resources as an ODU TTP within the ODU Topology of Figure
3 and to use either the inter-layer lock-id or the transitional link,
as described in sections 3.4 and 3.10 of [TE-TOPO], to correlate the
access links, in the client topology, with the ODU TTPs, in the OTN
topology, to which access link are connected to.
5.2. YANG Models for Service Configuration 5.2. YANG Models for Service Configuration
The service configuration procedure is assumed to be initiated (step The service configuration procedure is assumed to be initiated (step
1 in Figure 6) at the CMI from CNC to MDSC. Analysis of the CMI 1 in Figure 7) at the CMI from CNC to MDSC. Analysis of the CMI
models is (e.g., L1SM, L2SM, Transport-Service, VN, et al.) is models is (e.g., L1CSM, L2SM, VN) is outside the scope of this
outside the scope of this document. document.
As described in section 4.3, it is assumed that the CMI YANG models As described in section 4.3, it is assumed that the CMI YANG models
provide all the information that allows the MDSC to understand that provide all the information that allows the MDSC to understand that
it needs to coordinate the setup of a multi-domain ODU connection (or it needs to coordinate the setup of a multi-domain ODU data plane
connection segment) and, when needed, also the configuration of the connection (which can be either an end-to-end connection or a
segment connection) and, when needed, also the configuration of the
adaptation functions in the edge nodes belonging to different adaptation functions in the edge nodes belonging to different
domains. domains.
| |
| {1} | {1}
V V
---------------- ----------------
| {2} | | {2} |
| {3} MDSC | | {3} MDSC |
| | | |
skipping to change at page 36, line 40 skipping to change at page 34, line 48
(Network) / ( ) \ V (Network) / ( ) \ V
( Domain 1) / ----- \ ----- ( Domain 1) / ----- \ -----
( )/ \ (Network) ( )/ \ (Network)
A===========B \ ( Domain 3) A===========B \ ( Domain 3)
/ ( ) \( ) / ( ) \( )
AP-1 ( ) X===========Z AP-1 ( ) X===========Z
----- ( ) \ ----- ( ) \
( ) AP-2 ( ) AP-2
----- -----
Figure 6 - Multi-domain Service Setup Figure 7 - Multi-domain Service Setup
As an example, the objective in this section is to configure a As an example, the objective in this section is to configure a
transport service between R1 and R5. The cross-domain routing is transport service between R1 and R8, such as one of the services
assumed to be R1 <-> S3 <-> S2 <-> S31 <-> S33 <-> S34 <->S15 <-> S18 described in section 4.3. The inter-domain path is assumed to be R1
<-> R5. <-> S3 <-> S1 <-> S2 <-> S31 <-> S33 <-> S34 <->S15 <-> S18 <-> R8
(see the physical topology in Figure 1).
According to the different client signal type, there is different According to the different client signal types, different
adaptation required. adaptations can be required to be configured at the edge nodes
(i.e., S3 and S18).
After receiving such request, MDSC determines the domain sequence, After receiving such request, MDSC determines the domain sequence,
i.e., domain 1 <-> domain 2 <-> domain 3, with corresponding PNCs and i.e., domain 1 <-> domain 3 <-> domain 2, with corresponding PNCs
inter-domain links (step 2 in Figure 6). and the inter-domain links (step 2 in Figure 7).
As described in [PATH-COMPUTE], the domain sequence can be determined As described in [PATH-COMPUTE], the domain sequence can be
by running the MDSC own path computation on the MDSC internal determined by running the MDSC own path computation on the MDSC
topology, defined in section 5.1.4, if and only if the MDSC has native topology, defined in section 5.1.4, if and only if the MDSC
enough topology information. Otherwise, the MDSC can send path has enough topology information. Otherwise, the MDSC can send path
computation requests to the different PNCs (steps 2.1, 2.2 and 2.3 in computation requests to the different PNCs (steps 2.1, 2.2 and 2.3
Figure 6) and use this information to determine the optimal path on in Figure 7) and use this information to determine the optimal path
its internal topology and therefore the domain sequence. on its internal topology and therefore the domain sequence.
The MDSC will then decompose the tunnel request into a few tunnel The MDSC will then decompose the tunnel request into a few tunnel
segments via tunnel model (including both TE tunnel model and OTN segments via tunnel models (both technology agnostic TE tunnel model
tunnel model), and request different PNCs to setup each intra-domain and OTN tunnel model), and request different PNCs to setup each
tunnel segment (steps 3, 3.1, 3.2 and 3.3 in Figure 6). intra-domain tunnel segment (steps 3, 3.1, 3.2 and 3.3 in Figure 7).
Assume that each intra-domain tunnel segment can be set up The MDSC will take care of the configuration of both the intra-
successfully, and each PNC response to the MDSC respectively. Based domain tunnel segment and inter-domain tunnel via corresponding MPI
on each segment, MDSC will take care of the configuration of both the (via TE tunnel model and OTN tunnel model) through all the PNCs
intra-domain tunnel segment and inter-domain tunnel via corresponding controlling the domains selected during path computation. More
MPI (via TE tunnel model and OTN tunnel model). More specifically, specifically, for the inter-domain tunnel hand-off, taking into
for the inter-domain configuration, the ts-bitmap and tpn attributes account that the inter-domain links are all OTN links, the list of
need to be configured using the OTN Tunnel model. Then the end-to-end timeslots and the TPN value assigned to that ODUk connection at the
OTN tunnel will be ready. inter-domain link needs to be configured by the MDSC.
In any case, the access link configuration is done only on the PNCs In any case, the access link configuration is done only on the PNCs
that control the access links (e.g., PNC-1 and PNC-3 in our example) that control the access links (e.g., PNC-1 and PNC-3) and not on the
and not on the PNCs of transit domain (e.g., PNC-2 in our example). PNCs of transit domain(s) (e.g., PNC-2). An access link will be
An access link will be configured by MDSC after the OTN tunnel is set configured by MDSC after the OTN tunnel is set up.
up. Access configuration is different and dependent on the different
type of service. More details can be found in the following sections.
5.2.1. ODU Transit Service Access configuration will vary and will be dependent on each type of
service. Further discussion and examples are provided in the
following sub-sections.
In this scenario, described in section 4.3.1, the access links are 5.2.1. ODU Transit Service
configured as ODU Links.
Since it is assumed that the physical access links are pre- In this scenario, described in section 4.3.1, the physical access
configured, each PNC exposes, at its MPI, one TE Link (called "ODU links are configured as 10G OTN links and, as described in section
Link") for each of these physical access link. These links are 5.1, reported by each PNC as TE Links within the OTN abstract
reported, together with any other ODU internal or inter-domain link, topologies they expose to the MDSC.
within the OTN abstract topology exposed by each PNC, at its own MPI.
To setup this IP link, between R1 and R5, the CNC requests, at the To setup this IP link, between R1 and R8, the CNC requests, at the
CMI, the MDSC to setup an ODU transit service. CMI, the MDSC to setup an ODU transit service.
From the topology information described in section 5.1 above, the From its native topology, shown in Figure 6, the MDSC understands,
MDSC understands that R1 is attached to the access link terminating by means which are outside the scope of this document, that R1 is
on S3-1 LTP in the ODU Topology exposed by PNC1 and that R5 is attached to the access link terminating on AN1-1 LTP in the MPI1 OTN
attached to the access link terminating on AN2-1 LTP in the ODU Abstract Topology (Figure 3), exposed by PNC1, and that R8 is
Topology exposed by PNC2. attached to the access link terminating on AN2-1 LTP in the MPI2
Abstract Topology, exposed by PNC2.
MDSC would then request, at MPI1, the PNC1 to setup an ODU2 (Transit MDSC then performs multi-domain path computation (step 2 in Figure
Segment) Tunnel with one primary path between S3-1 and S2-1 LTPs: 7) and requests PNC1, PNC2 and PNC3, at MPI1, MPI2 and MPI3
respectively, to setup ODU2 (Transit Segment) Tunnels within the OTN
Abstract Topologies they expose (MPI1 OTN Abstract Topology, MPI2
OTN Abstract Topology and MPI3 OTN Abstract Topology, respectively).
MDSC requests, at MPI1, PNC1 to setup an ODU2 (Transit Segment)
Tunnel with one primary path between AN-1 and AN1-7 LTPs, within the
MPI1 OTN Abstract Topology (Figure 4), using the TE Tunnel YANG
model, defined in [TE-TUNNEL], with the OTN technology-specific
augmentations, defined in [OTN-TUNNEL]:
o Source and Destination TTPs are not specified (since it is a o Source and Destination TTPs are not specified (since it is a
Transit Tunnel) Transit Tunnel)
o Ingress and egress points are indicated in the route-object- o Ingress and egress points are indicated in the route-object-
include-exclude list of the explicit-route-objects of the primary include-exclude list of the explicit-route-objects of the primary
path: path:
o The first element references the access link terminating on o The first element references the access link terminating on
S3-1 LTP AN1-1 LTP
o The last two element references respectively the inter-domain o The last two element reference respectively the inter-domain
link terminating on S2-1 LTP and the data plane resources link terminating on AN1-7 LTP and the data plane resources
(i.e., the timeslots and the TPN, called "OTN Label") used by (i.e., the list of timeslots and the TPN) used by the ODU2
the ODU2 connection over that link. connection over that link.
The configuration of the timeslots used by the ODU2 connection on the The configuration of the timeslots used by the ODU2 connection on
internal links within a PNC domain (i.e., on the internal links the internal links within a PNC domain (i.e., on the internal links
domain) is outside the scope of this document since it is a matter of within domain1) is outside the scope of this document since it is a
the PNC domain internal implementation. matter of the PNC domain internal implementation.
However, the configuration of the timeslots used by the ODU2 However, the configuration of the timeslots used by the ODU2
connection at the transport network domain boundaries (e.g., on the connection at the transport network domain boundaries (e.g., on the
inter-domain links) needs to take into account the timeslots inter-domain links) needs to take into account the timeslots
available on physical nodes belonging to different PNC domains (e.g., available on physical nodes belonging to different PNC domains
on node S2 within PNC1 domain and on node S31 within PNC3 domain). (e.g., on node S2 within PNC1 domain and on node S31 within PNC3
domain).
The MDSC, when coordinating the setup of a multi-domain ODU The MDSC, when coordinating the setup of a multi-domain ODU
connection, also configures the data plane resources (i.e., the connection, also configures the data plane resources (i.e., the list
timeslots and the TPN) to be used on the inter-domain links. The MDSC of timeslots and the TPN) to be used on the inter-domain links. The
can know the timeslots which are available on the physical OTN nodes MDSC can know the timeslots which are available on the physical OTN
terminating the inter-domain links (e.g., S2 and S31) from the OTN nodes terminating the inter-domain links (e.g., S2 and S31) from the
Topology information exposed, at the MPIs, by the PNCs controlling OTN Topology information exposed, at the MPIs, by the PNCs
the OTN physical nodes (e.g., PNC1 and PNC3 controlling the physical controlling the OTN physical nodes (e.g., PNC1 and PNC3 controlling
nodes S2 and S31 respectively). the physical nodes S2 and S31 respectively).
Appendix B.2.1 provides the detailed JSON code ("mpi1-odu2-service- Appendix B.2.1 provides the detailed JSON code ("mpi1-odu2-service-
config.json") describing how the setup of this ODU2 (Transit Segment) config.json") describing how the setup of this ODU2 (Transit
Tunnel can be requested by the MDSC, using the [TE-TUNNEL] and [OTN- Segment) Tunnel can be requested by the MDSC, using the [TE-TUNNEL]
TUNNEL] YANG models at MPI1. and [OTN-TUNNEL] YANG models at MPI1.
The Transport PNC performs path computation and sets up the ODU2 PNC1 knows, as described in the mapping table in Section 5.1.1, that
cross-connections within the physical nodes S3, S5 and S6, as shown AN-1 and AN1-7 LTPs within the MPI1 OTN Abstract Topology it exposes
in section 4.3.1. at MPI1 correspond to the S3-1 and S2-3 LTPs, respectively, within
its native topology. Therefore it performs path computation, for an
ODU2 connection between these LTPs within its native topology, and
sets up the ODU2 cross-connections within the physical nodes S3, S1
and S2, as shown in section 4.3.1.
5.2.1.1. Single Domain Example Since the R1-S3 access link is a multi-function access link, PNC1
also configures the OTU2 trail before setting up the ODU2
cross-connection in node S3.
To setup an ODU2 end-to-end connection, supporting an IP link, As part of the OUD2 cross-connection configuration in node S2, PNC1
between R1 and R3, the CNC requests, at the CMI, the MDSC to setup an configures the data plane resources (i.e., the list of timeslots and
ODU transit service. the TPN), to be used by this ODU2 connection on the S2-S31
inter-domain link, as requested by the MDSC.
The Transport PNC reports the status of the created ODU2 (Transit Following similar requests from MDSC to setup ODU2 (Transit Segment)
Segment) Tunnel and its path within the ODU Topology as shown in Tunnels within the OTN Abstract Topologies they expose, PNC2 then
Figure 7 below: sets up ODU2 cross-connections on nodes S31 and S33 while PNC3 sets
up ODU2 cross-connections on nodes S15 and S18, as shown in section
4.3.1. PNC2 also configures the OTU2 trail on the S18-R8
multi-function access link.
.................................. 5.2.1.1. Single Domain Example
: :
: ODU Abstract Topology @ MPI :
: :
: +----+ +----+ :
: | | | | :
: | S1 |--------| S2 |- - - - -(R4)
: +----+ +----+ :
: / | :
: / | :
: +----+ +----+ | :
: | | | | | :
(R1)- - - - - S3 |---| S4 | | :
:S3-1 <<= + +----+ | :
: = \ | :
: = \ \ | :
: == ---+ \ | :
: = | \ | :
: = S5 | \ | :
: == --+ \ | :
(R2)- - - - - = \ \ | :
:S6-1 \ / = \ \ | :
: +--- = +----+ +----+ :
: | = | | | | :
: | S6 = --| S7 |---| S8 |- - - - -(R5)
: +--- = +----+ +----+ :
: / = :
(R3)- - - - - <<== :
:S6-2 :
:................................:
Figure 7 - ODU2 Transit Tunnel To setup an ODU2 end-to-end connection, supporting an IP link,
between R1 and R3, the CNC requests, at the CMI, the MDSC to setup
an ODU transit service.
Following the procedures described in section 5.2.1, MDSC requests
only PCN1 to setup the ODU2 (Transit Segment) Tunnel between the
access links terminating on AN-1 and AN1-2 LTPs within the MPI1
Abstract Topology and PNC1 sets up ODU2 cross-connections on nodes
S3, S5 and S6, as shown in section 4.3.1. PNC1 also configures the
OTU2 trails on the R1-S3 and R3-S6 multi-function access links.
5.2.2. EPL over ODU Service 5.2.2. EPL over ODU Service
In this scenario, described in section 4.3.2, the access links are In this scenario, described in section 4.3.2, the access links are
configured as Ethernet Links. configured as 10GE Links and, as described in section 5.1, reported
by each PNC as TE Links within the ETH abstract topologies they
expose to the MDSC.
To setup this IP link, between R1 and R5, the CNC requests, at the To setup this IP link, between R1 and R8, the CNC requests, at the
CMI, the MDSC to setup an EPL service. CMI, the MDSC to setup an EPL service.
As described in section 5.1.5 above, it is not clear in this case how From its native topology, shown in Figure 6, the MDSC understands,
the Ethernet access links between the transport network and the IP by means which are outside the scope of this document, that R1 is
router, are reported by the PNC to the MDSC. attached to the access link terminating on AN1-1 LTP in the MPI1 ETH
Abstract Topology, exposed by PNC1, and that R8 is attached to the
access link terminating on AN2-1 LTP in the MPI2 ETH Abstract
Topology, exposed by PNC2.
If the 10GE physical links are not reported as ODU links within the The MDSC also understands that it needs to coordinate the setup of a
OTN topology information, described in section 5.1.1 above than the multi-domain ODU2 Tunnel between the TTPs, abstracting nodes S3 and
MDSC will not have sufficient information to know that R1 and R5 are S18 within the OTN Abstract Topologies exposed by PNC1 and PNC2,
attached to the access links terminating on S3 and S6. respectively.
Assuming that the MDSC knows how R1 and R3 are attached to the MDSC then performs multi-domain path computation (step 2 in Figure
transport network, the MDSC would request the Transport PNC to setup 7) and then requests:
an ODU2 end-to-end Tunnel between S3 and S6.
This ODU Tunnel is setup between two TTPs of nodes S3 and S6. In case o PNC1, at MPI1, to setup an ODU2 (Head Segment) Tunnel within the
of nodes S3 and S6 support more than one TTP, the MDSC should decide MPI1 OTN Abstract Topology;
which TTP to use.
As discussed in 5.1.5, depending on the different hardware o PNC1, at MPI1, to steer the Ethernet client traffic from/to AN1-1
implementations of the physical nodes S3 and S6, not all the access LTP, within the MPI1 ETH Abstract Topology, thought that ODU2
links can be connected to all the TTPs. The MDSC should therefore (Head Segment) Tunnel;
select not only the optimal TTP but also a TTP that would allow the
Tunnel to be used by the service.
It is assumed that in case of node S3 or node S6 supports only one o PNC3, at MPI3, to setup an ODU2 (Transit Segment) Tunnel within
TTP, this TTP can be accessed by all the access links. the MPI3 OTN Abstract Topology;
o PNC2, at MPI2, to setup ODU2 (Tail Segment) Tunnel within the
MPI2 OTN Abstract Topology;
o PNC2, at MPI2, to steer the Ethernet client traffic to/from AN2-1
LTP, within the MPI2 ETH Abstract Topology, through that ODU2
(Tail Segment) Tunnel.
MDSC requests, at MPI1, PNC1 to setup an ODU2 (Head Segment) Tunnel
with one primary path between the source TTP and AN1-7 LTP, within
the MPI1 OTN Abstract Topology (Figure 4), using the TE Tunnel YANG
model, defined in [TE-TUNNEL], with the OTN technology-specific
augmentations, defined in [OTN-TUNNEL]:
o Only the Source TTP is specified (since it is a Head Segment
Tunnel): therefore the Destination TTP is not specified
o The egress point in indicated in the route-object-include-exclude
list of the explicit-route-objects of the primary path:
o The last two element reference respectively the inter-domain
link terminating on AN1-7 LTP and the data plane resources
(i.e., the list of timeslots and the TPN) used by the ODU2
connection over that link.
Appendix B.2.2 provides the detailed JSON code ("mpi1-odu2-tunnel- Appendix B.2.2 provides the detailed JSON code ("mpi1-odu2-tunnel-
config.json") describing how the setup of this ODU2 (Head Segment) config.json") describing how the setup of this ODU2 (Head Segment)
Tunnel can be requested by the MDSC, using the [TE-TUNNEL] and [OTN- Tunnel can be requested by the MDSC, using the [TE-TUNNEL] and [OTN-
TUNNEL] YANG models at MPI1. TUNNEL] YANG models at MPI1.
Once the ODU2 Tunnel setup has been requested, unless there is a one- MDSC requests, at MPI1, PNC1 to steer the Ethernet client traffic
to-one relationship between the S3 and S6 TTPs and the Ethernet from/to AN1-2 LTP, within the MPI1 ETH Abstract Topology (Figure 4),
access links toward R1 and R3 (as in the case, described in section thought the MPI1 ODU2 (Head Segment) Tunnel, using the Ethernet
5.1.5, where the Ethernet access links reside on different/dedicated Client YANG model, defined in [CLIENT-SIGNAL].
access card such that the ODU2 tunnel can only carry the Ethernet
traffic from the only Ethernet access link on the same access card
where the ODU2 tunnel is terminated), the MDSC also needs to request
the setup of an EPL service from the access links on S3 and S6,
attached to R1 and R3, and this ODU2 Tunnel.
Appendix B.2.3 provides the detailed JSON code ("mpi1-epl-service- Appendix B.2.3 provides the detailed JSON code ("mpi1-epl-service-
config.json") describing how the setup of this EPL service using the config.json") describing how the setup of this EPL service using the
ODU2 Tunnel can be requested by the MDSC, using the [CLIENT-SVC] YANG ODU2 Tunnel can be requested by the MDSC, using the [CLIENT-SIGNAL]
model at MPI1. YANG model at MPI1.
PNC1 knows, as described in the table in section 5.1.1, that the
tunnel source TTP and AN1-7 LTP, within the MPI1 OTN Abstract
Topology it exposes at MPI1, correspond to node S3 and S2-3 LTP,
respectively, within its native topology. Therefore it performs path
computation, for an ODU2 connection between node S3 and S2-3 LTP
within its native topology, and sets up the ODU2 cross-connections
within the physical nodes S3, S1 and S2, as shown in section 4.3.2.
As part of the OUD2 cross-connection configuration in node S2, PNC1
configures the data plane resources (i.e., the list of timeslots and
the TPN), to be used by this ODU2 connection on the S2-S31
inter-domain link, as requested by the MDSC.
After the configuration of the ODU2 cross-connection in node S3,
PNC1 also configures the [ETH -> (ODU)] and [(ODU2) -> ETH]
adaptation functions, within node S3, as shown in section 4.3.2.
Since the R1-S3 access link is a multi-function access link, PNC1
also configures the 10GE link before this step.
Following similar requests from MDSC to setup ODU2 (Segment) Tunnels
within the OTN Abstract Topologies they expose as well as the
steering of the Ethernet client traffic, PNC3 then sets up ODU2
cross-connections on nodes S31 and S33 while PNC2 sets up ODU2
cross-connections on nodes S15 and S18 as well as the [ETH ->
(ODU2)] and [(ODU2) -> ETH] adaptation functions in node S18, as
shown in section 4.3.2. PNC2 also configures the 10GE link on the
S18-R8 multi-function access link.
5.2.2.1. Single Domain Example
To setup this IP link, between R1 and R2, the CNC requests, at the
CMI, the MDSC to setup an EPL service.
Following the procedures described in section 5.2.2, the MDSC
requests PCN1 to:
o setup an ODU2 (end-to-end) Tunnel between the TTPs, abstracting
nodes S3 and S6 within MPI1 OTN Abstract Topology exposed by PNC1
at MPI1;
o steer the Ethernet client traffic between the AN1-1 and AN1-8
LTPs, exposed by PNC1 within MPI1 ETH Abstract Topology, through
that ODU2 (end-to-end) Tunnel.
Then PNC1 sets up ODU2 cross-connections on nodes S3, S5 and S6 as
well as the [ETH -> (ODU)] and [(ODU2) -> ETH] adaptation functions
in nodes S3 and S6, as shown in section 4.3.2. PNC1 also configures
the 10GE link on the R1-S3 multi-function access link (the R2-S6
access link has been pre-configured as a 10GE link).
5.2.3. Other OTN Client Services 5.2.3. Other OTN Client Services
In this scenario, the access links are configured as one of the OTN In this scenario, described in section 4.3.3, the access links are
clients (e.g., STM-64) links. configured as STM-64 links and, as described in section 5.1,
reported by each PNC as TE Links within the OTN Abstract Topologies
they expose to the MDSC.
As described in section 4.3.3, the CNC needs to setup an STM-64 The CNC requests, at the CMI, MDSC to setup an STM-64 Private Line
Private Link service, supporting an IP link, between R1 and R3 and service between R1 and R8.
requests this service at the CMI to the MDSC.
MDSC needs to setup an STM-64 Private Link service between R1 and R3 Following similar procedures as described in section 5.2.2, MDSC
supported by an ODU2 end-to-end connection between S3 and S6. understands that:
As described in section 5.1.5 above, it is not clear in this case how o R1 is attached to the access link terminating on AN1-1 LTP in the
the access links (e.g., the STM-N access links) between the transport MPI1 OTN Abstract Topology, exposed by PNC1, and that R8 is
network and the IP router, are reported by the PNC to the MDSC. attached to the access link terminating on AN2-1 LTP in the MPI2
OTN Abstract Topology, exposed by PNC2;
The same issues, as described in section 5.2.2, apply here: o it needs to coordinate the setup of a multi-domain ODU2 Tunnel
between the TTPs, abstracting nodes S3 and S18 within the OTN
Abstract Topologies exposed by PNC1 and PNC2, respectively.
o the MDSC needs to understand that R1 and R3 are connected, thought The MDSC then performs multi-domain path computation (step 2 in
STM-64 access links, with S3 and S6 Figure 7) and then requests:
o the MDSC needs to understand which TTPs in S3 and S6 can be o PNC1, at MPI1, to setup an ODU2 (Head Segment) Tunnel within the
accessed by these access links MPI1 OTN Abstract Topology;
o the MDSC needs to configure the private line service from these o PNC1, at MPI1, to steer the STM-64 transparent client traffic
access links through the ODU2 tunnel from/to AN1-1 LTP, within the MPI1 OTN Abstract Topology, thought
that ODU2 (Head Segment) Tunnel;
o PNC3, at MPI3, to setup an ODU2 (Transit Segment) Tunnel within
the MPI3 OTN Abstract Topology;
o PNC2, at MPI2, to setup ODU2 (Tail Segment) Tunnel within the
MPI2 OTN Abstract Topology;
o PNC2, at MPI2, to steer the STM-64 transparent client traffic
to/from AN2-1 LTP, within the MPI2 ETH Abstract Topology, through
that ODU2 (Tail Segment) Tunnel.
PNC1, PNC2 and PNC3 then sets up the ODU2 cross-connections within
the physical nodes S3, S1, S2, S31, S33, S15 and S18 as well as the
[STM-64 -> (ODU)] and [(ODU2) -> STM-64] adaptation functions in
nodes S3 and S18, as shown in section 4.3.3. PNC1 and PNC2 also
configure the STM-64 links on the R1-S3 and R8-S18 multi-function
access links, respectively.
5.2.3.1. Single Domain Example
To setup this IP link, between R1 and R3, the CNC requests, at the
CMI, the MDSC to setup an STM-64 Private Line service.
The MDSC and PNC1 follows similar procedures as described in section
5.2.2.1 to set up ODU2 cross-connections on nodes S3, S5 and S6 as
well as the [STM-64 -> (ODU)] and [(ODU2) -> STM-64] adaptation
functions in nodes S3 and S6, as shown in section 4.3.3. PNC1 also
configures the STM-64 links on the R1-S3 and R3-S6 multi-function
access links.
5.2.4. EVPL over ODU Service 5.2.4. EVPL over ODU Service
In this scenario, the access links are configured as Ethernet links, In this scenario, described in section 4.3.4, the access links are
as described in section 5.2.2 above. configured as 10GE links, as described in section 5.2.2 above.
As described in section 4.3.4, the CNC needs to setup EVPL services, The CNC requests, at the CMI, the MDSC to setup two EVPL services:
supporting IP links, between R1 and R3, as well as between R1 and R4 one between R1 and R2, and another between R1 and R8.
and requests these services at the CMI to the MDSC.
MDSC needs to setup two EVPL services, between R1 and R3, as well as Following similar procedures as described in section 5.2.2 and
between R1 and R4, supported by ODU0 end-to-end connections between 5.2.2.1, MDSC understands that:
S3 and S6 and between S3 and S2 respectively.
As described in section 5.1.5 above, it is not clear in this case how o R1 and R2 are attached to the access links terminating
the Ethernet access links between the transport network and the IP respectively on AN1-1 and AN1-8 LTPs in the MPI1 ETH Abstract
router, are reported by the PNC to the MDSC. Topology, exposed by PNC1, and that R8 is attached to the access
link terminating on AN2-1 LTP in the MPI2 ETH Abstract Topology,
exposed by PNC2;
The same issues, as described in section 5.1.5 above, apply here: o to setup the first (single-domain) EVPL service, between R1 and
R2, it needs to coordinate the setup of a single-domain ODU0
Tunnel between the TTPs, abstracting nodes S3 and S6 within the
OTN Abstract Topology exposed by PNC1;
o the MDSC needs to understand that R1, R3 and R4 are connected, o to setup the second (multi-domain) EPVL service, between R1 and
thought the Ethernet access links, with S3, S6 and S2 R8, it needs to coordinate the setup of a multi-domain ODU0
Tunnel between the TTPs, abstracting nodes S3 and S18 within the
OTN Abstract Topologies exposed by PNC1 and PNC2, respectively.
o the MDSC needs to understand which TTPs in S3, S6 and S2 can be To setup the first (single-domain) EVPL service between R1 and R2,
accessed by these access links the MDSC and PNC1 follows similar procedures as described in section
5.2.2.1 to set up ODU0 cross-connections on nodes S3, S5 and S6 as
well as the [VLAN -> (ODU0)] and [(ODU0) -> VLAN] adaptation
functions, in nodes S3 and S6, as shown in section 4.3.4. PNC1 also
configures the 10GE link on the R1-S3 multi-function access link.
o the MDSC needs to configure the EVPL services from these access As part of the [VLAN -> (ODU0)] and [(ODU0) -> VLAN] adaptation
links through the ODU0 tunnels functions configurations in nodes S2 and S6, PNC1 configures also
the classification rules required to associated only the Ethernet
client traffic received with VLAN ID 10 on the R1-S3 and R2-S6
access links with this EVPL service. The MDSC provides this
information to PNC1 using the [CLIENT-SIGNAL] model.
In addition, the MDSC needs to get the information that the access To setup the second (multi-domain) EVPL service between R1 and R8,
links on S3, S6 and S2 are capable of supporting EVPL (rather than the MDSC, PNC1, PNC2 and PNC3 follows similar procedures as
just EPL) as well as to coordinate the VLAN configuration, for each described in section 5.2.2 to setup the ODU0 cross-connections
EVPL service, on these access links (this is a similar issue as the within the physical nodes S3, S1, S2, S31, S33, S15 and S18 as well
timeslot configuration on access links discussed in section 4.3.1 as the [VLAN -> (ODU0)] and [(ODU0) -> VLAN] adaptation functions in
above). nodes S3 and S18, as shown in section 4.3.4. PNC2 also configures
the 10GE link on the R8-S18 multi-function access link (the R1-S3
10GE link has been already configured when the first EVPL service
has been setup).
As part of the [VLAN -> (ODU0)] and [(ODU0) -> VLAN] adaptation
functions configurations in nodes S3 and S18, PNC1 and,
respectively, PNC2 configure also the classification rules required
to associated only the Ethernet client traffic received with VLAN ID
20 on the R1-S3 and R8-S18 access links with this EVPL service. The
MDSC provides this information to PNC1 and PNC2 using the
[CLIENT-SIGNAL] model.
5.3. YANG Models for Protection Configuration 5.3. YANG Models for Protection Configuration
5.3.1. Linear Protection (end-to-end) 5.3.1. Linear Protection (end-to-end)
To be discussed in future versions of this document. To be discussed in future versions of this document.
5.3.2. Segmented Protection 5.4. Notifications
To be discussed in future versions of this document. Further detailed analysis is outside the scope of this document
5.5. Path Computation with Constraints
The path computation constraints that can be supported at the MPI
using the IETF YANG models defined in [TE-TUNNEL] and [PATH-
COMPUTE].
When there is a technology specific network (e.g., OTN), the
corresponding technology (e.g., OTN) model should also be used to
specify the tunnel information on MPI, with the constraint included
in TE Tunnel model.
Further detailed analysis is outside the scope of this document
6. Security Considerations 6. Security Considerations
This document analyses the applicability of the YANG models being
defined by the IETF to support OTN single and multi-domain
scenarios.
Inherently OTN networks ensure privacy and security via hard Inherently OTN networks ensure privacy and security via hard
partitioning of traffic onto dedicated circuits. The separation of partitioning of traffic onto dedicated circuits. The separation of
network traffic makes it difficult to intercept data transferred network traffic makes it difficult to intercept data transferred
between nodes over OTN-channelized links. between nodes over OTN-channelized links.
This document analyses the applicability of the YANG models being
defined by the IETF to support OTN single and multi-domain scenarios
There are no specific new security considerations introduced by this
document.
In OTN the (General Communication Channel) GCC is used for OAM In OTN the (General Communication Channel) GCC is used for OAM
functions such as performance monitoring, fault detection, and functions such as performance monitoring, fault detection, and
signaling. The GCC control channel should be secured using a suitable signaling. The GCC control channel should be secured using a
mechanism. suitable mechanism.
There are no additional or new security considerations introduced by
this document.
7. IANA Considerations 7. IANA Considerations
This document requires no IANA actions. This document requires no IANA actions.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC4427] Mannie, E., Papadimitriou, D., "Recovery (Protection and
Restoration) Terminology for Generalized Multi-Protocol
Label Switching (GMPLS)", RFC 4427, March 2006.
[RFC4655] Farrel, A. et al., "A Path Computation Element (PCE)-Based
Architecture", RFC4655, August 2006.
[RFC7926] Farrel, A. et al., "Problem Statement and Architecture for [RFC7926] Farrel, A. et al., "Problem Statement and Architecture for
Information Exchange between Interconnected Traffic- Information Exchange between Interconnected Traffic-
Engineered Networks", BCP 206, RFC 7926, July 2016. Engineered Networks", BCP 206, RFC 7926, July 2016.
[RFC4427] Mannie, E., Papadimitriou, D., "Recovery (Protection and [RFC8345] Clemm, A.,Medved, J. et al., "A Yang Data Model for
Restoration) Terminology for Generalized Multi-Protocol Network Topologies", RFC8345, March 2018.
Label Switching (GMPLS)", RFC 4427, March 2006.
[RFC8453] Ceccarelli, D., Lee, Y. et al., "Framework for Abstraction [RFC8453] Ceccarelli, D., Lee, Y. et al., "Framework for Abstraction
and Control of TE Networks (ACTN)", RFC8453, August 2018. and Control of TE Networks (ACTN)", RFC8453, August 2018.
[ITU-T G.709] ITU-T Recommendation G.709 (06/16), "Interfaces for the [ITU-T G.709] ITU-T Recommendation G.709 (06/16), "Interfaces for
optical transport network", June 2016. the optical transport network", June 2016.
[ITU-T G.808.1] ITU-T Recommendation G.808.1 (05/14), "Generic [ITU-T G.808.1] ITU-T Recommendation G.808.1 (05/14), "Generic
protection switching - Linear trail and subnetwork protection switching - Linear trail and subnetwork
protection", May 2014. protection", May 2014.
[ITU-T G.873.1] ITU-T Recommendation G.873.1 (05/14), "Optical [ITU-T G.873.1] ITU-T Recommendation G.873.1 (05/14), "Optical
transport network (OTN): Linear protection", May 2014. transport network (OTN): Linear protection", May 2014.
[TE-TOPO] Liu, X. et al., "YANG Data Model for TE Topologies", draft- [TE-TOPO] Liu, X. et al., "YANG Data Model for TE Topologies",
ietf-teas-yang-te-topo, work in progress. draft-ietf-teas-yang-te-topo, work in progress.
[OTN-TOPO] Zheng, H. et al., "A YANG Data Model for Optical Transport [OTN-TOPO] Zheng, H. et al., "A YANG Data Model for Optical
Network Topology", draft-ietf-ccamp-otn-topo-yang, work in Transport Network Topology", draft-ietf-ccamp-otn-topo-
progress. yang, work in progress.
[CLIENT-TOPO] Zheng, H. et al., "A YANG Data Model for Client-layer [CLIENT-TOPO] Zheng, H. et al., "A YANG Data Model for Client-layer
Topology", draft-zheng-ccamp-client-topo-yang, work in Topology", draft-zheng-ccamp-client-topo-yang, work in
progress. progress.
[TE-TUNNEL] Saad, T. et al., "A YANG Data Model for Traffic [TE-TUNNEL] Saad, T. et al., "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.
[PATH-COMPUTE] Busi, I., Belotti, S. et al, "Yang model for [PATH-COMPUTE] Busi, I., Belotti, S. et al, "Yang model for
requesting Path Computation", draft-ietf-teas-yang-path- requesting Path Computation", draft-ietf-teas-yang-path-
computation, work in progress. computation, work in progress.
[OTN-TUNNEL] Zheng, H. et al., "OTN Tunnel YANG Model", draft-ietf- [OTN-TUNNEL] Zheng, H. et al., "OTN Tunnel YANG Model", draft-
ccamp-otn-tunnel-model, work in progress. ietf-ccamp-otn-tunnel-model, work in progress.
[CLIENT-SVC] Zheng, H. et al., "A YANG Data Model for Optical [CLIENT-SIGNAL] Zheng, H. et al., "A YANG Data Model for Optical
Transport Network Client Signals", draft-zheng-ccamp-otn- Transport Network Client Signals", draft-zheng-ccamp-otn-
client-signal-yang, work in progress. client-signal-yang, work in progress.
8.2. Informative References 8.2. Informative References
[RFC5151] Farrel, A. et al., "Inter-Domain MPLS and GMPLS Traffic [RFC5151] Farrel, A. et al., "Inter-Domain MPLS and GMPLS Traffic
Engineering --Resource Reservation Protocol-Traffic Engineering --Resource Reservation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 5151, February 2008. Engineering (RSVP-TE) Extensions", RFC 5151, February
2008.
[RFC6898] Li, D. et al., "Link Management Protocol Behavior [RFC6898] Li, D. et al., "Link Management Protocol Behavior
Negotiation and Configuration Modifications", RFC 6898, Negotiation and Configuration Modifications", RFC 6898,
March 2013. March 2013.
[RFC8040] Bierman, A. et al., "RESTCONF Protocol", RFC 8040, January [RFC8040] Bierman, A. et al., "RESTCONF Protocol", RFC 8040, January
2017. 2017.
[RFC8309] Wu, Q. et al., "Service Models Explained", RFC 8309, [RFC8309] Wu, Q. et al., "Service Models Explained", RFC 8309,
January 2018. January 2018.
[ACTN-YANG] Zhang, X. et al., "Applicability of YANG models for [ACTN-YANG] Zhang, X. et al., "Applicability of YANG models for
Abstraction and Control of Traffic Engineered Networks", Abstraction and Control of Traffic Engineered Networks",
draft-zhang-teas-actn-yang, work in progress. draft-zhang-teas-actn-yang, work in progress.
[RFC-FOLD] Watsen, K. et al., "Handling Long Lines in Artwork in [RFC-FOLD] Watsen, K. et al., "Handling Long Lines in Artwork in
Internet-Drafts and RFCs", work in progress Internet-Drafts and RFCs", draft-ietf-netmod-artwork-
folding, work in progress
[TE-TUTORIAL] Bryskin, I. et al., "TE Topology and Tunnel Modeling
for Transport Networks", draft-ietf-teas-te-topo-and-
tunnel-modeling, work in progress
[ONF TR-527] ONF Technical Recommendation TR-527, "Functional [ONF TR-527] ONF Technical Recommendation TR-527, "Functional
Requirements for Transport API", June 2016. Requirements for Transport API", June 2016.
[ONF GitHub] ONF Open Transport (SNOWMASS) [ONF GitHub] ONF Open Transport (SNOWMASS),
https://github.com/OpenNetworkingFoundation/Snowmass- <https://github.com/OpenNetworkingFoundation/Snowmass-
ONFOpenTransport ONFOpenTransport>
[MEF 55] Metro Ethernet Forum, "Lifecycle Service Orchestration
(LSO): Reference Architecture and Framework", Technical
Specification MEF 55, March 2016,
<https://www.mef.net/Assets/Technical_Specifications/PDF/M
EF_55.pdf>
9. Acknowledgments 9. Acknowledgments
The authors would like to thank all members of the Transport NBI The authors would like to thank all members of the Transport NBI
Design Team involved in the definition of use cases, gap analysis Design Team involved in the definition of use cases, gap analysis
and guidelines for using the IETF YANG models at the Northbound and guidelines for using the IETF YANG models at the Northbound
Interface (NBI) of a Transport SDN Controller. Interface (NBI) of a Transport SDN Controller.
The authors would like to thank Xian Zhang, Anurag Sharma, Sergio The authors would like to thank Xian Zhang, Anurag Sharma, Sergio
Belotti, Tara Cummings, Michael Scharf, Karthik Sethuraman, Oscar Belotti, Tara Cummings, Michael Scharf, Karthik Sethuraman, Oscar
Gonzalez de Dios, Hans Bjursrom and Italo Busi for having initiated Gonzalez de Dios, Hans Bjursrom and Italo Busi for having initiated
the work on gap analysis for transport NBI and having provided the work on gap analysis for transport NBI and having provided
foundations work for the development of this document. foundations work for the development of this document.
The authors would like to thank the authors of the TE Topology and The authors would like to thank the authors of the TE Topology and
Tunnel YANG models [TE-TOPO] and [TE-TUNNEL], in particular Igor Tunnel YANG models [TE-TOPO] and [TE-TUNNEL], in particular, Igor
Bryskin, Vishnu Pavan Beeram, Tarek Saad and Xufeng Liu, for their Bryskin, Vishnu Pavan Beeram, Tarek Saad and Xufeng Liu, for their
support in addressing any gap identified during the analysis work. support in addressing any gap identified during the analysis work.
The authors would like to thank Henry Yu and Aihua Guo for their The authors would like to thank Henry Yu and Aihua Guo for their
input and review of the URIs structures used within the JSON code input and review of the URIs structures used within the JSON code
examples. examples.
This work was supported in part by the European Commission funded
H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727).
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
Appendix A. Validating a JSON fragment against a YANG Model Appendix A. Validating a JSON fragment against a YANG Model
The objective is to have a tool that allows validating whether a The objective is to have a tool that allows validating whether a
piece of JSON code embedded in an Internet-Draft is compliant with a piece of JSON code embedded in an Internet-Draft is compliant with a
YANG model without using a client/server. YANG model without using a client/server.
A.1. Manipulation of JSON fragments A.1. Manipulation of JSON fragments
This section describes the various ways JSON fragments are used in This section describes the various ways JSON fragments are used in
the I-D processing and how to manage them. the I-D processing and how to manage them.
Let's call "folded-JSON" the JSON embedded in the I-D: it fits the 72 Let's call "folded-JSON" the JSON embedded in the I-D: it fits the
chars width and it is acceptable for it to be invalid JSON. 72 chars width and it is acceptable for it to be invalid JSON.
We then define "unfolded-JSON" a valid JSON fragment having the same We then define "unfolded-JSON" a valid JSON fragment having the same
contents of the "folded-JSON " without folding, i.e. limits on the contents of the "folded-JSON " without folding, i.e. limits on the
text width. The folding/unfolding operation may be done according to text width. The folding/unfolding operation may be done according to
draft-kwatsen-netmod-artwork-folding. The "unfolded-JSON" can be [RFC-FOLD]. The "unfolded-JSON" can be edited by the authors using
edited by the authors using JSON editors with the advantages of JSON editors with the advantages of syntax validation and pretty-
syntax validation and pretty-printing. printing.
Both the "folded" and the "unfolded" JSON fragments can include Both the "folded" and the "unfolded" JSON fragments can include
comments having descriptive fields and directives we'll describe comments having descriptive fields and directives we'll describe
later to facilitate the reader and enable some automatic processing. later to facilitate the reader and enable some automatic processing.
The presence of comments in the "unfolded-JSON" fragment makes it an The presence of comments in the "unfolded-JSON" fragment makes it an
invalid JSON encoding of YANG data. Therefore we call "naked JSON" invalid JSON encoding of YANG data. Therefore we call "naked JSON"
the JSON where the comments have been stripped out: not only it is the JSON where the comments have been stripped out: not only it is
valid JSON but it is a valid JSON encoding of YANG data. valid JSON but it is a valid JSON encoding of YANG data.
skipping to change at page 48, line 16 skipping to change at page 50, line 16
Our validation toolchain has been designed to take a JSON in any of Our validation toolchain has been designed to take a JSON in any of
the three formats and validate it automatically against a set of the three formats and validate it automatically against a set of
relevant YANG modules using available open-source tools. It can be relevant YANG modules using available open-source tools. It can be
found at: https://github.com/GianmarcoBruno/json-yang/ found at: https://github.com/GianmarcoBruno/json-yang/
A.2. Comments in JSON fragments A.2. Comments in JSON fragments
We found useful to introduce two kinds of comments, both defined as We found useful to introduce two kinds of comments, both defined as
key-value pairs where the key starts with "//": key-value pairs where the key starts with "//":
- free-form descriptive comments, e.g."// COMMENT" : "refine this" to - free-form descriptive comments, e.g."// COMMENT" : "refine this"
describe properties of JSON fragments. to describe properties of JSON fragments.
- machine-usable directives e.g. "// __REFERENCES__DRAFTS__" : { - machine-usable directives e.g. "// __REFERENCES__DRAFTS__" : {
"ietf-routing-types@2017-12-04": "rfc8294",} which can be used to "ietf-routing-types@2017-12-04": "rfc8294",} which can be used to
automatically download from the network the relevant I-Ds or RFCs and automatically download from the network the relevant I-Ds or RFCs
extract from them the YANG models of interest. This is particularly and extract from them the YANG models of interest. This is
useful to keep consistency when the drafting work is rapidly particularly useful to keep consistency when the drafting work is
evolving. rapidly evolving.
A.3. Validation of JSON fragments: DSDL-based approach A.3. Validation of JSON fragments: DSDL-based approach
The idea is to generate a JSON driver file (JTOX) from YANG, then use The idea is to generate a JSON driver file (JTOX) from YANG, then
it to translate JSON to XML and validate it against the DSDL schemas, use it to translate JSON to XML and validate it against the DSDL
as shown in Figure 8. schemas, as shown in Figure 8.
Useful link: https://github.com/mbj4668/pyang/wiki/XmlJson Useful link: https://github.com/mbj4668/pyang/wiki/XmlJson
(2) (2)
YANG-module ---> DSDL-schemas (RNG,SCH,DSRL) YANG-module ---> DSDL-schemas (RNG,SCH,DSRL)
| | | |
| (1) | | (1) |
| | | |
Config/state JTOX-file | (4) Config/state JTOX-file | (4)
\ | | \ | |
\ | | \ | |
\ V V \ V V
JSON-file------------> XML-file ----------------> Output JSON-file------------> XML-file ----------------> Output
skipping to change at page 49, line 19 skipping to change at page 51, line 6
Config/state JTOX-file | (4) Config/state JTOX-file | (4)
\ | | \ | |
\ | | \ | |
\ V V \ V V
JSON-file------------> XML-file ----------------> Output JSON-file------------> XML-file ----------------> Output
(3) (3)
Figure 8 - DSDL-based approach for JSON code validation Figure 8 - DSDL-based approach for JSON code validation
In order to allow the use of comments following the convention In order to allow the use of comments following the convention
defined in section 3without impacting the validation process, these defined in section 3, without impacting the validation process,
comments will be automatically removed from the JSON-file that will these comments will be automatically removed from the JSON-file that
be validate. will be validate.
A.4. Validation of JSON fragments: why not using a XSD-based approach A.4. Validation of JSON fragments: why not using a XSD-based approach
This approach has been analyzed and discarded because no longer This approach has been analyzed and discarded because no longer
supported by pyang. supported by pyang.
The idea is to convert YANG to XSD, JSON to XML and validate it The idea is to convert YANG to XSD, JSON to XML and validate it
against the XSD, as shown in Figure 9: against the XSD, as shown in Figure 9:
(1) (1)
YANG-module ---> XSD-schema - \ (3) YANG-module ---> XSD-schema - \ (3)
+--> Validation +--> Validation
JSON-file------> XML-file ----/ JSON-file------> XML-file ----/
(2) (2)
Figure 9 - XSD-based approach for JSON code validation Figure 9 - XSD-based approach for JSON code validation
The pyang support for the XSD output format was deprecated in 1.5 and The pyang support for the XSD output format was deprecated in 1.5
removed in 1.7.1. However pyang 1.7.1 is necessary to work with YANG and removed in 1.7.1. However pyang 1.7.1 is necessary to work with
1.1 so the process shown in Figure 9 will stop just at step (1). YANG 1.1 so the process shown in Figure 9 will stop just at step
(1).
Appendix B. Detailed JSON Examples Appendix B. Detailed JSON Examples
The JSON code examples provided in this appendix have been validated The JSON code examples provided in this appendix have been validated
using the tools in Appendix A and folded using the tool in [RFC- using the tools in Appendix A and folded using the tool in [RFC-
FOLD]. FOLD].
B.1. JSON Examples for Topology Abstractions B.1. JSON Examples for Topology Abstractions
B.1.1. JSON Code: mpi1-otn-topology.json B.1.1. JSON Code: mpi1-otn-topology.json
skipping to change at page 71, line 12 skipping to change at page 73, line 12
https://github.com/danielkinguk/transport-nbi https://github.com/danielkinguk/transport-nbi
Authors' Addresses Authors' Addresses
Italo Busi (Editor) Italo Busi (Editor)
Huawei Huawei
Email: italo.busi@huawei.com Email: italo.busi@huawei.com
Daniel King (Editor) Daniel King (Editor)
Lancaster University Old Dog Consulting
Email: d.king@lancaster.ac.uk Email: daniel@olddog.co.uk
Haomian Zheng (Editor) Haomian Zheng (Editor)
Huawei Huawei
Email: zhenghaomian@huawei.com Email: zhenghaomian@huawei.com
Yunbin Xu (Editor) Yunbin Xu (Editor)
CAICT CAICT
Email: xuyunbin@ritt.cn Email: xuyunbin@ritt.cn
 End of changes. 257 change blocks. 
1024 lines changed or deleted 1164 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/