Bundle Sequence Identification for Bundle Protocol Version 7
draft-flentge-dtn-bundle-sequence-identification-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Felix Flentge | ||
| Last updated | 2026-10-26 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
GitHub Repository
Additional Web Page |
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-flentge-dtn-bundle-sequence-identification-00
Delay/Disruption Tolerant Networking F. Flentge
Internet-Draft European Space Agency
Intended status: Standards Track 26 October 2026
Expires: 29 April 2027
Bundle Sequence Identification for Bundle Protocol Version 7
draft-flentge-dtn-bundle-sequence-identification-00
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 29 April 2027.
Copyright Notice
Copyright (c) 2026 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.
Flentge Expires 29 April 2027 [Page 1]
Internet-Draft Bundle Sequence Identification October 2026
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 2
3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Bundle Sequence Counters (BSC) and Bundle Sequence Numbers
(BSN) . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Bundle Sequences and Collections . . . . . . . . . . . . . . 4
6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 5
7. CDDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
9. Security Considerations . . . . . . . . . . . . . . . . . . . 6
10. Operational and Manageability Considerations . . . . . . . . 6
11. Implementation Status . . . . . . . . . . . . . . . . . . . . 6
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
12.1. Normative References . . . . . . . . . . . . . . . . . . 6
12.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. 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 [CCSDS-734.6-O-1].
The definitions in this document are intended for use by BPv7
extension specifications. They do not change the identity rules of
[RFC9171] and do not by themselves define a new extension block or
administrative record.
2. 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 [RFC2119] [RFC8174] 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.
Flentge Expires 29 April 2027 [Page 2]
Internet-Draft Bundle Sequence Identification October 2026
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.
3. 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.
4. 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).
Flentge Expires 29 April 2027 [Page 3]
Internet-Draft Bundle Sequence Identification October 2026
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
[RFC9171].
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.
5. Bundle Sequences and Collections
BSNs are used to refer to bundle sequences and collections of such
sequences. Using CBOR as defined by [RFC8949], 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;
Flentge Expires 29 April 2027 [Page 4]
Internet-Draft Bundle Sequence Identification October 2026
* 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.
6. 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.
7. CDDL
The following CDDL uses the CDDL notation of [RFC8610] and the EID
rule defined by [RFC9171].
;Bundle Sequence Collection
seq-collection = [* seq]
;Bundle Sequence
seq = [
seq-id-ref: (uint .gt 0) / eid,
seq-start: seq-num,
range: seq-range / (uint .gt 0),
? blk-source: eid
]
;Bundle Sequence Range
seq-range = [
incl: (uint .gt 0),
+(excl: (uint .gt 0), incl: (uint .gt 0))
]
;Bundle Sequence Number
seq-num = uint
Flentge Expires 29 April 2027 [Page 5]
Internet-Draft Bundle Sequence Identification October 2026
8. IANA Considerations
This document requests no IANA action.
9. 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.
10. 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.
11. Implementation Status
This section records implementation experience in accordance with
[RFC7942] 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.
12. References
12.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/info/rfc2119>.
[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/info/rfc8174>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>.
Flentge Expires 29 April 2027 [Page 6]
Internet-Draft Bundle Sequence Identification October 2026
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[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/info/rfc9171>.
12.2. Informative References
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[CCSDS-734.6-O-1]
Consultative Committee for Space Data Systems, "Custody
Transfer and Compressed Bundle Status Reporting,
Experimental Specification", CCSDS 734.6-O-1, June 2026,
<<https://ccsds.org/publications/orangebooks/
entry/4868/>>.
Appendix A. 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.
Author's Address
Felix Flentge
European Space Agency
Email: felix.flentge@esa.int
Flentge Expires 29 April 2027 [Page 7]