🔧

Section 11.3

IP / MPLS / Transport Domain

IP/MPLS, transport, and optical as a single orchestration domain. Covers PE/P/RR topology, transponders/ROADM, the service abstractions exposed (L3VPN, L2VPN/EVPN, IP transit, optical λ, SR transport, transport slicing), the standardised IETF YANG service models (L3SM/L3NM/L2NM/L1CSM), the controller layer (Cisco NSO, Nokia NSP, Juniper Paragon, Blue Planet, ONAP SDN-C), live topology awareness via BGP-LS and PCEP/SR-PCE, and the legacy SDH/SONET integration gap. Anti-patterns: per-VRF Jinja-templated NSO, hard-coded SR paths in the catalog, vendor-flavoured service models leaking into XDO.

IP/MPLS and transport is the most heavily orchestrated domain in any telco — every other domain (mobile core, fixed access, enterprise services) eventually traverses it. It is also the domain where standard service models, multi-vendor controllers, and operator-driven YANG have advanced furthest. That maturity does not eliminate the integration challenges; it changes their shape.

This section covers the IP/MPLS, transport, and optical layer as a single orchestration domain — anchored by Cisco NSO, Nokia NSP, Juniper Paragon, and Blue Planet, exposing standard YANG-modelled services, and absorbing the legacy SDH/SONET footprint via vendor EMS. The goal is to make the orchestration interface explicit: what the domain controller exposes upward, what it hides downward, and where the abstraction breaks.

The IP/MPLS, Transport, and Optical Domain

The domain spans three technology layers that share a single orchestration story but very different element types. Understanding what sits where dictates what the domain controller can model and what it must hide.

Element classes in the IP/MPLS/transport domain

Element class	Role	Typical integration	Examples
PE (Provider Edge) router	Customer-facing service termination — VRFs, BGP peering, QoS, SR endpoints	NETCONF/YANG, gNMI; CLI fallback for legacy or feature gaps	Cisco ASR9k / NCS, Nokia 7750 SR, Juniper MX, Arista 7280R
P (Provider) router	Core IP/MPLS forwarding — LSR, no per-customer service state	NETCONF/YANG; BGP-LS feed for topology	Same vendors as PE; often shared platforms
RR (Route Reflector)	BGP control-plane scale; no data-plane role	Mostly read-only via BGP-LS / NETCONF	Vendor RRs or virtualised software RRs
Transponders / ROADM	Optical layer — wavelength multiplexing, fibre routing, dispersion	NETCONF/YANG (modern, OpenROADM-aligned) or SOAP / proprietary EMS (legacy)	Ciena 6500, Nokia 1830 PSS, Infinera Groove, Cisco NCS optical
SR-PCE / Path Computation Element	Centralised SR / RSVP-TE path computation with stateful awareness	PCEP, NETCONF	Cisco SR-PCE, Juniper Paragon Pathfinder (formerly NorthStar), Nokia NSP path computation
Aggregation / metro routers	Subscriber aggregation, BNG handoff, metro Ethernet	NETCONF/YANG; RADIUS for subscribers (covered in 11.5)	Vendor PE platforms in aggregation roles

Why this is one orchestration domain, not three

IP/MPLS, transport, and optical are usually treated as one orchestration domain because their service models compose: an L3VPN service depends on transport class, which depends on optical wavelength availability. Splitting them across separate orchestrators creates artificial coupling between independent products and forces XDO above to reason about layer-1/2/3 interactions that the domain controller should hide.

What the Domain Exposes Upward: Service Abstractions

The orchestration value of this domain is the abstractions the controller exposes to the layer above. A service-level NBI hides the per-device, per-vendor, per-protocol mechanics. The same service abstraction lets the cross-domain orchestrator compose without knowing whether a Cisco or Juniper PE is at the other end.

Service abstractions in this domain

Abstraction	What it represents	Standard YANG model	Hides from XDO
L3VPN service	Customer VPN with MPLS underlay, route-targets, QoS	IETF L3SM (RFC 8299), L3NM (RFC 9182)	VRF config, BGP-VPN sessions, route-target policy, per-PE templates
L2VPN / EVPN service	Layer-2 stretch — E-Line, E-LAN, E-Tree	IETF L2NM (RFC 9291)	EVPN BGP config, MAC-VRF, MTU policies, broadcast-domain handling
IP transit / Internet service	Public-IP connectivity, peering policy	OpenConfig network-instance + BGP	BGP peer config, route-policy, RPKI enforcement, prefix lists
Optical λ / OTN service	Wavelength-routed connection between sites	IETF L1CSM, OpenROADM	Per-ROADM port maps, optical reach, dispersion compensation, amplifier gain
Segment-routed transport	Underlay class-of-service tunnel	IETF SR-TE policy, OpenConfig SR	SID stacks, PCE state, policy attributes
Network slicing (transport)	IETF/3GPP-aligned slice in transport	IETF slice-ng (maturing)	Slice realisation across SR, RSVP-TE, optical

Standard ≠ universally implemented

IETF L3SM, L3NM, and L2NM are standards. Vendor implementations of them vary widely. A controller "supporting L3NM" may implement 60% of the model with vendor-specific deviations for the rest. Treat YANG model coverage as an integration test, not a datasheet line item.

The Domain Controller Layer

The IP/MPLS/transport domain has the deepest controller market in OSS. Multi-vendor support is a hard requirement — no operator runs a single-vendor IP estate. Four controllers dominate, each taking a different stance on standards vs vendor-native YANG.

Major IP/MPLS/transport domain controllers

Controller	Strength	Multi-vendor stance	Typical integration upward
Cisco NSO	Mature transactional service models, deep YANG ecosystem, NEDs for ~150 vendor/version pairs	Strong multi-vendor via NEDs; NSO is genuinely vendor-neutral despite being a Cisco product	NETCONF/YANG NBI, RESTCONF; consumed by XDO via custom service models or standard L3NM/L2NM
Nokia NSP	Native to Nokia transport/IP estate; integrated path computation, telemetry, assurance	Multi-vendor support exists but Nokia-first	NETCONF/YANG NBI; tighter coupling when paired with Nokia Orchestration Center (see 11.1)
Juniper Paragon	Strong path computation (formerly NorthStar), automation, telemetry	Multi-vendor for path computation; device config primarily Juniper	REST / NETCONF NBI
Blue Planet (MDSO + Manage Control Plan)	Multi-domain orchestration plus IP/optical domain control; strongest cross-vendor optical (Ciena heritage)	Multi-vendor by design	TMF Open APIs, custom NBI; spans XDO and ROM layers depending on deployment
ONAP SDN-C / SDC	Open-source; used in greenfield 5G transport in some Tier-1s	Designed multi-vendor; production maturity uneven	Standard YANG, custom adapters

NSO's reach is the NED ecosystem

Cisco NSO's multi-vendor depth comes from the NED catalog (Network Element Drivers — vendor- and version-specific YANG packages), not from NSO core. This is a strength (production-tested adapters across most vendors and software versions) and a constraint (every vendor software upgrade may require a NED upgrade with its own QA cycle). Treating NEDs as zero-cost is a common transformation budgeting mistake.

Standardised YANG Service Models

IP/MPLS is the only OSS domain where standardised, operator-driven YANG models have reached production use. The IETF service-model series (L3SM / L3NM / L2NM / L1CSM) and OpenConfig provide a common surface that controllers can implement and orchestrators can consume, reducing the per-vendor adapter explosion that plagues every other domain.

IETF L3SM (RFC 8299) — service-level L3VPN model. Describes what a customer VPN service looks like — sites, attachment circuits, SLA. Coarse-grained, customer-facing.
IETF L3NM (RFC 9182) — network-level L3VPN model. Describes what the network has to do to deliver L3SM. Used as the controller NBI in modern deployments.
IETF L2NM (RFC 9291) — equivalent for L2VPN/EVPN services.
IETF L1CSM — wavelength/optical service model.
IETF slice-ng — emerging transport slice model, still maturing, aligned with 3GPP slicing where the transport segment is owned by the IP/optical domain.
OpenConfig — operator-driven device-level YANG (network-instances, BGP, OSPF, telemetry). Used widely for telemetry and config; less for service models.

Service model vs network model

L3SM describes the service the customer sees — sites, VPN attachment circuits, SLA. L3NM describes what the network does to deliver it — VRFs, route-distinguishers, BGP-VPN sessions. The orchestrator above consumes L3SM (or its own equivalent CFS); the controller consumes L3NM (or vendor-native). Conflating the two collapses the abstraction, and the catalog ends up holding both kinds of detail.

Topology Awareness: BGP-LS, PCEP, SR-PCE

Unlike most OSS domains, IP/MPLS controllers see the live network topology in real time, via BGP-LS. That topology feeds path computation engines that select Segment Routing paths and RSVP-TE LSPs based on current load and constraints. This is what distinguishes a domain controller from an EMS — the controller has live state.

BGP-LS — distributes IGP topology, traffic-engineering attributes, and segment routing labels into the controller via BGP. Read-only feed of network state.
PCEP — protocol between the PCE (path computation element) and PE/headend routers. Enables centralised path selection with stateful awareness of existing tunnels.
SR-PCE — segment routing path computation. Computes label stacks for traffic-engineered paths and pushes them to ingress PEs.

Topology is a runtime concern, not a catalog concern

The catalog should never contain live topology. A service model that says "use SR path X" is wrong; the right shape is "deliver this service with transport class gold across these endpoints" — the controller selects the path at fulfilment time using current topology and constraints. Catalog items that hard-code paths are not catalog items, they are deployment artefacts.

Transmission Media: Fibre, Satellite, Microwave

Operators rarely choose transmission media in the abstract — geography, regulation, time-to-market, and cost dictate the mix. Most Tier-1 estates run all three (fibre as the backbone, microwave as cellular backhaul, satellite for remote/maritime/disaster-recovery), and each medium has different orchestration semantics. The point of this comparison is not the network-engineering trade-offs (those are well covered elsewhere) but how the integration shape changes per medium.

Satellite, fibre, microwave — comparing the data-transmission options

Property	Satellite	Fibre	Microwave
Throughput	10 Mbps – 300 Mbps (up to ~1 Gbps modern LEO)	1 Gbps – 100+ Gbps (Tbps with DWDM)	100 Mbps – 10 Gbps (depends on frequency / bandwidth)
Capacity	Limited — shared bandwidth, spectrum constraints, frequency reuse / spot beams	Very high — massive bandwidth headroom	Medium — higher than some satellite, lower than fibre
Latency	GEO 500 – 700 ms; LEO 20 – 50 ms	Very low — ~5 – 10 ms per 1000 km	Low — comparable to fibre (few ms)
Reliability	Moderate — rain fade, atmospheric conditions	Very high — weather-independent, highly stable	Moderate — rain (especially at higher frequencies); requires line of sight
Coverage	Global — excellent for remote / hard-to-reach areas	Limited — depends on cable footprint	Limited — typically 30 – 50 km per hop, line of sight
Deployment speed	Moderate — quick relative to fibre	Slow — civil works and infrastructure	Fast — quicker than fibre
Cost shape	High — equipment and operational cost	High initial CapEx, low OpEx	Medium — moderate equipment and install

Best-fit use cases

Satellite — remote areas, maritime and aviation, disaster recovery, broadcasting. Fibre — international backbones, 5G/6G core networks, data centres. Microwave — cellular backhaul, enterprise connectivity, public safety, temporary links. Most Tier-1 networks combine all three; greenfield mobile cores in remote geography increasingly use satellite for backhaul resilience.

The future is hybrid

No single medium wins. The architecturally honest position is that fibre dominates capacity, microwave dominates rapid deployment, and satellite dominates reach — and a serious operator runs a hybrid mix across all three. Catalogs and orchestration must therefore model the medium as an attribute of the resource (and a constraint on the SLA), not as a different service.

Orchestration shape by medium

Medium	Typical controller / EMS	Integration protocol	Orchestration challenge
Fibre / DWDM (modern)	Vendor optical controllers (Blue Planet, Nokia NSP, Infinera Transcend), OpenROADM-aligned	NETCONF/YANG, OpenROADM models	Mature path; service abstractions stable; SDH/legacy is the residual gap
Microwave (modern)	Vendor controllers — Ericsson MINI-LINK, Nokia Wavence, Huawei OptiX	NETCONF/YANG (modern), proprietary EMS (legacy)	Per-hop link-budget realities (rain fade, line-of-sight) leak into capacity planning; assurance must understand weather
Satellite — operator-owned	Vendor NMS (e.g. iDirect, Hughes JUPITER, Newtec Dialog)	SOAP / proprietary REST; rarely NETCONF	Bandwidth-on-demand, beam handover, weather-aware policy — orchestrator coordinates with NMS via session-style integration
Satellite — third-party SNO (Starlink, OneWeb, SES)	Provider-owned; operator integrates via API	Vendor REST API; multi-step workflow with waiting states	Typically integrated via automation middleware (e.g. Itential) because SNO APIs are proprietary, frequently versioned, and need workflow glue

Modelling the medium in the catalog

The catalog should treat transmission medium as a resource property and an SLA constraint, not as a separate product family. A "100 Mbps Internet at remote site" service may be deliverable over fibre, microwave, or satellite — with different latency, availability, and cost profiles. Modelling these as three different products forces the customer to know about media choices they should not need to know about, and forces the orchestrator to refactor the catalog every time a new medium becomes economically viable (the way LEO satellite did from 2022 onward).

Legacy Transport: SDH, SONET, Pre-OpenROADM Optical

Every Tier-1 still has substantial SDH, SONET, and pre-NETCONF OTN. These elements were designed before model-driven management existed, and their EMS systems (Ciena CMS for legacy 6500, Nokia 1830 NMS, Huawei iManager U2000) were not built to expose modern abstractions. Integrating them into a multi-vendor IP/transport orchestrator is the single largest source of "we cannot fully orchestrate this domain" caveats in transformation programmes.

The abstraction gap

Legacy transport EMS often expose only element-level CRUD — create cross-connect, configure port — with no service abstraction. The controller layer above must invent its own service model, then translate it into element-level operations against a SOAP / CORBA / proprietary NBI. This is real adapter engineering — typically months per platform, requiring ongoing maintenance every time the EMS is upgraded.

The migration trap

"We will migrate off SDH next year" is a permanent state in many networks. Some SDH circuits carry regulated services (legacy enterprise leased lines, transmission contracts) with multi-decade renewals. Treating SDH as temporary planning leads to catalog models that cannot represent SDH services cleanly, which forces operational workarounds and eventually a parallel commercial model.

Optical generations matter

Modern optical platforms (post-2015 ROADM, OpenROADM-aligned) speak NETCONF/YANG and slot into the orchestration story without adapter heroics. Legacy SDH/SONET and pre-OpenROADM optical do not. A transformation programme that assumes "optical = NETCONF" because the new gear speaks it will be ambushed by the legacy footprint inherited from acquisitions and long-life backbone infrastructure.

Anti-Patterns Specific to IP/MPLS Orchestration

IP/MPLS/transport orchestration anti-patterns

Anti-pattern	What it looks like	What breaks first
Per-VRF Jinja-templated NSO	Service model bypassed; engineers write per-customer Jinja templates and push CLI through NSO as a transport	NSO's transactional rollback is bypassed; first multi-device commit failure leaves orphaned config; reconciliation between desired and running state is impossible
SDH / SONET circuits modelled in YANG	Trying to fit legacy TDM service into a YANG model that does not represent it cleanly	The model bends to the device, not the service; every legacy variation forces a YANG extension; the model becomes unmaintainable and brittle to vendor change
Manual VLAN / IP / route-target allocation	RFS provisioning relies on humans claiming VLANs from a spreadsheet or wiki	Allocation collisions appear in production; automation cannot proceed without an IPAM/VLAN allocator the catalog can call; the orchestrator pauses for manual steps
Hard-coded SR-TE / RSVP paths in the catalog	Catalog items specify which segment routing path to use	Path selection should be runtime, not design-time; hard-coded paths break under topology change, maintenance windows, and capacity events
Per-vendor service models leaking into XDO	XDO consumes a Cisco-flavoured L3VPN model and a Juniper-flavoured L3VPN model as different things	Multi-vendor estate forces XDO to know vendors it should not know about; a vendor swap becomes an XDO refactor instead of a controller swap
Optical and IP modelled as separate orchestration islands	Two controllers, two service catalogs, no awareness between them	Wavelength provisioning blocks IP service activation but the IP orchestrator cannot see why; ops works around it manually; "design phase" lengthens

Section 11.3 Key Takeaways

IP/MPLS, transport, and optical form a single orchestration domain because their service models compose. Splitting them across separate orchestrators creates artificial coupling.
The domain exposes standardised abstractions (L3VPN, L2VPN/EVPN, IP transit, optical λ, SR transport) via IETF YANG models — L3SM/L3NM/L2NM/L1CSM — that are uniquely mature compared to other OSS domains.
Cisco NSO, Nokia NSP, Juniper Paragon, and Blue Planet dominate the controller layer. Multi-vendor support is non-negotiable; NSO's NED ecosystem is the de-facto multi-vendor framework, and its maintenance cost is non-zero.
Topology is a runtime concern, not a catalog concern. BGP-LS and PCEP/SR-PCE give the controller live state; the catalog must remain abstract enough that the controller can select paths.
Legacy SDH/SONET and pre-OpenROADM optical have no native model-driven story. Integrating them costs real adapter engineering and creates the largest abstraction gap in this domain.
The fastest disasters here — per-VRF Jinja-templated NSO, hard-coded SR paths in the catalog, manual VLAN allocation, vendor-flavoured service models leaking into XDO — are catalog anti-patterns more than network engineering ones.