| Internet-Draft | Forwarding in context of TVR | March 2023 |
| Blanchet | Expires 14 September 2023 | [Page] |
Some networks, such as in space, have links that are up and down based on a known schedule. In this context, IP Packets or Bundle Protocol Bundles should then be saved locally until the destination becomes reachable again. This document describes forwarding node policies regarding how to manage the local store as well as forwarding decisions. This specification applies to both IP packets or Bundle Protocol bundles.¶
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 14 September 2023.¶
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.¶
Some networks, such as in space, have links that are up and down based on a known schedule. In this context, IP Packets or Bundle Protocol Bundles should then be saved locally until the destination becomes reachable again. This document describes forwarding node policies regarding how to manage the local store as well as forwarding decisions. This specification applies to both IP packets or Bundle Protocol [RFC9171] bundles.¶
For easier reading, this document will use the word "packet" to encompass both IP packets and Bundle Protocol bundles.¶
In typical IP forwarding engines, if the route for a destination does not exist, a forwarding engine would drop the packet and then return an ICMP Unreachable Error Message to the source of the packet. This specification describes an atypical behavior of IP forwarding engines.¶
Bundles of the Bundle Protocol are defined for the purpose of store and forward, therefore it is a normal behavior to store the bundles until reachability is possible.¶
This document was written mostly based on Bundle Protocol implementations that are targetted for space networks. It was then generalized for IP. The IP behavior may be underspecified or inadequately specified for the first versions of this document.¶
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.¶
If the destination is unreachable, the packet is not discarded and therefore saved in memory. Whether volatile or non-volatile is an implementation decision. The packet should be saved with a timestamp to be used by policies described in this document.¶
When a new route is installed, or in general when the forwarding table has changed, then saved packets are parsed, and those that can be sent are sent, in order of the preference policy discussed below. How saved packets are parsed is implementation decision. For example, an implementation may index saved packets based on destination prefixes, so that the lookup is fast.¶
Policies are needed to guide the forwarding engine when the following events happen.¶
This section describes some policies that may be configured on the forwarding node.¶
When the packet memory store is full and space is needed such as a new packet is incoming, the drop policy comes into effect. It may also happen by other reasons, such as an asynchronous "garbage collection" process. The drop policy may be one (TBD: or many? with weights?) of the following.¶
An additional characteristic of the drop policy is related to the error messages when dropping a packet. The following list the possible error messages policies that may be added to any of the above drop policies. If no error message policy is added, then the default error message behavior from the respective stacks (IP or BP) are used.¶
When a destination becomes reachable by a new route in the forwarding table, the forwarding node may need to prefer starting sending some packets instead of others, for various reasons. For example, in a "short" time window of reachability, some packets or destinations may be preferred over others. In bandwidth limited links, control plane packets may be preferred to be sent first over data or telemetry or large media. The forwarding preference policy may be one of the following.¶
This memo includes no request to IANA.¶
The following people have provided comments to improve this document:¶