Subject: [dtn] Rick's user-agent DTN access

From: "Sipos, Brian J." <[email-masked]>
Date: Wed, 23 Mar 2022 17:31:04 +0000

All,

Related to Rick's IETF 113 presentation about how to use (in some way) a DTN
URI from a user agent such as cURL, one thing that has not really been
discussed (as far as I've seen) is the concept of a DTN "stub network" in
the same way that OSPF and AS refer to routing stubs, or that a DNS local
resolver is distinct from a caching/forwarding/recursive resolver. The main
aspect of the stub network is that the access configuration is very simple,
possibly statically configured or driven by a neighbor discovery mechanism.

The DTN stub network could be a single node or multiple nodes, but they all
sit on one side of a gateway node and all bundles to or from the stub
network is routed via the gateway. In this paradigm the "user-agent" DTN
access happens implicitly via the gateway so when a payload is sent to a
destination EID via cURL, the cURL process (acting as a limited BP agent,
see below) simply forwards the produced bundle to its gateway node.

If a BP agent were known to always be in a stub network its implementation
could be significantly simplified. This kind of "stub agent" or "non-routing
agent" would need to only communicate with its gateway node, and could
actually be built to be stateless in the sense that it would use a reliable
CL (e.g. TCPCL with a transfer MRU of zero to disallow reception) and once
the bundle transfer got ACK'd it was forgotten about locally. On the
receiving side it would be similarly stateless if it could use a
non-administrative Node ID, but this would require some nuance on the
last-hop peer side that isn't currently specified in TCPCL: if a peer
supplies a non-administrative Node ID in the SESS_INIT then only bundles
with that destination EID would be sent, not any other endpoints on the same
node.

One important aspect of this stub node is that it isn't simply a singleton
endpoint within an existing node, but has an actual Node ID and represents a
separate logical node. There currently is no alternate way to represent a
"detached endpoint" entity separate from a node; for example a node
"ipn:10.0" with a separate entity just for the endpoint "ipn:10.5" which
would somehow communicate with the 'parent' node. Alternately, and not
technically prohibited by the current protocol documents, a CLA could be
used to transport between a BP node and a detached endpoint. There's nothing
prohibiting a TCPCL entity identifying as "ipn:10.5" from connecting to the
node identifying as "ipn:10.0". The nuance is that the detached endpoint
entity doesn't have its own BP agent, can't exchange administrative records,
etc.

Just some thoughts,

Brian S.