TM Forum Community

 View Only

  • 1.  TMF Specification and difference

    Posted Jan 16, 2023 08:32
    Hi Team,

    Can someone let me know the difference between  TMF 638,TMF 639,TMF 640 and there use cases.

    and if there have any document of these TMF multiple use cases please provide.






    Regards,
    Shivam
    #General

    ------------------------------
    Shivam Chauhan
    Zensar
    ------------------------------


  • 2.  RE: TMF Specification and difference

    TM Forum Member
    Posted Jan 16, 2023 08:47
    Hi Shivam

    TMF638 is a Service Inventory management API. You can imagine that there will be a database or some other form of persistence representing services that have been provisioned to customers. TMF638 exposes CRUD operations on this persistence.
    Compare and contrast with TMF640, which is a Service Activation API. This API's operations communicate directly with the network (for example via custom software adaptors), to effect changes in the network configuration.
    We can expect that as part of service order provisioning (TMF641), relevant operations will be invoked from TMF640 and then TMF638, to effect the network provisioning and then ensure that the inventory is up-to-date.

    TMF639 is an inventory of resources, which could be network elements, logical resources, customer-premise equipment, and more. 

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

    Original Message


  • 3.  RE: TMF Specification and difference

    TM Forum Member
    Posted 13 days ago

    Hi Jonathan,

    Sorry about the late reply. I have some architectural concerns.

    The list and retrieve endpoints and the resource model for TMF640 appear identical to those of TMF638.

    This means that a TMF640 implementation cannot exist without something that for all intents and purposes is identical to an inventory of the activated services.

    (That would not necessarily be realized using database technology - theoretically the activation system could instead query the activated infrastructure directly, but in practice that would be too inefficient.)

    So let me call whatever persistence that supports TMF640 an "activation-inventory". Without it, the retrieve and list calls would be unimplementable.

    Now, it would appear that TMF638 is a subset of TMF640, where the difference is that TMF638 is not actively activating, but just storing information.

    There are obvious use-cases where an external, inactive TMF638 inventory needs to be kept synchronized with one or more activation-inventories.

    The above reply, however, seems to suggest that it would be the task of TMF641 to keep an external TMF638 inventory in sync with one or more activation-inventories of TMF640.

    I am concerned, that pushing the responsibility for maintaining consistency between an activation-inventory and an external TMF638 inventory would be unnecessarily error-prone.

    Having TMF640 synchronize directly, eastbound with an external TMF638 inventory appears to be safer, architecturally.

    Best regards,

    Peter



    ------------------------------
    Peter Bruun
    Hewlett Packard Enterprise
    ------------------------------

    Original Message


  • 4.  RE: TMF Specification and difference

    TM Forum Member
    Posted 12 days ago

    Hi Peter

    Thanks for your contribution to the discussion.

    See this related thread, where I relate to the possible differences in information content between the service inventory and the network.

    https://engage.tmforum.org/discussion/tmf640-vs-tmf638-getlist-api

    Regarding your last suggestion, you could indeed provide a wrapper implementation of TMF640 which would first approach the network and then update the inventory. Not sure that this is much different from having the TMF641 implementation do this orchestration.



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

    Original Message