Open APIs

Expand all | Collapse all

Resource Pool Management & Resource Inventory API

  • 1.  Resource Pool Management & Resource Inventory API

    TM Forum Member
    Posted Feb 18, 2019 02:45

    At TMForum Action Week I promised to have a look at the Resource Pool API.

    I would like to post my initial view on the topic here to get some feedback whether my thoughts go in the right direction. 

    I also put them to the resource inventory API page as well since it is closely related and I think at least part of it also relates to discussions in this thread:

    • First aspect: Resource Model
      • To figure out the relationship between Inventory and Pools/Reservation, I looked it up in SID GB922_Logical_and_Compound Resource. 
      • There reservation and related processes are handled as specific types of ManagementInfo (Everything goes on ManagedEntity Level, so also for Services)
        • Reservations are handled as ConfigurationInfo, but it is not spelled out there
        • State is a separate piece of ManagementInfo
      • The Resource resource ((Lächeln)) in ResourceInventory does not have ConfigurationInfo and only very weak "StateInfo" (either inconsistently described or I do not get the link between resource model and state machine.
      • The Activation & Configuration API has some more state types which look better, but are unspecified and not yet schematized and inconsistent with the resource inventory
      • My conclusion: It would be best to rework all these APIs (along with ResourcePoolAPI) to use a consistent resource model for resources spelling out ManagementInfo including state, configuration (and reservation, even if SID calls it a specific configuration) separately.
    • Second aspect: API structure
      • I think that by reworking ResourceInventory API as described above, all information pertaining to resources and pools, configuration and activation could be captured in a single API.
      • Nevertheless, I think this would not be sufficient since doing direct manipulations of the ResourceInventory does not seem to be appropriate as part of e.g. order capture
      • In a way this would be similar to replacing ProductOrdering with direct manipulation of the ProductInventory.
      • This is not correct since these APIs expose different functions (from different TAM domains) and do not only manipulate data entities.
      • So I think that a "Configuration and Activation" API as well as a "Reservation" API will be required in addition (I would keep them separate, for reasons as discussed above) whose implementations might then invoke the inventory API.
      • I call it "Reservation API" since I think resource pools are only specific ManagementMethods for Reservations, so the name of the API should reflect the main entity to be handled.


    Does this sound understandable and reasonable? If so, I would consider whether and how we could support an adaptation and schemification of these APIs in this direction, collaborating with their owner.


    P.S. The second aspect for me hints at a general question regarding APIs that is unclear: How do we describe which APIs are intended for which use cases (why cannot some frontend simply go ahead and modify the product inventory)? This topic came up in Frameworx and is very valid: A mapping between APIs and TAM Domains would be desirable, and actually I suspect an extension of these mappings to the ODA would lead to another level of (fruitful) discussion: Which APIs expose functionality of TAM blocks, which APIs expose the interface of ODA domain areas? To standardize this would really mean to define an architecture which standardizes functional placement

    Andreas Schlueter

  • 2.  RE: Resource Pool Management & Resource Inventory API

    TM Forum Member
    Posted Feb 19, 2019 05:37
    Andreas interesting and informative post.

    In the ODA program we just published:
    This was predicated on analysis of 5-6  5G and NaaS catalysts results. As part of this we developed an ODA Production Implementation Framework  to place the functionality in the Catalysts projects. What we realised as we completed the work that this has much more general application than 5G  and addresses your suggested comment   '...… To standardize this would really mean to define an architecture which standardizes functional placement'

    IG1167 ODA Functional Architecture R18.5.0   |  includes  mapping the functional groups to Frameworx including TAM.  However TAM has some historical limitations which we are planning to overcome in future releases of IG1167. This document also has some tables with placement of OPEN APIs  within the ODA Functional Groupings.

    For Release 19 we have agreed at AW Lisbon last week  to change the title and scope of GB999 to be a complete ODA Production  Implementation Framework covering multiple resource technologies - including 5G -   and incorporate some additional  functional elements including virtualisation and Lifecycle management functions . These later functionality updates will leverage prior work in

    Plus new work on addressing the SID models to be used for each functional block  within the ODA Production  Implementation framework

    The SID models turn out to be crucial to getting this right as each Open API points to specific parts of the SID model and stitching them together shows that there are some gaps and enhancements that need to be addressed together with practical best practices  constraints to make implementation tractable.
    These Models were discussed last week but time precluded us form discussing the full set of nine contributions at
    2019-02-14 Thu Q1: ODA/FX - NaaS Connectivity Service Models (UML & NaaS API Data Models)

    Meeting are held Tuesdays  currently at 11:00 and 13:00 GMT and recommence next week.
    PS NTT Japan is involved in some of these discussions
    Would be more than happy to set up a call to discuss if you are interested

    Dave Milham
    TM Forum Chief Architect, TM Forum

  • 3.  RE: Resource Pool Management & Resource Inventory API

    TM Forum Member
    Posted Feb 21, 2019 16:20
    Hi Andreas,

    I agree that a review of the Open API structure around resources is required.

    I strongly believe that  in line with TMF645 Service Qualification and TMF679 ProductOffering Qualification a Resource Qualification  needs to be defined.
    This API should support the scenario's for Selection and Reservation in the pre-order phase.
    Unfortunately the Reservation API in TMF685 is not modelled according the BusinessInteraction template and should therefore be redesigned.

    In the Resource Inventory several subclasses of ManagementInfo should be defined.
    In my own modelling I have already created a subclass called AssignmentInfo. This object defines the managementInfo related to the relationship between Resource and Product.
    The lifecycle for this object supports 'reserved' for temporary pre-order reservations and 'assigned' for used in an existing product.
    Note that also commonly used quarantine operations can be supported.

    Similarly I defined a subclass ServiceAccessPointInfo. This object defines the managementInfo related to the relationship between Resource and RFS.
    (ServiceAccessPoint) is vaguely defined in G922 ServiceOverview.
    The lifecycle for this object is a reduced version of the above that only contains 'allocated' and 'free' state.

    The lifecycle of the Resource in the inventory itself also needs to be defined in further detail. The diagram below is a first attempt at this.

    I am very interested in contributing in discussions for an improvement of the Resource Management Domain.