Bundle Transfer Protocol - Unidirectional

Status of This Memo

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 29 August 2025.¶

Copyright Notice

Copyright (c) 2025 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.¶

Table of Contents

1. Introduction

Bundle Protocol version 7 (BPv7) is defined in terms a layered logical architecture, detailed in [RFC9171], wherein the responsibility for the storing and routing of bundles lies with the Bundle Processing Agent (BPA), and the BPA relies upon Convergence Layer Adaptors (CLAs) to provide bundle transport between nodes. CLAs provide a unified interface to the BPA, allowing BPAs to be link-layer agnostic, but still use a diverse range of underlying link-layer protocols to transfer bundles between BPAs.¶

In the realm of near- and deep-space communication there are a number of standardized link-layer protocols, including [USLP], [TM], [AOS], [DVB-S2X], that share a set of common properties:¶

• They are unidirectional: data transfer occurs in one direction only, there is no in-band return path for data.¶

• They are frame-based: the link-layer protocol will guarantee that a frame of data is either delivered to the receiver in its entirety or not at all. Frames may be of fixed or variable length.¶

• They are point-to-point: although the medium over which the data transfer occurs may be broadcast in nature, the link-layer protocol provides an uncontested point-to-point communication channel between a single sender and a single receiver.¶

These characteristics provide a common baseline that allows the definition of a lightweight protocol for transferring BPv7 bundles meeting the requirements of a BPv7 CLA, and this document describes such a protocol, Bundle Transfer Protocol - Unidirectional (BTPU), suitable for implementation over any link-layer protocol that shares these characteristics. The protocol is applicable to other link-layer technologies which share these characteristics beyond those commonly used for space communication, for example 5G Unstructured PDUs [_5G], or [IEEE.802.3], without requiring underlying IP services.¶

The driving use-case of the protocol has been the transfer of BPv7 formatted Bundles, however it is equally capable of transferring any kind of binary data, but includes no explicit discriminator of the type of a particular Bundle. If multiple different types of Bundle are to be transferred by a single implementation, this specification considers the differentiation between different Bundle types to be a matter for the implementation. For example, both BPv6 ([RFC5050]) formatted Bundles and BPv7 Bundles can be multiplexed without issue, as the different formats can be distinguished by simple examination of the initial octets of a received Bundle by an implementation. Additionally, the segmentation mechanism enables the use of this protocol with Bundle formats that do not support some form of fragmentation.¶

Although designed for any link-layer protocol that shares the characteristics defined in Section 1, additional specification or profiling may be required to map the constructs of the link-layer protocol to the mechanisms defined in this specification.¶

+----------------------+
|  DTN Application     |
+----------------------+
|  BPv7 / BPv6         |
+----------------------+
|  BTPU               |
+----------------------+
|  Link-layer Protocol |
+----------------------+

2. Conventions and Definitions

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

3. Protocol Overview

The purpose of the protocol is to transfer a series of Bundles between two nodes. Because a Bundle is of variable length, which is unlikely to be exactly the same size as a Link-layer PDU, the protocol defines a mechanism to divide Bundles into Segments as required, such that each Link-layer PDU is efficiently filled with data, and one or more Bundles can be transferred in a minimal number of Link-layer PDUs, described in more detail in Section 4.¶

This segmentation is unrelated to BPv7 bundle fragmentation as defined in Section 5.8 of [RFC9171]. Although BPv7 bundle fragmentation may be used to sub-divide oversized BPv7 bundles, the required duplication of metadata blocks can result in inefficiencies or fail to generate BPv7 bundle fragment small enough to fit in a single Link-layer PDU.¶

As a sender may prioritize the transfer of each Bundle differently, the protocol allows for the multiplexing of Bundle transfers, so that the transfer of higher priority Bundles may interrupt the transfer of other Bundles, avoiding "head of line blocking", see Section 4.1 for more detail.¶

4. Segmentation and Transfers

As described in the Protocol Overview (Section 3), in order to transfer Bundles larger than a single Link-layer PDU into multiple PDUs, Bundles are be divided into a sequence of Segments by the sender and each Segment is emitted in its own a Message. However, if a complete Bundle can fit in the next Link-layer PDU, then the Bundle SHOULD be transferred without segmentation, see the Bundle Message (Section 7.1).¶

Each Segment is assigned a monotonically increasing integral sequence number, starting at zero (0). In addition to a sequence number, every Segment is associated with a Transfer that provides context to the sequence of Segments to enable the correct reassembly of the original Bundle. Each Transfer is assigned a number as an identifier, with each identified Transfer mapping to the segmentation of a single Bundle.¶

The transfer of a sequence of Segments of a Bundle a sender MUST be emitted via a sequence of Transfer Segment Messages (Section 7.2) carrying the same Transfer identifier. The end of a sequence of Segments MUST be indicated by emitting a Transfer End Message (Section 7.3), including the final Segment and the identifier of the Transfer that is now complete.¶

The receiver reassembles the transferred Bundle by concatenating the Segments that share a common Transfer number in the order of their sequence number. When all the Segments have been received and concatenated, the receiver is assumed to pass the recombined Bundle to an upper layer for further processing.¶

Transfer numbers are encoded using 32-bit unsigned integers. A sending implementation SHOULD choose a random value between 0 and 2^32-1 for the first Transfer number, and each subsequent Transfer MUST use the next numeric value in the sequence. To avoid placing a limit on the total number of Transfers between peers, numbers are allowed to "roll-over" via zero and repeat, i.e. the next number in the sequence is the previous number incremented by one, modulo 2^32.¶

5. Transfer Window

Because Messages may be lost in transmission due to the loss of Link-layer PDUs, and a sender may emit duplicate Messages as a defense against loss, see Section 6, a sender MUST maintain a sliding Transfer Window that defines the maximum number of Transfers that can be simultaneously in progress. As Transfers are identified by a monotonically increasing number, the size of the Transfer Window also strictly defines the range of identifiers of Transfers in progress.¶

The sender MUST maintain a reference to the greatest Transfer number used in any emitted Message, and MUST NOT emit any Message with a Transfer number less than or equal to the latest minus the size of the Transfer Window, taking into account the modulo 2^32 roll-over.¶

The receiver MUST maintain a reference to the greatest Transfer number received in any Message. When a Transfer Message is received with a Transfer number greater than the greatest previously received, the new Transfer number is considered the greatest Transfer number, and Transfers with number less than or equal to the latest minus the size of the Transfer Window MUST be considered Section 4.2. Because of Transfer number roll-over, half the number space of 2^32 and window size is used to determine if a number is older or newer than the latest Transfer number. Pseudocode for the algorithm is given in Figure 2.¶

The size of the Transfer Window SHOULD be the same at both receiver and sender, and MUST be configured via some out-of-band mechanism. The Transfer Window size MUST be at least 4, MUST be less than 2^12, and is RECOMMENDED to be 16. These are entirely arbitrary numbers, and need discussing by the WG.¶

const WINDOW_SIZE  # Configured transfer window size
var GREATEST = NIL # Greatest received transfer number, initially NIL

# Function to check if a transfer is valid within the current window
FUNCTION isTransferValid(T):
    # Ensure Transfer T is within the
    #  sliding window defined by WINDOW_SIZE
    RETURN ((GREATEST - T + 2^32) MOD 2^32) < WINDOW_SIZE

# Function to check if the transfer is considered a "new" transfer
FUNCTION isNewTransfer(T):
    IF GREATEST IS NIL THEN
        # The first transfer is always considered new
        RETURN TRUE
    # Check if the transfer is within the valid window range
    #  (half of the number space + window size)
    RETURN ((T - GREATEST + 2^32) MOD 2^32) <
                     (2^32 / 2) + (WINDOW_SIZE / 2)

# Main function to process a transfer and manage the sliding window
FUNCTION processTransfer(T):
    IF isNewTransfer(T) THEN
        # New transfer, update the greatest received transfer number
        GREATEST ← T
        # Cancel transfers that are now outside the window
        CANCEL_OUTDATED_TRANSFERS()
    ELSE IF isTransferValid(T) THEN
        # Transfer is in progress, continue handling it
        CONTINUE_PROCESSING(T)
    ELSE
        # Transfer is invalid (outside the window), ignore it
        IGNORE_MESSAGE(T)

6. Handling Link-layer PDU Loss

Due to the unreliable nature of the link-layer protocol, Link-layer PDUs may be lost in transmission, resulting in the loss of the contained Messages. Because the underlying link-layer is assumed to be unidirectional, the protocol does not include a mechanism to trigger the retransmission of lost Messages; instead the protocol allows the sender to repeat the transmission of Messages.¶

A sender MAY emit any Message multiple times in different Link-layer PDUs. Although every Link-layer PDU transmitted may contain different Messages, any repeated Message MUST be an exact copy of an already emitted Message. When segmenting bundles, not all Messages in a Transfer need be repeated the same number of times, and different Transfers may repeat Messages differently.¶

Although it is RECOMMENDED that Transfer Segment Messages (Section 7.2) are emitted in ascending order of sequence number; once emitted, any Message MAY be repeated any number of times, in any order. The number of repetitions of a particular Message is an implementation matter that can be influenced by many factors, including:¶

• Offline analysis of the deployed environment may require a certain amount of Message repetition to reach some required certainty of transfer.¶

• A higher 'reliability' factor associated with a particular Bundle may result in more copies of each associated Transfer Message being emitted.¶

• Signalling from the link-layer protocol, or some other out-of-band mechanism, may trigger increased repetition of a subset Messages, to protect against some temporary spike in Link-layer PDU loss rate.¶

The provided protection mechanisms are logically separate from any facilities the underlying link-layer protocol may have to protect against information loss through redundancy and erasure coding, and may be used as required by a deployment. If a link-layer protocol receives a duplicate transmission frame, it SHOULD be delivered to this protocol only once.¶

7. Message Definitions

All protocol Messages except the Indefinite Padding Message (Section 7.6) follow the common "Type-Length-Value" formatting pattern, with each Message being identified by a four octet header that encodes the type of the Message, and the length of the content of the Message.¶

 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 (24-bit unsigned integer)              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       ... Content ...                         :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type:

The type of the Message, allocated from IANA "BTPU Message Types" registry, see Section 10, expressed as a 8-bit unsigned integer in network byte order.¶

Length:

The length of the Message in octets, excluding the 4 octets of the header itself, expressed as a 24-bit unsigned integer in network byte order.¶

Content:

A sequence of octets of data of variable length determined by the corresponding Length field value, encoded according to the type of the Message.¶

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transfer Number                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment Sequence Number                                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    ... Segment Data ...                       :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transfer Number                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment Sequence Number                                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    ... Segment Data ...                       :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transfer Number                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Type          |
+-+-+-+-+-+-+-+-+

8. Security Considerations

This protocol does not define any measures to protect Messages or their content. Although there may be link-layer mechanisms to protect the transmission of frames against over-hearing and interference, transport-layer security is considered out of scope for the protocol. Mechanisms such as BPSec, defined in [RFC9172], MUST be used to provide integrity and protection at the Bundle layer as required.¶

9. Deployment Considerations

The following caveats should be considered before deploying instances of this protocol:¶

1. It is unreliable. Although there may be a link-layer protocol mechanism for a receiver to be notified that a frame has been lost in transmission, due to the unidirectional nature of the link-layer there is no in-band return path suitable for higher-layer acknowledgement of transfer success. Any acknowledgement system designed to provide reliability MUST use a logically separate path from receiver back to sender.¶

2. It does not provide congestion control or signalling. The underlying link-layer is expected to provide an uncontested point-to-point channel, and hence such mechanisms are considered to be out of scope. The protocol MUST NOT be deployed in environments where congestion may occur, such as the public Internet, when the underlying link-layer, or a higher layer, does not provide suitable congestion control.¶

3. It requires an out-of-band mechanism for configuration. This can either be via pre-placed static configuration, a parallel dynamic control-plane protocol, or some other mechanism beyond the scope of this specification.¶

10. IANA Considerations

IANA is requested to create a new registry entitled "BTPU Message Types". The registration policy for this registry, using terms defined in [RFC8126], is:¶

The initial values for the registry are:¶

11. References

Appendix A. Examples

+---------------------------+------------+-----------------+
| Bundle A                  | Bundle B   | Bundle C        |
+---------------------------+------------+-----------------+

:                           :            :                 :

+----------------------+----+------------+----+------------+---------+
| Transfer 1           | T1 |  Complete  | T2 | Transfer 2 | Padding |
| Segment 0            | S1 |  Bundle    | S0 | Segment 1  |         |
+----------------------+----+------------+----+------------+---------+

:                      :                      :                      :

+----------------------+----------------------+----------------------+
| Link-layer PDU N     | Link-layer PDU N + 1 | Link-layer PDU N + 2 |
+----------------------+----------------------+----------------------+

        +---------------------------+
        | Bundle B                  |  High Priority
        +---------------------------+
+--------------+-----------------+
| Bundle A     | Bundle C        |     Low Priority
+--------------+-----------------+


+----------------------+------------+----+----+------------+---------+
| T1    | Transfer 2   | Transfer 2 | T1 | T3 | Transfer 3 | Padding |
| S0    | Segment 0    | Segment 1  | S1 | S0 | Segment 1  |         |
+----------------------+------------+----+----+------------+---------+

:                      :                      :                      :

+----------------------+----------------------+----------------------+
| Link-layer PDU N     | Link-layer PDU N + 1 | Link-layer PDU N + 2 |
+----------------------+----------------------+----------------------+

Appendix B. Acknowledgments

TODO acknowledge.¶

EK, Brian Sipos & TCPCL authors, Chloe He¶

Author's Address