- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
7 hours ago - edited 6 hours ago
The Purpose of this Article (what’s in the article and what’s not)
- What this covers: Concept for modeling All-Photonic Network (APN) and Optical Transport Network (OTN) in TNI. How APN/OTN connectivity maps onto optical equipment.
- What this does not cover: Point-and-click configuration steps.
- Audience: TNI implementers, network architects, service and assurance teams.
What is IOWN’s All-Photonic Network (APN)
The Open All-Photonic Network (APN) is a network that connects endpoints directly with optical paths. It provides high-speed, ultra-reliable, and low-latency connections. In today’s network, optical paths are disjointed and operated segment-by-segment, i.e., local area network (LAN), access network, and inter-data-center network. By contrast, the Open APN will enable one optical path to span multiple segments. This will allow end-to-end communication with deterministic performance. This approach will require more dynamic and granular control.
APN user-plane functions:
APN-T - Open APN Transceiver
Role: the endpoint of a wavelength path. It transmits/receives optical signals on a designated wavelength. APN-T can sit at a user device or act as the WAN interface of a gateway (e.g., DCI/FDN).
APN-G - Open APN Gateway
Role: the wavelength-path gateway that interfaces APN-Ts to the trunk. It provides 1) control channels to talk to APN-Ts, 2) admission control (only allows assigned wavelengths), and for wavelength services 3) multiplex/demultiplex, 4) turn-back (low-latency local pathing), and (5) add/drop between APN-T and APN-I.
APN-I Open APN Interchange
Role: the mid-path wavelength switching element. It must support 1) wavelength cross-connect (any-port to any-port without Optical/Electric/Optical), 2) amplification, and 3) adaptation so APN-G↔APN-I and APN-I↔APN-I combinations interoperate.
APN Release 1.0 services at a glance (and the focus of this article):
- PtP Wavelength Path Service - Available in Release 1 (and Release 2).
APN Release 2.0 services at a glance:
- PtMP Wavelength Path Service - Listed for Release 2, with the note how to realize PtMP wavelength paths within Open APN.WX needs further studies.
- PtP Fiber Path Service - Available in Release 2.
- PtMP Fiber Path Service - Available in Release 2.
Open ROADM
Open ROADM is a Multi-Source Agreement that opens and disaggregates traditionally proprietary ROADM systems into standard, SDN-controllable functions with YANG/NETCONF models, so multivendor optical gear can be managed and provisioned consistently by a controller.
In the minimum Open APN, the Open APN user-plane functions APN-G, APN-I, and APN-T are realized on conventional ROADM systems compliant with the Open ROADM MSA, enabling APN wavelength services to run on ROADM technology.
What TNI is (and why model connectivity services in it)
Telecommunications Network Inventory (TNI) is the place to model optical plant and services end to end from fiber and splice/panel paths up through photonic functions (e.g., ROADM, amplifier, transponder) and logical optical layers. For APN + OTN this means you can represent APN.WX wavelength paths over APN.FX fiber paths, as well as OTN trails (e.g., ODU/OTU), using telecom-aligned classes and relationships that live in one inventory.
TNI creates a trusted single source of truth that replaces fragmented legacy inventories, improves data quality, and reduces OPEX. It accelerates time to market through a low- or no-code design and onboarding approach, leveraging an out-of-the-box telecom- and data-center-aligned data model with a template-driven Design & Assign and playbook experience for rapid instantiation of new equipment, logical resources, and workflows. The solution is open and standards-based, supporting the TM Forum Open API TMF639 (Resource Inventory Management), officially certified by the TM Forum, ensuring seamless interoperability with external systems.
TNI Telecom-aligned Data Model (Out-of-the-box)
TNI ships a telecom-focused CMDB model (classes and tables) for equipment, interfaces, connections, and services. The CMDB CI Class Models enumerates the standard classes and their exact table names used throughout this article.
CMDB CI Class Model is a store application and is a single source for all new base-system CMDB CI class models from ServiceNow store.
CI Classes Used to Create the APN and OTN Layers and the Underlying Infrastructure
Visible on the diagram below:
- Network Site - cmdb_ci_ni_site (extends cmdb_ci_site).
Used for: anchoring equipment, interfaces, and connections to locations (A/Z site fields on connection forms derive from this). - Telco equipment - cmdb_ci_ni_telco_equipment.
Used for: network element/chassis that hosts slots, cards, and network interfaces. - Slot (equipment holder) - cmdb_ci_container_slot.
Used for: the physical holder into which cards are installed. - Interface Card - cmdb_ci_interface_card.
Used for: interface/line cards that provide physical ports on the chassis. - Network Interface - cmdb_ci_ni_interface.
Used for: both physical ports and logical/virtual interfaces (sub-interfaces). Also the A/Z endpoints referenced by Logical/Physical Connections. - Physical Connection - cmdb_ci_ni_physical_link.
Used for: actual fiber/cable (or other physical media) connecting two interfaces/equipment. Includes Cable Parameters (type, length, strand count, etc.). - Logical Connection - cmdb_ci_ni_logical_path.
Used for: logical connectivity (e.g., VLAN/EVC paths, MPLS LSP/tunnels) with Port A/Port Z endpoints and optional Endpoint role.
Not visible on the diagram below, but also part of the model (optional):
- Network Topology - cmdb_ci_network_topology
Used for: graphically displaying how the different elements in a network such as equipment, connections, and interfaces are organized and connected to one another.
More information about the TNI data model and CI classes is available on our documentation site:
APN and OTN Network Diagram and Mapping of CIs to Classes
This diagram shows how IOWN’s All-Photonic Network (APN) and OTN layers - APN-T/G/I functions, their network interfaces, and the fiber/wavelength/OTN connections, map to ServiceNow TNI CI classes and relationships end-to-end.
At the edges, each site hosts an APN-T. The client signal at APN-T is represented by a DSP connection that terminates on the DSP (client tail side) logical network interfaces at the two APN-Ts (Sites A/Z). That client trail is carried by an OTN stack modeled as Logical Connections in cmdb_ci_ni_logical_path: LO-ODU riding on HO-ODU, which rides on an OTU trail. Above the photonic layer, the wavelength is modeled as an OTSi/OCh connection (channel). Each upper layer consumes the layer below it. The DSP trail consumes LO-ODU. LO-ODU consumes HO-ODU. HO-ODU consumes OTU. OTU consumes the OTSi/OCh wavelength.
The diagram makes the APN-T split explicit. The DSP logical network interfaces sit on the client tail side physical port. The LO-ODU, HO-ODU, OTU, and OTSi logical interfaces sit on the network tail side physical port. Each logical connection listed above terminates on its corresponding logical network interface on the correct side of the APN-Ts.
Across the middle of the diagram, the path traverses APN-G and APN-I nodes. In each node you model the physical optical interfaces on the interface cards and, on top of them, the logical interfaces they host, such as OTS and OMS. Between nodes, the line-side physical ports are joined with Physical Connections to represent the fiber. On top of those fibers, you create OTS logical connections between the OTS logical network interfaces at each end (OTS interfaces will be created automatically upon the design & assign of ‘Add Logical Connection (OTS model)’ and selecting the physical A/Z ports). Each OTS (LC) consumes the fiber span. You also model OMS logical connections between the node’s OMS logical interfaces (OMS interfaces will be created automatically upon the Design & Assign of ‘Add Logical Connection (OMS model)’ and selecting the OTS logical A/Z network interfaces).
With this layering in place, every upper-layer logical connection in the stack (OTSi/OCh, OTU, HO-ODU, LO-ODU, DSP) terminates on their correct logical interface, which is contained by the correct physical interface, and every inter-node segment is bound to a specific fiber. Read left to right: APN-T (Site A) > APN-G > APN-I > APN-G > APN-T (Site Z). At each hop the fiber is modeled as a Physical Connection. The wavelength (OTSi/OCh) is the photonic Logical Connection between the APN-Ts. The OTU and ODU trails and, where used, the DSP client trail are higher-layer logical connections. Each connection has A/Z endpoints (PtP) on specific network interfaces, and the layers are represented with Consumes::Consumed by relationships, preserving the full dependency chain from the client trail down to the underlying fiber infrastructure.
Object in the diagram |
CI Class |
Table |
Used for |
APN-Ts |
Telco Equipment |
cmdb_ci_ni_telco_equipment |
Transponder/termination node at the edge of the APN. It is the A/Z endpoint of the wavelength path, hosting the physical ports on both the client-tail and network-tail sides, plus the logical interface stack: DSP/client (client side) and, on the network side, OTSi/OCh, OTU, HO-ODU, and LO-ODU. |
APN-Gs |
Telco Equipment |
cmdb_ci_ni_telco_equipment |
Photonic gateway node that hosts the line-side optical interfaces (DEGREE) and add/drop toward APN-T (SRG). Provides control-channel termination, admission control, multiplex and demultiplex, turn-back, and add/drop for wavelength paths. |
APN-I |
Telco Equipment |
cmdb_ci_ni_telco_equipment |
Photonic interchange node for mid-path wavelength switching. Hosts line-side optical interfaces (DEGREE) used for wavelength cross-connect, amplification, and adaptation between APN-G ↔ APN-I and APN-I ↔ APN-I. |
Network Sites (Site A / Site Z) |
Network Site |
cmdb_ci_ni_site |
Anchors equipment and connections to locations for A/Z derivation and topology. |
Slots |
Slot (Equipment Holder) |
cmdb_ci_container_slot |
Equipment holder where interface cards are inserted. |
Cards |
Interface Card |
cmdb_ci_interface_card |
Represents the interface cards that are stored in a network. |
Physical Optical Interfaces |
Network Interface |
cmdb_ci_ni_interface |
Physical optical port on the card or chassis. Termination point for Physical Connections. |
OTS logical interfaces |
Network Interface |
cmdb_ci_ni_interface |
Logical interface used for OTS logical connection termination. Created automatically by Add Logical Connection (Design & Assign) upon selecting the physical ports as A/Z. |
OMS logical interfaces |
Network Interface |
cmdb_ci_ni_interface |
Logical interface used for OMS logical connection termination. Created automatically by Add Logical Connection (Design & Assign) upon selecting the OTS logical interfaces as A/Z. |
OTSi/OCh logical interfaces (at APN-T) |
Network Interface |
cmdb_ci_ni_interface |
Wavelength endpoint on the transponder network tail side. Created automatically by Add Logical Connection (Design & Assign) upon selecting the corresponding interfaces as A/Z. |
OTU logical interfaces (at APN-T) |
Network Interface |
cmdb_ci_ni_interface |
Endpoint for the OTU trail on the transponder network tail side. Created automatically by Add Logical Connection (Design & Assign) upon selecting the OTSi/OCh logical interfaces as A/Z. |
HO-ODU TTP logical interfaces (at APN-T) |
Network Interface |
cmdb_ci_ni_interface |
Termination of a high-order ODU trail as an ODU-TTP. Created automatically by Add Logical Connection (Design & Assign) upon selecting the OTU logical interfaces as A/Z. |
LO-ODU CTP Logical interfaces (at APN-T) |
Network Interface |
cmdb_ci_ni_interface |
Endpoint for low-order ODU connections used in cross-connects. ODU-CTP. Created automatically by Add Logical Connection (Design & Assign) upon selecting the HO-ODU TTP logical interfaces as A/Z. |
DSP logical interfaces (at APN-T) |
Network Interface |
cmdb_ci_ni_interface |
Client-side termination on the transponder. Created automatically by Add Logical Connection (Design & Assign) upon selecting the physical client tail side ports as A/Z. |
Fiber Connections (FC) |
Physical Connection |
cmdb_ci_ni_physical_link |
Physical fiber span between specific optical interfaces (physical A/Z ports). |
OTS Connections (LC) |
Logical Connection |
cmdb_ci_ni_logical_path |
Optical Transmission Section logical segment between OTS logical interfaces. Consumes the Fiber Physical Connection. |
OTSi / OCh Connection (LC) |
Logical Connection |
cmdb_ci_ni_logical_path |
Wavelength-level logical path between OTSi/OCh logical interfaces across the APN-G/APN-I chain. Consumes OMS Logical Connections. |
OTU Connection (LC) |
Logical Connection |
cmdb_ci_ni_logical_path |
OTU trail carried by the wavelength. Terminates on OUT logical interfaces. Consumes OTSi/OCh Logical Connection. |
HO-ODU Connection (LC) |
Logical Connection |
cmdb_ci_ni_logical_path |
High-order ODU trail that rides the OTU trail. Terminates on HO-ODU logical interfaces. Consumes OTU Logical Connection. |
LO-ODU Connection (LC) |
Logical Connection |
cmdb_ci_ni_logical_path |
Low-order ODU trail that rides the HO-ODU trail. Terminates on LO-ODU logical interfaces. Consumes HO-ODU Logical Connection. |
DSP Connection (LC) |
Logical Connection |
cmdb_ci_ni_logical_path |
Client/DSP trail between APN-T client ports. Top layer of the stack. Consumes LO-ODU Logical Connection. |
More information on the TNI Data Model - https://www.servicenow.com/docs/bundle/zurich-telecom-network-inventory/page/product/tmt-telecom-net...
When to use TNI Attribute Packs vs Custom fields on OOB tables
It’s no secret that various resource types require additional attributes to be managed across different technologies and use cases. The ServiceNow AI Platform, CMDB, and TNI application are extremely flexible and allow for custom configuration and customization, including the capability to manage additional attributes that are not present in the OOB solution.
For more information on Attribute Packs vs Custom fields please refer to this article:
Implementers’ Notes, Tips and Useful Links
- Use Design & Assign (change) to instantiate equipment (telecom equipment, interface cards, and physical network interfaces), then create Physical Connections for fibers and Logical Connections for OTS, OMS, OTSi/OCh, OTU, HO-ODU, LO-ODU, and (if modeled) DSP.
- TNI ships with demo data that already includes OOB various physical and logical connections and interface models, for example, Optical Transmission Section (OTS logical connection) and Optical Multiplexer Section (OMS logical connection), Optical Channel (OCh logical connection), and the corresponding network interface models such as OTS, OMS, and OCh logical interfaces. Other types of logical connection and logical interface models can be easily created, as well as the inventory templates, for rapid instantiation.
- When you use Design & Assign (change) Add Physical Connection, the A/Z physical interfaces must already exist, so you will be able to select them in the Add Physical Connection form.
- When you use Design & Assign (change) Add Logical Connection, the A/Z physical interfaces must already exist and be selected in the Add Logical Connection form, and the corresponding logical network interfaces will be created automatically according to the logical connection model, alongside the logical connection.
- The relationship DSP logical interface (parent) Depends on :: Used by LO-ODU interface (child) is optional and added manually. TNI doesn’t create it or require it, but it might help TSOM with CMDB-based alert grouping and impact analysis. If you want robust CMDB-based grouping and clear impact to the client edge with fewer assumptions about deeper optical relationships, keep the direct DSP > LO-ODU Depends on. This is platform-aligned and reduces reliance on long multi-hop traversals.
- Grouping: CMDB-based alert grouping can correlate an LO-ODU alert with the DSP (and anything above it) using a short path, improving correlation quality and performance.
- Impact analysis: An alert or outage on LO-ODU propagates up to the DSP (parent depends on child), so the client-side CI is impacted immediately without traversing the whole optical stack.
- It’s recommended to keep the physical and logical network interface names unique, as this allows for simpler alert binding to physical and logical interfaces (if you use or intend to use TSOM Event Management).
- After creating each logical connection, add the Consumes relationship (connection element) to the layer beneath it so impact traces correctly from client signal down to the span.
Useful links:
- Create Inventory Models
- Creating inventory template for network asset instantiation
- TNI Design and Assign
#TelecomNetworkInventory #TNI #AllPhotonicNetwork #APN #ROADM #WDM #OTN #OpticalNetwork #Design #IOWN
- 89 Views
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Great article!