The Purpose of this Article (what’s in the article and what’s not)
- What this covers: Concept for modeling L3VPN in TNI. The three-layer NSI pattern (global service > VRF > Network Service Endpoint). How NSIs sit on top of infrastructure CIs. implementer’s tips.
- What this does not cover: Point-and-click configuration steps.
- Audience: TNI implementers, network architects, service and assurance teams.
What is MPLS Layer 3 VPN (L3VPN) Service
An MPLS Layer 3 VPN provides private routed IP connectivity between multiple customer sites over a provider’s MPLS core. Customer Edge (CE) routers connect to Provider Edge (PE) routers, each customer’s routes are isolated in a VRF on the PE. MP-BGP is used between PEs to carry VPNv4/IPv6 routes (with labels) across the provider network, while PE–CE routing can be BGP, OSPF, static, etc. P (core) routers only switch labels and do not carry VPN routing context. This design delivers scalable, isolated multi-site connectivity.
What TNI is (and why model connectivity services in it)
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 L3VPN service 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. - Network Service Instance (or shortly ‘NSI’) - cmdb_ci_network_service_instance.
Used for: the service layer - your IPVPN service itself and the per-PE VRF instances and endpoint-level service constructs.
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:
MPLS Layer 3 VPN (L3VPN) Diagram and Mapping of CIs to Classes
This diagram shows how an MPLS Layer-3 VPN (IPVPN_MGMT_SERVICE) is modeled in ServiceNow TNI using a three-layer Network Service Instance pattern (service > VRFs > service endpoints) layered over infrastructure and connectivity CIs (network interfaces, VLAN/EVC, LSP/tunnel, and physical links) and how each element maps to the correct CI classes and tables.
For the L3VPN service (and the same applies to VPLS / L2VPN services), the design uses a three-level representation of service components, all modeled with the Network Service Instance (NSI) class (cmdb_ci_network_service_instance).
Note: The design difference for a VPLS service (in terms of how we apply Network Service Instance class CIs) is that we use a Network Service Instance CI to represent the Node/VSI instead of a VRF, while preserving the same three-layer hierarchy.
At the very top sits the customer-facing IPVPN_MGMT_Service NSI, which represents the L3VPN network service. Beneath it, each provider edge (PE) has a VRF NSI for this L3VPN i.e. an NSI representing the specific VRF instance on that router used by this L3VPN service. (A single PE may host many other VRFs for other VPNs, those are separate and not implied here). At the edges of those VRF layers are Network Service Endpoint NSIs that anchor the VRF to concrete logical connections (VLAN Paths in this case). All three layers are NSIs - each one is a CI created in the Network Service Instance table.
These NSIs are intentionally placed on top of instantiated infrastructure and connectivity CIs. The inventory below is modeled with standard TNI classes.
Reading the diagram from the access edges inward: each side presents a VLAN/EVC (a logical connection) on a sub-interface (e.g., Ge3/1.100, Ge6/1.100). Sub-interfaces are modeled as Network Interface CIs on the PE. The device also includes interface cards in specific slots, all part of the PE chassis. The OLO trunk between the edge and the provider footprint is modeled as a Physical Connection, because it represents an actual span between physical network interfaces. Across the core, an LSP/Tunnel is modeled as a Logical Connection between the two PEs, while the fiber link beneath it is a Physical Connection representing the real optical span.
Tip:
- Use Design & Assign (Changes > All > New > [select the design and assign task] > Next > Save > navigate to Change Tasks and click the task number > complete the form > submit) to instantiate the infrastructure (devices, cards, physical and logical connections).
- In the Zurich release, the NSIs and their corresponding relationships must be created manually, one by one. In order to automate the process please explore our Playbook Experience.
|
Object in the diagram |
CI Class |
Table |
Used for |
|
IPVPN_MGMT_SERVICE (top service) |
Network Service Instance |
cmdb_ci_network_service_instance |
Represents the customer L3VPN service. It is the parent NSI of all the VRF NSIs that belong to this L3VPN service. |
|
VRFs (on PE-LON-1 and PE-LON-2) |
Network Service Instance |
cmdb_ci_network_service_instance |
This L3VPN’s VRF instances, as child NSIs to the parent IPVPN_MGMT_SERVICE NSI and also a parent to its correspondent Network Service Endpoint NSIs. VRFs are also configured as parents to their corresponding telco equipment, which hosts them. |
|
Network Service Endpoints (on PE-LON-1 and PE-LON-2) |
Network Service Instance |
cmdb_ci_network_service_instance |
Child of its corresponding VRF NSI, it represents the service edges/endpoints. It anchors a VRF instance to the network connectivity (VLAN path logical connection) and acts as the parent of the VLAN path. |
|
Network Site (PE-LON-1/2) |
Network Site |
cmdb_ci_ni_site |
Anchors equipment and connections to locations for A/Z derivation. |
|
Telco Equipment (PEs) |
Telco Equipment |
cmdb_ci_ni_telco_equipment |
Chassis/NE container that holds slots/cards and hosts interfaces. |
|
IP Router (CEs) |
IP Router |
cmdb_ci_ip_router |
Router CI (IP routing device) participates in the service as an access edge device. |
|
Slots |
Slot (Equipment Holder) |
cmdb_ci_container_slot |
Physical holder in the chassis where interface cards are inserted. |
|
1G Card / 10G Card |
Interface Card |
cmdb_ci_interface_card |
Line/port cards that hosts the physical ports. |
|
Ge6/1, Ge3/1, 10G7/1 (physical ports) |
Network Interface |
cmdb_ci_ni_interface |
Physical ports used as endpoints (Port A/Z) of connections. |
|
Ge6/1.100, Ge3/1.100, 7/1.lsp (sub-interfaces) |
Network Interface |
cmdb_ci_ni_interface |
Logical sub interfaces applicable) used to carry VLAN/EVC and MPLS handoffs. |
|
VLAN/EVC 100 |
Logical Connection |
cmdb_ci_ni_logical_path |
Logical connectivity between interfaces. Created between Port A/Port Z (‘Add Logical Connection’ in Design & Assign automatically creates logical ports on top of the selected physical A/Z ports). |
|
OLO Trunks and Fiber Link |
Physical Connection |
cmdb_ci_ni_physical_link |
Physical connectivity span (fiber/cable) created between existing physical ports. (Use Add Physical Connection in Design & Assign). |
|
LSP/Tunnel |
Logical Connection |
cmdb_ci_ni_logical_path |
MPLS tunnel between PEs (‘Add Logical Connection’ in Design & Assign automatically creates logical ports on top of the selected physical A/Z ports). |
More information on the TNI Data Model: https://www.servicenow.com/docs/bundle/zurich-telecom-network-inventory/page/product/tmt-telecom-net...
The IPVPN_MGMT_SERVICE view in the Dependency Map shows the yellow-highlighted CIs, which correspond to the service diagram above.
The IPVPN_MGMT_SERVICE view in the Network Visualization > Topology shows the yellow-highlighted Devices and connectivity, which correspond to the service diagram above.
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. To support the relevant attribute sets on Network Service Instance class CIs, both globally and per role or type, representing the three-layer hierarchy of global L3VPN service, VRF, and Network Connection Endpoints, this article provides guidance on deciding whether to include additional fields on the out of the box Network Service Instance table (cmdb_ci_network_service_instance) or use TNI Attribute Packs in TNI for extension:
Implementers’ Notes, Tips and Useful Links
Direct form (quick path) to create a Network Service Instance CI
If you can’t find the form in navigation, open it directly (replace your instance name): https://YOUR_INSTANCE_NAME.service-now.com/cmdb_ci_network_service_instance.do
TNI Attributes Pack (do not forget to create it in the relevant application scope (Attribute Pack): https://www.servicenow.com/docs/bundle/zurich-telecom-network-inventory/page/product/tmt-telecom-net...
TNI Design & Assign
CI relationships between Network Service Instance CIs and other CIs must be created manually (in Zurich) via CI Class Manager > Network Service Instance > click on the specific CI > Related List > ‘+’
- ‘IPVPN_MGMT_Service’ Depends on :: Used by ‘VRF on PE-LON-1’
- ‘IPVPN_MGMT_Service’ Depends on :: Used by ‘VRF on PE-LON-2’
- ‘VRF on PE-LON-1’ Depends on :: Used by Service Endpoint toward SenH-1
- ‘VRF on PE-LON-1’ Depends on :: Used by PE-LON-1/ASR 9006/1
- ‘VRF on PE-LON-2’ Depends on :: Used by Service Endpoint toward SenH-2
- ‘VRF on PE-LON-2’ Depends on :: Used by PE-LON-1/ASR 9006/2
- ‘Endpoint toward SenH-1 Depends on :: Used by VLAN/EVC 100 (LC-1)
- ‘Endpoint toward SenH-2 Depends on :: Used by VLAN/EVC 100 (LC-2)
#TelecomNetworkInventory #TNI #MPLS #L3VPN #VPLS #TransportNetwork #Design
