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



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

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

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



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



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



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

    TM Forum Member
    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
    ------------------------------



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



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



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



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



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



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



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