Open APIs

 View Only
  • 1.  TMF API for Design and Assign

    TM Forum Member
    Posted 21 days ago

    A common process that is employed - both in Plan and Build, and in Order to Activation, is that of Assign and Design where individual resources are allocated to a design based on manual processes, automated processes applying business rules etc.

    As this 'design' is usually carried out in a Resource Inventory function, but can be called from both Service Fulfilment and Network Rollout processes, there arises a need for a separate API that enables the configuration of the requested design, results in a completed design with reserved (or even allocated) resources in the Resource Inventory.

    TMF652 is about ordering a specific resource, and is far too granular - and in any event - you STILL need a process to orchestrate all the resources that need to assigned, along with the associated designs around configuration or routing.

    How do we go about proposing a new API that enables the request, progress reporting and result retrieval of this function? 



    ------------------------------
    Pieter Eksteen
    CIENA Blue Planet
    ------------------------------


  • 2.  RE: TMF API for Design and Assign

    TM Forum Member
    Posted 21 days ago

    Hi Pieter,

    your statement "this 'design' is usually carried out in a Resource Inventory" is from the past implementations (I have similiar experience) but as far as I understand TMF standards and guidelines "this design" should be implemented in Service Order Management ODA Component. I believe reason for this is that SOM is loosely coupled with Resource Inventory in this case, which is a good thing. But here are far more experienced guys and I'm currious what they will say about your idea.



    ------------------------------
    Ján Krištof
    T-Mobile Czech & Slovak Telekom, a.s.
    ------------------------------



  • 3.  RE: TMF API for Design and Assign

    TM Forum Member
    Posted 20 days ago

    Thanks Jan,

    The challenge with putting it only in the Service Order Management space is that is also applies to plan and build - which I recognise is not something that has enjoyed a lot of attention in TMF.

    To a large extent it depends on whether you also use Resource Inventory for planned (future) state design, or only for service design recording.



    ------------------------------
    Pieter Eksteen
    CIENA Blue Planet
    ------------------------------



  • 4.  RE: TMF API for Design and Assign

    TM Forum Member
    Posted 16 days ago

    Agree. We should use Resource inventory also for plan and build procesess that's for sure. So I have this usecase in my mind: We need to split legacy inventory into two parts: data storage - represented by Resource inventory component (which is just service) and GUI - which allows user to perform complex task, such as network planning. And this should be separate component - used in plan & build process, different from Resource Inventory. This is how I see it, I might be wrong.



    ------------------------------
    Ján Krištof
    T-Mobile Czech & Slovak Telekom, a.s.
    ------------------------------



  • 5.  RE: TMF API for Design and Assign

    TM Forum Member
    Posted 20 days ago

    @Pieter Eksteen, I think the 'design' you refer to is a function of Resource Configuration and Activation (TMFC062).

    The TMFC062 Component specification is still a work in progress.  In the current view it's Core Function produces:

    • Resource Activation Management API (TMF702
    • Resource Function Activation Management API (TMF664)
    • Configuration Profile Management API (TMF783)

    The Resource Activation APIs (702, 664) are the ones you are looking for.  The other (783) is a recently proposed API which introduces Configuration as a managed entity, something which may be created, updated, deleted as well as applied to, or derived from, existing entity instances.

    As one of the primary authors of TMFC062 and TMF783 I would be quite interested in receiving feedback on our direction.



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



  • 6.  RE: TMF API for Design and Assign

    TM Forum Member
    Posted 20 days ago

    Thanks Vance,

    I considered both TMF702 and TMF664 before posting my question.

    The challenges are 2 fold:

    1. A design consists of multiple resources, not a single one - think the selection of all the resources (or resource types) from cell-site antenna to backhaul connection point.
    2. Both 664 and 702 deal with an 'already-known' resource type etc., and design is about deciding which resources to use.

    I have not looked at 783 - where can I find some details?



    ------------------------------
    Pieter Eksteen
    CIENA Blue Planet
    ------------------------------



  • 7.  RE: TMF API for Design and Assign

    TM Forum Member
    Posted 20 days ago

    @Pieter Eksteen,

    Please consider the examples illustrated in the TMF664 API User's Guide:

    Figure 2 Flow creation on existing topology
    The above diagram is a composite Resource Function representing a Flow Graph composed of Resource Functions A-Z.

    The examples in TMF664 are sourced from TR255:

    The TR255 series contains requirements, uses cases and protocol neutral models for an activation and configuration API concerning resource functions. Resource functions are a generalization and abstraction of various industry concepts including the ETSI NFV concepts of VNF, PNF VNF Forwarding Graph and Network Service, and the SDN concepts of Service Function and Service Function Chain. TR255 supports intent-based and detailed-based requests (as well as mixtures of intent-based and detailed-based).

    Resource Functions not only support the Composite/Atomic pattern but include additional properties for connectionPoint (input/output), connectivity (topology) and activationFeature (declarative configuration).



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



  • 8.  RE: TMF API for Design and Assign

    TM Forum Member
    Posted 20 days ago

    Hi Pieter,

    My 2 Cents..

    Design is done(what resources will be used based on availability of resources in context of where the service is to be delivered) for the Service and Resources are assigned to a Service and these assignments are recorded in Service & Resource Inventory.



    ------------------------------
    Srinivasa Vellanki
    Jio Platforms Limited
    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.
    ------------------------------



  • 9.  RE: TMF API for Design and Assign

    TM Forum Member
    Posted 19 days ago
    Dear Pieter,
    As the author of the initial TMFS017 FTTB Planning and Deployment Use Case, I'm currently updating the document to address the issue you raised. The challenge in the plan-and-build process lies in enabling specialized design tools to seamlessly communicate with inventory systems. After extensive consideration, I propose solutions to key issues, requiring updates to existing APIs and the introduction of new ones.
    1. Resource Catalog Alignment: Design tools and inventory systems must share a common Resource Catalog to describe complex resource compositions (e.g., Linecard XYZ fits specific slots and supports n XGS-PON ports). I propose reinstating the duality of ResourceSpecification (e.g., "XGS-PON linecard") and ResourceCandidate (e.g., "XYZ linecard for an ABC slot in a Ciena chassis") to distinguish the "what" (design phase) from the "which" (selection phase). This will require extensions to TMF634 Resource Catalog Management API.
    2. Physical Design: Physical design requires a Work Breakdown Structure (WBS) defining activities such as "place chassis at a site," "insert linecard into a slot," or "connect a port." While SID models Projects, WBS, and activities, no Open API currently supports this. I propose a new Open API for WBS to manage activities interacting with resources via produce (create resources in inventory), reserve (assign resources), and consume (remove resources) actions. Work orders (TMF697) can be derived from the WBS for technician-executed activities.
    3. Logical Design: Logical design, as outlined in Vance's contribution, involves configuring ResourceFunctions. For example, a PhysicalPort (e.g., SC/PC single-mode) on a linecard may include a ConnectionPoint (e.g., EthernetPort) with ActivationFeatures for speed settings. Connectivity links multiple ConnectionPoints, potentially across layers (e.g., SC/PC PhysicalPort → wavelength ConnectionPoint → Ethernet ConnectionPoint → IP ConnectionPoint). A WBS for logical design can include activities invoking TMF664 Resource Function Activation and Configuration API.
    4. Resource Pool Management (TMF685): ResourcePool Management is critical for assignment processes, often tied to a GeographicSite. When a linecard is added, its PhysicalPorts and ConnectionPoints are registered in the ResourcePool as available. Assigning a resource (e.g., plugging a connector into a PhysicalPort) removes it from the pool. For planning, a WBS can reserve resources in the pool.
    I hope this summary addresses your concerns and aligns with your vision. Please share your feedback.


    ------------------------------
    Koen Peeters
    OryxGateway FZ LLC
    ------------------------------