<?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-00"
     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="25" month="July" year="2023"/>

    <workgroup>tvr</workgroup>

    <abstract>
      <t>This document makes some supplements for TVR's requirements.</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. <xref target="I-D.ietf-tvr-use-cases"/>.</t>

      <t>Recently, the document <xref target="I-D.kcs-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 Identification of Time-Variant Node and Non-Time-Variant Node">
        <t>In the usecase of Time-Variant Routing<xref
        target="I-D.ietf-tvr-use-cases"/>, there may be two types of network
        composition. One is composed entirely of Time-Variant Nodes. For
        example, the location of network nodes in LEO will change from time.
        The other is composed of Time-Variant Nodes and Non-Time-Variant
        Nodes. For example, some network nodes have different power supplies.
        Some network nodes can be continuously powered, while others may
        change over time. Therefore,</t>

        <t>o MUST provide a discovery and resolving methodology for the
        identification of Time-Variant Node and Non-Time-Variant Node.</t>
      </section>

      <section title="Support Different Advertisement Strategies for Time-Variant Node and Non-Time-Variant Node">
        <t>As mentioned in 3.1, in the application scenario of Time-Variant
        Routing, there may be two types of nodes in the network, namely
        Time-Variant Node and Non-Time-Variant Node. In TVR, the state
        information of nodes needs to be advertised in order to make routing
        decisions. Redundancy of information advertisement in the network is a
        typical problem. In the use case of Time-Variant Routing, the
        time-variant state information of network nodes will affect the
        routing decision. However, the change frequency of state information
        of time-variant nodes and non-time-variant nodes is inconsistent.
        Therefore,</t>

        <t>o MUST support different advertisement strategies for time-variant
        nodes and non-time-variant nodes, so as to reduce notification
        redundancy in the network.</t>
      </section>
    </section>

    <section anchor="Conclusion" title="Conclusion">
      <t>This document makes some supplements for TVR's requirements about
      support identification and different advertisement strategies for
      Time-Variant Node and Non-Time-Variant Node.</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.kcs-tvr-requirements"
?>

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

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