TVR L. M. Contreras
Internet-Draft Telefonica
Intended status: Informational 20 October 2025
Expires: 23 April 2026
Using off-path mechanisms for exposing Time-Variant Routing information
draft-ietf-tvr-off-path-exposure-01
Abstract
Time-Variant Routing (TVR) involves predictable, scheduled changes to
network topology elements such as nodes, links, and adjacencies that
impact routing behavior over time. All those changes can alter the
connectivity in the network in a predictable manner, which is known
as Time-Variant Routing (TVR). This document proposes mechanisms for
exposing TVR information to both internal and external applications,
focusing on off-path solutions that decouple the advertisement of
scheduled changes from the routing control plane signaling.
Status of This Memo
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 23 April 2026.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
Contreras Expires 23 April 2026 [Page 1]
Internet-Draft Off-path TVR October 2025
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. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. On-path vs Off-path Mechanisms for TVR . . . . . . . . . . . 4
2.1. On-path Mechanisms . . . . . . . . . . . . . . . . . . . 4
2.2. Off-path Mechanisms . . . . . . . . . . . . . . . . . . . 4
2.3. Hybrid Approaches . . . . . . . . . . . . . . . . . . . . 5
3. Ways of retrieving scheduled topological changes . . . . . . 5
3.1. Interaction with a network controller . . . . . . . . . . 5
3.2. Interaction with routing protocols augmented to support TVR
advertisements . . . . . . . . . . . . . . . . . . . . . 6
3.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 6
4. Mechanisms for Exposing TVR Information . . . . . . . . . . . 7
4.1. ALTO Protocol . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Other Off-path Mechanisms . . . . . . . . . . . . . . . . 9
5. Security and operational considerations . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Assessment of ALTO as off-path solution against TVR
requirements . . . . . . . . . . . . . . . . . . . . . . 11
Appendix B. Assessment of the archietcture proposed in
I-D.wqb-tvr-applicability . . . . . . . . . . . . . . . . 13
Appendix C. Implementation status . . . . . . . . . . . . . . . 14
Appendix D. Identified gaps on TVR specifications . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
Time-Variant Routing (TVR) refers to operational scenarios where
network topology, including nodes, links, and adjacency attributes,
changes in a predictable, scheduled manner.
There can be operational situations (e.g., maintenance windows, load
balancing, energy-saving policies, or network upgrades) where changes
in the network, such as modifications in either nodes, links or
adjacencies, can introduce variations on the routing of that network.
Use cases representative of such operational situations are
Contreras Expires 23 April 2026 [Page 2]
Internet-Draft Off-path TVR October 2025
documented in [RFC9657]. Those predictable changes can be scheduled
either from a higher-level system (e.g., OSS) or from a Network
Controller. Figure 1 sketches a potential architecture facilitating
the exposure of changes introduced by TVR operation. There can be
multiple variants of such architecture.
Network (programming (impact
Operator ---------+ of scheduled estimation
| TVR changes) of scheduled
V TVR changes)
+-------------+ +--------------+
| Network | | Network |
| Controller |<----->| Digital Twin |
+-------------+ +--------------+
A |
(feeding impacts | | (activation
of scheduled +------+ +------+ of scheduled
TVR changes) | | TVR changes)
| |
V V
+-------------+ ,------._
|Off-path Info| ,-' `-.
| Component | / \
+-------------+ ( Network )
A \ /
| `-. ,-'
(exposure | `+------'
of scheduled | ^
TVR changes) | :
| (awareness :
| of scheduled v
| TVR changes) +-------------+
+------------->| Application |
+-------------+
Figure 1. Potential architecture using a dedicated Off-path
Information Component for advertising TVR scheduled changes
Since the expected changes can be predicted beforehand, then it is
possible to anticipate the impacts of that changes in the routing of
the network. , for instance by means of algorithms embedded in the
Network Controller allowing to recalculate the resulting routing
metrics, or through experimental observations e.g. in network digital
twins [I-D.irtf-nmrg-network-digital-twin-arch].
Being feasible then to automatize the changes and to pre-calculate
the impacts that those changes can introduce into the routing of the
network, it is possible to expose in advance such changes in a way
Contreras Expires 23 April 2026 [Page 3]
Internet-Draft Off-path TVR October 2025
that applications (both internal and external) can become aware of
those routing variations along time, allowing proactive service
management and optimization ahead of the activation of those changes.
This document builds on TVR-related foundational work [RFC9657],
[I-D.ietf-tvr-requirements] and [I-D.ietf-tvr-schedule-yang], but
focussing on off-path exposure of TVR information, describing
architectural considerations and mechanisms to present scheduled
network changes to applications.
2. On-path vs Off-path Mechanisms for TVR
At the time of advertising and consuming TVR scheduled changes, two
different mechanisms can be considered, namely on-path and off-path
mechanisms.
2.1. On-path Mechanisms
On-path mechanisms disseminate scheduled topological changes directly
through routing protocols such as OSPF, IS-IS, or BGP, augmented to
carry time-scheduled advertisements [I-D.ietf-tvr-schedule-yang].
This approach embeds TVR information on the routing data plane.
One of the primary benefits of disseminating scheduled topological
changes by routing protocols is the potential for timely, distributed
updates. This tight coupling enables rapid propagation of scheduled
changes across the network.
However, this approach also introduces several challenges:
* Cascading Updates: a single scheduled change (e.g., link metric
adjustment or path re-optimization) may trigger a series of
subsequent updates across the network. These cascading effects
can lead to excess of processing in the network elements if not
properly managed.
* Coordination and Conflict Resolution: in a distributed
environment, multiple nodes may attempt to adjust routes or
metrics concurrently. This increases the complexity of
coordination and requires robust mechanisms to detect and resolve
conflicts without introducing inconsistencies or loops.
2.2. Off-path Mechanisms
Off-path mechanisms expose TVR information via centralized or
logically separate systems outside the routing protocol control
plane, using specific protocols, data models or APIs for that
purpose.
Contreras Expires 23 April 2026 [Page 4]
Internet-Draft Off-path TVR October 2025
It can be advantageous for different reasons:
* Simplified conflict detection and resolution due to centralized
control.
* Controlled and potentially filtered exposure of information to
external or internal applications.
* Reduced impact on routing protocols and network stability.
Off-path solutions can ingest data from multiple sources, including
controllers and augmented routing protocols, and provide aggregated,
application-friendly views of scheduled network changes.
2.3. Hybrid Approaches
Hybrid approaches may combine on-path and off-path methods, e.g.,
using routing protocol advertisements for internal synchronization
and off-path systems for external exposure.
3. Ways of retrieving scheduled topological changes
According to the two strategies commented in the Introduction, it can
be considered two different ways in which off-path solutions retrieve
the information about scheduled topological changes. In one case,
the changes can be notified directly by a network controller, while
in the second case the changes are collected from advertisements in
augmented routing protocols.
In both cases, the data model for representing the scheduled changes
can be the same, describing the changing topological events in a
similar way. A data model for representing TVR information is
proposed in [I-D.ietf-tvr-schedule-yang], which can be used in any of
the options describe next.
3.1. Interaction with a network controller
The architecture in Figure 1 assumes the intervention of a Network
Controller in order to schedule and activate the changes in the
network in a predictable manner. The network controller can pass the
information about the planned changes to a separate component
dedicated to advertise the TVR changes off-path, or it could even
incorporate such capability as part of the functional capabilities of
the controller. Thus, depending on the capabilities of the
controller, it may either provide raw scheduled changes or
precomputed future topologies reflecting those changes.
Contreras Expires 23 April 2026 [Page 5]
Internet-Draft Off-path TVR October 2025
3.2. Interaction with routing protocols augmented to support TVR
advertisements
As an alternative solution, it could be the case that existing
routing protocols become augmented in order to natively support the
advertisement of network changes along the time (for instance, an
example of schedules for OSPF costs is provided in
[I-D.ietf-tvr-schedule-yang]). If that is the case, the off-path
solution can participate of the signaling of the network routing
information by listening to IGPs and/or peering with BGP speakers, as
described in [RFC7971]. This enables the off-path system to build
time-aware topological views based on routing advertisements.
3.3. Applicability
Uniform representation of scheduled changes facilitates ingestion and
processing. The YANG data model draft [I-D.ietf-tvr-schedule-yang]
provides a framework to represent schedules for nodes, interfaces,
and attributes, including timing, periodicity, and availability.
For instance, an engineer in the Network Operation Center (NOC)
represented in Figure 1 can program some changes in the network in a
planned, anticipated way so that the impacts of such changes can be
estimated in advance. For instance, the engineer can enter the
following data, according to [I-D.ietf-tvr-schedule-yang]:
Contreras Expires 23 April 2026 [Page 6]
Internet-Draft Off-path TVR October 2025
module: ietf-tvr-node
+--rw node-schedule
+--rw node-id? "192.168.10.17"
...
+--rw interface-schedule
+--rw interfaces*
+--rw name "GigabitEthernet0"
...
+--rw attribute-schedule
+--rw schedules*
+--rw schedule-id "0123456789"
+--rw (schedule-type)?
+--:(period)
...
+--rw period-start "2024-07-08T10:30:00"
+--rw time-zone-identifier? "Africa/Dakar"
+--rw (period-type)?
...
+--:(duration)
+--rw duration? "3600"
...
+--rw attr-value
+--rw available? "false"
This order represents the action of tearing down interface
GigabitEthernet0 of the node with loopback IP address 192.168.10.17
for one hour, at 10:30 local time of Dakar, due for instance to a
maintenance action in the network. With this information, the
network systems can analyse the impact of such action (the way in
which that impacts are evaluated are out of scope of this document).
According to the estimated impacts, the engineer can decide to
continue or to replan the action.
4. Mechanisms for Exposing TVR Information
Exposing TVR information requires mechanisms able to represent time-
varying network states, including topology and associated metrics,
with appropriate granularity and temporal precision.
4.1. ALTO Protocol
The Application-Layer Traffic Optimization (ALTO) protocol [RFC7285]
has been designed to expose network topological and cost information
to applications. In consequence, ALTO can an act as an off-path
mechanism for the purpose of exposing the impacts due to changes in
the routing of a network. In that case, the Off-path Information
Component in Figure 1 is realized by means of an ALTO Server.
Contreras Expires 23 April 2026 [Page 7]
Internet-Draft Off-path TVR October 2025
ALTO [RFC7285] provides topological-related information in the form
of both network and cost maps. The network map basically summarizes
the IP address ranges aggregated in each Provider-defined Identifier
(PID). Such IP addresses define either customers or service
functions attached to each network node. The cost map details the
topological relationship among PIDs in terms of a certain metric.
The basic metric provided is the routing cost among PIDs, but other
metrics can be also provided such as performance-related metrics
[RFC9439].
For the purpose of exposing future changes on the reachability
between PIDs in the network, ALTO defines in [RFC8896] a calendared
cost map (named ALTO cost calendar) which allows to signal future
changes on the cost metric. Thus, for a metric related to routing,
the cost calendar can expose scheduled modifications in the
connectivity between PIDs in a natural manner.
The ALTO cost calendar presents the information (i.e., metrics
between PIDs) in the form of JSON arrays, where each listed value
corresponds to a certain time interval. The ALTO cost calendar also
includes attributes to describe the time scope of the calendar. The
calendar provided by ALTO has the following attributes defined in
[RFC8896]:
* "Calendar-start-time", which indicates the date at which the first
value of the calendar applies.
* "Time-interval-size", that defines the duration of an ALTO
Calendar time interval in a unit of seconds.
* "Number-of-intervals", that indicates the number of values of the
cost calendar array.
* "Repeated", which is an optional attribute that indicates how many
iterations of the calendar value array have the same values.
In order to know about cheduled changes, two possibles strategies can
be in placed.
One strategy is to relay on centralized network control elements
populating scheduled changes to the ALTO server sufficiently in
advance as to calculate and expose the intended changes before them
are effectively activated in the network by the controllers. That
is, the introduction of changes is governed by the network controller
configuring dynamically the network elements (i.e., nodes, links)
following a planned set of actions. Such planned actions are the
ones fed to ALTO so that ALTO can create and expose updated
topological views for the scheduled modifications.
Contreras Expires 23 April 2026 [Page 8]
Internet-Draft Off-path TVR October 2025
A second strategy is to disseminate the scheduled changes by means of
the routing protocols in the network, so that the routing protocols
distribute the planned topological changes at link or node level. It
is worthy to note that a change distributed in this manner just by a
single node can motivate a cascade of some other scheduled changes in
different other nodes, thus representing potential stability issues
that should be addressed with care. Anyway, in certain environments
it can be suitable for signaling scheduled changes so that can serve
as basis for deriving from it the topological views to be exposed by
ALTO.
4.2. Other Off-path Mechanisms
While ALTO is a mature example, other off-path mechanisms may include
custom APIs exposing scheduled network data. Such APIs could be
supported by;
* Network Controllers, in case such controller is able to compute
and maintain the changes.
* Managing device, in charge of generating and maintaining the
schedules, or Schedule Database as defined in
[I-D.zdm-tvr-applicability].
5. Security and operational considerations
Same security and operational considerations as described in
[RFC8896] apply also in this document.
Apart from that, [I-D.ietf-tvr-requirements] describes relevant
security considerations for TVR solutions.
The off-path approach prevents some of those security issues, as the
ones requiring direct access to the source of information in risk,
like the time synchronization signals. However, some other threats
are of applicability, like the ones referring to the access to the
information, activity identification and privacy.
In order to mitigate such security risks, the off-path solution
should implement the necessary mechanisms for authentication, secure
data transfer and privacy preservation.
6. References
6.1. Normative References
Contreras Expires 23 April 2026 [Page 9]
Internet-Draft Off-path TVR October 2025
[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
"Application-Layer Traffic Optimization (ALTO) Protocol",
RFC 7285, DOI 10.17487/RFC7285, September 2014,
<https://www.rfc-editor.org/info/rfc7285>.
6.2. Informative References
[I-D.ietf-tvr-requirements]
King, D., Contreras, L. M., Sipos, B., and L. Zhang, "TVR
(Time-Variant Routing) Requirements", Work in Progress,
Internet-Draft, draft-ietf-tvr-requirements-07, 10 October
2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
tvr-requirements-07>.
[I-D.ietf-tvr-schedule-yang]
Qu, Y., Lindem, A., Kinzie, E., Fedyk, D., and M.
Blanchet, "YANG Data Model for Scheduled Attributes", Work
in Progress, Internet-Draft, draft-ietf-tvr-schedule-yang-
05, 4 July 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-tvr-schedule-yang-05>.
[I-D.irtf-nmrg-network-digital-twin-arch]
Zhou, C., Yang, H., Duan, X., Lopez, D., Pastor, A., Wu,
Q., Boucadair, M., and C. Jacquenet, "Network Digital
Twin: Concepts and Reference Architecture", Work in
Progress, Internet-Draft, draft-irtf-nmrg-network-digital-
twin-arch-11, 6 July 2025,
<https://datatracker.ietf.org/doc/html/draft-irtf-nmrg-
network-digital-twin-arch-11>.
[I-D.wqb-tvr-applicability]
Zhang, L., Ma, Q., Wu, Q., and M. Boucadair,
"Applicability of YANG Data Models for Scheduling of
Network Resources", Work in Progress, Internet-Draft,
draft-wqb-tvr-applicability-00, 10 September 2024,
<https://datatracker.ietf.org/doc/html/draft-wqb-tvr-
applicability-00>.
[I-D.zdm-tvr-applicability]
Zhang, L., Dong, J., and M. Boucadair, "Applicability of
TVR YANG Data Models", Work in Progress, Internet-Draft,
draft-zdm-tvr-applicability-04, 16 October 2025,
<https://datatracker.ietf.org/doc/html/draft-zdm-tvr-
applicability-04>.
[OPTIMAIX_repo]
"OPTIMAIX repository (https://github.com/OPTIMAIX)", n.d..
Contreras Expires 23 April 2026 [Page 10]
Internet-Draft Off-path TVR October 2025
[OPTIMAIX_video]
"Network Operation Demonstration
(https://www.youtube.com/channel/UC4_sduilyier-cA3-Xpir-
A)", December 2024.
[RFC7971] Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and
S. Previdi, "Application-Layer Traffic Optimization (ALTO)
Deployment Considerations", RFC 7971,
DOI 10.17487/RFC7971, October 2016,
<https://www.rfc-editor.org/info/rfc7971>.
[RFC8896] Randriamasy, S., Yang, R., Wu, Q., Deng, L., and N.
Schwan, "Application-Layer Traffic Optimization (ALTO)
Cost Calendar", RFC 8896, DOI 10.17487/RFC8896, November
2020, <https://www.rfc-editor.org/info/rfc8896>.
[RFC9439] Wu, Q., Yang, Y., Lee, Y., Dhody, D., Randriamasy, S., and
L. Contreras, "Application-Layer Traffic Optimization
(ALTO) Performance Cost Metrics", RFC 9439,
DOI 10.17487/RFC9439, August 2023,
<https://www.rfc-editor.org/info/rfc9439>.
[RFC9657] Birrane, III, E., Kuhn, N., Qu, Y., Taylor, R., and L.
Zhang, "Time-Variant Routing (TVR) Use Cases", RFC 9657,
DOI 10.17487/RFC9657, October 2024,
<https://www.rfc-editor.org/info/rfc9657>.
Appendix A. Assessment of ALTO as off-path solution against TVR
requirements
(Note: to be updated with [I-D.ietf-tvr-requirements] version -05 or
higher)
The Time Variant Routing requirements are being documented in
[I-D.ietf-tvr-requirements]. Despite that is yet a work in progress,
it is convenient to start an assessment of the off-path solution
provided by ALTO against the requirements expected to be supported by
any TVR-capable solution.
The following Table summarizes the assessment exercise. The
requirements are listed including the section (in brackets) of
[I-D.ietf-tvr-requirements] where they are defined.
Contreras Expires 23 April 2026 [Page 11]
Internet-Draft Off-path TVR October 2025
+===============================+===============================+
| Requirement | Compliance |
+===============================+===============================+
| (2.1) Resource scheduling | Feasible to reflect scheduled |
| | changes in a topology by means|
| | of a sequence of network and |
| | cost maps along the time |
+-------------------------------+-------------------------------+
| (2.2.1) Scope of Time- | Combines both time-invariant |
| Variability | and time-variant entities. |
| | Allows representation of |
| | global and individual changes |
+-------------------------------+-------------------------------+
| (2.2.2) Time Horizon | Specified by means of |
| | "time-interval-size" attribute|
| | expressed in seconds |
+-------------------------------+-------------------------------+
| (2.2.3) Time Precision | Determined in units of seconds|
| and Accuracy | |
+-------------------------------+-------------------------------+
| (2.2.4) Validity in a Schedule| Permits to accommodate |
| | multiple subsequent schedules |
+-------------------------------+-------------------------------+
| (2.2.5) Periodicity in a | Repetitive states specified |
| Schedule | by means of the attribute |
| | "repeated" |
+-------------------------------+-------------------------------+
| (2.2.6) Continuity in a | Governed by the |
| Schedule | "time-interval-size" attribute|
| | expressed in seconds |
+-------------------------------+-------------------------------+
| (2.2.7) Time-Overlap and | Not supported. It would |
| Priority | require extension of RFC8896 |
+-------------------------------+-------------------------------+
| (2.2.8) Property Value | Zero-order hold mode. Other |
| Interpolation | modes could be potentially |
| | supported |
+-------------------------------+-------------------------------+
| (2.2.9) Changes to Model | Support of fine-grained |
| State | changes |
+-------------------------------+-------------------------------+
| (2.3) Topologies | Schedules applicable to nodes |
| | and links. Support of |
| | potential future node or link |
| | connectivity |
+-------------------------------+-------------------------------+
| (2.4) Routing | Allows computation of |
| | TVR-enabled paths. Reported |
Contreras Expires 23 April 2026 [Page 12]
Internet-Draft Off-path TVR October 2025
| | constrains can be considered |
+-------------------------------+-------------------------------+
| (2.5) Integrity | Security considerations in |
| Considerations | both [RFC7285] and [RFC7971] |
| | apply in this case |
+-------------------------------+-------------------------------+
Appendix B. Assessment of the archietcture proposed in
[I-D.wqb-tvr-applicability]
(Note: to reconsider this section since [I-D.wqb-tvr-applicability]
already expired, and new version of the document in
[I-D.zdm-tvr-applicability] does not consider the same architecture)
[I-D.wqb-tvr-applicability] introduces an architecture for the
control scheduling of network resources, with two functional
components, namely the Scheduled Service Requester, in charge of
soliciting a resource schedule change, and the Scheduled Service
Responder, in charge of handling the scheduling orders. Such
architecture assumes the existence of funcitonal interfaces between
both comoponents.
Comparing such architecture with the one depicted in Figure 1, the
following mapping is possible, as represented in Figure 2.
Contreras Expires 23 April 2026 [Page 13]
Internet-Draft Off-path TVR October 2025
Network Operator (programming (impact
[ScheduleRequester]-----+ of scheduled estimation
| TVR changes) of scheduled
....................... V ............... TVR changes) ...
: [Schedule +-------------+ +--------------+ :
: Service | Network | | Network | :
: Responder] | Controller |<----->| Digital Twin | :
: +-------------+ +--------------+ :
: A ... | .............................:
: (feeding impacts | : | (activation
: of scheduled +------+ : +------+ of scheduled
: TVR changes) | : | TVR changes)
: | : |
: V : V
: +-------------+ : ,------._
: |Off-path Info| : ,-' `-.
: | Component | : / \
: +-------------+ : ( Network )
: A : \ /
:............. | .......: `-. ,-'
(exposure | `+------'
of scheduled | ^
TVR changes) | :
| (awareness :
| of scheduled v
| TVR changes) +-------------+
+------------->| Application |
+-------------+
[Schedule Consumer]
Figure 2. Schedule Requester, Responder and Consumer in the off-path
solution
From this assessment, it can be concluded that the roles of Schedule
Requester and Schedule Responder have its correspondance in the off-
path solution here described. However, the intended architecture in
[I-D.wqb-tvr-applicability] lacks of the role of Schedule Consumer
here described (or at least assumes that the Requester will be also
the Consumer, which cannot be necessarily the case).
Appendix C. Implementation status
The scenario proposed in Figure 1 has been implemented for the
validation of the off-path TVR approach using ALTO as off-path
mechanism. The use case to exercise the off-path solution considers
operational tasks in the network such as hardware and/or software
maintenance and upgrades. Such actions imply temporal topological
changes that can be anticipated since they are planned interventions
Contreras Expires 23 April 2026 [Page 14]
Internet-Draft Off-path TVR October 2025
in teh network. By leveraging on TVR, applications consuming the
network can be timnely informed of those changes in advanced,
permitting re-configurations and re-optimizations on the application
side minimizing negative impacts due to the foreseen changes.
A video demonstrating the scenario can be found in [OPTIMAIX_video].
The modules implementing the functionality have been released as open
source and are available at [OPTIMAIX_repo].
* Network Operation Center (NOC), developed by E-lighthouse. This
component is represented as the "Network Operator" in Figure 1.
It is in charge of requesting scheduled changes in the network.
* Net2plan_NDT, developed by E-lighthouse. This component is part
of the "Network Digital Twin" module in Figure 1. It is in charge
of performing advanced network simulations and reporting Key
Performance Indicator (KPI) evaluation consequence of the
topological changes.
* Change_Scheduler, devoloped by Telefónica. This component is part
of the "Network Controller" module in Figure 1. It is in charge
of receiving the topological changes requests, including the
intended execution time for the scheduled changes. It passess /
receive topological information and KPIs to / from Net2plan_NDT.
It is also in charge of triggering the execution of the network
chages at due time.
* ALTO_CostCalendar, developed by Telefónica. This component is
part of the "ALTO Server" module in Figure 1. It is in charge of
processing the predicted KPIs on the topology with the proposed
changes, and exposing those changes to external applications as an
example of off-path mechanism.
Appendix D. Identified gaps on TVR specifications
The work carried out for implementing the architecture in Figure 1
reveals some gaps.
* [I-D.ietf-tvr-schedule-yang] only provides granularity for
schedule changes at node and link level. However, operational
scenarios as the one described here can require further
granularity, as cards. A current workaround could be to count all
the interfaces of the same card, which can be onerous in some
cases (e.g., cards of 48 GigaEthernet ports).
* Advertisements of scheduled changes in distributed manner (that
is, on-path, directly using augmented routing protocols) can raise
conflicts. While conflicts are easy to be handled by centralized
Contreras Expires 23 April 2026 [Page 15]
Internet-Draft Off-path TVR October 2025
(i.e., off-path) solutions, it can require the definition of
arbitration mechanisms for the case of distributed (i.e., on-path)
ones.
* When distributed advertisements are in place, there are no means
defined for reverting planned changes other than reconfiguring and
launch new advertisements. Centralized approach simplifies the
evaluation of impacts, and then, facilitates the indetification of
potential problems that a planned change can cause. Distributed
means of distributed scheduled changes can require ways of easily
reverting proposed changes.
* When using distributed advertisement, the exposure of planned
changes to external parties or applications can be a security
problem, because the potential accessibility to internal
information beyond the topological changes. Secure ways of
accessing to that information can be needed to allow such use
cases.
Acknowledgements
This work has been partially funded by the Spanish Ministry of
Economic Affairs and Digital Transformation and the European Union -
NextGenerationEU under projects OPTIMAIX_OaaS (Ref. TSI-
063000-2021-34) and OPTIMAIX_NDT (Ref. TSI-063000-2021-35).
Author's Address
Luis M. Contreras
Telefonica
Ronda de la Comunicacion, s/n
28050 Madrid
Spain
Email: luismiguel.contrerasmurillo@telefonica.com
URI: http://lmcontreras.com
Contreras Expires 23 April 2026 [Page 16]
