TR-5XX.1-TAPI v2.1.2 Reference Implementation

TAPI v2.1.
2 Reference
Implementation
TR-5XX
Overview
Version 0.1
August 2019
TR-5XX.1 TAPI v2.1.2 Reference Implementation Version 0.1
ONF Document Type: Technical Recommendation

ONF Document Name: Core Information Model version 1.4
Disclaimer
THIS SPECIFICATION IS PROVIDED "AS IS" WITH NO WARRANTIES
WHATSOEVER, INCLUDING ANY WARRANTY OF MERCHANTABILITY,
NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR
ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL,
SPECIFICATION OR SAMPLE.
Any marks and brands contained herein are the property of their respective owners.
Open Networking Foundation

1000 El Camino Real, Suite 100, Menlo Park, CA 94025
www.opennetworking.org
©2018 Open Networking Foundation. All rights reserved.
Open Networking Foundation, the ONF symbol, and OpenFlow are registered trademarks of the
Open Networking Foundation, in the United States and/or in other countries. All other brands,
products, or service names are or may be trademarks or service marks of, and are used to
identify, products or services of their respective owners.
Important note
This Technical Recommendations has been approved by the Project TST, but has not been
approved by the ONF board. This Technical Recommendation is a new reference
implementation document focus on v2.1.2 models, which has been approved under the ONF
publishing guidelines for 'Informational' publications that allow Project technical steering teams
(TSTs) to authorize publication of Informational documents. The designation of '-info' at the end
of the document ID also reflects that the project team (not the ONF board) approved this TR.
Page 2 of 107 © 2018 Open Networking Foundation

Table of Contents
Disclaimer.................................................................................................................................................. 2
Important note........................................................................................................................................... 2
Document History........................................................................................................................................ 7
1 Introduction......................................................................................................................................... 8
1.1 General introduction to the model.................................................................................................... 8
1.2 Introduction to this document.......................................................................................................... 8
2 Model Overview................................................................................................................................... 8
3 RESTCONF/YANG Protocol considerations......................................................................................... 9

3.1 Root tree discovery....................................................................................................................... 10
3.2 YANG models discovery.............................................................................................................. 10
3.3 Operation API (RPC) vs Data API (REST).....................................................................................10
3.4 Query filtering............................................................................................................................. 10
3.5 Data encoding.............................................................................................................................. 11
3.5.1 Namespaces....................................................................................................................... 11
3.6 Notifications................................................................................................................................ 12
3.6.1 SSE vs Websockets............................................................................................................ 12
4 ONF Transport – API (TAPI) considerations......................................................................................12

4.1 TAPI SDK version and documentation........................................................................................... 12
4.2 TAPI Information model............................................................................................................... 14
4.2.1 Context............................................................................................................................. 15
4.2.2 Node and Topology Aspects of Forwarding Domain..............................................................16
4.2.2.1 Topology............................................................................................................... 16
4.2.2.2 Node..................................................................................................................... 17
4.2.2.3 Link...................................................................................................................... 17
4.2.3 Node Edge Point v/s Service End Point v/s Connection End Point...........................................17
4.2.3.1 Node-Edge-Point (NEP).......................................................................................... 18
4.2.3.2 Service-Interface-Point (SIP)...................................................................................18
4.2.3.3 Connection-End-Point (CEP)...................................................................................18
4.2.4 Service, Connection and Route............................................................................................ 19
4.2.4.1 Connectivity-Service (CS).......................................................................................19
4.2.4.2 Connection............................................................................................................ 19
4.2.4.3 Route.................................................................................................................... 19
4.2.4.4 Path...................................................................................................................... 19
4.3 TAPI Data API............................................................................................................................ 20

4.4 TAPI Notifications....................................................................................................................... 21
5 Topology abstraction model................................................................................................................ 22

5.1 Model guidelines.......................................................................................................................... 22
5.2 Inventory considerations............................................................................................................... 27
5.3 Network scenarios........................................................................................................................ 29
5.3.1 Scenario 1: ROADM network equipped with OTN matrices...................................................30
5.3.1.1 Model representation.............................................................................................. 30
5.3.2 Scenario 2: Point-to-point DWDM link + Mesh DWDM network...........................................31
5.3.2.1 Model representation.............................................................................................. 32
6 Connectivity service model.................................................................................................................. 33

6.1 Model guidelines.......................................................................................................................... 33
6.1.1 Multi-layer connectivity service provisioning and connection generation.................................35
6.1.1.1 Option A: Top most layer top-connection modelling with inter-layer referencing..........35
6.1.1.2 Option B: Per layer top-connection modelling without inter-layer referencing..............39
6.1.2 Resiliency mechanism at connectivity service.......................................................................43
6.1.3 Topology and service constrains for connectivity services......................................................44
7 Use cases Low Level designs (LLDs).................................................................................................... 46

7.1 Use case 0: Topology and services discovery..................................................................................47
7.1.1 Use Case 0a: Context & Service Interface Points discovery (synchronous mode)......................47
7.1.1.1 Required parameters............................................................................................... 49
7.1.2 Use Case 0b: Topology discovery (synchronous mode)..........................................................51
7.1.2.1 Required parameters............................................................................................... 53
7.2 Use case 1: Unconstrained E2E Service Provisioning...............................................................59
7.2.1 Use case 1a: Unconstrained DSR Service Provisioning single wavelength (<100G)......59
7.2.1.1 Required parameters...........................................................................................61
7.2.1.2 Expected results.................................................................................................. 69
7.2.2 Use Case 1b: Unconstrained DSR Service Provisioning multi wavelength (beyond 100G).
73
7.2.3 Use case 1c: Unconstrained ODU Service Provisioning.................................................75
7.2.4 Use case 1d: Unconstrained PHOTONIC_MEDIA/OTSi Service Provisioning................75
7.2.5 Use case 1e: Unconstrained PHOTONIC_MEDIA/ OTSiA/OTSiG Service Provisioning.76
7.3 Use case 3: Constrained Provisioning.......................................................................................78
7.3.1 Use case 3a: Include/exclude a node or group of nodes.................................................78
7.3.2 Use case 3b: Include/exclude a link or group of links......................................................78
7.3.3 Use case 3c: Include/exclude the path used by other service.........................................78
7.4 Use case 5: Use case 5: 1+1 protection with diverse service Provisioning..............................81
7.4.1 Use case 5a: 1+1 OLP Client Protection with Diverse Service Provisioning...................81

7.4.2 Use case 5b: 1+1 OLP Line Protection with Diverse Service Provisioning......................81
7.4.2.1 Expected result.................................................................................................... 82
7.4.3 Use case 5c: 1+1 protection with Diverse Service Provisioning (eSNCP).......................86
7.4.3.1 Expected result.................................................................................................... 88
7.5 Use case 6: Restoration policies for unconstrained and constrained connectivity services.......90
7.5.1 Use case 6a: Dynamic restoration policy for unconstrained and constrained connectivity
services...................................................................................................................................... 90
7.6 Use case 7: Restoration and protection schemas......................................................................91
7.6.1 Use case 7a: Dynamic restoration and 1+1 protection of DSR/ODU unconstrained
service provisioning.................................................................................................................... 91
7.7 Use Case 10: Service deletion (applicable to all previous use cases).......................................93
8 References........................................................................................................................................ 95
9 Definitions.......................................................................................................................................... 96
9.1 Terms defined elsewhere............................................................................................................... 96
9.2 Terms defined in this TR............................................................................................................... 96
9.3 Abbreviations and acronyms......................................................................................................... 96
9.4 This TR uses the following abbreviations and acronyms (Note that some cross references are included
here rather than in the Summary of main changes between version 1.3.1 and 1.4.........................................96
10 Conventions...................................................................................................................................... 103
10.1 Lifecycle Stereotypes................................................................................................................. 103
10.2 Key to diagram symbol set.......................................................................................................... 103
11 Future CoreModel work areas.......................................................................................................... 105
12 Terminology Translation table.......................................................................................................... 105
13 Documentation structure.................................................................................................................. 105
14 Individuals engaged.......................................................................................................................... 107

14.1 Editors...................................................................................................................................... 107
14.2 Contributors.............................................................................................................................. 107
List of Figures
Figure 2-1 Target OSS – SDN architecture for WDM..................................................................................9
Figure 4-1 Transport API Functional Architecture......................................................................................14
Figure 4-2 TAPI Mapping from ITU-T........................................................................................................ 18

Figure 5-1 NS-1: OTN/WDM Network scenario......................................................................................... 30

Figure 5-2 NS-1.T0: TAPI Topology Flat Abstraction model......................................................................30
Figure 5-3 NS-1.T0: TAPI Topology Flat Abstraction view comparison with Layered view........................31
Figure 5-4 NS-2: OTN/WDM Network scenario 2......................................................................................31
Figure 5-5 NS-2.T0: TAPI Topology Flat Abstraction model......................................................................32
Figure 5-6 NS-2.T0: TAPI Topology Flat Abstraction model comparison with Layered model..................32
Figure 7-1 UC-0a: Service Interface Point - LLD Workflow........................................................................47
Figure 7-2 UC-0b: Topology discovery - LLD Workflow.............................................................................52
Figure 7-3 UC-1: Unconstrained end-to-end service provisioning.............................................................59
Figure 7-4 TAPI Logical Termination Point Template – Basic Arrangements............................................68
Figure 7-5 Connectivity Service 10GE client signal over ODU2 (DSR-ODU Fixed Mapping) – Step1.......68
Figure 7-6 Connectivity Service 10GE client signal over ODU2 (DSR-ODU Fixed Mapping) – Step2
(ODU4 Top Connection creation)........................................................................................................ 69
(ODU2 over ODU4 Top Connection cross-connection).......................................................................69
(ODU4 over OTSi)............................................................................................................................... 70
Figure 7-9 Connectivity Service 10GE client signal over ODU2 (DSR-ODU Fixed Mapping) – Step5 (ODU
4 over OTSi over NMC)....................................................................................................................... 70
Figure 7-10 Connectivity Service 1GE client signal over ODU0 over ODU2 over ODU4 (Fixed DSR-ODU
mapping, flexible ODU allocation)....................................................................................................... 71
Figure 7-11 Connectivity Service 1GE client signal over ODU0 over ODU2 over ODU4 (Fixed DSR-ODU
mapping, flexible ODU allocation) with intermediate ODU0 switching.................................................71
Figure 7-12 Connectivity Service 10GE client signal over ODU2 over ODU4 (Fixed DSR-ODU mapping,
flexible ODU allocation) with intermediate transponder regeneration..................................................72
Figure 7-13 200GE DSR Service Provisioning over multi wavelength OTSiA (beyond 100G)..................73
Figure 7-14 OTSi single lambda connecitiy-service...................................................................................75
Figure 7-15 OTSiA/OTSiG multi-wavelength connectivity-service.............................................................76
Figure 7-16 UC-5b OLP protection schemas............................................................................................. 79
Figure 7-17 UC-5b OLP TAPI Connectivity-Service low-level description.................................................81
Figure 7-18 UC-5c eSNCP protection schema.......................................................................................... 85
Figure 7-19 UC5c: Connectivity Service 100GE client signal over ODU4 with Line Side eSNCP Protection
............................................................................................................................................................ 86
Figure 7-20 UC-10: Service Deletion workflow.......................................................................................... 92
Figure 10-1 Network diagram symbol set..................................................................................................... 102
Figure 6-2 Additional media diagram symbol set...........................................................................................103

Document History
Versio Date Description of Change
n
0.1 August 06, 2019 Initial version of the Reference Implementation document of TAPI v2.1.2

1 Introduction
1.1 General introduction to the model

This ONF Technical Recommendation (TR) focuses on the definition of a Reference
Implementation guide for a TRANSPORT-API (TAPI) based RESTCONF implementation focus
on the v2.1.2 version of the TAPI information models (pruned/refactored from the ONF Core
Information Model 1.2) and available in the public ONF Github repository at
https://github.com/OpenNetworkingFoundation/tapi.
1.2 Introduction to this document

This document acts as a guide t
2 Model Overview
The purpose of this document is to describe a set of guidelines and recommendations for a
standard use of the TAPI models in combination with RESTCONF protocol for the
implementation of the interface between network systems in charge of the control/management
of networks based on WDM/OTN technologies.
The target architectures, for which this reference interface is proposed, it is conceptually
described in Figure 2-1. As depicted in the architecture, this reference NBI will be the single
interface between Operations Support Systems (OSS) and the different SDN-Cs. The scope
includes multiple domains within the same network, where each domain SDN-C will export its
TAPI context, which will be consumed by the OSS or other applications directly or through and
intermediate multi-domain orchestrator (SDTN controller) which will expose an unified view.
Thus, this NBI specification will be used between a SDN-C and an SDTN Controller/OSS where
the SDN-C provides a view via a context to the SDTN Controller/OSS and the SDTN
Controller/OSS maintains that view in a database (probably transformed into a local model).
This document aims to define the base requirements of the management plane, implemented
through a standard interface over the SDN-C, to cover any use case for activation/configuration,
service provisioning, path-computation and monitoring of the WDM/OTN network.
The term “management” shall express that the scope is much wider than just configuring. The
proposed common interface shall account for:
 Configuration, e.g. for automating and optimizing the network services creation and
processes.
 Status, e.g. for automated configuration depending on current network status.
 Events (Alarms), e.g. for automated initiation of countermeasures.
 Current and Historical Performance Values, e.g. for perpetual network analysis.

This specification is supported by standards, protocol specifications, IETF RFCs, ITU-T

recommendations and the ONF Transport API (TAPI) documentation. The appropriate
references to this supplementary material are included where appropriate along the document to
support the statements which conforms this specification. However, this document does not
intends to re-define the protocols or information models composing the specification but to
complement, clarify or extends in those cases where a corner case or different interpretations
have been found along the mentioned standards.
Figure 2-1 Target OSS – SDN architecture for WDM
3 RESTCONF/YANG Protocol considerations

RESTCONF [RFC 8040] is proposed as the transport protocol for all the defined management
operations in the SDN architecture NBIs.
RESTCONF is a HTTP-based protocol that provides a programmatic interface for accessing data
defined in YANG 1.0 [RFC 6020] using the data store concepts defined in the Network
Configuration Protocol (NETCONF) [RFC 6241].
The RESTCONF specification consists of the following resources:
 {+restconf}/data (Data API): Create/Retrieve/Update/Delete (CRUD) based API for the
entire data tree defined in the TAPI information model YANG files (see section 4).
 {+restconf}/operations (Operations API): RPC based API consisting on a small set of
operations defined as RPCs in the TAPI information model YANG files.
 {+restconf}/data/ietf-restconf-monitoring:restconf-state/streams (Notifications API):
Notifications implementation of RESTCONF protocol is defined in
https://tools.ietf.org/html/rfc8040#section-6.3.
 {+restconf}/yang-library-version: This mandatory leaf identifies the revision date of the
"ietf-yang-library" YANG module that is implemented by this server.

3.1 Root tree discovery

The RESTCONF API {+restconf} root resource can be discovered by getting the "/.well-
known/host-meta" resource ([RFC 6415]) and using the <Link> element containing the
"restconf" attribute.
The client might send the following:
GET /.well-known/host-meta HTTP/1.1
Host: example.com
Accept: application/xrd+xml
The server might respond as follows:

HTTP/1.1 200 OK
Content-Type: application/xrd+xml
Content-Length: nnn
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
<Link rel='restconf' href='/restconf'/>
</XRD>
3.2 YANG models discovery

RESTCONF utilizes the YANG library [RFC 7895] and [RFC 8525] to allow a client to discover
the YANG module conformance information for the server, in case the client wants to use it.
The mandatory {+restconf}/yang-library-version resource is used to clearly identify the version
of the YANG library used by the server.
The server MUST implement the "ietf-yang-library" module, which MUST identify all of the
YANG modules used by the server, within the "modules-state/module" list resource. The
modules set resource is located at (both implementations are accepted so far):
 According to [RFC 7895]: {+restconf}/data/ietf-yang-library:modules-state/module
 According to [RFC 8525]: {+restconf}/data/ietf-yang-library:yang-library
3.3 Operation API (RPC) vs Data API (REST)

Currently there are two allowed APIs resources defined in RESTCONF. Although both are
compatible and valid, the recent discussions in TAPI suggest that in future releases RPCs
flavored implementations will be discontinued.
Thus, the current specification states that the support of the RESTCONF Data API is
mandatory; while the Operations API, based on the TAPI defined RPCs, is considered
optional.
3.4 Query filtering

According to RESTCONF specification, each operation allows zero or more query parameters to
be present in the request URI. Specifically, query operations’ parameters are described in

Section 4.8 of [RFC 8040]. Thus, the following query parameters MUST be supported by any
interface compliant with this specification:
Table 1: RESTCONF Query filters
Name Methods Description

content GET, Select config and/or non-config data
resources
HEAD
depth GET, Request limited subtree depth in the
reply content
HEAD
fields GET, Request a subset of the target
resource contents
HEAD
filter GET, Boolean notification filter for event
stream resources
HEAD
start-time GET, Replay buffer start time for event
stream resources
HEAD
stop-time GET, Replay buffer stop time for event
stream resources
HEAD
The specific use of these query parameters will be detailed in the different Use Cases Low Level
Design (LLDs) included in section .
The "depth", “fields”, “filter”, “replay” and “with-defauts” query parameter URIs SHALL be
listed in the "capability" leaf-list as part of the container definition in the "ietf-restconf-
monitoring" module, defined in Section 9.3 of [RFC 8040], to advertise the server capability of
supporting these query parameters. This resource shall be located at:
 {+restconf}/data/ietf-restconf-monitoring:restconf-state/capabilties
3.5 Data encoding

JSON encoding formats MUST be supported according to with Section 3.2 of [RFC 8040].
The solution adhering to this specification MUST support media type "application/yang-
data+json" as defined in [RFC 7951]. This MUST be advertised in the HTTP Header fields
“Accept” or “Content-Type” of the corresponding HTTP Request/Response messages.
3.5.1 Namespaces
According to Section 1.1.5 of [RFC 8040], "The JSON representation is defined in "JSON
Encoding of Data Modeled with YANG" [RFC7951] and supported with the "application/yang-
data+json" media type".

Thus, any implementation according to this specification MUST be compliant with the rules and
definitions included in [RFC 7951], specifically those related to namespaces qualification
included in Section 4 of [RFC 7951].
3.6 Notifications
The solution adhering to this specification must support all YANG-defined event notifications
included in the information models included in section 4.2 of this document.
The solution implementing the RESTCONF server must expose its supported notification
streams by populating the "restconf-state/streams" container definition in the "ietf-restconf-
monitoring" module defined in Section 9.3 of [RFC 8040]. The streams resource can be found at:
 {+restconf}/data/ietf-restconf-monitoring:restconf-state/streams
The RESTCONF server MUST support at least the NETCONF event stream as defined in
Section 3.2.3 of [RFC5277] with both JSON encoding format being supported and advertised as
two different location resources as described in Section 6.2 of [RFC 8040].
The RESTCONF server MUST support the RESTCONF Notifications subscription mechanism
is defined in Section 6.3 of [RFC 8040].
The solution must support the “filter” Query Parameter, as defined in Section 4.8.4 of [RFC
8040], to indicate the target subset of the possible events being advertised by the RESTCONF
server stream.
3.6.1 SSE vs Websockets

The RESTCONF standard defines the Server Sent Events (SSE) [W3C.REC-xml-20081126] as
the standard protocol for RESTCONF stream notification service; however, traditionally (such in
in previous OIF TAPI interoperability activities) the Websocket [RFC 6455] protocol
implementations have been availed by ONF and thus it is widely implemented.
4 ONF Transport – API (TAPI) considerations
4.1 TAPI SDK version and documentation

The ONF Transport API (T-API/TAPI) project is constantly evolving and new releases of the
information models are periodically updated. The TAPI 2.1.1 Release, publicly available since
10-12-2018, is the version required in the present version of this document.
As per informational purposes, we include here the TAPI SDK release notes
(https://github.com/OpenNetworkingFoundation/TAPI):
 TAPI UML Information Model - The TAPI UML models included in this TAPI release
(v2.1.1) are a normative part of the TAPI SDK and are the only source for subsequent
generated TAPI SDK components (YANG, OAS, etc.).
o These models are pruned/refactored from the ONF Core Information Model 1.4
[ONF TR-512]

o Some of the UML model artifacts (e.g., Classes, Attributes, and Types) that the
TAPI contributors consider to be evolving are marked as experimental using the
UML OpenModelProfile stereotypes. These artifacts could either become mature
or change/evolve in future releases.
 TAPI YANG Schema - The TAPI YANG models included in this TAPI release (v2.1.1)
are a normative part of the TAPI SDK.
o The YANG specifications have been generated from the corresponding UML
model using the ONF EAGLE UML2YANG mapping tool and further edited
manually to comply with the ONF IISOMI UML2YANG mapping guidelines.
o Status of YANG model artifacts can be determined by referring to the
corresponding UML artifacts. As described in the UML models, some artifacts
are considered experimental, and thus the corresponding YANG artifacts.
o The ONF TAPI release process does not guarantee backward compatibility of
YANG models across major versions of TAPI releases. The YANG model
backward compatibility criteria are outlined in section 11 of
(https://tools.ietf.org/html/rfc7950). YANG models included in this release are
not backward compatible with previous TAPI releases.
The TAPI yang models can be found at

https://github.com/OpenNetworkingFoundation/TAPI/tree/v2.1.1/YANG
TAPI YANG Schema is considered as the primary reference for TAPI information
models documentation and thus, any discussion or query about the model should
reference the YANG as the reference point for discussion.
 TAPI OpenAPI Specification - TAPI OAS ([OpenAPI] Specifications) included in this

TAPI release (v2.1.1) are an informative part of the TAPI SDK and are the recommended
REST API specifications to be used for TAPI interoperability based on this release.
o The OAS has been generated from the YANG data models included in this release
using the ONF EAGLE YANG2OAS tool following the RESTCONF protocol
specification (https://tools.ietf.org/html/rfc8040). This specification makes no
assessment as to the level of RESTCONF compliance of the TAPI REST APIs.
o Implementations may use other forms of REST APIs but must be based on the
YANG models defined in this release and are subject to implementation
agreements between concerned parties for interoperability.
The TAPI OAS specifications can be found at

https://github.com/OpenNetworkingFoundation/TAPI/tree/v2.1.1/OAS
TAPI OAS is a valuable reference implementation which may serve for early adoption of
TAPI concepts and first Proofs of Concepts (PoCs) but the present specification states
that the standard RESTCONF protocol described in the previous section must prevail
over any other implementation. Thus, any deviation of the standard included in the TAPI
OAS will be precluded in real deployments, in other words, in case of a conflict in
integration between two implementations, the RESTCONF standard will always
prevail over TAPI OAS or any other REST-alike implementation.

4.2 TAPI Information model

First attempt of defining the TAPI requirement and concepts was summarized in the [ONF TR-
527] ONF document. Here we have observed this document as a reference for high-level
description of TAPI concepts, but the information has been updated to the current object naming
and definition, which in some cases has evolved during the last years. Thus, the [ONF TR-527]
is considered obsolete and not sufficient to be single source of documentation for the TAPI
information model version which is proposed within this NBI specification.
The Transport API abstracts a common set of control plane functions such as Network
Topology, Connectivity Requests, Path Computation, OAM and Network Virtualization to a
set of Service interfaces. It also includes support for the following technology-specific interface
profiles for Carrier Ethernet (L2), Optical Transport Network (OTN) framework (L1-ODU) and
Photonic Media (L0-WDM).
Figure 4-2 Transport API Functional Architecture
The tapi-common@2018-12-10.yang model includes the “context” container which serves as the
root tree for all the rest of TAPI services which augment this module on top of the context
container.
This release supports technology-agnostic interfaces to the following functional modules:
‒ Topology Service – tapi-topology@2018-12-10.yang
‒ Connectivity Service – tapi-connectivity@2018-12-10.yang
‒ OAM Service – tapi-oam@2018-12-10.yang
‒ Path Computation Service – tapi-path-computation@2018-12-10.yang
‒ Virtual Network Service – tapi-virtual-network@2018-12-10.yang
‒ Notification Service – tapi-notification@2018-12-10.yang
It also includes support for the following technology-specific interface profiles:

‒ Carrier Ethernet (L2) – tapi-eth@2018-12-10.yang

‒ DSR - tapi-dsr@18-10-16.yang
‒ Optical Transport Network (L1-ODU) – tapi-odu@2018-12-10.yang
‒ Photonic Media (L0-WDM) – tapi-photonic-media@2018-12-10.yang
The entire list of YANG models composing the TAPI information model can be found in Error:
Reference source not found.
Table 2: TAPI YANG models summary.
Model Version Revision (dd/mm/yyyy)
tapi-common.yang 2.1.2 10/12/2018

tapi-connectivity.yang 2.1.2 10/12/2018
tapi-eth.yang 2.1.2 10/12/2018
tapi-dsr.yang 2.1.2 10/12/2018
tapi-notification.yang 2.1.2 10/12/2018
tapi-oam.yang 2.1.2 10/12/2018
tapi-odu.yang 2.1.2 10/12/2018
tapi-photonic-media.yang 2.1.2 10/12/2018
tapi-path-computation.yang 2.1.2 10/12/2018
tapi-topology.yang 2.1.2 10/12/2018
tapi-virtual-network.yang 2.1.2 10/12/2018
Last but not lease, TAPI models are pruned/refactored from the ONF Core Information Model
(Core IM) 1.44 [ONF TR-512], thus some of the Core IM model concepts are key to understand
the TAPI semantics and meanings. In this section, we introduce some associations to ONF Core
IM concepts, for more a full explanation of these concepts please refer to [ONF TR-512]
document.
In the rest of this section it is included a brief overview of the main TAPI concepts which will be
used along the rest of the document.
4.2.1 Context
T-API is based on a context relationship between a server (SDN Controller) and client (SDN
Application). A Context is an abstraction that allows for logical isolation and grouping of
network resource abstractions for specific purposes/applications and/or information
exchange with its users/clients over an interface.
It is understood that the APIs are executed within a shared Context between the API provider and
its client application. A shared Context models everything that exists in an API provider
to support a given API client.
For the role of the WDM/OTN SDN Domain Controller as defined in [GCTIO-SDN-Strategy], a
single context MUST be exposed, including the following information:

 The set of Service-Interface-Points exposed to the TAPI client applications representing

the available customer-facing access points for requesting network services. This set must
allow connectivity-service creation at the following layers:
 DSR Layer: Models a Digital Signal of an unspecified rate, it could be any type
of DSR signal such xGigE, FC-x, STM-x or OTU-k which are included as DSR
tapi-common:LAYER_PROTOCOL_QUALIFIER valid identities in tapi-
dsr@18-10-16.yang. This value can be used when the intent is to represent a
generic digital layer signal without making any statement on its format or
overhead (processing) capabilities.
 ODU Layer: Models the ODU layer as per [ITU-T G.709]
 PHOTONIC_MEDIA Layer: Models the OCH, OTSi, OTSiA, OTSiG, OMS,
OTS and Media channels as per [ITU-T G.872].
 A topology-context which includes one or more top-level Topology objects which are:
 Dynamic representations of the L2-L0 network based on stateful synchronization
of the SDN Controller with the network elements.
 For more details please see Section 5
 A connectivity-context which includes the list of Connectivity-Service and Connection
objects created within the TAPI Context.
 For more details please see Section 5.1.
 A path-computation-context which includes the list of Path Computation Services
(tapi-path-computation:path-comp-service) requested to the TAPI server and the set of
Path objects computed by the server.
 A notification-context which includes the list of notification subscriptions and the list
notifications emitted through each notification subscription stream.
 For more details please see Section 4.4
4.2.2 Node and Topology Aspects of Forwarding Domain

The Forwarding-Domain described in the ONF Core IM, represents the opportunity to enable
forwarding between its edge-points. The Forwarding-Domain can hold zero or more instances of
Forwarding Constructs (or Connections) and provides the context for requesting and instructing
the formation, adjustment and removal of Connections.
The Forwarding-Domain supports a recursive aggregation relationship such that the internal
construction of a Forwarding-Domain can be exposed as multiple lower level Forwarding-
Domains and associated Links (partitioning).
For the purposes of API requirements, the Forwarding-Domain has been refactored as two
separate entities:
4.2.2.1 Topology
The T-API Topology is an abstract representation of the topological-aspects of a particular set of
Network Resources. It is described in terms of the underlying topological network of Nodes and
Links that enable the forwarding capabilities of that particular set of Network Resources.

4.2.2.2 Node
The T-API Node is an abstract representation of the forwarding-capabilities of a particular set of
Network Resources. It is described in terms of the aggregation of set of ports (Node-Edge-Point)
belonging to those Network Resources and the potential to enable forwarding of information
between those edge ports.
4.2.2.3 Link
The T-API Link is an abstract representation of the effective adjacency between two or more
associated Nodes in a Topology. It is terminated by Node-Edge-Points of the associated Nodes.
4.2.3 Node Edge Point v/s Service End Point v/s Connection End Point
The TAPI Logical-Termination-Point (LTP) – is realized by three different constructs: Node-
Edge-Point (NEP), Connection-End-Point (CEP) and Connectivity Service-End-Point (CSEP);
they are by design, intended to be a generic, flexible modeling constructs, that can model:
 Different technology layers
 Different network configurations
 Different vendor equipment capabilities
So as such, the inherent flexibility, while preserving the underlying pattern, could lead to
different model arrangements for same functional configuration.
The Logical-Termination-Point (LTP) described in the ONF Core IM, represents encapsulation
of the addressing, mapping, termination, adaptation and OAM functions of one or more transport
layers (including circuit and packet forms). Where the client – server relationship is fixed 1:1 and
immutable, the different layers can be encapsulated in a single LTP instance. Where there is a
n:1 relationship between client and server, the layers are split over separate instances of LTP.
Functions that can be associated/disassociated to/from an Connection, such as OAM, protection
switching, and performance monitoring are referenced as secondary entities through the
associated LTP instance.
Following an illustrative mapping between ITU-T G.800/805 and TAPI constructs is described.

Figure 4-3 TAPI Mapping from ITU-T.
4.2.3.1 Node-Edge-Point (NEP)

The Node-Edge-Point represents the inward network-facing aspects of the edge-port functions
that access the forwarding capabilities provided by the Node. Hence it provides an encapsulation
of addressing, mapping, termination, adaptation and OAM functions of one or more transport
layers (including circuit and packet forms) performed at the entry and exit points of the Node.
The Node-Edge-Points have a specific role and directionality with respect to a specific Link.
4.2.3.2 Service-Interface-Point (SIP)
The TAPI Service-Interface-Point represents the outward customer-facing aspects of the edge-
port functions that access the forwarding capabilities provided by the Node. Hence it provides a
limited, simplified view of interest to external clients (e.g. shared addressing, capacity, resource
availability, etc.), that enable the clients to request connectivity without the need to understand
the provider network internals. Service-Interface-Point have a mapping relationship (one-to-one,
one-to-many, many-to-many) to Node-Edge-Points.
4.2.3.3 Connection-End-Point (CEP)
The Connection-End-Point represents the ingress/egress port aspects that access the forwarding
function provided by the Connection. The Connection-End-Points have a client-server

relationship with the Node-Edge-Points. The Connection-End-Points have a specific role and
directionality with respect to a specific Connection.
4.2.4 Service, Connection and Route
4.2.4.1 Connectivity-Service (CS)

The T-API Connectivity-Service represents an “intent-like” request for connectivity, between
two or more Service-Interface-Points exposed by the Context. As such, Connectivity-Service is a
container for connectivity request details and is distinct from the Connection that realizes the
request. The requestor of the Connectivity-Service is expected to be able to express their intent
using just an “external” Node view of Forwarding-Domain and the advertised Service-Interface-
Points and not require knowledge of the “internal” Topology details of the Forwarding-Domain.
4.2.4.2 Connection
The T-API Connection represents an enabled (provisioned) potential for forwarding (including
all circuit and packet forms) between two or more Node-Edge-Points (another realization of LTP
described in the ONF Core IM) from the Node aspect of the Forwarding-Domain. A Connection
is typically described utilizing the “internal” Topology view of Forwarding-Domain. The T-API
Connection is terminated by Connection-End-Points which are clients of the associated Node-
Edge-Points. As such, the Connection is a container for provisioned connectivity that tracks the
state of the allocated resources and is distinct from the Connectivity-Service request.
In this specification we distinguish two different types of connections:
 Cross-Connections – defined as a connection between Connection-End-Points within a
Forwarding-Domain (TAPI Node).
 Top Connections– are defined as end-to-end connections between Connection-End-
Points within the same layer which may belong to different Forwarding-Domains (TAPI
Nodes). They can be either terminated (“infrastructure trails”) or non-terminated
(connecting client signals). These connections MUST contain a Route (Connection
Route) object, including all the Connection-End-Points traversed which belong to the
same layer of the Top Connection. The general rules that applies to the creation of Top
Connections are introduced in Section 6.1
4.2.4.3 Route
The TAPI Route represents the route of a Top Connection through the Topology representation.
It is described as a list of Connection End-Points (CEPs) cross-connected by the underlying
Lower-Connections referenced in the lower-connection list of the Top Connection1.
4.2.4.4 Path
The TAPI Path is used to represent the output of path computation APIs and is described by an
ordered list of TE Links, either as strict hops (Node-Edge-Points) or as loose hops (Nodes).
4.3 TAPI Data API

As it was described in section the TAPI information models can be divided into: Data API and
Operations API. In this first specification, only the Data API be supported and the Operations
1
The TAPI Connection Route is described in terms of Cross-Connections rather than Link-Connections (Top Connections). Conceptually a
Connection Route is concatenation of Link Connections (resources associated with a Link) and Cross-Connections (resources within the Nodes in
the underlying Topology).

API is considered as optional and its support will be considered as a plus cause it can give for
flexibility to the TAPI Client applications in order to implement the use cases proposed in this
document.
Therefore, the list of Data API entries inferred from the TAPI YANG information models,
following a RESTCONF API implementation according to the guidelines included in section ,
contains a huge list of entries which MAY not be needed to implement the use cases proposed,
and thus not all entries are considered mandatory in this version of the NBI requirements. This
API entries support different REST operations namely, CREATE, RETRIEVE, UPDATE and
DELETE (i.e., CRUD). For further clarification of its implementation according to the
RESTCONF standard please see Section 4, RFC 8040.
Thus, for the first version of this specification, it is proposed a minimal set of objects which shall
support full CRUD support according to the TAPI YANG models specification (e.g.,
configurable objects should support all operations while non configurable objects shall support
only the RETRIEVE operation). Please note that although the list of API entries is reduced here,
the whole model MUST be supported, e.g., all child resources of the proposed list of objects
need to be configurable.
The complete mandatory operation set of TAPI objects required here can be found in.
Table 3: Minimum subset required of TAPI RESTCONF Data API.
API Entry RESTCONF Operations

allowed
/tapi-common:context/ GET, POST, PUT,
DELETE, PATCH
/tapi-common:context/service-interface-point/ POST, PATCH
/tapi-common:context/service-interface-point={uuid}/ GET, PUT, DELETE,
PATCH
/tapi-common:context/tapi-topology:topology-context/nw-topology-service/ GET, POST, PUT,
DELETE, PATCH
/tapi-common:context/tapi-topology:topology-context/topology={uuid}/ GET
node={uuid}/
link={uuid}/
node={uuid}/owned-node-edge-point={uuid}/
node={uuid}/owned-node-edge-point={uuid}/tapi-connectivity:cep-list/
node={uuid}/owned-node-edge-point={uuid}/tapi-connectivity:cep-list/
connection-end-point={uuid}/
/tapi-common:context/tapi-connectivity:connectivity-context/ GET, POST, PUT,
DELETE, PATCH
/tapi-common:context/tapi-connectivity:connectivity-context/connectivity- POST, PATCH
service/
/tapi-common:context/tapi-connectivity:connectivity-context/connectivity- GET, PUT, DELETE,

service={uuid}/ PATCH
/tapi-common:context/tapi-connectivity:connectivity-context/ GET
connection={uuid}/
/tapi-common:context/tapi-path-computation:path-computation-context/ GET, POST, PUT,
DELETE, PATCH
/tapi-common:context/tapi-path-computation:path-computation-context/path- POST, PATCH
comp-service/
/tapi-common:context/tapi-path-computation:path-computation-context/path- GET, PUT, DELETE,
comp-service={uuid}/ PATCH
/tapi-common:context/tapi-path-computation:path-computation-context/ GET
path={uuid}/
/tapi-common:context/tapi-common:context/tapi-notification:notification- GET, POST, PUT,
context/ DELETE, PATCH
/tapi-common:context/tapi-common:context/tapi-notification:notification- POST, PATCH
context/notif-subscription/
/tapi-common:context/tapi-common:context/tapi-notification:notification- GET, PUT, DELETE,
context/notif-subscription={uuid}/ PATCH
Please note that the TAPI implementation based on the RESTCONF standard defines a much wider set of API
entries and, in later versions of this specification, any valid API entry within the model can be requested.
4.4 TAPI Notifications

The current TAPI information model includes a specific model, the tapi-notification@2018-12-
10.yang, which defines the format of TAPI notifications but also, a custom TAPI notification
subscription procedure to enable a TAPI client to subscribe to receive these notifications in the
form of asynchronous events.
Although the notification format is key for homogeneous event processing, the notification
service and subscription mechanism proposed by TAPI overlaps with the standard mechanism
defined by the RESTCONF standard. The standard RESTCONF notification subscription
mechanism has been already defined in Section
However, due to its proven usefulness by the defined RPC create-notification-subscription-
service, its usage is considered a valid procedure for this first version of the current
specification. An enhancement of the current model version to allow the notification subscription
mechanism through the Data API is has been already proposed.

5 Topology abstraction model

In this chapter a complete reference topology abstraction model is described. Due to the need of
composing a unified view of the network resources along different T-API implementations, some
guidelines are required in order to constrain the possibilities or interpretations of the current
proposed models.
The topology model should provide the explicit multi-layer topology representation of the L2-L0
network including OTS, OMS, NMC, NMCA, OTSi, OTSiA, ODU, DSR layers.
Based on ONF TAPI 2.1 models, a topology abstraction view are required for vendor agnostic
integration on across management/control systems in the frame of the proposed architecture in
Section 2: TAPI Topology Flat Abstraction model which collapses all layers in a single multi-
layer topology (#0).
5.1 Model guidelines

In order to properly describe the first topology abstraction model proposed, the following global
guidelines are presented:
[TAPI-TOP-MODEL-REQ-1] The network logical abstraction collapses all network
layers (DSR, ODU, OTSi/OTSiA and Photonic Media (Media Channels, OMS, OTS))
which are represented explicitelly into a single topology (T0 – Multi-layer topology),
modelled as a tapi-topology:topology object within the
tapi-topology:topology-context/tapi-topology:nw-topology-service and tapi-
topology:topology-context/topology.
[TAPI-TOP-MODEL-REQ-2] The T0 – Multi-layer topology abstraction MUST be
presented as a tapi-topology:topology object within the
tapi-topology:topology-context/topology and referenced at tapi-topology:topology-
context/tapi-topology:nw-topology-service, together with the rest of topologies described
in the previous section.
module: tapi-topology
augment /tapi-common:context:
+--rw topology-context
+--ro nw-topology-service
| +--ro topology* [topology-uuid]
| | +--ro topology-uuid -> /tapi-common:context/tapi-
topology:topology-context/topology/uuid
| +--ro uuid? uuid
| +--ro name* [value-name]
| | +--ro value-name string
| | +--ro value? string
+--ro topology* [uuid]
[TAPI-TOP-MODEL-REQ-3] The Service Interface Points (SIPs) are employed to

represent the available service entry points. There MUST be SIPs associated to all DSR,
ODU and PHOTONIC_MEDIA node-edge-points (NEPs) in the network which support

service configuration (only restrictions imposed by hardware constrains should constrain

this list, e.g., transponders with fixed DSR-ODU mapping).
[TAPI-TOP-MODEL-REQ-4] A SIP is logically mapped to at least one topology NEPs
through the tapi-topology:owned-node-edge-point/mapped-service-interface-point
attribute:
+--ro node* [uuid]
| +--ro owned-node-edge-point* [uuid]
| | +--ro mapped-service-interface-point* [service-interface-
point-uuid]
| | | +--ro service-interface-point-uuid -> /tapi-
common:context/service-interface-point/uuid
The T0 – Multi-layer topology MUST include:

DSR/ODU Layers: represents the DSR/ODU layers explicit nodes.
[TAPI-TOP-MODEL-REQ-5] ODU/DSR forwarding domains represented as multi-
layer and multi-rate tapi-topology:node, allowing the representation of the internal
mapping between DSR and ODU NEPs (multi-layer) and the multiplexing/de-
multiplexing across different ODU rates (multi-rate). ODU-OTSi transitions MUST be
represented as transitional links.
[TAPI-TOP-MODEL-REQ-6] The ODU/DSR layer network MUST be represented
explicitly at the lowest partitioning level, i.e., each ODU/DSR forwarding domain
MUST be represented as a single tapi-topology:node. The following network
components included within the category of ODU forwarding domain are:
 Transponders.
 Muxponders.
 OTN switching nodes connecting client and line boards.
[TAPI-TOP-MODEL-REQ-7] The NEPs layer qualifications allowed for these layer nodes
are:
 layer-protocol-name=DSR, ODU
 supported-cep-layer-protocol-qualifier = [DIGITAL_SIGNAL_TYPE,
ODU_TYPE]
[TAPI-TOP-MODEL-REQ-8] Internal ODU multiplexing SHALL be modelled as NEP
pools indicating the total capacity rate provided by the pool and the number of client CEP
instances supported. However this feature is not fully supported in current proposed
TAPI version (2.1.2) but is being standardized in TAPI v2.2.
Examples in section 7, may include references to NEP Pools, please do not
consider those guidelines mandatory for this current specification.

Use case example: an OTN matrix being used to map ODUk client connections into
ODU4 line connections may express its multiplexing capabilities as a single ODU NEP
pool which may have the following parameters:
 layer-protocol-name = ODU4 (TTP rate)
 supported-cep-layer-protocol-qualifier = ODU0, ODU1, ODU2, ODU2e, ODU3
(CTP rates)
 total-potential-capacity = 400G
 available-capacity = Upon connections already established over the NEP pool.
Not supported yet or extensions to TAPI 2.1 are required:

 odu-pool
 client-capacity = 1,2.5,10,40G. (currently this parameter is modelled as a
leaf, it must be leaf-list to allow multiple values)
 max-client-instances = 80, 40, 10, 10, 2 (currently this parameter is modelled
as a leaf, it must be leaf-list to allow multiple values)
 Max # TTP instances = 4
 Max # CTP per TTP instances = 80, 40, 10, 10, 2
+--ro node* [uuid]
| +--ro node-edge-point* [uuid]
| | +--ro layer-protocol-name? tapi-common:layer-protocol-name
| | +--ro supported-cep-layer-protocol-qualifier* tapi-
common:layer-protocol-qualifier
| | +--ro aggregated-node-edge-point* [topology-uuid node-uuid
node-edge-point-uuid]
| | | +--ro topology-uuid -> /tapi-common:context/tapi-
| | | +--ro node-uuid -> /tapi-common:context/tapi-
topology:topology-context/topology/node/uuid
| | | +--ro node-edge-point-uuid -> /tapi-common:context/tapi-
topology:topology-context/topology/node/owned-node-edge-point/uuid
| | +--ro total-potential-capacity
| | | +--ro total-size
| | | | +--ro value? uint64
| | | | +--ro unit? capacity-unit
| | | +--ro bandwidth-profile
...
| | +--ro available-capacity
| | | +--ro total-size
| | | | +--ro value? uint64
| | | | +--ro unit? capacity-unit
| | | +--ro bandwidth-profile
...
| | +--ro odu-node-edge-point-spec
| | | +--ro odu-pool
| | | | +--ro client-capacity? uint64
| | | | +--ro max-client-instances? uint64
| | | | +--ro max-client-size?

[TAPI-TOP-MODEL-REQ-9] NEPs forwarding capabilities within a node can be

OPTIONALLY constrained by using node-rule-group/rules/forwarding-rules. The
NEPs can be segmented according to the following conditions:
 Different layer-protocol-qualifier. In case multiple a DSR/ODU node includes
NEPs with different layer-protocol-qualifier types (i.e., between different
DSR_SIGNAL_TYPEs or ODU_TYPE), each group SHALL be segmented with a
node-rule-group, including:
o forwarding-rule=MAY_FORWARD_ACROSS_GROUP
 Not forwarding between same device ports. In some cases it might be relevant to
restrict the forwarding between client ports at the same network device (e.g.,
transponder). In this case ALL NEPs related to client ports at the same device
SHALL be segmented with a node-rule-group, including:
o forwarding-rule=CANNOT_FORWARD_ACROSS_GROUP
In case these constrains exists in the network and a service is requested between NEPs
which are not potentially connected, the TAPI Server MUST reject any Connectivity
Service request no matter this restriction was exposed or not.
+--ro node* [uuid]
| +--ro node-rule-group* [uuid]
| | +--ro rule* [local-id]
| | +--ro rule-type? rule-type
| | | +--ro forwarding-rule? forwarding-rule
| | | +--ro override-priority? uint64
| | | +--ro local-id string
| | | +--ro name* [value-name]
| | | +--ro value-name string
| | | +--ro value? string
| | +--ro node-edge-point* [topology-uuid node-uuid node-edge-
point-uuid]
| | | +--ro topology-uuid -> /tapi-common:context/tapi-
| | | +--ro node-uuid -> /tapi-common:context/tapi-
| | | +--ro node-edge-point-uuid -> /tapi-common:context/tapi-
[TAPI-TOP-MODEL-REQ-10] The ODU NEPs representing the line side transmission and
OTSi NEPs are 1:1 transitional relations expressed as transitional links. A transitional
link MUST be represented as a tapi-topology:link object including a tapi-
topology:transitioned-layer-protocol-name leaf-list attribute, which includes the pair of
layer transition, e.g., [ODU, PHOTONIC_MEDIA].

+--ro link* [uuid]
| +--ro transitioned-layer-protocol-name* string
[TAPI-TOP-MODEL-REQ-11] OTU layer is intentionally not included in the model as

ODU->OTSiA/OTSi representation is enough to cover all our defined use cases.
OTSi/Photonic Media layers: represents OTSi/Photonic Media layer networks
[TAPI-TOP-MODEL-REQ-12] The OTSi/OTSiA layer represents the optical side of the
optical terminals (transponders/muxponders). This layer consists of nodes representing
the mapping and multiplexing of OTSi signals. It consists of nodes including OTSi client
endpoints representing the Trail Termination Points (TTPs) of the OTSi connections and
OTSi/OMS endpoints representing the physical connectivity with ROADM/FOADM
add/drop ports.
[TAPI-TOP-MODEL-REQ-13] The lower layer connectivity represented between
transponder/muxponder line ports and ROADM/FOADM’s add/drop ports MUST be
represented as tapi-topology:links between OMS PHOTONIC_MEDIA NEPs.
[TAPI-TOP-MODEL-REQ-14] OTSi NEPs MUST be present on top of OMS NEPs/CEPs
to represent the effective forwarding of OTSi connections over the OMS link between
Transponder Line Ports and ROADM Add/Drop ports.
[TAPI-TOP-MODEL-REQ-15] The NEPs layer qualifications allowed within OTSi nodes
MUST be:
 layer-protocol-name= PHOTONIC_MEDIA
 supported-cep-layer-protocol-qualifier=
[PHOTONIC_LAYER_QUALIFIER_OTSi/OTSiA],
[PHOTONIC_LAYER_QUALIFIER_OMS]
[TAPI-TOP-MODEL-REQ-16] Each OTSi/OTSiA NEP MAY include the tapi-photonic-
media:media-channel-node-edge-point-spec to represent the media channel pool
resources supportable, available and occupied.
[TAPI-TOP-MODEL-REQ-17] Generally transponder/muxponder line ports and
ROADM/FOADM’s add/drop ports are 1:1 relations, in case Optical Line Protection
(OLPs) are present, OLP complexity shall be always represented in the Topology T4-
Server Photonic Media OLS topology.
[TAPI-TOP-MODEL-REQ-18] Photonic-Media forwarding domains: represents the
Photonic Media (Open Line System (OLS)) network. This forwarding domains can be
mapped to OLP, ROADM/FOADM and ILA network elements which connectivity is
always represented as OMS or OTS links. These forwarding domains SHALL expose the
capability of create Media Channel connection and connectivity services between its
endpoints.
[TAPI-TOP-MODEL-REQ-19] The NEPs layer qualifications allowed at the Photonic-
Media forwarding domains (i.e., tapi-topology:node) are:

 layer-protocol-name= PHOTONIC_MEDIA
 supported-cep-layer-protocol-
qualifier=[PHOTONIC_LAYER_QUALIFIER_OMS],
[PHOTONIC_LAYER_QUALIFIER_NMC/NMCA].
[TAPI-TOP-MODEL-REQ-20] NMC NEPs MUST be present on top of OMS NEPs/CEPs
to represent the adjacency between OTSi signals and NMCs over the OMS link between
Transponder Line Ports and ROADM Add/Drop ports.
[TAPI-TOP-MODEL-REQ-21] Each NMC/NMCA NEP MUST include the tapi-photonic-
media:media-channel-node-edge-point-spec to represent the media channel pool
resources supportable, available and occupied.
[TAPI-TOP-MODEL-REQ-22] It is assumed at minimum, the lower layer forwarding
constructs (tapi-topology:link) between forwarding domains (tapi-topology:node) which
need to be represented in this topology should be OMS links. Thus, it is assumed that
OTS layer links and intermediate OMS forwarding domains (In Line Amplifier (ILA)
sites) might be represented or not depending on vendor implementation, but OMS
forwarding constructs (links) MUST be configured in the network in advance
without being needed to be created during upper layer services provisioning
process.
[TAPI-TOP-MODEL-REQ-23] In case OLP constructs are present for OMS protection, this
should be represented in TAPI by using tapi-topology:resilience-type/tapi-
topology:protection-type link’s attribute. Underlying switch control for OMS protection
is out of the scope of this modelling.
[TAPI-TOP-MODEL-REQ-24] In the current specification it is not required to include SIPs
at this layer to be selected by users for the creation of services at the NMC/NMCA layers
and it will only connection generated by the TAPI server MUST be represented.
5.2 Inventory considerations

Hardware identifiers currently stored in legacy OSS inventory systems MUST be correlated with
T-API UUID identifiers. This information will be provided by the SDN optical domain controller
suppliers as a pre-requisite for the use cases described in section of the present document.
For every inventory element represented as a logical element in TAPI by the SDN Domain
controller, an INVENTORY_ID tapi-common:name property shall be included into the logical
element construct.
In particular the INVENTORY_ID tag SHALL be included for the following TAPI objects:
 tapi-topology:node-edge-point
 tapi-common:service-interface-point
The proposal for a common definition of the INVENTORY_ID tag, follows 2 main principles
and it is based on TMF-814 naming standards:
 It is explicit and clear: there’s no ambiguity to which field each index correspond

 It can be augmented: if a new type of field needs to be inserted it does not break
compatibility with the former format.
The generic format is the concatenation of n tuple elements “/<field>=<index>”
The supported fields for tuple elements are:
Table 4: Inventory-id fields format.
<field> meaning
ne Network Element
r Rack
sh Shelf
s_sh Sub-shelf
sl Slot
s_sl Sub-slot
p Port

The supported sequence for the tuple is the following and covers a variety of supported scenarios
that may not all be applicable.
 [ ] means that may not be present
 [ …] means that multiple values can be specified (marked as green x in the matrix)

/ne=<nw-ne-name>[/r=<r_index>][/sh=<sh_index>[/s_sh=<s_sh_index>
…]][[/sl=<sl_index>[/s_sl=<s_sl_index> …]][/p=<p_index> …]]
 <nw-ne-name> is the real Network Element (NE) name configured in the network (i.e.
not managed by the SDN-C) and MUST be unique along all exposed interfaces of the
network control and management planes (i.e., Network Management Systems (NMSs) or
Element Management Systems (EMSs) exposing network information).
 <r_index> is the real Rack index configured in the network (i.e. not managed by the
SDN-C) and MUST be unique along all exposed interfaces of the network control and
management planes (i.e., Network Management Systems (NMSs) or Element
Management Systems (EMSs) exposing network information).
 <sh_index> is the real Shelf index configured in the network (i.e. not managed by the
 <s_sh_index> is the real Sub-Shelf index configured in the network (i.e. not managed by
the SDN-C) and MUST be unique along all exposed interfaces of the network control and


 <sl_index> is the real Slot index configured in the network (i.e. not managed by the
 <s_sl_index> is the real Sub-Slot index configured in the network (i.e. not managed by
the SDN-C) and MUST be unique along all exposed interfaces of the network control and
 <p_index> is the real Port index configured in the network (i.e. not managed by the
Meaning for the port the following possible combinations depicted in the following matrix.
Each column represents which tuples can be after the element listed in the first column.
Table 5: Inventory-id fields combination allowance.
/r= /sh= /s_sh= /sl= /s_sl= /p=

<r_index <sh_inde <s_sh_in <sl_inde <s_sl_ind <p_inde
> x> dex> x> ex> x>
/ne=<nw-ne- x x - x - x
name>
/r=<r_index> - x - x - -
/sh=<sh_index> - - x x - -
/ - - x x - -
s_sh=<s_sh_index
>
/sl=<sl_index> - - - - x x
/s_sl=<s_sl_index> - - - - x x
/p=<p_index> - - - - x

Some examples of INVENTORY_ID for node-edge-points:
"name": [{"value_name": "INVENTORY_ID", "value":
"/ne=MadridNorte/r=1/sh=2/sl=3/p=1" }]
"name": [{"value_name": "INVENTORY_ID", "value":
"/ne=MadridNorte/r=1/sh=2/sl=3/s_sl=4/p=1" }]

5.3 Network scenarios

Now we introduce two network scenarios, as the base examples to clearly explain the model
assumptions explained before.
5.3.1 Scenario 1: ROADM network equipped with OTN matrices

This first scenario represents a three-ROADM network equipped with OTN matrices to perform
grooming of Ethernet 1G and 10G client signals into 100G line-side interfaces transmitting OTSi
colored optical wavelengths.
Figure 5-4 NS-1: OTN/WDM Network scenario
5.3.1.1 Model representation
Figure 5-5 NS-1.T0: TAPI Topology Flat Abstraction model.

Figure 5-6 NS-1.T0: TAPI Topology Flat Abstraction view comparison with Layered view.
5.3.2 Scenario 2: Point-to-point DWDM link + Mesh DWDM network

The second scenario consists of two separated networks: one network is a point-to-point DWDM
link separated by 2 In-Line-Amplifiers (ILAs) and terminated in Fixed OADM structures
consisting on Mux/Demux; and the second is a similar three-ROADM network this time
equipped with Transponder/Muxponder cards, the two transponders present in the network are
connected to a Line Side Optical Line Protection (OLP) structures to provide optical 1+1
protection resilient schema.
Figure 5-7 NS-2: OTN/WDM Network scenario 2.

5.3.2.1 Model representation
Figure 5-8 NS-2.T0: TAPI Topology Flat Abstraction model.
Figure 5-9 NS-2.T0: TAPI Topology Flat Abstraction model comparison with Layered model.

6 Connectivity service model

In this chapter the complete connectivity service model will be described. The intention is to
clarify some gaps which might not be clear just be reading the current description included in
TAPI YANG models which need to be enhanced in order to provide a uniform understanding on
the use of the TAPI information models. Thus, in this section a set of reference design guidelines
are stated in order to constrain the possibilities or interpretations of the current proposed models.
6.1 Model guidelines

The following guidelines MUST be met by all implementations following the current
specification.
[TAPI-CONN-MODEL-REQ-1] The solution exposing the proposed NBI based on
RESCONF/TAPI MUST expose the capability of creating Connectivity-Service at all
proposed network layers.
 DSR Layer: Models a Digital Signal of an unspecified format. This value can be
used when the intent is to represent a generic digital layer signal without making
any statement on its format or overhead (processing) capabilities.
 ODU Layer: Models the ODU layer as per described in [ITU-T G.709].
 PHOTONIC_MEDIA Layer: Models the OCH, OTSi, OTSiA, OTSiG, and
Media channels (NMC/NMCA) as per described in [ITU-T G.872].
[TAPI-CONN-MODEL-REQ-2] The connectivity model proposed is not assuming the need
of tapi-topology:node representations of the forwarding domains. Thus, as already
described in Section 4.2.4.2, this model introduces the concept of Top Connections
which are defined as end-to-end connections between Connection-End-Points within the
same layer which may belong to different Forwarding-Domains (TAPI Nodes). They can
be either terminated (“infrastructure trails”) or non-terminated (connecting client signals).
[TAPI-CONN-MODEL-REQ-3] Each tapi-connectivity:connectivity-service will always
include a reference to one or more Top Connection tapi-connectivity:connection objects
within its connection list (tapi-connectivity:connectivity-service/connection) which
describe the end-to-end connectivity across the network layers traversed by the
connectivity-service (represented as the combination of the tapi-common:layer-protocol-
name and tapi-common: layer-protocol-qualifier attributes).
module: tapi-connectivity
+--rw connectivity-context
+--rw connectivity-service* [uuid]
| +--ro connection* [connection-uuid]
| | +--ro connection-uuid -> /tapi-common:context/tapi-
connectivity:connectivity-context/connection/uuid
[TAPI-CONN-MODEL-REQ-4] The Top Connection object is intended to represent how the

requested service has been implemented within a network layer. It shall include the tapi-

connectivity:connection/route object containing the list of connection-end-points (CEPs)

traversed by the service at that layer.
+--ro connection* [uuid]
+--ro route* [local-id]
| +--ro connection-end-point* [topology-uuid node-uuid node-edge-
point-uuid connection-end-point-uuid]
| | +--ro topology-uuid ->
/tapi-common:context/tapi-topology:topology-context/topology/uuid
| | +--ro node-uuid ->
/tapi-common:context/tapi-topology:topology-context/topology/node/uuid
| | +--ro node-edge-point-uuid ->
/tapi-common:context/tapi-topology:topology-context/topology/node/owned-node-
edge-point/uuid
| | +--ro connection-end-point-uuid ->
/tapi-common:context/tapi-topology:topology-context/topology/node/owned-node-
edge-point/tapi-connectivity:cep-list/connection-end-point/uuid
| +--ro local-id string
| +--ro value-name string
| +--ro value? string
[TAPI-CONN-MODEL-REQ-5] The tapi-connectivity:connection/route is modelled as a

YANG List object of CEPs which is, by the default, ordered by the system (i.e., the TAPI
service which produces it). However, as agreed by the TAPI group, the server is not
responsible of maintaining any specific logical order of the CEP. Thus, the logical order
of the connection-end-points within the Route object SHALL be inferred by the TAPI
client by the knowledge of the Topology information and the NEP to NEP associations
[TAPI-CONN-MODEL-REQ-6] The Top Connection MUST include a reference to all the
lower connections generated in the in the same network layer, to support the end-to-end
Top Connection. These references MUST be included within the tapi-
connectivity:connection/ tapi-connectivity:lower-connection list.
+--ro lower-connection* [connection-uuid]
| +--ro connection-uuid -> /tapi-common:context/tapi-
Please note that Top Connections may include lower-level Top Connections if they
belong to the same layer (different rates) and they represent infrastructure G.805 Trails.
E.g., an ODU2 Top Connection may be included within the tapi-
connectivity:connection/tapi-connectivity:lower-connection list of an ODU0 Top
Connection.
[TAPI-CONN-MODEL-REQ-7] Top Connections may be generated to represent two
different cases:

 Non-terminated Top Connections: between CEPs with a parent-NEPs (tapi-

topology:owned-node-edge-point/tapi-connectivity:cep-list/connection-end-
point/parent-node-edge-point) directly associated to the SIPs which has been
referenced by the Service-End-Points of the Connectivity-Service associated to
this Top Connection.
augment /tapi-common:context/tapi-topology:topology-context/tapi-
topology:topology/tapi-topology:node/tapi-topology:owned-node-edge-point:
+--ro cep-list
+--ro connection-end-point* [uuid]
+--ro parent-node-edge-point
| +--ro topology-uuid? -> /tapi-common:context/tapi-
| +--ro node-uuid? -> /tapi-common:context/tapi-
| +--ro node-edge-point-uuid? -> /tapi-common:context/tapi-
 Infrastructure Trails as defined in [ITU-T g.805]: between CEPs representing

Trail Termination Points (TTPs) which handover a signal of a given layer to
a higher layer. These CEPs also produce associated client-NEPs (tapi-
topology:owned-node-edge-point/tapi-connectivity:cep-list/connection-end-
point/client-node-edge-point), to represented the generated pool of resources at a
higher network layer or rate. E.g., an ODUk CEP producing a lower order ODUj
NEP or an ODUk CEP producing DSR NEP.
augment /tapi-common:context/tapi-topology:topology-context/tapi-
topology:topology/tapi-topology:node/tapi-topology:owned-node-edge-point:
+--ro cep-list
+--ro connection-end-point* [uuid]
+--ro client-node-edge-point* [topology-uuid node-uuid node-edge-
point-uuid]
| +--ro topology-uuid -> /tapi-common:context/tapi-
| +--ro node-uuid -> /tapi-common:context/tapi-
| +--ro node-edge-point-uuid -> /tapi-common:context/tapi-
6.1.1 Multi-layer connectivity service provisioning and connection generation

For the multi-layer connectivity service representation, once provisioned, the TAPI server might
choose among two possible models for representing the hierarchy of connections among
different layers.
6.1.1.1 Option A: Top most layer top-connection modelling with inter-layer referencing
In this approach, the TAPI server only includes the Top most layer Top Connection reference
within the Connectivity Service connections list. In this approach, the multi-layer connectivity
discovery is done reclusively analyzing the lower-level connection list of the Top Connection
objects, which includes a reference to the lower layer Top Connection until the bottom most
represented layer (Photonic_Media).

Assuming a DSR Connectivity-Service has been requested between two SIPs associated to NEPs
of the DSR layer, the multi-layer connections created are described by the following
assumptions:
At DSR layer:
[TAPI-CONN-MODEL-REQ-8] The CS triggers the creation of the Top Connection at the
DSR layer:
 Once DSR Top Connection is operational (tapi-connectivity:connection/tapi-
common:operational-state = ENABLED), the DSR CS becomes operational and
includes DSR Top Connection within its connection list.
 DSR Top Connection MUST include the explicit route referencing CEPs
associated to NEPs at the DSR layer.
[TAPI-CONN-MODEL-REQ-9] One or more, DSR XC Connections, which connections
which conforms the end-to-end route of DSR Top connection and MUST be included
within its lower-connection list.
 When operational (tapi-connectivity:connection/tapi-common:operational-state
= ENABLED), the DSR Top Connection becomes operational too.
At the ODU layer the CS triggers the creation of:

[TAPI-CONN-MODEL-REQ-10] 0-N Top Connections at the ODUj layers, which
describes the multiplexing of Low Order (LO)-ODU signals into High Order (HO)-ODU
signals.
 Each ODUj Top Connection MUST include the list of ODUj lower connections
which conforms the end-to-end route of the Top Connection at this layer rate.
 When each ODUj Top Connection become operational (tapi-
connectivity:connection/tapi-common:operational-state = ENABLED) in
increasing order from lower ODU layer (higher ODU rate) to the DSR layer, the
immediately upper layer adjacency is enabled (a higher layer NEP is created
“over” the operational CEP) allowing the upper layer Top Connection is realized.
 Moreover, all ODUj Top Connections are operational, a new tapi-topology:link at
the DSR layer (layer-protocol-name=DSR) MUST be generated between the
NEPs produced by the CEPs (Trail Termination Points) of the Top Most
Connection with the ODUj Layer rate as a tapi-connectivity: supported-client-
link.
+--ro supported-client-link* [topology-uuid link-uuid]
| +--ro link-uuid -> /tapi-common:context/tapi-
topology:topology-context/topology/link/uuid

 Additionally, when operational, the Top Most ODUj Connection can be

included within the DSR Top Connection lower-connection list.
[TAPI-CONN-MODEL-REQ-11] One Top Connection at the HO-ODUk rate, which
describe the highest order ODU (supported by this node) which transport by the optical
OTSi layer.
 When operational, the HO-ODUk Top Connection MUST be included within
highest ODUj rate Top Connection’s lower-connection list.
[TAPI-CONN-MODEL-REQ-12] Possibly multiple HO-ODUk XC Connections,
which conforms the end-to-end route of HO-ODUk Top connection and MUST be
included within its lower-connection list.
 When operational, the HO-ODUk Top Connection becomes operational too.
At the T3 – OTSi/Photonic Media layer the CS triggers the creation of:
[TAPI-CONN-MODEL-REQ-13] One Top Connection at the OTSi layer between the
two NEPs connected to the HO-ODUk NEPs by transitional links. The case of multi-
OTSi mapping to an ODUk client signal is out-of-the scope of the present specification.
 When the T2 OTSi Top Connection becomes operational, an ODU tapi-
topology:link between the related HO-ODUk NEPs is created, representing the
potential adjacency between these two NEPs at the HO-ODUk layer/rate. Thus,
allowing the T2 HO-ODUk Top Connection to be realized. The new generated
link MUST be referenced by the CEPs of the Top Connection which generates it
as a tapi-connectivity: supported-client-link.
 When operational, the OTSi/OTSiA Top Connections MUST be included within

the HO-ODUk Top connection lower-connection list.
 T2 OTSi/OTSiA Top Connection MUST include the explicit route referencing
CEPs associated to NEPs of T3 topology.
[TAPI-CONN-MODEL-REQ-14] Possibly multiple OTSi/OTSiA XC Connections,
which conforms the end-to-end route of OTSi/OTSiA Top connection and MUST be
 When operational, the OTSi/OTSiA Top Connection becomes operational too.
At the Photonic Media Layer, the CS triggers the creation of a Top Connection at the
NMC/NMCA layer.

[TAPI-CONN-MODEL-REQ-15] One NMC/NMCA Top Connection at the Photonic

Media server layer between the two NEPs connected to the OTSi/OTSiA NEPs through
an OMS link.
 When the NMC/NMCA Top Connection becomes operational, an OTSi tapi-
topology:link between the related OTSi NEPs is created, representing the
potential adjacency between these two NEPs at the OTSi layer. Thus, allowing the
OTSi Top Connection to be realized. The new generated link MUST be
referenced by the CEPs of the Top Connection which generates it as a tapi-
connectivity:supported-client-link.
 Moreover, the NMC/NMCA Top Connection MUST be included within
OTSi/OTSiA Top connection lower-connection list.
 NMC/NMCA Top Connection MUST include the explicit route referencing CEPs
associated to NEPs of Photonic Media Layer.
[TAPI-CONN-MODEL-REQ-16] Possibly multiple NMC/NMCA XC Connections,
which conforms the end-to-end route of NMC/NMCA Top connection and MUST be
 When operational, the T3 NMC/NMCA Top Connection becomes operational
too.
Following a complete generic example of a DSR connectivity-service is presented to clearly
identify the connection association hierarchy described by the previous set of requirements.
{"context":{
"connectivity-context":{
"connectivity-service":[
{"uuid":"CS_UUID",
"end-point":[
{"local_id":"LOCAL_ID_A","service-interface-point":{"service-interface-point-
uuid":"SIP_UUID_A"}},
{"local_id":"LOCAL_ID_B","service-interface-point":{"service-interface-point-
uuid":"SIP_UUID_B"}}],
"connection":[
{"connection_uuid":"T1_DSR_TOP_1"}]
}
],
"connection":[
{"uuid": "DSR_TOP_1",
"lower-connection":[
{"connection-uuid":"ODUj_TOP_1"},
{"connection-uuid":"DSR_XC_1"},
{"connection-uuid":"DSR_XC_2"}
]},
{"uuid": "ODUj_TOP_1",
{"connection-uuid":"ODUj_XC_1"},
{"connection-uuid":"HO-ODUk_TOP_1"}
]},
{"uuid": "HO-ODUk_TOP_1",

{"connection-uuid":"HO-ODUk_XC_1"},
{"connection-uuid":"OTSi_TOP_1"}
]},
{"uuid": "OTSi_TOP_1",
{"connection-uuid":"NMC_TOP_1"},
{"connection-uuid":"OTSi_XC_1"},
{"connection-uuid":"OTSi_XC_2"}
]},
{"uuid": "NMC_TOP_1",
{"connection-uuid":"NMC_XC_1"},
…
{"connection-uuid":"NMC_XC_N"}
]}
]}
}
}
6.1.1.2 Option B: Per layer top-connection modelling without inter-layer referencing

In this approach, the TAPI server includes a reference to each layer Top Connection within the
Connectivity Service’s Connection list. Associations between connection objects at different
layers can be made upon the Connectivity Service which reference them (all connections appear
to be part of the connection-references list object of the Connectivity Service) or by the tapi-
topology <-> tapi-connectivity model relationships included in the tapi-
connectivity:connection/supported-client-link attribute. E.g., a lower layer
Photonic_Media/OTSi Top Connection and an ODU Top connection are related if the later’s
Route object traverse two Connection End Points (CEPs) related to two Node Edge Points which
are connected by a Link object which is referenced by an OTSi Top Connection object.
Please note, that multi-rate connections within a layer MIGHT be referenced as detailed in the
previous approach (e.g., HO-ODUk and LO-ODUj connections).
Now, assuming that a DSR Connectivity-Service has been requested between two SIPs
associated to NEPs of the DSR layer, the multi-layer connections created are described by the
following assumptions:
At DSR layer:
[TAPI-CONN-MODEL-REQ-17] The CS triggers the creation of the Top Connection
at the DSR layer:
 Once DSR Top Connection is operational (tapi-connectivity:connection/tapi-
common:operational-state = ENABLED), the DSR CS becomes operational and
includes DSR Top Connection within its connection list.
 DSR Top Connection MUST include the explicit route referencing CEPs
associated to NEPs at the DSR layer.

[TAPI-CONN-MODEL-REQ-18] One or more, DSR XC Connections, which

connections which conforms the end-to-end route of DSR Top connection and MUST be
 When operational (tapi-connectivity:connection/tapi-common:operational-state
= ENABLED), the DSR Top Connection becomes operational too.
At the ODU layer the CS triggers the creation of:

[TAPI-CONN-MODEL-REQ-19] 0-N Top Connections at the ODUj layers, which
describes the multiplexing of Low Order (LO)-ODU signals into High Order (HO)-ODU
signals.
 Once each 0-N Top Connections at the ODUj layers are operational (tapi-
connectivity:connection/tapi-common:operational-state = ENABLED), all TOP
connections MUST be included within the CS connection list.
 Each ODUj Top Connection MUST include the list of ODUj lower connections
which conforms the end-to-end route of the Top Connection at this layer rate.
 When each ODUj Top Connection become operational (tapi-
connectivity:connection/tapi-common:operational-state = ENABLED) in
increasing order from lower ODU layer (higher ODU rate) to the DSR layer, the
immediately upper layer adjacency is enabled (a higher layer NEP is created
“over” the operational CEP) allowing the upper layer Top Connection is realized.
 Moreover, when all ODUj Top Connections are operational, a new tapi-
topology:link at the DSR layer (layer-protocol-name=DSR) MUST be generated
between the NEPs produced by the CEPs (Trail Termination Points) of the Top
Most Connection with the ODUj Layer rate as a tapi-connectivity: supported-
client-link.
[TAPI-CONN-MODEL-REQ-20] One Top Connection at the HO-ODUk rate, which

describe the highest order ODU (supported by this node) which transport by the optical
OTSi layer.
 Once the HO-ODUk Top Connection is operational (tapi-
connectivity:connection/tapi-common:operational-state = ENABLED), it
MUST be included within the CS connection list.
 When operational, the HO-ODUk Top Connection MUST be included within
highest ODUj rate Top Connection’s lower-connection list.

[TAPI-CONN-MODEL-REQ-21] Possibly multiple HO-ODUk XC Connections,

which conforms the end-to-end route of HO-ODUk Top connection and MUST be
 When operational, the HO-ODUk Top Connection becomes operational too.
At the T3 – OTSi/Photonic Media layer the CS triggers the creation of:
[TAPI-CONN-MODEL-REQ-22] One Top Connection at the OTSi layer between the
two NEPs connected to the HO-ODUk NEPs by transitional links. The case of multi-
OTSi mapping to an ODUk client signal is out-of-the scope of the present specification.
 Once the OTSi Top Connection is operational (tapi-connectivity:connection/tapi-
common:operational-state = ENABLED), it MUST be included within the CS
connection list.
 When the OTSi Top Connection becomes operational, an ODU tapi-topology:link
between the related HO-ODUk NEPs is created, representing the potential
adjacency between these two NEPs at the HO-ODUk layer/rate. Thus, allowing
the T2 HO-ODUk Top Connection to be realized. The new generated link MUST
be referenced by the Top Connection, which realizes it, as a tapi-connectivity:
supported-client-link.
 OTSi/OTSiA Top Connection MUST include the explicit route referencing CEPs
associated to NEPs of PHOTONIC_MEDIA Layer with OTSI supported-layer-
qualifier.
[TAPI-CONN-MODEL-REQ-23] Possibly multiple OTSi/OTSiA XC Connections,
which conforms the end-to-end route of OTSi/OTSiA Top connection and MUST be
 When operational, the OTSi/OTSiA Top Connection becomes operational too.
At the Photonic Media Layer, the CS triggers the creation of a Top Connection at the
NMC/NMCA layer.
[TAPI-CONN-MODEL-REQ-24] One NMC/NMCA Top Connection at the Photonic
Media server layer between the two NEPs connected to the OTSi/OTSiA NEPs through
an OMS link.
 Once the NMC/NMCA Top Connection is operational (tapi-
connectivity:connection/tapi-common:operational-state = ENABLED), it
MUST be included within the CS connection list.

 When the NMC/NMCA Top Connection becomes operational, an OTSi tapi-

topology:link between the related OTSi NEPs is created, representing the
potential adjacency between these two NEPs at the OTSi layer. Thus, allowing the
OTSi Top Connection to be realized. The new generated link MUST be
referenced by the CEPs of the Top Connection which generates it as a tapi-
connectivity:supported-client-link.
 Moreover, the NMC/NMCA Top Connection MUST be included within
OTSi/OTSiA Top connection lower-connection list.
 NMC/NMCA Top Connection MUST include the explicit route referencing CEPs
associated to NEPs of Photonic Media Layer.
[TAPI-CONN-MODEL-REQ-25] Possibly multiple NMC/NMCA XC Connections,
which conforms the end-to-end route of NMC/NMCA Top connection and MUST be
 When operational, the NMC/NMCA Top Connection becomes operational too.
Following a complete generic example of a DSR connectivity-service is presented to clearly
identify the connection association hierarchy described by the previous set of requirements.
{"context":{
"connectivity-context":{
"connectivity-service":[
{"uuid":"CS_UUID",
"end-point":[
{"local_id":"LOCAL_ID_A","service-interface-point":{"service-interface-point-
uuid":"SIP_UUID_A"}},
{"local_id":"LOCAL_ID_B","service-interface-point":{"service-interface-point-
uuid":"SIP_UUID_B"}}],
"connection":[
{"connection_uuid":"DSR_TOP_1"},
{"connection-uuid":"OTSi_TOP_1"},
{"connection-uuid":"NMC_TOP_1"}
]}
],
"connection":[
{"uuid": "DSR_TOP_1",
{"connection-uuid":"DSR_XC_1"},
{"connection-uuid":"DSR_XC_2"}
]},
{"uuid": "ODUj_TOP_1",
]},
… (repeated for N ODUj layer rates)
{"uuid": "ODUj_TOP_N",

{"connection-uuid":"HO-ODUk_TOP_1"},
]},
{"uuid": "HO-ODUk_TOP_1",
{"connection-uuid":"HO-ODUk_XC_2"}
]},
{"uuid": "OTSi_TOP_1",
{"connection-uuid":"OTSi_XC_1"},
{"connection-uuid":"OTSi_XC_2"}
]},
{"uuid": "NMC_TOP_1",
…
{"connection-uuid":"NMC_XC_N"}
]}
]}
}
}
6.1.2 Resiliency mechanism at connectivity service

[TAPI-CONN-MODEL-REQ-26] In order to implement different mechanism of
protection the TAPI Server MUST support the following protection and restoration
policies (tapi-topology:protection-type) at the Connectivity Service level:
 ONE_PLUS_ONE_PROTECTION
 ONE_PLUS_ONE_PROTECTION_WITH_DYNAMIC_RESTORATION
 PERMANENT_ONE_PLUS_ONE_PROTECTION
 ONE_FOR_ONE_PROTECTION
 DYNAMIC_RESTORATION
 PRE_COMPUTED_RESTORATION
| +--rw resilience-type
| | +--rw restoration-policy? restoration-policy
| | +--rw protection-type? protection-type
[TAPI-CONN-MODEL-REQ-27] For all protected services with restoration

capabilities, the default behavior assumed in this specification is
PER_DOMAIN_RESTORATION which implies the TAPI server is responsible of
activating the required control mechanisms to guarantee the restoration of the service
autonomously.

[TAPI-CONN-MODEL-REQ-28] At the Connection level, the switch control among

lower-connections, which implements the route diversity for the different levels of
protection policies listed in [TAPI-CONN-MODEL-REQ-26], MUST be implemented by
the TAPI server. The TAPI server MUST be able to describe these mechanisms by the
tapi-connectivity:connection/switch-control. The specific switch-control mechanisms for
each protection schema will be detailed in Section 7.4.
+--rw connection* [uuid]
+--ro switch-control* [uuid]
| +--ro sub-switch-control* [connection-uuid switch-control-uuid]
| | +--ro connection-uuid -> /tapi-common:context/tapi-
| | +--ro switch-control-uuid -> /tapi-common:context/tapi-
connectivity:connectivity-context/connection/switch-control/uuid
| +--ro switch* [local-id]
| | +--ro selected-connection-end-point* [topology-uuid node-uuid
node-edge-point-uuid connection-end-point-uuid]
| | | +--ro connection-end-point-uuid -> /tapi-
common:context/tapi-topology:topology-context/topology/node/owned-node-edge-
point/tapi-connectivity:cep-list/connection-end-point/uuid
| | +--ro selected-route* [connection-uuid route-local-id]
| | | +--ro connection-uuid -> /tapi-common:context/tapi-
| | | +--ro route-local-id -> /tapi-common:context/tapi-
connectivity:connectivity-context/connection/route/local-id
| | +--ro selection-control? selection-control
| | +--ro selection-reason? selection-reason
| | +--ro switch-direction? tapi-common:port-direction
| | +--ro local-id string
| | +--ro name* [value-name]
| +--ro uuid uuid
| +--ro resilience-type
| | +--ro restoration-policy? restoration-policy
| | +--ro protection-type? protection-type
| +--ro restoration-coordinate-type? coordinate-type
| +--ro restore-priority? uint64
| +--ro reversion-mode? reversion-mode
| +--ro wait-to-revert-time? uint64
| +--ro hold-off-time? uint64
| +--ro is-lock-out? boolean
| +--ro is-frozen? boolean
| +--ro is-coordinated-switching-both-ends? boolean
| +--ro max-switch-times? uint64
| +--ro preferred-restoration-layer* tapi-common:layer-protocol-
name
6.1.3 Topology and service constrains for connectivity services

[TAPI-CONN-MODEL-REQ-29] In order to implement different use cases which
imply the constrain of the service path along the network topology, the following
attributes of the tapi-onnectivity:connectivity-service object MUST be implemented.

| +--rw coroute-inclusion
| | +--rw connectivity-service-uuid? -> /tapi-common:context/tapi-
connectivity:connectivity-context/connectivity-service/uuid
| +--rw diversity-exclusion* [connectivity-service-uuid]
| | +--rw connectivity-service-uuid -> /tapi-common:context/tapi-
connectivity:connectivity-context/connectivity-service/uuid
| +--rw diversity-policy? diversity-policy
| +--rw include-topology* tapi-common:uuid
| +--rw avoid-topology* tapi-common:uuid
| +--rw include-path* tapi-common:uuid
| +--rw exclude-path* tapi-common:uuid
| +--rw include-link* tapi-common:uuid
| +--rw exclude-link* tapi-common:uuid
| +--rw include-node* tapi-common:uuid
| +--rw exclude-node*
tapi-common:uuidcontext/topology/node/uuid

7 Use cases Low Level designs (LLDs)

First we include the checklist of use cases in the scope of optical transport management with the
roadmap for its definition. This version of the document closes the definition of the PACK_1 of use cases
based on this NBI specification.
Table 6: UCs summary.
SDNC_
Use Cases Definition
PACK
Discovery use cases:
Use case 0a: Context & Service Interface Points discovery (synchronous mode) 1 July’19
Use case 0b: Topology discovery (synchronous mode) 1 July’19
Provisioning use cases:
Use case 1a: Unconstrained DSR Service Provisioning single wavelength (<100G). 1 July’19
Use case 1b: Unconstrained DSR Service Provisioning multi wavelength (beyond 100G). 1 July’19
Use case 1c: Unconstrained ODU Service Provisioning
Use case 1d: Unconstrained PHOTONIC_MEDIA/OTSi Service Provisioning 1 July’19
Use case 1e: Unconstrained PHOTONIC_MEDIA/OTSiA Service Provisioning 1 July’19
Use case 1f: Unconstrained PHOTONIC_MEDIA/NMC Service Provisioning
Use case 2a: Unconstrained service provisioning with OCh/OTSi(channel selection)
Use case 2b: Unconstrained service provisioning with ODU selection
Use case 2c: Unconstrained service provisioning with NMC (channel selection)
Use case 3a: Constrained Provisioning - Include/exclude a node or group of nodes.
Use case 3b: Constrained Provisioning -Include/exclude a link or group of links.
Use case 3c: Constrained Provisioning - Include/exclude the path used by other service. 1 July’19
Inventory use cases:
Use case 4: Inventory model for NBI interface
Resilience use cases:
Use case 5a: 1+1 OLP Client Protection with Diverse Service Provisioning
Use case 5b: 1+1 OLP Line Protection with Diverse Service Provisioning 1 July’19
Use case 5c: 1+1 Protection with Diverse Service Provisioning (eSNCP) 1 July’19
Use case 6a: Dynamic restoration policy for unconstrained and constrained connectivity
1 July’19
services.
Use case 6b: Pre-Computed restoration policy for unconstrained and constrained connectivity
services.
Use case 7a: Dynamic restoration and 1+1 protection of DSR/ODU unconstrained service
1 July’19
provisioning.
Use case 7b: Pre-Computed restoration policy and 1+1 protection of DSR/ODU unconstrained
service provisioning.
Use case 8: Permanent protection 1+1 for use cases
Use case 9: Reverted protection for use cases
Service maintenance use cases:
Use case 10: Service deletion (applicable to all previous use cases) 1 July’19
Use case 11a: Modification of service path
Use case 11b: Modification of service nominal path to secondary (protection) path for
maintenance operations.

Use case 11c Modification or upgrade of service capacity. (Only valid for electrical services)
Planning use cases:
Use case 12a: Pre-calculation of the optimum path (applicable to all previous use cases)
Use case 12b: Simultaneous pre-calculation of two disjoint paths.
Use case 12c: Multiple simultaneous path computation (Bulk request processing)
Use case 12d: Physical impairment validation of an pre-calculated OCh/OTSi trail path.
Alarms and Notification use cases:
Use case 13a: Subscription to notification stream service.
Use case 14a: Notification of new topology element (topology, link, node, node-edge-point)
inserted/removed in/from the network
Use case 14b: Notification of status change on existing topology element (topology, link, node,
node-edge-point) in the network.
Use case 15a: Notification of new connectivity-service element inserted/removed in/from the
network.
Use case 15b: Notification of status change on existing connectivity-service element in the
network.
Use case 16a: Notification of status change on the routing conditions of an existing connection
element in the network.
Use case 16b: Notification of status change on the switching conditions of an existing
connection element in the network.
7.1 Use case 0: Topology and services discovery

This use case consists on retrieving all information available from TAPI servers (SDN-C)
including topology, service-interface-points, connectivity-services and connections.
This use case is intended to be performed by any NBI client controller, module or application
which intends to discover the logical representation of the network done by the SDNC.
There are two modes of operations foreseen for this use case:
 Synchronous mode, based on periodic pooling retrieval operations and after each service
creation to reconcile the actual state of the network.
 Asynchronous mode, based on an initial proactive synchronization done from the NBI
client module and a connection oriented notification subscription session based on the
NBI Notification mechanism described in section and 4.4.
In this first phase of the specification the synchronous mechanism is foreseen to be fully
supported by any provider SDNC compliant with this specification.
For simplicity this use case is divided in three sub-use cases:
 Use Case 0a: Context & Service Interface Points discovery
 Use Case 0b: Topology discovery
7.1.1 Use Case 0a: Context & Service Interface Points discovery (synchronous mode)
Number UC0a
Name Context & Service Interface Points discovery (synchronous mode)

Technologies Optical

involved
Process/Areas Planning and Operations
Involved
Brief description The TAPI Context and Service Interface Points are the relevant network service information
required previous to any connectivity-service creation operation.
The discovery of this information is intended to be requested periodically and/or on-demand
basis, proactively from the TAPI client role, in order to synchronize the context information.
Layers involved DSR/ODU/PHOTONIC_MEDIA
Type Discovery
Description & The first use case consists on retrieving context and service-interface-point information (Figure
Workflow 7 -10). If the first operation (1) is correctly supported by the NBI server, it MUST retrieve the
context filtered subtree up to three levels down into the hierarchy (2). The response operation
MUST contain the attributes included in Table 7 which are marked as Mandatory (M) in the
Support (Sup) column.
The second operation (3) retrieves the list of service-interface-point (SIP) “uuid” (4), to
recursively retrieve the full content of each SIP object in operation (5) which employs the
“fields” query parameter to obtain only the desired filtered information. The response operation
(6) MUST contain the attributes included in Table 8 which are marked as Mandatory (M) in the
Support (Sup) column.
Figure 7-10 UC-0a: Service Interface Point - LLD Workflow.
7.1.1.1 Required parameters

Following we include the required parameters for each object which is retrieved in the previously
described RESTCONF operations.

Table 7: Context object definition
Context
Attribute Allowed Values/Format Mod Sup Notes

uuid "[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a- RO M  As per RFC 4122
fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]  Provided by tapi-server
{12}"
name List of {value-name, value} RO M  Provided by tapi-server
 CONTEXT_NAME is a
 "value-name": "CONTEXT_NAME" user legible unstructured
"value": " [0-9a-zA-Z_]{64} string tag to uniquely
 "value-name": "VENDOR_NAME" identify the tapi-server
"value": "[0-9a-zA-Z_]{64}" context.
 VENDOR_NAME is a
user legible unstructured
string tag to uniquely
identify the tapi-server
owner or supplier.
service-interface- List of {service-interface-point} RO M  Provided by tapi-server
point  Direct modification
disallowed
nw-topology- {network-topology-service} RO M  Provided by tapi-server
service
topology List of {topology} RO M  Provided by tapi-server
connectivity- List of {connectivity-service} RW M  Provided by tapi-client
service  Direct modification
disallowed
connection List of {connection} RO M  Provided by tapi-server
Table 8: Service Interface Point (SIP) object definition
Service-interface-point

uuid "[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a- RW M  As per RFC 4122
{12}"
name List of {value-name, value} RW M  Initial value provided by
tapi-server
 "value-name": "INVENTORY_ID",  INVENTORY_ID format
"value": " [0-9a-zA-Z_]{64}" is described in section 5.2
 Subsequent updates
provided by tapi-client
layer-protocol- ["DSR", "ETH", "ODU", RO M
name “PHOTONIC_MEDIA”]
supported-layer- List of ["DIGITAL_SIGNAL_TYPE", RO M  Provided by tapi-server
protocol-qualifier "ODU_TYPE",  All children identities

"PHOTONIC_LAYER_QUALIFIER”] defined for

["DIGITAL_SIGNAL_TY
PE", "ODU_TYPE",
"PHOTONIC_LAYER_Q
UALIFIER”] MUST be
supported.
administrative- ["UNLOCKED", "LOCKED"] RW M  Initial value provided by
state tapi-server
 Subsequent updates
provided by tapi-client
operational-state ["ENABLED", "DISABLED"] RO M  Provided by tapi-server
lifecycle-state ["PLANNED", RO M  Provided by tapi-server
"POTENTIAL_AVAILABLE",
"POTENTIAL_BUSY",
"INSTALLED",
"PENDING_REMOVAL"]
total-potential- “total-size”: {value, unit} RO M  Provided by tapi-server
capacity
 "value": "[0-9]{8}",
 "unit": ["TB", "TBPS", "GB",
"GBPS", "MB", "MBPS", "KB",
"KBPS"]
available- “total-size”: {value, unit} RO M  Provided by tapi-server
capacity
 "value": "[0-9]{8}",
"KBPS"]
tapi-photonic- “otsi-capability”:{ supportable-central- RO M  Provided by tapi-server
media:otsi- frequency-spectrum-band, supportable-  This block of attributes
service-interface- application-identifier, supportable- MUST augment SIPs
point-spec modulation, total-power-warn- attached to
threshold} PHOTONIC_MEDIA
NEPs exposing
 List of “supportable-central- OTSI/OTSiA service
frequency-spectrum-band”:{ central- provisioning capabilities.
frequency, frequency-constraint:  The central-frequency of
{adjustment-granularity, grid-type} } the laser specified in MHz.
o “central-frequency”: " It is the oscillation
[0-9]{9}", frequency of the
o “adjustment-granularity”: corresponding
[ “UNCONSTRAINED”, electromagnetic wave.
“G_3_125GHZ”, “G_6_25GHZ”,  Adjustment-granularity
“G_12_5GHZ”, “G_25GHZ”, in Gigahertz. As per ITU-
“G_50GHZ”, “G_100GHZ”,] T G.694.1, it is used to
o “grid-type”: calculate nominal central
[ “GRIDLESS”, “FLEX”, frequency".
“CWDM”, “DWDM”]  The grid-type specifies
 List of “supportable-application- the reference set of
identifier”:{ application-identifier- frequencies used to denote
type, application-code} allowed nominal central
o “application-identifier-type”: frequencies that may be
[ “PROPRIETARY”, used for defining
“ITUT_G959_1”, applications.

“ITUT_G698_1”,
“ITUT_G698_2”,
“ITUT_G696_1”,
“ITUT_G695”,]
o “application-code”: " [0-
9a-zA-Z_]{64}"
 List of “supportable-modulation”:
[ “RZ“, “NRZ”, “BPSK”, “DPSK”,
“QPSK”, “8QAM”, “16QAM”]
 “total-power-warn-threshold”: {total-
power-lower-warn-threshold-
default /min/max, total-power-upper-
warn-threshold-default /min/max”}
o “total-power-*-warn-threshold”:
"[0-9].[0-9]{7}",
tapi-photonic- “mc-pool”: RO M  Provided by tapi-server
media: media- {supportable/available/occupied-  This block of attributes
channel-service- spectrum} MUST augment SIPs
interface-point- attached to
spec  List of PHOTONIC_MEDIA
“supportable/available/occupied- NEPs exposing
spectrum”:{upper/lower- Media_Channel service
frequency, frequency-constraint: provisioning capabilities.
{adjustment-granularity, grid-type}  The upper/lower-
} frequency bound of the
o “upper/lower-frequency”: " media channel spectrum
[0-9]{9}", specified in MHz..
o “adjustment-granularity”:  Adjustment-granularity
[ “UNCONSTRAINED”, in Gigahertz. As per ITU-
“G_3_125GHZ”, “G_6_25GHZ”, T G.694.1, it is used to
“G_12_5GHZ”, “G_25GHZ”, calculate nominal central
“G_50GHZ”, “G_100GHZ”,] frequency".
o “grid-type”:  The grid-type specifies
[ “GRIDLESS”, “FLEX”, the reference set of
“CWDM”, “DWDM”] frequencies used to denote
allowed nominal central
frequencies that may be
used for defining
applications.
7.1.2 Use Case 0b: Topology discovery (synchronous mode)

Number UC0b
Name Topology discovery (synchronous mode)

involved
Process/ Planning and Operations
Areas
Involved
Brief The TAPI Topology is the relevant network logical representation information required for

description inventory, traffic-engineering or provisioning purposes.

The discovery of this information is intended to be requested periodically and/or on-demand basis,
proactively from the TAPI client role, in order to synchronize the context information.
Layers DSR/ODU/PHOTONIC_MEDIA
involved
Type Discovery
Description The topology discover use case consists on the workflow and operations depicted in Figure 7 -11.
& Workflow The first operation (1) retrieves the list of Topology references (UUID) included in the tapi-
topology:topology-context/nw-topology-service/ (2). For each Topology reference found,
operation (3) is repeated to obtain a Topology object instance filtered subtree up to three levels (4).
The details of the Topology object mandatory attributes is included in Table 9. The response
operation MUST contain the attributes included in Table 9 which are marked as Mandatory (M) in
the Support (Sup) column.
For each node found in operation (4), operation (5) is repeated to retrieve each tapi-topology:node
object (6) which MUST contain the attributes included in Table 10 which are marked as
Mandatory (M) in the Support (Sup) column. Recursively, for each node object a filtered operation
(7) is used to retrieve each owned-node-edge-point/uuid reference.
For each owned-node-edge-point reference discovered in operation (7), operation (9) is performed
to retrieve each owned-node-edge-point object (10) for each node. Each ONEP object MUST
contain the attributes included in Table 11 which are marked as Mandatory (M) in the Support
(Sup) column.
For each topology found in operation (4), operation (11) is repeated to retrieve each tapi-
topology:link object (12) which MUST contain the attributes included in Table 14 which are
marked as Mandatory (M) in the Support (Sup) column.

Figure 7-11 UC-0b: Topology discovery - LLD Workflow.

Following we include the required parameters for each object which is retrieved in the previously
described RESTCONF operations.

Table 9: Topology object definition
Topology

{12}"
name List of {value-name: value} RO M  Provided by tapi-server
 TOPOLOGY_NAME is a user
 "value-name": "TOPOLOGY_NAME" legible unstructured string tag
"value": " [0-9a-zA-Z_]{64}" to uniquely identify the tapi-
server topology.

layer-protocol- List of ["DSR", "ODU", RO M  Support OCH/OTSi?
name "PHOTONIC_MEDIA"]
link List of {link} RO M  Provided by tapi-server
node List of {node} RO M  Provided by tapi-server
Table 10: Node object definition
Node

{12}"
 NW-NE-NAME format is
 "value-name": "NW-NE-NAME" described in section 5.2
"value": " [0-9a-zA-Z_]{64}"
layer-protocol- List of ["DSR", "ODU", RO M  Support OCH/OTSi?
administrative- ["UNLOCKED", "LOCKED"] RO M  Provided by tapi-server

state
"POTENTIAL_BUSY", "INSTALLED",
"PENDING_REMOVAL"]
total-potential- “total-size”: {value: unit} RO O  Provided by tapi-server
capacity
 "value": "[0-9]{8}",
 "unit": ["TB", "TBPS", "GB", "GBPS",
"MB", "MBPS", "KB", "KBPS"]
available- “total-size”: {value: unit} RO O  Provided by tapi-server

capacity
 "value": "[0-9]{8}",
cost- List of {cost-name: cost-value} RO O  Support other cost metrics?
characteristic
 "cost-name": "HOP_COUNT"
"cost-value": "[0-9]{8}"
latency- List of { traffic-property-name: fixed- RO O  Support other latency
characteristic latency-characteristic } properties?
 "traffic-property-name":
"FIXED_LATENCY"
"fixed-latency-characteristic": "[0-9]
{8}"
encapsulated- {"topology-ref"} RO M  Provided by tapi-server
topology  Needed if encapsulated-
topology is supported
aggregated-node- List of {"node-edge-point-ref"} RO M  Provided by tapi-server
edge-point  Needed if encapsulated-
topology is supported
owned-node- List of {node-edge-point} RO M  Provided by tapi-server
edge-point
node-rule-group List of {node-rule-group} RO M  Provided by tapi-server
Table 11: Node-edge-point object definition
node-edge-point

{12}"
 INVENTORY_ID format is
 "value-name": "INVENTORY_ID", described in section 5.2
"value": " [0-9a-zA-Z_]{64}"
layer-protocol- List of ["DSR", "ODU", RO M  Provided by tapi-server

protocol-qualifier "ODU_TYPE",  All children identities defined
"PHOTONIC_LAYER_QUALIFIER”] for
["DIGITAL_SIGNAL_TYPE"
, "ODU_TYPE",
"PHOTONIC_LAYER_QUA
LIFIER”] MUST be

supported.

state
"PENDING_REMOVAL"]
termination-state ["LP_CAN_NEVER_TERMINATE", RO O  Provided by tapi-server
“LT_NOT_TERMINATED”,
“TERMINATED_SERVER_TO_CLIEN
T_FLOW”,
“TERMINATED_CLIENT_TO_SERVE
R_FLOW”,
“TERMINATED_BIDIRECTIONAL”,
“LT_PERMENANTLY_TERMINATED
”,
“TERMINATION_STATE_UNKNOWN
”]
termination- ["BIDIRECTIONAL", “SINK”, RO M  Provided by tapi-server
direction “SOURCE”]
link-port- ["BIDIRECTIONAL","INPUT","OUTP RO M  Provided by tapi-server
direction UT"]  Support
UNIDIRECTIONAL?
link-port-role ["SYMMETRIC"] RO M  Provided by tapi-server
total-potential- “total-size”: {value: unit} RO M  Provided by tapi-server
capacity
 "value": "[0-9]{8}",
available- “total-size”: {value: unit} RO M  Provided by tapi-server
capacity
 "value": "[0-9]{8}",
aggregated-node- List of {node-edge-point-ref} RO M  Provided by tapi-server
edge-point
mapped-service- List of {"/tapi-common:context/service- RO M  Provided by tapi-server

interface-point interface-point/uuid”}
cep-list List of {connection-end-point} RO M  Provided by tapi-server
tapi-photonic- “mc-pool”: RO M  Provided by tapi-server
media: media- {supportable/available/occupied-  This block of attributes
channel-service- spectrum} MUST augment SIPs
interface-point- attached to
spec  List of PHOTONIC_MEDIA
“supportable/available/occupied- NEPs exposing
spectrum”:{upper/lower-frequency, Media_Channel service
frequency-constraint: {adjustment- provisioning capabilities.
granularity, grid-type} }

o “upper/lower-frequency”: "  The upper/lower-

[0-9]{9}", frequency bound of the
o “adjustment-granularity”: media channel spectrum
[ “UNCONSTRAINED”, specified in MHz..
“G_3_125GHZ”, “G_6_25GHZ”,  Adjustment-
“G_12_5GHZ”, “G_25GHZ”, granularity in
“G_50GHZ”, “G_100GHZ”,] Gigahertz. As per ITU-T
o “grid-type”: [ “GRIDLESS”, G.694.1, it is used to
“FLEX”, “CWDM”, “DWDM”] calculate nominal central
frequency".
 The grid-type specifies
the reference set of
frequencies used to
denote allowed nominal
central frequencies that
may be used for defining
applications.
Table 12: Node-rule-group object definition
node-rule-group

{12}"
 "value-name": "NRG_NAME"
"value": " [0-9a-zA-Z_]{64}"
node-edge-point List of {node-edge-point-ref} RO M  Provided by tapi-server
rule List of {rule} RO M  Provided by tapi-server
Table 13: Rule object definition
rule

local-id "[0-9a-zA-Z_]{32}" RO M  Provided by tapi-server
 "value-name": "RULE_NAME"
"value": " [0-9a-zA-Z_]{64}"
rule-type ["FORWARDING"] RO M  Provided by tapi-server
 Support other rule types?
forwarding-rule ["MAY_FORWARD_ACROSS_GROU RO M  Provided by tapi-server
P",

"MUST_FORWARD_ACROSS_GROU
P",
"CANNOT_FORWARD_ACROSS_GR
OUP",
"NO_STATEMENT_ON_FORWARDI
NG"]
Table 14: Link object definition
link

{12}"
 "value-name": "LINK_NAME"
"value": " [0-9a-zA-Z_]{64}"
layer-protocol- List of ["DSR", "ODU", RO M
state
"PENDING_REMOVAL"]
direction ["BIDIRECTIONAL"] RO M  Provided by tapi- server
total-potential- “total-size”: {value: unit} RO M  Provided by tapi-server

capacity
 "value": "[0-9]{8}",
available- “total-size”: {value: unit} RO M  Provided by tapi-server
capacity
 "value": "[0-9]{8}",
transitioned- List of {layer-protocol-name} RO M  Only applicable to
layer-protocol- transitional-links.
name  Pending model extension.
cost- List of {cost-name: cost-value} RO O  Support other cost metrics?

characteristic
 "cost-name": "HOP_COUNT"

"cost-value": "[0-9]{8}"
latency- List of { traffic-property-name: fixed- RO O  Support other latency
characteristic latency-characteristic } properties?
 "traffic-property-name":
"FIXED_LATENCY"
"fixed-latency-characteristic": "[0-9]
{8}"
Risk- List of {risk-characteristic-name: risk- RO O
characteristic identifier-list}
 "risk-characteristic-name": ["SRLG",
"SRNG"]
"risk-identifier-list": List of "[0-9a-zA-
Z_]{64}"
node-edge-point List of {"node-edge-point-ref”} RO M  Provided by tapi-server
7.2 Use case 1: Unconstrained E2E Service Provisioning

Please note that this use case can divided in five sub use cases depending on the layer on which it is applied:
 UC1a: Unconstrained DSR Service Provisioning single wavelength (<100G).
 UC1b: Unconstrained DSR Service Provisioning multi wavelength (beyond 100G).
 UC1c: Unconstrained ODU Service Provisioning
 UC1d: Unconstrained PHOTONIC_MEDIA/OTSi Service Provisioning
 UC1e: Unconstrained PHOTONIC_MEDIA/OTSiA Service Provisioning
 UC1f: Unconstrained PHOTONIC_MEDIA/NMC Service Provisioning
In this specification we only consider the mandatory the implementation of the UC1a, UC1c and UC1d, the rest
are left for the next release of this document,
The workflow definition and required parameters described in these sections applies to all the different sub-use
cases but the results in terms of the number of connections generated are different depending on the layer to which
the unconstrained connectivity-service has been requested.
The main different between the different sub-use cases described here, is the selection of the Connectivity-Service-
End-Points, i.e., the layer to which their associated SIPs. Depending on this selection the connections generated in
the network are up to a networking layer or another. E.g., for the provisioning of a PHOTONIC_MEDIA/OTSi
Connectivity-Service, the TAPI Server will only generates connection up to the PHOTONIC_MEDIA/OTSi
network layer.
7.2.1 Use case 1a: Unconstrained DSR Service Provisioning single wavelength (<100G).
Number UC1a
Name Unconstrained DSR Service Provisioning single wavelength (<100G).

involved
Involved
Brief description The UC1 describes the provisioning of a tapi-connectivity:connectivity-service instance

between service-interface-points exposed by the TAPI-Server at the DSR networking layer.

This service can include intermediate regeneration if necessary.
The underlying connection provisioning and management (including lower layer connections
e.g., ODU, OTSi, NMC including intermediate regeneration connections if needed) is
performed by the SDN Domain controller.
The path of each lower layer connection (e.g., ODU or OCh/OTSi, OMS) across the network
topology is calculated by the controller and the connection automatically provisioned.
The “unconstrained” term refers that the TAPI-Client is not allowed to introduce any routing
constraint in the service request, thus relays completely into the routing capabilities of the
TAPI-Server to select the network resources employed to provide the desired service
characteristics.
Moreover, the TAPI-Client is not providing technology specific Traffic-Engineering
constrains such time-slot selection at the ODU layer, or optical-spectrum selection for the
routing of OTSi connections.
Type Provisioning
Description & The Use Case 1: Connectivity Service provisioning consists on the creation of a connectivity-
Workflow service between Service-Interface-Points at the DSR/ODU/PHOTONIC_MEDIA layers and
the retrieval of the generated connections information. The complete workflow is shown in
Figure 7 -12.
The first operation (1) triggers the creation of Connectivity-Service in the NBI Server. The
TAPI server MUST accept any valid combination of the attributes marked as Mandatory (M)
in the Support (Sup) column of Table 15 and Table 16. If the operation is successful, the NBI
server MUST return an http response message with the Location Header as specified in
https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5.
Once the resource has been created, the NBI Client may retrieve all information of the
Connectivity-Service (3), Connection list of references (5) and all its Connection objects (7).
The NBI server MUST return a valid object, if previous operations (4)(6)(8) succeed, which
are compliant with the definition of the objects included in Table 15 (Connectivity-Service)
and Table 17 (Connection). Please note the Connection object MUST include all attributes
marked as Mandatory (M) in the Support (Sup) in all Connection sub-objects defined in Table
18, Table 19, Table 20, Table 21, Table 22 and Table 23

Figure 7-12 UC-1: Unconstrained end-to-end service provisioning.
Table 15: Connectivity-service object definition
connectivity-service

uuid "[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a- RW M  As per RFC 4122
fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]  Provided by tapi-client
{12}"
name List of {value-name: value} RW M  Provided by tapi-client
 "value-name": "SERVICE_NAME"
"value": " [0-9a-zA-Z_]{64}"
administrative- ["UNLOCKED", "LOCKED"] RW O  Provided by tapi-client
state
"POTENTIAL_BUSY",
"INSTALLED",
"PENDING_REMOVAL"]
requested- “total-size”: {value: ,unit:} RW M  Provided by tapi-client
capacity

 "value": "[0-9]{8}",
"KBPS"]
service-type ["POINT_TO_POINT_CONNECTIVI RW O  Provided by tapi-client
TY"]  Support P2P only
service-layer List of ["DSR", "ODU", RW M  Provided by tapi-client
"PHOTONIC_MEDIA"]
preferred- List of ["DSR", "ODU", RW O 
transport-layer "PHOTONIC_MEDIA"]
connection List of {connection-ref - /tapi- RO M  Provided by tapi-server
common:context/tapi-
connectivity:connectivity-context/conne
ction/uuid}
end-point List of {connectivity-service-end- RW M  Provided by tapi-client
point}  Min elements 2.
Table 16: Connectivity-service-end-point object definition
connectivity-service-end-point

local-id "[0-9a-zA-Z_]{32}" RW M  Provided by tapi-client
layer-protocol- List of ["DSR", "ODU", RW M  Provided by tapi-client
name "PHOTONIC_MEDIA"] 
supported-layer- List of ["DIGITAL_SIGNAL_TYPE", RW M  Provided by tapi-server
protocol-qualifier "ODU_TYPE",  All children identities defined
["DIGITAL_SIGNAL_TYPE",
"ODU_TYPE",
"PHOTONIC_LAYER_QUALI
FIER”] MUST be supported.
administrative- ["UNLOCKED", "LOCKED"] RW O  Provided by tapi-client
state
operational-state ["ENABLED", "DISABLED"] RO O  Provided by tapi-server
lifecycle-state ["PLANNED", RO O  Provided by tapi-server
"POTENTIAL_BUSY",
"INSTALLED",
"PENDING_REMOVAL"]
direction ["BIDIRECTIONAL", “INPUT”, RW O  Provided by tapi-client
“OUTPUT”]
role ["SYMMETRIC", "TRUNK"] RW O  Provided by tapi-client

 Support only P2P
capacity “total-size”: {value: unit} RW O  Provided by tapi-client
 "value": "[0-9]{8}",


"KBPS"]
service-interface- "/tapi-common:context/service- RW M  Provided by tapi-client
point interface-point/uuid”
connection-end- List { connection-end-point} RO M  Provided by tapi-server
point
Table 17: Connection object definition
connection

{12}"
name List of {value-name, value} RO M  Provided by tapi-server
 "value-name":
"CONNECTION_NAME"
"value": " [0-9a-zA-Z_]{64}"
layer-protocol- List of ["DSR", "ODU", RO M  Provided by tapi-client

"POTENTIAL_BUSY",
"INSTALLED",
"PENDING_REMOVAL"]
direction ["BIDIRECTIONAL"] RO M  Provided by tapi- server
 Support UNIDIRECTIONAL?
lower-connection List of {connectivity-ref - /tapi- RO M  Provided by tapi-server
common:context/tapi-
ction/uuid}
connection-end- List of {"connection-end-point-ref - RO M  Provided by tapi-server
point /tapi-common:context/tapi-
topology:topology-context/topology/no
de/owned-node-edge-point/tapi-
connectivity:cep-list/connection-end-
point/uuid "}
route List of { route } RO M  Provided by tapi-server
switch-control List of { switch-control } RO M  Provided by tapi-server

Table 18: Connection-end-point object definition
connection-end-point

{12}"
 "value-name": "CEP_NAME"
"value": " [0-9a-zA-Z_]{64}"
layer-protocol- List of ["DSR", "ODU", RO M Provided by tapi-server
protocol-qualifier "ODU_TYPE", All children identities defined
["DIGITAL_SIGNAL_TYPE",
"ODU_TYPE",
"PHOTONIC_LAYER_QUALI
FIER”] MUST be supported.
state
"POTENTIAL_BUSY",
"INSTALLED",
"PENDING_REMOVAL"]
termination-state ["LP_CAN_NEVER_TERMINATE", RO M  Provided by tapi-server
“LT_NOT_TERMINATED”,
“TERMINATED_SERVER_TO_CLIE
NT_FLOW”,
“TERMINATED_CLIENT_TO_SERV
ER_FLOW”,
“TERMINATED_BIDIRECTIONAL”,
“LT_PERMENANTLY_TERMINATE
D”,
“TERMINATION_STATE_UNKNOW
N”]
termination- ["BIDIRECTIONAL", “SINK”, RO M  Provided by tapi-server
direction “SOURCE”]  Support SOURCE/SINK?
connection-port- ["BIDIRECTIONAL","INPUT","OUT RO M  Provided by tapi-server
direction PUT"]  Support UNIDIRECTIONAL?
connection-port- ["SYMMETRIC"] RO M  Provided by tapi-server
role
aggregated- List of {node-edge-point-ref} RO O  Provided by tapi-server
connection-end-

point
parent-node- List of {node-edge-point-ref} RO M  Provided by tapi-server
edge-point
client-node-edge- List of {node-edge-point-ref} RO M  Provided by tapi-server
point
tapi-odu:odu- {odu-connection-end-point-spec} RO M  Provided by tapi-server
connection-end-
point-spec
tapi-photonic- { otsi-connection-end-point-spec } RO M  Provided by tapi-server
media:otsi-  MUST augment CEPs at the
connection-end- PHOTONIC_MEDIA layer
point-spec with OTSI layer-protocol-
qualifier.
tapi-photonic- {otsi-assembly-connection-end-point- RO M  Provided by tapi-server
media:otsi- spec }  MUST augment CEPs at the
assembly- PHOTONIC_MEDIA layer
connection-end- with OTSIA layer-protocol-
point-spec qualifier.
tapi-photonic- {media-channel-connection-end- RO M  Provided by tapi-server
media:media- point-spec}  MUST augment CEPs at the
channel- PHOTONIC_MEDIA layer
connection-end- with NMC/NMCA layer-
point-spec protocol-qualifier.
Table 19: ODU-Connection-end-point-spec object definition
odu-connection-end-point-spec

odu-common { odu-type, odu-rate, odu-rate-tolerance RO M  Provided by tapi-server
}  All children identities defined
for ["ODU_TYPE"] MUST be
 “odu-type”: [ ODU_TYPE], supported.
 “odu-rate”: [0-9]{12},  odu-rate-tolerance
 “odu-rate-tolerance”: [0-9]{12}, Standardized values are defined
in Table 7-2/G.709
odu-term-and- { odu-slot-size, auto-payload-type, RO M  Provided by tapi-server
adapter configured-client-type, configured-
mapping-type, accepted-payload-type,
named-payload-type, hex-payload-
type}
 odu-slot-size
 auto-payload-type? boolean
 configured-client-type: tapi-
dsr:digital-signal-type
 configured-mapping-type?
mapping-type
 accepted-payload-type

 named-payload-type? odu-named-
payload-type
 hex-payload-type? uint64
odu-ctp {total-power, power-spectral-density} RO M  Provided by tapi-server
 tributary-slot-list* uint64
 tributary-port-number? uint64
 accepted-msi? string
Table 20: OTSI-Connection-end-point-spec object definition
otsi-connection-end-point-spec

otsi-termination {selected-central-frequency, selected- RO M  Provided by tapi-server
application-identifier, selected-
modulation, selected-spectrum,
transmitted-power, received-power,
laser-properties}
selected-central- { central-frequency, frequency- RO M  Provided by tapi-server
frequency constraint: {adjustment-granularity,  The central-frequency of the
grid-type} } laser specified in MHz. It is the
oscillation frequency of the
 “central-frequency”: "[0-9]{9}", corresponding electromagnetic
 “adjustment-granularity”: wave.
[ “UNCONSTRAINED”,  Adjustment-granularity in
“G_3_125GHZ”, “G_6_25GHZ”, Gigahertz. As per ITU-T
“G_12_5GHZ”, “G_25GHZ”, G.694.1, it is used to calculate
“G_50GHZ”, “G_100GHZ”,] nominal central frequency".
 “grid-type”: [ “GRIDLESS”,  The grid-type specifies the
“FLEX”, “CWDM”, “DWDM”] reference set of frequencies
used to denote allowed nominal
central frequencies that may be
used for defining applications.
selected- { application-identifier-type, RO M  Provided by tapi-server
application- application-code}
identifier
 “application-identifier-type”:
[ “PROPRIETARY”,
“ITUT_G959_1”, “ITUT_G698_1”,
“ITUT_G698_2”, “ITUT_G696_1”,
“ITUT_G695”,]
 “application-code”:”[0-9a-zA-Z_]
{64}"
selected - [“RZ“, “NRZ”, “BPSK”, “DPSK”, RO M  Provided by tapi-server
modulation “QPSK”, “8QAM”, “16QAM”]
selected- { lower-frequency, upper-frequency, RO M  Provided by tapi-server

spectrum frequency-constraint: {adjustment-  The central-frequency of the
granularity, grid-type} } laser specified in MHz. It is the

 “upper/lower-frequency”: corresponding electromagnetic

"[0-9]{9}", wave.
 “adjustment-granularity”:  Adjustment-granularity in
[ “UNCONSTRAINED”, Gigahertz. As per ITU-T
“G_3_125GHZ”, “G_6_25GHZ”, G.694.1, it is used to calculate
“G_12_5GHZ”, “G_25GHZ”, nominal central frequency".
“G_50GHZ”, “G_100GHZ”,]  The grid-type specifies the
 “grid-type”: [ “GRIDLESS”, reference set of frequencies
“FLEX”, “CWDM”, “DWDM”] used to denote allowed nominal
transmited-power {total-power, power-spectral-density} RO M  Provided by tapi-server
 “total-power”:"[0-9].[0-9]{7}",
 “power-spectral-density”:
"[0-9].[0-9]{7}",
received-power {total-power, power-spectral-density} RO M  Provided by tapi-server

 “total-power”:"[0-9].[0-9]{7}",
"[0-9].[0-9]{7}",
laser-properties {laser-status, laser-application-type, RO M  Provided by tapi-server
laser-bias-current, laser-temperature}
 “laser-status”:
[“ON”,”OFF”,”PULSING”,
“UNDEFINED”]
 “laser-application-type”:
[“PUMP”, “MODULATED”,
“PULSE”]
 “laser-bias-current”: "[0-9].
[0-9]{7}",
 “laser-temperature”: "[0-9].
[0-9]{7}",

Table 21: OTSI-Assembly-connection-end-point-spec object definition
otsi-assembly-connection-end-point-spec

otsi-adapter “number-of-otsi”: [0-9]{9} RO O  Provided by tapi-server
fec-parameters { pre-fec-ber, post-fec-ber, corrected- RO M  Provided by tapi-server

bytes, corrected-bits, uncorrectable-
bytes, uncorrectable-bits}: ”:
"[0-9].[0-9]{64}",

Table 22 media-channel-connection-end-point-spec object definition
media-channel-connection-end-point-spec

occupied- { lower-frequency, upper-frequency, RO M  Provided by tapi-server
spectrum frequency-constraint: {adjustment-  The central-frequency of the
granularity, grid-type} } laser specified in MHz. It is the
 “upper/lower-frequency”: corresponding electromagnetic
"[0-9]{9}", wave.
 “adjustment-granularity”:  Adjustment-granularity in
[ “UNCONSTRAINED”, Gigahertz. As per ITU-T
“G_3_125GHZ”, “G_6_25GHZ”, G.694.1, it is used to calculate
“G_12_5GHZ”, “G_25GHZ”, nominal central frequency".
“G_50GHZ”, “G_100GHZ”,]  The grid-type specifies the
 “grid-type”: [ “GRIDLESS”, reference set of frequencies
“FLEX”, “CWDM”, “DWDM”] used to denote allowed nominal
measured-power- {total-power, power-spectral-density} RO M  Provided by tapi-server
ingress
 “total-power”:"[0-9].[0-9]{7}",
"[0-9].[0-9]{7}",
measured-power- {total-power, power-spectral-density} RO M  Provided by tapi-server
ingress
 “total-power”:"[0-9].[0-9]{7}",
"[0-9].[0-9]{7}",
Table 23: Route object definition
route

 "value-name": "ROUTE_NAME"
"value": " [0-9a-zA-Z_]{64}"
connection-end- List of {"connection-end-point-ref - RO M  Provided by tapi-server
point /tapi-common:context/tapi-
topology:topology-context/topology/n
ode/owned-node-edge-point/tapi-
point/uuid "}


7.2.1.2 Expected results

In the following subsections we include detail examples of the expected results after the
successful provisioning of connectivity-services. Please note that all examples follow the rules
detailed in section 6.1.1
In order to show some detailed TAPI connectivity examples, first a simple legend of icons and
basic arrangement is included in Error: Reference source not found.
Figure 7-13 TAPI Logical Termination Point Template – Basic Arrangements.
7.2.1.2.1 UC1a - Example 1: 10GE client signal over ODU2 over ODU4 (DSR-ODU
Fixed Mapping, flexible ODU allocation)

(ODU4 Top Connection creation)
(ODU2 over ODU4 Top Connection cross-connection)

(ODU4 over OTSi).
(ODU 4 over OTSi over NMC).
7.2.1.2.2 UC1a - Example 2: 1GE client signal over ODU0 over ODU2 over ODU4
(Fixed DSR-ODU mapping, flexible ODU allocation)
For simplification OTSi and Photonic Media layers have been omitted from this example, as it is
the exact same case depicted in the previous example.

Figure 7-19 Connectivity Service 1GE client signal over ODU0 over ODU2 over ODU4 (Fixed DSR-
ODU mapping, flexible ODU allocation)
7.2.1.2.3 UC1a - Example 3: 1GE client signal over ODU0 over ODU2 over ODU4
(Fixed DSR-ODU mapping, flexible ODU allocation) with intermediate ODU0
switching.
Figure 7-20 Connectivity Service 1GE client signal over ODU0 over ODU2 over ODU4 (Fixed DSR-
ODU mapping, flexible ODU allocation) with intermediate ODU0 switching

7.2.1.2.4 UC1a - Example 4: 10GE client signal over ODU2 over ODU4 (Fixed DSR-
ODU mapping, flexible ODU allocation) with intermediate transponder
regeneration.
In this example we are taking for the first time intermediate regeneration (3R) of the optical
channel (OTSi/OTSiA) into account from the modelling perspective. Please take into account the
following considerations:
The TAPI Server MAY or MAY NOT expose SIPs for the regeneration board OTSi/OTSiA:
a) The TAPI Server does not expose SIPs for the regeneration board OTSi/OTSiA
interfaces, thus these resources are only available to be consumed by the internal control
plane for regeneration of a higher layer (ODU, DSR) client connectivity-service.
Currently we assume this approach.
b) The TAPI Server does expose SIPs for the regeneration board OTSi/OTSiA interfaces.
So, the TAPI Server exposes to the user the creation of the two OTSi/OTSiA connectivity
services segments independently, to be used by higher layer services. Moreover, these
SIPs also can be used to define a multi-hop OTSi/OTSiA connectivity-service forcing the
use of regeneration. Inthis case, the user MUST request a creation of a CS including (for
a regenerated service with a single regeneration point) four CSEPs with references to
aEND, zEND and intermediate regeneration SIPs, in the CS request.
Assuming the option a), the expected connectivity model result in terms of hierarchy of
connections within the CS’s connection list, SHALL include a single HO-ODUk supported by
N-segments of OTSi/OTSiA connections represented as ODU links between every regeneration
stage (in this example a single regeneration results into 2 OTSI/OTSIA segments).
Figure 7-21 Connectivity Service 10GE client signal over ODU2 over ODU4 (Fixed DSR-ODU
mapping, flexible ODU allocation) with intermediate transponder regeneration.
7.2.2 Use Case 1b: Unconstrained DSR Service Provisioning multi wavelength (beyond 100G).
Number UC1b
Name Unconstrained DSR Service Provisioning multi wavelength (beyond 100G).

Technologies involved Optical
Process/Areas Involved Planning and Operations

Brief description The UC1 describes the provisioning of a tapi-connectivity:connectivity-service

instance between service-interface-points exposed by the TAPI-Server at the DSR
networking layer. This service can include intermediate regeneration if
necessary.
The underlying connection provisioning and management (including lower layer
connections e.g., ODU, OTSi/OTSiA/OTSiG, NMC/NMCA including intermediate
regeneration connections if needed) is performed by the SDN Domain controller.
The path of each lower layer connection (e.g., ODU or OCh/OTSi, OMS) across
the network topology is calculated by the controller and the connection
automatically provisioned.
The “unconstrained” term refers that the TAPI-Client is not allowed to introduce
any routing constraint in the service request, thus relays completely into the routing
capabilities of the TAPI-Server to select the network resources employed to
provide the desired service characteristics.
Moreover, the TAPI-Client is not providing technology specific Traffic-
Engineering constrains such time-slot selection at the ODU layer, or optical-
spectrum selection for the routing of OTSi connections.
Type Provisioning
Description & Workflow This UC is implemented following the same workflow described in “Description &
Workflow” of UC1a described in section 7.2.1

The connection generation follows the rules detailed in section 6.1.1.In this use case it is
expected that originally, the ODU and PHOTONIC_MEDIA layers are connect through a
transitional link.
This particular case requires the generation of a OTSiA/OTSiG (depending on the monitoring
capabilities implemented by the TAPI server) Top Connection between the pair of NEPs
connecting the PHOTONIC_MEDIA side of the ODU and PHOTONIC_MEDIA transitional
links. These NEPs MUST report within the supported-layer-qualifier list the following types:
[PHOTONIC_LAYER_QUALIFIER_OTSi, PHOTONIC_LAYER_QUALIFIER_OTSiA,
PHOTONIC_LAYER_QUALIFIER_OTSiG].
Once generated the OTSiA/OTSiG Top Connection Connection-End-Points (CEPs), a client-
node-edge-point structure MUST be dynamically generated to support the generation of the N
number of OTSi Top Connections required to transport the service. N Top OTSi Connctions are
thus, generated over the same parent NEP (which only includes
PHOTONIC_LAYER_QUALIFIER_OTSi within its supported-layer-qualifier list). The rest of
the workflow is equivalent to the one described for single wavelength DSR connectivity-
services. Please see the detail graphical description in Figure 7 -22.

Figure 7-22 200GE DSR Service Provisioning over multi wavelength OTSiA (beyond 100G).
7.2.3 Use case 1c: Unconstrained ODU Service Provisioning

[TO BE DEFINED IN NEXT RELEASE]
7.2.4 Use case 1d: Unconstrained PHOTONIC_MEDIA/OTSi Service Provisioning

Number UC1d
Name Unconstrained PHOTONIC_MEDIA/OTSi Service Provisioning

instance between service-interface-points exposed by the TAPI-Server at the
PHOTONIC_MEDIA networking layer. This service can include intermediate
regeneration if necessary.
connections e.g., OTS, NMC including intermediate regeneration connections if
needed) is performed by the SDN Domain controller.
The path of each lower layer connection (e.g., OCh/OTSi, OMS) across the
network topology is calculated by the controller and the connection automatically
provisioned.
Layers involved PHOTONIC_MEDIA

Type Provisioning

This use case requires the relevant Service Interface Points (SIPs) attached to the corresponding
OTSI NEPs are available and exposed by the TAPI server.
transitional link.
Please see the detail graphical description in Figure 7 -23:
Figure 7-23 OTSi single lambda connecitiy-service.
7.2.5 Use case 1e: Unconstrained PHOTONIC_MEDIA/ OTSiA/OTSiG Service Provisioning

Number UC1d
Name Unconstrained PHOTONIC_MEDIA/OTSi Service Provisioning

instance between service-interface-points exposed by the TAPI-Server at the
PHOTONIC_MEDIA networking layer. This service can include intermediate

regeneration if necessary.
connections e.g., OTS, NMC including intermediate regeneration connections if
needed) is performed by the SDN Domain controller.
The path of each lower layer connection (e.g., OCh/OTSi, OMS) across the
network topology is calculated by the controller and the connection automatically
provisioned.
Type Provisioning

This use case requires the relevant Service Interface Points (SIPs) attached to the corresponding
OTSIA/OTSIG NEPs are available and exposed by the TAPI server.
transitional link.
This particular case requires the generation of an OTSiA/OTSiG (depending on the monitoring
capabilities implemented by the TAPI server) Top Connection between the pair of NEPs
connecting the PHOTONIC_MEDIA side of the ODU and PHOTONIC_MEDIA transitional
links. These NEPs MUST report within the supported-layer-qualifier list the following types:
[PHOTONIC_LAYER_QUALIFIER_OTSi, PHOTONIC_LAYER_QUALIFIER_OTSiA,
PHOTONIC_LAYER_QUALIFIER_OTSiG].
Once generated the OTSiA/OTSiG Top Connection Connection-End-Points (CEPs), a client-
node-edge-point structure MUST be dynamically generated to support the generation of the N
number of OTSi Top Connections required to transport the service. N Top OTSi Connctions are
thus, generated over the same parent NEP (which only includes
PHOTONIC_LAYER_QUALIFIER_OTSi within its supported-layer-qualifier list). Please see
the detail graphical description in Figure 7 -24.

Figure 7-24 OTSiA/OTSiG multi-wavelength connectivity-service.
7.3 Use case 3: Constrained Provisioning
7.3.1 Use case 3a: Include/exclude a node or group of nodes.

7.3.2 Use case 3b: Include/exclude a link or group of links.

7.3.3 Use case 3c: Include/exclude the path used by other service.
Number UC3c
Name Constrained provisioning: Include/exclude the path used by other service.

Brief description This use case consists on the requests of a connectivity service between two
Connectivity Service End Points associated to Service Interface points at different
layers (DSR, ODU or OTSi). This service is subject to the inclusion/exclusion of
the path associated to one or more already provisioned services. This service can
include intermediate regeneration if necessary.
The underlying connection generation (including lower layer connections e.g.,
OCh/OTSi, Photonic Media and regeneration nodes) is made by the SDN Domain
controller.
The route of each lower layer connection (e.g., OCh/OTSi, Photonic Media) across
the network topology is calculated by the SDN Domain controller considering the
constraints introduced in the service request. The route in each layer is recursively

calculated from the lower layer to the upper layer, excluding/including ALL those
components of the topology shared with the connections created to support the
selected service.
For the coroute-inclusion capability, the CS’s Top Connection’s routes MUST
share the same potentially shared resources (i.e., links) of the referenced service in
all layers from DSR to PHOTONIC_MEDIA_OMS when it applies.
Moreover, the Top Connection’s routes (including the new path when the
restoration is triggered) of a CS implementing coroute-inclusion or diversity-
exclusion policies, MUST include/exclude the all the potentially shared resources
(i.e., links) related to the route objects referenced by all the connections
(TopConnections) conforming the referenced CS. This condition MUST be met at
any time the TAPI Server in charge of the service, performs a path computation
action for the target service i.e., at the provisioning or restoration actions.
In case the referenced connectivity-service’s path changes due to a restoration or
any other reroute action and this new path enters in conflict with the conditions
impose to any other service referencing it by the coroute-inclusion or diversity-
exclusion attribute, the latter is not forced to proactively reroute but if any user or
control plane action force it to re-route then the conditions will need to be meet
again.
Type Provisioning
Description & Workflow The connectivity-service object sent by the TAPI Client to the Server to request the
creation of the service MUST include the coroute-inclusion or diversity-exclusion
attributes within.
The connectivity-service/s referenced by the coroute-inclusion or diversity-
exclusion attributes MUST be present in the TAPI Server context at the time of the
CS provisioning is request. In case, the referenced CS element is invalid, the TAPI
Server MUST return an error message in the RESTConf response message,
according to the rules included in https://tools.ietf.org/html/rfc8040#section-7, with
the “invalid-value” <error-tag>.
In case the referenced CS by the coroute-inclusion or diversity-exclusion
attributes change its route, this service will not change accordingly, in other words,
the TAPI server is not aimed to maintain a stateful relation between the services.
This UC is implemented following the same workflow described in “Description &

Table 24 complements the information included in the Use Case 1 definition, with the
Connectivity-Service attributes required to implement this use case, this implies all attributes and
objects included in Section 7.2.1.1 tables is required for this use case too.
Table 24: Connectivity-service diversity-exclusion and coroute-inclusion object definitions.
coroute-inclusion {connectivity-service-uuid: RW M  Reference to an existing

connectivity-service-ref - /tapi- ConnectivityService already
common:context/tapi- present in the TAPI server

connectivity:connectivity-context/conne context MUST be valid.

ctivity-service/uuid }
coroute- {connectivity-service-uuid: RW M  Reference to an existing
exclusion connectivity-service-ref - /tapi- ConnectivityService already
common:context/tapi- present in the TAPI server
connectivity:connectivity-context/conne context MUST be valid.
ctivity-service/uuid }

7.4 Use case 5: Use case 5: 1+1 protection with diverse service Provisioning
7.4.1 Use case 5a: 1+1 OLP Client Protection with Diverse Service Provisioning
7.4.2 Use case 5b: 1+1 OLP Line Protection with Diverse Service Provisioning
Number UC5b
Name 1+1 OLP Protection with Diverse Service Provisioning

Involved
Brief description This use case covers the use of OLPs elements for 1+1 and 1:1 protection services at
different layers (OMS, OTSi/OTSiA, DSR).
Three possible protection schemas based on OLP identified, so far, are represented in
Figure 7 -25.
Figure 7-25 UC-5b OLP protection schemas.
1. OMS OLP protection is not intended to be configured by the user, but to be

represented by the TAPI server as part of the Photonic_Media layer topology as
described in [TAPI-TOP-MODEL-REQ-23]. Thus OMS protection is out of the scope.
2. Line Side OLP protection represents a protection schema where an OLP is placed
between the Transponder line ports and two add/drop ports of a ROADM. The OLP
components duplicates the incoming signal and implements an Automatic Protection
Switch (APS) which switch the traffic between the two Add/Drop ports upon loss of
signal conditions (power measurement decrease under a target threshold) in less than
50ms. This is the intended case to be modelled by this UC.

3. Client Side OLP protection is left to further versions of this specification due to low
priority.
The TAPI server is responsible of maintaining the SLA condition and triggers the
automatic protection/switching actions when the connectivity-service nominal path is
being affected by any outage condition which provoke a degradation or interruption of
the service.
The protection process MUST be triggered automatically by the TAPI server, however,
the TAPI client MUST be notified about the service condition changes through the tapi-
notification service. The description of the notification process and its detail Low-Level-
Design is out of the scope of this use case definition.
Type Resilience
Description & This type of OLP protection (Line Side OLP) requires the reservation of two disjoint
Workflow routes along the Photonic_Media layer for the provisioning of connections to support the
1+1 or 1:1 Connectivity Services.
The TAPI Client SHOULD select two valid SIPs, to be referenced by the CSEPs, which
reference two OTSi/Photonic_Media NEPs directly connected to the Line-Side OLP
elements, as described in the Connectivity Service example (Figure 7 -26).
The TAPI Client MAY include the three SIPs mapped to the NMC/Photonic_Media
NEPs representing the switching ports of the OLP components (NMC1, NMC2, NMC3
as represented in the Figure), to associated to them different Protection Roles within the
CSEPs definition (please note that zEnd peer SIPs, NEPs have been omitted in this
explanation for simplicity). These protection roles MAY be in the example
PROTECTED (71.D1 - NMC1), WORK (72.D1 - NMC2), PROTECT (73.D1 - NMC3).
Alternatively, the TAPI Client MAY delegate the protection role selection to the TAPI
Server during the CS provisioning process and thus, only the two OTSi/Photonic_Media
SIPs MUST be referenced within the CS request. In case, the protection role is
delegated, the TAPI Client MUST include the preferred-restoration-layer attribute in
the CS’s request.
The Connectivity Service object sent to the TAPI Server MUST include the tapi-
connectivity:connectivity-service/tapi-topology:resilience-type/protection-type attribute
to specify which type of protection service is requested. Depending on the type of
protection this attribute MAY be set with the following values:
 ONE_PLUS_ONE_PROTECTION: Double selective receiving, dual
transmitting and selective receiving. The optical power from Tx are split with a
ratio of 50:50 on the main route and the standby route, which means both the
main and standby routes are in use no matter whether there is a fault in the main
route.
 ONE_FOR_ONE_PROTECTION: Selective receiving election, selective
transmitting and selective receiving mode. There are a main route and a standby
route between the two sites.
7.4.2.1 Expected result

The expected result after the creation of the OLP protected Photonic_Media/OTSi connectivity
service is represented over the TAPI topology scenario included in Section 5.3.2 in Figure 7 -
26.

Figure 7-26 UC-5b OLP TAPI Connectivity-Service low-level description.
Once the CS is created, the TAPI Server is responsible of implementing the Switch control
among the connections generated to support the different protection schemas (1+1, 1:1), which
MUST provide automatic switch control between the working and protection connections in less
than 50ms.
The requested Photonic_Media/OTSi CS triggers the creation of:
 Protected OTSi Top Connection.
 Protected NMC Top Connection: which has two routes and implements switch-control
and sub-switch-control based on its aEnd and zEnd lower-connections switch-control.
o aEnd OLP site NMC lower connection: implementing the switch-control
between aEnd working and protection CEPs (NMC-2, NMC-3).
o N intermediate NMC lower connections: without switch control (connections
along the ROADM nodes)
o zEnd OLP site NMC lower connection: implementing the switch-control
between aEnd working and protection CEPs (respective CEPs to NMC-2, NMC-
3 in the other zEnd OLP).
In case the service is 1:1 PROTECTION:
o selected-connection-end-points: NMC-1, NMC-2 (and the respective CEPs in
zEnd) switch between NMC-2 and NMC-3 when the conditions changes.
o selected-route: Route-A, and switch to Route-B, when the conditions changes
In case the service is 1+1 PROTECTION:

o selected-connection-end-points: NMC-1, NMC-2, NMC-3 (and the respective

CEPs in zEnd) initially when both routes are active, and switch between NMC-2
and NMC-3 when the conditions changes.
o selected-route: Route-A, Route-B initially when both routes are active, and
switch to one of them, when the conditions changes.
For both cases:
o sub-switch-control: Referencing aEnd, zEnd OLP site NMC lower connection
switch-control objects.

Table 25, Table 26, Table 27, Table 28 and Table 29 complements the information included in
the Use Case 1 definition, with the Connectivity-Service, Connectivity-Service-End-Points,
Connections and Switch-control, attributes required to implement this use case, this implies all
attributes and objects included in Section 7.2.1.1 tables is required for this use case too.
Table 25: Connectivity-service attributes for 1+1 UC5b.

resiliency-type {"protection-type": RW M  Provided by tapi-client
[ONE_FOR_ONE_PROTECTIO
N,
ONE_PLUS_ONE_PROTECTIO
N]}
preferred-restoration-layer [PHOTONIC_MEDIA] RW M  Provided by tapi-client
reversion-mode ["REVERTIVE", "NON- RW M  Provided by tapi-client

REVERTIVE"]
restore-priority "[0-9]+" RW O  Provided by tapi-client
hold-off-time "[0-9]{4}" RW O  Provided by tapi-client
wait-to-revert-time "[0-9]{4}" RW O  Provided by tapi-client
max-switch-times "[0-9]{2}" RW O  Provided by tapi-client
is-coordinated-switching-both- [true, false] RW O  Provided by tapi-client
ends
is-lock-out [true, false] RW O  Provided by tapi-client
is-frozen [true, false] RW O  Provided by tapi-client
Table 26: Connectivity-service-End-Points attributes for UC5b.
connectivity-service-end-point


Protection-role ["WORK", "PROTECT", RW M  Provided by tapi-client
"PROTECTED"]  Support only P2P
Table 27: Connection attributes for UC5b.
connection

switch-control List of { switch-control } RO M  Provided by tapi-server
Table 28: Switch-control attributes for UC5b.
switch-control

{12}"
 "value-name": "SWC_NAME"
"value": " [0-9a-zA-Z]{64}"
resilience-type {"protection-type": RO O  Provided by tapi- server
[ONE_PLUS_ONE_PROTECTION",
"ONE_FOR_ONE_PROTECTION"]}
reversion-mode ["REVERTIVE", "NON- RO O  Provided by tapi- server
REVERTIVE"]
restore-priority "[0-9]+" RO O  Provided by tapi- server
hold-off-time "[0-9]{4}" RO O  Provided by tapi- server
wait-to-revert- "[0-9]{4}" RO O  Provided by tapi- server
time
max-switch- "[0-9]{2}" RO O  Provided by tapi- server
times
is-coordinated- [true, false] RO O  Provided by tapi- server
switching-both-
ends
is-lock-out [true, false] RO O  Provided by tapi- server
is-frozen [true, false] RO O  Provided by tapi- server
preferred- List of [“PHOTONIC_MEDIA”] RO M  Provided by tapi- server

restoration-layer
sub-switch- List of RO M  Provided by tapi-server
control {"/config/context/connection/{uuid}/swi
tch-control/{switch_control_uuid}/"}
switch List of { switch } RO M  Provided by tapi-server
Table 29: Switch attributes for UC5b.
switch

 "value-name": "SW_NAME"
"value": " [0-9a-zA-Z_]{64}"
switch-direction ["BIDIRECTIONAL", "INPUT", RO M  Provided by tapi-server
"OUTPUT"]
switch-control ["LOCK_OUT", "NORMAL", RO M  Provided by tapi-server
"MANUAL", "FORCED"]
switch-reason ["LOCKOUT", "NORMAL", RO M  Provided by tapi-server
"MANUAL", "FORCED",
"WAIT_TO_REVERT",
"SIGNAL_DEGRADE",
"SIGNAL_FAIL"]
selected- List of {"connection-end-point-ref - RO M  Provided by tapi-server
connection-end- /tapi-common:context/tapi-
point topology:topology-context/topology/no
de/owned-node-edge-point/tapi-
point/uuid "}
selected-route List of {"/tapi-common:context/tapi- RO M  Provided by tapi-server
ction/{uuid}/route/{local_id}/ "}
7.4.3 Use case 5c: 1+1 protection with Diverse Service Provisioning (eSNCP)
Number UC5c
Name 1+1 protection with Diverse Service Provisioning (eSNCP)

Brief description This use case covers the provisioning of 1+1 protected services implemented
through the electrical subnetwork connection protection (eSNCP) schema (Figure
7 -27) also known as ODUk SNCP.
ODUk SNCP protection protects services on line boards and on the units physically
located behind the line boards. Cross-connections on the electrical layer are used to
implement dual feeding and selective receiving, and protection switching is
triggered by OTN overhead alarms. The cross-connection granularity is ODUk (k =
0, 1, 2, 3, 4, flex).
Figure 7-27 UC-5c eSNCP protection schema.
The actual implementation of the ODUk SNCP monitoring mode is out of the
scope of this document but it is assumed that at least the Path Monitoring (PM)
OTN mechanism MUST be supported to provide end-to-end ODU protection
switching for DSR client services (e.g., multi-domain ODU services are out of the
scope of this use case definition).
automatic protection/switching actions when the connectivity-service nominal path
is being affected by any outage condition which provoke a degradation or
interruption of the service.
The protection process MUST be triggered automatically by the TAPI server,
however, the TAPI client MUST be notified about the service condition changes
through the tapi-notification service. The description of the notification process and
its detail Low-Level-Design is out of the scope of this use case definition.
Layers involved ODU
Type Resilience
Description & Workflow The connectivity service is requested between two DSR/ODU connectivity service
endpoints and requires the reservation of two disjoint routes at the ODU layer between
transponder’s line interfaces.
The TAPI Client SHOULD select two valid SIPs, to be referenced by the
ConnectivityServiceEndPoints, which reference two DSR/LO-ODUj NEPs which are
intended to be connected by the 1+1 connectivity-service at the ODU layer (Figure 7
-28).
The TAPI Client MAY include the two pairs of SIPs (67.D1, 68.D1) mapped to the
HO-ODUk NEPs representing the electrical side of the transponders line ports
selected to be cross-connected to the LO-ODUj NEPs, to protect the service. The

TAPI Client MAY associate to them different Protection Roles within the CSEPs
definition. These protection roles MAY be in the example PROTECTED (61.D1 -
LO-ODU-1), WORK (67.D1 - HO-ODU-1), PROTECT (68.D1 - HO-ODU-1) (zEND
peers have been omitted for simplicity).
Alternatively, the TAPI Client MAY delegate the protection role selection to the TAPI
Server during the CS provisioning process and thus, only specify the two DSR/LO-
ODUj SIPs MUST be referenced within the CS request. In case, the protection role is
delegated, the TAPI Client MUST include the preferred-restoration-layer attribute
in the CS’s request.
connectivity:connectivity-service/tapi-topology:resilience-type/protection-type
attribute with ONE_PLUS_ONE_PROTECTION attribute value.
7.4.3.1 Expected result

The expected result after the creation of the eSNCP ODU Connectivity Service is represented
over the TAPI topology scenario included in Section 5.3.2 in Figure 7 -28.
Figure 7-28 UC5c: Connectivity Service 100GE client signal over ODU4 with Line Side eSNCP
Protection
Once the CS is created, the TAPI Server is responsible of implementing the Switch control
among the connections generated to support the ODU eSNCP protection schema, which MUST
provide automatic switch control between the working and protection connections in less than
50ms. Please refer to the graphical illustration of this use case included Figure 7 -28, which
includes the Connection generated after the CS is created.
The requested ODU CS triggers the creation of:
 Protected DSR Top Connection.

 Protected LO-ODU Top Connection: which has two routes and implements switch-
control and sub-switch-control based on its aEnd and zEnd lower-connections switch-
control.
o aEnd LO-ODU lower connection: implementing the switch-control between
aEnd working and protection CEPs (LO-ODU-3, LO-ODU-4).
o zEnd LO-ODU lower connection: implementing the switch-control between
aEnd working and protection CEPs (LO-ODU-5, LO-ODU-6).
o selected-connection-end-points: LO-ODU-1, LO-ODU-3, LO-ODU-4 (and the
respective CEPs in zEnd) initially when both routes are active, and switch
between LO-ODU-3 and LO-ODU-4 when the conditions changes.
o selected-route: Route-A (HO-ODU-Top-Connection-A), Route-B (HO-ODU-
Top-Connection-B) initially when both routes are active, and switch to one of
them, when the conditions changes.
o sub-switch-control: Referencing aEnd, zEnd LO-ODU lower connection switch-
control objects.
 One working HO-ODU-Top Connection-A. Without switch control and its associated
lower-connections.
 One protection HO-ODU-Top Connection-B. Without switch control and its
associated lower-connections.
Additionally, the service might generate the PHOTONIC_MEDIA Layer connections if ODU
layer does not has enough resources:
 One working OTSi-Top Connection-A. Without switch control and its associated
lower-connections.
 One protection OTSi -Top Connection-B. Without switch control and its associated
lower-connections.
 One working NMC-Top Connection-A. Without switch control and its associated
lower-connections.
 One protection NMC -Top Connection-B. Without switch control and its associated
lower-connections.
Table 30 complements the information included in the Use Case 1 and Use Case 5b definitions,
with the Connectivity-Service attributes required implementing this use case, this implies all
attributes and objects included in Section 7.2.1.1 and 7.4.2.2 tables are required for this use case
too.
Table 30: Connectivity-service attributes for UC5c.

resiliency-type {"protection-type": RW M  Provided by tapi-client

N]}
preferred-restoration-layer [ODU] RW M  Provided by tapi-client

REVERTIVE"]
ends
7.5 Use case 6: Restoration policies for unconstrained and constrained

connectivity services
7.5.1 Use case 6a: Dynamic restoration policy for unconstrained and constrained connectivity
services.
Number UC6a
Name Dynamic restoration policy for DSR/ODU/OTSI unconstrained connectivity

services
Involved
Brief description This use case covers the provisioning of connectivity-services with restoration
capabilities.
The dynamic restoration capability can be requested at different layers i.e., DSR, ODU,
OTSI. The TAPI client just need to specify two available Connectivity Service End
Points and introduce the service characteristics (including the restoration-type and
protection-type attributes).
dynamic restoration process when the connectivity-service nominal path is being
affected by any outage condition which provoke a degradation or interruption of the
service.
The TAPI server is expected to calculate the new restoration path according to the
current network conditions when the SLA failure occurs.
The dynamic restoration process MUST be triggered automatically by the TAPI server,
however, the TAPI client MUST be notified about the service condition changes through
the tapi-notification service. The description of the notification process and its detail

Low-Level-Design is out of the scope of this use case definition.

Additional constrains, such coroute-inclusion or diversity-exclusion SHALL be account
as loose constrains at the time of the restoration occurs, i.e., applicable if possible.
Layers involved DSR, ODU, PHOTONIC_MEDIA
Type Resilience
Description & The connectivity service is requested between two DSR/ODU/OTSI CSEPs. The TAPI
Workflow Client SHOULD select two valid SIPs, to be referenced by the CSEPs, which reference
two DSR/LO-ODUj/OTSI NEPs which are intended to be connected by the dynamic-
restorable service.
The TAPI Client MAY include the tapi-connectivity:preferred-restoration-layer object
to specify the preferred restoration layer, but the final decision on how to implement the
restoration is responsibility of the TAPI server based on the current network conditions
when the dynamic restoration process occurs.
with DYNAMIC_RESTORATION attribute value.

with the Connectivity-Service attributes required to implement this use case, this implies all
attributes and objects included in Section 7.2.1.1 tables are required for this use case too.
Table 31: Connectivity-service attributes for UC6a.

resiliency-type {" protection-type": RW M  Provided by tapi-client
[DYNAMIC_RESTORATION]}
preferred-restoration-layer [ODU, PHOTONIC_MEDIA] RW M  Provided by tapi-client

REVERTIVE"]
7.6 Use case 7: Restoration and protection schemas.
7.6.1 Use case 7a: Dynamic restoration and 1+1 protection of DSR/ODU unconstrained service
provisioning.
Number UC7a
Name Restoration and protection 1+1



Involved
Brief description This use case covers the provisioning of connectivity-services with restoration
capabilities and 1+1 protection capabilities.
This first sub use case of this block proposes a 1+1 protection schema, which can be
implemented either:
 Over the PHOTONIC_MEDIA layer as the OLP Protection schema defined in
section 7.4.2
 Over the ODU layer as the eSNCP protection schema defined in section 7.4.3
This protection schema MUST provide automatic switch control between the working
and protection connections in less than 50ms. Moreover, this use case introduces a
second level of protection which is implemented through dynamic restoration of the first
connection affected by a failure. The dynamic restoration policy MUST be implemented
just one time.
The Connectivity-Service can be requested at different layers i.e., DSR, ODU. The TAPI
client just need to specify two available Connectivity Service End Points and introduce
the service characteristics (including the restoration-type and protection-type attributes).
protection and dynamic restoration processes when the connectivity-service working
path is being affected by any outage condition which provoke a degradation or
interruption of the service.
The TAPI server is expected to calculate the new restoration path according to the
current network conditions when the SLA failure occurs.
The protection and dynamic restoration processes MUST be triggered automatically by
the TAPI server, however, the TAPI client MUST be notified about the service condition
changes through the tapi-notification service. The description of the notification process
and its detail Low-Level-Design is out of the scope of this use case definition.
Additional constrains, such coroute-inclusion or diversity-exclusion SHALL be account
as loose constrains at the time of the restoration occurs, i.e., applicable if possible
Type Resilience
Description & The connectivity service is requested between two DSR/ODU CSEPs. The TAPI Client
Workflow SHOULD select two valid SIPs, to be referenced by the CSEPs, which reference two
DSR/LO-ODUj NEPs which are intended to be connected by the dynamic-restorable
service.
The TAPI Client MAY include the tapi-connectivity:preferred-restoration-layer object
to specify the preferred restoration layer, but the final decision on how to implement the
restoration is responsibility of the TAPI server based on the current network conditions
when the dynamic restoration process occurs.
with ONE_PLUS_ONE_PROTECTION_WITH_DYNAMIC_RESTORATION
attribute value.


with the Connectivity-Service, Connectivity-Service-End-Points, Connections and Switch-
control, attributes required to implement this use case, this implies all attributes and objects
included in Section 7.2.1.1 and 7.4.2.2 tables are required for this use case too.
Table 32: Connectivity-service attributes for UC7a.

resiliency-type {"protection-type": [ RW M  Provided by tapi-client
N_WITH_DYNAMIC_RESTOR
ATION ]}
preferred-restoration-layer [ODU, PHOTONIC_MEDIA] RW M  Provided by tapi-client

REVERTIVE"]
ends
7.7 Use Case 10: Service deletion (applicable to all previous use cases)
Number UC10
Name Service deletion (applicable to all previous use cases)

involved
Involved
Brief description This use case covers the deletion of a target connectivity-service and all the related
connections created by this service (i.e., all connections included as part of the CS
connection list).
If the user is not authorized to delete the target resource, then an error response containing
a "403 Forbidden" status-line SHOULD be returned. The error-tag value "access-denied"
is returned in this case. A server MAY return a "404 Not Found" status-line, as described
in Section 6.5.4 in [RFC7231]. The error-tag value "invalid-value" is returned in this

case.
Type Resilience
Description & The TAPI client MUST specify the tapi-connectivity:connectivity-service/uuid attribute
Workflow in the RESTCONF DELETE request in order to identify the service to be removed.
Figure 7-29 UC-10: Service Deletion workflow.

8 References
[RFC 8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol",
RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-
editor.org/info/rfc8040>.
[RFC 6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A.
Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC
6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-
[RFC 7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC
7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-
[RFC 7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module
Library", RFC 7895, DOI 10.17487/RFC7895, June 2016,
<https://www.rfc-editor.org/info/rfc7895>.
[OpenAPI] OpenAPI Specification Version 3.0.2,
<https://swagger.io/specification/>
[RFC 6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, DOI
10.17487/RFC6455, December 2011,
<https://www.rfc-editor.org/info/rfc6455>.
[W3C.REC-eventsource-20150203] Hickson, I., "Server-Sent Events", World Wide Web
Consortium Recommendation REC-eventsource-20150203, February
2015Considerations <http://www.w3.org/TR/2015/REC-eventsource-
20150203>.
[ONF TR-527] Functional Requirements for Transport API, June 10, 2016, ONF TR-
527,
<https://wiki.opennetworking.org/display/OTCC/TAPI+Documentatio
n>
[ONF TR-512] https://www.opennetworking.org/wp-content/uploads/2018/12/TR-
512_v1.4_OnfCoreIm-info.zip
[ITU-T G.709] ITU-T G.709: Interfaces for the optical transport network,
G.709/Y.1331 (06/16), https://www.itu.int/rec/T-REC-G.709
[ITU-T G.872] ITU-T G.872: Architecture of optical transport networks, ITU-T G.872
2017, https://standards.globalspec.com/std/10165255/ITU-T G.872
[ITU-T G.872] ITU-T G.805: Generic functional architecture of transport networks,
(03/2000), https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-
REC-G.805-200003-I!!PDF-E&type=items
[RFC 7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC
7951, DOI 10.17487/RFC7951, August 2016, <http://www.rfc-

9 Definitions
9.1 Terms defined elsewhere

This document uses terms defined elsewhere. These terms are highlighted in section 9.3
Abbreviations and acronyms below by referring to the definition source document.
9.2 Terms defined in this TR

The primary purpose of TR-512 is to define terms and hence terms are defined throughout the
document suite and model. Key terms are highlighted in section 9.3 Abbreviations and acronyms
below. Where a term is defined elsewhere there is a reference to the document where the term is
defined.
9.3 Abbreviations and acronyms
9.4 This TR uses the following abbreviations and acronyms (Note that some cross
references are included here rather than in the


o
o



o

o






The purpose of this document is to describe a set of guidelines and recommendations for a
standard use of the TAPI models in combination with RESTCONF protocol for the
implementation of the interface between network systems in charge of the control/management
of networks based on WDM/OTN technologies. section where the cross reference is only
relevant for abbreviation/acronym interpretation purposes):
Ø Phase
(A) Assembly
(e) electrical
(G) Group
(O) Overhead
(p) photonic
Analogue Continuously variable quantity (not relevantly quantized, not digitized). Used to
convey information.
AP Access Point [ITU-T G.805]
API Application Programmer's Interface
BBF BroadBand Forum (see https://www.broadband-forum.org/)
BC Boundary Clock
BMCA Best Master Clock Algorithm
C&SC Configuration and Switch Controller (model entity)
CASC C&SC
CC ControlConstruct (see TR-512.8)
CD ConstraintDomain (see TR-512.11)
cir circulator
CNM Customer Network Management
CP Connection Point [ITU-T G.805]
CRUD Create Read Update Delete
CTP Connection Termination Point. Note that definitions differ between TM Forum
[TMF 612] and [ITU-T M.3100]. Both usages apply here when referring to legacy
cases and the abbreviation is qualified in all cases of use.
DSP Digital Signal Processor
DSRA Digital Services Reference Architecture (see TMF)
E-O Electrical - Optical
ECC Embedded Communications Channel [ITU-T G.874]
EDFA Erbium Doped Fiber Amplifier
EMS Element Management System [definition reference ITU-T M.3400 - TMN]2
2
This term is not intended for use other than in reference to legacy systems.

ERP Ethernet Ring Protection

ERPS Ethernet Ring Protection Switching
ETH Ethernet MAC Layer [definition reference ITU-T G.8001]
eTOM enhanced Telecommunications Operations Map (see TMF)
ETY Ethernet Physical Layer [definition ITU-T G.8001]
FC ForwardingConstruct (defined in the ONF-CIM - see TR-512.2).
 Note that at this point the definition is subtly different to that in [TMF TR225].
The aim is to align the terms usage
FD ForwardingDomain (defined in the ONF-CIM - see TR-512.2)
FDFr FlowDomainFragment [TMF 612]
FRE ForwardingRelationshipEncapsulation [TMF TR215]
FRU Field Replaceable Unit
FTP FloatingTerminationPoint [TMF 612]
g Glass (used on an FC representing a fibre)
GitHub See www.github.com
GUID Globally Unique IDentifier (see www.wikipedia .org/Globally_unique_identifier)
H2M Human to Machine
IISOMI Informal Inter-SDO Open Model Initiative (see [OSSDN-EAGLE])
IM Information Model (see section 1 Introduction above)
IMP Inverse MultiPlexing [ITU-T G.805]
ISO International Organization for Standardization (see www.iso.org)
ITC Information Transfer Channel
ITU International Telecommunications Union (see www.itu.int)
ITU-T Telecommunications Standardization Sector of ITU-T (see
http://www.itu.int/en/ITU-T/Pages/default.aspx)
JSON JavaScript Object Notation (www.json.org/)
La Laser
LP LayerProtocol (defined in the ONF-CIM – see TR-512.2). Note that there are two
related terms:
 layer-protocol: used to refer to the information transfer protocol (or
Characteristic Information of the signal)
 layerProtcolName: used to refer to the attribute in the LP class that carries the
value that identifies the characteristic layer-protocol of the LP
 LayerProtocolName: used to refer to the data type that holds the formal name of
the layer-protocol
LTP LogicalTerminationPoint (defined in the ONF-CIM - see TR-512.2)
M2M Machine to Machine

MA Management Agent
MAC Media Access Control
MC Media Channel
MCA Media Channel Assembly
MCC Management Control Continuum (see [TMF IG1118]
MCG Media Channel Group
ME Managed Element OR Media Element (clarified per usage)
Media Substances (singular Medium) through which signal carrier is conveyed. In this case
a vacuum is also considered as a medium.
MEF MEF Forum (see https://mef.net/)
MEG Maintenance Entity Group
MEP MEG End Point
MFDFr MatrixFlowDomainFragment
MIP MEG Intermediate Point
MLSN MultiLayerSubNetwork [TMF 612]
MP2MP Multi-Point to Multi-Point
MPLS-TP Multi-Protocol Label Switching Transport Profile [definition reference RFC6378]
MSS Multiple Strand Span
NCD NetworkControlDomain
NDC Network Domain Channel
NE NetworkElement
NFV Network Function Virtualization
NMC Network Media Channel
NMCA Network Media Channel Assembly
NMCG Network Media Channel Group
NMS Network Management System
NVP Name-Value Pair
OAM Operations Administration and Maintenance
OC Ordinary Clock OR Overall Controller
OCh Optical Channel
ODU Optical Data Unit
OIF Optical Interworking Forum (see http://www.oiforum.com/)
OIMT Open Information Model & Tooling (an ONF project)
OME Optical Maintenance Entity
OMS Optical Multiplex Section
OMS-O Optical Multiplex Section-Overhead

ONF Open Networking Foundation

ONF-CIM ONF Common Information Model
OPS Optical Protection Switch
OS Operations System (same as OSS) OR Optical Section
OSC Optical Supervisory Channel
OSME Optical Signal Maintenance Entity
OSNR Optical Signal to Noise Ratio
OSS Operation Support System
OTCC Open Transport Configuration and Control (an ONF project)
OTN Optical Transport Network
OTS Optical Transmission Section
OTS-O Optical Transmission Section-Overhead
OTSi Optical Tributary Signal
OTSiG Optical Tributary Signal Group
OTSiG-O Optical Tributary Signal Group-Overhead
OTU Optical Transport Unit
OTU-CN Optical Transport Unit beyond 100G (B100G)
P&R Pruning and Refactoring (Prune and Refactor)
P2MP Point to Multi-Point
P2P Point to Point
PC ProcessingConstruct (see TR-512.11)
Pd Photodiode
Pe Pump of electrons (constant power stream)
Pm Phase modulation
PoC Proof of Concept
PON Passive Optical Network
Pp Pump of photons (constant power stream)
PRC Primary Reference Clock
PTP Physical Termination Point [TMF 612]
PTP Precision Time Protocol [IEEE 1588]
RMP Rooted Multi-Point
ROADM Reconfigurable Optical Add-Drop Multiplexor
SD FEC Soft Decision Forward Error Correction
SDN Software Defined Networking [ONF]
SDO Standards Development Organization
Se Signal encoded on an electron stream

Si Signal
SID Shared Information and Date model (see TMF)
SiG Signal Group
SNC SubNetworkConnection [TMF 612]
SNP SubNetworkPoint [ ITU-T G.8081]
Sp Signal encoded on a photon stream
SSM Synchronization Status Message
TAPI Transport API
TBD To Be Defined
TC Transparent Clock
TCP Termination Connection Point [ITU-T G.805]
TDM Time Division Multiplex
TL1 Transaction Language 1 (https://en.wikipedia.org/wiki/Transaction_Language_1)
TMF TeleManagement Forum (see www.tmforum.org)
TOSCA [OASIS TOSCA]
TP Termination Point [ITU-T M.3100]
TPE TerminationPointEncapsulation [TMF TR215]
TR Technical Recommendation [ONF] Technical Report [TM Forum]
TRI Transport Resource Identifier [ ITU-T G.8081]
TTP Trail Termination Point [ITU-T M.3100]
UML Unified Modelling Language (see www.omg.org)
UUID Universally Unique IDentifier (see
https://en.wikipedia.org/wiki/Universally_unique_identifier)
VCAT Virtual Concatenation
VM Virtual Machine
VMM Virtual Machine Manager
VNE Virtual Network Element
VNF Virtual Network Function
XC CrossConnection
YANG https://en.wikipedia.org/wiki/YANG

10 Conventions
10.1 Lifecycle Stereotypes

Lifecycle stereotypes (see [ONF TR-514]) are applied to entities in the model to indicate their
degree of maturity3. These are made visible in many of the figures in this document.
The following stereotypes appear in TR-512:
 «Experimental»: Indicates that the entity is at a very early stage of development and will
almost certainly change. The entity is NOT mature enough to be used in
implementation4.
 «Preliminary»: Indicates that the entity is at a relatively early stage of development and
is likely to change but is mature enough to be used in implementation.
If no stereotype is shown (or the entity is marked «Mature») the entity is mature. Other Lifecycle
Stereotypes are defined in [ONF TR-514].
10.2 Key to diagram symbol set

This document set includes a number of UML diagrams. The UML symbol set is suitably
explained in [ONF TR-514]. Many of the UML diagrams in this document have small font (due
to density of information conveyed). It will be necessary for the reader to zoom in and pan across
the figure to see the detail5.
This document set also contains a number of non-UML diagrams, which use the symbols
highlighted below in pictorial representations of network examples. The symbol set is an
advanced partial hybrid of symbols used by other bodies (see [TMF TR215] and [ITU-T G.805]).
3
The whole model including all degrees of work in progress has been published to allow the user maximum
opportunity to set a most consistent direction with the work at hand. It is considered important to expose work in
progress especially where this may have an impact on a choice of implementation. There may be some experimental
structure that contains some very stable parts, without that structure those parts might be quite uninterpretable. A
user who decides to take a low risk approach can ignore preliminary and experimental parts. A user who is more
inclined to take a risk or who is looking for inspiration for their work can take the experimental and preliminary
parts, understanding the risk involved.
4
The implementer can clearly choose to use the item at risk (expecting change and accounting for this in
deployments etc.)
5
The aim is to improve the figure readability in future releases.

Figure 10-30 Network diagram symbol set6
In addition in the diagrams related to media the following symbols and labels are used.
6
It should be noted that in this version and future versions the terms ForwardingDomain (FD) and
ForwardingConstruct (FC) are used in place of SubNetwork (SN) and SubNetworkConnection (SNC) (used in the
earlier versions of the ONF-CIM).

Figure 6-31 Additional media diagram symbol set
11 Future CoreModel work areas

Future work areas are covered in TR-512.FE.
12 Terminology Translation table

The translations provided in this release are early draft (see TR-512.TM). There may be errors in
the table and the table is not complete. It should be used for guidance only.
13 Documentation structure
TR-512 is delivered in a .zip file. The file has key documents at the top level and several folders
that contain other documents, UML figures and the model.
The .zip file is structured as below:
 ReadMe.txt

 TR-512.1_OnfCoreIm-Overview.pdf (inc. Links to ModelDescription documents and OnfModel folder)

 ModelDescriptions folder (each document includes navigable links to other relevant documents)
o TR-512.2_OnfCoreIm-ForwardingAndTermination.pdf
o TR-512.3_OnfCoreIm-Foundation.pdf
o TR-512.4_OnfCoreIm-Topology.pdf
o TR-512.5_OnfCoreIm-Resilience.pdf
o TR-512.6_OnfCoreIm-Physical.pdf
o TR-512.7_OnfCoreIm-Specification.pdf
o TR-512.8_OnfCoreIm-Control.pdf
o TR-512.10_OnfCoreIm-OperationPatterns.pdf
o TR-512.11_OnfCoreIm-ProcessingConstruct.pdf
o TR-512.12_OnfCoreIm-Software.pdf
o TR-512.A.1_OnfCoreIm-AppendixOverview.pdf
o TR-512.A.2_OnfCoreIm-Appendix-ModelStructurePatternsAndArchitecture.pdf
o TR-512.A.3_OnfCoreIm-Appendix-ModelRationale.pdf
o TR-512.A.4_OnfCoreIm-Appendix-AnalogueAndMediaExamples-L0.pdf
o TR-512.A.5_OnfCoreIm-Appendix-CircuitSwitchedExamples-L1-L2-gd.pdf
o TR-512.A.6_OnfCoreIm-Appendix-PacketSwitchedExamples-L2-L3-gd.pdf
o TR-512.A.7_OnfCoreIm-Appendix-ControlAndInteractionExamples-gd.pdf
o TR-512.A.8_OnfCoreIm-Appendix-TimingAndSynchronizationExamples.pdf
o TR-512.A.9_OnfCoreIm-Appendix-ProcessingConstructExamples.pdf
o TR-512.A.10_OnfCoreIm-Appendix-SpecificationExamples.pdf
o TR-512.A.11_OnfCoreIm-Appendix-ResilienceExamples.pdf
o TR-512.A.13_OnfCoreIm-Appendix-SoftwareExamples.pdf
o TR-512.DD_OnfCoreIm-DataDictionary.pdf
o TR-512.FE_OnfCoreIm-FutureEnhancements.pdf
o TR-512.GT_OnfCoreIm-CommonGendocTemplate.pdf
o TR-512.TM_OnfCoreIm-TerminologyMapping.pdf
 UmlFigures folder (has a subfolder for each document that includes one or more UML figures. These figures have been included to aid
viewing as some are very detailed (as the .pdf figures do not scale sufficiently)).
o TR-512.1
o TR-512.2
o TR-512.3
o TR-512.4
o TR-512.5
o TR-512.6
o TR-512.7
o TR-512.8
o TR-512.10
o TR-512.11
o TR-512.12
o TR-512.A.2
o TR-512.FE
 OnfModel folder
o .project,
o CoreModel.di,
o CoreModel.notation
o CoreModel.uml
o OpenModel_Profile.profile.di
o OpenModel_Profile.profile.notation
o OpenModel_Profile.profile.uml
o Experimental.profile.di7
o Experimental.profile.notation
o Experimental.profile.uml
The Gendoc Templates used to generate the TR-512 documents and other documentation aids
are provided via another .zip file. They have been delivered to ensure inter-release continuity and
will be used as a basis for the construction of the documentation for the next release of model.
7
The Experimental profile provides some stereotypes related to experimental rules (e.g. in the Physical model). The
relevant stereotypes in this profile will be moved to a formal profile in the next release.

14 Individuals engaged
14.1 Editors
Nigel DAVIS Ciena

Kam LAM FiberHome
14.2 Contributors
Arturo MAYORAL Telefónica
End of Document

TR-5XX.1-TAPI v2.1.2 Reference Implementation

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TR-5XX.1-TAPI v2.1.2 Reference Implementation

Uploaded by

Copyright:

Available Formats

TAPI v2.1.

ONF Document Type: Technical Recommendation

Open Networking Foundation

Page 2 of 107 © 2018 Open Networking Foundation

3 RESTCONF/YANG Protocol considerations......................................................................................... 9

4 ONF Transport – API (TAPI) considerations......................................................................................12

Page 3 of 107 © 2018 Open Networking Foundation

4.4 TAPI Notifications....................................................................................................................... 21

5 Topology abstraction model................................................................................................................ 22

6 Connectivity service model.................................................................................................................. 33

7 Use cases Low Level designs (LLDs).................................................................................................... 46

Page 4 of 107 © 2018 Open Networking Foundation

11 Future CoreModel work areas.......................................................................................................... 105

12 Terminology Translation table.......................................................................................................... 105

13 Documentation structure.................................................................................................................. 105

14 Individuals engaged.......................................................................................................................... 107

Page 5 of 107 © 2018 Open Networking Foundation

Figure 5-1 NS-1: OTN/WDM Network scenario......................................................................................... 30

Page 6 of 107 © 2018 Open Networking Foundation

Page 7 of 107 © 2018 Open Networking Foundation

1.1 General introduction to the model

1.2 Introduction to this document

Page 8 of 107 © 2018 Open Networking Foundation

This specification is supported by standards, protocol specifications, IETF RFCs, ITU-T

Figure 2-1 Target OSS – SDN architecture for WDM

3 RESTCONF/YANG Protocol considerations

Page 9 of 107 © 2018 Open Networking Foundation

3.1 Root tree discovery

The server might respond as follows:

3.2 YANG models discovery

3.3 Operation API (RPC) vs Data API (REST)

3.4 Query filtering

Page 10 of 107 © 2018 Open Networking Foundation

Name Methods Description

3.5 Data encoding

Page 11 of 107 © 2018 Open Networking Foundation

3.6.1 SSE vs Websockets

4 ONF Transport – API (TAPI) considerations

4.1 TAPI SDK version and documentation

Page 12 of 107 © 2018 Open Networking Foundation

The TAPI yang models can be found at

 TAPI OpenAPI Specification - TAPI OAS ([OpenAPI] Specifications) included in this

The TAPI OAS specifications can be found at

Page 13 of 107 © 2018 Open Networking Foundation

4.2 TAPI Information model

Figure 4-2 Transport API Functional Architecture

Page 14 of 107 © 2018 Open Networking Foundation

‒ Carrier Ethernet (L2) – tapi-eth@2018-12-10.yang

Model Version Revision (dd/mm/yyyy)

tapi-common.yang 2.1.2 10/12/2018

Page 15 of 107 © 2018 Open Networking Foundation

 The set of Service-Interface-Points exposed to the TAPI client applications representing

4.2.2 Node and Topology Aspects of Forwarding Domain

Page 16 of 107 © 2018 Open Networking Foundation

Page 17 of 107 © 2018 Open Networking Foundation

Figure 4-3 TAPI Mapping from ITU-T.

4.2.3.1 Node-Edge-Point (NEP)

Page 18 of 107 © 2018 Open Networking Foundation

4.2.4 Service, Connection and Route

4.2.4.1 Connectivity-Service (CS)

4.3 TAPI Data API

Page 19 of 107 © 2018 Open Networking Foundation

API Entry RESTCONF Operations

Page 20 of 107 © 2018 Open Networking Foundation