| Internet-Draft | tvr-requirements | July 2023 |
| Wang & Liu | Expires 26 January 2024 | [Page] |
This document makes some supplements for TVR's requirements.¶
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 26 January 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.¶
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. [I-D.ietf-tvr-use-cases].¶
Recently, the document [I-D.kcs-tvr-requirements] gave some TVR's requirements about general temporality , and this document makes some supplements for TVR's requirements.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Considering requirements for TVR (Time-Variant Routing) in the following aspects¶
In the usecase of Time-Variant Routing[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,¶
o MUST provide a discovery and resolving methodology for the identification of Time-Variant Node and Non-Time-Variant Node.¶
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,¶
o MUST support different advertisement strategies for time-variant nodes and non-time-variant nodes, so as to reduce notification redundancy in the network.¶
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.¶
TBD.¶