Re: [dtn-interest] Can we implement DTN in Network layer of protocol stack ?

[Ezra Kissel <[e-mail]>]

This list might be interested in our work on the eXtensible Session 
Protocol and our notion of a session-enabled buffer-and-burst model for 
data movement.  While our focus has been on high-performance, bulk data 
transfers, I believe our model could in many ways address what the 
original poster had in mind.

(PFLDNet 2010)
http://damsl.cis.udel.edu/projects/phoebus/phoebus_slabs.pdf

It has occurred to us on more than one occasion that we could apply our 
store-and-forward approach for managing the interaction between MANETs 
and DTNs, as well as optimizing WAN transfers for frequently 
disconnected endpoints where the latency of individual PDUs is less of a 
concern.

We would also very much welcome exploring the commonalities of BP with 
our notion of a Session-PDU within the DTNRG.

Regards,
- ezra

On 5/9/2012 8:26 AM, Scott, Keith L. wrote:
> Do you mean ‘can DTN be implemented underneath the sockets API’? And, if
> you want this to be completely transparent to applications, presumably
> ‘hiding underneath SOCK_STREAM or SOCK_DGRAM’?
>
> In a sense, there’s nothing in IP that prevents you from storing IP
> datagrams while waiting for a forward path to become available; the
> issues in implementing IP this way all have to do with the things around
> IP, e.g.:
>
> ·Routing implementations that drop datagrams when no next hop is available
>
> ·ARP (which has timeouts)
>
> ·DNS queries (which have timeouts)
>
> ·Routing protocols like OSPF (which have timeouts and which typically do
> not deal well with either scheduled connectivity or temporary partitions)
>
> ·Applications that expect either 1) real-time connectivity from IP –or-
> 2) no connectivity (but not a possibly-delayed store-and-forward service)
>
> Routing’s probably NOT an issue here if we’re talking about MANETs since
> we could tweak the MANET routing protocols, but some of the others (esp.
> application expectations) are a bit problematic. You’d also need to
> worry about how/if you want to implement things like custody transfer,
> the various bundle notifications, etc.
>
> That said, there are implementations of BP that live underneath IP (BBN
> has an implementation that does this). The chances are that the class of
> applications that would be amenable to ‘transparent’ transplantation to
> use BP services are UDP-based, and for these (if the applications don’t
> have timers that would preclude it) you might consider using the DTN
> Tunnel that’s in the DTN2 reference implementation or an equivalent.
> That is, if the application can handle it, just tunnel UDP over BP. If
> the application can’t handle it, then hiding BP underneath the sockets
> API wouldn’t work (without modifying the application) anyway.
>
> Another approach would be to ask: what’s the MANET getting you that
> DTN/BP can’t (or doesn’t)?
>
> --keith
>
> *From:*[e-mail]
> [mailto:[e-mail]] *On Behalf Of *zhd5408
> *Sent:* Wednesday, May 09, 2012 4:56 AM
> *To:* dtn-interest
> *Subject:* [dtn-interest] Can we implement DTN in Network layer of
> protocol stack ?
>
> Now almost all the DTN implement with Adding bundle layer between
> application and transport layer.
>
> These DTN are separated with MANET completely, all the data from MANET
> should be translated through the DTN gateway and all the applications
> used in DTN must be redesigned.But MANET and DTN can coexist in some cases.
>
> I wonder that whether can we design DTN via modifying the network layer,
> not using BP. Thus the MANET and DTN can coexist and it is transparent
> for upper layers. All the applications don't need to modify.
>
> If to do so. What problems will encounter? or is it possible?
>
> ------------------------------------------------------------------------
>
> heyeast
>