Open APIs

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

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

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

Original Message:
Sent: Apr 24, 2025 02:44
From: Ján Krištof
Subject: TMF API for Design and Assign

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

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

Original Message:
Sent: Apr 24, 2025 06:39
From: Pieter Eksteen
Subject: TMF API for Design and Assign

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


Original Message:
Sent: Apr 24, 2025 02:44
From: Ján Krištof
Subject: TMF API for Design and Assign

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.

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

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

Original Message:
Sent: Apr 24, 2025 03:15
From: Vance Shipley
Subject: TMF API for Design and Assign

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

@Pieter Eksteen,

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

The examples in TMF664 are sourced from TR255:

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

Original Message:
Sent: Apr 24, 2025 06:44
From: Pieter Eksteen
Subject: TMF API for Design and Assign

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


Original Message:
Sent: Apr 24, 2025 03:15
From: Vance Shipley
Subject: TMF API for Design and Assign

@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

Hi Vance,

Yes, I looked at this in detail - but the 'decisions' about 'which' resources (or indeed whether new resources are required) are not best decided at activation/build time.

For one - the costs of a service are directly related not only to what the service-ready-network can provide, but also what it cannot provide. Determining that before activation is crucial in many scenarios, and I do not believe any of the existing API's address this sufficiently.

------------------------------
Peter Eksteen
Senior Advisor, Product Line Management
CIENA Blue Planet
------------------------------

Original Message:
Sent: Apr 24, 2025 08:47
From: Vance Shipley
Subject: TMF API for Design and Assign

@Pieter Eksteen,

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

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


Original Message:
Sent: Apr 24, 2025 06:44
From: Pieter Eksteen
Subject: TMF API for Design and Assign

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


Original Message:
Sent: Apr 24, 2025 03:15
From: Vance Shipley
Subject: TMF API for Design and Assign

@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

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

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

Thanks Koen,

We are broadly aligned.

I am in the process of drafting a new TMF-aligned API (that we can perhaps submit for inclusion in the standards) that deals with Design & Assign requests. This will be an 'order' based request - but similar to the Service Qualification API in that it will produce a 'result' of the design (and potentially reserve resources in the Resource Inventory) that can then be queried, or referenced in later build or fulfilment processes.

In our portfolio today these requests are dealt with as internal orders, with a proprietary API, and integration is complex. We are intending to simplify the integration and of course use TMF Open API mechanism to reduce the time and cost to do this in future.

------------------------------
Peter Eksteen
Ciena Corporation
------------------------------

Original Message:
Sent: Apr 25, 2025 05:18
From: Koen Peeters
Subject: TMF API for Design and Assign

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