]> 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 binary objects of different priority, preventing head-of-line blocking impacting performance. The 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 (CLPs) 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 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 a receiver in its entirety or not at all. Frames can be of fixed or variable length.
• They provide a single logical channel: the communication between a sender and one or more receivers of frames can be logically separated from other communication over the link-layer by an implementation, perhaps by the use of channel identifiers, circuit identifiers, or tuples of source and destination address information.

These characteristics provide a common baseline that allows the definition of a lightweight mechanism 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 Ethernet , without requiring underlying IP services. Although designed for any link-layer protocol that shares the characteristics above, additional specification or profiling might 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 .

Segment:

In order to transfer a Bundle larger than a Link-layer PDU, Bundles can be subdivided into Segments in order to fit within a Link-layer PDU, see .

Transfer:

The context in which the transmission of the Segments of a single Bundle occurs, 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 can 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 can prioritize the transfer of each Bundle differently, the protocol allows for the multiplexing of Bundle transfers, so that the transfer of higher priority Bundles can interrupt the transfer of other Bundles, avoiding "head of line blocking", see for more detail. The bundle transfers are expected to occur over the same logical channel, rather than using a separate channel for each bundle or group of bundles that share priority. This does not preclude using multiple logical channels, but each channel is expected to be an independent instance of the protocol.

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 can be 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 can 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 that indicates the relative position of the Segment within the total sequence of Segments, with zero (0) indicating the first segment; i.e. Segments are ordered 0 to N, where N is the Segment Index in the Transfer End Message. The Segments of a Bundle MUST be emitted by the sender as a series of Transfer Segment Messages carrying the same Transfer identifier, starting with Segment Index zero (0). The end of a transfer MUST be indicated by emitting a Transfer End Message, including the index and data of the final Segment. 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. 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. A receiver reassembles the transferred Bundle by concatenating the Segments that share a common Transfer number in the ascending order of their Segment Index. The Segment Index in the Transfer End Message indicates the final Segment Index (N); a transfer is complete when Segments with indices 0 through N have been received. Once all the Segments have been received and concatenated, a receiver is expected to pass the recombined Bundle to an upper layer for further processing.

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 can be aborted by the sender while a Transfer is in progress by emitting a Transfer Cancel Message containing the identifier of the Transfer to cancel. A receiver of a Transfer Cancel Message SHOULD discard any segments already received and MUST ignore any further Messages associated with the Transfer.

Transfer Window Because Messages can 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. This margin allows a receiver that has experienced a temporary loss of signal to correctly resume processing, distinguishing genuinely new Transfers from those that have wrapped around the number space and are obsolete. Pseudocode for the algorithm is given in . The size of the Transfer Window at a receiver MUST NOT be smaller than the size of the Transfer Window at the sender; the simplest way to ensure this is to configure the same size at the sender and all receivers, which is RECOMMENDED. Transfer Window sizes 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. 16 is an arbitrary number, and needs 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 can 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. A receiver MAY ignore any duplicate Message already received for an in-progress Transfer. When segmenting bundles, not all Messages in a Transfer need be repeated the same number of times, and different Transfers can repeat Messages differently. Although it is RECOMMENDED that segments 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 might require a certain amount of Message repetition to reach some required certainty of transfer.
• A higher 'reliability' factor associated with a particular Bundle could result in more copies of each associated Transfer Message being emitted.
• Signalling from the link-layer protocol, or some other out-of-band mechanism, might trigger increased repetition of a subset of 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 might 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 Format 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.

Flags:

A 4-bit field for flags, see .

Length:

The length of the Message in octets, excluding the 4 octets of the header itself, encoded as a 20-bit unsigned integer in network byte order. This length includes both the optional Hint Items and the Content.

Content:

A sequence of octets of data. Its length is the main Message Length minus the total length of any present Hint Items. The content is encoded according to the Type of the Message.

Message Flags The Message Flags field is a 4-bit 4 bits is considered enough, as it allows a 20-bit Message Length field, and many additional flags could be better expressed with Hint Items. field, formatted as follows:

H:

The 'H' (Hint) flag. If this bit is set to 1, it indicates that one or more Hint Items are present immediately following the Message header.

RFU (Reserved for Future Use):

These 3 bits are unassigned. They MUST be set to zero by the sender and MUST be ignored by the receiver.

Hint Items To allow the transfer of optional additional information, Messages can carry extra information in the form of Hint Items. Because Messages can be lost in transmission, this metadata provides additional information about the Transfer itself, rather than being particular to the containing Message, and MAY be repeated in multiple different or repeated Messages. If the 'H' flag is set in the Message header, the header is followed by one or more Hint Items. Each item is encoded in a Type-Length-Value format, with a 2-octet header followed by a variable-length value. This format intentionally omits a flags field to prevent nested metadata.

Hint Type:

A 7-bit identifier for the Hint Item, allocated from the "BTPU Hint Types" IANA registry, see , encoded as a 7-bit unsigned integer in network byte order.

H:

The 'H' (Hint) flag. If this bit is set to 1, it indicates that another Hint Item immediately follows this Hint Item. If this bit is set to 0, then the Message content immediately follows the Hint Item.

Length:

An 8-bit unsigned integer specifying the length of the Value field in octets. This limits the value of a single Hint Item to 255 octets.

Value:

The payload of the Hint Item.

Unrecognized Messages and Hint Items Because all Messages, except the Indefinite Padding Message, follow the common Message format, a Message can be skipped by a receiver without knowledge of its Type-specific semantics. A receiver that parses a Message with a Type value that it does not recognize, other than the value 6 or a value in the range 0x80..0x9F, MUST ignore the Message by skipping the number of octets indicated by the Length field, and continue processing any subsequent Messages in the Link-layer PDU. This applies to every unrecognized Type value, including any allocated in the future from the range reserved for future expansion, allowing Message types defined in future documents to be introduced into deployments where not all receivers have been updated to recognize them. The Type value 6 and Type values in the range 0x80..0x9F indicate that the octets encountered are not a Message at all, but an encapsulated bundle in its native format: 6 is the initial octet of a BPv6 bundle, and 0x80..0x9F are the possible initial octets of the CBOR array of a BPv7 bundle, see . Both bundle formats are self-delimiting, so a receiver that implements the corresponding format can determine the extent of the bundle, handle it as it would the content of a Bundle Message, and continue processing any subsequent Messages in the Link-layer PDU. A receiver that does not implement the corresponding bundle format cannot determine the extent of the bundle, and MUST NOT attempt to process the remainder of the Link-layer PDU. Similarly, a receiver that parses a Hint Item with a Hint Type that it does not recognize MUST ignore the Hint Item by skipping the number of octets indicated by the Hint Item Length field, and continue processing any subsequent Hint Items and the Message Content. Hint Items are therefore only suitable for carrying optional information that can be safely ignored by a receiver.

Message Definitions The following standard protocol Messages are defined:

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. Because it conveys a complete Bundle, a Bundle Message is not a Transfer: it has no Transfer number and is not subject to the Transfer Window, which bounds only the number of segmented Transfers that can be simultaneously in progress. 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 that indicates no Bundle content (e.g., a length of 0 if no metadata is present) 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 indicate the completion of a multi-segment Bundle Transfer, and encapsulate the final segment. 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 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 an Indefinite Padding Message terminates with a non-zero octet, the non-zero octet is the first octet of the subsequent Message.

Standard Hint Items The following Hint Items are defined in this document:

Bundle Length Hint The Bundle Length Hint Item is used to signal the total length of a bundle that is being transferred in segments. This allows a receiver to pre-allocate the necessary memory to reassemble the complete bundle. This Hint Item MAY be included in a Transfer Segment Message or a Transfer End Message. Receivers SHOULD ignore this Hint Item if encountered in other message types. The Hint Item has a Hint Type of 0, and its layout is as follows:

Length:

The length of the Bundle Length field. This MUST be one of 1, 2, 4, or 8.

Bundle Length:

The total length of the bundle being transferred, encoded as an unsigned integer in network byte order, with a size corresponding to the Length field.

A sender SHOULD choose the smallest possible length that can accommodate the total bundle length. For example, a bundle of 2000 octets should be encoded with a Length of 2, and a Value of 2000 encoded as a 16-bit unsigned integer.

Security Considerations This protocol does not define any measures to protect Messages or their content. There might 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 are to be considered before deploying instances of this protocol:

1. It is unreliable. Although there might 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 might 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

BTPU Message Types Registry IANA is requested to create a new registry entitled "BTPU Message Types", in the existing "Bundle Protocol" registry group. The registration procedures for this registry, using terms defined in , is: BTPU Message Types registration policies

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

Specifications defining new Message Types, including any future allocation from the range reserved for future expansion, MUST use the common Message format defined in , so that receivers that do not recognize the new Type value can process the containing Link-layer PDU as described in . 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
6	Reserved to avoid clash with BPv6	This document
0x80..0x9F	Reserved to avoid clash with BPv7 Bundle (CBOR array)	This document

The initial value of 6 is reserved to ensure that a Link-layer PDU containing a single Bundle Protocol version 6 bundle can be distinguished from BTP-U Messages.

BTPU Hint Types Registry IANA is requested to create a new registry entitled "BTPU Hint Types", in the existing "Bundle Protocol" registry group. The registration procedures for this registry, using terms defined in , is: Specifications defining new Hint Types MUST specify which Message types the Hint is applicable to, and SHOULD specify receiver behavior when the Hint is encountered in other Message types. BTPU Hint Types registration policies

Values	Registration Procedure
0..0x6F	Standards Action
0x70..0x7F	Private Use

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

Type	Hint	Reference
0	Bundle Length	This document

BTPU Message Flags Registry IANA is requested to create a new registry entitled "BTPU Message Flags", in the existing "Bundle Protocol" registry group. This registry governs the 4-bit Message Flags field. The registration procedures for this registry, using terms defined in , is Standards Action. The initial values for the registry are: BTPU Message Flags initial values

Bit	Name	Description	Reference
0 (0x8)	H (Hint)	Indicates presence of Hint Items	This document
1-3	Unassigned

Bit 0 is the most significant bit.

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 The following sections has examples of an implementation emitting Bundles into Link-layer PDUs. Although the examples demonstrate the core principles, for example Bundle Segmentation with priority, the algorithm used to pack Messages into Link-layer PDUs is just for example purposes. An implementation can use an alternate algorithm that meets this specification but suits its overall architecture, and where this is applicable is noted in each example.

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 emitted 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 emitted without segmentation. Bundle C is emitted 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

Bundle A is emitted without segmentation, and the Bundle B is segmented to fill the first Link-layer PDU. During the preparation of the next Link-layer PDU high priority Bundle C is queued for emission. Therefore the further emission of Bundle B is paused, and Bundle C is emitted as two Segments, with the third Link-layer PDU containing the second Segments of both Bundle B and C, plus padding. The order of emission of the second Segments of Bundle B and C makes no semantic difference.

Repetition of Bundle Segments An example of the transmission of two Bundles of differing required repetition in three Link-layer PDUs is shown in .

Repetition of some Bundles within a sequence of Segments

Bundle A is required by some higher-layer loss protection policy to be repeated twice in two separate Link-layer PDUs. Bundle A does not require additional loss protection, and can therefore be transmitted once. As Bundle A can fit in its entirety in a single Link-layer PDU, it is emitted as a Complete Bundle Message, with Bundle B emitted as a Segment Messages sized to fill the remainder of each PDU. The Complete Bundle Message of Bundle A is repeated in the second Link-layer PDU, with the remainder of the second PDU filled with the next Segment of Bundle B. The third Link-layer PDU contains the last Segment of Bundle B and padding. An alternate implementation could have segmented both Bundles, and repeated the Segments of Bundle A whilst interleaving the Segments of Bundle B.

Acknowledgments The author would like to thank Erik Kline, Brian Sipos, and Chloe He for their invaluable feedback and discussion of the protocol, and this work would not exist without the excellent prior work by the TCP-CLv4 authors.