| Internet-Draft | IP-Optical NDT Simulation Framework | November 2026 |
| Zhao, et al. | Expires 6 May 2027 | [Page] |
This document describes a lightweight, event-driven simulation framework for IP-optical Network Digital Twins (NDTs). The framework investigates how optical and transport events propagate across network layers and interact with IP-layer protection, routing convergence, and traffic redistribution.¶
The framework integrates three capabilities into a unified simulation process: dependency-aware event propagation, causal coordination of IP and optical behaviors on a common simulation timeline, and fidelity-aware evaluation of the resulting service impacts. Cross-layer dependency uncertainty and model limitations are explicitly considered to avoid unsupported resilience conclusions.¶
The framework uses abstract optical and transport states rather than continuous optical propagation models. It reuses existing IETF topology and management information where applicable and supports reproducible what-if analysis, historical incident replay, and protection-strategy comparison. It does not define new network protocols or YANG modules, and simulation results are not directly applied to production networks.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 6 May 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
IP and optical transport networks are commonly managed as separate layers. The IP layer provides routing, traffic engineering, Segment Routing, fast reroute, and traffic forwarding, while optical and transport layers provide connectivity, resource allocation, and protection or restoration capabilities.¶
Although these layers are operationally distinct, their behaviors are closely coupled. A physical failure may affect multiple IP links, while optical protection may restore connectivity before an IP-layer failure-detection mechanism triggers. Conversely, IP fast reroute or routing convergence may occur while lower-layer restoration is still in progress, potentially causing unnecessary traffic movement or transient congestion.¶
Such interactions are difficult to evaluate using an IP-only or optical-only simulation. Static cross-layer topology correlation can identify dependencies but cannot, by itself, explain how protection actions and service impacts evolve over time.¶
The main research question addressed by this document is: * How can a lightweight Network Digital Twin reproduce the causal interactions between optical and IP network behaviors, while accounting for incomplete dependency information and limitations of simplified simulation models?¶
To address this question, the framework combines an abstract optical and transport state model with IP-layer behavior simulation through a common cross-layer event mechanism. The intended contribution is not a new topology model or an additional network control protocol. Instead, it is a simulation methodology for determining which resources are affected by an event, how the resulting network behaviors interact over time, and under which conditions the resulting service-impact estimates can be considered reliable.¶
This document builds upon the IRTF NDT reference architecture and can use topology relationships provided by SIMAP and existing IP/optical topology models.¶
While these existing efforts provide architectural foundations, topology correlation, and support for what-if analysis, this document focuses on the execution semantics of interacting optical and IP-layer events, uncertainty propagation into dynamic service-impact assessment, and reproducible validation of simulation behavior.¶
The framework does not redefine the underlying topology models or their interfaces.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The framework contains three logical functions: * IP Simulation Function (IPSF): Simulates IP-layer behavior, including failure detection, IGP convergence, Segment Routing policy changes, fast reroute, traffic redistribution, and resulting service impacts. * Lightweight Optical and Transport State Function (LOTSF): Represents optical, OTN, and physical resources using discrete resource states, protection actions, timers, and capacity characteristics. It does not require continuous optical propagation simulation. * Cross-Layer Correlation Function (CLCF): Maintains cross-layer dependency relationships, translates events between simulation functions, and coordinates event execution using a common causal event timeline.¶
The CLCF is the central coordination function. It does not replace production controllers and does not control the production network.¶
+-----------------------------------------------------------+
| NDT Scenario Context |
| |
| IP/TE Topology | Optical/OTN Resources | Traffic |
| Dependency Information | Events | Timing Profiles |
+-----------------------------+-----------------------------+
|
v
+-----------------------------------------------------------+
| Cross-Layer Correlation Function (CLCF) |
| |
| +-------------------+ +------------------------------+ |
| | Dependency Graph | | Causal Event Queue | |
| | | | | |
| | Resource Mapping | | Event Ordering | |
| | Shared Risks | | Causal Dependencies | |
| | Uncertainty | | Cross-Layer Translation | |
| +-------------------+ +------------------------------+ |
+-----------------------------+-----------------------------+
|
+-------------+-------------+
| |
v v
+---------------------------+ +----------------------------+
| Lightweight Optical and | | IP Simulation Function |
| Transport State Function | | (IPSF) |
| (LOTSF) | | |
| | | IP Detection / FRR |
| Optical / OTN States | | IGP / BGP / SR Policy |
| Protection / Restoration | | Routing Convergence |
| Resource Capacity | | Traffic / Service Impact |
+-------------+-------------+ +--------------+-------------+
| |
+---------------+---------------+
|
v
+-----------------------------------------------------------+
| Cross-Layer Evaluation |
| |
| Causal Event Trace | Service Impact | Shared-Risk Exposure|
| Dependency Uncertainty | Model Fidelity |
| Reproducible Scenario Comparison |
+-----------------------------+-----------------------------+
|
v
Advisory Results Only
The arrows in Figure 1 represent the logical organization of the framework. During simulation, the CLCF exchanges events and state updates bidirectionally with the IPSF and LOTSF. Result evaluation may also use intermediate states, not only final states.¶
Each simulation is associated with a scenario context containing the baseline topology, traffic demands, service objectives, relevant resource dependencies, event inputs, and applicable timing and policy profiles.¶
A Cross-Layer Dependency Graph provides the relationships required to determine how lower-layer resource changes may affect IP-layer objects. These relationships can include IP logical links, router interfaces, OTN resources, optical channels, fiber spans, cables, ducts, sites, protection groups, and physical shared-risk objects.¶
Dependency information may be incomplete, inferred, or inconsistent across data sources. To represent these conditions, the framework distinguishes four relationship categories:¶
Verified: A relationship supported by available authoritative or otherwise validated information.¶
Inferred: A relationship derived from indirect evidence or correlation rules.¶
Conflicting: A relationship for which available sources provide incompatible information.¶
Unknown: A relationship that cannot be established using the available inputs.¶
Dependencies may also carry source provenance, temporal validity, and confidence indications. A confidence indication does not necessarily represent a statistically calibrated probability.¶
The CLCF uses these attributes when determining the affected resources of an event. A verified dependency can support a definite impact conclusion under the declared model assumptions, whereas an unknown or conflicting dependency may require alternative hypotheses or an explicitly undetermined result.¶
In particular, an unknown lower-layer dependency MUST NOT be interpreted as evidence that two IP paths are physically disjoint.¶
The Cross-Layer Dependency Graph may contain incomplete, inferred, or conflicting relationships. These conditions can affect both the identification of shared physical risks and the propagation of lower-layer events into IP-layer simulation effects.¶
The framework therefore distinguishes uncertainty in dependency evidence from uncertainty in the resulting resilience conclusion.¶
When a dependency cannot be uniquely established, the CLCF can construct alternative dependency hypotheses consistent with the available observations and verified relationships.¶
Each hypothesis represents a possible cross-layer dependency configuration for the affected part of the network.¶
Verified relationships are preserved across admissible hypotheses. Inferred, conflicting, or unknown relationships may produce alternative dependency configurations, subject to known resource and topology constraints.¶
The framework does not assign numerical probabilities to these hypotheses unless a separately validated probabilistic model is available.¶
Hypothesis evaluation can be limited to the resources relevant to the selected simulation scenario to avoid unnecessary expansion of the entire dependency graph.¶
For a given topology snapshot, the CLCF evaluates whether a primary path and a backup path satisfy the physical-diversity requirement within a declared shared-risk scope.¶
The assessment produces one of three outcomes:¶
Verified: Physical disjointness is established through complete, verified dependency information within the assessment scope, or through exhaustive evaluation showing that all materially admissible dependency hypotheses satisfy the diversity requirement.¶
Violated: A shared physical-risk object is established by verified evidence, or exhaustive evaluation shows that all materially admissible dependency hypotheses violate the diversity requirement.¶
Undetermined: Neither physical disjointness nor a violation can be established. This includes cases involving incomplete or conflicting dependencies, differing outcomes across admissible hypotheses, or insufficient hypothesis coverage.¶
An unknown dependency MUST NOT be interpreted as evidence of physical disjointness. When only a subset of admissible hypotheses has been evaluated, a definitive conclusion requires sufficient independent evidence; otherwise, the result is Undetermined.¶
The assessment report identifies the supporting evidence, unresolved dependencies, and relevant assumptions. Here, Verified denotes the physical-diversity assessment outcome rather than the verification status of an individual dependency relationship.¶
Dependency uncertainty is also considered when propagating lower-layer events into IP-layer effects.¶
For each admissible dependency hypothesis, the CLCF identifies the potentially affected IP links, paths, and services. The corresponding event effects can then be evaluated using the causal simulation procedure.¶
The resulting affected-resource sets may be compared to distinguish:¶
Confirmed affected resources: Confirmed affected resources are those whose impact is established by verified dependencies or by exhaustive hypothesis evaluation. If the hypothesis set is incomplete, resources affected under every evaluated hypothesis are reported as common to the evaluated scenarios, rather than definitively affected.¶
Potentially affected resources: Resources identified as affected under at least one admissible hypothesis.¶
Unaffected resources: Resources established as unaffected under all relevant admissible hypotheses.¶
For quantitative service-impact metrics, the framework may report the range of results obtained across the evaluated hypotheses.¶
Such ranges are not necessarily statistical confidence intervals. They represent scenario-dependent outcomes under the specified dependency assumptions. They constitute exhaustive bounds only when the evaluated hypotheses cover all material admissible possibilities.¶
This distinction allows the framework to avoid producing a single unsupported prediction when dependency information is insufficient.¶
Each dependency hypothesis is evaluated using an independent simulation state and causal event queue initialized from the same baseline scenario. Events and state changes produced under one hypothesis do not affect the execution of another hypothesis. Results are aggregated only after the individual hypothesis evaluations are completed.¶
A simulation report can include the assessed resilience status, supporting dependency evidence, unresolved dependency relationships, and assumptions used during hypothesis evaluation.¶
When service-impact estimates differ between hypotheses, the report identifies the dependencies responsible for those differences.¶
The result can therefore distinguish a verified shared-risk violation, a potential shared-risk exposure, and an absence of sufficient evidence to establish physical diversity.¶
This mechanism enables dependency uncertainty to influence both the interpretation of cross-layer resilience and the execution of service-impact simulation.¶
The framework uses a simulation-wide Causal Event Queue to coordinate optical/transport events, IP-layer reactions, and service-impact observations. The queue is intended to reproduce the temporal and causal relationships between network-layer behaviors without requiring the optical and IP simulation functions to execute in lockstep.¶
A normalized simulation event is represented by the following logical attributes:¶
Event Identifier: A unique identifier within the simulation execution.¶
Scheduled Time: The logical time at which the event is eligible for execution.¶
Origin and Target: The originating function and affected resource or network object.¶
Event Type: A resource-state change, observation, protection action, routing reaction, or evaluation event.¶
Causal Predecessors: References to events whose successful execution is required before the event can proceed.¶
Expected State Version: An optional reference to the resource-state version under which the event was generated.¶
Event Parameters: Timing, resource, and policy parameters relevant to the modeled action.¶
An event may additionally contain its effective timestamp and observation timestamp when these differ from the scheduled execution time.¶
The distinction is important because the occurrence of a physical condition and its observation by an IP-layer mechanism are not necessarily simultaneous.¶
Each event is associated with an execution precondition. An event is eligible for execution only when its causal predecessors have completed and its relevant state conditions remain satisfied.¶
For example, a simulated IP fast-reroute action may depend on the completion of an IP-layer failure-detection event. If optical restoration removes the impairment before the configured detection condition is satisfied, the pending detection event may become inapplicable.¶
Conversely, a rerouting action already completed before optical restoration is not retroactively removed. Any subsequent traffic movement must be represented by another event.¶
+------------------------------------------------+
+--->| Causal Event Queue (Q) |
| | |
| | Time / Event ID / Causal Predecessors |
| | Expected State Version / Event Parameters |
| +-----------------------+------------------------+
| |
| v
| +------------------------+
| | Pending event within | No
| | simulation horizon T? +-------------+
| +-----------+------------+ |
| Yes |
| | |
| v |
| +------------------------+ |
| | Advance Logical Time | |
| | Accumulate Service | |
| | Impact over Interval | |
| +-----------+------------+ |
| | |
| v |
| +------------------------+ |
| | Select and Remove | |
| | Causally Enabled Event | |
| +-----------+------------+ |
| | |
| v |
| +------------------------+ |
| | Event Validation | |
| | | |
| | Check Preconditions | |
| | Check State Version | |
| | Check Duplicate Effect | |
| +-----------+------------+ |
| | |
| +-----------+-----------+ |
| | | |
| Invalid Valid |
| | | |
| v v |
| +-------------------+ +----------------------+ |
| | Skip / Invalidate | | Atomic State Update | |
| | / Deduplicate | | | |
| | | | LOTSF: Optical / OTN | |
| | Record Outcome | | IPSF: IP / Routing | |
| +---------+---------+ +----------+-----------+ |
| | | |
| | v |
| | +----------------------+ |
| | | Derive New Events | |
| | | | |
| | | Detection/Protection | |
| | | Restoration/Reroute | |
| | +----------+-----------+ |
| | | |
| +-----------+-----------+ |
| | |
| v |
| +------------------------+ |
| | Record Causal Trace | |
| | Schedule New Events | |
| | (Event Time >= Now) | |
| +-----------+------------+ |
| | |
+-----------------------------+ |
|
v
+------------------------+
| Finalize Service Impact|
| |
| Causal Event Trace |
| Service / Risk Report |
| Model Status |
+------------------------+
The CLCF maintains a non-decreasing logical simulation clock. Events are selected primarily according to their scheduled simulation time.¶
At each simulation timestamp, the scheduler processes eligible events in an order consistent with their declared causal dependencies.¶
When multiple independent events share the same scheduled timestamp, the framework uses a documented deterministic tie-breaking rule. Such ordering is an execution convention and does not imply a physical causal relationship between otherwise independent network actions.¶
Each event applies an atomic update to the relevant simulated state and may generate additional events.¶
Newly generated events may target the same or another simulation function. Their scheduled times cannot precede the current logical simulation time.¶
Events generated at the same timestamp are processed until no further eligible same-time events remain. Implementations should detect inconsistent causal dependencies and unbounded zero-time event generation.¶
When concurrent events request conflicting state changes to the same resource, the simulator applies a declared conflict-resolution rule or reports an unresolved simulation conflict. When simultaneous events can produce different outcomes depending on their execution order, the framework should identify the result as ordering-sensitive. The simulator may evaluate alternative admissible orderings or apply a justified, documented ordering policy. Deterministic tie-breaking alone does not establish the physical ordering of concurrent network actions.¶
The IPSF and LOTSF can therefore model overlapping recovery processes while preserving deterministic replay.¶
Service impact is evaluated using the intermediate network states and their durations, rather than only the final converged state.¶
A pending event can become inapplicable when the underlying network state changes before the event is executed.¶
The framework uses resource-state versions and event preconditions to identify stale events. A stale event does not modify the current simulated state, but its invalidation and reason are retained in the causal event trace.¶
Duplicate event suppression is also necessary because the same physical failure may be reported through multiple alarms or management systems.¶
Events can be deduplicated when they represent the same causal occurrence, target resource, intended effect, and applicable state version. Events originating from distinct physical failures must not be merged solely because they affect the same resource.¶
The framework also distinguishes an unchanged state from a new state transition. Repeated notifications of an already-applied state change do not need to trigger repeated IP-layer reactions unless the configured model explicitly requires them.¶
If repeated cross-layer actions produce routing oscillation or continuing state changes, the framework retains those transitions as simulated behavior rather than incorrectly suppressing them as duplicates.¶
For each processed event, the framework records the scheduled and executed times, causal predecessors, state changes, and resulting events.¶
Events that are skipped, invalidated, or rejected are also recorded with their execution outcomes.¶
The resulting causal trace enables the framework to determine whether an IP-layer reaction was triggered by a lower-layer state change, an observation delay, an earlier routing action, or an interaction between concurrent recovery processes.¶
This event trace is the basis for reproducible scenario replay, timing-error analysis, and the identification of potentially adverse protection interactions.¶
Algorithm 1: Causal Cross-Layer Event Execution
Input:
S = initial simulation state
Q = initial causal event queue
T = simulation time horizon
t_prev = simulation start time
while Q is not empty:
t = Q.next_timestamp()
if t > T:
break
accumulate_service_impact(S, t_prev, t)
E = Q.remove_events_at(t)
steps = 0
while E is not empty:
e = E.pop_causally_enabled()
if e is NONE:
report_unresolved_dependencies(E)
terminate simulation
steps = steps + 1
if steps > MAX_ZERO_TIME_STEPS:
report_zero_time_cycle()
terminate simulation
if state_version_is_stale(e, S):
record(e, "INVALIDATED")
invalidate_dependent_events(e)
continue
if preconditions_not_satisfied(e, S):
record(e, "SKIPPED")
invalidate_dependent_events(e)
continue
if is_duplicate_effect(e, S):
record(e, "DEDUPLICATED")
continue
delta = apply_atomic_transition(e, S)
record(e, delta)
for child in derive_events(e, S):
require child.time >= t
if child.time == t:
E.insert(child)
else:
Q.insert(child)
t_prev = t
accumulate_service_impact(S, t_prev, T)
return:
causal_trace,
service_impact,
model_status
¶
The scheduler removes each selected event from the pending event set before processing it. Events generated at the current simulation timestamp are processed within the same logical time step. A bounded zero-time execution guard prevents unbounded event generation.¶
Service impact is accumulated over intervals between consecutive simulation timestamps, using the network state applicable to each interval. Invalidated or skipped events do not modify the simulation state, and their dependent events are invalidated unless an alternative valid causal dependency exists.¶
Consider an illustrative scenario in which a lower-layer failure occurs at simulation time 0, while an IP failure-detection condition would be satisfied at 50 ms if the impairment persists.¶
If the optical layer restores the affected connectivity at 35 ms and the IP detection condition is no longer satisfied, the pending detection event is invalidated and no IP rerouting is triggered by that event.¶
If optical restoration instead completes at 90 ms, the IP-layer detection event may execute at 50 ms and trigger a simulated rerouting action. When optical restoration subsequently completes, the resulting connectivity change may initiate further IP-layer behavior depending on the configured policy.¶
All timing values are illustrative and are not protocol defaults.¶
This example demonstrates that causal event execution must account for changing preconditions and concurrent recovery processes. Simply processing all previously scheduled events without state validation may produce unnecessary or incorrect simulated routing transitions.¶
The CLCF translates lower-layer state changes into IP-layer simulation effects using the dependency graph and configured translation rules.¶
For hard failures, translation identifies affected IP logical links, paths, Segment Routing policies, and services. However, a lower-layer failure does not automatically imply that the corresponding IP link becomes unavailable. Lower-layer protection may preserve or restore client connectivity before the relevant IP failure-detection mechanism declares a failure.¶
For soft degradation, the CLCF may estimate packet-loss risk, delay variation, or effective capacity reduction using equipment characteristics, historical measurements, calibrated impairment profiles, and operator-defined thresholds.¶
A pre-FEC error indication does not necessarily imply IP packet loss. When an impairment-to-service relationship is not sufficiently supported, the framework reports a bounded or unknown impact rather than assuming a deterministic mapping.¶
The IPSF subsequently models IP-layer reactions using the translated effects and configured protocol behavior. BFD-related behavior, for example, uses a configured or modeled detection profile rather than a universal detection-time assumption.¶
Cross-layer translation rules remain simulation-specific and may be calibrated using historical observations.¶
Consider a fiber failure affecting an optical resource that supports one or more IP logical links. The framework processes the resulting cross-layer events as follows:¶
Failure and Optical Protection: The LOTSF updates the affected resource state and schedules optical protection or restoration events according to the configured timing profile.¶
Cross-Layer Event Translation: The CLCF identifies affected IP links using the Cross-Layer Dependency Graph. If the lower-layer failure causes an observable IP-layer impairment, the CLCF generates a corresponding simulation event. A lower-layer failure does not necessarily imply an immediate IP link failure.¶
IP-Layer Reaction: Upon receiving the impairment event, the IPSF models the configured failure-detection behavior. If the impairment persists until the detection condition is satisfied, the IPSF may trigger fast reroute, routing convergence, or Segment Routing policy recomputation.¶
Restoration and Event Invalidation: When optical connectivity is restored, the LOTSF generates a restoration event, which the CLCF translates into an updated IP-layer condition. If the IP failure-detection condition is no longer satisfied, a pending detection event may be invalidated. IP-layer actions already completed are preserved, and any subsequent routing changes depend on the configured recovery policy.¶
Service-Impact Evaluation: The framework evaluates the resulting traffic and service states over the event timeline, including interruption duration, traffic redistribution, and possible overlapping protection actions.¶
For example, assume an impairment begins at simulation time 0 and would satisfy an IP failure-detection condition at 50 ms if it persists. If optical restoration completes at 35 ms and the impairment is cleared, the pending detection event is invalidated. If restoration completes at 90 ms, IP-layer detection and rerouting may occur before optical recovery.¶
These timing values are illustrative and are not protocol defaults.¶
This example demonstrates how the CLCF coordinates lower-layer state changes and IP-layer reactions through causal event scheduling, rather than directly mapping each optical failure to an unconditional IP link failure.¶
The interaction between optical restoration and IP-layer protection is evaluated through their combined effects on routing and service behavior.¶
The framework considers whether IP-layer detection and rerouting occur before, during, or after lower-layer recovery, and whether the resulting traffic movement is necessary or beneficial.¶
Overlapping protection actions do not automatically constitute a coordination problem. A coordination conflict is identified only when the modeled interaction causes an adverse outcome, such as avoidable rerouting, repeated traffic movement, transient congestion, or service-impact amplification under the selected evaluation criteria.¶
The IPSF calculates the effect of network-state changes on traffic demands, path availability, resource utilization, and service objectives. Service-specific delay, loss, and recovery constraints may be supplied as scenario evaluation criteria.¶
The resulting cross-layer evaluation can distinguish between a resource failure that is masked by lower-layer recovery, a failure requiring an IP-layer response, and an event whose effect remains uncertain because of incomplete dependencies or insufficient model fidelity.¶
A simulation produces a traceable evaluation report rather than a production control instruction.¶
The report can include:¶
The causal event trace and protection or convergence timeline. Affected resources, IP paths, and services. Service-impact estimates, including relevant loss, delay, congestion, and recovery characteristics. Verified shared risks, unresolved dependencies, and uncertainty assumptions. Scenario versions, translation rules, timing profiles, and model-validity information.¶
These outputs allow the operator to determine not only the expected service impact but also which assumptions and event interactions contributed to that result.¶
The proposed framework uses abstract optical and transport states to support lightweight cross-layer simulation. Its effectiveness depends on whether the model can reproduce relevant network behaviors and provide additional insight beyond existing simulation approaches.¶
This section outlines a methodology for validating model fidelity and evaluating the contribution of causal cross-layer simulation.¶
Model fidelity can be evaluated by replaying historical network incidents using recorded topology, optical alarms, protection events, IP routing changes, and service-performance observations.¶
The LOTSF reproduces lower-layer state transitions, while the CLCF coordinates cross-layer events and the IPSF simulates IP-layer reactions. The resulting event timeline and service impacts are compared with observed network behavior.¶
Relevant evaluation metrics include:¶
Event Timing Accuracy: Differences between simulated and observed event timestamps and recovery durations.¶
Event-Order Agreement: Consistency of simulated causal event sequences with observed event ordering.¶
Service-Impact Accuracy: Differences in service-interruption duration, traffic loss, and congestion behavior.¶
Dependency Accuracy: Correct identification of affected resources and physical shared risks.¶
Historical observations may be used to calibrate timing and event-translation parameters. Independent observations should be used for validation where available.¶
When operational ground truth is insufficient, the framework reports model assumptions and uncertainty rather than claiming validated prediction accuracy. Synthetic scenarios may verify execution correctness but do not establish operational accuracy.¶
The proposed framework can be compared with two baseline approaches to assess the additional value of causal cross-layer event simulation.¶
Three approaches are considered:¶
IP-Only Simulation: Models IP failure detection, routing convergence, and traffic redistribution without explicit lower-layer dependencies.¶
Static Cross-Layer Correlation: Uses IP-optical dependency information to identify affected resources and shared risks, but does not coordinate optical restoration and IP-layer reactions through a common causal event timeline.¶
Causal Cross-Layer Simulation: Combines dependency-aware event propagation, causal event scheduling, and uncertainty-aware service-impact evaluation.¶
A common failure scenario is used for comparison. Two logically disjoint IP paths share an underlying physical resource, while another backup path has incomplete physical-dependency information.¶
A lower-layer failure is introduced with different optical restoration timing profiles, allowing evaluation of interactions between optical recovery and IP-layer failure detection or rerouting.¶
The approaches use consistent IP behavior models, traffic demands, and service objectives where applicable. Differences in available cross-layer information are documented.¶
The comparison focuses on:¶
Shared-Risk Identification: Whether hidden physical dependencies and uncertain path-diversity conclusions are correctly identified.¶
Recovery Behavior: Whether cross-layer event ordering and protection interactions are accurately represented.¶
Service Impact: Differences in predicted interruption duration, congestion, and traffic redistribution.¶
Simulation Efficiency: Execution time, memory consumption, and event-processing overhead.¶
Results are compared against historical observations or a declared reference model where available. Unsupported predictions are reported as unavailable rather than assigned artificial error values.¶
For reproducibility, experiments record topology snapshots, dependency information, event inputs, timing profiles, model versions, and random seeds where applicable.¶
The evaluation aims to determine when causal cross-layer simulation provides additional accuracy or analytical value, while identifying limitations caused by incomplete data, model abstraction, and computational overhead. No performance improvement is assumed without supporting experimental evidence.¶
Consider an optical channel that experiences degraded performance without an immediate hard failure.¶
The LOTSF represents the degradation using a resource-state transition and relevant performance indicators. The CLCF applies an impairment-to-service translation profile to determine whether an IP-layer effect is supported by the available evidence.¶
The IPSF then evaluates alternative behaviors, such as maintaining the current route, selectively shifting affected traffic, or allowing configured protection mechanisms to respond.¶
The simulation compares service impact, traffic utilization, convergence behavior, and unnecessary routing changes.¶
If the relationship between optical degradation and packet-layer impact is uncertain, the evaluation reports the associated assumptions or impact bounds.¶
Historical observations may subsequently be used to assess whether the selected translation profile and event-timing model reproduce the observed service behavior.¶
This scenario demonstrates the role of calibrated impairment translation in causal cross-layer simulation without requiring continuous optical propagation modeling.¶
The framework can consume sensitive topology, physical infrastructure, service, and traffic information. Access control, data integrity protection, and appropriate confidentiality measures are therefore necessary.¶
Incorrect or malicious input data may lead to inaccurate dependency assessments, incorrect event propagation, or misleading recovery recommendations. Input validation and provenance tracking are important safeguards.¶
The simulation environment must remain logically isolated from production network control. Simulated state transitions, routing changes, protection actions, and traffic-engineering recommendations are simulation-only information and MUST NOT be directly applied to production network elements.¶
Any subsequent operational action based on simulation results requires a separate authorization, validation, and change-control process outside the scope of this document.¶
Simulation reports may reveal physical shared risks and network resilience weaknesses and should be protected accordingly.¶
This document requests no IANA actions.¶