TVR L. M. Contreras
Internet-Draft Telefonica
Intended status: Informational 27 February 2024
Expires: 30 August 2024
Using ALTO for exposing Time-Variant Routing information
draft-contreras-tvr-alto-exposure-03
Abstract
Network operations can require time-based, scheduled changes in
nodes, links, adjacencies, etc. All those changes can alter the
connectivity in the network in a predictable manner, which is known
as Time-Variant Routing (TVR). Existing IETF solutions like ALTO can
assist, as an off-path mechanism, on the exposure of such predicted
changes to both internal and external applications then anticipating
the occurrence of routing changes. This document describes how ALTO
helps in that purpose.
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 30 August 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Contreras Expires 30 August 2024 [Page 1]
Internet-Draft ALTO for TVR February 2024
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. Capabilities of ALTO for exposing information . . . . . . . . 4
2.1. ALTO exposed information . . . . . . . . . . . . . . . . 4
2.2. Mechanism for anticipating routing changes in ALTO . . . 4
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
4. Assessment of ALTO as off-path solution against TVR
requirements . . . . . . . . . . . . . . . . . . . . . . 6
5. Security and operational considerations . . . . . . . . . . . 7
6. Informative References . . . . . . . . . . . . . . . . . . . 7
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
There can be operational situations 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 documented in
[I-D.ietf-tvr-use-cases]. Those predictable changes can be scheduled
either from a higher-level system (e.g., OSS) or from a Network
Controller.
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
that applications (both internal and external) can become aware of
those routing variations along time.
Contreras Expires 30 August 2024 [Page 2]
Internet-Draft ALTO for TVR February 2024
Current IETF solutions like ALTO [RFC7285] have been conceived for
exposing topological information with associated metrics. In
consequence, ALTO can be perceived as a suitable piece allowing to
expose the impacts due to changes in the routing of a network.
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
+--------+ ,------._
| ALTO | ,-' `-.
| Server | / \
+--------+ ( Network )
A \ /
| `-. ,-'
(exposure | `+------'
of scheduled | ^
TVR changes) | :
| (awareness :
| of scheduled v
| TVR changes) +-------------+
+------------->| Application |
+-------------+
Figure 1. Potential architecture using ALTO for TVR
ALTO can act as an off-path mechanism for exposing scheduled
topological changes. It permits different strategies at the time of
working with time-based topological variations due to changes
affecting nodes, links, adjacencies, or metrics.
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 topological changes
before those changes are effectively activated in the network by the
Contreras Expires 30 August 2024 [Page 3]
Internet-Draft ALTO for TVR February 2024
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.
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.
2. Capabilities of ALTO for exposing information
2.1. ALTO exposed information
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].
Because of the possibility of incorporating additional metrics and a
variety of topological information, ALTO can be considered as a
generic IETF network exposure function [I-D.contreras-alto-ietf-nef].
2.2. Mechanism for anticipating routing changes in ALTO
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.
Contreras Expires 30 August 2024 [Page 4]
Internet-Draft ALTO for TVR February 2024
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.
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 ALTO retrieves 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 to be defined for representing the
scheduled changes can be the same, so representing the changing
topological events in a similar way. An example of a potential data
model representing scheduled changes is proposed in
[I-D.united-tvr-schedule-yang]. A model like that could serve the
same purpose 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 the ALTO server, so that the
ALTO server can calculate the future topological map (in terms of
network and cost maps provided by ALTO). Alternatively, if the
network controller has the means of doing so, the network controller
could even pass the future topology to ALTO. In any case, with the
different topological representations, ALTO can expose the current
and future views in a time-based manner leveraging on the cost
calendar feature.
Contreras Expires 30 August 2024 [Page 5]
Internet-Draft ALTO for TVR February 2024
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, as suggested in
[I-D.taylor-tvr-prb-stmt]. If that is the case, ALTO can participate
of the network routing information by listening to IGPs and/or
peering with BGP speakers, as described in [RFC7971].
4. Assessment of ALTO as off-path solution against TVR requirements
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.
+===============================+===============================+
| Requirement | Compliance |
+===============================+===============================+
| (3.1) Resource scheduling | Feasible to reflect scheduled |
| | changes in a topology by means|
| | of a sequence of network and |
| | cost maps along the time |
+-------------------------------+-------------------------------+
| (3.2.1) Scope of Time- | Combines both time-invariant |
| Variability | and time-variant entities. |
| | Allows representation of |
| | global and individual changes |
+-------------------------------+-------------------------------+
| (3.2.2) Time Horizon | Specified by means of |
| | "time-interval-size" attribute|
| | expressed in seconds |
+-------------------------------+-------------------------------+
| (3.2.3) Time Precision | Determined in units of seconds|
+-------------------------------+-------------------------------+
| (3.2.4) Validity in a Schedule| Permits to accommodate |
| | multiple subsequent schedules |
+-------------------------------+-------------------------------+
| (3.2.5) Periodicity in a | Repetitive states specified |
| Schedule | by means of the attribute |
| | "repeated" |
Contreras Expires 30 August 2024 [Page 6]
Internet-Draft ALTO for TVR February 2024
+-------------------------------+-------------------------------+
| (3.2.6) Continuity in a | Governed by the |
| Schedule | "time-interval-size" attribute|
| | expressed in seconds |
+-------------------------------+-------------------------------+
| (3.2.7) Time-Overlap and | Not supported. It would |
| Priority | require extension of RFC8896 |
+-------------------------------+-------------------------------+
| (3.2.8) Property Value | Zero-order hold mode. Other |
| Interpolation | modes could be potentially |
| | supported |
+-------------------------------+-------------------------------+
| (3.2.9) Changes to Model | Support of fine-grained |
| State | changes |
+-------------------------------+-------------------------------+
| (3.3) Topologies | Schedules applicable to nodes |
| | and links. Support of |
| | potential future node or link |
| | connectivity |
+-------------------------------+-------------------------------+
| (3.4) Routing | Allows computation of |
| | TVR-enabled paths |
+-------------------------------+-------------------------------+
5. Security and operational considerations
Same security and operational considerations as described in
[RFC8896] apply also in this document.
6. Informative References
[I-D.contreras-alto-ietf-nef]
Contreras, L. M., "Considering ALTO as IETF Network
Exposure Function", Work in Progress, Internet-Draft,
draft-contreras-alto-ietf-nef-01, 11 July 2022,
<https://datatracker.ietf.org/doc/html/draft-contreras-
alto-ietf-nef-01>.
[I-D.ietf-tvr-requirements]
King, D., Contreras, L. M., and B. Sipos, "TVR (Time-
Variant Routing) Requirements", Work in Progress,
Internet-Draft, draft-ietf-tvr-requirements-01, 23 October
2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
tvr-requirements-01>.
[I-D.ietf-tvr-use-cases]
Birrane, E. J., Kuhn, N., Qu, Y., Taylor, R., and L.
Zhang, "TVR (Time-Variant Routing) Use Cases", Work in
Contreras Expires 30 August 2024 [Page 7]
Internet-Draft ALTO for TVR February 2024
Progress, Internet-Draft, draft-ietf-tvr-use-cases-06, 24
February 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-tvr-use-cases-06>.
[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, "Digital Twin
Network: Concepts and Reference Architecture", Work in
Progress, Internet-Draft, draft-irtf-nmrg-network-digital-
twin-arch-04, 23 October 2023,
<https://datatracker.ietf.org/doc/html/draft-irtf-nmrg-
network-digital-twin-arch-04>.
[I-D.taylor-tvr-prb-stmt]
Taylor, R., "Time Variant Routing Problem Statement", Work
in Progress, Internet-Draft, draft-taylor-tvr-prb-stmt-00,
24 October 2022, <https://datatracker.ietf.org/doc/html/
draft-taylor-tvr-prb-stmt-00>.
[I-D.united-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-united-tvr-schedule-
yang-00, 11 October 2023,
<https://datatracker.ietf.org/doc/html/draft-united-tvr-
schedule-yang-00>.
[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>.
[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>.
Contreras Expires 30 August 2024 [Page 8]
Internet-Draft ALTO for TVR February 2024
[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>.
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 30 August 2024 [Page 9]