Thanks Dave for this very detailed reply.
Specifically regarding the Open API - the Open API data model is derived directly from the TMF Information Framework (the SID) with a number of simplification rules.
The NaaS suite referred to by Dave contains a part of the full data model, in the service domain.
All the recently-published Open API swaggers and specifications (user guides) are generated from this common data model, so the model is effectively being published piece-meal. I believe that the intention is to publish the model as a separate deliverable at some time in the future but I don't know what the exact plans are.
We do not model (in the Open API and in the SID) specific types of products, services, or resources - rather we use the specification pattern, allowing definition of (say) Broadband, VPN, A-side connection, etc., as product/service/resource with characteristics. As Dave mentioned, it is possible to create specific subclasses to represent concrete types, using the extension mechanisms described in the Open API design guidelines (recently published as draft
here). The Resource Catalog API user guide (
here) includes an introductory section describing more specifically how to extend catalog models.
Hope it helps
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
------------------------------
Original Message:
Sent: Jun 08, 2020 10:07
From: Dave Milham
Subject: Open API compatibility with TMF 814/MTOSI
Interesting question . For Open Digital Architecture (ODA)-see IG1167 ODA Functional Architecture v5.0.1 -
we introduced a notion of ODA Production where all fulfilment happens as separated from commercial and general purpose Core Commerce / Product Ordering . this focus on decoupling was not a key consideration in MTOSI ./MTMN/ MTOP
We developed as more detailed model for ODA Production in GB999 ODA Production Implementation Guidelines v4.0.1
this was developed from around six 5G related catalyst Projects.
It is predicated on two assumptions
- Service exposed by ODA Production are resource technology neutral and are preferable intent based ( implying simply data models rather than complex resource hierarchies s
- Use of TMF909 API Suite Specification for NaaS v3.0.1 as the API technical interface ( REST / JSON Schemas)
The open issue with the data model used in the NaaS is that they need need to be extended for most practical cases. This is readily achieved with use of schemas. For the legacy networks technologies we haven't had interest in creating these but use of ONF 512 and TMF TR275 models it should be possible to do that.
For 5G candidate data model extensions are just being published in IG1211 and IG 1217 and an intent based approach in IG1194 Focus on Services not Slices v1.0.1 These documents have detailed schema extension proposals/Candidates. IG 1211 and 1217 are in the publication process but re available to members registered on the ODA project at:
IG1217 Resource Inventory of 3GPP NRM for Service Assurance v1.0
IG1211 ODA 5G Management Implementation Guidelines v1.0
------------------------------
Dave Milham
TM Forum chief architect
Original Message:
Sent: Jun 06, 2020 07:21
From: Umashankar Nair
Subject: Open API compatibility with TMF 814/MTOSI
I am relatively new to the TMF open API standards. I would like to know if we have an object model defined in open api which is similar in nature to the one present in the TMF 814 CORBA standards. It would be helpful if someone could point out to the TMF Open API standards which are compatible with either TMF 814 or MTOSI
------------------------------
Umashankar Nair
Alphion Corporation
------------------------------