Open APIs

Hi all,

I would appreciate your feedback on a design choice we are currently evaluating regarding network data collection exposed at the CFS layer.

Context

In our OSS landscape, we have an application called XSO that exposes several APIs (e.g. TMF640, TMF641, TMF653, TMF645).
At the CFS level, XSO provides a TMF640 Service Activation & Configuration interface, which:

• Decomposes CFSs into RFSs (catalog- and rule-based)
• Delegates activation to multiple NSALs (Network Service Activation Layers)
• Each NSAL manages one or more RFSs and underlying Resources

Objective

We want to introduce a "collect" operation on the XSO TMF640 (CFS level), allowing applications to retrieve live/stored network information.

Key characteristics:

• The collect operation is cascaded to NSALs via their own TMF640 collect operations
• Supports both synchronous and asynchronous modes (events via TMF688)
• Uses TMF662 Entity Catalog to define the hierarchy of collectable entities (CFS → RFS)
• EntitySpecifications are linked to ServiceSpecifications (TMF633) via entitySpecRelationship

Request Structure (simplified example)

The collect operation accepts a list of entities describing what data to retrieve:

[    {        "name": "cpe.liveInfo",        "characteristic": [            {                "name": "identifier",				"valueType" : "object",                "value": {                    "type": "uniqueId",                    "value": "uniqueId of a device"                }            }        ],        "entitySpecification": {				"id": "id of entity spec collect.cpe.liveInfo"		}    }]

This is posted to TMF640: POST /service/{id}/collect

Notes:

• The request targets a specific CFS instance
• Optional identifiers allow filtering (e.g. specific device vs all)
• Based on the specification, the system determines which RFS/NSALs to invoke

Design Question: What should the response look like?

We are currently considering three options:

Option 1 – Return a CFS enriched with collected data (relatedEntity by value)

• Aggregate network data from NSALs and attach it to the CFS as relatedEntity (by value)

Pros

• Single call returns both:
  • Service inventory (CFS + RFS)
  • Collected network data

Cons

• TMF640 (v4/v5) Swaggers do not support relatedEntity by value
• Data models suggest support, but Swagger definitions appear inconsistent
• TMF702 (Resource Inventory) does not include relatedEntity
• Would require extending both TMF640 and TMF702 APIs

Option 2 – Return a list of collected entities

• Response mirrors the request: list of entities (tree structure using entityRelationship) returned

Pros

• No API extension required
• Clean and symmetric (entities in / entities out)

Cons

• No service inventory context (CFS/RFS) included in the response (could be through entities though...)

Option 3 – Return a CFS with relatedEntity by reference

• Store collected data in Entity Inventory (TMF703)
• Return references (relatedEntity by ref) in the CFS

Pros

• No change required on TMF640
• Aligns with persistence strategy (TMF703)

Cons

• Requires additional calls to retrieve actual data
• Increased complexity for consumers
• Still requires some extension on TMF702
• Not our preferred option

Question to the community

Which option would you recommend, and why?

In particular:

• Have you faced similar challenges when exposing "collect" or telemetry-like operations?
• How do you balance API purity (TMF compliance) vs usability (single-call vs multi-call patterns)?
• Any best practices around using TMF662 / TMF703 in this context?

Best regards,

Hi Frederic,

I notice that there is no mention of a TMF638 service inventory? Normally you would expect that the services would also be persisted (possibly off the TMF640 processes) in TMF638 - which would provide you with both a read interface, and notifications of changes.

Have you considered that approach?

Hi all,

I would appreciate your feedback on a design choice we are currently evaluating regarding network data collection exposed at the CFS layer.

Context

In our OSS landscape, we have an application called XSO that exposes several APIs (e.g. TMF640, TMF641, TMF653, TMF645).
At the CFS level, XSO provides a TMF640 Service Activation & Configuration interface, which:

• Decomposes CFSs into RFSs (catalog- and rule-based)
• Delegates activation to multiple NSALs (Network Service Activation Layers)
• Each NSAL manages one or more RFSs and underlying Resources

Objective

We want to introduce a "collect" operation on the XSO TMF640 (CFS level), allowing applications to retrieve live/stored network information.

Key characteristics:

• The collect operation is cascaded to NSALs via their own TMF640 collect operations
• Supports both synchronous and asynchronous modes (events via TMF688)
• Uses TMF662 Entity Catalog to define the hierarchy of collectable entities (CFS → RFS)
• EntitySpecifications are linked to ServiceSpecifications (TMF633) via entitySpecRelationship

Request Structure (simplified example)

The collect operation accepts a list of entities describing what data to retrieve:

[    {        "name": "cpe.liveInfo",        "characteristic": [            {                "name": "identifier",				"valueType" : "object",                "value": {                    "type": "uniqueId",                    "value": "uniqueId of a device"                }            }        ],        "entitySpecification": {				"id": "id of entity spec collect.cpe.liveInfo"		}    }]

This is posted to TMF640: POST /service/{id}/collect

Notes:

• The request targets a specific CFS instance
• Optional identifiers allow filtering (e.g. specific device vs all)
• Based on the specification, the system determines which RFS/NSALs to invoke

Design Question: What should the response look like?

We are currently considering three options:

Option 1 – Return a CFS enriched with collected data (relatedEntity by value)

• Aggregate network data from NSALs and attach it to the CFS as relatedEntity (by value)

Pros

• Single call returns both:
  • Service inventory (CFS + RFS)
  • Collected network data

Cons

• TMF640 (v4/v5) Swaggers do not support relatedEntity by value
• Data models suggest support, but Swagger definitions appear inconsistent
• TMF702 (Resource Inventory) does not include relatedEntity
• Would require extending both TMF640 and TMF702 APIs

Option 2 – Return a list of collected entities

• Response mirrors the request: list of entities (tree structure using entityRelationship) returned

Pros

• No API extension required
• Clean and symmetric (entities in / entities out)

Cons

• No service inventory context (CFS/RFS) included in the response (could be through entities though...)

Option 3 – Return a CFS with relatedEntity by reference

• Store collected data in Entity Inventory (TMF703)
• Return references (relatedEntity by ref) in the CFS

Pros

• No change required on TMF640
• Aligns with persistence strategy (TMF703)

Cons

• Requires additional calls to retrieve actual data
• Increased complexity for consumers
• Still requires some extension on TMF702
• Not our preferred option

Question to the community

Which option would you recommend, and why?

In particular:

• Have you faced similar challenges when exposing "collect" or telemetry-like operations?
• How do you balance API purity (TMF compliance) vs usability (single-call vs multi-call patterns)?
• Any best practices around using TMF662 / TMF703 in this context?

Best regards,

Hi Peter,

I have not described our full service portfolio but we are indeed using various TMF repository/inventory APIs like TMF638 and TMF639. When I mentioned that Option 1 would return the inventory part, it was from our ServiceInventory ;)

Anyway TMF640 and TMF638 suffer from the same issue regarding relatedEntity property.

Best regards,

Hi Frederic,

I notice that there is no mention of a TMF638 service inventory? Normally you would expect that the services would also be persisted (possibly off the TMF640 processes) in TMF638 - which would provide you with both a read interface, and notifications of changes.

Have you considered that approach?

Hi all,

I would appreciate your feedback on a design choice we are currently evaluating regarding network data collection exposed at the CFS layer.

Context

In our OSS landscape, we have an application called XSO that exposes several APIs (e.g. TMF640, TMF641, TMF653, TMF645).
At the CFS level, XSO provides a TMF640 Service Activation & Configuration interface, which:

• Decomposes CFSs into RFSs (catalog- and rule-based)
• Delegates activation to multiple NSALs (Network Service Activation Layers)
• Each NSAL manages one or more RFSs and underlying Resources

Objective

We want to introduce a "collect" operation on the XSO TMF640 (CFS level), allowing applications to retrieve live/stored network information.

Key characteristics:

• The collect operation is cascaded to NSALs via their own TMF640 collect operations
• Supports both synchronous and asynchronous modes (events via TMF688)
• Uses TMF662 Entity Catalog to define the hierarchy of collectable entities (CFS → RFS)
• EntitySpecifications are linked to ServiceSpecifications (TMF633) via entitySpecRelationship

Request Structure (simplified example)

The collect operation accepts a list of entities describing what data to retrieve:

[    {        "name": "cpe.liveInfo",        "characteristic": [            {                "name": "identifier",				"valueType" : "object",                "value": {                    "type": "uniqueId",                    "value": "uniqueId of a device"                }            }        ],        "entitySpecification": {				"id": "id of entity spec collect.cpe.liveInfo"		}    }]

This is posted to TMF640: POST /service/{id}/collect

Notes:

• The request targets a specific CFS instance
• Optional identifiers allow filtering (e.g. specific device vs all)
• Based on the specification, the system determines which RFS/NSALs to invoke

Design Question: What should the response look like?

We are currently considering three options:

Option 1 – Return a CFS enriched with collected data (relatedEntity by value)

• Aggregate network data from NSALs and attach it to the CFS as relatedEntity (by value)

Pros

• Single call returns both:
  • Service inventory (CFS + RFS)
  • Collected network data

Cons

• TMF640 (v4/v5) Swaggers do not support relatedEntity by value
• Data models suggest support, but Swagger definitions appear inconsistent
• TMF702 (Resource Inventory) does not include relatedEntity
• Would require extending both TMF640 and TMF702 APIs

Option 2 – Return a list of collected entities

• Response mirrors the request: list of entities (tree structure using entityRelationship) returned

Pros

• No API extension required
• Clean and symmetric (entities in / entities out)

Cons

• No service inventory context (CFS/RFS) included in the response (could be through entities though...)

Option 3 – Return a CFS with relatedEntity by reference

• Store collected data in Entity Inventory (TMF703)
• Return references (relatedEntity by ref) in the CFS

Pros

• No change required on TMF640
• Aligns with persistence strategy (TMF703)

Cons

• Requires additional calls to retrieve actual data
• Increased complexity for consumers
• Still requires some extension on TMF702
• Not our preferred option

Question to the community

Which option would you recommend, and why?

In particular:

• Have you faced similar challenges when exposing "collect" or telemetry-like operations?
• How do you balance API purity (TMF compliance) vs usability (single-call vs multi-call patterns)?
• Any best practices around using TMF662 / TMF703 in this context?

Best regards,