Delay/Disruption Tolerant Networking R. Taylor
Internet-Draft Aalyria Technologies
Intended status: Standards Track 16 March 2025
Expires: 17 September 2025
Bundle Transfer Protocol - Unidirectional
draft-taylor-dtn-btpu-01
Abstract
This document defines a protocol for the unidirectional transfer of
large binary objects, typically Bundle Protocol version 7 bundles,
between two nodes connected by a unidirectional, unreliable, frame-
based link-layer protocol, without requiring IP services.
The protocol does not require a return path for acknowledgements, but
instead supports data repetition as a mechanism to protect against
data loss. It fully supports the disaggregation of flows of bundles
of different priority, preventing head-of-line blocking impacting
performance.
The binary wire format of the protocol is designed to enable
performant implementation in hardware or software, with the aim of
enabling protocol implementations to run at the line-rate of the
underlying link-layer protocol.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://ricktaylor.github.io/btpu/draft-taylor-dtn-btpu.html. Status
information for this document may be found at
https://datatracker.ietf.org/doc/draft-taylor-dtn-btpu/.
Discussion of this document takes place on the Delay/Disruption
Tolerant Networking Working Group mailing list (mailto:dtn@ietf.org),
which is archived at https://mailarchive.ietf.org/arch/browse/dtn/.
Subscribe at https://www.ietf.org/mailman/listinfo/dtn/.
Source for this draft and an issue tracker can be found at
https://github.com/ricktaylor/btpu.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Taylor Expires 17 September 2025 [Page 1]
Internet-Draft BTPU March 2025
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 17 September 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Messages . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Segmentation and Transfers . . . . . . . . . . . . . . . . . 7
4.1. Interleaving Transfers . . . . . . . . . . . . . . . . . 8
4.2. Cancelling Transfers . . . . . . . . . . . . . . . . . . 8
5. Transfer Window . . . . . . . . . . . . . . . . . . . . . . . 8
6. Handling Link-layer PDU Loss . . . . . . . . . . . . . . . . 9
7. Message Definitions . . . . . . . . . . . . . . . . . . . . . 10
7.1. Bundle Message . . . . . . . . . . . . . . . . . . . . . 11
7.2. Transfer Segment Message . . . . . . . . . . . . . . . . 11
7.3. Transfer End Message . . . . . . . . . . . . . . . . . . 12
7.4. Transfer Cancel Message . . . . . . . . . . . . . . . . . 13
7.5. Definite Padding Message . . . . . . . . . . . . . . . . 13
7.6. Indefinite Padding Message . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. Deployment Considerations . . . . . . . . . . . . . . . . . . 14
Taylor Expires 17 September 2025 [Page 2]
Internet-Draft BTPU March 2025
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 17
A.1. Segmentation of a sequence of Bundles of equal
priority . . . . . . . . . . . . . . . . . . . . . . . . 17
A.2. Segmentation of a sequence of Bundles of different
priority . . . . . . . . . . . . . . . . . . . . . . . . 18
A.3. Message repetition . . . . . . . . . . . . . . . . . . . 19
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
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 Protocols (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 Convergence
Layer Protocols to transfer bundles between BPAs over underlying
link-layer protocols.
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 pair 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 a receiver in its entirety
or not at all. Frames may be of fixed or variable length.
Taylor Expires 17 September 2025 [Page 3]
Internet-Draft BTPU March 2025
These characteristics provide a common baseline that allows the
definition of a lightweight protocol for transferring BPv7 bundles
meeting the requirements of a BPv7 Convergence Layer Protocol, 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. Although designed for any link-
layer protocol that shares the characteristics above, 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 |
+----------------------+
Figure 1: The location of BTPU in relation to the Bundle Protocol
and a Link- layer protocol
The driving use-case of the protocol has been the transfer of BPv7
Bundles, however it is equally capable of transferring any kind of
binary data, but includes no explicit discriminator of the format of
a particular block of binary data. If multiple different types of
binary data are to be transferred by a single implementation, this
specification considers the differentiation between different types
of binary data to be a matter for the implementation. For example,
both BPv6 Bundles ([RFC5050]) 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 binary data formats that do not natively
support some form of fragmentation.
Taylor Expires 17 September 2025 [Page 4]
Internet-Draft BTPU March 2025
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.
2.1. Terminology
Within the scope of this document, the following terms have specific
meaning:
Bundle: A higher-layer protocol data unit, typically a BPv7 Bundle
as defined in [RFC9171].
Link-layer PDU: The protocol data unit, excluding any link-layer
protocol specific headers or metadata, that makes up a complete
transmission unit or frame, as defined by the link-layer protocol
specification.
Message: A single protocol data item, see Section 7.
Transfer: The context in which the transmission of the Segments of a
single Bundle occurs, see Section 4.
Segment: In order to transfer a Bundle larger than a Link-layer PDU,
Bundles may be subdivided into Segments in order to fit within a
Link-layer PDU, see Section 4.
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.
Taylor Expires 17 September 2025 [Page 5]
Internet-Draft BTPU March 2025
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.
3.1. Messages
The basic primitive of the protocol is the Message, a self-describing
unit of protocol control information of variable length. The sender
is responsible for composing one or more Messages as required, and
packing them into a Link-layer PDU, such that a single PDU is
optimally filled. The receiving node parses the contained Messages
from each received Link-layer PDU, and then processes them as
individual control signals. This sequence of Messages is the logical
control-plane used by the protocol. This document uses the verb
"emit" to describe to the writing of a new Message to a Link-layer
PDU ready for transmission, to differentiate from the the
transmission of the Link-layer PDU itself, as many Messages may
emitted prior to the transmission of the containing PDU.
See Section 7 for detail of each type of Message.
3.2. Padding
Because the size of a Bundle is not expected to exactly match the
size of a Link-layer PDU, an implementation will likely need to add
padding to the PDU so that the Link-layer PDU size requirements are
met. Two Messages are available for this purpose: The Definite
Padding Message (Section 7.5) and the Indefinite Padding Message
(Section 7.6). Padding Messages are valid at any point within a
Link-layer PDU.
It is RECOMMENDED that implementations use the Definite Padding
Message to add padding to a Link-layer PDU, except when less than
four octets of padding are required, as the minimum length of the
Definite Padding Message is four octets.
When the link-layer protocol provides variable length Link-layer
PDUs, implementations SHOULD take into account the mechanisms used by
the link-layer protocol to support variable length Link-layer PDUs,
and emit Link-layer PDUs of a suitable size for the underlying
protocol. For example, if variable length Link-layer PDUs are
implemented by the link-layer protocol using a sub-framing mechanism,
then emitting Link-layer PDUs of a single, or whole number of sub-
frames may increase reliability.
Taylor Expires 17 September 2025 [Page 6]
Internet-Draft BTPU March 2025
The algorithm used to pad and pack Messages efficiently into Link-
layer PDUs is an implementation matter.
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 Segment
Index, starting at zero (0), that indicates the relative position of
the Segment within the total sequence of Segments. In addition to a
Segment Index, 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 series 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.
A receiver reassembles the transferred Bundle by concatenating the
Segments that share a common Transfer number in the order of their
Segment Index. When all the Segments have been received and
concatenated, a receiver is expected to pass the recombined Bundle to
an upper layer for further processing.
Transfer numbers are expressed as 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" to zero and repeat, i.e. the next number in
the sequence is the previous number incremented by one, modulo 2^32.
Taylor Expires 17 September 2025 [Page 7]
Internet-Draft BTPU March 2025
4.1. Interleaving Transfers
In order to support the transmission of Bundles with different
priorities, Transfer Messages associated with different Transfers,
i.e. with different Transfer numbers, MAY be interleaved. This
allows senders to interrupt the emission of a sequence of Segments
associated with one Transfer with one or more Segments of another
Transfer, preventing a large lower priority Transfer blocking a
higher priority Transfers.
4.2. Cancelling Transfers
A Transfer may be aborted by the sender while a Transfer is in
progress by the emitting of a Transfer Cancel Message (Section 7.4)
containing the identifier of the Transfer to cancel. A receiver of a
Transfer Cancel Message SHOULD discard any cached segments already
received and MUST ignore any further Messages associated with the
Transfer.
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.
Each 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 the sender and
all receivers, 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,
Taylor Expires 17 September 2025 [Page 8]
Internet-Draft BTPU March 2025
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)
Figure 2: A receiver's algorithm for determining Transfer number
validity and sliding window
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.
Taylor Expires 17 September 2025 [Page 9]
Internet-Draft BTPU March 2025
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 Segment Index; 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.
Message replication is logically separate from any facilities the
underlying link-layer protocol may have to protect against
information loss through redundancy and/or erasure coding, and may be
used as required by a deployment. If a link-layer protocol receives
a duplicate Link-layer PDU, 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.
Taylor Expires 17 September 2025 [Page 10]
Internet-Draft BTPU March 2025
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, encoded 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, encoded 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.
7.1. Bundle Message
The Bundle Message is used to encapsulate an entire Bundle, and
SHOULD be used by an implementation when a Bundle will fit in its
entirety in a single Link-layer PDU to avoid the overhead of
segmentation, and reducing the risk of the total loss of a Bundle if
one or more unnecessary segments of a Bundle is lost.
A Bundle Message has a type of 2. The Message Content MUST be a
valid Bundle.
Emitting a Bundle Message with a Length field value of zero (0), i.e
no Bundle content, only adds control-plane overhead and SHOULD NOT be
used as an alternative form of padding.
7.2. Transfer Segment Message
The Transfer Segment Message is used to encapsulate a segment of a
multi-segment Bundle Transfer.
A Transfer Segment Message has a type of 3. The Message Content
field is formatted as follows:
Taylor Expires 17 September 2025 [Page 11]
Internet-Draft BTPU March 2025
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 Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Segment Data ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Transfer Number: The numeric identifier of the Transfer that this
Segment is part of, encoded as a 32-bit unsigned integer in
network byte order.
Segment Index: The position of the Segment within the sequence of
all Segments of a Transfer, encoded as a 32-bit unsigned integer
in network byte order.
Segment Data: The octets of a Segment of the Transfer, with the
length calculated as the Message content length excluding the
eight (8) octets of the Transfer Number and Segment Index.
Transfer Segment Messages SHOULD NOT have zero octets of Segment
Data, i.e. the total length of the Message SHOULD be greater than 12
octets. Such Messages only add control-plane overhead and SHOULD NOT
be used as an alternative form of padding.
7.3. Transfer End Message
The Transfer End Message is used to encapsulate the last segment of a
multi-segment Bundle Transfer, and complete the Transfer.
A Transfer End Message has a type of 4. The Message Content field is
formatted as follows:
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 Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Segment Data ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Transfer Number: The numeric identifier of the in-progress
(Section 5) Transfer that is completing, encoded as a 32-bit
unsigned integer in network byte order.
Taylor Expires 17 September 2025 [Page 12]
Internet-Draft BTPU March 2025
Segment Index: The non-zero Segment Index of the final Segment,
encoded as a 32-bit unsigned integer in network byte order.
Segment Data: The octets of the final Segment of the Transfer, with
the length calculated as the Message content length excluding the
eight (8) octets of the Transfer Number and Segment Index.
Transfer End Messages SHOULD NOT have zero octets of Segment Data,
i.e. the total length of the Message SHOULD be greater than 12
octets. Such Messages only add control-plane overhead and SHOULD NOT
be used as an alternative form of padding.
7.4. Transfer Cancel Message
The Transfer Cancel Message is used to indicate that the indicated
Transfer is being aborted, and any prior or later received Segments
associated with the Transfer MUST be discarded by a receiver.
A Transfer Cancel Message has a type of 5. The Message Content field
is formatted as follows:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Transfer Number: The numeric identifier of the in-progress
(Section 5) Transfer that is cancelled, encoded as a 32-bit
unsigned integer in network byte order.
The Transfer Cancel Message has no content, and hence has a fixed
length of 4 octets.
A peer that receives a Transfer Cancel Message with a Transfer Number
field value that does not match the numeric identifier of an
in-progress (Section 5) Transfer MUST ignore the Message.
7.5. Definite Padding Message
The Definite Padding Message is used to add padding to a Link-layer
PDU.
A Definite Padding Message has a type of 1. Any content it contains
has no semantic meaning, and a sender SHOULD set the content to a
sequence of zero (0) octets. Receivers MUST ignore any Message
content.
Taylor Expires 17 September 2025 [Page 13]
Internet-Draft BTPU March 2025
It is valid for this Message to have no content, i.e. a Length field
value of zero (0), adding a total of four (4) octets of padding to
the Link-layer PDU.
7.6. Indefinite Padding Message
An Indefinite Padding Message has a type of zero (0), and in order to
support padding with a minimum total length of one octet, the Message
does not include an explicit Length or Content field, and hence has
the following layout:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Type |
+-+-+-+-+-+-+-+-+
Type: The type of the Message: zero (0).
The Indefinite Padding Message type field is followed by a sequence
of zero or more zero (0) octets, ending at the first non-zero octet,
or the end of the fixed-length Link-layer PDU. The content of the
Message has no meaning, and MUST be ignored by a receiver.
Note: When a Indefinite Padding Message terminates with a non-zero
octet, the non-zero octet is the first octet of the subsequent
Message.
8. Security Considerations
This protocol does not define any measures to protect Messages or
their content. There may be link-layer mechanisms to protect the
transmission of frames against over-hearing and interference, and
upper layer mechanisms, such as BPSec defined in [RFC9172], can be
used to provide integrity and protection at a higher layer.
Therefore transport-layer security is considered out of scope for the
protocol, and lower and/or upper layer mechanisms MUST be used to
provide security.
9. Deployment Considerations
The following caveats should be considered before deploying instances
of this protocol:
Taylor Expires 17 September 2025 [Page 14]
Internet-Draft BTPU March 2025
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
channel between sender and receivers, 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 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", in the existing "Bundle Protocol" registry group. The
registration policy for this registry, using terms defined in
[RFC8126], is:
+============+===============================+
| Values | Registration Policy |
+============+===============================+
| 0..0x6F | Standards Action |
+------------+-------------------------------+
| 0x70..0x7F | Private Use |
+------------+-------------------------------+
| 0x80..0xFF | Reserved for future expansion |
+------------+-------------------------------+
Table 1: BTPU Message Types registration
policies
The initial values for the registry are:
Taylor Expires 17 September 2025 [Page 15]
Internet-Draft BTPU March 2025
+======+==========================================+===============+
| Type | Message | Reference |
+======+==========================================+===============+
| 0 | Indefinite Padding Message (Section 7.6) | This document |
+------+------------------------------------------+---------------+
| 1 | Definite Padding Message (Section 7.5) | This document |
+------+------------------------------------------+---------------+
| 2 | Bundle Message (Section 7.1) | This document |
+------+------------------------------------------+---------------+
| 3 | Transfer Segment Message (Section 7.2) | This document |
+------+------------------------------------------+---------------+
| 4 | Transfer End Message (Section 7.3) | This document |
+------+------------------------------------------+---------------+
| 5 | Transfer Cancel Message (Section 7.4) | This document |
+------+------------------------------------------+---------------+
Table 2: BTPU Message Types initial values
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9171] Burleigh, S., Fall, K., and E. Birrane, III, "Bundle
Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171,
January 2022, <https://www.rfc-editor.org/rfc/rfc9171>.
[RFC9172] Birrane, III, E. and K. McKeever, "Bundle Protocol
Security (BPSec)", RFC 9172, DOI 10.17487/RFC9172, January
2022, <https://www.rfc-editor.org/rfc/rfc9172>.
11.2. Informative References
Taylor Expires 17 September 2025 [Page 16]
Internet-Draft BTPU March 2025
[AOS] "Advanced Orbiting Systems (AOS) Space Data Link
Protocol", CCSDS 732.0-B-4, October 2021,
<https://public.ccsds.org/Pubs/132x0b3.pdf>.
[DVB-S2X] "Digital Video Broadcasting (DVB); Second generation
framing structure, channel coding and modulation systems
for Broadcasting, Interactive Services, News Gathering and
other broadband satellite applications; Part 2: DVB-S2
Extensions (DVB-S2X)", ETSI EN 302 307-2, August 2024,
<https://www.etsi.org/deliver/
etsi_en/302300_302399/30230702/01.04.01_60/
en_30230702v010401p.pdf>.
[IEEE.802.3]
"IEEE Standard for Ethernet", IEEE,
DOI 10.1109/ieeestd.2022.9844436, ISBN ["9781504487252"],
July 2022, <https://doi.org/10.1109/ieeestd.2022.9844436>.
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol
Specification", RFC 5050, DOI 10.17487/RFC5050, November
2007, <https://www.rfc-editor.org/rfc/rfc5050>.
[TM] "Telemetry (TM) Space Data Link Protocol",
CCSDS 132.0-B-3, October 2021,
<https://public.ccsds.org/Pubs/132x0b3.pdf>.
[USLP] "Unified Space Data Link Protocol (USLP)",
CCSDS 732.1-B-3, June 2024,
<https://public.ccsds.org/Pubs/732x1b3e1.pdf>.
[_5G] 3GPP and C. Devaki, "System architecture for the 5G System
(5GS)", 21 December 2022, <https://www.3gpp.org/ftp/Specs/
archive/23_series/23.501/23501-i00.zip>.
Appendix A. Examples
A.1. Segmentation of a sequence of Bundles of equal priority
An example of the transmission of three Bundles of varying sizes and
equal priority in three Link-layer PDUs is shown in Figure 3.
Taylor Expires 17 September 2025 [Page 17]
Internet-Draft BTPU March 2025
+---------------------------+------------+-----------------+
| 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 |
+----------------------+----------------------+----------------------+
Figure 3: Segmentation of a sequence of Bundles of equal priority
Bundle A is transferred as two Segments, included in the first and
second Link-layer PDU, as Transfer 1. Bundle B fits completely in
the second Link-layer PDU, and is therefore transferred without
segmentation. Bundle C is transferred as two Segments split between
the second and third PDU, but padding is required to fill the third
PDU. An alternative algorithm could have selected to not segment
Bundle C, but to pad the second PDU and include Bundle C without
segmentation in the third PDU, without changing the semantics, as an
implementation preference.
A.2. Segmentation of a sequence of Bundles of different priority
An example of the transmission of three Bundles of varying sizes and
different priority in three Link-layer PDUs is shown in Figure 4.
Taylor Expires 17 September 2025 [Page 18]
Internet-Draft BTPU March 2025
+---------------------------+
| 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 |
+----------------------+----------------------+----------------------+
Figure 4: Interleaved segmentation of a sequence of Bundles of
different priority
TODO: Rework this diagram to be a bit clearer, currently Bundle B
arrives during the first frame processing.
A.3. Message repetition
TODO: Add an example of repetitions
Appendix B. Acknowledgments
TODO acknowledge.
EK, Brian Sipos & TCPCL authors, Chloe He
Author's Address
Rick Taylor
Aalyria Technologies
Email: rtaylor@aalyria.com
Taylor Expires 17 September 2025 [Page 19]