Open APIs

 View Only
  • 1.  Query on IPVPN service order / activation scenario

    TM Forum Member
    Posted May 12, 2024 22:54

    We have a scenario on IPVPN service order/activation whereby it requires response parameters such as port number, ip address and subnet mask/prefix-length.

    Which TM Forum Open API is suitable to address above scenario?





      ------------------------------
      Tajul Fakhar Fahirurazi
      TM Technology Services Sdn Bhd
      ------------------------------


    1. 2.  RE: Query on IPVPN service order / activation scenario

      TM Forum Member
      Posted May 13, 2024 00:53

      How about TMF640 - Service Activation and Configuration?

      The request body of POST in this API is a Service, as is the response body. So your network element (or adapter) can enrich the service characteristics in the response body.

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



    2. 3.  RE: Query on IPVPN service order / activation scenario

      TM Forum Member
      Posted Jun 13, 2024 03:40
      Edited by Ilyas Premji Jun 13, 2024 06:06

      Hi Jonathan,

      Same scenario for  IPVPN service activation, what is the suitable TMF API to be used between Service Orchestrator and the NMS? The NMS is managing traditional ip mpls network. 

      I'm baffled either to use TMF640, TMF664, TMF702 or others? 

      Could you enlighten me?



      ------------------------------
      Wan Ahmad Rahimi Nik
      TM Technology Services Sdn Bhd
      ------------------------------



    3. 4.  RE: Query on IPVPN service order / activation scenario

      TM Forum Member
      Posted Jun 14, 2024 04:54

      I'm afraid that's way beyond my knowledge, sorry. You basically have three APIs - Service Activation, Resource Function Activation, Resource Activation

      So if you're activating a service, I guess service activation (TMF640) would be appropriate.



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



    4. 5.  RE: Query on IPVPN service order / activation scenario

      TM Forum Member
      Posted Jun 14, 2024 13:47

      Thank you for your feedback 



      ------------------------------
      Wan Ahmad Rahimi Nik
      TM Technology Services Sdn Bhd
      ------------------------------



    5. 6.  RE: Query on IPVPN service order / activation scenario

      TM Forum Member
      Posted Jun 14, 2024 06:54
      Edited by Dave Milham 23 days ago

      The current answer is the APIs in the NaaS API Component Suite TMF909 and supporting document IG1224  which is TMF 640 or 641. depends a bit on the exact capabilities of the NMS and the extent to which the Service orchestrator to know the internal of the technology domain exposed by the  NMS. I recall this is discussed in IG1224

      However we have a major study in this area on Self Healing Domains with a focus on networks. Current network offer re evolving to self healing and use of intent management which means NaaS and APIs will need to evolve this may not be important if you are interfacing to previous  generation NMS. Meeting for Self healing domains are on Wednesdays at 10:00 BST where scenarios use cases are being discussed there is also a deeper dive on this topic on ODA production   Thursday 10:30 BST. Note next week most of the teams are at DTW. so next meeting are in the week commencing  24th June 2024. Are you attending DTW next week if so we could set up an appointment? to discuss further?



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



    6. 7.  RE: Query on IPVPN service order / activation scenario

      TM Forum Member
      Posted Jun 14, 2024 13:48

      Thank you for the info.

      I'm not joining DTW event next week, may be we catch up later.



      ------------------------------
      Wan Ahmad Rahimi Nik
      TM Technology Services Sdn Bhd
      ------------------------------



    7. 8.  RE: Query on IPVPN service order / activation scenario

      TM Forum Member
      Posted Jun 15, 2024 02:14
      Edited by Vance Shipley 24 days ago

      If "Service Orchestrator" were an ODA Component your question could be answered authoritatively, however it is not, although it has been proposed.

      Your question becomes one of whether to model and manage entities of the Service or Resource domains.

      When viewed from an ODA Core Commerce block perspective a Customer Facing Service (CFS) is required to be put into a Product.  Activating a CFS is done with TMF640.

      When viewed from an ODA Production block perspective, holistically, an IP MPLS network is in the Resource domain and a Resource Function (RF) is the correct choice for representing a Network Service (NS), such as an IETF service chain (VPN).  Activating an RF is done with TMF664.

      You mention NMS, which includes functions for configuration, fault and performance management (CM, FM, PM). Where an NMS is managing Resource domain network elements you should use TMF664 and TMF702 for CM, TMF642 for FM and TMF628 for PM.

      Between a CFS and an RF you have a Resource Facing Function (RFS) which is an entity of the Service domain. The original purpose of an RFS was to encapsulate technology specifics so that RFSs may change without necessitating a CFS change. RF was a more recent addition and, if done correctly, should be reusable as you switch out network vendors, for example. This leaves less of a role for RFS.

      Many have a Service domain centric view, managing CFS/RFS with ODA and Open APIs and leaving the Resource domain as an integration exercise using whatever protocols vendors support. This is essentially the NaaS view (Network-as-a-Service).

      If I were a vendor of network solutions I might want to support both TMF640 and TMF664 so that the choice of a Resource or Service domain centric solution could be left to the CSPs. Those APIs are quite similar so it isn't much of a burden.



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