<?xml version='1.0' encoding='utf-8'?>
<!-- This template is for creating an Internet Draft using xml2rfc,
    which is available here: http://xml.resource.org. -->
<?xml-model href="rfc7991bis.rnc"?>  <!-- Required for schema validation and schema-aware editing -->
<!-- <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> -->
<!-- This third-party XSLT can be enabled for direct transformations in XML processors, including most browsers -->

<rfc
      xmlns:xi="http://www.w3.org/2001/XInclude"
      category="std"
      docName="draft-zw-lsr-tvr-extensions-01"
      ipr="trust200902"
      obsoletes=""
      updates=""
      submissionType="IETF"
      xml:lang="en"
      tocInclude="true"
      tocDepth="4"
      symRefs="true"
      sortRefs="true"
      version="3">
  <!-- xml2rfc v2v3 conversion 2.38.1 -->
  <!-- category values: std, bcp, info, exp, and historic
    ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
       or pre5378Trust200902
    you can add the attributes updates="NNNN" and obsoletes="NNNN" 
    they will automatically be output with "(if approved)" -->

 <!-- ***** FRONT MATTER ***** -->

 <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
        full title is longer than 39 characters -->

   <title abbrev="Abbreviated Title">IS-IS and OSPF extensions for TVR (Time-Variant Routing) </title>
    <seriesInfo name="Internet-Draft" value="draft-zw-lsr-tvr-extensions-01"/>
    <!-- add 'role="editor"' below for the editors if appropriate -->

   <!-- Another author who claims to be an editor -->

   <author fullname="Zheng Zhang" initials="Z" surname="Zhang">
      <organization>ZTE Corporation</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->

         <city></city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <phone></phone>
        <email>zhang.zheng@zte.com.cn</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>
    
    <author fullname="Haisheng Wu" initials="H" surname="Wu">
      <organization>ZTE Corporation</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->

         <city></city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <phone></phone>
        <email>wu.haisheng@zte.com.cn</email>
        <!-- uri and facsimile elements may also be added -->
      </address>
	 </author>
	 
	 <author fullname="Jing Wang" initials="J" surname="Wang">
      <organization>China Mobile</organization>
      <address>
        <postal>
          <street>No.32 XuanWuMen West Street</street>
          <!-- Reorder these if your country does things differently -->

          <city>Beijing</city>
          <region/>
          <code>100053</code>
          <country>China</country>
        </postal>
        <phone></phone>
        <email>wangjingjc@chinamobile.com</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>
    
    <date year="2024"/>
    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
        in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->

   <!-- Meta-data Declarations -->

   <area>Routing</area>
    <workgroup>TVR</workgroup>
    <!-- WG name at the upperleft corner of the doc,
        IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
        which is used by the RFC Editor as a nod to the history of the IETF. -->

   <keyword>TVR IGP extensions</keyword>
    <!-- Keywords will be incorporated into HTML output
        files in a meta tag but they have no effect on text or nroff
        output. If you submit your draft to the RFC Editor, the
        keywords will be used for the search engine. -->

   <abstract>
      <t>TVR needs IGP to calculate different results depending on the time, without convergence after the detection of link or nodes. 
	  IGP nodes need to learn the predictable and scheduled changes in advance. 
	  This document defines the IGP extensions for predictable and scheduled changes of TVR.</t>
    </abstract>
  </front>
  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
      <t>This draft was submitted as <xref target="I-D.zw-tvr-igp-extensions" format="default"/>.</t>
	  <t><xref target="I-D.ietf-tvr-use-cases" format="default"/> and <xref target="I-D.ietf-tvr-requirements" format="default"/> 
	  describe a new challenge for non-terrestrial networks. In these networks, there are predictable and scheduled changes of link or nodes. 
	  The affected nodes which connected the changing link or node advertise the changes after finding the changes. 
	  After convergence all the nodes calculate a new routing table. But for the predictable and scheduled changes, 
	  the nodes can advertise the changes and do the calculation in advance to reduce the convergence time.</t>

        <figure anchor="tvr1">
        <artwork align="left" name="Figure 1" type="" alt=""><![CDATA[
   -----------------------------------------------------
   |                 Satellite Network                 |
   |                                                   |
   |   ----------------            ----------------    |
   ----| Satellite R1 |------------| Satellite R2 |-----
       ----------------            ----------------
              |                            |
              |                            |
              |                            |
      -------------------         -------------------
  ----| Ground Station1 |---------| Ground Station2 |----
  |   -------------------         -------------------   |
  |                                                     |
  |                                                     |
  |                    Ground Network                   |
  -------------------------------------------------------
           ]]></artwork>
      </figure>      
      
      <t>For example, in Figure 1, The groud station 1/2 connects the Satellite. Because of the satellite movement, 
	  the metric between satellite and ground station changes over time. Because the movement is periodic, 
	  the metric is changed periodically. Regardless the unexpected situation like bad weather, 
	  the metric variation is predicable and scheduled. 
	  The groud station 1/2 advertises the predicable and scheduled metric variation to the ground network. 
	  Then the nodes in the ground network can learn the scheduled metric and calculate the routing table in advance.</t>
      
      <t>This document defines the a set of extensions to IS-IS, OSPFv2 and OSPFv3 for predictable and scheduled changes of TVR. 
	  These extensions can be advertised by the node self which has predictable and scheduled changes, 
	  or by the node which connected or adjacenct to the node which has predictable and scheduled changes.</t>
	  
	  <t>This document helps the implementation of Intrinsic schedule defined in section 3.1.1 in <xref target="I-D.ietf-tvr-requirements" format="default"/>. 
	  And the schedule based on Flex Algorithm can solve the time overlap mentioned in section 3.2.7 in <xref target="I-D.ietf-tvr-requirements" format="default"/>. 
	  The schedule in different FA may be overlapped, but the constrain-based routing calculation will not be affected.</t>

      <section numbered="true" toc="default">
        <name>Requirements Language</name>
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
       "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
       document are to be interpreted as described in <xref target="RFC2119" format="default"/>.</t>
      </section>
    </section>
    
    <section numbered="true" toc="default">
      <name>Terminology</name>
      <t>TBD.</t>
    </section>
    
    <section numbered="true" toc="default">
      <name>Time Variant Algorithm</name>
      <t>The predictable and scheduled changes can be looked as a set of new constrains which defined in <xref target="RFC9350" format="default"/>. 
	  The new constrains are advertised as new sub-tlvs.</t>
    </section>
    
    <section numbered="true" toc="default">
      <name>Time Variant sub-TLVs of IS-IS and OSPF FAD Sub-TLV</name>
      <t>A new type of Metric-Type is defined for time variant in IS-IS FAD sub-TLV which defined in section 5.1 <xref target="RFC9350" format="default"/> 
	  and OSPF FAD sub-TLV which defined in section 5.2 <xref target="RFC9350" format="default"/>.</t>
      <t>A new Time Variant sub-TLV is advertised as a sub-TLV of IS-IS FAD sub-TLV and OSPF FAD sub-TLV. The Time Variant sub-TLV has following formats:</t>
      
        <figure anchor="tvr-sub-tlv">
        <artwork align="left" name="Figure 2" type="" alt=""><![CDATA[
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |    Length     | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Recurrence-type                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Metric1                              |
   |                       Time-slot1-begin                        |
   |                       Time-slot1-end                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Metric2                              |
   |                       Time-slot2-begin                        |
   |                       Time-slot2-end                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               .                               |
   .                               .                               .
   |                               .                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Metric[m]                            |
   |                       Time-slot[m]-begin                      |
   |                       Time-slot[m]-end                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ]]></artwork>
      </figure>
        
        <dl newline="true" spacing="normal" indent="8">
        <dt>Type: 1-octet. TBD (To be assigned by IANA).</dt>
        <dd></dd>
        <dt>Length: 1-octet. The number of the set of metric and time-slot.</dt>
        <dd></dd>
		<dt>Recurrence-type: 4-octet. The schedule repetitiveness.</dt>
        <dd></dd>
        <dt>Metric: 4-octet. The metric value of specific time slot. The value of 0xffffffff indicates unreachable.</dt>
        <dd></dd>
        <dt>Time-slot-begin: 4-octet. The begin time of this time-slot.</dt>
        <dd></dd>
        <dt>Time-slot-end: 4-octet. The end time of this time-slot.</dt>
        <dd></dd>
        </dl> 
    </section>
    
   
    <section numbered="true" toc="default">
      <name>Handling of the time variant sub-TLV</name>
      <t>The handling follows the definition in <xref target="RFC9350" format="default"/>, 
	  except one or more timers are scheduled for different time-slot carried in time variant sub-tlv. 
	  When a scheduled time-slot is coming, the associated routing table needs to be calculated with the associated metric.</t>
	  <t>When the Recurrence-type in the time variant sub-TLV is set, the routing table needs to be calculated repeatedly. 
	  During the time which is not covered by the time-slot, the default metric is suggested to be used for routing calculation.</t>
    </section>
    
    <section anchor="IANA" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>The document requests new allocations from the IANA registries as follows:</t>
      <section numbered="true" toc="default">
      <name>IGP Metric-type Registry</name>
      <t>IANA is requested to allocate a new code points from the "IGP Metric-Type" registry.</t>
        <table anchor="TABLE_1" align="center">
          <name>IGP Metric-Type</name>
          <thead>
            <tr>
              <th align="center">Type</th>
              <th align="center">Description</th>
              <th align="center">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">TBD1</td>
              <td align="center">Time Variant metric</td>
              <td align="center">This Document</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section numbered="true" toc="default">
      <name>IS-IS Registry</name>
      <t>IANA is requested to allocate a new code points from the "IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV" registry.</t>
        <table anchor="TABLE_2" align="center">
          <name>IS-IS TVR sub-TLV</name>
          <thead>
            <tr>
              <th align="center">Type</th>
              <th align="center">Description</th>
              <th align="center">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">TBD2</td>
              <td align="center">Time Variant</td>
              <td align="center">This Document</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section numbered="true" toc="default">
      <name>OSPF Registry</name>
      <t>IANA is requested to allocate a new code points from the "OSPF Flexible Algorithm Definition TLV Sub-TLVs" registry.</t>
        <table anchor="TABLE_3" align="center">
          <name>OSPF TVR sub-TLV</name>
          <thead>
            <tr>
              <th align="center">Type</th>
              <th align="center">Description</th>
              <th align="center">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">TBD3</td>
              <td align="center">Time Variant</td>
              <td align="center">This Document</td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
    <section anchor="Security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This document does not introduce more security consideration than <xref target="RFC9350" format="default"/>.</t>
    </section>
	
	<section title="Acknowledgements"> 
    <t>TBD.</t>
   </section>
  </middle>
  <!--  *****BACK MATTER ***** -->

 <back>

   <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <?rfc include="reference.RFC.2119.xml"?>	
        <?rfc include="reference.RFC.9350.xml"?>
      </references>
      <references title="Informative References">
	    <?rfc include="reference.I-D.ietf-tvr-use-cases.xml"?>
        <?rfc include="reference.I-D.ietf-tvr-requirements.xml"?>
		<?rfc include="reference.I-D.zw-tvr-igp-extensions.xml"?>		
    </references>
    </references>
 </back>
</rfc>
