draft-ietf-ccamp-transport-nbi-app-statement-03.txt   draft-ietf-ccamp-transport-nbi-app-statement-04.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 Lancaster University
H. Zheng H. Zheng
Huawei Huawei
Y. Xu Y. Xu
CAICT CAICT
Expires: April 2019 October 22, 2018 Expires: May 2019 November 4, 2018
Transport Northbound Interface Applicability Statement Transport Northbound Interface Applicability Statement
draft-ietf-ccamp-transport-nbi-app-statement-03 draft-ietf-ccamp-transport-nbi-app-statement-04
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 Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other documents and may be updated, replaced, or obsoleted by other documents at any
at any time. It is inappropriate to use Internet-Drafts as time. It is inappropriate to use Internet-Drafts as reference
reference material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 22, 2019. This Internet-Draft will expire on May 4, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with respect
respect to this document. Code Components extracted from this to this document. Code Components extracted from this document must
document must include Simplified BSD License text as described in include Simplified BSD License text as described in Section 4.e of
Section 4.e of the Trust Legal Provisions and are provided without the Trust Legal Provisions and are provided without warranty as
warranty as described in the Simplified BSD License. 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.
skipping to change at page 2, line 26 skipping to change at page 2, line 41
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 IETF (TEAS and CCAMP WGs in particular) to support OTN
single and multi-domain scenarios. 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 7 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.1.1. Single-Domain Scenario..............................12
4.2. Topology Abstractions 12 4.2. Topology Abstractions....................................12
4.3. Service Configuration 14 4.3. Service Configuration....................................14
4.3.1. ODU Transit 15 4.3.1. ODU Transit.........................................15
4.3.2. EPL over ODU 16 4.3.2. EPL over ODU........................................16
4.3.3. Other OTN Clients Services 17 4.3.3. Other OTN Clients Services..........................17
4.3.4. EVPL over ODU 18 4.3.4. EVPL over ODU.......................................18
4.3.5. EVPLAN and EVPTree Services 18 4.3.5. EVPLAN and EVPTree Services.........................19
4.3.6. Dynamic Service Configuration 20 4.3.6. Dynamic Service Configuration.......................20
4.4. Multi-function Access Links 21 4.4. Multi-function Access Links..............................21
4.5. Protection and Restoration Configuration 22 4.5. Protection and Restoration Configuration.................22
4.5.1. Linear Protection (end-to-end) .................... 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.5.3. End-to-End Dynamic restoration......................24
4.5.4. Segmented Dynamic Restoration 24 4.5.4. Segmented Dynamic Restoration.......................25
4.6. Service Modification and Deletion 25 4.6. Service Modification and Deletion........................25
4.7. Notification 25 4.7. Notification.............................................25
4.8. Path Computation with Constraint 26 4.8. Path Computation with Constraint.........................26
5. YANG Model Analysis...........................................27
5. YANG Model Analysis 27 5.1. YANG Models for Topology Abstraction.....................27
5.1. YANG Models for Topology Abstraction 27 5.1.1. Domain 1 Black Topology Abstraction.................28
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 30 5.1.4. Multi-domain Topology Stitching.....................31
5.1.4. Multi-domain Topology Stitching 31 5.1.5. Access Links........................................33
5.1.5. Access Links 33 5.2. YANG Models for Service Configuration....................35
5.2. YANG Models for Service Configuration .................. 35 5.2.1. ODU Transit Service.................................37
5.2.1. ODU Transit Service 37 5.2.1.1. Single Domain Example..........................39
5.2.1.1. Single Domain Example 39 5.2.2. EPL over ODU Service................................40
5.2.2. EPL over ODU Service 40 5.2.3. Other OTN Client Services...........................42
5.2.3. Other OTN Client Services ......................... 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 43 5.3.1. Linear Protection (end-to-end)......................43
5.3.1. Linear Protection (end-to-end) 43 5.3.2. Segmented Protection................................43
5.3.2. Segmented Protection 43 6. Security Considerations.......................................43
6. Security Considerations 44 7. IANA Considerations...........................................44
7. IANA Considerations 44 8. References....................................................44
8. References 44 8.1. Normative References.....................................44
8.1. Normative References 44 8.2. Informative References...................................45
8.2. Informative References 45 9. Acknowledgments...............................................46
9. Acknowledgments 46 Appendix A. Validating a JSON fragment against a YANG Model...47
Validating a JSON fragment against a YANG Model 47 A.1. Manipulation of JSON fragments..........................47
A.1. Manipulation of JSON fragments 47 A.2. Comments in JSON fragments..............................48
A.2. Comments in JSON fragments 48 A.3. Validation of JSON fragments: DSDL-based approach.......48
A.3. Validation of JSON fragments: DSDL-based approach 48 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 49 Appendix B. Detailed JSON Examples............................50
Detailed JSON Examples 50 B.1. JSON Examples for Topology Abstractions.................50
B.1. JSON Examples for Topology Abstractions 50 B.1.1. JSON Code: mpi1-otn-topology.json.................50
B.1.1. JSON Code: mpi1-otn-topology.json 50 B.2. JSON Examples for Service Configuration.................66
B.2. JSON Examples for Service Configuration 68 B.2.1. JSON Code: mpi1-odu2-service-config.json..........66
B.2.1. JSON Code: mpi1-odu2-service-config.json 68 B.2.2. JSON Code: mpi1-odu2-tunnel-config.json...........70
B.2.2. JSON Code: mpi1-odu2-tunnel-config.json 72 B.2.3. JSON Code: mpi1-epl-service-config.json...........70
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 will be 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., [RESTCONF]). (e.g., [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 (TEAS and CCAMP WGs in particular) to support OTN
single and multi-domain scenarios. 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 This document assumes a reference architecture, including interfaces,
interfaces, based on the Abstraction and Control of Traffic- based on the Abstraction and Control of Traffic-Engineered Networks
Engineered Networks (ACTN), defined in [ACTN-Frame]. (ACTN), defined in [RFC8453].
The focus of this document is on the MPI (interface between the The focus of this document is on the MPI (interface between the Multi
Multi Domain Service Coordinator (MDSC) and a Physical Network Domain Service Coordinator (MDSC) and a Physical Network Controller
Controller (PNC), controlling a transport network domain). (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 [ACTN-Frame]. 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 could be described when needed.
The relationship between the current IETF YANG models and the type The relationship between the current IETF YANG models and the type of
of ACTN interfaces can be found in [ACTN-YANG]. Therefore, it ACTN interfaces can be found in [ACTN-YANG]. Therefore, it considers
considers the TE Topology YANG model defined in [TE-TOPO], with the the TE Topology YANG model defined in [TE-TOPO], with the OTN
OTN Topology augmentation defined in [OTN-TOPO] and the TE Tunnel Topology augmentation defined in [OTN-TOPO] and the TE Tunnel YANG
YANG model defined in [TE-TUNNEL], with the OTN Tunnel augmentation model defined in [TE-TUNNEL], with the OTN Tunnel augmentation
defined in [OTN-TUNNEL]. defined in [OTN-TUNNEL].
[Editors' note:] Add information about the additional models which The ONF Technical Recommendations for Functional Requirements for the
are needed for service configuration. transport API in [ONF TR-527] and the ONF transport API multi-domain
examples in [ONF GitHub] have been considered as input for defining
The ONF Technical Recommendations for Functional Requirements for the reference scenarios analyzed in this document.
the transport API in [ONF TR-527] and the ONF transport API multi-
domain examples in [ONF GitHub] have been considered as input for
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, still to be
validated with TEAS WG: 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 that PNC, the MDSC would not specify any source or destination TTP
TTP (i.e., it would leave the source, destination, src-tp-id and (i.e., it would leave the source, destination, src-tp-id and dst-
dst-tp-id attributes empty) for the tunnel and it would use the tp-id attributes empty) for the tunnel and it would use the
explicit-route-object/route-object-include-exclude list to explicit-route-object/route-object-include-exclude list to specify
specify the ingress and egress links for each path of the Transit the ingress and egress links for each path of the Transit Tunnel
Tunnel Segment. 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 model and OTN Topology augmentation. The TE Topology YANG model in
in [TE-TOPO] is being updated to report the label set [TE-TOPO] is being updated to report the label set information.
information.
[Editors' note:] These assumptions should be described in the TE
Tutorial and removed from this section (need to check the TE
Tutorial document).
This document is also making the following assumptions, still to be This document is also making the following assumptions, still to be
validated with CCAMP WG: validated with CCAMP WG:
1. The topology information for the Ethernet access links is 1. The topology information for the Ethernet access links is modelled
modelled using the YANG model defined in [Client-Topo]. using the YANG model defined in [CLIENT-TOPO].
2. The service information for Ethernet and other OTN client layer 2. The service information for Ethernet and other OTN client layer
services are modelled using the YANG model defined in [Client- services are modelled using the YANG model defined in [Client-
Signal]. 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 in document are using ODU switching. It is assumed that the ODU links
links are pre-configured and using mechanisms such as WDM are pre-configured and using mechanisms such as WDM wavelength, which
wavelength, which are outside the scope of this document. are outside the scope of this document.
2. Terminology 2. Terminology
Domain: defined as a collection of network elements within a common Domain: defined as a collection of network elements within a common
realm of address space or path computation responsibility [RFC5151] realm of address space or path computation responsibility [RFC5151]
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 uniformly and independent of the equipment and operating environment.
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 MAC Bridging: Virtual LANs (VLANs) on IEEE 802.3 Ethernet network
[Editors' note:] Add terminology for end-to-end data plane
connection, data plane segment connection.
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>)}
skipping to change at page 7, line 31 skipping to change at page 7, line 31
switching with client/server adaptation: "([client] -> [server])". switching with client/server adaptation: "([client] -> [server])".
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 then sends it to S6 which finally sends to R3. Node R3 terminates the
the ODU2 from S6 before switching at the packet (PKT) layer. 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 case of
bidirectional paths, the forward and backward directions are bidirectional paths, the forward and backward directions are selected
selected arbitrarily, but the convention is consistent between 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 IETF (TEAS and CCAMP WG in
particular) can be used. particular) can be used.
The examples are provided using JSON because JSON code is easier for The examples are provided using JSON because JSON code is easier for
humans to read and write. 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 JSON language does not support the insertion of comments that have
been instead found to be useful when writing the examples. This 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. pair with the JSON name string starting with the "//" characters. For
For example, when describing the example of a TE Topology instance 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 against the YANG models following the validation process described in
in Appendix A, which would not consider the comments. 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 first step of the validation process while the second JSON name/value
name/value pair will be validated against the YANG model pair will be validated against the YANG model definitions.
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 providing transport services to an IP customer network
through eight access links: 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 --------- R7
: : \ / \ \ | : : / \ : : : : \ / \ \ | : : / \ : :
: : S6 ---- S7 ---- S8 ------ S32 S33 ------ R8 : : S6 ---- S7 ---- S8 ------ S32 S33 ------ R8
: : / | | : : / \ / : :....... : : / | | : : / \ / : :.......
R3 ------+ | | : :/ S34 : : R3 ------+ | | : :/ S34 : :
: :..........|.......|...: / / : : : :..........|.......|...: / / : :
........: | | /:.../.......: : ........: | | /:.../.......: :
| | / / : | | / / :
...........|.......|..../..../... : ...........|.......|..../..../... :
: | | / / : .............. : | | / / : ..............
: Network | | / / : : : Network | | / / : :
: domain 2 | | / / : :Customer : domain 2 | | / / : :Customer
: S11 ---- S12 / : : domain : S11 ---- S12 / : : domain
: / | \ / : : : / | \ / : :
: S13 S14 | S15 ------------- R4 : S13 S14 | S15 ------------- R4
: | \ / \ | \ : : : | \ / \ | \ : :
: | S16 \ | \ : : : | S16 \ | \ : :
skipping to change at page 10, line 8 skipping to change at page 10, line 43
: | / \ / : : : | / \ / : :
: S19 ---- S20 ---- S21 ------------ R6 : S19 ---- S20 ---- S21 ------------ R6
: : : : : :
:...............................: :............. :...............................: :.............
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 OTN switching nodes capable of switching in the electrical
domain (ODU switching) and that all the Si-Sj OTN links within the domain (ODU switching) and that all the Si-Sj OTN links within the
transport network (intra-domain or inter-domain) are 100G links transport network (intra-domain or inter-domain) are 100G links while
while the access Ri-Sj links are 10G links. Different technologies the access Ri-Sj links are 10G links. Different technologies can be
can be used at the access links (e.g., Ethernet, STM-n, OTN). 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 outside the scope of this document and are not exposed at the MPIs to
to the MDSC. the MDSC.
The transport domain control architecture, shown in Figure 2, The transport domain control architecture, shown in Figure 2, follows
follows the ACTN architecture and framework document [ACTN-Frame], the ACTN architecture and framework document [RFC8453], and
and functional components: functional components:
-------------- --------------
| | | |
| CNC | | CNC |
| | | |
-------------- --------------
| |
....................|....................... CMI ....................|....................... CMI
| |
---------------- ----------------
skipping to change at page 11, line 43 skipping to change at page 12, line 6
( Domain 1 ) ----- ( ) ( Domain 1 ) ----- ( )
( ) ( Network ) ( ) ( Network )
( ) ( Domain 3 ) ( ) ( Domain 3 )
----- ( ) ----- ( )
( ) ( )
----- -----
Figure 2 - Controlling Hierarchy Figure 2 - Controlling Hierarchy
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 service control from the underlying technology and helps the customer
customer express the network as desired by business needs. express the network as desired by business needs. Therefore, care
Therefore, care must be taken to keep a minimal dependency on the must be taken to keep a minimal dependency on the CMI (or no
CMI (or no dependency at all) with respect to the network domain dependency at all) with respect to the network domain technologies.
technologies. The MPI instead requires some specialization according The MPI instead requires some specialization according to the domain
to the domain technology. technology.
This document assumes that the CNC controls the customer IP network This document assumes that the CNC controls the customer IP network
and requests, at the CMI, transport connectivity between IP routers. and requests, at the CMI, transport connectivity between IP routers.
The MDSC coordinates, via three MPIs, the control of a multi-domain The MDSC coordinates, via three MPIs, the control of a multi-domain
transport network through three PNCs. 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 three MPIs, while the control interface(s) between the CNC and the IP
IP routers is outside the scope of this document. It is also assumed 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 that the CMI allows the CNC to provide all the information that is
required by the MDSC to properly configure the transport required by the MDSC to properly configure the transport connectivity
connectivity requested by the customer. requested by the customer.
[Editors' note:] Check the assumption above with the latest version
of the ACTN framework: it is the CNC or "something" above the CNC
which controls the customer IP network
In case the CNC requests transport connectivity between IP routers In case the CNC requests transport connectivity between IP routers
attached to different transport domains (e.g., between R1 and R5), attached to different transport domains (e.g., between R1 and R5),
the MDSC coordinates the setup of a multi-domain end-to-end OTN the MDSC coordinates the setup of a multi-domain end-to-end OTN
connection across multiple PNCs (e.g., PNC1, PNC2 and PNC3 in in connection across multiple PNCs (e.g., PNC1, PNC2 and PNC3 in in
Figure 2) as well as the configuration of the client signal mapping Figure 2) as well as the configuration of the client signal mapping
at the PNCs controlling the edge domains (e.g., PNC1 and PNC2 in at the PNCs controlling the edge domains (e.g., PNC1 and PNC2 in
Figure 2). Figure 2).
4.1.1. Single-Domain Scenario 4.1.1. Single-Domain Scenario
skipping to change at page 12, line 43 skipping to change at page 12, line 47
Figure 1), the MDSC can request the PNC controlling that domain Figure 1), the MDSC can request the PNC controlling that domain
(e.g., PNC1 in Figure 2) to setup an intra-domain end-to-end OTN (e.g., PNC1 in Figure 2) to setup an intra-domain end-to-end OTN
connection and configure the client signal mapping. connection and configure the client signal mapping.
Alternatively, the MDSC can just configure the client signal mapping Alternatively, the MDSC can just configure the client signal mapping
and let the PNC take decisions about how to implement the service and let the PNC take decisions about how to implement the service
(e.g., setting up the intra-domain end-to-end OTN connection). (e.g., setting up the intra-domain end-to-end OTN connection).
4.2. Topology Abstractions 4.2. Topology Abstractions
Abstraction provides a selective method for representing Abstraction provides a selective method for representing connectivity
connectivity information within a domain. There are multiple methods information within a domain. There are multiple methods to abstract a
to abstract a network topology. This document assumes the network topology. This document assumes the abstraction method
abstraction method defined in [RFC7926]: defined in [RFC7926]:
"Abstraction is the process of applying the policy to the "Abstraction is the process of applying the policy to the available
available TE information within a domain, to produce selective TE information within a domain, to produce selective information
information that represents the potential ability to connect that represents the potential ability to connect across the domain.
across the domain. Thus, abstraction does not necessarily offer Thus, abstraction does not necessarily offer all possible
all possible connectivity options, but presents a general view of connectivity options, but presents a general view of potential
potential connectivity according to the policies that determine connectivity according to the policies that determine how the
how the domain's administrator wants to allow the domain resources domain's administrator wants to allow the domain resources to be
to be used." used."
[ACTN-Frame] Provides the context of topology abstraction in the [RFC8453] Provides the context of topology abstraction in the ACTN
ACTN architecture and discusses a few alternatives for the architecture and discusses a few alternatives for the abstraction
abstraction methods for both packet and optical networks. This is an methods for both packet and optical networks. This is an important
important consideration since the choice of the abstraction method consideration since the choice of the abstraction method impacts
impacts protocol design and the information it carries. According protocol design and the information it carries. According to
to [ACTN-Frame], 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
this case, the MDSC has the full knowledge of the underlying this case, the MDSC has the full knowledge of the underlying
network topology; network topology;
o Black topology: The entire domain network is abstracted as a o Black topology: The entire domain network is abstracted as a
single virtual node with the access/egress links without single virtual node with the access/egress links without
disclosing any node internal connectivity information; disclosing any node internal connectivity information;
o Grey topology: This abstraction level is between black topology o Grey topology: This abstraction level is between black topology
and white topology from a granularity point of view. This is an and white topology from a granularity point of view. This is an
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 topology abstraction of the
domain's network topology. domain's network topology.
Each PNC provides topology abstraction of its own domain topology Each PNC provides topology abstraction of its own domain topology
independently from each other, and therefore it is possible that independently from each other, and therefore it is possible that
different PNCs provide different types of topology abstractions. different PNCs provide different types of topology abstractions.
The MPI operates on the abstract topology regardless of, and The MPI operates on the abstract topology regardless of, and
independently from, the type of abstraction provided by the PNC. independently from, the type of abstraction provided by the PNC.
To analyze how the MPI operates on abstract topologies independently To analyze how the MPI operates on abstract topologies independently
from the topology abstraction provided by each PNC and, therefore, from the topology abstraction provided by each PNC and, therefore,
that different PNCs can provide different topology abstractions, that different PNCs can provide different topology abstractions, that
that the following examples are assumed: the following examples are assumed:
o PNC1 provides a black topology abstraction which exposes at MPI1 o PNC1 provides a black topology abstraction which exposes at MPI1 a
a single virtual node (representing the whole network domain 1). single virtual node (representing the whole network domain 1).
o PNC2 provides a black topology abstraction which exposes at MPI2 o PNC2 provides a black topology abstraction which exposes at MPI2 a
a single virtual node (representing the whole network domain 2). single virtual node (representing the whole network domain 2).
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.
[Editors' note:] Evaluate whether to change the description of the
PNC2 abstraction to provide an example of a grey topology
abstraction (pending discussion about grey topology abstraction)
The MDSC should be capable of stitching together each abstracted The MDSC should be capable of stitching together each abstracted
topology to build its own view of the multi-domain network topology. topology to build its own view of the multi-domain network topology.
The process may require suitable oversight, including administrative The process may require suitable oversight, including administrative
configuration and trust models, but this is out of scope for this configuration and trust models, but this is out of scope for this
document. document.
The MDSC can also provide topology abstraction of its own view of The MDSC can also provide topology abstraction of its own view of the
the multi-domain network topology at its CMIs depending on the multi-domain network topology at its CMIs depending on the customers'
customers' needs: it can provide different types of topology needs: it can provide different types of topology abstractions at
abstractions at different CMIs. different CMIs.
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 The type of services could depend on the type of physical links (e.g.
(e.g. OTN link, ETH link or SDH link) between the routers and OTN link, ETH link or SDH link) between the routers and transport
transport network. 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 are not under the control of, and not visible to, the MDSC nor to the
the PNCs. Therefore, these mechanisms are outside the scope of this PNCs. Therefore, these mechanisms are outside the scope of this
document. document.
It is just assumed that the CNC is capable of requesting the proper It is just assumed that the CNC is capable of requesting the proper
configuration of the different adaptation functions inside the configuration of the different adaptation functions inside the
customer's IP routers, by means which are outside the scope of this 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. In this case, it is assumed that the
physical/optical interconnections below the ODU layer (up to the physical/optical interconnections below the ODU layer (up to the OTU2
OTU2 trail) are pre-configured using mechanisms which are outside trail) are pre-configured using mechanisms which are outside the
the scope of this document and not exposed at the MPIs between the scope of this document and not exposed at the MPIs between the PNCs
PNCs and the MDSC. For simplicity of the description, it is also and the MDSC. For simplicity of the description, it is also assumed
assumed that these interfaces are not channelized (i.e., they can that these interfaces are not channelized (i.e., they can only
only support one ODU2). support one ODU2).
To setup a 10Gb IP link between R1 and R5, an ODU2 end-to-end To setup a 10Gb IP link between R1 and R5, an ODU2 end-to-end
connection needs be created in the data plane between R1 and R5, connection needs be created in the data plane between R1 and R5,
through transport nodes S3, S1, S2, S31, S33, S34, S15 and S18 which through transport nodes S3, S1, S2, S31, S33, S34, S15 and S18 which
belong to different PNC domains (multi-domain service request): belong to different PNC domains (multi-domain service request):
R1 ([PKT] -> ODU2), S3 ([ODU2]), S1 ([ODU2]), S2 ([ODU2]), R1 ([PKT] -> ODU2), S3 ([ODU2]), S1 ([ODU2]), S2 ([ODU2]),
S31 ([ODU2]), S33 ([ODU2]), S34 ([ODU2]), S31 ([ODU2]), S33 ([ODU2]), S34 ([ODU2]),
S15 ([ODU2]), S18 ([ODU2]), R5 (ODU2 -> [PKT]) S15 ([ODU2]), S18 ([ODU2]), R5 (ODU2 -> [PKT])
It is assumed that, at the CMI, the CNC requests, using mechanisms It is assumed that, at the CMI, the CNC requests, using mechanisms
which are outside the scope of this document, the MDSC to setup of which are outside the scope of this document, the MDSC to setup of an
an ODU2 transit service between the access links on S3 and S8 and ODU2 transit service between the access links on S3 and S8 and that
that the MDSC understands that it shall setup an ODU2 segment the MDSC understands that it shall setup an ODU2 segment connection
connection between the access links on S3 and S18, which belongs to between the access links on S3 and S18, which belongs to different
different PNC domains (multi-domain service request). PNC domains (multi-domain service request).
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 are created in the data plane between R1 and R3,
through transport nodes S3, S5 and S6 which belong to the same PNC through transport nodes S3, S5 and S6 which belong to the same PNC
domain (single-domain service request): domain (single-domain service 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 Since the CNC is not aware of the transport network controlling
hierarchy, the mechanisms used by the CNC to request at the CMI the hierarchy, the mechanisms used by the CNC to request at the CMI the
MDSC to setup an ODU2 transit service are independent on whether the MDSC to setup an ODU2 transit service are independent on whether the
service request is single-domain or multi-domain. service request is single-domain or multi-domain.
Based on the assumption above, the MDSC understands that it shall Based on the assumption above, the MDSC understands that it shall
setup an ODU2 segment connection between the access links on S3 and setup an ODU2 segment connection between the access links on S3 and
S6, which belong to the same PNC domain (single-domain service S6, which belong to the same PNC domain (single-domain service
request) and it can just pass the request at the MPI to PNC1 to request) and it can just pass the request at the MPI to PNC1 to setup
setup a single-domain ODU2 segment connection between its access a single-domain ODU2 segment connection between its access links on
links on S3 and S6. 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 Ethernet physical links.
To setup a 10Gb IP link between R1 and R5, an EPL service needs to To setup a 10Gb IP link between R1 and R5, an EPL service needs to be
be created between R1 and R5, supported by an ODU2 end-to-end created between R1 and R5, supported by an ODU2 end-to-end connection
connection in the data plane between transport nodes S3 and S18, in the data plane between transport nodes S3 and S18, through
through transport nodes S1, S2, S31, S33, S34 and S15, which belong transport nodes S1, S2, S31, S33, S34 and S15, which belong to
to different PNC domains (multi-domain service request: different PNC domains (multi-domain service request:
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), R5 (ETH -> [PKT])
Based on the assumptions described in section 4.3.1, the CNC Based on the assumptions described in section 4.3.1, the CNC requests
requests at the CMI the MDSC to setup an EPL service between the at the CMI the MDSC to setup an EPL service between the access links
access links on S3 and S8 and the MDSC understands that it shall on S3 and S8 and the MDSC understands that it shall setup an ODU2
setup an ODU2 end-to-end connection between nodes S3 and S18, which end-to-end connection between nodes S3 and S18, which belongs to
belongs to different PNC domains (multi-domain service request). The different PNC domains (multi-domain service request). The MDSC also
MDSC also understands how the adaptation functions inside nodes S3 understands how the adaptation functions inside nodes S3 and S18
and S18 (i.e., S3 (ETH -> [ODU2]), S18 ([ODU2] -> ETH), S18 (ETH -> (i.e., S3 (ETH -> [ODU2]), S18 ([ODU2] -> ETH), S18 (ETH -> [ODU2])
[ODU2]) and S3 ([ODU2] -> ETH)) should be configured. and S3 ([ODU2] -> ETH)) should be configured.
To setup a 10Gb IP link between R1 and R3, an EPL service needs to To setup a 10Gb IP link between R1 and R3, an EPL service needs to be
be created between R1 and R3, supported by an ODU2 end-to-end created between R1 and R3, supported by an ODU2 end-to-end connection
connection in the data plane between transport nodes S3 and S6, in the data plane between transport nodes S3 and S6, through the
through the transport node S5, which belong to the same PNC domain transport node S5, which belong to the same PNC domain (single-domain
(single-domain service request): service request):
R1 ([PKT] -> ETH), S3 (ETH -> [ODU2]), S5 ([ODU2]), R1 ([PKT] -> ETH), S3 (ETH -> [ODU2]), S5 ([ODU2]),
S6 ([ODU2] -> ETH), R3 (ETH-> [PKT]) S6 ([ODU2] -> ETH), R3 (ETH-> [PKT])
As described in section 4.3.1, the mechanisms used by the CNC at the As described in section 4.3.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, the MDSC understands that it shall
setup an EPL service between the access links on S3 and S6, which setup an EPL service between the access links on S3 and S6, which
belong to the same PNC domain (single-domain service request) and it belong to the same PNC domain (single-domain service request) and it
can just pass the request at the MPI to PNC1 to setup a single- can just pass the request at the MPI to PNC1 to setup a single-domain
domain EPL service its access links on S3 and S6. In this case, PNC1 EPL service its access links on S3 and S6. In this case, PNC1 can
can take care of setting up the single-domain ODU2 end-to-end take care of setting up the single-domain ODU2 end-to-end connection
connection between nodes S3 and S6 as well as of configuring the between nodes S3 and S6 as well as of configuring the adaptation
adaptation functions on these edge nodes. 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 [ITU-T G.709] defines mappings of different client layers into ODU.
ODU. Most of them are used to provide Private Line services over Most of them are used to provide Private Line services over an OTN
an OTN transport network supporting a variety of types of physical transport network supporting a variety of types of physical access
access links (e.g., Ethernet, SDH STM-N, Fibre Channel, InfiniBand, links (e.g., Ethernet, SDH STM-N, Fibre Channel, InfiniBand, etc.).
etc.).
The physical links interconnecting the IP routers and the transport The physical links interconnecting the IP routers and the transport
network can be any of these types. network can be any of these types.
In order to setup a 10Gb IP link between R1 and R5 using, for In order to setup a 10Gb IP link between R1 and R5 using, for example
example SDH physical links between the IP routers and the transport SDH physical links between the IP routers and the transport network,
network, an STM-64 Private Line service needs to be created between an STM-64 Private Line service needs to be created between R1 and R5,
R1 and R5, supported by an ODU2 end-to-end connection in the data supported by an ODU2 end-to-end connection in the data plane between
plane between transport nodes S3 and S18, through transport nodes transport nodes S3 and S18, through transport nodes S1, S2, S31, S33,
S1, S2, S31, S33, S34 and S15, which belong to different PNC domains S34 and S15, which belong to different PNC domains (multi-domain
(multi-domain service request): service 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), R5 (STM-64 -> [PKT])
Based on the assumptions described in section 4.3.1, the CNC Based on the assumptions described in section 4.3.1, the CNC requests
requests the CMI the MDSC to setup an STM-64 Private Line service the CMI the MDSC to setup an STM-64 Private Line service between the
between the access links on S3 and S8 and the MDSC understands what access links on S3 and S8 and the MDSC understands what to do as
to do as described in section 4.3.2 (multi-domain service request). described in section 4.3.2 (multi-domain service request).
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.3.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
skipping to change at page 18, line 20 skipping to change at page 18, line 23
the MPI to PNC1 to setup a single-domain STM-64 Private Line service the MPI to PNC1 to setup a single-domain STM-64 Private Line service
between it access links on S3 and S6. between it access links on S3 and S6.
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, To setup two 1Gb IP links between R1 to R3 and between R1 and R5, two
two EVPL services need to be created, supported by two ODU0 end-to- EVPL services need to be created, supported by two ODU0 end-to-end
end connections in the data plane respectively between transport connections in the data plane respectively between transport nodes S3
nodes S3 and S6, through transport node S5, which belong ot the same and S6, through transport node S5, which belong ot the same PNC
PNC domain (single-domain service request) and between transport domain (single-domain service request) and between transport nodes S3
nodes S3 and S18, through transport nodes S1, S2, S31, S33, S34 and and S18, through transport nodes S1, S2, S31, S33, S34 and S15, which
S15, which belong to different PNC domains (multi-domain service belong to different PNC domains (multi-domain service request):
request):
R1 ([PKT] -> VLAN), S3 (VLAN -> [ODU0]), S1 ([ODU0]), R1 ([PKT] -> VLAN), S3 (VLAN -> [ODU0]), S1 ([ODU0]),
S2 ([ODU0]), S31 ([ODU0]), S33 ([ODU0]), S34 ([ODU0]), S2 ([ODU0]), S31 ([ODU0]), S33 ([ODU0]), S34 ([ODU0]),
S15 ([ODU0]), S18 ([ODU0] -> VLAN), R5 (VLAN -> [PKT]) S15 ([ODU0]), S18 ([ODU0] -> VLAN), R5 (VLAN -> [PKT])
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), R3 (VLAN -> [PKT])
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 Based on the assumptions described in section 4.3.1, the CNC requests
requests at the CMI the MDSC to setup these EVPL services and the at the CMI the MDSC to setup these EVPL services and the MDSC
MDSC understands what to do as described in section 4.3.2. understands what to do as described in section 4.3.2.
4.3.5. EVPLAN and EVPTree Services 4.3.5. EVPLAN and EVPTree Services
When the physical links interconnecting the IP routers and the When the physical links interconnecting the IP routers and the
transport network are Ethernet links, multipoint Ethernet services transport network are Ethernet links, multipoint Ethernet services
(e.g., EPLAN and EPTree) can also be supported. It is also possible (e.g., EPLAN and EPTree) can also be supported. It is also possible
that multiple Ethernet services (e.g., EVPL, EVPLAN and EVPTree) that multiple Ethernet services (e.g., EVPL, EVPLAN and EVPTree)
share the same physical link using different VLANs. share the same physical link using different VLANs.
Note - it is assumed that EPLAN and EPTree services can be supported Note - it is assumed that EPLAN and EPTree services can be supported
by configuring EVPLAN and EVPTree with port mapping. by configuring EVPLAN and EVPTree with port mapping.
Since this EVPLAN/EVPTree service can share the same Ethernet Since this EVPLAN/EVPTree service can share the same Ethernet
physical links between IP routers and transport nodes (e.g., with physical links between IP routers and transport nodes (e.g., with the
the EVPL services described in section 4.3.4), a different VLAN ID EVPL services described in section 4.3.4), a different VLAN ID (e.g.,
(e.g., 30) can be associated with this EVPLAN/EVPTree service. 30) can be associated with this EVPLAN/EVPTree service.
In order to setup an IP subnet between R1, R2, R3 and R5, an 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 EVPLAN/EVPTree service needs to be created, supported by two ODUflex
end-to-end connections respectively between S3 and S6, crossing end-to-end connections respectively between S3 and S6, crossing
transport node S5, and between S3 and S18, crossing transport nodes transport node S5, and between S3 and S18, crossing transport nodes
S1, S2, S31, S33, S34 and S15 which belong to different PNC domains. S1, S2, S31, S33, S34 and S15 which belong to different PNC domains.
Some MAC Bridging capabilities are also required on some nodes at Some MAC Bridging capabilities are also required on some nodes at the
the edge of the transport network: for example, Ethernet Bridging edge of the transport network: for example, Ethernet Bridging
capabilities can be configured in nodes S3 and S6: capabilities can be configured in nodes S3 and S6:
o MAC Bridging in node S3 is needed to select, based on the MAC o MAC Bridging in node S3 is needed to select, based on the MAC
Destination Address, whether received Ethernet frames should be Destination Address, whether received Ethernet frames should be
forwarded to R1 or to the ODUflex terminating on node S6 or to forwarded to R1 or to the ODUflex terminating on node S6 or to the
the other ODUflex terminating on node S18; other ODUflex terminating on node S18;
o MAC bridging function in node S6 is needed to select, based on o MAC bridging function in node S6 is needed to select, based on the
the MAC Destination Address, whether received Ethernet frames MAC Destination Address, whether received Ethernet frames should
should be sent to R2 or to R3 or to the ODUflex terminating on be sent to R2 or to R3 or to the ODUflex terminating on node S3.
node S3.
In order to support an EVPTree service instead of an EVPLAN, In order to support an EVPTree service instead of an EVPLAN,
additional configuration of the Ethernet Bridging capabilities on additional configuration of the Ethernet Bridging capabilities on the
the nodes at the edge of the transport network is required. nodes at the edge of the transport network is required.
The traffic flows between R1 and R3, between R3 and R5 and between The traffic flows between R1 and R3, between R3 and R5 and between R1
R1 and R5 can be summarized as: and R5 can be summarized as:
R1 ([PKT] -> VLAN), S3 (VLAN -> [MAC] -> [ODUflex]), R1 ([PKT] -> VLAN), S3 (VLAN -> [MAC] -> [ODUflex]),
S5 ([ODUflex]), S6 ([ODUflex] -> [MAC] -> VLAN), S5 ([ODUflex]), S6 ([ODUflex] -> [MAC] -> VLAN),
R3 (VLAN -> [PKT]) R3 (VLAN -> [PKT])
R3 ([PKT] -> VLAN), S6 (VLAN -> [MAC] -> [ODUflex]), R3 ([PKT] -> VLAN), S6 (VLAN -> [MAC] -> [ODUflex]),
S5 ([ODUflex]), S3 ([ODUflex] -> [MAC] -> [ODUflex]), S5 ([ODUflex]), S3 ([ODUflex] -> [MAC] -> [ODUflex]),
S1 ([ODUflex]), S2 ([ODUflex]), S31 ([ODUflex]), S1 ([ODUflex]), S2 ([ODUflex]), S31 ([ODUflex]),
S33 ([ODUflex]), S34 ([ODUflex]), S33 ([ODUflex]), S34 ([ODUflex]),
S15 ([ODUflex]), S18 ([ODUflex] -> VLAN), R5 (VLAN -> [PKT]) S15 ([ODUflex]), S18 ([ODUflex] -> VLAN), R5 (VLAN -> [PKT])
R1 ([PKT] -> VLAN), S3 (VLAN -> [MAC] -> [ODUflex]), R1 ([PKT] -> VLAN), S3 (VLAN -> [MAC] -> [ODUflex]),
S1 ([ODUflex]), S2 ([ODUflex]), S31 ([ODUflex]), S1 ([ODUflex]), S2 ([ODUflex]), S31 ([ODUflex]),
S33 ([ODUflex]), S34 ([ODUflex]), S33 ([ODUflex]), S34 ([ODUflex]),
S15 ([ODUflex]), S18 ([ODUflex] -> VLAN), R5 (VLAN -> [PKT]) S15 ([ODUflex]), S18 ([ODUflex] -> VLAN), R5 (VLAN -> [PKT])
As described in section 4.3.2, it is assumed that the CNC is As described in section 4.3.2, it is assumed that the CNC is capable,
capable, via the CMI, to request the setup of this EVPLAN/EVPTree via the CMI, to request the setup of this EVPLAN/EVPTree service,
service, providing all the information that the MDSC needs to providing all the information that the MDSC needs to understand that
understand that it need to request PNC1 to setup an ODUflex it need to request PNC1 to setup an ODUflex connection between nodes
connection between nodes S3 and S6 (single-domain service request) S3 and S6 (single-domain service request) and it also needs to
and it also needs to coordinate the setup of a multi-domain ODUflex coordinate the setup of a multi-domain ODUflex connection between
connection between nodes S3 and S16 as well as the MAC bridging and nodes S3 and S16 as well as the MAC bridging and the adaptation
the adaptation functions on these edge nodes. functions on these edge nodes.
In case the CNC needs the setup of an EVPLAN/EVPTree service only In case the CNC needs the setup of an EVPLAN/EVPTree service only
between R1, R2 and R3 (single-domain service request), it would 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 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 information provided at the CMI is sufficient for the MDSC to
understand that this is a single-domain service request. understand that this is a single-domain service request.
The MDSC can then just request PNC1 to setup a single-domain The MDSC can then just request PNC1 to setup a single-domain
EVPLAN/EVPTree service between nodes S3 and S6. PNC1 can take care EVPLAN/EVPTree service between nodes S3 and S6. PNC1 can take care of
of setting up the single-domain ODUflex end-to-end connection setting up the single-domain ODUflex end-to-end connection between
between nodes S3 and S6 as well as of configuring the MAC bridging nodes S3 and S6 as well as of configuring the MAC bridging and the
and the adaptation functions on these edge nodes. adaptation functions on these edge nodes.
4.3.6. Dynamic Service Configuration 4.3.6. Dynamic Service Configuration
Given the service established in the previous sections, there is a Given the service established in the previous sections, there is a
demand for an update of some service characteristics. A demand for an update of some service characteristics. A
straightforward approach would be terminate the current service and straightforward approach would be terminate the current service and
replace with a new one. Another more advanced approach would be a replace with a new one. Another more advanced approach would be a
dynamic configuration, in which case there will be no interruption dynamic configuration, in which case there will be no interruption
for the connection. for the connection.
An example application would be updating the SLA information for a An example application would be updating the SLA information for a
certain connection. For example, an ODU transit connection is set up certain connection. For example, an ODU transit connection is set up
according to section 4.3.1, with the corresponding SLA level of "no according to section 4.3.1, with the corresponding SLA level of 'no
protection". After the establishment of this connection, the user protection'. After the establishment of this connection, the user
would like to enhance this service by providing a restoration after would like to enhance this service by providing a restoration after
potential failure, and a request is generated on the CMI. In this potential failure, and a request is generated on the CMI. In this
case, after receiving the request, the MDSC would need to send an case, after receiving the request, the MDSC would need to send an
update message to the PNC, changing the SLA parameters in TE Tunnel update message to the PNC, changing the SLA parameters in TE Tunnel
model. Then the connection characteristic would be changed by PNC, model. Then the connection characteristic would be changed by PNC,
and a notification would be sent to MDSC for acknowledgement. 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- network can be configured in different modes, e.g., as OTU2 or STM-64
64 or 10GE. or 10GE.
This configuration can be done a-priori by means outside the scope This configuration can be done a-priori by means outside the scope of
of this document. In this case, these links will appear at the MPI this document. In this case, these links will appear at the MPI
either as an ODU Link or as an STM-64 Link or as a 10GE Link either as an ODU Link or as an STM-64 Link or as a 10GE Link
(depending on the a-priori configuration) and will be controlled at (depending on the a-priori configuration) and will be controlled at
the MPI as discussed in section 4.3. the MPI as discussed in section 4.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 give
the control to the MPI to decide, based on the service the control to the MPI to decide, based on the service configuration,
configuration, how to configure it. how to configure it.
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 multi-
functional access link while the physical links between R7 and S31 functional access link while the physical links between R7 and S31
and between R5 and S18 are STM-64 and 10GE physical links and between R5 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 R7 or an EPL service between R1 and R5.
The traffic flow between R1 and R7 can be summarized as: The traffic flow between R1 and R7 can be summarized as:
R1 ([PKT] -> STM-64), S3 (STM-64 -> [ODU2]), S1 ([ODU2]), R1 ([PKT] -> STM-64), S3 (STM-64 -> [ODU2]), S1 ([ODU2]),
S2 ([ODU2]), S31 ([ODU2] -> STM-64), R3 (STM-64 -> [PKT]) S2 ([ODU2]), S31 ([ODU2] -> STM-64), R3 (STM-64 -> [PKT])
The traffic flow between R1 and R5 can be summarized as: The traffic flow between R1 and R5 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), R5 (ETH -> [PKT])
As described in section 4.3.2, it is assumed that the CNC is As described in section 4.3.2, it is assumed that the CNC is capable,
capable, via the CMI, to request the setup either an STM-64 Private via the CMI, to request the setup either an STM-64 Private Line
Line service between R1 and R7 or an EPL service between R1 and R5, service between R1 and R7 or an EPL service between R1 and R5,
providing all the information that the MDSC needs to understand that providing all the information that the MDSC needs to understand that
it needs to coordinate the setup of a multi-domain ODU2 connection, it needs to coordinate the setup of a multi-domain ODU2 connection,
either between nodes S3 and S31, or between nodes S3 and S18, as either between nodes S3 and S31, or between nodes S3 and S18, as well
well as the adaptation functions on these edge nodes, and in as the adaptation functions on these edge nodes, and in particular
particular whether the multi-function access link on between R1 and whether the multi-function access link on between R1 and S3 should
S3 should operate as an STM-64 or as a 10GE link. operate as an STM-64 or as a 10GE 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 mechanism, typically provided via linear protection methods and would
would be configured to operate as 1+1 unidirectional (the most be configured to operate as 1+1 unidirectional (the most common OTN
common OTN protection method), 1+1 bidirectional or 1:n protection method), 1+1 bidirectional or 1:n bidirectional. This
bidirectional. This ensures fast and simple service survivability. 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 and with dynamic restoration.
The MDSC needs to be capable of coordinating different PNCs to The MDSC needs to be capable of coordinating different PNCs to
configure protection switching when requesting the setup of the configure protection switching when requesting the setup of the
skipping to change at page 23, line 5 skipping to change at page 23, line 12
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.
Two cases can be considered: Two cases can be considered:
o In one case, the working and protection transport entities pass o In one case, the working and protection transport entities pass
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 o In another case, the working and protection transport entities can
can pass through different PNC domains: 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 Given the fast dynamic of protection switching operations in the data
data plane (50ms recovery time), this reporting is not expected to plane (50ms recovery time), this reporting is not expected to be in
be in real-time. 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 any service defined in section 4.3 from failures within
the OTN multi-domain transport network, the MDSC should be capable the OTN multi-domain transport network, the MDSC should be capable of
of requesting each PNC to configure OTN intra-domain protection when requesting each PNC to configure OTN intra-domain protection when
requesting the setup of the ODU2 data plane connection segment. requesting the setup of the ODU2 data plane connection segment.
If PNC1 provides linear protection, the working and protection If PNC1 provides linear protection, the working and protection
transport entities could be: transport entities could be:
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 If PNC2 provides linear protection, the working and protection
transport entities could be: transport entities could be:
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 If PNC3 provides linear protection, the working and protection
transport entities could be: transport entities could be:
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.5.3. End-to-End Dynamic restoration
To restore any service defined in section 4.3 from failures within To restore any service defined in section 4.3 from failures within
the OTN multi-domain transport network, the MDSC should be capable the OTN multi-domain transport network, the MDSC should be capable of
of coordinating different PNCs to configure and control OTN end-to- coordinating different PNCs to configure and control OTN end-to-end
end dynamic Restoration in the data plane between nodes S3 and node dynamic Restoration in the data plane between nodes S3 and node S18.
S18. For example, the MDSC can request the PNC1, PNC2 and PNC3 to For example, the MDSC can request the PNC1, PNC2 and PNC3 to create a
create a service with no-protection, MDSC set the end-to-end service service with no-protection, MDSC set the end-to-end service with the
with the dynamic restoration. dynamic restoration.
Working transport entity: S3, S1, S2, Working transport entity: S3, S1, S2,
S31, S33, S34, S31, S33, S34,
S15, S18 S15, S18
When a link failure between S1 and s2 occurred in network domain 1, 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 PNC1 does not restore the tunnel and send the alarm notification to
the MDSC, MDSC will perform the end-to-end restoration. the MDSC, MDSC will perform the end-to-end restoration.
Restored transport entity: S3, S4, S8, Restored transport entity: S3, S4, S8,
S12, S15, S18 S12, S15, S18
4.5.4. Segmented Dynamic Restoration 4.5.4. Segmented Dynamic Restoration
To restore any service defined in section 4.3 from failures within To restore any service defined in section 4.3 from failures within
the OTN multi-domain transport network, the MDSC should be capable the OTN multi-domain transport network, the MDSC should be capable of
of coordinating different PNCs to configure and control OTN coordinating different PNCs to configure and control OTN segmented
segmented dynamic Restoration in the data plane between nodes S3 and dynamic Restoration in the data plane between nodes S3 and node S18.
node S18.
Working transport entity: S3, S1, S2, Working transport entity: S3, S1, S2,
S31, S33, S34, S31, S33, S34,
S15, S18 S15, S18
When a link failure between S1 and s2 occurred in network domain 1, 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 PNC1 will restore the tunnel and send the alarm or tunnel update
notification to the MDSC, MDSC will update the restored tunnel. notification to the MDSC, MDSC will update the restored tunnel.
Restored transport entity: S3, S4, S8, S2 Restored transport entity: S3, S4, S8, S2
S31, S33, S34, S31, S33, S34,
S15, S18 S15, S18
When a link failure between network domain 1 and network domain 2 When a link failure between network domain 1 and network domain 2
occurred, PNC1 and PNC2 will send the alarm notification to the occurred, PNC1 and PNC2 will send the alarm notification to the MDSC,
MDSC, MDSC will update the restored tunnel. MDSC will update the restored tunnel.
Restored transport entity: S3, S4, S8, Restored transport entity: S3, S4, S8,
S12, S15, S18 S12, S15, S18
In order to improve the efficiency of recovery, the controller can In order to improve the efficiency of recovery, the controller can
establish a recovery path in a concurrent way. When the recovery establish a recovery path in a concurrent way. When the recovery
fails in one domain or one network element, the rollback operation fails in one domain or one network element, the rollback operation
should be supported. should be supported.
The creation of the recovery path by the controller can use the 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 method of "make-before-break", in order to reduce the impact of the
recovery operation on the services. recovery operation on the services.
4.6. Service Modification and Deletion 4.6. Service Modification and Deletion
[Editors' Note:] The service configuration include service creation,
modification and deletion.
For example, the service modification includes the service bandwidth
modification and service SLA level upgrade and degrade, such as
service protection type changed from no protection to 1+1
protection.
To be discussed in future versions of this document. To be discussed in future versions of this document.
4.7. Notification 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 Because there are three types of topology abstraction type defined in
in section 4.2, the notification should also be abstracted. The PNC section 4.2, the notification should also be abstracted. The PNC and
and MDSC should coordinate together to determine the notification MDSC should coordinate together to determine the notification policy,
policy, such as when an intra-domain alarm occurred, the PNC may not such as when an intra-domain alarm occurred, the PNC may not report
report the alarm but the service state change notification to the the alarm but the service state change notification to the MDSC.
MDSC.
4.8. Path Computation with Constraint 4.8. Path Computation with Constraint
It is possible to have constraint during path computation procedure; It is possible to have constraint during path computation procedure;
typical cases include IRO/XRO and so on. This information is carried typical cases include IRO/XRO and so on. This information is carried
in the TE Tunnel model and used when there is a request with 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 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 be a Tunnel from R1 to R5 with an IRO from S2 to S31, then qualified
feedback would become: feedback would become:
skipping to change at page 26, line 40 skipping to change at page 26, line 39
S31 ([ODU2]), S33 ([ODU2]), S34 ([ODU2]), S31 ([ODU2]), S33 ([ODU2]), S34 ([ODU2]),
S15 ([ODU2]), S18 ([ODU2]), R5 (ODU2 -> [PKT]) S15 ([ODU2]), S18 ([ODU2]), R5 (ODU2 -> [PKT])
If the request covers the IRO from S8 to S12, then the above path If the request covers the IRO from S8 to S12, then the above path
would not be qualified, while a possible computation result may be: would not be qualified, while a possible computation result may be:
R1 ([PKT] -> ODU2), S3 ([ODU2]), S1 ([ODU2]), S2 ([ODU2]), R1 ([PKT] -> ODU2), S3 ([ODU2]), S1 ([ODU2]), S2 ([ODU2]),
S8 ([ODU2]), S12 ([ODU2]), S15 ([ODU2]), S18 ([ODU2]), R5 (ODU2 -> S8 ([ODU2]), S12 ([ODU2]), S15 ([ODU2]), S18 ([ODU2]), R5 (ODU2 ->
[PKT]) [PKT])
Similarly, the XRO can be represented by the TE tunnel model as Similarly, the XRO can be represented by the TE tunnel model as well.
well.
When there is a technology specific network (e.g., OTN), the When there is a technology specific network (e.g., OTN), the
corresponding technology (OTN) model should also be used to specify corresponding technology (OTN) model should also be used to specify
the tunnel information on MPI, with the constraint included in TE the tunnel information on MPI, with the constraint included in TE
Tunnel model. Tunnel model.
5. YANG Model Analysis 5. YANG Model Analysis
This section provides a high-level overview of how IETF YANG models This section provides a high-level overview of how IETF YANG models
can be used at the MPIs, between the MDSC and the PNCs, to support can be used at the MPIs, between the MDSC and the PNCs, to support
the scenarios described in section 4. the scenarios described in section 4.
Section 5.1 describes the different topology abstractions provided Section 5.1 describes the different topology abstractions provided to
to the MDSC by each PNC via its own MPI. the MDSC by each PNC via its own MPI.
Section 5.2 describes how the MDSC can coordinate different requests Section 5.2 describes how the MDSC can coordinate different requests
to different PNCs, via their own MPIs, to setup the different to different PNCs, via their own MPIs, to setup the different
services described in section 4.3. 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
skipping to change at page 28, line 35 skipping to change at page 28, line 35
: AN1-7 | | AN1-4 : : AN1-7 | | AN1-4 :
: | | : : | | :
: +-----------------+ : : +-----------------+ :
: | | : : | | :
: AN1-6 | | AN1-5 : : AN1-6 | | AN1-5 :
:..........|..........|...........: :..........|..........|...........:
| | | |
(S11) (S12) (S11) (S12)
Figure 3 - Abstract Topology exposed at MPI1 (MPI1 OTN Topology) Figure 3 - Abstract Topology exposed at MPI1 (MPI1 OTN Topology)
[Editors' note:] Update figure 3 to match with the new topology
abstraction
As described in section 4.1, it is assumed that the physical links As described in section 4.1, it is assumed that the physical links
between the physical nodes are pre-configured and therefore PNC1 between the physical nodes are pre-configured and therefore PNC1
exports at MPI1 one abstract TE Link, within the MPI1 OTN topology, exports at MPI1 one abstract TE Link, within the MPI1 OTN topology,
for each OTU2 or OTU4 trail which support an abstract TE link in the for each OTU2 or OTU4 trail which support an abstract TE link in the
MPI1 ODU Topology. MPI1 ODU Topology.
[Editors' note:] Add some description about the relationship between
the abstract and the physical topology within the PNC1 "brain."
.................................. ..................................
: : : :
: ODU Abstract Topology @ MPI : : ODU Abstract Topology @ MPI :
: Gotham City Area : : Gotham City Area :
: Metro Transport Network : : Metro Transport Network :
: : : :
: +----+ +----+ : : +----+ +----+ :
: | |S1-1 | |S2-1: : | |S1-1 | |S2-1:
: | S1 |--------| S2 |----- - -(S31) : | S1 |--------| S2 |----- - -(S31)
: +----+ S2-2+----+ : : +----+ S2-2+----+ :
skipping to change at page 30, line 21 skipping to change at page 30, line 21
AN1-7 -> S6-2 AN1-7 -> S6-2
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 this ODU Topology is reported by the
PNC, using the [TE-TOPO] and [OTN-TOPO] YANG models at MPI1. PNC, using the [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:
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 label restrictions are also not
shown to simplify the JSON code example 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, one TE Topology
instance for the ODU layer (MPI2 OTN Topology) containing only one instance for the ODU layer (MPI2 OTN Topology) containing only one
skipping to change at page 31, line 10 skipping to change at page 31, line 10
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, one TE Topology
instance for the ODU layer (MPI3 OTN Topology) containing one instance for the ODU layer (MPI3 OTN Topology) containing one
abstract TE node for each physical node and one abstract TE link for abstract TE node for each physical node and one abstract TE link for
each physical link (internal links, inter-domain links or access each physical link (internal links, inter-domain links or access
links). links).
5.1.4. Multi-domain Topology Stitching 5.1.4. Multi-domain Topology Stitching
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 knowledge of the topologies of each domain until each PNC reports its
its own abstraction topology, so the MDSC needs to merge together own abstraction topology, so the MDSC needs to merge together the
the abstract topologies provided by different PNCs, at the MPIs, to abstract topologies provided by different PNCs, at the MPIs, to build
build its own topology view, as described in section 4.3 of [TE- its own topology view, as described in section 4.3 of [TE-TOPO].
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 stitch the multi-domain topology and obtain the full map of topology.
topology. The topology of each domain may be in an abstracted shape The topology of each domain may be in an abstracted shape (refer to
(refer to section 5.2 of [ACTN-Fwk] for a different level of section 5.2 of [RFC8453] for a different level of abstraction), while
abstraction), while the inter-domain link information MUST be the inter-domain link information must be complete and fully
complete and fully configured by the MDSC. configured by the 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 "stitch" 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 TOPO]: two inter-domain links reporting the same plug-id value can be
be merged as a single intra-domain link within any MDSC native merged as a single intra-domain link within any MDSC native topology.
topology. The value of the reported plug-id information can be The value of the reported plug-id information can be either assigned
either assigned by a central network authority, and configured by a central network authority, and configured within the two PNC
within the two PNC domains, or it can be discovered using automatic domains, or it can be discovered using automatic discovery mechanisms
discovery mechanisms (e.g., LMP-based, as defined in [RFC6898]). (e.g., LMP-based, as defined in [RFC6898]).
In case the plug-id values are assigned by a central authority, it In case the plug-id values are assigned by a central authority, it is
is under the central authority responsibility to assign unique under the central authority responsibility to assign unique values.
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 information discovered by the automatic discovery mechanisms needs to
to be encoded as a bit string within the plug-id value. This be encoded as a bit string within the plug-id value. This encoding is
encoding is implementation specific, but the encoding rules need to implementation specific, but the encoding rules need to be consistent
be consistent across all the PNCs. 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 RECOMMENDED even different automatic discovery mechanisms), it is needed that the
that the plug-id namespace is partitioned to avoid that different plug-id namespace is partitioned to avoid that different sources
sources assign the same plug-id value to different inter-domain assign the same plug-id value to different inter-domain link. The
link. The encoding of the plug-id namespace within the plug-id value encoding of the plug-id namespace within the plug-id value is
is implementation specific but needs to be consistent across all the implementation specific but needs to be consistent across all the
PNCs. PNCs.
Another possibility is to pre-configure, either in the adjacent PNCs Another possibility is to pre-configure, either in the adjacent PNCs
or in the MDSC, the association between the inter-domain link or in the MDSC, the association between the inter-domain link
identifiers (topology-id, node-id and tp-id) assigned by the two identifiers (topology-id, node-id and tp-id) assigned by the two
adjacent PNCs to the same inter-domain link. adjacent PNCs to the same inter-domain link.
This last scenario requires further investigation and will be This last scenario requires further investigation and will be
discussed in a future version of this document. discussed in a future version of this document.
[Editors' note:] Add some description of the abstract multi-domain
topology within the MDSC "brain."
........................ ........................
: : : :
: Network domain 1 : ............. : Network domain 1 : .............
: Grey Topology : : : : Grey Topology : : :
: Abstraction : : Network : : Abstraction : : Network :
: : : domain 3 : : : : domain 3 :
(R1)- - -------+ : : (White) : (R1)- - -------+ : : (White) :
: \ +--------------+ : : \ +--------------+ :
: \ / : : \ : : \ / : : \ :
: \ / : : \ : : \ / : : \ :
skipping to change at page 33, line 37 skipping to change at page 33, line 38
: | + / +--+ : : | + / +--+ :
: | |/ / +--- - -(R4) : | |/ / +--- - -(R4)
: Black +--- AN2 ---------+ : : Black +--- AN2 ---------+ :
: Topology | | : : Topology | | :
: Abstraction | +-------------- - -(R5) : Abstraction | +-------------- - -(R5)
: | : : | :
: +---------------- - -(R6) : +---------------- - -(R6)
: : : :
:...............................: :...............................:
Figure 5 - Multi-domain Abstract Topology discovered by MDSC Figure 5 - Multi-domain Abstract Topology discovered by MDSC
5.1.5. Access Links 5.1.5. Access Links
Access links in Figure 3 are shown as ODU Links: the modeling of the Access links in Figure 3 are shown as ODU Links: the modeling of the
access links for other access technologies is currently an open access links for other access technologies is currently an open
issue. issue.
The modeling of the access link in case of non-ODU access technology 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 has also an impact on the need to model ODU TTPs and layer transition
transition capabilities on the edge nodes (e.g., nodes S2, S3, S6 capabilities on the edge nodes (e.g., nodes S2, S3, S6 and S8 in
and S8 in Figure 3). Figure 3).
If, for example, the physical NE S6 is implemented in a "pizza box", If, for example, the physical NE S6 is implemented in a "pizza box",
the data plane would have only set of ODU termination resources the data plane would have only set of ODU termination resources
(where up to 2xODU4, 4xODU3, 20xODU2, 80xODU1, 160xODU0 and (where up to 2xODU4, 4xODU3, 20xODU2, 80xODU1, 160xODU0 and
160xODUflex can be terminated). The traffic coming from each of the 160xODUflex can be terminated). The traffic coming from each of the
10GE access links can be mapped into any of these ODU terminations. 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 Instead if, for example, the physical NE S6 can be implemented as a
multi-board system where access links reside on different/dedicated multi-board system where access links reside on different/dedicated
access cards with a separated set of ODU termination resources access cards with a separated set of ODU termination resources (where
(where up to 1xODU4, 2xODU3, 10xODU2, 40xODU1, 80xODU0 and up to 1xODU4, 2xODU3, 10xODU2, 40xODU1, 80xODU0 and 80xODUflex for
80xODUflex for each resource can be terminated). The traffic coming each resource can be terminated). The traffic coming from one 10GE
from one 10GE access links can be mapped only into the ODU access links can be mapped only into the ODU terminations which
terminations which reside on the same access card. reside on the same access card.
The more generic implementation option for a physical NE (e.g., S6) 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 would be the case is of a multi-board system with multiple access
cards with separated sets of access links and ODU termination cards with separated sets of access links and ODU termination
resources (where up to 1xODU4, 2xODU3, 10xODU2, 40xODU1, 80xODU0 and resources (where up to 1xODU4, 2xODU3, 10xODU2, 40xODU1, 80xODU0 and
80xODUflex for each resource can be terminated). The traffic coming 80xODUflex for each resource can be terminated). The traffic coming
from each of the 10GE access links on one access card can be mapped 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 only into any of the ODU terminations which reside on the same access
access card. card.
In the last two cases, only the ODUs terminated on the same access 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 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 that 10GE access link. Terminated ODUs can instead be sent to any of
the OTU4 interfaces the OTU4 interfaces
In all these cases, terminated ODUs can be sent to any of the OTU4 In all these cases, terminated ODUs can be sent to any of the OTU4
interfaces assuming the implementation is based on a non-blocking interfaces assuming the implementation is based on a non-blocking ODU
ODU cross-connect. cross-connect.
If the access links are reported via MPI in some, still to be 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 defined, client topology, it is possible to report each set of ODU
termination resources as an ODU TTP within the ODU Topology of termination resources as an ODU TTP within the ODU Topology of Figure
Figure 3 and to use either the inter-layer lock-id or the 3 and to use either the inter-layer lock-id or the transitional link,
transitional link, as described in sections 3.4 and 3.10 of [TE- as described in sections 3.4 and 3.10 of [TE-TOPO], to correlate the
TOPO], to correlate the access links, in the client topology, with access links, in the client topology, with the ODU TTPs, in the OTN
the ODU TTPs, in the OTN topology, to which access link are topology, to which access link are connected to.
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 6) 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., L1SM, L2SM, Transport-Service, VN, et al.) is
outside the scope of this document. outside the scope of this 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 it needs to coordinate the setup of a multi-domain ODU connection (or
(or connection segment) and, when needed, also the configuration of connection segment) and, when needed, also the configuration of the
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 44 skipping to change at page 36, line 44
/ ( ) \( ) / ( ) \( )
AP-1 ( ) X===========Z AP-1 ( ) X===========Z
----- ( ) \ ----- ( ) \
( ) AP-2 ( ) AP-2
----- -----
Figure 6 - Multi-domain Service Setup Figure 6 - 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 R5. The cross-domain routing is
assumed to be R1 <-> S3 <-> S2 <-> S31 <-> S33 <-> S34 <->S15 <-> assumed to be R1 <-> S3 <-> S2 <-> S31 <-> S33 <-> S34 <->S15 <-> S18
S18 <-> R5. <-> R5.
According to the different client signal type, there is different According to the different client signal type, there is different
adaptation required. adaptation required.
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 i.e., domain 1 <-> domain 2 <-> domain 3, with corresponding PNCs and
and inter-domain links (step 2 in Figure 6). inter-domain links (step 2 in Figure 6).
As described in [PATH-COMPUTE], the domain sequence can be As described in [PATH-COMPUTE], the domain sequence can be determined
determined by running the MDSC own path computation on the MDSC by running the MDSC own path computation on the MDSC internal
internal topology, defined in section 5.1.4, if and only if the MDSC topology, defined in section 5.1.4, if and only if the MDSC has
has enough topology information. Otherwise, the MDSC can send path enough topology information. Otherwise, the MDSC can send path
computation requests to the different PNCs (steps 2.1, 2.2 and 2.3 computation requests to the different PNCs (steps 2.1, 2.2 and 2.3 in
in Figure 6) and use this information to determine the optimal path Figure 6) and use this information to determine the optimal path on
on its internal topology and therefore the domain sequence. 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 model (including both TE tunnel model and OTN
tunnel model), and request different PNCs to setup each intra-domain tunnel model), and request different PNCs to setup each intra-domain
tunnel segment (steps 3, 3.1, 3.2 and 3.3 in Figure 6). tunnel segment (steps 3, 3.1, 3.2 and 3.3 in Figure 6).
Assume that each intra-domain tunnel segment can be set up Assume that each intra-domain tunnel segment can be set up
successfully, and each PNC response to the MDSC respectively. Based successfully, and each PNC response to the MDSC respectively. Based
on each segment, MDSC will take care of the configuration of both on each segment, MDSC will take care of the configuration of both the
the intra-domain tunnel segment and inter-domain tunnel via intra-domain tunnel segment and inter-domain tunnel via corresponding
corresponding MPI (via TE tunnel model and OTN tunnel model). More MPI (via TE tunnel model and OTN tunnel model). More specifically,
specifically, for the inter-domain configuration, the ts-bitmap and for the inter-domain configuration, the ts-bitmap and tpn attributes
tpn attributes need to be configured using the OTN Tunnel model. need to be configured using the OTN Tunnel model. Then the end-to-end
Then the end-to-end OTN tunnel will be ready. OTN tunnel will be ready.
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 in our example)
and not on the PNCs of transit domain (e.g., PNC-2 in our example). and not on the PNCs of transit domain (e.g., PNC-2 in our example).
An access link will be configured by MDSC after the OTN tunnel is An access link will be configured by MDSC after the OTN tunnel is set
set up. Access configuration is different and dependent on the up. Access configuration is different and dependent on the different
different type of service. More details can be found in the type of service. More details can be found in the following sections.
following sections.
[Editor's Note:] Add some notes for the single-domain case
5.2.1. ODU Transit Service 5.2.1. ODU Transit Service
In this scenario, described in section 4.3.1, the access links are In this scenario, described in section 4.3.1, the access links are
configured as ODU Links. configured as ODU Links.
Since it is assumed that the physical access links are pre- Since it is assumed that the physical access links are pre-
configured, each PNC exposes, at its MPI, one TE Link (called "ODU configured, each PNC exposes, at its MPI, one TE Link (called "ODU
Link") for each of these physical access link. These links are Link") for each of these physical access link. These links are
reported, together with any other ODU internal or inter-domain link, reported, together with any other ODU internal or inter-domain link,
within the OTN abstract topology exposed by each PNC, at its own within the OTN abstract topology exposed by each PNC, at its own MPI.
MPI.
To setup this IP link, between R1 and R5, the CNC requests, at the To setup this IP link, between R1 and R5, 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 the topology information described in section 5.1 above, the
MDSC understands that R1 is attached to the access link terminating MDSC understands that R1 is attached to the access link terminating
on S3-1 LTP in the ODU Topology exposed by PNC1 and that R5 is on S3-1 LTP in the ODU Topology exposed by PNC1 and that R5 is
attached to the access link terminating on AN2-1 LTP in the ODU attached to the access link terminating on AN2-1 LTP in the ODU
Topology exposed by PNC2. Topology exposed by PNC2.
[Editors' note:] Add some information about the path computation
step.
MDSC would then request, at MPI1, the PNC1 to setup an ODU2 (Transit MDSC would then request, at MPI1, the PNC1 to setup an ODU2 (Transit
Segment) Tunnel with one primary path between S3-1 and S2-1 LTPs: Segment) Tunnel with one primary path between S3-1 and S2-1 LTPs:
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 S3-1 LTP
[Editor's note:] The need for the second element is for further o The last two element references respectively the inter-domain
study.
o The last two element references respectively the inter-domain
link terminating on S2-1 LTP and the data plane resources link terminating on S2-1 LTP and the data plane resources
(i.e., the timeslots and the TPN, called "OTN Label") used by (i.e., the timeslots and the TPN, called "OTN Label") used by
the ODU2 connection over that link. the ODU2 connection over that link.
The configuration of the timeslots used by the ODU2 connection on The configuration of the timeslots used by the ODU2 connection on the
the internal links within a PNC domain (i.e., on the internal links 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 domain) is outside the scope of this document since it is a matter of
of the PNC domain internal implementation. 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 available on physical nodes belonging to different PNC domains (e.g.,
(e.g., on node S2 within PNC1 domain and on node S31 within PNC3 on node S2 within PNC1 domain and on node S31 within PNC3 domain).
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
timeslots and the TPN) to be used on the inter-domain links. The timeslots and the TPN) to be used on the inter-domain links. The MDSC
MDSC can know the timeslots which are available on the physical OTN can know the timeslots which are available on the physical OTN nodes
nodes terminating the inter-domain links (e.g., S2 and S31) from the terminating the inter-domain links (e.g., S2 and S31) from the OTN
OTN Topology information exposed, at the MPIs, by the PNCs Topology information exposed, at the MPIs, by the PNCs controlling
controlling the OTN physical nodes (e.g., PNC1 and PNC3 controlling the OTN physical nodes (e.g., PNC1 and PNC3 controlling the physical
the physical nodes S2 and S31 respectively). nodes S2 and S31 respectively).
[Editor's note:] These working assumptions seem generic and not
specific for the YANG models defined by IETF: should we move it to
section 4?
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 config.json") describing how the setup of this ODU2 (Transit Segment)
Segment) Tunnel can be requested by the MDSC, using the [TE-TUNNEL] Tunnel can be requested by the MDSC, using the [TE-TUNNEL] and [OTN-
and [OTN-TUNNEL] YANG models at MPI1. TUNNEL] YANG models at MPI1.
The Transport PNC performs path computation and sets up the ODU2 The Transport PNC performs path computation and sets up the ODU2
cross-connections within the physical nodes S3, S5 and S6, as shown cross-connections within the physical nodes S3, S5 and S6, as shown
in section 4.3.1. in section 4.3.1.
[Editor's note:] Complete the description to cover the other domains
as well as the status reporting.
5.2.1.1. Single Domain Example 5.2.1.1. Single Domain Example
To setup an ODU2 end-to-end connection, supporting an IP link, 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 between R1 and R3, the CNC requests, at the CMI, the MDSC to setup an
an ODU transit service. ODU transit service.
[Editor's note:] Complete the description of the single-domain
scenario.
The Transport PNC reports the status of the created ODU2 (Transit The Transport PNC reports the status of the created ODU2 (Transit
Segment) Tunnel and its path within the ODU Topology as shown in Segment) Tunnel and its path within the ODU Topology as shown in
Figure 7 below: Figure 7 below:
.................................. ..................................
: : : :
: ODU Abstract Topology @ MPI : : ODU Abstract Topology @ MPI :
: : : :
: +----+ +----+ : : +----+ +----+ :
skipping to change at page 40, line 43 skipping to change at page 40, line 43
:S6-2 : :S6-2 :
:................................: :................................:
Figure 7 - ODU2 Transit Tunnel Figure 7 - ODU2 Transit Tunnel
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 Ethernet Links.
[Editors' note:] Need to add information about the use of the
Ethernet client topology.
[Editor's Note:] Add considerations for the case the access links
are multi-function access links
To setup this IP link, between R1 and R5, the CNC requests, at the To setup this IP link, between R1 and R5, 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 As described in section 5.1.5 above, it is not clear in this case how
how the Ethernet access links between the transport network and the the Ethernet access links between the transport network and the IP
IP router, are reported by the PNC to the MDSC. router, are reported by the PNC to the MDSC.
If the 10GE physical links are not reported as ODU links within the If the 10GE physical links are not reported as ODU links within the
OTN topology information, described in section 5.1.1 above than the OTN topology information, described in section 5.1.1 above than the
MDSC will not have sufficient information to know that R1 and R5 are MDSC will not have sufficient information to know that R1 and R5 are
attached to the access links terminating on S3 and S6. attached to the access links terminating on S3 and S6.
Assuming that the MDSC knows how R1 and R3 are attached to the Assuming that the MDSC knows how R1 and R3 are attached to the
transport network, the MDSC would request the Transport PNC to setup transport network, the MDSC would request the Transport PNC to setup
an ODU2 end-to-end Tunnel between S3 and S6. an ODU2 end-to-end Tunnel between S3 and S6.
This ODU Tunnel is setup between two TTPs of nodes S3 and S6. In This ODU Tunnel is setup between two TTPs of nodes S3 and S6. In case
case of nodes S3 and S6 support more than one TTP, the MDSC should of nodes S3 and S6 support more than one TTP, the MDSC should decide
decide which TTP to use. which TTP to use.
As discussed in 5.1.5, depending on the different hardware As discussed in 5.1.5, depending on the different hardware
implementations of the physical nodes S3 and S6, not all the access implementations of the physical nodes S3 and S6, not all the access
links can be connected to all the TTPs. The MDSC should therefore links can be connected to all the TTPs. The MDSC should therefore
select not only the optimal TTP but also a TTP that would allow the select not only the optimal TTP but also a TTP that would allow the
Tunnel to be used by the service. Tunnel to be used by the service.
It is assumed that in case of node S3 or node S6 supports only one It is assumed that in case of node S3 or node S6 supports only one
TTP, this TTP can be accessed by all the access links. TTP, this TTP can be accessed by all the access links.
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 Once the ODU2 Tunnel setup has been requested, unless there is a one-
one-to-one relationship between the S3 and S6 TTPs and the Ethernet to-one relationship between the S3 and S6 TTPs and the Ethernet
access links toward R1 and R3 (as in the case, described in section access links toward R1 and R3 (as in the case, described in section
5.1.5, where the Ethernet access links reside on different/dedicated 5.1.5, where the Ethernet access links reside on different/dedicated
access card such that the ODU2 tunnel can only carry the Ethernet access card such that the ODU2 tunnel can only carry the Ethernet
traffic from the only Ethernet access link on the same access card traffic from the only Ethernet access link on the same access card
where the ODU2 tunnel is terminated), the MDSC also needs to request 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, the setup of an EPL service from the access links on S3 and S6,
attached to R1 and R3, and this ODU2 Tunnel. 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] ODU2 Tunnel can be requested by the MDSC, using the [CLIENT-SVC] YANG
YANG model at MPI1. model at MPI1.
5.2.3. Other OTN Client Services 5.2.3. Other OTN Client Services
[Editor's Note:] Update this section to describe the multi-domain
scenario
In this scenario, the access links are configured as one of the OTN In this scenario, the access links are configured as one of the OTN
clients (e.g., STM-64) links. clients (e.g., STM-64) links.
[Editor's Note:] Add considerations for the case the access links
are multi-function access links
As described in section 4.3.3, the CNC needs to setup an STM-64 As described in section 4.3.3, the CNC needs to setup an STM-64
Private Link service, supporting an IP link, between R1 and R3 and Private Link service, supporting an IP link, between R1 and R3 and
requests this service at the CMI to the MDSC. requests this service at the CMI to the MDSC.
MDSC needs to setup an STM-64 Private Link service between R1 and R3 MDSC needs to setup an STM-64 Private Link service between R1 and R3
supported by an ODU2 end-to-end connection between S3 and S6. supported by an ODU2 end-to-end connection between S3 and S6.
As described in section 5.1.5 above, it is not clear in this case As described in section 5.1.5 above, it is not clear in this case how
how the access links (e.g., the STM-N access links) between the the access links (e.g., the STM-N access links) between the transport
transport network and the IP router, are reported by the PNC to the network and the IP router, are reported by the PNC to the MDSC.
MDSC.
The same issues, as described in section 5.2.2, apply here: The same issues, as described in section 5.2.2, apply here:
o the MDSC needs to understand that R1 and R3 are connected, o the MDSC needs to understand that R1 and R3 are connected, thought
thought STM-64 access links, with S3 and S6 STM-64 access links, with S3 and S6
o the MDSC needs to understand which TTPs in S3 and S6 can be o the MDSC needs to understand which TTPs in S3 and S6 can be
accessed by these access links accessed by these access links
o the MDSC needs to configure the private line service from these o the MDSC needs to configure the private line service from these
access links through the ODU2 tunnel access links through the ODU2 tunnel
5.2.4. EVPL over ODU Service 5.2.4. EVPL over ODU Service
[Editor's Note:] Update this section to describe the multi-domain
scenario
In this scenario, the access links are configured as Ethernet links, In this scenario, the access links are configured as Ethernet links,
as described in section 5.2.2 above. as described in section 5.2.2 above.
As described in section 4.3.4, the CNC needs to setup EVPL services, As described in section 4.3.4, the CNC needs to setup EVPL services,
supporting IP links, between R1 and R3, as well as between R1 and R4 supporting IP links, between R1 and R3, as well as between R1 and R4
and requests these services at the CMI to the MDSC. and requests these services at the CMI to the MDSC.
MDSC needs to setup two EVPL services, between R1 and R3, as well as MDSC needs to setup two EVPL services, between R1 and R3, as well as
between R1 and R4, supported by ODU0 end-to-end connections between between R1 and R4, supported by ODU0 end-to-end connections between
S3 and S6 and between S3 and S2 respectively. S3 and S6 and between S3 and S2 respectively.
As described in section 5.1.5 above, it is not clear in this case As described in section 5.1.5 above, it is not clear in this case how
how the Ethernet access links between the transport network and the the Ethernet access links between the transport network and the IP
IP router, are reported by the PNC to the MDSC. router, are reported by the PNC to the MDSC.
The same issues, as described in section 5.1.5 above, apply here: The same issues, as described in section 5.1.5 above, apply here:
o the MDSC needs to understand that R1, R3 and R4 are connected, o the MDSC needs to understand that R1, R3 and R4 are connected,
thought the Ethernet access links, with S3, S6 and S2 thought the Ethernet access links, with S3, S6 and S2
o the MDSC needs to understand which TTPs in S3, S6 and S2 can be o the MDSC needs to understand which TTPs in S3, S6 and S2 can be
accessed by these access links accessed by these access links
o the MDSC needs to configure the EVPL services from these access o the MDSC needs to configure the EVPL services from these access
links through the ODU0 tunnels links through the ODU0 tunnels
In addition, the MDSC needs to get the information that the access In addition, the MDSC needs to get the information that the access
links on S3, S6 and S2 are capable of supporting EVPL (rather than links on S3, S6 and S2 are capable of supporting EVPL (rather than
just EPL) as well as to coordinate the VLAN configuration, for each just EPL) as well as to coordinate the VLAN configuration, for each
EVPL service, on these access links (this is a similar issue as the EVPL service, on these access links (this is a similar issue as the
timeslot configuration on access links discussed in section 4.3.1 timeslot configuration on access links discussed in section 4.3.1
above). above).
5.3. YANG Models for Protection Configuration 5.3. YANG Models for Protection Configuration
skipping to change at page 44, line 19 skipping to change at page 43, line 47
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 This document analyses the applicability of the YANG models being
defined by the IETF to support OTN single and multi-domain scenarios defined by the IETF to support OTN single and multi-domain scenarios
There are no specific new security considerations introduced by this There are no specific new security considerations introduced by this
document. 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 signaling. The GCC control channel should be secured using a suitable
suitable mechanism. mechanism.
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
[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 [RFC4427] Mannie, E., Papadimitriou, D., "Recovery (Protection and
Restoration) Terminology for Generalized Multi-Protocol Restoration) Terminology for Generalized Multi-Protocol
Label Switching (GMPLS)", RFC 4427, March 2006. Label Switching (GMPLS)", RFC 4427, March 2006.
[ACTN-Frame] Ceccarelli, D., Lee, Y. et al., "Framework for [RFC8453] Ceccarelli, D., Lee, Y. et al., "Framework for Abstraction
Abstraction and Control of Transport Networks", draft- and Control of TE Networks (ACTN)", RFC8453, August 2018.
ietf-teas-actn-framework, work in progress.
[ITU-T G.709] ITU-T Recommendation G.709 (06/16), "Interfaces for [ITU-T G.709] ITU-T Recommendation G.709 (06/16), "Interfaces for the
the optical transport network", June 2016. 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", [TE-TOPO] Liu, X. et al., "YANG Data Model for TE Topologies", draft-
draft-ietf-teas-yang-te-topo, work in progress. ietf-teas-yang-te-topo, work in progress.
[OTN-TOPO] Zheng, H. et al., "A YANG Data Model for Optical [OTN-TOPO] Zheng, H. et al., "A YANG Data Model for Optical Transport
Transport Network Topology", draft-ietf-ccamp-otn-topo- Network Topology", draft-ietf-ccamp-otn-topo-yang, work in
yang, work in progress. 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-busibel-teas-yang- requesting Path Computation", draft-ietf-teas-yang-path-
path-computation, work in progress. computation, work in progress.
[OTN-TUNNEL] Zheng, H. et al., "OTN Tunnel YANG Model", draft- [OTN-TUNNEL] Zheng, H. et al., "OTN Tunnel YANG Model", draft-ietf-
ietf-ccamp-otn-tunnel-model, work in progress. ccamp-otn-tunnel-model, work in progress.
[CLIENT-SVC] Zheng, H. et al., "A YANG Data Model for Optical [CLIENT-SVC] 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 Engineering (RSVP-TE) Extensions", RFC 5151, February 2008.
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
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.
[I2RS-TOPO] Clemm, A. et al., "A Data Model for Network Topologies", [RFC-FOLD] Watsen, K. et al., "Handling Long Lines in Artwork in
draft-ietf-i2rs-yang-network-topo, work in progress.
[RFC-FOLD] Watsen, K. et al., " Handling Long Lines in Artwork in
Internet-Drafts and RFCs", work in progress Internet-Drafts and RFCs", 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
9. Acknowledgments 9. Acknowledgments
skipping to change at page 47, line 5 skipping to change at page 47, line 5
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 document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
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 Let's call "folded-JSON" the JSON embedded in the I-D: it fits the 72
72 chars width and it is acceptable for it to be invalid JSON. 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 draft-kwatsen-netmod-artwork-folding. The "unfolded-JSON" can be
edited by the authors using JSON editors with the advantages of edited by the authors using JSON editors with the advantages of
syntax validation and pretty-printing. syntax validation and pretty-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
skipping to change at page 47, line 48 skipping to change at page 48, line 4
Folded-JSON Unfolded-JSON Naked JSON Folded-JSON Unfolded-JSON Naked JSON
<-- fold_it <-- author edits <-- fold_it <-- author edits
<=72-chars? MUST MAY MAY <=72-chars? MUST MAY MAY
valid JSON? MAY MUST MUST valid JSON? MAY MUST MUST
JSON-encoding MAY MAY MUST JSON-encoding MAY MAY MUST
of YANG data of YANG data
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" - free-form descriptive comments, e.g."// COMMENT" : "refine this" to
to describe properties of JSON fragments. 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 automatically download from the network the relevant I-Ds or RFCs and
and extract from them the YANG models of interest. This is extract from them the YANG models of interest. This is particularly
particularly useful to keep consistency when the drafting work is useful to keep consistency when the drafting work is rapidly
rapidly evolving. 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 The idea is to generate a JSON driver file (JTOX) from YANG, then use
use it to translate JSON to XML and validate it against the DSDL it to translate JSON to XML and validate it against the DSDL schemas,
schemas, as shown in Figure 8. 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 10 skipping to change at page 49, line 23
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 3without impacting the validation process, these
comments will be automatically removed from the JSON-file that will comments will be automatically removed from the JSON-file that will
be validate. 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 The pyang support for the XSD output format was deprecated in 1.5 and
and removed in 1.7.1. However pyang 1.7.1 is necessary to work with removed in 1.7.1. However pyang 1.7.1 is necessary to work with YANG
YANG 1.1 so the process shown in Figure 9 will stop just at step 1.1 so the process shown in Figure 9 will stop just at step (1).
(1).
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 [FOLD]. using the tools in Appendix A and folded using the tool in [RFC-
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
This is the JSON code reporting the OTN Topology @ MPI: This is the JSON code reporting the OTN Topology @ MPI:
========== NOTE: '\\' line wrapping per BCP XX (RFC XXXX) ========== NOTE: '\\' line wrapping per BCP XX (RFC XXXX) ===========
===========
{ {
"// __TITLE__": "ODU Black Topology @ MPI1", "// __TITLE__": "ODU Black Topology @ MPI1",
"// __LAST_UPDATE__": "October 18, 2018", "// __LAST_UPDATE__": "October 18, 2018",
"// __MISSING_ATTRIBUTES__": true, "// __MISSING_ATTRIBUTES__": true,
"// __REFERENCE_DRAFTS__": { "// __REFERENCE_DRAFTS__": {
"ietf-routing-types@2017-12-04": "rfc8294", "ietf-routing-types@2017-12-04": "rfc8294",
"ietf-otn-types@2017-10-30": "draft-ietf-ccamp-otn-tunnel-model- "ietf-otn-types@2017-10-30": "draft-ietf-ccamp-otn-tunnel-model-\
\
\01", \01",
"ietf-network@2018-02-26": "rfc8345", "ietf-network@2018-02-26": "rfc8345",
"ietf-network-topology@2018-02-26": "rfc8345", "ietf-network-topology@2018-02-26": "rfc8345",
"ietf-te-types@2018-06-12": "draft-ietf-teas-yang-te-15", "ietf-te-types@2018-06-12": "draft-ietf-teas-yang-te-15",
"ietf-te-topology@2018-06-15": "draft-ietf-teas-yang-te-topo- "ietf-te-topology@2018-06-15": "draft-ietf-teas-yang-te-topo-18",
18", "ietf-otn-topology@2017-10-30": "draft-ietf-ccamp-otn-topo-yang-\
"ietf-otn-topology@2017-10-30": "draft-ietf-ccamp-otn-topo-yang-
\
\02" \02"
}, },
"// __RESTCONF_OPERATION__": { "// __RESTCONF_OPERATION__": {
"operation": "GET", "operation": "GET",
"url": "http://{{PNC1-ADDR}}/restconf/data/ietf- "url": "http://{{PNC1-ADDR}}/restconf/data/ietf-network:networks"
network:networks"
}, },
"ietf-network:networks": { "ietf-network:networks": {
"network": [ "network": [
{ {
"network-id": "providerId/201/clientId/300/topologyId/otn- "network-id": "providerId/201/clientId/300/topologyId/otn-bl\
bl\
\ack-topology", \ack-topology",
"network-types": { "network-types": {
"ietf-te-topology:te-topology": { "ietf-te-topology:te-topology": {
"ietf-otn-topology:otn-topology": {} "ietf-otn-topology:otn-topology": {}
} }
}, },
"ietf-te-topology:provider-id": 201, "ietf-te-topology:provider-id": 201,
"ietf-te-topology:client-id": 300, "ietf-te-topology:client-id": 300,
"ietf-te-topology:te-topology-id": "otn-black-topology", "ietf-te-topology:te-topology-id": "otn-black-topology",
"// ietf-te-topology:te": "presence container requires: "// ietf-te-topology:te": "presence container requires: prov\
prov\
\ider, client and te-topology-id", \ider, client and te-topology-id",
"ietf-te-topology:te": { "ietf-te-topology:te": {
"name": "OTN Black Topology @ MPI1" "name": "OTN Black Topology @ MPI1"
}, },
"// ietf-network:node": "Access LTPs to be reviewed in a "// ietf-network:node": "Access LTPs to be reviewed in a fut\
fut\
\ure update", \ure update",
"ietf-network:node": [ "ietf-network:node": [
{ {
"// __NODE__:__DESCRIPTION__": { "// __NODE__:__DESCRIPTION__": {
"name": "AN1", "name": "AN1",
"identifier": "10.0.0.1", "identifier": "10.0.0.1",
"type": "Abstract Node", "type": "Abstract Node",
"physical node(s)": "whole network domain 1" "physical node(s)": "whole network domain 1"
}, },
"node-id": "10.0.0.1", "node-id": "10.0.0.1",
"ietf-te-topology:te-node-id": "10.0.0.1", "ietf-te-topology:te-node-id": "10.0.0.1",
"ietf-te-topology:te": { "ietf-te-topology:te": {
"te-node-attributes": { "te-node-attributes": {
"name": "AN11", "name": "AN11",
"admin-status": "up", "admin-status": "up",
"// __DISCUSS__ is-abstract": "To be discussed with "// __DISCUSS__ is-abstract": "To be discussed with \
\
\TE Topology authors", \TE Topology authors",
"// __DISCUSS__ underlay-topology": "To be "// __DISCUSS__ underlay-topology": "To be discussed\
discussed\
\ with TE Topology authors" \ with TE Topology authors"
}, },
"oper-status": "up", "oper-status": "up",
"// __DISCUSS__ tunnel-termination-point": [] "// __DISCUSS__ tunnel-termination-point": []
}, },
"ietf-network-topology:termination-point": [ "ietf-network-topology:termination-point": [
{ {
"// __DESCRIPTION__:__LTP__": { "// __DESCRIPTION__:__LTP__": {
"name": "AN1-1 LTP", "name": "AN1-1 LTP",
"link type(s)": "OTU-2", "link type(s)": "OTU-2",
"physical node": "S3", "physical node": "S3",
"unnumberd/ifIndex": 1, "unnumberd/ifIndex": 1,
"port type": "tributary port", "port type": "tributary port",
"connected to": "R1" "connected to": "R1"
}, },
"tp-id": "1", "tp-id": "1",
"ietf-te-topology:te-tp-id": 1, "ietf-te-topology:te-tp-id": 1,
"ietf-te-topology:te": { "ietf-te-topology:te": {
"name": "AN1-1 LTP", "name": "AN1-1 LTP",
"admin-status": "up", "admin-status": "up",
"// __DISCUSS__ interface-switching-capability": "// __DISCUSS__ interface-switching-capability": "\
"\
\See Link attributes (teNodeId/10.0.0.1/teLinkId/1)", \See Link attributes (teNodeId/10.0.0.1/teLinkId/1)",
"// __DISCUSS__ inter-domain-plug-id": "Access "// __DISCUSS__ inter-domain-plug-id": "Access Lin\
Lin\
\k", \k",
"// __COMMENT__ inter-layer-lock-id": "Empty: OTN "// __COMMENT__ inter-layer-lock-id": "Empty: OTN \
\
\Links are pre-configured", \Links are pre-configured",
"oper-status": "up", "oper-status": "up",
"// __DISCUSS__ ietf-otn-topology:supported- "// __DISCUSS__ ietf-otn-topology:supported-payloa\
payloa\
\d-types": "List of ODU clients?", \d-types": "List of ODU clients?",
"// __DISCUSS__ ietf-otn-topology:client-facing": "// __DISCUSS__ ietf-otn-topology:client-facing": \
\
\true \true
} }
}, },
{ {
"// __DESCRIPTION__:__LTP__": { "// __DESCRIPTION__:__LTP__": {
"name": "AN1-2 LTP", "name": "AN1-2 LTP",
"link type(s)": "OTU-4", "link type(s)": "OTU-4",
"physical node": "S2", "physical node": "S2",
"unnumberd/ifIndex": 1, "unnumberd/ifIndex": 1,
"port type": "inter-domain port", "port type": "inter-domain port",
"connected to": "S31" "connected to": "S31"
}, },
"tp-id": "2", "tp-id": "2",
"ietf-te-topology:te-tp-id": 2, "ietf-te-topology:te-tp-id": 2,
"ietf-te-topology:te": { "ietf-te-topology:te": {
"name": "AN1-2 LTP", "name": "AN1-2 LTP",
"admin-status": "up", "admin-status": "up",
"// __DISCUSS__ interface-switching-capability": "// __DISCUSS__ interface-switching-capability": "\
"\
\See Link attributes (teNodeId/10.0.0.1/teLinkId/2)", \See Link attributes (teNodeId/10.0.0.1/teLinkId/2)",
"// __DISCUSS__ inter-domain-plug-id": "Inter- "// __DISCUSS__ inter-domain-plug-id": "Inter-doma\
doma\
\in Link", \in Link",
"oper-status": "up", "oper-status": "up",
"// __DISCUSS__ ietf-otn-topology:supported- "// __DISCUSS__ ietf-otn-topology:supported-payloa\
payloa\
\d-types": "Empty? (inter-domain OTN link)", \d-types": "Empty? (inter-domain OTN link)",
"// __DEFAULT__ ietf-otn-topology:client-facing": "// __DEFAULT__ ietf-otn-topology:client-facing": \
\
\false \false
} }
}, },
{ {
"// __DESCRIPTION__:__LTP__": { "// __DESCRIPTION__:__LTP__": {
"name": "AN1-3 LTP", "name": "AN1-3 LTP",
"link type(s)": "OTU-2", "link type(s)": "OTU-2",
"physical node": "S6", "physical node": "S6",
"unnumberd/ifIndex": 1, "unnumberd/ifIndex": 1,
"port type": "tributary port", "port type": "tributary port",
"connected to": "R2" "connected to": "R2"
}, },
"tp-id": "3", "tp-id": "3",
"ietf-te-topology:te-tp-id": 3, "ietf-te-topology:te-tp-id": 3,
"ietf-te-topology:te": { "ietf-te-topology:te": {
"name": "AN1-3 LTP", "name": "AN1-3 LTP",
"admin-status": "up", "admin-status": "up",
"// __DISCUSS__ interface-switching-capability": "// __DISCUSS__ interface-switching-capability": "\
"\
\See Link attributes (teNodeId/10.0.0.1/teLinkId/3)", \See Link attributes (teNodeId/10.0.0.1/teLinkId/3)",
"// __DISCUSS__ inter-domain-plug-id": "Access "// __DISCUSS__ inter-domain-plug-id": "Access Lin\
Lin\
\k", \k",
"oper-status": "up", "oper-status": "up",
"// __DISCUSS__ ietf-otn-topology:supported- "// __DISCUSS__ ietf-otn-topology:supported-payloa\
payloa\
\d-types": "List of ODU clients?", \d-types": "List of ODU clients?",
"// __DISCUSS__ ietf-otn-topology:client-facing": "// __DISCUSS__ ietf-otn-topology:client-facing": \
\
\true \true
} }
}, },
{ {
"// __DESCRIPTION__:__LTP__": { "// __DESCRIPTION__:__LTP__": {
"name": "AN1-4 LTP", "name": "AN1-4 LTP",
"link type(s)": "OTU-4", "link type(s)": "OTU-4",
"physical node": "S8", "physical node": "S8",
"unnumberd/ifIndex": 1, "unnumberd/ifIndex": 1,
"port type": "inter-domain port", "port type": "inter-domain port",
"connected to": "S32" "connected to": "S32"
}, },
"tp-id": "4", "tp-id": "4",
"ietf-te-topology:te-tp-id": 4, "ietf-te-topology:te-tp-id": 4,
"ietf-te-topology:te": { "ietf-te-topology:te": {
"name": "AN1-4 LTP", "name": "AN1-4 LTP",
"admin-status": "up", "admin-status": "up",
"// __DISCUSS__ interface-switching-capability": "// __DISCUSS__ interface-switching-capability": "\
"\
\See Link attributes (teNodeId/10.0.0.1/teLinkId/4)", \See Link attributes (teNodeId/10.0.0.1/teLinkId/4)",
"// __DISCUSS__ inter-domain-plug-id": "Inter- "// __DISCUSS__ inter-domain-plug-id": "Inter-doma\
doma\
\in Link", \in Link",
"oper-status": "up", "oper-status": "up",
"// __DISCUSS__ ietf-otn-topology:supported- "// __DISCUSS__ ietf-otn-topology:supported-payloa\
payloa\
\d-types": "Empty? (inter-domain OTN link)", \d-types": "Empty? (inter-domain OTN link)",
"// __DEFAULT__ ietf-otn-topology:client-facing": "// __DEFAULT__ ietf-otn-topology:client-facing": \
\
\false \false
} }
}, },
{ {
"// __DESCRIPTION__:__LTP__": { "// __DESCRIPTION__:__LTP__": {
"name": "AN1-5 LTP", "name": "AN1-5 LTP",
"link type(s)": "OTU-4", "link type(s)": "OTU-4",
"physical node": "S8", "physical node": "S8",
"unnumberd/ifIndex": 5, "unnumberd/ifIndex": 5,
"port type": "inter-domain port", "port type": "inter-domain port",
"connected to": "S12" "connected to": "S12"
}, },
"tp-id": "5", "tp-id": "5",
"ietf-te-topology:te-tp-id": 5, "ietf-te-topology:te-tp-id": 5,
"ietf-te-topology:te": { "ietf-te-topology:te": {
"name": "AN1-5 LTP", "name": "AN1-5 LTP",
"admin-status": "up", "admin-status": "up",
"// __DISCUSS__ interface-switching-capability": "// __DISCUSS__ interface-switching-capability": "\
"\
\See Link attributes (teNodeId/10.0.0.1/teLinkId/5)", \See Link attributes (teNodeId/10.0.0.1/teLinkId/5)",
"// __DISCUSS__ inter-domain-plug-id": "Inter- "// __DISCUSS__ inter-domain-plug-id": "Inter-doma\
doma\
\in Link", \in Link",
"oper-status": "up", "oper-status": "up",
"// __DISCUSS__ ietf-otn-topology:supported- "// __DISCUSS__ ietf-otn-topology:supported-payloa\
payloa\
\d-types": "Empty? (inter-domain OTN link)", \d-types": "Empty? (inter-domain OTN link)",
"// __DEFAULT__ ietf-otn-topology:client-facing": "// __DEFAULT__ ietf-otn-topology:client-facing": \
\
\false \false
} }
}, },
{ {
"// __DESCRIPTION__:__LTP__": { "// __DESCRIPTION__:__LTP__": {
"name": "AN1-6 LTP", "name": "AN1-6 LTP",
"link type(s)": "OTU-4", "link type(s)": "OTU-4",
"physical node": "S7", "physical node": "S7",
"unnumberd/ifIndex": 4, "unnumberd/ifIndex": 4,
"port type": "inter-domain port", "port type": "inter-domain port",
"connected to": "S11" "connected to": "S11"
}, },
"tp-id": "6", "tp-id": "6",
"ietf-te-topology:te-tp-id": 6, "ietf-te-topology:te-tp-id": 6,
"ietf-te-topology:te": { "ietf-te-topology:te": {
"name": "AN1-6 LTP", "name": "AN1-6 LTP",
"admin-status": "up", "admin-status": "up",
"// __DISCUSS__ interface-switching-capability": "// __DISCUSS__ interface-switching-capability": "\
"\
\See Link attributes (teNodeId/10.0.0.1/teLinkId/6)", \See Link attributes (teNodeId/10.0.0.1/teLinkId/6)",
"// __DISCUSS__ inter-domain-plug-id": "Inter- "// __DISCUSS__ inter-domain-plug-id": "Inter-doma\
doma\
\in Link", \in Link",
"oper-status": "up", "oper-status": "up",
"// __DISCUSS__ ietf-otn-topology:supported- "// __DISCUSS__ ietf-otn-topology:supported-payloa\
payloa\
\d-types": "Empty? (inter-domain OTN link)", \d-types": "Empty? (inter-domain OTN link)",
"// __DEFAULT__ ietf-otn-topology:client-facing": "// __DEFAULT__ ietf-otn-topology:client-facing": \
\
\false \false
} }
}, },
{ {
"// __DESCRIPTION__:__LTP__": { "// __DESCRIPTION__:__LTP__": {
"name": "AN1-7 LTP", "name": "AN1-7 LTP",
"link type(s)": "OTU-2", "link type(s)": "OTU-2",
"physical node": "S6", "physical node": "S6",
"unnumberd/ifIndex": 2, "unnumberd/ifIndex": 2,
"port type": "tributary port", "port type": "tributary port",
"connected to": "R3" "connected to": "R3"
}, },
"tp-id": "7", "tp-id": "7",
"ietf-te-topology:te-tp-id": 7, "ietf-te-topology:te-tp-id": 7,
"ietf-te-topology:te": { "ietf-te-topology:te": {
"name": "AN1-7 LTP", "name": "AN1-7 LTP",
"admin-status": "up", "admin-status": "up",
"// __DISCUSS__ interface-switching-capability": "// __DISCUSS__ interface-switching-capability": "\
"\
\See Link attributes (teNodeId/10.0.0.1/teLinkId/7)", \See Link attributes (teNodeId/10.0.0.1/teLinkId/7)",
"// __DISCUSS__ inter-domain-plug-id": "Access "// __DISCUSS__ inter-domain-plug-id": "Access Lin\
Lin\
\k", \k",
"oper-status": "up", "oper-status": "up",
"// __DISCUSS__ ietf-otn-topology:supported- "// __DISCUSS__ ietf-otn-topology:supported-payloa\
payloa\
\d-types": "List of ODU clients?", \d-types": "List of ODU clients?",
"// __DISCUSS__ ietf-otn-topology:client-facing": "// __DISCUSS__ ietf-otn-topology:client-facing": \
\
\true \true
} }
} }
] ]
} }
], ],
"// ietf-network-topology:link": "Access links to be "// ietf-network-topology:link": "Access links to be reviewe\
reviewe\
\d in a future update", \d in a future update",
"ietf-network-topology:link": [ "ietf-network-topology:link": [
{ {
"// __DESCRIPTION__:__LINK__": { "// __DESCRIPTION__:__LINK__": {
"name": "Access Link from AN1-1", "name": "Access Link from AN1-1",
"type": "access link", "type": "access link",
"physical link": "Link from S3-1 to R1" "physical link": "Link from S3-1 to R1"
}, },
"link-id": "teNodeId/10.0.0.1/teLinkId/1", "link-id": "teNodeId/10.0.0.1/teLinkId/1",
"ietf-te-topology:te": { "ietf-te-topology:te": {
"te-link-attributes": { "te-link-attributes": {
"name": "Access Link from AN1-1", "name": "Access Link from AN1-1",
"// __DISCUSS__ access-type": "Can we assume point- "// __DISCUSS__ access-type": "Can we assume point-t\
t\
\o-point as the default value?", \o-point as the default value?",
"access-type": "point-to-point", "access-type": "point-to-point",
"// __COMMENT__ external-domain": "Empty: the plug- "// __COMMENT__ external-domain": "Empty: the plug-i\
i\
\d is used instead of this container", \d is used instead of this container",
"// __DISCUSS__ is-abstract": "To be discussed with "// __DISCUSS__ is-abstract": "To be discussed with \
\
\TE Topology authors", \TE Topology authors",
"// __DISCUSS__ underlay": "To be discussed with TE "// __DISCUSS__ underlay": "To be discussed with TE \
\
\Topology authors", \Topology authors",
"admin-status": "up", "admin-status": "up",
"interface-switching-capability": [ "interface-switching-capability": [
{ {
"switching-capability": "ietf-te- "switching-capability": "ietf-te-types:switching\
types:switching\
\-otn", \-otn",
"encoding": "ietf-te-types:lsp-encoding-oduk", "encoding": "ietf-te-types:lsp-encoding-oduk",
"max-lsp-bandwidth": [ "max-lsp-bandwidth": [
{ {
"priority": 0, "priority": 0,
"// __DISCUSS__ te-bandwidth": "ODU2" "// __DISCUSS__ te-bandwidth": "ODU2"
} }
] ]
} }
], ],
"// __COMMENT__ label-restrictions": "Not described "// __COMMENT__ label-restrictions": "Not described \
\
\in this JSON example", \in this JSON example",
"// __DISCUSS__ link-protection-type": "Can we "// __DISCUSS__ link-protection-type": "Can we assum\
assum\
\e unprotected as the default value?", \e unprotected as the default value?",
"link-protection-type": "unprotected", "link-protection-type": "unprotected",
"max-link-bandwidth": { "max-link-bandwidth": {
"// __DISCUSS__ te-bandwidth": "1xODU2" "// __DISCUSS__ te-bandwidth": "1xODU2"
}, },
"max-resv-link-bandwidth": { "max-resv-link-bandwidth": {
"// __DISCUSS__ te-bandwidth": "1xODU2" "// __DISCUSS__ te-bandwidth": "1xODU2"
}, },
"unreserved-bandwidth": [ "unreserved-bandwidth": [
{ {
"priority": 0, "priority": 0,
"// __DISCUSS__ te-bandwidth": "1xODU2" "// __DISCUSS__ te-bandwidth": "1xODU2"
} }
] ]
}, },
"oper-status": "up", "oper-status": "up",
"// __EMPTY__ is-transitional": "It is not a "// __EMPTY__ is-transitional": "It is not a transitio\
transitio\
\nal link", \nal link",
"// __DISCUSS__ underlay ": "To be discussed with TE "// __DISCUSS__ underlay ": "To be discussed with TE T\
T\
\opology authors" \opology authors"
}, },
"source": { "source": {
"source-node": "10.0.0.1", "source-node": "10.0.0.1",
"source-tp": 1 "source-tp": 1
}, },
"// __EMPTY__ destination": "access link" "// __EMPTY__ destination": "access link"
}, },
{ {
"// __DESCRIPTION__:__LINK__": { "// __DESCRIPTION__:__LINK__": {
"name": "Inter-domain Link from AN1-2", "name": "Inter-domain Link from AN1-2",
"type": "inter-domain link", "type": "inter-domain link",
"physical link": "Link from S2-1 to S31" "physical link": "Link from S2-1 to S31"
}, },
"link-id": "teNodeId/10.0.0.1/teLinkId/2", "link-id": "teNodeId/10.0.0.1/teLinkId/2",
"ietf-te-topology:te": { "ietf-te-topology:te": {
"te-link-attributes": { "te-link-attributes": {
"name": "Inter-domain Link from AN1-2", "name": "Inter-domain Link from AN1-2",
"// __DISCUSS__ access-type": "Can we assume point- "// __DISCUSS__ access-type": "Can we assume point-t\
t\
\o-point as the default value?", \o-point as the default value?",
"access-type": "point-to-point", "access-type": "point-to-point",
"// __DISCUSS__ is-abstract": "To be discussed with "// __DISCUSS__ is-abstract": "To be discussed with \
\
\TE Topology authors", \TE Topology authors",
"// __DISCUSS__ underlay": "To be discussed with TE "// __DISCUSS__ underlay": "To be discussed with TE \
\
\Topology authors", \Topology authors",
"admin-status": "up", "admin-status": "up",
"interface-switching-capability": [ "interface-switching-capability": [
{ {
"switching-capability": "ietf-te- "switching-capability": "ietf-te-types:switching\
types:switching\
\-otn", \-otn",
"encoding": "ietf-te-types:lsp-encoding-oduk", "encoding": "ietf-te-types:lsp-encoding-oduk",
"max-lsp-bandwidth": [ "max-lsp-bandwidth": [
{ {
"priority": 0, "priority": 0,
"// __DISCUSS__ te-bandwidth": "ODU4" "// __DISCUSS__ te-bandwidth": "ODU4"
} }
], ],
"// __DISCUSS__ label-restrictions": "To be "// __DISCUSS__ label-restrictions": "To be adde\
adde\
\d?" \d?"
} }
], ],
"// __DISCUSS__ link-protection-type": "Can we "// __DISCUSS__ link-protection-type": "Can we assum\
assum\
\e unprotected as the default value?", \e unprotected as the default value?",
"link-protection-type": "unprotected", "link-protection-type": "unprotected",
"max-link-bandwidth": { "max-link-bandwidth": {
"// __DISCUSS__ te-bandwidth": "1xODU4, ..." "// __DISCUSS__ te-bandwidth": "1xODU4, ..."
}, },
"max-resv-link-bandwidth": { "max-resv-link-bandwidth": {
"// __DISCUSS__ te-bandwidth": "1xODU4, ..." "// __DISCUSS__ te-bandwidth": "1xODU4, ..."
}, },
"unreserved-bandwidth": [ "unreserved-bandwidth": [
{ {
"priority": 0, "priority": 0,
"// __DISCUSS__ te-bandwidth": "1xODU4, ..." "// __DISCUSS__ te-bandwidth": "1xODU4, ..."
} }
] ]
}, },
"oper-status": "up", "oper-status": "up",
"// __EMPTY__ is-transitional": "It is not a "// __EMPTY__ is-transitional": "It is not a transitio\
transitio\
\nal link", \nal link",
"// __DISCUSS__ underlay ": "To be discussed with TE "// __DISCUSS__ underlay ": "To be discussed with TE T\
T\
\opology authors" \opology authors"
}, },
"source": { "source": {
"source-node": "10.0.0.1", "source-node": "10.0.0.1",
"source-tp": 2 "source-tp": 2
}, },
"// __EMPTY__ destination": "inter-domain link" "// __EMPTY__ destination": "inter-domain link"
}, },
{ {
"// __DESCRIPTION__:__LINK__": { "// __DESCRIPTION__:__LINK__": {
"name": "Access Link from AN1-3", "name": "Access Link from AN1-3",
"type": "access link", "type": "access link",
"physical link": "Link from S6-1 to R2" "physical link": "Link from S6-1 to R2"
}, },
"link-id": "teNodeId/10.0.0.1/teLinkId/3", "link-id": "teNodeId/10.0.0.1/teLinkId/3",
"ietf-te-topology:te": { "ietf-te-topology:te": {
"te-link-attributes": { "te-link-attributes": {
"name": "Access Link from AN1-3", "name": "Access Link from AN1-3",
"// __DISCUSS__ access-type": "Can we assume point- "// __DISCUSS__ access-type": "Can we assume point-t\
t\
\o-point as the default value?", \o-point as the default value?",
"access-type": "point-to-point", "access-type": "point-to-point",
"// __DISCUSS__ is-abstract": "To be discussed with "// __DISCUSS__ is-abstract": "To be discussed with \
\
\TE Topology authors", \TE Topology authors",
"// __DISCUSS__ underlay": "To be discussed with TE "// __DISCUSS__ underlay": "To be discussed with TE \
\
\Topology authors", \Topology authors",
"admin-status": "up", "admin-status": "up",
"interface-switching-capability": [ "interface-switching-capability": [
{ {
"switching-capability": "ietf-te- "switching-capability": "ietf-te-types:switching\
types:switching\
\-otn", \-otn",
"encoding": "ietf-te-types:lsp-encoding-oduk", "encoding": "ietf-te-types:lsp-encoding-oduk",
"max-lsp-bandwidth": [ "max-lsp-bandwidth": [
{ {
"priority": 0, "priority": 0,
"// __DISCUSS__ te-bandwidth": "ODU2" "// __DISCUSS__ te-bandwidth": "ODU2"
} }
], ],
"// __DISCUSS__ label-restrictions": "To be "// __DISCUSS__ label-restrictions": "To be adde\
adde\
\d?" \d?"
} }
], ],
"// __DISCUSS__ link-protection-type": "Can we "// __DISCUSS__ link-protection-type": "Can we assum\
assum\
\e unprotected as the default value?", \e unprotected as the default value?",
"link-protection-type": "unprotected", "link-protection-type": "unprotected",
"max-link-bandwidth": { "max-link-bandwidth": {
"// __DISCUSS__ te-bandwidth": "1xODU2" "// __DISCUSS__ te-bandwidth": "1xODU2"
}, },
"unreserved-bandwidth": [ "unreserved-bandwidth": [
{ {
"priority": 0, "priority": 0,
"// __DISCUSS__ te-bandwidth": "1xODU2" "// __DISCUSS__ te-bandwidth": "1xODU2"
} }
], ],
"max-resv-link-bandwidth": { "max-resv-link-bandwidth": {
"// __DISCUSS__ te-bandwidth": "1xODU2" "// __DISCUSS__ te-bandwidth": "1xODU2"
} }
}, },
"oper-status": "up", "oper-status": "up",
"// __EMPTY__ is-transitional": "It is not a "// __EMPTY__ is-transitional": "It is not a transitio\
transitio\
\nal link", \nal link",
"// __DISCUSS__ underlay ": "To be discussed with TE "// __DISCUSS__ underlay ": "To be discussed with TE T\
T\
\opology authors" \opology authors"
}, },
"source": { "source": {
"source-node": "10.0.0.1", "source-node": "10.0.0.1",
"source-tp": 3 "source-tp": 3
}, },
"// __EMPTY__ destination": "access link" "// __EMPTY__ destination": "access link"
}, },
{ {
"// __DESCRIPTION__:__LINK__": { "// __DESCRIPTION__:__LINK__": {
"name": "Inter-domain Link from AN1-4", "name": "Inter-domain Link from AN1-4",
"type": "inter-domain link", "type": "inter-domain link",
"physical link": "Link from S8-1 to S32" "physical link": "Link from S8-1 to S32"
}, },
"link-id": "teNodeId/10.0.0.1/teLinkId/4", "link-id": "teNodeId/10.0.0.1/teLinkId/4",
"ietf-te-topology:te": { "ietf-te-topology:te": {
"te-link-attributes": { "te-link-attributes": {
"name": "Inter-domain Link from AN1-4", "name": "Inter-domain Link from AN1-4",
"// __DISCUSS__ access-type": "Can we assume point- "// __DISCUSS__ access-type": "Can we assume point-t\
t\
\o-point as the default value?", \o-point as the default value?",
"access-type": "point-to-point", "access-type": "point-to-point",
"// __DISCUSS__ is-abstract": "To be discussed with "// __DISCUSS__ is-abstract": "To be discussed with \
\
\TE Topology authors", \TE Topology authors",
"// __DISCUSS__ underlay": "To be discussed with TE "// __DISCUSS__ underlay": "To be discussed with TE \
\
\Topology authors", \Topology authors",
"admin-status": "up", "admin-status": "up",
"interface-switching-capability": [ "interface-switching-capability": [
{ {
"switching-capability": "ietf-te- "switching-capability": "ietf-te-types:switching\
types:switching\
\-otn", \-otn",
"encoding": "ietf-te-types:lsp-encoding-oduk", "encoding": "ietf-te-types:lsp-encoding-oduk",
"max-lsp-bandwidth": [ "max-lsp-bandwidth": [
{ {
"priority": 0, "priority": 0,
"// __DISCUSS__ te-bandwidth": "ODU4" "// __DISCUSS__ te-bandwidth": "ODU4"
} }
], ],
"// __DISCUSS__ label-restrictions": "To be "// __DISCUSS__ label-restrictions": "To be adde\
adde\
\d?" \d?"
} }
], ],
"// __DISCUSS__ link-protection-type": "Can we "// __DISCUSS__ link-protection-type": "Can we assum\
assum\
\e unprotected as the default value?", \e unprotected as the default value?",
"link-protection-type": "unprotected", "link-protection-type": "unprotected",
"max-link-bandwidth": { "max-link-bandwidth": {
"// __DISCUSS__ te-bandwidth": "1xODU4, ..." "// __DISCUSS__ te-bandwidth": "1xODU4, ..."
}, },
"unreserved-bandwidth": [ "unreserved-bandwidth": [
{ {
"priority": 0, "priority": 0,
"// __DISCUSS__ te-bandwidth": "1xODU4, ..." "// __DISCUSS__ te-bandwidth": "1xODU4, ..."
} }
], ],
"max-resv-link-bandwidth": { "max-resv-link-bandwidth": {
"// __DISCUSS__ te-bandwidth": "1xODU4, ..." "// __DISCUSS__ te-bandwidth": "1xODU4, ..."
} }
}, },
"oper-status": "up", "oper-status": "up",
"// __EMPTY__ is-transitional": "It is not a "// __EMPTY__ is-transitional": "It is not a transitio\
transitio\
\nal link", \nal link",
"// __DISCUSS__ underlay ": "To be discussed with TE "// __DISCUSS__ underlay ": "To be discussed with TE T\
T\
\opology authors" \opology authors"
}, },
"source": { "source": {
"source-node": "10.0.0.1", "source-node": "10.0.0.1",
"source-tp": 4 "source-tp": 4
}, },
"// __EMPTY__ destination": "inter-domain link" "// __EMPTY__ destination": "inter-domain link"
}, },
{ {
"// __DESCRIPTION__:__LINK__": { "// __DESCRIPTION__:__LINK__": {
"name": "Inter-domain Link from AN1-5", "name": "Inter-domain Link from AN1-5",
"type": "inter-domain link", "type": "inter-domain link",
"physical link": "Link from S8-5 to S12" "physical link": "Link from S8-5 to S12"
}, },
"link-id": "teNodeId/10.0.0.1/teLinkId/5", "link-id": "teNodeId/10.0.0.1/teLinkId/5",
"ietf-te-topology:te": { "ietf-te-topology:te": {
"te-link-attributes": { "te-link-attributes": {
"name": "Inter-domain Link from AN1-5", "name": "Inter-domain Link from AN1-5",
"// __DISCUSS__ access-type": "Can we assume point- "// __DISCUSS__ access-type": "Can we assume point-t\
t\
\o-point as the default value?", \o-point as the default value?",
"access-type": "point-to-point", "access-type": "point-to-point",
"// __DISCUSS__ is-abstract": "To be discussed with "// __DISCUSS__ is-abstract": "To be discussed with \
\
\TE Topology authors", \TE Topology authors",
"// __DISCUSS__ underlay": "To be discussed with TE "// __DISCUSS__ underlay": "To be discussed with TE \
\
\Topology authors", \Topology authors",
"admin-status": "up", "admin-status": "up",
"interface-switching-capability": [ "interface-switching-capability": [
{ {
"switching-capability": "ietf-te- "switching-capability": "ietf-te-types:switching\
types:switching\
\-otn", \-otn",
"encoding": "ietf-te-types:lsp-encoding-oduk", "encoding": "ietf-te-types:lsp-encoding-oduk",
"max-lsp-bandwidth": [ "max-lsp-bandwidth": [
{ {
"priority": 0, "priority": 0,
"// __DISCUSS__ te-bandwidth": "ODU4" "// __DISCUSS__ te-bandwidth": "ODU4"
} }
], ],
"// __DISCUSS__ label-restrictions": "To be "// __DISCUSS__ label-restrictions": "To be adde\
adde\
\d?" \d?"
} }
], ],
"// __DISCUSS__ link-protection-type": "Can we "// __DISCUSS__ link-protection-type": "Can we assum\
assum\
\e unprotected as the default value?", \e unprotected as the default value?",
"link-protection-type": "unprotected", "link-protection-type": "unprotected",
"max-link-bandwidth": { "max-link-bandwidth": {
"// __DISCUSS__ te-bandwidth": "1xODU4, ..." "// __DISCUSS__ te-bandwidth": "1xODU4, ..."
}, },
"max-resv-link-bandwidth": { "max-resv-link-bandwidth": {
"// __DISCUSS__ te-bandwidth": "1xODU4, ..." "// __DISCUSS__ te-bandwidth": "1xODU4, ..."
}, },
"unreserved-bandwidth": [ "unreserved-bandwidth": [
{ {
"priority": 0, "priority": 0,
"// __DISCUSS__ te-bandwidth": "1xODU4, ..." "// __DISCUSS__ te-bandwidth": "1xODU4, ..."
} }
] ]
}, },
"oper-status": "up", "oper-status": "up",
"// __EMPTY__ is-transitional": "It is not a "// __EMPTY__ is-transitional": "It is not a transitio\
transitio\
\nal link", \nal link",
"// __DISCUSS__ underlay ": "To be discussed with TE "// __DISCUSS__ underlay ": "To be discussed with TE T\
T\
\opology authors" \opology authors"
}, },
"source": { "source": {
"source-node": "10.0.0.1", "source-node": "10.0.0.1",
"source-tp": 5 "source-tp": 5
}, },
"// __EMPTY__ destination": "inter-domain link" "// __EMPTY__ destination": "inter-domain link"
}, },
{ {
"// __DESCRIPTION__:__LINK__": { "// __DESCRIPTION__:__LINK__": {
"name": "Inter-domain Link from AN1-6", "name": "Inter-domain Link from AN1-6",
"type": "inter-domain link", "type": "inter-domain link",
"physical link": "Link from S7-4 to S11" "physical link": "Link from S7-4 to S11"
}, },
"link-id": "teNodeId/10.0.0.1/teLinkId/6", "link-id": "teNodeId/10.0.0.1/teLinkId/6",
"ietf-te-topology:te": { "ietf-te-topology:te": {
"te-link-attributes": { "te-link-attributes": {
"name": "Inter-domain Link from AN1-6", "name": "Inter-domain Link from AN1-6",
"// __DISCUSS__ access-type": "Can we assume point- "// __DISCUSS__ access-type": "Can we assume point-t\
t\
\o-point as the default value?", \o-point as the default value?",
"access-type": "point-to-point", "access-type": "point-to-point",
"// __DISCUSS__ is-abstract": "To be discussed with "// __DISCUSS__ is-abstract": "To be discussed with \
\
\TE Topology authors", \TE Topology authors",
"// __DISCUSS__ underlay": "To be discussed with TE "// __DISCUSS__ underlay": "To be discussed with TE \
\
\Topology authors", \Topology authors",
"admin-status": "up", "admin-status": "up",
"interface-switching-capability": [ "interface-switching-capability": [
{ {
"switching-capability": "ietf-te- "switching-capability": "ietf-te-types:switching\
types:switching\
\-otn", \-otn",
"encoding": "ietf-te-types:lsp-encoding-oduk", "encoding": "ietf-te-types:lsp-encoding-oduk",
"max-lsp-bandwidth": [ "max-lsp-bandwidth": [
{ {
"priority": 0, "priority": 0,
"// __DISCUSS__ te-bandwidth": "ODU4" "// __DISCUSS__ te-bandwidth": "ODU4"
} }
], ],
"// __DISCUSS__ label-restrictions": "To be "// __DISCUSS__ label-restrictions": "To be adde\
adde\
\d?" \d?"
} }
], ],
"// __DISCUSS__ link-protection-type": "Can we "// __DISCUSS__ link-protection-type": "Can we assum\
assum\
\e unprotected as the default value?", \e unprotected as the default value?",
"link-protection-type": "unprotected", "link-protection-type": "unprotected",
"max-link-bandwidth": { "max-link-bandwidth": {
"// __DISCUSS__ te-bandwidth": "1xODU4, ..." "// __DISCUSS__ te-bandwidth": "1xODU4, ..."
}, },
"max-resv-link-bandwidth": { "max-resv-link-bandwidth": {
"// __DISCUSS__ te-bandwidth": "1xODU4, ..." "// __DISCUSS__ te-bandwidth": "1xODU4, ..."
}, },
"unreserved-bandwidth": [ "unreserved-bandwidth": [
{ {
"priority": 0, "priority": 0,
"// __DISCUSS__ te-bandwidth": "1xODU4, ..." "// __DISCUSS__ te-bandwidth": "1xODU4, ..."
} }
] ]
}, },
"oper-status": "up", "oper-status": "up",
"// __EMPTY__ is-transitional": "It is not a "// __EMPTY__ is-transitional": "It is not a transitio\
transitio\
\nal link", \nal link",
"// __DISCUSS__ underlay ": "To be discussed with TE "// __DISCUSS__ underlay ": "To be discussed with TE T\
T\
\opology authors" \opology authors"
}, },
"source": { "source": {
"source-node": "10.0.0.1", "source-node": "10.0.0.1",
"source-tp": 6 "source-tp": 6
}, },
"// __EMPTY__ destination": "inter-domain link" "// __EMPTY__ destination": "inter-domain link"
}, },
{ {
"// __DESCRIPTION__:__LINK__": { "// __DESCRIPTION__:__LINK__": {
"name": "Access Link from AN1-7", "name": "Access Link from AN1-7",
"type": "access link", "type": "access link",
"physical link": "Link from S6-2 to R3" "physical link": "Link from S6-2 to R3"
}, },
"link-id": "teNodeId/10.0.0.1teLinkId/7", "link-id": "teNodeId/10.0.0.1teLinkId/7",
"ietf-te-topology:te": { "ietf-te-topology:te": {
"te-link-attributes": { "te-link-attributes": {
"name": "Access Link from AN1-7", "name": "Access Link from AN1-7",
"// __DISCUSS__ access-type": "Can we assume point- "// __DISCUSS__ access-type": "Can we assume point-t\
t\
\o-point as the default value?", \o-point as the default value?",
"access-type": "point-to-point", "access-type": "point-to-point",
"// __DISCUSS__ is-abstract": "To be discussed with "// __DISCUSS__ is-abstract": "To be discussed with \
\
\TE Topology authors", \TE Topology authors",
"// __DISCUSS__ underlay": "To be discussed with TE "// __DISCUSS__ underlay": "To be discussed with TE \
\
\Topology authors", \Topology authors",
"admin-status": "up", "admin-status": "up",
"interface-switching-capability": [ "interface-switching-capability": [
{ {
"switching-capability": "ietf-te- "switching-capability": "ietf-te-types:switching\
types:switching\
\-otn", \-otn",
"encoding": "ietf-te-types:lsp-encoding-oduk", "encoding": "ietf-te-types:lsp-encoding-oduk",
"max-lsp-bandwidth": [ "max-lsp-bandwidth": [
{ {
"priority": 0, "priority": 0,
"// __DISCUSS__ te-bandwidth": "ODU2" "// __DISCUSS__ te-bandwidth": "ODU2"
} }
], ],
"// __DISCUSS__ label-restrictions": "To be "// __DISCUSS__ label-restrictions": "To be adde\
adde\
\d?" \d?"
} }
], ],
"// __DISCUSS__ link-protection-type": "Can we "// __DISCUSS__ link-protection-type": "Can we assum\
assum\
\e unprotected as the default value?", \e unprotected as the default value?",
"link-protection-type": "unprotected", "link-protection-type": "unprotected",
"max-link-bandwidth": { "max-link-bandwidth": {
"// __DISCUSS__ te-bandwidth": "1xODU2" "// __DISCUSS__ te-bandwidth": "1xODU2"
}, },
"max-resv-link-bandwidth": { "max-resv-link-bandwidth": {
"// __DISCUSS__ te-bandwidth": "1xODU2" "// __DISCUSS__ te-bandwidth": "1xODU2"
}, },
"unreserved-bandwidth": [ "unreserved-bandwidth": [
{ {
"priority": 0, "priority": 0,
"// __DISCUSS__ te-bandwidth": "1xODU2" "// __DISCUSS__ te-bandwidth": "1xODU2"
} }
] ]
}, },
"oper-status": "up", "oper-status": "up",
"// __EMPTY__ is-transitional": "It is not a "// __EMPTY__ is-transitional": "It is not a transitio\
transitio\
\nal link", \nal link",
"// __DISCUSS__ underlay ": "To be discussed with TE "// __DISCUSS__ underlay ": "To be discussed with TE T\
T\
\opology authors" \opology authors"
}, },
"source": { "source": {
"source-node": "10.0.0.1", "source-node": "10.0.0.1",
"source-tp": 7 "source-tp": 7
}, },
"// __EMPTY__ destination": "access link" "// __EMPTY__ destination": "access link"
} }
] ]
} }
] ]
} }
} }
B.2. JSON Examples for Service Configuration B.2. JSON Examples for Service Configuration
B.2.1. JSON Code: mpi1-odu2-service-config.json B.2.1. JSON Code: mpi1-odu2-service-config.json
This is the JSON code reporting the ODU2 transit service This is the JSON code reporting the ODU2 transit service
configuration @ MPI: configuration @ MPI:
========== NOTE: '\\' line wrapping per BCP XX (RFC XXXX) ========== NOTE: '\\' line wrapping per BCP XX (RFC XXXX) ===========
===========
{ {
"// __TITLE__": "ODU2 Service Configuration @ MPI1", "// __TITLE__": "ODU2 Service Configuration @ MPI1",
"// __LAST_UPDATE__": "October 22, 2018", "// __LAST_UPDATE__": "October 22, 2018",
"// __MISSING_ATTRIBUTES__": true, "// __MISSING_ATTRIBUTES__": true,
"// __REFERENCE_DRAFTS__": { "// __REFERENCE_DRAFTS__": {
"ietf-routing-types@2017-12-04": "rfc8294", "ietf-routing-types@2017-12-04": "rfc8294",
"ietf-otn-types@2018-06-07": "draft-ietf-ccamp-otn-tunnel-model- "ietf-otn-types@2018-06-07": "draft-ietf-ccamp-otn-tunnel-model-\
\
\02", \02",
"ietf-te-types@2018-07-01": "draft-ietf-teas-yang-te-16", "ietf-te-types@2018-07-01": "draft-ietf-teas-yang-te-16",
"ietf-te@2018-07-01": "draft-ietf-teas-yang-te-16", "ietf-te@2018-07-01": "draft-ietf-teas-yang-te-16",
"ietf-otn-tunnel@2018-06-07": "draft-ietf-ccamp-otn-tunnel- "ietf-otn-tunnel@2018-06-07": "draft-ietf-ccamp-otn-tunnel-model\
model\
\-02" \-02"
}, },
"// __RESTCONF_OPERATION__": { "// __RESTCONF_OPERATION__": {
"operation": "PUT", "operation": "PUT",
"url": "http://{{PNC1-ADDR}}/restconf/data/ietf-te:te" "url": "http://{{PNC1-ADDR}}/restconf/data/ietf-te:te"
}, },
"ietf-te:te": { "ietf-te:te": {
"tunnels": { "tunnels": {
"tunnel": [ "tunnel": [
{ {
"name": "mpi1-odu2-service", "name": "mpi1-odu2-service",
"// identifier": "ODU2-SERVICE-TUNNEL-ID @ MPI1", "// identifier": "ODU2-SERVICE-TUNNEL-ID @ MPI1",
"identifier": 1, "identifier": 1,
"description": "ODU2 Service implemented by ODU2 OTN "description": "ODU2 Service implemented by ODU2 OTN Tunne\
Tunne\
\l Segment @ MPI1", \l Segment @ MPI1",
"// encoding and switching-type": "ODU", "// encoding and switching-type": "ODU",
"encoding": "ietf-te-types:lsp-encoding-oduk ", "encoding": "ietf-te-types:lsp-encoding-oduk ",
"switching-type": "ietf-te-types:switching-otn", "switching-type": "ietf-te-types:switching-otn",
"// source": "None: transit tunnel segment", "// source": "None: transit tunnel segment",
"// destination": "None: transit tunnel segment", "// destination": "None: transit tunnel segment",
"// src-tp-id": "None: transit tunnel segment", "// src-tp-id": "None: transit tunnel segment",
"// dst-tp-id": "None: transit tunnel segment", "// dst-tp-id": "None: transit tunnel segment",
"// ietf-otn-tunnel:src-client-signal": "None: ODU "// ietf-otn-tunnel:src-client-signal": "None: ODU transit\
transit\
\ tunnel segment", \ tunnel segment",
"// ietf-otn-tunnel:dst-client-signal": "None: ODU "// ietf-otn-tunnel:dst-client-signal": "None: ODU transit\
transit\
\ tunnel segment", \ tunnel segment",
"bidirectional": true, "bidirectional": true,
"// protection": "No protection", "// protection": "No protection",
"// __ DEFAULT __ protection": { "// __ DEFAULT __ protection": {
"// __ DEFAULT __ enable": false "// __ DEFAULT __ enable": false
}, },
"// restoration": "No restoration", "// restoration": "No restoration",
"// __ DEFAULT __ restoration": { "// __ DEFAULT __ restoration": {
"// __ DEFAULT __ enable": false "// __ DEFAULT __ enable": false
}, },
skipping to change at page 70, line 28 skipping to change at page 68, line 23
}, },
"te-bandwidth": { "te-bandwidth": {
"ietf-otn-tunnel:odu-type": "ietf-otn-types:prot-ODU2" "ietf-otn-tunnel:odu-type": "ietf-otn-types:prot-ODU2"
}, },
"// hierarchical-link": "None: transit tunnel segment", "// hierarchical-link": "None: transit tunnel segment",
"p2p-primary-paths": { "p2p-primary-paths": {
"p2p-primary-path": [ "p2p-primary-path": [
{ {
"name": "mpi1-odu2-service-primary-path", "name": "mpi1-odu2-service-primary-path",
"path-scope": "ietf-te-types:path-scope-segment", "path-scope": "ietf-te-types:path-scope-segment",
"// te-bandwidth": "None: only the tunnel bandwidth "// te-bandwidth": "None: only the tunnel bandwidth \
\
\needs to be specified in transport applications", \needs to be specified in transport applications",
"explicit-route-objects": { "explicit-route-objects": {
"route-object-include-exclude": [ "route-object-include-exclude": [
{ {
"// comment": "Tunnel hand-off OTU2 ingress "// comment": "Tunnel hand-off OTU2 ingress in\
in\
\terface (S3-1)", \terface (S3-1)",
"index": 1, "index": 1,
"explicit-route-usage": "ietf-te-types:route- "explicit-route-usage": "ietf-te-types:route-i\
i\
\nclude-ero", \nclude-ero",
"num-unnum-hop": { "num-unnum-hop": {
"// node-id": "AN1 Node", "// node-id": "AN1 Node",
"node-id": "10.0.0.1", "node-id": "10.0.0.1",
"// link-tp-id": "AN1-1 LTP", "// link-tp-id": "AN1-1 LTP",
"link-tp-id": 1, "link-tp-id": 1,
"hop-type": "STRICT", "hop-type": "STRICT",
"direction": "INCOMING" "direction": "INCOMING"
} }
}, },
{ {
"// comment": "Tunnel hand-off ODU2 ingress "// comment": "Tunnel hand-off ODU2 ingress la\
la\
\bel (ODU2 over OTU2) at S3-1", \bel (ODU2 over OTU2) at S3-1",
"index": 2, "index": 2,
"explicit-route-usage": "ietf-te-types:route- "explicit-route-usage": "ietf-te-types:route-i\
i\
\nclude-ero", \nclude-ero",
"label-hop": { "label-hop": {
"te-label": { "te-label": {
"// __ DISCUSS __ odu-label": "How are HO- "// __ DISCUSS __ odu-label": "How are HO-\
\
\ODU (ODUk over OTUk) label represented?", \ODU (ODUk over OTUk) label represented?",
"// __ DISCUSS __ direction": "Check with "// __ DISCUSS __ direction": "Check with \
\
\TE Tunnel authors", \TE Tunnel authors",
"direction": "FORWARD " "direction": "FORWARD "
} }
} }
}, },
{ {
"// comment": "Tunnel hand-off OTU4 egress "// comment": "Tunnel hand-off OTU4 egress int\
int\
\erface (S2-1)", \erface (S2-1)",
"index": 3, "index": 3,
"explicit-route-usage": "ietf-te-types:route- "explicit-route-usage": "ietf-te-types:route-i\
i\
\nclude-ero", \nclude-ero",
"num-unnum-hop": { "num-unnum-hop": {
"// node-id": "AN1 Node", "// node-id": "AN1 Node",
"node-id": "10.0.0.1", "node-id": "10.0.0.1",
"// link-tp-id": "AN1-2 LTP", "// link-tp-id": "AN1-2 LTP",
"link-tp-id": 1, "link-tp-id": 1,
"hop-type": "STRICT", "hop-type": "STRICT",
"direction": "OUTGOING" "direction": "OUTGOING"
} }
}, },
{ {
"// comment": "Tunnel hand-off ODU2 egress "// comment": "Tunnel hand-off ODU2 egress lab\
lab\
\el (ODU2 over OTU4) at S2-1", \el (ODU2 over OTU4) at S2-1",
"index": 4, "index": 4,
"explicit-route-usage": "ietf-te-types:route- "explicit-route-usage": "ietf-te-types:route-i\
i\
\nclude-ero", \nclude-ero",
"label-hop": { "label-hop": {
"te-label": { "te-label": {
"ietf-otn-tunnel:tpn": 1, "ietf-otn-tunnel:tpn": 1,
"ietf-otn-tunnel:tsg": "ietf-otn- "ietf-otn-tunnel:tsg": "ietf-otn-types:tsg\
types:tsg\
\-1.25G", \-1.25G",
"ietf-otn-tunnel:ts-list": "1-8", "ietf-otn-tunnel:ts-list": "1-8",
"// __ DISCUSS __ direction": "Check with "// __ DISCUSS __ direction": "Check with \
\
\TE Tunnel authors", \TE Tunnel authors",
"direction": "FORWARD " "direction": "FORWARD "
} }
} }
} }
] ]
} }
} }
] ]
} }
} }
] ]
} }
} }
} }
skipping to change at page 72, line 30 skipping to change at page 70, line 15
} }
} }
] ]
} }
} }
] ]
} }
} }
} }
B.2.2. JSON Code: mpi1-odu2-tunnel-config.json B.2.2. JSON Code: mpi1-odu2-tunnel-config.json
The JSON code for this use case will be added in a future version of The JSON code for this use case will be added in a future version of
this document this document
An incomplete version is located on GitHub at: An incomplete version is located on GitHub at:
https://github.com/danielkinguk/transport-nbi https://github.com/danielkinguk/transport-nbi
B.2.3. JSON Code: mpi1-epl-service-config.json B.2.3. JSON Code: mpi1-epl-service-config.json
The JSON code for this use case will be added in a future version of The JSON code for this use case will be added in a future version of
this document this document
An incomplete version is located on GitHub at: An incomplete version is located on GitHub at:
https://github.com/danielkinguk/transport-nbi https://github.com/danielkinguk/transport-nbi
Authors' Addresses Authors' Addresses
Italo Busi (Editor) Italo Busi (Editor)
 End of changes. 309 change blocks. 
850 lines changed or deleted 650 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/