Re: [dtn] DTN addressing, routing, and ownership

[Brian Sipos <[e-mail]>]

The semantics of DTN EID URIs are very similar in concept to the URN
behavior [1], in that an EID itself must be resolved to some kind of CL
access/transport mechanism to be "usable" in any sense other than just an
identifier. The fact that an EID is encoded as a URL instead of URN seems to
be historical and just a fact of life at this point.

 

In that same light though, EIDs could be augmented (without changing the
basic URL encoding behavior) to indicate intrinsic CL parameters. For
example:

dtn://nodeA/svc1?cl=tcpcl,host=dtn.example.com,port=4556

could resolve to using TCPCL by initiating a session with "dtn.example.com"
and transferring a bundle.

The point and benefit of using this kind of 'resolution helper' URI query is
that it doesn't actually modify the base EID which is had by just removing
query part of the URI. And all of this can be done with existing tools,
nothing specialized to DTN.

 

COAP uses augmented schemes for alternate transports [2], but that is
required because COAP URLs already make use of the URI query part so
transport options can't collide with those. Using DTN query part for CL
parameters allows a lot more flexibility for parameterizing the CL use, not
that the flexibility is strictly needed. My feeling is that the using the
query part to resolve the URI also fits in line with how the URN resolution
[1] already works.

 

If the goal really is to use a DNS-name as the node name itself, the query
semantics could be defined so that the lack of a "host" parameter treats the
node name as the host name. For example:

dtn://dtn.example.com/svc1?cl=tcpcl

 

I would love to see this kind of thing in a concrete proposal, including a
registry of named convergence layers (which doesn't yet exist but I've seen
hinted at in some other documents).

 

[1] https://tools.ietf.org/html/rfc8141

[2] https://tools.ietf.org/html/rfc8323

 

 

  _____  

From: dtn <[e-mail]> on behalf of Birrane, Edward J.
<[e-mail]>
Sent: Monday, July 13, 2020 15:00
To: [e-mail] <[e-mail]>
Subject: Re: [dtn] DTN addressing, routing, and ownership 

 

I don't disagree that there are cases where certain schemes do and do not
make sense.  For example, using an IP address on a deep-space spacecraft
seems unnecessary and using an IPN address on a node on the Internet seems
unnecessary.  

 

Maybe a simpler question is: could I have a bundle whose source EID is
simply:  "www.eds_discount_emporium.com:1234'  and do we really need to
develop a new scheme to represent that?  

 

I certainly defer to those with more knowledge on URI syntax as to whether
BPbis should add a defined scheme id to its registry of allowed schemes.

 

-Ed

 

Edward J. Birrane, III, Ph.D.
Embedded Applications Group Supervisor
Principal Staff, Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 <tel:(443)%20778-7423>  / (F) 443-228-3839
<tel:(443)%20228-3839> 

 

From: [e-mail] <[e-mail]> 
Sent: Monday, July 13, 2020 2:53 PM
To: [e-mail]; Birrane, Edward J.
<[e-mail]>; [e-mail]
Subject: [EXT] Re: DTN addressing, routing, and ownership

 


APL external email warning: Verify sender [e-mail]
<mailto:[e-mail]>  before clicking links or attachments

 

Rick,

I considered both ways, but I think that, for the sake of argument here, the
http URI is the "primary" URI, with the IPN portion appended to it. However,
you're right, in that you should use the query component(s) as a delimiter.
If you use the URI query component as the BP EID, you can maintain full
compatibility with L4 load balancers, etc, which can perform forwarding
decisions based upon that query. That also maintains compatibility with
websocket URI's.

 

Thanks,

Jeremy

  _____  

From: Rick Taylor <[e-mail]
<mailto:[e-mail]> >
Sent: Monday, July 13, 2020 6:32:06 PM
To: Mayer, Jeremy; [e-mail]
<mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> 
Subject: RE: DTN addressing, routing, and ownership 

 

Hi Ed,

 

I'm with Jeremy on this.  HTTP makes a fine CLA as HTTP defines a transport
already.   The http:// schema specifies the address *and* the transport.

 

@Jeremy: would your example be better as
http+ipn:[ipn_parts]#[http_resource?query] ?

 

(One day I will finish my HTTP-REST CLA draft)

 

Rick

 

From: dtn [mailto:[e-mail]] On Behalf Of Jeremy.Mayer@dlr..de
<mailto:[e-mail]> 
Sent: 13 July 2020 15:48
To: [e-mail] <mailto:[e-mail]> ;
[e-mail] <mailto:[e-mail]> 
Subject: Re: [dtn] DTN addressing, routing, and ownership

 

Ed,

Throwing in my $0.02: I'm not entirely sure that http is a valid scheme from
this perspective. I consider http (& webSockets, IMAP, carrier pigeon, etc)
to be a "CLA++", where it's actually a last-hop convergence layer scheme. 

Therefore, it might be preemptive to start creating "non-DTN-specific"
scheme names. Instead, we should strongly consider the use of the
oft-forgotten-yet-completely-valid '+' character within the scheme name for
these types of use-cases. We can use that character to specify dtn/ipn
(which essentially outline the behavior of BP) and the the associated CLA
path. If we go this way, some schemes would look like: http+ipn://[http
URL]#[ipn URI]. 

 

Thanks,

Jeremy

  _____  

From: dtn <[e-mail] <mailto:[e-mail]> > on behalf of
Birrane, Edward J. <[e-mail]
<mailto:[e-mail]> >
Sent: Monday, July 13, 2020 3:57:29 PM
To: [e-mail] <mailto:[e-mail]> 
Subject: Re: [dtn] DTN addressing, routing, and ownership 

 

One other comment on supported EID schemes:

 

The split between DEST and DST_PORT does indeed formally exist for the ipn
EID scheme: node number and service number.  We could do the same sort of
thing for the dtn scheme, but the WG has not yet reached consensus on the
detailed syntax of dtn-scheme EIDs.  It's not that we haven't recognized
this issue, it's that the issue is addressed in the EID schemes rather than
in the protocol specification itself.

 

[EJB]  Looking at section 10.6 I see dtn: and ipn: as defined scheme names.
Is there something that breaks if we also allow an http: scheme in this
registry? For those simpler cases where late binding is *not* needed then a
standard IP is fine, and otherwise a "host name" or loopback can be used for
late binding instead. 

 

[EJB] In no way am I suggesting to  not use dtn: or ipn:, but perhaps http:
should also be included as a possibility?