| Internet-Draft | Abbreviated Title | October 2023 |
| Zhang & Wu | Expires 19 April 2024 | [Page] |
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.¶
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 19 April 2024.¶
Copyright (c) 2023 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.¶
This draft was submitted as [I-D.zw-tvr-igp-extensions].¶
[I-D.ietf-tvr-use-cases] and [I-D.ietf-tvr-requirements] 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.¶
-----------------------------------------------------
| Satellite Network |
| |
| ---------------- ---------------- |
----| Satellite R1 |------------| Satellite R2 |-----
---------------- ----------------
| |
| |
| |
------------------- -------------------
----| Ground Station1 |---------| Ground Station2 |----
| ------------------- ------------------- |
| |
| |
| Ground Network |
-------------------------------------------------------
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.¶
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.¶
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 [RFC2119].¶
TBD.¶
The predictable and scheduled changes can be looked as a net of new constrains which defined in [RFC9350]. The new constrains are advertised as new sub-tlvs.¶
A new type of Metric-Type is defined for time variant in IS-IS FAD sub-TLV which defined in section 5.1 [RFC9350] and OSPF FAD sub-TLV which defined in section 5.2 [RFC9350].¶
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:¶
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric1 |
| Time-slot1-begin |
| Time-slot1-end |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric2 |
| Time-slot2-begin |
| Time-slot2-end |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
. . .
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric[m] |
| Time-slot[m]-begin |
| Time-slot[m]-end |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The handling follows the definition in [RFC9350], 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.¶
The document requests new allocations from the IANA registries as follows:¶
IANA is requested to allocate a new code points from the "IGP Metric-Type" registry.¶
| Type | Description | Reference |
|---|---|---|
| TBD1 | Time Variant metric | This Document |
IANA is requested to allocate a new code points from the "IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV" registry.¶
| Type | Description | Reference |
|---|---|---|
| TBD2 | Time Variant | This Document |
IANA is requested to allocate a new code points from the "OSPF Flexible Algorithm Definition TLV Sub-TLVs" registry.¶
| Type | Description | Reference |
|---|---|---|
| TBD3 | Time Variant | This Document |
This document does not introduce more security consideration than [RFC9350].¶