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

["Burleigh, Scott C (US 312B)" <[e-mail]>]

Brian, one note of clarification: BP EIDs are not necessarily encoded as URLs (e.g., the ipn-scheme EIDs are not URLs).  They're URIs, per 4.1.5.1, so both URLs and URNs can be accommodated; we just have to work out the details.  As you say, the fact that a dtn-scheme EID is encoded to look like a URL instead of URN is a fact of life at this point.

Speaking of CoAP, you might want to check out the taraCoAP work from Antara Teknik, which is intended to provide a RESTful interface for DTN.  They've got a fully functional prototype but I don't think anybody has deployed it yet.

Scott

From: dtn <[e-mail]> On Behalf Of Brian Sipos
Sent: Wednesday, July 15, 2020 9:44 AM
To: Birrane, Edward J. <[e-mail]>; [e-mail]
Subject: [EXTERNAL] Re: [dtn] DTN addressing, routing, and ownership

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]<mailto:[e-mail]>> on behalf of Birrane, Edward J. <[e-mail]<mailto:[e-mail]>>
Sent: Monday, July 13, 2020 15:00
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Monday, July 13, 2020 2:53 PM
To: [e-mail]<mailto:[e-mail]>; Birrane, Edward J. <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[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 <rick@tropicalstormsoftware..com<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?