Child pages
  • TAPI Contributions and Presentations

 

 

cid:image003.png@01D47AB3.2CCAF460

 

 

 

 

 

 

 

 

 

 

 


ONF Document Type: Technical Recommendation

ONF Document Name: Core Information Model version 1.4
 

Disclaimer

THIS SPECIFICATION IS PROVIDED "AS IS" WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION OR SAMPLE.

Any marks and brands contained herein are the property of their respective owners.

 

Open Networking Foundation
1000 El Camino Real, Suite 100, Menlo Park, CA 94025
www.opennetworking.org

©2018 Open Networking Foundation. All rights reserved.

 

Open Networking Foundation, the ONF symbol, and OpenFlow are registered trademarks of the Open Networking Foundation, in the United States and/or in other countries. All other brands, products, or service names are or may be trademarks or service marks of, and are used to identify, products or services of their respective owners.   

 

Important note

This Technical Recommendations has been approved by the Project TST, but has not been approved by the ONF board.   This Technical Recommendation is a new reference implementation document focus on v2.1.2 models, which has been approved under the ONF publishing guidelines for 'Informational' publications that allow Project technical steering teams (TSTs) to authorize publication of Informational documents.   The designation of '-info' at the end of the document ID also reflects that the project team (not the ONF board) approved this TR.

 


Table of Contents

Disclaimer

Important note

Document History

1 Introduction

1.1 General introduction to the model

1.2 Introduction to this document

2 Model Overview

3 RESTCONF/YANG Protocol considerations

3.1 Root tree discovery

3.2 YANG models discovery

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

3.4 Query filtering

3.5 Data encoding

3.5.1 Namespaces

3.6 Notifications

3.6.1 SSE vs Websockets

4 ONF Transport – API (TAPI) considerations

4.1 TAPI SDK version and documentation

4.2 TAPI Information model

4.2.1 Context

4.2.2 Node and Topology Aspects of Forwarding Domain

4.2.2.1 Topology

4.2.2.2 Node

4.2.2.3 Link

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

4.2.3.1 Node-Edge-Point (NEP)

4.2.3.2 Service-Interface-Point (SIP)

4.2.3.3 Connection-End-Point (CEP)

4.2.4 Service, Connection and Route

4.2.4.1 Connectivity-Service (CS)

4.2.4.2 Connection

4.2.4.3 Route

4.2.4.4 Path

4.3 TAPI Data API

4.4 TAPI Notifications

5 Topology abstraction model

5.1 Model guidelines

5.2 Inventory considerations

5.3 Network scenarios

5.3.1 Scenario 1: ROADM network equipped with OTN matrices

5.3.1.1 Model representation

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

5.3.2.1 Model representation

6 Connectivity service model

6.1 Model guidelines

6.1.1 Multi-layer connectivity service provisioning and connection generation

6.1.1.1 Option A: Top most layer top-connection modelling with inter-layer referencing

6.1.1.2 Option B: Per layer top-connection modelling without inter-layer referencing

6.1.2 Resiliency mechanism at connectivity service

6.1.3 Topology and service constrains for connectivity services

7 Use cases Low Level designs (LLDs)

7.1 Use case 0: Topology and services discovery

7.1.1 Use Case 0a: Context & Service Interface Points discovery (synchronous mode)

7.1.1.1 Required parameters

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

7.1.2.1 Required parameters

7.2 Use case 1: Unconstrained E2E Service Provisioning

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

7.2.1.1 Required parameters

7.2.1.2 Expected results

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

7.2.2.1 Expected results

7.2.3 Use case 1c: Unconstrained ODU Service Provisioning

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

7.2.4.1 Expected results

7.2.5 Use case 1e: Unconstrained PHOTONIC_MEDIA/ OTSiA/OTSiG Service Provisioning

7.2.5.1 Expected results

7.3 Use case 3: Constrained Provisioning

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

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

7.3.3 Use case 3c: Include/exclude the path used by other service.

7.3.3.1 Required parameters

7.4 Use case 5: Use case 5:  1+1 protection with diverse service Provisioning

7.4.1 Use case 5a: 1+1 OLP Client Protection with Diverse Service Provisioning

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

7.4.2.1 Expected result

7.4.2.2 Required parameters

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

7.4.3.1 Expected result

7.4.3.2 Required parameters

7.5 Use case 6: Restoration policies for unconstrained and constrained connectivity services

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

7.5.1.1 Required parameters

7.6 Use case 7: Restoration and protection schemas.

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

7.6.1.1 Required parameters

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

8 References

9 Definitions

9.1 Terms defined elsewhere

9.2 Terms defined in this TR

9.3 Abbreviations and acronyms

9.4 This TR uses the following abbreviations and acronyms (Note that some cross references are included here rather than in the Summary of main changes between version 1.3.1 and 1.4

10 Conventions

10.1 Lifecycle Stereotypes

10.2 Key to diagram symbol set

11 Future CoreModel work areas

12 Terminology Translation table

13 Documentation structure

14 Individuals engaged

14.1 Editors

14.2 Contributors

List of Figures

Figure 2-1 Target OSS – SDN architecture for WDM

Figure 4-1 Transport API Functional Architecture

Figure 4-2 TAPI Mapping from ITU-T.

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

Figure 5-2 NS-1.T0: TAPI Topology Flat Abstraction model.

Figure 5-3 NS-1.T0: TAPI Topology Flat Abstraction view comparison with Layered view.

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

Figure 5-5 NS-2.T0: TAPI Topology Flat Abstraction model.

Figure 5-6 NS-2.T0: TAPI Topology Flat Abstraction model comparison with Layered model.

Figure 7-1 UC-0a: Service Interface Point - LLD Workflow.

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

Figure 7-3 UC-1: Unconstrained end-to-end service provisioning.

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

Figure 7-5 Connectivity Service 10GE client signal over ODU2 (DSR-ODU Fixed Mapping) – Step1

Figure 7-6 Connectivity Service 10GE client signal over ODU2 (DSR-ODU Fixed Mapping) – Step2 (ODU4 Top Connection creation)

Figure 7-7 Connectivity Service 10GE client signal over ODU2 (DSR-ODU Fixed Mapping) – Step3 (ODU2 over ODU4 Top Connection cross-connection)

Figure 7-8 Connectivity Service 10GE client signal over ODU2 (DSR-ODU Fixed Mapping) – Step4 (ODU4 over OTSi).

Figure 7-9 Connectivity Service 10GE client signal over ODU2 (DSR-ODU Fixed Mapping) – Step5 (ODU 4 over OTSi over NMC).

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

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

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

Figure 7-13 200GE DSR Service Provisioning over multi wavelength OTSiA (beyond 100G).

Figure 7-14 OTSi single lambda connecitiy-service.

Figure 7-15 OTSiA/OTSiG multi-wavelength connectivity-service.

Figure 7-16 UC-5b OLP protection schemas.

Figure 7-17 UC-5b OLP TAPI Connectivity-Service low-level description.

Figure 7-18 UC-5c eSNCP protection schema.

Figure 7-19 UC5c: Connectivity Service 100GE client signal over ODU4 with Line Side eSNCP Protection

Figure 7-20 UC-10: Service Deletion workflow.

Figure 10-1 Network diagram symbol set

Figure 6-2 Additional media diagram symbol set

Document History

Version

Date

Description of Change

0.1

August 06, 2019

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


1        Introduction

1.1      General introduction to the model

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

1.2      Introduction to this document

This document acts as a guide t

 

2        Model Overview

The purpose of this document is to describe a set of guidelines and recommendations for a standard use of the TAPI models in combination with RESTCONF protocol for the implementation of the interface between network systems in charge of the control/management of networks based on WDM/OTN technologies.

The target architectures, for which this reference interface is proposed, it is conceptually described in Figure 1 . As depicted in the architecture, this reference NBI will be the single interface between Operations Support Systems (OSS) and the different SDN-Cs. The scope includes multiple domains within the same network, where each domain SDN-C will export its TAPI context, which will be consumed by the OSS or other applications directly or through and intermediate multi-domain orchestrator (SDTN controller) which will expose an unified view.

Thus, this NBI specification will be used between a SDN-C and an SDTN Controller/OSS where the SDN-C provides a view via a context to the SDTN Controller/OSS and the SDTN Controller/OSS maintains that view in a database (probably transformed into a local model).

This document aims to define the base requirements of the management plane, implemented through a standard interface over the SDN-C, to cover any use case for activation/configuration, service provisioning, path-computation and monitoring of the WDM/OTN network.

The term “management” shall express that the scope is much wider than just configuring. The proposed common interface shall account for:

  • Configuration, e.g. for automating and optimizing the network services creation and processes.
  • Status, e.g. for automated configuration depending on current network status.
  • Events (Alarms), e.g. for automated initiation of countermeasures.
  • Current and Historical Performance Values, e.g. for perpetual network analysis.

This specification is supported by standards, protocol specifications, IETF RFCs, ITU-T recommendations and the ONF Transport API (TAPI) documentation. The appropriate references to this supplementary material are included where appropriate along the document to support the statements which conforms this specification. However, this document does not intends to re-define the protocols or information models composing the specification but to complement, clarify or extends in those cases where a corner case or different interpretations have been found along the mentioned standards.

 

Figure 2- 1 Target OSS – SDN architecture for WDM

3        RESTCONF/YANG Protocol considerations

RESTCONF [RFC 8040] is proposed as the transport protocol for all the defined management operations in the SDN architecture NBIs.

RESTCONF is a HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG 1.0 [RFC 6020] using the data store concepts defined in the Network Configuration Protocol (NETCONF) [RFC 6241].

The RESTCONF specification consists of the following resources:

  • {+restconf}/data (Data API): Create/Retrieve/Update/Delete (CRUD) based API for the entire data tree defined in the TAPI information model YANG files (see section 4 ).
  • {+restconf}/operations (Operations API): RPC based API consisting on a small set of operations defined as RPCs in the TAPI information model YANG files.
  • {+restconf}/data/ietf-restconf-monitoring:restconf-state/streams (Notifications API): Notifications implementation of RESTCONF protocol is defined in https://tools.ietf.org/html/rfc8040#section-6.3 .
  • {+restconf}/yang-library-version: This mandatory leaf identifies the revision date of the "ietf-yang-library" YANG module that is implemented by this server.

 

3.1      Root tree discovery

The RESTCONF API {+restconf} root resource can be discovered by getting the "/.well-known/host-meta" resource ([RFC 6415]) and using the <Link> element containing the "restconf" attribute.

The client might send the following:

GET /.well-known/host-meta HTTP/1.1

Host: example.com

Accept: application/xrd+xml

 

The server might respond as follows:

HTTP/1.1 200 OK

Content-Type: application/xrd+xml

Content-Length: nnn

 

<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>

<Link rel='restconf' href='/restconf'/>

</XRD>

3.2      YANG models discovery

RESTCONF utilizes the YANG library [RFC 7895] and [RFC 8525] to allow a client to discover the YANG module conformance information for the server, in case the client wants to use it.

The mandatory {+restconf}/yang-library-version resource is used to clearly identify the version of the YANG library used by the server.

The server MUST implement the " ietf-yang-library " module, which MUST identify all of the YANG modules used by the server, within the "modules-state/module" list resource. 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/module
  • According to [RFC 8525]: {+restconf}/data/ietf-yang-library : yang-library

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

Currently there are two allowed APIs resources defined in RESTCONF. Although both are compatible and valid, the recent discussions in TAPI suggest that in future releases RPCs flavored implementations will be discontinued.

Thus, the current specification states that the support of the RESTCONF Data API is mandatory; while the Operations API, based on the TAPI defined RPCs, is considered optional.

3.4      Query filtering

According to RESTCONF specification, each operation allows zero or more query parameters to be   present in the request URI. Specifically, query operations’ parameters are described in Section 4.8 of [RFC 8040] . Thus, the following query parameters MUST be supported by any interface compliant with this specification:

Table 1 : RESTCONF Query filters

Name         

Methods

Description                            

content      

GET,   

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

The "depth", “fields”, “filter”, “replay” and “with-defauts” query parameter URIs SHALL be listed in the "capability" leaf-list as part of the container definition in the "ietf-restconf-monitoring" module, defined in Section 9.3 of [RFC 8040] ,  to advertise the server capability of supporting these query parameters. This resource shall be located at:

  • {+restconf}/data/ietf-restconf-monitoring:restconf-state/capabilties

 

3.5      Data encoding

JSON encoding formats MUST be supported according to with Section 3.2 of [RFC 8040] .

The solution adhering to this specification MUST support media type "application/yang-data+json" as defined in [RFC 7951] . This MUST be advertised in the HTTP Header fields “Accept” or “Content-Type” of the corresponding HTTP Request/Response messages.

3.5.1       Namespaces

According to Section 1.1.5 of [RFC 8040] , " The JSON representation is defined in "JSON Encoding of Data Modeled with YANG" [RFC7951] and supported with the "application/yang-data+json" media type".

Thus, any implementation according to this specification MUST be compliant with the rules and definitions included in [RFC 7951] , specifically those related to namespaces qualification included in Section 4 of [RFC 7951] .

3.6      Notifications

The solution adhering to this specification must support all YANG-defined event notifications included in the information models included in section 4.2 of this document.

The solution implementing the RESTCONF server must expose its supported notification streams by populating the "restconf-state/streams" container definition in the "ietf-restconf-monitoring" module defined in Section 9.3 of [RFC 8040] . The streams resource can be found at:

  • {+restconf}/data/ietf-restconf-monitoring:restconf-state/streams

The RESTCONF server MUST support at least the NETCONF event stream as defined in Section 3.2.3 of [RFC5277] with both JSON encoding format being supported and advertised as two different location resources as described in Section 6.2 of [RFC 8040] .

The RESTCONF server MUST support the RESTCONF Notifications subscription mechanism is defined in Section 6.3 of [RFC 8040] .

The solution must support the “filter” Query Parameter, as defined in Section 4.8.4 of [RFC 8040] , to indicate the target subset of the possible events being advertised by the RESTCONF server stream.

3.6.1       SSE vs Websockets

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

4        ONF Transport – API (TAPI) considerations

4.1      TAPI SDK version and documentation

The ONF Transport API (T-API/TAPI) project is constantly evolving and new releases of the information models are periodically updated. The TAPI 2.1.1 Release, publicly available since 10-12-2018, is the version required in the present version of this document .

As per informational purposes, we include here the TAPI SDK release notes ( https://github.com/OpenNetworkingFoundation/TAPI ):

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

The TAPI yang models can be found at https://github.com/OpenNetworkingFoundation/TAPI/tree/v2.1.1/YANG

TAPI YANG Schema is considered as the primary reference for TAPI information models documentation and thus, any discussion or query about the model should reference the YANG as the reference point for discussion.

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

The TAPI OAS specifications can be found at https://github.com/OpenNetworkingFoundation/TAPI/tree/v2.1.1/OAS

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

4.2      TAPI Information model

First attempt of defining the TAPI requirement and concepts was summarized in the [ONF TR-527] ONF document. Here we have observed this document as a reference for high-level description of TAPI concepts, but the information has been updated to the current object naming and definition, which in some cases has evolved during the last years. Thus, the [ONF TR-527] is considered obsolete and not sufficient to be single source of documentation for the TAPI information model version which is proposed within this NBI specification.

The Transport API abstracts a common set of control plane functions such   as   Network   Topology, Connectivity   Requests,   Path   Computation, OAM and Network Virtualization to a set of Service interfaces. It also includes support for the following technology-specific interface profiles for Carrier Ethernet (L2), Optical Transport Network (OTN) framework (L1-ODU) and Photonic Media (L0-WDM).

Figure 4 - 1 Transport API Functional Architecture

The tapi-common@2018-12-10.yang model includes the “context” container which serves as the root tree for all the rest of TAPI services which augment this module on top of the context container.

This release supports technology-agnostic interfaces to the following functional modules:

       Topology Service – tapi-topology@2018-12-10.yang

       Connectivity Service – tapi-connectivity@2018-12-10.yang

       OAM Service – tapi-oam@2018-12-10.yang

       Path Computation Service – tapi-path-computation@2018-12-10.yang

       Virtual Network Service – tapi-virtual-network@2018-12-10.yang

       Notification Service – tapi-notification@2018-12-10.yang

It also includes support for the following technology-specific interface profiles:

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

       DSR - tapi-dsr@18-10-16.yang

       Optical Transport Network (L1-ODU) – tapi-odu@2018-12-10.yang

       Photonic Media (L0-WDM) – tapi-photonic-media@2018-12-10.yang

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

Table 2 : TAPI YANG models summary.

Model

Version

Revision (dd/mm/yyyy)

tapi-common.yang

2.1.2

10/12/2018

tapi-connectivity.yang

2.1.2

10/12/2018

tapi-eth.yang

2.1.2

10/12/2018

tapi-dsr.yang

2.1.2

10/12/2018

tapi-notification.yang

2.1.2

10/12/2018

tapi-oam.yang

2.1.2

10/12/2018

tapi-odu.yang

2.1.2

10/12/2018

tapi-photonic-media.yang

2.1.2

10/12/2018

tapi-path-computation.yang

2.1.2

10/12/2018

tapi-topology.yang

2.1.2

10/12/2018

tapi-virtual-network.yang

2.1.2

10/12/2018

Last but not lease, TAPI models are pruned/refactored from the ONF Core Information Model (Core IM) 1.44 [ONF TR-512], thus some of the Core IM model concepts are key to understand the TAPI semantics and meanings. In this section, we introduce some associations to ONF Core IM concepts, for more a full explanation of these concepts please refer to [ONF TR-512] document.

In the rest of this section it is included a brief overview of the main TAPI concepts which will be used along the rest of the document.

4.2.1       Context

T-API is based on a context relationship between a server (SDN Controller) and client (SDN Application). A Context is an abstraction that allows for logical isolation and   grouping   of   network   resource   abstractions   for   specific   purposes/applications   and/or information exchange with its users/clients over an interface.

It is understood that the APIs are executed within a shared Context between the API provider and its client application.  A  shared Context  models  everything  that  exists  in  an  API  provider  to support a given API client.

For the role of the WDM/OTN SDN Domain Controller as defined in [GCTIO-SDN-Strategy], a single context MUST be exposed , including the following information:

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

4.2.2       Node and Topology Aspects of Forwarding Domain

The Forwarding-Domain described in the ONF Core IM, represents the opportunity to enable forwarding between its edge-points. The Forwarding-Domain can hold zero or more instances of Forwarding Constructs (or Connections) and provides the context for requesting and instructing the formation, adjustment and removal of Connections.

The Forwarding-Domain supports a recursive aggregation relationship such that the internal construction of a Forwarding-Domain can be exposed as multiple lower level Forwarding-Domains and associated Links (partitioning).

For the purposes of API requirements, the Forwarding-Domain has been refactored as two separate entities:

4.2.2.1    Topology

The T-API Topology is an abstract representation of the topological-aspects of a particular set of Network Resources. It is described in terms of the underlying topological network of Nodes and Links that enable the forwarding capabilities of that particular set of Network Resources.

4.2.2.2    Node

The T-API Node is an abstract representation of the forwarding-capabilities of a particular set of Network Resources. It is described in terms of the aggregation of set of ports (Node-Edge-Point) belonging to those Network Resources and the potential to enable forwarding of information between those edge ports.

4.2.2.3    Link

The T-API Link is an abstract representation of the effective adjacency between two or more associated Nodes in a Topology. It is terminated by Node-Edge-Points of the associated Nodes.

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

The TAPI Logical-Termination-Point (LTP) – is realized by three different constructs: Node-Edge-Point (NEP), Connection-End-Point (CEP) and Connectivity Service-End-Point (CSEP); they are by design, intended to be a generic, flexible modeling constructs, that can model:

  • Different technology layers
  • Different network configurations
  • Different vendor equipment capabilities

So as such, the inherent flexibility, while preserving the underlying pattern, could lead to different model arrangements for same functional configuration.

The Logical-Termination-Point (LTP) described in the ONF Core IM, represents encapsulation of the addressing, mapping, termination, adaptation and OAM functions of one or more transport layers (including circuit and packet forms). Where the client – server relationship is fixed 1:1 and immutable, the different layers can be encapsulated in a single LTP instance. Where there is a n:1 relationship between client and server, the layers are split over separate instances of LTP.

Functions that can be associated/disassociated to/from an Connection, such as OAM, protection switching, and performance monitoring are referenced as secondary entities through the associated LTP instance.

Following an illustrative mapping between ITU-T G.800/805 and TAPI constructs is described.

Figure 4 - 2 TAPI Mapping from ITU-T.

 

4.2.3.1    Node-Edge-Point (NEP)

The Node-Edge-Point represents the inward network-facing aspects of the edge-port functions that access the forwarding capabilities provided by the Node. Hence it provides an encapsulation of addressing, mapping, termination, adaptation and OAM functions of one or more transport layers (including circuit and packet forms) performed at the entry and exit points of the Node. The Node-Edge-Points have a specific role and directionality with respect to a specific Link.

4.2.3.2    Service-Interface-Point (SIP)

The TAPI Service-Interface-Point represents the outward customer-facing aspects of the edge-port functions that access the forwarding capabilities provided by the Node. Hence it provides a limited, simplified view of interest to external clients (e.g. shared addressing, capacity, resource availability, etc.), that enable the clients to request connectivity without the need to understand the provider network internals. Service-Interface-Point have a mapping relationship (one-to-one, one-to-many, many-to-many) to Node-Edge-Points.

4.2.3.3    Connection-End-Point (CEP)

The Connection-End-Point represents the ingress/egress port aspects that access the forwarding function provided by the Connection. The Connection-End-Points have a client-server relationship with the Node-Edge-Points. The Connection-End-Points have a specific role and directionality with respect to a specific Connection.

4.2.4       Service, Connection and Route

4.2.4.1    Connectivity-Service (CS)

The T-API Connectivity-Service represents an “intent-like” request for connectivity, between two or more Service-Interface-Points exposed by the Context. As such, Connectivity-Service is a container for connectivity request details and is distinct from the Connection that realizes the request. The requestor of the Connectivity-Service is expected to be able to express their intent using just an “external” Node view of Forwarding-Domain and the advertised Service-Interface-Points and not require knowledge of the “internal” Topology details of the Forwarding-Domain.

4.2.4.2    Connection

The T-API Connection represents an enabled (provisioned) potential for forwarding (including all circuit and packet forms) between two or more Node-Edge-Points (another realization of LTP described in the ONF Core IM) from the Node aspect of the Forwarding-Domain. A Connection is typically described utilizing the “internal” Topology view of Forwarding-Domain. The T-API Connection is terminated by Connection-End-Points which are clients of the associated Node-Edge-Points. As such, the Connection is a container for provisioned connectivity that tracks the state of the allocated resources and is distinct from the Connectivity-Service request.

In this specification we distinguish two different types of connections:

  • Cross-Connections – defined as a connection between Connection-End-Points within a Forwarding-Domain (TAPI Node).
  • Top Connections – are defined as end-to-end connections between Connection-End-Points within the same layer which may belong to different Forwarding-Domains (TAPI Nodes). They can be either terminated (“infrastructure trails”) or non-terminated (connecting client signals). These connections MUST contain a Route (Connection Route) object, including all the Connection-End-Points traversed which belong to the same layer of the Top Connection. The general rules that applies to the creation of Top Connections are introduced in Section 6.1

4.2.4.3    Route

The TAPI Route represents the route of a Top Connection through the Topology representation. It is described as a list of Connection End-Points (CEPs) cross-connected by the underlying Lower-Connections referenced in the lower-connection list of the Top Connection [1] .

4.2.4.4    Path

The TAPI Path is used to represent the output of path computation APIs and is described by an ordered list of TE Links, either as strict hops (Node-Edge-Points) or as loose hops (Nodes).

4.3      TAPI Data API

As it was described in section 3.3 the TAPI information models can be divided into: Data API and Operations API. In this first specification, only the Data API be supported and the Operations API is considered as optional and its support will be considered as a plus cause it can give for flexibility to the TAPI Client applications in order to implement the use cases proposed in this document.

Therefore, the list of Data API entries inferred from the TAPI YANG information models, following a RESTCONF API implementation according to the guidelines included in section 3 , contains a huge list of entries which MAY not be needed to implement the use cases proposed, and thus not all entries are considered mandatory in this version of the NBI requirements. This API entries support different REST operations namely, CREATE, RETRIEVE, UPDATE and DELETE (i.e., CRUD). For further clarification of its implementation according to the RESTCONF standard please see Section 4, RFC 8040 .

Thus, for the first version of this specification, it is proposed a minimal set of objects which shall support full CRUD support according to the TAPI YANG models specification (e.g., configurable objects should support all operations while non configurable objects shall support only the RETRIEVE operation). Please note that although the list of API entries is reduced here, the whole model MUST be supported, e.g., all child resources of the proposed list of objects need to be configurable.

The complete mandatory operation set of TAPI objects required here can be found in Table 2 .

Table 3 : Minimum subset required of TAPI RESTCONF Data API.

API Entry

RESTCONF Operations allowed

/tapi-common:context/

GET, POST, PUT, DELETE, PATCH

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

POST, PATCH

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

GET, PUT, DELETE, PATCH

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

GET, POST, PUT, DELETE, PATCH

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

GET

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

POST, PATCH

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

POST, PATCH

/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, POST, PUT, DELETE, PATCH

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

POST, PATCH

/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 and, in later versions of this specification, any valid API entry within the model can be requested.

4.4      TAPI Notifications

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

Although the notification format is key for homogeneous event processing, the notification service and subscription mechanism proposed by TAPI overlaps with the standard mechanism defined by the RESTCONF standard. The standard RESTCONF notification subscription mechanism has been already defined in Section 3.6

However, due to its proven usefulness by the defined RPC create-notification-subscription-service, its usage is considered a valid procedure for this first version of the current specification. An enhancement of the current model version to allow the notification subscription mechanism through the Data API is has been already proposed.


5        Topology abstraction model

In this chapter a complete reference topology abstraction model is described. Due to the need of composing a unified view of the network resources along different T-API implementations, some guidelines are required in order to constrain the possibilities or interpretations of the current proposed models.

The topology model should provide the explicit multi-layer topology representation of the L2-L0 network including OTS, OMS, NMC, NMCA, OTSi, OTSiA, ODU, DSR layers.

Based on ONF TAPI 2.1 models, a topology abstraction view are required for vendor agnostic integration on across management/control systems in the frame of the proposed architecture in Section 2 : TAPI Topology Flat Abstraction model which collapses all layers in a single multi-layer topology (#0).

5.1      Model guidelines

In order to properly describe the first topology abstraction model proposed, the following global guidelines are presented:

[TAPI-TOP-MODEL-REQ-1]                        The network logical abstraction collapses all network layers (DSR, ODU, OTSi/OTSiA and Photonic Media (Media Channels, OMS, OTS)) which are represented explicitelly into a single topology (T0 – Multi-layer topology), modelled as a tapi-topology:topology object within the tapi-topology:topology-context/tapi-topology:nw-topology-service and tapi-topology:topology-context/topology.

[TAPI-TOP-MODEL-REQ-2]                        The T0 – Multi-layer topology abstraction MUST be presented as a tapi-topology:topology object within the tapi-topology:topology-context/topology and referenced at tapi-topology:topology-context/tapi-topology:nw-topology-service, together with the rest of topologies described in the previous section.

module: tapi-topology

  augment /tapi-common:context:

    +--rw topology-context

       +--ro nw-topology-service

       |  +--ro topology* [topology-uuid]

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

       |  +--ro uuid?       uuid

       |  +--ro name* [value-name]

       |  |  +--ro value-name    string

       |  |  +--ro value?        string

+--ro topology* [uuid]

 

[TAPI-TOP-MODEL-REQ-3]                        The Service Interface Points (SIPs) are employed to represent the available service entry points. There MUST be SIPs associated to all DSR, ODU and PHOTONIC_MEDIA node-edge-points (NEPs) in the network which support service configuration (only restrictions imposed by hardware constrains should constrain this list, e.g., transponders with fixed DSR-ODU mapping).

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

  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:

DSR/ODU Layers: represents the DSR/ODU layers explicit nodes.

[TAPI-TOP-MODEL-REQ-5]                        ODU/DSR forwarding domains represented as multi-layer and multi-rate tapi-topology:node , allowing the representation of the internal mapping between DSR and ODU NEPs (multi-layer) and the multiplexing/de-multiplexing across different ODU rates (multi-rate) . ODU-OTSi transitions MUST be represented as transitional links.

[TAPI-TOP-MODEL-REQ-6]                        The ODU/DSR layer network MUST be represented explicitly at the lowest partitioning level, i.e., each ODU/DSR forwarding domain MUST be represented as a single tapi-topology:node. The following network components included within the category of ODU forwarding domain are:

  • Transponders.
  • Muxponders.
  • OTN switching nodes connecting client and line boards.

[TAPI-TOP-MODEL-REQ-7]                        The NEPs layer qualifications allowed for these layer nodes are:

  • layer-protocol-name=DSR, ODU
  • supported-cep-layer-protocol-qualifier = [DIGITAL_SIGNAL_TYPE, ODU_TYPE]

[TAPI-TOP-MODEL-REQ-8]                        Internal ODU multiplexing SHALL be modelled as NEP pools indicating the total capacity rate provided by the pool and the number of client CEP instances supported. However this feature is not fully supported in current proposed TAPI version (2.1.2) but is being standardized in TAPI v2.2.

Examples in section 7 , may include references to NEP Pools, please do not consider those guidelines mandatory for this current specification.

Use case example : an OTN matrix being used to map ODUk client connections into ODU4 line connections may express its multiplexing capabilities as a single ODU NEP pool which may have the following parameters:

  • layer-protocol-name = ODU4 (TTP rate)
  • supported-cep-layer-protocol-qualifier = ODU0, ODU1, ODU2, ODU2e, ODU3 (CTP rates)
  • total-potential-capacity = 400G
  • available-capacity = Upon connections already established over the NEP pool.

 

Not supported yet or extensions to TAPI 2.1 are required:

  • odu-pool
    • client-capacity = 1,2.5,10,40G. (currently this parameter is modelled as a leaf, it must be leaf-list to allow multiple values)
    • max-client-instances = 80, 40, 10, 10, 2 (currently this parameter is modelled as a leaf, it must be leaf-list to allow multiple values)
  • Max # TTP instances = 4
  • Max # CTP per TTP instances = 80, 40, 10, 10, 2

 

module: tapi-topology

  augment /tapi-common:context:

    +--rw topology-context

       +--ro topology* [uuid]

          +--ro node* [uuid]

          |  +--ro node-edge-point* [uuid]

          |  |  +--ro layer-protocol-name?   tapi-common:layer-protocol-name

          |  |  +--ro supported-cep-layer-protocol-qualifier* tapi-common:layer-protocol-qualifier

    |  |  +--ro aggregated-node-edge-point* [topology-uuid node-uuid node-edge-point-uuid]

          |  |  |  +--ro topology-uuid           -> /tapi-common:context/tapi-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 total-potential-capacity

          |  |  |  +--ro total-size

          |  |  |  |  +--ro value?   uint64

          |  |  |  |  +--ro unit?    capacity-unit

    |  |  |  +--ro bandwidth-profile

...

    |  |  +--ro available-capacity

    |  |  |  +--ro total-size

          |  |  |  |  +--ro value?   uint64

          |  |  |  |  +--ro unit?    capacity-unit

    |  |  |  +--ro bandwidth-profile

...

          |  |  +--ro odu-node-edge-point-spec

          |  |  |  +--ro odu-pool

          |  |  |  |  +--ro client-capacity?        uint64

          |  |  |  |  +--ro max-client-instances?   uint64

          |  |  |  |  +--ro max-client-size?       

 

[TAPI-TOP-MODEL-REQ-9]                        NEPs forwarding capabilities within a node can be OPTIONALLY constrained by using node-rule-group/rules/forwarding-rules. The NEPs can be segmented according to the following conditions:

  • Different layer-protocol-qualifier. In case multiple a DSR/ODU node includes NEPs with different layer-protocol-qualifier types (i.e., between different DSR_SIGNAL_TYPEs or ODU_TYPE), each group SHALL be segmented with a node-rule-group, including:
    • forwarding-rule=MAY_FORWARD_ACROSS_GROUP
  • Not forwarding between same device ports . In some cases it might be relevant to restrict the forwarding between client ports at the same network device (e.g., transponder). In this case ALL NEPs related to client ports at the same device SHALL be segmented with a node-rule-group, including:
    • 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-10]                   The ODU NEPs representing the line side transmission and OTSi NEPs are 1:1 transitional relations expressed as transitional links . A transitional link MUST be represented as a tapi-topology:link object including  a tapi-topology:transitioned-layer-protocol-name leaf-list attribute, which includes the pair of layer transition, e.g., [ODU,               PHOTONIC_MEDIA].

module: tapi-topology

  augment /tapi-common:context:

    +--ro topology* [uuid]         

       +--ro link* [uuid]

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

 

[TAPI-TOP-MODEL-REQ-11]                   OTU layer is intentionally not included in the model as ODU->OTSiA/OTSi representation is enough to cover all our defined use cases.

OTSi/Photonic Media layers: represents OTSi/Photonic Media layer networks

[TAPI-TOP-MODEL-REQ-12]                   The OTSi/OTSiA layer represents the optical side of the optical terminals (transponders/muxponders). This layer consists of nodes representing the mapping and multiplexing of OTSi signals. It consists of nodes including OTSi client endpoints representing the Trail Termination Points (TTPs) of the OTSi connections and OTSi/OMS endpoints representing the physical connectivity with ROADM/FOADM add/drop ports.

[TAPI-TOP-MODEL-REQ-13]                   The lower layer connectivity represented between transponder/muxponder line ports and ROADM/FOADM’s add/drop ports MUST be represented as tapi-topology:links between OMS PHOTONIC_MEDIA NEPs.

[TAPI-TOP-MODEL-REQ-14]                   OTSi NEPs MUST be present on top of OMS NEPs/CEPs to represent the effective forwarding of OTSi connections over the OMS link between Transponder Line Ports and ROADM Add/Drop ports.

[TAPI-TOP-MODEL-REQ-15]                   The NEPs layer qualifications allowed within OTSi nodes MUST be:

  • layer-protocol-name= PHOTONIC_MEDIA
  • supported-cep-layer-protocol-qualifier= [PHOTONIC_LAYER_QUALIFIER_OTSi/OTSiA], [PHOTONIC_LAYER_QUALIFIER_OMS]

[TAPI-TOP-MODEL-REQ-16]                   Each OTSi/OTSiA NEP MAY include the tapi-photonic-media:media-channel-node-edge-point-spec to represent the media channel pool resources supportable, available and occupied.

[TAPI-TOP-MODEL-REQ-17]                   Generally transponder/muxponder line ports and ROADM/FOADM’s add/drop ports are 1:1 relations, in case Optical Line Protection (OLPs) are present, OLP complexity shall be always represented in the Topology T4-Server Photonic Media OLS topology.

[TAPI-TOP-MODEL-REQ-18]                   Photonic-Media forwarding domains: represents the Photonic Media (Open Line System (OLS)) network. This forwarding domains can be mapped to OLP, ROADM/FOADM and ILA network elements which connectivity is always represented as OMS or OTS links. These forwarding domains SHALL expose the capability of create Media Channel connection and connectivity services between its endpoints.

[TAPI-TOP-MODEL-REQ-19]                   The NEPs layer qualifications allowed at the Photonic-Media forwarding domains (i.e., tapi-topology:node) are:

  • layer-protocol-name= PHOTONIC_MEDIA
  • supported-cep-layer-protocol-qualifier=[PHOTONIC_LAYER_QUALIFIER_OMS], [PHOTONIC_LAYER_QUALIFIER_NMC/NMCA] .

[TAPI-TOP-MODEL-REQ-20]                   NMC NEPs MUST be present on top of OMS NEPs/CEPs to represent the adjacency between OTSi signals and NMCs over the OMS link between Transponder Line Ports and ROADM Add/Drop ports.

[TAPI-TOP-MODEL-REQ-21]                   Each NMC/NMCA NEP MUST include the tapi-photonic-media:media-channel-node-edge-point-spec to represent the media channel pool resources supportable, available and occupied.

[TAPI-TOP-MODEL-REQ-22]                   It is assumed at minimum, the lower layer forwarding constructs (tapi-topology:link) between forwarding domains (tapi-topology:node) which need to be represented in this topology should be OMS links. Thus, it is assumed that OTS layer links and intermediate OMS forwarding domains (In Line Amplifier (ILA) sites) might be represented or not depending on vendor implementation, but OMS forwarding constructs (links) MUST be configured in the network in advance without being needed to be created during upper layer services provisioning process .

[TAPI-TOP-MODEL-REQ-23]                   In case OLP constructs are present for OMS protection, this should be represented in TAPI by using tapi-topology:resilience-type/tapi-topology:protection-type link’s attribute. Underlying switch control for OMS protection is out of the scope of this modelling.

[TAPI-TOP-MODEL-REQ-24]                   In the current specification it is not required to include SIPs at this layer to be selected by users for the creation of services at the NMC/NMCA layers and it will only connection generated by the TAPI server MUST be represented.

5.2      Inventory considerations

Hardware identifiers currently stored in legacy OSS inventory systems MUST be correlated with T-API UUID identifiers. This information will be provided by the SDN optical domain controller suppliers as a pre-requisite for the use cases described in section 0 of the present document.

For every inventory element represented as a logical element in TAPI by the SDN Domain controller, an INVENTORY_ID tapi-common:name property shall be included into the logical element construct.

In particular the INVENTORY_ID tag SHALL be included for the following TAPI objects:

  • tapi-topology:node-edge-point
  • tapi-common:service-interface-point

The proposal for a common definition of the INVENTORY_ID tag, follows 2 main principles and it is based on TMF-814 [A1] 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

x

-

-

/sl=<sl_index>

-

-

-

-

x

x

/s_sl=<s_sl_index>

-

-

-

-

x

x

/p=<p_index>

-

-

-

-

 

x

 

Some examples of INVENTORY_ID for node-edge-points:

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

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

 

5.3      Network scenarios

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

5.3.1       Scenario 1: ROADM network equipped with OTN matrices

This first scenario represents a three-ROADM network equipped with OTN matrices to perform grooming of Ethernet 1G and 10G client signals into 100G line-side interfaces transmitting OTSi colored optical wavelengths.

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

 

5.3.1.1    Model representation

Figure 5 - 2 NS-1.T0: TAPI Topology Flat Abstraction model.

 

Figure 5 - 3 NS-1.T0: TAPI Topology Flat Abstraction view comparison with Layered view.

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

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

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

5.3.2.1    Model representation

Figure 5 - 5 NS-2.T0: TAPI Topology Flat Abstraction model.

 

Figure 5 - 6 NS-2.T0: TAPI Topology Flat Abstraction model comparison with Layered model.

 


6        Connectivity service model

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

6.1      Model guidelines

The following guidelines MUST be met by all implementations following the current specification.

[TAPI-CONN-MODEL-REQ-1]              The solution exposing the proposed NBI based on RESCONF/TAPI MUST expose the capability of creating Connectivity-Service at all proposed network layers.

  • DSR Layer: Models a Digital Signal of an unspecified format. This value can be used when the intent is to represent a generic digital layer signal without making any statement on its format or overhead (processing) capabilities.
  • ODU Layer: Models the ODU layer as per described in [ITU-T G.709].
  • PHOTONIC_MEDIA Layer: Models the OCH, OTSi, OTSiA, OTSiG, and Media channels (NMC/NMCA) as per described in [ITU-T G.872].

[TAPI-CONN-MODEL-REQ-2]              The connectivity model proposed is not assuming the need of tapi-topology:node representations of the forwarding domains. Thus, as already described in Section 4.2.4.2 , this model introduces the concept of Top Connections which are defined as end-to-end connections between Connection-End-Points within the same layer which may belong to different Forwarding-Domains (TAPI Nodes). They can be either terminated (“infrastructure trails”) or non-terminated (connecting client signals).

[TAPI-CONN-MODEL-REQ-3]              Each tapi-connectivity:connectivity-service will always include a reference to one or more Top Connection tapi-connectivity:connection objects within its connection list ( tapi-connectivity:connectivity-service/connection ) which describe the end-to-end connectivity across the network layers traversed by the connectivity-service (represented as the combination of the tapi-common:layer-protocol-name and tapi-common: layer-protocol-qualifier attributes).

module: tapi-connectivity

  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 is intended to represent how the requested service has been implemented within a network layer . It shall include the tapi-connectivity:connection/route object containing the list of connection-end-points (CEPs) traversed by the service at that layer.

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 service which produces it). However, as agreed by the TAPI group, the server is not responsible of maintaining any specific logical order of the CEP. Thus, the logical order of the connection-end-points within the Route object SHALL be inferred by the TAPI client by the knowledge of the Topology information and the NEP to NEP associations

[TAPI-CONN-MODEL-REQ-6]              The Top Connection MUST include a reference to all the lower connections generated in the in the same network layer, to support the end-to-end Top Connection. These references MUST be included within the tapi-connectivity:connection/ tapi-connectivity: lower-connection list.

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

 

Please note that Top Connections may include lower-level Top Connections if they belong to the same layer (different rates) and they represent infrastructure G.805 Trails. E.g., an ODU2 Top Connection may be included within the tapi-connectivity:connection/ tapi-connectivity: lower-connection list of an ODU0 Top Connection.

[TAPI-CONN-MODEL-REQ-7]              Top Connections may be generated to represent two different cases:

  • Non-terminated Top Connections : between CEPs with a parent-NEPs ( tapi-topology:owned-node-edge-point/tapi-connectivity:cep-list/connection-end-point/parent-node-edge-point ) directly associated to the SIPs which has been referenced by the Service-End-Points of the Connectivity-Service associated to this Top Connection.

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

    +--ro cep-list

       +--ro connection-end-point* [uuid]

          +--ro parent-node-edge-point

          |  +--ro topology-uuid?          -> /tapi-common:context/tapi-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 represented the generated pool of resources at a higher network layer or rate. E.g., an ODUk CEP producing a lower order ODUj NEP or an ODUk CEP producing DSR NEP.

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

    +--ro cep-list

       +--ro connection-end-point* [uuid]

          +--ro client-node-edge-point* [topology-uuid node-uuid node-edge-point-uuid]

          |  +--ro topology-uuid           -> /tapi-common:context/tapi-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

6.1.1       Multi-layer connectivity service provisioning and connection generation

For the multi-layer connectivity service representation, once provisioned, the TAPI server might choose among two possible models for representing the hierarchy of connections among different layers.

6.1.1.1    Option A: Top most layer top-connection modelling with inter-layer referencing

In this approach, the TAPI server only includes the Top most layer Top Connection reference within the Connectivity Service connections list. In this approach, the multi-layer connectivity discovery is done reclusively analyzing the lower-level connection list of the Top Connection objects, which includes a reference to the lower layer Top Connection until the bottom most represented layer (Photonic_Media).

Assuming a DSR Connectivity-Service has been requested between two SIPs associated to NEPs of the DSR layer, the multi-layer connections created are described by the following assumptions:

At DSR layer :

[TAPI-CONN-MODEL-REQ-8]              The CS triggers the creation of the Top Connection at the DSR layer:

  • Once DSR Top Connection is operational ( tapi-connectivity:connection/tapi-common:operational-state = ENABLED ), the DSR CS becomes operational and includes DSR Top Connection within its connection list.
  • DSR Top Connection MUST include the explicit route referencing CEPs associated to NEPs at the DSR layer.

[TAPI-CONN-MODEL-REQ-9]              One or more, DSR XC Connections, which connections which conforms the end-to-end route of DSR Top connection and MUST be included within its lower-connection list.

  • When operational ( tapi-connectivity:connection/tapi-common:operational-state = ENABLED ), the DSR Top Connection becomes operational too.

 

At the ODU layer t he CS triggers the creation of:

[TAPI-CONN-MODEL-REQ-10]         0-N Top Connections at the ODUj layers, which describes the multiplexing of Low Order (LO)-ODU signals into High Order (HO)-ODU signals.

  • Each ODUj Top Connection MUST include the list of ODUj lower connections which conforms the end-to-end route of the Top Connection at this layer rate.
  • When each ODUj Top Connection become operational ( tapi-connectivity:connection/tapi-common:operational-state = ENABLED ) in increasing order from lower ODU layer (higher ODU rate) to the DSR layer, the immediately upper layer adjacency is enabled (a higher layer NEP is created “over” the operational CEP) allowing the upper layer Top Connection is realized.
  • Moreover, all ODUj Top Connections are operational, a new tapi-topology:link at the DSR layer ( layer-protocol-name=DSR ) MUST be generated between the NEPs produced by the CEPs (Trail Termination Points) of the Top Most Connection with the ODUj Layer rate as a tapi-connectivity: supported-client-link.

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

 

  • Additionally, when operational, the Top Most ODUj Connection can be included within the DSR Top Connection lower-connection list.

[TAPI-CONN-MODEL-REQ-11]         One Top Connection at the HO-ODUk rate, which describe the highest order ODU (supported by this node) which transport by the optical OTSi layer.

  • When operational, the HO-ODUk Top Connection MUST be included within highest ODUj rate Top Connection’s lower-connection list .

[TAPI-CONN-MODEL-REQ-12]         Possibly multiple HO-ODUk XC Connections, which conforms the end-to-end route of HO-ODUk Top connection and MUST be included within its lower-connection list.

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

At the T3 – OTSi/Photonic Media layer the CS triggers the creation of:

[TAPI-CONN-MODEL-REQ-13]         One Top Connection at the OTSi layer between the two NEPs connected to the HO-ODUk NEPs by transitional links. The case of multi-OTSi mapping to an ODUk client signal is out-of-the scope of the present specification.

  • When the T2 OTSi Top Connection becomes operational, an ODU tapi-topology:link between the related HO-ODUk NEPs is created, representing the potential adjacency between these two NEPs at the HO-ODUk layer/rate. Thus, allowing the T2 HO-ODUk Top Connection to be realized. The new generated link MUST be referenced by the CEPs of the Top Connection which generates it as a tapi-connectivity: supported-client-link.

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

 

  • When operational, the OTSi/OTSiA Top Connections MUST be included within the HO-ODUk Top connection lower-connection list.
  • T2 OTSi/OTSiA Top Connection MUST include the explicit route referencing CEPs associated to NEPs of T3 topology.

[TAPI-CONN-MODEL-REQ-14]         Possibly multiple OTSi/OTSiA XC Connections, which conforms the end-to-end route of OTSi/OTSiA Top connection and MUST be included within its lower-connection list.

  • When operational, the OTSi/OTSiA Top Connection becomes operational too.

At the Photonic Media Layer , the CS triggers the creation of a Top Connection at the NMC/NMCA layer.

[TAPI-CONN-MODEL-REQ-15]         One NMC/NMCA Top Connection at the Photonic Media server layer between the two NEPs connected to the OTSi/OTSiA NEPs through an OMS link.

  • When the NMC/NMCA Top Connection becomes operational, an OTSi tapi-topology:link between the related OTSi NEPs is created, representing the potential adjacency between these two NEPs at the OTSi layer. Thus, allowing the OTSi Top Connection to be realized. The new generated link MUST be referenced by the CEPs of the Top Connection which generates it as a tapi-connectivity:supported-client-link.
  • Moreover, the NMC/NMCA Top Connection MUST be included within OTSi/OTSiA Top connection lower-connection list.
  • NMC/NMCA Top Connection MUST include the explicit route referencing CEPs associated to NEPs of Photonic Media Layer .

[TAPI-CONN-MODEL-REQ-16]         Possibly multiple NMC/NMCA XC Connections, which conforms the end-to-end route of NMC/NMCA Top connection and MUST be included within its lower-connection list.

  • When operational, the T3 NMC/NMCA Top Connection becomes operational too.

Following a complete generic example of a DSR connectivity-service is presented to clearly identify the connection association hierarchy described by the previous set of requirements.

{"context":{

"connectivity-context":{

"connectivity-service":[

{"uuid":"CS_UUID",

"end-point":[

{"local_id":"LOCAL_ID_A","service-interface-point":{"service-interface-point-uuid":"SIP_UUID_A"}},

{"local_id":"LOCAL_ID_B","service-interface-point":{"service-interface-point-uuid":"SIP_UUID_B"}}],

"connection":[

{"connection_uuid":"T1_DSR_TOP_1"}]

}

],

"connection":[

{"uuid": "DSR_TOP_1",

"lower-connection":[

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

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

{"connection-uuid":"DSR_XC_2"}

]},

{"uuid": "ODUj_TOP_1",

"lower-connection":[

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

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

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

]},

{"uuid": "HO-ODUk_TOP_1",

"lower-connection":[

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

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

{"connection-uuid":"OTSi_TOP_1"}

]},

{"uuid": "OTSi_TOP_1",

"lower-connection":[

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

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

{"connection-uuid":"OTSi_XC_2"}

]},

{"uuid": "NMC_TOP_1",

"lower-connection":[

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

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

{"connection-uuid":"NMC_XC_N"}

]}

]}

   }

}

 

6.1.1.2    Option B: Per layer top-connection modelling without inter-layer referencing

In this approach, the TAPI server includes a reference to each layer Top Connection within the Connectivity Service’s Connection list. Associations between connection objects at different layers can be made upon the Connectivity Service which reference them (all connections appear to be part of the connection-references list object of the Connectivity Service) or by the tapi-topology <-> tapi-connectivity model relationships included in the tapi-connectivity:connection/supported-client-link attribute. E.g., a lower layer Photonic_Media/OTSi Top Connection and an ODU Top connection are related if the later’s Route object traverse two Connection End Points (CEPs) related to two Node Edge Points which are connected by a Link object which is referenced by an OTSi Top Connection object.

Please note, that multi-rate connections within a layer MIGHT be referenced as detailed in the previous approach (e.g., HO-ODUk and LO-ODUj connections).

Now, assuming that a DSR Connectivity-Service has been requested between two SIPs associated to NEPs of the DSR layer, the multi-layer connections created are described by the following assumptions:

At DSR layer :

[TAPI-CONN-MODEL-REQ-17]         The CS triggers the creation of the Top Connection at the DSR layer:

  • Once DSR Top Connection is operational ( tapi-connectivity:connection/tapi-common:operational-state = ENABLED ), the DSR CS becomes operational and includes DSR Top Connection within its connection list.
  • DSR Top Connection MUST include the explicit route referencing CEPs associated to NEPs at the DSR layer.

[TAPI-CONN-MODEL-REQ-18]         One or more, DSR XC Connections, which connections which conforms the end-to-end route of DSR Top connection and MUST be 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-19]         0-N Top Connections at the ODUj layers, which describes the multiplexing of Low Order (LO)-ODU signals into High Order (HO)-ODU signals.

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

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

 

[TAPI-CONN-MODEL-REQ-20]         One Top Connection at the HO-ODUk rate, which describe the highest order ODU (supported by this node) which transport by the optical OTSi layer.

  • Once the HO-ODUk Top Connection is operational ( tapi-connectivity:connection/tapi-common:operational-state = ENABLED ), it MUST be included within the CS connection list.
  • When operational, the HO-ODUk Top Connection MUST be included within highest ODUj rate Top Connection’s lower-connection list .

[TAPI-CONN-MODEL-REQ-21]         Possibly multiple HO-ODUk XC Connections, which conforms the end-to-end route of HO-ODUk Top connection and MUST be included within its lower-connection list.

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

At the T3 – OTSi/Photonic Media layer the CS triggers the creation of:

[TAPI-CONN-MODEL-REQ-22]         One Top Connection at the OTSi layer between the two NEPs connected to the HO-ODUk NEPs by transitional links. The case of multi-OTSi mapping to an ODUk client signal is out-of-the scope of the present specification.

  • Once the OTSi Top Connection is operational ( tapi-connectivity:connection/tapi-common:operational-state = ENABLED ), it MUST be included within the CS connection list.
  • When the OTSi Top Connection becomes operational, an ODU tapi-topology:link between the related HO-ODUk NEPs is created, representing the potential adjacency between these two NEPs at the HO-ODUk layer/rate. Thus, allowing the T2 HO-ODUk Top Connection to be realized. The new generated link MUST be referenced by the Top Connection, which realizes it, as a tapi-connectivity: supported-client-link.

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

 

  • OTSi/OTSiA Top Connection MUST include the explicit route referencing CEPs associated to NEPs of PHOTONIC_MEDIA Layer with OTSI supported-layer-qualifier.

[TAPI-CONN-MODEL-REQ-23]         Possibly multiple OTSi/OTSiA XC Connections, which conforms the end-to-end route of OTSi/OTSiA Top connection and MUST be included within its lower-connection list.

  • When operational, the OTSi/OTSiA Top Connection becomes operational too.

At the Photonic Media Layer , the CS triggers the creation of a Top Connection at the NMC/NMCA layer.

[TAPI-CONN-MODEL-REQ-24]         One NMC/NMCA Top Connection at the Photonic Media server layer between the two NEPs connected to the OTSi/OTSiA NEPs through an OMS link.

  • Once the NMC/NMCA Top Connection is operational ( tapi-connectivity:connection/tapi-common:operational-state = ENABLED ), it MUST be included within the CS connection list.
  • When the NMC/NMCA Top Connection becomes operational, an OTSi tapi-topology:link between the related OTSi NEPs is created, representing the potential adjacency between these two NEPs at the OTSi layer. Thus, allowing the OTSi Top Connection to be realized. The new generated link MUST be referenced by the CEPs of the Top Connection which generates it as a tapi-connectivity:supported-client-link.
  • Moreover, the NMC/NMCA Top Connection MUST be included within OTSi/OTSiA Top connection lower-connection list.
  • NMC/NMCA Top Connection MUST include the explicit route referencing CEPs associated to NEPs of Photonic Media Layer .

[TAPI-CONN-MODEL-REQ-25]         Possibly multiple NMC/NMCA XC Connections, which conforms the end-to-end route of NMC/NMCA Top connection and MUST be included within its lower-connection list.

  • When operational, the NMC/NMCA Top Connection becomes operational too.

Following a complete generic example of a DSR connectivity-service is presented to clearly identify the connection association hierarchy described by the previous set of requirements.

{"context":{

"connectivity-context":{

"connectivity-service":[

{"uuid":"CS_UUID",

"end-point":[

{"local_id":"LOCAL_ID_A","service-interface-point":{"service-interface-point-uuid":"SIP_UUID_A"}},

{"local_id":"LOCAL_ID_B","service-interface-point":{"service-interface-point-uuid":"SIP_UUID_B"}}],

"connection":[

{"connection_uuid":"DSR_TOP_1"},

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

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

{"connection-uuid":"NMC_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"},                                                         {"connection-uuid":"ODUj_TOP_2"},

]},

 

… (repeated for N ODUj layer rates)

 

{"uuid": "ODUj_TOP_N",

"lower-connection":[

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

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

]},

{"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": "NMC_TOP_1",

"lower-connection":[

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

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

{"connection-uuid":"NMC_XC_N"}

]}

]}

   }

}

6.1.2       Resiliency mechanism at connectivity service

[TAPI-CONN-MODEL-REQ-26]         In order to implement different mechanism of protection the TAPI Server MUST support the following protection and restoration policies ( tapi-topology:protection-type ) at the Connectivity Service level:

  • ONE_PLUS_ONE_PROTECTION
  • ONE_PLUS_ONE_PROTECTION_WITH_DYNAMIC_RESTORATION
  • PERMANENT_ONE_PLUS_ONE_PROTECTION
  • ONE_FOR_ONE_PROTECTION
  • DYNAMIC_RESTORATION
  • PRE_COMPUTED_RESTORATION

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-27]         For all protected services with restoration capabilities, the default behavior assumed in this specification is PER_DOMAIN_RESTORATION which implies the TAPI server is responsible of activating the required control mechanisms to guarantee the restoration of the service autonomously.

[TAPI-CONN-MODEL-REQ-28]         At the Connection level, the switch control among lower-connections, which implements the route diversity for the different levels of protection policies listed in [TAPI-CONN-MODEL-REQ-26] , MUST be implemented by the TAPI server. The TAPI server MUST be able to describe these mechanisms by the tapi-connectivity:connection/switch-control. The specific switch-control mechanisms for each protection schema will be detailed in Section 7.4 .

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 

6.1.3       Topology and service constrains for connectivity services

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

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:uuidcontext/topology/node/uuid

 


7        Use cases Low Level designs (LLDs)

First we include the checklist of use cases in the scope of optical transport management with the roadmap for its definition. This version of the document closes the definition of the PACK_1 of use cases based on this NBI specification.

  Table 6 : UCs summary.

Use Cases

SDNC_PACK

Definition

Discovery use cases:

 

Use case 0a: Context & Service Interface Points discovery (synchronous mode)

1

July’19

Use case 0b: Topology discovery (synchronous mode)

1

July’19

Provisioning use cases:

 

 

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

1

July’19

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

1

July’19

Use case 1c: Unconstrained ODU Service Provisioning

 

 

Use case 1d: Unconstrained PHOTONIC_MEDIA/OTSi Service Provisioning

1

July’19

Use case 1e: Unconstrained PHOTONIC_MEDIA/OTSiA Service Provisioning

1

July’19

Use case 1f: Unconstrained PHOTONIC_MEDIA/NMC Service Provisioning

 

 

Use case 2a: Unconstrained service provisioning with OCh/OTSi(channel selection)

 

 

Use case 2b: Unconstrained service provisioning with ODU selection

 

 

Use case 2c: Unconstrained service provisioning with NMC (channel selection)

 

 

Use case 3a: Constrained Provisioning - Include/exclude a node or group of nodes.

 

 

Use case 3b: Constrained Provisioning -Include/exclude a link or group of links.

 

 

Use case 3c: Constrained Provisioning - Include/exclude the path used by other service.

1

July’19

Inventory use cases:

 

Use case 4: Inventory model for NBI interface

 

 

Resilience use cases:

 

 

Use case 5a: 1+1 OLP Client Protection with Diverse Service Provisioning

 

 

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

1

July’19

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

1

July’19

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

1

July’19

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

 

 

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

1

July’19

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

 

 

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

 

 

Use case 9: Reverted protection for use cases

 

 

Service maintenance use cases:

 

 

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

1

July’19

Use case 11a: Modification of service path

 

 

Use case 11b: Modification of service nominal path to secondary (protection) path for maintenance operations.

 

 

Use case 11c Modification or upgrade of service capacity. (Only valid for electrical services)

 

 

Planning use cases:

 

 

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

 

 

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

 

 

Use case 12c: Multiple simultaneous path computation (Bulk request processing)

 

 

Use case 12d: Physical impairment validation of an pre-calculated OCh/OTSi trail path.

 

 

Alarms and Notification use cases:

 

 

Use case 13a: Subscription to notification stream service.

 

 

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

 

 

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

 

 

Use case 15a: Notification of new connectivity-service element inserted/removed in/from the network.

 

 

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

 

 

Use case 16a: Notification of status change on the routing conditions of an existing connection element in the network.

 

 

Use case 16b: Notification of status change on the switching conditions of an existing connection element in the network.

 

 

 

7.1      Use case 0: Topology and services discovery

This use case consists on retrieving all information available from TAPI servers (SDN-C) including topology, service-interface-points, connectivity-services and connections.

This use case is intended to be performed by any NBI client controller, module or application which intends to discover the logical representation of the network done by the SDNC.

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

  • Synchronous mode , based on periodic pooling retrieval operations and after each service creation to reconcile the actual state of the network.
  • Asynchronous mode , based on an initial proactive synchronization done from the NBI client module and a connection oriented notification subscription session based on the NBI Notification mechanism described in section 3.6 and 4.4 .

 

In this first phase of the specification the synchronous mechanism is foreseen to be fully supported by any provider SDNC compliant with this specification.

For simplicity this use case is divided in three sub-use cases:

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

7.1.1       Use Case 0a: Context & Service Interface Points discovery (synchronous mode)

Number

UC0a

Name

Context & Service Interface Points discovery (synchronous mode)

Technologies involved

Optical

Process/Areas Involved

Planning and Operations

Brief description

The TAPI Context and Service Interface Points are the relevant network service information required previous to any connectivity-service creation operation.

The discovery of this information is intended to be requested periodically and/or on-demand basis, proactively from the TAPI client role, in order to synchronize the context information.

Layers involved

DSR/ODU/PHOTONIC_MEDIA

Type

Discovery

Description & Workflow

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

The second operation (3) retrieves the list of service-interface-point (SIP) “uuid” (4), to recursively retrieve the full content of each SIP object in operation (5) which employs the “fields” query parameter to obtain only the desired filtered information. The response operation (6) MUST contain the attributes included in Table 8 which are marked as Mandatory (M) in the Support (Sup) column.

Figure 7 - 1 UC-0a: Service Interface Point - LLD Workflow.

 

 

 

 

7.1.1.1    Required parameters

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

  Table 7 : Context object definition

Context

Attribute

Allowed Values/Format

Mod

Sup

Notes

uuid

"[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-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

nw-topology-service

{ network-topology-service }

RO

M

  • Provided by tapi-server

topology

List of { topology }

RO

M

  • Provided by tapi-server

connectivity-service

List of { connectivity-service }

RW

M

  • Provided by tapi-client
  • Direct modification disallowed

connection

List of { connection }

RO

M

  • Provided by tapi-server

 

  Table 8 : Service Interface Point (SIP) object definition

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 5.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”:{ supportable-central-frequency-spectrum-band, supportable-application-identifier, supportable-modulation, total-power-warn-threshold}

  • List of “supportable-central-frequency-spectrum-band”:{ 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/OTSiA service provisioning capabilities.
  • 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.

 

tapi-photonic-media: media-channel-service-interface-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

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.

 

 

7.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, in order 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 7 - 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 is included in Table 9 . The response operation MUST contain the attributes included in Table 9 which are marked as Mandatory (M) in the Support (Sup) column.

For each node found in operation (4), operation (5) is repeated to retrieve each tapi-topology:node object (6) which MUST contain the attributes included in Table 10 which are marked as Mandatory (M) in the Support (Sup) column. Recursively, for each node object a filtered operation (7) is used to retrieve each owned-node-edge-point/uuid reference.

For each owned-node-edge-point reference discovered in operation (7), operation (9) is performed to retrieve each owned-node-edge-point object (10) for each node. Each ONEP object MUST contain the attributes included in Table 11 which are marked as Mandatory (M) in the Support (Sup) column.

For each topology found in operation (4), operation (11) is repeated to retrieve each tapi-topology:link object (12) which MUST contain the attributes included in Table 14 which are marked as Mandatory (M) in the Support (Sup) column.

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

 

7.1.2.1    Required parameters

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

  Table 9 : Topology object definition

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

  • Support OCH/OTSi?

link

List of { link }

RO

M

  • Provided by tapi-server

node

List of { node }

RO

M

  • Provided by tapi-server

 

  Table 10 : Node object definition

Node

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 5.2

 

layer-protocol-name

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

RO

M

  • Support OCH/OTSi?

 

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

  • Support other cost metrics?

latency-characteristic

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

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

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

RO

O

  • Support other latency properties?

encapsulated-topology

{" topology-ref "}

RO

M

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

aggregated-node-edge-point

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

RO

M

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

owned-node-edge-point

List of { node-edge-point }

RO

M

  • Provided by tapi-server

node-rule-group

List of { node-rule-group }

RO

M

  • Provided by tapi-server

 

  Table 11 : Node-edge-point object definition

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 5.2

 

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

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
  • Support UNIDIRECTIONAL?

link-port-role

["SYMMETRIC"]

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

aggregated-node-edge-point

List of { node-edge-point-ref}

RO

M

  • Provided by tapi-server

 

mapped-service-interface-point

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

RO

M

  • Provided by tapi-server

cep-list

List of { connection-end-point }

RO

M

  • Provided by tapi-server

tapi-photonic-media: media-channel-service-interface-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

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.

 

  Table 12 : Node-rule-group object definition

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

  • Provided by tapi-server

 

  Table 13 : Rule object definition

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 14 : Link object definition

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

  • Only applicable to transitional-links.
  • Pending model extension.

 

cost-characteristic

List of  {cost-name: cost-value}

  • "cost-name": "HOP_COUNT"

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

RO

O

  • Support other cost metrics?

latency-characteristic

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

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

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

RO

O

  • Support other latency properties?

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

7.2      Use case 1: Unconstrained E2E Service Provisioning

Please note that this use case can divided in five sub use cases depending on the layer on which it is applied:

  • UC1a: Unconstrained DSR Service Provisioning single wavelength ( < 100G).
  • UC1b: Unconstrained DSR Service Provisioning multi wavelength (beyond 100G).
  • UC1c: Unconstrained ODU Service Provisioning
  • UC1d: Unconstrained PHOTONIC_MEDIA/OTSi Service Provisioning
  • UC1e: Unconstrained PHOTONIC_MEDIA/OTSiA Service Provisioning
  • UC1f: Unconstrained PHOTONIC_MEDIA/NMC Service Provisioning

In this specification we only consider the mandatory the implementation of the UC1a, UC1c and UC1d, the rest are left for the next release of this document,

The workflow definition and required parameters described in these sections applies to all the different sub-use cases but the results in terms of the number of connections generated are different depending on the layer to which the unconstrained connectivity-service has been requested.

The main different between the different sub-use cases described here, is the selection of the Connectivity-Service-End-Points, i.e., the layer to which their associated SIPs. Depending on this selection the connections generated in the network are up to a networking layer or another. E.g., for the provisioning of a PHOTONIC_MEDIA/OTSi Connectivity-Service, the TAPI Server will only generates connection up to the PHOTONIC_MEDIA/OTSi network layer.

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

Number

UC1a

Name

Unconstrained DSR Service Provisioning single wavelength (<100G).

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 including intermediate regeneration connections if needed) is performed by the SDN Domain controller.

The path of each lower layer connection (e.g., ODU or OCh/OTSi, OMS) across the network topology is calculated by the controller and the connection automatically provisioned.

The “unconstrained” term refers that the TAPI-Client is not allowed to introduce any routing constraint in the service request, thus relays completely into the routing capabilities of the TAPI-Server to select the network resources employed to provide the desired service characteristics.

Moreover, the TAPI-Client is not providing technology specific Traffic-Engineering constrains such time-slot selection at the ODU layer, or optical-spectrum selection for the routing of OTSi connections.

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

The first operation (1) triggers the creation of Connectivity-Service in the NBI Server. The TAPI server MUST accept any valid combination of the attributes marked as Mandatory (M) in the Support (Sup) column of Table 15 and Table 16 . If the operation is successful, the NBI server MUST return an http response message with the Location Header as specified in https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5 .

Once the resource has been created, the NBI Client may retrieve all information of the Connectivity-Service (3), Connection list of references (5) and all its Connection objects (7). The NBI server MUST return a valid object, if previous operations (4)(6)(8) succeed, which are compliant with the definition of the objects included in Table 15 (Connectivity-Service) and Table 17 (Connection). Please note the Connection object MUST include all attributes marked as Mandatory (M) in the Support (Sup) in all Connection sub-objects defined in Table 18 , Table 19 , Table 20 , Table 21 , Table 22 and Table 23

 

Figure 7 - 3 UC-1: Unconstrained end-to-end service provisioning.

 

 

7.2.1.1    Required parameters

 

  Table 15 : Connectivity-service object definition

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

  •  

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.

 

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

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

  • Provided by tapi-server

 

  Table 17 : Connection object definition

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

  • Provided by tapi-server

switch-control

List of { switch-control }

RO

M

  • Provided by tapi-server

 

  Table 18 : Connection-end-point object definition

connection-end-point

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
  • Support SOURCE/SINK?

connection-port-direction

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

RO

M

  • Provided by tapi-server
  • Support UNIDIRECTIONAL?

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

M

  • Provided by tapi-server

 

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

{ otsi-connection-end-point-spec }

RO

M

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

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

{otsi-assembly-connection-end-point-spec }

RO

M

  • Provided by tapi-server
  • MUST augment CEPs at the PHOTONIC_MEDIA layer with OTSIA layer-protocol-qualifier.

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

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

RO

M

  • Provided by tapi-server
  • MUST augment CEPs at the PHOTONIC_MEDIA layer with NMC/NMCA layer-protocol-qualifier.

 

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

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

{ odu-slot-size, auto-payload-type, configured-client-type, configured-mapping-type, accepted-payload-type, named-payload-type, hex-payload-type }

  • odu-slot-size
  • auto-payload-type?         boolean
  • configured-client-type: tapi-dsr:digital-signal-type
  • configured-mapping-type?   mapping-type
  • accepted-payload-type
  • named-payload-type?   odu-named-payload-type
  • hex-payload-type?     uint64

RO

M

  • Provided by tapi-server

odu-ctp

{total-power, power-spectral-density}

  • tributary-slot-list*     uint64
  • tributary-port-number?   uint64
  • accepted-msi?            string

RO

M

  • Provided by tapi-server

 

 

  Table 20 : OTSI-Connection-end-point-spec object definition

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 21 : OTSI-Assembly-connection-end-point-spec object definition

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

 

fec-parameters

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

RO

M

  • Provided by tapi-server

 

 

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

media-channel-connection-end-point-spec

Attribute

Allowed Values/Format

Mod

Sup

Notes

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

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

 

  Table 23 : Route object definition

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

 


7.2.1.2    Expected results

In the following subsections we include detail examples of the expected results after the successful provisioning of connectivity-services. Please note that all examples follow the rules detailed in section 6.1.1

In order to show some detailed TAPI connectivity examples, first a simple legend of icons and basic arrangement is included in Figure 13 .

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

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

Figure 7 - 5 Connectivity Service 10GE client signal over ODU2 (DSR-ODU Fixed Mapping) – Step1

 

Figure 7 - 6 Connectivity Service 10GE client signal over ODU2 (DSR-ODU Fixed Mapping) – Step2 (ODU4 Top Connection creation)

 

Figure 7 - 7 Connectivity Service 10GE client signal over ODU2 (DSR-ODU Fixed Mapping) – Step3 (ODU2 over ODU4 Top Connection cross-connection)

 

 

Figure 7 - 8 Connectivity Service 10GE client signal over ODU2 (DSR-ODU Fixed Mapping) – Step4 (ODU4 over OTSi).

 

 

Figure 7 - 9 Connectivity Service 10GE client signal over ODU2 (DSR-ODU Fixed Mapping) – Step5 (ODU 4 over OTSi over NMC).

 

7.2.1.2.2              UC1a - Example 2: 1GE client signal over ODU0 over ODU2 over ODU4 (Fixed DSR-ODU mapping, flexible ODU allocation)

For simplification OTSi and Photonic Media layers have been omitted from this example, as it is the exact same case depicted in the previous example.

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

 

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

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

 

7.2.1.2.4              UC1a - Example 4: 10GE client signal over ODU2 over ODU4 (Fixed DSR-ODU mapping, flexible ODU allocation) with intermediate transponder regeneration.

In this example we are taking for the first time intermediate regeneration (3R) of the optical channel (OTSi/OTSiA) into account from the modelling perspective. Please take into account the following considerations:

The TAPI Server MAY or MAY NOT expose SIPs for the regeneration board OTSi/OTSiA:

a)     The TAPI Server does not expose SIPs for the regeneration board OTSi/OTSiA interfaces, thus these resources are only available to be consumed by the internal control plane for regeneration of a higher layer (ODU, DSR) client connectivity-service. Currently we assume this approach.

b)     The TAPI Server does expose SIPs for the regeneration board OTSi/OTSiA interfaces. So, the TAPI Server exposes to the user the creation of the two OTSi/OTSiA connectivity services segments independently, to be used by higher layer services. Moreover, these SIPs also can be used to define a multi-hop OTSi/OTSiA connectivity-service forcing the use of regeneration. Inthis case, the user MUST request a creation of a CS including (for a regenerated service with a single regeneration point) four CSEPs with references to aEND, zEND and intermediate regeneration SIPs, in the CS request.

Assuming the option a), the expected connectivity model result in terms of hierarchy of connections within the CS’s connection list, SHALL include a single HO-ODUk supported by N-segments of OTSi/OTSiA connections represented as ODU links between every regeneration stage (in this example a single regeneration results into 2 OTSI/OTSIA segments).

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

 

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

Number

UC1b

Name

Unconstrained DSR Service Provisioning multi wavelength (beyond 100G). 

Technologies involved

Optical

Process/Areas Involved

Planning and Operations

Brief description

The UC1 describes the provisioning of a tapi-connectivity:connectivity-service instance between service-interface-points exposed by the TAPI-Server at the DSR networking layer. This service can include intermediate regeneration if necessary.

The underlying connection provisioning and management (including lower layer connections e.g., ODU, OTSi/OTSiA/OTSiG, NMC/NMCA including intermediate regeneration connections if needed) is performed by the SDN Domain controller.

The path of each lower layer connection (e.g., ODU or OCh/OTSi, OMS) across the network topology is calculated by the controller and the connection automatically provisioned.

The “unconstrained” term refers that the TAPI-Client is not allowed to introduce any routing constraint in the service request, thus relays completely into the routing capabilities of the TAPI-Server to select the network resources employed to provide the desired service characteristics.

Moreover, the TAPI-Client is not providing technology specific Traffic-Engineering constrains such time-slot selection at the ODU layer, or optical-spectrum selection for the routing of OTSi connections.

Layers involved

DSR/ODU/PHOTONIC_MEDIA

Type

Provisioning

Description & Workflow

This UC is implemented following the same workflow described in “Description & Workflow” of UC1a described in section 7.2.1

7.2.2.1    Expected results

The connection generation follows the rules detailed in section 6.1.1 .In this use case it is expected that originally, the ODU and PHOTONIC_MEDIA layers are connect through a transitional link.

This particular case requires the generation of a OTSiA/OTSiG (depending on the monitoring capabilities implemented by the TAPI server) Top Connection between the pair of NEPs connecting the PHOTONIC_MEDIA side of the ODU and PHOTONIC_MEDIA transitional links. These NEPs MUST report within the supported-layer-qualifier list the following types: [PHOTONIC_LAYER_QUALIFIER_OTSi, PHOTONIC_LAYER_QUALIFIER_OTSiA, PHOTONIC_LAYER_QUALIFIER_OTSiG].

Once generated the OTSiA/OTSiG Top Connection Connection-End-Points (CEPs), a client-node-edge-point structure MUST be dynamically generated to support the generation of the N number of OTSi Top Connections required to transport the service. N Top OTSi Connctions are thus, generated over the same parent NEP (which only includes PHOTONIC_LAYER_QUALIFIER_OTSi within its supported-layer-qualifier list). The rest of the workflow is equivalent to the one described for single wavelength DSR connectivity-services. Please see the detail graphical description in Figure 7 - 13 .

Figure 7 - 13 200GE DSR Service Provisioning over multi wavelength OTSiA (beyond 100G).

 

7.2.3      Use case 1c: Unconstrained ODU Service Provisioning

[TO BE DEFINED IN NEXT RELEASE]

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

Number

UC1d

Name

Unconstrained PHOTONIC_MEDIA/OTSi Service Provisioning

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 PHOTONIC_MEDIA networking layer. This service can include intermediate regeneration if necessary.

The underlying connection provisioning and management (including lower layer connections e.g., OTS, NMC including intermediate regeneration connections if needed) is performed by the SDN Domain controller.

The path of each lower layer connection (e.g., OCh/OTSi, OMS) across the network topology is calculated by the controller and the connection automatically provisioned.

The “unconstrained” term refers that the TAPI-Client is not allowed to introduce any routing constraint in the service request, thus relays completely into the routing capabilities of the TAPI-Server to select the network resources employed to provide the desired service characteristics.

Moreover, the TAPI-Client is not providing technology specific Traffic-Engineering constrains such time-slot selection at the ODU layer, or optical-spectrum selection for the routing of OTSi connections.

Layers involved

PHOTONIC_MEDIA

Type

Provisioning

Description & Workflow

This UC is implemented following the same workflow described in “Description & Workflow” of UC1a described in section 7.2.1

 

 

7.2.4.1    Expected results

This use case requires the relevant Service Interface Points (SIPs) attached to the corresponding OTSI NEPs are available and exposed by the TAPI server.

The connection generation follows the rules detailed in section 6.1.1 .In this use case it is expected that originally, the ODU and PHOTONIC_MEDIA layers are connect through a transitional link.

Please see the detail graphical description in Figure 7 - 14 :

Figure 7 - 14 OTSi single lambda connecitiy-service.

 

7.2.5      Use case 1e: Unconstrained PHOTONIC_MEDIA/ OTSiA/OTSiG Service Provisioning

Number

UC1d

Name

Unconstrained PHOTONIC_MEDIA/OTSi Service Provisioning

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 PHOTONIC_MEDIA networking layer. This service can include intermediate regeneration if necessary.

The underlying connection provisioning and management (including lower layer connections e.g., OTS, NMC including intermediate regeneration connections if needed) is performed by the SDN Domain controller.

The path of each lower layer connection (e.g., OCh/OTSi, OMS) across the network topology is calculated by the controller and the connection automatically provisioned.

The “unconstrained” term refers that the TAPI-Client is not allowed to introduce any routing constraint in the service request, thus relays completely into the routing capabilities of the TAPI-Server to select the network resources employed to provide the desired service characteristics.

Moreover, the TAPI-Client is not providing technology specific Traffic-Engineering constrains such time-slot selection at the ODU layer, or optical-spectrum selection for the routing of OTSi connections.

Layers involved

PHOTONIC_MEDIA

Type

Provisioning

Description & Workflow

This UC is implemented following the same workflow described in “Description & Workflow” of UC1a described in section 7.2.1

 

 

7.2.5.1    Expected results

This use case requires the relevant Service Interface Points (SIPs) attached to the corresponding OTSIA/OTSIG NEPs are available and exposed by the TAPI server.

The connection generation follows the rules detailed in section 6.1.1 .In this use case it is expected that originally, the ODU and PHOTONIC_MEDIA layers are connect through a transitional link.

This particular case requires the generation of an OTSiA/OTSiG (depending on the monitoring capabilities implemented by the TAPI server) Top Connection between the pair of NEPs connecting the PHOTONIC_MEDIA side of the ODU and PHOTONIC_MEDIA transitional links. These NEPs MUST report within the supported-layer-qualifier list the following types: [PHOTONIC_LAYER_QUALIFIER_OTSi, PHOTONIC_LAYER_QUALIFIER_OTSiA, PHOTONIC_LAYER_QUALIFIER_OTSiG].

Once generated the OTSiA/OTSiG Top Connection Connection-End-Points (CEPs), a client-node-edge-point structure MUST be dynamically generated to support the generation of the N number of OTSi Top Connections required to transport the service. N Top OTSi Connctions are thus, generated over the same parent NEP (which only includes PHOTONIC_LAYER_QUALIFIER_OTSi within its supported-layer-qualifier list). Please see the detail graphical description in Figure 7 - 15 .

 

Figure 7 - 15 OTSiA/OTSiG multi-wavelength connectivity-service.

 

 

7.3      Use case 3: Constrained Provisioning

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

[TO BE DEFINED IN NEXT RELEASE]

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

[TO BE DEFINED IN NEXT RELEASE]

7.3.3      Use case 3c: Include/exclude the path used by other service.

Number

UC3c

Name

Constrained provisioning: Include/exclude the path used by other service.

Technologies involved

Optical

Process/Areas Involved

Planning and Operations

Brief description

This use case consists on the requests of a connectivity service between two Connectivity Service End Points associated to Service Interface points at different layers (DSR, ODU or OTSi). This service is subject to the inclusion/exclusion of the path associated to one or more already provisioned services. This service can include intermediate regeneration if necessary.

The underlying connection generation (including lower layer connections e.g., OCh/OTSi, Photonic Media and regeneration nodes) is made by the SDN Domain controller.

The route of each lower layer connection (e.g., OCh/OTSi, Photonic Media) across the network topology is calculated by the SDN Domain controller considering the constraints introduced in the service request. The route in each layer is recursively calculated from the lower layer to the upper layer, excluding/including ALL those components of the topology shared with the connections created to support the selected service.

For the coroute-inclusion capability, the CS’s Top Connection’s routes MUST share the same potentially shared resources (i.e., links) of the referenced service in all layers from DSR to PHOTONIC_MEDIA_OMS when it applies.

Moreover, the Top Connection’s routes (including the new path when the restoration is triggered) of a CS implementing coroute-inclusion or diversity-exclusion policies, MUST include/exclude the all the potentially shared resources (i.e., links) related to the route objects referenced by all the connections (TopConnections) conforming the referenced CS. This condition MUST be met at any time the TAPI Server in charge of the service, performs a path computation action for the target service i.e., at the provisioning or restoration actions .

In case the referenced connectivity-service’s path changes due to a restoration or any other reroute action and this new path enters in conflict with the conditions impose to any other service referencing it by the coroute-inclusion or diversity-exclusion attribute, the latter is not forced to proactively reroute but if any user or control plane action force it to re-route then the conditions will need to be meet again.

Layers involved

DSR/ODU/PHOTONIC_MEDIA

Type

Provisioning

Description & Workflow

The connectivity-service object sent by the TAPI Client to the Server to request the creation of the service MUST include the coroute-inclusion or diversity-exclusion attributes within .

The connectivity-service/s referenced by the coroute-inclusion or diversity-exclusion attributes MUST be present in the TAPI Server context at the time of the CS provisioning is request. In case, the referenced CS element is invalid, the TAPI Server MUST return an error message in the RESTConf response message, according to the rules included in https://tools.ietf.org/html/rfc8040#section-7 , with the “invalid-value” <error-tag>.

In case the referenced CS by the coroute-inclusion or diversity-exclusion attributes change its route, this service will not change accordingly, in other words, the TAPI server is not aimed to maintain a stateful relation between the services.

This UC is implemented following the same workflow described in “Description & Workflow” of UC1a described in section 7.2.1

 

7.3.3.1    Required parameters

Table 24 complements the information included in the Use Case 1 definition, with the Connectivity-Service attributes required to implement this use case, this implies all attributes and objects included in Section 7.2.1.1 tables is required for this use case too.

 

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

connectivity-service

coroute-inclusion

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

RW

M

  • Reference to an existing ConnectivityService already present in the TAPI server context MUST be valid.

coroute-exclusion

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

RW

M

  • Reference to an existing ConnectivityService already present in the TAPI server context MUST be valid.

 

 


7.4      Use case 5: Use case 5:  1+1 protection with diverse service Provisioning

7.4.1      Use case 5a: 1+1 OLP Client Protection with Diverse Service Provisioning

[TO BE DEFINED IN NEXT RELEASE]

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

Number

UC5b

Name

1+1 OLP Protection with Diverse Service Provisioning

Technologies involved

Optical

Process/Areas Involved

Planning and Operations

Brief description

This use case covers the use of OLPs elements for 1+1 and 1:1 protection services at different layers (OMS, OTSi/OTSiA, DSR).

Three possible protection schemas based on OLP identified, so far, are represented in Figure 7 - 16 .

Figure 7 - 16 UC-5b OLP protection schemas.

1. OMS OLP protection is not intended to be configured by the user, but to be represented by the TAPI server as part of the Photonic_Media layer topology as described in [TAPI-TOP-MODEL-REQ-23] . Thus OMS protection is out of the scope.

2. Line Side OLP protection represents a protection schema where an OLP is placed between the Transponder line ports and two add/drop ports of a ROADM. The OLP components duplicates the incoming signal and implements an Automatic Protection Switch (APS) which switch the traffic between the two Add/Drop ports upon loss of signal conditions (power measurement decrease under a target threshold) in less than 50ms. This is the intended case to be modelled by this UC.

3. Client Side OLP protection is left to further versions of this specification due to low priority.

The TAPI server is responsible of maintaining the SLA condition and triggers the automatic protection/switching actions when the connectivity-service nominal path is being affected by any outage condition which provoke a degradation or interruption of the service.

The protection process MUST be triggered automatically by the TAPI server, however, the TAPI client MUST be notified about the service condition changes through the tapi-notification service. The description of the notification process and its detail Low-Level-Design is out of the scope of this use case definition.

Layers involved

PHOTONIC_MEDIA

Type

Resilience

Description & Workflow

This type of OLP protection ( Line Side OLP ) requires the reservation of two disjoint routes along the Photonic_Media layer for the provisioning of connections to support the 1+1 or 1:1 Connectivity Services.

The TAPI Client SHOULD select two valid SIPs, to be referenced by the CSEPs, which reference two OTSi/Photonic_Media NEPs directly connected to the Line-Side OLP elements, as described in the Connectivity Service example ( Figure 7 - 17 ).

The TAPI Client MAY include the three SIPs mapped to the NMC/Photonic_Media NEPs representing the switching ports of the OLP components (NMC1, NMC2, NMC3 as represented in the Figure), to associated to them different Protection Roles within the CSEPs definition (please note that zEnd peer SIPs, NEPs have been omitted in this explanation for simplicity). These protection roles MAY be in the example PROTECTED (71.D1 - NMC1), WORK (72.D1 - NMC2), PROTECT (73.D1 - NMC3).

Alternatively, the TAPI Client MAY delegate the protection role selection to the TAPI Server during the CS provisioning process and thus, only the two OTSi/Photonic_Media SIPs MUST be referenced within the CS request. In case, the protection role is delegated, the TAPI Client MUST include the preferred-restoration-layer attribute in the CS’s request.

The Connectivity Service object sent to the TAPI Server MUST include the tapi-connectivity:connectivity-service/tapi-topology:resilience-type/protection-type attribute to specify which type of protection service is requested. Depending on the type of protection this attribute MAY be set with the following values:

  • ONE_PLUS_ONE_PROTECTION: Double selective receiving, dual transmitting and selective receiving. The optical power from Tx are split with a ratio of 50:50 on the main route and the standby route, which means both the main and standby routes are in use no matter whether there is a fault in the main route.
  • ONE_FOR_ONE_PROTECTION: Selective receiving election, selective transmitting and selective receiving mode. There are a main route and a standby route between the two sites.

This UC is implemented following the same workflow described in “Description & Workflow” of UC1a described in section 7.2.1

7.4.2.1    Expected result

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

Figure 7 - 17 UC-5b OLP TAPI Connectivity-Service low-level description.

Once the CS is created, the TAPI Server is responsible of implementing the Switch control among the connections generated to support the different protection schemas (1+1, 1:1), which MUST provide automatic switch control between the working and protection connections in less than 50ms.

The requested Photonic_Media/OTSi CS triggers the creation of:

  • Protected OTSi Top Connection .
  • Protected NMC Top Connection : which has two routes and implements switch-control and sub-switch-control based on its aEnd and zEnd lower-connections switch-control.
    • aEnd OLP site NMC lower connection : implementing the switch-control between aEnd working and protection CEPs (NMC-2, NMC-3).
    • N intermediate NMC lower connections : without switch control (connections along the ROADM nodes)
    • zEnd OLP site NMC lower connection : implementing the switch-control between aEnd working and protection CEPs (respective CEPs to NMC-2, NMC-3 in the other zEnd OLP).

In case the service is 1:1 PROTECTION:

  • selected-connection-end-points: NMC-1, NMC-2 (and the respective CEPs in zEnd) switch between NMC-2 and NMC-3 when the conditions changes.
  • selected-route: Route-A, and switch to Route-B, when the conditions changes

In case the service is 1+1 PROTECTION:

  • selected-connection-end-points: NMC-1, NMC-2, NMC-3 (and the respective CEPs in zEnd) initially when both routes are active, and switch between NMC-2 and NMC-3 when the conditions changes.
  • selected-route: Route-A, Route-B initially when both routes are active, and switch to one of them, when the conditions changes.

For both cases:

  • sub-switch-control: Referencing aEnd, zEnd OLP site NMC lower connection switch-control objects.

 

7.4.2.2    Required parameters

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

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

connectivity-service

 

 

 

 

Attribute

Allowed Values/Format

Mod

Sup

Notes

resiliency-type

{" protection-type ": [ONE_FOR_ONE_PROTECTION, ONE_PLUS_ONE_PROTECTION]}

RW

M

  • Provided by tapi-client

 

preferred-restoration-layer

[PHOTONIC_MEDIA]

RW

M

  • Provided by tapi-client

 

reversion-mode

["REVERTIVE", "NON-REVERTIVE"]

RW

M

  • Provided by tapi-client

restore-priority

"[0-9]+"

RW

O

  • Provided by tapi-client

hold-off-time

"[0-9]{4}"

RW

O

  • Provided by tapi-client

wait-to-revert-time

"[0-9]{4}"

RW

O

  • Provided by tapi-client

max-switch-times

"[0-9]{2}"

RW

O

  • Provided by tapi-client

is-coordinated-switching-both-ends

[true, false]

RW

O

  • Provided by tapi-client

is-lock-out

[true, false]

RW