|
1 | | -# ONF Open Transport API (TAPI) |
2 | | -This is a repository for the ONF Transport API SDK. This SDK is being released under the Apache 2.0 license. |
| 1 | +# Linux Foundation ONMI Project Transport API (TAPI) |
3 | 2 |
|
4 | | -The ONF [Transport API](https://wiki.opennetworking.org/display/OTCC/TAPI) (TAPI) project charted under the [ONF Open Transport Configuration & Control](https://www.opennetworking.org/projects/open-transport/) (OTCC) is responsible for the development of this SDK as an Open Source project. This release supports technology-agnostic interfaces to the following functional modules: |
| 3 | +**This is the release version ***2.1.5*** of the Linux Foundation ONMI Project Transport API (TAPI) SDK |
| 4 | +This SDK is being released under the Apache 2.0 license.** |
| 5 | + |
| 6 | +The [LF TAPI](https://github.com/Open-Network-Models-and-Interfaces-ONMI/TAPI-Home) project is [chartered ](https://github.com/Open-Network-Models-and-Interfaces-ONMI/onmi-home/blob/main/ONMI-charter) under the LF Projects. [OMNI ](https://github.com/Open-Network-Models-and-Interfaces-ONMI/onmi-home/wiki) TAPI is responsible for the development of this SDK as an Open Source project. |
| 7 | + |
| 8 | +This [release](https://github.com/Open-Network-Models-and-Interfaces-ONMI/TAPI/tree/v2.1.5) includes technology-agnostic interfaces to the following functional modules: |
5 | 9 | - Topology Service |
6 | 10 | - Connectivity Service |
7 | 11 | - OAM Service |
8 | 12 | - Path Computation Service |
9 | 13 | - Virtual Network Service |
10 | 14 | - Notification Service |
| 15 | +- Equipment Inventory Service |
| 16 | +- Streaming Service |
| 17 | +- Physical Route (new) |
11 | 18 |
|
12 | | -It also include support for the following technology-specific interface profiles |
| 19 | +It also includes support for the following technology-specific interface profiles |
13 | 20 | - Carrier Ethernet (L2) |
14 | 21 | - Optical Transport Network (L1-ODU) |
15 | 22 | - Photonic Media (L0-WDM) |
16 | 23 |
|
17 | | -The TAPI project delivers [SDKs releases](https://github.com/OpenNetworkingFoundation/TAPI/releases) periodically and includes the following components: |
18 | | -- ***TAPI UML Information Model*** - The TAPI UML models included in an TAPI SDK release are a **_normative_** part of the TAPI SDK and are the only source for subsequent generated TAPI SDK components (YANG, OAS, etc.). |
19 | | - - These models are pruned/refactored from the [ONF Core Information Model 1.3.1](https://3vf60mmveq1g8vzn48q2o71a-wpengine.netdna-ssl.com/wp-content/uploads/2018/01/TR-512_v1.3.1_OnfCoreIm-info.zip) |
20 | | - - Some of the UML model artifacts (e.g., Classes, Attributes, Types) that the TAPI contributors consider to be evolving are marked as ***experimental*** using the UML OpenModelProfile stereotypes. These artifacts could either become mature or *change/evolve* in future releases. |
21 | | -- ***TAPI YANG Schema*** - The TAPI YANG models included in an TAPI SDK release are a ***normative*** part of the TAPI SDK. |
22 | | - - The YANG specifications are generated from the corresponding UML model in the SDK release using the [ONF EAGLE UML2YANG mapping tool](https://github.com/OpenNetworkingFoundation/EagleUmlYang) and further edited manually to comply with the [ONF IISOMI UML2YANG mapping guidelines](https://wiki.opennetworking.org/display/OIMT/UML+-+YANG+Guidelines). |
23 | | - - Status of YANG model artifacts can be determined by referring to the corresponding UML artifacts. As described in the UML models, some artifacts are considered *experimental*, and thus the corresponding YANG artifacts. |
24 | | - - The ONF TAPI release process does not guarantee backward compatibility of YANG models across major versions of TAPI releases. The YANG model backward compatibility criteria are outlined in section 11 of (https://tools.ietf.org/html/rfc7950). |
25 | | -- ***TAPI OpenAPI Specififcation*** - TAPI OAS (OpenAPI Specifications) included in an TAPI SDK release are an ***informative*** part of the TAPI SDK and are the _recommended_ REST API specifications to be used for TAPI interoperability based on a particular SDK release. |
26 | | - - The OAS are generated from the YANG data models included in the corresponding SDK release using the [ONF EAGLE YANG2OAS](https://github.com/OpenNetworkingFoundation/EagleYangOpenAPI) tool following the RESTConf protocol specification (https://tools.ietf.org/html/rfc8040). This specification makes no assessment as to the level of RESTConf compliance of the TAPI REST APIs. |
27 | | - - Implementations may use other forms of REST APIs but must be based on the YANG models defined in the corresponding TAPI SDK release and are subject to implementation agreements between concerned parties for interoperability. |
28 | | -- ***TAPI Reference Implementation*** - the python code stubs for which are generated using the [Swagger Codegen](https://swagger.io/tools/swagger-codegen/) |
29 | | -- ***TAPI Implementation Guide*** - a PDF document providing an overview of the SDK. |
30 | | - |
31 | | -Changes included in an TAPI release are listed in https://github.com/OpenNetworkingFoundation/TAPI/blob/develop/CHANGE_LOG/ |
| 24 | +The SDK includes the following components: |
| 25 | +- **_TAPI UML Information Model_** - The TAPI UML models included in this TAPI release (v2.1.5) are a partially normative part of the TAPI SDK and are the only source for subsequent generated TAPI SDK components (YANG, OAS, etc.). |
| 26 | + - These models are pruned/refactored from the (formerly ONF) Core Information Model (ITU-T G.7711). |
| 27 | + - Some of the UML model artifacts (e.g., Classes, Attributes, Types) that the TAPI contributors consider to be evolving are marked as experimental using the UML OpenModelProfile stereotypes. These artifacts could either become mature or change/evolve in future releases. |
| 28 | + - Note that in earlier releases the UML was fully normative. Going forward it is expected that UML will be used solely as an aid for analysis. At this point the UML is still aligned with the YANG. |
| 29 | + |
| 30 | +- **_TAPI YANG Schema_** - The TAPI YANG models included in this TAPI release (v2.1.5) are a normative part of the TAPI SDK. |
| 31 | + - The YANG specifications have been generated from the corresponding UML model using the [EAGLE UML2YANG mapping tool](https://github.com/Open-Network-Models-and-Interfaces-ONMI/onmi-iisomi-uml-yang) ("Tapi_v2x" branch) and further edited manually to comply with the [IISOMI UML2YANG mapping guidelines](https://github.com/Open-Network-Models-and-Interfaces-ONMI/onmi-iisomi-home). |
| 32 | + - Status of YANG model artifacts can be determined by referring to the corresponding UML artifacts. As described in the UML models, some artifacts are considered experimental, and thus are the corresponding YANG artifacts. |
| 33 | + - The TAPI release process does not guarantee backward compatibility of YANG models across major versions of TAPI releases. The YANG model backward compatibility criteria are outlined in section 11 of [RFC7950](https://tools.ietf.org/html/rfc7950). |
| 34 | + YANG models included in this release are backward compatible with previous ***TAPI 2.1.3*** release. |
| 35 | + |
| 36 | +- **_TAPI OpenAPI Specification_** - TAPI OAS (OpenAPI Specifications) included in this TAPI release (v2.1.5) are an informative part of the TAPI SDK. |
| 37 | + - The OAS have been generated from the YANG data models included in this release using the [EAGLE YANG2OAS](https://github.com/Open-Network-Models-and-Interfaces-ONMI/onmi-iisomi-yang-openapi) tool following the RESTConf protocol specification [RFC8040](https://tools.ietf.org/html/rfc8040). This specification makes no assessment as to the level of RESTConf compliance of the TAPI REST APIs. |
| 38 | + - Implementations may use other forms of REST APIs but must be based on the YANG models defined in this release and are subject to implementation agreements between concerned parties for interoperability. |
| 39 | + - The OAS has not been changed from the version released with TAPI release v2.1.3. |
| 40 | + |
| 41 | +- [Documentation associated with this release](https://github.com/Open-Network-Models-and-Interfaces-ONMI/TAPI-Documentation/releases/tag/v2.1.5) |
| 42 | + |
| 43 | +As the most deployed release of TAPI at this point is TAPI 2.1.3 (TIP recommended) a detailed differences between 2.1.3 and 2.1.5 can be obtained using |
| 44 | +- https://github.com/Open-Network-Models-and-Interfaces-ONMI/TAPI/compare/v2.1.3...v2.1.5 |
| 45 | + |
| 46 | +As TAPI 2.5.x is also a TIP recommended release a detailed differences between 2.1.5 and 2.5.2 can be obtained using |
| 47 | +- https://github.com/Open-Network-Models-and-Interfaces-ONMI/TAPI/compare/v2.1.5...v2.5.2 |
| 48 | + |
| 49 | +[**_HighLevelDiff_Tapi2.1.3To2.1.5.pdf_**](https://github.com/Open-Network-Models-and-Interfaces-ONMI/TAPI-Documentation/tree/v2.1.5/DeltaDocument) highlights the key changes from 2.1.3 to 2.1.5 |
| 50 | + |
| 51 | +## What's Changed |
| 52 | +* Tapi 2.1.3 fixes by @nigel-r-davis in https://github.com/Open-Network-Models-and-Interfaces-ONMI/TAPI/pull/661 |
| 53 | +* YANG updates for 2.1.5 by @nigel-r-davis in https://github.com/Open-Network-Models-and-Interfaces-ONMI/TAPI/pull/663 |
| 54 | + |
| 55 | +**Summary of changes** |
| 56 | +- Addition of physical route |
| 57 | +- Addition of paginated get (experimental) |
| 58 | +- String field restrictions relaxed to “any conformant YANG string” throughout. Explanation added in TR-547 section 2.8 String fields. |
| 59 | +- transmited-power, received-power, otsi-termination, selected-application-identifier and otsi-config made Conditional. |
| 60 | +- Various minor improvements to documentation |
0 commit comments