Internet DRAFT - draft-ietf-tvr-requirements

draft-ietf-tvr-requirements







Network Working Group                                            D. King
Internet-Draft                                      Lancaster University
Intended status: Informational                           L. M. Contreras
Expires: 5 September 2024                                     Telefonica
                                                                B. Sipos
                                                                 JHU/APL
                                                            4 March 2024


                TVR (Time-Variant Routing) Requirements
                     draft-ietf-tvr-requirements-02

Abstract

   Time-Variant Routing (TVR) refers to the calculation of a path or
   subpath through a network where the time of message transmission (or
   receipt) is part of the overall route computation.  This means that,
   all things being equal, a TVR computation might produce different
   results depending on the time that the computation is performed
   without other detectable changes to the network topology or other
   cost functions associated with the route.

   This document introduces requirements where TVR computations could
   improve message exchange in a network.

About This Document

   This note is to be removed before publishing as an RFC.

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-ietf-tvr-requirements/.

   Discussion of this document takes place on the Time Variant Routing
   Working Group mailing list (mailto:tvr@ietf.org), which is archived
   at https://mailarchive.ietf.org/arch/browse/tvr/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/tvr/.

   Source for this draft and an issue tracker can be found at
   https://github.com/danielkinguk/tvr-requirements.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.







King, et al.            Expires 5 September 2024                [Page 1]

Internet-Draft              tvr-requirements                  March 2024


   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 5 September 2024.

Copyright Notice

   Copyright (c) 2024 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.  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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Overview of Time-Variant Networks . . . . . . . . . . . . . .   5
     3.1.  Resource Scheduling . . . . . . . . . . . . . . . . . . .   5
       3.1.1.  Schedule Visibility . . . . . . . . . . . . . . . . .   6
       3.1.2.  Generation Locality . . . . . . . . . . . . . . . . .   6
       3.1.3.  Execution Locality  . . . . . . . . . . . . . . . . .   7
     3.2.  General Temporality . . . . . . . . . . . . . . . . . . .   8
       3.2.1.  Scope of Time-Variability . . . . . . . . . . . . . .   8
       3.2.2.  Time Horizon  . . . . . . . . . . . . . . . . . . . .   9
       3.2.3.  Time Precision  . . . . . . . . . . . . . . . . . . .   9
       3.2.4.  Validity in a Schedule  . . . . . . . . . . . . . . .  10
       3.2.5.  Periodicity in a Schedule . . . . . . . . . . . . . .  10
       3.2.6.  Continuity in a Schedule  . . . . . . . . . . . . . .  10
       3.2.7.  Time-Overlap and Priority . . . . . . . . . . . . . .  11
       3.2.8.  Property Value Interpolation  . . . . . . . . . . . .  11
       3.2.9.  Changes to Model State  . . . . . . . . . . . . . . .  12
     3.3.  Topologies  . . . . . . . . . . . . . . . . . . . . . . .  12
       3.3.1.  Nodes . . . . . . . . . . . . . . . . . . . . . . . .  12
       3.3.2.  Termination Points  . . . . . . . . . . . . . . . . .  13



King, et al.            Expires 5 September 2024                [Page 2]

Internet-Draft              tvr-requirements                  March 2024


       3.3.3.  Links . . . . . . . . . . . . . . . . . . . . . . . .  13
       3.3.4.  Network Layering  . . . . . . . . . . . . . . . . . .  13
     3.4.  Routing . . . . . . . . . . . . . . . . . . . . . . . . .  14
       3.4.1.  Centralized . . . . . . . . . . . . . . . . . . . . .  14
       3.4.2.  Distributed . . . . . . . . . . . . . . . . . . . . .  14
       3.4.3.  Hybrid  . . . . . . . . . . . . . . . . . . . . . . .  15
       3.4.4.  Constraints . . . . . . . . . . . . . . . . . . . . .  15
   4.  Time-Variant Use Case Requirements  . . . . . . . . . . . . .  15
     4.1.  Operating Efficiency Use Case . . . . . . . . . . . . . .  15
   5.  Requirements Summary  . . . . . . . . . . . . . . . . . . . .  16
     5.1.  Support the Identification and Advertisement of Entity
           Property Changes  . . . . . . . . . . . . . . . . . . . .  16
     5.2.  Support Proxy Advertisement . . . . . . . . . . . . . . .  16
     5.3.  Support Identification and Classification of Node
           Properties  . . . . . . . . . . . . . . . . . . . . . . .  16
     5.4.  Support System Schedule and Time Interval Changes . . . .  17
     5.5.  Support Appropriate Time Accuracy . . . . . . . . . . . .  17
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  18
   References  . . . . . . . . . . . . . . . . . . . . . . . . . . .  18
     Normative References  . . . . . . . . . . . . . . . . . . . . .  18
     Informative References  . . . . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1.  Introduction


2.  Conventions and Definitions

   Specific terms used within this document are as follows:

   Model:  The universe being modeled, which defines a parameter space.

   Entity:  A single separable item within the model.  Each entity has a
      stable identity which is time-invariant.

   Property:  A single attribute of an entity which is used to
      parameterize that entity.  The notion of a property is not time-
      variant, the property always exists within an entity but its value
      may be time-variant.

   Property Value:  The specific value of a property, both as a planned
      state within the schedule timeline and as a realized state in
      wall-clock time.

   Schedule:  The method of parameterizing time-variance intrinsic to a




King, et al.            Expires 5 September 2024                [Page 3]

Internet-Draft              tvr-requirements                  March 2024


      time-variant model.  The parameters of a schedule are within the
      state space of the model.

   Schedule Time:  An idealized timeline within a time-variant model
      over which entities and property values may change without a
      difference of state in the model itself.  The notion of schedule
      time is intrinsic to the model.

   Wall-Clock Time:  The true timeline, measured in some time scale by
      some local ticker.  The notion of wall-clock time is extrinsic to
      the model; even non-time-variant models allow for changes over
      wall-clock time, just as different model states rather than a
      change _within_ the model itself.

   Time Instant:  A single instant of time, consistent with the concepts
      of date-time in [RFC3339].

   Timeline:  A possibly bounded interval of time, consistent with the
      concept of a period in [RFC3339].

   Subsequent:  A time instant which is later in a timeline than some
      reference time instant.

   Orchestrator:  The subsystem of a managing device which centralizes
      control of a network and applies policy to manage a network.  A
      Path Computation Element (PCE) is an example of an Orchestrator.

   Manager:  The subsystem in a managing device which operates a
      management protocol to control an Agent.

   Agent:  The subsystem in a managed device which operates a management
      protocol to be controlled by a Manager.

   (Routing) Application:  The subsystem of a managed device which
      performs the functions of a routing protocol and/or algorithm.
















King, et al.            Expires 5 September 2024                [Page 4]

Internet-Draft              tvr-requirements                  March 2024


            +--------------------+       +-------------------+
            |   Managing Device  |       |   Managed Device  |
            |                    |       |                   |
            |  +--------------+  |       |  +-------------+  |
            |  | Orchestrator |  |       |  | Application |  |
            |  +--------------+  |       |  +-------------+  |
            |         |          |       |         |         |
            |  +--------------+  |       |  +-------------+  |
            |  |    Manager   |  |---+---|  |     Agent   |  |
            |  +--------------+  |   :   |  +-------------+  |
            +--------------------+   :   +-------------------+
                                     :
                              +-------------+
                              |  Data Model |
                              +-------------+

                       Figure 1: Management Entities

3.  Overview of Time-Variant Networks

   Existing Internet routing techniques maintain end-to-end connected
   paths across a network.  Routing mechanisms exist to recover
   connectivity and resume normal traffic forwarding as the topology
   changes.  Occasionally, optimization of routes may also be requested,
   especially post-topology changes due to disruptive events.  However,
   there are a growing number of use cases where changes to the routing
   topology are an expected part of network operations.  In these
   scenarios, the pre-planned loss and restoration of an adjacency, or
   formation of an alternate adjacency, should be seen as a non-
   disruptive event.

   Time-Variant Routing (TVR) refers to calculating a path or subpath
   through a network where the time of message transmission (or receipt)
   is part of the overall route computation.  Therefore, a TVR
   computation might produce different results depending on the time
   that the calculation is performed without other detectable changes to
   the network topology or other cost functions associated with the
   route.

3.1.  Resource Scheduling

   Planned resource scheduling will be required for various scenarios;
   these include networks with mobile entities, such as crewless aerial
   vehicles and orbiting satellite constellations
   [I-D.ietf-tvr-use-cases].  In these scenarios, links are lost and re-
   established as a function of the mobility of the platforms.
   Furthermore, link activity might be restricted to certain times of
   the day in networks without reliable access to power, such as



King, et al.            Expires 5 September 2024                [Page 5]

Internet-Draft              tvr-requirements                  March 2024


   networks harvesting energy from tidal, wind, and solar resources.
   Similarly, network traffic might be planned around energy costs or
   expected user data volumes in networks prioritising green computing
   and energy efficiency over data rate.

3.1.1.  Schedule Visibility

   Because scheduled time-variance is not a part of exsting routing
   algorithms and managed data models, not all routing applications will
   be made to handle schedules as part of the routing parameters
   intrinsically.

   Two extremes of schedules being associated to routing data are:

   Intrinsic Schedule:  In this situation, the schedule is an intrinsic
      part of the managed data model which is visible to the routing
      application and used as part of the routing algorithms.  When the
      schedule is intrinsic, there is not necessarily the notion of a
      schedule being "executed" in wall-clock time because the time-
      varying parameters are ingested as part of the routing algorithms
      natural functioning.

   Extrinsic Schedule:  In this situation, the schedule is not part of
      the managed data proper but maintained within the Orchestrator;
      the routing application only sees the effects of changes in
      routing parameters as the schedule is executed (in wall-clock
      time) by the Agent.

   There is also the possibility of an intermediate situation where the
   schedule is still part of the managed data model but is visible only
   to, and executed in wall-clock time by, the management Agent.  This
   allows a more distributed use of scheduled data than centralizing its
   processing in an Orchestrator.

3.1.2.  Generation Locality

   The generation of a scheduled data model depends on collecting source
   data (which likely has some temporal information in it to begin
   with), choosing a time horizon to schedule within, and then
   processing the source data into an overall schedule.

   Two extremes for locality of schedule generation are:

   Centralized Generation:  In this situation, all schedule generation







King, et al.            Expires 5 September 2024                [Page 6]

Internet-Draft              tvr-requirements                  March 2024


      is centralized within a network Orchestrator and changes are sent
      to routing applications in wall-clock time via a management
      interface.  Even though the generation of the schedule is
      centralized, both the schedule visibility (within the data model)
      and the locality of how the schedule is executed are
      unconstrained.

      For example, a schedule could be generated in a central
      orchestrator synchronized to all managed devices which then
      execute the schedule in a distributed manner.

   Distributed Generation:  This situation corresponds with the
      Intrinsic or intermediate schedule visibility, where a schedule
      (with a potentially limited time horizon from what is known at the
      orchestrator) is part of the managed data which is distributed to
      managed devices to be handled either by the Agent or by the
      routing Application itself.

3.1.3.  Execution Locality

   Depending on the visibility of schedules within a data model (see
   Section 3.1.1) there are different options for where the schedule may
   be executed to ultimately affect a time-varying configuration on a
   managed device.

   Two extremes for locality of schedule execution are:

   Centralized Execution:  In this situation, all schedule execution is
      centralized within a network Orchestrator and changes are sent to
      routing applications in wall-clock time via a management
      interface.  This situation can apply to any type of schedule
      visibility, but only to centralized generation because the full
      scheduled data model needs to be available to the entity
      performing the execution.

   Distributed Execution:  In this situation, schedules are executed on
      each managed device independently but based on synchronized
      clocks.  This situation corresponds with the Intrinsic or
      intermediate schedule visibility, where a schedule (with a
      potentially limited time horizon from what is known at the
      Orchestrator) is part of the managed data which is distributed to
      managed devices to be handled either by the Agent or by the
      routing Application itself.








King, et al.            Expires 5 September 2024                [Page 7]

Internet-Draft              tvr-requirements                  March 2024


      When schedules are distributed to the managed devices, it
      necessarily increases the amount of data that the managing device
      needs to synchronize across the network.  The ratio of increased
      size can be mitigated by only distributing a limited time horizon
      to each device within a sliding window that moves forward in non-
      real-time.

   When schedules are both generated and executed centrally, there is a
   consistency risk between different managed devices because if one
   device fails to be reconfigured in wall-clock time its configuration
   will no longer align with the other devices which are supposed to all
   operate on the same schedule.  To recover from this kind of
   situation, either reattempts to configure the misaligned device can
   be made to bring it back into alignment with the other devices or the
   other devices' configurations must be rolled-back into consistency
   which will then cause all the devices to be off-schedule.

   When schedules are executed on each device, there is a risk that
   clocks on different devices become desynchronized beyond the time
   precision required of the schedule.  Because real-time clocks are
   necessary for more than just schedule execution, and because accurate
   and precise time sources exist outside of network time (_e.g._, GPS
   time) this risk can be made to have a low probability.

   With distributed execution there is also a risk that a manager loses
   connectivity with the managed device and the device eventually runs
   out of time horizon in the schedule which is known to it.  This risk
   can be mitigated by trading between the size and the horizon end-time
   of schedules distributed to managed devices.  This trade can be
   different for different devices, where some well-connected devices
   operate closer to just-in-time with short horizons while other
   devices can be given a longer horizon to allow it to execute in the
   absense of near-continuous manager connectivity.

3.2.  General Temporality

   This section covers different aspects of how temporality applies to
   any potential TVR information model.  Each aspect is roughly
   independent and informs how a model can choose to include temporality
   in its parameter space.

3.2.1.  Scope of Time-Variability

   One aspect of any time-varying model is the scope of what may be
   time-variable.  Two extremes of this aspect are:






King, et al.            Expires 5 September 2024                [Page 8]

Internet-Draft              tvr-requirements                  March 2024


   *  A model which is completely time-invariant, which while there is
      still a notion of time it has no affect on any of the model
      entities.

   *  A model in which every entity has some kind of schedule applied.

   It is expected that an application of time-variability to real world
   data models will keep some entities within the model time-invariant
   and allow scheduling of other, specific entities.

   Another aspect of any time-varying model is the granularity of state
   to which a schedule can be applied.  Two extremes of this aspect are:

   *  A model where one single schedule applies to the entire universe
      (_i.e._ indicating when the time-variant entities are valid or
      invalid).

   *  A model where every property of every entity can be scheduled
      independently.  This is the temporality model of [AIXM].

   It is expected that an application of time-variability to data models
   will fit within these extremes, possibly applying a schedule to each
   entity indicating when that entity is valid or invalid, or applying a
   schedule to groups of properties within the entity (while leaving
   other properties time-invariant).

3.2.2.  Time Horizon

   In an idealized model the schedules will apply indefinitely far in
   the past and the future, but in a realizable model with both
   processing and storage limitations there will need to be a time
   horizon within which the model applies and outside of which the model
   has no meaning.  In some cases this horizon will be intrinsic to the
   model itself, with an explicit model parameter indicating the
   horizon.  In other cases the model may allow indefinitely-large
   schedules but the processing of the planning timeline is bounded to
   limit resource needs.

3.2.3.  Time Precision

   Different time-variant models will require different granularities of
   planning time, either because of limitations or assumptions about
   wall-clock time or because of requirements within the modeled domain.
   It is up to specific models to define the precision of time values
   and the required accuracy and precison of wall-clocks which execute
   the schedules.





King, et al.            Expires 5 September 2024                [Page 9]

Internet-Draft              tvr-requirements                  March 2024


3.2.4.  Validity in a Schedule

   Within a single schedule over the planning timeline there will likely
   be a need to have multiple discrete intervals of validity over
   absolute schedule time.  The time instants at which a schedule is
   invalid indicate an undefined property value, so it is important for
   a model to be able to accomodate multiple schedules as necessary to
   ensure that some properties can have values at all times.

   A model which restricts itself to a single interval of validity could
   run into difficulties over a long enough time horizon and would need
   to resort to having multiple model entities represent the same
   modeled "thing" which can lead to confusion and inefficiency.

3.2.5.  Periodicity in a Schedule

   Separate from the concept of intervals of validity in absolute
   schedule time, there can be a need to model repetitive states in a
   concise way.  One way to model a periodic change of state is to
   combine a set of absolute time intervals with a periodic
   parameterization (duration valid and duration invalid); this is the
   mdoel of [AIXM].

   A model which does not include the notion of periodicy within a
   schedule could be used in situations where discrete intervals of
   validity are needed to handle periodic state changes which is neither
   storage nor processing efficient.

3.2.6.  Continuity in a Schedule

   A schedule which includes a sequence of time intervals needs to
   ensure that the interpretation of those intervals in the schedule
   timeline does not leave any "gaps" at the interval boundaries.  For
   that reason, it is important that the model uses half-open intervals
   of time so that time-adjacent intervals leave no gap.  In keeping
   with the terminology of [RFC3339], intervals are bounded by their
   "start" and "end" instants.  It is suggested that any time-varying
   model use schedules with intervals closed on their start time and
   open on their end time.  This behavior lends to the interpretation,
   in the schedule timeline, that the scheduled state takes effect at an
   interval's start and continues until the subsequent state.










King, et al.            Expires 5 September 2024               [Page 10]

Internet-Draft              tvr-requirements                  March 2024


3.2.7.  Time-Overlap and Priority

   In an ideal situation a model would be guaranteed by design to
   contain only contiguous and non-overlapping schedules for each time-
   variant scope.  In a realized model this kind of invaraint might not
   be enforcable or might lead to overly complex schedule structures.
   One way a model can handle this is to establish a concept of schedule
   priority, where some intervals of the schedule timeline contain
   overlapping schedules for the same properties and only the highest-
   priority schedule applies.  When priorities are allowed by a model,
   it enables the concept of an "overlay" where a long-duration state
   can be temporarilly (in schedule time) superseded by a short-duration
   state.

3.2.8.  Property Value Interpolation

   When a schedule is applied to an entity in a way which is more
   granular (Section 3.2.1) than just indicating when that whole entity
   is valid or invalid, the model needs to consider how individual
   properties are to be treated between scheduled instants.  Some of the
   possibile behaviors are:

   Zero-order hold:  From the instant a scheduled value applies to a
      property until the subsequent-in-schedule-time value supersedes
      it.  This is simple from a logical standpoint, but discontinuties
      in the value over schedule time could cause issues with the model
      itself.  For some models, though, the constant values between
      change instants are actually beneficial by allowing the entire
      timeline to be compressed into a sequence of discrete state-change
      instants.  This is the behavior implied in models such as [AIXM].

   Linear interpolation:  At the instants of time defined in the
      schedule the property takes the exact values, but between those
      instants the property is interpolated linearly over time.  This
      results in a state that is continuous over time, which is
      beneficial for some kinds of model but also means that there is no
      simple discrete sequence of states.

   Higher-order or spline interpolation:  Higher order interpolations
      can result in properties that vary over schedule time in ways that
      are more or less beneficial to different types of models.

   Regardless of the types of interpolation used, a model can choose to
   apply interpolation globally or per-property.  Since different
   properties represent different physical or logical metrics of a
   network it is expected that different types of interpolation will be
   needed for different represented quantities.




King, et al.            Expires 5 September 2024               [Page 11]

Internet-Draft              tvr-requirements                  March 2024


3.2.9.  Changes to Model State

   Separate from how a time-variant model can contain a schedule
   timeline within the model state, a model design will need to consider
   how changes to the model state itself (over wall-clock time) are
   handled.  This aspect is actually not specific to a time-variant
   model but is important to consider in this context.

   Two extremes of this aspect are:

   *  A model which can only be changed wholesale, superseded by an
      entire new model state.  This is easy to keep consistent but has
      inefficiences of storage and transport if the model state is to be
      shared or exchanged between real entities.

   *  A model which has an intrinsic notion of fine-grained superseding
      changes, possibly scoped to individual entities, individual
      schedules, or more complex groupings.

3.3.  Topologies

   The primary entities of a topological network model, as realized in
   [RFC8345] and similar predecessors, are nodes and unidirectional
   links, with a secondary entity representing the "termination point"
   for each side of a link at a node.  Following the concepts described
   in Section 3.1 these are the entities to which an intrinsic schedule
   can be applied.

3.3.1.  Nodes

   When a schedule is applied to a node the granularity could at least
   be at the individual node.  In cases where the properties of a node
   have time-variable values the model may define an interpolation
   method, either globally or per-property.

   A node is just a named entity in Layer 3 [RFC8346] and Layer 2
   [RFC8944] topologies.  Schedules on a node could be used to indicate
   the validity of the entire node or changing properties of that
   entity.  When a schedule indicates that a node is not valid for a
   schedule time instant, that validity could apply to all of its
   termination points and links as well.  This logic allows a schedule
   to represent, for example, the expected power-on state of a node at a
   specific layer.








King, et al.            Expires 5 September 2024               [Page 12]

Internet-Draft              tvr-requirements                  March 2024


3.3.2.  Termination Points

   When a schedule is applied to a termination point the granularity
   should at least be at the individual entity.  In cases where the
   properties of a termination point have time-variable values the model
   may define an interpolation method, either globally or per-property.

   A termination point is associated with an IP address in Layer 3
   [RFC8346] and a MAC address in Layer 2 [RFC8944] topologies.
   Schedules on a termination point could be used to indicate the
   validity of the layer-2/3 interface represented by the entity or
   changing properties of that entity.  When a schedule indicates that a
   termination point is not valid for a schedule time instant, that
   validity may apply to all of its links as well.  This logic allows a
   schedule to represent, for example, the expected power-on or
   administrative-enabled state of an attached network interface card
   (NIC) or virtual private network (VPN) endpoint.

3.3.3.  Links

   When a schedule is applied to a link the granularity should at least
   be at the individual link.  In cases where the properties of a link
   have time-variable values the model should define an interpolation
   method, either globally or per-property.

   A link is associated with link metric properties in Layer 3 [RFC8346]
   and Layer 2 [RFC8944] topologies.  Schedules on a link should be used
   to indicate the validity of the entire link or changing properties of
   that entity.  When a schedule indicates that a link is not valid for
   a schedule time instant, that validity should not apply to its
   termination points and nodes.  This logic allows a schedule to
   represent, for example, the expected connectivity state, data
   throughput/rate, and latency/delay of a link.

3.3.4.  Network Layering

   When a schedule indicates that an entity is not valid for a schedule
   time instant, that validity should not apply to any of its associated
   overlay or underlay network entities.  The effects of scheduled
   administrative disabling or enabling of an entity at one layer do not
   imply a change in administrative enabled state at any other layer.
   Likewise, the assigning of an address property at one layer does not
   imply the presence or absence of an address assignment at that same
   time instant for any other layer.







King, et al.            Expires 5 September 2024               [Page 13]

Internet-Draft              tvr-requirements                  March 2024


3.4.  Routing

   Traditional network routing techniques typically use link bandwidth
   and delay for path calculation, and do not consider time-based
   factors.  TVR should be capable of improving network performance and
   reliability in environments where entities liveness and link
   availability is a time-based consideration, with various factors,
   including power availability, interface line of sight or expected
   demand.

   However, even if some adjacency failures are predictable, others are
   not, including link failures and entity outages.  Therefore, any new
   technique or routing protocol extension for TVR enviroments must be
   capable of handling planned and unexpected resource losses.

   Time-Variant Routing (TVR) introduces a scenario of calculating a
   path, or sub-path within a network, taking into account the timing of
   message transmission or receipt as an integral part of the overall
   route computation.

   Furthermore, Synchronization of network time across TVR-capable
   entities is critical in TVR networks.

   Three scenarios are currently considered when computing TVR-enabled
   paths.

3.4.1.  Centralized

   The network entities will receive the time variable information and
   traffic forwarding rules directly from a logically centralized
   source, an Orchestrator.  The time variable data may then be
   processed locally by the entity entered into the scheduled routing
   table and specific forwarding rules applied.

3.4.2.  Distributed

   Network entities may participate in a routing scheme where time
   variable information is propagated through the network via capability
   and variability advertisements.  This could be achieved using
   extensions to existing routing schemes and techniques so that link,
   adjacency, cost, and schedule may be considered when making
   forwarding decisions for per-hop packets or calculating traffic
   engineered end-to-end paths.  It should be noted that schedule
   distribution and entity computation latency may exist in some network
   environments.






King, et al.            Expires 5 September 2024               [Page 14]

Internet-Draft              tvr-requirements                  March 2024


   In some enviroments scheduling information may distributed through a
   management plane mechanism, such as NETCONF or gnmi, instead of the
   routing scheme.

3.4.3.  Hybrid

   In this scenario, mixed-entity TVR capability exists.  Some entities
   will require a schedule provided by a centralized source, and others
   will be capable of advertising and learning scheduled information via
   a distributed mechanism.

   This scenario presents time and schedule synchronization and source
   verification challenges and will require further study.

3.4.4.  Constraints


   // TBD

4.  Time-Variant Use Case Requirements

   Several TVR use cases have been identifed and discussed in
   [I-D.ietf-tvr-use-cases].  This section provides further detail on
   specific requirements to meet use case needs.

4.1.  Operating Efficiency Use Case

   Several operational efficiency requirements exist; these include:

   1.  Distribution of Predicted Topology-change.  The predicted
       topology-change information may include the valid time, invalid
       time, link costs at different times, and change periods.

   2.  Topology Changes.  The predicted topology-change information may
       change due to forecasted or unforecasted changes.  The managing
       entity should be capable of providing a partial or full topology
       update as often as needed.

   3.  The Minimum Route Recalculation Interval and Threshold.  Although
       some cases may assume that the cost persists for a sufficient
       amount of time, considering that each route contains multiple
       links, the change frequency of the path may be much higher than
       the cost.  In this case, the minimum recalculation interval or
       cost change threshold is needed to determine when a route
       recalculation is required.  Of course, scheduled topology
       connection changes must be considered when path calculation is
       required.




King, et al.            Expires 5 September 2024               [Page 15]

Internet-Draft              tvr-requirements                  March 2024


5.  Requirements Summary

5.1.  Support the Identification and Advertisement of Entity Property
      Changes

   In Time-Variant Routing, scheduling of availible entity resources is
   expected is expected.  In practical situations, however, the
   properties of entities can be converted back and forth between Time-
   Variant and Non-Time-Variant nodes.

   An entity must support the identification and advertisement of non-
   scheduled property changes.

   Besides, if there are abnormal changes in the system, it is necessary
   to advertise them through the existing routing protocols in time to
   achieve the stability of Time-Variant Routing and avoid redundant
   advertisements.  For example, an entity in the system is suddenly
   damaged due to external factors.  Changes in entity state outside of
   a schedule are communicated to other entities in a network through
   existing routing protocol mechanims, where they exist.

   A manager should provide an advertisement methodology for responding
   to abnormal changes in the system.

5.2.  Support Proxy Advertisement

   Proxies can help to improve the efficiency of the network.  There are
   some entities in the network that do not have routing functions.
   When their properties change, they are unable to notify other
   entities in the network.  Proxy nodes can help nodes without routing
   functions to advertise information, thus improving the efficiency of
   the network.  Therefore,

   o Must support proxy entities to help non-routing nodes implement
   information advertisement.

5.3.  Support Identification and Classification of Node Properties

   The entity properties of the network may change as described in 3.1.
   If the system cannot timely identify and classify in a processing
   manner after the entity properties change, it will lead to suboptimal
   routing decisions.  Therefore,

   o Must provide a discovery and resolving methodology for the
   identification and classification of entity schedule changes.






King, et al.            Expires 5 September 2024               [Page 16]

Internet-Draft              tvr-requirements                  March 2024


5.4.  Support System Schedule and Time Interval Changes

   The system's schedule may change, requiring entity configuration
   updates instead it being set once and not being able to be modified.
   Additionally, time-variant intervals in the system may also vary.
   Therefore,

   o Must support system schedule changes.

   o Must support time interval changes.

5.5.  Support Appropriate Time Accuracy

   The accuracy of the time cannot be too large or too small; otherwise,
   convergence may not be possible.  Therefore,

   o Must support appropriate time tolerance.

6.  Security Considerations

   The security implications for networks using time-variant routing
   mechanisms must also be considered.  Several potential security
   implications will need careful investigation, these include:

   *  Denial-of-Service (DoS) attacks: Malicious actors could manipulate
      or disrupt the time information shared within the network, leading
      to issues with routing protocols and potentially causing DoS
      attacks.  This could impact the network's ability to function
      properly and deliver services to entities.

   *  Traffic analysis and route prediction: Predicting network
      activity: By analyzing the shared time information, attackers
      could potentially predict network activity patterns and routing
      decisions.  This information could be used to launch targeted
      attacks or plan disruptions.

   *  Identifying user activity: In some scenarios, precise time
      information might be linked to specific user or device activity or
      network usage patterns.  This could raise privacy concerns if not
      properly anonymized or protected.

   *  Spoofing and manipulation: Fake or manipulated time information
      could be injected into the network, leading to incorrect routing
      decisions and disruptions.  This could be used to redirect
      traffic, launch man-in-the-middle attacks, or gain unauthorized
      access to resources.





King, et al.            Expires 5 September 2024               [Page 17]

Internet-Draft              tvr-requirements                  March 2024


7.  IANA Considerations

   This document has no IANA actions.

Contributors

   The following authors contributed significantly to this document:


      Jing Wang
      China Mobile
      China
      Email: wangjingjc@chinamobile.com

      Peng Liu
      China Mobile
      China
      Email: liupengyjy@chinamobile.com

      Li Zhang
      Huawei
      China
      Email: zhangli344@huawei.com

      Zheng (Sandy) Zhang
      ZTE Corporation
      China
      Email: zhang.zheng@zte.com.cn

      Yuehua Wei
      ZTE Corporation
      China
      Email: wei.yuehua@zte.com.cn


References

Normative References

   [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
              Progress, Internet-Draft, draft-ietf-tvr-use-cases-09, 29
              February 2024, <https://datatracker.ietf.org/doc/html/
              draft-ietf-tvr-use-cases-09>.

Informative References




King, et al.            Expires 5 September 2024               [Page 18]

Internet-Draft              tvr-requirements                  March 2024


   [AIXM]     EUROCONTROL and Federal Aviation Administration, "AIXM 5
              Temporality Model", 15 September 2010,
              <https://aixm.aero/sites/aixm.aero/files/imce/AIXM51/
              aixm_temporality_1.0.pdf>.

   [I-D.contreras-tvr-alto-exposure]
              Contreras, L. M., "Using ALTO for exposing Time-Variant
              Routing information", Work in Progress, Internet-Draft,
              draft-contreras-tvr-alto-exposure-03, 27 February 2024,
              <https://datatracker.ietf.org/doc/html/draft-contreras-
              tvr-alto-exposure-03>.

   [I-D.hou-tvr-satellite-network-usecases]
              Dongxu, H., Min, X., Zhou, F., and D. Yuan, "Satellite
              Network Routing Use Cases", Work in Progress, Internet-
              Draft, draft-hou-tvr-satellite-network-usecases-02, 14
              September 2023, <https://datatracker.ietf.org/doc/html/
              draft-hou-tvr-satellite-network-usecases-02>.

   [I-D.king-tvr-ntn-challanges]
              King, D. and K. Shortt, "Time Variant Challenges for Non-
              Terrestrial Networks", Work in Progress, Internet-Draft,
              draft-king-tvr-ntn-challanges-00, 17 January 2023,
              <https://datatracker.ietf.org/doc/html/draft-king-tvr-ntn-
              challanges-00>.

   [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
              Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
              <https://www.rfc-editor.org/info/rfc3339>.

   [RFC8345]  Clemm, A., Medved, J., Varga, R., Bahadur, N.,
              Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
              Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
              2018, <https://www.rfc-editor.org/info/rfc8345>.

   [RFC8346]  Clemm, A., Medved, J., Varga, R., Liu, X.,
              Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model
              for Layer 3 Topologies", RFC 8346, DOI 10.17487/RFC8346,
              March 2018, <https://www.rfc-editor.org/info/rfc8346>.

   [RFC8944]  Dong, J., Wei, X., Wu, Q., Boucadair, M., and A. Liu, "A
              YANG Data Model for Layer 2 Network Topologies", RFC 8944,
              DOI 10.17487/RFC8944, November 2020,
              <https://www.rfc-editor.org/info/rfc8944>.

Authors' Addresses





King, et al.            Expires 5 September 2024               [Page 19]

Internet-Draft              tvr-requirements                  March 2024


   D. King
   Lancaster University
   Email: d.king@lancaster.ac.uk


   L. M. Contreras
   Telefonica
   Email: luismiguel.contrerasmurillo@telefonica.com


   B. Sipos
   JHU/APL
   Email: brian.sipos+ietf@gmail.com






































King, et al.            Expires 5 September 2024               [Page 20]