<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.13 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC4760 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4760.xml">
<!-- ENTITY USECASES PUBLIC ''
      'https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-geng-rtgwg-cfn-dyncast-ps-usecase-00.xml'-->
]>
<?rfc compact="yes"?>
<?rfc text-list-symbols="o*+-"?>
<?rfc subcompact="no"?>
<?rfc sortrefs="no"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<rfc category="info" docName="draft-wang-tvr-requirements-consideration-01"
     ipr="trust200902" submissionType="IETF">
  <front>
    <title abbrev="tvr-requirements">Consideration for TVR (Time-Variant
    Routing) Requirements</title>

    <author fullname="Jing Wang" initials="J." surname="Wang">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street>No.32 XuanWuMen West Street</street>

          <city>Beijing</city>

          <code>100053</code>

          <country>China</country>
        </postal>

        <email>wangjingjc@chinamobile.com</email>
      </address>
    </author>

    <author fullname="Peng Liu" initials=" P." surname="Liu">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street>No.32 XuanWuMen West Street</street>

          <city>Beijing</city>

          <code>100053</code>

          <country>China</country>
        </postal>

        <email>liupengyjy@chinamobile.com</email>
      </address>
    </author>

    <date day="26" month="September" year="2023"/>

    <workgroup>tvr</workgroup>

    <abstract>
      <t>This document makes some supplements to TVR's requirements, including
      advertisement, identification, classification of node attributes, and
      appropriate system settings.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="introduction" title="Introduction">
      <t>Existing routing protocols are expected to maintain end-to-end
      connected paths across a network. There are cases where the end-to-end
      path can not be maintained, such as the loss of an adjacent peer. In
      these cases, corrections could be applied prior to the resumption of
      data transmission. Corrections may include attempting to re-establish
      lost adjacencies and recalculating or rediscovering a functional
      topology.</t>

      <t>There were three use cases had been defined in the TVR's use case
      document <xref target="I-D.ietf-tvr-use-cases"/>. The first is resource
      preservation; one example of a network where nodes must perform resource
      preservation is an energy-harvesting, wireless sensor network. The
      second is operating efficiency; one example of a network where nodes
      might seek to optimize operating cost is a set of nodes operating over
      cellular connections that charge both On-Peak and Off-Peak data rates.
      The third is mobile devices; some examples of this use case are
      vehicle-to-vehicle communications, Low Earth Orbit (LEO) networked
      constellation (LEO-NC), and so on.</t>

      <t>Recently, the document <xref target="I-D.ietf-tvr-requirements"/>
      gave some TVR's requirements about general temporality , and this
      document makes some supplements for TVR's requirements.</t>
    </section>

    <section anchor="conventions-and-definitions" title="Conventions">
      <t>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
      <xref format="default" target="RFC2119"/> <xref format="default"
      target="RFC8174"/> when, and only when, they appear in all capitals, as
      shown here.</t>
    </section>

    <section title="Requirements">
      <t>Considering requirements for TVR (Time-Variant Routing) in the
      following aspects</t>

      <section title="Support the Identification and Advertisement of Node Attribute Changes">
        <t>In Time-Variant Routing, scheduling of the system are as expected.
        In practical situations, however, the attributes of nodes can be
        converted back and forth between Time-Variant and Non-Time-Variant
        nodes. For example, a mobile phone can be considered a
        Non-Time-Variant node in the network when charging. After unplugging
        the power cord, it can be considered a Time-Variant-Node because it
        starts to be powered by batteries.</t>

        <t>o MUST support the identification and advertisement of node
        attribute changes.</t>

        <t>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, a node in the system is
        suddenly damaged due to external factors. Therefore,</t>

        <t>o Should provide a advertisement methodology for responding to
        abnormal changes in the system.</t>
      </section>

      <section title="Support Agent Node Advertisement">
        <t>Agent nodes can help to improve the efficiency of the network.
        There are some nodes in the network that do not have routing
        functions. When their attributes change, they are unable to notify
        other nodes in the network. Agent nodes can help nodes without routing
        functions to advertise information, thus improving the efficiency of
        the network. Therefore,</t>

        <t>o MUST support agent nodes to help non-routing nodes implement
        information advertisement.</t>
      </section>

      <section title="Support Identification and Classification of Node Attributes">
        <t>The node attributes of the network may change as described in 3.1.
        If the system cannot timely identify and classify in a processing
        manner after the node attributes change, it will lead to suboptimal
        routing decisions. Therefore,</t>

        <t>o MUST provide a discovery and resolving methodology for the
        identification and classification of node attributes.</t>
      </section>

      <section title="Support System Schedule and Time Interval Changes">
        <t>The system's schedule may change, requiring of to be reconfigured
        instead it being set once and not being able to be modified.
        Additionally, time-variant intervals in the system may also vary.
        Therefore,</t>

        <t>o MUST support system schedule changes.</t>

        <t>o MUST support time interval changes.</t>
      </section>

      <section title="Support Appropriate Time Accuracy">
        <t>The accuracy of the time cannot be too large or too small;
        otherwise, convergence may not be possible. Therefore,</t>

        <t>o MUST support appropriate time accuracy.</t>
      </section>
    </section>

    <section anchor="Conclusion" title="Conclusion">
      <t>This document makes some supplements to TVR's requirements.</t>
    </section>

    <section anchor="security-considerations" title="Security Considerations">
      <t>TBD.</t>
    </section>

    <section anchor="iana-considerations" title="IANA Considerations">
      <t>TBD.</t>
    </section>
  </middle>

  <back>
    <references title="Informative References">
      <?rfc include="reference.I-D.ietf-tvr-use-cases"?>

      <?rfc include="reference.I-D.ietf-tvr-requirements"
?>

      <?rfc include="reference.RFC.2119.xml"?>

      <?rfc include="reference.RFC.8174.xml"
?>
    </references>
  </back>
</rfc>
