]> Aalyria Technologies

rtaylor@aalyria.com

INT Delay/Disruption Tolerant Networking DTN BPv7 Bundle Protocol 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 The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Delay/Disruption Tolerant Networking Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Bundle Protocol version 7 (BPv7) is defined in terms a layered logical architecture, detailed in , 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 , , , , 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.

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 , or , 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.

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 () 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.

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

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 .

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 .

Transfer:

The context in which the transmission of the Segments of a single Bundle occurs, see .

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 .

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 . This segmentation is unrelated to BPv7 bundle fragmentation as defined in . 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 for more detail.

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 for detail of each type of Message.

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 and the Indefinite Padding Message. 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. The algorithm used to pad and pack Messages efficiently into Link-layer PDUs is an implementation matter.

Segmentation and Transfers As described in the Protocol Overview, 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. 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 carrying the same Transfer identifier. The end of a sequence of Segments MUST be indicated by emitting a Transfer End Message, 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.

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.

Cancelling Transfers A Transfer may be aborted by the sender while a Transfer is in progress by the emitting of a Transfer Cancel Message 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.

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 , 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 . 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 . 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, and is RECOMMENDED to be 16. These are entirely arbitrary numbers, and need discussing by the WG.

A receiver's algorithm for determining Transfer number validity and sliding window

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

Message Definitions All protocol Messages except the Indefinite Padding Message 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.

Type:

The type of the Message, allocated from IANA "BTPU Message Types" registry, see , 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.

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.

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:

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.

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:

Transfer Number:

The numeric identifier of the in-progress Transfer that is completing, encoded as a 32-bit unsigned integer in network byte order.

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.

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:

Transfer Number:

The numeric identifier of the in-progress 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 Transfer MUST ignore the Message.

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

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:

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.

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

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

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 , is: BTPU Message Types registration policies

Values	Registration Policy
0..0x6F	Standards Action
0x70..0x7F	Private Use
0x80..0xFF	Reserved for future expansion

The initial values for the registry are: BTPU Message Types initial values

Type	Message	Reference
0	Indefinite Padding Message	This document
1	Definite Padding Message	This document
2	Bundle Message	This document
3	Transfer Segment Message	This document
4	Transfer End Message	This document
5	Transfer Cancel Message	This document

References Normative References This document presents a specification for the Bundle Protocol, adapted from the experimental Bundle Protocol specification developed by the Delay-Tolerant Networking Research Group of the Internet Research Task Force and documented in RFC 5050. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document defines a security protocol providing data integrity and confidentiality services for the Bundle Protocol (BP). Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Informative References 3rd Generation Partnership Project

France Sophia Antipolis Cedex

Nokia Germany IEEE This document describes the end-to-end protocol, block formats, and abstract service description for the exchange of messages (bundles) in Delay Tolerant Networking (DTN). This document was produced within the IRTF's Delay Tolerant Networking Research Group (DTNRG) and represents the consensus of all of the active contributors to this group. See http://www.dtnrg.org for more information. This memo defines an Experimental Protocol for the Internet community.

Examples

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 .

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.

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 .

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.

Message repetition TODO: Add an example of repetitions

Acknowledgments TODO acknowledge. EK, Brian Sipos & TCPCL authors, Chloe He