A Lightweight Cross-Layer Simulation Framework for IP-Optical Network Digital Twins

Introduction Operator backbone networks are commonly engineered and operated using a layered architecture. The IP layer handles routing, traffic engineering, Segment Routing policies , fast reroute, and packet forwarding. The optical and transport layers handle optical channels, OTN containers, wavelengths, line systems, protection groups, fiber spans, and physical sites. This separation provides useful operational boundaries. However, it also creates cross-layer visibility gaps. The IP layer typically observes logical links, IGP adjacencies, TE attributes, Segment Routing policies, BGP paths, and traffic matrices. The optical and transport layers observe ODU containers, optical channels, optical power, error counters, line systems, ROADMs, transponders, fiber spans, ducts, sites, and protection state. These layers use different identifiers, models, event semantics, and timing behavior. As a result, a single-layer simulation may not be sufficient for several operational questions. Examples include:

Two IP backup paths may be logically disjoint but may share the same fiber cable, duct, site, power domain, or maintenance window;
An optical soft degradation may affect packet loss or delay before a hard failure or a protection switch is visible to the IP layer;
Optical protection and IP-layer mechanisms, such as fast reroute, BFD detection , IGP convergence, or Segment Routing policy recomputation, may overlap in time and cause unnecessary churn;
An optical-layer simulation may model lower-layer resource failures, but may not evaluate IP traffic redistribution, service priority, congestion, or packet-layer convergence; and
Energy-saving actions on packet, OTN, or optical resources may reduce restoration capacity or increase recovery time after a later failure.

A Network Digital Twin provides an appropriate environment for this type of cross-layer what-if analysis. The framework in this document is intended to be lightweight. It does not perform continuous physical optical propagation simulation. Instead, it abstracts optical and transport behavior as discrete resources, events, states, timers, and resource counters. It then translates lower-layer events into inputs that can be used by an IP-layer simulation function.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

Scope and Non-Goals This document is scoped to cross-layer simulation in a Network Digital Twin, planning system, assurance system, or offline validation environment. This document does not define: * A new IGP, BGP, Segment Routing, PCE, OTN, or optical control-plane protocol; * A new BGP-LS NLRI, TLV, or attribute; * A new ACTN MPI, CMI, or SBI; * A new optical protection protocol; * A new SRLG encoding; * A new YANG module; * A closed-loop automation procedure for production networks; or * A replacement for detailed optical planning or optical impairment tools. The framework consumes existing topology, telemetry, inventory, service, and controller data where available. It does not require changes to production routing protocols, optical control protocols, or production device behavior. All simulated events, coordination hints, simulation metric adjustment advice, simulated link-state changes, protection actions, and energy-state changes described in this document are digital-twin-internal objects. They MUST NOT be directly sent to production routers, optical devices, or controllers as configuration or control instructions.

Relationship to Existing Work This document is intended to describe a concrete cross-layer simulation use case for Network Digital Twin systems. It is aligned with the Network Digital Twin reference architecture described in , but it does not update or extend that architecture. The framework can consume service-to-infrastructure relationship information from Service and Infrastructure Maps (SIMAP) . This document does not define a SIMAP data model and does not extend any SIMAP YANG module. The framework can consume abstract TE topology or resource information from ACTN-based systems . This document does not define a new ACTN interface and does not change the roles of CNC, MDSC, or PNC. The framework can reference TE topology objects from and technology-specific optical or OTN topology objects from applicable CCAMP models, such as and . This document does not define a new optical topology model or a new optical impairment model.

Terminology

Network Digital Twin (NDT):: A digital representation of a network and its behavior, used to support analysis, diagnosis, simulation, prediction, validation, and optimization.
IP Simulation Function (IPSF):: A logical function that simulates IP-layer control-plane and forwarding behavior in a digital twin. The simulated behavior can include IGP, BGP, Segment Routing, TE, fast reroute, BFD-related effects, traffic redistribution, and congestion.
Lightweight Optical and Transport State Function (LOTSF):: A logical function that represents optical, OTN, and physical resource behavior as discrete states, events, timers, and resource counters. The LOTSF does not perform continuous optical propagation simulation.
Cross-Layer Correlation Function (CLCF):: A logical function that maintains relationships between IP-layer objects and optical, OTN, and physical resources. It translates events between the IPSF and the LOTSF for simulation purposes.
Cross-Layer Dependency Graph:: A graph maintained by the CLCF. It represents relationships among IP interfaces, IP logical links, client ports, OTN resources, optical channels, line-system resources, fiber spans, ducts, sites, protection groups, and other shared-risk objects.
Soft Degradation:: A lower-layer condition in which transport or optical performance has degraded but has not necessarily resulted in a hard failure, loss of signal, or protection switch.
Protection Simulation Hint (PSH):: A digital-twin-internal object generated by the CLCF. It indicates that the IPSF can simulate a bounded protection-coordination behavior. A PSH is not a protocol message and MUST NOT be sent to production network devices.
Simulation-Only Object:: An object that exists only in a digital twin or simulation context. A simulation-only object MUST NOT be interpreted as production configuration or production operational state.

Framework Architecture The framework contains three logical functions. Figure 1: IP-Optical Cross-Layer Simulation Framework Architecture The IPSF simulates IP-layer behavior. Its inputs can include IP topology, IGP attributes, TE attributes, Segment Routing policies, BGP paths, link utilization, traffic matrices, and service priorities. The LOTSF simulates discrete state of optical, OTN, and physical resources. Its inputs can include ODU resources, optical channels, wavelengths, protection groups, line systems, optical power, FEC-related counters, alarms, fiber cables, ducts, sites, and energy state. The CLCF is the cross-layer correlation and translation function. It does not replace an IP controller, optical controller, or ACTN controller. It maintains a cross-layer dependency graph in the digital twin, translates lower-layer events into IP-layer simulation inputs, and translates IP-layer path or service queries into lower-layer constraint queries.

Data Sources The framework can consume data from several sources. Examples include: * Link-state and traffic-engineering information collected using BGP-LS ; * Segment Routing information carried using BGP-LS SR extensions ; * Topology data modeled using the generic network topology model and the TE topology model ; * Transport and optical resource data from OTN, WSON, flexi-grid, or optical impairment-aware topology models; * Service, tunnel, and protection relationship data from controllers, orchestrators, planning systems, or network management systems; * Traffic matrices from IPFIX, NetFlow, telemetry, controller analytics, or planning databases; * Optical performance indicators, including optical power, pre-FEC and post-FEC error counters, OSNR-related indicators, protection state, alarms, and performance counters; and * Physical inventory information, including sites, racks, fiber cables, ducts, conduits, line-system components, power domains, and maintenance domains. A deployment is expected to record the source, timestamp, freshness, and confidence of each data input. If data from multiple sources conflicts, the deployment can apply an operator-defined precedence policy and expose unresolved conflicts in simulation results.

Cross-Layer Dependency Graph The Cross-Layer Dependency Graph is the main correlation structure used by the CLCF. A deployment can use this graph to represent relationships such as: * IP logical link to router interface; * Router interface to transponder, muxponder, or OTN client port; * Transponder, muxponder, or OTN client port to client signal; * Client signal to ODU container or time-slot resource; * ODU resource to optical channel or wavelength; * Optical channel to line-system segment; * Line-system segment to fiber span; * Fiber span to cable, duct, conduit, site, or maintenance domain; and * Resource to protection group, restoration domain, or shared-risk object. The graph can contain one-to-one, one-to-many, many-to-one, and many-to-many relationships. For example, one IP logical link may traverse multiple optical and physical resources, and one physical resource may carry multiple IP logical links. The CLCF can derive simulation SRLGs from the Cross-Layer Dependency Graph. A derived simulation SRLG can include protocol-visible SRLGs, such as SRLG information used with GMPLS routing extensions RFC4203, and simulation-only risk objects, such as a shared fiber cable, shared duct, shared site, shared power domain, shared amplifier site, or shared maintenance window. A simulation SRLG MUST NOT be automatically injected into a production control plane unless a separate operator-approved provisioning and change control process explicitly does so.

Lightweight Optical and Transport State Abstraction The LOTSF represents optical and transport behavior using discrete states, events, timers, and resource counters. It is intended to be lightweight enough for large-scale what-if simulation.

Resource State The LOTSF can represent the following resource types when such data is available: * Optical channel or wavelength; * ODU container, tributary slot, or equivalent transport resource; * Line-system segment; * Fiber span; * ROADM, amplifier, transponder, muxponder, or other relevant component; * Protection group or restoration domain; and * Energy state of ports, modules, cards, and line-system components.

Event State The LOTSF can use the following event states:

Event State	Description
HEALTHY	The resource is healthy and no simulated event affects service behavior.
SOFT_DEGRADED	A lower-layer performance indicator has crossed an operator-defined warning or soft-failure threshold, but the condition has not necessarily resulted in a hard failure or protection switch.
HARD_FAILED	A hard failure has occurred, such as a modeled fiber cut, loss of signal, equipment failure, or equivalent loss of transport capability.
OPTICAL_RESTORING	The optical or transport layer is performing protection switching or restoration in the simulation.
COORDINATION_RACE	A system-level composite state in which lower-layer protection or restoration and IP-layer detection, fast reroute, IGP convergence, or Segment Routing policy recomputation overlap in the simulation timeline and may cause packet loss, reordering, oscillation, or suboptimal routing. Unlike per-resource states, this state reflects a cross-layer timing condition.
CONVERGED	The simulated multi-layer system has reached a stable state after protection, restoration, rerouting, or traffic shifting.

Timer and Jitter Modeling A deployment can use stochastic, historical, or deterministic delay models. Modeled delays can include: * Lower-layer fault detection delay; * Performance monitoring report delay; * Protection switching delay; * Restoration delay; * Alarm propagation delay; * Resource wake-up delay; and * Cross-layer translation and simulation processing delay. Stochastic or historical delay models are useful when the operator wants to evaluate sensitivity to hardware response variation, alarm propagation variation, restoration timing, or wake-up timing. Deterministic timers are useful for repeatable test cases.

Cross-Layer Simulation Procedure

Topology Ingestion The IPSF imports IP topology, routing, Segment Routing, TE, and traffic data. The LOTSF imports optical, OTN, and physical resource data. The CLCF builds the Cross-Layer Dependency Graph from these inputs. If an IP logical link has no known lower-layer dependency, the CLCF can mark the link as having incomplete cross-layer correlation. Results that depend on such a link can be reported with reduced confidence.

Event Normalization When the LOTSF generates or receives a lower-layer event, the CLCF normalizes the event into common attributes, including affected resources, severity, timestamp, validity interval, and confidence. If one lower-layer event affects multiple resources, the CLCF can identify affected IP logical links, Segment Routing policies, TE tunnels, service paths, and traffic demands.

Cross-Layer Translation The CLCF translates lower-layer events into IP-layer simulation events. Typical translations include: * Mapping a fiber cut to one or more simulated IP logical link failures; * Mapping soft degradation to loss risk, delay variation, capacity reduction, or simulation simulation metric adjustment advice; * Mapping lower-layer protection switching to a transient capacity change, delay change, or restoration window; * Mapping a shared cable, duct, conduit, or site to an SRLG relationship; and * Mapping a sleeping resource to reduced restoration capacity or increased recovery time. Translation rules are expected to be operator-configurable. A simulation result can record the rule version used during the simulation.

IP-Layer Impact Simulation The IPSF simulates IP-layer behavior using the translated events. The simulated behavior can include: * IGP convergence; * BGP path changes; * Segment Routing policy recomputation; * Fast reroute behavior; * BFD-related detection effects; * Traffic redistribution; * Congestion, loss, delay, and availability changes; and * Service-priority impact. If BFD behavior is modeled, the IPSF is expected to use the configured BFD detection time or an operator-specified simulation profile. The framework does not assume a universal BFD timer value. In soft-degradation scenarios, BFD behavior is modeled according to operator policy and the configured detection profile. For example, BFD may remain up while the modeled degradation does not prevent BFD control packets from being received within the configured detection time, or it may be modeled as down when packet loss or delay causes the configured detection time to expire.

Result Generation The simulation result can include: * Injected or observed events; * Affected lower-layer resources; * Affected IP links, paths, Segment Routing policies, and services; * Protection, restoration, and convergence timeline; * Loss, delay, utilization, and availability impact; * SRLG or physical-diversity violations; * Energy-state impact on restoration capability; * Translation rule versions; * Data completeness and confidence; and * Optional operational recommendations. Operational recommendations in the simulation result are advisory. They MUST NOT be automatically applied to production network elements unless a separate operator-approved validation and change-control process exists.

Use Cases

Cross-Layer SRLG Resiliency Validation Two primary or backup paths can be disjoint in the IP topology but share a lower-layer or physical resource. This use case validates whether IP-layer protection paths satisfy physical-diversity requirements. A typical procedure is: 1. The CLCF derives simulation SRLGs from the Cross-Layer Dependency Graph; 2. The LOTSF models a failure of a cable, duct, site, line-system segment, or other risk object; 3. The CLCF identifies affected IP links, paths, and services; 4. The IPSF simulates routing convergence, Segment Routing policy recomputation, and traffic shifting; and 5. The framework reports congestion, service impact, and physical-diversity violations. The output can include hidden shared risks, non-diverse backup paths, post-failure congestion points, and candidate physically diverse paths.

Soft Degradation Impact Analysis A lower-layer soft degradation may not immediately cause a hard failure or protection switch, but it can affect packet loss, delay variation, or error behavior. This use case evaluates the service-impact window between lower-layer degradation and IP-layer reaction. A typical procedure is: 1. The LOTSF models an optical power anomaly, FEC counter anomaly, or performance counter anomaly as SOFT_DEGRADED; 2. The CLCF translates the soft degradation to IP-layer loss risk, delay variation, capacity reduction, or simulation metric adjustment advice; 3. The IPSF compares candidate strategies, such as keeping traffic in place, moving only high-priority traffic, increasing a metric, or simulating link withdrawal; and 4. The framework reports service impact, congestion, and convergence effects for each strategy. This use case does not require production routers to directly interpret optical impairment indicators.

Protection-Timer Interaction Analysis Lower-layer protection and IP-layer protection can occur within overlapping time windows. Depending on timer values and implementation behavior, the overlap can be benign or can cause unnecessary rerouting, transient congestion, reordering, or oscillation. A typical procedure is: 1. The LOTSF provides the modeled lower-layer detection, protection, and restoration timeline; 2. The IPSF provides the modeled IP-layer detection, fast-reroute, and convergence timeline; 3. The CLCF identifies overlapping intervals; 4. The simulation enters COORDINATION_RACE state if the modeled actions conflict; and 5. The framework compares timer profiles, hold-down windows, and protection policies. The output can include whether IP-layer action occurs before lower-layer recovery, whether unnecessary convergence occurs, whether traffic churn is introduced, and whether a different timer profile should be evaluated.

Coordinated Protection and Flexible Traffic Shifting When a lower-layer resource is soft-degraded but not hard-failed, moving all traffic away from the affected path can overload backup paths, while taking no action can harm high-priority services. This use case evaluates service-aware and staged cross-layer protection strategies. A typical procedure is: 1. The LOTSF reports a soft degradation event; 2. The CLCF generates a Protection Simulation Hint with a bounded validity interval; 3. The IPSF simulates one or more behaviors, such as delayed failure declaration, suppression of global convergence, metric increase, movement of only high-priority traffic, or recomputation of physically diverse Segment Routing policies; and 4. The framework compares service impact, congestion, convergence, and stability. The PSH is used only inside the digital twin. It is not a production protocol message.

Energy-Aware IP-Optical Simulation During low-demand periods, an operator may want to evaluate whether selected ports, transponders, muxponders, OTN resources, optical channels, modules, or cards can be placed into lower-power states when such states are supported by the equipment and operational policy. A typical procedure is: 1. The IPSF identifies low-load links or demands using the traffic matrix; 2. The CLCF maps the selected IP objects to optical, OTN, and physical resources; 3. The LOTSF marks candidate resources as sleeping in the simulation; 4. The framework evaluates N-1 or operator-defined failure cases under the sleeping topology; and 5. The framework evaluates wake-up delay, restoration capacity, physical diversity, and service objectives. A candidate energy-saving policy can be reported as feasible only when the modeled low-power states are supported by the relevant equipment and when the policy satisfies utilization, restoration-capacity, wake-up-delay, physical-diversity, and protection-timing constraints defined by the operator.

Operational Considerations

Data Completeness The accuracy of cross-layer simulation depends on the completeness of resource mapping. Missing inventory, incomplete fiber mapping, stale OTN resource data, or incorrect service mapping can lead to incorrect results. A deployment can report data gaps, incomplete mappings, and low-confidence objects.

Time Synchronization Cross-layer timing analysis depends on a consistent time base. Telemetry systems, controllers, network management systems, and the digital twin can use synchronized time sources. If timestamp uncertainty is material to the result, the simulation can report uncertainty bounds.

Policy Versioning Translation rules, soft-degradation thresholds, simulation metric adjustment policies, service-priority policies, and energy constraints can be versioned. A simulation result can record the policy versions used for reproducibility and audit.

Scalability Large provider networks can contain many routers, optical channels, OTN resources, physical assets, and services. Implementations can use incremental updates, event-driven simulation, and local recomputation when possible.

Security Considerations The framework described in this document can consume sensitive production network data, including topology, traffic matrices, customer-service mapping, physical fiber routes, site locations, and shared-risk information. The framework MUST preserve separation between the digital twin and the production network. Simulation events, Protection Simulation Hints, simulation metric adjustment advice, simulated link-state changes, simulated interface state, and other simulation outputs MUST NOT be directly sent to production routers, optical controllers, or optical devices. Topology, traffic matrices, customer-service mapping, physical routes, site locations, and shared-risk information SHOULD be protected by access control. Sensitive data SHOULD be encrypted in transit and at rest. Data collection SHOULD use read-only access whenever possible. If a deployment also contains closed-loop automation, that automation MUST be separated from this simulation framework by explicit validation, approval, and change-control procedures. Input data SHOULD be validated. Malicious or incorrect topology, telemetry, or inventory data can produce incorrect simulation results, conceal shared risks, or generate unsafe operational recommendations. Simulation reports can expose network weaknesses. Reports SHOULD be protected with the same or stronger controls as the input data.

IANA Considerations This document requests no IANA actions.