Open APIs

 View Only
  • 1.  TMF702 vs TMF664

    TM Forum Member
    Posted Jul 13, 2022 00:35
    Is there any material providing guidance on when to use TMF702 vs TMF664.

    Didn't do proper analysis but at a high level TMF664 appears to be over-lapping with TMF702 & TMF640.

    ------------------------------
    Srinivasa Vellanki
    Reliance Jio Infocomm Ltd
    Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of my employer or TM Forum.
    ------------------------------


  • 2.  RE: TMF702 vs TMF664

    TM Forum Member
    Posted Jul 13, 2022 02:44
    TMF702 is for "traditional" network resources, while TMF664 is for network functions (NFVs).
    I'm sure that @Vance Shipley can give a more detailed exposition.​

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



  • 3.  RE: TMF702 vs TMF664

    TM Forum Member
    Posted Jul 13, 2022 03:43
    Thank you @Jonathan Goldberg

    Difference btw Traditional Network Resources and Virtual Network Functions should be limited to how they are installed/Instantiated and possibly life-cycle management.

    There should not be any difference in how and what they are provisioned/configured to support a Service.

    Will look forward to more inputs from @Vance Shipley

    ------------------------------
    Srinivasa Vellanki
    Reliance Jio Infocomm Ltd
    Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of my employer or TM Forum.
    ------------------------------



  • 4.  RE: TMF702 vs TMF664

    TM Forum Member
    Posted Jul 13, 2022 05:12
    The APIs tend to fall into one of a set of common patterns including Catalog, Inventory and Activation.  If your intent is to cause the instantiation of a Physical or Logical Resource entity than TMF702 would be appropriate. If your intent is to cause the instantiation of a Resource Function entity that it's TMF664 which also includes Task Resources for Day 2 operations such as Scale, Heal and Migrate which are specific to Resource Function. Afterwards you may want to record the instantiated details in a Resource Inventory with TMF639. 

    If you're looking for overlap, here's a little game for you, try and find a difference between TMF702 and TMF639.  :)


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



  • 5.  RE: TMF702 vs TMF664

    TM Forum Member
    Posted Jul 13, 2022 09:31
    Thank you @Vance Shipley, this clarifies. TMF664 is equivalent to TMF652 (and not TMF702) which is responsible for getting the physical device ready for supporting Services.​

    TMF702 is for provisioning/configuring the Device with Service details in order to support the Service.

    Think the term Activation (and how I perceived Activation might only mean) in the title misled me to check with TMF702.

    Regards
    Srinivas

    ------------------------------
    Srinivasa Vellanki
    Reliance Jio Infocomm Ltd
    Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of my employer or TM Forum.
    ------------------------------



  • 6.  RE: TMF702 vs TMF664

    TM Forum Member
    Posted Jan 16, 2024 09:41

    Hey @Vance Shipley

    I was just pondering a similar question to that posted originally and I got from your post that actually 702 and 639 almost are equivalent (inventory management) and perhaps are overlapping with no need to have both?

    Actually the idea that a different API specification is used (702 vs 664) based on the network function being physical or virtual is not the case because 664 references PNF's as being supported?

    We were actually looking at a use case where we have a requirement to rebuild a port on a network device, would you see this as a use case for the /heal task based resource within this API or am I reading this wrong?

    Much appreciate any guidance with this

    cheers

    Dave



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



  • 7.  RE: TMF702 vs TMF664

    TM Forum Member
    Posted Jan 16, 2024 11:11
    Edited by Vance Shipley Jan 16, 2024 13:31

    Yes @David Whitfield, it is true that TMF702 is identical to TMF639 with just a different resource path prefix.  TMF664 differs in the task operations it supports and that it makes available the schemas for ResourceFunction, ConnectionPointRef, ResourceGraph, etc. through it's OAS ("swagger").

    You note that TMF664 refers to PNF, however it is only as part of the ETSI NFV concepts which inspired it's functional requirements.  You should NOT manage PhysicalResource entities with TMF664.  It would however be a common scenario for ResourceFunctions activated with TMF664 to be included in the /resource Collection of a TMF639 implementation, along with other LogicalResources and PhysicalResources, so they do all certainly mix.

    As to your requirement to rebuild a port on a network device, I assume that you aren't changing the hardware, like swapping the SFP module, so really you would be operating on a LogicalResource, probably a ResourceFunction.  I suggest you review TR255 from which TMF664 arose.  In TR255A you'll find a description of how to represent ETSI VNF, Network Service, etc., as a composite ResourceFunction. There you'll find diagrams like the example below:

    diagram of vCDN
    Each of the rectangles is a ResourceFunction (RF). The grey box is an RF for a network function (NF), the green is an RF for a port (ConnectionPoint) and the orange is an RF for a transport link. A detailed example of this, with payloads, is provided in the TMF664 User Guide.
    So yes, you have the right idea, represent the Network Function (NF) of your physical network device as an RF.  The inputs and outputs of this RF, listed in the connectionPoint attribute, may be references to RFs representing the logical function of the ports. Include these references in the resourceRelationship attribute also with a relationshipType indicating a composition relationship (i.e. "composedOf"). If you wish also manage PhysicalResources for the hardware aspects of the devices and include them in the related resources.
    For a complete picture of managing the host platform (device), software and functions of an NF see TMF730, which completes the concepts introduced by TR255.



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



  • 8.  RE: TMF702 vs TMF664

    TM Forum Member
    Posted Jan 16, 2024 12:40

    Thanks @Vance Shipley for the in depth response, I will have a better read of the TR255 document.

    To give a bit of context even though the capability is to reset a port this is in the fixed access broadband domain where this capability is provided by the last mile fibre provider to reset their port on their network device. We do not have any references to this network device therefore this is not something held in our resource inventory. They manage this by providing us an API (not TMF) to perform the rebuild by providing their service reference which is held in our inventory as an external reference against our service.

    I was trying to look for an appropriate TMF API to use to allow exposure of this capability which is provided by them from our internal OSS as a treatment of a service which is not working. Given this clarification and the lack of internally mastered resources do you think there is a different answer here in terms of TMF API?

    cheers

    Dave



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