Child pages
  • TAPI Contributions and Presentations

SUE Projects:1306 ONF Misc:5-Templates:5-21 MS Word - Spec:links:ONF-horiz-med.tif  

 

 

 

 

 

 

 

 

 

 


­ ONF Document Type: Technical Recommendation

ONF Document Name: Functional Requirements for Transport API
 

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

2275 E. Bayshore Road, Suite 103, Palo Alto, CA 94303

www.opennetworking.org

 

©2016 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.   

Contents

1 Introduction

1.1 Purpose

1.2 Scope

1.3 References

1.4 Abbreviations

1.5 Terms and Definitions

1.6 Conventions

2 Functional Architecture

3 Functional Requirements

3.1 Topology Service

3.1.1 Topology Retrieval APIs

3.2 ConnectivityService

3.2.1 Connectivity Retrieval APIs

3.2.2 Connectivity Request APIs

3.3 Path Computation Service

3.3.1 Path Computation Request APIs

3.4 Virtual Network Service

3.4.1 Virtual Network Retrieval APIs

3.4.2 Virtual Network Request APIs

3.5 Notification Service

3.5.1 Notification Subscription and Filtering APIs

3.5.2 Notification Message Types

3.6 TAPI Data Types

4 Appendix A: Transport API Concepts Overview

4.1 Context

4.2 Node and Topology Aspects of Forwarding Domain

4.3 Hierarchical Control Domains and Contexts

4.4 Topology Traversal using APIs

4.5 Service, Connection and Route

4.6 NodeEdgePoint v/s ServiceInterfacePoint v/s ConnectionEndPoint

5 Appendix A2: Support of Node Constraints

5.1 TAPI 1.0 Node Model

5.2 TAPI 2.0 Node Rules

5.3 More Complex Modeling

6 Appendix A3: Support of Resilience

6.1 Single-domain e2e linear protection/restoration

6.1.1 Domain Topology

6.1.2 ConnectivityService Creation

6.2 Multi-domain segment linear protection/restoration

6.2.1 Multi-domain Topology

6.2.2 Multi-domain ConnectivityService Creation with Local Resilience

6.3 Multi-domain e2e linear protection/restoration

6.3.1 Multi-domain Topology

6.3.2 Multi-domain ConnectivityService Creation with e2e linear protection

6.4 Retrieving Status

7 Appendix A4: Virtual Network Service

1.1 OIF Virtual Transport Network Service

1.2 TAPI Support of Virtual Network Services

8 Appendix B: Transport API Examples Use cases

8.1 10GE EPL Service over ODU2 Connection over 100G OTN network

8.2 1G EVPL Service over ODU0 Connection over 100G OTN network

8.3 Var-rate EVPL Service over EVC Connection over 100G OTN network

8.4 EVPL Service with Load Balancing

8.5 Anycast EVPL Service

9 Appendix C: Multi-layer and Multi-domain Use cases

9.1 Multi-layer and Multi-domain Topology Initialization

9.2 Multi-layer and multi-domain services/connections

9.3 Further work

10 Appendix D: Transport API Information Model Skeleton

11 Contributors

12 Changes from TAPI FRD 1.0

 

List of Figures

 

Figure 1: T-API Artifacts - ONF/OSSDN Project Dependencies

Figure 2: Transport API Functional Architecture

Figure 3 : Simple Physical Network Example

Figure 4: Shared Contexts - Architecture perspective

Figure 5: Shared Contexts & Topology

Figure 6: Topological Decomposition of Node

Figure 7: Recursive Topological Decomposition of Node

Figure 8: Node/Topology perspectives of recursively partitioned Forwarding Domain (FD)

Figure 9: View of Controller-1 Context based on Views exported by Controllers 2 & 3

Figure 10: Views of Controller-2 Contexts

Figure 11: Views of Controller-3 Contexts

Figure 12: API Client’s View of Controller-1 Context without retrieving Topology details

Figure 13: API Client’s View of Controller-1 Context by retrieving top-most level of Topology

Figure 14: API Client’s View of Controller1 Context by retrieving 2 levels of Topology details

Figure 15: API Client’s View of Controller-1 Context by retrieving 3 levels of Topology details

Figure 16: Service & Connections from Controller-1 perspective

Figure 17: Service & Connections from Controller-2 perspective

Figure 18: Service & Connections from Controller-3 perspective

Figure 19: Example Physical Network Topology

Figure 20: Example 10GE EPL Service over ODU2

Figure 21: 10G EPL - Customer View of Connectivity

Figure 22: 10G EPL - Provider’s View of Topology exported to the Customer

Figure 23: 10G EPL - Provider’s View of Service/Connections exported to the Customer

Figure 24: 10G EPL - Customer's view of Service/Connectivity

Figure 25: Example 1G EVPL Service over ODU0

Figure 26: 1G EVPL - Customer View of Connectivity

Figure 27: 1G EVPL - Provider’s View of Topology exported to the Customer

Figure 28: 1G EVPL - Provider’s View of Service/Connections exported to the Customer

Figure 29: 1G EVPL - Customer's view of Service/Connectivity

Figure 30: EVPL Service with Load Balancing

Figure 31: Example Anycast EVPL Service

Figure 32: Multi-layer and Multi-domain Example Network Configuration

Figure 33: Network Topology in Controller 1

Figure 34: Multi-layer and Multi-domain service/connection setup (Option A)

Figure 35: Multi-layer and Multi-domain service/connection setup (Option B)

Figure 36: Topology instance diagram after service/connection setup

Figure 37: Transport API Information Model Skeleton

Figure 38: Topology Service Skeleton

Figure 39: ConnectivityService Skeleton

Figure 40: Virtual Network Service Skeleton

Figure 41: Path Computation Service Skeleton

List of Functional Requirement Tables

 

TAPI_FR 1: Get Topology List

TAPI_FR 2: Get Topology Details

TAPI_FR 3: Get Node Details

TAPI_FR 4: Get Link Details

TAPI_FR 5: Get Node Edge Point Details

TAPI_FR 6: Get ServiceInterfacePoint List

TAPI_FR 7: Get ServiceInterfacePoint Details

TAPI_FR 8: Get ConnectivityService List

TAPI_FR 9: Get ConnectivityService Details

TAPI_FR 10: Get Connection Details

TAPI_FR 11: Get Connection End Point Details

TAPI_FR 12: Create ConnectivityService

TAPI_FR 13: Update ConnectivityService

TAPI_FR 14: Delete ConnectivityService

TAPI_FR 15: Compute P2P Path

TAPI_FR 16: Optimize P2P Path

TAPI_FR 17: Get Virtual Network Service List

TAPI_FR 18: Get Virtual Network Service Details

TAPI_FR 19: Create Virtual Network Service

TAPI_FR 20: Delete Virtual Network Service

TAPI_FR 21: Discover Supported Notification Types

TAPI_FR 22: Create   Notification Subscription

TAPI_FR 23: Modify   Notification Subscription

TAPI_FR 24: Delete   Notification Subscription

TAPI_FR 25: Suspend   Notification Subscription

TAPI_FR 26: Resume   Notification Subscription

TAPI_FR 27: Retrieve   Notification Records

TAPI_FR 28: Object Creation Notification

TAPI_FR 29: Object Deletion Notification

TAPI_FR 30: Attribute Value Change Notification

TAPI_FR 31: State Change Notification

TAPI_FR 32: Layer Protocol Name

TAPI_FR 33: Capacity (Fixed Bandwidth)

TAPI_FR 34: Capacity (Profile)

TAPI_FR 35: Administration State

TAPI_FR 36: Operational State

TAPI_FR 37: Lifecycle State

TAPI_FR 38: Port Role

TAPI_FR 39: Port Direction

TAPI_FR 40: Termination Direction

TAPI_FR 41: ServiceInterfacePoint TRI format

TAPI_FR 42: Service Type

TAPI_FR 43: Connectivity Constraints

TAPI_FR 44: Virtual Network Service Constraints

TAPI_FR 45: Traffic Matrix

TAPI_FR 46: Path Optimization Constraint

TAPI_FR 47: Path Objective Function

TAPI_FR 48: Notification-Header

TAPI_FR 49: Notification-Type

TAPI_FR 50: Object-Type

TAPI_FR 51: Notification-Source-Indicator


1        Introduction

The software defined networking (SDN) paradigm revolves around separation of forwarding/data plane and control plane, logically centralized control and application-focused programmable interfaces. In transport networks where logically-centralized control/management and control-data separation are not new concepts and the network-control function and behavior are well-understood and established, standardizing application programmer’s interfaces (APIs) to the network control functions become important. 

1.1        Purpose

The purpose of this document is to specify the information that is relevant to an application programmer’s interface (API) to transport network-control functions and serve as a “Functional Requirements” (FR) document for the transport API work in ONF.

Note: this document provides a guideline for understanding the Transport API, however the API itself is specified through the T-API Software Development Kit (SDK) and where there are differences the SDK will take precedence.

Since the APIs are defined at interface boundaries and are intended to mask the need to understand   the internal architectures on either side of the interface boundary, the focus has been to define purpose-specific use case scenarios from an application point of view treating the API provider as a “black box”. These application use cases have been used to drive the API requirements as well as to harmonize, generalize and normalize the API specifications. To facilitate the understanding of these requirements, some of the use cases are described in the appendices.

Although these requirements are based upon several use cases that were deemed key for the application domain, the APIs have been developed with the intent of not precluding their being employed by additional valid application use cases.

The requirements specified in this document are intended to drive the detailed UML information model specifications, from which the YANG/JSON schema and Swagger APIs are generated. The following figure illustrates the inter-relationships between various T-API project artifacts:

Figure 1 : T-API Artifacts - ONF/OSSDN Project Dependencies

 

1.2        Scope

This issue of the document specifies APIs for following transport network controller services:

-           Topology Service

-           Connectivity Service

-           Path Computation Service

-           Virtual Network Service

-           Notification Service

-           OAM Service

For the purposes of this document, it is assumed that access control and policy details are conveyed via a distinct/orthogonal interface.  It is understood that all API requests would be subject to filtering and scoping based on the privileges assigned to the calling entity and these would be based on business contracts as well as security and organizational roles. Application of such policy constraints and filtering to the API requests and responses is out of scope for this document. In other words, the API considerations in this document are from the perspective of the most privileged super-user.

1.3        References

ONF TR-512

Core Information Model (v1.2) – Note: CIM v1.3 can be found on github

ONF TR-502

SDN Architecture

ONF TR-516

Framework for SDN: Scope and Requirements

ONF2015.276.xx

SDN Notifications Framework (draft)

ONF2015.320.xx

Transport API IM Concepts

ONF2015.381.xx

Transport API Examples

ONF2015.338.xx

State Information Model

ONF2015.323.xx

LTP/End-Point Directionality

1.4        Abbreviations

API

Application Programmer’s Interface

IM

Information Model

OTCC

Open Transport Config & Control Project

OTN

Optical Transport Network

OAM

Operations, Administration and Maintenance

MPLS-TP

MPLS-Transport Profile

EMS/NMS

Element/Network Management System

ASON/GMPLS

Automatic Switched Optical Network/Generalized MultiProtocol Label Switching

SLA

Service Level Agreement

NE

Network Element

FD

Forwarding Domain

NCD

Network Control Domain

EP

End Point

LTP

Logical Termination Point

T-API/TAPI

Transport API

TRI

Transport Resource Identifier

1.5        Terms and Definitions

This section defines some key terms that aid in understating the requirements. More information is provided in the appendices and it is recommended that the reader familiarize themselves with the basic concepts, constructs and use cases described in those sections.

In general, the T-API uses terminology that is familiar to the transport network management industry, but maps to constructs defined in the ONF Core Information Model in form of purpose-specific realizations. So it must be noted that these definitions are neither authoritative nor exhaustive, and the reader should refer to the realized/mapped entities defined in ONF Core Information Model document.

Also it should be noted that API IM relates to information exchanged over an interface and the entity definitions are intended to provide a logical structure for encapsulating information that is exchanged, and not intended to specify the information model patterns for implementations on either side of the interface.

Context (API Context)

The T-API defines the scope of control, interaction and naming that a particular T-API provider or client application has with respect to the information exchanged over the interface. This Context is shared between the API provider and its client.

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 .

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 ( NodeEdgePoint ) belonging to those Network Resources and the potential to enable forwarding of information between those edge ports.

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 NodeEdgePoints of the associated Nodes .

  NodeEdgePoint

The T-API NodeEdgePoint 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 .

ServiceInterfacePoint

The T-API ServiceInterfacePoint 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. ServiceInterfacePoint have a mapping relationship ( one-to-one, one-to-many, many-to-many ) to NodeEdgePoints . [1]

ConnectionEndPoint

The T-API ConnectionEndPoint represents the ingress/egress port aspects that access the forwarding function provided by the Connection . The ConnectionEndPoints have a client-server relationship with the NodeEdgePoints .

ConnectivityService

The T-API ConnectivityService represents an “intent-like” request for connectivity between two or more ServiceInterfacePoints . As such, ConnectivityService is a container for connectivity request details and is distinct from the Connection that realizes the request

ConnectivityService-End-Point?

Connection

The T-API Connection represents an enabled (provisioned) potential for forwarding (including all circuit and packet forms) between two or more NodeEdgePoints of a Node . The T-API Connection is terminated by ConnectionEndPoints which are clients of the associated NodeEdgePoints . As such, the Connection is a container for provisioned connectivity that tracks the state of the allocated resources and is distinct from the ConnectivityService request.

Route (Connection Route)

The T-API Route represents the route of a Connection through the Nodes in the underlying Topology. It is described as a list of ConnectionEndPoints . [2]

Path

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

Virtual Network Service

The T-API VirtualNetworkService   (VNS) represents a request for creation and offering of a virtual network Topology that maps two or more ServiceInterfacePoints , by an API-provider to an API client in accordance with agreements reached between them (e.g., satisfying the users’ objectives). As such, VirtualNetworkService is a container for virtual network Topology request details and is distinct from the Topology that realizes the request.

1.6        Conventi ons

This document uses the keywords "may" and "must" to qualify optional and mandatory requirements.


2        Functional Architecture

The Transport API is defined in the background context of network programmability and applies SDN principles to enable cost reduction, innovation and reduced time to market of new services. It aims to achieve these goals by providing programmable access to typical transport SDN Controller functions. The Transport API abstracts a common set of control plane functions, such as Network Topology, Connectivity Requests, Path Computation and Network Virtualization to a set of Service interfaces.

The API is defined to be applicable on the interface between a Transport SDN controller “Black Box” and its client application. The actors involved in the information exchange over this interface include transport network provider domain controllers in the role of producers and the transport network application systems in the role of the consumers. The transport network application systems could be either a business client system (which itself may include some control functions) or the network operator’s upper level control, orchestration and/or operations systems. This includes privileged application systems that would expect access to internal views of the network model and states using these same set of APIs - for example, usage of topology API to access abstract/virtual network topologies provided to business clients as well the underlying actual network topology and entities to which the abstract /virtual entities are mapped. The T-API is also intended to be equally applicable between the controllers within a transport controller recursive hierarchy.

It is understood that the API is executed within a shared Context between the API provider and its client application. A shared Context models everything that exists in an API provider to support a given API client. The negotiation and setup of the shared Context is outside the T-API scope, but is expected to minimally involve agreement on ServiceInterfacePoints , its naming (TRI) and its capabilities.

Typically, the shared Context setup also includes association attributes to establish identity and security that permit secure client-provider communication sessions. A session is the mechanism [3] that supports information exchange between specific instances of an API client and an API provider within a shared Context that has been secured by appropriate authentication and security credentials and prevents unauthorized access. Similar to user login, the session normally begins with an exchange of identity and security credentials, followed by agreement on an initial state, much of which may be re-stored from prior sessions.  During the session, the API client may invoke services on and modify the state of resources within the shared Context . Each information exchange should be attributable to a session, for example in an audit log. A session may continue indefinitely, or end with an explicit logout, a failure, or a timeout. Since the shared Context supports only one session (or vice-versa), the session identification and association with the shared Context is implicit. 

T hus a shared Context determines the makeup of the network resource abstraction instances over which the API operates. For example, the API client could

  • Request retrieval of the ServiceInterfacePoints in the shared Context
  • Request creation of a ConnectivityService between the ServiceInterfacePoints – these operations can be performed without the knowledge of Network Topology or with the knowledge of the Topology (using Topology retrieval APIs)
  • Request creation/modification of  Virtual Network Topology within the shared context
  • Request retrieval of the (Virtual) Network Topology   - either provider-assigned (by offline/external means) or client-created- (using VN Service API)  within the shared context
  • Subscribe to notification of events within the shared Context

Figure 2 : Transport API Functional Architecture

 


3        Functional Requirements

3.1     Topology Service

The Topology Service allows an API client to retrieve topological information that is within its shared Context.

3.1.1 Topology Retrieval APIs

TAPI_FR 1 : Get Topology List

Description

  • Returns list of top-level Topology instances directly scoped by the Context
  • This also includes details for each Topology including references to lower-level Nodes  and Links encompassed by the Topology as allowed by policy

Pre-conditions

 

Inputs

  • Retrieve Scope Filter: LayerProtocolName List : Enumeration value

-           If set/non-empty, the API call will return references to only those Topology instances that support at least one of the specified layer protocols

Outputs

List of Topology entities and details for each including:

  • List of IDs, Names, User-Labels and Extensions (if any)
  • List of encompassed Nodes indexed by Layer including Node details
  • List of encompassed Links indexed by Layer including Link details

Notifications

 

Error-conditions

 

Post-conditions

 

 

TAPI_FR 2 : Get Topology Details

Description

  • Returns attributes of the Topology identified by the provided inputs.
  • This includes references to lower-level Nodes  and Links encompassed by the Topology

Pre-conditions

 

Inputs

  • Topology ID or Name : String

-           When NULL is provided, this API call should return an error.

  • Scope Filter: LayerProtocolName List : Enumeration value

-           If set/non-empty, the API call will return references to only those encompassed Nodes and Links that support at least one of the specified layer protocols

Outputs

  • List of IDs, Names, User-Labels and Extensions (if any)
  • List of encompassed Nodes indexed by Layer including Node details
  • List of encompassed Links indexed by Layer including Link details

Notifications

 

Error-conditions

 

Post-conditions

 

 

TAPI_FR 3 : Get Node Details

Description

  • Returns attributes of the Node identified by the provided inputs.
  • This includes references to NodeEdgePoints aggregated by the Node
  • This also includes attributes representing the identification/naming, states and capabilities of the Node .

Pre-conditions

 

Inputs

  • Topology ID or Name : String

-           ID/name of the containing Topology that owns this Node

-           When NULL is provided, this API call should return an error.

  • Node ID or Name : String

-           When NULL is provided, this API call should return an error condition

  • Scope Filter: LayerProtocolName List : Enumeration value

-           If set/non-empty, the API call will return references to only those aggregated NodeEdgePoints that support at least one of the specified layer protocols

Outputs

  • List of IDs, Names, User-Labels and Extensions (if any)
  • List of supported LayerProtocolName s
  • Administrative, Operational and Lifecycle States
  • Transfer characteristics such as Cost, Timing, Integrity and Capacity
  • List of references to aggregated NodeEdgePoints indexed by Layer

Notifications

 

Error-conditions

 

Post-conditions

 

 

TAPI_FR 4 : Get Link Details

Description

  • Returns attributes of the Link identified by the provided inputs.
  • This includes references to NodeEdgePoints terminating the Link .
  • This includes references to the Nodes associated by the Link .
  • This refers to an abstract/logical entity and could represent virtual links and/or compound links (internally aggregate lower-level serial/parallel links)

Pre-conditions

 

Inputs

  • Topology ID or Name : String

-           ID/name of the containing Topology that owns this Link

-           When NULL is provided, this API call should return an error.

  • Link ID or Name : String

-           When NULL is provided, this API call should return an error

  • Scope Filter: LayerProtocolName List : Enumeration value

-           If set/non-empty, the API call will return references to only those terminating NodeEdgePoints that support at least one of the specified layer protocols

Outputs

  • List of IDs, Names, User-Labels and Extensions (if any)
  • Administrative, Operational, and Lifecycle States
  • List of supported LayerProtocolName s
  • Transfer characteristics such as Cost, Timing, Integrity and Capacity
  • Risk characteristics including shared-risk
  • Validation characteristics - Validation describes the various adjacent discovery and reachability verification protocols. Also may describe Information source and degree of integrity.
  • List of following details for every NodeEdgePoint terminating the Link

         Role of the terminating NodeEdgePoint in the context of the Link

         Direction of the terminating NodeEdgePoint in the context of the Link

         Reference to terminating NodeEdgePoint

         List of references to associated Nodes

Notifications

 

Error-conditions

 

Post-conditions

 

 

TAPI_FR 5 : Get NodeEdgePoint Details

Description

  • Returns attributes of the NodeEdgePoint identified by the provided inputs.

Pre-conditions

 

Inputs

  • Topology ID or Name : String

-           ID/name of the containing Topology that owns this Link

-           When NULL is provided, this API call should return an error.

  • Node ID or Name : String

-           ID/name of the containing Node that owns or references this NodeEdgePoint

-           When NULL is provided, this API call should return an error condition

  • NodeEdgePoint ID or Name : String

-           When NULL is provided, this API call should return an error

  • Scope Filter: LayerProtocolName List : Enumeration value

-           If set/non-empty, the API call will return only the specified Layer-Protocol attribute-details indexed by Layer

Outputs

  • List of IDs, Names, User-Labels and Extensions (if any)
  • Administrative, Operational, and Lifecycle States
  • List of supported Layer-Protocols including attribute-details indexed by Layer

Notifications

 

Error-conditions

 

Post-conditions

 

 

3.2     ConnectivityService

The ConnectivityService allows an API client to retrieve connectivity information and request ConnectivityService within its shared Context.

3.2.1 Connectivity Retrieval APIs

TAPI_FR 6 : Get ServiceInterfacePoint List

Description

  • Returns list of ServiceInterfacePoints
  • This includes the ServiceInterfacePoints are being used in a ConnectivityService request as well as those that are not being used
  • This also includes the attribute details for each ServiceInterfacePoint

-           including references to the mapped NodeEdgePoint .

Pre-conditions

 

Inputs

  • Retrieve Scope Filter: LayerProtocolName List : Enumeration value

-           If set/non-empty, the API call will return references to only those encompassed ServiceInterfacePoints that support at least one of the specified layer protocols

Outputs

List of ServiceInterfacePoints indexed by Layer and details for each including:

  • List of IDs, Names, User-Labels and Extensions (if any)
  • Lifecycle State
  • List of supported LayerProtocolNames including attribute-details indexed by Layer
  • Reference to the NodeEdgePoints mapped to this ServiceInterfacePoint

Notifications

 

Error-conditions

 

Post-conditions

 

 

TAPI_FR 7 : Get ServiceInterfacePoint Details

Description

  • Returns attributes of the ServiceInterfacePoint identified by the provided inputs.

-           including references to the mapped NodeEdgePoint .

Pre-conditions

 

Inputs

  • ServiceInterfacePoint ID or Name : String

-           When NULL is provided, this API call should return an error condition

Outputs

  • List of IDs, Names, User-Labels and Extensions (if any)
  • Lifecycle State
  • List of supported LayerProtocolNames including attribute-details indexed by Layer
  • Reference to the NodeEdgePoint mapped to this ServiceInterfacePoint

Notifications

 

Error-conditions

 

Post-conditions

 

 

TAPI_FR 8 : Get ConnectivityService List

Description

  • Returns list of ConnectivityService entities that represent the connectivity requests that were received
  • This also includes attribute details for each ConnectivityService including

         References to ServiceInterfacePoints terminating the Service

         Optionally References to any Connections realizing the ConnectivityService  

Pre-conditions

 

Inputs

  • Retrieve Scope Filter: LayerProtocolName List : Enumeration value

-           If set/non-empty, the API call will return references to only those encompassed ConnectivityServices that support at least one of the specified layer protocols

  • Include Connections : true or false

Outputs

List of ConnectivityServices indexed by LayerProtocolName and details for each including:

  • List of IDs, Names, User-Labels and Extensions (if any)
  • Administrative, Operational, and Lifecycle States
  • Connectivity Constraints including

         Required Constraints such as Capacity

         Optional Constraints such as Layer, Latency, Cost, etc.

  • List of following details for every ServiceInterfacePoint associated with the ConnectivityService

         Role of the terminating ServiceInterfacePoint in the context of the ConnectivityService

         Directionality of the terminating ServiceInterfacePoint in the context of the ConnectivityService

         Reference to terminating ServiceInterfacePoint

  • Optionally List of Connections realizing the ConnectivityService

Notifications

 

Error-conditions

 

Post-conditions

 

 

TAPI_FR 9 : Get ConnectivityService Details

Description

  • Returns attributes of the ConnectivityService entity identified by the provided inputs.
  • This includes references to ServiceInterfacePoints terminating the ConnectivityService .
  • This optionally includes references to any Connections realizing the ConnectivityService .

Pre-conditions

 

Inputs

  • Service ID or Name : String

-           When NULL is provided, this API call should return an error condition

  • Include Connections : true or false

Outputs

  • List of IDs, Names, User-Labels and Extensions (if any)
  • Administrative, Operational, and Lifecycle States
  • Connectivity Constraints including

         Required Constraints such as Capacity

         Optional Constraints such as Layer,  Latency, Cost, etc.

  • List of following details for every ServiceInterfacePoint associated with the ConnectivityService

         Role of the terminating ServiceInterfacePoint in the context of the Service

         Directionality of the terminating ServiceInterfacePoint in the context of the Service

         Reference to terminating ServiceInterfacePoint

  • Optionally List of Connections realizing the ConnectivityService

Notifications

 

Error-conditions

 

Post-conditions

 

 

TAPI_FR 10 : Get Connection Details

Description

  • Returns attributes of the Connection entity identified by the provided inputs.
  • This includes references to ConnectionEndPoints terminating the Connection .
  • This includes references to Routes in the underlying Topology .
  • This includes reference to the Node containing this Connection .

Pre-conditions

 

Inputs

  • Service ID or Name : String

-           ID/name of the containing ConnectivityService that requested this Connection

-           When NULL is provided, this API call should return an error condition

  • Connection ID or Name : String

-           When NULL is provided, this API call should return an error condition

Outputs

  • List of IDs, Names, User-Labels and Extensions (if any)
  • Operational, and Lifecycle States
  • Connectivity Constraints including

         Required Constraints such as Capacity

         Optional Constraints such as Layer,  Latency, Cost, etc.

  • Validation characteristics
  • Reference to the parent (containing) Node
  • List of following details for every ConnectionEndPoint associated with the Connection

         Role of the terminating ConnectionEndPoint in the context of the Connection

         Directionality of the terminating ConnectionEndPoint in the context of the Connection

         Reference to terminating ConnectionEndPoint

  • List of Routes of the specified Connection and details of each including

         List of references to lower-level ConnectionEndPoints that describe the Route of the specified Connection through the Nodes in the underlying Topology

Notifications

 

Error-conditions

 

Post-conditions

 

 

TAPI_FR 11 : Get Connection End Point Details

Description

  • Returns attributes of ConnectionEndPoint identified by the provided inputs.
  • This includes references to the server and client (if any) NodeEdgePoints for this ConnectionEndPoint .
  • This includes references to peer (if any) ConnectionEndPoint that is connected to this ConnectionEndPoint .

Pre-conditions

 

Inputs

  • Service ID or Name : String

-           ID/name of the containing ConnectivityService that requested this Connection

-           When NULL is provided, this API call should return an error condition

  • Connection ID or Name : String

-           ID/name of the containing Connection that owns or references this ConnectionEndPoint

-           When NULL is provided, this API call should return an error condition

  • ConnectionEndPoint ID or Name : String

-           When NULL is provided, this API call should return an error condition

Outputs

  • List of IDs, Names, User-Labels and Extensions (if any)
  • Operational and Lifecycle State
  • List of supported LayerProtocolName s including attribute-details indexed by Layer
  • Reference to the Server (containing) and Client (if any) NodeEdgePoint
  • Reference to the Peer (if any) ConnectionEndPoint

Notifications

 

Error-conditions

 

Post-conditions

 

 

3.2.2 Connectivity Request APIs

TAPI_FR 12 : Create ConnectivityService

Description

  • Causes creation of a ForwardingConstruct representing the ConnectivityService request to connect the ServiceInterfacePoints within the shared Context between API Client and  Provider
  • Returns Service ID to be used as reference for future actions
  • Initial definition will be for a basic point-to-point bidirectional service

Pre-conditions

  • Requestor/Client has visibility of the set of ServiceInterfacePoints between which connectivity is desired within the Context
  • Requestor/Client has information about the types of connectivity available and constraints it can specify such as Service Level
  • Requestor/Client may be aware of other existing ConnectivityServices and their IDs

Inputs

  • List of following details for every ServiceInterfacePoint for the ConnectivityService

         Role of the terminating ServiceInterfacePoint in the context of the Service

         Directionality of the terminating ServiceInterfacePoint in the context of the Service

         Reference (Name/ID) to terminating ServiceInterfacePoint

         Optionally the Layer of the ServiceInterfacePoint if it supports multiple layers  

  • Connectivity Constraints including

         Required Constraints such as Capacity

         Optional Constraints such as Layer,  Latency, Cost, etc.

  • Topology Constraints
  • Resilience Constraints
  • Start Time & End Time

Outputs

  • Service ID
  • Operational State
  • Lifecycle State
  • Confirmation of Service Characteristics : See above inputs

Notifications

  • ObjectCreation notifications on ConnectivityService , associated/created Connections and ConnectionEndPoints
  • AttributeValueChange notifications on affected ServiceInterfacePoints
  • StateChanges on related State attributes in the affected objects

Error-conditions

Service not supported

Service input not supported

Endpoint not recognized

Post-conditions

 

 

TAPI_FR 13 : Update ConnectivityService

Description

  • Causes modification of an existing ForwardingConstruct representing the ConnectivityService request identified by the inputs
  • Returns confirmation or rejection of modification

Pre-conditions

  • Requestor/Client already knows the existing Service ID
  • Requestor/Client has information about the types of Service Characteristics that can be modified

Inputs

  • Service ID or Name

-           When NULL is provided, this API call should return an error condition

  • Connectivity Constraints including

         Required Constraints such as Capacity

         Optional Constraints such as Layer,  Latency, Cost, etc.

  • Start Time & End Time

Outputs

  • Success/Failure
  • Operational State
  • Lifecycle State
  • Confirmation of Service Characteristics : See inputs above

Notifications

  • AttributeValueChange notifications on ConnectivityService , associated/affected Connections , ConnectionEndPoints and ServiceInterfacePoints
  • May also result in ObjectCreation and/or  ObjectDeletion notifications on associated/affected Connections and/or ConnectionEndPoints
  • StateChanges on related State attributes in the affected objects  

Error-conditions

Modification could not be supported

Modification parameter not understood

Modification not allowed

Post-conditions

ConnectivityService modified

 

TAPI_FR 14 : Delete ConnectivityService

Description

  • Causes deletion of an existing ConnectivityService
  • Deletes all associated Connections that were owned/created by the ConnectivityService

Pre-conditions

  • Requestor/Client already knows the existing Service ID

Inputs

  • Service ID or Name: String

-           When NULL is provided, this API call should return an error condition

Outputs

  • ID of the deleted ConnectivityService

Notifications

  • ObjectDeletion notifications on ConnectivityService , associated/deleted Connections and ConnectionEndPoints
  • AttributeValueChange notifications on affected ServiceInterfacePoints
  • StateChanges on related State attributes in the affected objects

Error-conditions

 

Post-conditions

ConnectivityService deleted

3.3     Path Computation Service

The APIs in this section have been defined making certain assumptions on the division of responsibilities and sequence flow of interactions between different T-API Service interfaces. For example, it is assumed that a connection control module that handles the ConnectivityService request, is  in charge of the management and implementation of the Connections in terms of real resource commitment for the routes ( Paths ) of an Connection . In contrast, a routing control module that handles the PathComputationService requests (from the internal connection-control module or external applications) is responsible for computing and providing the Paths for a potential Connection as output.

3.3.1 Path Computation Request APIs

TAPI_FR 15 : Compute P2P Path

Description

Path computation can be called in the context of  service request since path computation is provided in a domain according to the policy which has to refer to specification of service for which the path computation request is required.

The client side of the API can request the server side of the API to compute a single path or a batch of paths with consideration of a set of constraints

Pre-conditions

The server side of this API should have the topology information (including TE information) of the network in which the path computation applies. Includes  Connectivity matrix, port label restriction ( only applicable to optical layer path computation)

Inputs

  • List of following details for every [4] ServiceInterfacePoint for the ConnectivityService

         Role [5] of the terminating ServiceInterfacePoint in the context of the Service

         Directionality of the terminating ServiceInterfacePoint in the context of the Service

         Reference (Name/ID) to terminating ServiceInterfacePoint

         Optionally the Layer of the ServiceInterfacePoint if it supports multiple layers  

  • Routing (Connectivity) Constraints including

         Required Constraints such as Capacity

         Optional Constraints such as Layer,  Latency, Cost, etc.

  • Objective function

Outputs

List of paths computed containing following information (only “one” if shouldComputeConcurrentPaths is false)

  • Path identifier (identifier of the calculated route )
  • Routing constraints (Description of connectivity constraints that are met)
  • Path which is an ordered list of TE Links – described either as strict hops (NodeEdgePoints) or loose hops(Nodes )

Notifications

  • ObjectCreation notifications on computed /created Paths

Error-conditions

Cause of failure

Post-conditions

 

 

TAPI_FR 16 : Optimize P2P Path

Description

A connection can be reconfigured to meet new constraints and achieve path optimization via this API. Reconfiguration may involve intermediate-point changes and route changes

Pre-conditions

The server side of this API should have the topology information (including TE information) of the network in which the path computation applies

Inputs

  • Path Id:  Identifier of path to be modified
  • Connection Id: (optional) Identifies resources in use for the Connection for the path  being optimized
  • Routing (Connectivity) Constraints including

         Required Constraints such as Capacity

         Optional Constraints such as Layer,  Latency, Cost, etc.

  • Objective Function
  • Optimization Constraint

Outputs

List of paths computed containing following information (only “one” if shouldComputeConcurrentPaths = false)

  • Path identifier (identifier of the calculated route )
  • Routing constrains (Description of connectivity constraints that are met)
  • Path which is an ordered list of (TE Links) – described either as strict hops (NodeEdgePoints) or loose hops(Nodes )

Notifications

  • AttributeValueChange   notifications on affected Paths

Error-conditions

Cause of failure:

  • Optimization fail due to insufficient resources
  • Cannot readjust resource allocation without interruption of existing services.
  • Cannot satisfy other constraints, such as timing issue or performance threshold.

Post-conditions

 

3.4     Virtual Network Service

3.4.1 Virtual Network Retrieval APIs

TAPI_FR 17 : Get Virtual Network Service List

Description

  • Returns list of VirtualNetworkService entities that represent the virtual network requests that were received
  • This also includes attribute details for each VirtualNetworkService including

         References to ServiceInterfacePoints of the Service

         Optionally,  references to the virtual Topology realizing the VirtualNetworkService  

Pre-conditions

 

Inputs

  • Retrieve Scope Filter: Layer-Protocol List : Enumeration value

-           If set/non-empty, the API call will return references to only those encompassed VirtualNetworkServices that support at least one of the specified layer protocols

  • Include Topology : true or false

Outputs

List of VirtualNetworkServices indexed by Layer and details for each including:

  • List of IDs, Names, User-Labels and Extensions (if any)
  • Administrative, Operational, and Lifecycle States
  • Virtual Network Constraints including

         Required Constraints such as Service Level and Traffic Matrix

         Any optional Constraints  

  • Optionally the Topology realizing the VirtualNetworkService

Notifications

 

Error-conditions

 

Post-conditions

 

 

TAPI_FR 18 : Get Virtual Network Service Details

Description

  • Returns attributes of the VirtualNetworkService entity identified by the provided inputs.
  • This includes references to ServiceInterfacePoints of the VirtualNetworkService .
  • This optionally includes references to the Topology realizing the VirtualNetworkService .

Pre-conditions

 

Inputs

  • Service ID or Name : String

-           When NULL is provided, this API call should return an error condition

  • Include Topology : true or false

Outputs

  • List of IDs, Names, User-Labels and Extensions (if any)
  • Administrative, Operational, and Lifecycle States
  • Virtual Network Constraints including

         Required Constraints such as Service Level and Traffic Matrix

         Any optional Constraints  

  • Optionally the Topology realizing the VirtualNetworkService

Notifications

 

Error-conditions

 

Post-conditions

 

 

3.4.2 Virtual Network Request APIs

TAPI_FR 19 : Create V irtual N etwork Service

Description

For  the client side of the API to request creation of a virtual network from a network (maybe physical or virtual network, recursively ) provided by the server side of this API, according to the traffic volume between the access points of the client.

As a result, the server side of this API will reserve a set of resources to build up the virtual network, over which the client side of the API is allowed to e.g. configure virtual connections (through other transport APIs).

Pre-conditions

The server side of this API should have the topology information of the network under its control.

Inputs

  • List of following details for every ServiceInterfacePoint for the Virtual Network Service

         Reference (Name/ID) to the ServiceInterfacePoint

  • Virtual Network Constraints including

         Required Constraints such as Traffic Matrix

         Any optional Constraints such as Service Level

  • Start Time & End Time

Outputs

  • Virtual Network Service ID: The identifier of the V irtual N etwork Service instance that was created that includes identifier/reference of the virtual Topology that was created .

Notifications

  • ObjectCreation notifications on VirtualNetworkService , and associated/created  Topology, Nodes, Links and NodeEdgePoints
  • AttributeValueChange notifications on affected ServiceInterfacePoints
  • StateChanges on related State attributes in the affected objects

Error-conditions

  • There are not enough resources to set up the virtual network that meets the client traffic requirement.

Post-conditions

  • The server side of this API reserves a set of resources to build up the virtual network.
  • The server side of this API maintains the resources and the status of the created virtual networks, as well as the mapping relationship between the created virtual networks and the network under control of the server side.
  • The client side of this API is allowed to have virtual connection control over the virtual network.

 

TAPI_FR 20 : D elete V irtua l N etwork Service

Description

For the client side of the API to delete the V irtual N etwork Service and the associated Topology that it owns.

As a result, the server side of this API will release the resources used by this virtual network.

Pre-conditions

  • The server side of this API has the topology information of the network under its control.
  • The client side of this API has requested a virtual network from the server side of this API.
  • All virtual connections in the virtual network should be deleted by the client before deleting the virtual network.

Inputs

  • Virtual Network Service ID: The identifier of the virtual network to be deleted

Outputs

  • Id VirtualNetworkService   that was deleted

Notifications

  • ObjectDeletion notifications on VirtualNetworkService , and associated/deleted Topologies, Nodes, Links and NodeEdgePoints
  • AttributeValueChange notifications on affected ServiceInterfacePoints
  • StateChanges on related State attributes in the affected objects

Error-conditions

  • The requested VN (to be deleted) ID does not exist at the server side.
  • One or more virtual connections remain in the virtual network .

Post-conditions

  • The server side of this API releases the resources used by the virtual network.

 

3.5     Notification Service

<kam> Update from the 2016.06.10 version:

  1. Change Notification manager to API Client
  2. Change Notification agent to API Server
  3. Move the governing of notification subscription function from the notification manager to a functional component called Notification Control.
  4. Add Alarm notification to 3.5.2
  5. Add TCA notification to 3.5.2
  6. Question: Should we treat AVC and State Change notifications the same?
  7. Question: Do we want to model notification subscriptions as objects?

</kam>

Notifications refer to the set of autonomous messages that provide information about events, for example, alarm raisings and clearings, performance monitoring (PM) threshold crossing alerts (TCA), object creation/deletion, attribute value change (AVC), etc. Note that state change is a kind of AVC.  Entities that emit notifications include network resources and MCC components. In some standards, notifications are referred to as event reports.  The specification of functional requirements for Alarms (FM) and TCAs (PM) notifications have been added in this release of the document.

Notifications specifications are generally written around a model of an API Client and an API Server. The term API Client is used to designate an entity that subscribes and receives notification messages, while the term API Server is used to designate an entity that recognizes events, turns them into notification messages, and transmits them to pertinent API Clients (subscribers). Thus, the API Server represents (acts on behalf of) resources that are subject to events, and emits notification messages to inform zero or more API Clients (receiving entities) of these events.  . 

Notifications may be separated into two classes, primitive notifications (which are defined as) from resources to API Servers, and those that are processed and emitted by the API Servers into a form suitable for exposure to API Clients (subscribers). An API Server is modeled as the publisher of notification messages, to any number of subscription target destinations. Examples of further processing functions of the API Server for notification include interpretation, correlation, filtering, embellishment with time stamp, sequence number, system and managed object identifier.  Primitive notifications are out of scope of this document.

3.5.1 Notification Subscription and Filtering APIs

Notifications shall follow a publish and subscribe model.  In this document, we use a  notifications control (NC) function in the API Server to describe the governing of the subscription of notification service. The NC shall be able to create, be queried, modify, suspend, resume and delete a notifications subscription.  The notifications available to an API Client for subscription are bounded by the (virtual) resources and privileges visible to that API Client. Subscriptions shall not time out and be automatically deleted during the lifetime of a given session [6]

It will also be possible to retrieve notification records at a later time, by querying the NC for the history records of the generated notifications. This result of the query depends on other configuration policies such as the record retention policies, which is implementation-specific and are out of the scope of this document.

Knowledge of available notifications and their sources is a precondition for subscription. An API Server shall permit a NC to discover its supported notification types.  Particularly in the case of virtualized resources of SDN, notifications discovery may be a feature of a general resource discovery mechanism. 

Notification subscribers specify their interest according to filter, where a filter is any combination of (event related) criteria that can be unambiguously evaluated against an input to produce an accept/reject result. A filter is an attribute of a subscription, and may be modified over the lifetime of the subscription. Filters are local to the subscription, and do not survive the deletion of that subscription. The actual notifications delivered to a target/subscriber are those that pass the subscription filter.

 

TAPI_FR 21 : Discover Supported Notification Types

Description

Allows an API Client to discover the notifications capabilities supported by an API Provider

Pre-conditions

Knowledge of the Notification Server (e.g. URI, IP/Port, etc.)

Inputs

 

Outputs

  • Supported Notification-Type List: Enumeration value

The notification types are specified in section 3.5.2.

  • Supported Object-Type List: Enumeration value

The object types are specified as globally unique identifiers.

Notifications

 

Error-conditions

Reason for Failure

Post-conditions

Supported notification and object types discovered

 

TAPI_FR 22 : Create   Notification Subscription

Description

Allows an API Client to subscribe for receiving autonomous  notifications from API provider, as per the specified filters

Pre-conditions

Knowledge of available notifications types and their sources

Inputs

  • Subscription Scope Filter: Notification-Type List: Multiple Enumeration values. If set/non-empty, the system will push Notifications of one of the specified notification types only. The notification types are specified in section 3.5.2.
  • Subscription Scope Filter: Object-Type List: Multiple Enumeration values.  If set/non-empty, the system will push Notifications related to one of the specified object types only. The object types are specified as globally unique identifiers.
  • Subscription Scope Filter: Layer-Protocol-Name List: Multiple Enumeration values. If set/non-empty, the system will push Notifications related to one of the specified layer protocols only. The layer protocols are specified in section 3.6.
  • Subscription Scope Filter: Object-Instance-Id List: List of globally unique object Ids (globalId). If set/non-empty, the system will push Notifications related to the specified Object instances only, irrespective of other filter attribute settings

Outputs

subscriptionId

Notifications

notificationId

Object Creation Notification per the successful subscription.

Error-conditions

Reason for Failure

Post-conditions

Subscription created

 

TAPI_FR 23 : Modify   Notification Subscription

Description

Allows an API Client to modify its subscription to receive autonomous  notifications from API provider, as per the specified filters

Pre-conditions

Knowledge of available notifications subscription (i.e., subscriptionId), types and their sources

Inputs

  • Subscription Id: String
  • Subscription Scope Filter: Notification-Type List: If this parameter is specified in the input, its value will override the current filter of the existing subscription. The notification types are specified in section 3.5.2.
  • Subscription Scope Filter: Object-Type List: If this parameter is specified in the input, its value will override the current filter of the existing subscription. The object types are specified as globally unique identifiers.
  • Subscription Scope Filter: Layer-Protocol-Name List: If this parameter is specified in the input, its value will override the current filter of the existing subscription. The layer protocols are specified in section 3.6.
  • Subscription Scope Filter: Object-Instance-Id List: If this parameter is specified in the input, its value will override the current filter of the existing subscription. If set/non-empty, the system will push Notifications related to the specified Object instances only, irrespective of other filter attribute settings

Outputs

subscriptionId

Notifications

notificationId

Object Creation Notification per the successful subscription.

Error-conditions

Reason for Failure

Post-conditions

Subscription modified

 

TAPI_FR 24 : Delete   Notification Subscription

Description

Allows an API Client to delete its subscription to stop receiving autonomous  notifications from API provider

Pre-conditions

Knowledge of available notification subscriptions

Inputs

  • Subscription Id: String.

Outputs

SubscriptionId of the notification subscription that was deleted

Notifications

Object Deletion Notification per the successful subscription.

Error-conditions

Reason for Failure

Post-conditions

Subscription deleted

 

TAPI_FR 25 : Suspend Notification Subscription

Description

Allows an API Client to modify its subscription to temporarily stop receiving autonomous notifications from API provider

Pre-conditions

Knowledge of available notification subscriptions

The notification subscription is active and not suspended

Inputs

  • Subscription Id: String.

Outputs

SubscriptionId of the notification subscription that was suspended

Notifications

State Change Notification per the successful subscription suspension.

Error-conditions

Reason for Failure

Post-conditions

Subscription suspended

 

TAPI_FR 26 : Resume   Notification Subscription

Description

Allows an API Client to modify its subscription to resume receiving autonomous  notifications from API provider

Pre-conditions

Knowledge of available notification subscriptions

The notification subscription is suspended

Inputs

  • Subscription Id: String.

Outputs

SubscriptionId of the notification subscription that was resumed

Notifications

State Change Notification per the successful subscription that was resumed

Error-conditions

Reason for Failure

Post-conditions

Subscription resumed

 

TAPI_FR 27 : Retrieve   Notification Records

Description

Allows an API Client to retrieve notification records by querying the API server for records of the generated notifications. This result of the query depends on other configuration policies such as the record retention policies, which server implementation specific.

Pre-conditions

Knowledge of available notifications types and their sources

Knowledge of any Record retention polices that affect the availability of the queried Notification records.

Inputs

  • Subscription Scope Filter: Notification-Type List: Multiple Enumeration values. If set/non-empty, the system will push Notifications of one of the specified notification types only. The notification types are specified in section 3.5.2.
  • Subscription Scope Filter: Object-Type List: Multiple Enumeration values.  If set/non-empty, the system will push Notifications related to one of the specified object types only. The object types are specified as globally unique identifiers.
  • Subscription Scope Filter: Layer-Protocol-Name List: Multiple Enumeration values. If set/non-empty, the system will push Notifications related to one of the specified layer protocols only. The layer protocols are specified in section 3.6.
  • Subscription Scope Filter: Object-Instance-Id List: List of globally unique object Ids (globalId). If set/non-empty, the system will push Notifications related to the specified Object instances only, irrespective of other filter attribute settings
  • Start Time & End Time – Returns all Notifications whose Event-Time falls under this range. This operation ignores the existence of any record retention policies and assumes knowledge of those polices via external means.

Outputs

List of Notification records

Notifications

 

Error-conditions

Reason for Failure

Post-conditions

Subscription created

 

3.5.2 Notification Message Types

TAPI_FR 28 : Object Creation Notification

Values

This message shall minimally support the following attributes

  • Notification Info
    • Object Class
    • Object Instance
    • Notification Id
    • Event Time
    • Notification Type
      • Object Creation
  • Additional Information: NameAndValue [*]
  • Additional Text
  • Source Indicator

 

TAPI_FR 29 : Object Deletion Notification

Values

This message shall minimally support the following attributes

  • Notification Info
    • Object Class
    • Object Instance
    • Notification Id
    • Event Time
    • Notification Type
      • Object Deletion
  • Additional Information: NameAndValue [*]
  • Additional Text
  • Source Indicator

 

TAPI_FR 30 : Attribute Value Change Notification

Values

This message shall minimally support the following attributes

  • Notification Info
    • Object Class
    • Object Instance
    • Notification Id
    • Event Time
    • Notification Type
      • Attribute Value Change
  • Changed Attributes [1..*]
    • { attributeName, oldAttributeValue, newAttributeValue }
  • Additional Information: NameAndValue [*]
  • Additional Text
  • Source Indicator

 

 

 

  •  

 

 

TAPI_FR 32 : Alarm Notification

Values

This message shall minimally support the following attributes

  • Notification Info
    • Object Class
    • Object Instance
    • Notification Id
    • Event Time
    • Notification Type
      • Alarm notification
  • Alarm Info [1..*]
  • Probable Cause
  • Perceived Severity
    • { critical, major, minor, warning, cleared }
    • Service Affecting
      • Not service affecting
      • Service affecting
      • Unknown
    • Is Transient
  • Additional Information: NameAndValue [*]
  • Additional Text
  • Changed Attributes [*]
  • Layer Protocol Name
  • Source Indicator

 

 

TAPI_FR 33 : Threshold Crossing Alert

Values

This message shall minimally support the following attributes

  • Notification Info
    • Object Class
    • Object Instance
    • Notification Id
    • Event Time
    • Notification Type
      • Threshold Crossing Alert
  • TCA Info
    • Threshold Crossing Type
      • {Cleared, Threshold above, Threshold below}
    • Is Transient
    • Monitored/Threshold Parameter
      • { parameter name, current value, normal range {upper bound, lower bound}}
  • Additional Information: NameAndValue [*]
  • Additional Text
  • Changed Attributes [*]
  • Layer Protocol Name
  • Source Indicator

 

3.6     TAPI Data Types

This section identifies the data types, formats and values commonly associated with the parameters of the various TAPI service interface APIs.

TAPI_FR 34 : LayerProtocolName

Values

The Layer-Protocol attribute shall minimally support following for Connectivity layers (NOTE: MPLS-TP has been removed pending completion of the associated Spec Model in ONF)

  • OTSiA
  • OTU
  • ODU
  • ETH
  • ETY

 

TAPI_FR 35 : Capacity (Fixed Bandwidth)

Values

The Capacity (Bandwidth)  attribute is applicable for digital layers and shall minimally support following values in Mbps

  • 10 (Ethernet Lan)
  • 100 (Fast Ethernet)
  • 1000 (Gigabit Ethernet)
  • 2400 (ODU1/OTU1)
  • 10000 (10GBE/ODU2/OTU2)
  • 40000 (40GBE/ODU3/OTU3)
  • 100000 (100GBE/ODU4/OTU4)

 

TAPI_FR 36 : Capacity (Profile)

Values

The following are the required Bandwidth Profile parameters

  • Committed Information Rate (CIR): The rate of the packets that the transport networks commit to forward with some negotiated QoS objectives (packet loss, packet delay, packet delay variation). CIR-conformant packets are also referred to as green packets.

The following are the optional Bandwidth Profile parameters

  • Bandwidth Profile Type: Indicates the type of algorithm (e.g., MEF 10.1, RFC 2697, RFC 2698, RCF 4115, etc.). If not specified, it is selected based on the controller’s policy.
  • Committed Burst Size (CBS): The maximum burst-size at which frames can be received at the line speed while still being CIR-conformant. If not specified, it is selected based on the controller’s policy.
  • Excessive Information Rate (EIR): The rate of packet that the transport network allows to be forwarded but without guaranteed any QoS objectives. EIR-conformant packets are also referred to as yellow packets. The default value is 0.
  • Excessive Burst Size (EBS): The maximum burst-size at which frames can be received at the line speed while still being EIR-conformant. If not specified, it is selected based on the controller’s policy.
  • Color Mode (CM): Indicates whether the packets are marked with the color information (color-aware) or not (color-blind). The default value is color-blind.
  • Coupling Flag (CF): Indicates the mode of operations for the MEF 10.1 Bandwidth Profile Type. When set, the rate of yellow frames is bounded by the Peak Information Rate (PIR = CIR + EIR); otherwise the rate of yellow frames is bounded by the EIR. If not specified, it is selected based on the controller’s policy.

 

 

TAPI_FR 38 : Operational State

Values

  • ENABLED
  • DISABLED

 

TAPI_FR 39 : Lifecycle State

Values

  • PLANNED
  • POTENTIAL
  • INSTALLED
  • PENDING_REMOVAL

 

TAPI_FR 40 : Port Role

Values

Denotes the role of the End-Point with respect to the Forwarding-Construct

  • Symmetric
  • Root
  • Leaf
  • Trunk
  • Unknown

 

TAPI_FR 41 : Port Direction

Values

Denotes the directionality of the signal-flow in the Port with respect to the Forwarding-Construct

  • Input
  • Output
  • Bidirectional
  • Unidentified_or_Unknown

 

TAPI_FR 42 : Termination Direction

Values

Denotes the directionality of the signal-flow in the ServiceInterfacePoint or ConnectionEndPoint

  • Sink
  • Source
  • Bidirectional
  • Unidentified_or_Unknown

 

TAPI_FR 43 : ServiceInterfacePoint TRI format

Values

The End-Point Name shall minimally support following formats

  • TRI
  • URI
  • Domain-specific String

The formats for the TRI is out of scope for this FR and is typically part of the implementation agreements (IAs)

 

TAPI_FR 44 : Service Type

Values

The Service Type attribute shall minimally support following values

  • POINT_TO_POINT
  • POINT_TO_MULTIPOINT
  • MULTIPOINT
  • ROOTED_MULTIPOINT

 

TAPI_FR 45 : Connectivity Constraints

Values

The following are the required Connectivity parameters

  • Service Type: The type of connectivity requested
  • Requested Capacity: Requested bandwidth (fixed or range)

The following are the optional Connectivity constraint parameters

  • Service Level Descriptor– a abstract label the meaning of which is mutually agreed – typically represents metrics such as - Class of service, priority, resiliency, availability
  • Latency – integer value and unit - upper bound
  • Cost Characteristic – Vector of one or more metrics that would enable the provider to make a decision when implementing the Service
  • Schedule

 

TAPI_FR 46 : Topology Constraints

Values

The following are optional Topology parameters

  • Include Topology / Path/Link/Node – indicates partial or complete set of nodes and/or NodeEdgePoints to be used
  • Exclude Topology / Path/Link/Node - indicates partial set of nodes and/or NodeEdgePoints to be avoided
  • Preferred Transport Layer: Represents the preferred layer of transported service

 

TAPI_FR 47 : Resilience Constraints

Values

The following are optional Resilience parameters

  • ResilienceType
  • ReversionMode
  • RestorePriority
  • WaitToRevertTime
  • HoldOffTime
  •  

 

 

 

TAPI_FR 48 : Virtual Network Service Constraints

Values

The following are the required Virtual Network Service parameters

  • Traffic Matrix: A matrix to describe the traffic (e.g., bandwidth) between each pair of ServiceInterfacePoints

The following are the optional Virtual Network constraint parameters

  • VN Service Level Descriptor – a abstract label the meaning of which is mutually agreed – typically represents metrics such as – type of topology abstraction, class of service, priority, resiliency, availability

 

TAPI_FR 49 : Traffic Matrix

Values

The Traffic Matrix consists of a list of elements, each describing possible individual traffic flow comprising the matrix, including:

  • ServiceInterfacePoint details for the Traffic flow
  • Reference (Name/ID) to  the Source ServiceInterfacePoint
  • Reference (Name/ID) to  the Sink ServiceInterfacePoint
  • Optionally the Layer of the ServiceInterfacePoint if it supports multiple layers
  • Traffic Constraints including
  • Required Constraints such as Capacity
  • Optional Constraints such as Layer,  Latency, Cost, etc.

 

TAPI_FR 50 : Path Optimization Constraint

Values

The following are the optimization constraint parameters to be provided as input to the Path Optimization API

  • Whether traffic interruption allowed or not

 

TAPI_FR 51 : Path Objective Function

Values

The following are the Objective Function parameters to be provided as input to the Path Computation Service API

  • Allow to compute concurrent Paths or not
  • Minimize the cost
  • Resource sharing (max re-usage/min re-usage) Whether new resource can be used or no
  • Minimum/maximum link utilization value
  • Maximize the amount of successfully computed paths  (Only for concurrent path computation)
  • Minimize aggregate Bandwidth Consumption (Only for concurrent path computation)
  • Minimize the load of the Most Loaded Link  (Only for concurrent path computation)
  • Minimize Cumulative Cost of a set of paths  (Only for concurrent path computation)

 

TAPI_FR 52 : Notification-Header

Description

All notifications shall contain a common header that identifies the type of the notification, the producer of the notification (object class, object instance), the time at which the underlying event occurred, a unique notification identifier, and the object instance identifier of the system hosting the agent.

Values

This header shall minimally support the following attributes

  • Notification Identifier (uuid)
  • Notification Type
  • Object Type
  • Object Instance Identifier (uuid) – Globally unique ID of the object on which this notification is being raised
  • Object Instance Name List
  • Event Time Stamp
  • Notification Source Indicator

 

TAPI_FR 53 : Notification-Type

Description

Notification agents shall classify notification messages into notification types; additional notification types may be defined as needed.

Values

This enumeration shall minimally support following values

  • Object Creation
  • Object Deletion
  • Attribute Value Change
  • State Change

 

TAPI_FR 54 : Object-Type

Description

Notification agents shall identify the type of the object on which a notification is raised and allow filtering of the notifications based on object types; additional object types may be defined as needed.

Values

This enumeration shall minimally support following values

  • Topology
  • Node
  • Link
  • Connection
  • Path
  • ConnectivityService
  • Virtual Network Service
  • Path Computation Service
  • NodeEdgePoint
  • ServiceInterfacePoint
  • ConnectionEndPoint

 

TAPI_FR 55 : Notification-Source-Indicator

Description

Notification agents shall identify the source of notification messages.

Values

This enumeration attribute shall minimally support following values

  • ResourceOperation
  • ManagementOperation
  • Unknown

4        Appendix A: Transport API Concepts Overview

4.1        Context

An SDN controller or manager typically organizes its information and operates on that information within specific contexts. 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. Thus, Context defines the scope of control and naming that a particular SDN controller, manager or a client application has with respect to the information it operates on internally or exchanges over an interface.  It therefore determines the makeup of the network resource abstractions within that domain of control.

More specifically, a T-API Context:

  • Is defined by a set of ServiceInterfacePoints and its capabilities (capacity, layers, etc.)
  • Utilizes one or more shared namespace in information exchanges over the interface
  • Includes one or more top-level Topology abstractions that are:
    • Either statically assigned by a controller or dynamically created on client request
    • Defined by a set of Nodes and Links
  • Provides scope for control (create/retrieve/update/delete) of Topology abstractions
  • Determines the level of abstraction exposed over an interface

To further illustrate the concept of Context, consider the simple single domain physical network example shown in Figure-3 [7] . It depicts a Network Provider ( Blue ) with two Customers ( Red and Green ). In this example, the network provider controller has 3 Contexts – its own internal/admin Context representing all the resources under its control (Control Domain), and one Context per customer ( Red and Green ) that it shares over its interfaces. This is shown in Figure-4 & Figure-5 below. In this example, the provider exposes a single- Node Topology abstraction to customer Red , while it exposes a multi- Node Topology abstraction to customer Green .

Figure 3 : Simple Physical Network Example

 

Figure 4 : Shared Contexts - Architecture perspective

 

Figure 5 : Shared Contexts & Topology

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

-           Node – which represents the forwarding-potential  between its edge-points ( LTP s)

-           Topology – which represents the topological-aggregation of lower-level Links and Nodes

Depending on the frame of reference for an API invocation (or the position of an imaginary observer), only the opaque Node -aspects of a Forwarding-Domain would be visible (placing the observer external to the Forwarding-Domain ) or the entire Topology- structure of a Forwarding-Domain would be visible (placing the observer internal to the Forwarding-Domain)

In this representation, a Node is a logical abstraction of forwarding capability, and as such could encompass an internal Topology . In such a case, a Node can be recursively decomposed into its lower-level Nodes and Links . So a Node at a top-level could abstract the Topology of an entire network while a Node at the bottom-most level could abstract a switch matrix within a device/NE.

To illustrate the concept, consider the physical network example presented in Figure-3 above. The Node-R1 in the Red shared Context can be decomposed into a Topology of 3 Nodes R1.1 , R1.2 , R1.3 and the Links between them, as shown in the Figure-6 below.

Figure 6 : Topological Decomposition of Node

Figure-7 illustrates another example of hierarchical topology recursion from a top level topology abstraction (node B) to successively more detailed levels of topology abstraction until the lowest level of interest is reached (in this example, C, A1.1-A1.3, A2.1-A2.3).  

 

Figure 7 : Recursive Topological Decomposition of Node

And Figure-8 below illustrates the same network example, from the perspectives of an imaginary observer, viewing the ForwardingDomain from different locations within the abstraction.

Figure 8 : Node/Topology perspectives of recursively partitioned Forwarding Domain (FD)

The effective adjacency between two or more Forwarding-Domains is modeled by a Link . In its basic form (i.e., point-to-point Link ) it associates a set of ( Node-)Edge-Point client layers on one Forwarding-Domain with an equivalent set of ( Node-)Edge-Point client layers on another Forwarding-Domain . A Link may offer parameters such as capacity and delay depending on the type of technology that supports the Link . A Forwarding-Domain may aggregate Links that are wholly within the bounds of the Forwarding-Domain . A Link with an Off-network end cannot be encompassed by a Forwarding-Domain. The Link can support multiple transport layers via the associated ( Node-)Edge-Point instances on which it terminates.

4.3        Hierarchical Control Domains and Contexts

The T-API Context is a realization of the Network-Control-Domain as defined in the ONF Core Information Model

In interfaces where an abstracted view of network is offered, e.g. in client/server SDN controller relationship, the Context defines the scope of control of the client SDN controller on the abstracted/virtual network view that has been provided by the server SDN controller. Thus Context relates to an abstracted view of the partitioned provider resources allocated to that particular client. In such cases, the Context also scopes the namespace for identifying objects representing the (virtual) resources within the (virtual) network view. The following figures illustrate few examples of Contexts in a hierarchical SDN controller system:

 

Figure 9 : View of Controller-1 Context based on Views exported by Controllers 2 & 3

 

Figure 10 : Views of Controller-2 Contexts

 

Figure 11 : Views of Controller-3 Contexts

4.4        Topology Traversal using APIs

The following figures illustrate few examples of views of a provider topology, that a T-API client application may obtain using the APIs.

 

Figure 12 : API Client’s View of Controller-1 Context without retrieving Topology details

Figure 13 : API Client’s View of Controller-1 Context by retrieving top-most level of Topology

Figure 14 : API Client’s View of Controller1 Context by retrieving 2 levels of Topology details

 

Figure 15 : API Client’s View of Controller-1 Context by retrieving 3 levels of Topology details

4.5        Service, Connection and Route

A ConnectivityService represents an “intent-like” request for connectivity between two or more ServiceInterfacePoints (a realization of LTP described in the ONF Core IM) exposed by the Context . As such, ConnectivityService is distinct from the Connection that realizes the ConnectivityService . The requestor of the ConnectivityService is expected to be able to express their intent using just an “external” Node view of Forwarding-Domain and the advertised ServiceInterfacePoints and not require knowledge of the “internal” Topology details of the Forwarding-Domain .

The association of the ConnectivityService to ServiceInterfacePoints is made via the EndPoints of the ConnectivityService .

The ConnectivityService is modeled by the Forwarding-Construct entity defined in the ONF Core Information Model.

The Connection represents an enabled potential for forwarding (including all circuit and packet forms) between two or more NodeEdgePoints (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 Connection is modeled by the Forwarding-Construct entity defined in the ONF Core Information Model.

The association of the Connection to ConnectionEndPoints (yet another realization of LTP described in the ONF Core IM) is made via the Endpoints of the Connection , where each Endpoint of the Connection has a role in the context of the Connection . The traffic forwarding between the associated ConnectionEndPoints of the Connection depends upon the type of Connection

The Connection can be used to represent many different structures including point-to-point (P2P), point-to-multipoint (P2MP), rooted-multipoint (RMP) and multipoint-to-multipoint (MP2MP) bridge and selector structure for linear, ring or mesh protection schemes.

A Connection supports a recursive aggregation relationship such that the internal construction of a Connection can be exposed as multiple lower-level Connection instances (partitioning). A Connection can have zero or more Routes , each of which is defined as a list of lower level Connection instances. At the lowest level of recursion, a Connection represents a cross-connection within a switch matrix/fabric in a Network Element.

The Route represents the individual routes of a Connection . It is represented by a list of ConnectionEndPoints at a lower level. Note that depending on the characteristics of the ConnectivityService supported by a Connection , the Connection can have multiple Routes .

 

 

Figure 16 : Service & Connections from Controller-1 perspective

Figure 17 : Service & Connections from Controller-2 perspective

 

 

Figure 18 : Service & Connections from Controller-3 perspective

 

4.6        NodeEdgePoint v/s ServiceInterfacePoint v/s ConnectionEndPoint

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.

Three forms of LTPs are realized in T-API model: 

  • NodeEdgePoint - The NodeEdgePoint 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 NodeEdgePoints have a specific role and directionality with respect to a specific Link.
  • ServiceInterfacePoint - The ServiceInterfacePoint 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. ServiceInterfacePoint have a mapping relationship ( one-to-one, one-to-many, many-to-many ) to NodeEdgePoints . [8] The ServiceInterfacePoints have a specific role and directionality with respect to a specific ConnectivityService.
  • ConnectionEndPoint - The ConnectionEndPoint represents the ingress/egress port aspects that access the forwarding function provided by the Connection . The ConnectionEndPoints have a client-server relationship with the NodeEdgePoints . The ConnectionEndPoints have a specific role and directionality with respect to a specific Connection.


5        Appendix A2: Support of Node Constraints

TAPI 2.0 introduces additional capability to model node constraints for path computation and ConnectivityServices.  The Common Information Model (CIM) v1.3 introduces concepts for modeling ForwardingDomain and Link Constraints.  The Node Constraint model used in TAPI 2.0 is derived from the Core Information Model v1.3 by pruning and refactoring.   The TAPI NodeRuleGroup, InterRuleGroup and Rule are refactoring of the corresponding CIM objects. 

Addition of the NodeRuleGroup, InterRuleGroup and Rule into TAPI 2.0 allows modeling of more detailed constraints on port-to-port connectivity within a Node in the TAPI topology.

5.1        TAPI 1.0 Node Model

In the TAPI 1.0 Node Model, the Node provided an abstract representation of the forwarding-capabilities of a particular set of Network Resources , and included a set of ports ( NodeEdgePoint ) belonging to those Network Resources.  In the figure below, the Node model exposes six NodeEdgePoints but does not expose any statement on connectability between them, so there is a default assumption that there are no constraints on forwarding between ports.  Overall attributes such as cost or latency can be associated with the Node but apply to the port-to-port connectivity uniformly.

Figure 19 : TAPI 1.0 Node

More detail about any constraints on port-to-port connectivity can be modeled in TAPI 1.0 by exposing a more detailed sub-topology to convey limitations, e.g., in the figure below the top left NEP A.1 cannot connect to the bottom left NEP B.2 except by going through sub-node C, as there is no link connecting the two sub-nodes A and B directly.  This could be used to attach additional cost for going from A.1 to B.2.

Figure 2: TAPI 1.0 Node with Detailed Topology

However, exposing detailed topology requires the addition of internal links and NEPs, adding to the overhead of the topology, and forcing the user to create explicit forwarding in each of the new nodes.   In some cases detailed topology may not be capable of expressing all constraints, especially where the internal links and NEPs may have no physical counterpart (internal to network element)

 

5.2        TAPI 2.0 Node Rules

In TAPI 2.0, NodeRuleGroups are added to convey port-to-port connectivity constraints.  The NodeRuleGroup contains a set of one or more Rules associated with the node, as well as the set of affected ports and associated attributes such as the cost or other metrics associated with forwarding.  The Rule has a ruleType and a forwardingRule such as “MAY” or “CANNOT” forward.  The figure below shows a NodeRuleGroup affecting ports A.1 and C.1.

Figure 3: TAPI 2.0 NodeRuleGroup

It should be noted that the default behavior between ports if no NodeRuleGroup is expressed is that forwarding is not constrained.

Importantly, NodeRuleGroups are not given a strict hierarchy but can overlap each other.

Asymmetrical constraints such as MAY forward from A.1 to C.1 but CANNOT forward from C.1 to A.1 can be expressed by separate NodeRuleGroups where in the first A.1 is given a linkPortDirection of Source and C.1 a linkPortDirection of Destination and the forwardingRule is MAY, while in the second the lnikPortDirections are opposite and the ForwardingRule is CANNOT.

NodeRuleGroups can summarize the relationships between sets of ports with common constraints, and yield a relatively simple and clear statement of constraints, however if desired NodeRuleGroups can be used to create the equivalent of a connectivity matrix by defining a NodeRuleGroup per port-pair and direction as shown in the Figure below.  In simplest form, a rule is expressed for each pair (A.1-C.1, A.2-C.1, etc.) with forwardingRule MAY or CANNOT, specifying whether connectability is supported or not; actually it is only necessary to provide a rule where connectability is not supported, since the default is support.  In more complex forms costs or metrics can be given as well as a forwardingRule.

Figure 4: TAPI 2.0 Connectivity Matrix expressed as NodeRuleGroups

5.3        More Complex Modeling

For more complex connectivity constraints it is possible to use NodeRuleGroups to specify connectability across a subset of ports that have a common rule and then specify connectivity between different NodeRuleGroups by expressing an InterRuleGroup.  This makes it possible, for example, to describe connectability between ports that may be supported by one type of card in a device and then connectability between these ports and other ports supported by a different card.

An example is shown in the figure below.

Figure 5: TAPI 2.0 NodeRuleGroup and InterRuleGroup Combination

A.1 and A.2 may, for example, be on a card that supports full switching functionality including switching of data from one port to another.

B.1 and B.2 on the other hand may be on a card that supports multiplexing but not switching between local ports on the card.

C.1 and C.2 may be on a line card that supports aggregation of traffic from client ports onto a larger bandwidth transport link.

A NodeRuleGroup (A) can be exposed for A.1 and A.2 with no constraints, and another NodeRuleGroup (B) for B.1 and B.2 that indicates data CANNOT be forwarded between ports.  InterRuleGroups can then be exposed that support forwarding between Group A and Group C and between Group B and Group C to express the capability to forward data from the client ports in Group A and Group B to the line side ports in Group C.

6        Appendix A3: Support of Resilience

The following section provides exemplary use cases for TAPI ConnectivityServices supporting resiliency .

6.1        Single-domain e2e linear protection /restoration

 

In this single-domain end-to-end linear resilience example, the following actions take place:

  • Client configures the resilience type and resilience-related parameters when creating a ConnectivityService.
  • Client specifies any route constraints for work route and protection route separately when creating a ConnectivityService.
  • In some resilience schemes, Route may need LifecycleState to expressed, due to a Route may have encapsulated protection or other complex nesting of resilience schemes.

6.1.1      Domain Topology

The domain topology supports multiple diverse paths between the two NodeEdgePoints corresponding to the target ServiceInterfacePoints.

6.1.2      ConnectivityService Creation

The ConnectivityService request indicates resiliency requirements:

-           Protection type

-           Reversion mode

The resulting ConnectivityService is made with two diverse paths across the domain, one working and one protect.  As shown in the figure below, the SDN Controller creates a green working path from A.1 to A.2 and a red protect path from A.1 through A.3 to A.2, both supporting a connection between NEPs 01 and 05 and ConnectivityService between SIPs SIP1 and SIP2.

 

6.2        Multi-domain segment linear protection/restoration

In a multi-domain ConnectivityService, resiliency can be provided using segment linear protection/restoration within individual domains.  The additional requirements to support this are as follows:

-           Need to configure the segment protection type for multi-domain controller when creating a ConnectivityService.

For resilience of inter-domain links: combination of e2e protection and segment protection, combination of e2e restoration and segment protection.

Resiliency across the inter-domain interface can be supported by using local protection capability of the inter-domain links.

6.2.1      Multi-domain Topology

In this case an example topology of three separate domains is shown, each with its own SDN Controller and with a Multi-Domain Controller coordinating across domains. 

6.2.2      Multi-domain ConnectivityService Creation with Local Resilience

In this scenario, the MD Controller computes the domain path and requests ConnectivityService across each domain, specifying an associated Protection Type and Reversion Mode.  The interdomain SIPs are chosen such that the interdomain link supports link protection.  Within each domain, the SDN Controller for the domain creates a protected connection that includes a working and protect path.  Note that in the middle domain the ingress and egress NEPs are on the same node, so multiple paths are not available.

 

 

6.3        Multi-domain e2e linear protection/restoration

In this multi-domain end-to-end linear resilience example these additional actions are taken:

  • Client specifies the protection role of the ConnServiceEP when creating a ConnectivityService.
  • Client indicates routes used for work or protection after creating a ConnectivityService, in another word, routes should be specified with protection role.

The ConnectivityService in the transit domains are made aware of the protection schema

6.3.1      Multi-domain Topology

The multi-domain topology is shown below, similar to the topology in the previous example.

6.3.2      Multi-domain ConnectivityService Creation with e2e linear protection

In this scenario, the MD Controller coordinates the creation of work and protect paths across multiple domains.  It selects the SIPs to be used for the inter-domain links and uses TAPI to identify the SIPs and their roles to the domain Controllers.

For Domain A, the MD Controller specifies that ConnectivityService EndPoint corresponding to SIP1 is the Protected interface point, while the ConnectivityServiceEndPopint corresponding to SIP3 is Working type and the ConnectivityService EndPoint corresponding to SIP4 is Protect type.  Controller A then creates two paths, one from SIP1 to SIP3 and one from SIP1 to SIP4.

 

For Domain B, the MD Controller specifies that the ConnectivityService EndPoint corresponding to SIP11 is the Protected interface point, while the ConnectivityService EndPoint corresponding to SIP9 is Working type and the ConnectivityService EndPoint corresponding to SIP10 is Protect type.  Controller B then creates two paths, one from SIP9 to SIP11 and one from SIP10 to SIP11.

For the transit domain D, it is possible for the MD Controller to request two independent ConnectivityServices, one for Working and one for Protect path.  However there may be some benefit to Controller D to know that there is a relationship between the two paths, so the MD Controller makes a single request to Controller D that identifies the ConnectivityService EndPoints corresponding to SIP5 and SIP7 as the Working interface points and the ConnectivityService EndPoints corresponding to SIP6 and SIP8 as the Protect interface points and Controller D creates two diverse paths for Working and Protect.

Once the ConnectivityServices across each domain are completed, there are two diverse end-to-end paths that provide Working and Protect paths for the end-to-end ConnectivityService.

6.4        Retrieving Status

Resilient connections are modeled as having multiple sub-connections where SwitchControl (SC) at the ConnectionEndPoint of the connection coordinates the handling of data across the sub-connections.  SC functionality is determined inherently in the type of resiliency that is requested for the connection, however SC can be queried to retrieve the current state of the protection switching of the connection.

7        Appendix A4: Virtual Network Service

1.1              OIF Virtual Transport Network Service

OIF classifies three types of virtual transport network service [OIF VTNS IA]:

Type A service i s a dynamic connection service such as Bandwidth on Demand (BoD).  Type A service makes available to the user a single virtual NE (vNE) modeling network transport capability, with two or more interface ports that are connected to client sites via links. The user has control over the configuration of the interface ports and over the cross connections between these interface ports. Type A service corresponds roughly to the IETF ACTN Virtual Network Service 1.

Type B service makes available to the user a virtual network (VN) consisting of a set of vNEs which are interconnected by a set of virtual links, and are connected with client sites via links. The user has control over the configuration of the interface ports and cross connections between these interfaces ports in every vNE within the VN, in a similar manner as it can configure interface ports and cross connections in physical NEs. Type B service can be regarded as a super set of Type A.

The virtual network topology is pre - configured between customer and owner of the network . The operator stays in full control and has responsibility for configuring resources for the virtual network. Type B service corresponds roughly to the IETF ACTN Virtual Network Service 2a.

Type C service adds the capability for customers to request dynamic creation/modification/deletion of virtual networks provided by the operator .

The virtual network is not pre - configured between customer and owner of the physical network . The customers are able to change the virtual network topology, for example by adding or removing virtual nodes and virtual links. [Note: Operator policies may limit the modifications for example to the addition/removal of virtual links as opposed to the addition/removal of virtual NEs.]  Type C service corresponds roughly to the IETF ACTN Virtual Network Service 2b.

 

1.2              TAPI Support of Virtual Network Services

In TAPI 1.0/2.0, Type A and Type B service is supported through the use of ConnectivityService and Topology Service components, while parts of Type C service are supported through the Virtual Network Service components. 

In the case of Type A, a context of shared ServiceInterfacePoints is pre-configured between the customer and network provider, and no further topology is exposed.  The customer makes service requests for ConnectivityService between SIPs, as in Figure 1.

In the case of Type B service, the customer initially presents offline a set of traffic requirements that express a traffic matrix of demand between SIPs, and the network provider creates a virtual topology to support this traffic matrix, again offline.  The customer can then retrieve the virtual network topology over the virtual network service API, as shown in Figure 2, using the TAPI Topology Service component to request Context, Topology, Node and Link information.

Using this topology, the customer can control use of the network by requesting connectivity across the virtual network with explicit path control, for example requesting a ConnectivityService between SIP1 and SIP4 with an includePath attribute that requires the path to traverse VN1, VN2 and VN4, as shown in Figure 3.  This allows the customer to control usage of the resources provided by their virtual network.

In the case of Service Type C, TAPI supports the initial dynamic creation and deletion of the virtual network, through the Virtual Network Service component.  In order to dynamically create their virtual network, the customer uses TAPI to request creation of a virtual network service, providing a set of traffic demands anticipated between the SIPs in the shared Context.  The network responds by creating a virtual network topology and making this available to the customer, together with a unique identifier for the virtual network service. 

Subsequently, the customer can retrieve current details of the virtual network using the TAPI Topology component and can create, modify and delete ConnectivityServices across the virtual network using the ConnectivityService component.  Ultimately the virtual network can be deleted through the Virtual Network Service component.

It is possible for the customer to create multiple virtual network services using the same Context, connecting the same or different subsets of the SIPs making up the Context as shown in Figure 4.

Each virtual network service is assigned a unique identifier and the customer can selectively create ConnectivityServices using a specific virtual network service, by specifying that a particular topology be used for the ConnectivityService, as shown in Figure 5.

In the current version of TAPI, modification of the virtual network service is not supported, as the definition and impact of some modification actions, such as addition of a new virtual node in a topology, are not yet supported.

 

8        Appendix B: Transport API Examples Use cases

NOTE: this Appendix will be revised to incorporate work with MEF

Figure 13 below shows the reference physical network (“God View”) where Service Provider (SP) physical NEs (colored in blue) are interconnected each other within the SP network and three Customer Edge (CE) NEs (colored in red) are connected through the SP network.

The circles represent the “interface number” of the physical interfaces attached to each node.

The UNI links (in read) are 10GE physical links while the NNI links (in blue) are 100G OTN physical links (OTU4).

It is also assumed that the CE NEs are IP routers using the SP network to setup IP links between them.

Interface P.4 (interface number 4 of node P) is not connected to any peer NE.

It is assumed that the whole SP network is managed by a single-domain SDN controller (SP Controller).

Figure 20 : Example Physical Network Topology

In order to be able to setup a ConnectivityService, ServiceInterfacePoints, representing shared knowledge between the customer and the provider, need to be pre-configured, based on customer and provider negotiation.

We consider three different scenarios where ConnectivityServices can be requested:

a)     In the simplest case, there is no information about an abstract network topology shared between the client application and service provider.

 

In this case, only the ServiceInterfacePoints are shared knowledge.

 

Only the ConnectivityService APIs are used by the client to manage ConnectivityServices between ServiceInterfacePoints. No path constraints can be requested in the connectivity setup request and no path information can be returned for a connection.

 

When a ConnectivityService request T-API is received, a connection controller within the service provider will internally call its path computation to setup the connection within the service provider network. This interaction is outside the scope of this document.

 

Topology and Path Computation T-APIs are not used between the client application and the service provider.

 

  1. The client application and service provider can also have shared knowledge of an abstract network topology.

 

The shared topology could be known a priori or retrieved via Topology API. This topology can be used to provide path constrains in the connectivity setup request and/or as a reference topology for returning the path of a connection.

 

The client application can internally call its path computation to derive the path constraints, based on this shared network topology view, of a connectivity setup request. This interaction is outside the scope of this document.

 

Path Computation T-APIs are not used.

 

  1. When the client application and service provider can also have shared knowledge of an abstract network topology, a further enhancement is possible.

 

Client application call the Path Computation T-API, with set of constrains based on abstracted NW view, to get a “list” of paths matching customer application constrains.

 

Client application can use this information to provide path constraints in the Connectivity Request Setup T-API to force the SP controller to select the path it prefers from the list returned by the Path Computation API.

 

This approach seems more useful in more complex scenarios e.g., a multi-domain network scenario where an orchestrator controller can request a domain controller to setup a sub-optimal path within its domain which would be part of the optimal multi-domain path.

8.1        10GE EPL Service over ODU2 Connection over 100G OTN network

In this use case the customer is willing to dynamically create a 10G IP Link between two of its CE routers connected to the SP network via two 10GE physical interfaces: for example an IP Link between CE1 and CE2 routers.

In this use case, it is assumed that the customer is requesting the service provider to forward all the Ethernet frames in the same manner, so only one Priority/CoS is implicitly defined for the EPL service.

In order to support this use case in the reference network example, it is sufficient to pre-configure three ServiceInterfacePoints: X, Y and Z such that, to create an IP Link between CE1 and CE2, a 10GE EPL Service needs to be requested between SEPs X and Y. Configuring a bandwidth constraint for this service is optional since, by definition, is shall be the same fixed bandwidth used on both the UNI Links associated with SEPs X and Y.

Figure 21 : Example 10GE EPL Service over ODU2

In the shared T-API context, X is a pool of one and only one potential L-EC (Link Ethernet Connection, as defined in G.8021) ConnectionEndPoint (CEP).

The customer controller knows also the mapping between this potential L-EC CEP within the shared context and the potential L-EC CEP associated to the CE1, port 1, and therefore it can infer that the SEP X maps to that L-EC CEP within its context.

Figure 22 : 10G EPL - Customer View of Connectivity

In a similar manner, the SP controller can infer that the SEP X maps to the potential L-EC CEP, within its context, associated with PE1, port 1:

Figure 23 : 10G EPL - Provider’s View of Topology exported to the Customer

Similar one-to-one mappings apply to Y and Z Service EPs.

When the 10GE EPL service is requested, an L-EC (Link Ethernet Connection, as defined in G.8021.1) connection (between PE1.1 and PE2.2) within the SP network will be created:

Figure 24 : 10G EPL - Provider’s View of Service/Connections exported to the Customer

Three different implementations, within the service provider, are possible

  • ODU2 connection
  • Service EC (S-EC) connection
  • PW connection

The choice can be based on network capability, service-provider policy, a pre-negotiated policy between customer and provider, dynamically chosen by the service provider controller e.g. based on the feedbacks from the path computation used within the SP controller.

Note – if there is a multi-layer shared abstract topology view, the path constraints of the service request can be used by the customer to constrain also the selection of the connection type. Detailed description of this use case is for further study.

As soon as the service is successfully created, the customer can create the IP Link, within the customer controller context, since there is a one-to-one mapping between the SEPs and the IP NEPs of the IP Link supported by the 10GE EPL Service:

Figure 25 : 10G EPL - Customer's view of Service/Connectivity

In this use case, there is one and only one L-EC connection within the shared context that can support the requested service. There is no need to report this L-EC connection, since it does not provide to the customer controller any additional information besides the fact that the service has been successfully setup.

8.2        1G EVPL Service over ODU0 Connection over 100G OTN network

In this use case the customer is willing to dynamically create a 1G IP Link between two of its CE routers, connected to the SP network via two 10GE physical interfaces which can be shared by different IP Links (using VLANs).

Also in this use case, it is assumed that the customer is requesting the service provider to forward all the Ethernet frames in the same manner, so only one Priority/CoS is implicitly defined for the EVPL service.

In order to support this use case in the reference network example, it is sufficient to pre-configure three SEPs: X, Y and Z such that, to create a 1G VLAN-based IP Link between CE1 and CE2, a 1G EVPL Service needs to be requested between SEPs X and Y. In this case the bandwidth profile for the EVPL service needs to be configured: it is assumed that the CIR is 1 Gb/s while the EIR is zero. The configuration of the CBS parameter is optional: if not specified, it can be chosen by the operator.

Figure 26 : Example 1G EVPL Service over ODU0

In the shared T-API context, X is a pool of 4k C-EC (Customer Ethernet Connection, as defined in G.8021) potential CEPs.

The customer controller knows also the mapping between these 4k potential C-EC CEPs, within the shared context, and the 4k potential C-EC CEPs as within its context, associated to the CE1, port 1, and therefore it can infer that the SEP X maps to those 4k potential C-EC CEPs within its context.

Figure 27 : 1G EVPL - Customer View of Connectivity

In a similar manner, the SP controller can infer that the SEP X maps to all the 4k potential C-EC CEPs, within its context, associated with PE1, port 1:

Figure 28 : 1G EVPL - Provider’s View of Topology exported to the Customer

Similar mappings apply to Y and Z Service EPs.

When the 1G EVPL service is requested, a C-EC connection (between PE1.1 and PE2.2) within the SP network will be created:

Figure 29 : 1G EVPL - Provider’s View of Service/Connections exported to the Customer

Three different implementations, within the service provider, are possible

  • ODU0 connection
  • S-EC connection
  • PW connection

The choice can be based on network capability, service-provider policy, a pre-negotiated policy between customer and provider, dynamically chosen by the service provider controller e.g. based on the feedbacks from the path computation used within the SP controller.

Note – if there is a multi-layer shared abstract topology view, the path constraints of the service request can be used by the customer to constrain also the selection of the connection type. Detailed description of this use case is for further study.

As soon as the service is successfully created, the Service Provider shall also report, within the shared context, a C-EC connection between C-EC CEPs that map to the actual C-EC CEPs, within the SP network. In particular, the actual C-EC CEPs, within the shared context, provide information of the C-VLAN ID values to be used at the edge of the SP network. Alternately, if the Customer wants to force (for whatever reason) a specific C-VLAN value to be used inside the pool (top-down choice), the intended C-VLAN can be specified as part of the constraints related to the setup of the C-EC connection.

Based on the C-EC connection, the customer controller can create the 1G VLAN-based IP Link, supported by the EVPL Service, between IP NEPs that map to the actual C-EC CEPs, within the shared context. In particular, the configuration of the C-VLAN ID values to be used on the IP NEPs, within the customer context, is inferred from the information in the associated actual C-EC CEPs, within the shared context.

Figure 30 : 1G EVPL - Customer's view of Service/Connectivity

In this use case, there is many possible C-EC connections within the shared context that can support the requested service. There is a need to report, within the shared context, the actual C-EC connection implementing the requested service to provide the customer controller the information it needs to properly configure the IP NEPs within its own context (e.g., the C-VLAN ID values).

8.3        Var-rate EVPL Service over EVC Connection over 100G OTN network

For further study

8.4        EVPL Service with Load Balancing

Detailed description of this use case is for further study. This section just provides few guidelines:

Figure 31 : EVPL Service with Load Balancing

In order to support this use case in the reference network example, in addition to the X, Y and Z SEPs, another SEP K needs to be created, such that, to create a 1G VLAN-based IP Link between CE1 and CE2, a 1G EVPL Service needs to be requested between SEPs X and K.

K is a pool of 8k C-EC potential CEPs in the shared context which, within the context of the Customer controller, maps with all the 8k potential VLAN-based IP Node EndPoints that can be created over CE2, ports 1 and 2.

Within the Provider controller, these 8k C-EC potential CEPs map with all the 8k potential C-EC CEPs associated with PE2, ports 2 and 4.

It is worth noting that SEPs Y and K have an overlapping set of potential CEPs.

8.5        Anycast EVPL Service

Detailed description of this use case is for further study. This section just provides few guidelines:

Figure 32 : Example Anycast EVPL Service

In order to support this use case in the reference network example, in addition to the X, Y and Z SEPs, another SEP H needs to be created, such that, to create a 1G VLAN-based IP Link between CE1 and either CE2 or CE3, a 1G EVPL Service needs to be requested between SEPs X and H.

H is a pool of 8k C-EC potential CEPs in the shared context which, within the context of the Customer controller, maps with all the 8k potential VLAN-based IP Node EndPoints that can be created over CE2, port 1 and CE3, port 1.

Within the Provider controller, these 8k C-EC potential CEPs map with all the 8k potential C-EC CEPs associated with PE2, port 2 and PE3, port 1.

It is worth noting that SEPs Y and Z K have overlapping set of potential CEPs with SEP H.


9        Appendix C: Multi-layer and Multi-domain Use cases

This section gives the usage examples of TAPI information model and API in a multi-layer and multi-domain network.

We  assume a  multi-layer and multi-domain Service Provider network configuration as shown in the following figure. The network includes 3 domains, each with an associated SDN Controller that acts as the Domain controller (DC).  These are coordinated by a Multi-Domain (MDC) SDN Controller which services two Clients, Client-R (Red) and Client-G (Green). Each Client has set of edge devices (CEs) connected to the SP network over UNI points. These Client interfaces (UNIs) are 10GE while the inter-domain interfaces (NNIs) are 100G OTU. Also it is assumed that all provider edge (PE) devices are capable of switching at both ETH and ODU layers while the internal devices can only switch at ODU layer.

For the TAPI SDN interface, the MDC interacts with each DC over a distinct TAPI Context exposed by that DC. A TAPI Context is defined by a set of Service Interface Points (SIPs). In this example, it is assumed that ServiceInterfacePoints are configured between the domains and at the network boundaries. Thus each controller exposes one SIP per UNI/NNI at its domain boundary. Similarly, the MDC exposes 2 distinct TAPI contexts over its SDN interface for each of its Clients.  The  SIPs at the client boundaries are mapped by the clients to their internal topologies (Red and Green SIPs) . Finally let us assume the presence of an additional “Admin” Context that provides a view of the internal resources of the MDC.

Figure 33 : Multi-layer and Multi-domain Example Network Configuration

9.1        Multi-layer and Multi-domain Topology Initialization

We assume that all the 3 controllers are within one service provider s scope, but for this example we assume that each DC expose s different type of topology abstraction of its managed network to the MDC .

The figure below depicts an example Topology exposed by DC-1 to the MDC over the TAPI Context-1. It is assumed that the exposed TAPI-Context Topology is a 2 Node abstraction (1 per layer) of DC ‘s network

Figure 34: Topology exposed by DC-1 to MDC

The figure below depicts an example Topology exposed by DC- 2 to the MDC over the TAPI Context-2. It is assumed that the exposed TAPI Context Topology contains one Node per device in the DC’s' network

Figure 35: Topology exposed by DC-2 to MDC

The figure below depicts an example Topology exposed by DC-3 to the MDC over the TAPI Context-3. It is assumed that the exposed TAPI Context Topology contains one Node per layer per device in the DC’s network.

Figure 36: Topology exposed by DC-3 to MDC

 

 

The figure below depicts an view of the MDC’s aggregated Topology which is assumed to be exposed over the TAPI “Admin” Context. This is basically an internal MDC view and is not expected to be presented to normal TAPI clients. This Context is defined by the SIPs (1.g, 2.R, 3.G, 4.R, 11.G, 12.R, 10.G, 9.R). This “Admin” Context contains the top-level aggregated topology composed by MDC. This top-level aggregated topology contains 3 Nodes D1, D2 & D3 each representing the domain context exposed by the respective underlying DC.  Each of these top-level Nodes encompass an “internal” topology which maps to the Topology exposed within the respective domain context.

It is a question of choice whether to only expose the UNI SIPs mapped to the edges of the aggregated topology or to also expose the “internal” NNI SIPs in this view. The latter would make sense if there is some use for those – like allowing the “Admin” client to request per-domain Connectivity (for testing purposes or otherwise). Finally if the “Admin” client is expected to make per-layer, per domain connectivity requests, then the SIPs at the layer boundaries can be defined/exposed (example TBD).

In Domain 1 the Ethernet switching domain (D1-e) and OTN switching domain (D1-o) are connected with a transitional link (dashed light blue link);  similarly in Domain 3, the Ethernet domains D3-1e and D3-2e are connected to the OTN domains D3-1o and D3-2o with transitional links (dashed light blue). This multi-layer topology enables cross-layer route computation in the controller.

Figure 37: MDC’s Aggregated Network Topology Exposed in the Admin Context

 

The topology exposed to the client is an abstracted view that is generated by the MD Controller and may provide much more limited information about the network.  For example, Client-G may only see a single node topology for the network.. The figure below depicts an example Topology exposed by MDC to its Green client over TAPI Context-G. It is assumed that exposed Topology is an edge-Node abstraction of MDC‘s internal Context

Figure 38: Topology exposed by MDC to Green Client

 

9.2        Multi-layer and multi-domain services/connections

In this example, to setup Ethernet over OTUk service in this multi-domain and multi-layer network involves the MD Controller setting up the OTUk service first and then using this to create an Ethernet link for the Ethernet service.  This leaves flexibility for the OTUk service to be used for additional Ethernet services. A n example service of 10GE EPL over OTN (multi-layer and multi-domain service) between ServiceEndPoint 1 and ServiceEndpoint 2 is requested in this network.

T he following is a summary of the API message exchange :

  1. Client-G requests a 10G EPL ConnectivityService between its SIPs (1.G, 11.G)
  2. MD-controller computes & provisions E2E connectivity within its internal topology
  3. MD-controller requests 10G ConnectivityService between SIPs (1.D1, 5.D1)
  4. Domain1-controller computes & provisions ODU+ETH Connections in its domain
  5. Domain1-controller returns provisioned Connections in terms of Context-1 topology
  6. MD-controller requests 10G ConnectivityService between SIPs (5.D2, 7.D2)
  7. Domain2-controller computes & provisions ODU Connections in its domain
  8. Domain2-controller returns provisioned Connections in terms of Context-2 topology
  9. MD-controller requests 10G ConnectivityService between SIPs (7.D3, 11.D3)
  10.                      Domain3-controller computes & provisions ODU+ETH Connections in its domain
  11.                      Domain3-controller returns provisioned Connections in terms of Context-3 topology
  12.                      MD Controller updates its internal Topology and resource pool capacity/usage metrics
  13.                      MD-controller returns provisioned Connections in terms of Context-G topology
    1. MD-controller updates capacity/usage metrics in Context-G topology

 

Figure 35 : Multi-layer and Multi-domain service/connection setup

9.3        Further work

ONF OTCC is currently discussing a Multi-layer/Multi-domain example with separation of the server layer and client layer connectivity services.  This may be added to the document.

Multi-domain protection and multi-domain P2MP/MP2MP service use cases are for further study .


10          Appendix D: Transport API Information Model Skeleton

 

Figure 36 : Transport API Information Model Skeleton

Figure 37 : Topology Service Skeleton

Figure 38 : ConnectivityService Skeleton

 

Figure 39 : Virtual Network Service Skeleton

 

Figure 40 : Path Computation Service Skeleton


11          Contributors

The Transport API Documentation Design team responsible for the writing of v2 of this document included:

  • Italo Busi, Huawei
  • Luis Contreras, Telefonica
  • Nigel Davis, Ciena
  • Kam Lam, Fiberhome
  • Lyndon Ong, Ciena
  • Karthik Sethuraman, NEC (Editor)
  • Ricard Vilalta, CTTC

Special thanks to everyone who have provided their input and comments to make this a better document.

12          Changes from TAPI FRD 1.0

The following is a list of the main changes in this specification from v1.0:

  1. Name Format: general change to camel case corresponding to UML model
  2. Terminology: Service EndPoint ServiceInterfacePoint (per agreement with MEF)
  3. Terminology: Service/Connection/Link Port EndPoint
  4. Topology Additions: Resilience-Type, NodeRuleGroup/InterRuleGroup/Rule
  5. ConnectivityService Additions: TopologyConstraints, ResilienceConstraints, Schedule, SwitchControl
  6. Model Change: Route changes from list of Connections to list of ConnectionEndPoints, as this provides equivalent information
  7. Model Change: Path changes from list of TELinks to list of Links, TELinks removed
  8. Notification: Updates made to add alarms and TCA
  9. Appendix Changes:
    1. Appendix A updated with new terminology
    2. Appendices A2-A4 added
    3. Appendix B to be updated pending MEF discussions – marked as such
    4. Appendix C updated to use new figures
    5. Appendix D UML diagrams updated

 

 


[1] Criteria for assigning/mapping ServiceInterfacePoints to NodeEdgePoints are out of scope of this FR, but are typically part of implementation agreement (IAs) and some examples are provided by the use cases in the appendices.

[2] The TAPI Connection Route is described in terms of Cross-Connections rather than Link-Connections. Conceptually a Connection Route is concatenation of Link Connections (resources associated with a Link) and Cross-Connections (resources within the Nodes in the underlying Topology) .

[3] The actual implementation-specific mechanisms to maintain, exchange or enforce the session state information is out of scope of this document and could be either maintained by the stateful API provider/server or offered by the API clients (as in stateless RESTful communication architectures)

[4] The number of ServiceInterfacePoints is restricted to 2 for the Path Computation request

[5] The value for Role is constrained to only Symmetric for the Path Computation request

 

[6] A session is the mechanism that supports information exchange between specific instances of an API client and an API server within a shared Context that has been secured by appropriate authentication and security credentials.   

[7] The capabilities of the PE-NE in the figure-2 above are further described in detail in Appendix C

[8] Criteria for assigning/mapping ServiceInterfacePoints to NodeEdgePoints are out of scope of this FR, but are typically part of implementation agreement (IAs) and some examples are provided by the use cases in the appendices B & C.