[dtn] Re: bundle de-dup guidance, node ID vs EID

[[e-mail]]

Hi, Erik.  The resolution to the problem you identify goes like this:

*	The source of any bundle is identified by a node ID (RFC 9171 4.3.1), which may be the null endpoint ID (RFC 9171 3.2).
*	Every singleton EID may serve as a node ID (RFC 9171 4.2.5.2).

 

So the source of any bundle is identified by a singleton EID (or the null EID).  Not elegant, I know; this evolved over some time.  The idea is that, since a singleton EID identifies an endpoint that contains exactly one node, the ID of that endpoint – like the IDs of potentially many other singleton EIDs – implicitly identifies the node that is the sole occupant of that endpoint.

 

The advantage of using a singleton EID (in this context, a node ID) to identify the source of the bundle is that the service number (if you’re using the ipn EID scheme) can provide some additional information about the application that offered the ADU that is the bundle’s payload.  Some applications exploit this feature.

 

The ID of a bundle is then formed as the combination of the source node ID and the bundle creation timestamp.  Two bundles that were issued at the exact same time could be distinguished by (a) possibly different source node IDs and (b) different sequence numbers in the bundle creation timestamp.

 

I’m unclear on your first point; we normally figure that the spacecraft has a clock, the BPA queries the clock for the current time at the moment it creates the bundle, and that time becomes the “bundle creation time” component of the bundle creation timestamp.  There isn’t any notion of timestampers, per se, in the spec.

 

On your last point, you’re right, two bundles that were issued by different nodes at exactly the same time, with exactly the same timestamp sequence numbers, would be indistinguishable.  In practice, every anonymous bundle (every bundle whose source node ID is the null endpoint ID) has to be regarded with some suspicion by the receiving BPA: might be innocent, might be a DOS attack.  I think reliable guidance on how to handle these things would be challenging to assemble, as it could be wholly dependent on destination endpoint (service number), previous node (from the previous node extension block), network status, bundle size, BPSec block integrity checking, time of day, national security threat level, whatever.  Possibly some guidance will emerge from operational experience.

 

Scott

 

From: Erik Kline <[e-mail]> 
Sent: Wednesday, March 18, 2026 8:26 PM
To: DTN WG <[e-mail]>
Subject: [dtn] bundle de-dup guidance, node ID vs EID

 

All,

 

Apologies for the n00b question, but looking into how a BPA should de-dup bundles so that it doesn't retransmit something it already forwarded made me realize I failed to notice one specific detail earlier.

 

RFC 9171 S4.2.7 says:

 

   """The

   combination of source node ID and bundle creation timestamp serves to
   identify a single transmission request, enabling it to be
   acknowledged by the receiving application ...

   """

 

I was surprised to realize that the source *node ID* is used rather than the source EID.  IIUC, this implies at least two things that hadn't occurred to me before:

 

    [1] sending BPAs MUST gate all bundles for all source services through a "timestamper", rather than using a "timestamper" instance per service, and

 

    [2] receiving BPAs MUST take the source EID and transform it into a node ID in order to construct a key for lookup in any kind of  "already forwarded Bundle" cache table.

 

Do I understand this correctly?  This is what implementations do?

 

Separately, should a receiving BPA be able to de-dup bundles with a null endpoint source node ID?  If not, I wonder if we might need some guidance on policies for BPAs to protect themselves from certain kinds of traffic injection.

 

-ek