draft-ietf-ccamp-transport-nbi-app-statement-06.txt   draft-ietf-ccamp-transport-nbi-app-statement-07.txt 
CCAMP Working Group I. Busi CCAMP Working Group I. Busi
Internet Draft Huawei Internet Draft Huawei
Intended status: Informational D. King Intended status: Informational D. King
Old Dog Consulting Old Dog Consulting
H. Zheng H. Zheng
Huawei Huawei
Y. Xu Y. Xu
CAICT CAICT
Expires: March 2020 September 12, 2019 Expires: April 2020 October 31, 2019
Transport Northbound Interface Applicability Statement Transport Northbound Interface Applicability Statement
draft-ietf-ccamp-transport-nbi-app-statement-06 draft-ietf-ccamp-transport-nbi-app-statement-07
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on March 12, 2020. This Internet-Draft will expire on April 31, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Abstract Abstract
Transport network domains, including Optical Transport Network (OTN) This document provides an analysis of the applicability of the YANG
and Wavelength Division Multiplexing (WDM) networks, are typically models defined by the IETF (Traffic Engineering Architecture and
deployed based on a single vendor or technology platforms. They are Signaling (TEAS) moreover, Common Control and Measurement Plane
often managed using proprietary interfaces to dedicated Element (CCAMP) WGs in particular) to support ODU transit services,
Management Systems (EMS), Network Management Systems (NMS) and Transparent client services and EPL/EVPL Ethernet services over OTN
increasingly Software Defined Network (SDN) controllers. single and multi-domain network scenarios.
A well-defined open interface to each domain management system or
controller is required for network operators to facilitate control
automation and orchestrate end-to-end services across multi-domain
networks. These functions may be enabled using standardized data
models (e.g. YANG), and appropriate protocol (e.g., RESTCONF).
This document analyses the applicability of the YANG models being This document also describes how existing YANG models can be used
defined by the IETF (Traffic Engineering Architecture and Signaling through a number of worked examples and JSON fragments.
(TEAS) and Common Control and Measurement Plane (CCAMP) WGs in
particular) to support OTN single and multi-domain scenarios.
Table of Contents Table of Contents
1. Introduction...................................................4 1. Introduction...................................................4
1.1. The scope of this document................................4 1.1. The Scope of this Document................................4
1.2. Assumptions...............................................5 2. Terminology....................................................5
2. Terminology....................................................6 3. Conventions Used in this Document..............................8
3. Conventions used in this document..............................7 3.1. Topology and Traffic Flow Processing......................8
3.1. Topology and traffic flow processing......................7 3.2. JSON code.................................................9
3.2. JSON code.................................................8 4. Scenarios Description.........................................10
4.1. Reference Network........................................10
4. Scenarios Description..........................................9 4.2. Topology Abstractions....................................15
4.1. Reference Network.........................................9 4.3. Service Configuration....................................16
4.2. Topology Abstractions....................................13 4.3.1. ODU Transit.........................................17
4.3. Service Configuration....................................15 4.3.2. EPL over ODU........................................18
4.3.1. ODU Transit.........................................16 4.3.3. Transparent Client Services.........................19
4.3.2. EPL over ODU........................................17 4.3.4. EVPL over ODU.......................................20
4.3.3. Other OTN Clients Services..........................18 4.4. Multi-function Access Links..............................21
4.3.4. EVPL over ODU.......................................19 4.5. Protection and Restoration Configuration.................22
4.4. Multi-function Access Links..............................20 4.5.1. Linear Protection (end-to-end)......................23
4.5. Protection and Restoration Configuration.................21 4.5.2. Segmented Protection................................24
4.5.1. Linear Protection (end-to-end)......................21 4.6. Notification.............................................25
4.5.2. Segmented Protection................................23 4.7. Path Computation with Constraints........................25
4.6. Notification.............................................23 5. YANG Model Analysis...........................................26
4.7. Path Computation with Constraint.........................24 5.1. YANG Models for Topology Abstraction.....................26
5. YANG Model Analysis...........................................24 5.1.1. Domain 1 Black Topology Abstraction.................28
5.1. YANG Models for Topology Abstraction.....................25 5.1.2. Domain 2 Black Topology Abstraction.................32
5.1.1. Domain 1 Black Topology Abstraction.................26 5.1.3. Domain 3 White Topology Abstraction.................33
5.1.2. Domain 2 Black Topology Abstraction.................30 5.1.4. Multi-domain Topology Merging.......................34
5.1.3. Domain 3 White Topology Abstraction.................31 5.2. YANG Models for Service Configuration....................36
5.1.4. Multi-domain Topology Merging.......................31 5.2.1. ODU Transit Service.................................40
5.2. YANG Models for Service Configuration....................33 5.2.1.1. Single Domain Example..........................42
5.2.1. ODU Transit Service.................................36 5.2.2. EPL over ODU Service................................42
5.2.1.1. Single Domain Example..........................38 5.2.2.1. Single Domain Example..........................45
5.2.2. EPL over ODU Service................................38 5.2.3. Other OTN Client Services...........................45
5.2.2.1. Single Domain Example..........................40 5.2.3.1. Single Domain Example..........................46
5.2.3. Other OTN Client Services...........................41 5.2.4. EVPL over ODU Service...............................47
5.2.3.1. Single Domain Example..........................42 5.3. YANG Models for Protection Configuration.................48
5.2.4. EVPL over ODU Service...............................42 5.3.1. Linear Protection (end-to-end)......................48
5.3. YANG Models for Protection Configuration.................44 5.3.2. Segmented Protection................................50
5.3.1. Linear Protection (end-to-end)......................44 5.4. Notifications............................................51
5.4. Notifications............................................44 5.5. Path Computation with Constraints........................52
5.5. Path Computation with Constraints........................44 6. Security Considerations.......................................52
6. Security Considerations.......................................44 6.1. OTN Security.............................................52
7. IANA Considerations...........................................45 7. IANA Considerations...........................................53
8. References....................................................45 8. References....................................................53
8.1. Normative References.....................................45 8.1. Normative References.....................................53
8.2. Informative References...................................46 8.2. Informative References...................................54
9. Acknowledgments...............................................47 9. Acknowledgments...............................................55
Appendix A. Validating a JSON fragment against a YANG Model...49 Appendix A. Validating a JSON fragment against a YANG Model...57
A.1. Manipulation of JSON fragments..........................49 A.1. Manipulation of JSON fragments..........................57
A.2. Comments in JSON fragments..............................50 A.2. Comments in JSON fragments..............................58
A.3. Validation of JSON fragments: DSDL-based approach.......50 A.3. Validation of JSON fragments: DSDL-based approach.......58
A.4. Validation of JSON fragments: why not using a XSD-based A.4. Validation of JSON fragments: why not using an XSD-based
approach......................................................51 approach......................................................59
Appendix B. Detailed JSON Examples............................60
Appendix B. Detailed JSON Examples............................52 B.1. JSON Examples for Topology Abstractions.................61
B.1. JSON Examples for Topology Abstractions.................52 B.1.1. JSON Code: mpi1-otn-topology.json.................61
B.1.1. JSON Code: mpi1-otn-topology.json.................52 B.1.2. JSON Code: mpi1-eth-topology.json.................85
B.2. JSON Examples for Service Configuration.................68 B.2. JSON Examples for Service Configuration.................90
B.2.1. JSON Code: mpi1-odu2-service-config.json..........68 B.2.1. JSON Code: mpi1-odu2-service-config.json..........90
B.2.2. JSON Code: mpi1-odu2-tunnel-config.json...........72 B.2.2. JSON Code: mpi1-odu2-tunnel-config.json...........93
B.2.3. JSON Code: mpi1-epl-service-config.json...........72 B.2.3. JSON Code: mpi1-epl-service-config.json...........96
1. Introduction 1. Introduction
Transport of packet services are critical for a wide-range of Transport network domains, including Optical Transport Network (OTN)
applications and services, including data center and LAN and Wavelength Division Multiplexing (WDM) networks, are typically
interconnects, Internet service backhauling mobile backhaul and deployed based on a single vendor or technology platforms. They are
enterprise Carrier Ethernet services. These services are typically often managed using proprietary interfaces to dedicated Element
setup using stovepipe NMS and EMS platforms, often requiring Management Systems (EMS), Network Management Systems (NMS) and
propriety management platforms and legacy management interfaces. A increasingly Software Defined Network (SDN) controllers.
clear goal of operators is to automate the setup of transport
services across multiple transport technology domains.
A common open interface (API) to each domain controller and or Support of packet connectivity services over transport network
management system is pre-requisite for network operators to control domains are critical for a wide range of applications and services,
multi-vendor and multi-domain networks and also enable service including data center and LAN interconnects, Internet service
provisioning coordination/automation. This can be achieved by using backhauling, mobile backhaul and enterprise Carrier Ethernet
standardized YANG models, used together with an appropriate protocol services. A clear goal of operators is to automate the setup of
(e.g., RESTCONF [RFC8040]). these connectivity services across multiple transport network
domains, that may utilize different technologies.
This document analyses the applicability of the YANG models being A well-defined common open interface to each domain controller or a
management system is required for network operators to control
multi-vendor and multi-domain networks and also enable coordination
and automation of service provisioning. This is facilitated by using
standardized data models (e.g., YANG models), and an appropriate
protocol (e.g., RESTCONF [RFC8040]).
This document examines the applicability of the YANG models being
defined by IETF (Traffic Engineering Architecture and Signaling defined by IETF (Traffic Engineering Architecture and Signaling
(TEAS) and Common Control and Measurement Plane (CCAMP) WGs in (TEAS) moreover, Common Control and Measurement Plane (CCAMP) WGs in
particular) to support Optical Transport Networks (OTN) single and particular) to support Optical Transport Networks (OTN) single and
multi-domain scenarios. multi-domain scenarios.
1.1. The scope of this document 1.1. The Scope of this Document
This document assumes a reference architecture, including This document assumes a reference architecture, including
interfaces, based on the Abstraction and Control of Traffic- interfaces, based on the Abstraction and Control of Traffic-
Engineered Networks (ACTN), defined in [RFC8453]. Engineered Networks (ACTN), defined in [RFC8453].
The focus of this document is on the MPI (interface between the The focus of this document is on the interface between the Multi
Multi Domain Service Coordinator (MDSC) and a Physical Network Domain Service Coordinator (MDSC) and a Provisioning Network
Controller (PNC), controlling a transport network domain). Controller (PNC), controlling a transport network domain, called
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 CMI (interface between the Customer Network Detailed analysis of the interface between the Customer Network
Controller (CNC) and the MDSC) as well as of the interface between Controller (CNC) and the MDSC, called CNC-MDSC Interface (CMI) in
service and network orchestrators are outside the scope of this [RFC8453], as well as of the interface between service and network
document. However, some considerations and assumptions about the orchestrators are outside the scope of this document. However, when
information are described when needed. needed, this document describes some considerations and assumptions
about the information which needs to be provided at these
interfaces.
The relationship between the current IETF YANG models and the type The list of the IETF YANG models which are applicable to the ACTN
of ACTN interfaces can be found in [ACTN-YANG]. Therefore, it MPI can be found in [ACTN-YANG].
considers the TE Topology YANG model defined in [TE-TOPO], with the
OTN Topology augmentation defined in [OTN-TOPO] and the TE Tunnel
YANG model defined in [TE-TUNNEL], with the OTN Tunnel augmentation
defined in [OTN-TUNNEL]. It also considers the Ethernet Client
Topology augmentation defined in [CLIENT-TOPO] as well as the Client
Signal YANG models defined in [CLIENT-SIGNAL] for both Transparent
and Ethernet clients.
The ONF Technical Recommendations for Functional Requirements for The Functional Requirements for the transport API as described in
the transport API in [ONF TR-527] and the ONF transport API multi- the Optical Networking Foundation (ONF) document [ONF TR-527] have
domain examples in [ONF GitHub] have been considered as input for been taken as input for defining the reference scenarios analyzed in
defining the reference scenarios analyzed in this document. this document.
1.2. Assumptions The analysis provided in this document confirms that the IETF YANG
models defined in [RFC8345], [TE-TOPO], [OTN-TOPO], [CLIENT-TOPO],
[TE-TUNNEL], [PATH-COMPUTE], [OTN-TUNNEL] and [CLIENT-SIGNAL] can be
used together to control a multi-domain OTN network to support
different types of multi-domain services, such as ODU transit
services, Transparent client services and EPL/EVPL Ethernet
services, over a multi-domain OTN connection, satisfying also the
requirements in [ONF TR-527].
This document is making the following assumptions: 2. Terminology
1. The MDSC can request, at the MPI, a PNC to setup a Transit Tunnel Domain: A domain, as defined in [RFC4655], is "any collection of
Segment using the TE Tunnel YANG model: in this case, since the network elements within a common sphere of address management or
endpoints of the E2E Tunnel are outside the domain controlled by path computation responsibility". Specifically, within this
that PNC, the MDSC would not specify any source or destination TE document, we mean a part of an operator's network that is under
Tunnel Termination Point (TTP), i.e., it would leave empty the common management (i.e., under shared operational management using
source, destination, src-tp-id and dst-tp-id attributes of the TE the same instances of a tool and the same policies). Network
tunnel instance, and it would use the explicit-route-object (ERO) elements will often be grouped into domains based on technologies,
or route-object-include-exclude list to specify the ingress and vendor profiles, or geographic proximity.
egress links for each path of the Transit Tunnel Segment.
2. Each PNC provides to the MDSC, at the MPI, the list of available CNC: Customer Network Controller
timeslots on the inter-domain links using the TE Topology YANG
model and OTN Topology augmentation. The TE Topology YANG model
in [TE-TOPO] is being updated to report the label set
information.
See section 1.7 of [TE-TUTORIAL] for more details. Connection: The data plane configuration of an LSP, within this
document it is typically an ODU LSP. An end-to-end connection/LSP
represents an entire connection/LSP between the connection/LSP node
end-points. A connection/LSP segment represents a portion of the
end-to-end connection/LSP.
This document has made the following assumptions: Connectivity Service: A service, or connectivity service, in the
context of this document can be considered as some form of
connectivity service between customer sites across the network
operator's network [RFC8309].
1. The topology information for the Ethernet Client access links is E-LINE: Ethernet Line
modelled using the YANG model defined in [CLIENT-TOPO];
2. The topology information for the OTN and Transparent Client EPL: Ethernet Private Line
access links is modelled using the YANG model defined in [OTN-
TOPO];
3. The mapping information for Ethernet and Transparent Client EVPL: Ethernet Virtual Private Line
signals are modelled using the YANG model defined in [CLIENT-
SIGNAL].
Finally, the Network Elements (NEs) described in the scenarios used ILL: Inter-Layer Lock
in the document are using ODU switching. It is assumed that the ODU
links are pre-configured and using mechanisms such as WDM
wavelength, which are outside the scope of this document.
2. Terminology Link: A link, or a physical link, is used to reprent the adjacency
between two physical nodes. The term OTN link represents a link
between two OTN switching physical nodes.
Domain: A domain as defined by [RFC4655] is "any collection of LSP: Label Switched Path
network elements within a common sphere of address management or
path computation responsibility". Specifically, within this
document we mean a part of an operator's network that is under
common management (i.e., under shared operational management using
the same instances of a tool and the same policies). Network
elements will often be grouped into domains based on technology
types, vendor profiles, and geographic proximity.
E-LINE: Ethernet Line LTP: Link Termination Point
EPL: Ethernet Private Line MDSC: Multi-Domain Service Coordinator
EVPL: Ethernet Virtual Private Line Network Configuration: As described in [RFC8309] it describes the
instructions provided to a controller on how to configure parts of a
network.
ODU: Optical Channel Data Unit
OTU: Optical Channel Transport Unit
OTN: Optical Transport Network OTN: Optical Transport Network
Service: A service in the context of this document can be considered PNC: Provisioning Network Controller
as some form of connectivity between customer sites across the
network operator's network [RFC8309]. Protection Switching: Protection switching, as defined in [ITU-T
G.808.1] and [RFC4427], provides the capability to swith the traffic
in case of network failurs over pre-allocated networks resourse.
Typically linear protection methods would be used and configured to
operate as 1+1 unidirectional, 1+1 bidirectional or 1:n
bidirectional. This ensures fast and simple service survivability.
Protection Transport Entity/LSP: A protection transport entity/LSP,
as defined in [ITU-T G.808.1] and [RFC4427], represents the path
where the "normal" user traffic is transported during protection
switching events (e.g., when the working transport entity/LSP
fails).
Restoration: Restoration methods, as defined in [RFC4427], provide
the capability to reroute and restore traffic around network
failures without the necessity to allocate network resources as
required for dedicated 1+1 protection schemes. On the other hand,
restoration times are typically longer than protection switching
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.
UNI: User Network Interface TE Link: As defined in [TE-TOPO], it is an element of a TE topology,
presented as an edge on TE graph.
MDSC: Multi-Domain Service Coordinator TE Tunnel: As defined in [TE-TUTORIAL], it is a connection-oriented
service provided by a layer network of delivery of a client's data
between source and destination tunnel termination points.
CNC: Customer Network Controller TE Tunnel Segment: As defined in [TE-TUTORIAL], it is a part of a
multi-domain TE tunnel that spans.
PNC: Provisioning Network Controller TE Tunnel Hand-off: As defined in [TE-TUTORIAL], it is an access
link or inter-domain link by which a multi-domain TE tunnel enters
or exits a given network domain.
3. Conventions used in this document Note - The three definitions above are currently in [TE-TUTORIAL]
but it is expected that they will be moved to [TE-TUNNEL]. When this
happens, the reference will be updated and the [TE-TUTORIAL]
reference will be downgraded to Informative.
3.1. Topology and traffic flow processing TPN: Tributary Port Number
TTP: Tunnel Termination Point
Termination and Adaptation: It represents the termination of a
server-layer connection at the node edge-point and the
adaptation/mapping of the client layer traffic over the terminated
server-layer connection.
Transparent Client: As defined in [CLIENT-SIGNAL], it represents a
client-layer signal, such as Ethernet physical interfaces, FC, STM-
n, that cannot be switched but only mapped over a server-layer TE
Tunnel.
Working Transport Entity/LSP: A working transport entity/LSP, as
defined in [ITU-T G.808.1] and [RFC4427], represents the path where
the "normal" user traffic is transported.
UNI: User Network Interface
3. Conventions Used in this Document
3.1. Topology and Traffic Flow Processing
The traffic flow between different nodes is specified as an ordered The traffic flow between different nodes is specified as an ordered
list of nodes, separated with commas, indicating within the brackets list of nodes, separated with commas, indicating within the brackets
the processing within each node: the processing within each node:
<node> [<processing>]{, <node> [<processing>]} <node> [<processing>]{, <node> [<processing>]}
The order represents the order of traffic flow being forwarded The order represents the order of traffic flow being forwarded
through the network. through the network.
The processing can be just switching at a given layer The <processing> represents the type of processing performed by the
"[(switching)]" or also having an adaptation of a client layer into node, which can be just switching at a given layer
a server layer "[(client) -> server]" or [client -> (server)], "(switching-layer)" or it can also include an adaptation of a client
depending on whether the node is switching in the client or in the layer into a server layer: "(client-layer) -> server-layer" or
server layer. "client-layer -> (server-layer)", where the round brackets are used
to represent at which layer (client layer or server layer) the node
is switching.
For example, the following traffic flow: For example, the following traffic flow:
R1 [(PKT) -> ODU2], S3 [(ODU2)], S5 [(ODU2)], S6 [(ODU2)], R1 [(PKT) -> ODU2], S3 [(ODU2)], S5 [(ODU2)], S6 [(ODU2)],
R3 [ODU2 -> (PKT)] R3 [ODU2 -> (PKT)]
Node R1 is switching at the packet (PKT) layer and mapping packets Node R1 is switching at the packet (PKT) layer and mapping packets
into an ODU2 before transmission to node S3. Nodes S3, S5 and S6 are into an ODU2 before transmission to node S3. Nodes S3, S5 and S6,
switching at the ODU2 layer: S3 sends the ODU2 traffic to S5 which are switching at the ODU2 layer: S3 sends the ODU2 traffic to S5,
then sends it to S6 which finally sends to R3. Node R3 terminates which then sends it to S6 which finally sends to R3. Node R3
the ODU2 from S6 before switching at the packet (PKT) layer. terminates the ODU2 from S6 before switching at the packet (PKT)
layer.
The paths of working and protection transport entities are specified The paths of working and protection transport entities are specified
as an ordered list of nodes, separated with commas: as an ordered list of nodes, separated with commas:
<node> {, <node>} <node> {, <node>}
The order represents the order of traffic flow being forwarded The order represents the order of traffic flow being forwarded
through the network in the forward direction. In the case of through the network in the forward direction. In the case of
bidirectional paths, the forward and backward directions are bidirectional paths, the forward and backward directions are
selected arbitrarily, but the convention is consistent between selected arbitrarily, but the convention is consistent between
skipping to change at page 8, line 43 skipping to change at page 10, line 5
For example, when describing the example of a TE Topology instance For example, when describing the example of a TE Topology instance
representing the ODU Abstract Topology exposed by the Transport PNC, representing the ODU Abstract Topology exposed by the Transport PNC,
the following comment has been added to the JSON code: the following comment has been added to the JSON code:
"// comment": "ODU Abstract Topology @ MPI", "// comment": "ODU Abstract Topology @ MPI",
The JSON code examples provided in this document have been validated The JSON code examples provided in this document have been validated
against the YANG models following the validation process described against the YANG models following the validation process described
in Appendix A, which would not consider the comments. in Appendix A, which would not consider the comments.
In order to have successful validation of the examples, some To have successful validation of the examples, some numbering scheme
numbering scheme has been defined to assign identifiers to the has been defined to assign identifiers to the different entities
different entities which would pass the syntax checks. In that case, which would pass the syntax checks. In that case, to simplify the
to simplify the reading, another JSON name/value pair formatted as a reading, another JSON name/value pair formatted as a comment and
comment and using the mnemonic identifiers is also provided. For using the mnemonic identifiers is also provided. For example, the
example, the identifier of node S3 (S3-NODE-ID) has been assumed to identifier of node S3 (S3-NODE-ID) has been assumed to be "10.0.0.3"
be "10.0.0.3" and would be shown in the JSON code example using the and would be shown in the JSON code example using the two JSON
two JSON name/value pair: name/value pair:
"// te-node-id": "S3-NODE-ID", "// te-node-id": "S3-NODE-ID",
"te-node-id": "10.0.0.3", "te-node-id": "10.0.0.3",
The first JSON name/value pair will be automatically removed in the The first JSON name/value pair will be automatically removed in the
first step of the validation process while the second JSON first step of the validation process, while the second JSON
name/value pair will be validated against the YANG model name/value pair will be validated against the YANG model
definitions. definitions.
4. Scenarios Description 4. Scenarios Description
4.1. Reference Network 4.1. Reference Network
The physical topology of the reference network is shown in Figure 1. The physical topology of the reference network is shown in Figure 1.
It represents an OTN network composed of three transport network It represents an OTN network composed of three transport network
domains which provide transport connectivity services to an IP domains which provide connectivity services to an IP customer
customer network through eight access links: network 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
: : \ \ | : : \ : : domain : : \ \ | : : \ : : domain
skipping to change at page 10, line 40 skipping to change at page 11, line 40
: | \ / \ | \ : : : | \ / \ | \ : :
: | S16 \ | \ : : : | S16 \ | \ : :
: | / 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 transport network switching nodes This document assumes that all the Si transport network switching
Si are capable of switching in the electrical domain (ODU switching) nodes are capable of switching in the electrical domain (ODU
and that all the Si-Sj OTN links within the transport network switching) moreover, that all the Si-Sj OTN links within the
(intra-domain or inter-domain) are 100G links while the access Ri-Sj transport network (intra-domain or inter-domain) are 100G links
links are 10G links. while the access Ri-Sj links are 10G links.
It is also assumed that, within the transport network, the This document also assumes that within the transport network, the
physical/optical interconnections supporting the Si-Sj OTN links (up physical/optical connections supporting the Si-Sj OTN links (up to
to the OTU4 trail), are pre-configured using mechanisms which are the OTU4 trail), are pre-provisioned using mechanisms which are
outside the scope of this document and are not exposed at the MPIs outside the scope of this document and are not exposed at the MPIs
to the MDSC. to the MDSC.
Different technologies can be used on the access links (e.g., Different transmission technologies can be used on the access links
Ethernet, STM-N and OTU). Section 4.3 provides more details about (e.g., Ethernet, STM-N and OTU). Section 4.3 provides more details
the different assumptions on the access links for different services about the different assumptions on the access links for different
types and section 4.4 describes the control of access links which types of connectivity services and section 4.4 describes the control
can support different technology configuration (e.g., STM-64, 10GE of access links which can support different technology
or OTU2) depending on the type of service being configured (multi- configurations (e.g., STM-64, 10GE or OTU2) depending on the type of
function access links). service being configured (multi-function access links).
The transport domain control architecture, shown in Figure 2, To carry client signals (e.g., Ethernet or STM-N) over OTN, some ODU
follows the ACTN architecture and framework document [RFC8453], and termination and adaptation resources need to be available on the
functional components: physical edge nodes (e.g., node S3 and S18). The location of these
resources within the physical node is implementation specific and
outside the scope of standardization. This document assumes that
these termination and adaptation resources are located on the
physical interfaces of the edge nodes terminating the access links.
In other words, each physical access link has a set dedicated ODU
termination and adaptation resources.
The transport network control architecture, shown in Figure 2,
follows the ACTN architecture as defined in the ACTN framework
document [RFC8453], and uses the same functional components:
-------------- --------------
| | | |
| CNC | | CNC |
| | | |
-------------- --------------
| |
....................|....................... CMI ....................|....................... CMI
| |
---------------- ----------------
skipping to change at page 12, line 42 skipping to change at page 13, line 42
( Network ) ( ) ( ) ( Network ) ( ) ( )
( Domain 1 ) ----- ( ) ( Domain 1 ) ----- ( )
( ) ( Network ) ( ) ( Network )
( ) ( Domain 3 ) ( ) ( Domain 3 )
----- ( ) ----- ( )
( ) ( )
----- -----
Figure 2 - Controlling Hierarchies Figure 2 - Controlling Hierarchies
The ACTN framework facilitates the detachment of the network and 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 the end-to-end network through the MPIs toward the
underlying PNCs.
The ACTN framework facilitates the separation of the network and
service control from the underlying technology. It helps the service control from the underlying technology. It helps the
customer define the network as desired by business needs. Therefore, customer to define the network as desired by business needs. The CMI
care must be taken to keep a minimal level of dependency on the CMI is defined to keep a minimal level of dependency (or no dependency
(or no dependency at all) with respect to the network domain at all) from the underlying network technologies. The MPI instead
technologies. The MPI instead requires some specialization according requires some specialization according to the domain technology.
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 shown in Figure 2. three MPIs, as shown in Figure 2.
It is worth noting that the split of functionality at the MPI in the The split of functionality at the MPI in the ACTN architecture
ACTN architecture between the MDSC and the PNCs is between the MDSC (multi-domain controller) and the PNCs (domain
equivalent/analogous to the split of functionality which is assumed controllers), is equivalent to separation functionality assumed in
for the ONF T-API interface when used between a multi-domain the ONF T-API interface, as described in the ONF T-API multi-domain
controller and domain controllers, as described in the ONF T-API use cases [ONF TR-527]. Furthermore, this functional separation is
multi-domain use cases [ONF TR-527], as well as at 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 [MEF 55].
Architecture [MEF 55].
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, at the CMI, transport architecture which is capable of requesting connectivity services on
connectivity between IP routers, when needed. demand between IP routers at the CMI.
The CNC can request transport connectivity services between IP The CNC can request connectivity services between IP routers which
routers which can be attached to different transport domains (e.g., can be attached to different transport network domains (e.g.,
between R1 and R8 in Figure 1) or to the same transport domain between R1 and R8 in Figure 1) or to the same transport network
(e.g., between R1 and R3 in Figure 1). Since the CNC is not aware of domain (e.g., between R1 and R3 in Figure 1). Since the CNC is not
the transport network controlling hierarchy, the mechanisms used by aware of the transport network controller hierarchy, the mechanisms
the CNC to request, at the CMI, transport connectivity services are used by the CNC to request connectivity services at the CMI is also
independent on whether the service request is single-domain or unaware whether the requested service spans a single-domain or
multi-domain. multi-domains.
It is assumed that the CMI allows the CNC to provide all the It is assumed that the CMI allows the CNC to provide all the
information that is required by the MDSC to understand the necessary information needed by the MDSC to understand the
connectivity service request and to decide the network connectivity service request and to determine the network
configurations to be requested, at the MPIs, to its underlying PNCs configurations to be requested, at the MPIs, to its underlying PNCs
to support the requested connectivity service. to support the requested connectivity service.
When a single-domain service is requested by the CNC at the CMI The MDSC, after having received a single-domain service request from
(e.g., between R1 and R3 in Figure 1), the MDSC can follow the same the CNC at the CMI (e.g., between R1 and R3 in Figure 1), can follow
procedures, described above for the multi-domain service, and decide the same procedures, described above for the multi-domain service,
the network configuration to request only at the MPI of the PNC and decide the network configuration to request only at the MPI of
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 Abstraction provides a selective method for representing
connectivity information within a domain. There are multiple methods connectivity information within a domain. There are multiple methods
to abstract a network topology. This document assumes the to abstract a network topology. This document assumes the
abstraction method defined in [RFC7926]: abstraction method defined in [RFC7926]:
"Abstraction is the process of applying the policy to the "Abstraction is the process of applying the policy to the
available TE information within a domain, to produce selective available TE information within a domain, to produce selective
skipping to change at page 14, line 21 skipping to change at page 15, line 26
all possible connectivity options, but presents a general view of all possible connectivity options, but presents a general view of
potential connectivity according to the policies that determine potential connectivity according to the policies that determine
how the domain's administrator wants to allow the domain resources how the domain's administrator wants to allow the domain resources
to be used." to be used."
[RFC8453] Provides the context of topology abstraction in the ACTN [RFC8453] Provides the context of topology abstraction in the ACTN
architecture and discusses a few alternatives for the abstraction architecture and discusses a few alternatives for the abstraction
methods for both packet and optical networks. This is an important methods for both packet and optical networks. This is an important
consideration since the choice of the abstraction method impacts consideration since the choice of the abstraction method impacts
protocol design and the information it carries. According to protocol design and the information it carries. According to
[RFC8453], there are three types of topology: [RFC8453], there are three types of topologies:
o White topology: This is a case where the PNC provides the actual o White topology: This is a case where the PNC provides the actual
network topology to the MDSC without any hiding or filtering. In network topology to the MDSC without any hiding or filtering. In
this case, the MDSC has the full knowledge of the underlying this case, the MDSC has the full knowledge of the underlying
network topology; network topology;
o Black topology: The entire domain network is abstracted as a o Black topology: The entire domain network is abstracted as a
single virtual node with the access/egress links without single virtual node with the access links and inter-domain links
disclosing any node internal connectivity information; without disclosing any node internal connectivity information;
o Grey topology: This abstraction level is between black topology o Grey topology: This abstraction level is between black topology
and white topology from a granularity point of view. This is an and white topology from a granularity point of view.
abstraction of TE tunnels for all pairs of border nodes. We may
further differentiate from a perspective of how to abstract
internal TE resources between the pairs of border nodes:
- Grey topology type A: border nodes with TE links between them
in a full mesh fashion;
- Grey topology type B: border nodes with some internal
abstracted nodes and abstracted links.
Each PNC should provide the MDSC with a network topology Each PNC should provide the MDSC a network topology abstraction
abstractions hiding the internal details of the physical domain hiding the internal details of the physical domain network topology
network topology controlled by the PNC and this abstraction is controlled by the PNC. As described in section 3 of [RFC8453], the
independent of the abstractions provided by other PNCs. Therefore it level of abstraction provided by each PNC is based on the PNC
is possible that different PNCs provide different types of topology configuration parameters and it is independent of the abstractions
abstractions and each MPI operates on the abstract topology provided by other PNCs. Therefore, it is possible that different
regardless of, and independently from, the type of abstraction PNCs provide different types of topology abstractions. The MDSC can
provided by the PNC. operate on each MPI abstract topology regardless of, and
independently from, the type of abstraction provided by its
underlying PNC.
To analyze how the MDSC can operate on abstract topologies For analyzing how the MDSC can operate on an abstract topology
independently from the topology abstraction provided by each PNC provided by several PNcs that independently applied different
and, therefore, that different PNCs can provide different topology abstraction policies and therefore provided different types of
abstractions, that the following examples are assumed: abstract topologies, the following assumptions are made for the
reference network in Figure 1:
o PNC1 and PNC2 provide black topology abstractions which expose at o 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 o PNC3 provides a white topology abstraction which exposes at MPI3
all the physical nodes and links within network domain 3. all the physical nodes and links within network domain 3.
The MDSC should be capable of stitching together the abstracted The MDSC should be capable of stitching together the abstracted
topologies provided by each PNC to build its own view of the topologies provided by each PNC to build its view of the multi-
multi-domain network topology. The process may require suitable domain network topology. This topology knowledge may require proper
oversight, including administrative configuration and trust models, oversight, including the application of local policy, configuration
a method of how to achieve this is out of scope for this document. methods, and the application of a trust model. Methods of how to
manage these aspects are out of scope for this document, but
The MDSC can also provide topology abstraction of its own view of recomandations are provided in the Security section of this
the multi-domain network topology at its CMIs depending on the
customers' needs: it can provide different types of topology
abstractions at different CMIs. Analyzing the topology abstractions
provided by the MDSC to its CMIs is outside the scope of this
document. document.
The MDSC can also provide topology abstraction of its view of the
multi-domain network topology at its CMIs depending on the
customers' needs and policies: it can provide different types of
topology abstractions at different CMIs. Analyzing the topology
abstractions provided by the MDSC to its CMIs is outside the scope
of this document.
4.3. Service Configuration 4.3. Service Configuration
In the following scenarios, it is assumed that the CNC is capable of In the following scenarios, it is assumed that the CNC is capable of
requesting service connectivity from the MDSC to support IP routers requesting connectivity services from the MDSC, for example to
connectivity. interconnect IP routers.
The type of services could depend on the type of physical links The type of connectivity services depends on the type of physical
(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 control of different adaptations inside IP routers, Ri (PKT -> The packet processing inside IP routers, including packet
foo) and Rj (foo -> PKT), are assumed to be performed by means that encapsualation and decapsulation, Ri (PKT -> foo) and Rj (foo ->
are not under the control of, and not visible to, the MDSC nor to PKT), are assumed to be performed by means that are not under the
the PNCs. Therefore, these mechanisms are outside the scope of this control of, and not visible to, the MDSC nor to the PNCs. Therefore,
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 interconnections below the ODU layer (up to the OTU2 trail) are
pre-configured using mechanisms which are outside the scope of this pre-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).
To setup a 10Gb IP link between R1 and R8, an ODU2 end-to-end When a 10Gb IP link between R1 and R8 is needed, an ODU2 end-to-end
connection needs to be created, passing through transport nodes S3, connection needs to be created, passing through transport network
S1, S2, S31, S33, S34, S15 and S18 which belong to different PNC nodes S3, S1, S2, S31, S33, S34, S15 and S18 which belong to
domains (multi-domain service request): 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 understands that it needs to establish 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). It also different PNC domains (multi-domain service request). The MDSC also
decides the network configurations to request, at the MPIs, to its determines the network configuration requests to be sent to its
underlying PNCs, to coordinate the setup of a multi-domain ODU2 underlying PNCs, at the MPIs, to coordinate the setup of a multi-
segment connection between the access links on S3 and S18. domain ODU2 connection segment between the access links on S3 and
S18.
To setup of a 10Gb IP link between R1 and R3, an ODU2 end-to-end When a 10Gb IP link between R1 and R3 is needed, an ODU2 end-to-end
connection needs to be created, passing through transport nodes S3, connection needs to be created, passing through transport network
S5 and S6 which belong to the same PNC domain (single-domain service nodes S3, S5 and S6 which belong to the same PNC domain (single-
request): 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 understand 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
same PNC domain (single-domain service request) and it decides the same PNC domain (single-domain service request) and it decides the
proper network configuration to request PNC1. proper network configuration to request PNC1.
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 In this case, it is assumed that the Ethernet physical interfaces
(up to the MAC layer) are pre-configured using mechanisms which are (up 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.
To setup a 10Gb IP link between R1 and R8, an EPL service needs to When a 10Gb IP link between between R1 and R8 is needed, an EPL
be created, supported by an ODU2 end-to-end connection, between service needs to be created, supported by an ODU2 end-to-end
transport nodes S3 and S18, passing through transport nodes S1, S2, connection, between transport network nodes S3 and S18, passing
S31, S33, S34 and S15, which belong to different PNC domains (multi- through transport network nodes S1, S2, S31, S33, S34 and S15, which
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 understands that it needs to setup an EPL service between The MDSC receives, at the CMI, the request to create an EPL service
the access links on S3 and S18, which belong to different PNC between the access links on S3 and S18, which belong to different
domains (multi-domain service request). It also decides the network PNC domains (multi-domain service request). The MDSC determines the
configurations to request, at the MPIs, to its underlying PNCs, to network configurations to request, at the MPIs, to its underlying
coordinate the setup of an end-to-end ODU2 connection between the PNCs, to coordinate the setup of an end-to-end ODU2 connection
nodes S3 and S8, including the configuration of the adaptation between the nodes S3 and S8, including the configuration of the
functions inside these edge nodes, such as S3 [ETH -> (ODU2)] and adaptation functions inside these edge nodes, such as S3 [ETH ->
S18 [(ODU2) -> ETH]. (ODU2)] and S18 [(ODU2) -> ETH].
To setup a 10Gb IP link between R1 and R2, an EPL service needs to When a 10Gb IP link between R1 and R2 is needed, an EPL service
be created, supported by an ODU2 end-to-end connection between needs to be created, supported by an ODU2 end-to-end connection
transport nodes S3 and S6, passing through the transport node S5, between transport network nodes S3 and S6, passing through the
which belong to the same PNC domain (single-domain service request): transport network node S5, which belong to the same PNC domain
(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 understand 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, which 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. Other OTN Clients Services 4.3.3. Transparent Client Services
[ITU-T G.709] defines mappings of different Transparent Client [ITU-T G.709] defines mappings of different Transparent Client
layers into ODU. Most of them are used to provide Private Line layers into ODU. Most of them are used to provide Private Line
services over an OTN transport network supporting a variety of types services over an OTN transport network supporting a variety of types
of physical access links (e.g., Ethernet, SDH STM-N, Fibre Channel, of physical access links (e.g., Ethernet, SDH STM-N, Fibre Channel,
InfiniBand, etc.) interconnecting the IP routers and the transport InfiniBand, etc.) interconnecting the IP routers and the transport
network. network.
In order to setup a 10Gb IP link between R1 and R8 using, with for When a 10Gb IP link between R1 and R8 is needed, using, for example
example SDH physical links between the IP routers and the transport SDH physical links between the IP routers and the transport network,
network, an STM-64 Private Line service needs to be created, an STM-64 Private Line service needs to be created, supported by an
supported by an ODU2 end-to-end connection, between transport nodes ODU2 end-to-end connection, between transport network nodes S3 and
S3 and S18, passing through transport nodes S1, S2, S31, S33, S34 S18, passing through transport network nodes S1, S2, S31, S33, S34
and S15, which belong to different PNC domains (multi-domain service and S15, which belong to different PNC domains (multi-domain service
request): request):
R1 [(PKT) -> STM-64], S3 [STM-64 -> (ODU2)], S1 [(ODU2)], R1 [(PKT) -> STM-64], S3 [STM-64 -> (ODU2)], S1 [(ODU2)],
S2 [(ODU2)], S31 [(ODU2)], S33 [(ODU2)], S34[(ODU2)], S2 [(ODU2)], S31 [(ODU2)], S33 [(ODU2)], S34[(ODU2)],
S15 [(ODU2)], S18 [(ODU2) -> STM-64], R8 [STM-64 -> (PKT)] S15 [(ODU2)], S18 [(ODU2) -> STM-64], R8 [STM-64 -> (PKT)]
As already described (section 4.1) CNC provides the essential As described (section 4.1) the CNC provides the essential
information to permit the MDSC to understand which type of service information to permit the MDSC to compute which type of service is
is needed, in this case, an STM-64 Private Line service between the needed, in this case, an STM-64 Private Line Service between the
access links on S3 and S8, and it also decides the network access links on S3 and S8, and it also decides the network
configurations, including the configuration of the adaptation configurations, including the configuration of the adaptation
functions inside these edge nodes, such as S3 [STM-64 -> (ODU2)] and functions inside these edge nodes, such as S3 [STM-64 -> (ODU2)] and
S18 [(ODU2) -> STM-64]. S18 [(ODU2) -> STM-64].
To setup a 10Gb IP link between R1 and R3), an STM-64 Private Line When a 10Gb IP link between R1 and R3 is needed, an STM-64 Private
service needs to be created between R1 and R3 (single-domain service Line service needs to be created between R1 and R3 (single-domain
request): 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 understand 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
physical interfaces (up to the MAC layer) are pre-configured. physical interfaces (up to the MAC layer) are pre-provisioned.
To setup two 1Gb IP links between R1 to R2 and between R1 and R8, When two 1Gb IP links between R1 to R2 and between R1 and R8 are
two EVPL services need to be created, supported by two ODU0 end-to- needed, two EVPL services need to be created, supported by two ODU0
end connections: end-to-end connections:
R1 [(PKT) -> VLAN], S3 [VLAN -> (ODU0)], S5 [(ODU0)], R1 [(PKT) -> VLAN], S3 [VLAN -> (ODU0)], S5 [(ODU0)],
S6 [(ODU0) -> VLAN], R2 [VLAN -> (PKT)] S6 [(ODU0) -> VLAN], R2 [VLAN -> (PKT)]
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 fist 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 are sharing the same Ethernet physical
link between R1 and S3, different VLAN IDs are associated with link between R1 and S3, different VLAN IDs are associated with
different EVPL services: for example, VLAN IDs 10 and 20 different EVPL services: for example, VLAN IDs 10 and 20
respectively. respectively.
Based on the assumptions described in section 4.3.2, the CNC Based on the assumptions described in section 4.3.2, the CNC sends a
requests at the CMI the MDSC to setup these EVPL services and the request to the MDSC, at the CMI, to setup these EVPL services. The
MDSC understands 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 done a-priori 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 the a-priori the MPI as links supporting only one mode (depending on how the link
configuration) and will be controlled at the MPI as discussed in has been pre-provisioned) and will be controlled at the MPI as
section 4.3: for example, a 10G multi-function access link can be discussed in section 4.3: for example, a 10G multi-function access
pre-configured as an OTU2 trail (section 4.3.1), a 10GE physical link can be pre-provisioned as an OTU2 trail (section 4.3.1), a 10GE
link (section 4.3.2) or an STM-64 physical link (section 4.3.3). physical link (section 4.3.2) or an STM-64 physical link (section
4.3.3).
It is also possible not to configure these links a-priori and let It is also possible not to configure these links a-priori and let
the MDSC (or, in case of a single-domain service request, the PNC) the MDSC (or, in case of a single-domain service request, the PNC)
decide how to configure these links, based on the service decide how to configure these links, based on the service
configuration. configuration.
For example, if the physical link between R1 and S3 is a For example, if the physical link between R1 and S3 is a
multi-functional access link while the physical links between R4 and multi-functional access link while the physical links between R4 and
S6 and between R8 and S18 are STM-64 and 10GE physical links S6 and between R8 and S18 are STM-64 and 10GE physical links
respectively, it is possible to configure either an STM-64 Private respectively, it is possible to configure either an STM-64 Private
skipping to change at page 20, line 46 skipping to change at page 22, 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 to request at the CMI the setup either an STM-64 The CNC is capable of requesting, via the CMI, the setup either an
Private Line service, between R1 and R4, or an EPL service, between STM-64 Private Line service, between R1 and R4, or an EPL service,
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 request, 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 coordinate the setup of an end-to-end ODU2 connection, either
between nodes S3 and S6, or between nodes S3 and S18, including the between nodes S3 and S6, or between nodes S3 and S18, including the
configuration of the adaptation functions on these edge nodes, and configuration of the adaptation functions on these edge nodes, and
in particular whether the multi-function access link between R1 and in particular whether the multi-function access link between R1 and
S3 should operate as an STM-64 or as a 10GE physical link. S3 should operate as an STM-64 or as a 10GE physical link.
4.5. Protection and Restoration Configuration Assumptions used in this example, as well as the service scenarios
of sections 4.3, include:
Protection switching provides a pre-allocated survivability o the R1-S3 and R8-S18 access links will be multi-function access
mechanism, typically provided via linear protection methods and links, which can be configured as an OTU2 trail or as an STM-64
would be configured to operate as 1+1 unidirectional (the most or a 10GE physical link;
common OTN protection method), 1+1 bidirectional or 1:n
bidirectional. This ensures fast and simple service survivability.
Restoration methods would provide the capability to reroute and o the R3-S6 access link will be a multi-function access link which
restore connectivity traffic around network faults, without the can be configured as an OTU2 trail or as an STM-64 physical link;
network penalty imposed with dedicated 1+1 protection schemes.
This section describes only services which are protected with linear o the R4-S6 access link is pre-provisioned as an STM-64 physical
protection. The description of services using dynamic restoration is link;
outside the scope of this document.
The MDSC needs to be capable of deciding the network configuration o all the other access links (and, in particular, the R2-S6 access
to request different PNCs to coordinate the protection switching links) are pre-provisioned as 10GE physical links, up to the MAC
configuration to support protected connectivity services described layer.
in section 4.3.
Since in these service examples, switching within the transport 4.5. Protection and Restoration Configuration
network domain is performed only in the OTN ODU layer. It may also
be assumed that protection switching within the transport network As described in [RFC4427], recovery can be performed by either
domain is provided at the OTN ODU layer. protection switching or restoration mechanisms. This section
describes only services which are protected with linear protection,
considering both end-to-end and segment protection, as defined in
[ITU-T G.808.1] and [RFC4427]. The description of services using
dynamic restoration is outside the scope of this document.
The MDSC needs to be capable of determining the network
configurations to request different PNCs to coordinate the
protection switching configuration to support protected connectivity
services described in section 4.3.
In the service examples described in section 4.3, switching within
the transport network domain is only performed at the OTN ODU layer.
Therefore, it is also assumed that protection switching within the
transport network also occurs at the OTN ODU layer, using the
mechanisms defined in [ITU-T G.873.1].
4.5.1. Linear Protection (end-to-end) 4.5.1. Linear Protection (end-to-end)
In order to protect the connectivity services described in section To protect the connectivity services described in section 4.3 from
4.3 from failures within the OTN multi-domain transport network, the failures within the OTN multi-domain transport network, the MDSC can
MDSC can decide to request its underlying PNCs to configure ODU2 decide to request its underlying PNCs to configure ODU2 linear
linear protection between the access nodes (e.g., nodes S3 and S18 protection between the transport network edge nodes (e.g., nodes S3
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 to with It is assumed that the OTN linear protection is configured as 1+1
1+1 unidirectional protection switching type, as defined in [ITU-T unidirectional protection switching type according to the definition
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 o In one case, the working and protection transport entities pass
through the same PNC domains: through the same PNC domains:
skipping to change at page 22, line 37 skipping to change at page 24, line 9
o In another case, the working and protection transport entities o In another case, the working and protection transport entities
can pass through different PNC domains: can pass through different PNC domains:
Working transport entity: S3, S5, S7, Working transport entity: S3, S5, S7,
S11, S12, S17, S18 S11, S12, S17, S18
Protection transport entity: S3, S1, S2, Protection transport entity: S3, S1, S2,
S31, S33, S34, S31, S33, S34,
S15, S18 S15, S18
The PNCs should be capable to report to the MDSC which is the active The PNCs should be capable of reporting to the MDSC which is the
transport entity, as defined in [ITU-T G.808.1], in the data plane. active transport entity, as defined in [ITU-T G.808.1], in the data
plane.
Given the fast dynamic of protection switching operations in the Given the fast dynamic of protection switching operations in the
data plane (50ms recovery time), this reporting is not expected to data plane (e.g., 50ms switching time), this reporting is not
be in real-time. expected to 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
skipping to change at page 23, line 36 skipping to change at page 25, line 8
MDSC can also request PNC3 to configure linear protection between MDSC can also request PNC3 to configure linear protection between
its edge nodes S31 and S34: its edge nodes S31 and S34:
Working transport entity: S31, S33, S34 Working transport entity: S31, S33, S34
Protection transport entity: S31, S32, S34 Protection transport entity: S31, S32, S34
4.6. Notification 4.6. Notification
To realize the topology update, service update and restoration To realize the topology update, service update and restoration
function, following notification type should be supported: function, following notification types should be supported:
1. Object create 1. Object create
2. Object delete 2. Object delete
3. Object state change 3. Object state change
4. Alarm 4. Alarm
There are three types of topology abstraction type defined in There are three types of topology abstraction types defined in
section 4.2, the notification should also be abstracted. The PNC and section 4.2, and the notifications should also be abstracted. The
MDSC should coordinate together to determine the notification PNC and MDSC should coordinate together to determine the
policy, such as when an intra-domain alarm occurred, the PNC may not notification policy. This will include information such as when an
report the alarm but the service state change notification to the intra-domain alarm occurred. The PNC may not report the alarm, but
it should provide notification of the service state change to the
MDSC. MDSC.
4.7. Path Computation with Constraint Analysis and methods of how event alarms are triggered, managed and
propagated are outside the scope of this document.
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., IRO/XRO).
For example, the CNC can request, at the CMI, an ODU transit 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 service, 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 constraint to pass through the link from S2 to S31 (IRO), such that
a qualified path could be: a qualified path could be:
R1 [(PKT) -> ODU2], S3 [(ODU2]), S1 [(ODU2]), S2 [(ODU2]), R1 [(PKT) -> ODU2], S3 [(ODU2]), S1 [(ODU2]), S2 [(ODU2]),
skipping to change at page 24, line 30 skipping to change at page 26, line 9
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 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 S12, then the above path would not be qualified, while the following
would be: would 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 understand these constraints and take them into account in MDSC can satisfy these constraints and take them into account in its
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 constraints to domains and inter-domain links) and in the path computation
provide to its underlying PNCs, to be taken into account in the path constraints to provide to its underlying PNCs, to be taken into
computation procedures implemented by the PNCs (with a more detailed account in the path computation procedures implemented by the PNCs
view of topology). (with a more detailed view of topology).
Further detailed analysis is outside the scope of this document.
5. YANG Model Analysis 5. YANG Model Analysis
This section analyses how the IETF YANG models can be used at the This section analyses how the IETF YANG models can be used at the
MPIs, between the MDSC and the PNCs, to support the scenarios MPIs, between the MDSC and the PNCs, to support the scenarios
described in section 4. described in section 4.
The YANG models described in [ACTN-YANG] are assumed to be used at The YANG models described in [ACTN-YANG] are assumed to be used at
the MPI. the MPI.
skipping to change at page 25, line 18 skipping to change at page 26, line 42
Section 5.2 describes how the MDSC can request different PNCs, via Section 5.2 describes how the MDSC can request different PNCs, via
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
Each PNC reports its respective OTN abstract topology to the MDSC, This section analyses how each PNC can report its respective
as described in section 4.2, using the Topology YANG models, defined abstract topology to the MDSC, as described in section 4.2, using
in [RFC8345], with the TE Topology YANG augmentations, provided in the Topology YANG models, defined in [RFC8345], with the TE Topology
[TE-TOPO], and the OTN technology-specific YANG augmentations, YANG augmentations, provided in [TE-TOPO], and the OTN
defined in [OTN-TOPO]. technology-specific YANG augmentations, defined in [OTN-TOPO] or the
Ethernet client technology-specific YANG augmentations, defined in
[CLIENT-TOPO].
As described in section 4.1, the OTU4 trails on inter-domain and
intra-domain physical links are pre-provisioned and therefore not
exposed at the MPIs. Only the TE Links they support can be exposed
at the MPI, depending on the topology abstraction performed by the
PNC.
The access links can be multi-function access links, as described in
section 4.4.
As described in section 4.1, each physical access link has a
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 a transparent client physical links (e.g.,
STM-64 physical link) as an OTUk trail. STM-64 physical link) or as an OTUk trail.
In order to support the EPL and EVPL services, described in sections In order to support the EPL and EVPL services, described in sections
4.3.2 and 4.3.4, the access links, which are capable to be 4.3.2 and 4.3.4, the access links, which are capable of being
configured as Ethernet physical links, are reported by each PNC configured as Ethernet physical links, are reported by each PNC
within its respective Ethernet abstract topology, using the Topology within its respective Ethernet abstract topology, using the Topology
YANG models, defined in [RFC8345], with the TE Topology YANG YANG models, defined in [RFC8345], with the TE Topology YANG
augmentations, defined in [TE-TOPO], and the Ethernet client augmentations, defined in [TE-TOPO], 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 or as an OTUk trail and/or configured as an Ethernet physical link, an OTUk trail, or as a
as transparent client physical links (e.g., STM-64 physical link). transparent client physical links (e.g., STM-64 physical link). In
In this case, these physical access links are represented in both this case, these physical access links are represented in both the
the OTN and Ethernet abstract topologies. OTN and Ethernet abstract topologies.
The PNC reports the capabilities of the access or inter-domain link
ends it can control. It is the MDSC responsibility to request
configuration of these links matching the capabilities of both link
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 in 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. are reported in these Ethernet abstract topologies, to report that
the underlying networt domain is not capable to support Ethernet TE
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.2. It exposes at MPI1 to the MDSC, two TE Topology
instances with only one TE node each. 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)
and only inter-domain and access abstract TE links (which represent moreover, only inter-domain and access abstract TE links (which
the inter-domain physical links and the access physical links which represent the inter-domain physical links and the access physical
can support ODU and/or transparent client layers), as shown in links which can support ODU, or transparent client layers, both), as
Figure 3 below. shown in Figure 3 below.
................................... ...................................
: : : :
: +-----------------+ : : +-----------------+ :
: | | : : | | :
(R1)- - --------| |-------- - -(S31) (R1)- - --------| |-------- - -(S31)
: AN1-1 | | AN1-7 : : AN1-1 | | AN1-7 :
: | | : : | | :
(R3)- - --------| | : (R3)- - --------| | :
: AN1-2 | AN1 | : : AN1-2 | AN1 | :
skipping to change at page 27, line 24 skipping to change at page 29, line 24
: | | : : | | :
: | | : : | | :
: | | : : | | :
: | | : : | | :
: +-----------------+ : : +-----------------+ :
: : : :
:.................................: :.................................:
Figure 4 - ETH Abstract Topology exposed at MPI1 (MPI1 ETH Topology) Figure 4 - ETH Abstract Topology exposed at MPI1 (MPI1 ETH Topology)
As described in section 4.1, it is assumed that the OTU4 trails on The OTU4 trails on the inter-domain physical links (e.g., the link
the inter-domain physical links (e.g., the link between S2 and S31) between S2 and S31) are pre-provisioned and exposed as external TE
are pre-configured and exposed as external TE Links, within the MPI1 Links, within the MPI1 OTN topology (e.g., the external TE Link
OTN topology (e.g., the external TE Link terminating on AN1-7 TE terminating on AN1-7 TE Link Termination Point (LTP) abstracting the
Link Termination Point (LTP) abstracting the OTU4 trail between S2 OTU4 trail between S2 and S31).
and S31).
In order to analyze the service scenarios of sections 4.3 and 4.4:
o the access link between S3 and R1 is assumed to be a
multi-function access link, which can be configured as an OTU2
trail or as an STM-64 or a 10GE physical link;
o the access link between S6 and R2 is assumed to be pre-configured
as a 10GE physical link, up to the MAC layer;
o the access link between S6 and R3 is assumed to be a
multi-function access link which can be configured as an OTU2
trail or as an STM-64 physical link;
o the access link connected to router R4 is assumed to be
pre-configured as an STM-64 physical link.
Therefore PNC1 exports at MPI1 the following external TE Links, The PNC1 exports at MPI1 the following external TE Links, within the
within the MPI1 OTN topology: MPI1 OTN topology, representing the multi-function access links
under its control:
o two abstract TE Links, terminating on LTP AN1-1 and AN1-2 o 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 o 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.
skipping to change at page 28, line 28 skipping to change at page 30, line 10
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 abstracting the physical access link between S3 and R1 and the
access link between S6 and R2 respectively, reporting that they can access link between S6 and R2 respectively, reporting that they can
support Ethernet client signal with port-based and VLAN-based support Ethernet client signal with port-based and VLAN-based
classifications. The PNC1 native topology would represent the classifications.
physical network topology of the domain controlled by the PNC, as
shown in Figure 5. PNC1 should expose at MPI1 also the ODU termination and adaptation
resources which are available to carry client signals (e.g.,
Ethernet or STM-N) over OTN. This information is reported by the
Tunnel Termination Points (TTPs) within the MPI1 OTN Topology.
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
will assign a transition link or an inter-layer lock identifier,
which is unique across all the TE Topologies PNC1 is exposing at
MPI1, to each TTP and access link's LTP pair.
For simplicity purposes, this document assigns the same number to
the LTP-ID, TTP-ID and ILL-ID that corresponds to the same access
link (i.e., 1, 2, 3 and 8 respectively for the LTP, TTP and
Inter-Layer Lock (IIL) corresponding with the access links AN1-1,
AN1-2, AN1-3 and AN1-8).
The PNC1 native topology would represent the physical network
topology of the domain controlled by the PNC, as shown in Figure 5.
.................................. ..................................
: : : :
: Physical Topology @ PNC1 : : Physical Topology @ PNC1 :
: : : :
: +----+ +----+ : : +----+ +----+ :
: | |S1-1 | |S2-3: : | |S1-1 | |S2-3:
: | S1 |--------| S2 |----- - -(S31) : | S1 |--------| S2 |----- - -(S31)
: +----+ S2-1+----+ : : +----+ S2-1+----+ :
: S1-2/ |S2-2 : : S1-2/ |S2-2 :
skipping to change at page 30, line 21 skipping to change at page 32, line 21
S6-3 AN1-3 S6-3 AN1-3
S7-3 AN1-4 S7-3 AN1-4
S8-4 AN1-5 S8-4 AN1-5
S8-5 AN1-6 S8-5 AN1-6
Appendix B.1.1 provides the detailed JSON code example ("mpi1-otn- Appendix B.1.1 provides the detailed JSON code example ("mpi1-otn-
topology.json") describing how the MPI1 ODU Topology is reported by topology.json") describing how the MPI1 ODU Topology is reported by
the PNC1, using the [RFC8345], [TE-TOPO] and [OTN-TOPO] YANG models, the PNC1, using the [RFC8345], [TE-TOPO] and [OTN-TOPO] YANG models,
at MPI1. at MPI1.
Appendix B.1.2 provides the detailed JSON code example ("mpi1-eth-
topology.json") describing how the MPI1 ETH Topology is reported by
the PNC1, using the [RFC8345], [TE-TOPO] and [CLIENT-TOPO] YANG
models, at MPI1.
It is worth noting that this JSON code example does not provide all It is worth noting that this JSON code example does not provide all
the attributes defined in the relevant YANG models, including: the attributes defined in the relevant YANG models, including:
o YANG attributes which are outside the scope of this document are o YANG attributes which are outside the scope of this document are
not shown; not shown;
o The attributes describing the set of label values that are o 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;
skipping to change at page 30, line 47 skipping to change at page 33, line 9
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.2, to expose to the MDSC, at MPI2, two TE Topology
instances with only one TE node each: instances with only one TE node each:
o the first instance reports the domain 2 OTN abstract topology o the first instance reports the domain 2 OTN abstract topology
view (MPI2 OTN Topology), with only one abstract node (i.e., AN2) view (MPI2 OTN Topology), with only one abstract node (i.e., AN2)
and only inter-domain and access abstract TE links (which and 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 and/or transparent client layers); links which can support ODU, or transparent client layers or
both);
o the instance reports the domain 2 Ethernet abstract topology view o 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
are available to carry client signals (e.g., Ethernet or STM-N) over
OTN in the TTPs within the MPI2 OTN Topology.
In particular, PNC2 reports in both the MPI2 OTN Topology and MPI2
ETH Topology an AN2-1 access link which abstracts the multi-function
physical access link between S18 and R8, which is assumed to
correspond to the S18-3 LTP, within the PNC2 native topology. It
also reports in the MPI2 ETH Topology a TTP which abstracts the ODU
termination and adaptation resources dedicated to this physical
access link and the inter-layer lock between this 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.2, to expose to the MDSC, at MPI3, two TE Topology
instances with multiple TE nodes, one for each physical node: instances with multiple TE nodes, one for each physical node:
o the first instance reports the domain 3 OTN topology view (MPI3 o 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 o 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 represent the two edge physical nodes (i.e., S31 and S33) and
only the two access TE links which represent the access physical only the two access TE links which represent the access physical
links. links.
PNC3 also reports the ODU termination and adaptation resources which
are available to carry client signals (e.g., Ethernet or STM-N) over
OTN in the TTPs within the MPI3 OTN Topology.
5.1.4. Multi-domain Topology Merging 5.1.4. Multi-domain Topology Merging
As assumed at the beginning of this section, MDSC does not have any MDSC does not have any knowledge of the topologies of each domain
knowledge of the topologies of each domain until each PNC reports until each PNC reports its own abstract topologies, so the MDSC
its own abstract topologies, so the MDSC needs to merge together needs to merge these abstract topologies, provided by different
these abstract topologies, provided by different PNCs, to build its PNCs, to build its own topology view of the multi-domain network
own topology view of the multi-domain network (MDSC multi-domain (MDSC multi-domain native topology), as described in section 4.3 of
native topology), as described in section 4.3 of [TE-TOPO]. [TE-TOPO].
Given the topologies reported from multiple PNCs, the MDSC need to The topology of each domain may be in an abstracted shape (refer to
merge them into its multi-domain native topology. The topology of section 5.2 of [RFC8453] for a different level of abstraction),
each domain may be in an abstracted shape (refer to section 5.2 of while the inter-domain link information must be complete and fully
[RFC8453] for a different level of abstraction), while the inter- configured by the MDSC.
domain link information must be complete and fully configured by the
MDSC.
The inter-domain link information is reported to the MDSC by the two The inter-domain link information is reported to the MDSC by the two
PNCs, controlling the two ends of the inter-domain link. PNCs, controlling the two ends of the inter-domain link.
The MDSC needs to understand how to merge together these inter- The MDSC needs to know how to merge these inter-domain links. One
domain links. possibility is to use the plug-id information, defined in [TE-TOPO]:
two inter-domain TE links, within two different MPI abstract
One possibility is to use the plug-id information, defined in [TE-
TOPO]: two inter-domain TE links, within two different MPI abstract
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 In case the plug-id values are assigned by a central authority, it
is under the central authority responsibility to assign unique is under the central authority responsibility to assign unique
values. values.
In case the plug-id values are automatically discovered, the In case the plug-id values are automatically discovered, the
information discovered by the automatic discovery mechanisms needs information discovered by the automatic discovery mechanisms needs
to be encoded as a bit string within the plug-id value. This to be encoded as a bit string within the plug-id value. This
encoding is implementation specific, but the encoding rules need to encoding is implementation-specific, but the encoding rules need to
be consistent across all the PNCs. be consistent across all the PNCs.
In case of co-existence within the same network of multiple sources In case of co-existence within the same network of multiple sources
for the plug-id (e.g., central authority and automatic discovery or for the plug-id (e.g., central authority and automatic discovery or
even different automatic discovery mechanisms), it is needed that even different automatic discovery mechanisms), it is needed that
the plug-id namespace is partitioned to avoid that different sources the plug-id namespace is partitioned to avoid that different sources
assign the same plug-id value to different inter-domain 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 implementation specific and will need to be consistent across all
the PNCs. the 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.
Based on the plug-id values, the MDSC can merge together the For example, this document assumes that the following plug-id values
abstract topologies exposed by the underlying PNCs, as described in are assigned, by administrative configuration, to the inter-domain
sections 5.1.1, 5.1.2 and 5.1.3 above, into its multi-domain native links shown in Figure 1:
TE topology as shown in Figure 6.
Inter-Domain Link Plug-ID Value
S2-S31 0x000231
S7-S11 0x000711
S8-S12 0x000812
S8-S32 0x000832
S12-S32 0x001232
S15-S34 0x001534
Based on the plug-id values, the MDSC can merge the abstract
topologies exposed by the underlying PNCs, as described in sections
5.1.1, 5.1.2 and 5.1.3 above, into its multi-domain native TE
topology, as shown in Figure 6.
........................ ........................
: : : :
: Network domain 1 : ............. : Network domain 1 : .............
: Black Topology : : : : Black Topology : : :
: Abstraction : : Network : : Abstraction : : Network :
: AN1-1 : : domain 3 : : AN1-1 : : domain 3 :
(R1)- - ----------+ : : (White) : (R1)- - ----------+ : : (White) :
: \ +--------------+ : : \ +--------------+ :
(R2)- - ---------+ + / : : \ : (R2)- - ---------+ + / : : \ :
skipping to change at page 33, line 42 skipping to change at page 36, line 42
: 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
setup different multi-domains services, as described in section 4.3,
using the TE Tunnel YANG model, defined in [TE-TUNNEL], with the OTN
technology-specific augmentations, defined in [OTN-TUNNEL] with the
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 is (e.g., L1CSM, L2SM, VN) is outside the scope of this
document. document, but it is assumed that the CMI YANG models provide all the
information that allows the MDSC to understand that it needs to
As described in section 4.3, it is assumed that the CMI YANG models coordinate the setup of a multi-domain ODU data plane connection
provide all the information that allows the MDSC to understand that (which can be either an end-to-end connection or a segment
it needs to coordinate the setup of a multi-domain ODU data plane connection) and, when needed, also the configuration of the
connection (which can be either an end-to-end connection or a
segment connection) and, when needed, also the configuration of the
adaptation functions in the edge nodes belonging to different adaptation functions in the edge nodes belonging to different
domains. domains.
| |
| {1} | {1}
V V
---------------- ----------------
| {2} | | {2} |
| {3} MDSC | | {3} MDSC |
| | | |
skipping to change at page 35, line 6 skipping to change at page 38, line 43
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
transport 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 According to the different client signal types, different
adaptations can be required to be configured at the edge nodes adaptations can be required to be configured at the edge nodes
(i.e., S3 and S18). (i.e., S3 and S18).
After receiving such request, MDSC determines the domain sequence, After receiving such request, MDSC determines the domain sequence,
i.e., domain 1 <-> domain 3 <-> domain 2, with corresponding PNCs i.e., domain 1 <-> domain 3 <-> domain 2, with corresponding PNCs
and the inter-domain links (step 2 in Figure 7). and the inter-domain links (step 2 in Figure 7).
As described in [PATH-COMPUTE], the domain sequence can be As described in [PATH-COMPUTE], the domain sequence can be
determined by running the MDSC own path computation on the MDSC determined by running the MDSC own path computation on the MDSC
native topology, defined in section 5.1.4, if and only if the MDSC native topology, defined in section 5.1.4, if and only if the MDSC
has enough topology information. Otherwise, the MDSC can send path has enough topology information. Otherwise, the MDSC can send path
computation requests to the different PNCs (steps 2.1, 2.2 and 2.3 computation requests to the different PNCs (steps 2.1, 2.2 and 2.3
in Figure 7) and use this information to determine the optimal path in Figure 7) and use this information to determine the optimal path
on its internal topology and therefore the domain sequence. on its internal topology and therefore the domain sequence.
The MDSC will then decompose the tunnel request into a few tunnel The MDSC will then decompose the tunnel request into a few TE tunnel
segments via tunnel models (both technology agnostic TE tunnel model segments and request different PNCs to setup each intra-domain TE
and OTN tunnel model), and request different PNCs to setup each tunnel segment (steps 3, 3.1, 3.2 and 3.3 in Figure 7).
intra-domain 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 tunnel segment and inter-domain tunnel via corresponding MPI domain TE tunnel segments and inter-domain TE tunnel hand-off via
(via TE tunnel model and OTN tunnel model) through all the PNCs corresponding MPI (using the TE tunnel YANG model defined in
controlling the domains selected during path computation. More [TE-TUNNEL] and the OTN tunnel YANG model augmentations defined in
specifically, for the inter-domain tunnel hand-off, taking into [OTN-TUNNEL]) through all the PNCs controlling the domains selected
account that the inter-domain links are all OTN links, the list of during path computation. More specifically, for the inter-domain TE
timeslots and the TPN value assigned to that ODUk connection at the tunnel hand-off, taking into account that the inter-domain links are
inter-domain link needs to be configured by the MDSC. all OTN links, the list of timeslots and the TPN value assigned to
that ODUk connection at the inter-domain link needs to be configured
by the MDSC.
The configuration of the timeslots and the TPN value used by the
ODU2 connection on the internal links within a PNC domain (i.e., on
the internal links within domain1) is outside the scope of this
document, since it is a matter of the PNC domain internal
implementation.
However, the configuration of the timeslots used by the ODU2
connection at the transport network domain boundaries (e.g., on the
inter-domain links) needs to take into account the timeslots
available on physical nodes belonging to different PNC domains
(e.g., on node S2 within PNC1 domain and node S31 within PNC3
domain). Each PNC provides to the MDSC, at the MPI, the list of
available timeslots on the inter-domain links using the TE Topology
YANG model and OTN Topology augmentation. The TE Topology YANG model
in [TE-TOPO] is being updated to report the label set information.
See section 1.7 of [TE-TUTORIAL] for more details.
The MDSC, when coordinating the setup of a multi-domain ODU
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
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
OTN Topology information exposed, at the MPIs, by the PNCs
controlling the OTN physical nodes (e.g., PNC1 and PNC3 controlling
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.
5.2.1. ODU Transit Service 5.2.1. ODU Transit Service
In this scenario, described in section 4.3.1, the physical access In this scenario, described in section 4.3.1, the physical access
links are configured as 10G OTN links and, as described in section links are configured as 10G OTN links and, as described in section
5.1, reported by each PNC as TE Links within the OTN abstract 5.1, reported by each PNC as TE Links within the OTN abstract
topologies they expose to the MDSC. topologies they expose to the MDSC.
To setup this IP link, between R1 and R8, the CNC requests, at the When an IP link, between R1 and R8 is needed, the CNC requests, at
CMI, the MDSC to setup an ODU transit service. the CMI, the MDSC to setup an ODU transit service.
From its native topology, shown in Figure 6, the MDSC understands, From its native topology, shown in Figure 6, the MDSC understands,
by means which are outside the scope of this document, that R1 is by 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 OTN attached to the access link terminating on AN1-1 LTP in the MPI1 OTN
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 MDSC then performs multi-domain path computation (step 2 in Figure
7) and requests PNC1, PNC2 and PNC3, at MPI1, MPI2 and MPI3 7) and requests PNC1, PNC2 and PNC3, at MPI1, MPI2 and MPI3
skipping to change at page 36, line 35 skipping to change at page 41, line 12
Abstract Topologies they expose (MPI1 OTN Abstract Topology, MPI2 Abstract Topologies they expose (MPI1 OTN Abstract Topology, MPI2
OTN Abstract Topology and MPI3 OTN Abstract Topology, respectively). OTN Abstract Topology and MPI3 OTN Abstract Topology, respectively).
MDSC requests, at MPI1, PNC1 to setup an ODU2 (Transit Segment) 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 4), using the TE Tunnel YANG MPI1 OTN Abstract Topology (Figure 4), 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 o Source and Destination TTPs are not specified (since it is a
Transit Tunnel) Transit Tunnel): i.e., the source, src-tp-id, destination and
dst-tp-id attributes of the TE tunnel instance are empty
o Ingress and egress points are indicated in the route-object- o Ingress and egress points are indicated in the route-object-
include-exclude list of the explicit-route-objects of the primary include-exclude list of the explicit-route-objects of the primary
path: path:
o The first element references the access link terminating on o The first element references the access link terminating on
AN1-1 LTP AN1-1 LTP
o The last two element reference respectively the inter-domain o 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.
The configuration of the timeslots used by the ODU2 connection on
the internal links within a PNC domain (i.e., on the internal links
within domain1) is outside the scope of this document since it is a
matter of the PNC domain internal implementation.
However, the configuration of the timeslots used by the ODU2
connection at the transport network domain boundaries (e.g., on the
inter-domain links) needs to take into account the timeslots
available on physical nodes belonging to different PNC domains
(e.g., on node S2 within PNC1 domain and on node S31 within PNC3
domain).
The MDSC, when coordinating the setup of a multi-domain ODU
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
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
OTN Topology information exposed, at the MPIs, by the PNCs
controlling the OTN physical nodes (e.g., PNC1 and PNC3 controlling
the physical nodes S2 and S31 respectively).
Appendix B.2.1 provides the detailed JSON code ("mpi1-odu2-service- Appendix B.2.1 provides the detailed JSON code ("mpi1-odu2-service-
config.json") describing how the setup of this ODU2 (Transit config.json") describing how the setup of this ODU2 (Transit
Segment) Tunnel can be requested by the MDSC, using the [TE-TUNNEL] Segment) Tunnel can be requested by the MDSC, using the [TE-TUNNEL]
and [OTN-TUNNEL] YANG models at MPI1. and [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, as shown in section 4.3.1. 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 also configures the OTU2 trail before setting up the ODU2
cross-connection in node S3. cross-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
the TPN), to be used by this ODU2 connection on the S2-S31 the TPN), to be used by this ODU2 connection on the S2-S31 inter-
inter-domain link, as requested by the MDSC. domain link, as requested by the MDSC.
Following similar requests from MDSC to setup ODU2 (Transit Segment) Following similar requests from MDSC to setup ODU2 (Transit Segment)
Tunnels within the OTN Abstract Topologies they expose, PNC2 then Tunnels within the OTN Abstract Topologies they expose, PNC2 then
sets up ODU2 cross-connections on nodes S31 and S33 while PNC3 sets sets up ODU2 cross-connections on nodes S31 and S33 while PNC3 sets
up ODU2 cross-connections on nodes S15 and S18, as shown in section up ODU2 cross-connections on nodes S15 and S18. PNC2 also configures
4.3.1. PNC2 also configures the OTU2 trail on the S18-R8 the OTU2 trail on the S18-R8 multi-function access link.
multi-function access link.
5.2.1.1. Single Domain Example 5.2.1.1. Single Domain Example
To setup an ODU2 end-to-end connection, supporting an IP link, To setup an ODU2 end-to-end connection, supporting an IP link,
between R1 and R3, the CNC requests, at the CMI, the MDSC to setup between R1 and R3, the CNC requests, at the CMI, the MDSC to setup
an ODU transit service. an ODU transit service.
Following the procedures described in section 5.2.1, MDSC requests Following the procedures described in section 5.2.1, MDSC requests
only PCN1 to setup the ODU2 (Transit Segment) Tunnel between the only PCN1 to setup the ODU2 (Transit Segment) Tunnel between the
access links terminating on AN-1 and AN1-2 LTPs within the MPI1 access links terminating on AN-1 and AN1-2 LTPs within the MPI1
Abstract Topology and PNC1 sets up ODU2 cross-connections on nodes Abstract Topology and PNC1 sets up ODU2 cross-connections on nodes
S3, S5 and S6, as shown in section 4.3.1. PNC1 also configures the S3, S5 and S6. PNC1 also configures the OTU2 trails on the R1-S3 and
OTU2 trails on the R1-S3 and R3-S6 multi-function access links. R3-S6 multi-function access links.
5.2.2. EPL over ODU Service 5.2.2. EPL over ODU Service
In this scenario, described in section 4.3.2, the access links are In this scenario, described in section 4.3.2, the access links are
configured as 10GE Links and, as described in section 5.1, reported configured as 10GE Links and, as described in section 5.1, reported
by each PNC as TE Links within the ETH abstract topologies they by each PNC as TE Links within the ETH abstract topologies they
expose to the MDSC. expose to the MDSC.
To setup this IP link, between R1 and R8, the CNC requests, at the When this IP link, between R1 and R8, is needed, the CNC requests,
CMI, the MDSC to setup an EPL service. at the CMI, the MDSC to setup an EPL service.
From its native topology, shown in Figure 6, the MDSC understands, From its native topology, shown in Figure 6, the MDSC understands,
by means which are outside the scope of this document, that R1 is by 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.
The MDSC also understands that it needs to coordinate the setup of a As described in sections 5.1.1 and 5.1.2:
multi-domain ODU2 Tunnel between the TTPs, abstracting nodes S3 and
S18 within the OTN Abstract Topologies exposed by PNC1 and PNC2, o the AN1-1 LTP, within the MPI1 ETH Abstract Topology, and the
respectively. AN1-1 TTP, within the MPI1 OTN Abstract Topology, have the same
IIL identifier (within the scope of MPI1);
o the AN2-1 LTP, within the MPI2 ETH Abstract Topology, and the
AN2-1 TTP, within the MPI2 OTN Abstract Topology, have the same
IIL identifier (within the scope of MPI2).
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,
abstracting S3-1 and S18-3 TTPs, within the OTN Abstract Topologies
exposed by PNC1 and PNC2, respectively.
MDSC then performs multi-domain path computation (step 2 in Figure MDSC then performs multi-domain path computation (step 2 in Figure
7) and then requests: 7) and then requests:
o PNC1, at MPI1, to setup an ODU2 (Head Segment) Tunnel within the o 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 o 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;
skipping to change at page 39, line 23 skipping to change at page 43, line 35
the MPI3 OTN Abstract Topology; the MPI3 OTN Abstract Topology;
o PNC2, at MPI2, to setup ODU2 (Tail Segment) Tunnel within the o PNC2, at MPI2, to setup ODU2 (Tail Segment) Tunnel within the
MPI2 OTN Abstract Topology; MPI2 OTN Abstract Topology;
o PNC2, at MPI2, to steer the Ethernet client traffic to/from AN2-1 o 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 source TTP and AN1-7 LTP, within with one primary path between the AN1-1 TTP and AN1-7 LTP, within
the MPI1 OTN Abstract Topology (Figure 4), using the TE Tunnel YANG the MPI1 OTN Abstract Topology (Figure 4), 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 is specified (since it is a Head Segment o Only the Source TTP (i.e., AN1 TE-Node and AN1-1 TTP) is
Tunnel): therefore the Destination TTP is not specified specified (since it is a Head Segment Tunnel): therefore the
Destination TTP is not specified
o The egress point in indicated in the route-object-include-exclude o 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:
o The last two element reference respectively the inter-domain o 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.2 provides the detailed JSON code ("mpi1-odu2-tunnel- Appendix B.2.2 provides the detailed JSON code ("mpi1-odu2-tunnel-
config.json") describing how the setup of this ODU2 (Head Segment) config.json") describing how the setup of this ODU2 (Head Segment)
Tunnel can be requested by the MDSC, using the [TE-TUNNEL] and [OTN- Tunnel can be requested by the MDSC, using the [TE-TUNNEL] and [OTN-
TUNNEL] YANG models at MPI1. TUNNEL] YANG models at MPI1.
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].
Appendix B.2.3 provides the detailed JSON code ("mpi1-epl-service- Appendix Error! Reference source not found. provides the detailed
config.json") describing how the setup of this EPL service using the JSON code ("mpi1-epl-service-config.json") describing how the setup
ODU2 Tunnel can be requested by the MDSC, using the [CLIENT-SIGNAL] of this EPL service using the ODU2 Tunnel can be requested by the
YANG model at MPI1. MDSC, using the [CLIENT-SIGNAL] YANG model at MPI1.
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
tunnel source TTP and AN1-7 LTP, within the MPI1 OTN Abstract AN1-1 TTP and the AN1-7 LTP, within the MPI1 OTN Abstract Topology
Topology it exposes at MPI1, correspond to node S3 and S2-3 LTP, it exposes at MPI1, correspond to S3-1 TTP and S2-3 LTP,
respectively, within its native topology. Therefore it performs path respectively, within its native topology. Therefore it performs path
computation, for an ODU2 connection between node S3 and S2-3 LTP computation, for an ODU2 connection between S3-1 TTP and S2-3 LTP
within its native topology, and sets up the ODU2 cross-connections within its native topology, and sets up the ODU2 cross-connections
within the physical nodes S3, S1 and S2, as shown in section 4.3.2. within the physical nodes S3, S1 and S2, as shown in section 4.3.2.
As part of the OUD2 cross-connection configuration in node S2, PNC1 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
the TPN), to be used by this ODU2 connection on the S2-S31 the TPN), to be used by this ODU2 connection on the S2-S31 inter-
inter-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, After the configuration of the ODU2 cross-connection in node S3,
PNC1 also configures the [ETH -> (ODU)] and [(ODU2) -> ETH] PNC1 also configures the [ETH -> (ODU)] and [(ODU2) -> ETH]
adaptation functions, within node S3, as shown in section 4.3.2. adaptation functions, within node S3, as shown in section 4.3.2.
Since the R1-S3 access link is a multi-function access link, PNC1 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-connections on nodes S31 and S33 while PNC2 sets up ODU2
cross-connections on nodes S15 and S18 as well as the [ETH -> cross-connections on nodes S15 and S18 as well as the [ETH ->
(ODU2)] and [(ODU2) -> ETH] adaptation functions in node S18, as (ODU2)] and [(ODU2) -> ETH] adaptation functions in node S18, as
shown in section 4.3.2. PNC2 also configures the 10GE link on the shown in section 4.3.2. PNC2 also configures the 10GE link on the
S18-R8 multi-function access link. S18-R8 multi-function access link.
5.2.2.1. Single Domain Example 5.2.2.1. Single Domain Example
To setup this IP link, between R1 and R2, the CNC requests, at the When this IP link, between R1 and R2, is needed, the CNC requests,
CMI, the MDSC to setup an EPL service. at 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 TTPs, abstracting o Setup an ODU2 (end-to-end) Tunnel between the AN1-1 and AN1-2
nodes S3 and S6 within MPI1 OTN Abstract Topology exposed by PNC1 TTPs, abstracting S3-1 and S6-1 TTPs, within the MPI1 OTN
at MPI1; Abstract Topology exposed by PNC1 at MPI1;
o steer the Ethernet client traffic between the AN1-1 and AN1-8 o 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-configured as a 10GE link). access link has been pre-provisioned as a 10GE link, as described in
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, configured as STM-64 links and, as described in section 5.1,
reported by each PNC as TE Links within the OTN Abstract Topologies reported by each PNC as TE Links within the OTN Abstract Topologies
they expose to the MDSC. they 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, MDSC
understands that: understands that:
o R1 is attached to the access link terminating on AN1-1 LTP in the o 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 o it needs to coordinate the setup of a multi-domain ODU2 Tunnel
between the TTPs, abstracting nodes S3 and S18 within the OTN between the AN1-1 and AN2-1 TTPs, abstracting S3-1 and S18-3
Abstract Topologies exposed by PNC1 and PNC2, respectively. TTPs, within the OTN Abstract Topologies exposed by PNC1 and
PNC2, 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 o 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 o 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;
skipping to change at page 42, line 28 skipping to change at page 46, line 44
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
To setup this IP link, between R1 and R3, the CNC requests, at the When this IP link, between R1 and R3, is needed, the CNC requests,
CMI, the MDSC to setup an STM-64 Private Line service. at the CMI, the MDSC to setup an STM-64 Private Line service.
The MDSC and PNC1 follows similar procedures as described in section The MDSC and PNC1 follows similar procedures as described in section
5.2.2.1 to set up ODU2 cross-connections on nodes S3, S5 and S6 as 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 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
skipping to change at page 43, line 11 skipping to change at page 47, line 26
Following similar procedures as described in section 5.2.2 and Following similar procedures as described in section 5.2.2 and
5.2.2.1, MDSC understands that: 5.2.2.1, MDSC understands that:
o R1 and R2 are attached to the access links terminating o 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 o 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 TTPs, abstracting nodes S3 and S6 within the Tunnel between the AN1-1 and AN1-8 TTPs, abstracting S3-1 and
OTN Abstract Topology exposed by PNC1; S6-1 TTPs, within the OTN Abstract Topology exposed by PNC1;
o to setup the second (multi-domain) EPVL service, between R1 and o To setup the second (multi-domain) EPVL service, between R1 and
R8, it needs to coordinate the setup of a multi-domain ODU0 R8, it needs to coordinate the setup of a multi-domain ODU0
Tunnel between the TTPs, abstracting nodes S3 and S18 within the Tunnel between the AN1-1 and AN2-1 TTPs, abstracting nodes S3-1
OTN Abstract Topologies exposed by PNC1 and PNC2, respectively. and S18-3 TTPs, within the OTN Abstract Topologies exposed by
PNC1 and PNC2, 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 section the MDSC and PNC1 follows similar procedures as described in section
5.2.2.1 to set up ODU0 cross-connections on nodes S3, S5 and S6 as 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 well as the [VLAN -> (ODU0)] and [(ODU0) -> VLAN] adaptation
functions, in nodes S3 and S6, as shown in section 4.3.4. PNC1 also functions, in nodes S3 and S6, as shown in section 4.3.4. PNC1 also
configures the 10GE link on the R1-S3 multi-function access link. 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 functions configurations in nodes S2 and S6, PNC1 configures also
skipping to change at page 44, line 12 skipping to change at page 48, line 29
respectively, PNC2 configure also the classification rules required respectively, PNC2 configure also the classification rules required
to associated only the Ethernet client traffic received with VLAN ID to associated only the Ethernet client traffic received with VLAN ID
20 on the R1-S3 and R8-S18 access links with this EVPL service. The 20 on the R1-S3 and R8-S18 access links with this EVPL service. The
MDSC provides this information to PNC1 and PNC2 using the MDSC provides this information to PNC1 and PNC2 using the
[CLIENT-SIGNAL] model. [CLIENT-SIGNAL] model.
5.3. YANG Models for Protection Configuration 5.3. YANG Models for Protection Configuration
5.3.1. Linear Protection (end-to-end) 5.3.1. Linear Protection (end-to-end)
To be discussed in future versions of this document. As described in section 4.5.1, the MDSC can decide to protect a
multi-domain connectivity service by setting up ODU linear
protection switching between edge nodes controlled by different PNCs
(e.g., nodes S3 and S8, controlled by PNC1 and PNC2 respectively, to
protect services between R1 and R8).
MDSC performs path computation, as described in section 5.2, to
compute both the paths for working and protection transport
entities: the computed paths can pass through these same PNC domains
or through different transit PNC domains.
Considering the case, described in section 4.5.1, where the working
and protection transport entities pass through the same domain, MDSC
would perform the same steps described in section 5.2 to setup the
ODU Tunnel and to configure the steering of the client traffic
between the access links and the ODU Tunnel. The only differences
are in the configuration of the ODU Tunnels.
MDSC requests at the MPI1, PNC1 to setup an ODU2 (Head Segment)
Tunnel within the MPI1 OTN Abstract Topology (Figure 4), using the
TE Tunnel YANG model, defined in [TE-TUNNEL], with the OTN
technology-specific augmentations, defined in [OTN-TUNNEL], with one
primary path and one secondary path with1+1 protection switching
enabled:
o 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;
o The egress point for the working transport entity in indicated in
the route-object-include-exclude list of the explicit-route-
objects of the primary path, as described in section 5.2.2;
o The protection switching end-point in indicated in the route-
object-include-exclude list of the explicit-route-objects of the
secondary path:
o The first element references the TE-Node of the Source TTP
(i.e., AN1 TE-Node);
o The egress point for the protection transport entity in indicated
in the route-object-include-exclude list of the explicit-route-
objects of the secondary path:
o The last two element reference respectively the inter-domain
link terminating on AN1-6 LTP and the data plane resources
(i.e., the list of timeslots and the TPN) used by the ODU2
connection over that link.
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
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
understands, from the route-object-include-exclude list of the
explicit-route-objects of the secondary path configuration (whose
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
outside of its control domain.
PNC1 can performs path computation within its native topology and
setup the ODU connections in nodes S3, S1, S2, S4 and S8 as well as
configure the protection group in node S3.
5.3.2. Segmented Protection
Under specific policies, it is possible to deploy a segmented
protection for multi-domain services. The configuration of the
segmented protection can be divided into a few steps, considering
the example in section 4.5.2, the following steps would be used.
MDSC performs path computation, as described in section 5.2, to
compute all the paths for working and protection transport entities,
which pass through the same PNC domains and inter-domain links: the
MDSC would perform the same steps described in section 5.2 to setup
the ODU Tunnel and to configure the steering of the client traffic
between the access links and the ODU Tunnel. The only differences
are in the configuration of the ODU Tunnels.
MDSC requests at the MPI1, PNC1 to setup an ODU2 (Head Segment)
Tunnel within the MPI1 OTN Abstract Topology (Figure 4), using the
TE Tunnel YANG model, defined in [TE-TUNNEL], with the OTN
technology-specific augmentations, defined in [OTN-TUNNEL], with one
primary 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
Head Segment Tunnel), as described in section 5.2.2;
o The egress point (i.e., AN1-7 LTP) is indicated in the route-
object-include-exclude list of the explicit-route-objects of the
primary path, as described in section 5.2.2;
o The protection switching end-points are indicated in the route-
object-include-exclude list of the explicit-route-objects of the
secondary path:
o The first element references the TE-Node of the Source TTP
(i.e., AN1 TE-Node);
o The last element references the TE-Node of the egress point
(i.e., AN1 TE-Node).
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,
correspond to S3-1 TTP and the S2-3 LTP, respectively, within its
native topology. It also understands, from the route-object-include-
exclude list of the explicit-route-objects of the secondary path
configuration (whole last element represent an abstract node
terminating the inter-domain link used for the primary path), that
the protection group should be terminated in nodes S3 and S2.
PNC1 will perform path computations using its native topology and
setup the ODU connections in nodes S3, S1, S2, S4 and S8 as well as
configure the protection group in nodes S3 and S2.
Following similar requests from MDSC to setup ODU2 (Segment)
Tunnels, with segment protection, within the OTN Abstract Topologies
they expose. PNC3 then sets up ODU2 cross-connections on nodes S31,
S32, 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 segment protection between nodes S15 and S18.
MDSC stitch the configuration above to form its internal view of the
end-to-end tunnel with segmented protection.
Given the configuration above, the protection capability has been
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
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 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 in this example) will not be aware of the failure and
switching, nor do the nodes in Network domain 2 and 3.
5.4. Notifications 5.4. Notifications
Further detailed analysis is outside the scope of this document Notification mechanisms are required for the scenarios analyzed in
this draft, as described in section 4.6.
The notification mechanisms are protocol-dependent. It is assumed
that the RESTCONF protocol, defined in [RFC8040], is used at the
MPIs mentioned in this document.
On the perspective of MPI, the MDSC is the client while the PNC is
acting as the server of the notification. The essential event
streams, subscription and processing rules after receiving
notification can be found in section 6 of [RFC8040].
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- using the IETF YANG models defined in [TE-TUNNEL] and [PATH-
COMPUTE]. 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 defined by the IETF to support OTN single and multi-domain
scenarios. scenarios.
When deploying ACTN functional components the securing of external
interfaces and hardening of resource datastores, the protection of
confidential information, and limiting the access of function,
should all be carefully considered. Section 9 of [RFC8453]
highlights that implementations should consider encrypting data that
flows between key components, especially when they are implemented
at remote node. Further discussion on securing the interface between
the MDSC and PNCs via the MDSC-PNC Interface (MPI) is discussed in
section 9.2 of [RFC8453].
The YANG modules highlighted in this document are designed to be
accessed via network configuration protocols such as NETCONF
[RFC6241] or RESTCONF [RFC8040]. When using NETCONF, utilizing a
secure transport via Secure Shell (SSH) [RFC6242] is mandatory. If
using RESTCONF, then secure transport via TLS [RFC8446] is
mandatory. When using either NETCONF or RESTCONF, the use of Network
Configuration Access Control Model (NACM) [RFC8341] may be used to
restrict access to specific protocol operations and content.
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 In OTN the (General Communication Channel) GCC is used for OAM
functions such as performance monitoring, fault detection, and functions such as performance monitoring, fault detection, and
signaling. The GCC control channel should be secured using a signaling. The GCC control channel should be secured using a
suitable mechanism. suitable mechanism.
There are no additional or new security considerations introduced by
this document.
7. IANA Considerations 7. IANA Considerations
This document requires no IANA actions. This document requires no IANA actions.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC4427] Mannie, E., Papadimitriou, D., "Recovery (Protection and [RFC4427] Mannie, E., Papadimitriou, D., "Recovery (Protection and
Restoration) Terminology for Generalized Multi-Protocol Restoration) Terminology for Generalized Multi-Protocol
skipping to change at page 45, line 40 skipping to change at page 53, line 42
[RFC8453] Ceccarelli, D., Lee, Y. et al., "Framework for Abstraction [RFC8453] Ceccarelli, D., Lee, Y. et al., "Framework for Abstraction
and Control of TE Networks (ACTN)", RFC8453, August 2018. and Control of TE Networks (ACTN)", RFC8453, August 2018.
[ITU-T G.709] ITU-T Recommendation G.709 (06/16), "Interfaces for [ITU-T G.709] ITU-T Recommendation G.709 (06/16), "Interfaces for
the optical transport network", June 2016. the optical transport network", June 2016.
[ITU-T G.808.1] ITU-T Recommendation G.808.1 (05/14), "Generic [ITU-T G.808.1] ITU-T Recommendation G.808.1 (05/14), "Generic
protection switching - Linear trail and subnetwork protection switching - Linear trail and subnetwork
protection", May 2014. protection", May 2014.
[ITU-T G.873.1] ITU-T Recommendation G.873.1 (05/14), "Optical [ITU-T G.873.1] ITU-T Recommendation G.873.1 (10/17), "Optical
transport network (OTN): Linear protection", May 2014. transport network (OTN): Linear protection", October 2017.
[TE-TOPO] Liu, X. et al., "YANG Data Model for TE Topologies", [TE-TOPO] Liu, X. et al., "YANG Data Model for TE Topologies",
draft-ietf-teas-yang-te-topo, work in progress. draft-ietf-teas-yang-te-topo, work in progress.
[OTN-TOPO] Zheng, H. et al., "A YANG Data Model for Optical [OTN-TOPO] Zheng, H. et al., "A YANG Data Model for Optical
Transport Network Topology", draft-ietf-ccamp-otn-topo- Transport Network Topology", draft-ietf-ccamp-otn-topo-
yang, work in progress. yang, work in progress.
[CLIENT-TOPO] Zheng, H. et al., "A YANG Data Model for Client-layer [CLIENT-TOPO] Zheng, H. et al., "A YANG Data Model for Client-layer
Topology", draft-zheng-ccamp-client-topo-yang, work in Topology", draft-zheng-ccamp-client-topo-yang, work in
skipping to change at page 46, line 20 skipping to change at page 54, line 24
Engineering Tunnels and Interfaces", draft-ietf-teas-yang- Engineering Tunnels and Interfaces", draft-ietf-teas-yang-
te, work in progress. te, work in progress.
[PATH-COMPUTE] Busi, I., Belotti, S. et al, "Yang model for [PATH-COMPUTE] Busi, I., Belotti, S. et al, "Yang model for
requesting Path Computation", draft-ietf-teas-yang-path- requesting Path Computation", draft-ietf-teas-yang-path-
computation, work in progress. computation, work in progress.
[OTN-TUNNEL] Zheng, H. et al., "OTN Tunnel YANG Model", draft- [OTN-TUNNEL] Zheng, H. et al., "OTN Tunnel YANG Model", draft-
ietf-ccamp-otn-tunnel-model, work in progress. ietf-ccamp-otn-tunnel-model, work in progress.
[CLIENT-SIGNAL] Zheng, H. et al., "A YANG Data Model for Optical [CLIENT-SIGNAL] Zheng, H. et al., "A YANG Data Model for Transport
Transport Network Client Signals", draft-zheng-ccamp-otn- Network Client Signals", draft-ietf-ccamp-client-signal-
client-signal-yang, work in progress. yang, work in progress.
8.2. Informative References 8.2. Informative References
[RFC5151] Farrel, A. et al., "Inter-Domain MPLS and GMPLS Traffic [RFC6241] Enns, R. et al., "Network Configuration Protocol
Engineering --Resource Reservation Protocol-Traffic (NETCONF)", RFC 6241, June 2011.
Engineering (RSVP-TE) Extensions", RFC 5151, February
2008. [RFC6242] Wasserman, W., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, June 2011.
[RFC6898] Li, D. et al., "Link Management Protocol Behavior [RFC6898] Li, D. et al., "Link Management Protocol Behavior
Negotiation and Configuration Modifications", RFC 6898, Negotiation and Configuration Modifications", RFC 6898,
March 2013. March 2013.
[RFC8040] Bierman, A. et al., "RESTCONF Protocol", RFC 8040, January [RFC8040] Bierman, A. et al., "RESTCONF Protocol", RFC 8040, January
2017. 2017.
[RFC8309] Wu, Q. et al., "Service Models Explained", RFC 8309, [RFC8309] Wu, Q. et al., "Service Models Explained", RFC 8309,
January 2018. January 2018.
[RFC8341] Bierman, A., Bjorklund, M., "Network Configuration Access
Control Model", RFC 8341, March 2018.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, August 2018.
[ACTN-YANG] Zhang, X. et al., "Applicability of YANG models for [ACTN-YANG] Zhang, X. et al., "Applicability of YANG models for
Abstraction and Control of Traffic Engineered Networks", Abstraction and Control of Traffic Engineered Networks",
draft-zhang-teas-actn-yang, work in progress. draft-zhang-teas-actn-yang, work in progress.
[RFC-FOLD] Watsen, K. et al., "Handling Long Lines in Artwork in [RFC-FOLD] Watsen, K. et al., "Handling Long Lines in Artwork in
Internet-Drafts and RFCs", draft-ietf-netmod-artwork- Internet-Drafts and RFCs", draft-ietf-netmod-artwork-
folding, work in progress folding, work in progress
[TE-TUTORIAL] Bryskin, I. et al., "TE Topology and Tunnel Modeling [TE-TUTORIAL] Bryskin, I. et al., "TE Topology and Tunnel Modeling
for Transport Networks", draft-ietf-teas-te-topo-and- for Transport Networks", draft-ietf-teas-te-topo-and-
tunnel-modeling, work in progress tunnel-modeling, work in progress
[ONF TR-527] ONF Technical Recommendation TR-527, "Functional [ONF TR-527] ONF Technical Recommendation TR-527, "Functional
Requirements for Transport API", June 2016. Requirements for Transport API", June 2016.
[ONF GitHub] ONF Open Transport (SNOWMASS),
<https://github.com/OpenNetworkingFoundation/Snowmass-
ONFOpenTransport>
[MEF 55] Metro Ethernet Forum, "Lifecycle Service Orchestration [MEF 55] Metro Ethernet Forum, "Lifecycle Service Orchestration
(LSO): Reference Architecture and Framework", Technical (LSO): Reference Architecture and Framework", Technical
Specification MEF 55, March 2016, Specification MEF 55, March 2016,
<https://www.mef.net/Assets/Technical_Specifications/PDF/M <https://www.mef.net/Assets/Technical_Specifications/PDF/M
EF_55.pdf> EF_55.pdf>
9. Acknowledgments 9. Acknowledgments
The authors would like to thank all members of the Transport NBI The authors would like to thank all members of the Transport NBI
Design Team involved in the definition of use cases, gap analysis Design Team involved in the definition of use cases, gap analysis
skipping to change at page 49, line 43 skipping to change at page 58, line 13
valid JSON but it is a valid JSON encoding of YANG data. valid JSON but it is a valid JSON encoding of YANG data.
The following schema resumes these definitions: The following schema resumes these definitions:
unfold_it --> stripper --> unfold_it --> stripper -->
Folded-JSON Unfolded-JSON Naked JSON Folded-JSON Unfolded-JSON Naked JSON
<-- fold_it <-- author edits <-- fold_it <-- author edits
<=72-chars? MUST MAY MAY <=72-chars? must may may
valid JSON? MAY MUST MUST valid JSON? may must must
JSON-encoding MAY MAY MUST JSON-encoding
of YANG data of YANG data? may may must
Our validation toolchain has been designed to take a JSON in any of Our validation toolchain has been designed to take a JSON in any of
the three formats and validate it automatically against a set of the three formats and validate it automatically against a set of
relevant YANG modules using available open-source tools. It can be relevant YANG modules using available open-source tools. It can be
found at: https://github.com/GianmarcoBruno/json-yang/ found at: https://github.com/GianmarcoBruno/json-yang/
A.2. Comments in JSON fragments A.2. Comments in JSON fragments
We found useful to introduce two kinds of comments, both defined as We found useful to introduce two kinds of comments, both defined as
key-value pairs where the key starts with "//": key-value pairs where the key starts with "//":
skipping to change at page 51, line 10 skipping to change at page 59, line 23
JSON-file------------> XML-file ----------------> Output JSON-file------------> XML-file ----------------> Output
(3) (3)
Figure 8 - DSDL-based approach for JSON code validation Figure 8 - DSDL-based approach for JSON code validation
In order to allow the use of comments following the convention In order to allow the use of comments following the convention
defined in section 3, without impacting the validation process, defined in section 3, without impacting the validation process,
these comments will be automatically removed from the JSON-file that these comments will be automatically removed from the JSON-file that
will be validate. will be validate.
A.4. Validation of JSON fragments: why not using a XSD-based approach A.4. Validation of JSON fragments: why not using 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
skipping to change at page 52, line 15 skipping to change at page 61, line 9
Appendix B. Detailed JSON Examples Appendix B. Detailed JSON Examples
The JSON code examples provided in this appendix have been validated The JSON code examples provided in this appendix have been validated
using the tools in Appendix A and folded using the tool in [RFC- using the tools in Appendix A and folded using the tool in [RFC-
FOLD]. FOLD].
B.1. JSON Examples for Topology Abstractions B.1. JSON Examples for Topology Abstractions
B.1.1. JSON Code: mpi1-otn-topology.json B.1.1. JSON Code: mpi1-otn-topology.json
This is the JSON code reporting the OTN Topology @ MPI: This is the JSON code reporting the OTN Topology @ MPI1:
========== NOTE: '\\' line wrapping per BCP XX (RFC XXXX) =========== ========== NOTE: '\\' line wrapping per BCP XXX (RFC XXXX) ==========
{ {
"// __LAST_UPDATE__": "October 21, 2019",
"// __TITLE__": "ODU Black Topology @ MPI1", "// __TITLE__": "ODU Black Topology @ MPI1",
"// __LAST_UPDATE__": "October 18, 2018",
"// __MISSING_ATTRIBUTES__": true,
"// __REFERENCE_DRAFTS__": { "// __REFERENCE_DRAFTS__": {
"ietf-routing-types@2017-12-04": "rfc8294", "ietf-routing-types@2017-12-04": "rfc8294",
"ietf-otn-types@2017-10-30": "draft-ietf-ccamp-otn-tunnel-model-\ "ietf-te-types@2019-07-05": "draft-ietf-teas-yang-te-types-10",
\01", "ietf-layer1-types@2019-09-09": "draft-ietf-ccamp-layer1-types-0\
\2",
"ietf-network@2018-02-26": "rfc8345", "ietf-network@2018-02-26": "rfc8345",
"ietf-network-topology@2018-02-26": "rfc8345", "ietf-network-topology@2018-02-26": "rfc8345",
"ietf-te-types@2018-06-12": "draft-ietf-teas-yang-te-15", "ietf-te-topology@2019-02-07": "draft-ietf-teas-yang-te-topo-22",
"ietf-te-topology@2018-06-15": "draft-ietf-teas-yang-te-topo-18", "ietf-otn-topology@2019-07-07": "draft-ietf-ccamp-otn-topo-yang-\
"ietf-otn-topology@2017-10-30": "draft-ietf-ccamp-otn-topo-yang-\ \08"
\02"
},
"// __RESTCONF_OPERATION__": {
"operation": "GET",
"url": "http://{{PNC1-ADDR}}/restconf/data/ietf-network:networks"
}, },
"// __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:provider-id": 201, "ietf-te-topology:te-topology-identifier": {
"ietf-te-topology:client-id": 300, "provider-id": 201,
"ietf-te-topology:te-topology-id": "otn-black-topology", "client-id": 300,
"// ietf-te-topology:te": "presence container requires: prov\ "topology-id": "otn-black-topology"
\ider, client and te-topology-id", },
"// __COMMENT__ ietf-te-topology:te": "presence container re\
\quires: 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": "Access LTPs to be reviewed in a fut\
\ure update",
"ietf-network:node": [ "ietf-network:node": [
{ {
"// __NODE__:__DESCRIPTION__": { "// __NODE__:__DESCRIPTION__": {
"name": "AN1", "name": "AN1",
"identifier": "10.0.0.1", "identifier": "10.0.0.1",
"type": "Abstract Node", "type": "Abstract Node",
"physical node(s)": "whole network domain 1" "physical node(s)": "The whole network domain 1"
}, },
"node-id": "10.0.0.1", "node-id": "10.0.0.1",
"ietf-te-topology:te-node-id": "10.0.0.1", "ietf-te-topology:te-node-id": "10.0.0.1",
"ietf-te-topology:te": { "ietf-te-topology:te": {
"te-node-attributes": { "te-node-attributes": {
"name": "AN11", "name": "AN11",
"admin-status": "up", "is-abstract": "",
"// __DISCUSS__ is-abstract": "To be discussed with \ "admin-status": "up"
\TE Topology authors",
"// __DISCUSS__ underlay-topology": "To be discussed\
\ with TE Topology authors"
}, },
"oper-status": "up", "oper-status": "up",
"// __DISCUSS__ tunnel-termination-point": [] "tunnel-termination-point": [
{
"// __COMMENT__ tunnel-tp-id": "AN1-1 TTP-ID (1 ->\
\ 0x01 -> 'AQ==')",
"tunnel-tp-id": "AQ==",
"name": "AN1-1 OTN TTP",
"// __COMMENT__ encoding and switching-capability"\
\: "OTN (ODU)",
"switching-capability": "ietf-te-types:switching-o\
\tn",
"encoding": "ietf-te-types:lsp-encoding-oduk",
"// __COMMENT__ inter-layer-lock-id": "{ AN1-1 ILL\
\-ID (1) }",
"inter-layer-lock-id": [
1
],
"admin-status": "up",
"oper-status": "up"
},
{
"// __COMMENT__ tunnel-tp-id": "AN1-2 TTP-ID (2 ->\
\ 0x02 -> 'Ag==')",
"tunnel-tp-id": "Ag==",
"name": "AN1-2 OTN TTP",
"// __COMMENT__ encoding and switching-capability"\
\: "OTN (ODU)",
"switching-capability": "ietf-te-types:switching-o\
\tn",
"encoding": "ietf-te-types:lsp-encoding-oduk",
"// __COMMENT__ inter-layer-lock-id": "{ AN1-2 ILL\
\-ID (2) }",
"inter-layer-lock-id": [
2
],
"admin-status": "up",
"oper-status": "up"
},
{
"// __COMMENT__ tunnel-tp-id": "AN1-3 TTP-ID (3 ->\
\ 0x03 -> 'Awo=')",
"tunnel-tp-id": "Awo=",
"name": "AN1-3 OTN TTP",
"// __COMMENT__ encoding and switching-capability"\
\: "OTN (ODU)",
"switching-capability": "ietf-te-types:switching-o\
\tn",
"encoding": "ietf-te-types:lsp-encoding-oduk",
"// __COMMENT__ inter-layer-lock-id": "{ AN1-3 ILL\
\-ID (3) }",
"inter-layer-lock-id": [
3
],
"admin-status": "up",
"oper-status": "up"
},
{
"// __COMMENT__ tunnel-tp-id": "AN1-8 TTP-ID (8 ->\
\ 0x08 -> 'CA==')",
"tunnel-tp-id": "CA==",
"name": "AN1-8 OTN TTP",
"// __COMMENT__ encoding and switching-capability"\
\: "OTN (ODU)",
"switching-capability": "ietf-te-types:switching-o\
\tn",
"encoding": "ietf-te-types:lsp-encoding-oduk",
"// __COMMENT__ inter-layer-lock-id": "{ AN1-8 ILL\
\-ID (1) }",
"inter-layer-lock-id": [
8
],
"admin-status": "up",
"oper-status": "up"
}
]
}, },
"ietf-network-topology:termination-point": [ "ietf-network-topology:termination-point": [
{ {
"// __DESCRIPTION__:__LTP__": { "// __DESCRIPTION__:__LTP__": {
"name": "AN1-1 LTP", "name": "AN1-1 LTP",
"link type(s)": "OTU-2", "link type(s)": "Multi-function (OTU2, STM-64 and \
\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": [
{
"// __COMMENT__ encoding and switching-capabil\
\ity": "OTN (ODU)",
"switching-capability": "ietf-te-types:switchi\
\ng-otn",
"encoding": "ietf-te-types:lsp-encoding-oduk",
"max-lsp-bandwidth": [
{
"priority": 0,
"te-bandwidth": {
"ietf-otn-topology:odu-type": "ietf-laye\
\r1-types:ODU2"
}
}
]
}
],
"// __NOT-PRESENT__ inter-domain-plug-id": "Use of\
\ plug-id for access Link is outside the scope of this document",
"// __COMMENT__ inter-layer-lock-id": "{ AN1-1 ILL\
\-ID (1) }",
"inter-layer-lock-id": [
1
],
"admin-status": "up", "admin-status": "up",
"// __DISCUSS__ interface-switching-capability": "\
\See Link attributes (teNodeId/10.0.0.1/teLinkId/1)",
"// __DISCUSS__ inter-domain-plug-id": "Access Lin\
\k",
"// __COMMENT__ inter-layer-lock-id": "Empty: OTN \
\Links are pre-configured",
"oper-status": "up", "oper-status": "up",
"// __DISCUSS__ ietf-otn-topology:supported-payloa\ "ietf-otn-topology:client-svc": {
\d-types": "List of ODU clients?", "client-facing": true,
"// __DISCUSS__ ietf-otn-topology:client-facing": \ "supported-client-signal": [
"ietf-layer1-types:STM-64"
\true ]
}
} }
}, },
{ {
"// __DESCRIPTION__:__LTP__": { "// __DESCRIPTION__:__LTP__": {
"name": "AN1-2 LTP", "name": "AN1-2 LTP",
"link type(s)": "OTU-4", "link type(s)": "Multi-function (OTU2 and STM-64)",
"physical node": "S2", "physical node": "S6",
"unnumberd/ifIndex": 1, "unnumberd/ifIndex": 2,
"port type": "inter-domain port", "port type": "tributary port",
"connected to": "S31" "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": [
{
"// __COMMENT__ encoding and switching-capabil\
\ity": "OTN (ODU)",
"switching-capability": "ietf-te-types:switchi\
\ng-otn",
"encoding": "ietf-te-types:lsp-encoding-oduk",
"max-lsp-bandwidth": [
{
"priority": 0,
"te-bandwidth": {
"ietf-otn-topology:odu-type": "ietf-laye\
\r1-types:ODU2"
}
}
]
}
],
"// __NOT-PRESENT__ inter-domain-plug-id": "Use of\
\ plug-id for access Link is outside the scope of this document",
"// __COMMENT__ inter-layer-lock-id": "{ AN1-2 ILL\
\-ID (2) }",
"inter-layer-lock-id": [
2
],
"admin-status": "up", "admin-status": "up",
"// __DISCUSS__ interface-switching-capability": "\
\See Link attributes (teNodeId/10.0.0.1/teLinkId/2)",
"// __DISCUSS__ inter-domain-plug-id": "Inter-doma\
\in Link",
"oper-status": "up", "oper-status": "up",
"// __DISCUSS__ ietf-otn-topology:supported-payloa\ "ietf-otn-topology:client-svc": {
\d-types": "Empty? (inter-domain OTN link)", "client-facing": true,
"// __DEFAULT__ ietf-otn-topology:client-facing": \ "supported-client-signal": [
\false "ietf-layer1-types:STM-64"
]
}
} }
}, },
{ {
"// __DESCRIPTION__:__LTP__": { "// __DESCRIPTION__:__LTP__": {
"name": "AN1-3 LTP", "name": "AN1-3 LTP",
"link type(s)": "OTU-2", "link type(s)": "STM-64",
"physical node": "S6", "physical node": "S6",
"unnumberd/ifIndex": 1, "unnumberd/ifIndex": 3,
"port type": "tributary port", "port type": "tributary port",
"connected to": "R2" "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\
\": "STM-64 Access Link only (no ODU switching)",
"// __NOT-PRESENT__ inter-domain-plug-id": "Use of\
\ plug-id for access Link is outside the scope of this document",
"// __COMMENT__ inter-layer-lock-id": "{ AN1-3 ILL\
\-ID (3) }",
"inter-layer-lock-id": [
3
],
"admin-status": "up", "admin-status": "up",
"// __DISCUSS__ interface-switching-capability": "\
\See Link attributes (teNodeId/10.0.0.1/teLinkId/3)",
"// __DISCUSS__ inter-domain-plug-id": "Access Lin\
\k",
"oper-status": "up", "oper-status": "up",
"// __DISCUSS__ ietf-otn-topology:supported-payloa\ "ietf-otn-topology:client-svc": {
\d-types": "List of ODU clients?", "client-facing": true,
"// __DISCUSS__ ietf-otn-topology:client-facing": \ "supported-client-signal": [
\true "ietf-layer1-types:STM-64"
]
}
} }
}, },
{ {
"// __DESCRIPTION__:__LTP__": { "// __DESCRIPTION__:__LTP__": {
"name": "AN1-4 LTP", "name": "AN1-4 LTP",
"link type(s)": "OTU-4", "link type(s)": "OTU4",
"physical node": "S8", "physical node": "S7",
"unnumberd/ifIndex": 1, "unnumberd/ifIndex": 3,
"port type": "inter-domain port", "port type": "inter-domain port",
"connected to": "S32" "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": [
{
"// __COMMENT__ encoding and switching-capabil\
\ity": "OTN (ODU)",
"switching-capability": "ietf-te-types:switchi\
\ng-otn",
"encoding": "ietf-te-types:lsp-encoding-oduk",
"max-lsp-bandwidth": [
{
"priority": 0,
"te-bandwidth": {
"ietf-otn-topology:odu-type": "ietf-laye\
\r1-types:ODU4"
}
}
]
}
],
"// __COMMENT__ inter-domain-plug-id": "S7-S11 Plu\
\g-id (0x000711 -> AAcR)",
"inter-domain-plug-id": "AAcR",
"// __NOT-PRESENT__ inter-layer-lock-id": "ODU Ser\
\ver Layer topology not exposed",
"admin-status": "up", "admin-status": "up",
"// __DISCUSS__ interface-switching-capability": "\
\See Link attributes (teNodeId/10.0.0.1/teLinkId/4)",
"// __DISCUSS__ inter-domain-plug-id": "Inter-doma\
\in Link",
"oper-status": "up", "oper-status": "up",
"// __DISCUSS__ ietf-otn-topology:supported-payloa\ "// __NOT-PRESENT__ ietf-otn-topology:client-svc":\
\d-types": "Empty? (inter-domain OTN link)", \ "OTN inter-domain link"
"// __DEFAULT__ ietf-otn-topology:client-facing": \
\false
} }
}, },
{ {
"// __DESCRIPTION__:__LTP__": { "// __DESCRIPTION__:__LTP__": {
"name": "AN1-5 LTP", "name": "AN1-5 LTP",
"link type(s)": "OTU-4", "link type(s)": "OTU4",
"physical node": "S8", "physical node": "S8",
"unnumberd/ifIndex": 5, "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": [
{
"// __COMMENT__ encoding and switching-capabil\
\ity": "OTN (ODU)",
"switching-capability": "ietf-te-types:switchi\
\ng-otn",
"encoding": "ietf-te-types:lsp-encoding-oduk",
"max-lsp-bandwidth": [
{
"priority": 0,
"te-bandwidth": {
"ietf-otn-topology:odu-type": "ietf-laye\
\r1-types:ODU4"
}
}
]
}
],
"// __COMMENT__ inter-domain-plug-id": "S8.S12 Plu\
\g-id (0x000812 -> AAgS)",
"inter-domain-plug-id": "AAgS",
"// __NOT-PRESENT__ inter-layer-lock-id": "ODU Ser\
\ver Layer topology not exposed",
"admin-status": "up", "admin-status": "up",
"// __DISCUSS__ interface-switching-capability": "\
\See Link attributes (teNodeId/10.0.0.1/teLinkId/5)",
"// __DISCUSS__ inter-domain-plug-id": "Inter-doma\
\in Link",
"oper-status": "up", "oper-status": "up",
"// __DISCUSS__ ietf-otn-topology:supported-payloa\ "// __NOT-PRESENT__ ietf-otn-topology:client-svc":\
\d-types": "Empty? (inter-domain OTN link)", \ "OTN inter-domain link"
"// __DEFAULT__ ietf-otn-topology:client-facing": \
\false
} }
}, },
{ {
"// __DESCRIPTION__:__LTP__": { "// __DESCRIPTION__:__LTP__": {
"name": "AN1-6 LTP", "name": "AN1-6 LTP",
"link type(s)": "OTU-4", "link type(s)": "OTU4",
"physical node": "S7", "physical node": "S8",
"unnumberd/ifIndex": 4, "unnumberd/ifIndex": 5,
"port type": "inter-domain port", "port type": "inter-domain port",
"connected to": "S11" "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": [
{
"// __COMMENT__ encoding and switching-capabil\
\ity": "OTN (ODU)",
"switching-capability": "ietf-te-types:switchi\
\ng-otn",
"encoding": "ietf-te-types:lsp-encoding-oduk",
"max-lsp-bandwidth": [
{
"priority": 0,
"te-bandwidth": {
"ietf-otn-topology:odu-type": "ietf-laye\
\r1-types:ODU4"
}
}
]
}
],
"// __COMMENT__ inter-domain-plug-id": "S8.S32 Plu\
\g-id (0x000832 -> AAgy)",
"inter-domain-plug-id": "AAgy",
"// __NOT-PRESENT__ inter-layer-lock-id": "ODU Ser\
\ver Layer topology not exposed",
"admin-status": "up", "admin-status": "up",
"// __DISCUSS__ interface-switching-capability": "\
\See Link attributes (teNodeId/10.0.0.1/teLinkId/6)",
"// __DISCUSS__ inter-domain-plug-id": "Inter-doma\
\in Link",
"oper-status": "up", "oper-status": "up",
"// __DISCUSS__ ietf-otn-topology:supported-payloa\ "// __NOT-PRESENT__ ietf-otn-topology:client-svc":\
\d-types": "Empty? (inter-domain OTN link)", \ "OTN inter-domain link"
"// __DEFAULT__ ietf-otn-topology:client-facing": \
\false
} }
}, },
{ {
"// __DESCRIPTION__:__LTP__": { "// __DESCRIPTION__:__LTP__": {
"name": "AN1-7 LTP", "name": "AN1-7 LTP",
"link type(s)": "OTU-2", "link type(s)": "OTU4",
"physical node": "S6", "physical node": "S2",
"unnumberd/ifIndex": 2, "unnumberd/ifIndex": 3,
"port type": "tributary port", "port type": "inter-domain port",
"connected to": "R3" "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": [
{
"// __COMMENT__ encoding and switching-capabil\
\ity": "OTN (ODU)",
"switching-capability": "ietf-te-types:switchi\
\ng-otn",
"encoding": "ietf-te-types:lsp-encoding-oduk",
"max-lsp-bandwidth": [
{
"priority": 0,
"te-bandwidth": {
"ietf-otn-topology:odu-type": "ietf-laye\
\r1-types:ODU4"
}
}
]
}
],
"// __COMMENT__ inter-domain-plug-id": "S2-S31 Plu\
\g-id (0x000231 -> AAIx)",
"inter-domain-plug-id": "AAIx",
"// __NOT-PRESENT__ inter-layer-lock-id": "ODU Ser\
\ver Layer topology not exposed",
"admin-status": "up", "admin-status": "up",
"// __DISCUSS__ interface-switching-capability": "\
\See Link attributes (teNodeId/10.0.0.1/teLinkId/7)",
"// __DISCUSS__ inter-domain-plug-id": "Access Lin\
\k",
"oper-status": "up", "oper-status": "up",
"// __DISCUSS__ ietf-otn-topology:supported-payloa\ "// __NOT-PRESENT__ ietf-otn-topology:client-svc":\
\d-types": "List of ODU clients?", \ "OTN inter-domain link"
"// __DISCUSS__ ietf-otn-topology:client-facing": \
\true
} }
} }
] ]
} }
], ],
"// ietf-network-topology:link": "Access links to be reviewe\
\d in a future update",
"ietf-network-topology:link": [ "ietf-network-topology:link": [
{ {
"// __DESCRIPTION__:__LINK__": { "// __DESCRIPTION__:__LINK__": {
"name": "Access Link from AN1-1", "name": "Access Link from AN1-1",
"type": "access link", "type": "Multi-function access link (OTU2, STM-64 and \
\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/10.0.0.1/teLinkId/1",
"source": {
"source-node": "10.0.0.1",
"source-tp": 1
},
"// __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",
"// __DISCUSS__ access-type": "Can we assume point-t\ "// __NOT-PRESENT__ external-domain": "The plug-id i\
\o-point as the default value?", \s used instead of this container",
"access-type": "point-to-point", "// __NOT-PRESENT__ is-abstract": "The access link i\
"// __COMMENT__ external-domain": "Empty: the plug-i\ \s not abstract",
\d is used instead of this container",
"// __DISCUSS__ is-abstract": "To be discussed with \
\TE Topology authors",
"// __DISCUSS__ underlay": "To be discussed with TE \
\Topology authors",
"admin-status": "up",
"interface-switching-capability": [ "interface-switching-capability": [
{ {
"// __COMMENT__ encoding and switching-capabilit\
\y": "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,
"// __DISCUSS__ te-bandwidth": "ODU2" "te-bandwidth": {
"ietf-otn-topology:odu-type": "ietf-layer1\
\-types:ODU2"
}
} }
] ]
} }
], ],
"// __COMMENT__ label-restrictions": "Not described \ "// __COMMENT__ label-restrictions": "Outside the sc\
\in this JSON example", \ope of this JSON example",
"// __DISCUSS__ link-protection-type": "Can we assum\
\e unprotected as the default value?",
"link-protection-type": "unprotected",
"max-link-bandwidth": { "max-link-bandwidth": {
"// __DISCUSS__ te-bandwidth": "1xODU2" "te-bandwidth": {
"ietf-otn-topology:odulist": [
{
"odu-type": "ietf-layer1-types:ODU2",
"number": 1
}
]
}
}, },
"max-resv-link-bandwidth": { "max-resv-link-bandwidth": {
"// __DISCUSS__ te-bandwidth": "1xODU2" "te-bandwidth": {
"ietf-otn-topology:odulist": [
{
"odu-type": "ietf-layer1-types:ODU2",
"number": 1
}
]
}
}, },
"unreserved-bandwidth": [ "unreserved-bandwidth": [
{ {
"priority": 0, "priority": 0,
"// __DISCUSS__ te-bandwidth": "1xODU2" "te-bandwidth": {
"ietf-otn-topology:odulist": [
{
"odu-type": "ietf-layer1-types:ODU2",
"number": 1
}
]
}
} }
] ],
"// __NOT-PRESENT__ ietf-otn-topology:tsg": "Access \
\Link with no HO-ODU termination and LO-ODU switching",
"admin-status": "up"
}, },
"oper-status": "up", "oper-status": "up",
"// __EMPTY__ is-transitional": "It is not a transitio\ "// __NOT-PRESENT__ is-transitional": "It is not a tra\
\nal link", \nsitional link"
"// __DISCUSS__ underlay ": "To be discussed with TE T\ }
\opology authors"
},
"source": {
"source-node": "10.0.0.1",
"source-tp": 1
},
"// __EMPTY__ destination": "access link"
}, },
{ {
"// __DESCRIPTION__:__LINK__": { "// __DESCRIPTION__:__LINK__": {
"name": "Inter-domain Link from AN1-2", "name": "Access Link from AN1-2",
"type": "inter-domain link", "type": "Multi-function access link (OTU2 and STM-64)",
"physical link": "Link from S2-1 to S31" "physical link": "Link from S6-2 to R3"
}, },
"link-id": "teNodeId/10.0.0.1/teLinkId/2", "link-id": "teNodeId/10.0.0.1/teLinkId/2",
"source": {
"source-node": "10.0.0.1",
"source-tp": 2
},
"// __NOT-PRESENT__ destination": "access link",
"ietf-te-topology:te": { "ietf-te-topology:te": {
"te-link-attributes": { "te-link-attributes": {
"name": "Inter-domain Link from AN1-2", "name": "Access Link from AN1-2",
"// __DISCUSS__ access-type": "Can we assume point-t\ "// __NOT-PRESENT__ external-domain": "The plug-id i\
\o-point as the default value?", \s used instead of this container",
"access-type": "point-to-point", "// __NOT-PRESENT__ is-abstract": "The access link i\
"// __DISCUSS__ is-abstract": "To be discussed with \ \s not abstract",
\TE Topology authors",
"// __DISCUSS__ underlay": "To be discussed with TE \
\Topology authors",
"admin-status": "up",
"interface-switching-capability": [ "interface-switching-capability": [
{ {
"// __COMMENT__ encoding and switching-capabilit\
\y": "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,
"// __DISCUSS__ te-bandwidth": "ODU4" "te-bandwidth": {
"ietf-otn-topology:odu-type": "ietf-layer1\
\-types:ODU2"
}
} }
], ]
"// __DISCUSS__ label-restrictions": "To be adde\
\d?"
} }
], ],
"// __DISCUSS__ link-protection-type": "Can we assum\ "// __COMMENT__ label-restrictions": "Outside the sc\
\e unprotected as the default value?", \ope of this JSON example",
"link-protection-type": "unprotected",
"max-link-bandwidth": { "max-link-bandwidth": {
"// __DISCUSS__ te-bandwidth": "1xODU4, ..." "te-bandwidth": {
"ietf-otn-topology:odulist": [
{
"odu-type": "ietf-layer1-types:ODU2",
"number": 1
}
]
}
}, },
"max-resv-link-bandwidth": { "max-resv-link-bandwidth": {
"// __DISCUSS__ te-bandwidth": "1xODU4, ..." "te-bandwidth": {
"ietf-otn-topology:odulist": [
{
"odu-type": "ietf-layer1-types:ODU2",
"number": 1
}
]
}
}, },
"unreserved-bandwidth": [ "unreserved-bandwidth": [
{ {
"priority": 0, "priority": 0,
"// __DISCUSS__ te-bandwidth": "1xODU4, ..." "te-bandwidth": {
"ietf-otn-topology:odulist": [
{
"odu-type": "ietf-layer1-types:ODU2",
"number": 1
}
]
}
} }
] ],
"// __NOT-PRESENT__ ietf-otn-topology:tsg": "Access \
\Link with no HO-ODU termination and LO-ODU switching",
"admin-status": "up"
}, },
"oper-status": "up", "oper-status": "up",
"// __EMPTY__ is-transitional": "It is not a transitio\ "// __NOT-PRESENT__ is-transitional": "It is not a tra\
\nal link", \nsitional link"
"// __DISCUSS__ underlay ": "To be discussed with TE T\ }
\opology authors"
},
"source": {
"source-node": "10.0.0.1",
"source-tp": 2
},
"// __EMPTY__ destination": "inter-domain link"
}, },
{ {
"// __DESCRIPTION__:__LINK__": { "// __DESCRIPTION__:__LINK__": {
"name": "Access Link from AN1-3", "name": "Access Link from AN1-3",
"type": "access link", "type": "STM-64 Access link",
"physical link": "Link from S6-1 to R2" "physical link": "Link from S6-3 to R4"
}, },
"link-id": "teNodeId/10.0.0.1/teLinkId/3", "link-id": "teNodeId/10.0.0.1/teLinkId/3",
"source": {
"source-node": "10.0.0.1",
"source-tp": 3
},
"// __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",
"// __DISCUSS__ access-type": "Can we assume point-t\ "// __NOT-PRESENT__ external-domain": "The plug-id i\
\o-point as the default value?",
"access-type": "point-to-point", \s used instead of this container",
"// __DISCUSS__ is-abstract": "To be discussed with \ "// __NOT-PRESENT__ is-abstract": "The access link i\
\TE Topology authors", \s not abstract",
"// __DISCUSS__ underlay": "To be discussed with TE \ "// __NOT-PRESENT__ interface-switching-capability":\
\Topology authors", \ "STM-64 Access Link only (no ODU switching)",
"admin-status": "up", "// __NOT-PRESENT__ max-link-bandwidth": "STM-64 Acc\
"interface-switching-capability": [ \ess Link only (no ODU switching)",
{ "// __NOT-PRESENT__ max-resv-link-bandwidth": "STM-6\
"switching-capability": "ietf-te-types:switching\ \4 Access Link only (no ODU switching)",
\-otn", "// __NOT-PRESENT__ unreserved-bandwidth": "STM-64 A\
"encoding": "ietf-te-types:lsp-encoding-oduk", \ccess Link only (no ODU switching)",
"max-lsp-bandwidth": [ "// __NOT-PRESENT__ ietf-otn-topology:tsg": "STM-64 \
{ \Access Link only (no HO-ODU termination and LO-ODU switching)",
"priority": 0, "admin-status": "up"
"// __DISCUSS__ te-bandwidth": "ODU2"
}
],
"// __DISCUSS__ label-restrictions": "To be adde\
\d?"
}
],
"// __DISCUSS__ link-protection-type": "Can we assum\
\e unprotected as the default value?",
"link-protection-type": "unprotected",
"max-link-bandwidth": {
"// __DISCUSS__ te-bandwidth": "1xODU2"
},
"unreserved-bandwidth": [
{
"priority": 0,
"// __DISCUSS__ te-bandwidth": "1xODU2"
}
],
"max-resv-link-bandwidth": {
"// __DISCUSS__ te-bandwidth": "1xODU2"
}
}, },
"oper-status": "up", "oper-status": "up",
"// __EMPTY__ is-transitional": "It is not a transitio\ "// __NOT-PRESENT__ is-transitional": "It is not a tra\
\nal link", \nsitional link"
"// __DISCUSS__ underlay ": "To be discussed with TE T\ }
\opology authors"
},
"source": {
"source-node": "10.0.0.1",
"source-tp": 3
},
"// __EMPTY__ destination": "access link"
}, },
{ {
"// __DESCRIPTION__:__LINK__": { "// __DESCRIPTION__:__LINK__": {
"name": "Inter-domain Link from AN1-4", "name": "Inter-domain Link from AN1-4",
"type": "inter-domain link", "type": "OTU4 inter-domain link",
"physical link": "Link from S8-1 to S32" "physical link": "Link from S7-3 to S11"
}, },
"link-id": "teNodeId/10.0.0.1/teLinkId/4", "link-id": "teNodeId/10.0.0.1/teLinkId/4",
"source": {
"source-node": "10.0.0.1",
"source-tp": 4
},
"// __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",
"// __DISCUSS__ access-type": "Can we assume point-t\ "// __NOT-PRESENT__ external-domain": "The plug-id i\
\o-point as the default value?", \s used instead of this container",
"access-type": "point-to-point", "// __NOT-PRESENT__ is-abstract": "The access link i\
"// __DISCUSS__ is-abstract": "To be discussed with \ \s not abstract",
\TE Topology authors",
"// __DISCUSS__ underlay": "To be discussed with TE \
\Topology authors",
"admin-status": "up",
"interface-switching-capability": [ "interface-switching-capability": [
{ {
"// __COMMENT__ encoding and switching-capabilit\
\y": "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,
"// __DISCUSS__ te-bandwidth": "ODU4" "te-bandwidth": {
"ietf-otn-topology:odu-type": "ietf-layer1\
\-types:ODU4"
}
} }
], ]
"// __DISCUSS__ label-restrictions": "To be adde\
\d?"
} }
], ],
"// __DISCUSS__ link-protection-type": "Can we assum\ "// __COMMENT__ label-restrictions": "Outside the sc\
\e unprotected as the default value?", \ope of this JSON example",
"link-protection-type": "unprotected",
"max-link-bandwidth": { "max-link-bandwidth": {
"// __DISCUSS__ te-bandwidth": "1xODU4, ..." "te-bandwidth": {
"ietf-otn-topology:odulist": [
{
"odu-type": "ietf-layer1-types:ODU4",
"number": 1
},
{
"odu-type": "ietf-layer1-types:ODU2",
"number": 10
},
{
"odu-type": "ietf-layer1-types:ODU0",
"number": 80
}
]
}
},
"max-resv-link-bandwidth": {
"te-bandwidth": {
"ietf-otn-topology:odulist": [
{
"odu-type": "ietf-layer1-types:ODU4",
"number": 1
},
{
"odu-type": "ietf-layer1-types:ODU2",
"number": 10
},
{
"odu-type": "ietf-layer1-types:ODU0",
"number": 80
}
]
}
}, },
"unreserved-bandwidth": [ "unreserved-bandwidth": [
{ {
"priority": 0, "priority": 0,
"// __DISCUSS__ te-bandwidth": "1xODU4, ..." "te-bandwidth": {
"ietf-otn-topology:odulist": [
{
"odu-type": "ietf-layer1-types:ODU4",
"number": 1
},
{
"odu-type": "ietf-layer1-types:ODU2",
"number": 10
},
{
"odu-type": "ietf-layer1-types:ODU0",
"number": 80
}
]
}
} }
], ],
"max-resv-link-bandwidth": { "ietf-otn-topology:tsg": "ietf-layer1-types:tsg-1.25\
"// __DISCUSS__ te-bandwidth": "1xODU4, ..." \G",
} "admin-status": "up"
}, },
"oper-status": "up", "oper-status": "up",
"// __EMPTY__ is-transitional": "It is not a transitio\ "// __NOT-PRESENT__ is-transitional": "It is not a tra\
\nal link", \nsitional link"
"// __DISCUSS__ underlay ": "To be discussed with TE T\ }
\opology authors"
},
"source": {
"source-node": "10.0.0.1",
"source-tp": 4
},
"// __EMPTY__ destination": "inter-domain link"
}, },
{ {
"// __DESCRIPTION__:__LINK__": { "// __DESCRIPTION__:__LINK__": {
"name": "Inter-domain Link from AN1-5", "name": "Inter-domain Link from AN1-5",
"type": "inter-domain link", "type": "OTU4 inter-domain link",
"physical link": "Link from S8-5 to S12" "physical link": "Link from S8-4 to S12"
}, },
"link-id": "teNodeId/10.0.0.1/teLinkId/5", "link-id": "teNodeId/10.0.0.1/teLinkId/5",
"source": {
"source-node": "10.0.0.1",
"source-tp": 5
},
"// __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",
"// __DISCUSS__ access-type": "Can we assume point-t\ "// __NOT-PRESENT__ external-domain": "The plug-id i\
\o-point as the default value?", \s used instead of this container",
"access-type": "point-to-point", "// __NOT-PRESENT__ is-abstract": "The access link i\
"// __DISCUSS__ is-abstract": "To be discussed with \ \s not abstract",
\TE Topology authors",
"// __DISCUSS__ underlay": "To be discussed with TE \
\Topology authors",
"admin-status": "up",
"interface-switching-capability": [ "interface-switching-capability": [
{ {
"// __COMMENT__ encoding and switching-capabilit\
\y": "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,
"// __DISCUSS__ te-bandwidth": "ODU4" "te-bandwidth": {
"ietf-otn-topology:odu-type": "ietf-layer1\
\-types:ODU4"
}
} }
], ]
"// __DISCUSS__ label-restrictions": "To be adde\
\d?"
} }
], ],
"// __DISCUSS__ link-protection-type": "Can we assum\ "// __COMMENT__ label-restrictions": "Outside the sc\
\e unprotected as the default value?", \ope of this JSON example",
"link-protection-type": "unprotected",
"max-link-bandwidth": { "max-link-bandwidth": {
"// __DISCUSS__ te-bandwidth": "1xODU4, ..." "te-bandwidth": {
"ietf-otn-topology:odulist": [
{
"odu-type": "ietf-layer1-types:ODU4",
"number": 1
},
{
"odu-type": "ietf-layer1-types:ODU2",
"number": 10
},
{
"odu-type": "ietf-layer1-types:ODU0",
"number": 80
}
]
}
}, },
"max-resv-link-bandwidth": { "max-resv-link-bandwidth": {
"// __DISCUSS__ te-bandwidth": "1xODU4, ..." "te-bandwidth": {
"ietf-otn-topology:odulist": [
{
"odu-type": "ietf-layer1-types:ODU4",
"number": 1
},
{
"odu-type": "ietf-layer1-types:ODU2",
"number": 10
},
{
"odu-type": "ietf-layer1-types:ODU0",
"number": 80
}
]
}
}, },
"unreserved-bandwidth": [ "unreserved-bandwidth": [
{ {
"priority": 0, "priority": 0,
"// __DISCUSS__ te-bandwidth": "1xODU4, ..." "te-bandwidth": {
"ietf-otn-topology:odulist": [
{
"odu-type": "ietf-layer1-types:ODU4",
"number": 1
},
{
"odu-type": "ietf-layer1-types:ODU2",
"number": 10
},
{
"odu-type": "ietf-layer1-types:ODU0",
"number": 80
}
]
}
} }
]
],
"ietf-otn-topology:tsg": "ietf-layer1-types:tsg-1.25\
\G",
"admin-status": "up"
}, },
"oper-status": "up", "oper-status": "up",
"// __EMPTY__ is-transitional": "It is not a transitio\ "// __NOT-PRESENT__ is-transitional": "It is not a tra\
\nal link", \nsitional link"
"// __DISCUSS__ underlay ": "To be discussed with TE T\ }
\opology authors"
},
"source": {
"source-node": "10.0.0.1",
"source-tp": 5
},
"// __EMPTY__ destination": "inter-domain link"
}, },
{ {
"// __DESCRIPTION__:__LINK__": { "// __DESCRIPTION__:__LINK__": {
"name": "Inter-domain Link from AN1-6", "name": "Inter-domain Link from AN1-6",
"type": "inter-domain link", "type": "OTU4 inter-domain link",
"physical link": "Link from S7-4 to S11" "physical link": "Link from S8-5 to S32"
}, },
"link-id": "teNodeId/10.0.0.1/teLinkId/6", "link-id": "teNodeId/10.0.0.1/teLinkId/6",
"source": {
"source-node": "10.0.0.1",
"source-tp": 6
},
"// __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",
"// __DISCUSS__ access-type": "Can we assume point-t\ "// __NOT-PRESENT__ external-domain": "The plug-id i\
\o-point as the default value?", \s used instead of this container",
"access-type": "point-to-point", "// __NOT-PRESENT__ is-abstract": "The access link i\
"// __DISCUSS__ is-abstract": "To be discussed with \ \s not abstract",
\TE Topology authors",
"// __DISCUSS__ underlay": "To be discussed with TE \
\Topology authors",
"admin-status": "up",
"interface-switching-capability": [ "interface-switching-capability": [
{ {
"// __COMMENT__ encoding and switching-capabilit\
\y": "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,
"// __DISCUSS__ te-bandwidth": "ODU4" "te-bandwidth": {
"ietf-otn-topology:odu-type": "ietf-layer1\
\-types:ODU4"
}
} }
],
"// __DISCUSS__ label-restrictions": "To be adde\ ]
\d?"
} }
], ],
"// __DISCUSS__ link-protection-type": "Can we assum\ "// __COMMENT__ label-restrictions": "Outside the sc\
\e unprotected as the default value?", \ope of this JSON example",
"link-protection-type": "unprotected",
"max-link-bandwidth": { "max-link-bandwidth": {
"// __DISCUSS__ te-bandwidth": "1xODU4, ..." "te-bandwidth": {
"ietf-otn-topology:odulist": [
{
"odu-type": "ietf-layer1-types:ODU4",
"number": 1
},
{
"odu-type": "ietf-layer1-types:ODU2",
"number": 10
},
{
"odu-type": "ietf-layer1-types:ODU0",
"number": 80
}
]
}
}, },
"max-resv-link-bandwidth": { "max-resv-link-bandwidth": {
"// __DISCUSS__ te-bandwidth": "1xODU4, ..." "te-bandwidth": {
"ietf-otn-topology:odulist": [
{
"odu-type": "ietf-layer1-types:ODU4",
"number": 1
},
{
"odu-type": "ietf-layer1-types:ODU2",
"number": 10
},
{
"odu-type": "ietf-layer1-types:ODU0",
"number": 80
}
]
}
}, },
"unreserved-bandwidth": [ "unreserved-bandwidth": [
{ {
"priority": 0, "priority": 0,
"// __DISCUSS__ te-bandwidth": "1xODU4, ..." "te-bandwidth": {
"ietf-otn-topology:odulist": [
{
"odu-type": "ietf-layer1-types:ODU4",
"number": 1
},
{
"odu-type": "ietf-layer1-types:ODU2",
"number": 10
},
{
"odu-type": "ietf-layer1-types:ODU0",
"number": 80
}
]
}
} }
] ],
"ietf-otn-topology:tsg": "ietf-layer1-types:tsg-1.25\
\G",
"admin-status": "up"
}, },
"oper-status": "up", "oper-status": "up",
"// __EMPTY__ is-transitional": "It is not a transitio\ "// __NOT-PRESENT__ is-transitional": "It is not a tra\
\nal link", \nsitional link"
"// __DISCUSS__ underlay ": "To be discussed with TE T\ }
\opology authors"
},
"source": {
"source-node": "10.0.0.1",
"source-tp": 6
},
"// __EMPTY__ destination": "inter-domain link"
}, },
{ {
"// __DESCRIPTION__:__LINK__": { "// __DESCRIPTION__:__LINK__": {
"name": "Access Link from AN1-7", "name": "Inter-domain Link from AN1-7",
"type": "access link", "type": "OTU4 inter-domain link",
"physical link": "Link from S6-2 to R3" "physical link": "Link from S2-3 to S31"
}, },
"link-id": "teNodeId/10.0.0.1teLinkId/7", "link-id": "teNodeId/10.0.0.1teLinkId/7",
"source": {
"source-node": "10.0.0.1",
"source-tp": 7
},
"// __NOT-PRESENT__ destination": "inter-domain link",
"ietf-te-topology:te": { "ietf-te-topology:te": {
"te-link-attributes": { "te-link-attributes": {
"name": "Access Link from AN1-7", "name": "Inter-domain Link from AN1-7",
"// __DISCUSS__ access-type": "Can we assume point-t\ "// __NOT-PRESENT__ external-domain": "The plug-id i\
\o-point as the default value?", \s used instead of this container",
"access-type": "point-to-point", "// __NOT-PRESENT__ is-abstract": "The access link i\
"// __DISCUSS__ is-abstract": "To be discussed with \ \s not abstract",
\TE Topology authors",
"// __DISCUSS__ underlay": "To be discussed with TE \
\Topology authors",
"admin-status": "up",
"interface-switching-capability": [ "interface-switching-capability": [
{ {
"// __COMMENT__ encoding and switching-capabilit\
\y": "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,
"// __DISCUSS__ te-bandwidth": "ODU2" "te-bandwidth": {
"ietf-otn-topology:odu-type": "ietf-layer1\
\-types:ODU4"
}
} }
], ]
"// __DISCUSS__ label-restrictions": "To be adde\
\d?"
} }
], ],
"// __DISCUSS__ link-protection-type": "Can we assum\ "// __COMMENT__ label-restrictions": "Outside the sc\
\e unprotected as the default value?", \ope of this JSON example",
"link-protection-type": "unprotected",
"max-link-bandwidth": { "max-link-bandwidth": {
"// __DISCUSS__ te-bandwidth": "1xODU2" "te-bandwidth": {
"ietf-otn-topology:odulist": [
{
"odu-type": "ietf-layer1-types:ODU4",
"number": 1
},
{
"odu-type": "ietf-layer1-types:ODU2",
"number": 10
},
{
"odu-type": "ietf-layer1-types:ODU0",
"number": 80
}
]
}
}, },
"max-resv-link-bandwidth": { "max-resv-link-bandwidth": {
"// __DISCUSS__ te-bandwidth": "1xODU2" "te-bandwidth": {
"ietf-otn-topology:odulist": [
{
"odu-type": "ietf-layer1-types:ODU4",
"number": 1
},
{
"odu-type": "ietf-layer1-types:ODU2",
"number": 10
},
{
"odu-type": "ietf-layer1-types:ODU0",
"number": 80
}
]
}
}, },
"unreserved-bandwidth": [ "unreserved-bandwidth": [
{ {
"priority": 0, "priority": 0,
"// __DISCUSS__ te-bandwidth": "1xODU2" "te-bandwidth": {
"ietf-otn-topology:odulist": [
{
"odu-type": "ietf-layer1-types:ODU4",
"number": 1
},
{
"odu-type": "ietf-layer1-types:ODU2",
"number": 10
},
{
"odu-type": "ietf-layer1-types:ODU0",
"number": 80
}
]
}
} }
] ],
"ietf-otn-topology:tsg": "ietf-layer1-types:tsg-1.25\
\G",
"admin-status": "up"
}, },
"oper-status": "up", "oper-status": "up",
"// __EMPTY__ is-transitional": "It is not a transitio\ "// __NOT-PRESENT__ is-transitional": "It is not a tra\
\nal link", \nsitional link"
"// __DISCUSS__ underlay ": "To be discussed with TE T\ }
\opology authors" }
]
}
]
}
}
B.1.2. JSON Code: mpi1-eth-topology.json
This is the JSON code reporting the ETH Topology @ MPI1:
========== NOTE: '\\' line wrapping per BCP XXX (RFC XXXX) ==========
{
"// __LAST_UPDATE__": "October 16, 2019",
"// __TITLE__": "ETH Black Topology @ MPI1",
"// __REFERENCE_DRAFTS__": {
"ietf-routing-types@2017-12-04": "rfc8294",
"ietf-te-types@2019-07-05": "draft-ietf-teas-yang-te-types-10",
"ietf-network@2018-02-26": "rfc8345",
"ietf-network-topology@2018-02-26": "rfc8345",
"ietf-te-topology@2019-02-07": "draft-ietf-teas-yang-te-topo-22",
"ietf-eth-tran-types@2019-03-27": "draft-ietf-ccamp-client-signa\
\l-yang-00",
"ietf-eth-te-topology@2019-07-08": "draft-zheng-ccamp-client-top\
\o-yang-06"
},
"// __MISSING_ATTRIBUTES__": true,
"ietf-network:networks": {
"network": [
{
"network-id": "providerId/201/clientId/300/topologyId/eth-bl\
\ack-topology",
"network-types": {
"ietf-te-topology:te-topology": {
"ietf-eth-te-topology:eth-tran-topology": {}
}
},
"ietf-te-topology:te-topology-identifier": {
"provider-id": 201,
"client-id": 300,
"te-topology-id": "eth-black-topology"
},
"// __COMMENT__ ietf-te-topology:te": "presence container re\
\quires: provider-id, client-id and te-topology-id",
"ietf-te-topology:te": {
"name": "ETH Black Topology @ MPI1"
},
"ietf-network:node": [
{
"// __NODE__:__DESCRIPTION__": {
"name": "AN1",
"identifier": "10.0.0.1",
"type": "Abstract Node",
"physical node(s)": "The whole network domain 1"
}, },
"node-id": "10.0.0.1",
"ietf-te-topology:te-node-id": "10.0.0.1",
"// __COMMENT__ supporting-node": "Not used because topo\
\logy hierarchy is outside the scope of this JSON example",
"ietf-te-topology:te": {
"te-node-attributes": {
"name": "AN11",
"is-abstract": {},
"admin-status": "up"
},
"oper-status": "up",
"// __NOT-PRESENT__ tunnel-termination-point": "ETH Ac\
\cess Links only (no ETH TE switching)"
},
"ietf-network-topology:termination-point": [
{
"// __DESCRIPTION__:__LTP__": {
"name": "AN1-1 LTP",
"link type(s)": "Multi-function (OTU2, STM-64 and \
\10GE)",
"physical node": "S3",
"unnumberd/ifIndex": 1,
"port type": "tributary port",
"connected to": "R1"
},
"tp-id": "1",
"ietf-te-topology:te-tp-id": 1,
"ietf-te-topology:te": {
"name": "AN1-1 LTP",
"// __NOT-PRESENT__ interface-switching-capability\
\": "ETH Access Link only (no ETH TE switching)",
"// __COMMENT__ inter-domain-plug-id": "Use of plu\
\g-id for access Link is outside the scope of this document",
"// __COMMENT__ inter-layer-lock-id": "AN1-1 ILL-I\
\D (1)",
"inter-layer-lock-id": [
1
],
"admin-status": "up",
"oper-status": "up"
},
"// __COMMENT__ ingress-bandwidth-profile": "Outside\
\ the scope of this JSON example",
"ietf-eth-te-topology:eth-svc": {
"client-facing": true,
"supported-classification": {
"port-classification": true,
"vlan-classification": {
"vlan-tag-classification": true,
"outer-tag": {
"supported-tag-types": [
"ietf-eth-tran-types:classify-c-vlan"
],
"vlan-range": "1-4094"
}
}
},
"supported-vlan-operations": {
"transparent-vlan-operations": true
}
}
},
{
"// __DESCRIPTION__:__LTP__": {
"name": "AN1-8 LTP",
"link type(s)": "10GE",
"physical node": "S6",
"unnumberd/ifIndex": 1,
"port type": "tributary port",
"connected to": "R2"
},
"tp-id": "8",
"ietf-te-topology:te-tp-id": 8,
"ietf-te-topology:te": {
"name": "AN1-8 LTP",
"// __COMMENT__ inter-layer-lock-id": "AN1-8 ILL-I\
\D (8)",
"// __NOT-PRESENT__ interface-switching-capability\
\": "ETH Access Link only (no ETH TE switching)",
"// __COMMENT__ inter-domain-plug-id": "Use of plu\
\g-id for access Link is outside the scope of this document",
"inter-layer-lock-id": [
8
],
"admin-status": "up",
"oper-status": "up"
},
"// __COMMENT__ ingress-bandwidth-profile": "Outside\
\ the scope of this JSON example",
"ietf-eth-te-topology:eth-svc": {
"client-facing": true,
"supported-classification": {
"port-classification": true,
"vlan-classification": {
"vlan-tag-classification": true,
"outer-tag": {
"supported-tag-types": [
"ietf-eth-tran-types:classify-c-vlan"
],
"vlan-range": "1-4094"
}
}
},
"supported-vlan-operations": {
"transparent-vlan-operations": true
}
}
}
]
}
],
"ietf-network-topology:link": [
{
"// __DESCRIPTION__:__LINK__": {
"name": "Access Link from AN1-1",
"type": "Multi-function access link (OTU2, STM-64 and \
\10GE)",
"physical link": "Link from S3-1 to R1"
},
"link-id": "teNodeId/10.0.0.1/teLinkId/1",
"source": { "source": {
"source-node": "10.0.0.1", "source-node": "10.0.0.1",
"source-tp": 7 "source-tp": 1
}, },
"// __EMPTY__ destination": "access link" "// __NOT-PRESENT__ destination": "access link",
"ietf-te-topology:te": {
"te-link-attributes": {
"name": "Access Link from AN1-1",
"// __NOT-PRESENT__ external-domain": "The plug-id i\
\s used instead of this container",
"// __NOT-PRESENT__ is-abstract": "The access link i\
\s not abstract",
"// __NOT-PRESENT__ interface-switching-capability":\
\ "ETH Access Link only (no ETH TE switching)",
"// __NOT-PRESENT__ label-restrictions": "ETH Access\
\ Link only (no ETH TE switching)",
"// __NOT-PRESENT__ max-link-bandwidth": "ETH Access\
\ Link only (no ETH TE switching)",
"// __NOT-PRESENT__ max-resv-link-bandwidth": "ETH A\
\ccess Link only (no ETH TE switching)",
"// __NOT-PRESENT__ unreserved-bandwidth": "ETH Acce\
\ss Link only (no ETH TE switching)",
"admin-status": "up"
},
"oper-status": "up",
"// __NOT-PRESENT__ is-transitional": "It is not a tra\
\nsitional link"
}
},
{
"// __DESCRIPTION__:__LINK__": {
"name": "Access Link from AN1-8",
"type": "10GE access link",
"physical link": "Link from S6-1 to R2"
},
"link-id": "teNodeId/10.0.0.1/teLinkId/8",
"source": {
"source-node": "10.0.0.1",
"source-tp": 8
},
"// __NOT-PRESENT__ destination": "access link",
"ietf-te-topology:te": {
"te-link-attributes": {
"name": "Access Link from AN1-8",
"// __NOT-PRESENT__ external-domain": "The plug-id i\
\s used instead of this container",
"// __NOT-PRESENT__ is-abstract": "The access link i\
\s not abstract",
"// __NOT-PRESENT__ interface-switching-capability":\
\ "ETH Access Link only (no ETH TE switching)",
"// __NOT-PRESENT__ label-restrictions": "ETH Access\
\ Link only (no ETH TE switching)",
"// __NOT-PRESENT__ max-link-bandwidth": "ETH Access\
\ Link only (no ETH TE switching)",
"// __NOT-PRESENT__ max-resv-link-bandwidth": "ETH A\
\ccess Link only (no ETH TE switching)",
"// __NOT-PRESENT__ unreserved-bandwidth": "ETH Acce\
\ss Link only (no ETH TE switching)",
"admin-status": "up"
},
"oper-status": "up",
"// __NOT-PRESENT__ is-transitional": "It is not a tra\
\nsitional link"
}
} }
] ]
} }
] ]
} }
} }
B.2. JSON Examples for Service Configuration B.2. JSON Examples for Service Configuration
B.2.1. JSON Code: mpi1-odu2-service-config.json B.2.1. JSON Code: mpi1-odu2-service-config.json
This is the JSON code reporting the ODU2 transit service This is the JSON code reporting the ODU2 transit service
configuration @ MPI: configuration @ MPI1:
========== NOTE: '\\' line wrapping per BCP XX (RFC XXXX) =========== ========== NOTE: '\\' line wrapping per BCP XXX (RFC XXXX) ==========
{ {
"// __LAST_UPDATE__": "October 23, 2019",
"// __TITLE__": "ODU2 Service Configuration @ MPI1", "// __TITLE__": "ODU2 Service Configuration @ MPI1",
"// __LAST_UPDATE__": "October 22, 2018",
"// __MISSING_ATTRIBUTES__": true,
"// __REFERENCE_DRAFTS__": { "// __REFERENCE_DRAFTS__": {
"ietf-routing-types@2017-12-04": "rfc8294", "ietf-routing-types@2017-12-04": "rfc8294",
"ietf-otn-types@2018-06-07": "draft-ietf-ccamp-otn-tunnel-model-\ "ietf-te-types@2019-07-05": "draft-ietf-teas-yang-te-types-10",
\02", "ietf-layer1-types@2019-09-09": "draft-ietf-ccamp-layer1-types-0\
"ietf-te-types@2018-07-01": "draft-ietf-teas-yang-te-16", \2",
"ietf-te@2018-07-01": "draft-ietf-teas-yang-te-16", "ietf-te@2019-04-09": "draft-ietf-teas-yang-te-21",
"ietf-otn-tunnel@2018-06-07": "draft-ietf-ccamp-otn-tunnel-model\ "ietf-otn-tunnel@2019-10-23": "draft-ietf-ccamp-otn-tunnel-model\
\-02" \-08"
}, },
"// __MISSING_ATTRIBUTES__": true,
"// __RESTCONF_OPERATION__": { "// __RESTCONF_OPERATION__": {
"operation": "PUT", "operation": "POST",
"url": "http://{{PNC1-ADDR}}/restconf/data/ietf-te:te" "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",
"// identifier": "ODU2-SERVICE-TUNNEL-ID @ MPI1", "// __COMMENT__ identifier": "ODU2-SERVICE-TUNNEL-ID @ MPI\
\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",
"// encoding and switching-type": "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",
"// source": "None: transit tunnel segment", "// __NOT-PRESENT__ source": "Transit tunnel segment",
"// destination": "None: transit tunnel segment", "// __NOT-PRESENT__ src-tp-id": "Transit tunnel segment",
"// src-tp-id": "None: transit tunnel segment", "// __NOT-PRESENT__ destination": "Transit tunnel segment",
"// dst-tp-id": "None: transit tunnel segment", "// __NOT-PRESENT__ dst-tp-id": "Transit tunnel segment",
"// ietf-otn-tunnel:src-client-signal": "None: ODU transit\
\ tunnel segment",
"// ietf-otn-tunnel:dst-client-signal": "None: ODU transit\
\ tunnel segment",
"bidirectional": true, "bidirectional": true,
"// protection": "No protection",
"// __ DEFAULT __ protection": { "// __ DEFAULT __ protection": {
"// __ DEFAULT __ enable": false "// __ DEFAULT __ enable": false
}, },
"// restoration": "No restoration",
"// __ DEFAULT __ restoration": { "// __ DEFAULT __ restoration": {
"// __ DEFAULT __ enable": false "// __ DEFAULT __ enable": false
}, },
"// te-topology-identifier": "ODU Black Topology @ MPI1", "// __COMMENT__ te-topology-identifier": "ODU Black Topolo\
\gy @ 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-otn-types:prot-ODU2" "ietf-otn-tunnel:odu-type": "ietf-layer1-types:ODU2"
}, },
"// hierarchical-link": "None: transit tunnel segment", "provisioning-state": "ietf-te-types:tunnel-state-up",
"p2p-primary-paths": { "p2p-primary-paths": {
"p2p-primary-path": [ "p2p-primary-path": [
{ {
"name": "mpi1-odu2-service-primary-path", "name": "mpi1-odu2-service-primary-path",
"path-scope": "ietf-te-types:path-scope-segment", "// __NOT-PRESENT__ te-bandwidth": "The tunnel bandw\
"// te-bandwidth": "None: only the tunnel bandwidth \ \idth is used",
\needs to be specified in transport applications", "explicit-route-objects-always": {
"explicit-route-objects": {
"route-object-include-exclude": [ "route-object-include-exclude": [
{ {
"// comment": "Tunnel hand-off OTU2 ingress in\ "// __COMMENT__": "Tunnel hand-off OTU2 ingres\
\terface (S3-1)", \s interface (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-ero", \nclude-object",
"num-unnum-hop": { "unnumbered-link-hop": {
"// node-id": "AN1 Node", "// __COMMENT__ node-id": "AN1 NODE-ID",
"node-id": "10.0.0.1", "node-id": "10.0.0.1",
"// link-tp-id": "AN1-1 LTP", "// __COMMENT__ link-tp-id": "AN1-1 LTP",
"link-tp-id": 1, "link-tp-id": 1,
"hop-type": "STRICT", "// __DEFAULT__ hop-type": "strict",
"direction": "INCOMING" "// __DEFAULT__ direction": "outgoing"
} }
}, },
{ {
"// comment": "Tunnel hand-off ODU2 ingress la\ "// __COMMENT__": "Tunnel hand-off ODU2 ingres\
\bel (ODU2 over OTU2) at S3-1", \s label (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-ero", \nclude-object",
Internet-Draft Transport NBI Applicability-Statement September 20199
"label-hop": { "label-hop": {
"te-label": { "te-label": {
"// __ DISCUSS __ odu-label": "How are HO-\ "ietf-otn-tunnel:tpn": 1,
\ODU (ODUk over OTUk) label represented?", "// __NOT-PRESENT__ ietf-otn-tunnel:tsg": \
"// __ DISCUSS __ direction": "Check with \ \"Not applicable for ODUk over OTUk",
\TE Tunnel authors", "// __NOT-PRESENT__ ietf-otn-tunnel:ts-lis\
"direction": "FORWARD " \t": "Not applicable for ODUk over OTUk",
"// __DEFAULT__ direction": "forward"
} }
} }
}, },
{ {
"// comment": "Tunnel hand-off OTU4 egress int\ "// __COMMENT__": "Tunnel hand-off OTU4 egress\
\erface (S2-1)", \ interface (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-ero",
"num-unnum-hop": { \nclude-object",
"// node-id": "AN1 Node", "unnumbered-link-hop": {
"// __COMMENT__ node-id": "AN1 Node",
"node-id": "10.0.0.1", "node-id": "10.0.0.1",
"// link-tp-id": "AN1-2 LTP", "// __COMMENT__ link-tp-id": "AN1-7 LTP",
"link-tp-id": 1, "link-tp-id": 7,
"hop-type": "STRICT", "// __DEFAULT__ hop-type": "strict",
"direction": "OUTGOING" "// __DEFAULT__ direction": "outgoing"
} }
}, },
{ {
"// comment": "Tunnel hand-off ODU2 egress lab\ "// __COMMENT__": "Tunnel hand-off ODU2 egress\
\el (ODU2 over OTU4) at S2-1", \ label (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-ero", \nclude-object",
"label-hop": { "label-hop": {
"te-label": { "te-label": {
"ietf-otn-tunnel:tpn": 1, "ietf-otn-tunnel:tpn": 1,
"ietf-otn-tunnel:tsg": "ietf-otn-types:tsg\ "ietf-otn-tunnel:tsg": "ietf-layer1-types:\
\-1.25G", \tsg-1.25G",
"ietf-otn-tunnel:ts-list": "1-8", "ietf-otn-tunnel:ts-list": "1-8",
"// __ DISCUSS __ direction": "Check with \ "// __DEFAULT__ direction": "forward"
\TE Tunnel authors",
"direction": "FORWARD "
} }
} }
} }
] ]
} }
} }
] ]
} }
} }
] ]
} }
} }
} }
skipping to change at page 72, line 17 skipping to change at page 93, line 44
] ]
} }
} }
] ]
} }
} }
} }
B.2.2. JSON Code: mpi1-odu2-tunnel-config.json B.2.2. JSON Code: mpi1-odu2-tunnel-config.json
The JSON code for this use case will be added in a future version of This is the JSON code reporting the ODU2 head tunnel segment
this document configuration @ MPI1:
An incomplete version is located on GitHub at: ========== NOTE: '\\' line wrapping per BCP XXX (RFC XXXX) ==========
{
"// __LAST_UPDATE__": "October 23, 2019",
"// __TITLE__": "ODU2 Tunnel Configuration @ MPI1",
"// __REFERENCE_DRAFTS__": {
"ietf-routing-types@2017-12-04": "rfc8294",
"ietf-te-types@2019-07-05": "draft-ietf-teas-yang-te-types-10",
"ietf-layer1-types@2019-09-09": "draft-ietf-ccamp-layer1-types-0\
\2",
"ietf-te@2019-04-09": "draft-ietf-teas-yang-te-21",
"ietf-otn-tunnel@2019-10-23": "draft-ietf-ccamp-otn-tunnel-model\
\-08"
},
"// __MISSING_ATTRIBUTES__": true,
"// __RESTCONF_OPERATION__": {
"operation": "POST",
"url": "http://{{PNC1-ADDR}}/restconf/data/ietf-te:te/tunnels"
},
"ietf-te:te": {
"tunnels": {
"tunnel": [
{
"name": "mpi1-odu2-tunnel",
"// __COMMENT__ identifier": "ODU2-TUNNEL-ID @ MPI1",
"identifier": 2,
"description": "TNBI Example for an ODU2 Head Tunnel Segme\
\nt @ MPI1",
"// __COMMENT__ encoding and switching-type": "OTN (ODU)",
"encoding": "ietf-te-types:lsp-encoding-oduk",
"switching-type": "ietf-te-types:switching-otn",
"// __COMMENT__ source": "AN1 Node-ID",
"source": "10.0.0.1",
"// __COMMENT__ src-tp-id": "AN1-1 TTP-ID (1 -> 0x01 -> '0\
\1')",
"src-tp-id": "01",
"// __NOT-PRESENT__ destination": "Head tunnel segment",
"// __NOT-PRESENT__ dst-tp-id": "Head tunnel segment",
"bidirectional": true,
"// __ DEFAULT __ protection": {
"// __ DEFAULT __ enable": false
},
"// __ DEFAULT __ restoration": {
"// __ DEFAULT __ enable": false
},
"// __COMMENT__ te-topology-identifier": "ODU Black Topolo\
https://github.com/danielkinguk/transport-nbi \gy @ MPI1",
"te-topology-identifier": {
"provider-id": 201,
"client-id": 300,
"topology-id": "otn-black-topology"
},
"te-bandwidth": {
"ietf-otn-tunnel:odu-type": "ietf-layer1-types:ODU2"
},
"provisioning-state": "ietf-te-types:tunnel-state-down",
"p2p-primary-paths": {
"p2p-primary-path": [
{
"name": "mpi1-odu2-tunnel-primary-path",
"// __NOT-PRESENT__ te-bandwidth": "The tunnel bandw\
\idth is used",
"explicit-route-objects-always": {
"route-object-include-exclude": [
{
"// __COMMENT__": "Tunnel hand-off OTU4 egress\
\ interface (AN1-7 LTP)",
"index": 1,
"explicit-route-usage": "ietf-te-types:route-i\
\nclude-object",
"unnumbered-link-hop": {
"// __COMMENT__ node-id": "AN1 NODE-ID",
"node-id": "10.0.0.1",
"// __COMMENT__ link-tp-id": "AN1-7 LTP-ID",
"link-tp-id": 7,
"// __DEFAULT__ hop-type": "strict",
"// __DEFAULT__ direction": "outgoing"
}
},
{
"// __COMMENT__": "Tunnel hand-off ODU2 egress\
\ label (ODU2 over OTU4)",
"index": 2,
"explicit-route-usage": "ietf-te-types:route-i\
\nclude-object",
"label-hop": {
"te-label": {
"ietf-otn-tunnel:tpn": 2,
"ietf-otn-tunnel:tsg": "ietf-layer1-types:\
\tsg-1.25G",
"ietf-otn-tunnel:ts-list": "9-16",
"// __DEFAULT__ direction": "forward"
}
}
}
]
}
}
]
}
}
]
}
}
}
B.2.3. JSON Code: mpi1-epl-service-config.json B.2.3. JSON Code: mpi1-epl-service-config.json
The JSON code for this use case will be added in a future version of This is the JSON code reporting the EPL service configuration @ MPI:
this document
An incomplete version is located on GitHub at: ========== NOTE: '\\' line wrapping per BCP XXX (RFC XXXX) ==========
https://github.com/danielkinguk/transport-nbi {
"// __LAST_UPDATE__": "October 16, 2019",
"// __TITLE__": "EPL Configuration @ MPI1",
"// __REFERENCE_DRAFTS__": {
"ietf-routing-types@2017-12-04": "rfc8294",
"ietf-te-types@2019-07-05": "draft-ietf-teas-yang-te-types-10",
"ietf-eth-tran-types@2019-03-27": "draft-ietf-ccamp-client-signa\
\l-yang-00",
"ietf-eth-tran-service@2019-03-27": "draft-ietf-ccamp-client-sig\
\nal-yang-00"
},
"// __MISSING_ATTRIBUTES__": true,
"// __RESTCONF_OPERATION__": {
"operation": "POST",
"url": "http://{{PNC1-ADDR}}/restconf/data/ietf-eth-tran-service\
\:etht-svc/etht-svc-instances"
},
"ietf-eth-tran-service:etht-svc": {
"etht-svc-instances": [
{
"etht-svc-name": "mpi1-epl-service",
"etht-svc-descr": "TNBI Example for an EPL over ODU2 Service\
\ @ MPI1",
"// __DEFAULT__ etht-svc-type": "ietf-eth-tran-types:p2p-svc\
\",
"// __COMMENT__ te-topology-identifier": "ETH Black Topology\
\ @ MPI1",
"te-topology-identifier": {
"provider-id": 201,
"client-id": 300,
"topology-id": "eth-black-topology"
},
"etht-svc-end-points": [
{
"// __COMMENT__": "10GE Service End-Point at the access \
\interface (S3-1 -> AN1-1)",
"etht-svc-end-point-name": "mpi1-epl-an1-1-service-end-p\
\oint",
"etht-svc-end-point-descr": "Ethernet Service End-Point \
\at S3-1 (AN1-1) access link",
"etht-svc-access-points": [
{
"// __COMMENT__": "10GE Service Access Point at the \
\access interface (S3-1 -> AN1-1)",
"etht-svc-end-point-name": "mpi-epl-an1-1-service-ac\
\cess-point",
"// __COMMENT__ access-node-id": "AN1 NODE-ID",
"access-node-id": "10.0.0.1",
"// __COMMENT__ access-ltp-id": "AN1-1 LTP-ID",
"access-ltp-id": 1
}
]
}
],
"service-classification-type": "ietf-eth-tran-types:port-cla\
\ssification",
"// __COMMENT__ ingress-egress-bandwidth-profile": "Outside \
\the scope of this JSON example",
"// __NOT-PRESENT__ vlan-operations": "Transparent VLAN oper\
\ations",
"etht-svc-tunnels": [
{
"// __COMMENT__ tunnel-name": "ODU2 Head Tunnel Segment \
\@ MPI1",
"tunnel-name": "mpi1-odu2-tunnel"
}
],
"admin-status": "ietf-te-types:tunnel-admin-state-up"
}
]
}
}
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
skipping to change at page 74, line 5 skipping to change at page 100, line 5
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 Huawei
Email: younglee.tx@gmail.com Email: leeyoung@huawei.com
Victor Lopez Victor Lopez
Telefonica Telefonica
Email: victor.lopezalvarez@telefonica.com Email: victor.lopezalvarez@telefonica.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
Nokia
Email: dieter.beller@nokia.com
 End of changes. 332 change blocks. 
1004 lines changed or deleted 2112 lines changed or added

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