]> European Space Agency

felix.flentge@esa.int

Internet Delay/Disruption Tolerant Networking DTN Bundle Protocol BPv7 This document defines compact sequence identifiers, ranges, and collections for referring to one or more Bundle Protocol Version 7 bundles. The mechanism supports efficient signaling and enables ordered reception, duplicate suppression, and gap detection.

Introduction Bundle Protocol Version 7 (BPv7) identifies a bundle using its source node ID, creation timestamp, and, for fragments, fragment information. Some protocol functions need a compact way to identify ordered groups of bundles and ranges within those groups. This document defines Bundle Sequence Numbers (BSNs), Bundle Sequence IDs (BSIDs), bundle sequences, bundle sequence ranges, and bundle sequence collections for that purpose. The mechanism is derived from the corresponding CCSDS experimental specification . The definitions in this document are intended for use by BPv7 extension specifications. They do not change the identity rules of and do not by themselves define a new extension block or administrative record.

Conventions and Terminology 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. Block Source Administrative Endpoint ID (AEID) : An endpoint ID of the administrative element of the BP agent that assigns a Bundle Sequence Number and inserts the corresponding extension block. Bundle Sequence Counter (BSC) : A counter that supplies Bundle Sequence Numbers for one protocol function and one sequence-identification context. Bundle Sequence ID (BSID) : An unsigned integer identifying a Bundle Sequence Counter. The value zero indicates bundle destination-based counter selection. Bundle Sequence Number (BSN) : An unsigned integer obtained from a Bundle Sequence Counter and carried in an extension block.

Applicability The mechanism is suitable where a protocol function benefits from compact signaling of bundle ranges, ordered reception, duplicate suppression, or gap detection. Counter scope, persistence, and maximum values require operational coordination. A consuming specification MUST define how sequence information is carried and how its processing context is established.

Bundle Sequence Counters (BSC) and Bundle Sequence Numbers (BSN) Bundle Sequence Counters (BSCs) provide a Bundle Protocol Agent with integer sequence numbers for use in extension blocks. When a node inserts the current value of a counter into an extension block as a BSN, it MUST increment the BSC by one. A BSC MAY wrap to zero after reaching a configured maximum value of 2^8, 2^16, 2^32, or 2^64. The maximum MUST be large enough that a BSN is not reused while a bundle or administrative record containing the earlier value can remain relevant. A node MAY maintain multiple BSCs. Each BSC MUST be qualified either by a positive Bundle Sequence ID (BSID) or by a destination endpoint ID (EID), i.e. an EID used as a destination in a bundle's primary header. The use of a destination EID to qualify a BSC SHALL be indicated by BSID '0' whenever required. BSC SHALL be further qualified by an Administrative Endpoint ID (AEID) of the Bundle Agent maintaining the counter. An administrative element may be registered under multiple AEIDs. Each AEID identifies a distinct BSC context. In addition, separate protocol functions, such as custody transfer or compressed bundle status reporting, MUST use separate BSCs. As a result, each Bundle Sequence Counter (BSC) and the Bundle Sequence Numbers (BSNs) it provides are uniquely identified by one of the following:

1. A Block Source Administrative Endpoint ID (AEID) together with a positive Bundle Sequence ID (BSID).
2. A Block Source Administrative Endpoint ID (AEID) together with an endpoint ID (EID) when BSID is zero.

Within one consuming protocol function and during the relevant bundle lifetime, sequence information identifies a bundle by the block source AEID, the BSN, and either the destination EID when BSID is zero or the positive BSID when BSID is non-zero. Sequence identification does not replace the BPv7 bundle identity defined by . Whenever a BSN is used in an extension block, the full identification of that BSN MUST be available to any processing bundle node by only processing the bundle. This MAY be achieved by providing the AEID and BSID or endpoint ID within the extension block. AEID MAY also be provided implicitly by the bundle source node ID in the primary block if it is an administrative endpoint ID. A qualifying endpoint ID MAY be the destination endpoint ID in the primary block. Implementations SHOULD preserve BSC state across restart. If state cannot be preserved, an operator MUST prevent ambiguous reuse, for example by waiting until prior values cannot remain relevant, changing the block source AEID, or selecting a new positive BSID.

Bundle Sequences and Collections BSNs are used to refer to bundle sequences and collections of such sequences. Using CBOR as defined by , a bundle sequence SHALL be a definite-length CBOR array of three or four items:

• The first item SHALL either be a positive BSID as a CBOR unsigned integer or an EID as a CBOR encoded endpoint ID.
• The second item SHALL be the first BSN as a CBOR unsigned integer.
• The third item SHALL be the length of the sequence, a CBOR unsigned integer, or a range as defined below.
• The optional fourth item is the block source AEID as a CBOR encoded endpoint ID. A consuming specification MUST state whether the block source AEID is present or implicit.

A range SHALL be a definite-length CBOR array containing an odd number of CBOR unsigned integers. The values SHALL alternately specify included and excluded subsequence lengths, beginning and ending with an included length. The first BSN applies to the first element of the first included subsequence, for example:

• 1st included subsequence length;
• 1st excluded subsequence length;
• 2nd included subsequence length;
• 2nd excluded subsequence length;
• 3rd included subsequence length, etc.

A bundle sequence collection SHALL be a definite-length CBOR array containing zero or more bundle sequences. An empty collection is permitted. Sequences in a collection need not use the same identifier or block source AEID. A receiver MUST reject a sequence as malformed if an included or excluded length is zero, if a range has even length, if arithmetic overflows, or if the sequence does not meet the consuming specification's AEID rules.

Fragmentation A bundle containing an extension block that uses this sequence-identification mechanism MUST NOT be fragmented. Extension blocks using this specification MUST NOT be added to a fragment and MUST NOT be processed in a fragment. Sources SHOULD set the Bundle Must Not be Fragmented flag. Convergence-layer segmentation is unaffected.

CDDL The following CDDL uses the CDDL notation of and the EID rule defined by .

IANA Considerations This document requests no IANA action.

Security Considerations Forged, replayed, or ambiguously reused sequence information can cause incorrect operation of protocol functions that rely on the mechanisms defined in this specification.

Operational and Manageability Considerations Management information SHOULD expose BSC values, configured moduli, persistence status, restart events, rejected or malformed sequences, detected wraparound, and retained sequence state. Operators SHOULD document the assignment and purpose of positive BSIDs.

Implementation Status This section records implementation experience in accordance with and is intended to be removed before publication as an RFC. The European Space Agency Bundle Protocol implementation includes separate counter maps for custody transfer and compressed reporting, sequence-number generation and wraparound handling, and encoding and decoding of sequence structures. Unit and system tests have been used to validate these functions.

References Normative References 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 proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. 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. Informative References This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. Consultative Committee for Space Data Systems

Acknowledgements The author would like to acknowledge the substantial technical contributions of Aida Manole, Alice LeBihan, and Yanik Jeck to the development, review, discussion, and refinement of the mechanisms specified in this document. Their contributions to the corresponding CCSDS work significantly influenced the design and maturation of this specification.