< draft-ietf-ccamp-transport-nbi-app-statement-13.txt   draft-ietf-ccamp-transport-nbi-app-statement-14.txt >
CCAMP Working Group I. Busi, Ed. CCAMP Working Group I. Busi, Ed.
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Informational D. King, Ed. Intended status: Informational D. King, Ed.
Expires: April 2, 2022 Old Dog Consulting Expires: 26 September 2022 Old Dog Consulting
H. Zheng, Ed. H. Zheng, Ed.
Huawei Huawei
Y. Xu, Ed. Y. Xu, Ed.
CAICT CAICT
September 29, 2021 25 March 2022
Transport Northbound Interface Applicability Statement Transport Northbound Interface Applicability Statement
draft-ietf-ccamp-transport-nbi-app-statement-13 draft-ietf-ccamp-transport-nbi-app-statement-14
Abstract Abstract
This document provides an analysis of the applicability of the YANG This document provides an analysis of the applicability of the YANG
models defined by the IETF (Traffic Engineering Architecture and models defined by the IETF (in particular in the Traffic Engineering
Signaling (TEAS) moreover, Common Control and Measurement Plane Architecture and Signaling (TEAS) and Common Control and Measurement
(CCAMP) WGs in particular) to support ODU transit services, Plane (CCAMP) working groups) to support ODU transit services,
Transparent client services and EPL/EVPL Ethernet services over OTN transparent client services, and Ethernet Private Line/Ethernet
single and multi-domain network scenarios. Virtual Private Line (EPL/EVPL) services over Optical Transport
Network (OTN) in single and multi-domain network scenarios.
This document also describes how existing YANG models can be used This document also describes how existing YANG models can be used
through a number of worked examples and JSON fragments. through several worked examples and JSON fragments.
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). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 2, 2022. This Internet-Draft will expire on 26 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 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 (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Revised BSD License text as
include Simplified BSD License text as described in Section 4.e of described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Revised BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. The Scope of this Document . . . . . . . . . . . . . . . 4 1.1. The Scope of this Document . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Conventions Used in this Document . . . . . . . . . . . . . . 7 3. Conventions Used in this Document . . . . . . . . . . . . . . 7
3.1. Topology and Traffic Flow Processing . . . . . . . . . . 7 3.1. Topology and Traffic Flow Processing . . . . . . . . . . 7
3.2. JSON code . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Scenarios Description . . . . . . . . . . . . . . . . . . . . 8
4. Scenarios Description . . . . . . . . . . . . . . . . . . . . 9 4.1. Reference Network . . . . . . . . . . . . . . . . . . . . 8
4.1. Reference Network . . . . . . . . . . . . . . . . . . . . 9 4.2. Topology Abstractions . . . . . . . . . . . . . . . . . . 12
4.2. Topology Abstractions . . . . . . . . . . . . . . . . . . 13 4.3. Service Configuration . . . . . . . . . . . . . . . . . . 14
4.3. Service Configuration . . . . . . . . . . . . . . . . . . 15 4.3.1. ODU Transit . . . . . . . . . . . . . . . . . . . . . 14
4.3.1. ODU Transit . . . . . . . . . . . . . . . . . . . . . 15 4.3.2. EPL over ODU . . . . . . . . . . . . . . . . . . . . 15
4.3.2. EPL over ODU . . . . . . . . . . . . . . . . . . . . 16 4.3.3. Transparent Client Services . . . . . . . . . . . . . 16
4.3.3. Transparent Client Services . . . . . . . . . . . . . 17 4.3.4. EVPL over ODU . . . . . . . . . . . . . . . . . . . . 17
4.3.4. EVPL over ODU . . . . . . . . . . . . . . . . . . . . 18 4.4. Multi-Function Access Links . . . . . . . . . . . . . . . 18
4.4. Multi-function Access Links . . . . . . . . . . . . . . . 19 4.5. Protection and Restoration Configuration . . . . . . . . 19
4.5. Protection and Restoration Configuration . . . . . . . . 20 4.5.1. Linear Protection (End-to-End) . . . . . . . . . . . 20
4.5.1. Linear Protection (end-to-end) . . . . . . . . . . . 21 4.5.2. Segmented Protection . . . . . . . . . . . . . . . . 21
4.5.2. Segmented Protection . . . . . . . . . . . . . . . . 22 4.6. Event Notifications and Alarms . . . . . . . . . . . . . 21
4.6. Notification . . . . . . . . . . . . . . . . . . . . . . 22 4.7. Path Computation with Constraints . . . . . . . . . . . . 22
4.7. Path Computation with Constraints . . . . . . . . . . . . 23 5. YANG Model Analysis . . . . . . . . . . . . . . . . . . . . . 23
5. YANG Model Analysis . . . . . . . . . . . . . . . . . . . . . 24 5.1. YANG Models for Topology Abstraction . . . . . . . . . . 23
5.1. YANG Models for Topology Abstraction . . . . . . . . . . 24 5.1.1. Domain 1 Black Topology Abstraction . . . . . . . . . 24
5.1.1. Domain 1 Black Topology Abstraction . . . . . . . . . 25 5.1.2. Domain 2 Black Topology Abstraction . . . . . . . . . 28
5.1.2. Domain 2 Black Topology Abstraction . . . . . . . . . 29 5.1.3. Domain 3 White Topology Abstraction . . . . . . . . . 29
5.1.3. Domain 3 White Topology Abstraction . . . . . . . . . 30 5.1.4. Multi-domain Topology Merging . . . . . . . . . . . . 29
5.1.4. Multi-domain Topology Merging . . . . . . . . . . . . 30 5.2. YANG Models for Service Configuration . . . . . . . . . . 32
5.2. YANG Models for Service Configuration . . . . . . . . . . 33 5.2.1. ODU Transit Service . . . . . . . . . . . . . . . . . 35
5.2.1. ODU Transit Service . . . . . . . . . . . . . . . . . 36 5.2.2. EPL over ODU Service . . . . . . . . . . . . . . . . 37
5.2.2. EPL over ODU Service . . . . . . . . . . . . . . . . 38 5.2.3. Other OTN Client Services . . . . . . . . . . . . . . 40
5.2.3. Other OTN Client Services . . . . . . . . . . . . . . 41 5.2.4. EVPL over ODU Service . . . . . . . . . . . . . . . . 41
5.2.4. EVPL over ODU Service . . . . . . . . . . . . . . . . 42 5.3. YANG Models for Protection Configuration . . . . . . . . 42
5.3. YANG Models for Protection Configuration . . . . . . . . 43 5.3.1. Linear Protection (end-to-end) . . . . . . . . . . . 42
5.3.1. Linear Protection (end-to-end) . . . . . . . . . . . 43
5.3.2. Segmented Protection . . . . . . . . . . . . . . . . 44 5.3.2. Segmented Protection . . . . . . . . . . . . . . . . 44
5.4. Notifications . . . . . . . . . . . . . . . . . . . . . . 46 5.4. Notifications . . . . . . . . . . . . . . . . . . . . . . 45
5.5. Path Computation with Constraints . . . . . . . . . . . . 46 5.5. Path Computation with Constraints . . . . . . . . . . . . 46
6. Security Considerations . . . . . . . . . . . . . . . . . . . 46
6. Security Considerations . . . . . . . . . . . . . . . . . . . 47
6.1. OTN Security . . . . . . . . . . . . . . . . . . . . . . 47 6.1. OTN Security . . . . . . . . . . . . . . . . . . . . . . 47
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 47
8.1. Normative References . . . . . . . . . . . . . . . . . . 47 8.1. Normative References . . . . . . . . . . . . . . . . . . 47
8.2. Informative References . . . . . . . . . . . . . . . . . 49 8.2. Informative References . . . . . . . . . . . . . . . . . 49
Appendix A. Validating a JSON fragment against a YANG Model . . 51 Appendix A. Validating a JSON fragment against a YANG Model . . 51
A.1. Manipulation of JSON fragments . . . . . . . . . . . . . 51 A.1. JSON CODE . . . . . . . . . . . . . . . . . . . . . . . . 51
A.2. Comments in JSON fragments . . . . . . . . . . . . . . . 52 A.2. Manipulation of JSON fragments . . . . . . . . . . . . . 52
A.3. Validation of JSON fragments: DSDL-based approach . . . . 52 A.3. Comments in JSON fragments . . . . . . . . . . . . . . . 53
A.4. Validation of JSON fragments: why not using an XSD-based A.4. Validation of JSON fragments: DSDL-based approach . . . . 53
approach . . . . . . . . . . . . . . . . . . . . . . . . 53 A.5. Validation of JSON fragments: why not using an XSD-based
Appendix B. Detailed JSON Examples . . . . . . . . . . . . . . . 53 approach . . . . . . . . . . . . . . . . . . . . . . . . 54
B.1. JSON Examples for Topology Abstractions . . . . . . . . . 53 Appendix B. Detailed JSON Examples . . . . . . . . . . . . . . . 54
B.1.1. JSON Code: mpi1-otn-topology.json . . . . . . . . . . 53 B.1. JSON Examples for Topology Abstractions . . . . . . . . . 54
B.1.2. JSON Code: mpi1-eth-topology.json . . . . . . . . . . 75 B.1.1. JSON Code: mpi1-otn-topology.json . . . . . . . . . . 55
B.2. JSON Examples for Service Configuration . . . . . . . . . 80 B.1.2. JSON Code: mpi1-eth-topology.json . . . . . . . . . . 77
B.2.1. JSON Code: mpi1-odu2-service-config.json . . . . . . 80 B.2. JSON Examples for Service Configuration . . . . . . . . . 82
B.2.2. JSON Code: mpi1-odu2-tunnel-config.json . . . . . . . 83 B.2.1. JSON Code: mpi1-odu2-service-config.json . . . . . . 82
B.2.3. JSON Code: mpi1-epl-service-config.json . . . . . . . 86 B.2.2. JSON Code: mpi1-odu2-tunnel-config.json . . . . . . . 85
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 87 B.2.3. JSON Code: mpi1-epl-service-config.json . . . . . . . 88
Additional Authors' Addresses . . . . . . . . . . . . . . . . . . 88 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 89
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 89 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 91
1. Introduction 1. Introduction
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 a single technology platform.
often managed using proprietary interfaces to dedicated Element They are often managed using proprietary interfaces to dedicated
Management Systems (EMS), Network Management Systems (NMS) and Element Management Systems (EMS), Network Management Systems (NMS)
increasingly Software Defined Network (SDN) controllers. and increasingly Software Defined Network (SDN) controllers.
Support of packet connectivity services over transport network Support of packet connectivity services over a transport network
domains are critical for a wide range of applications and services, domain is critical for a wide range of applications and services,
including data center and LAN interconnects, Internet service including data center and LAN interconnects, Internet service
backhauling, mobile backhaul and enterprise Carrier Ethernet backhauling, mobile backhaul and enterprise Carrier Ethernet
services. A clear goal of operators is to automate the setup of services. An explicit goal of operators is to automate the setup of
these connectivity services across multiple transport network these connectivity services across multiple transport network
domains, that may utilize different technologies. domains, that may utilize different technologies.
A well-defined common open interface to each domain controller or a A well-defined common open interface to each domain controller or a
management system is required for network operators to control multi- management system is required for network operators to control multi-
vendor and multi-domain networks and also enable coordination and vendor and multi-domain networks and also enable coordination and
automation of service provisioning. This is facilitated by using automation of service provisioning. This is facilitated by using
standardized data models (e.g., YANG models), and an appropriate standardized data models (e.g., YANG models), and an appropriate
protocol (e.g., RESTCONF [RFC8040]). protocol (e.g., RESTCONF [RFC8040]).
This document examines the applicability of the YANG models being This document examines the applicability of the YANG models defined
defined by IETF (Traffic Engineering Architecture and Signaling by the IETF (in particular in the Traffic Engineering Architecture
(TEAS) moreover, Common Control and Measurement Plane (CCAMP) WGs in and Signaling (TEAS) and Common Control and Measurement Plane (CCAMP)
particular) to support Optical Transport Networks (OTN) single and working groups) to support OTN in a single and multi-domain network
multi-domain scenarios. scenarios.
1.1. The Scope of this Document 1.1. The Scope of this Document
This document assumes a reference architecture, including interfaces, This document assumes a reference architecture, including interfaces,
based on the Abstraction and Control of Traffic- Engineered Networks based on the Framework for Abstraction and Control of Traffic-
(ACTN), defined in [RFC8453]. Engineered Networks (ACTN), defined in [RFC8453].
The focus of this document is on the interface between the Multi The focus of this document is on the interface between the Multi
Domain Service Coordinator (MDSC) and a Provisioning Network Domain Service Coordinator (MDSC) and a Provisioning Network
Controller (PNC), controlling a transport network domain, called Controller (PNC), controlling a transport network domain, called
MDSC-PNC Interface (MPI) in [RFC8453]. MDSC-PNC Interface (MPI) in [RFC8453].
It is worth noting that the same MPI analyzed in this document could It is worth noting that the same MPI analyzed in this document could
be used between hierarchical MDSC controllers, as shown in Figure 4 be used between hierarchical MDSC controllers, as shown in Figure 4
of [RFC8453]. of [RFC8453].
Detailed analysis of the interface between the Customer Network A detailed analysis of the interface between the Customer Network
Controller (CNC) and the MDSC, called CNC-MDSC Interface (CMI) in Controller (CNC) and the MDSC, called CNC-MDSC Interface (CMI) in
[RFC8453], as well as of the interface between service and network [RFC8453], as well as the interface between service and network
orchestrators are outside the scope of this document. However, when orchestrators are outside the scope of this document. However, when
needed, this document describes some considerations and assumptions needed, this document describes some considerations and assumptions
about the information which needs to be provided at these interfaces. about the information which needs to be provided at these interfaces.
The list of the IETF YANG models which apply to the ACTN MPI can be
The list of the IETF YANG models which are applicable to the ACTN MPI found in [ACTN-YANG].
can be found in [ACTN-YANG].
The Functional Requirements for the transport API as described in the The Functional Requirements for the transport API as described in the
Optical Networking Foundation (ONF) document [ONF_TR-527] have been Optical Networking Foundation (ONF) document [ONF_TR-527] have been
taken as input for defining the reference scenarios analyzed in this taken as input for defining the reference scenarios analyzed in this
document. document.
The analysis provided in this document confirms that the IETF YANG The analysis provided in this document confirms that the IETF YANG
models defined in [RFC8453], [RFC8795], [OTN-TOPO], [CLIENT-TOPO], models defined in [RFC8453], [RFC8795], [OTN-TOPO], [CLIENT-TOPO],
[TE-TUNNEL], [PATH-COMPUTE], [OTN-TUNNEL] and [CLIENT-SIGNAL] can be [TE-TUNNEL], [PATH-COMPUTE], [OTN-TUNNEL], and [CLIENT-SIGNAL] can be
used together to control a multi-domain OTN network to support used together to control a multi-domain OTN network to support
different types of multi-domain services, such as ODU transit different types of multi-domain services, such as Optical Data Unit
services, Transparent client services and EPL/EVPL Ethernet services, (ODU) transit services, Transparent client services and EPL/EVPL
over a multi-domain OTN connection, satisfying also the requirements Ethernet Private Line/Ethernet Virtual Private Line (EPL/EVPL)
in [ONF_TR-527]. services, over a multi-domain OTN connection, satisfying also the
requirements in [ONF_TR-527].
2. Terminology 2. Terminology
Domain A domain, as defined in [RFC4655], is "any collection of Domain A domain, as defined in [RFC4655], is "any collection of
network elements within a common sphere of address management or network elements within a common sphere of address management or
path computation responsibility". Specifically, within this path computation responsibility". Specifically, within this
document, we mean a part of an operator's network that is under document, we mean a part of an operator's network that is under
common management (i.e., under shared operational management using common management (i.e., under shared operational management using
the same instances of a tool and the same policies). Network the same instances of a tool and the same policies). Network
elements will often be grouped into domains based on technologies, elements will often be grouped into domains based on technologies,
vendor profiles, or geographic proximity. vendor profiles, or geographic proximity.
CNC Customer Network Controller CNC Customer Network Controller
Connection The data plane configuration of an LSP, within this Connection The data plane configuration of an LSP: within this
document it is typically an ODU LSP. An end-to-end connection/LSP document it is typically an ODU LSP. An end-to-end connection/LSP
represents an entire connection/LSP between the connection/LSP represents an entire connection between the connection node end-
node end-points. A connection/LSP segment represents a portion of points. A connection/LSP segment represents a portion of the end-
the end-to-end connection/LSP. to-end connection.
Connectivity Service A service, or connectivity service, in the Connectivity Service A connectivity service, in the context of this
context of this document can be considered as some form of document, can be considered as a connection between customer
connectivity service between customer sites across the network sites, across the network operator's network [RFC8309].
operator's network [RFC8309].
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
ILL Inter-Layer Lock ILL Inter-Layer Lock
Link A link, or a physical link, is used to reprent the adjacency Link It is used to represent the adjacency between two nodes.
between two physical nodes. The term OTN link represents a link The term physical link represents a link between two physical
between two OTN switching physical nodes. nodes. The term OTN link represents a link between two OTN nodes.
LSP Label Switched Path LSP Label Switched Path
LTP Link Termination Point LTP Link Termination Point
MDSC Multi-Domain Service Coordinator MDSC Multi-Domain Service Coordinator
Network Configuration As described in [RFC8309] it describes the Network Configuration As described in [RFC8309] it describes the
instructions provided to a controller on how to configure parts of instructions provided to a controller on how to configure parts of
a network. a network.
skipping to change at page 6, line 4 skipping to change at page 5, line 47
LTP Link Termination Point LTP Link Termination Point
MDSC Multi-Domain Service Coordinator MDSC Multi-Domain Service Coordinator
Network Configuration As described in [RFC8309] it describes the Network Configuration As described in [RFC8309] it describes the
instructions provided to a controller on how to configure parts of instructions provided to a controller on how to configure parts of
a network. a network.
ODU Optical Channel Data Unit ODU Optical Channel Data Unit
OTU Optical Channel Transport Unit OTU Optical Channel Transport Unit
OTN Optical Transport Network OTN Optical Transport Network
PNC Provisioning Network Controller PNC Provisioning Network Controller
Protection Switching Protection switching, as defined in Protection Switching Protection switching, as defined in
[ITU-T_G.808.1] and [RFC4427], provides the capability to swith [ITU-T_G.808.1] and [RFC4427], provides the capability to switch
the traffic in case of network failurs over pre-allocated networks the traffic in case of network failures over pre-allocated
resourse. Typically linear protection methods would be used and networks resources. Typically linear protection methods would be
configured to operate as 1+1 unidirectional, 1+1 bidirectional or used and configured to operate as 1+1 unidirectional, 1+1
1:n bidirectional. This ensures fast and simple service bidirectional or 1:n bidirectional. This ensures fast and simple
survivability. service survivability.
Protection Transport Entity/LSP A protection transport entity/LSP, Protection Transport Entity/LSP A protection transport entity/LSP,
as defined in [ITU-T_G.808.1] and [RFC4427], represents the path as defined in [ITU-T_G.808.1] and [RFC4427], represents the path
where the "normal" user traffic is transported during protection where the "normal" user traffic is transported during protection
switching events (e.g., when the working transport entity/LSP switching events (e.g., when the working transport entity/LSP
fails). fails).
Restoration Restoration methods, as defined in [RFC4427], provide Restoration Restoration methods, as defined in [RFC4427], provide
the capability to reroute and restore traffic around network the capability to reroute and restore traffic around network
failures without the necessity to allocate network resources as failures without the necessity to allocate network resources as
required for dedicated 1+1 protection schemes. On the other hand, required for dedicated 1+1 protection schemes. On the other hand,
restoration times are typically longer than protection switching restoration times are typically longer than protection switching
times. times.
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.
TE Link As defined in [RFC8795], it is an element of a TE topology, TE Link As defined in [RFC8795], is an element of a TE topology,
presented as an edge on TE graph. presented as an edge on TE graph.
TE Tunnel As defined in [TE-TUTORIAL], it is a connection-oriented TE Tunnel As defined in [TE-TUNNEL], it is a connection-oriented
service provided by a layer network of delivery of a client's data service provided by a layered network of delivery of a client's
between source and destination tunnel termination points. data between source and destination tunnel termination points.
See also [TE-TUTORIAL].
TE Tunnel Segment As defined in [TE-TUTORIAL], it is a part of a TE Tunnel Segment As defined in [TE-TUNNEL], it is a part of a
multi-domain TE tunnel that spans. multi-domain TE tunnel that spans. See also [TE-TUTORIAL].
TE Tunnel Hand-off As defined in [TE-TUTORIAL], it is an access link TE Tunnel Hand-off It is an access or inter-domain LTP by which a
or inter-domain link by which a multi-domain TE tunnel enters or multi-domain TE tunnel enters or exits a given network domain.
exits a given network domain. See also [TE-TUTORIAL].
Note - The three definitions above are currently in [TE-TUTORIAL] but Note - The three definitions above are currently in [TE-TUTORIAL] but
it is expected that they will be moved to [TE-TUNNEL]. When this it is expected that they will be moved to [TE-TUNNEL]. When this
happens, the reference will be updated and the [TE-TUTORIAL] happens, the reference will be updated and the [TE-TUTORIAL]
reference will be downgraded to Informative. reference will be downgraded to Informative.
TPN Tributary Port Number TPN Tributary Port Number
TTP Tunnel Termination Point TTP Tunnel Termination Point
skipping to change at page 8, line 23 skipping to change at page 8, line 19
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 the case of through the network in the forward direction. In the case of
bidirectional paths, the forward and backward directions are selected bidirectional paths, the forward and backward directions are selected
arbitrarily, but the convention is consistent between working/ arbitrarily, but the convention is consistent between working/
protection path pairs, as well as across multiple domains. protection path pairs, as well as across multiple domains.
3.2. JSON code The use of curly brackets denotes multiple nodes in a list.
This document provides some detailed JSON code examples to describe
how the YANG models being developed by the IETF (TEAS and CCAMP WG in
particular) may be used. The scenario examples are provided using
JSON to facilitate readability.
Different objects need to have an identifier. The convention used to
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 "-",
followed by "-ID". For example, the mnemonic identifier for node S3
would be S3-NODE-ID.
The JSON language does not support the insertion of comments that
have been instead found to be useful when writing the examples. This
document will insert comments into the JSON code as JSON name/value
pair with the JSON name string starting with the "//" characters.
For example, when describing the example of a TE Topology instance
representing the ODU Abstract Topology exposed by the Transport PNC,
the following comment has been added to the JSON code:
"// comment": "ODU Abstract Topology @ MPI",
The JSON code examples provided in this document have been validated
against the YANG models following the validation process described in
Appendix A, which would not consider the comments.
To have successful validation of the examples, some numbering scheme
has been defined to assign identifiers to the different entities
which would pass the syntax checks. In that case, to simplify the
reading, another JSON name/value pair formatted as a comment and
using the mnemonic identifiers is also provided. For 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 two JSON name/
value pair:
"// te-node-id": "S3-NODE-ID",
"te-node-id": "10.0.0.3",
The first JSON name/value pair will be automatically removed in the
first step of the validation process, while the second JSON name/
value pair will be validated against the YANG model definitions.
4. Scenarios Description 4. Scenarios Description
4.1. Reference Network 4.1. Reference Network
The physical topology of the reference network is shown in Figure 1. The physical topology of the reference network is shown in Figure 1.
It represents an OTN network composed of three transport network It represents an OTN network composed of three transport network
domains which provide connectivity services to an IP customer network domains that provide connectivity services to an IP customer network
through nine access links: through nine 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
skipping to change at page 10, line 42 skipping to change at page 9, line 42
: | / S17 -- S18 --------- R8 : | / S17 -- S18 --------- R8
: | / \ / : : : | / \ / : :
: S19 ---- S20 ---- S21 ------------ R9 : S19 ---- S20 ---- S21 ------------ R9
: : : : : :
:...............................: :............. :...............................: :.............
Figure 1: Reference network Figure 1: Reference network
This document assumes that all the Si transport network switching This document assumes that all the Si transport network switching
nodes are capable of switching in the electrical domain (ODU nodes are capable of switching in the electrical domain (ODU
switching) moreover, that all the Si-Sj OTN links within the switching) moreover, all the Si-Sj OTN links within the transport
transport network (intra-domain or inter-domain) are 100G links while network (intra-domain or inter-domain) are 100G links while the
the access Ri-Sj links are 10G links. access Ri-Sj links are 10G links.
This document also assumes that within the transport network, the This document also assumes that within the transport network, the
physical/optical connections supporting the Si-Sj OTN links (up to physical/optical connections supporting the Si-Sj OTN links (up to
the OTU4 trail), are pre-provisioned using mechanisms which are the OTU4 trail), are pre-provisioned using mechanisms that are
outside the scope of this document and are not exposed at the MPIs to outside the scope of this document and are not exposed at the MPIs to
the MDSC. the MDSC.
Different transmission technologies can be used on the access links Different transmission technologies can be used on the access links
(e.g., Ethernet, STM-N and OTU). Section 4.3 provides more details (e.g., Ethernet, Synchronous Transport Module (STM) and OTU).
about the different assumptions on the access links for different Section 4.3 provides more details about the different assumptions on
types of connectivity services and Section 4.4 describes the control the access links for different types of connectivity services, and
of access links which can support different technology configurations Section 4.4 describes the control of access links that can support
(e.g., STM-64, 10GE or OTU2) depending on the type of service being different technology configurations (e.g., STM-64, 10GE or OTU2)
configured (multi-function access links). depending on the type of service being configured (multi-function
access links).
To carry client signals (e.g., Ethernet or STM-N) over OTN, some ODU To carry client signals (e.g., Ethernet or STM-N) over OTN, some ODU
termination and adaptation resources need to be available on the termination and adaptation resources need to be available on the
physical edge nodes (e.g., node S3 and S18). The location of these physical edge nodes (e.g., node S3 and S18). The location of these
resources within the physical node is implementation specific and resources within the physical node is implementation-specific and
outside the scope of standardization. This document assumes that outside the scope of standardization. This document assumes that
these termination and adaptation resources are located on the these termination and adaptation resources are located on the
physical interfaces of the edge nodes terminating the access links. physical interfaces of the edge nodes terminating the access links.
In other words, each physical access link has a set dedicated ODU In other words, each physical access link has a set of dedicated ODU
termination and adaptation resources. termination and adaptation resources.
The transport network control architecture, shown in Figure 2, The transport network control architecture, shown in Figure 2,
follows the ACTN architecture as defined in the ACTN framework follows the ACTN architecture as defined in the ACTN framework
document [RFC8453], and uses the same functional components: document [RFC8453], and uses the same functional components:
-------------- --------------
| | | |
| CNC | | CNC |
| | | |
skipping to change at page 12, line 46 skipping to change at page 11, line 46
----- ( ) ----- ( )
( ) ( )
----- -----
Figure 2: Controlling Hierarchies Figure 2: Controlling Hierarchies
The NEs within network domains 1, 2 and 3 of Figure 1 are controlled, The NEs within network domains 1, 2 and 3 of Figure 1 are controlled,
respectively, by PNC1, PNC2 and PNC3 of Figure 2. The MDSC control respectively, by PNC1, PNC2 and PNC3 of Figure 2. The MDSC control
the end-to-end network through the MPIs toward the underlying PNCs. the end-to-end network through the MPIs toward the underlying PNCs.
The ACTN framework facilitates the separation of the network and The ACTN framework facilitates separating the network and service
service control from the underlying technology. It helps the control from the underlying technology. It helps the customer to
customer to define the network as desired by business needs. The CMI define the network as desired by business needs. The CMI is defined
is defined to keep a minimal level of dependency (or no dependency at to keep a minimal level of dependency (or no dependency at all) from
all) from the underlying network technologies. The MPI instead the underlying network technologies. The MPI instead requires some
requires some specialization according to the domain technology. specialization according to the domain technology.
The control interfaces within the scope of this document are the The control interfaces within the scope of this document are the
three MPIs, as shown in Figure 2. three MPIs, as shown in Figure 2.
The split of functionality at the MPI in the ACTN architecture The split of functionality at the MPI in the ACTN architecture
between the MDSC (multi-domain controller) and the PNCs (domain between the MDSC and the PNCs, is equivalent to separation
controllers), is equivalent to separation functionality assumed in functionality assumed in the ONF T-API interface, as described in the
the ONF T-API interface, as described in the ONF T-API multi-domain ONF T-API multi-domain use cases [ONF_TR-527]. Furthermore, this
use cases [ONF_TR-527]. Furthermore, this functional separation is functional separation is similarly defined in the MEF PRESTO
similarly defined in the MEF PRESTO interface between the Service interface between the Service Orchestration Functionality (SOF) and
Orchestration Functionality (SOF) and the Infrastructure Control and the Infrastructure Control and Management (ICM) in the MEF LSO
Management (ICM) in the MEF LSO Architecture [MEF55]. Architecture [MEF55].
This document does not make any assumption about the control This document does not make any assumption about the control
architecture of the customer IP network: in line with [RFC8453], the architecture of the customer IP network: in line with [RFC8453], the
CNC is just a functional component within the customer control CNC is just a functional component within the customer control
architecture which is capable of requesting connectivity services on architecture which is capable of requesting connectivity services on
demand between IP routers at the CMI. demand between IP routers at the CMI.
The CNC can request connectivity services between IP routers which The CNC can request connectivity services between IP routers which
can be attached to different transport network domains (e.g., between can be attached to different transport network domains (e.g., between
R1 and R8 in Figure 1) or to the same transport network domain (e.g., R1 and R8 in Figure 1) or to the same transport network domain (e.g.,
skipping to change at page 13, line 50 skipping to change at page 12, line 50
and decide the network configuration to request only at the MPI of and decide the network configuration to request only at the MPI of
the PNC controlling that domain (e.g., MPI1 of PNC1 in Figure 2). the PNC controlling that domain (e.g., MPI1 of PNC1 in Figure 2).
4.2. Topology Abstractions 4.2. Topology Abstractions
Abstraction provides a selective method for representing connectivity Abstraction provides a selective method for representing connectivity
information within a domain. There are multiple methods to abstract information within a domain. There are multiple methods to abstract
a network topology. This document assumes the abstraction method a network topology. This document assumes the abstraction method
defined in [RFC7926]: defined in [RFC7926]:
Abstraction is the process of applying the policy to the available Abstraction is the process of applying policy to the available TE
TE information within a domain, to produce selective information information within a domain, to produce selective information that
that represents the potential ability to connect across the represents the potential ability to connect across the domain.
domain. Thus, abstraction does not necessarily offer all possible
connectivity options, but presents a general view of potential Thus, abstraction does not necessarily offer all possible
connectivity options, but it presents a general view of potential
connectivity according to the policies that determine how the connectivity according to the policies that determine how the
domain's administrator wants to allow the domain resources to be domain's administrator wants to allow the domain resources to be
used. used.
[RFC8453] Provides the context of topology abstraction in the ACTN [RFC8453] Provides the context of topology abstraction in the ACTN
architecture and discusses a few alternatives for the abstraction architecture and discusses a few alternatives for the abstraction
methods for both packet and optical networks. This is an important methods for both packet and optical networks. This is an important
consideration since the choice of the abstraction method impacts consideration since the choice of the abstraction method impacts
protocol design and the information it carries. According to protocol design and the information it carries. According to
[RFC8453], there are three types of topologies: [RFC8453], there are three types of topologies:
o White topology: This is a case where the PNC provides the actual * 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 * Black topology: The entire domain network is abstracted as a
single virtual node with the access links and inter-domain links single virtual node with the access links and inter-domain links
without disclosing any node internal connectivity information; without disclosing any node internal connectivity information;
o Grey topology: This abstraction level is between black topology * Grey topology: This abstraction level is between black topology
and white topology from a granularity point of view. and white topology from a granularity point of view.
Each PNC should provide the MDSC a network topology abstraction Each PNC should provide the MDSC a network topology abstraction
hiding the internal details of the physical domain network topology hiding the internal details of the physical domain network topology
controlled by the PNC. As described in section 3 of [RFC8453], the controlled by the PNC. As described in section 3 of [RFC8453], the
level of abstraction provided by each PNC is based on the PNC level of abstraction provided by each PNC is based on the PNC
configuration parameters and it is independent of the abstractions configuration parameters and it is independent of the abstractions
provided by other PNCs. Therefore, it is possible that different provided by other PNCs. Therefore, it is possible that different
PNCs provide different types of topology abstractions. The MDSC can PNCs provides different topology abstractions. The MDSC can operate
operate on each MPI abstract topology regardless of, and on each MPI abstract topology regardless of, and independently from,
independently from, the type of abstraction provided by its the type of abstraction provided by its underlying PNC.
underlying PNC.
For analyzing how the MDSC can operate on an abstract topology For analyzing how the MDSC can operate on an abstract topology
provided by several PNcs that independently applied different provided by several PNCs that independently applied different
abstraction policies and therefore provided different types of abstraction policies and therefore provided different types of
abstract topologies, the following assumptions are made for the abstract topologies, the following assumptions are made for the
reference network in Figure 1: reference network in Figure 1:
o PNC1 and PNC2 provide black topology abstractions which expose at * PNC1 and PNC2 provide black topology abstractions which expose at
MPI1, and MPI2 respectively, a single virtual node (representing MPI1, and MPI2 respectively, a single virtual node (representing
the whole network domain 1, and domain 2 respectively). the whole network domain 1, and domain 2 respectively).
o PNC3 provides a white topology abstraction which exposes at MPI3 * PNC3 provides a white topology abstraction which exposes at MPI3
all the physical nodes and links within network domain 3. all the physical nodes and links within network domain 3.
The MDSC should be capable of stitching together the abstracted The MDSC should be capable of stitching together the abstracted
topologies provided by each PNC to build its view of the multi- topologies provided by each PNC to build its view of the multi-
domain network topology. This topology knowledge may require proper domain network topology. This topology knowledge may require proper
oversight, including the application of local policy, configuration oversight, including the application of local policy, configuration
methods, and the application of a trust model. Methods of how to methods, and the application of a trust model. Methods of how to
manage these aspects are out of scope for this document, but manage these aspects are out of scope for this document, but
recomandations are provided in the Security section of this document. recomandations are provided in the Security section of this document.
The MDSC can also provide topology abstraction of its view of the The MDSC can also provide topology abstraction of its view of the
multi-domain network topology at its CMIs depending on the customers' multi-domain network topology at its CMIs depending on the customers'
needs and policies: it can provide different types of topology needs and policies: it can provide different topology abstractions at
abstractions at different CMIs. Analyzing the topology abstractions different CMIs. Analyzing the topology abstractions provided by the
provided by the MDSC to its CMIs is outside the scope of this MDSC to its CMIs is outside the scope of this document.
document.
4.3. Service Configuration 4.3. Service Configuration
In the following scenarios, it is assumed that the CNC is capable of In the following scenarios, it is assumed that the CNC is capable of
requesting connectivity services from the MDSC, for example to requesting connectivity services from the MDSC, for example, to
interconnect IP routers. interconnect IP routers.
The type of connectivity services depends on the type of physical The type of connectivity services depends on the type of physical
links (e.g. OTN link, ETH link or SDH link) between the routers and links (e.g. OTN link, ETH link or SDH link) between the routers and
transport network. transport network.
The packet processing inside IP routers, including packet The packet processing inside IP routers, including packet
encapsualation and decapsulation, Ri (PKT -> foo) and Rj (foo -> encapsualation and decapsulation, Ri (PKT -> foo) and Rj (foo ->
PKT), are assumed to be performed by means that are not under the PKT), are assumed to be performed by means that are not under the
control of, and not visible to, the MDSC nor to the PNCs. Therefore, control of, and not visible to, the MDSC or to the PNCs. Therefore,
these mechanisms are outside the scope of this document. these mechanisms are outside the scope of this 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. network can be 10G OTN links.
In this case, it is assumed that the physical/optical In this case, it is assumed that the physical/optical
interconnections below the ODU layer (up to the OTU2 trail) are pre- interconnections below the ODU layer (up to the OTU2 trail) are pre-
provisioned using mechanisms which are outside the scope of this provisioned using mechanisms which are outside the scope of this
document and not exposed at the MPIs between the PNCs and the MDSC. document and not exposed at the MPIs between the PNCs and the MDSC.
For simplicity of the description, it is also assumed that these For simplicity of the description, it is also assumed that these
interfaces are not channelized (i.e., they can only support one interfaces are not channelized (i.e., they can only support one
ODU2). ODU2).
When a 10Gb IP link between R1 and R8 is needed, an ODU2 end-to-end When a 10Gb IP connectivity service between R1 and R8 is needed, an
connection needs to be created, passing through transport network ODU2 end-to-end connection needs to be created, passing through
nodes S3, S1, S2, S31, S33, S34, S15 and S18 which belong to transport network nodes S3, S1, S2, S31, S33, S34, S15 and S18, which
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)], R8 [ODU2 -> (PKT)] S15 [(ODU2)], S18 [(ODU2)], R8 [ODU2 -> (PKT)]
The MDSC receives, at the CMI,the request to create an ODU2 transit The MDSC receives, at the CMI, the request to create an ODU2 transit
service between the access links on S3 and S18, which belong to service between the access links on S3 and S18, which belong to
different PNC domains (multi-domain service request). The MDSC also different PNC domains (multi-domain service request). The MDSC also
determines the network configuration requests to be sent to its determines the network configuration requests to be sent to its
underlying PNCs, at the MPIs, to coordinate the setup of a multi- underlying PNCs, at the MPIs, to coordinate the setup of a multi-
domain ODU2 connection segment between the access links on S3 and domain ODU2 connection segment between the access links on S3 and
S18. S18.
When a 10Gb IP link between R1 and R3 is needed, an ODU2 end-to-end When a 10Gb IP connectivity service between R1 and R3 is needed, an
connection needs to be created, passing through transport network ODU2 end-to-end connection needs to be created, passing through
nodes S3, S5 and S6 which belong to the same PNC domain (single- transport network nodes S3, S5 and S6 which belong to the same PNC
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)]
As described in Section 4.1, the mechanisms, used by the CNC at the As described in Section 4.1, the mechanisms, used by the CNC at the
CMI, are independent on whether the service request is single-domain CMI, are independent on whether the service request is single-domain
service or multi-domain. service or multi-domain.
The MDSC can figure out that it needs to setup an ODU2 transit The MDSC can figure out that it needs to setup an ODU2 transit
service between the access links on S3 and S6, which belong to the service between the access links on S3 and S6, which belong to the
skipping to change at page 16, line 46 skipping to change at page 15, line 44
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 10G Ethernet physical links (10GE). network can be 10G Ethernet physical links (10GE).
In this case, it is assumed that the Ethernet physical interfaces (up In this case, it is assumed that the Ethernet physical interfaces (up
to the MAC layer) are pre-provisioned using mechanisms which are to the MAC layer) are pre-provisioned using mechanisms which are
outside the scope of this document and not exposed at the MPIs outside the scope of this document and not exposed at the MPIs
between the PNCs and the MDSC. between the PNCs and the MDSC.
When a 10Gb IP link between between R1 and R8 is needed, an EPL When a 10Gb IP connectivity service between R1 and R8 is needed, an
service needs to be created, supported by an ODU2 end-to-end EPL service needs to be created, supported by an ODU2 end-to-end
connection, between transport network nodes S3 and S18, passing connection, between transport network nodes S3 and S18, passing
through transport network nodes S1, S2, S31, S33, S34 and S15, which through transport network nodes S1, S2, S31, S33, S34 and S15, which
belong to different PNC domains (multi-domain service request): belong to 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], R8 [ETH -> (PKT)] S15 [(ODU2)], S18 [(ODU2) -> ETH], R8 [ETH -> (PKT)]
The MDSC receives, at the CMI, the request to create an EPL service The MDSC receives, at the CMI, the request to create an EPL service
between the access links on S3 and S18, which belong to different PNC between the access links on S3 and S18, which belong to different PNC
domains (multi-domain service request). The MDSC determines the domains (multi-domain service request). The MDSC determines the
network configurations to request, at the MPIs, to its underlying network configurations to request, at the MPIs, to its underlying
PNCs, to coordinate the setup of an end-to-end ODU2 connection PNCs, to coordinate the setup of an end-to-end ODU2 connection
between the nodes S3 and S8, including the configuration of the between the nodes S3 and S8, including the configuration of the
adaptation functions inside these edge nodes, such as S3 [ETH -> adaptation functions inside these edge nodes, such as S3 [ETH ->
(ODU2)] and S18 [(ODU2) -> ETH]. (ODU2)] and S18 [(ODU2) -> ETH].
When a 10Gb IP link between R1 and R2 is needed, an EPL service needs When a 10Gb IP connection between R1 and R2 is needed, an EPL service
to be created, supported by an ODU2 end-to-end connection between needs to be created, supported by a ODU2 end-to-end connection
transport network nodes S3 and S6, passing through the transport between transport network nodes S3 and S6, passing through the
network node S5, which belong to the same PNC domain (single-domain transport network node S5, which belong to the same PNC domain
service request): (single-domain service request):
R1 [(PKT) -> ETH], S3 [ETH -> (PKT)] S5 [(ODU2)], R1 [(PKT) -> ETH], S3 [ETH -> (PKT)] S5 [(ODU2)],
S6 [(ODU2) -> ETH], R2 [ETH -> (PKT)] S6 [(ODU2) -> ETH], R2 [ETH -> (PKT)]
As described in Section 4.1, the mechanisms used by the CNC at the As described in Section 4.1, the mechanisms used by the CNC at the
CMI are independent on whether the service request is single-domain CMI are independent on whether the service request is single-domain
service or multi-domain. service or multi-domain.
Based on the assumption above, in this case, the MDSC can figure out Based on the assumption above, in this case, the MDSC can figure out
that it needs to setup an EPL service between the access links on S3 that it needs to setup an EPL service between the access links on S3
and S6, which belong to the same PNC domain (single-domain service and S6, that belong to the same PNC domain (single-domain service
request) and it decides the proper network configuration to request request) and it decides the proper network configuration to request
PNC1. PNC1.
4.3.3. Transparent Client Services 4.3.3. Transparent Client Services
[ITU-T_G.709] defines mappings of different Transparent Client layers [ITU-T_G.709] defines mappings of different Transparent Client layers
into ODU. Most of them are used to provide Private Line services into ODU. Most of them are used to provide Private Line services
over an OTN transport network supporting a variety of types of over an OTN transport network supporting a variety of types of
physical access links (e.g., Ethernet, SDH STM-N, Fibre Channel, physical access links (e.g., Ethernet, SDH STM-N, Fibre Channel,
InfiniBand, etc.) interconnecting the IP routers and the transport InfiniBand, etc.) interconnect the IP routers and the transport
network. network.
When a 10Gb IP link between R1 and R8 is needed, using, for example When a 10Gb IP connectivity service between R1 and R8 is needed,
SDH physical links between the IP routers and the transport network, using, for example SDH physical links between the IP routers and the
an STM-64 Private Line service needs to be created, supported by an transport network, an STM-64 Private Line service needs to be
ODU2 end-to-end connection, between transport network nodes S3 and created, supported by a ODU2 end-to-end connection, between transport
S18, passing through transport network nodes S1, S2, S31, S33, S34 network nodes S3 and S18, passing through transport network nodes S1,
and S15, which belong to different PNC domains (multi-domain service S2, S31, S33, S34 and S15, which belong to different PNC domains
request): (multi-domain 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], R8 [STM-64 -> (PKT)] S15 [(ODU2)], S18 [(ODU2) -> STM-64], R8 [STM-64 -> (PKT)]
As described (Section 4.1) the CNC provides the essential information As described (Section 4.1) the CNC provides the essential information
to permit the MDSC to compute which type of service is needed, in to permit the MDSC to compute which type of service is needed, in
this case, an STM-64 Private Line Service between the access links on this case, an STM-64 Private Line Service between the access links on
S3 and S8, and it also decides the network configurations, including S3 and S8, and it also decides the network configurations, including
the configuration of the adaptation functions inside these edge the configuration of the adaptation functions inside these edge
nodes, such as S3 [STM-64 -> (ODU2)] and S18 [(ODU2) -> STM-64]. nodes, such as S3 [STM-64 -> (ODU2)] and S18 [(ODU2) -> STM-64].
When a 10Gb IP link between R1 and R3 is needed, an STM-64 Private When a 10Gb IP connectivity service between R1 and R3 is needed, an
Line service needs to be created between R1 and R3 (single-domain STM-64 Private Line service needs to be created between R1 and R3
service request): (single-domain service 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.1, the mechanisms, used by the CNC at the As described in Section 4.1, the mechanisms, used by the CNC at the
CMI, are independent on whether the service request is single-domain CMI, are independent on whether the service request is single-domain
service or multi-domain. service or multi-domain.
Based on the assumption above, in this case, the MDSC can figure out Based on the assumption above, in this case, the MDSC can figure out
that it needs to setup an STM-64 Private Line service between the that it needs to setup an STM-64 Private Line service between the
access links on S3 and S6, which belong to the same PNC domain access links on S3 and S6, which belong to the same PNC domain
(single-domain service request) and it decides the proper network (single-domain service request), and it decides the proper network
configuration to request PNC1. configuration to request PNC1.
4.3.4. EVPL over ODU 4.3.4. EVPL over ODU
When the physical links interconnecting the IP routers and the When the physical links interconnecting the IP routers and the
transport network are Ethernet physical links, it is also possible transport network are Ethernet physical links, it is also possible
that different Ethernet services (e.g., EVPL) can share the same that different Ethernet services (e.g., EVPL) can share the same
physical access link using different VLANs. physical access link using different VLANs.
As described in Section 4.3.2, it is assumed that the Ethernet As described in Section 4.3.2, it is assumed that the Ethernet
skipping to change at page 19, line 11 skipping to change at page 18, line 11
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], R8[VLAN -> (PKT)] S15 [(ODU0)], S18 [(ODU0) -> VLAN], R8[VLAN -> (PKT)]
It is worth noting that the first EVPL service is required between It is worth noting that the first EVPL service is required between
access links which belong to the same PNC domain (single-domain access links which belong to the same PNC domain (single-domain
service request) while the second EVPL service is required between service request) while the second EVPL service is required between
access links which belong to different PNC domains (multi-domain access links which belong to different PNC domains (multi-domain
service request). service request).
Since the two EVPL services are sharing the same Ethernet physical Since the two EVPL services share the same Ethernet physical link
link between R1 and S3, different VLAN IDs are associated with between R1 and S3, different VLAN IDs are associated with different
different EVPL services: for example, VLAN IDs 10 and 20 EVPL services: for example, VLAN IDs 10 and 20 respectively.
respectively.
Based on the assumptions described in Section 4.3.2, the CNC sends a Based on the assumptions described in Section 4.3.2, the CNC sends a
request to the MDSC, at the CMI, to setup these EVPL services. The request to the MDSC, at the CMI, to set up these EVPL services. The
MDSC will determine the network configurations to request to the MDSC will determine the network configurations to request to the
underlying PNCs, as described in Section 4.3.2. underlying PNCs, as described in Section 4.3.2.
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 trail or network can be configured in different modes, e.g., as OTU2 trail or
STM-64 or 10GE physical links. STM-64 or 10GE physical links.
This configuration can be pre-provisioned by means which are outside This configuration can be pre-provisioned by means which are outside
the scope of this document. In this case, these links will appear at the scope of this document. In this case, these links will appear at
the MPI as links supporting only one mode (depending on how the link the MPI as links supporting only one mode (depending on how the link
has been pre-provisioned) and will be controlled at the MPI as has been pre-provisioned) and will be controlled at the MPI as
discussed in Section 4.3: for example, a 10G multi-function access discussed in Section 4.3: for example, a 10G multi-function access
skipping to change at page 20, line 9 skipping to change at page 19, line 9
R1 [(PKT) -> STM-64], S3 [STM-64 -> (ODU2)], S5 [(ODU2)], R1 [(PKT) -> STM-64], S3 [STM-64 -> (ODU2)], S5 [(ODU2)],
S6 [(ODU2) -> STM-64], R4 [STM-64 -> (PKT)] S6 [(ODU2) -> STM-64], R4 [STM-64 -> (PKT)]
The traffic flow between R1 and R8 can be summarized as: The traffic flow between R1 and R8 can be summarized as:
R1 [(PKT) -> ETH], S3 [ETH -> (ODU2)], S1 [(ODU2)], R1 [(PKT) -> ETH], S3 [ETH -> (ODU2)], S1 [(ODU2)],
S2 [(ODU2)], S31 [(ODU2)), S33 [(ODU2)], S34 [(ODU2)], S2 [(ODU2)], S31 [(ODU2)), S33 [(ODU2)], S34 [(ODU2)],
S15 [(ODU2)], S18 [(ODU2) -> ETH], R8 [ETH -> (PKT)] S15 [(ODU2)], S18 [(ODU2) -> ETH], R8 [ETH -> (PKT)]
The CNC is capable of requesting, via the CMI, the setup either an The CNC is capable of requesting, via the CMI, the setup of either an
STM-64 Private Line service, between R1 and R4, or an EPL service, STM-64 Private Line service, between R1 and R4, or an EPL service,
between R1 and R8. between R1 and R8.
The MDSC, based on the service being request, decides the network The MDSC, based on the service being requested, decides the network
configurations to request, at the MPIs, to its underlying PNCs, to configurations to request, at the MPIs, to its underlying PNCs, to
coordinate the setup of an end-to-end ODU2 connection, either between coordinate the setup of an end-to-end ODU2 connection, either between
nodes S3 and S6, or between nodes S3 and S18, including the nodes S3 and S6, or between nodes S3 and S18, including the
configuration of the adaptation functions on these edge nodes, and in configuration of the adaptation functions on these edge nodes, and in
particular whether the multi-function access link between R1 and S3 particular whether the multi-function access link between R1 and S3
should operate as an STM-64 or as a 10GE physical link. should operate as an STM-64 or as a 10GE physical link.
Assumptions used in this example, as well as the service scenarios of Assumptions used in this example, as well as the service scenarios of
Section 4.3, include: Section 4.3, include:
o the R1-S3 and R8-S18 access links will be multi-function access * the R1-S3 and R8-S18 access links will be multi-function access
links, which can be configured as an OTU2 trail or as an STM-64 or links, which can be configured as an OTU2 trail or as an STM-64 or
a 10GE physical link; a 10GE physical link;
o the R3-S6 access link will be a multi-function access link which * the R3-S6 access link will be a multi-function access link which
can be configured as an OTU2 trail or as an STM-64 physical link; can be configured as an OTU2 trail or as an STM-64 physical link;
o the R4-S6 access link is pre-provisioned as an STM-64 physical * the R4-S6 access link is pre-provisioned as an STM-64 physical
link; link;
o all the other access links (and, in particular, the R2-S6 access * all the other access links (and, in particular, the R2-S6 access
links) are pre-provisioned as 10GE physical links, up to the MAC links) are pre-provisioned as 10GE physical links, up to the MAC
layer. layer.
4.5. Protection and Restoration Configuration 4.5. Protection and Restoration Configuration
As described in [RFC4427], recovery can be performed by either As described in [RFC4427], recovery can be performed by either
protection switching or restoration mechanisms. This section protection switching or restoration mechanisms. This section
describes only services which are protected with linear protection, describes only services which are protected with linear protection,
considering both end-to-end and segment protection, as defined in considering both end-to-end and segment protection, as defined in
[ITU-T_G.808.1] and [RFC4427]. The description of services using [ITU-T_G.808.1] and [RFC4427]. The description of services using
skipping to change at page 21, line 11 skipping to change at page 20, line 11
configurations to request different PNCs to coordinate the protection configurations to request different PNCs to coordinate the protection
switching configuration to support protected connectivity services switching configuration to support protected connectivity services
described in Section 4.3. described in Section 4.3.
In the service examples described in Section 4.3, switching within In the service examples described in Section 4.3, switching within
the transport network domain is only performed at the OTN ODU layer. the transport network domain is only performed at the OTN ODU layer.
Therefore, it is also assumed that protection switching within the Therefore, it is also assumed that protection switching within the
transport network also occurs at the OTN ODU layer, using the transport network also occurs at the OTN ODU layer, using the
mechanisms defined in [ITU-T_G.873.1]. mechanisms defined in [ITU-T_G.873.1].
4.5.1. Linear Protection (end-to-end) 4.5.1. Linear Protection (End-to-End)
To protect the connectivity services described in Section 4.3 from To protect the connectivity services described in Section 4.3 from
failures within the OTN multi-domain transport network, the MDSC can failures within the OTN multi-domain transport network, the MDSC can
decide to request its underlying PNCs to configure ODU2 linear decide to request its underlying PNCs to configure ODU2 linear
protection between the transport network edge nodes (e.g., nodes S3 protection between the transport network edge nodes (e.g., nodes S3
and S18 for the services setup between R1 and R8). and S18 for the services setup between R1 and R8).
It is assumed that the OTN linear protection is configured as 1+1 It is assumed that the OTN linear protection is configured as 1+1
unidirectional protection switching type according to the definition unidirectional protection switching type according to the definition
in [ITU-T_G.808.1] and [ITU-T_G.873.1], as well as in [RFC4427]. in [ITU-T_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 * 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 can * In another case, the working and protection transport entities 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 of reporting to the MDSC which is the The PNCs should be capable of reporting to the MDSC which, is the
active transport entity, as defined in [ITU-T_G.808.1], in the data active transport entity, as defined in [ITU-T_G.808.1], in the data
plane. plane.
Given the fast dynamic of protection switching operations in the data Given the fast dynamic of protection switching operations in the data
plane (e.g., 50ms switching time), this reporting is not expected to plane (e.g., 50ms switching time), this reporting is not expected to
be in real-time. be in real-time.
It is also worth noting that with unidirectional protection It is also worth noting that with unidirectional protection
switching, e.g., 1+1 unidirectional protection switching, the active switching, e.g., 1+1 unidirectional protection switching, the active
transport entity may be different in the two directions. transport entity may be different in the two directions.
4.5.2. Segmented Protection 4.5.2. Segmented Protection
To protect the connectivity services defined in Section 4.3 from To protect the connectivity services defined in Section 4.3 from
failures within the OTN multi-domain transport network, the MDSC can failures within the OTN multi-domain transport network, the MDSC can
decide to request its underlying PNCs to configure ODU2 linear decide to request its underlying PNCs to configure ODU2 linear
protection between the edge nodes of each domain. protection between the edge nodes of each domain.
For example, MDSC can request PNC1 to configure linear protection For example, the MDSC can request PNC1 to configure linear protection
between its edge nodes S3 and S2: between its edge nodes S3 and S2:
Working transport entity: S3, S1, S2 Working transport entity: S3, S1, S2
Protection transport entity: S3, S4, S8, S2 Protection transport entity: S3, S4, S8, S2
MDSC can also request PNC2 to configure linear protection between MDSC can also request PNC2 to configure linear protection between
its edge nodes S15 and S18: its edge nodes S15 and S18:
Working transport entity: S15, S18 Working transport entity: S15, S18
Protection transport entity: S15, S12, S17, S18 Protection transport entity: S15, S12, S17, S18
MDSC can also request PNC3 to configure linear protection between its MDSC can also request PNC3 to configure linear protection between its
edge nodes S31 and S34: edge nodes S31 and S34:
Working transport entity: S31, S33, S34 Working transport entity: S31, S33, S34
Protection transport entity: S31, S32, S34 Protection transport entity: S31, S32, S34
4.6. Notification 4.6. Event Notifications and Alarms
To realize the topology update, service update and restoration To realize the three functions of topology update, service update,
function, following notification types should be supported: and restoration, the following notification types need to 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
There are three types of topology abstraction types defined in There are three types of topology abstraction types defined in
Section 4.2, and the notifications should also be abstracted. The Section 4.1, Paragraph 16, and the notifications should also be
PNC and MDSC should coordinate together to determine the notification abstracted. The PNC and MDSC should coordinate together to determine
policy. This will include information such as when an intra-domain the notification policy. This will include information such as when
alarm occurred. The PNC may not report the alarm, but it should an intra-domain alarm occurred. The PNC may not report the alarm,
provide notification of the service state change to the MDSC. but it should provide notification of the service state change to the
MDSC.
Analysis and methods of how event alarms are triggered, managed and Detailed analysis and methods of how event alarms are triggered,
propagated are outside the scope of this document. managed and propagated are outside the scope of this document.
4.7. Path Computation with Constraints 4.7. Path Computation with Constraints
It is possible to define constraints to be taken into account during It is possible to define constraints to be taken into account during
path computation procedures (e.g., IRO/XRO). path computation procedures (e.g., Include Route Object (IRO) and
Exclude Route Object (XRO) [RFC5521]).
For example, the CNC can request, at the CMI, an ODU transit service, For example, the CNC can request, at the CMI, an ODU transit service,
as described in Section 4.3.1, between R1 and R8 with the constraint as described in Section 4.3.1, between R1 and R8 with the constraint
to pass through the link from S2 to S31 (IRO), such that a qualified to pass through the link from S2 to S31 (IRO), such that a qualified
path could be: path could be:
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)], R8 [ODU2 -> (PKT)] S15 [(ODU2)], S18 [(ODU2)], R8 [ODU2 -> (PKT)]
If the CNC instead requested to pass through the link from S8 to S12, If the CNC instead requested to pass through the link from S8 to S12,
then the above path would not be qualified, while the following would then the above path would not be qualified, while the following would
be: 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]), R8 [ODU2 -> S8 [(ODU2]), S12[(ODU2]), S15 [(ODU2]), S18[(ODU2]), R8 [ODU2 ->
(PKT)] (PKT)]
The mechanisms, used by the CNC to provide path constraints at the The mechanisms used by the CNC to provide path constraints at the
CMI, are outside the scope of this document. It is assumed that the CMI, are outside the scope of this document. It is assumed that the
MDSC can satisfy these constraints and take them into account in its MDSC can satisfy these constraints and take them into account in its
path computation procedures (which would decide at least which path computation procedures (which would decide at least which
domains and inter-domain links) and in the path computation domains and inter-domain links) and in the path computation
constraints to provide to its underlying PNCs, to be taken into constraints to provide to its underlying PNCs, to be taken into
account in the path computation procedures implemented by the PNCs account in the path computation procedures implemented by the PNCs
(with a more detailed view of topology). (with a more detailed view of topology).
Further detailed analysis is outside the scope of this document. Further detailed analysis is outside the scope of this document.
skipping to change at page 24, line 28 skipping to change at page 23, line 30
their own MPIs, the network configuration needed to setup the their own MPIs, the network configuration needed to setup the
different services described in Section 4.3. different services described in Section 4.3.
Section 5.3 describes how the protection scenarios can be deployed, Section 5.3 describes how the protection scenarios can be deployed,
including end-to-end protection and segment protection, for both including end-to-end protection and segment protection, for both
intra-domain and inter-domain scenario. intra-domain and inter-domain scenario.
5.1. YANG Models for Topology Abstraction 5.1. YANG Models for Topology Abstraction
This section analyses how each PNC can report its respective abstract This section analyses how each PNC can report its respective abstract
topology to the MDSC, as described in Section 4.2, using the Topology topology to the MDSC, as described in Section 4.1, Paragraph 16,
YANG models, defined in [RFC8345], with the TE Topology YANG using the Topology YANG models, defined in [RFC8345], with the TE
augmentations, provided in [RFC8795], and the OTN technology-specific Topology YANG augmentations, provided in [RFC8795], and the OTN
YANG augmentations, defined in [OTN-TOPO] or the Ethernet client technology-specific YANG augmentations, defined in [OTN-TOPO] or the
technology-specific YANG augmentations, defined in [CLIENT-TOPO]. Ethernet client technology-specific YANG augmentations, defined in
[CLIENT-TOPO].
As described in Section 4.1, the OTU4 trails on inter-domain and As described in Section 4.1, the OTU4 trails on inter-domain and
intra-domain physical links are pre-provisioned and therefore not intra-domain physical links are pre-provisioned and, therefore, not
exposed at the MPIs. Only the TE Links they support can be exposed exposed at the MPIs. Only the TE Links they support can be exposed
at the MPI, depending on the topology abstraction performed by the at the MPI, depending on the topology abstraction performed by the
PNC. PNC.
The access links can be multi-function access links, as described in The access links can be multi-function access links, as described in
Section 4.4. Section 4.4.
As described in Section 4.1, each physical access link has a As described in Section 4.1, each physical access link has a
dedicated set of ODU termination and adaptation resources. dedicated set of ODU termination and adaptation resources.
The [OTN-TOPO] model allows reporting within the OTN abstract The [OTN-TOPO] model allows reporting within the OTN abstract
topology also the access links which are capable of supporting the topology also the access links which are capable of supporting the
transparent client layers, defined in Section 4.3.3 and in transparent client layers, defined in Section 4.3.3 and in
[CLIENT-SIGNAL]. These links can also be multi-function access links [CLIENT-SIGNAL]. These links can also be multi-function access links
that can be configured as a transparent client physical links (e.g., that can be configured as transparent client physical links (e.g.,
STM-64 physical link) or as an OTUk trail. STM-64 physical link) or as an OTUk trail.
In order to support the EPL and EVPL services, described in In order to support the EPL and EVPL services, described in
Section 4.3.2 and Section 4.3.2, the access links, which are capable Section 4.3.2 and Section 4.3.4, the access links, which are capable
of being configured as Ethernet physical links, are reported by each of being configured as Ethernet physical links, are reported by each
PNC within its respective Ethernet abstract topology, using the PNC within its respective Ethernet abstract topology, using the
Topology YANG models, defined in [RFC8345], with the TE Topology YANG Topology YANG models, defined in [RFC8345], with the TE Topology YANG
augmentations, defined in [RFC8795], and the Ethernet client augmentations, defined in [RFC8795], and the Ethernet client
technology-specific YANG augmentations, defined in [CLIENT-TOPO]. technology-specific YANG augmentations, defined in [CLIENT-TOPO].
These links can also be multi-function access links that can be These links can also be multi-function access links that can be
configured as an Ethernet physical link, an OTUk trail, or as a configured as an Ethernet physical link, an OTUk trail, or as a
transparent client physical links (e.g., STM-64 physical link). In transparent client physical links (e.g., STM-64 physical link). In
this case, these physical access links are represented in both the this case, these physical access links are represented in both the
OTN and Ethernet abstract topologies. OTN and Ethernet abstract topologies.
skipping to change at page 25, line 28 skipping to change at page 24, line 35
The PNC reports the capabilities of the access or inter-domain link The PNC reports the capabilities of the access or inter-domain link
ends it can control. It is the MDSC responsibility to request ends it can control. It is the MDSC responsibility to request
configuration of these links matching the capabilities of both link configuration of these links matching the capabilities of both link
ends. ends.
It is worth noting that in the network scenarios analyzed in this It is worth noting that in the network scenarios analyzed in this
document (where switching is performed only at the ODU layer), the document (where switching is performed only at the ODU layer), the
Ethernet abstract topologies reported by the PNCs describes only the Ethernet abstract topologies reported by the PNCs describes only the
Ethernet client access links: no Ethernet TE switching capabilities Ethernet client access links: no Ethernet TE switching capabilities
are reported in these Ethernet abstract topologies, to report that are reported in these Ethernet abstract topologies, to report that
the underlying networt domain is not capable to support Ethernet TE the underlying networt domain is not capable supporting Ethernet TE
Tunnels/LSPs. Tunnels/LSPs.
5.1.1. Domain 1 Black Topology Abstraction 5.1.1. Domain 1 Black Topology Abstraction
PNC1 provides the required black topology abstraction, as described PNC1 provides the required black topology abstraction, as described
in Section 4.2. It exposes at MPI1 to the MDSC, two TE Topology in Section 4.1, Paragraph 16. It exposes at MPI1 to the MDSC, two TE
instances with only one TE node each. Topology instances with only one TE node each.
The first TE Topology instance reports the domain 1 OTN abstract The first TE Topology instance reports the domain 1 OTN abstract
topology view (MPI1 OTN Topology), using the OTN technology-specific topology view (MPI1 OTN Topology), using the OTN technology-specific
augmentations [OTN-TOPO], with only one abstract TE node (i.e., AN1) augmentations [OTN-TOPO], with only one abstract TE node (i.e., AN1)
moreover, only inter-domain and access abstract TE links (which moreover, only inter-domain and access abstract TE links (which
represent the inter-domain physical links and the access physical represent the inter-domain physical links and the access physical
links which can support ODU, or transparent client layers, both), as links that can support ODU, or transparent client layers, both), as
shown in Figure 3 below. shown in Figure 3 below.
................................... ...................................
: : : :
: +-----------------+ : : +-----------------+ :
: | | : : | | :
(R1)- - --------| |-------- - -(S31) (R1)- - --------| |-------- - -(S31)
: AN1-1 | | AN1-7 : : AN1-1 | | AN1-7 :
: | | : : | | :
(R3)- - --------| | : (R3)- - --------| | :
skipping to change at page 27, line 15 skipping to change at page 26, line 15
The OTU4 trails on the inter-domain physical links (e.g., the link The OTU4 trails on the inter-domain physical links (e.g., the link
between S2 and S31) are pre-provisioned and exposed as external TE between S2 and S31) are pre-provisioned and exposed as external TE
Links, within the MPI1 OTN topology (e.g., the external TE Link Links, within the MPI1 OTN topology (e.g., the external TE Link
terminating on AN1-7 TE Link Termination Point (LTP) abstracting the terminating on AN1-7 TE Link Termination Point (LTP) abstracting the
OTU4 trail between S2 and S31). OTU4 trail between S2 and S31).
The PNC1 exports at MPI1 the following external TE Links, within the The PNC1 exports at MPI1 the following external TE Links, within the
MPI1 OTN topology, representing the multi-function access links under MPI1 OTN topology, representing the multi-function access links under
its control: its control:
o two abstract TE Links, terminating on LTP AN1-1 and AN1-2 * two abstract TE Links, terminating on LTP AN1-1 and AN1-2
respectively, abstracting the physical access link between S3 and respectively, abstracting the physical access link between S3 and
R1 and the access link between S6 and R3 respectively, reporting R1 and the access link between S6 and R3 respectively, reporting
that they can support STM-64 client signals as well as ODU2 that they can support STM-64 client signals as well as ODU2
connections; connections;
o one abstract TE Link, terminating on LTP AN1-3, abstracting the * one abstract TE Link, terminating on LTP AN1-3, abstracting the
physical access link between S6 and R4, reporting that it can physical access link between S6 and R4, reporting that it can
support STM-64 client signals but no ODU2 connections. support STM-64 client signals but no ODU2 connections.
The information about the 10GE access link between S6 and R2 as well The information about the 10GE access link between S6 and R2 as well
as the fact that the access link between S3 and R1 can also be as the fact that the access link between S3 and R1 can also be
configured as a 10GE link cannot be exposed by PNC1 within the MPI1 configured as a 10GE link cannot be exposed by PNC1 within the MPI1
OTN topology. OTN topology.
Therefore, PNC1 exports at MPI1, within the MPI1 ETH topology, two Therefore, PNC1 exports at MPI1, within the MPI1 ETH topology, two
abstract TE Links, terminating on LTP AN1-1 and AN1-8 respectively, abstract TE Links, terminating on LTP AN1-1 and AN1-8 respectively,
abstracting the physical access link between S3 and R1 and the access abstracting the physical access link between S3 and R1 and the access
link between S6 and R2 respectively, reporting that they can support link between S6 and R2 respectively, reporting that they can support
Ethernet client signal with port-based and VLAN-based Ethernet client signal with port-based and VLAN-based
classifications. classifications.
PNC1 should expose at MPI1 also the ODU termination and adaptation PNC1 should expose at MPI1 also the ODU termination and adaptation
resources which are available to carry client signals (e.g., Ethernet resources that are available to carry client signals (e.g., Ethernet
or STM-N) over OTN. This information is reported by the Tunnel or STM-N) over OTN. This information is reported by the Tunnel
Termination Points (TTPs) within the MPI1 OTN Topology. Termination Points (TTPs) within the MPI1 OTN Topology.
In particular, PNC1 will report, within the MPI1 OTN Topology, one In particular, PNC1 will report, within the MPI1 OTN Topology, one
TTP for each access link (i.e., AN1-1, AN1-2, AN1-3 and AN1-8) and TTP for each access link (i.e., AN1-1, AN1-2, AN1-3 and AN1-8) and
will assign a transition link or an inter-layer lock identifier, will assign a transition link or an inter-layer lock identifier,
which is unique across all the TE Topologies PNC1 is exposing at which is unique across all the TE Topologies PNC1 is exposing at
MPI1, to each TTP and access link's LTP pair. MPI1, to each TTP and access link's LTP pair.
For simplicity purposes, this document assigns the same number to the For simplicity purposes, this document assigns the same number to the
skipping to change at page 28, line 42 skipping to change at page 27, line 42
(R3)- - -----| S6 |---| S7 |---| S8 |----- - -(S32) (R3)- - -----| S6 |---| S7 |---| S8 |----- - -(S32)
:S6-2+----+4 2+----+4 3+----+ : :S6-2+----+4 2+----+4 3+----+ :
: / | | : : / | | :
(R3)- - ------ S7-3 | | S8-4 : (R3)- - ------ S7-3 | | S8-4 :
:S6-3 | | : :S6-3 | | :
:...............|........|.......: :...............|........|.......:
| | | |
(S11) (S12) (S11) (S12)
Figure 5: Physical Topology controlled by PNC1 Figure 5: Physical Topology controlled by PNC1
The PNC1 native topology is not exposed and therefore it under PNC The PNC1 native topology is not exposed, and therefore it is the
responsibility to abstract the whole domain physical topology as a PNC's responsibility to abstract the whole domain physical topology
single TE node and to maintain a mapping between the LTPs exposed at as a single TE node and to maintain a mapping between the LTPs
MPI abstract topologies and the associated physical interfaces exposed at MPI abstract topologies and the associated physical
controlled by the PNC: interfaces controlled by the PNC:
Physical Interface OTN Topology LTP ETH Topology LTP Physical Interface OTN Topology LTP ETH Topology LTP
(Figure 5) (Figure 3) (Figure 4) (Figure 5) (Figure 3) (Figure 4)
S2-3 AN1-7 S2-3 AN1-7
S3-1 AN1-1 AN1-1 S3-1 AN1-1 AN1-1
S6-1 AN1-8 S6-1 AN1-8
S6-2 AN1-2 S6-2 AN1-2
S6-3 AN1-3 S6-3 AN1-3
S7-3 AN1-4 S7-3 AN1-4
S8-4 AN1-5 S8-4 AN1-5
skipping to change at page 29, line 29 skipping to change at page 28, line 29
at MPI1. at MPI1.
Appendix B.1.2 provides the detailed JSON code example ("mpi1-eth- Appendix B.1.2 provides the detailed JSON code example ("mpi1-eth-
topology.json") describing how the MPI1 ETH Topology is reported by topology.json") describing how the MPI1 ETH Topology is reported by
the PNC1, using the [RFC8345], [RFC8795] and [CLIENT-TOPO] YANG the PNC1, using the [RFC8345], [RFC8795] and [CLIENT-TOPO] YANG
models, at MPI1. 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, including: the attributes defined in the relevant YANG models, including:
o YANG attributes which are outside the scope of this document are * YANG attributes that are outside the scope of this document are
not shown; not shown;
o The attributes describing the set of label values that are * The attributes describing the set of label values that are
available at the inter-domain links (label-restriction container) available at the inter-domain links (label-restriction container)
are also not shown to simplify the JSON code example; are also not shown to simplify the JSON code example;
o The comments describing the rationale for not including some * 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
included only in the first object instance (e.g., in the Access only in the first object instance (e.g., in the Access Link from
Link from the AN1-1 description or in the AN1-1 LTP description). 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, two TE Topology in Section 4.1, Paragraph 16, to expose to the MDSC, at MPI2, two TE
instances with only one TE node each: Topology instances with only one TE node each:
o the first instance reports the domain 2 OTN abstract topology view * the first instance reports the domain 2 OTN abstract topology view
(MPI2 OTN Topology), with only one abstract node (i.e., AN2) and (MPI2 OTN Topology), with only one abstract node (i.e., AN2) and
only inter-domain and access abstract TE links (which represent only inter-domain and access abstract TE links (which represent
the inter-domain physical links and the access physical links the inter-domain physical links and the access physical links that
which can support ODU, or transparent client layers or both); can support ODU, transparent client layers, or both);
o the instance reports the domain 2 Ethernet abstract topology view * the instance reports the domain 2 Ethernet abstract topology view
(MPI2 ETH Topology), with only one abstract TE node (i.e., AN2) (MPI2 ETH Topology), with only one abstract TE node (i.e., AN2)
and only access abstract TE links (which represent the access and only access abstract TE links (which represent the access
physical links which can support Ethernet client layers). physical links which can support Ethernet client layers).
PNC2 also reports the ODU termination and adaptation resources which PNC2 also reports the ODU termination and adaptation resources which
are available to carry client signals (e.g., Ethernet or STM-N) over are available to carry client signals (e.g., Ethernet or STM-N) over
OTN in the TTPs within the MPI2 OTN Topology. OTN in the TTPs within the MPI2 OTN Topology.
In particular, PNC2 reports in both the MPI2 OTN Topology and MPI2 In particular, PNC2 reports in both the MPI2 OTN Topology and MPI2
ETH Topology an AN2-1 access link which abstracts the multi-function ETH Topology an access link that abstracts the multi-function
physical access link between S18 and R8, which is assumed to physical access link between S18 and R8, and terminates on the AN2-1
correspond to the S18-3 LTP, within the PNC2 native topology. It LTP that corresponds to the S18-3 physical interface, within the PNC2
also reports in the MPI2 ETH Topology a TTP which abstracts the ODU native topology. It also reports in the MPI2 ODU Topology an AN2-1
termination and adaptation resources dedicated to this physical TTP which abstracts the ODU termination and adaptation resources
access link and the inter-layer lock between this TTP, and the AN2-1 dedicated to this physical access link and the inter-layer lock
LTPs reported within the MPI2 OTN Topology and the MPI2 ETH Topology. between the AN2-1 TTP, and the AN2-1 LTPs reported within the MPI2
OTN Topology and the MPI2 ETH Topology.
5.1.3. Domain 3 White Topology Abstraction 5.1.3. Domain 3 White Topology Abstraction
PNC3 provides the required white topology abstraction, as described PNC3 provides the required white topology abstraction, as described
in Section 4.2, to expose to the MDSC, at MPI3, two TE Topology in Section 4.1, Paragraph 16, to expose to the MDSC, at MPI3, two TE
instances with multiple TE nodes, one for each physical node: Topology instances with multiple TE nodes, one for each physical
node:
o the first instance reports the domain 3 OTN topology view (MPI3 * the first instance reports the domain 3 OTN topology view (MPI3
OTN Topology), with four TE nodes, which represent the four OTN Topology), with four TE nodes, which represent the four
physical nodes (i.e. S31, S32, S33 and S34), and abstract TE physical nodes (i.e. S31, S32, S33 and S34), and abstract TE
links, which represent the inter-domain and internal physical links, which represent the inter-domain and internal physical
links; links;
o the second instance reports the domain 3 Ethernet abstract * the second instance reports the domain 3 Ethernet abstract
topology view (MPI3 ETH Topology), with only two TE nodes, which topology view (MPI3 ETH Topology), with only two TE nodes, which
represent the two edge physical nodes (i.e., S31 and S33) and only represent the two edge physical nodes (i.e., S31 and S33) and only
the two access TE links which represent the access physical links. the two access TE links which represent the access physical links.
PNC3 also reports the ODU termination and adaptation resources which PNC3 also reports the ODU termination and adaptation resources which
are available to carry client signals (e.g., Ethernet or STM-N) over are available to carry client signals (e.g., Ethernet or STM-N) over
OTN in the TTPs within the MPI3 OTN Topology. OTN in the TTPs within the MPI3 OTN Topology.
5.1.4. Multi-domain Topology Merging 5.1.4. Multi-domain Topology Merging
MDSC does not have any knowledge of the topologies of each domain MDSC does not have any knowledge of the topologies of each domain
until each PNC reports its own abstract topologies, so the MDSC needs until each PNC reports its abstract topologies, so the MDSC needs to
to merge these abstract topologies, provided by different PNCs, to merge these abstract topologies, provided by different PNCs, to build
build its own topology view of the multi-domain network (MDSC multi- its topology view of the multi-domain network (MDSC multi-domain
domain native topology), as described in section 4.3 of [RFC8795]. native topology), as described in section 4.3 of [RFC8795].
The topology of each domain may be in an abstracted shape (refer to The topology of each domain may be in an abstracted shape (refer to
section 5.2 of [RFC8453] for a different level of abstraction), while section 5.2 of [RFC8453] for a different level of abstraction), while
the inter-domain link information must be complete and fully the inter-domain link information must be 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 know how to merge these inter-domain links. One The MDSC needs to know how to merge these inter-domain links. One
skipping to change at page 31, line 26 skipping to change at page 30, line 26
topologies, terminating on two LTPs reporting the same plug-id value topologies, terminating on two LTPs reporting the same plug-id value
can be merged as a single intra-domain link, within any MDSC native can be merged as a single intra-domain link, within any MDSC native
topology. topology.
The value of the reported plug-id information can be either assigned The value of the reported plug-id information can be either assigned
by a central network authority and configured within the two PNC by a central network authority and configured within the two PNC
domains. Alternatively, it may be discovered using an automatic domains. Alternatively, it may be discovered using an automatic
discovery mechanisms (e.g., LMP-based, as defined in [RFC6898]). discovery mechanisms (e.g., LMP-based, as defined in [RFC6898]).
In case the plug-id values are assigned by a central authority, it is In case the plug-id values are assigned by a central authority, it is
under the central authority responsibility to assign unique values. under the central authority's responsibility to assign unique values.
In case the plug-id values are automatically discovered, the In case the plug-id values are automatically discovered, the
information discovered by the automatic discovery mechanisms needs to information discovered by the automatic discovery mechanisms needs to
be encoded as a bit string within the plug-id value. This encoding be encoded as a bit string within the plug-id value. This encoding
is implementation-specific, but the encoding rules need to be is implementation-specific, but the encoding rules need to be
consistent across all the PNCs. consistent across all the PNCs.
In case of co-existence within the same network of multiple sources In case of co-existence within the same network of multiple sources
for the plug-id (e.g., central authority and automatic discovery or for the plug-id (e.g., central authority and automatic discovery or
even different automatic discovery mechanisms), it is needed that the even different automatic discovery mechanisms), it is needed that the
plug-id namespace is partitioned to avoid that different sources plug-id namespace is partitioned to avoid that different sources
assign the same plug-id value to different inter-domain links. Also, assign the same plug-id value to different inter-domain links. Also,
the encoding of the plug-id namespace within the plug-id value is the encoding of the plug-id namespace within the plug-id value is
implementation specific and will need to be consistent across all the implementation-specific and will need to be consistent across all the
PNCs. PNCs.
This document assumes that the plug-id is assigned by a central This document assumes that the plug-id is assigned by a central
authority, with the first octet set to 0x00 to represent the central authority, with the first octet set to 0x00 to represent the central
authority namespace. The configuration method used, within each PNC authority namespace. The configuration method used, within each PNC
domain, are outside the scope of this document. domain, are outside the scope of this document.
For example, this document assumes that the following plug-id values For example, this document assumes that the following plug-id values
are assigned, by administrative configuration, to the inter-domain are assigned, by administrative configuration, to the inter-domain
links shown in Figure 1: links shown in Figure 1:
skipping to change at page 32, line 52 skipping to change at page 31, line 52
: | + / +--+ : : | + / +--+ :
: | |/ / : : | |/ / :
: Black +--- AN2 ------------- - -(R7) : Black +--- AN2 ------------- - -(R7)
: Topology | | AN2-1 : : Topology | | AN2-1 :
: Abstraction | +-------------- - -(R8) : Abstraction | +-------------- - -(R8)
: | : : | :
: +---------------- - -(R9) : +---------------- - -(R9)
: : : :
:...............................: :...............................:
Figure 6: Multi-domain Abstract Topology controlled by an MDSC Figure 6: Multi-domain Abstract Topology controlled by an MDSC
5.2. YANG Models for Service Configuration 5.2. YANG Models for Service Configuration
This section analyses how the MDSC can request the different PNCs to This section analyses how the MDSC can request the different PNCs to
setup different multi-domains services, as described in Section 4.3, setup different multi-domains services, as described in Section 4.3,
using the TE Tunnel YANG model, defined in [TE-TUNNEL], with the OTN using the TE Tunnel YANG model, defined in [TE-TUNNEL], with the OTN
technology-specific augmentations, defined in [OTN-TUNNEL] with the technology-specific augmentations, defined in [OTN-TUNNEL] with the
client service YANG model defined in [CLIENT-SIGNAL]. client service YANG model defined in [CLIENT-SIGNAL].
The service configuration procedure is assumed to be initiated (step The service configuration procedure is assumed to be initiated (step
1 in Figure 7) at the CMI from CNC to MDSC. Analysis of the CMI 1 in Figure 7) at the CMI from CNC to MDSC. Analysis of the CMI
models is (e.g., L1CSM, L2SM, VN) is outside the scope of this models (e.g., L1CSM, L2SM, VN) are outside the scope of this
document, but it is assumed that the CMI YANG models provide all the document, but it is assumed that the CMI YANG models provide all the
information that allows the MDSC to understand that it needs to information that allows the MDSC to understand that it needs to
coordinate the setup of a multi-domain ODU data plane connection coordinate the setup of a multi-domain ODU data plane connection
(which can be either an end-to-end connection or a segment (which can be either an end-to-end connection or a segment
connection) and, when needed, also the configuration of the connection) and, when needed, also the configuration of the
adaptation functions in the edge nodes belonging to different adaptation functions in the edge nodes belonging to different
domains. domains.
| |
| {1} | {1}
skipping to change at page 34, line 40 skipping to change at page 33, line 40
(Network) / ( ) \ V (Network) / ( ) \ V
( Domain 1) / ----- \ ----- ( Domain 1) / ----- \ -----
( )/ \ (Network) ( )/ \ (Network)
A===========B \ ( Domain 3) A===========B \ ( Domain 3)
/ ( ) \( ) / ( ) \( )
AP-1 ( ) X===========Z AP-1 ( ) X===========Z
----- ( ) \ ----- ( ) \
( ) AP-2 ( ) AP-2
----- -----
Figure 7: Multi-domain Service Setup Figure 7: Multi-domain Service Setup
As an example, the objective in this section is to configure a As an example, the objective in this section is to configure a
connectivity service between R1 and R8, such as one of the services connectivity service between R1 and R8, such as one of the services
described in Section 4.3. The inter-domain path is assumed to be R1 described in Section 4.3. The inter-domain path is assumed to be R1
<-> S3 <-> S1 <-> S2 <-> S31 <-> S33 <-> S34 <->S15 <-> S18 <-> R8 <-> S3 <-> S1 <-> S2 <-> S31 <-> S33 <-> S34 <->S15 <-> S18 <-> R8
(see the physical topology in Figure 1). (see the physical topology in Figure 1).
According to the different client signal types, different adaptations According to the different client signal types, different adaptations
can be required to be configured at the edge nodes (i.e., S3 and can be required to be configured at the edge nodes (i.e., S3 and
S18). S18).
skipping to change at page 35, line 15 skipping to change at page 34, line 15
After receiving such request, MDSC determines the domain sequence, After receiving such request, MDSC determines the domain sequence,
i.e., domain 1 <-> domain 3 <-> domain 2, with corresponding PNCs and i.e., domain 1 <-> domain 3 <-> domain 2, with corresponding PNCs and
the inter-domain links (step 2 in Figure 7). the inter-domain links (step 2 in Figure 7).
As described in [PATH-COMPUTE], the domain sequence can be determined As described in [PATH-COMPUTE], the domain sequence can be determined
by running the MDSC own path computation on the MDSC native topology, by running the MDSC own path computation on the MDSC native topology,
defined in Section 5.1.4, if and only if the MDSC has enough topology defined in Section 5.1.4, if and only if the MDSC has enough topology
information. Otherwise, the MDSC can send path computation requests information. Otherwise, the MDSC can send path computation requests
to the different PNCs (steps 2.1, 2.2 and 2.3 in Figure 7) and use to the different PNCs (steps 2.1, 2.2 and 2.3 in Figure 7) and use
this information to determine the optimal path on its internal this information to determine the optimal path on its internal
topology and therefore the domain sequence. topology and, therefore, the domain sequence.
The MDSC will then decompose the tunnel request into a few TE tunnel The MDSC will then decompose the tunnel request into a few TE tunnel
segments and request different PNCs to setup each intra-domain TE segments and request different PNCs to setup each intra-domain TE
tunnel segment (steps 3, 3.1, 3.2 and 3.3 in Figure 7). tunnel segment (steps 3, 3.1, 3.2 and 3.3 in Figure 7).
The MDSC will take care of the configuration of both the intra- The MDSC will take care of the configuration of both the intra-
domain TE tunnel segments and inter-domain TE tunnel hand-off via domain TE tunnel segments and inter-domain TE tunnel hand-off via
corresponding MPI (using the TE tunnel YANG model defined in corresponding MPI (using the TE tunnel YANG model defined in
[TE-TUNNEL] and the OTN tunnel YANG model augmentations defined in [TE-TUNNEL] and the OTN tunnel YANG model augmentations defined in
[OTN-TUNNEL]) through all the PNCs controlling the domains selected [OTN-TUNNEL]) through all the PNCs controlling the domains selected
skipping to change at page 36, line 7 skipping to change at page 35, line 7
in [RFC8795] is being updated to report the label set information. in [RFC8795] is being updated to report the label set information.
See section 1.7 of [TE-TUTORIAL] for more details. See section 1.7 of [TE-TUTORIAL] for more details.
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 list connection, also configures the data plane resources (i.e., the list
of timeslots and the TPN) to be used on the inter-domain links. The of timeslots and the TPN) to be used on the inter-domain links. The
MDSC can know the timeslots which are available on the physical OTN MDSC can know the timeslots which are available on the physical OTN
nodes terminating the inter-domain links (e.g., S2 and S31) from the nodes terminating the inter-domain links (e.g., S2 and S31) from the
OTN Topology information exposed, at the MPIs, by the PNCs OTN Topology information exposed, at the MPIs, by the PNCs
controlling the OTN physical nodes (e.g., PNC1 and PNC3 controlling controlling the OTN physical nodes (e.g., PNC1 and PNC3 controlling
the physical nodes S2 and S31 respectively). the physical nodes S2 and S31, respectively).
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) and not on the that control the access links (e.g., PNC-1 and PNC-3) and not on the
PNCs of transit domain(s) (e.g., PNC-2). An access link will be PNCs of transit domain(s) (e.g., PNC-2). An access link will be
configured by MDSC after the OTN tunnel is set up. configured by MDSC after the OTN tunnel is set up.
Access configuration will vary and will be dependent on each type of Access configuration will vary and will be dependent on each type of
service. Further discussion and examples are provided in the service. Further discussion and examples are provided in the
following sub-sections. following sub-sections.
skipping to change at page 36, line 41 skipping to change at page 35, line 41
Abstract Topology (Figure 3), exposed by PNC1, and that R8 is Abstract Topology (Figure 3), exposed by PNC1, and that R8 is
attached to the access link terminating on AN2-1 LTP in the MPI2 attached to the access link terminating on AN2-1 LTP in the MPI2
Abstract Topology, exposed by PNC2. Abstract Topology, exposed by PNC2.
MDSC then performs multi-domain path computation (step 2 in Figure 7) MDSC then performs multi-domain path computation (step 2 in Figure 7)
and requests PNC1, PNC2 and PNC3, at MPI1, MPI2 and MPI3 and requests PNC1, PNC2 and PNC3, at MPI1, MPI2 and MPI3
respectively, to setup ODU2 (Transit Segment) Tunnels within the OTN respectively, to setup ODU2 (Transit Segment) Tunnels within the OTN
Abstract Topologies they expose (MPI1 OTN Abstract Topology, MPI2 OTN Abstract Topologies they expose (MPI1 OTN Abstract Topology, MPI2 OTN
Abstract Topology and MPI3 OTN Abstract Topology, respectively). Abstract Topology and MPI3 OTN Abstract Topology, respectively).
MDSC requests, at MPI1, PNC1 to setup an ODU2 (Transit Segment) The MDSC requests, at MPI1, PNC1 to setup an ODU2 (Transit Segment)
Tunnel with one primary path between AN-1 and AN1-7 LTPs, within the Tunnel with one primary path between AN-1 and AN1-7 LTPs, within the
MPI1 OTN Abstract Topology (Figure 3), using the TE Tunnel YANG MPI1 OTN Abstract Topology (Figure 3), using the TE Tunnel YANG
model, defined in [TE-TUNNEL], with the OTN technology-specific model, defined in [TE-TUNNEL], with the OTN technology-specific
augmentations, defined in [OTN-TUNNEL]: augmentations, defined in [OTN-TUNNEL]:
o Source and Destination TTPs are not specified (since it is a * Source and Destination TTPs are not specified (since it is a
Transit Tunnel): i.e., the source, src-tp-id, destination and dst- Transit Tunnel): i.e., the source, src-tp-id, destination and dst-
tp-id attributes of the TE tunnel instance are empty tp-id attributes of the TE tunnel instance are empty
o Ingress and egress points are indicated in the route-object- * 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:
* The first element references the access link terminating on - The first element references the access link terminating on
AN1-1 LTP AN1-1 LTP
* The last two element reference respectively the inter-domain - The last two element reference respectively the inter-domain
link terminating on AN1-7 LTP and the data plane resources link terminating on AN1-7 LTP and the data plane resources
(i.e., the list of timeslots and the TPN) used by the ODU2 (i.e., the list of timeslots and the TPN) used by the ODU2
connection over that link. connection over that link.
Appendix B.2.1 provides the detailed JSON code ("mpi1-odu2-service- Appendix B.2.1 provides the detailed JSON code ("mpi1-odu2-service-
config.json") describing how the setup of this ODU2 (Transit Segment) config.json") describing how the setup of this ODU2 (Transit Segment)
Tunnel can be requested by the MDSC, using the [TE-TUNNEL] and Tunnel can be requested by the MDSC, using the [TE-TUNNEL] and
[OTN-TUNNEL] YANG models at MPI1. [OTN-TUNNEL] YANG models at MPI1.
PNC1 knows, as described in the mapping table in Section 5.1.1, that PNC1 knows, as described in the mapping table in Section 5.1.1, that
AN-1 and AN1-7 LTPs within the MPI1 OTN Abstract Topology it exposes AN-1 and AN1-7 LTPs within the MPI1 OTN Abstract Topology it exposes
at MPI1 correspond to the S3-1 and S2-3 LTPs, respectively, within at MPI1 correspond to the S3-1 and S2-3 LTPs, respectively, within
its native topology. Therefore it performs path computation, for an its native topology. Therefore it performs path computation for an
ODU2 connection between these LTPs within its native topology, and ODU2 connection between these LTPs within its native topology, and
sets up the ODU2 cross-connections within the physical nodes S3, S1 sets up the ODU2 cross-connections within the physical nodes S3, S1
and S2. and S2.
Since the R1-S3 access link is a multi-function access link, PNC1 Since the R1-S3 access link is a multi-function access link, PNC1
also configures the OTU2 trail before setting up the ODU2 cross- also configures the OTU2 trail before setting up the ODU2 cross-
connection in node S3. connection in node S3.
As part of the OUD2 cross-connection configuration in node S2, PNC1 As part of the OUD2 cross-connection configuration in node S2, PNC1
configures the data plane resources (i.e., the list of timeslots and configures the data plane resources (i.e., the list of timeslots and
skipping to change at page 38, line 28 skipping to change at page 37, line 31
From its native topology, shown in Figure 6, the MDSC understands, by From its native topology, shown in Figure 6, the MDSC understands, by
means which are outside the scope of this document, that R1 is means which are outside the scope of this document, that R1 is
attached to the access link terminating on AN1-1 LTP in the MPI1 ETH attached to the access link terminating on AN1-1 LTP in the MPI1 ETH
Abstract Topology, exposed by PNC1, and that R8 is attached to the Abstract Topology, exposed by PNC1, and that R8 is attached to the
access link terminating on AN2-1 LTP in the MPI2 ETH Abstract access link terminating on AN2-1 LTP in the MPI2 ETH Abstract
Topology, exposed by PNC2. Topology, exposed by PNC2.
As described in Section 5.1.1 and Section 5.1.2: As described in Section 5.1.1 and Section 5.1.2:
o the AN1-1 LTP, within the MPI1 ETH Abstract Topology, and the * the AN1-1 LTP, within the MPI1 ETH Abstract Topology, and the
AN1-1 TTP, within the MPI1 OTN Abstract Topology, have the same AN1-1 TTP, within the MPI1 OTN Abstract Topology, have the same
IIL identifier (within the scope of MPI1); IIL identifier (within the scope of MPI1);
o the AN2-1 LTP, within the MPI2 ETH Abstract Topology, and the * the AN2-1 LTP, within the MPI2 ETH Abstract Topology, and the
AN2-1 TTP, within the MPI2 OTN Abstract Topology, have the same AN2-1 TTP, within the MPI2 OTN Abstract Topology, have the same
IIL identifier (within the scope of MPI2). IIL identifier (within the scope of MPI2).
Therefore, the MDSC also understands that it needs to coordinate the Therefore, the MDSC also understands that it needs to coordinate the
setup of a multi-domain ODU2 Tunnel between AN1-1 and AN2-1 TTPs, setup of a multi-domain ODU2 Tunnel between AN1-1 and AN2-1 TTPs,
abstracting S3-1 and S18-3 TTPs, within the OTN Abstract Topologies abstracting the ODU termination and adaptation resources on S3-1 and
exposed by PNC1 and PNC2, respectively. S18-3 physical interfaces, within the OTN Abstract Topologies exposed
by PNC1 and PNC2, respectively.
MDSC then performs multi-domain path computation (step 2 in Figure 7) MDSC then performs multi-domain path computation (step 2 in Figure 7)
and then requests: and then requests:
o PNC1, at MPI1, to setup an ODU2 (Head Segment) Tunnel within the * PNC1, at MPI1, to setup an ODU2 (Head Segment) Tunnel within the
MPI1 OTN Abstract Topology; MPI1 OTN Abstract Topology;
o PNC1, at MPI1, to steer the Ethernet client traffic from/to AN1-1 * PNC1, at MPI1, to steer the Ethernet client traffic from/to AN1-1
LTP, within the MPI1 ETH Abstract Topology, thought that ODU2 LTP, within the MPI1 ETH Abstract Topology, thought that ODU2
(Head Segment) Tunnel; (Head Segment) Tunnel;
o PNC3, at MPI3, to setup an ODU2 (Transit Segment) Tunnel within * PNC3, at MPI3, to setup an ODU2 (Transit Segment) Tunnel within
the MPI3 OTN Abstract Topology; the MPI3 OTN Abstract Topology;
o PNC2, at MPI2, to setup ODU2 (Tail Segment) Tunnel within the MPI2 * PNC2, at MPI2, to setup ODU2 (Tail Segment) Tunnel within the MPI2
OTN Abstract Topology; OTN Abstract Topology;
o PNC2, at MPI2, to steer the Ethernet client traffic to/from AN2-1 * PNC2, at MPI2, to steer the Ethernet client traffic to/from AN2-1
LTP, within the MPI2 ETH Abstract Topology, through that ODU2 LTP, within the MPI2 ETH Abstract Topology, through that ODU2
(Tail Segment) Tunnel. (Tail Segment) Tunnel.
MDSC requests, at MPI1, PNC1 to setup an ODU2 (Head Segment) Tunnel MDSC requests, at MPI1, PNC1 to setup an ODU2 (Head Segment) Tunnel
with one primary path between the AN1-1 TTP and AN1-7 LTP, within the with one primary path between the AN1-1 TTP and AN1-7 LTP, within the
MPI1 OTN Abstract Topology (Figure 3), using the TE Tunnel YANG MPI1 OTN Abstract Topology (Figure 3), using the TE Tunnel YANG
model, defined in [TE-TUNNEL], with the OTN technology-specific model, defined in [TE-TUNNEL], with the OTN technology-specific
augmentations, defined in [OTN-TUNNEL]: augmentations, defined in [OTN-TUNNEL]:
o Only the Source TTP (i.e., AN1 TE-Node and AN1-1 TTP) is specified * Only the Source TTP (i.e., AN1 TE-Node and AN1-1 TTP) is specified
(since it is a Head Segment Tunnel): therefore the Destination TTP (since it is a Head Segment Tunnel): therefore the Destination TTP
is not specified is not specified
o The egress point in indicated in the route-object-include-exclude * The egress point in indicated in the route-object-include-exclude
list of the explicit-route-objects of the primary path: list of the explicit-route-objects of the primary path:
* The last two element reference respectively the inter-domain - The last two element reference respectively the inter-domain
link terminating on AN1-7 LTP and the data plane resources link terminating on AN1-7 LTP and the data plane resources
(i.e., the list of timeslots and the TPN) used by the ODU2 (i.e., the list of timeslots and the TPN) used by the ODU2
connection over that link. connection over that link.
Since there is not enough information about which client traffic
should be steered to the OTN Tunnel, the ODU2 (Head Segment) Tunnel
is setup with the administrative auto state, as defined in
[TE-TUNNEL].
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 Tunnel can be requested by the MDSC, using the [TE-TUNNEL] and
[OTN-TUNNEL] YANG models at MPI1. [OTN-TUNNEL] YANG models at MPI1.
MDSC requests, at MPI1, PNC1 to steer the Ethernet client traffic MDSC requests, at MPI1, PNC1 to steer the Ethernet client traffic
from/to AN1-2 LTP, within the MPI1 ETH Abstract Topology (Figure 4), from/to AN1-2 LTP, within the MPI1 ETH Abstract Topology (Figure 4),
thought the MPI1 ODU2 (Head Segment) Tunnel, using the Ethernet thought the MPI1 ODU2 (Head Segment) Tunnel, using the Ethernet
Client YANG model, defined in [CLIENT-SIGNAL]. Client YANG model, defined in [CLIENT-SIGNAL].
skipping to change at page 40, line 20 skipping to change at page 39, line 31
domain link, as requested by the MDSC. domain link, as requested by the MDSC.
After the configuration of the ODU2 cross-connection in node S3, PNC1 After the configuration of the ODU2 cross-connection in node S3, PNC1
also configures the [ETH -> (ODU)] and [(ODU2) -> ETH] adaptation also configures the [ETH -> (ODU)] and [(ODU2) -> ETH] adaptation
functions, within node S3, as shown in Section 4.3.2. functions, within node S3, as shown in Section 4.3.2.
Since the R1-S3 access link is a multi-function access link, PNC1 Since the R1-S3 access link is a multi-function access link, PNC1
also configures the 10GE link before this step. also configures the 10GE link before this step.
Following similar requests from MDSC to setup ODU2 (Segment) Tunnels Following similar requests from MDSC to setup ODU2 (Segment) Tunnels
within the OTN Abstract Topologies they expose as well as the within the OTN Abstract Topologies, they expose as well as the
steering of the Ethernet client traffic, PNC3 then sets up ODU2 steering of the Ethernet client traffic, PNC3 then sets up ODU2
cross-connections on nodes S31 and S33 while PNC2 sets up ODU2 cross- cross-connections on nodes S31 and S33 while PNC2 sets up ODU2 cross-
connections on nodes S15 and S18 as well as the [ETH -> (ODU2)] and connections on nodes S15 and S18 as well as the [ETH -> (ODU2)] and
[(ODU2) -> ETH] adaptation functions in node S18, as shown in [(ODU2) -> ETH] adaptation functions in node S18, as shown in
Section 4.3.2. PNC2 also configures the 10GE link on the S18-R8 Section 4.3.2. PNC2 also configures the 10GE link on the S18-R8
multi-function access link. multi-function access link.
5.2.2.1. Single Domain Example 5.2.2.1. Single Domain Example
When this IP link, between R1 and R2, is needed, the CNC requests, at When this IP link, between R1 and R2, is needed, the CNC requests, at
the CMI, the MDSC to setup an EPL service. the CMI, the MDSC to setup an EPL service.
Following the procedures described in Section 5.2.2, the MDSC Following the procedures described in Section 5.2.2, the MDSC
requests PCN1 to: requests PCN1 to:
o Setup an ODU2 (end-to-end) Tunnel between the AN1-1 and AN1-2 * Setup an ODU2 (end-to-end) Tunnel between the AN1-1 and AN1-2
TTPs, abstracting S3-1 and S6-1 TTPs, within the MPI1 OTN Abstract TTPs, abstracting S3-1 and S6-1 TTPs, within the MPI1 OTN Abstract
Topology exposed by PNC1 at MPI1; Topology exposed by PNC1 at MPI1;
o Steer the Ethernet client traffic between the AN1-1 and AN1-8 * Steer the Ethernet client traffic between the AN1-1 and AN1-8
LTPs, exposed by PNC1 within MPI1 ETH Abstract Topology, through LTPs, exposed by PNC1 within MPI1 ETH Abstract Topology, through
that ODU2 (end-to-end) Tunnel. that ODU2 (end-to-end) Tunnel.
Then PNC1 sets up ODU2 cross-connections on nodes S3, S5 and S6 as Then PNC1 sets up ODU2 cross-connections on nodes S3, S5 and S6 as
well as the [ETH -> (ODU)] and [(ODU2) -> ETH] adaptation functions well as the [ETH -> (ODU)] and [(ODU2) -> ETH] adaptation functions
in nodes S3 and S6, as shown in Section 4.3.2. PNC1 also configures in nodes S3 and S6, as shown in Section 4.3.2. PNC1 also configures
the 10GE link on the R1-S3 multi-function access link (the R2-S6 the 10GE link on the R1-S3 multi-function access link (the R2-S6
access link has been pre-provisioned as a 10GE link, as described in access link has been pre-provisioned as a 10GE link, as described in
Section 4.4). Section 4.4).
5.2.3. Other OTN Client Services 5.2.3. Other OTN Client Services
In this scenario, described in Section 4.3.3, the access links are In this scenario, described in Section 4.3.3, the access links are
configured as STM-64 links and, as described in Section 5.1, reported configured as STM-64 links and, as described in Section 5.1, reported
by each PNC as TE Links within the OTN Abstract Topologies they by each PNC as TE Links within the OTN Abstract Topologies they
expose to the MDSC. expose to the MDSC.
The CNC requests, at the CMI, MDSC to setup an STM-64 Private Line The CNC requests, at the CMI, MDSC to setup an STM-64 Private Line
service between R1 and R8. service between R1 and R8.
Following similar procedures as described in Section 5.2.2, MDSC Following similar procedures as described in Section 5.2.2, the MDSC
understands that: understands that:
o R1 is attached to the access link terminating on AN1-1 LTP in the * R1 is attached to the access link terminating on AN1-1 LTP in the
MPI1 OTN Abstract Topology, exposed by PNC1, and that R8 is MPI1 OTN Abstract Topology, exposed by PNC1, and that R8 is
attached to the access link terminating on AN2-1 LTP in the MPI2 attached to the access link terminating on AN2-1 LTP in the MPI2
OTN Abstract Topology, exposed by PNC2; OTN Abstract Topology, exposed by PNC2;
o it needs to coordinate the setup of a multi-domain ODU2 Tunnel * it needs to coordinate the setup of a multi-domain ODU2 Tunnel
between the AN1-1 and AN2-1 TTPs, abstracting S3-1 and S18-3 TTPs, between the AN1-1 and AN2-1 TTPs, abstracting the ODU termination
and adaptation resources on S3-1 and S18-3 physical interfaces,
within the OTN Abstract Topologies exposed by PNC1 and PNC2, within the OTN Abstract Topologies exposed by PNC1 and PNC2,
respectively. respectively.
The MDSC then performs multi-domain path computation (step 2 in The MDSC then performs multi-domain path computation (step 2 in
Figure 7) and then requests: Figure 7) and then requests:
o PNC1, at MPI1, to setup an ODU2 (Head Segment) Tunnel within the * PNC1, at MPI1, to setup an ODU2 (Head Segment) Tunnel within the
MPI1 OTN Abstract Topology; MPI1 OTN Abstract Topology;
o PNC1, at MPI1, to steer the STM-64 transparent client traffic * PNC1, at MPI1, to steer the STM-64 transparent client traffic
from/to AN1-1 LTP, within the MPI1 OTN Abstract Topology, thought from/to AN1-1 LTP, within the MPI1 OTN Abstract Topology, thought
that ODU2 (Head Segment) Tunnel; that ODU2 (Head Segment) Tunnel;
o PNC3, at MPI3, to setup an ODU2 (Transit Segment) Tunnel within * PNC3, at MPI3, to setup an ODU2 (Transit Segment) Tunnel within
the MPI3 OTN Abstract Topology; the MPI3 OTN Abstract Topology;
o PNC2, at MPI2, to setup ODU2 (Tail Segment) Tunnel within the MPI2 * PNC2, at MPI2, to setup ODU2 (Tail Segment) Tunnel within the MPI2
OTN Abstract Topology; OTN Abstract Topology;
o PNC2, at MPI2, to steer the STM-64 transparent client traffic to/ * PNC2, at MPI2, to steer the STM-64 transparent client traffic to/
from AN2-1 LTP, within the MPI2 ETH Abstract Topology, through from AN2-1 LTP, within the MPI2 ETH Abstract Topology, through
that ODU2 (Tail Segment) Tunnel. that ODU2 (Tail Segment) Tunnel.
PNC1, PNC2 and PNC3 then sets up the ODU2 cross-connections within PNC1, PNC2 and PNC3 then sets up the ODU2 cross-connections within
the physical nodes S3, S1, S2, S31, S33, S15 and S18 as well as the the physical nodes S3, S1, S2, S31, S33, S15 and S18 as well as the
[STM-64 -> (ODU)] and [(ODU2) -> STM-64] adaptation functions in [STM-64 -> (ODU)] and [(ODU2) -> STM-64] adaptation functions in
nodes S3 and S18, as shown in Section 4.3.3. PNC1 and PNC2 also nodes S3 and S18, as shown in Section 4.3.3. PNC1 and PNC2 also
configure the STM-64 links on the R1-S3 and R8-S18 multi-function configure the STM-64 links on the R1-S3 and R8-S18 multi-function
access links, respectively. access links, respectively.
5.2.3.1. Single Domain Example 5.2.3.1. Single Domain Example
When this IP link, between R1 and R3, is needed, the CNC requests, at When an IP link, between R1 and R3, is needed, the CNC requests, at
the CMI, the MDSC to setup an STM-64 Private Line service. the CMI, the MDSC to setup an STM-64 Private Line service.
The MDSC and PNC1 follows similar procedures as described in The MDSC and PNC1 follows similar procedures as described in
Section 5.2.2.1 to set up ODU2 cross-connections on nodes S3, S5 and Section 5.2.2.1 to set up ODU2 cross-connections on nodes S3, S5 and
S6 as well as the [STM-64 -> (ODU)] and [(ODU2) -> STM-64] adaptation S6 as well as the [STM-64 -> (ODU)] and [(ODU2) -> STM-64] adaptation
functions in nodes S3 and S6, as shown in Section 4.3.3. PNC1 also functions in nodes S3 and S6, as shown in Section 4.3.3. PNC1 also
configures the STM-64 links on the R1-S3 and R3-S6 multi-function configures the STM-64 links on the R1-S3 and R3-S6 multi-function
access links. access links.
5.2.4. EVPL over ODU Service 5.2.4. EVPL 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 10GE links, as described in Section 5.2.2 above. configured as 10GE links, as described in Section 5.2.2 above.
The CNC requests, at the CMI, the MDSC to setup two EVPL services: The CNC requests, at the CMI, the MDSC to setup two EVPL services:
one between R1 and R2, and another between R1 and R8. one between R1 and R2, and another between R1 and R8.
Following similar procedures as described in Section 5.2.2 and Following similar procedures as described in Section 5.2.2 and
Section 5.2.2.1, MDSC understands that: Section 5.2.2.1, MDSC understands that:
o R1 and R2 are attached to the access links terminating * R1 and R2 are attached to the access links terminating
respectively on AN1-1 and AN1-8 LTPs in the MPI1 ETH Abstract respectively on AN1-1 and AN1-8 LTPs in the MPI1 ETH Abstract
Topology, exposed by PNC1, and that R8 is attached to the access Topology, exposed by PNC1, and that R8 is attached to the access
link terminating on AN2-1 LTP in the MPI2 ETH Abstract Topology, link terminating on AN2-1 LTP in the MPI2 ETH Abstract Topology,
exposed by PNC2; exposed by PNC2;
o To setup the first (single-domain) EVPL service, between R1 and * To setup the first (single-domain) EVPL service, between R1 and
R2, it needs to coordinate the setup of a single-domain ODU0 R2, it needs to coordinate the setup of a single-domain ODU0
Tunnel between the AN1-1 and AN1-8 TTPs, abstracting S3-1 and S6-1 Tunnel between the AN1-1 and AN1-8 TTPs, abstracting S3-1 and S6-1
TTPs, within the OTN Abstract Topology exposed by PNC1; TTPs, within the OTN Abstract Topology exposed by PNC1;
o To setup the second (multi-domain) EPVL service, between R1 and * To setup the second (multi-domain) EPVL service, between R1 and
R8, it needs to coordinate the setup of a multi-domain ODU0 Tunnel R8, it needs to coordinate the setup of a multi-domain ODU0 Tunnel
between the AN1-1 and AN2-1 TTPs, abstracting nodes S3-1 and S18-3 between the AN1-1 and AN2-1 TTPs, abstracting the ODU termination
TTPs, within the OTN Abstract Topologies exposed by PNC1 and PNC2, and adaptation resources on S3-1 and S18-3 physical interfaces,
within the OTN Abstract Topologies exposed by PNC1 and PNC2,
respectively. respectively.
To setup the first (single-domain) EVPL service between R1 and R2, To setup the first (single-domain) EVPL service between R1 and R2,
the MDSC and PNC1 follows similar procedures as described in the MDSC and PNC1 follows similar procedures as described in
Section 5.2.2.1 to set up ODU0 cross-connections on nodes S3, S5 and Section 5.2.2.1 to set up ODU0 cross-connections on nodes S3, S5 and
S6 as well as the [VLAN -> (ODU0)] and [(ODU0) -> VLAN] adaptation S6 as well as the [VLAN -> (ODU0)] and [(ODU0) -> VLAN] adaptation
functions, in nodes S3 and S6, as shown in Section 4.3.2. PNC1 also functions, in nodes S3 and S6, as shown in Section 4.3.2. PNC1 also
configures the 10GE link on the R1-S3 multi-function access link. configures the 10GE link on the R1-S3 multi-function access link.
As part of the [VLAN -> (ODU0)] and [(ODU0) -> VLAN] adaptation As part of the [VLAN -> (ODU0)] and [(ODU0) -> VLAN] adaptation
functions configurations in nodes S2 and S6, PNC1 configures also the functions configurations in nodes S2 and S6, PNC1 configures also the
classification rules required to associated only the Ethernet client classification rules required to associate only the Ethernet client
traffic received with VLAN ID 10 on the R1-S3 and R2-S6 access links traffic received with VLAN ID 10 on the R1-S3 and R2-S6 access links
with this EVPL service. The MDSC provides this information to PNC1 with this EVPL service. The MDSC provides this information to PNC1
using the [CLIENT-SIGNAL] model. using the [CLIENT-SIGNAL] model.
To setup the second (multi-domain) EVPL service between R1 and R8, To setup the second (multi-domain) EVPL service between R1 and R8,
the MDSC, PNC1, PNC2 and PNC3 follows similar procedures as described the MDSC, PNC1, PNC2 and PNC3 follows similar procedures as described
in Section 5.2.2 to setup the ODU0 cross-connections within the in Section 5.2.2 to setup the ODU0 cross-connections within the
physical nodes S3, S1, S2, S31, S33, S15 and S18 as well as the [VLAN physical nodes S3, S1, S2, S31, S33, S15 and S18 as well as the [VLAN
-> (ODU0)] and [(ODU0) -> VLAN] adaptation functions in nodes S3 and -> (ODU0)] and [(ODU0) -> VLAN] adaptation functions in nodes S3 and
S18, as shown in Section 4.3.2. PNC2 also configures the 10GE link S18, as shown in Section 4.3.2. PNC2 also configures the 10GE link
skipping to change at page 43, line 43 skipping to change at page 43, line 7
5.3.1. Linear Protection (end-to-end) 5.3.1. Linear Protection (end-to-end)
As described in Section 4.5.1, the MDSC can decide to protect a As described in Section 4.5.1, the MDSC can decide to protect a
multi-domain connectivity service by setting up ODU linear protection multi-domain connectivity service by setting up ODU linear protection
switching between edge nodes controlled by different PNCs (e.g., switching between edge nodes controlled by different PNCs (e.g.,
nodes S3 and S8, controlled by PNC1 and PNC2 respectively, to protect nodes S3 and S8, controlled by PNC1 and PNC2 respectively, to protect
services between R1 and R8). services between R1 and R8).
MDSC performs path computation, as described in Section 5.2, to MDSC performs path computation, as described in Section 5.2, to
compute both the paths for working and protection transport entities: compute both the paths for working and protection transport entities:
the computed paths can pass through these same PNC domains or through the computed paths can pass through these exact PNC domains or
different transit PNC domains. through different transit PNC domains.
Considering the case, described in Section 4.5.1, where the working Considering the case, described in Section 4.5.1, where the working
and protection transport entities pass through the same domain, MDSC and protection transport entities pass through the same domain, MDSC
would perform the same steps described in Section 5.2 to setup the would perform the same steps described in Section 5.2 to setup the
ODU Tunnel and to configure the steering of the client traffic ODU Tunnel and to configure the steering of the client traffic
between the access links and the ODU Tunnel. The only differences between the access links and the ODU Tunnel. The only differences
are in the configuration of the ODU Tunnels. are in the configuration of the ODU Tunnels.
MDSC requests at the MPI1, PNC1 to setup an ODU2 (Head Segment) MDSC requests at the MPI1, PNC1 to setup an ODU2 (Head Segment)
Tunnel within the MPI1 OTN Abstract Topology (Figure 3), using the TE Tunnel within the MPI1 OTN Abstract Topology (Figure 3), using the TE
Tunnel YANG model, defined in [TE-TUNNEL], with the OTN technology- Tunnel YANG model, defined in [TE-TUNNEL], with the OTN technology-
specific augmentations, defined in [OTN-TUNNEL], with one primary specific augmentations, defined in [OTN-TUNNEL], with one primary
path and one secondary path with 1+1 protection switching enabled: path and one secondary path with 1+1 protection switching enabled:
o Only the Source TTP (i.e., AN1-1 TTP) is specified (since it is a * Only the Source TTP (i.e., AN1-1 TTP) is specified (since it is a
Head Segment Tunnel), as described in Section 5.2.2; Head Segment Tunnel), as described in Section 5.2.2;
o The egress point for the working transport entity in indicated in * The egress point for the working transport entity in indicated in
the route-object-include-exclude list of the explicit-route- the route-object-include-exclude list of the explicit-route-
objects of the primary path, as described in Section 5.2.2; objects of the primary path, as described in Section 5.2.2;
o The protection switching end-point in indicated in the route- * The protection switching end-point in indicated in the route-
object-include-exclude list of the explicit-route-objects of the object-include-exclude list of the explicit-route-objects of the
secondary path: secondary path:
* The first element references the TE-Node of the Source TTP - The first element references the TE-Node of the Source TTP
(i.e., AN1 TE-Node); (i.e., AN1 TE-Node);
o The egress point for the protection transport entity in indicated * The egress point for the protection transport entity in indicated
in the route-object-include-exclude list of the explicit-route- in the route-object-include-exclude list of the explicit-route-
objects of the secondary path: objects of the secondary path:
* The last two element reference respectively the inter-domain - The last two element reference respectively the inter-domain
link terminating on AN1-6 LTP and the data plane resources link terminating on AN1-6 LTP and the data plane resources
(i.e., the list of timeslots and the TPN) used by the ODU2 (i.e., the list of timeslots and the TPN) used by the ODU2
connection over that link. connection over that link.
PNC1 knows, as described in the table in Section 5.1.1, that the PNC1 knows, as described in the table in Section 5.1.1, that the
AN1-1 TTP, AN1-7 LTP and the AN1-6 LTP, within the MPI1 OTN Abstract AN1-1 TTP, AN1-7 LTP and the AN1-6 LTP, within the MPI1 OTN Abstract
Topology it exposes at MPI1, correspond to S3-1 TTP, S2-3 LTP and the Topology it exposes at MPI1, correspond to S3-1 TTP, S2-3 LTP and the
S8-5 LTP, respectively, within its native topology. It also S8-5 LTP, respectively, within its native topology. It also
understands, from the route-object-include-exclude list of the understands, from the route-object-include-exclude list of the
explicit-route-objects of the secondary path configuration (whose explicit-route-objects of the secondary path configuration (whose
last two elements represent an inter-domain link), that node S3 is last two elements represent an inter-domain link), that node S3 is
the end-point of the protection group while the other end-point is the end-point of the protection group while the other end-point is
outside of its control domain. outside of its control domain.
PNC1 can performs path computation within its native topology and PNC1 can perform path computation within its native topology and
setup the ODU connections in nodes S3, S1, S2, S4 and S8 as well as setup the ODU connections in nodes S3, S1, S2, S4 and S8 as well as
configure the protection group in node S3. configure the protection group in node S3.
5.3.2. Segmented Protection 5.3.2. Segmented Protection
Under specific policies, it is possible to deploy a segmented Under specific policies, it is possible to deploy a segmented
protection for multi-domain services. The configuration of the protection for multi-domain services. The configuration of the
segmented protection can be divided into a few steps, considering the segmented protection can be divided into a few steps, considering the
example in Section 4.5.2, the following steps would be used. example in Section 4.5.2, the following steps would be used.
skipping to change at page 45, line 21 skipping to change at page 44, line 40
the ODU Tunnel and to configure the steering of the client traffic the ODU Tunnel and to configure the steering of the client traffic
between the access links and the ODU Tunnel. The only differences between the access links and the ODU Tunnel. The only differences
are in the configuration of the ODU Tunnels. are in the configuration of the ODU Tunnels.
MDSC requests at the MPI1, PNC1 to setup an ODU2 (Head Segment) MDSC requests at the MPI1, PNC1 to setup an ODU2 (Head Segment)
Tunnel within the MPI1 OTN Abstract Topology (Figure 3), using the TE Tunnel within the MPI1 OTN Abstract Topology (Figure 3), using the TE
Tunnel YANG model, defined in [TE-TUNNEL], with the OTN technology- Tunnel YANG model, defined in [TE-TUNNEL], with the OTN technology-
specific augmentations, defined in [OTN-TUNNEL], with one primary specific augmentations, defined in [OTN-TUNNEL], with one primary
path and one secondary path with 1+1 protection switching enabled: path and one secondary path with 1+1 protection switching enabled:
o Only the Source TTP (i.e., AN1-1 TTP) is specified (since it is a * Only the Source TTP (i.e., AN1-1 TTP) is specified (since it is a
Head Segment Tunnel), as described in Section 5.2.2; Head Segment Tunnel), as described in Section 5.2.2;
o The egress point (i.e., AN1-7 LTP) is indicated in the route- * The egress point (i.e., AN1-7 LTP) is indicated in the route-
object-include-exclude list of the explicit-route-objects of the object-include-exclude list of the explicit-route-objects of the
primary path, as described in Section 5.2.2; primary path, as described in Section 5.2.2;
o The protection switching end-points are indicated in the route- * The protection switching end-points are indicated in the route-
object-include-exclude list of the explicit-route-objects of the object-include-exclude list of the explicit-route-objects of the
secondary path: secondary path:
* The first element references the TE-Node of the Source TTP - The first element references the TE-Node of the Source TTP
(i.e., AN1 TE-Node); (i.e., AN1 TE-Node);
* The last element references the TE-Node of the egress point - The last element references the TE-Node of the egress point
(i.e., AN1 TE-Node). (i.e., AN1 TE-Node).
As described in Section 5.2.2, PNC1 knows that the AN1-1 TTP and the As described in Section 5.2.2, PNC1 knows that the AN1-1 TTP and the
AN1-7 LTP, within the MPI1 OTN Abstract Topology it exposes at MPI1, AN1-7 LTP, within the MPI1 OTN Abstract Topology it exposes at MPI1,
correspond to S3-1 TTP and the S2-3 LTP, respectively, within its correspond to S3-1 TTP and the S2-3 LTP, respectively, within its
native topology. It also understands, from the route-object-include- native topology. It also understands, from the route-object-include-
exclude list of the explicit-route-objects of the secondary path exclude list of the explicit-route-objects of the secondary path
configuration (whole last element represent an abstract node configuration (whole last element represent an abstract node
terminating the inter-domain link used for the primary path), that terminating the inter-domain link used for the primary path), that
skipping to change at page 46, line 17 skipping to change at page 45, line 34
expose. PNC3 then sets up ODU2 cross-connections on nodes S31, S32, expose. PNC3 then sets up ODU2 cross-connections on nodes S31, S32,
S33 and S34 and segment protection between nodes S31 and D34. PNC2 S33 and S34 and segment protection between nodes S31 and D34. PNC2
sets up ODU2 cross-connections on nodes S15, S12, S17 and S18 and sets up ODU2 cross-connections on nodes S15, S12, S17 and S18 and
segment protection between nodes S15 and S18. segment protection between nodes S15 and S18.
MDSC stitch the configuration above to form its internal view of the MDSC stitch the configuration above to form its internal view of the
end-to-end tunnel with segmented protection. end-to-end tunnel with segmented protection.
Given the configuration above, the protection capability has been Given the configuration above, the protection capability has been
deployed on the tunnels. The head-end node of each domain can do the deployed on the tunnels. The head-end node of each domain can do the
switching once there is a failure on one the tunnel segment. For switching once there is a failure on one of the tunnel segments. For
example, in Network domain 1, when there is a failure on the S1-S2 example, in Network domain 1, when there is a failure on the S1-S2
lin, the head-end nodes S2 and S3 will automatically do the switching lin, the head-end nodes S2 and S3 will automatically do the switching
to S3-S4-S8-S2. This switching will be reported to the corresponding to S3-S4-S8-S2. This switching will be reported to the corresponding
PNC (PNC1 in this example) and then MDSC. Other PNCs (PNC2 and PNC3 PNC (PNC1 in this example) and then MDSC. Other PNCs (PNC2 and PNC3
in this example) will not be aware of the failure and switching, nor in this example) will not be aware of the failure and switching, nor
do the nodes in Network domain 2 and 3. do the nodes in network domains 2 and 3.
5.4. Notifications 5.4. Notifications
Notification mechanisms are required for the scenarios analyzed in Notification mechanisms are required for the scenarios analyzed in
this draft, as described in Section 4.6. this draft, as described in Section 4.6.
The notification mechanisms are protocol-dependent. It is assumed The notification mechanisms are protocol-dependent. It is assumed
that the RESTCONF protocol, defined in [RFC8040], is used at the MPIs that the RESTCONF protocol, defined in [RFC8040] is optional, and may
mentioned in this document. be used at the MPIs mentioned in this document.
On the perspective of MPI, the MDSC is the client while the PNC is From the perspective of MPI, the MDSC is the client while the PNC is
acting as the server of the notification. The essential event acting as the server of the notification. The essential event
streams, subscription and processing rules after receiving streams, subscription and processing rules after receiving
notification can be found in section 6 of [RFC8040]. notification can be found in section 6 of [RFC8040].
Additional alarm reporting functions and alarm report management may
be found in [ITU-T_X.733] and [ITU-T_X.734]
Further detailed analysis of notification management is outside the
scope of this document.
5.5. Path Computation with Constraints 5.5. Path Computation with Constraints
The path computation constraints that can be supported at the MPI The path computation constraints that can be supported at the MPI
using the IETF YANG models defined in [TE-TUNNEL] and [PATH-COMPUTE]. using the IETF YANG models defined in [TE-TUNNEL] and [PATH-COMPUTE].
When there is a technology-specific network (e.g., OTN), the When there is a technology-specific network (e.g., OTN), the
corresponding technology (e.g., OTN) model should also be used to corresponding technology (e.g., OTN) model should also be used to
specify the tunnel information on MPI, with the constraint included specify the tunnel information on MPI, with the constraint included
in TE Tunnel model. in TE Tunnel model.
Further detailed analysis is outside the scope of this document Further detailed analysis is outside the scope of this document.
6. Security Considerations 6. Security Considerations
This document analyses the applicability of the YANG models being 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.
When deploying ACTN functional components the securing of external When deploying ACTN functional components the securing of external
interfaces and hardening of resource datastores, the protection of interfaces and hardening of resource datastores, the protection of
confidential information, and limiting the access of function, should confidential information, and limit the access of function, should
all be carefully considered. Section 9 of [RFC8453] highlights that all be carefully considered. Section 9 of [RFC8453] highlights that
implementations should consider encrypting data that flows between implementations should consider encrypting data that flows between
key components, especially when they are implemented at remote node. key components, especially when they are implemented at remote nodes.
Further discussion on securing the interface between the MDSC and Further discussion on securing the interface between the MDSC and
PNCs via the MDSC-PNC Interface (MPI) is discussed in section 9.2 of PNCs via the MDSC-PNC Interface (MPI) is discussed in section 9.2 of
[RFC8453]. [RFC8453].
The YANG modules highlighted in this document are designed to be The YANG modules highlighted in this document are designed to be
accessed via network configuration protocols such as NETCONF accessed via network configuration protocols such as NETCONF
[RFC6241] or RESTCONF [RFC8040]. When using NETCONF, utilizing a [RFC6241] or RESTCONF [RFC8040]. When using NETCONF, utilizing a
secure transport via Secure Shell (SSH) [RFC6242] is mandatory. If secure transport via Secure Shell (SSH) [RFC6242] is mandatory. If
using RESTCONF, then secure transport via TLS [RFC8446] is mandatory. using RESTCONF, then secure transport via TLS [RFC8446] is mandatory.
When using either NETCONF or RESTCONF, the use of Network When using either NETCONF or RESTCONF, the use of Network
Configuration Access Control Model (NACM) [RFC8341] may be used to Configuration Access Control Model (NACM) [RFC8341] may be used to
restrict access to specific protocol operations and content. restrict access to specific protocol operations and content.
6.1. OTN Security 6.1. OTN Security
Inherently OTN networks ensure privacy and security via hard Inherently OTN networks ensure privacy and security via hard
partitioning of traffic onto dedicated circuits. The separation of partitioning of traffic onto dedicated circuits. The separation of
network traffic makes it difficult to intercept data transferred network traffic makes it difficult to intercept data transferred
between nodes over OTN-channelized links. between nodes over OTN-channelized links.
In OTN the (General Communication Channel) GCC is used for OAM Within OTN environments, the (General Communication Channel) GCC is
functions such as performance monitoring, fault detection, and used for OAM functions such as performance monitoring, fault
signaling. The GCC control channel should be secured using a detection, and signaling. The GCC control channel should be secured
suitable mechanism. using a suitable 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
[CLIENT-SIGNAL] [CLIENT-SIGNAL]
Zheng, H., Guo, A., Busi, I., Snitser, A., Lazzeri, F., Zheng, H., Guo, A., Busi, I., Snitser, A., and F. Lazzeri,
Xu, Y., Zhao, Y., Liu, X., and G. Fioccola, "A YANG Data "A YANG Data Model for Transport Network Client Signals",
Model for Transport Network Client Signals", draft-ietf- Work in Progress, Internet-Draft, draft-ietf-ccamp-client-
ccamp-client-signal-yang-05 (work in progress), July 2021. signal-yang-06, 5 January 2022,
<https://www.ietf.org/archive/id/draft-ietf-ccamp-client-
signal-yang-06.txt>.
[CLIENT-TOPO] [CLIENT-TOPO]
Zheng, H., Guo, A., Busi, I., Xu, Y., Zhao, Y., and X. Zheng, H., Guo, A., Busi, I., Xu, Y., Zhao, Y., and X.
Liu, "A YANG Data Model for Ethernet TE Topology", draft- Liu, "A YANG Data Model for Ethernet TE Topology", Work in
ietf-ccamp-eth-client-te-topo-yang-01 (work in progress), Progress, Internet-Draft, draft-ietf-ccamp-eth-client-te-
September 2021. topo-yang-02, 7 March 2022,
<https://www.ietf.org/archive/id/draft-ietf-ccamp-eth-
client-te-topo-yang-02.txt>.
[ITU-T_G.709] [ITU-T_G.709]
ITU-T Recommendation G.709, "Interfaces for the optical ITU-T Recommendation G.709, "Interfaces for the optical
transport network", ITU-T G.709 , March 2020. transport network", ITU-T G.709 , March 2020.
[ITU-T_G.808.1] [ITU-T_G.808.1]
ITU-T Recommendation G.808.1, "Generic protection International Telecommunication Union, "Generic protection
switching - Linear trail and subnetwork protection", ITU-T switching - Linear trail and subnetwork protection", ITU-T
G.808.1 , May 2014. Recommendation G.808.1 , May 2014.
[ITU-T_G.873.1] [ITU-T_G.873.1]
ITU-T Recommendation G.873.1, "Optical transport network International Telecommunication Union, "Optical transport
(OTN): Linear protection", ITU-T G.808.1 , October 2017. network (OTN): Linear protection", ITU-T Recommendation
G.873.1 , October 2017.
[OTN-TOPO] [OTN-TOPO] Zheng, H., Busi, I., Liu, X., Belotti, S., and O. G. D.
Zheng, H., Busi, I., Liu, X., Belotti, S., and O. G. D.
Dios, "A YANG Data Model for Optical Transport Network Dios, "A YANG Data Model for Optical Transport Network
Topology", draft-ietf-ccamp-otn-topo-yang-13 (work in Topology", Work in Progress, Internet-Draft, draft-ietf-
progress), July 2021. ccamp-otn-topo-yang-14, 7 March 2022,
<https://www.ietf.org/archive/id/draft-ietf-ccamp-otn-
topo-yang-14.txt>.
[OTN-TUNNEL] [OTN-TUNNEL]
Zheng, H., Busi, I., Belotti, S., Lopez, V., and Y. Xu, Zheng, H., Busi, I., Belotti, S., Lopez, V., and Y. Xu,
"OTN Tunnel YANG Model", draft-ietf-ccamp-otn-tunnel- "OTN Tunnel YANG Model", Work in Progress, Internet-Draft,
model-14 (work in progress), July 2021. draft-ietf-ccamp-otn-tunnel-model-15, 7 March 2022,
<https://www.ietf.org/archive/id/draft-ietf-ccamp-otn-
tunnel-model-15.txt>.
[PATH-COMPUTE] [PATH-COMPUTE]
Busi, I., Belotti, S., Lopez, V., Sharma, A., and Y. Shi, Busi, I., Belotti, S., Dios, O. G. D., Sharma, A., and D.
"YANG Data Model for requesting Path Computation", draft- Ceccarelli, "A YANG Data Model for requesting path
ietf-teas-yang-path-computation-16 (work in progress), computation", Work in Progress, Internet-Draft, draft-
September 2021. ietf-teas-yang-path-computation-18, 22 March 2022,
<https://www.ietf.org/archive/id/draft-ietf-teas-yang-
path-computation-18.txt>.
[RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery [RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery
(Protection and Restoration) Terminology for Generalized (Protection and Restoration) Terminology for Generalized
Multi-Protocol Label Switching (GMPLS)", RFC 4427, Multi-Protocol Label Switching (GMPLS)", RFC 4427,
DOI 10.17487/RFC4427, March 2006, DOI 10.17487/RFC4427, March 2006,
<https://www.rfc-editor.org/info/rfc4427>. <https://www.rfc-editor.org/info/rfc4427>.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Element (PCE)-Based Architecture", RFC 4655, Computation Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006, DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>. <https://www.rfc-editor.org/info/rfc4655>.
[RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the
Path Computation Element Communication Protocol (PCEP) for
Route Exclusions", RFC 5521, DOI 10.17487/RFC5521, April
2009, <https://www.rfc-editor.org/info/rfc5521>.
[RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G.,
Ceccarelli, D., and X. Zhang, "Problem Statement and Ceccarelli, D., and X. Zhang, "Problem Statement and
Architecture for Information Exchange between Architecture for Information Exchange between
Interconnected Traffic-Engineered Networks", BCP 206, Interconnected Traffic-Engineered Networks", BCP 206,
RFC 7926, DOI 10.17487/RFC7926, July 2016, RFC 7926, DOI 10.17487/RFC7926, July 2016,
<https://www.rfc-editor.org/info/rfc7926>. <https://www.rfc-editor.org/info/rfc7926>.
[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
skipping to change at page 49, line 37 skipping to change at page 49, line 32
[RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
O. Gonzalez de Dios, "YANG Data Model for Traffic O. Gonzalez de Dios, "YANG Data Model for Traffic
Engineering (TE) Topologies", RFC 8795, Engineering (TE) Topologies", RFC 8795,
DOI 10.17487/RFC8795, August 2020, DOI 10.17487/RFC8795, August 2020,
<https://www.rfc-editor.org/info/rfc8795>. <https://www.rfc-editor.org/info/rfc8795>.
[TE-TUNNEL] [TE-TUNNEL]
Saad, T., Gandhi, R., Liu, X., Beeram, V. P., Bryskin, I., Saad, T., Gandhi, R., Liu, X., Beeram, V. P., Bryskin, I.,
and O. G. D. Dios, "A YANG Data Model for Traffic and O. G. D. Dios, "A YANG Data Model for Traffic
Engineering Tunnels, Label Switched Paths and Interfaces", Engineering Tunnels, Label Switched Paths and Interfaces",
draft-ietf-teas-yang-te-27 (work in progress), July 2021. Work in Progress, Internet-Draft, draft-ietf-teas-yang-te-
29, 7 February 2022, <https://www.ietf.org/archive/id/
draft-ietf-teas-yang-te-29.txt>.
8.2. Informative References 8.2. Informative References
[ACTN-YANG] [ACTN-YANG]
Lee, Y., Zheng, H., Ceccarelli, D., Yoon, B. Y., and S. Lee, Y., Zheng, H., Ceccarelli, D., Yoon, B. Y., and S.
Belotti, "Applicability of YANG models for Abstraction and Belotti, "Applicability of YANG models for Abstraction and
Control of Traffic Engineered Networks", draft-ietf-teas- Control of Traffic Engineered Networks", Work in Progress,
actn-yang-08 (work in progress), September 2021. Internet-Draft, draft-ietf-teas-actn-yang-09, 7 March
2022, <https://www.ietf.org/archive/id/draft-ietf-teas-
actn-yang-09.txt>.
[MEF55] Metro Ethernet Forum, "Lifecycle Service Orchestration [ITU-T_X.733]
(LSO): Reference Architecture and Framework", Technical International Telecommunication Union, "Information
Specification MEF 55 , March 2016, technology - Open Systems Interconnection - Systems
Management: Alarm reporting function", ITU-T
Recommendation X.733 , February 1992.
[ITU-T_X.734]
International Telecommunication Union, "Information
technology - Open Systems Interconnection - Systems
Management: Event report management function", ITU-T
Recommendation X.734 , September 1992.
[MEF55] MEF Forum, "Lifecycle Service Orchestration (LSO):
Reference Architecture and Framework", MEF 55 , March
2016,
<https://www.mef.net/Assets/Technical_Specifications/PDF/ <https://www.mef.net/Assets/Technical_Specifications/PDF/
MEF_55.pdf>. MEF_55.pdf>.
[ONF_TR-527] [ONF_TR-527]
ONF Technical Recommendation TR-527, "Functional Open Networking Foundation, "Functional Requirements for
Requirements for Transport API", ONF TR-527 , May 2014. Transport API", ONF Technical Recommendation TR-527 , May
2014.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>. <https://www.rfc-editor.org/info/rfc6242>.
skipping to change at page 50, line 47 skipping to change at page 51, line 12
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
"Handling Long Lines in Content of Internet-Drafts and "Handling Long Lines in Content of Internet-Drafts and
RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
<https://www.rfc-editor.org/info/rfc8792>. <https://www.rfc-editor.org/info/rfc8792>.
[TE-TUTORIAL] [TE-TUTORIAL]
Bryskin, I., Beeram, V. P., Saad, T., and X. Liu, "TE Bryskin, I., Beeram, V. P., Saad, T., and X. Liu, "TE
Topology and Tunnel Modeling for Transport Networks", Topology and Tunnel Modeling for Transport Networks", Work
draft-ietf-teas-te-topo-and-tunnel-modeling-06 (work in in Progress, Internet-Draft, draft-ietf-teas-te-topo-and-
progress), July 2020. tunnel-modeling-06, 12 July 2020,
<https://www.ietf.org/archive/id/draft-ietf-teas-te-topo-
and-tunnel-modeling-06.txt>.
Appendix A. Validating a JSON fragment against a YANG Model Appendix A. Validating a JSON fragment against a YANG Model
The objective is to have a tool that allows validating whether a The objective is to have a tool that allows validating whether a
piece of JSON code embedded in an Internet-Draft is compliant with a piece of JSON code embedded in an Internet-Draft is compliant with a
YANG model without using a client/server. YANG model without using a client/server.
A.1. Manipulation of JSON fragments A.1. JSON CODE
This document provides some detailed JSON code examples to describe
how the YANG models being developed by the IETF (TEAS and CCAMP WG in
particular) may be used. The scenario examples are provided using
JSON to facilitate readability.
Different objects need to have an identifier. The convention used to
create mnemonic identifiers is to use the object name (e.g., S3 for
node S3), followed by its type (e.g., NODE), separated by a "-",
followed by "-ID". For example, the mnemonic identifier for AN1
would be AN1-NODE-ID.
The JSON language does not inherently support the insertion of
comments. This document will insert comments into the JSON code as
JSON name/value pair with the JSON name string starting with the "//"
characters. For example, when describing the example of a TE
Topology instance representing the ODU Abstract Topology exposed by
the Transport PNC, the following comment has been added to the JSON
code:
"// comment": "ODU Abstract Topology @ MPI",
The JSON code examples provided in this document have been validated
against the YANG models following the validation process described in
Appendix A, which would not consider the comments.
To have successful validation of the examples, some numbering scheme
has been defined to assign identifiers to the different entities
which would pass the syntax checks. In that case, to simplify the
reading, another JSON name/value pair formatted as a comment and
using the mnemonic identifiers is also provided. For example, the
identifier of AN1 (AN1-NODE-ID) has been assumed to be "192.0.2.1"
and would be shown in the JSON code example using the two JSON name/
value pair:
"// te-node-id": "AN1-NODE-ID",
"te-node-id": "192.0.2.1",
The first JSON name/value pair will be automatically removed in the
first step of the validation process, while the second JSON name/
value pair will be validated against the YANG model definitions.
A.2. Manipulation of JSON fragments
This section describes the various ways JSON fragments are used in This section describes the various ways JSON fragments are used in
the I-D processing and how to manage them. the I-D processing and how to manage them.
Let's call "folded-JSON" the JSON embedded in the I-D: it fits the 72 Let's call "folded-JSON" the JSON embedded in the I-D: it fits the 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
skipping to change at page 51, line 50 skipping to change at page 53, line 18
<-- 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 JSON-encoding
of YANG data? may may must of YANG data? may may must
Our validation toolchain has been designed to take a JSON in any of The 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.
found at: https://github.com/GianmarcoBruno/json-yang/
A.2. Comments in JSON fragments The tool used to validate the JSON examples in this document can be
found at: https://github.com/ietf-ccamp-wg/json-yang/tree/2.2
We found useful to introduce two kinds of comments, both defined as A.3. Comments in JSON fragments
key-value pairs where the key starts with "//":
o free-form descriptive comments, e.g."// COMMENT" : "refine this" We found it useful to introduce two kinds of comments, both defined
as key-value pairs where the key starts with "//":
* free-form descriptive comments, e.g."// comment" : "refine this"
to describe properties of JSON fragments. to describe properties of JSON fragments.
o machine-usable directives e.g. "// *REFERENCES__DRAFTS*" : { * machine-usable directives e.g. "// header" : {"reference-drafts" :
"ietf-routing-types@2017-12-04": "rfc8294",} which can be used to { "ietf-routing-types@2017-12-04": "rfc8294",}} which can be used
automatically download from the network the relevant I-Ds or RFCs to automatically download from the network the relevant I-Ds or
and extract from them the YANG models of interest. This is RFCs and extract from them the YANG models of interest. This is
particularly useful to keep consistency when the drafting work is particularly useful to keep consistency when the drafting work is
rapidly evolving. rapidly evolving.
A.3. Validation of JSON fragments: DSDL-based approach A.4. Validation of JSON fragments: DSDL-based approach
The idea is to generate a JSON driver file (JTOX) from YANG, then use The idea is to generate a JSON driver file (JTOX) from YANG, then use
it to translate JSON to XML and validate it against the DSDL schemas, it to translate JSON to XML and validate it against the DSDL 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
(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 3, without impacting the validation process, these defined in Section 3, without 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 validated.
A.4. Validation of JSON fragments: why not using an XSD-based approach A.5. Validation of JSON fragments: why not using an XSD-based approach
This approach has been analyzed and discarded because no longer This approach has been analyzed and discarded because no longer
supported by pyang. supported by pyang.
The idea is to convert YANG to XSD, JSON to XML and validate it The idea is to convert YANG to XSD, JSON to XML and validate it
against the XSD, as shown in Figure 9: against the XSD, as shown in Figure 9:
(1) (1)
YANG-module ---> XSD-schema - \ (3) YANG-module ---> XSD-schema - \ (3)
+--> Validation +--> Validation
JSON-file------> XML-file ----/ JSON-file------> XML-file ----/
(2) (2)
Figure 9: XSD-based approach for JSON code validation Figure 9: XSD-based approach for JSON code validation
The pyang support for the XSD output format was deprecated in 1.5 and The pyang support for the XSD output format was deprecated in 1.5 and
removed in 1.7.1. However pyang 1.7.1 is necessary to work with YANG removed in 1.7.1. However, pyang 1.7.1 is necessary to work with
1.1 so the process shown in Figure 9 will stop just at step (1). YANG 1.1 so the process shown in Figure 9 will stop just at step (1).
Appendix B. Detailed JSON Examples Appendix B. Detailed JSON Examples
The JSON code examples provided in this appendix have been validated The JSON code examples provided in this appendix have been validated
using the tools in Appendix A and folded using the tool in [RFC8792]. using the tools in Appendix A and folded using the tool in [RFC8792].
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 @ MPI1: This is the JSON code reporting the OTN Topology @ MPI1:
========== NOTE: '\\' line wrapping per BCP XXX (RFC XXXX) ========== =============== NOTE: '\\' line wrapping per RFC 8792 ===============
{ {
"// __LAST_UPDATE__": "October 21, 2019", "// header": {
"// __TITLE__": "ODU Black Topology @ MPI1", "last-update": "March 15, 2022",
"// __REFERENCE_DRAFTS__": { "title": "ODU Black Topology @ MPI1",
"ietf-routing-types@2017-12-04": "rfc8294", "missing-attributes": true,
"ietf-te-types@2019-07-05": "draft-ietf-teas-yang-te-types-10", "reference-drafts": {
"ietf-layer1-types@2019-09-09": "draft-ietf-ccamp-layer1-types-0\ "ietf-routing-types@2017-12-04": "rfc8294",
\2", "ietf-te-types@2020-06-10": "rfc8776",
"ietf-network@2018-02-26": "rfc8345", "ietf-layer1-types@2021-02-19": "draft-ietf-ccamp-layer1-types\
"ietf-network-topology@2018-02-26": "rfc8345", \-10",
"ietf-te-topology@2019-02-07": "draft-ietf-teas-yang-te-topo-22", "ietf-network@2018-02-26": "rfc8345",
"ietf-otn-topology@2019-07-07": "draft-ietf-ccamp-otn-topo-yang-\ "ietf-network-topology@2018-02-26": "rfc8345",
\08" "ietf-te-topology@2020-08-06": "rfc8795",
"ietf-otn-topology@2021-07-08": "draft-ietf-ccamp-otn-topo-yan\
\g-13"
}
}, },
"// __MISSING_ATTRIBUTES__": true,
"ietf-network:networks": { "ietf-network:networks": {
"network": [ "network": [
{ {
"network-id": "providerId/201/clientId/300/topologyId/otn-bl\ "network-id": "providerId/201/clientId/300/topologyId/otn-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:te-topology-identifier": { "ietf-te-topology:te-topology-identifier": {
"provider-id": 201, "provider-id": 201,
"client-id": 300, "client-id": 300,
"topology-id": "otn-black-topology" "topology-id": "otn-black-topology"
}, },
"// __COMMENT__ ietf-te-topology:te": "presence container re\ "// comment ietf-te-topology:te": "presence container requir\
\quires: provider-id, client-id and te-topology-id", \es: provider-id, client-id 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": [ "ietf-network:node": [
{ {
"// __NODE__:__DESCRIPTION__": { "// node description": {
"name": "AN1", "name": "AN1",
"identifier": "10.0.0.1", "identifier": "192.0.2.1",
"type": "Abstract Node", "type": "Abstract Node",
"physical node(s)": "The whole network domain 1" "physical node(s)": "The whole network domain 1"
}, },
"node-id": "10.0.0.1", "node-id": "192.0.2.1",
"ietf-te-topology:te-node-id": "10.0.0.1", "ietf-te-topology:te-node-id": "192.0.2.1",
"ietf-te-topology:te": { "ietf-te-topology:te": {
"te-node-attributes": { "te-node-attributes": {
"name": "AN11", "name": "AN11",
"is-abstract": "", "is-abstract": [
null
],
"admin-status": "up" "admin-status": "up"
}, },
"oper-status": "up", "oper-status": "up",
"tunnel-termination-point": [ "tunnel-termination-point": [
{ {
"// __COMMENT__ tunnel-tp-id": "AN1-1 TTP-ID (1 ->\ "// comment tunnel-tp-id": "AN1-1 TTP-ID (1 -> 0x0\
\ 0x01 -> 'AQ==')", \1 -> 'AQ==' in base64)",
"tunnel-tp-id": "AQ==", "tunnel-tp-id": "AQ==",
"name": "AN1-1 OTN TTP", "name": "AN1-1 OTN TTP",
"// __COMMENT__ encoding and switching-capability"\ "// comment encoding and switching-capability": "O\
\: "OTN (ODU)", \TN (ODU)",
"switching-capability": "ietf-te-types:switching-o\ "switching-capability": "ietf-te-types:switching-o\
\tn", \tn",
"encoding": "ietf-te-types:lsp-encoding-oduk", "encoding": "ietf-te-types:lsp-encoding-oduk",
"// __COMMENT__ inter-layer-lock-id": "{ AN1-1 ILL\ "// comment inter-layer-lock-id": "{ AN1-1 ILL-ID \
\-ID (1) }", \(1) }",
"inter-layer-lock-id": [ "inter-layer-lock-id": [
1 1
], ],
"admin-status": "up", "admin-status": "up",
"oper-status": "up" "oper-status": "up"
}, },
{ {
"// __COMMENT__ tunnel-tp-id": "AN1-2 TTP-ID (2 ->\ "// comment tunnel-tp-id": "AN1-2 TTP-ID (2 -> 0x0\
\ 0x02 -> 'Ag==')", \2 -> 'Ag==' in base64)",
"tunnel-tp-id": "Ag==", "tunnel-tp-id": "Ag==",
"name": "AN1-2 OTN TTP", "name": "AN1-2 OTN TTP",
"// __COMMENT__ encoding and switching-capability"\ "// comment encoding and switching-capability": "O\
\: "OTN (ODU)", \TN (ODU)",
"switching-capability": "ietf-te-types:switching-o\ "switching-capability": "ietf-te-types:switching-o\
\tn", \tn",
"encoding": "ietf-te-types:lsp-encoding-oduk", "encoding": "ietf-te-types:lsp-encoding-oduk",
"// __COMMENT__ inter-layer-lock-id": "{ AN1-2 ILL\ "// comment inter-layer-lock-id": "{ AN1-2 ILL-ID \
\-ID (2) }", \(2) }",
"inter-layer-lock-id": [ "inter-layer-lock-id": [
2 2
], ],
"admin-status": "up", "admin-status": "up",
"oper-status": "up" "oper-status": "up"
}, },
{ {
"// __COMMENT__ tunnel-tp-id": "AN1-3 TTP-ID (3 ->\ "// comment tunnel-tp-id": "AN1-3 TTP-ID (3 -> 0x0\
\ 0x03 -> 'Awo=')", \3 -> 'Awo=' in base64)",
"tunnel-tp-id": "Awo=", "tunnel-tp-id": "Awo=",
"name": "AN1-3 OTN TTP", "name": "AN1-3 OTN TTP",
"// __COMMENT__ encoding and switching-capability"\ "// comment encoding and switching-capability": "O\
\: "OTN (ODU)", \TN (ODU)",
"switching-capability": "ietf-te-types:switching-o\ "switching-capability": "ietf-te-types:switching-o\
\tn", \tn",
"encoding": "ietf-te-types:lsp-encoding-oduk", "encoding": "ietf-te-types:lsp-encoding-oduk",
"// __COMMENT__ inter-layer-lock-id": "{ AN1-3 ILL\ "// comment inter-layer-lock-id": "{ AN1-3 ILL-ID \
\-ID (3) }", \(3) }",
"inter-layer-lock-id": [ "inter-layer-lock-id": [
3 3
], ],
"admin-status": "up", "admin-status": "up",
"oper-status": "up" "oper-status": "up"
}, },
{ {
"// __COMMENT__ tunnel-tp-id": "AN1-8 TTP-ID (8 ->\ "// comment tunnel-tp-id": "AN1-8 TTP-ID (8 -> 0x0\
\ 0x08 -> 'CA==')", \8 -> 'CA==' in base64)",
"tunnel-tp-id": "CA==", "tunnel-tp-id": "CA==",
"name": "AN1-8 OTN TTP", "name": "AN1-8 OTN TTP",
"// __COMMENT__ encoding and switching-capability"\ "// comment encoding and switching-capability": "O\
\: "OTN (ODU)", \TN (ODU)",
"switching-capability": "ietf-te-types:switching-o\ "switching-capability": "ietf-te-types:switching-o\
\tn", \tn",
"encoding": "ietf-te-types:lsp-encoding-oduk", "encoding": "ietf-te-types:lsp-encoding-oduk",
"// __COMMENT__ inter-layer-lock-id": "{ AN1-8 ILL\ "// comment inter-layer-lock-id": "{ AN1-8 ILL-ID \
\-ID (1) }", \(1) }",
"inter-layer-lock-id": [ "inter-layer-lock-id": [
8 8
], ],
"admin-status": "up", "admin-status": "up",
"oper-status": "up" "oper-status": "up"
} }
] ]
}, },
"ietf-network-topology:termination-point": [ "ietf-network-topology:termination-point": [
{ {
"// __DESCRIPTION__:__LTP__": { "// ltp description": {
"name": "AN1-1 LTP", "name": "AN1-1 LTP",
"link type(s)": "Multi-function (OTU2, STM-64 and \ "link type(s)": "Multi-function (OTU2, STM-64 and \
\10GE)", \10GE)",
"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",
"interface-switching-capability": [ "interface-switching-capability": [
{ {
"// __COMMENT__ encoding and switching-capabil\ "// comment encoding and switching-capability"\
\ity": "OTN (ODU)", \: "OTN (ODU)",
"switching-capability": "ietf-te-types:switchi\ "switching-capability": "ietf-te-types:switchi\
\ng-otn", \ng-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,
"te-bandwidth": { "te-bandwidth": {
"ietf-otn-topology:odu-type": "ietf-laye\ "ietf-otn-topology:otn": {
\r1-types:ODU2" "odu-type": "ietf-layer1-types:ODU2"
}
} }
} }
] ]
} }
], ],
"// __NOT-PRESENT__ inter-domain-plug-id": "Use of\ "// not-present inter-domain-plug-id": "Use of plu\
\ plug-id for access Link is outside the scope of this document", \g-id for access Link is outside the scope of this document",
"// __COMMENT__ inter-layer-lock-id": "{ AN1-1 ILL\ "// comment inter-layer-lock-id": "{ AN1-1 ILL-ID \
\-ID (1) }", \(1) }",
"inter-layer-lock-id": [ "inter-layer-lock-id": [
1 1
], ],
"admin-status": "up", "admin-status": "up",
"oper-status": "up", "oper-status": "up",
"ietf-otn-topology:client-svc": { "ietf-otn-topology:client-svc": {
"client-facing": true, "client-facing": true,
"supported-client-signal": [ "supported-client-signal": [
"ietf-layer1-types:STM-64" "ietf-layer1-types:STM-64"
] ]
} }
} }
}, },
{ {
"// __DESCRIPTION__:__LTP__": { "// ltp description": {
"name": "AN1-2 LTP", "name": "AN1-2 LTP",
"link type(s)": "Multi-function (OTU2 and STM-64)", "link type(s)": "Multi-function (OTU2 and STM-64)"\
\,
"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": "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",
"interface-switching-capability": [ "interface-switching-capability": [
{ {
"// __COMMENT__ encoding and switching-capabil\ "// comment encoding and switching-capability"\
\ity": "OTN (ODU)", \: "OTN (ODU)",
"switching-capability": "ietf-te-types:switchi\ "switching-capability": "ietf-te-types:switchi\
\ng-otn", \ng-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,
"te-bandwidth": { "te-bandwidth": {
"ietf-otn-topology:odu-type": "ietf-laye\ "ietf-otn-topology:otn": {
\r1-types:ODU2" "odu-type": "ietf-layer1-types:ODU2"
}
} }
} }
] ]
} }
], ],
"// __NOT-PRESENT__ inter-domain-plug-id": "Use of\ "// not-present inter-domain-plug-id": "Use of plu\
\ plug-id for access Link is outside the scope of this document", \g-id for access Link is outside the scope of this document",
"// __COMMENT__ inter-layer-lock-id": "{ AN1-2 ILL\ "// comment inter-layer-lock-id": "{ AN1-2 ILL-ID \
\-ID (2) }", \(2) }",
"inter-layer-lock-id": [ "inter-layer-lock-id": [
2 2
], ],
"admin-status": "up", "admin-status": "up",
"oper-status": "up", "oper-status": "up",
"ietf-otn-topology:client-svc": { "ietf-otn-topology:client-svc": {
"client-facing": true, "client-facing": true,
"supported-client-signal": [ "supported-client-signal": [
"ietf-layer1-types:STM-64" "ietf-layer1-types:STM-64"
] ]
} }
} }
}, },
{ {
"// __DESCRIPTION__:__LTP__": { "// ltp description": {
"name": "AN1-3 LTP", "name": "AN1-3 LTP",
"link type(s)": "STM-64", "link type(s)": "STM-64",
"physical node": "S6", "physical node": "S6",
"unnumberd/ifIndex": 3, "unnumberd/ifIndex": 3,
"port type": "tributary port", "port type": "tributary port",
"connected to": "R4" "connected to": "R4"
}, },
"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",
"// __NOT-PRESENT__ interface-switching-capability\ "// not-present interface-switching-capability": "\
\": "STM-64 Access Link only (no ODU switching)", \STM-64 Access Link only (no ODU switching)",
"// __NOT-PRESENT__ inter-domain-plug-id": "Use of\ "// not-present inter-domain-plug-id": "Use of plu\
\ plug-id for access Link is outside the scope of this document", \g-id for access Link is outside the scope of this document",
"// __COMMENT__ inter-layer-lock-id": "{ AN1-3 ILL\ "// comment inter-layer-lock-id": "{ AN1-3 ILL-ID \
\-ID (3) }", \(3) }",
"inter-layer-lock-id": [ "inter-layer-lock-id": [
3 3
], ],
"admin-status": "up", "admin-status": "up",
"oper-status": "up", "oper-status": "up",
"ietf-otn-topology:client-svc": { "ietf-otn-topology:client-svc": {
"client-facing": true, "client-facing": true,
"supported-client-signal": [ "supported-client-signal": [
"ietf-layer1-types:STM-64" "ietf-layer1-types:STM-64"
] ]
skipping to change at page 59, line 4 skipping to change at page 60, line 32
3 3
], ],
"admin-status": "up", "admin-status": "up",
"oper-status": "up", "oper-status": "up",
"ietf-otn-topology:client-svc": { "ietf-otn-topology:client-svc": {
"client-facing": true, "client-facing": true,
"supported-client-signal": [ "supported-client-signal": [
"ietf-layer1-types:STM-64" "ietf-layer1-types:STM-64"
] ]
} }
} }
}, },
{ {
"// __DESCRIPTION__:__LTP__": { "// ltp description": {
"name": "AN1-4 LTP", "name": "AN1-4 LTP",
"link type(s)": "OTU4", "link type(s)": "OTU4",
"physical node": "S7", "physical node": "S7",
"unnumberd/ifIndex": 3, "unnumberd/ifIndex": 3,
"port type": "inter-domain port", "port type": "inter-domain port",
"connected to": "S11" "connected to": "S11"
}, },
"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",
"interface-switching-capability": [ "interface-switching-capability": [
{ {
"// __COMMENT__ encoding and switching-capabil\ "// comment encoding and switching-capability"\
\ity": "OTN (ODU)", \: "OTN (ODU)",
"switching-capability": "ietf-te-types:switchi\ "switching-capability": "ietf-te-types:switchi\
\ng-otn", \ng-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,
"te-bandwidth": { "te-bandwidth": {
"ietf-otn-topology:odu-type": "ietf-laye\ "ietf-otn-topology:otn": {
\r1-types:ODU4" "odu-type": "ietf-layer1-types:ODU4"
}
} }
} }
] ]
} }
], ],
"// __COMMENT__ inter-domain-plug-id": "S7-S11 Plu\ "// comment inter-domain-plug-id": "S7-S11 Plug-id\
\g-id (0x000711 -> AAcR)", \ (0x000711 -> AAcR)",
"inter-domain-plug-id": "AAcR", "inter-domain-plug-id": "AAcR",
"// __NOT-PRESENT__ inter-layer-lock-id": "ODU Ser\ "// not-present inter-layer-lock-id": "ODU Server \
\ver Layer topology not exposed", \Layer topology not exposed",
"admin-status": "up", "admin-status": "up",
"oper-status": "up", "oper-status": "up",
"// __NOT-PRESENT__ ietf-otn-topology:client-svc":\ "// not-present ietf-otn-topology:client-svc": "OT\
\ "OTN inter-domain link" \N inter-domain link"
} }
}, },
{ {
"// __DESCRIPTION__:__LTP__": { "// ltp description": {
"name": "AN1-5 LTP", "name": "AN1-5 LTP",
"link type(s)": "OTU4", "link type(s)": "OTU4",
"physical node": "S8", "physical node": "S8",
"unnumberd/ifIndex": 4, "unnumberd/ifIndex": 4,
"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",
"interface-switching-capability": [ "interface-switching-capability": [
{ {
"// __COMMENT__ encoding and switching-capabil\ "// comment encoding and switching-capability"\
\ity": "OTN (ODU)", \: "OTN (ODU)",
"switching-capability": "ietf-te-types:switchi\ "switching-capability": "ietf-te-types:switchi\
\ng-otn", \ng-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,
"te-bandwidth": { "te-bandwidth": {
"ietf-otn-topology:odu-type": "ietf-laye\ "ietf-otn-topology:otn": {
\r1-types:ODU4" "odu-type": "ietf-layer1-types:ODU4"
}
} }
} }
] ]
} }
], ],
"// __COMMENT__ inter-domain-plug-id": "S8-S12 Plu\ "// comment inter-domain-plug-id": "S8-S12 Plug-id\
\g-id (0x000812 -> AAgS)", \ (0x000812 -> AAgS)",
"inter-domain-plug-id": "AAgS", "inter-domain-plug-id": "AAgS",
"// __NOT-PRESENT__ inter-layer-lock-id": "ODU Ser\ "// not-present inter-layer-lock-id": "ODU Server \
\ver Layer topology not exposed", \Layer topology not exposed",
"admin-status": "up", "admin-status": "up",
"oper-status": "up", "oper-status": "up",
"// __NOT-PRESENT__ ietf-otn-topology:client-svc":\ "// not-present ietf-otn-topology:client-svc": "OT\
\ "OTN inter-domain link" \N inter-domain link"
} }
}, },
{ {
"// __DESCRIPTION__:__LTP__": { "// ltp description": {
"name": "AN1-6 LTP", "name": "AN1-6 LTP",
"link type(s)": "OTU4", "link type(s)": "OTU4",
"physical node": "S8", "physical node": "S8",
"unnumberd/ifIndex": 5, "unnumberd/ifIndex": 5,
"port type": "inter-domain port", "port type": "inter-domain port",
"connected to": "S32" "connected to": "S32"
}, },
"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",
"interface-switching-capability": [ "interface-switching-capability": [
{ {
"// __COMMENT__ encoding and switching-capabil\ "// comment encoding and switching-capability"\
\ity": "OTN (ODU)", \: "OTN (ODU)",
"switching-capability": "ietf-te-types:switchi\ "switching-capability": "ietf-te-types:switchi\
\ng-otn", \ng-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,
"te-bandwidth": { "te-bandwidth": {
"ietf-otn-topology:odu-type": "ietf-laye\ "ietf-otn-topology:otn": {
\r1-types:ODU4" "odu-type": "ietf-layer1-types:ODU4"
}
} }
} }
] ]
} }
], ],
"// __COMMENT__ inter-domain-plug-id": "S8-S32 Plu\ "// comment inter-domain-plug-id": "S8-S32 Plug-id\
\g-id (0x000832 -> AAgy)", \ (0x000832 -> AAgy)",
"inter-domain-plug-id": "AAgy", "inter-domain-plug-id": "AAgy",
"// __NOT-PRESENT__ inter-layer-lock-id": "ODU Ser\ "// not-present inter-layer-lock-id": "ODU Server \
\ver Layer topology not exposed", \Layer topology not exposed",
"admin-status": "up", "admin-status": "up",
"oper-status": "up", "oper-status": "up",
"// __NOT-PRESENT__ ietf-otn-topology:client-svc":\ "// not-present ietf-otn-topology:client-svc": "OT\
\ "OTN inter-domain link" \N inter-domain link"
} }
}, },
{ {
"// __DESCRIPTION__:__LTP__": { "// ltp description": {
"name": "AN1-7 LTP", "name": "AN1-7 LTP",
"link type(s)": "OTU4", "link type(s)": "OTU4",
"physical node": "S2", "physical node": "S2",
"unnumberd/ifIndex": 3, "unnumberd/ifIndex": 3,
"port type": "inter-domain port", "port type": "inter-domain port",
"connected to": "S31" "connected to": "S31"
}, },
"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",
"interface-switching-capability": [ "interface-switching-capability": [
{ {
"// __COMMENT__ encoding and switching-capabil\ "// comment encoding and switching-capability"\
\: "OTN (ODU)",
\ity": "OTN (ODU)",
"switching-capability": "ietf-te-types:switchi\ "switching-capability": "ietf-te-types:switchi\
\ng-otn", \ng-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,
"te-bandwidth": { "te-bandwidth": {
"ietf-otn-topology:odu-type": "ietf-laye\ "ietf-otn-topology:otn": {
\r1-types:ODU4" "odu-type": "ietf-layer1-types:ODU4"
}
} }
} }
] ]
} }
], ],
"// __COMMENT__ inter-domain-plug-id": "S2-S31 Plu\ "// comment inter-domain-plug-id": "S2-S31 Plug-id\
\g-id (0x000231 -> AAIx)",
\ (0x000231 -> AAIx)",
"inter-domain-plug-id": "AAIx", "inter-domain-plug-id": "AAIx",
"// __NOT-PRESENT__ inter-layer-lock-id": "ODU Ser\ "// not-present inter-layer-lock-id": "ODU Server \
\ver Layer topology not exposed", \Layer topology not exposed",
"admin-status": "up", "admin-status": "up",
"oper-status": "up", "oper-status": "up",
"// __NOT-PRESENT__ ietf-otn-topology:client-svc":\ "// not-present ietf-otn-topology:client-svc": "OT\
\ "OTN inter-domain link" \N inter-domain link"
} }
} }
] ]
} }
], ],
"ietf-network-topology:link": [ "ietf-network-topology:link": [
{ {
"// __DESCRIPTION__:__LINK__": { "// link description": {
"name": "Access Link from AN1-1", "name": "Access Link from AN1-1",
"type": "Multi-function access link (OTU2, STM-64 and \ "type": "Multi-function access link (OTU2, STM-64 and \
\10GE)", \10GE)",
"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/192.0.2.1/teLinkId/1",
"source": { "source": {
"source-node": "10.0.0.1", "source-node": "192.0.2.1",
"source-tp": 1 "source-tp": "1"
}, },
"// __NOT-PRESENT__ destination": "access link", "// not-present destination": "access link",
"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",
"// __NOT-PRESENT__ external-domain": "The plug-id i\ "// not-present external-domain": "The plug-id is us\
\s used instead of this container", \ed instead of this container",
"// __NOT-PRESENT__ is-abstract": "The access link i\ "// not-present is-abstract": "The access link is no\
\s not abstract", \t abstract",
"interface-switching-capability": [ "interface-switching-capability": [
{ {
"// __COMMENT__ encoding and switching-capabilit\ "// comment encoding and switching-capability": \
\y": "OTN (ODU)", \"OTN (ODU)",
"switching-capability": "ietf-te-types:switching\ "switching-capability": "ietf-te-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,
"te-bandwidth": { "te-bandwidth": {
"ietf-otn-topology:odu-type": "ietf-layer1\ "ietf-otn-topology:otn": {
\-types:ODU2" "odu-type": "ietf-layer1-types:ODU4"
}
} }
} }
] ]
} }
], ],
"// __COMMENT__ label-restrictions": "Outside the sc\ "// comment label-restrictions": "Outside the scope \
\ope of this JSON example", \of this JSON example",
"max-link-bandwidth": { "max-link-bandwidth": {
"te-bandwidth": { "te-bandwidth": {
"ietf-otn-topology:odulist": [ "ietf-otn-topology:odulist": [
{ {
"odu-type": "ietf-layer1-types:ODU2", "odu-type": "ietf-layer1-types:ODU2",
"number": 1 "number": 1
} }
] ]
} }
}, },
skipping to change at page 64, line 11 skipping to change at page 65, line 45
"te-bandwidth": { "te-bandwidth": {
"ietf-otn-topology:odulist": [ "ietf-otn-topology:odulist": [
{ {
"odu-type": "ietf-layer1-types:ODU2", "odu-type": "ietf-layer1-types:ODU2",
"number": 1 "number": 1
} }
] ]
} }
} }
], ],
"// __NOT-PRESENT__ ietf-otn-topology:tsg": "Access \ "// not-present ietf-otn-topology:tsg": "Access Link\
\Link with no HO-ODU termination and LO-ODU switching", \ with no HO-ODU termination and LO-ODU switching",
"admin-status": "up" "admin-status": "up"
}, },
"oper-status": "up", "oper-status": "up",
"// __NOT-PRESENT__ is-transitional": "It is not a tra\ "// not-present is-transitional": "It is not a transit\
\nsitional link" \ional link"
} }
}, },
{ {
"// __DESCRIPTION__:__LINK__": { "// link description": {
"name": "Access Link from AN1-2", "name": "Access Link from AN1-2",
"type": "Multi-function access link (OTU2 and STM-64)", "type": "Multi-function access link (OTU2 and STM-64)"\
\,
"physical link": "Link from S6-2 to R3" "physical link": "Link from S6-2 to R3"
}, },
"link-id": "teNodeId/10.0.0.1/teLinkId/2", "link-id": "teNodeId/192.0.2.1/teLinkId/2",
"source": { "source": {
"source-node": "10.0.0.1", "source-node": "192.0.2.1",
"source-tp": 2 "source-tp": "2"
}, },
"// __NOT-PRESENT__ destination": "access link", "// not-present destination": "access link",
"ietf-te-topology:te": { "ietf-te-topology:te": {
"te-link-attributes": { "te-link-attributes": {
"name": "Access Link from AN1-2", "name": "Access Link from AN1-2",
"// __NOT-PRESENT__ external-domain": "The plug-id i\ "// not-present external-domain": "The plug-id is us\
\s used instead of this container", \ed instead of this container",
"// __NOT-PRESENT__ is-abstract": "The access link i\ "// not-present is-abstract": "The access link is no\
\s not abstract", \t abstract",
"interface-switching-capability": [ "interface-switching-capability": [
{ {
"// __COMMENT__ encoding and switching-capabilit\ "// comment encoding and switching-capability": \
\y": "OTN (ODU)", \"OTN (ODU)",
"switching-capability": "ietf-te-types:switching\ "switching-capability": "ietf-te-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,
"te-bandwidth": { "te-bandwidth": {
"ietf-otn-topology:odu-type": "ietf-layer1\ "ietf-otn-topology:otn": {
\-types:ODU2" "odu-type": "ietf-layer1-types:ODU2"
}
} }
} }
] ]
} }
], ],
"// __COMMENT__ label-restrictions": "Outside the sc\ "// comment label-restrictions": "Outside the scope \
\ope of this JSON example", \of this JSON example",
"max-link-bandwidth": { "max-link-bandwidth": {
"te-bandwidth": { "te-bandwidth": {
"ietf-otn-topology:odulist": [ "ietf-otn-topology:odulist": [
{ {
"odu-type": "ietf-layer1-types:ODU2", "odu-type": "ietf-layer1-types:ODU2",
"number": 1 "number": 1
} }
] ]
} }
}, },
"max-resv-link-bandwidth": { "max-resv-link-bandwidth": {
"te-bandwidth": { "te-bandwidth": {
"ietf-otn-topology:odulist": [ "ietf-otn-topology:odulist": [
{ {
"odu-type": "ietf-layer1-types:ODU2", "odu-type": "ietf-layer1-types:ODU2",
"number": 1 "number": 1
skipping to change at page 65, line 44 skipping to change at page 67, line 32
"te-bandwidth": { "te-bandwidth": {
"ietf-otn-topology:odulist": [ "ietf-otn-topology:odulist": [
{ {
"odu-type": "ietf-layer1-types:ODU2", "odu-type": "ietf-layer1-types:ODU2",
"number": 1 "number": 1
} }
] ]
} }
} }
], ],
"// __NOT-PRESENT__ ietf-otn-topology:tsg": "Access \ "// not-present ietf-otn-topology:tsg": "Access Link\
\Link with no HO-ODU termination and LO-ODU switching", \ with no HO-ODU termination and LO-ODU switching",
"admin-status": "up" "admin-status": "up"
}, },
"oper-status": "up", "oper-status": "up",
"// __NOT-PRESENT__ is-transitional": "It is not a tra\ "// not-present is-transitional": "It is not a transit\
\nsitional link" \ional link"
} }
}, },
{ {
"// __DESCRIPTION__:__LINK__": { "// link description": {
"name": "Access Link from AN1-3", "name": "Access Link from AN1-3",
"type": "STM-64 Access link", "type": "STM-64 Access link",
"physical link": "Link from S6-3 to R4" "physical link": "Link from S6-3 to R4"
}, },
"link-id": "teNodeId/10.0.0.1/teLinkId/3", "link-id": "teNodeId/192.0.2.1/teLinkId/3",
"source": { "source": {
"source-node": "10.0.0.1", "source-node": "192.0.2.1",
"source-tp": 3 "source-tp": "3"
}, },
"// __NOT-PRESENT__ destination": "access link", "// not-present destination": "access link",
"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",
"// __NOT-PRESENT__ external-domain": "The plug-id i\ "// not-present external-domain": "The plug-id is us\
\s used instead of this container", \ed instead of this container",
"// __NOT-PRESENT__ is-abstract": "The access link i\ "// not-present is-abstract": "The access link is no\
\s not abstract", \t abstract",
"// __NOT-PRESENT__ interface-switching-capability":\ "// not-present interface-switching-capability": "ST\
\ "STM-64 Access Link only (no ODU switching)", \M-64 Access Link only (no ODU switching)",
"// __NOT-PRESENT__ max-link-bandwidth": "STM-64 Acc\ "// not-present max-link-bandwidth": "STM-64 Access \
\ess Link only (no ODU switching)", \Link only (no ODU switching)",
"// __NOT-PRESENT__ max-resv-link-bandwidth": "STM-6\ "// not-present max-resv-link-bandwidth": "STM-64 Ac\
\4 Access Link only (no ODU switching)", \cess Link only (no ODU switching)",
"// __NOT-PRESENT__ unreserved-bandwidth": "STM-64 A\ "// not-present unreserved-bandwidth": "STM-64 Acces\
\ccess Link only (no ODU switching)", \s Link only (no ODU switching)",
"// __NOT-PRESENT__ ietf-otn-topology:tsg": "STM-64 \ "// not-present ietf-otn-topology:tsg": "STM-64 Acce\
\Access Link only (no HO-ODU termination and LO-ODU switching)", \ss Link only (no HO-ODU termination and LO-ODU switching)",
"admin-status": "up" "admin-status": "up"
}, },
"oper-status": "up", "oper-status": "up",
"// __NOT-PRESENT__ is-transitional": "It is not a tra\ "// not-present is-transitional": "It is not a transit\
\nsitional link" \ional link"
} }
}, },
{ {
"// __DESCRIPTION__:__LINK__": { "// link description": {
"name": "Inter-domain Link from AN1-4", "name": "Inter-domain Link from AN1-4",
"type": "OTU4 inter-domain link", "type": "OTU4 inter-domain link",
"physical link": "Link from S7-3 to S11" "physical link": "Link from S7-3 to S11"
}, },
"link-id": "teNodeId/10.0.0.1/teLinkId/4", "link-id": "teNodeId/192.0.2.1/teLinkId/4",
"source": { "source": {
"source-node": "10.0.0.1", "source-node": "192.0.2.1",
"source-tp": 4 "source-tp": "4"
}, },
"// __NOT-PRESENT__ destination": "inter-domain link", "// not-present destination": "inter-domain link",
"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",
"// __NOT-PRESENT__ external-domain": "The plug-id i\ "// not-present external-domain": "The plug-id is us\
\s used instead of this container", \ed instead of this container",
"// __NOT-PRESENT__ is-abstract": "The access link i\ "// not-present is-abstract": "The access link is no\
\s not abstract", \t abstract",
"interface-switching-capability": [ "interface-switching-capability": [
{ {
"// __COMMENT__ encoding and switching-capabilit\ "// comment encoding and switching-capability": \
\y": "OTN (ODU)", \"OTN (ODU)",
"switching-capability": "ietf-te-types:switching\ "switching-capability": "ietf-te-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,
"te-bandwidth": { "te-bandwidth": {
"ietf-otn-topology:odu-type": "ietf-layer1\ "ietf-otn-topology:otn": {
\-types:ODU4" "odu-type": "ietf-layer1-types:ODU2"
}
} }
} }
] ]
} }
], ],
"// __COMMENT__ label-restrictions": "Outside the sc\ "// comment label-restrictions": "Outside the scope \
\ope of this JSON example", \of this JSON example",
"max-link-bandwidth": { "max-link-bandwidth": {
"te-bandwidth": { "te-bandwidth": {
"ietf-otn-topology:odulist": [ "ietf-otn-topology:odulist": [
{ {
"odu-type": "ietf-layer1-types:ODU4", "odu-type": "ietf-layer1-types:ODU4",
"number": 1 "number": 1
}, },
{ {
"odu-type": "ietf-layer1-types:ODU2", "odu-type": "ietf-layer1-types:ODU2",
"number": 10 "number": 10
skipping to change at page 68, line 46 skipping to change at page 70, line 35
} }
] ]
} }
} }
], ],
"ietf-otn-topology:tsg": "ietf-layer1-types:tsg-1.25\ "ietf-otn-topology:tsg": "ietf-layer1-types:tsg-1.25\
\G", \G",
"admin-status": "up" "admin-status": "up"
}, },
"oper-status": "up", "oper-status": "up",
"// __NOT-PRESENT__ is-transitional": "It is not a tra\ "// not-present is-transitional": "It is not a transit\
\nsitional link" \ional link"
} }
}, },
{ {
"// __DESCRIPTION__:__LINK__": { "// link description": {
"name": "Inter-domain Link from AN1-5", "name": "Inter-domain Link from AN1-5",
"type": "OTU4 inter-domain link", "type": "OTU4 inter-domain link",
"physical link": "Link from S8-4 to S12" "physical link": "Link from S8-4 to S12"
}, },
"link-id": "teNodeId/10.0.0.1/teLinkId/5", "link-id": "teNodeId/192.0.2.1/teLinkId/5",
"source": { "source": {
"source-node": "10.0.0.1", "source-node": "192.0.2.1",
"source-tp": 5 "source-tp": "5"
}, },
"// __NOT-PRESENT__ destination": "inter-domain link", "// not-present destination": "inter-domain link",
"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",
"// __NOT-PRESENT__ external-domain": "The plug-id i\ "// not-present external-domain": "The plug-id is us\
\s used instead of this container", \ed instead of this container",
"// __NOT-PRESENT__ is-abstract": "The access link i\ "// not-present is-abstract": "The access link is no\
\s not abstract", \t abstract",
"interface-switching-capability": [ "interface-switching-capability": [
{ {
"// __COMMENT__ encoding and switching-capabilit\ "// comment encoding and switching-capability": \
\y": "OTN (ODU)", \"OTN (ODU)",
"switching-capability": "ietf-te-types:switching\ "switching-capability": "ietf-te-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,
"te-bandwidth": { "te-bandwidth": {
"ietf-otn-topology:odu-type": "ietf-layer1\ "ietf-otn-topology:otn": {
\-types:ODU4" "odu-type": "ietf-layer1-types:ODU4"
}
} }
} }
] ]
} }
], ],
"// __COMMENT__ label-restrictions": "Outside the sc\ "// comment label-restrictions": "Outside the scope \
\ope of this JSON example", \of this JSON example",
"max-link-bandwidth": { "max-link-bandwidth": {
"te-bandwidth": { "te-bandwidth": {
"ietf-otn-topology:odulist": [ "ietf-otn-topology:odulist": [
{ {
"odu-type": "ietf-layer1-types:ODU4", "odu-type": "ietf-layer1-types:ODU4",
"number": 1 "number": 1
}, },
{ {
"odu-type": "ietf-layer1-types:ODU2", "odu-type": "ietf-layer1-types:ODU2",
"number": 10 "number": 10
skipping to change at page 71, line 7 skipping to change at page 72, line 44
} }
] ]
} }
} }
], ],
"ietf-otn-topology:tsg": "ietf-layer1-types:tsg-1.25\ "ietf-otn-topology:tsg": "ietf-layer1-types:tsg-1.25\
\G", \G",
"admin-status": "up" "admin-status": "up"
}, },
"oper-status": "up", "oper-status": "up",
"// __NOT-PRESENT__ is-transitional": "It is not a tra\ "// not-present is-transitional": "It is not a transit\
\nsitional link" \ional link"
} }
}, },
{ {
"// __DESCRIPTION__:__LINK__": { "// link description": {
"name": "Inter-domain Link from AN1-6", "name": "Inter-domain Link from AN1-6",
"type": "OTU4 inter-domain link", "type": "OTU4 inter-domain link",
"physical link": "Link from S8-5 to S32" "physical link": "Link from S8-5 to S32"
}, },
"link-id": "teNodeId/10.0.0.1/teLinkId/6", "link-id": "teNodeId/192.0.2.1/teLinkId/6",
"source": { "source": {
"source-node": "10.0.0.1", "source-node": "192.0.2.1",
"source-tp": 6 "source-tp": "6"
}, },
"// __NOT-PRESENT__ destination": "inter-domain link", "// not-present destination": "inter-domain link",
"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",
"// __NOT-PRESENT__ external-domain": "The plug-id i\ "// not-present external-domain": "The plug-id is us\
\s used instead of this container", \ed instead of this container",
"// __NOT-PRESENT__ is-abstract": "The access link i\ "// not-present is-abstract": "The access link is no\
\s not abstract", \t abstract",
"interface-switching-capability": [ "interface-switching-capability": [
{ {
"// __COMMENT__ encoding and switching-capabilit\ "// comment encoding and switching-capability": \
\y": "OTN (ODU)", \"OTN (ODU)",
"switching-capability": "ietf-te-types:switching\ "switching-capability": "ietf-te-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,
"te-bandwidth": { "te-bandwidth": {
"ietf-otn-topology:odu-type": "ietf-layer1\ "ietf-otn-topology:otn": {
\-types:ODU4" "odu-type": "ietf-layer1-types:ODU4"
}
} }
} }
] ]
} }
], ],
"// __COMMENT__ label-restrictions": "Outside the sc\ "// comment label-restrictions": "Outside the scope \
\ope of this JSON example", \of this JSON example",
"max-link-bandwidth": { "max-link-bandwidth": {
"te-bandwidth": { "te-bandwidth": {
"ietf-otn-topology:odulist": [ "ietf-otn-topology:odulist": [
{ {
"odu-type": "ietf-layer1-types:ODU4", "odu-type": "ietf-layer1-types:ODU4",
"number": 1 "number": 1
}, },
{ {
"odu-type": "ietf-layer1-types:ODU2", "odu-type": "ietf-layer1-types:ODU2",
"number": 10 "number": 10
skipping to change at page 73, line 14 skipping to change at page 75, line 4
"odu-type": "ietf-layer1-types:ODU0", "odu-type": "ietf-layer1-types:ODU0",
"number": 80 "number": 80
} }
] ]
} }
} }
], ],
"ietf-otn-topology:tsg": "ietf-layer1-types:tsg-1.25\ "ietf-otn-topology:tsg": "ietf-layer1-types:tsg-1.25\
\G", \G",
"admin-status": "up" "admin-status": "up"
}, },
"oper-status": "up", "oper-status": "up",
"// __NOT-PRESENT__ is-transitional": "It is not a tra\ "// not-present is-transitional": "It is not a transit\
\nsitional link" \ional link"
} }
}, },
{ {
"// __DESCRIPTION__:__LINK__": { "// link description": {
"name": "Inter-domain Link from AN1-7", "name": "Inter-domain Link from AN1-7",
"type": "OTU4 inter-domain link", "type": "OTU4 inter-domain link",
"physical link": "Link from S2-3 to S31" "physical link": "Link from S2-3 to S31"
}, },
"link-id": "teNodeId/10.0.0.1teLinkId/7", "link-id": "teNodeId/192.0.2.1teLinkId/7",
"source": { "source": {
"source-node": "10.0.0.1", "source-node": "192.0.2.1",
"source-tp": 7 "source-tp": "7"
}, },
"// __NOT-PRESENT__ destination": "inter-domain link", "// not-present destination": "inter-domain link",
"ietf-te-topology:te": { "ietf-te-topology:te": {
"te-link-attributes": { "te-link-attributes": {
"name": "Inter-domain Link from AN1-7", "name": "Inter-domain Link from AN1-7",
"// __NOT-PRESENT__ external-domain": "The plug-id i\ "// not-present external-domain": "The plug-id is us\
\s used instead of this container", \ed instead of this container",
"// __NOT-PRESENT__ is-abstract": "The access link i\ "// not-present is-abstract": "The access link is no\
\s not abstract", \t abstract",
"interface-switching-capability": [ "interface-switching-capability": [
{ {
"// __COMMENT__ encoding and switching-capabilit\ "// comment encoding and switching-capability": \
\y": "OTN (ODU)", \"OTN (ODU)",
"switching-capability": "ietf-te-types:switching\ "switching-capability": "ietf-te-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,
"te-bandwidth": { "te-bandwidth": {
"ietf-otn-topology:odu-type": "ietf-layer1\ "ietf-otn-topology:otn": {
\-types:ODU4" "odu-type": "ietf-layer1-types:ODU4"
}
} }
} }
] ]
} }
], ],
"// __COMMENT__ label-restrictions": "Outside the sc\ "// comment label-restrictions": "Outside the scope \
\ope of this JSON example", \of this JSON example",
"max-link-bandwidth": { "max-link-bandwidth": {
"te-bandwidth": { "te-bandwidth": {
"ietf-otn-topology:odulist": [ "ietf-otn-topology:odulist": [
{ {
"odu-type": "ietf-layer1-types:ODU4", "odu-type": "ietf-layer1-types:ODU4",
"number": 1 "number": 1
}, },
{ {
"odu-type": "ietf-layer1-types:ODU2", "odu-type": "ietf-layer1-types:ODU2",
"number": 10 "number": 10
skipping to change at page 75, line 25 skipping to change at page 77, line 16
} }
] ]
} }
} }
], ],
"ietf-otn-topology:tsg": "ietf-layer1-types:tsg-1.25\ "ietf-otn-topology:tsg": "ietf-layer1-types:tsg-1.25\
\G", \G",
"admin-status": "up" "admin-status": "up"
}, },
"oper-status": "up", "oper-status": "up",
"// __NOT-PRESENT__ is-transitional": "It is not a tra\ "// not-present is-transitional": "It is not a transit\
\nsitional link" \ional link"
} }
} }
] ]
} }
] ]
} }
} }
B.1.2. JSON Code: mpi1-eth-topology.json B.1.2. JSON Code: mpi1-eth-topology.json
This is the JSON code reporting the ETH Topology @ MPI1: This is the JSON code reporting the ETH Topology @ MPI1:
========== NOTE: '\\' line wrapping per BCP XXX (RFC XXXX) ========== =============== NOTE: '\\' line wrapping per RFC 8792 ===============
{ {
"// __LAST_UPDATE__": "November 19, 2019", "// header": {
"// __TITLE__": "ETH Black Topology @ MPI1", "last-update": "March 15, 2022",
"// __REFERENCE_DRAFTS__": { "title": "ETH Black Topology @ MPI1",
"ietf-routing-types@2017-12-04": "rfc8294", "reference-drafts": {
"ietf-te-types@2019-07-05": "draft-ietf-teas-yang-te-types-10", "ietf-routing-types@2017-12-04": "rfc8294",
"ietf-network@2018-02-26": "rfc8345", "ietf-te-types@2020-06-10": "rfc8776",
"ietf-network-topology@2018-02-26": "rfc8345", "ietf-network@2018-02-26": "rfc8345",
"ietf-te-topology@2019-02-07": "draft-ietf-teas-yang-te-topo-22", "ietf-network-topology@2018-02-26": "rfc8345",
"ietf-eth-tran-types@2019-03-27": "draft-ietf-ccamp-client-signa\ "ietf-te-topology@2020-08-06": "rfc8795",
\l-yang-00", "ietf-eth-tran-types@2021-07-07": "draft-ietf-ccamp-client-sig\
"ietf-eth-te-topology@2019-11-18": "draft-zheng-ccamp-client-top\ \nal-yang-05",
\o-yang-08" "ietf-eth-te-topology@2019-11-18": "draft-ietf-ccamp-eth-clien\
\t-te-topo-yang-00"
}
}, },
"// __MISSING_ATTRIBUTES__": true,
"ietf-network:networks": { "ietf-network:networks": {
"network": [ "network": [
{ {
"network-id": "providerId/201/clientId/300/topologyId/eth-bl\ "network-id": "providerId/201/clientId/300/topologyId/eth-bl\
\ack-topology", \ack-topology",
"network-types": { "network-types": {
"ietf-te-topology:te-topology": { "ietf-te-topology:te-topology": {
"ietf-eth-te-topology:eth-tran-topology": {} "ietf-eth-te-topology:eth-tran-topology": {}
} }
}, },
"ietf-te-topology:te-topology-identifier": { "ietf-te-topology:te-topology-identifier": {
"provider-id": 201, "provider-id": 201,
"client-id": 300, "client-id": 300,
"topology-id": "eth-black-topology" "topology-id": "eth-black-topology"
}, },
"// __COMMENT__ ietf-te-topology:te": "presence container re\ "// comment ietf-te-topology:te": "presence container requir\
\quires: provider-id, client-id and te-topology-id", \es: provider-id, client-id and te-topology-id",
"ietf-te-topology:te": { "ietf-te-topology:te": {
"name": "ETH Black Topology @ MPI1" "name": "ETH Black Topology @ MPI1"
}, },
"ietf-network:node": [ "ietf-network:node": [
{ {
"// __NODE__:__DESCRIPTION__": { "// node description": {
"name": "AN1", "name": "AN1",
"identifier": "10.0.0.1", "identifier": "192.0.2.1",
"type": "Abstract Node", "type": "Abstract Node",
"physical node(s)": "The whole network domain 1" "physical node(s)": "The whole network domain 1"
}, },
"node-id": "10.0.0.1", "node-id": "192.0.2.1",
"ietf-te-topology:te-node-id": "10.0.0.1", "ietf-te-topology:te-node-id": "192.0.2.1",
"// __COMMENT__ supporting-node": "Not used because topo\ "// comment supporting-node": "Not used because topology\
\logy hierarchy is outside the scope of this JSON example", \ hierarchy is outside the scope of this JSON example",
"ietf-te-topology:te": { "ietf-te-topology:te": {
"te-node-attributes": { "te-node-attributes": {
"name": "AN11", "name": "AN11",
"is-abstract": "", "is-abstract": [
null
],
"admin-status": "up" "admin-status": "up"
}, },
"oper-status": "up", "oper-status": "up",
"// __NOT-PRESENT__ tunnel-termination-point": "ETH Ac\ "// not-present tunnel-termination-point": "ETH Access\
\cess Links only (no ETH TE switching)" \ Links only (no ETH TE switching)"
}, },
"ietf-network-topology:termination-point": [ "ietf-network-topology:termination-point": [
{ {
"// __DESCRIPTION__:__LTP__": { "// ltp description": {
"name": "AN1-1 LTP", "name": "AN1-1 LTP",
"link type(s)": "Multi-function (OTU2, STM-64 and \ "link type(s)": "Multi-function (OTU2, STM-64 and \
\10GE)", \10GE)",
"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",
"// __NOT-PRESENT__ interface-switching-capability\ "// not-present interface-switching-capability": "\
\": "ETH Access Link only (no ETH TE switching)", \ETH Access Link only (no ETH TE switching)",
"// __COMMENT__ inter-domain-plug-id": "Use of plu\ "// comment inter-domain-plug-id": "Use of plug-id\
\g-id for access Link is outside the scope of this document", \ for access Link is outside the scope of this document",
"// __COMMENT__ inter-layer-lock-id": "AN1-1 ILL-I\ "// comment inter-layer-lock-id": "AN1-1 ILL-ID (1\
\D (1)", \)",
"inter-layer-lock-id": [ "inter-layer-lock-id": [
1 1
], ],
"admin-status": "up", "admin-status": "up",
"oper-status": "up" "oper-status": "up"
}, },
"// __COMMENT__ ingress-bandwidth-profile": "Outside\ "// comment ietf-eth-te-topology:ingress-bandwidth-p\
\ the scope of this JSON example", \rofile": "Outside the scope of this JSON example",
"ietf-eth-te-topology:eth-svc": { "ietf-eth-te-topology:eth-svc": {
"client-facing": true, "client-facing": true,
"supported-classification": { "supported-classification": {
"port-classification": true, "port-classification": true,
"vlan-classification": { "vlan-classification": {
"vlan-tag-classification": true, "vlan-tag-classification": true,
"outer-tag": { "outer-tag": {
"supported-tag-types": [ "supported-tag-types": [
"ietf-eth-tran-types:classify-c-vlan" "ietf-eth-tran-types:classify-c-vlan"
], ],
"vlan-range": "1-4094" "vlan-range": "1-4094"
} }
} }
}, },
"supported-vlan-operations": { "supported-vlan-operations": {
"transparent-vlan-operations": true "transparent-vlan-operations": true
} }
} }
}, },
{ {
"// __DESCRIPTION__:__LTP__": { "// ltp description": {
"name": "AN1-8 LTP", "name": "AN1-8 LTP",
"link type(s)": "10GE", "link type(s)": "10GE",
"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": "8", "tp-id": "8",
"ietf-te-topology:te-tp-id": 8, "ietf-te-topology:te-tp-id": 8,
"ietf-te-topology:te": { "ietf-te-topology:te": {
"name": "AN1-8 LTP", "name": "AN1-8 LTP",
"// __COMMENT__ inter-layer-lock-id": "AN1-8 ILL-I\ "// comment inter-layer-lock-id": "AN1-8 ILL-ID (8\
\D (8)", \)",
"// __NOT-PRESENT__ interface-switching-capability\ "// not-present interface-switching-capability": "\
\": "ETH Access Link only (no ETH TE switching)", \ETH Access Link only (no ETH TE switching)",
"// __COMMENT__ inter-domain-plug-id": "Use of plu\ "// comment inter-domain-plug-id": "Use of plug-id\
\g-id for access Link is outside the scope of this document", \ for access Link is outside the scope of this document",
"inter-layer-lock-id": [ "inter-layer-lock-id": [
8 8
], ],
"admin-status": "up", "admin-status": "up",
"oper-status": "up" "oper-status": "up"
}, },
"// __COMMENT__ ingress-bandwidth-profile": "Outside\ "// comment ingress-bandwidth-profile": "Outside the\
\ the scope of this JSON example", \ scope of this JSON example",
"ietf-eth-te-topology:eth-svc": { "ietf-eth-te-topology:eth-svc": {
"client-facing": true, "client-facing": true,
"supported-classification": { "supported-classification": {
"port-classification": true, "port-classification": true,
"vlan-classification": { "vlan-classification": {
"vlan-tag-classification": true, "vlan-tag-classification": true,
"outer-tag": { "outer-tag": {
"supported-tag-types": [ "supported-tag-types": [
"ietf-eth-tran-types:classify-c-vlan" "ietf-eth-tran-types:classify-c-vlan"
], ],
skipping to change at page 79, line 5 skipping to change at page 80, line 48
"supported-vlan-operations": { "supported-vlan-operations": {
"transparent-vlan-operations": true "transparent-vlan-operations": true
} }
} }
} }
] ]
} }
], ],
"ietf-network-topology:link": [ "ietf-network-topology:link": [
{ {
"// __DESCRIPTION__:__LINK__": { "// link description": {
"name": "Access Link from AN1-1", "name": "Access Link from AN1-1",
"type": "Multi-function access link (OTU2, STM-64 and \ "type": "Multi-function access link (OTU2, STM-64 and \
\10GE)", \10GE)",
"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/192.0.2.1/teLinkId/1",
"source": { "source": {
"source-node": "10.0.0.1", "source-node": "192.0.2.1",
"source-tp": 1 "source-tp": "1"
}, },
"// __NOT-PRESENT__ destination": "access link", "// not-present destination": "access link",
"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",
"// __NOT-PRESENT__ external-domain": "The plug-id i\ "// not-present external-domain": "The plug-id is us\
\s used instead of this container", \ed instead of this container",
"// __NOT-PRESENT__ is-abstract": "The access link i\ "// not-present is-abstract": "The access link is no\
\s not abstract", \t abstract",
"// __NOT-PRESENT__ interface-switching-capability":\ "// not-present interface-switching-capability": "ET\
\ "ETH Access Link only (no ETH TE switching)", \H Access Link only (no ETH TE switching)",
"// __NOT-PRESENT__ label-restrictions": "ETH Access\ "// not-present label-restrictions": "ETH Access Lin\
\ Link only (no ETH TE switching)", \k only (no ETH TE switching)",
"// __NOT-PRESENT__ max-link-bandwidth": "ETH Access\ "// not-present max-link-bandwidth": "ETH Access Lin\
\ Link only (no ETH TE switching)", \k only (no ETH TE switching)",
"// __NOT-PRESENT__ max-resv-link-bandwidth": "ETH A\ "// not-present max-resv-link-bandwidth": "ETH Acces\
\ccess Link only (no ETH TE switching)", \s Link only (no ETH TE switching)",
"// __NOT-PRESENT__ unreserved-bandwidth": "ETH Acce\ "// not-present unreserved-bandwidth": "ETH Access L\
\ss Link only (no ETH TE switching)", \ink only (no ETH TE switching)",
"admin-status": "up" "admin-status": "up"
}, },
"oper-status": "up", "oper-status": "up",
"// __NOT-PRESENT__ is-transitional": "It is not a tra\ "// not-present is-transitional": "It is not a transit\
\nsitional link" \ional link"
} }
}, },
{ {
"// __DESCRIPTION__:__LINK__": { "// link description": {
"name": "Access Link from AN1-8", "name": "Access Link from AN1-8",
"type": "10GE access link", "type": "10GE 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/8", "link-id": "teNodeId/192.0.2.1/teLinkId/8",
"source": { "source": {
"source-node": "10.0.0.1", "source-node": "192.0.2.1",
"source-tp": 8 "source-tp": "8"
}, },
"// __NOT-PRESENT__ destination": "access link", "// not-present destination": "access link",
"ietf-te-topology:te": { "ietf-te-topology:te": {
"te-link-attributes": { "te-link-attributes": {
"name": "Access Link from AN1-8", "name": "Access Link from AN1-8",
"// __NOT-PRESENT__ external-domain": "The plug-id i\ "// not-present external-domain": "The plug-id is us\
\s used instead of this container", \ed instead of this container",
"// __NOT-PRESENT__ is-abstract": "The access link i\ "// not-present is-abstract": "The access link is no\
\s not abstract", \t abstract",
"// __NOT-PRESENT__ interface-switching-capability":\ "// not-present interface-switching-capability": "ET\
\ "ETH Access Link only (no ETH TE switching)", \H Access Link only (no ETH TE switching)",
"// __NOT-PRESENT__ label-restrictions": "ETH Access\ "// not-present label-restrictions": "ETH Access Lin\
\ Link only (no ETH TE switching)", \k only (no ETH TE switching)",
"// __NOT-PRESENT__ max-link-bandwidth": "ETH Access\ "// not-present max-link-bandwidth": "ETH Access Lin\
\ Link only (no ETH TE switching)", \k only (no ETH TE switching)",
"// __NOT-PRESENT__ max-resv-link-bandwidth": "ETH A\ "// not-present max-resv-link-bandwidth": "ETH Acces\
\ccess Link only (no ETH TE switching)", \s Link only (no ETH TE switching)",
"// __NOT-PRESENT__ unreserved-bandwidth": "ETH Acce\ "// not-present unreserved-bandwidth": "ETH Access L\
\ss Link only (no ETH TE switching)", \ink only (no ETH TE switching)",
"admin-status": "up" "admin-status": "up"
}, },
"oper-status": "up", "oper-status": "up",
"// __NOT-PRESENT__ is-transitional": "It is not a tra\ "// not-present is-transitional": "It is not a transit\
\nsitional link" \ional 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 @ MPI1: configuration @ MPI1:
========== NOTE: '\\' line wrapping per BCP XXX (RFC XXXX) ========== =============== NOTE: '\\' line wrapping per RFC 8792 ===============
{ {
"// __LAST_UPDATE__": "October 23, 2019", "// header": {
"// __TITLE__": "ODU2 Service Configuration @ MPI1", "// last-update": "March 15, 2022",
"// __REFERENCE_DRAFTS__": { "// title": "ODU2 Service Configuration @ MPI1",
"reference-drafts": {
"ietf-routing-types@2017-12-04": "rfc8294", "ietf-routing-types@2017-12-04": "rfc8294",
"ietf-te-types@2019-07-05": "draft-ietf-teas-yang-te-types-10", "ietf-te-types@2020-06-10": "rfc8776",
"ietf-layer1-types@2019-09-09": "draft-ietf-ccamp-layer1-types-0\ "ietf-layer1-types@2021-02-19": "draft-ietf-ccamp-layer1-types-1\
\2", \0",
"ietf-te@2019-04-09": "draft-ietf-teas-yang-te-21", "ietf-te@2021-02-20": "draft-ietf-teas-yang-te-26",
"ietf-otn-tunnel@2019-10-23": "draft-ietf-ccamp-otn-tunnel-model\ "ietf-otn-tunnel@2021-06-25": "draft-ietf-ccamp-otn-tunnel-model\
\-08" \-14"
}
}, },
"// __MISSING_ATTRIBUTES__": true, "// missing-attributes": true,
"// __RESTCONF_OPERATION__": { "// restconf_operation": {
"operation": "POST", "operation": "POST",
"url": "http://{{PNC1-ADDR}}/restconf/data/ietf-te:te/tunnels" "url": "http://{{PNC1-ADDR}}/restconf/data/ietf-te:te/tunnels"
}, },
"ietf-te:te": { "ietf-te:te": {
"tunnels": { "tunnels": {
"tunnel": [ "tunnel": [
{ {
"name": "mpi1-odu2-service", "name": "mpi1-odu2-service",
"// __COMMENT__ identifier": "ODU2-SERVICE-TUNNEL-ID @ MPI\ "// comment identifier": "ODU2-SERVICE-TUNNEL-ID @ MPI1",
\1",
"identifier": 1, "identifier": 1,
"description": "ODU2 Service implemented by ODU2 OTN Tunne\ "description": "ODU2 Service implemented by ODU2 OTN Tunne\
\l Segment @ MPI1", \l Segment @ MPI1",
"// __COMMENT__ encoding and switching-type": "OTN (ODU)", "// comment encoding and switching-type": "OTN (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",
"// __NOT-PRESENT__ source": "Transit tunnel segment", "// not-present source": "Transit tunnel segment",
"// __NOT-PRESENT__ src-tp-id": "Transit tunnel segment", "// not-present src-tunnel-tp-id": "Transit tunnel segment\
"// __NOT-PRESENT__ destination": "Transit tunnel segment", \",
"// __NOT-PRESENT__ dst-tp-id": "Transit tunnel segment", "// not-present destination": "Transit tunnel segment",
"// not-present dst-tunnel-tp-id": "Transit tunnel segment\
\",
"bidirectional": true, "bidirectional": true,
"// __ DEFAULT __ protection": { "// default protection": {
"// __ DEFAULT __ enable": false "// default enable": false
}, },
"// __ DEFAULT __ restoration": { "// default restoration": {
"// __ DEFAULT __ enable": false "// default enable": false
}, },
"// __COMMENT__ te-topology-identifier": "ODU Black Topolo\ "// comment te-topology-identifier": "ODU Black Topology @\
\gy @ MPI1", \ MPI1",
"te-topology-identifier": { "te-topology-identifier": {
"provider-id": 201, "provider-id": 201,
"client-id": 300, "client-id": 300,
"topology-id": "otn-black-topology" "topology-id": "otn-black-topology"
}, },
"te-bandwidth": { "te-bandwidth": {
"ietf-otn-tunnel:odu-type": "ietf-layer1-types:ODU2" "ietf-otn-tunnel:otn": {
"ietf-otn-tunnel:odu-type": "ietf-layer1-types:ODU2"
}
}, },
"provisioning-state": "ietf-te-types:tunnel-state-up", "admin-state": "ietf-te-types:tunnel-admin-state-up",
"p2p-primary-paths": { "primary-paths": {
"p2p-primary-path": [ "primary-path": [
{ {
"name": "mpi1-odu2-service-primary-path", "name": "mpi1-odu2-service-primary-path",
"// __NOT-PRESENT__ te-bandwidth": "The tunnel bandw\ "// not-present te-bandwidth": "The tunnel bandwidth\
\idth is used",
\ is used",
"explicit-route-objects-always": { "explicit-route-objects-always": {
"route-object-include-exclude": [ "route-object-include-exclude": [
{ {
"// __COMMENT__": "Tunnel hand-off OTU2 ingres\ "// comment": "Tunnel hand-off OTU2 ingress in\
\s interface (S3-1 -> AN1-1)", \terface (S3-1 -> AN1-1)",
"index": 1, "index": 1,
"explicit-route-usage": "ietf-te-types:route-i\ "explicit-route-usage": "ietf-te-types:route-i\
\nclude-object", \nclude-object",
"unnumbered-link-hop": { "unnumbered-link-hop": {
"// __COMMENT__ node-id": "AN1 NODE-ID", "// comment node-id": "AN1 NODE-ID",
"node-id": "10.0.0.1", "node-id": "192.0.2.1",
"// __COMMENT__ link-tp-id": "AN1-1 LTP", "// comment link-tp-id": "AN1-1 LTP",
"link-tp-id": 1, "link-tp-id": 1,
"// __DEFAULT__ hop-type": "strict", "// default hop-type": "strict",
"// __DEFAULT__ direction": "outgoing" "// default direction": "outgoing"
} }
}, },
{ {
"// __COMMENT__": "Tunnel hand-off ODU2 ingres\ "// comment": "Tunnel hand-off ODU2 ingress la\
\s label (ODU2 over OTU2) at S3-1 (AN1-1)", \bel (ODU2 over OTU2) at S3-1 (AN1-1)",
"index": 2, "index": 2,
"explicit-route-usage": "ietf-te-types:route-i\ "explicit-route-usage": "ietf-te-types:route-i\
\nclude-object", \nclude-object",
"label-hop": { "label-hop": {
"te-label": { "te-label": {
"ietf-otn-tunnel:tpn": 1, "ietf-otn-tunnel:otn-tpn": 1,
"// __NOT-PRESENT__ ietf-otn-tunnel:tsg": \ "// not-present ietf-otn-tunnel:tsg": "Not\
\ applicable for ODUk over OTUk",
"// not-present ietf-otn-tunnel:ts-list": \
\"Not applicable for ODUk over OTUk", \"Not applicable for ODUk over OTUk",
"// __NOT-PRESENT__ ietf-otn-tunnel:ts-lis\ "// default direction": "forward"
\t": "Not applicable for ODUk over OTUk",
"// __DEFAULT__ direction": "forward"
} }
} }
}, },
{ {
"// __COMMENT__": "Tunnel hand-off OTU4 egress\ "// comment": "Tunnel hand-off OTU4 egress int\
\ interface (S2-3 -> AN1-7)", \erface (S2-3 -> AN1-7)",
"index": 3, "index": 3,
"explicit-route-usage": "ietf-te-types:route-i\ "explicit-route-usage": "ietf-te-types:route-i\
\nclude-object", \nclude-object",
"unnumbered-link-hop": { "unnumbered-link-hop": {
"// __COMMENT__ node-id": "AN1 Node", "// comment node-id": "AN1 Node",
"node-id": "10.0.0.1", "node-id": "192.0.2.1",
"// __COMMENT__ link-tp-id": "AN1-7 LTP", "// comment link-tp-id": "AN1-7 LTP",
"link-tp-id": 7, "link-tp-id": 7,
"// __DEFAULT__ hop-type": "strict", "// default hop-type": "strict",
"// __DEFAULT__ direction": "outgoing" "// default direction": "outgoing"
} }
}, },
{ {
"// __COMMENT__": "Tunnel hand-off ODU2 egress\ "// comment": "Tunnel hand-off ODU2 egress lab\
\ label (ODU2 over OTU4) at S2-3 (AN1-7)", \el (ODU2 over OTU4) at S2-3 (AN1-7)",
"index": 4, "index": 4,
"explicit-route-usage": "ietf-te-types:route-i\ "explicit-route-usage": "ietf-te-types:route-i\
\nclude-object", \nclude-object",
"label-hop": { "label-hop": {
"te-label": { "te-label": {
"ietf-otn-tunnel:tpn": 1, "ietf-otn-tunnel:otn-tpn": 1,
"ietf-otn-tunnel:tsg": "ietf-layer1-types:\ "ietf-otn-tunnel:tsg": "ietf-layer1-types:\
\tsg-1.25G", \tsg-1.25G",
"ietf-otn-tunnel:ts-list": "1-8", "ietf-otn-tunnel:ts-list": "1-8",
"// __DEFAULT__ direction": "forward" "// default direction": "forward"
} }
} }
} }
] ]
} }
} }
] ]
} }
} }
] ]
} }
} }
} }
B.2.2. JSON Code: mpi1-odu2-tunnel-config.json B.2.2. JSON Code: mpi1-odu2-tunnel-config.json
This is the JSON code reporting the ODU2 head tunnel segment This is the JSON code reporting the ODU2 head tunnel segment
configuration @ MPI1: configuration @ MPI1:
========== NOTE: '\\' line wrapping per BCP XXX (RFC XXXX) ========== =============== NOTE: '\\' line wrapping per RFC 8792 ===============
{ {
"// __LAST_UPDATE__": "October 23, 2019", "// header": {
"// __TITLE__": "ODU2 Tunnel Configuration @ MPI1", "last-update": "March 15, 2022",
"// __REFERENCE_DRAFTS__": { "title": "ODU2 Tunnel Configuration @ MPI1",
"ietf-routing-types@2017-12-04": "rfc8294", "reference-drafts": {
"ietf-te-types@2019-07-05": "draft-ietf-teas-yang-te-types-10", "ietf-routing-types@2017-12-04": "rfc8294",
"ietf-layer1-types@2019-09-09": "draft-ietf-ccamp-layer1-types-0\ "ietf-te-types@2020-06-10": "rfc8776",
\2", "ietf-layer1-types@2021-02-19": "draft-ietf-ccamp-layer1-types\
"ietf-te@2019-04-09": "draft-ietf-teas-yang-te-21", \-10",
"ietf-otn-tunnel@2019-10-23": "draft-ietf-ccamp-otn-tunnel-model\ "ietf-te@2021-02-20": "draft-ietf-teas-yang-te-26",
\-08" "ietf-otn-tunnel@2021-06-25": "draft-ietf-ccamp-otn-tunnel-mod\
\el-14"
}, },
"// __MISSING_ATTRIBUTES__": true, "// missing-attributes": true,
"// __RESTCONF_OPERATION__": { "// restconf-operation": {
"operation": "POST", "operation": "POST",
"url": "http://{{PNC1-ADDR}}/restconf/data/ietf-te:te/tunnels" "url": "http://{{PNC1-ADDR}}/restconf/data/ietf-te:te/tunnels"
}
}, },
"ietf-te:te": { "ietf-te:te": {
"tunnels": { "tunnels": {
"tunnel": [ "tunnel": [
{ {
"name": "mpi1-odu2-tunnel", "name": "mpi1-odu2-tunnel",
"// __COMMENT__ identifier": "ODU2-TUNNEL-ID @ MPI1", "// comment identifier": "ODU2-TUNNEL-ID @ MPI1",
"identifier": 2, "identifier": 2,
"description": "TNBI Example for an ODU2 Head Tunnel Segme\ "description": "TNBI Example for an ODU2 Head Tunnel Segme\
\nt @ MPI1", \nt @ MPI1",
"// __COMMENT__ encoding and switching-type": "OTN (ODU)", "// comment encoding and switching-type": "OTN (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",
"// __COMMENT__ source": "AN1 Node-ID", "// comment source": "AN1 Node-ID",
"source": "10.0.0.1", "source": "192.0.2.1",
"// __COMMENT__ src-tp-id": "AN1-1 TTP-ID (1 -> 0x01 -> '0\ "// comment src-tunnel-tp-id": "AN1-1 TTP-ID (1 -> 0x01 ->\
\1')", \ 'AQ==' in base64)",
"src-tp-id": "01", "src-tunnel-tp-id": "AQ==",
"// __NOT-PRESENT__ destination": "Head tunnel segment", "// not-present destination": "Head tunnel segment",
"// __NOT-PRESENT__ dst-tp-id": "Head tunnel segment", "// not-present dst-tunnel-tp-id": "Head tunnel segment",
"bidirectional": true, "bidirectional": true,
"// __ DEFAULT __ protection": { "// default protection": {
"// __ DEFAULT __ enable": false "// default enable": false
}, },
"// __ DEFAULT __ restoration": { "// default restoration": {
"// __ DEFAULT __ enable": false "// default enable": false
}, },
"// __COMMENT__ te-topology-identifier": "ODU Black Topolo\ "// comment te-topology-identifier": "ODU Black Topology @\
\gy @ MPI1", \ MPI1",
"te-topology-identifier": { "te-topology-identifier": {
"provider-id": 201, "provider-id": 201,
"client-id": 300, "client-id": 300,
"topology-id": "otn-black-topology" "topology-id": "otn-black-topology"
}, },
"te-bandwidth": { "te-bandwidth": {
"ietf-otn-tunnel:odu-type": "ietf-layer1-types:ODU2" "ietf-otn-tunnel:otn": {
"ietf-otn-tunnel:odu-type": "ietf-layer1-types:ODU2"
}
}, },
"provisioning-state": "ietf-te-types:tunnel-state-down", "admin-state": "ietf-te:tunnel-admin-auto",
"p2p-primary-paths": { "primary-paths": {
"p2p-primary-path": [ "primary-path": [
{ {
"name": "mpi1-odu2-tunnel-primary-path", "name": "mpi1-odu2-tunnel-primary-path",
"// __NOT-PRESENT__ te-bandwidth": "The tunnel bandw\ "// not-present te-bandwidth": "The tunnel bandwidth\
\ is used",
\idth is used",
"explicit-route-objects-always": { "explicit-route-objects-always": {
"route-object-include-exclude": [ "route-object-include-exclude": [
{ {
"// __COMMENT__": "Tunnel hand-off OTU4 egress\ "// comment": "Tunnel hand-off OTU4 egress int\
\ interface (AN1-7 LTP)", \erface (AN1-7 LTP)",
"index": 1, "index": 1,
"explicit-route-usage": "ietf-te-types:route-i\ "explicit-route-usage": "ietf-te-types:route-i\
\nclude-object", \nclude-object",
"unnumbered-link-hop": { "unnumbered-link-hop": {
"// __COMMENT__ node-id": "AN1 NODE-ID", "// comment node-id": "AN1 NODE-ID",
"node-id": "10.0.0.1", "node-id": "192.0.2.1",
"// __COMMENT__ link-tp-id": "AN1-7 LTP-ID", "// comment link-tp-id": "AN1-7 LTP-ID",
"link-tp-id": 7, "link-tp-id": 7,
"// __DEFAULT__ hop-type": "strict", "// default hop-type": "strict",
"// __DEFAULT__ direction": "outgoing" "// default direction": "outgoing"
} }
}, },
{ {
"// __COMMENT__": "Tunnel hand-off ODU2 egress\ "// comment": "Tunnel hand-off ODU2 egress lab\
\ label (ODU2 over OTU4)", \el (ODU2 over OTU4)",
"index": 2, "index": 2,
"explicit-route-usage": "ietf-te-types:route-i\ "explicit-route-usage": "ietf-te-types:route-i\
\nclude-object", \nclude-object",
"label-hop": { "label-hop": {
"te-label": { "te-label": {
"ietf-otn-tunnel:tpn": 2, "ietf-otn-tunnel:otn-tpn": 2,
"ietf-otn-tunnel:tsg": "ietf-layer1-types:\ "ietf-otn-tunnel:tsg": "ietf-layer1-types:\
\tsg-1.25G", \tsg-1.25G",
"ietf-otn-tunnel:ts-list": "9-16", "ietf-otn-tunnel:ts-list": "9-16",
"// __DEFAULT__ direction": "forward" "// default direction": "forward"
} }
} }
} }
] ]
} }
} }
] ]
} }
} }
] ]
} }
} }
} }
B.2.3. JSON Code: mpi1-epl-service-config.json B.2.3. JSON Code: mpi1-epl-service-config.json
This is the JSON code reporting the EPL service configuration @ MPI: This is the JSON code reporting the EPL service configuration @ MPI:
========== NOTE: '\\' line wrapping per BCP XXX (RFC XXXX) ========== =============== NOTE: '\\' line wrapping per RFC 8792 ===============
{ {
"// __LAST_UPDATE__": "November 19, 2019", "// header": {
"// __TITLE__": "EPL Configuration @ MPI1", "last-update": "March 15, 2022",
"// __REFERENCE_DRAFTS__": { "title": "EPL Configuration @ MPI1",
"ietf-routing-types@2017-12-04": "rfc8294", "reference-drafts": {
"ietf-te-types@2019-07-05": "draft-ietf-teas-yang-te-types-10", "ietf-routing-types@2017-12-04": "rfc8294",
"ietf-eth-tran-types@2019-03-27": "draft-ietf-ccamp-client-signa\ "ietf-te@2021-05-16": "draft-ietf-teas-yang-te-27",
\l-yang-00", "ietf-te-types@2020-06-10": "rfc8776",
"ietf-eth-tran-service@2019-03-27": "draft-ietf-ccamp-client-sig\ "ietf-eth-tran-types@2021-07-07": "draft-ietf-ccamp-client-sig\
\nal-yang-00" \nal-yang-05",
}, "ietf-eth-tran-service@2021-01-11": "draft-ietf-ccamp-client-s\
"// __MISSING_ATTRIBUTES__": true, \ignal-yang-05"
"// __RESTCONF_OPERATION__": { },
"operation": "POST", "missing-attributes": true,
"url": "http://{{PNC1-ADDR}}/restconf/data/ietf-eth-tran-service\ "restconf-operation": {
\:etht-svc/etht-svc-instances" "operation": "POST",
"url": "http://{{PNC1-ADDR}}/restconf/data/ietf-eth-tran-servi\
\ce:etht-svc/etht-svc-instances"
}
}, },
"ietf-eth-tran-service:etht-svc": { "ietf-eth-tran-service:etht-svc": {
"etht-svc-instances": [ "etht-svc-instances": [
{ {
"etht-svc-name": "mpi1-epl-service", "etht-svc-name": "mpi1-epl-service",
"etht-svc-descr": "TNBI Example for an EPL over ODU2 Service\ "etht-svc-descr": "TNBI Example for an EPL over ODU2 Service\
\ @ MPI1", \ @ MPI1",
"// __DEFAULT__ etht-svc-type": "ietf-eth-tran-types:p2p-svc\ "// default etht-svc-type": "ietf-eth-tran-types:p2p-svc",
\", "// comment te-topology-identifier": "ETH Black Topology @ M\
"// __COMMENT__ te-topology-identifier": "ETH Black Topology\ \PI1",
\ @ MPI1",
"te-topology-identifier": { "te-topology-identifier": {
"provider-id": 201, "provider-id": 201,
"client-id": 300, "client-id": 300,
"topology-id": "eth-black-topology" "topology-id": "eth-black-topology"
}, },
"etht-svc-end-points": [ "etht-svc-end-points": [
{ {
"// __COMMENT__": "10GE Service End-Point at the access \ "// comment": "10GE Service End-Point at the access inte\
\interface (S3-1 -> AN1-1)", \rface (S3-1 -> AN1-1)",
"etht-svc-end-point-name": "mpi1-epl-an1-1-service-end-p\ "etht-svc-end-point-name": "mpi1-epl-an1-1-service-end-p\
\oint", \oint",
"etht-svc-end-point-descr": "Ethernet Service End-Point \ "etht-svc-end-point-descr": "Ethernet Service End-Point \
\at S3-1 (AN1-1) access link", \at S3-1 (AN1-1) access link",
"service-classification-type": "ietf-eth-tran-types:port\
\-classification",
"etht-svc-access-points": [ "etht-svc-access-points": [
{ {
"// __COMMENT__": "10GE Service Access Point at the \ "// comment": "10GE Service Access Point at the acce\
\access interface (S3-1 -> AN1-1)", \ss interface (S3-1 -> AN1-1)",
"access-point-id": "mpi-epl-an1-1-service-access-poi\ "access-point-id": "mpi-epl-an1-1-service-access-poi\
\nt", \nt",
"// __COMMENT__ access-node-id": "AN1 NODE-ID", "// comment access-node-id": "AN1 NODE-ID",
"access-node-id": "10.0.0.1", "access-node-id": "192.0.2.1",
"// __COMMENT__ access-ltp-id": "AN1-1 LTP-ID", "// comment access-ltp-id": "AN1-1 LTP-ID",
"access-ltp-id": 1 "access-ltp-id": 1
} }
] ],
} "service-classification-type": "ietf-eth-tran-types:port\
], \-classification",
"// __COMMENT__ ingress-egress-bandwidth-profile": "Outside \ "// comment ingress-egress-bandwidth-profile": "Outside \
\the scope of this JSON example", \the scope of this JSON example",
"// __NOT-PRESENT__ vlan-operations": "Transparent VLAN oper\ "// comment not present vlan-operations": "Transparent V\
\ations", \LAN operations"
"etht-svc-tunnels": [
{
"// __COMMENT__ tunnel-name": "ODU2 Head Tunnel Segment \
\@ MPI1",
"tunnel-name": "mpi1-odu2-tunnel"
} }
], ],
"underlay": {
"otn-tunnels": [
{
"// comment tunnel-name": "ODU2 Head Tunnel Segment @ \
\MPI1",
"name": "mpi1-odu2-tunnel"
}
]
},
"admin-status": "ietf-te-types:tunnel-admin-state-up" "admin-status": "ietf-te-types:tunnel-admin-state-up"
} }
] ]
} }
} }
Acknowledgments Acknowledgments
The authors would like to thank all members of the Transport NBI The authors would like to thank all members of the Transport NBI
Design Team involved in the definition of use cases, gap analysis and Design Team involved in the definition of use cases, gap analysis and
guidelines for using the IETF YANG models at the Northbound Interface guidelines for using the IETF YANG models at the Northbound Interface
(NBI) of a Transport SDN Controller. (NBI) of a Transport SDN Controller.
The authors would like to thank Xian Zhang, Anurag Sharma, Sergio The authors would like to thank Xian Zhang, Anurag Sharma, Sergio
Belotti, Tara Cummings, Michael Scharf, Karthik Sethuraman, Oscar Belotti, Tara Cummings, Michael Scharf, Karthik Sethuraman, Oscar
Gonzalez de Dios, Hans Bjursrom and Italo Busi for having initiated Gonzalez de Dios, and Hans Bjursrom for having initiated the work on
the work on gap analysis for transport NBI and having provided gap analysis for transport NBI and having provided foundations work
foundations work for the development of this document. for the development of this document.
The authors would like to thank the authors of the TE Topology and The authors would like to thank the authors of the TE Topology and
Tunnel YANG models [RFC8795] and [TE-TUNNEL], in particular, Igor Tunnel YANG models [RFC8795] and [TE-TUNNEL], in particular, Igor
Bryskin, Vishnu Pavan Beeram, Tarek Saad and Xufeng Liu, for their Bryskin, Vishnu Pavan Beeram, Tarek Saad and Xufeng Liu, for their
support in addressing any gap identified during the analysis work. support in addressing any gap identified during the analysis work.
The authors would like to thank Henry Yu and Aihua Guo for their The authors would like to thank Henry Yu and Aihua Guo for their
input and review of the URIs structures used within the JSON code input and review of the URIs structures used within the JSON code
examples. examples.
This work was supported in part by the European Commission funded This work was supported in part by the European Commission funded
H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727). H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727).
This document was prepared using kramdown. This document was prepared using kramdown.
Previous versions of this document was prepared using 2-Word- Previous versions of this document was prepared using 2-Word-
v2.0.template.dot. v2.0.template.dot.
Additional Authors' Addresses Contributors
Yang Zhao Yang Zhao
China Mobile China Mobile
Email: zhaoyangyjy@chinamobile.com Email: zhaoyangyjy@chinamobile.com
Sergio Belotti Sergio Belotti
Nokia Nokia
Email: sergio.belotti@nokia.com Email: sergio.belotti@nokia.com
Gianmarco Bruno Gianmarco Bruno
Ericsson Ericsson
Email: gianmarco.bruno@ericsson.com Email: gianmarco.bruno@ericsson.com
Young Lee Young Lee
Sung Kyun Kwan University Sung Kyun Kwan University
Email: younglee.tx@gmail.com Email: younglee.tx@gmail.com
Victor Lopez Victor Lopez
Nokia Nokia
Email: victor.lopez@nokia.com Email: victor.lopez@nokia.com
Carlo Perocchio Carlo Perocchio
Ericsson Ericsson
Email: carlo.perocchio@ericsson.com Email: carlo.perocchio@ericsson.com
Ricard Vilalta Ricard Vilalta
CTTC CTTC
Email: ricard.vilalta@cttc.es Email: ricard.vilalta@cttc.es
Michael Scharf Michael Scharf
Hochschule Esslingen - University of Applied Sciences Hochschule Esslingen - University of Applied Sciences
Email: michael.scharf@hs-esslingen.de Email: michael.scharf@hs-esslingen.de
Dieter Beller Dieter Beller
Nokia Nokia
Email: dieter.beller@nokia.com Email: dieter.beller@nokia.com
Authors' Addresses Authors' Addresses
Italo Busi (editor) Italo Busi (editor)
Huawei Huawei
Email: italo.busi@huawei.com Email: italo.busi@huawei.com
Daniel King (editor) Daniel King (editor)
Old Dog Consulting Old Dog Consulting
Email: daniel@olddog.co.uk Email: daniel@olddog.co.uk
Haomian Zheng (editor) Haomian Zheng (editor)
Huawei Huawei
Email: zhenghaomian@huawei.com Email: zhenghaomian@huawei.com
Yunbin Xu (editor) Yunbin Xu (editor)
CAICT CAICT
Email: xuyunbin@ritt.cn Email: xuyunbin@ritt.cn
 End of changes. 432 change blocks. 
934 lines changed or deleted 1018 lines changed or added

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