]> Viagenie

marc.blanchet@viagenie.ca

Routing Internet Engineering Task Force forwarding dtn tvr disruption 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.

Introduction 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. 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.

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

Forwarding 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.

• Packet memory store is full and a new packet is incoming.
• A destination becomes reachable by a new route entry in the forwarding table. Which stored packets should be forwarded first.
• A packet has expired. BP Bundles have lifetimes. IP packets have TTL (IPv4) or Hop Limit (IPv6). However, this specification does not change the behavior of IP packets when TTL or Hop Limit has a value of zero.
• The capability of storing packets for a forwarding node may be resource demanding, especially in scenarios where node resources are very limited, such as in space. Therefore, the forwarding node owner may want to have preference on which types of packets are stored or not. For example, the forwarding node may prefer by policy to store packets based on the source address, destination address, both addresses or various fields, such as Flow Label, Diffserv or else. Bundles also have various fields that may be used for such policies.
• When a packet needs to be dropped, an error should be sent back to the source. Both IP and BP has those error messages. However, in a constraint environment, error messages may be too costly to send back to source. Another case is when the packet is just "too" old to make an error message relevant to be sent. A policy may tell the forwarding node to not send error messages back to source when dropping packets.

Policies This section describes some policies that may be configured on the forwarding node.

Drop Policy 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.

• Drop oldest: The oldest packets are dropped. Error messages are sent to the source.
• Drop last from these sources. Keep the packets from these sources as long as possible: e.g. drop them after dropping all others, Sources are specified as a list of prefixes. Order in the list is relevant: first one in the list is the last one to drop.
• Drop last for these destinations. Keep the packets to this destination as long as possible: e.g. drop them after dropping all others. Destinations are specified as a list of prefixes. Order in the list is relevant: first one in the list is the last one to drop.
• Drop last if a field is set to a value. Keep the packets with the specified field having the specified value as long as possible: e.g. drop them after dropping all others

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.

• do not send error message: If packets are dropped, error messages are not sent to the source.
• send error message only if newer than x min/hour/day: If packets are dropped, error messages are sent to the source only if the timestamp of the packet is newer than the specified period from now.

Forwarding Preference Policy 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.

• Forward first from these sources: Start forwarding packets of this list of sources before forwarding others. Sources are specified as a list of prefixes. Order in the list is relevant: first one in the list is the first one to forward.
• Forward first for these destinations: Start forwarding packets of this list of destinations before forwarding others. Destinations are specified as a list of prefixes. Order in the list is relevant: first one in the list is the first one to forward.
• Forward first if a field is set to a value: Start forwarding packets with the specified field having the specified value.

TODO and Comments

• Information model in Yang to describe policies?
• Default route "policy": avoid sending packets back to Earth?
• weighted multiple concurrent policies?

IANA Considerations This memo includes no request to IANA.

Security Considerations TBD

References Normative References Informative References

Acknowledgements The following people have provided comments to improve this document: