Open APIs

 View Only
Expand all | Collapse all

Alignment across IG1228 and IG1224 from Activation perspective.

  • 1.  Alignment across IG1228 and IG1224 from Activation perspective.

    TM Forum Member
    Posted Oct 07, 2021 14:56

    Hi All,

    I am going through the Mobile Use Case in IG1228 and I noticed that we don't use TMF640 Activation and Configuration API in the sequence diagrams. I see that the Resource Order Management System receives the TMF652 Resource Order and directly calls the HSS, PCRF and VMS APIs. Are we recommending that the Activation Systems should expose a TMF652 Resource Order API in an ODA Architecture and not TMF640 Activation and Configuration API? 


    In IG1224 NaaS Service Fulfillment Guidelines, we see a bigger role of TMF640 Service Activation and Configuration API where it is used to activate the Service in the Network. Do we have a different recommendations for B2B and B2C services in ODA where for Residential Services it is the TMF652 Resource Order API that is recommended and for complex connectivity services, it is recommended to expose TMF640 Service Activation and Configuration API for Activation? 




    ------------------------------
    Kinshuk Kulshreshtha
    Oracle Corporation

    My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.
    ------------------------------


  • 2.  RE: Alignment across IG1228 and IG1224 from Activation perspective.

    TM Forum Member
    Posted Oct 07, 2021 21:47
    Hi Kinshuk, 

        Yes, it is a keen observation and the NaaS team has taken one example and demonstrated how a traditional fulfillment process can be done using service abstraction to remove the resource knowledge from the BSS layer, therefore, increasing network agility, reducing time to market, and providing for non-technology-focused to deliver products and services. See IG1228 Use Case 10 ODA Flow with NaaS.  

        But the team is more focused on enhancing IG1224 than redoing other use cases the "NaaS-way".   IG1224 rel 4.0 just came out and includes SQM, usage management, and the link with Autonomous Network and Intent-based request.  We are starting work on V5.0 focused on adding service tests, service problems, and more details on SQM/CLA and AN. 

         Service providers have the choice to continue with the traditional method or transform to NaaS using service abstraction. 

        



    ------------------------------
    Johanne Mayer
    MayerConsult Inc
    NaaS Compass Inc - www.naascompass.com
    ------------------------------



  • 3.  RE: Alignment across IG1228 and IG1224 from Activation perspective.

    TM Forum Member
    Posted Oct 08, 2021 03:25
    Hello

    And adding to Johanne response, you have to consider, Kinshuk, that IG1228 provided an example of an API call flow to solve UC. The intent is not to provide a 'normative' flow but to demonstrate one way to cover the UC. It's perfectly valid to describe other alternatives. This particularly true for this articulation between SOM and Resource domains where you can use ServiceOrder describing RFS + Resource, or Resource Order, or Service Activation & Configuration, or Resource Activation & Configuration.

    Ludovic

    ------------------------------
    Ludovic Robert
    Orange
    My answer are my own & don't represent necessarily my company or the TMF
    ------------------------------



  • 4.  RE: Alignment across IG1228 and IG1224 from Activation perspective.

    TM Forum Member
    Posted Oct 08, 2021 05:04
    Edited by Kinshuk Kulshreshtha Oct 08, 2021 05:05
    Hi Ludovic,

    Thanks for the clarification that IG1228 provides "one way" to cover the use case and it may not be the 'recommended way' to address the UC. 

    Roland,

    Good to know about that you are planning to use TMF702 Resource Activation API that is in Beta.I think it makes a lot of sense to use it for individual resources. If you guys have regular working sessions to progress on IG1228 Mobile Use Case, I would like to be part of the working group as well so that I can contribute more to IG1228.

    ------------------------------
    Kinshuk Kulshreshtha
    Oracle Corporation

    My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.
    ------------------------------



  • 5.  RE: Alignment across IG1228 and IG1224 from Activation perspective.

    Posted Oct 11, 2021 02:44
    Hi Kinshuk,

    The IG1228 meetings are on Thursday 2PM CET. I believe they are open to everyone that partipates in the ODA project.

    Best regards,

    ------------------------------
    Roland Leners
    SATEC GROUP
    ------------------------------



  • 6.  RE: Alignment across IG1228 and IG1224 from Activation perspective.

    Posted Oct 08, 2021 04:30
    Hi Kinshuk,

    Referring to the IG1228 use case that you mention, we will consider introducing (as part of current Sprint-6) a component in charge of activation that is separate from order management. That component will be the provider of the activation and configuration APIs. We will initially focus on the resource activation API though (TMF702 in beta). 

    So far we have tried to not press too far ahead of the technical architecture team that defines the components. That is why activation is currently subsumed in the order management component and why Open API compliant activation calls are not explicitly shown (see also the first note below figure 13 of v1 of the use case). However there are some indications that the technical architecture team is also considering separate activation components, which prompts us to have a look at this as part of the current Sprint-6.

    Best regards,

    ------------------------------
    Roland Leners
    SATEC GROUP
    ------------------------------



  • 7.  RE: Alignment across IG1228 and IG1224 from Activation perspective.

    TM Forum Member
    Posted Jul 21, 2022 12:02
    I am coming back to this thread again to see if we have a clear guidelines on when to use TMF640 Vs TMF702 for Activation. Based on the current work, I am seeing that it is TMF640 for complex B2B SaaS type services and TMF702 for mass market B2C services like Mobile. Just want to check if Is it the pattern that gets extended to other services also eg: Should we use TMF640 to activate a VPN service and TMF 702 for broadband, TV etc?

    ------------------------------
    Kinshuk Kulshreshtha
    Oracle Corporation

    My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.
    ------------------------------



  • 8.  RE: Alignment across IG1228 and IG1224 from Activation perspective.

    Posted Jul 23, 2022 02:09
    Edited by Roland Leners Jul 23, 2022 03:35
    Hi Kinshuk,

    I am not sure that there clear guidelines, but here is the way the discussions have evolved on our side. From a networking perspective, the service concept provides a higher level of abstraction. Activating a service with TMF640 requires the providing component to orchestrate the activation of the underlying resources. I understand that this is e.g. a key characteristic of NaaS. If such capability is not present, the orchestration needs to be done by a resource order management component (e.g. catalog driven) which would integrate with resource activation via TMF702. So in my opinion, it is not a matter of the type of service, but an architectural choice which is a.o. driven by the capabilities of the existing stack (you are rarely in a greenfield situations with such projects).

    In the IG1228 use case that my company worked upon, we chose using TMF702. But this is illustrative and it was not our intention to imply that activation of mass market B2C mobile services would necessarily use this API. 

    Best regards,

    ------------------------------
    Roland Leners
    alvatross by SATEC
    ------------------------------



  • 9.  RE: Alignment across IG1228 and IG1224 from Activation perspective.

    TM Forum Member
    Posted Jul 23, 2022 10:24
    Hi Roland,

    Thanks for your inputs and clarifications. I think we need to come up with some guidance and recommendations on API usage perspective so that folks implementing the API have some clear pointers to decide. Let me summaries what you are saying and add my thoughts also to drive a discussion on it

    • TMF640 Service Activation APIs will be used in the cases where the Activation Systems receive a higher level Service Construct and break it into a lower level Resource Constructs to identify what all resources needs to be activated for this service. We typically see this behaviour in the activation of complex B2B services like NaaS, where we interact with WAN Controllers, Domain Controllers, SDN Controllers etc that are responsible for configuring multiple devices in their domain for the activation of a given Service. 
    • TMF702 Resource Activation API will be used when the Service Order Management System identifies what all resources needs to be activated for a given service and decompose the Service Order into smaller constructs and handover the responsibility to a Resource Order Management System that orchestrates the Resource Order into individual Resource Activation Requests to the Activation System. We see this behaviour in services like Mobile, Broadband etc. where for a given Broadband Order, the Service Management System works with Service Inventory to identify which ADSL Port needs to be activated on which DSLAM and handover that request to Activation System. We have a similar case for HSS, VMS and PCRF Profile Activations for Mobile. 
    • There can be cases where the Activation System for B2B Connectivity Service like VPN  does not have the intelligence to operate at a domain level, rather it operates at the resource level. In such cases, it expects the Service Order Management and Service Inventory to identify all the PE Routers, I-NNI, ENNI and CPEs to be configured for the activation of the VPN Service. In such cases, we may need to use TMF702 Resource Activation API for complex B2B services like L2 VPN as well. 

    Please let me know if you agree with the summary above. I am copying @Ludovic Robert @Johanne Mayer @Jonathan Goldberg for their inputs as well.

    ------------------------------
    Kinshuk Kulshreshtha
    Oracle Corporation

    My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.
    ------------------------------



  • 10.  RE: Alignment across IG1228 and IG1224 from Activation perspective.

    Posted Jul 25, 2022 04:44
    Hi Kinshuk,

    I agree with what you write.

    I believe that one of the key aspects concerns the management of the catalog. For a deep integration between the order management and the network, you need a deep catalog and deep exposure thereof. In e.g. a NaaS approach, the domain manager or service orchestrator embeds a catalog, but will not expose the full depth. You could replace some catalog layers by workflow configurations. From the outside you would not know because it is a black box. 

    Best regards,


    ------------------------------
    Roland Leners
    alvatross by SATEC
    ------------------------------



  • 11.  RE: Alignment across IG1228 and IG1224 from Activation perspective.

    TM Forum Member
    Posted Jul 25, 2022 19:00
    Hi Roland,

    Thanks a lot for your confirmation. 

    Tagging @Ludovic Robert @Johanne Mayer @Jonathan Goldberg @Vance Shipley @Derrick Evans @Dave Milham @Kamal Maghsoudlou @Koen Peeters @Stephane AH-KO to get their inputs as well. I think this discussion is related to the other discussion that has initiated in this thread. I am sure other folks would also be having similar doubts. So, having a clear recommendations from TMF perspective would be good and that can be added to IG1228 as well.


    ​​​​

    ------------------------------
    Kinshuk Kulshreshtha
    Oracle Corporation

    My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.
    ------------------------------



  • 12.  RE: Alignment across IG1228 and IG1224 from Activation perspective.

    TM Forum Member
    Posted Jul 25, 2022 23:51
    @Kinshuk Kulshreshtha solicits opinions on Activation APIs.  Activation APIs are produced by functions providing an activation service. In my humble opinion (TAC-280) we need to have ODA Components for Orchestration on the heat map.

    I also feel compelled to comment on the scope of the Service and Resource domains. A historical view may break this into physical Resources and logical Services however today we have a Resource domain dominated by software.  The current intent is that Network Services are represented by Resource Function while the Service domain contains the entities which go into Products. Just because it has "service" in the name doesn't make it a Service domain entity!

    With this in mind you'll probably find many of your use cases should technically use TMF664 rather that TMF702.

    For completeness I'll also add that we are missing Configuration​ pattern APIs. The distinction being that while 640/702/664 may be used to alter the configuration of an active entity a Configuration pattern API would manage configurations as first class, addressable, entities (i.e. day, evening, staged, template).​

    ------------------------------
    Vance Shipley
    SigScale
    ------------------------------



  • 13.  RE: Alignment across IG1228 and IG1224 from Activation perspective.

    TM Forum Member
    Posted Jul 26, 2022 19:57
    I completely agree with you @Vance Shipley that in many cases we would need to activate Network Functions (or Resource Functions) that are typically managed by NFVOs and VNFMs. So, in this cases using TMF664 Resource Function API would make more sense. However,  ETSI has came up with NFV-SOL API interfaces to handle the NFVO and VNFM abstractions. There is a work going on with ONAP to support ETSI API alignment

    How do you see TMF664 being uptake and adopted by industry as compared to the NFV-SOL APIs. I am not sure if they complement each other or compete. Is there a plan to align TMF664 with ETSI NFV-SOL APIs?

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



  • 14.  RE: Alignment across IG1228 and IG1224 from Activation perspective.

    TM Forum Member
    Posted Jul 27, 2022 01:18

    @Kinshuk Kulshreshtha asks:

    | How do you see TMF664 being uptake and adopted by industry as compared to the NFV-SOL APIs.

    If your organization has broad support of TM Forum Open APIs you may prefer to use TMF664 for better alignment.

    You might have an ODA Component for Orchestration/Activation which consumes the ETSI-NFV SOL005 API to drive NFVO. If your NFVO produces TMF664 it would be that ODA Component. Similar situation with Kubernetes.

    The real challenge is in creating an enterprise wide Management Continuum. If your organization has adopted ODA you have Catalogs (TMFC006/010) and Inventories (TMFC008/012) supporting Fulfillment, Assurance and Billing in Day 0,1,2. Multiple Catalogs and Inventories are to be expected however they should (must?) be federated. If you have technology domain specific silos you have broken the continuum. Accomplishing federation within ODA is a matter of maintaining the relationships (e.g. TMF639: resourceRelationship) however currently different APIs will mean siloed domains.

    I see ODA providing the path of least resistance to achieving a Management Continuum which I believe is an industry imperative. 

    | Is there a plan to align TMF664 with ETSI NFV-SOL APIs?

    There is a proposal (TMF729A) for an Open API extension which would enable external federation with relationship references supporting other APIs including SOL005 and SOL002. This would enable the ETSI NFV entities (i.e. NS, VNF) to be known within ODA. Below is a diagram from TMF729A showing navigation between ODA and NFVO:


    The proposal isn't specific to ETSI NFV APIs, it is meant to support navigation across management domains generally, and especially multi-cloud.

    It is commonly asserted that CNF are somehow exempt from being inventoried ("they move around") however those are just excuses. Kubernetes (k8s) knows where your CNFs are and produces an API to manage them. We should be able to reference those CNF with the TMF729A extensions.

    Keeping a federated inventory of k8s CNFs may be accomplished in a few ways: a) an ODA Component consumes the k8s API and produces TMF639, b) an Operator within k8s produces TMF639, or c) a k8s Operator consumes TMF639 to keep TMFC012 synchronized. Any of these approaches would keep your CNFs within ODA, maintaining a Management Continuum, and wouldn't require TMF729A.

    ... and if Nephio comes to mind, yeah, I'm on top of it. :)



    ------------------------------
    Vance Shipley
    SigScale
    ------------------------------



  • 15.  RE: Alignment across IG1228 and IG1224 from Activation perspective.

    TM Forum Member
    Posted Jul 29, 2022 12:24
    Historical Note: It is worth recalling that TMF664 was created by the ZOOM project to cover both the NFV0002  Os-ma stage 2 requirement  and the NFV out of scope OSS/BSS -Elements Management Interface. At that point in time NFV had indicated it would not produced a stage 3 specification for  what became SOL5 whcih came after we completed TMF664.

    TMF664 also supports a comprehensive EM management model based on Resource Functions(RF)   described in TR255 Resource Function Activation and Configuration Suite.
    Resource Functions are an integral part of the TMF Information Framework GB922 Resource domain so there integration with customer product service aspects is fully defined making these models easier to integrate with OSS BSS based on GB922. see also

    IG1161 Overview: Agile Intent-based Resource Management in Hybrid Environments R17.5.1




    ------------------------------
    Dave Milham
    TM Forum, Chief Architect
    ------------------------------



  • 16.  RE: Alignment across IG1228 and IG1224 from Activation perspective.

    Posted Aug 02, 2022 08:54
    Edited by Derrick Evans Aug 02, 2022 08:55
    Hello All,
    This thread is a very interesting read and there is a great deal to unpack here.
    Without getting into the various TMF Specs I will just recount some experience I had which might bring some of this into focus.

    I am not sure this discussion is really about B2B versus B2C but it is certainly about complexity.

    My background included consumer fixed broadband. In fulfilling an order for FTTC based consumer service, there was a great deal of decomposition and orchestration arising from a product order before you got to configuring individual network elements. What is more, all of this was seen as an OSS responsibility to manage relatively naked network elements. At the core of it was something which could take a service order and orchestrate the placing of orders with third party suppliers (for both ADSL modems and third party fixed access) as well as configuring VLANs and RADIUS servers and the like. So there was the CRM platform, the order orchestration platform and the individual domain based configuration and activation platforms involved. Moreover the orchestration platform had to monitor events over several days to complete an order.

    Then in latter years I got involved in consumer 3g,4g,and 5g mobile. Relating my previous experience to the mobile OSS architects their response was 
    "Well Derrick, we let the CRM layer deal with allocating the msisdn, sourcing the SIM and ordering the hand set. Provisioning the service then just involves taking the identities and policies from the CRM sourced order and updating three databases (HSS, Service Profile and VMS platform) over the course of a couple of minutes the "network" takes care of the rest itself."

    When you looked at the key information coming from CRM (as the platform raising the service order) there really wasn't any abstraction or much in the way of orchestration to deal with.

    ------------------------------
    Derrick Evans
    ------------------------------



  • 17.  RE: Alignment across IG1228 and IG1224 from Activation perspective.

    TM Forum Member
    Posted Aug 02, 2022 10:39
    Thanks @Vance Shipley and @Dave Milham for your insights into TMF664 and its history with ETSI NFVO APIs​​. This is very helpful to understand the rationale and background about co-existence of these APIs. 

    Thanks @Derrick Evans for sharing your experiences with various domains. They certainly match mine as well :) ​and I completely agree with you that it is all about the complexity and also the capability and the interface exposed by the Activation Systems.

    If Activation system receives a separate request to activate each resource for a Service like it is shown in IG1228 UC008 for Mobile, then probably TMF702 makes more sense. But if the Activation System is capable to take the request to activate multiple resources for a service in a single API call, then TMF640 would make more sense. This will be beneficial from performance perspective as well as it will reduce the number of calls to Activation System. eg: In case of Mobile, if the Activation system can expose a single API to receive the Activation Request for Mobile Service and has the ability to transform that call to  different downstream calls to HSS, VMS etc. then the sequence diagrams for Mobile would look a bit different from what we currently have in IG1228 UC008 for Mobile. Would you agree @Roland Leners


    ------------------------------
    Kinshuk Kulshreshtha
    Oracle Corporation

    My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.
    ------------------------------



  • 18.  RE: Alignment across IG1228 and IG1224 from Activation perspective.

    Posted Aug 03, 2022 06:49
    Hi Kinshuk,

    I agree. I personally think that the diagram referred to by @Vance Shipley (TAC-280) provides the right framework. The "Activation System" (using your terminology) could fulfill the function of a "Service Orchestration (or Activation)" or a "Resource Orchestration (or Activation)" component, depending on its capabilities. And the APIs would depend on this function, as shown in the diagram.

    In UC008 we could indeed have chosen an integration between Service Order Management and Service Activation (using TMF640), instead of 2 stage architecture with Service Order Management and Resource Order Management (integrating with Resource Activation using TMF702). We made this choice because we did not want to dodge the question on how the service or resources are eventually activated in the network. Even with a Service Activation component this question remains, unless one considers service activation as a black box and one is not interested how it orchestrates the underlying services and resources. But we were specifically interested in this orchestration aspect and wanted to show it as explicitly as possible.

    Maybe the choice of a mobile product was not the best one we could have made. But we did not want to drown in the complexities of e.g. a corporate B2B product, which could have obfuscated the goal of the use case.

    Hope these clarifications are helpful,

    Best regards,


    ------------------------------
    Roland Leners
    alvatross by SATEC
    ------------------------------



  • 19.  RE: Alignment across IG1228 and IG1224 from Activation perspective.

    TM Forum Member
    Posted Aug 03, 2022 09:59
    Thanks @Roland Leners for your confirmation. It validates my thinking and approach.

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



  • 20.  RE: Alignment across IG1228 and IG1224 from Activation perspective.

    Posted Aug 04, 2022 13:40
    One thing to remember about NaaS, is the need to review service composition and create a number of reusable, modular smaller atomic services that can be exposed, consumed and reused across multiple composite services, across multiple domains.  Telstra will speak about their experience in our Joint DTW session in creating these atomic services as they are continuously optimizing and evolving their services from years of experience doing NaaS.  It may not be easy to demonstrate that fact, but we tried to demonstrate it in IG1224A Use cases from what we had done in our Automating NaaS Lambda catalyst driven by AT&T. 

    ------------------------------
    Johanne Mayer
    Ciena Corporation
    ------------------------------