Skip to main content

Bundle Sequence Identification for Bundle Protocol Version 7
draft-flentge-dtn-bundle-sequence-identification-00

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]