@Jonathan Goldberg
@Koen PeetersThanks a lot for your inputs on this. It is very helpful. In some threads I have seen that Service Candidate does not have any semantic meaning. But it seems that it does have a role to play and this is exactly where it needs to be used. That is really great!
@Stephan PelletierI am so happy that you joined this thread :-) . You have bought a very interesting point about Strongly Typed Service Order API, which MEF is driving with its LSO Legato API where they (or I should say you) have added MefServiceConfiguration. I see a similar Pattern here in your payload.
From Catalog perspective, if I try to reconcile what you have specified with what Jonathan and Koen has mentioned above, will it be fair to say that
my_service_variant1 can be modelled as a ServiceCandidate and
sliceTechnicalServiceType is similar to ServiceCandidateRef that @Koen Peeters has suggested to add to Service Order API?
Regards,
------------------------------
Kinshuk Kulshreshtha
Oracle Corporation
My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.
------------------------------
Original Message:
Sent: Nov 14, 2022 09:53
From: Stephan Pelletier
Subject: Service Offers in TMF633 Schema
Hi Kinshuk!
Happy to join you in this thread! (I miss you! :-) )
Agree with you that a catalog approach for more technical orders (such as internal service orders, but also service orders between partner companies) adds overhead in many ways.
What I am driving, across a few partner network operators (in context of MOCN operators for 5G Network Slicing), which would apply as well to internal service orders, is the use of strongly-typed Service Order API where, for one, you can define your own JSON schema (as sophisticated as you wish - it's actually needed for Slicing Service and Slice Profiles), not being constrained with the old flat serviceCharacteristics name-value pairs approach. This leverages a new "serviceConfiguration" section to-be-added to the TMF Service Order API (it should have been added a few years ago, as we had driven this in via the consortium of ONF, MEF, and TMF - but it is finally soon coming officially as a result of requirements of other TMF projects).
Example here of using serviceConfiguration:
serviceOrderItem:
- id: "1"
action: add
"@type": ServiceOrderItemAdd
service: {}
serviceConfiguration:
"@type": RanNetworkSliceSubnetAddAction
"@schemaLocation": http://nbi/api/v4/serviceSpecification/RanNetworkSliceSubnetAddAction.json
externald: ID
instanceName: RanSliceSubnet-Test1
serviceType: RanNetworkSliceSubnetAddAction
administrativeState: UNLOCKED
operationalState: ENABLED
networkSliceSubnetType: RN_SLICESUBNET
priorityLabel: 1
epTransportRef:
- N3_Tr_Slice1
sliceTechnicalServiceType: my_service_variant1
sliceProfileList:
- pLMNInfoList:
- sNSSAI:
sST: 1
sD: A1
pLMNId:
etc.
To answer directly your question (how do you differentiate between flavors of a same service), I introduced, as part of the service schema (RAN Network Slice Subnet, in this example) an attribute that I called "sliceTechnicalServiceType" (you can call it what you want for a Transport service using the same service schema). I basically expose ALL attributes possible for a RAN Network Slice Subnet (including RAN Slice Profile attributes) so the API supports any and every attribute possible (a generic RAN Network Slice Subnet exposure). Then, I complement with passing a sliceTechnicalServiceType which identify a variant (or blueprint) of a RAN Network Slice Subnet service. The client is "abstract" for any default or pre-defined values or other predefined Design & Assign business logic. This abstraction is very important. You want to hide the details from the interface. It is by using the simple sliceTechnicalServiceType attribute that the orchestration functionality executes the variant-specific Design & Assign rules (which can be static rules such as default or pre-defined values, or dynamic rules with different algorithms if needed). The only thing the client needs to know, other than which service attributes should be used, is what variant they need to ask for (as a simple sliceTechnicalServiceType value).
That's it!
Hope that's interesting to you!
Cheers!
------------------------------
Stephan Pelletier
STEPHAN PELLETIER CONSULTING INC.
Original Message:
Sent: Nov 12, 2022 22:40
From: Kinshuk Kulshreshtha
Subject: Service Offers in TMF633 Schema
Hi All,
Just like we have the concept of Product Offers in the Product Catalog API, do we have anything similar to model Service Offers in TMF633 Service Catalog API? This may be needed for CSPs internal infrastructure services that are ordered by the Network Teams to build the Network Infrastructure. eg: I can have a Transport Domain Infrastructure service that is needed to be built in the network for upcoming B2B customer orders. But I offer only 2 flavours of Transport Domains, Gold Transport for mission critical services with ultra low latency and jitter and Standard Transport for standard services. So, on top of my Transport Domain service, that may have a set of characteristics to define these network properties, I would like to create 2 Service Offers where I can set the default values of specific characteristics to drive the behaviour for Standard Transport and Gold Transport.
One way to model this is to use full Product Catalog with Product Specs, Product Offers etc, which seems to be an overhead in this case because these services are owned by the Network Infrastructure team and never exposed to customers. Also, there is no customer billing involved here as these are internal services. Hence, I am looking for a simple construct that I can create above my Service Specifications that can specify the default value of various characteristics for each flavour. Please let me know what is the recommended way to model this requirement in TMF. I don't see anything called Service Offer in TMF633 Schema.
Regards,
Kinshuk
------------------------------
Kinshuk Kulshreshtha
Oracle Corporation
My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.
------------------------------