Open APIs

Expand all | Collapse all

TMF-641 vs TMF-640

  • 1.  TMF-641 vs TMF-640

    TM Forum Member
    Posted Dec 03, 2018 14:10
    Hi,

    There is ambiguity in terms of scope of TMF-641 vs TMF-640. Is there any material that I can refer to that describes the purpose of TMF-641 vs TMF-640.

    If there isn't one I would like to propose something and get the community feedback on it.

    Am considering mapping eTOM processes to be supported by TMF-641(Process Identifier - 4.5) and TMF-640(Process Identifier - 4.5.4)

    Regards
    Srinivas

    ------------------------------
    Srinivasa Vellanki
    Amdocs Management Limited
    ------------------------------


  • 2.  RE: TMF-641 vs TMF-640

    TM Forum Member
    Posted Dec 04, 2018 02:05
    ​In my humble view, TMF-641 is a kin to MEF 55's CANTATA (CUS:BUS), and TMF-640 is roughly similar to LEGATO (BUS:SOF).
    Or at least that's where I would use both.

    ------------------------------
    Sergey Zak
    Australia
    Senior Domain Architect
    ------------------------------



  • 3.  RE: TMF-641 vs TMF-640

    TM Forum Member
    Posted Dec 04, 2018 04:31
    Hello

    There are differences between TMF640 & TMF641 . We got this conversation one year ago in ONAP project (we implemented TMF API). I could invite you to go to this page: External API Framework Files - Developer Wiki - Confluence
    Onap remove preview
    External API Framework Files - Developer Wiki - Confluence
    Files that are contributions to the External API Framework project
    View this on Onap >
    and look for a document called 'ONAP Sharing Session - TMF640 - TMF 641.pptx' posted Dec 20, 2017.

    We implemented TMF641 and since then we envision to implement partially 640 for interlude-like UC.

    Hope it helps

    Ludovic

    ------------------------------
    Ludovic Robert
    Orange
    ------------------------------



  • 4.  RE: TMF-641 vs TMF-640

    Posted Dec 04, 2018 04:31
    ​This is something that we wrote in the NaaS API component suite when we had both TMF640 & TMF641 included:

    There is some inherent flexibility in the TMF Open API design to support different business models.   One area where this flexibility is clear is whether the network exposes single services and service order processing is fully a BSS responsibility.  Or the network may accept the full or partial service order and service order processing is a network responsibility. The decision would drive the usage of TMF 641 and/or 640.

     

    Also refer to IG1164 Requirements Analysis for the Ordering and Configuration of Services and Resources: with Impacts on APIs and Information Models for further information.



    ------------------------------
    Johanne Mayer
    Telstra Corporation
    ------------------------------



  • 5.  RE: TMF-641 vs TMF-640

    TM Forum Member
    Posted Dec 05, 2018 03:43
    Edited by Srinivasa Vellanki Dec 06, 2018 08:28

    Since my posts were not appearing on submit, didn't know if they were taken or not, leading to duplication. So am updating this post to remove the content which is already in another post below.

    ------------------------------
    Srinivasa Vellanki
    Amdocs Management Limited
    ------------------------------



  • 6.  RE: TMF-641 vs TMF-640

    TM Forum Member
    Posted Dec 05, 2018 05:06
    Hi,

    I would like to add my view on the difference between TMF640 and TMF641.
    TMF641 is the northbound interface of a service order management system (SOM). Via this northbound API the service order management receives requests to perform actions on one or more services (CFS).
    It is the responsibility of the SOM to implement a process  called service design to derive from this set of CFS a set of RFS that need to be activated, modified or deactivated.
    It is also the responsibility of the SOM to orchestrate the activation of these RFS while respecting dependencies on required resources and other rfs.
    For the activation of each RFS the SOM will TMF640 as a southbound interface towards a service platform.



    ------------------------------
    Koenraad Peeters
    Ciminko Luxembourg
    ------------------------------



  • 7.  RE: TMF-641 vs TMF-640

    TM Forum Member
    Posted Dec 05, 2018 18:46
    Edited by Srinivasa Vellanki Dec 07, 2018 08:25

    Had problem with uploading Images or any attachments. Tried using different browsers but doesn't seem to help.

     

    Thank you for all the inputs.

     

    Am trying to summarize my understanding and also sharing some new aspects that I did like to use to differentiate between TMF-641 and TMF-640. Please share your feedback.

     

    Architecture Options:

    Option-1: TMF-641 should be the Interface for BSS to request Services using Service Orders.

    Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

     

    Differences:

    Differences between TMF-641 and TMF-640 in terms of functional capabilities. Architecture option should be chosen based on these capabilities and not extend the capabilities of TMF-640 to make it look like TMF-641 thus defeating the purpose of two(TMF-641 and TMF-640) standard Interfaces and making them ambiguous.

     

    TMF-641

    1. Operations(CRUD) on Service Order
    2. Service Order can contain multiple Services
    3. Support for Composition and Decomposition to RFS(s) and Resource(s)
    4. Support for Long Running Business Processes, support for Inflight changes to Service Order
    5. Provider of TMF-641 works with Service Inventory using TMF-638

    6. TAM Functions supported: Design Solution, Assignments, Reservation, Manage Service Dependencies, Manage Service Instance, Address Validation, Plan for Service Configuration and Activation and Service Configuration & Activation(using TMF-640)
    7. Orders can result in partial success and provide control to the consumer to handle/resolve the failed aspects.

     TMF-640

    1. Operations(CRUD) on Service(typically RFS, however in case of Architecture Option2 can be Service which represents both CFS and RFS)
    2. Request operates on Single Service
    3. Support for Decomposition to Resource Provisioning requests on a single Resource only
    4. Support for short lived Business Processes, no need for Inflight changes of Service Request.
    5. Provider of TMF-640 doesn't need Service Inventory

    6. TAM Functions supported: Service Configuration & Activation. Infrastructure(Devices & Networks) for the Service are expected to be pre-existing.
    7. Service requests are atomic, complete success or complete failure.
    ------------------------------
    Srinivasa Vellanki
    Amdocs Management Limited
    ------------------------------



  • 8.  RE: TMF-641 vs TMF-640

    TM Forum Member
    Posted Dec 05, 2018 11:22
    Hi Sergey, Srinivas
    Can I suggest you engage with @Ludovic Robert​​, who leads the Service Ordering API, he can hopefully give his view of the relationship between this and the Service Activation API (to be renamed I believe in R18.5 from Activation and Configuration).

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    ------------------------------



  • 9.  RE: TMF-641 vs TMF-640

    Posted Dec 04, 2018 05:24
    The way I've seen 640 is more like the degenerate case of TMF641.   You can run 641 with just a single service entry or with multiple.   One thing that's been apparent in the MEF ordering work is that technical inter-carrier ordering gets quite into the detail of the service sub-components.   Serviceability is at a UNI not ELINE level.

    Much of this is subjective in any case.   If I'm describing an Ethernet service between two customer locations I'll have a couple of UNIs and an EVC description in the request, whether they are data sets or service objects is an implementation choice.   At the same orchestration/abstraction layer you'll need the same data.

    Mark

    ------------------------------
    Mark Gibson
    Amdocs
    MEF Applications Committee co-chair
    ------------------------------



  • 10.  RE: TMF-641 vs TMF-640

    TM Forum Member
    Posted Dec 06, 2018 03:47
    Hello

    Agreed.
    Just one quick add...TMF640 features a monitor resource that is associated to a service change request and allow to manage async process. It is useful (We use it as well to log request).

    Best regards

    ------------------------------
    Ludovic Robert
    Orange
    ------------------------------



  • 11.  RE: TMF-641 vs TMF-640

    TM Forum Member
    Posted Dec 06, 2018 02:16
    Thank you

    Am completely aligned with this.

    ------------------------------
    Srinivasa Vellanki
    Amdocs Management Limited
    ------------------------------



  • 12.  RE: TMF-641 vs TMF-640

    TM Forum Member
    Posted Dec 06, 2018 02:16
    Sure will do

    ------------------------------
    Srinivasa Vellanki
    Amdocs Management Limited
    ------------------------------



  • 13.  RE: TMF-641 vs TMF-640

    TM Forum Member
    Posted Dec 07, 2018 09:05
    Appreciate inputs on the differences between TMF-641 and TMF-640.

    Have added the 7th difference. Also changed point 2 on TMF-640 to restrict to Single Resource.

    ------------------------------
    Srinivasa Vellanki
    Amdocs Management Limited
    ------------------------------



  • 14.  RE: TMF-641 vs TMF-640

    TM Forum Member
    Posted Nov 11, 2020 11:01
    Hi Srinivasa,et al,

    Regarding the 2nd  Option here:-

    Architecture Options:

    Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

    Scenario :- There is a SOM in the business and which is CFS and while sending down the notifications related to the service to the other RFS's in the domain ,but not in TMF640 structured way , Can we expect the CFS interface to send the payload or the data in already structured form i.e, more alike TMF 641 standard ?
    What could be the impact on the SOM which is already on TMF 641 to manipulate the data to TMF 640 before sending it down to RFS nodes in topology ?



    Regards
    Manisha

    ------------------------------
    MANISHA MALLA
    Telstra Corporation
    ------------------------------



  • 15.  RE: TMF-641 vs TMF-640

    TM Forum Member
    Posted Dec 06, 2018 09:11
    Hi Ludovic,

    Am proposing to not support async process for TMF-640. If we support async process then there will arise need for in-flight changes to the earlier request, resulting in Service Configuration/Activation Request being similar to Service Order.

    If we agree on point 6 "TAM Functions supported: Service Configuration & Activation. Infrastructure(Devices & Networks) for the Service are expected to be pre-existing" on TMF-640, then we will not need async process for TMF-640.

    Regards
    Srinivas

    ------------------------------
    Srinivasa Vellanki
    Amdocs Management Limited
    ------------------------------



  • 16.  RE: TMF-641 vs TMF-640

    TM Forum Member
    Posted Nov 22, 2020 06:00
    Edited by Srinivasa Vellanki Nov 22, 2020 06:03
    Hi Manisha,

    Am not very sure I follow the question..

    If the question is if there is a SOM managing the CFS Service Order, what would it need to do to send a RFS Service Order to another SOM?
    Typically SOM has ability to decompose a CFS Service Order to RFS Service Orders and delegate the RFS Service Order to other SOM using TMF-641.

    Please note the options listed were about two years ago and my thinking/opinion has evolved since then based on new learnings.

    TMF-640 - Used to transition a Service (CFS or RFS) from one state to anther.
    TMF-641 - Used to fulfill a CFS Service using other RFS Service by delegating a RFS Service Order as supported by other SOM.

    Note CFS & RFS are to be modelled properly, they don't represent systems or organizations in Service Provider setup. CFS & RFS are based on actual Telco Services.

    ------------------------------
    Srinivasa Vellanki
    Amdocs Management Limited
    ------------------------------



  • 17.  RE: TMF-641 vs TMF-640

    TM Forum Member
    Posted Apr 12, 2021 13:25

    Hi
    We recently debated this on back of actual implementation for complex Enterprise segment of Tier 1 Telco. Our conclusion is that RFS Order Mgmt is of limited use and definitely should be avoided when there is already CFS Order Mgmt

    RFS Order Mgmt could potentially be used for Bulk Operations of RFS for eg Migration, and that too when RFSes have no CFS for eg Backhaul Circuits for Plan & Build, when hese circuits are being upgraded etc

    Even that can be avoided by extending TMF640 slightly to allow multiple RFSes in payload, and Plan & Build Workflow Manager consumes this. Please see our thoughts on the subject compiled below

    It would help if the TMF 641 / TMF 640 write-ups updated for such clarification and give clear guidance by addressing the ambiguities



    ------------------------------
    Nikhil Shah
    Prodapt North America, Inc
    ------------------------------



  • 18.  RE: TMF-641 vs TMF-640

    TM Forum Member
    Posted Jun 21, 2021 07:23

    Interested by the above post here @Srinivasa Vellanki. Would i be correct in suggesting that your belief is that a service should be able to have its state transitioned (TMF640) without a service order (TMF641). My view on this was that a service would only transition state via an order however long or short running that might be?

    My thinking was quite closely aligned with @Koen Peeters , Is my below understanding incorrect?






    ------------------------------
    David Whitfield
    TalkTalk Group
    ------------------------------



  • 19.  RE: TMF-641 vs TMF-640

    TM Forum Member
    Posted Apr 12, 2021 14:15
    Managing CFS Service Order and RFS Service Order separately and having different Order Managers for CFS & RFS are two different things and we can have both being done in the same architecture depending on the Service Provider needs.

    Based on the above analysis think we are not aligned on what we mean by CFS vs RFS.

    ------------------------------
    Srinivasa Vellanki
    Amdocs Management Limited
    ------------------------------



  • 20.  RE: TMF-641 vs TMF-640

    TM Forum Member
    Posted Jun 21, 2021 10:02
    Hi David
    Consider the use case where service features are directly exposed to the end user of the service (I believe some call this "self-provisioning"). Subject of course to permissions and business rules (e.g. no changes allowed that have a commercial or pricing impact), you might well allow changes in service profile. I'm no expert here, but when I looked into IP Centrex some years ago, I remember that there were a large number of features that could be set and changed directly by end users.
    In this case, a service order might be considered as redundant, the user-facing UI would directly invoke POST on Service in TMF640 to achieve the change.
    Does it make sense?

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



  • 21.  RE: TMF-641 vs TMF-640

    TM Forum Member
    Posted Jun 21, 2021 15:25
    Hi David,

    It will be no surprise that I concur with your model.

    ------------------------------
    Koen Peeters
    Ciminko Luxembourg
    ------------------------------



  • 22.  RE: TMF-641 vs TMF-640

    TM Forum Member
    Posted Jun 22, 2021 21:05
    @David Whitfield
    Agree that TMF-640 should not result in Service State change. It was my mistake to think that TMF-640 might also enable some level of Service State change. Thank you for the picture this is very helpful.

    Regards
    Srinivas

    ------------------------------
    Srinivasa Vellanki
    Amdocs Management Limited
    ------------------------------



  • 23.  RE: TMF-641 vs TMF-640

    TM Forum Member
    Posted Jul 25, 2021 19:50
    Hi David,

    I work with Abdul at Telstra where we have implemented a NaaS architecture with independent domains that hide their resources. The business layer speaks either TMF640/TMF641 to create/manage services, and the services are TMF640. Resources are not directly exposed but are hidden within domains, where they may be shared within the domain.
    TMF641 merely provides a way of manipulating one or more related TMF640 services.

    If you manipulate a TMF640 service, you also change its TMF638 inventory. If you manipulate TMF638 inventory separately, then better be the thing that has aligned the network. So TMF638 is something that  may be within domain, depending on whether the domain is TMF native or a skin over something else. Likewise whether a domain uses TMF652/TMF639 is up to it.

    As Abdul has said, most domains exposing simple/sync services have done TMF640 only. TMF640 gets ugly (for consumers) when dealing with complexity of long running orders, in-flight amends, in-flight cancels, etc which are common with access services where we are closing an air gap. TMF641 does this easily and also handles bundles of related services if required.

    We also have a concept of a 'shallow' E2E domain which doesn't have its own resources, but merely orchestrates compositions of services across other domains. Composite services exposed on this domain would typically be ordered by TMF641, as the compositions would generally be a mix of TMF640 services managed in other domains by a mix of TMF640 and TMF641. Helper services which are agents (such as a factory service for creating/relating other services), or an optimiser service for handling cross domain auto-configuration, etc again could be managed with either TMF641 or TMF640.

    TMF640 for service ordering got us going on NaaS quickly, but in my view TMF641 is where we are ending up. The first 3 services I helped define were TMF640, the next 4 I did myself are TMF641!

    Best Regards,

    Matt


    ------------------------------
    Matt Beanland
    Telstra Corporation
    ------------------------------



  • 24.  RE: TMF-641 vs TMF-640

    TM Forum Member
    Posted Jul 28, 2021 04:28
    @David Whitfield The upcoming version of IG1228 features a service and resource order management use case (for postpaid mobile) that has some differences with your chart. The network is addressed by resource order management through internal invocation of TMF702. It really depends on whether the network can be abstracted at service level (e.g. NaaS) or not (like in the .

    Secondly, I am not sure to understand why TMF640 would be required for resource order management (like indicated on the chart). How would ROM use this interface as it should not manage any services?​

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



  • 25.  RE: TMF-641 vs TMF-640

    TM Forum Member
    Posted Jun 22, 2021 21:41

    Hi,


    IG1224 captures considerations that a Service Designer has to undertake while selecting Service Fulfillment API (TMF640 v/s TMF61) for the service. IG1224 is an evolving document, please feel free to join us in the "ODA NaaS Service Fulfilment User Guide (ODA1)" call for discussion around this topic or if you want to contribute towards its evolution.

    Jist from IG1224 below

    • Type 1: Physical infrastructure deployment required for the provisioning of service. This involves a complex orchestration process with a long lead time.  This provisioning may require manual tasks, integration with a third party via order management process, including email, calls, etc. TMF641 is better suited to support this type of provisioning.
    • Type 2: Existing Infrastructure will be used for provisioning the service. There are two variations identified in Type 2.
      • Type 2a:  Rapid activation: The provisioning is performed by zero-touch orchestration. This may also include seamless integration with third-party providers. Provisioning these services can be performed with a shorter lead time (both synchronous & asynchronous).  TMF640 is found best suited to support this type of provisioning.
      • Type 2b: Complex activation: The provisioning may include complex orchestration with a long lead time. This type may include composite services which span across multiple domains with different types of provisioning patterns and complex activation dependencies.  This provisioning may also require manual tasks and integration with a third party via order management process, including email, calls, etc.  TMF641 is found best suited to support this type of provisioning.



    ------------------------------
    Abdul Majid Hussain
    Telstra Corporation
    ------------------------------



  • 26.  RE: TMF-641 vs TMF-640

    TM Forum Member
    Posted Jun 23, 2021 04:07
    Hi,

    thanks to Abdul for the valuable hint to IG1224. That means, depending on the complexity of service activation, both APIs, TMF640 and TMF641, can be used for this purpose.

    And hence, both ways might result in corresponding service state changes. (!) For instance, in TMF640, a POST will set the service state to "active" whereas an appropriate PATCH could set it to "inactive" etc. In fact, TMF640_Service_Activation_Management_API_User_Guide_v4.0.0.pdf contains exactly such examples in the chapter "Operations on Service".




    ------------------------------
    Thomas Dupré
    Deutsche Telekom AG
    ------------------------------



  • 27.  RE: TMF-641 vs TMF-640

    TM Forum Member
    Posted Jun 25, 2021 12:22
    Hey @Abdul Majid Hussain, I would be interested in joining a conversation around this topic. How would I join the  "ODA NaaS Service Fulfilment User Guide (ODA1)" call?


    ------------------------------
    David Whitfield
    TalkTalk Group
    ------------------------------



  • 28.  RE: TMF-641 vs TMF-640

    TM Forum Member
    Posted Jun 27, 2021 10:51
    Thank you will try to join the meetings if not will try to review and share my feedback offline.

    ------------------------------
    Srinivasa Vellanki
    Amdocs Management Limited
    ------------------------------



  • 29.  RE: TMF-641 vs TMF-640

    TM Forum Member
    Posted Jun 28, 2021 10:15
    Edited by Srinivasa Vellanki Jun 28, 2021 10:16
    Hi,

    Like the suggestion made by @David Whitfield​​​ "My view on this was that a service would only transition state via an order however long or short running that might be?".

    Points to think..

    Why should the consumer be impacted when the implementation of the Service changes? If the purpose of RFS or NaaS is to abstract CFS & Product from Network complexity expect the Integration to not change when the network evolves from using a PNF to start with and then the network evolves to use a VNF.

    Are we missing a Product Configuration API?

    Regards
    Srinivas

    ------------------------------
    Srinivasa Vellanki
    Amdocs Management Limited
    ------------------------------



  • 30.  RE: TMF-641 vs TMF-640

    TM Forum Member
    Posted Jun 25, 2021 13:06
    Hi David, I hope you  can join us to discuss NaaS on Tuesdays 8am EST / 10PM Australia using this ODA Calendar entry:

    ODA NaaS Service Fulfilment User Guide (ODA1)

    Tue 6/29/2021 8:00 AM - 9:00 AM View series

    https://us02web.zoom.us/j/89097568744?pwd=eWgreE5UVE9haGlVS0lCbXpwREcvUT09

    ODA NaaS Service Fulfilment User Guide (ODA1)

     

    Meeting rescheduled to accommodate US and Australian participants.

     

    Join Zoom Meeting

    https://us02web.zoom.us/j/89097568744?pwd=eWgreE5UVE9haGlVS0lCbXpwREcvUT09

     

    Meeting ID: 890 9756 8744

    Passcode: 056043

     

    OR

     

    Dial by your location

    Find your local number: https://us02web.zoom.us/u/kdKP4r774b



    ------------------------------
    Johanne Mayer
    MayerConsult Inc
    ------------------------------



  • 31.  RE: TMF-641 vs TMF-640

    TM Forum Member
    Posted Jun 27, 2021 02:25
    As an administrative note, @David Whitfield, you should probably join the ODA project if you are not already a member.


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



  • 32.  RE: TMF-641 vs TMF-640

    TM Forum Member
    Posted Aug 10, 2021 14:38
    Hi Roland,

    Is there a way to access the working version of IG1228 that plans to feature Service and Resource Order Management for Post paid mobile?




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

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



  • 33.  RE: TMF-641 vs TMF-640

    TM Forum Member
    Posted Aug 11, 2021 11:21
    Hi Kinshuk,

    It is being published these days. Please, check whether you have access to it in this URL.

    Best regards,

    ------------------------------
    Abel Ruiz Huerta
    SATEC GROUP
    ------------------------------



  • 34.  RE: TMF-641 vs TMF-640