Child pages
  • TAPI Contributions and Presentations

 

 

cid:image003.png@01D47AB3.2CCAF460

 

 

 

 

 

 

 

 

 

 

 


ONF Document Type: Technical Recommendation

 

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.   

 

 


Table of Contents

Disclaimer

Document History

1 Introduction

1.1 General introduction to the model

1.2 Introduction to this document

2 RESTCONF/YANG Protocol considerations

2.1 Root tree discovery

2.2 YANG model’s discovery

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

2.4 Query filtering

2.5 Data encoding

2.5.1 Namespaces

2.6 Notifications

2.6.1 SSE vs WebSocket

3 ONF Transport – API (TAPI) considerations

3.1 TAPI SDK version and documentation

3.2 TAPI Information model

3.2.1 Context

3.2.2 Node and Topology Aspects of Forwarding Domain

3.2.2.1 Topology

3.2.2.2 Node

3.2.2.3 Link

3.2.3 Node Edge Point v/s Service End Point v/s Connection End Point

3.2.3.1 Node-Edge-Point (NEP)

3.2.3.2 Service-Interface-Point (SIP)

3.2.3.3 Connection-End-Point (CEP)

3.2.4 Service, Connection and Route

3.2.4.1 Connectivity-Service (CS)

3.2.4.2 Connection

3.2.4.3 Route

3.2.4.4 Path

3.3 TAPI Data API

3.4 TAPI Notifications

4 Topology abstraction model

4.1 Model guidelines

4.2 Inventory considerations

4.3 Network scenarios

4.3.1 Scenario 1: ROADM network equipped with OTN matrices

4.3.1.1 Model representation (Transitional Link approach)

4.3.2 Scenario 2: Point-to-point DWDM link + Mesh DWDM network

4.3.2.1 Model representation

5 Connectivity service model

5.1 Model guidelines

5.1.1 Multi-layer connectivity service provisioning and connection generation

5.1.2 Resiliency mechanism at connectivity service

5.1.3 Topology and service constrains for connectivity services

6 Use cases Low Level designs (LLDs)

6.1 Topology and services discovery

6.1.1 Use Case 0a: Context & Service Interface Points discovery (pooling mode)

6.1.1.1 Required parameters

6.1.2 Use Case 0b: Topology discovery (synchronous mode)

6.1.2.1 Required parameters

6.1.2.2 Expected results

6.1.3 Use case 0c: Connectivity Service discovery (synchronous mode)

6.1.3.1 Required parameters

6.2 Unconstrained E2E Service Provisioning

6.2.1 Use case 1a: Unconstrained DSR Service Provisioning single wavelength (<100G).

6.2.1.1 Required parameters

6.2.1.2 Expected results

6.2.2 Use Case 1b: Unconstrained DSR Service Provisioning multi wavelength (beyond 100G).

6.2.2.1 Expected results

6.2.3 Use case 1c: Unconstrained ODU Service Provisioning

6.2.4 Use case 1d: Unconstrained PHOTONIC_MEDIA/OTSi Service Provisioning

6.2.4.1 Expected results

6.2.5 Use case 1e: Unconstrained PHOTONIC_MEDIA/OTSiA Service Provisioning

6.2.5.1 Expected results

6.2.6 Use case 1f: Unconstrained PHOTONIC_LAYER_QUALIFER_MC Service Provisioning

6.2.6.1 Expected results

6.3 Constrained Provisioning

6.3.1 Use case 3a: Include/exclude a node or group of nodes.

6.3.1.1 Required parameters

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

6.3.2.1 Required parameters

6.3.3 Use case 3c: Include/exclude the route used by other service.

6.3.3.1 Required parameters

6.4 Inventory

6.4.1 Use case 4a: Introduction of references to external inventory model.

6.4.2 Use case 4b: Complete Inventory model for NBI Interface.

6.4.2.1 Required parameters

6.4.2.2 Relative location of component with TAPI 2.1.3 using holder location

6.5 Resiliency

6.5.1 Use case 5a: 1+1 OLP OMS/OTS Protection with Diverse Service Provisioning

6.5.1.1 Expected result

6.5.2 Use case 5b: 1+1 OLP Line Protection with Diverse Service Provisioning

6.5.2.1 Expected results

6.5.2.2 Required parameters

6.5.3 Use case 5c: 1+1 protection with Diverse Service Provisioning (eSNCP)

6.5.3.1 Expected result

6.5.3.2 Required parameters

6.5.4 Use case 6a: Dynamic restoration policy for unconstrained and constrained connectivity services.

6.5.4.1 Required parameters

6.5.5 Use case 6b: Pre-Computed restoration policy for unconstrained and constrained connectivity services.

6.5.5.1 Required parameters

6.5.6 Use case 7a: Dynamic restoration and 1+1 protection of DSR/ODU unconstrained service provisioning.

6.5.6.1 Required parameters

6.5.7 Use case 7b: Pre-Computed restoration policy and 1+1 protection of DSR/ODU unconstrained service provisioning.

6.5.7.1 Required parameters

6.5.8 Use case 8: Permanent protection 1+1 for use cases

6.5.8.1 Required parameters

6.6 Maintenance

6.6.1 Use Case 10: Service deletion (applicable to all previous use cases)

6.7 Planning

6.7.1 Use case 12a: Pre-calculation of the optimum path (applicable to all previous use cases)

6.7.1.1 Required parameters

6.7.2 Use case 12b: Simultaneous pre-calculation of two disjoint paths

6.8 Notifications and alarms.

6.8.1 Use case 13a: Subscription to notification service.

6.8.2 Use case 14a: Notification of new topology element (topology, link, node, node-edge-point) inserted/removed in/from the network

6.8.3 Use case 14b: Notification of new connectivity-service element inserted/removed in/from the network.

6.8.4 Use case 14c: Notification of new path-computation element inserted/removed in/from the network

6.8.5 Use case 15a: Notification of status change on existing topology element (topology, link, node, node-edge-point) in the network.

6.8.6 Use case 15b: Notification of status change on existing connectivity-service element in the network.

6.8.7 Use case 15c: Notification of status change on the switching conditions of an existing connection element in the network.

7 References

8 Definitions

8.1 Terms defined elsewhere

8.2 Terms defined in this TR

8.3 Abbreviations and acronyms

9 Individuals engaged

9.1 Editors

9.2 Contributors

List of Figures

Figure 2-1  Example SDN architecture for WDM/OTN network

Figure 3-1 Transport API Functional Architecture

Figure 3-2 TAPI Mapping from ITU-T.

Figure 4-1 Media-channel entities relationship.

Figure 4-2 NS-1: OTN/WDM Network scenario

Figure 4-3 NS-1. T0: TAPI Topology Flat Abstraction model, transitional link approach.

Figure 4-4 NS-1. T0: TAPI Topology Flat Abstraction model, transitional link approach (Device view).

Figure 4-5 NS-1.T0: TAPI Topology Flat Abstraction model multi-layer node approach.

Figure 4-6 NS-1.T0: TAPI Topology Flat Abstraction model multi-layer node approach (Device view).

Figure 4-7 NS-2: OTN/WDM Network scenario 2.

Figure 4-8 NS-2. T0: TAPI Topology Flat Abstraction Transitional Link model.

Figure 4-9 NS-2. T0: TAPI Topology Flat Abstraction Transitional Link model (Device view).

Figure 4-10 NS-2. T0: TAPI Topology Flat Abstraction Multi-Layer Node model.

Figure 4-11 NS-2. T0: TAPI Topology Flat Abstraction Multi-Layer Node model (Device view).

Figure 6-1 UC-0a: Context and Service Interface Point - LLD Workflow.

Figure 6-2 UC-0b: Topology discovery - LLD Workflow.

Figure 6-3 TAPI topology representation at "day 0" following Transitional Link modelling approach.

Figure 6-4 TAPI topology representation at "day 0" following Multi-layer Node modelling approach.

Figure 6-5 UC-0c: Connectivity Service - LLD Workflow.

Figure 6-6 UC-1: Unconstrained end-to-end service provisioning.

Figure 6-7 TAPI Logical Termination Point Template – Basic Arrangements.

Figure 6-8 UNI Modelling simplifications

Figure 6-9 Connectivity Service 10GE client signal over ODU2 (DSR-ODU Fixed Mapping) over ODU4 over single OTSi – Transitional Link modelling

Figure 6-10 Connectivity Service 10GE client signal over ODU2 (DSR-ODU Fixed Mapping) over ODU4 over single OTSi – Multi-layer node modelling.

Figure 6-11 Connectivity Service 1GE client signal over ODU0 over ODU2 over ODU4 (Fixed DSR-ODU mapping, flexible ODU allocation)

Figure 6-12 Connectivity Service 1GE client signal over ODU0 over ODU2 over ODU4 (Fixed DSR-ODU mapping, flexible ODU allocation) with intermediate ODU0 switching

Figure 6-13 Connectivity Service 10GE client signal over ODU2 over ODU4 (Fixed DSR-ODU mapping, flexible ODU allocation) with intermediate transponder regeneration.

Figure 6-14 200GE over ODUc2 connectivity-service over two OTSi/OTSiMC over a single physical (PHOTONIC-MEDIA_OMS) port (Transitional Link).

Figure 6-15 200GE over ODUc2 connectivity-service over two OTSi/OTSiMC over a single physical (PHOTONIC-MEDIA_OMS) port (Multi-Layer Node).

Figure 6-16 OTSi single lambda connectivity-service - Transitional link model.

Figure 6-17 OTSi single lambda connectivity-service - Multi-layer node approach.

Figure 6-18 OTSiA multi-wavelength connectivity-service (transitional link model abstraction).

Figure 6-19 OTSiA multi-wavelength connectivity-service (multi-layer node model abstraction).

Figure 6-20 Media-channel entities relationship.

Figure 6-21 Full Bidirectional - UNI and OMS bidirectional scenario.

Figure 6-22 Mixed Scenario - UNI bidirectional and OMS unidirectional.

Figure 6-23 Full Unidirectional - UNI and OMS unidirectional scenario.

Figure 6-24 UC-4b Hierarchical arrangement of equipment objects with TAPI 2.1.3.

Figure 6-25 UC-4b Network Element Subracks container-holder location examples.

Figure 6-26 UC-5c OMS OLP protection schemas.

Figure 6-27 UC-5a OLP protection TAPI representation.

Figure 6-28 UC-5b Line OLP protection schema.

Figure 6-29 UC-5b: Resiliency workflow.

Figure 6-30 UC-5b OLP TAPI Connectivity-Service low-level description.

Figure 6-31 UC-5b OLP TAPI Connectivity-Service low-level description. Unidirectional OLS modelling.

Figure 6-32 UC-5c eSNCP protection schema.

Figure 6-33 UC5c: eSNCP protection schema for HO-ODUk Top Connection.

Figure 6-34 UC-6a: Resiliency workflow.

Figure 6-35 UC-10: Service Deletion workflow.

Figure 6-36 UC-12a: Pre-calculation of the optimum path workflow.

Figure 6-37 UC-12b: Simultaneous pre-calculation of two disjoint paths

Figure 6-38 UC-13a: Subscription to notification stream service


List of Tables

Table 1: RESTCONF Query filters

Table 2: TAPI YANG models summary.

Table 3: Minimum subset required of TAPI RESTCONF Data API

Table 4: Inventory-id fields format.

Table 5: Inventory-id fields combination allowance.

Table 6: Context object definition

Table 7: Service Interface Point (SIP) object definition

Table 8: Topology object definition

Table 9: Node object definition

Table 10: Node-edge-point object definition

Table 11: Node-rule-group object definition

Table 12: Rule object definition

Table 13: Link object definition

Table 14: Connectivity-service object definition

Table 15: Connectivity-service-end-point object definition

Table 16: Connection object definition

Table 17: Connection-end-point object definition

Table 18: ODU-Connection-end-point-spec object definition

Table 19: otsi-connection-end-point-spec object definition

Table 20: OTSI-Assembly-connection-end-point-spec object definition

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

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

Table 23: Route object definition

Table 24: otsia-connectivity-service-end-point-spec object definition

Table 25: mca-connectivity-service-end-point-spec object definition

Table 26: Connectivity-service node topology-constrains object definitions.

Table 27: Connectivity-service link topology-constrains object definitions.

Table 28: Connectivity-service diversity-exclusion and coroute-inclusion object definitions.

Table 29: Main parameters for equipment model required.

Table 30: Equipment object's attributes required for UC4b.

Table 31: Common-holder-properties object's attributes required for UC4b.

Table 32: Common-equipment-properties object's attributes required for UC4b.

Table 33: Common-actual-properties object's attributes required for UC4b.

Table 34: Device object attributes required for UC4b.

Table 35: Connectivity-service attributes for 1+1 UC5b.

Table 36: Connectivity-service-End-Points attributes for UC5b.

Table 37: Connection attributes for UC5b.

Table 38: Switch-control attributes for UC5b.

Table 39: Switch attributes for UC5b.

Table 40: Connectivity-service attributes for UC5c.

Table 41: Connectivity-service attributes for UC6a.

Table 42: Connectivity-service attributes for UC6a.

Table 43: Connectivity-service attributes for UC7a.

Table 44: Connectivity-service attributes for UC7b.

Table 45: Connectivity-service attributes for UC8.

Table 46: Path-computation-context attributes.

Table 47: Path-comp-serv object's attributes.

Table 48: Path-service endpoint object's attributes.

Table 49: Topology constraint object's attributes.

Table 50: Routing constraint object's attributes.

Table 51: Objective function object's attributes.

Table 52: Optimization-constraint object's attributes.


Document History

Version

Date

Description of Change

0.1

August 06, 2019

Initial version of the Reference Implementation document of TAPI v2.1.2

0.2

December 03, 2019

General upgrade with new use cases.

0.5

February 18, 2020

First general TAPI group review.

0.7

April 08, 2020

Model consolidation into v2.1.3.

General review of connectivity model, photonic media and resiliency concepts applicable to proposed use cases.

0.8

April 15, 2020

Refinement of the UC4b

0.9

April 21, 2020

Full review until section 4.3

0.10

May 26, 2020

Full review, with pending comments for tracking discussion into following versions.

0.11

May 26, 2020

Fully reviewed document with latest contributions into Transitional Link modelling, UNI interfaces simplification description and protection scheme refinements into UCs 5a, 5b and 5c.

1.0

June 23, 2020

TR Official version.


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.3 version of the TAPI information models (pruned/refactored from the ONF Core Information Model 1.4) and available in the public ONF GitHub repository at:

https://github.com/OpenNetworkingFoundation/TAPI/releases/tag/v2.1.3

1.2      Introduction to this document

T he 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 System (OSS), Orchestrator, (super) Controller, etc [1] . The scope of the architecture covers multiple domains within the same network, and it might consist of one or more layers of controllers, where each layer controller will export a certain level of abstraction through its TAPI context (e.g., a hierarchical controller may consume several domain SDN-C TAPI contexts to conform a multi-domain network and exposed it as an aggregated TAPI context). In this document we will refer the lower layer of controllers as SDN domain controller or SDN-C, and, to any hierarchical controller performing the same management/control capabilities or use cases over multiple network domains as Software-Defined Transport Network (SDTN) controller.

Thus, this specification is intended for the interface between an SDN-C and Orchestrator, (super) Controller or client layer systems (such OSS) where the SDN-C provides its network management through a TAPI context and maintains a synchronized view in a database.

Moreover, the client layer which will consume the TAPI context systems may have distinct roles (e.g., physical inventory) and that they may be composed of different components or applications. E.g., an OSS system composed by different pieces dedicated to different applications (such inventory, assurance or planning).

This document aims to define the base requirements for any TAPI Server entity (e.g., a SDN-C) which is intended to expose the management/control [2] capabilities of any use case such activation/configuration, service provisioning, path-computation and monitoring over a WDM/OTN network, through the interface defined in this document.

The term management/control 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 intend 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   Example SDN architecture for WDM /OTN network


2        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 0 [A1] ).
  • {+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.
  • {+restconf}/data/ietf-restconf-monitoring:restconf-state/capabilities: leaf to report the server capability of supporting query parameters defined in https://tools.ietf.org/html/rfc8040#section-9.1 .

2.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 will send the following query:

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>

2.2      YANG model’s 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 the YANG modules used by the server, within the "modules-state/module" and "yang-library/module-set/module" list resource. T he modules set resource is located at (both implementations are accepted so far):

  • According to [RFC 7895]: {+restconf}/data/ietf-yang-library : modules-state
  • According to [RFC 8525]: {+restconf}/data/ietf-yang-library : yang-library

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

Currently there are two allowed APIs resources defined in RESTCONF. Although both are compatible and valid, given the low penetration in the industry of the RPC-based API implementation, it is not currently included in this specification.

Thus, the current specification takes the support of the RESTCONF ‘data’ API as mandatory; while the ‘operations’ API, based on the TAPI defined RPCs, is considered optional.

2.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,   

HEAD

Select config and/or non-config data  resources     

depth        

GET,   

HEAD

Request limited subtree depth in the reply content     

fields       

GET,   

HEAD

Request a subset of the target resource contents   

filter       

GET,   

HEAD

Boolean notification filter for event  stream resources

start-time

GET,   

HEAD

Replay buffer start time for event stream resources     

stop-time

GET,   

HEAD

Replay buffer stop time for event stream resources     

 

The specific use of these query parameters will be detailed in the different Use Cases Low Level Design (LLDs) included in section 6 .

The "depth", “fields”, “filter”, “replay” and “with-defaults” [A2] 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

2.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.

2.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] .

Example:

GET /restconf/data/tapi-common:context HTTP/1.1                                                                                                                                              Host: example.com                                                                                                                                                                            Accept: application/yang-data+json

 

{

  "tapi-common:context": { # Root tree object is qualified by the module name.

    "tapi-connectivity:connectivity-context": { # Any augmentation introduces a new qualification of the module name where the augmentation was defined.

      "connectivity-service": [

        {

          "uuid": "0b530f9f-0fc3-4d27-b6c3-5c821214db1f"

        }

      ]

    }

  }

 

2.6      Notifications

The solution adhering to this specification must support all YANG-defined event notifications included in the information models included in section 3.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 with JSON encoding format, as defined in Section 3.2.3 of [RFC5277] and 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.

2.6.1       SSE vs WebSocket

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.


3        ONF Transport – API (TAPI) considerations

3.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. All TAPI release notes can be found at:

  https://github.com/OpenNetworkingFoundation/TAPI/releases

Current document is focus on TAPI v2 .1. 3 release.

DISCLAIMER : The PHOTONIC_LAYER_QUALIFIER_MC and PHOTONIC_LAYER_QUALIFIER_OTSiMC layer-protocol-qualifier values have been newly introduced in TAPI v2.1.3. They are equivalent to previous PHOTONIC_LAYER_QUALIFER_SMC and PHOTONIC_LAYER_QUALIFER_NMC of v2.1.2 respectively. Please find more detailed information in [TAPI-TOP-MODEL-REQ-20] .

3.2      TAPI Information model

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 3 - 1 Transport API Functional Architecture

The entire list of YANG models composing the TAPI information model can be found in Table 2 .

Table 2 : TAPI YANG models summary [A3] .

Model

Version

Revision (dd/mm/yyyy)

tapi-common.yang

2.1.3

23/04/2020

tapi-connectivity.yang

2.1.3

16/06/2020

tapi-eth.yang

2.1.3

23/04/2020

tapi-dsr.yang

2.1.3

23/04/2020

tapi-streaming.yang

2.1.3

16/06/2020

tapi-notification.yang

2.1.3

16/06/2020

tapi-oam.yang

2.1.3

23/04/2020

tapi-odu.yang

2.1.3

23/04/2020

tapi-photonic-media.yang

2.1.3

16/06/2020

tapi-path-computation.yang

2.1.3

23/04/2020

tapi-topology.yang

2.1.3

23/04/2020

tapi-virtual-network.yang [3]

2.1.3

16/06/2020

 

Finally, TAPI models are pruned/refactored from the ONF Core Information Model (Core IM) 1.4 [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.

3.2.1       Context

T-API is based on a context relationship between a server and client. 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.

The TAPI server tapi-common: context includes the following information [A4] :

  • 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 x GigE, FC-x, STM-x or OTU-k which are included as DSR tapi-common:LAYER_PROTOCOL_QUALIFIER valid identities in tapi-dsr . 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 4
  • A connectivity-context which includes the list of Connectivity-Service and Connection objects created within the TAPI Context.
    • For more details please see Section 0 [A5] .
  • 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 3.4

3.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: Topology and Node.

3.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.

3.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.

3.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.

3.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 a 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 3 - 2 TAPI Mapping from ITU-T.

 

3.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.

3.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.

3.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.

3.2.4       Service, Connection and Route

3.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.

3.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 (XC) – defined as a connection between Connection-End-Points of the same layer within a Forwarding-Domain (represented as a tapi-topology:n ode object).
  • Top Connections – are defined as end-to-end connections between Connection-End-Points within the same layer which may span multiple Forwarding-Domains. Top connections are composed by zero or more XCs 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 5.1 .

3.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 Connection [4] .

The following route states are foreseen:

  • Current route, i.e. the route where the signal is flowing according to Controller’s best knowledge.
  • Not Current route, applicable in case of resiliency schemes.

 

Note that lower-connections are used to reflect partitioning and route to reflect signal flow.

3.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).

3.3      TAPI Data API

As it was described in Section 3.2 he 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 API is considered as optional and its support will be considered as a plus, because 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 0 , 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 model’s 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 .

Table 3 : Minimum subset required of TAPI RESTCONF Data API

API Entry

RESTCONF Operations allowed

/tapi-common:context/

GET,  PUT,  PATCH [5]

/tapi-common:context/service-interface-point/

GET

/tapi-common:context/service-interface-point={uuid}/

GET, PUT, DELETE, PATCH

/tapi-common:context/tapi-topology:topology-context/nw-topology-service/

GET

/tapi-common:context/tapi-topology:topology-context/topology={uuid}/

GET

/tapi-common:context/tapi-topology:topology-context/topology={uuid}/node={uuid}/

GET

/tapi-common:context/tapi-topology:topology-context/topology={uuid}/link={uuid}/

GET

/tapi-common:context/tapi-topology:topology-context/topology={uuid}/node={uuid}/owned-node-edge-point={uuid}/

GET

/tapi-common:context/tapi-topology:topology-context/topology={uuid}/node={uuid}/owned-node-edge-point={uuid}/tapi-connectivity:cep-list/

GET

/tapi-common:context/tapi-topology:topology-context/topology={uuid}/node={uuid}/owned-node-edge-point={uuid}/tapi-connectivity:cep-list/connection-end-point={uuid}/

GET

/tapi-common:context/tapi-connectivity:connectivity-context/

GET, POST, PUT, DELETE, PATCH

/tapi-common:context/tapi-connectivity:connectivity-context/connectivity-service/

GET

/tapi-common:context/tapi-connectivity:connectivity-context/connectivity-service={uuid}/

GET, PUT, DELETE, PATCH

/tapi-common:context/tapi-connectivity:connectivity-context/connection={uuid}/

GET

/tapi-common:context/tapi-path-computation:path-computation-context/

GET, POST, PUT, DELETE, PATCH

/tapi-common:context/tapi-path-computation:path-computation-context/path-comp-service/

GET

/tapi-common:context/tapi-path-computation:path-computation-context/path-comp-service={uuid}/

GET, PUT, DELETE, PATCH

/tapi-common:context/tapi-path-computation:path-computation-context/path={uuid}/

GET

/tapi-common:context/tapi-common:context/tapi-notification:notification-context/

GET

/tapi-common:context/tapi-common:context/tapi-notification:notification-context/notif-subscription/

GET

/tapi-common:context/tapi-common:context/tapi-notification:notification-context/notif-subscription={uuid}/

GET, PUT, DELETE, PATCH

Please note that the TAPI implementation based on the RESTCONF standard defines a much wider set of API entries , thus consider the previous list as a reduction of the implementation scope.

3.4      TAPI Notifications

The current TAPI information model includes a specific model, the tapi-notification@ 2018-12-10 [A6] .yang , which defines the TAPI notifications format but also a custom TAPI notification subscription procedure to enable a TAPI clients to subscribe to receive these notifications in the form of asynchronous events.

This TAPI Notification mechanism MUST be compatible with the standard RESTCONF notification subscription mechanism already described in Section 2.6 .

 


4        Topology abstraction model

In this chapter a reference topology abstraction model is described. Due to the need of composing a unified view of the network resources along different TAPI 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, MC, OTSIMC, OTSi/OTSiA, ODU, DSR layers.

Please note that OTU layer is intentionally simplified in TAPI model. ODU and OTSiA/OTSi representation is considered enough to cover all our defined use cases.

Based on ONF TAPI 2.1.3 models, a topology abstraction view is described for vendor agnostic integration across management/control systems in the frame of the proposed architecture in Section 3 . The TAPI Topology Flat Abstraction model collapses all layers in a single multi-layer topology. The nomenclature T0 – Multi-layer topology and T# 0 is used interchangeably to reference this topology in the remaining document.

4.1      Model guidelines

To properly describe the 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 (OTSiMC, MC, OMS, OTS)) which are represented explicitly 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 T#0 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 other topologies that the server may implement.

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. Each SIPs MUST have at least one NEP related to it and all DSR, ODU and PHOTONIC_MEDIA node-edge-points (NEPs) which support service configuration SHOULD have a SIP associated to it (only restrictions imposed by hardware constrains should constrain this list, e.g., transponders with fixed DSR-ODU mapping). [A7]

[TAPI-TOP-MODEL-REQ-4]                        A SIP is logically mapped to topology NEPs through the tapi-topology:owned-node-edge-point/mapped-service-interface-point attribute:

  augment /tapi-common:context:

       +--ro topology* [uuid]

          +--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:

The following topology abstraction model proposes some degrees of freedom for the TAPI Server topology abstraction model implementation (e.g., L0 Photonic Media layer bidirectional/unidirectional or Transitional Link vs Multi-Layer node approaches). Thus, the TAPI Client would eventually need to deal with the TAPI Server implementation as soon as it is according to the rules described in this document.

DSR/ODU Layers:

[TAPI-TOP-MODEL-REQ-5]                        DSR/ODU 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) .

[TAPI-TOP-MODEL-REQ-6]                        The DSR/ODU layer network MUST be represented explicitly at the lowest partitioning level, i.e., each DSR/ODU 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 = [
    • all identities with base tapi-dsr:DIGITAL_SIGNAL_TYPE,
    • all identities with base tapi-odu:ODU_TYPE ]

[TAPI-TOP-MODEL-REQ-8]                        NEPs forwarding capabilities within a node can be optionally constrained by using node-rule-group/rules/forwarding-rules. This feature might be required for some use cases where an external path computation entity is placed on top of the TAPI Server, the details of whether this requirement MUST be fulfil will be introduced, where appropriate, in the use cases section. The NEPs can be segmented according to the following conditions:

  • Different layer-protocol-qualifier. In case a multi-layer 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:
    • forwarding-rule=MAY_FORWARD_ACROSS_GROUP
  • Not forwarding between same device ports . In some case 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:
    • 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.

module: tapi-topology

  augment /tapi-common:context:

+--rw topology-context      

  +--ro topology* [uuid]

    +--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-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

 

[TAPI-TOP-MODEL-REQ-9]                        The ODU <-> OTSI transitions MAY be represented by a transitional link between ODU NEPs representing the line side transmission and OTSi NEPs. 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].

module: tapi-topology

  augment /tapi-common:context:

    +--ro topology* [uuid]         

       +--ro link* [uuid]

       |  +--ro transitioned-layer-protocol-name* string

 

 

The transitional-link representation MUST be present at 'Day 0' (for more detailed description please check the examples included in section 6.1.2.2 ) TAPI Server representation of the topology, between two NEP pools at the ODU and PHOTONIC_MEDIA (OTSi layer qualified) layers. These NEP pools are intended to represent solely the adjacency between the two nodes representing the electrical and optical side of the target optical terminal (i.e., these NEPs are not intended to represent the inverse multiplexing capabilities of the ODU CEPs over OTSi generated NEP resources).

The model assumes a single NEP pool at the OTSi layer. It MUST include a reference to every NEP representing the TTP facing side of each optical line port exposing OTSi connectivity capacity. These references MUST be implemented by referencing individual OTSi NEPs associated to each physical Optical Line interface using the tapi-topology:node/owned-node-edge-point/aggregated-node-edge-point attribute within the NEP pool representation.

At the ODU side, the NEP representation is the same, but it is assumed that the individual NEPs will be created (and "attached" to the ODU NEP pool) dynamically by TAPI server, as a response of the creation of OTSi connections in the lower layer, i.e., the individual ODU NEPs exposing ODU connectivity resources will only be available after the lower layer (OTSi) will be provisioned.

[TAPI-TOP-MODEL-REQ-10]                   Alternatively, the ODU <-> OTSI transitions MAY be represented within the same DSR/ODU multi-layer node, by including the OTSI/OTSiA layers representation of the optical side of the optical terminals. In this case the ODU<-> OTSI transition MUST be represented as stack of tapi-topology:node-edge-point and tapi-connectivity:connection-end-points related to each other by tapi-connectivity:connection-end-point/parent-node-edge-point and tapi-connectivity:connection-end-point/client-node-edge-point attributes:

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-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 client-node-edge-point* [topology-uuid node-uuid node-edge-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     

In case of the multi-layer nodes collapses the OTSi/OTSiA layer together with DSR and ODU layers into the same tapi-topology:node representation the NEPs CAN be qualified as:

  • tapi-photonic-media:PHOTONIC_LAYER_QUALIFER_OTSI,
  • tapi-photonic-media:PHOTONIC_LAYER_QUALIFER_OTSIA,

Moreover, in case of the multi-layer node implementation, the following requirements' set, related to the OTSI PHOTONIC_MEDIA layer, MUST apply to the multi-layer node construct too.

Please note, the TAPI Client MUST deal with both ODU-OTSI transition modelling approaches.

OTSi/Photonic Media layers:

[TAPI-TOP-MODEL-REQ-11]                   The OTSi 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. This optical line interfaces representation shall be available at 'Day 0' i.e., after the Optical Terminals commissioning stage and prior to any service deployment over the optical line interfaces. For more detail please check the examples included in section 6.1.2.2 .

[TAPI-TOP-MODEL-REQ-12]                   The physical connectivity between transponder/muxponder line ports and ROADM/FOADM’s add/drop ports MUST be represented as UNIDIRECTIONAL or BIDIRECTIONAL tapi-topology:links between PHOTONIC_MEDIA NEPs. These NEPs MUST be qualified as layer-protocol-qualifier: LAYER_PROTOCOL_QUALIFIER_UNSPECIFIED. These NEPs represents the OTS and OMS switching layers and they should be the mounting point for any monitoring function in any of those layers.

[TAPI-TOP-MODEL-REQ-13]                   Independently of OMS NEPs directionality, the OTSI/OTSiA NEP representations on top of OMS NEP/CEPs MUST be BIDIRECTIONAL.

[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 non-qualified PHOTONIC_MEDIA 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], [LAYER_PROTOCOL_QUALIFIER_UNSPECIFIED]

[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 relation, in case Optical Line Protection (OLPs) are present, OLP complexity shall be always represented in the Photonic Media layer (for further description please see Use Case 5b).

Photonic-Media forwarding domains represents the Photonic Media (Open Line System (OLS)) network

[TAPI-TOP-MODEL-REQ-18]                   The Photonic-Media forwarding domains can be mapped to OLP, ROADM/FOADM and ILA network elements which connectivity is always represented as PHOTONIC_MEDIA links (which may be augmented with OTS/OMS layers monitoring OAM functions). 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 = [

LAYER_PROTOCOL_QUALIFIER_UNSPECIFIED,

PHOTONIC_LAYER_QUALIFIER_MC,

PHOTONIC_LAYER_QUALIFIER_OTSiMC] .

[TAPI-TOP-MODEL-REQ-20]                   Media Channel layer is consisting on Media-Channel  (MC) constructs, representing a reserved portion of the spectrum to route the OTSi signals, and by the OTSiMC layer which represents the actual portion of the spectrum occupied by the signal (MC spectrum must be wider than the OTSiMC). Please see Figure 4-1 graphical representation for more clarity.

The MC layer MUST be represented by client NEPs/CEPs on top of the PHOTONIC_MEDIA/ LAYER_PROTOCOL_QUALIFIER_UNSPECIFIED  (representing OTS/OMS layers) NEPs/CEPs at the OLS side of the links between Transponder Line Ports and ROADM Add/Drop ports.

The OTSiMC layer MAY be optionally represented by client NEPs/CEPs on top of the PHOTONIC_LAYER_QUALIFER_MC CEPs. The representation of this layer does only provide monitoring information but not switching (which only happens at MC layer), thus its inclusion depends on the HW monitoring capabilities of the optical HW components of the network.

Figure 4 - 1 Media-channel entities relationship.

 

[TAPI-TOP-MODEL-REQ-21]                   Each MC, OTSiMC 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 PHOTONIC_MEDIA links collapsing OTS and OMS layers. These 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 or OTS 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 or OTS protection is out of the scope of this modelling.

4.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 6 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.

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 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).
  • <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 management planes (i.e., Network Management Systems (NMSs) or Element Management Systems (EMSs) exposing network information).
  • <sl_index> is the real 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 management planes (i.e., Network Management Systems (NMSs) or Element Management Systems (EMSs) exposing network information).
  • <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 management planes (i.e., Network Management Systems (NMSs) or Element Management Systems (EMSs) exposing network information).
  • <p_index> is the real Port 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).

 

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=

<r_index>

/sh=

<sh_index>

/s_sh=

<s_sh_index>

/sl=

<sl_index>

/s_sl=

<s_sl_index>

/p=

<p_index>

/ne=<nw-ne-name>

X

x

-

x

-

x

/r=<r_index>

-

x

-

x

-

-

/sh=<sh_index>

-

-

x

x

-

-

/s_sh=<s_sh_index>

-

-

-

x

-

-

/sl=<sl_index>

-

-

-

-

x

x

/s_sl=<s_sl_index>

-

-

-

-

x

x

/p=<p_index>

-

-

-

-

-

-

 

Some examples of INVENTORY_ID for the node-edge-points potentially mapped to the ports described in the examples shown in Figure 6 - 25 in Section 6.4.2.2 :

Example 1:

"name": [{"value_name": "INVENTORY_ID", "value":

"/ne=MadridNorte/r=1/sh=1/sl=1/s_sl=0"}]

 

Example 2:

"name": [{"value_name": "INVENTORY_ID", "value": "/ne=MadridNorte/r=1/sh=2/sl=2/s_sl=1/p=3"}]

 

Example 3:

"name": [{"value_name": "INVENTORY_ID", "value": "/ne=MadridNorte/r=1/sh=3/sl=7/s_sl=2/p=2"}]


4.3      Network scenarios

Now we introduce two network scenarios, as the base examples to clearly explain the model assumptions explained before.

4.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 4 - 2 NS-1: OTN/WDM Network scenario

4.3.1.1    Model representation (Transitional Link approach)

Please note, in the following representations, the OMS and OTS layers are present purely for information purposes. The specification has stated that these two layers are collapsed from the switching representation perspective. They are represented using LAYER_PROTOCOL_QUALIFIER_UNSPECIFIED layer-protocol-qualifier construct. Please find more details in [TAPI-TOP-MODEL-REQ-22] .

Figure 4 - 3 NS-1. T0: TAPI Topology Flat Abstraction model, transitional link approach.

Figure 4 - 4 NS-1. T0: TAPI Topology Flat Abstraction model, transitional link approach (Device view).

 

Figure 4 - 5 NS-1.T0: TAPI Topology Flat Abstraction model multi-layer node approach.

 

Figure 4 - 6 NS-1.T0: TAPI Topology Flat Abstraction model multi-layer node approach (Device view).

 


4.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 4 - 7 NS-2: OTN/WDM Network scenario 2.

4.3.2.1    Model representation

Figure 4 - 8 NS-2. T0: TAPI Topology Flat Abstraction Transitional Link model.

Figure 4 - 9 NS-2. T0: TAPI Topology Flat Abstraction Transitional Link model (Device view).

 

Figure 4 - 10 NS-2. T0: TAPI Topology Flat Abstraction Multi-Layer Node model.

Figure 4 - 11 NS-2. T0: TAPI Topology Flat Abstraction Multi-Layer Node model (Device view).

 


5        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 by 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.

The topology absence model is excluded. TAPI model covers connectivity-service without connections but in this reference implementation agreement this option is not covered.

5.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 OTSi,/ OTSiA, and Media Channels (OTSIMC, MC) as per described in [ITU-T G.872].

[TAPI-CONN-MODEL-REQ-2]              The connectivity model MUST include the concept of Top Connection, which is defined as end-to-end connections between CEPs 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). Please see section 3.2.4.2 for more complete information.

[TAPI-CONN-MODEL-REQ-3]              A tapi-connectivity:connectivity-service MUST, after being successfully provisioned by the TAPI Server, always include a reference to all Top Connection tapi-connectivity:connection objects supporting/composing the CS between its Connectivity-Service-End-Points (CSEPs), within its connection list ( tapi-connectivity:connectivity-service/connection ). These connections describe the end-to-end connectivity across the network at every 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

  augment /tapi-common:context:

+--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 MUST 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.

module: tapi-connectivity

  augment /tapi-common:context:

+--rw connectivity-context

    +--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 name* [value-name]

          |     +--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 server which produces it). The TAPI Server SHALL maintain the logical order of the CEP, however the absolute source of truth, to infer the logical order of the connection-end-points within the Route object by the TAPI client by the knowledge of the Topology information (links) and the NEP and CEP associations, which MUST univocally represent the correct sequence of CEPs for each Top Connection.

[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 and rate. These references MUST be included within the tapi-connectivity:connection/ tapi-connectivity: lower-connection list. Please note that the use of the lower-connection attribute is used to represent the partitioning of the Top Connection and does not introduce any layering relationship.

module: tapi-connectivity

  augment /tapi-common:context:

+--rw connectivity-context

    +--ro connection* [uuid]

             +--ro lower-connection* [connection-uuid]

       |   +--ro connection-uuid -> /tapi-common:context/tapi-connectivity:connectivity-context/connection/uuid

 

[TAPI-CONN-MODEL-REQ-7]              Top Connections MAY 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-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

 

 

  • 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 represent 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-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

 

5.1.1   Multi-layer connectivity service provisioning and connection generation

In the proposed model, the TAPI server MUST include a reference to each layer Top Connection within the Connectivity Service’s Connection list as stated in 38 [TAPI-CONN-MODEL-REQ-3] .

The Connectivity Service routing across different layers MUST be inferred the Top-connections and its lower-connections, composing/supporting the connectivity-service (referenced within the tapi-connectivity:connectivity-service/connection list attribute) and by the tapi-topology <-> tapi-connectivity model relationships. These relationships are described in the following requirements:

[TAPI-CONN-MODEL-REQ-8]              Every layer-protocol or layer-protocol-rate transition MUST be represented as a stack of tapi-topology:node-edge-point and tapi-connectivity:connection-end-points related to each other by tapi-connectivity:connection-end-point/parent-node-edge-point and tapi-connectivity:connection-end-point/client-node-edge-point attributes:

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-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 client-node-edge-point* [topology-uuid node-uuid node-edge-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     

Please note that the previous statement is valid for all layer-protocol and layer-protocol-rate transitions but for the HO-ODUk <-> OTSi layer transition which MAY be represented also by a tapi-topology:link object including  a tapi-topology:transitioned-layer-protocol-name attribute as described in [TAPI-TOP-MODEL-REQ-9] .

[TAPI-CONN-MODEL-REQ-9]              Additionally every tapi-topology:link object generated to represent the adjacency between every pair of NEPs connected by the sequence of cross-connections included as lower-connections of a Top Connection object MUST be referenced by the tapi-connectivity:connection/supported-client-link attribute. The rest of the section states in which conditions these links SHALL be generated.

module: tapi-connectivity

  augment /tapi-common:context:

+--rw connectivity-context

    +--ro connection* [uuid]

          +--ro supported-client-link* [topology-uuid link-uuid]

                |  +--ro topology-uuid    -> /tapi-common:context/tapi-topology:topology-context/topology/uuid

       |  +--ro link-uuid -> /tapi-common:context/tapi-topology:topology-context/topology/link/uuid

 

Now, 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-10]         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 too 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-11]         One or more, DSR XC Connections, describing the lower partitioning level 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 t he CS triggers the creation of:

[TAPI-CONN-MODEL-REQ-12]         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 describing the lower partitioning level of ODUj Top Connection.
  • 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 to be realized.
  • Moreover, when all ODUj Top Connections are operational, a new tapi-topology:link at the DSR layer ( layer-protocol-name=DSR ) MAY be optionally generated between the NEPs produced by the CEPs (Trail Termination Points) of the Top Most Connection with the ODUj Layer rate and referenced by the tapi-connectivity: supported-client-link attribute .

 

[TAPI-CONN-MODEL-REQ-13]         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 the HO-ODUk Top Connection become operational ( tapi-connectivity:connection/tapi-common:operational-state = ENABLED ) the lower-rate ODU layer adjacency is enabled ( client layer NEPs is created “over” the operational CEPs) allowing the upper layer Top Connection to be realized.

[TAPI-CONN-MODEL-REQ-14]         Possibly multiple HO-ODUk XC Connections, describing the lower partitioning level of DSR Top Connection and they MUST be included within its lower-connection list.

  • When all XCs become operational, the HO-ODUk Top Connection becomes operational too.

At the PHOTONIC_LAYER_QUALIFER_OTSI layer the CS triggers the creation of:

[TAPI-CONN-MODEL-REQ-15]         One or more Top Connection at the OTSi layer between the two NEPs supporting the HO-ODUk NEPs.

  • Once the OTSi Top Connection is operational ( tapi-connectivity:connection/tapi-common:operational-state = ENABLED ), it MUST be included within the CS connection list.
  • If the multi-layer node modelling approach defined in 0 is followed (OTSI<>ODU layer transition is represented by the NEPs <> CEPs stack relationship instead of transitional links) and related HO-ODUk NEPs are not present in the multi-layer node, then these NEPs MUST be generated to allow the HO-ODUk Top Connection to be realized.
  • When the OTSi Top Connection becomes operational, an ODU tapi-topology:link between the related HO-ODUk NEPs MAY be optionally generated, representing the potential adjacency between these two NEPs at the HO-ODUk layer/rate. 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-16]         Possibly multiple OTSi/OTSiA, XC Connections, describing the lower partitioning level of OTSI Top Connection and MUST be included within its lower-connection list.

  • When operational, the OTSi/OTSiA Top Connection becomes operational too.
  • If the multi-layer node modelling approach defined in [TAPI-TOP-MODEL-REQ-11] is followed (OTSI<>ODU layer transition is represented by the NEPs <> CEPs stack relationship instead of transitional links) OTSi XC Connections may not be generated, nor referenced by the lower-connection list. In this case, the Top Connection's route MUST consists of the CEPs referenced at tapi-connectivity:connection/connection-end-point list.

 

At the Photonic Media Layer , the CS triggers the creation of one or more PHOTONIC_LAYER_QUALIFER_MC and optionally a PHOTONIC_LAYER_QUALIFER_OTSIMC Top Connections at the Media-Channel layer.

[TAPI-CONN-MODEL-REQ-17]         One MC Top Connection at the Photonic Media layer between the two CEPs supported by the MC NEPs facing the OTSi NEPs. At server PHOTONIC_MEDIA layer, the NEPs are linked by PHOTONIC_MEDIA link.

  • Once the MC Top Connection is operational ( tapi-connectivity:connection/tapi-common:operational-state = ENABLED ), it MUST be included within the CS connection list.
  • When the MC Top Connection becomes operational ( tapi-connectivity:connection/tapi-common:operational-state = ENABLED ),  an OTSi tapi-topology:link between the OTSi NEPs facing the MC NEPs MAY be optionally generated, representing the potential adjacency between these two NEPs at the OTSi layer. Thus, allowing ALL OTSi Top Connections supported by the MC to be realized. The new generated link [6] MUST be referenced by the CEPs of the Top Connection which generates it as a tapi-connectivity:supported-client-link.
  • MC Top Connection MUST include the explicit route referencing CEPs associated to NEPs of PHOTONIC_MEDIA Layer with MC supported-layer-qualifier.

[TAPI-CONN-MODEL-REQ-18]         Possibly multiple MC XC Connections, describing the lower partitioning level of MC Top Connection and MUST be included within its lower-connection list.

  • When all XC become operational, the MC Top Connection becomes operational too.

OTSiMC layer representation, including Top Connections, XCs and CEPs, is only required to represent monitoring capabilities at the filters but not switching (switching is just happening at the lower MC layer). Thus, the representation of the OTSiMC CEPs is optional and it depends upon the monitoring capabilities of the photonic_media layer filters at the OTSiMC level (signal positioning within the actual spectrum filtered MC).

[TAPI-CONN-MODEL-REQ-19]         One or more OTSiMC Top Connections (depending on the number of OTSI signals composing the OTSiA) at the Photonic Media layer between the two client NEPs generated by MC CEPs logically linked to PHOTONIC_MEDIA Add/Drop ports connected to the OT's line ports.

  • Once the each OTSiMC Top Connection is operational ( tapi-connectivity:connection/tapi-common:operational-state = ENABLED ), they MUST be included within the CS connection list.
  • Each OTSiMC Top Connection MUST include the explicit route referencing CEPs associated to NEPs of PHOTONIC_MEDIA Layer with OTSiMC supported-layer-qualifier.

[TAPI-CONN-MODEL-REQ-20]         Possibly multiple OTSiMC XC Connections, describing the lower partitioning level of OTSiMC Top Connection and MUST be included within its lower-connection list.

OTSiMC CEPs are present for two purposes, forwarding and monitoring. In the photonic model is never relevant for forwarding (strict fate sharing with MC), but only for monitoring.

  • When all XC become operational, the OTSiMC 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":"ODUj_TOP_1"},

                        {"connection-uuid":"ODUj+N_TOP_N"},

                        {"connection-uuid":"HO-ODUk_TOP_1"},

{"connection-uuid":"OTSi_TOP_1"},

{"connection-uuid":"OTSIMC_TOP_1"},

{"connection-uuid":"MC_TOP_1"}

]}

],

 

"connection":[

{"uuid": "DSR_TOP_1",

"lower-connection":[

{"connection-uuid":"DSR_XC_1"},

{"connection-uuid":"DSR_XC_2"}

]},

{"uuid": "ODUj_TOP_1",

"lower-connection":[

{"connection-uuid":"ODUj_XC_1"},

{"connection-uuid":"ODUj_XC_2"},

]},

 

… (repeated for N ODUj layer rates)

 

{"uuid": "ODUj_TOP_N",

"lower-connection":[

{"connection-uuid":"ODUj_XC_1"},

{"connection-uuid":"ODUj_XC_2"},

]},

{"uuid": "HO-ODUk_TOP_1",

"lower-connection":[

{"connection-uuid":"HO-ODUk_XC_1"},

{"connection-uuid":"HO-ODUk_XC_2"}

]},

{"uuid": "OTSi_TOP_1",

"lower-connection":[

{"connection-uuid":"OTSi_XC_1"},

{"connection-uuid":"OTSi_XC_2"}

]},

{"uuid": "OTSiMC_TOP_1",

"lower-connection":[

{"connection-uuid":"OTSiMC_XC_1"},

{"connection-uuid":"OTSiMC_XC_2"},

{"connection-uuid":"OTSiMC_XC_N"}

]} ,

{"uuid": "MC_TOP_1",

"lower-connection":[

{"connection-uuid":"MC_XC_1"},

{"connection-uuid":"MC_XC_2"},

{"connection-uuid":"MC_XC_N"}

]}

 

]}

   }

}

5.1.2       Resiliency mechanism at connectivity service

[TAPI-CONN-MODEL-REQ-21]         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
  • ONE_PLUS_ONE_PROTECTION_WITH_PRE_COMPUTED_RESTORATION
  • PERMANENT_ONE_PLUS_ONE_PROTECTION
  • ONE_FOR_ONE_PROTECTION
  • DYNAMIC_RESTORATION
  • PRE_COMPUTED_RESTORATION

module: tapi-connectivity

  augment /tapi-common:context:

    +--rw connectivity-context

+--rw connectivity-service* [uuid]

       |  +--rw resilience-type

       |  |  +--rw restoration-policy?   restoration-policy

|  |  +--rw protection-type? protection-type

 

[TAPI-CONN-MODEL-REQ-22]         The TAPI server, for all protected services with restoration capabilities, SHALL implement the PER_DOMAIN_RESTORATION policy by default, which implies it is responsible of activating the required control mechanisms to guarantee the restoration of the service autonomously.

[TAPI-CONN-MODEL-REQ-23]         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-21] , 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 0 [A8] .

module: tapi-connectivity

  augment /tapi-common:context:

    +--rw connectivity-context

+--rw connection* [uuid]

    +--ro switch-control* [uuid]

          |  +--ro sub-switch-control* [connection-uuid switch-control-uuid]

          |  |  +--ro connection-uuid        -> /tapi-common:context/tapi-connectivity:connectivity-context/connection/uuid

          |  |  +--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-connectivity:connectivity-context/connection/uuid

          |  |  |  +--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 name* [value-name]

          |  +--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 

5.1.3       Topology and service constrains for connectivity services

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

module: tapi-connectivity

  augment /tapi-common:context:

    +--rw connectivity-context

+--rw connectivity-service* [uuid]

|  +--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:uuid

 


6        Use cases Low Level designs (LLDs)

6.1      Topology and services discovery

This use case consists on retrieving all information available from TAPI servers (SDN-C) including service-interface-points and topology. 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 SDN-C.

There are two modes of operations foreseen for this use case:

  • Polling mode - based on periodic pooling retrieval operations and after each service creation to reconcile the actual state of the network.
  • Event triggered mode (Notifications) - 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 2.6 and 3.4 .

 

In this version at least the pooling mechanism is foreseen to be fully supported by any provider SDN-C compliant with this specification.

The use case is divided in two

  • Use Case 0a: Context & Service Interface Points discovery
  • Use Case 0b: Topology discovery

6.1.1       Use Case 0a: Context & Service Interface Points discovery (po l o ling mode)

Number

UC0a

Name

Context & Service Interface Points discovery (po l o ling mode)

Technologies involved

Optical

Process/Areas Involved

Planning and Operations

Brief description

The TAPI Context and Service Interface Points are the relevant network service information required before 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, to synchronize the context information.

Layers involved

DSR/ODU/PHOTONIC_MEDIA

Type

Discovery

Description & Workflow

This use case consists on retrieving context and service-interface-point information ( Figure 6-1 ). 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 6 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 7 which are marked as Mandatory (M) in the Support (Sup) column.

Figure 6 - 1 UC-0a: Context and Service Interface Point - LLD Workflow.

 

6.1.1.1    Required parameters

Following the required parameters for each object which is retrieved in this use case.

 

  Table 6 : Context object definition

Context

/tapi-common:context

Attribute

Allowed Values/Format

Mod

Sup

Notes

uuid

"[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}"

RO

M

  • As per RFC 4122
  • Provided by tapi-server

name

List of {value-name, value}

  • "value-name": "CONTEXT_NAME"

"value": " [0-9a-zA-Z_]{64}

  • "value-name": "VENDOR_NAME"

"value": "[0-9a-zA-Z_]{64}"

RO

M

  • Provided by tapi-server
  • CONTEXT_NAME is a user legible unstructured string tag to uniquely identify the tapi-server context.
  • VENDOR_NAME is a user legible unstructured string tag to uniquely identify the tapi-server owner or supplier.

service-interface-point

List of { service-interface-point }

RO

M

  • Provided by tapi-server
  • Direct modification disallowed

notification-context

  • List of { notif-subscription }
  • List of { notification }

RO

O

  • Provided by tapi-server

topology-context

  • { network-topology-service }
  • List of { topology }

RO

M

  • Provided by tapi-server

connectivity-context

  • List of { connectivity-service }
  • List of { connection }

RO

M

  • Provided by tapi-server

 

  Table 7 : Service Interface Point (SIP) object definition

Service-interface-point

/tapi-common:context/service-interface-point

Attribute

Allowed Values/Format

Mod

Sup

Notes

uuid

"[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}"

RW

M

  • As per RFC 4122
  • Provided by tapi-server

name

List of {value-name, value}

  • "value-name": "INVENTORY_ID",

  "value": " [0-9a-zA-Z_]{64}"

 

RW

M

  • Initial value provided by tapi-server
  • INVENTORY_ID format is described in section 4.2
  • Subsequent updates provided by tapi-client

layer-protocol-name

["DSR", "ETH", "ODU", “PHOTONIC_MEDIA”]

RO

M

 

supported-layer-protocol-qualifier

List of ["DIGITAL_SIGNAL_TYPE", "ODU_TYPE", "PHOTONIC_LAYER_QUALIFIER”]

RO

M

  • Provided by tapi-server
  • All children identities defined for ["DIGITAL_SIGNAL_TYPE", "ODU_TYPE",   "PHOTONIC_LAYER_QUALIFIER”] MUST be supported.

administrative-state

["UNLOCKED", "LOCKED"]

RW

M

  • Initial value provided by tapi-server
  • Subsequent updates provided by tapi-client

operational-state

["ENABLED", "DISABLED"]

RO

M

  • Provided by tapi-server

lifecycle-state

["PLANNED", "POTENTIAL_AVAILABLE", "POTENTIAL_BUSY", "INSTALLED", "PENDING_REMOVAL"]

RO

M

  • Provided by tapi-server

total-potential-capacity

“total-size”: {value,  unit}

  • "value": "[0-9]{8}",
  • "unit": ["TB", "TBPS", "GB", "GBPS", "MB", "MBPS", "KB", "KBPS"]

RO

M

  • Provided by tapi-server

available-capacity

“total-size”: {value,  unit}

  • "value": "[0-9]{8}",
  • "unit": ["TB", "TBPS", "GB", "GBPS", "MB", "MBPS", "KB", "KBPS"]

RO

M

  • Provided by tapi-server

tapi-photonic-media:otsi-service-interface-point-spec/ otsi-capability

  • List of “supportable-central-frequency-spectrum-band”:{ lower/upper-central-frequency, frequency-constraint: {adjustment-granularity, grid-type} }
    • “central-frequency”: "

[0-9]{9}",

  • “adjustment-granularity”:[ “UNCONSTRAINED”, “ G_3_125GHZ ”, “ G_6_25GHZ” , “ G_12_5GHZ ”, “ G_25GHZ ”, “ G_50GHZ ”, “ G_100GHZ”, ]
  • “grid-type”: [          “GRIDLESS”, “FLEX”, “CWDM”, “DWDM”]
  • List of “supportable-application-identifier”:{ application-identifier-type, application-code}
    • 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}"
  • 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”}
    • “total-power-*-warn-threshold”: " [0-9].[ 0-9 ]{7}"

 

 

RO

M

 

  • Provided by tapi-server
  • This block of attributes MUST augment SIPs attached to PHOTONIC_MEDIA NEPs exposing OTSI/OTSiG service provisioning capabilities.
  • The lower/upper- central-frequency of the laser specified in MHz. Those correspond to the lower and upper central frequencies of the band.
  • frequency-constraint specify the rest of feasible central frequencies within the band.
  • Adjustment-granularity in Gigahertz. As per ITU-T G.694.1, it is used to 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.

 

tapi-photonic-media:otsi-service-interface-point-spec/ power-management-capability

  • "supportable-maximum-output-power":{total-power, power-spectral-density}
    • "Total-power":" [0-9].[ 0-9 ]{64}",
    • "power-spectral-density":" [0-9].[ 0-9 ]{64}"
  • "supportable-minimum-output-power":{total-power, power-spectral-density}
    • "Total-power":" [0-9].[ 0-9 ]{64}",
    • "power-spectral-density":" [0-9].[ 0-9 ]{64}"
  • "tolerable-maximum-output-power":{total-power, power-spectral-density}
    • "Total-power":" [0-9].[ 0-9 ]{64}",
    • "power-spectral-density":" [0-9].[ 0-9 ]{64}"
  • "tolerable-minimum-output-power":{total-power, power-spectral-density}
    • "Total-power":" [0-9].[ 0-9 ]{64}",
    • "power-spectral-density":" [0-9].[ 0-9 ]{64}"

 

RW

M

 

  • Provided by tapi-server
  • Can be updated by the tapi-client

 

tapi-photonic-media: media-channel-service-interface-point-spec/mc-pool

  • List of “ supportable/available/occupied-spectrum ”:{upper/lower-frequency, frequency-constraint: {adjustment-granularity, grid-type} }
    • “upper/lower-frequency”: "

[0-9]{9}",

  • “adjustment-granularity”:[ “UNCONSTRAINED”, “ G_3_125GHZ ”, “ G_6_25GHZ” , “ G_12_5GHZ ”, “ G_25GHZ ”, “ G_50GHZ ”, “ G_100GHZ”, ]
  • “grid-type”: [          “GRIDLESS”, “FLEX”, “CWDM”, “DWDM”]

 

RO

M

 

  • Provided by tapi-server
  • This block of attributes MUST augment SIPs attached to PHOTONIC_MEDIA NEPs exposing Media_Channel service provisioning capabilities.
  • The upper/lower-frequency bound of the media channel spectrum specified in MHz..
  • Adjustment-granularity in Gigahertz. As per ITU-T G.694.1, it is used to 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.

 

tapi-photonic-media: media-channel-service-interface-point-spec/power-management-capability

  • "supportable-maximum-output-power":{total-power, power-spectral-density}
    • "Total-power":" [0-9].[ 0-9 ]{64}",
    • "power-spectral-density":" [0-9].[ 0-9 ]{64}"
  • "supportable-minimum-output-power":{total-power, power-spectral-density}
    • "Total-power":" [0-9].[ 0-9 ]{64}",
    • "power-spectral-density":" [0-9].[ 0-9 ]{64}"
  • "tolerable-maximum-output-power":{total-power, power-spectral-density}
    • "Total-power":" [0-9].[ 0-9 ]{64}",
    • "power-spectral-density":" [0-9].[ 0-9 ]{64}"
  • "tolerable-minimum-output-power":{total-power, power-spectral-density}
    • "Total-power":" [0-9].[ 0-9 ]{64}",
    • "power-spectral-density":" [0-9].[ 0-9 ]{64}"

 

RW

M

 

  • Provided by tapi-server
  • Can be updated by the tapi-client

 

 


6.1.2       Use Case 0b: Topology discovery (synchronous mode)

Number

UC0b

Name

Topology discovery (synchronous mode)

Technologies involved

Optical

Process/Areas Involved

Planning and Operations

Brief description

The TAPI Topology is the relevant network logical representation information required for 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, to synchronize the context information.

Layers involved

DSR/ODU/PHOTONIC_MEDIA

Type

Discovery

Description & Workflow

The topology discover use case consists on the workflow and operations depicted in Figure 6-2 . 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 are included in Table 8 . The response operation MUST contain the attributes included in Table 8 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 9 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 10 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 13 which are marked as Mandatory (M) in the Support (Sup) column.

Figure 6 - 2 UC-0b: Topology discovery - LLD Workflow.

 

6.1.2.1    Required parameters

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

  Table 8 : Topology object definition

Topology

/tapi-common:context/tapi-topology:topology-context/topology

Attribute

Allowed Values/Format

Mod

Sup

Notes

uuid

"[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}"

RO

M

  • As per RFC 4122
  • Provided by tapi-server

name

List of {value-name: value}

  • "value-name": "TOPOLOGY_NAME"

"value": " [0-9a-zA-Z_]{64}"

RO

M

  • Provided by tapi-server
  • TOPOLOGY _NAME is a user legible unstructured string tag to uniquely identify the tapi-server topology.

layer-protocol-name

List of ["DSR", "ODU", "PHOTONIC_MEDIA"]

RO

M

  • Provided by tapi-server

link

List of { link }

RO

M

  • Provided by tapi-server

node

List of { node }

RO

M

  • Provided by tapi-server

 

  Table 9 : Node object definition

Node

/tapi-common:context/tapi-topology:topology-context/topology/node

Attribute

Allowed Values/Format

Mod

Sup

Notes

uuid

"[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}"

RO

M

  • As per RFC 4122
  • Provided by tapi-server

name

List of {value-name: value}

  • "value-name": "NW-NE-NAME"

"value": " [0-9a-zA-Z_]{64}"

RO

M

  • Provided by tapi-server
  • NW-NE-NAME format is described in section 4.2

 

layer-protocol-name

List of ["DSR", "ODU", "PHOTONIC_MEDIA"]

RO

M

  • Provided by tapi-server

 

administrative-state

["UNLOCKED", "LOCKED"]

RO

M

  • Provided by tapi-server

operational-state

["ENABLED", "DISABLED"]

RO

M

  • Provided by tapi-server

lifecycle-state

["PLANNED", "POTENTIAL_AVAILABLE", "POTENTIAL_BUSY", "INSTALLED", "PENDING_REMOVAL"]

RO

M

  • Provided by tapi-server

total-potential-capacity

“total-size”: {value:  unit}

  • "value": "[0-9]{8}",
  • "unit": ["TB", "TBPS", "GB", "GBPS", "MB", "MBPS", "KB", "KBPS"]

RO

O

  • Provided by tapi-server

available-capacity

“total-size”: {value:  unit}

  • "value": "[0-9]{8}",
  • "unit": ["TB", "TBPS", "GB", "GBPS", "MB", "MBPS", "KB", "KBPS"]

RO

O

  • Provided by tapi-server

cost-characteristic

List of  {cost-name: cost-value}

  • "cost-name": "HOP_COUNT"

"cost-value": "[0-9]{8}"

RO

O

  • Provided by tapi-server

latency-characteristic

List of  { traffic-property-name: fixed-latency-characteristic }

  • "traffic-property-name": "FIXED_LATENCY"

"fixed-latency-characteristic": "[0-9]{8}"

RO

O

  • Provided by tapi-server

encapsulated-topology

{" topology-ref "}

RO

O

  • Provided by tapi-server
  • Needed if encapsulated-topology is supported

aggregated-node-edge-point

List of {" node-edge-point-ref "}

RO

O

  • Provided by tapi-server
  • Needed if encapsulated-topology is supported

owned-node-edge-point

List of { node-edge-point }

RO

M

node-rule-group

List of { node-rule-group }

RO

O

 

  Table 10 : Node-edge-point object definition

Node-edge-point

/tapi-common:context/tapi-topology:topology-context/topology/node/owned-node-edge-point

Attribute

Allowed Values/Format

Mod

Sup

Notes

uuid

"[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}"

RO

M

  • As per RFC 4122
  • Provided by tapi-server

name

List of {value-name: value}

  • "value-name": "INVENTORY_ID",

  "value": " [0-9a-zA-Z_]{64}"

 

RO

M

  • Provided by tapi-server
  • INVENTORY_ID format is described in section 4.2

 

layer-protocol-name

["DSR", "ODU", "PHOTONIC_MEDIA"]

RO

M

  • Provided by tapi-server

supported-cep-layer-protocol-qualifier

List of ["DIGITAL_SIGNAL_TYPE", "ODU_TYPE", "PHOTONIC_LAYER_QUALIFIER”]

RO

M

  • Provided by tapi-server
  • All children identities defined for ["DIGITAL_SIGNAL_TYPE", "ODU_TYPE",   "PHOTONIC_LAYER_QUALIFIER”] MUST be supported when applicable.

administrative-state

["UNLOCKED", "LOCKED"]

RO

M

  • Provided by tapi-server

operational-state

["ENABLED", "DISABLED"]

RO

M

  • Provided by tapi-server

lifecycle-state

["PLANNED", "POTENTIAL_AVAILABLE", "POTENTIAL_BUSY", "INSTALLED", "PENDING_REMOVAL"]

RO

M

  • Provided by tapi-server

termination-state

["LP_CAN_NEVER_TERMINATE", “LT_NOT_TERMINATED”, “TERMINATED_SERVER_TO_CLIENT_FLOW”, “TERMINATED_CLIENT_TO_SERVER_FLOW”, “TERMINATED_BIDIRECTIONAL”, “LT_PERMENANTLY_TERMINATED”, “TERMINATION_STATE_UNKNOWN”]

RO

O

  • Provided by tapi-server

termination-direction

["BIDIRECTIONAL", “SINK”, “SOURCE”]

RO

M

  • Provided by tapi-server

link-port-direction

["BIDIRECTIONAL", "INPUT","OUTPUT"]

RO

M

  • Provided by tapi-server

link-port-role

["SYMMETRIC"]

RO

O

  • Provided by tapi-server

total-potential-capacity

“total-size”: {value:  unit}

  • "value": "[0-9]{8}",
  • "unit": ["TB", "TBPS", "GB", "GBPS", "MB", "MBPS", "KB", "KBPS"]

RO

M

  • Provided by tapi-server

available-capacity

“total-size”: {value:  unit}

  • "value": "[0-9]{8}",
  • "unit": ["TB", "TBPS", "GB", "GBPS", "MB", "MBPS", "KB", "KBPS"]

RO

M

  • Provided by tapi-server

aggregated-node-edge-point

List of { node-edge-point-ref}

RO

O

  • Provided by tapi-server

 

mapped-service-interface-point

List of { "/tapi-common:context/service-interface-point/uuid ”}

RO

O

  • Provided by tapi-server

cep-list

List of { connection-end-point }

RO

M

  • Provided by tapi-server

tapi-photonic-media: media-channel-node-edge-point-spec

“mc-pool”: { supportable/available/occupied-spectrum }

  • List of “ supportable/available/occupied-spectrum ”:{upper/lower-frequency, frequency-constraint: {adjustment-granularity, grid-type} }
    • “upper/lower-frequency”: "

[0-9]{9}",

  • “adjustment-granularity”:[ “UNCONSTRAINED”, “ G_3_125GHZ ”, “ G_6_25GHZ” , “ G_12_5GHZ ”, “ G_25GHZ ”, “ G_50GHZ ”, “ G_100GHZ”, ]
  • “grid-type”: [          “GRIDLESS”, “FLEX”, “CWDM”, “DWDM”]

RO

O

 

  • Provided by tapi-server
  • This block of attributes MUST augment PHOTONIC_MEDIA NEPs exposing Media_Channel characteristics.
  • The upper/lower-frequency bound of the media channel spectrum specified in MHz..
  • Adjustment-granularity in Gigahertz. As per ITU-T G.694.1, it is used to 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.

tapi-odu:odu-node-edge-point-spec

"odu-pool":
{client capacity, max-client-instances, max-client-size}

RO

O

  • Provided by tapi-server

 

  Table 11 : Node-rule-group object definition

Node-rule-group

/tapi-common:context/tapi-topology:topology-context/topology/node/node-rule-group

Attribute

Allowed Values/Format

Mod

Sup

Notes

uuid

"[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}"

RO

M

  • As per RFC 4122
  • Provided by tapi-server

name

List of {value-name: value}

  • "value-name": "NRG_NAME"

"value": " [0-9a-zA-Z_]{64}"

RO

M

  • Provided by tapi-server

node-edge-point

List of { node-edge-point-ref}

RO

M

  • Provided by tapi-server

rule

List of { rule }

RO

M

 

  Table 12 : Rule object definition

Rule

/tapi-common:context/tapi-topology:topology-context/topology/node/node-rule-group/rule

Attribute

Allowed Values/Format

Mod

Sup

Notes

local-id

"[0-9a-zA-Z_]{32}"

RO

M

  • Provided by tapi-server

name

List of {value-name: value}

  • "value-name": "RULE_NAME"

"value": " [0-9a-zA-Z_]{64}"

RO

M

  • Provided by tapi-server

rule-type

["FORWARDING"]

RO

M

  • Provided by tapi-server
  • Support other rule types?

forwarding-rule

["MAY_FORWARD_ACROSS_GROUP", "MUST_FORWARD_ACROSS_GROUP", "CANNOT_FORWARD_ACROSS_GROUP", "NO_STATEMENT_ON_FORWARDING"]

RO

M

  • Provided by tapi-server

 

Table 13 : Link object definition

Link

/tapi-common:context/tapi-topology:topology-context/topology/link

Attribute

Allowed Values/Format

Mod

Sup

Notes

uuid

"[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}"

RO

M

  • As per RFC 4122
  • Provided by tapi-server

name

List of {value-name: value}

  • "value-name": "LINK_NAME"

"value": " [0-9a-zA-Z_]{64}"

RO

M

  • Provided by tapi-server

layer-protocol-name

List of ["DSR", "ODU", "PHOTONIC_MEDIA"]

RO

M

 

administrative-state

["UNLOCKED", "LOCKED"]

RO

M

  • Provided by tapi-server

operational-state

["ENABLED", "DISABLED"]

RO

M

  • Provided by tapi-server

lifecycle-state

["PLANNED", "POTENTIAL_AVAILABLE", "POTENTIAL_BUSY", "INSTALLED", "PENDING_REMOVAL"]

RO

M

  • Provided by tapi-server

direction

["BIDIRECTIONAL"]

RO

M

  • Provided by tapi- server

 

total-potential-capacity

“total-size”: {value:  unit}

  • "value": "[0-9]{8}",
  • "unit": ["TB", "TBPS", "GB", "GBPS", "MB", "MBPS", "KB", "KBPS"]

RO

M

  • Provided by tapi-server

available-capacity

“total-size”: {value:  unit}

  • "value": "[0-9]{8}",
  • "unit": ["TB", "TBPS", "GB", "GBPS", "MB", "MBPS", "KB", "KBPS"]

RO

M

  • Provided by tapi-server

transitioned-layer-protocol-name

List of { layer-protocol-name}

RO

M

  • Provided by tapi-server
  • Only applicable to transitional-links.

cost-characteristic

List of  {cost-name: cost-value}

  • "cost-name": "HOP_COUNT"

"cost-value": "[0-9]{8}"

RO

O

 

latency-characteristic

List of  { traffic-property-name: fixed-latency-characteristic }

  • "traffic-property-name": "FIXED_LATENCY"

"fixed-latency-characteristic": "[0-9]{8}"

RO

O

 

Risk-characteristic

List of  {risk-characteristic-name: risk-identifier-list}

  • "risk-characteristic-name": ["SRLG", "SRNG"]

"risk-identifier-list": List of "[0-9a-zA-Z_]{64}"

RO

O

 

node-edge-point

List of {" node-edge-point-ref }

RO

M

  • Provided by tapi-server

6.1.2.2   
Expected results

 

In this section we introduce the detail TAPI-Topology modelling expected at "Day 0" (i.e., after the commissioning stage of the network devices into the SDN-C, but before any service is configured).

6.1.2.2.1     UC0b - Example 0: TAPI topology representation at "day 0" following Transitional Link modelling approach

 

The detailed description of the assumptions assumed by the Reference Implementation to compose the Topology at Day '0' based on a Transitional-Link model, are described in [TAPI-TOP-MODEL-REQ-9] .

Figure 6 - 3 TAPI topology representation at "day 0" following Transitional Link modelling approach.

6.1.2.2.2     UC0b - Example 0: TAPI topology representation at "day 0" following Multi-layer Node modelling approach

Figure 6 - 4 TAPI topology representation at "day 0" following Multi-layer Node modelling approach.

 


6.1.3       Use case 0c: Connectivity Service discovery (synchronous mode)

 

Number

UC 0C

Name

Connectivity Service discovery (synchronous mode)

Technologies involved

Optical

Process/Areas Involved

Planning and Operations

Brief description

The TAPI Connectivity Service is a relevant network service information required for the 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 connectivity information.

Layers involved

DSR, ODU, PHOTONIC_MEDIA

Type

Planning

Description & Workflow

The Use Case 0c: Connectivity Service discovery consists on the retrieve of a connectivity-service at the DSR/ODU/PHOTONIC_MEDIA layers and the retrieval of the generated connections information. The complete workflow is shown in Figure 6-5

The NBI Client first retrieves the connectivity-context trimmed by the ?fields=connectivity-service filter to  retrieve all connectivity-services deployed in the TAPI Server (2). Then, iteratively the information of each Connectivity-Service (3) is requested, and also its list of Connection references (5). For all Connection reference a Connection retrieval operation is performed to get the Connection object details (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 14 (Connectivity-Service) and Table 16 (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 17 , Table 18 , Table 19 , Table 20 , Table 21 and Table 23 .

Captura de pantalla de un celular con texto

Descripción generada automáticamente

Figure 6 - 5 UC-0c: Connectivity Service - LLD Workflow.

 

6.1.3.1    Required parameters

For the details about the required parameters for each object retrieved in the previously described RESTCONF call operation, please refer to the UC1a Required Parameters Section 6.2.1.1

 


6.2      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 [A9] Service Provisioning

UC1c is left to be considered in future version of this specification.

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 of 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.

 

6.2.1      Use case 1a: Unconstrained DSR Service Provisioning single wavelength (<100G).

Number

UC1a

Name

Unconstrained DSR Service Provisioning single wavelength (<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, NMC [A10] 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 introducing any routing constraint in the service request, thus rely 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.

Layers involved

DSR/ODU/PHOTONIC_MEDIA

Type

Provisioning

Description & Workflow

The Use Case 1: Connectivity Service provisioning consists on the creation of a connectivity-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 6-6 .

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 14 and Table 15 . 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 (here a pooling or event-trigger mechanism need to be defined in order to reconciliate the information),) 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 14 (Connectivity-Service) and Table 16 (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 17 , Table 18 , Table 19 , Table 20 , Table 21 and Table 23 .

 

Figure 6 - 6 UC-1: Unconstrained end-to-end service provisioning.

 

 

6.2.1.1    Required parameters

 

  Table 14 : Connectivity-service object definition

Connectivity-service

/tapi-common:context/tapi-connectivity:connectivity-context/connectivity-service

Attribute

Allowed Values/Format

Mod

Sup

Notes

uuid

"[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}"

RW

M

  • As per RFC 4122
  • Provided by tapi-client

name

List of  {value-name: value}

  • "value-name": "SERVICE_NAME"

"value": " [0-9a-zA-Z_]{64}"

RW

M

  • Provided by tapi-client

administrative-state

["UNLOCKED", "LOCKED"]

RW

O

  • Provided by tapi-client

operational-state

["ENABLED", "DISABLED"]

RO

M

  • Provided by tapi-server

lifecycle-state

["PLANNED", "POTENTIAL_AVAILABLE", "POTENTIAL_BUSY", "INSTALLED", "PENDING_REMOVAL"]

RO

M

  • Provided by tapi-server

requested-capacity

“total-size”: {value: ,unit:}

  • "value": "[0-9]{8}",
  • "unit": ["TB", "TBPS", "GB", "GBPS", "MB", "MBPS", "KB", "KBPS"]

RW

M

  • Provided by tapi-client

service-type

["POINT_TO_POINT_CONNECTIVITY"]

RW

O

  • Provided by tapi-client
  • Support P2P only

service-layer

List of ["DSR", "ODU", "PHOTONIC_MEDIA"]

RW

M

  • Provided by tapi-client

preferred-transport-layer

List of ["DSR", "ODU", "PHOTONIC_MEDIA"]

RW

O

  • Provided by tapi-client

connection

List of { connection-ref - /tapi-common:context/tapi-connectivity:connectivity-context/connection/uuid}

RO

M

  • Provided by tapi-server

end-point

List of { connectivity-service-end-point }

RW

M

  • Provided by tapi-client
  • Min elements 2.
  • See Table 15

 

  Table 15 : Connectivity-service-end-point object definition

Connectivity-service-end-point

/tapi-common:context/tapi-connectivity:connectivity-service/end-point

Attribute

Allowed Values/Format

Mod

Sup

Notes

local-id

"[0-9a-zA-Z_]{32}"

RW

M

  • Provided by tapi-client

layer-protocol-name

List of ["DSR", "ODU", "PHOTONIC_MEDIA"]

RW

M

  • Provided by tapi-client

supported-layer-protocol-qualifier

List of ["DIGITAL_SIGNAL_TYPE", "ODU_TYPE", "PHOTONIC_LAYER_QUALIFIER”]

RW

M

  • Provided by tapi-server
  • All children identities defined for ["DIGITAL_SIGNAL_TYPE", "ODU_TYPE",   "PHOTONIC_LAYER_QUALIFIER”] MUST be supported.

administrative-state

["UNLOCKED", "LOCKED"]

RW

O

  • Provided by tapi-client

operational-state

["ENABLED", "DISABLED"]

RO

O

  • Provided by tapi-server

lifecycle-state

["PLANNED", "POTENTIAL_AVAILABLE", "POTENTIAL_BUSY", "INSTALLED", "PENDING_REMOVAL"]

RO

O

  • Provided by tapi-server

direction

["BIDIRECTIONAL", “INPUT”, “OUTPUT”]

RW

O

  • Provided by tapi-client

 

role

["SYMMETRIC", "TRUNK"]

RW

O

  • Provided by tapi-client
  • Support only P2P

capacity

“total-size”: {value:  unit}

  • "value": "[0-9]{8}",
  • "unit": ["TB", "TBPS", "GB", "GBPS", "MB", "MBPS", "KB", "KBPS"]

RW

O

  • Provided by tapi-client

service-interface-point

"/tapi-common:context/service-interface-point/uuid

RW

M

  • Provided by tapi-client

connection-end-point

List { connection-end-point}

RO

M

 

  Table 16 : Connection object definition

connection

/tapi-common:context/tapi-connectivity:connection

Attribute

Allowed Values/Format

Mod

Sup

Notes

uuid

"[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}"

RO

M

  • As per RFC 4122
  • Provided by tapi-server

name

List of {value-name, value}

  • "value-name": "CONNECTION_NAME"

"value": " [0-9a-zA-Z_]{64}"

RO

M

  • Provided by tapi-server

layer-protocol-name

List of ["DSR", "ODU", "PHOTONIC_MEDIA"]

RO

M

  • Provided by tapi-client

 

operational-state

["ENABLED", "DISABLED"]

RO

M

  • Provided by tapi-server

lifecycle-state

["PLANNED", "POTENTIAL_AVAILABLE", "POTENTIAL_BUSY", "INSTALLED", "PENDING_REMOVAL"]

RO

M

  • Provided by tapi-server

direction

["BIDIRECTIONAL"]

RO

M

  • Provided by tapi- server
  • Support UNIDIRECTIONAL?

lower-connection

List of { connectivity-ref - /tapi-common:context/tapi-connectivity:connectivity-context/connection/uuid}

RO

M

  • Provided by tapi-server

connection-end-point

List of {"connection-end-point-ref  - /tapi-common:context/tapi-topology:topology-context/topology/node/owned-node-edge-point/tapi-connectivity:cep-list/connection-end-point/uuid "}

RO

M

  • Provided by tapi-server

route

List of { route }

RO

M

switch-control

List of { switch-control }

RO

M

  • Provided by tapi-server

supported-client-link

List of {link-ref - topology-uuid + link-uuid

RO

O

  • Provided by tapi-server

 

  Table 17 : Connection-end-point object definition

Connection-end-point

/tapi-common:context/tapi-topology:topology-context/topology/node/owned-node-edge-point/tapi-connectivity:cep-list/connection-end-point

Attribute

Allowed Values/Format

Mod

Sup

Notes

uuid

"[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}"

RO

M

  • As per RFC 4122
  • Provided by tapi-server

name

List of {value-name: value}

  • "value-name": "CEP_NAME"

"value": " [0-9a-zA-Z_]{64}"

RO

M

  • Provided by tapi-server

layer-protocol-name

List of ["DSR", "ODU", "PHOTONIC_MEDIA"]

RO

M

Provided by tapi-server

supported-layer-protocol-qualifier

List of ["DIGITAL_SIGNAL_TYPE", "ODU_TYPE", "PHOTONIC_LAYER_QUALIFIER”]

RO

M

  • Provided by tapi-server

All children identities defined for ["DIGITAL_SIGNAL_TYPE", "ODU_TYPE",   "PHOTONIC_LAYER_QUALIFIER”] MUST be supported.

administrative-state

["UNLOCKED", "LOCKED"]

RO

M

  • Provided by tapi-server

operational-state

["ENABLED", "DISABLED"]

RO

M

  • Provided by tapi-server

lifecycle-state

["PLANNED", "POTENTIAL_AVAILABLE", "POTENTIAL_BUSY", "INSTALLED", "PENDING_REMOVAL"]

RO

M

  • Provided by tapi-server

termination-state

["LP_CAN_NEVER_TERMINATE", “LT_NOT_TERMINATED”, “TERMINATED_SERVER_TO_CLIENT_FLOW”, “TERMINATED_CLIENT_TO_SERVER_FLOW”, “TERMINATED_BIDIRECTIONAL”, “LT_PERMENANTLY_TERMINATED”, “TERMINATION_STATE_UNKNOWN”]

RO

M

  • Provided by tapi-server

termination-direction

["BIDIRECTIONAL", “SINK”, “SOURCE”]

RO

M

  • Provided by tapi-server

connection-port-direction

["BIDIRECTIONAL","INPUT","OUTPUT"]

RO

M

  • Provided by tapi-server

connection-port-role

["SYMMETRIC"]

RO

M

  • Provided by tapi-server

aggregated-connection-end-point

List of { node-edge-point-ref}

RO

O

  • Provided by tapi-server

parent-node-edge-point

List of { node-edge-point-ref}

RO

M

  • Provided by tapi-server

client-node-edge-point

List of { node-edge-point-ref}

RO

M

  • Provided by tapi-server

tapi-odu:odu-connection-end-point-spec

{odu-connection-end-point-spec}

RO

O

  • Provided by tapi-server
  • MUST augment CEPs at the ODU layer
  • See Table 18

tapi-photonic-media:otsi-connection-end-point-spec

{ otsi-connection-end-point-spec }

RO

O

  • Provided by tapi-server
  • MUST augment CEPs at the PHOTONIC_MEDIA layer with OTSI layer-protocol-qualifier.
  • See Table 19

tapi-photonic-media:media-channel-connection-end-point-spec

{media-channel-connection-end-point-spec}

RO

O

  • Provided by tapi-server
  • MUST augment CEPs at the PHOTONIC_MEDIA layer with MC/OTSiMC layer-protocol-qualifier.
  • See Table 21

tapi-photonic-media:ots-media-channel-connection-end-point-spec

{ots-media-channel-connection-end-point-spec}

 

 

  • Provided by tapi-server
  • MUST augment CEPs at the PHOTONIC_MEDIA layer with layer-protocol-qualifier:LAYER_PROTOCOL_QUALIFIER_UNSPECIFIED
  • See Table 22

 

  Table 18 : ODU-Connection-end-point-spec object definition

odu-connection-end-point-spec

/tapi-common:context/tapi-topology:topology-context/topology/node/owned-node-edge-point/tapi-connectivity:cep-list/connection-end-point/tapi-odu:odu-connection-end-point-spec

Attribute

Allowed Values/Format

Mod

Sup

Notes

odu-common

{ odu-type, odu-rate, odu-rate-tolerance }

  • “odu-type”: [ ODU_TYPE],
  • odu-rate ”: [ 0-9 ]{12},
  • “odu-rate-tolerance”: [ 0-9 ]{12},

 

RO

M

  • Provided by tapi-server
  • All children identities defined for ["ODU_TYPE"] MUST be supported.
  • odu-rate-tolerance Standardized values are defined in Table 7-2/G.709

odu-term-and-adapter

{ opu-tributary-slot-list, auto-payload-type, configured-client-type, configured-mapping-type, accepted-payload-type, named-payload-type, hex-payload-type }

  • opu-tributary-slot-size: ["1G25", "2G5" ]
  • auto-payload-type? boolean
  • configured-client-type: [DIGITAL_SIGNAL_TYPE]
  • configured-mapping-type: ["AMP", "BMP", "GFP-F", "GMP", "TTP_GFP_BMP", "NULL"]
  • accepted-payload-type
    • "named-payload-type": ["UNKNOWN", "UNINTERPRETABLE"]
    • "hex-payload-type": "[0-9]{64}",
  • fec-parameters : { pre-fec-ber, post-fec-ber, corrected-bytes, corrected-bits, uncorrectable-bytes, uncorrectable-bits}
    • " pre-fec-ber" :             "[0-9]{64}",
    • " post-fec-ber" :           "[0-9]{64}",
    • " corrected-bytes" :      "[0-9]{64}",
    • " corrected-bits":       "[0-9]{64}",
    • "un correctable-bytes" :      "[0-9]{64}",
    • "un correctable-bits":       "[0-9]{64}",
  • odu-cn-effective-time-slot: List of "[0-9]{64}"

 

RO

M

  • Provided by tapi-server
  • Configured-client-type accepts any child identities defined for ["DIGITAL_SIGNAL_TYPE"]

odu-ctp

{tributary-slot-list, tributary-port-number, accepted-msi}

  • tributary-slot-list :   List of "[0-9]{64}"
  • tributary-port-number:  "[0-9]{64}"
  • accepted-msi?            string

RO

M

  • Provided by tapi-server

odu-protection

{aps-enable, aps-level}

  • aps-enable :   Boolean
  • aps-level: "[0-9]{64}"

 

 

 

RO

O

  • Provided by tapi-server

 

 

  Table 19 : otsi-connection-end-point-spec object definition

otsi-connection-end-point-spec

/tapi-common:context/tapi-topology:topology-context/topology/node/owned-node-edge-point/tapi-connectivity:cep-list/connection-end-point/tapi-photonic-media:otsi-connection-end-point-spec

Attribute

Allowed Values/Format

Mod

Sup

Notes

otsi-termination

{selected-central-frequency, selected-application-identifier, selected-modulation, selected-spectrum, transmitted-power, received-power, laser-properties}

RO

M

  • Provided by tapi-server

 

selected-central-frequency

{ central-frequency, frequency-constraint: {adjustment-granularity, grid-type} }

  • “central-frequency”: "[0-9]{9}",
  • “adjustment-granularity”:[ “UNCONSTRAINED”, “G_3_125GHZ”, “G_6_25GHZ”, “G_12_5GHZ”, “G_25GHZ”, “G_50GHZ”, “G_100GHZ”,]
  • “grid-type”: [ “GRIDLESS”, “FLEX”, “CWDM”, “DWDM”]

 

RO

M

  • Provided by tapi-server
  • The central-frequency of the laser specified in MHz. It is the oscillation frequency of the corresponding electromagnetic wave.
  • Adjustment-granularity in Gigahertz. As per ITU-T G.694.1, it is used to 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.

selected-application-identifier

{ application-identifier-type, application-code}

  • “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}"

RO

M

  • Provided by tapi-server

selected -modulation

[“RZ“, “NRZ”, “BPSK”, “DPSK”, “QPSK”, “8QAM”, “16QAM”]

 

RO

M

  • Provided by tapi-server

 

selected-spectrum

{lower-frequency, upper-frequency, frequency-constraint: {adjustment-granularity, grid-type} }

  • “upper/lower-frequency”:          "[0-9]{9}",
  • “adjustment-granularity”:[ “UNCONSTRAINED”, “G_3_125GHZ”, “G_6_25GHZ”, “G_12_5GHZ”, “G_25GHZ”, “G_50GHZ”, “G_100GHZ”,]
  • “grid-type”: [ “GRIDLESS”, “FLEX”, “CWDM”, “DWDM”]

 

RO

M

  • Provided by tapi-server
  • The central-frequency of the laser specified in MHz. It is the oscillation frequency of the corresponding electromagnetic wave.
  • Adjustment-granularity in Gigahertz. As per ITU-T G.694.1, it is used to 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.

transmited-power

{total-power, power-spectral-density}

  • “total-power”:" [0-9].[ 0-9 ]{7}",
  • “power-spectral-density”:          " [0-9].[ 0-9 ]{7}",

 

 

RO

M

  • Provided by tapi-server

received-power

{total-power, power-spectral-density}

  • “total-power”:" [0-9].[ 0-9 ]{7}",
  • “power-spectral-density”:          " [0-9].[ 0-9 ]{7}",

RO

M

  • Provided by tapi-server

laser-properties

{laser-status, laser-application-type, 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}",

RO

M

  • Provided by tapi-server

 

Table 20 : OTSI-Assembly-connection-end-point-spec object definition

otsi-assembly-connection-end-point-spec [A11]

/tapi-common:context/tapi-topology:topology-context/topology/node/owned-node-edge-point/tapi-connectivity:cep-list/connection-end-point/tapi-photonic-media:otsi-assembly-connection-end-point-spec

Attribute

Allowed Values/Format

Mod

Sup

Notes

otsi-adapter

“number-of-otsi”: [0-9]{9}

RO

O

  • Provided by tapi-server

 

 

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

media-channel-connection-end-point-spec

/tapi-common:context/tapi-topology:topology-context/topology/node/owned-node-edge-point/tapi-connectivity:cep-list/connection-end-point/tapi-photonic-media:media-channel-connection-end-point-spec

Attribute

Allowed Values/Format

Mod

Sup

Notes

media-channel

{occupied-spectrum, measured-power-ingress, measured-power-egress}

R0

M

Mandatory only for PHOTONIC_LAYER_QUALIFIER_MC layer-protocol-qualified CEPs

occupied-spectrum

{lower-frequency, upper-frequency, frequency-constraint}

  • “upper/lower-frequency”:          "[0-9]{9}",
  • "frequency-constraint": {adjustment-granularity, grid-type}
    • “adjustment-granularity”: [ “UNCONSTRAINED”, “G_3_125GHZ”, “G_6_25GHZ”, “G_12_5GHZ”, “G_25GHZ”, “G_50GHZ”, “G_100GHZ”,]
    • “grid-type”: [ “GRIDLESS”, “FLEX”, “CWDM”, “DWDM”]

 

RO

M

  • Provided by tapi-client
  • The upper/lower-frequency boundaries of the band specified in MHz.
  • Adjustment-granularity in Gigahertz. As per ITU-T G.694.1, it is used to calculate nominal central frequency".

 

  • The grid-type specifies the reference set of frequencies used to denote allowed nominal central frequencies

measured-power-ingress

{total-power, power-spectral-density}

  • “total-power”:" [0-9].[ 0-9 ]{7}",
  • power-spectral-density ”:          " [0-9].[ 0-9 ]{7}",

RO

M

  • Provided by tapi-server

measured-power-egress

{total-power, power-spectral-density}

  • “total-power”:" [0-9].[ 0-9 ]{7}",
  • power-spectral-density ”:          " [0-9].[ 0-9 ]{7}",

RO

M

  • Provided by tapi-server

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

ots-media-channel-connection-end-point-spec

/tapi-common:context/tapi-topology:topology-context/topology/node/owned-node-edge-point/tapi-connectivity:cep-list/connection-end-point/tapi-photonic-media:ots-media-channel-connection-end-point-spec

Attribute

Allowed Values/Format

Mod

Sup

Notes

ots-media-channel

{occupied-spectrum, measured-power-ingress, measured-power-egress}

R0

M

Mandatory only for LAYER_PROTOCOL_QUALIFIER_UNSPECIFIED layer-protocol-qualified CEPs corresponding to OMS-OTS abstraction in the photonic_media layer

occupied-spectrum

{lower-frequency, upper-frequency, frequency-constraint}

  • “upper/lower-frequency”:          "[0-9]{9}",
  • "frequency-constraint": {adjustment-granularity, grid-type}
    • “adjustment-granularity”: [ “UNCONSTRAINED”, “G_3_125GHZ”, “G_6_25GHZ”, “G_12_5GHZ”, “G_25GHZ”, “G_50GHZ”, “G_100GHZ”,]
    • “grid-type”: [ “GRIDLESS”, “FLEX”, “CWDM”, “DWDM”]

 

RO

M

  • Provided by tapi-client
  • The upper/lower-frequency boundaries of the band specified in MHz.
  • Adjustment-granularity in Gigahertz. As per ITU-T G.694.1, it is used to calculate nominal central frequency".

 

  • The grid-type specifies the reference set of frequencies used to denote allowed nominal central frequencies

measured-power-ingress

{total-power, power-spectral-density}

  • “total-power”:" [0-9].[ 0-9 ]{7}",
  • power-spectral-density ”:          " [0-9].[ 0-9 ]{7}",

RO

M

  • Provided by tapi-server

measured-power-egress

{total-power, power-spectral-density}

  • “total-power”:" [0-9].[ 0-9 ]{7}",
  • power-spectral-density ”:          " [0-9].[ 0-9 ]{7}",

RO

M

  • Provided by tapi-server

 

  Table 23 : Route object definition

route

/tapi-common:context/tapi-connectivity:connection/route

Attribute

Allowed Values/Format

Mod

Sup

Notes

local-id

"[0-9a-zA-Z_]{32}"

RO

M

  • Provided by tapi-server

name

List of {value-name: value}

  • "value-name": "ROUTE_NAME"

"value": " [0-9a-zA-Z_]{64}"

RO

M

  • Provided by tapi-server

connection-end-point

List of {"connection-end-point-ref  - /tapi-common:context/tapi-topology:topology-context/topology/node/owned-node-edge-point/tapi-connectivity:cep-list/connection-end-point/uuid "}

RO

M

  • Provided by tapi-server

 

Table 24 : otsia-connectivity-service-end-point-spec object definition

otsia-connectivity-service-end-point-spec

/tapi-common:context/tapi-connectivity:connectivity-service/end-point/ otsia-connectivity-service-end-point-spec

Attribute

Allowed Values/Format

Mod

Sup

Notes

otsi-config

List of {otsi-config [local-id]}

  • otsi-config:{central-frequency, spectrum, application-identifier, modulation, laser-control, transmit-power, total-power-warn-threshold-upper, total-power-warn-threshold-lower, local-id, name}

RW

M

  • Provided by tapi-client

number-of-otsi

[0-9]{9}

RW

M

  • Provided by tapi-client

central-frequency

  • central-frequency: "[0-9]{9}",
  • "frequency-constraint": {adjustment-granularity, grid-type}
    • “adjustment-granularity”: [ “UNCONSTRAINED”, “G_3_125GHZ”, “G_6_25GHZ”, “G_12_5GHZ”, “G_25GHZ”, “G_50GHZ”, “G_100GHZ”,]
    • “grid-type”: [ “GRIDLESS”, “FLEX”, “CWDM”, “DWDM”]

 

 

RW

M

  • Provided by tapi-client
  • The central-frequency of the laser specified in MHz. It is the oscillation frequency of the corresponding electromagnetic wave.
  • Adjustment-granularity in Gigahertz. As per ITU-T G.694.1, it is used to calculate nominal central frequency".

 

  • The grid-type specifies the reference set of frequencies used to denote allowed nominal central frequencies

spectrum

{lower-frequency, upper-frequency, frequency-constraint}

  • “upper/lower-frequency”:          "[0-9]{9}",
  • "frequency-constraint": {adjustment-granularity, grid-type}
    • “adjustment-granularity”: [ “UNCONSTRAINED”, “G_3_125GHZ”, “G_6_25GHZ”, “G_12_5GHZ”, “G_25GHZ”, “G_50GHZ”, “G_100GHZ”,]
    • “grid-type”: [ “GRIDLESS”, “FLEX”, “CWDM”, “DWDM”]

 

RW

M

  • Provided by tapi-client
  • The upper/lower-frequency boundaries of the band specified in MHz.
  • Adjustment-granularity in Gigahertz. As per ITU-T G.694.1, it is used to calculate nominal central frequency".

 

  • The grid-type specifies the reference set of frequencies used to denote allowed nominal central frequencies

application-identifier

{application-identifier-type, application-code}

  • “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}"

RW

M

  • Provided by tapi-client

modulation

[“RZ“, “NRZ”, “BPSK”, “DPSK”, “QPSK”, “8QAM”, “16QAM”]

 

RW

M

  • Provided by tapi-client

transmit-power

{total-power, power-spectral-density}

  • “total-power”:" [0-9].[ 0-9 ]{7}",
  • “power-spectral-density”:          " [0-9].[ 0-9 ]{7}",

 

 

RW

M

  • Provided by tapi-client

laser-control

[FORCED-ON, FORCED-OFF, AUTOMATIC-LASER-SHUTDOWN, UNDEFINED]

RW

O

  • Provided by tapi-client

total-power-warn-threshold-upper

[0-9].[ 0-9 ]{7}

RW

M

  • Provided by tapi-client

total-power-warn-threshold-lower

[0-9].[ 0-9 ]{7}

RW

M

  • Provided by tapi-client

local-id

"[0-9a-zA-Z_]{32}"

RW

M

  • Provided by tapi-client

name

List of {value-name: value}

  • "value-name": "OTSI_CONN_NAME"

"value": " [0-9a-zA-Z_]{64}"

RW

M

  • Provided by tapi-server

 

Table 25 : mca-connectivity-service-end-point-spec object definition

mca-connectivity-service-end-point-spec

/tapi-common:context/tapi-connectivity:connectivity-service/end-point/ mca-connectivity-service-end-point-spec

Attribute

Allowed Values/Format

Mod

Sup

Notes

number-of-mc

[0-9]{9}

RW

M

  • Provided by tapi-client

capacity

{value:  unit}

  •     "value": "[0-9]{8}",
  • "unit": ["TB", "TBPS", "GB", "GBPS", "MB", "MBPS", "KB", "KBPS"]

RW

M

  • Provided by tapi-client

mc-config

List of {otsi-config [local-id]}

  • otsi-config:{spectrum, power-management-config-pac }

 

RW

M

  • Provided by tapi-client

spectrum

{lower-frequency, upper-frequency, frequency-constraint}

  • “upper/lower-frequency”:          "[0-9]{9}",
  • "frequency-constraint": {adjustment-granularity, grid-type}
    • “adjustment-granularity”: [ “UNCONSTRAINED”, “G_3_125GHZ”, “G_6_25GHZ”, “G_12_5GHZ”, “G_25GHZ”, “G_50GHZ”, “G_100GHZ”,]
    • “grid-type”: [ “GRIDLESS”, “FLEX”, “CWDM”, “DWDM”]

 

RW

M

  • Provided by tapi-client
  • The upper/lower-frequency boundaries of the band specified in MHz.
  • Adjustment-granularity in Gigahertz. As per ITU-T G.694.1, it is used to calculate nominal central frequency".

 

  • The grid-type specifies the reference set of frequencies used to denote allowed nominal central frequencies

power-management-config-pac

{intended-maximum-output-power, intended-minimum-output-power, expected-maximum-input-power, expected-minimum-input-power}

  • "intended-maximum-output-power":{total-power, power-spectral-density}
    • "Total-power":" [0-9].[ 0-9 ]{64}",
    • "power-spectral-density":" [0-9].[ 0-9 ]{64}"
  • "intended-minimum-output-power":{total-power, power-spectral-density}
    • "Total-power":" [0-9].[ 0-9 ]{64}",
    • "power-spectral-density":" [0-9].[ 0-9 ]{64}"
  • "expected-maximum-output-power":{total-power, power-spectral-density}
    • "Total-power":" [0-9].[ 0-9 ]{64}",
    • "power-spectral-density":" [0-9].[ 0-9 ]{64}"
  • "expected-minimum-output-power":{total-power, power-spectral-density}
    • "Total-power":" [0-9].[ 0-9 ]{64}",
    • "power-spectral-density":"[0-9].[0-9]{64}"

RW

M

  • Provided by tapi-client

local-id

"[0-9a-zA-Z_]{32}"

RW

M

Provided by tapi-client

name

List of {value-name: value}

  • "value-name": "OTSI_CONN_NAME"

"value": " [0-9a-zA-Z_]{64}"

RW

M

Provided by tapi-server

 

 

 

6.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 5.1.1

To show some detailed TAPI connectivity examples, first a simple legend of icons and basic arrangement is included in Figure 6-7 .

Figure 6 - 7 TAPI Logical Termination Point Template – Basic Arrangements.

6.2.1.2.1     UC1a - Example 1: 10GE client signal over ODU2 over ODU4 (DSR-ODU Fixed Mapping, flexible ODU allocation)

The following diagrams illustrate a possible sequence of generation of the required TAPI topology and connectivity objects and its relationships according to the rules described in section 5.1.1 . However, the internal TAPI server workflow MAY vary and, if notification or streaming services are available, the sequence of asynchronous notifications received by the TAPI client MAY be different.

Thus, the objective of this and the subsequent examples detailing the use cases is to illustrate the object composition and most importantly to define the expected result after a connectivity-service provisioning.

Please note, that in the following examples (all included examples in Section 6 ), a modelling simplification (represented by blue square) of the client interface (UNI) has been introduced. For the current version of the RIA, the modelling of the UNI client facing side interfaces is not yet covered in detail, so the actual implementation decisions are left to the vendor according to each individual HW capabilities. Thus, please consider the following examples as a guideline of representation the connectivity modelling of the network facing side (e.g., the representation of how the multiplexing of DSR signals over ODU over OTSi shall be modelled). In the following figure we include the general assumed UNI simplifications represented in the examples included in this version of the RIA.

The following figure represents different assumptions done in the UNI representation.

  • Option 1: Assumes there is not flexibility at the DSR layer but the fixed cross-connection (at DSR layer) are explicitly represented.
  • Option 2: Assumes there is not flexibility at the DSR layer and the fixed cross-connection (at DSR layer) are not explicitly represented.
  • Option 3: Assumes there is flexibility at the DSR layer.

 

Captura de pantalla de un celular

Descripción generada automáticamente

Figure 6 - 8 UNI Modelling simplifications

Please note, that the following versions of the RIA will address the UNI representation in detail so the previous simplifications may not be longer valid.

 

Figure 6 - 9 Connectivity Service 10GE client signal over ODU2 (DSR-ODU Fixed Mapping) over ODU4 over single OTSi – Transitional Link modelling

Figure 6 - 10 Connectivity Service 10GE client signal over ODU2 (DSR-ODU Fixed Mapping) over ODU4 over single OTSi – Multi-layer node modelling.

6.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 6 - 11 Connectivity Service 1GE client signal over ODU0 over ODU2 over ODU4 (Fixed DSR-ODU mapping, flexible ODU allocation)

 

6.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.