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

From: zhd5408 <[email-masked]>
Date: Wed, 9 May 2012 16:56:07 +0800

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

---

From: "Scott, Keith L." <[email-masked]>
Date: Wed, 9 May 2012 12:26:27 +0000

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: [email-masked] [mailto:[email-masked]] 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 ?

________________________________
heyeast

---

From: Ezra Kissel <[email-masked]>
Date: Thu, 10 May 2012 12:32:06 -0400

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:[email-masked]
> [mailto:[email-masked]] *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 ?
>
> 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.
>
> ------------------------------------------------------------------------
>
> heyeast
>

---

From: heyeast <[email-masked]>
Date: Fri, 11 May 2012 16:18:54 +0800

hi Vint Cerf:
In high loss/latency environment, DTN is implicit the best choice for us. However, we focus on the wireless environment with low latency but sometime the link will disconnect for a few time. In other words, we wish using DTN to enhance the MANET's reliable and robust.

As keith refer, now BBN technology has implement WNaN with handling BP under IP stack and transparent for upper layers.

heyeast

From: Vint Cerf
Date: 2012-05-09 18:21
To: zhd5408
Subject: Re: [dtn-interest] Can we implement DTN in Network layer of protocol stack ?
I think the problem is that the logic and behavior of DTN is different
from IP. Most of the IP-based protocols assume low latency while DTN
assume high latency and loss. The result is that hiding the BP (or DTN
functionality) in the network layer leads to applications that will be
confused or just fail when operating in a high loss/latency
environment. UDP applications don't necessarily work either if they
assume implicit low latency.

v

On Wed, May 9, 2012 at 4:56 AM, zhd5408 <[email-masked]> wrote:
> 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.
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/dtn-interest
>

---

From: Vint Cerf <[email-masked]>
Date: Fri, 11 May 2012 04:21:14 -0400

so the "transparency" assertion is of interest - DTN/BP is intended to
be very resilient in the face of disconnection - IP is nominally not
so "patient" - so how is this "transparency" achieved?

vint

On Fri, May 11, 2012 at 4:18 AM, heyeast <[email-masked]> wrote:
> hi Vint Cerf:
> In high loss/latency environment, DTN is implicit the best choice for us.
> However, we focus on the wireless environment with low latency but sometime
> the link will disconnect for a few time. In other words, we wish using DTN
> to enhance the MANET's reliable and robust.
>
> As keith refer, now BBN technology has implement WNaN with handling BP under
> IP stack and transparent for upper layers.
>

---

From: heyeast <[email-masked]>
Date: Fri, 11 May 2012 16:49:25 +0800

Hi keith:

Thanks for your attention. To the question "what’s the MANET getting you that DTN/BP can’t (or doesn’t)?" my answer is, in some critical MANET environments link  will disconnect frequently.It is a MANET scenario but not a DTN scenario completely. Maybe MANET can't handle these disconnect.So we wish using DTN to enhance the reliability and robust of the MANET.  implement DTN in network layer, thus can be used for MANET.

The WNaN developed by BBN Technology is amazing. But it is not open for us. I have read this paper "The DARPA WNaN Network Architecture " about that. It is heuristic for me. Firstly it tells me it is possible for me to do this. although it is so difficulty.    I will also consider the DTN Tunnel in DTN2 seriously.

Thank u again. 

heyeast

From: Scott, Keith L.
Date: 2012-05-09 20:26
To: zhd5408; dtn-interest
Subject: RE: [dtn-interest] Can we implement DTN in Network layer of protocol stack ?
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: [email-masked] [mailto:[email-masked]] 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 ?

 

heyeast

---

From: heyeast <[email-masked]>
Date: Fri, 11 May 2012 17:06:22 +0800

I have read this paper. Buffer-and-burst model refer in this paper is very interesting. But I think your focus is mainly on the data movement and high-performance. less handling on the disconnect of the link. I think the notion is similar to the BP. and the work is also valuable for us.

regards.

heyeast

From: Ezra Kissel
Date: 2012-05-11 00:32
To: Scott, Keith L.
CC: zhd5408; dtn-interest
Subject: Re: Re: [dtn-interest] Can we implement DTN in Network layer of protocol stack ?
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)

Regards,
- ezra

On 5/9/2012 8:26 AM, Scott, Keith L. wrote:
> Do you mean 慶an DTN be implemented underneath the sockets API? And, if
> 慼iding underneath SOCK_STREAM or SOCK_DGRAM?
>
> In a sense, there抯 nothing in IP that prevents you from storing IP
> 稲outing implementations that drop datagrams when no next hop is available
>
> 稟RP (which has timeouts)
>
> 稤NS queries (which have timeouts)
>
> 稲outing protocols like OSPF (which have timeouts and which typically do
> 稟pplications that expect either 1) real-time connectivity from IP 杘r-
> Routing抯 probably NOT an issue here if we抮e talking about MANETs since
> application expectations) are a bit problematic. You抎 also need to
> applications that would be amenable to 憈ransparent?transplantation to
> use BP services are UDP-based, and for these (if the applications don抰
> Tunnel that抯 in the DTN2 reference implementation or an equivalent.
> the application can抰 handle it, then hiding BP underneath the sockets
> API wouldn抰 work (without modifying the application) anyway.
>
> Another approach would be to ask: what抯 the MANET getting you that
> DTN/BP can抰 (or doesn抰)?
>
> --keith
>

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Fri, 11 May 2012 14:52:38 +0000

An even easier solution might be the BPTAP implementation described in http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=06187106.  BPTAP is unfortunately not publicly releasable due to ITAR restrictions, but not because it's a real defense article, simply because of the way its development was funded.  We're working on a different, and I think more capable, implementation that's funded in a way that will enable JPL to at least license it and possible release it as open source.  But it's not ready yet.
Scott
From: [email-masked] [mailto:[email-masked]] On Behalf Of heyeast
Sent: Friday, May 11, 2012 1:49 AM
To: Scott, Keith L.
Cc: dtn-interest
Subject: Re: [dtn-interest] Can we implement DTN in Network layer of protocol stack ?

Hi keith:

Thanks for your attention. To the question "what's the MANET getting you that DTN/BP can't (or doesn't)?" my answer is, in some critical MANET environments link  will disconnect frequently.It is a MANET scenario but not a DTN scenario completely. Maybe MANET can't handle these disconnect.So we wish using DTN to enhance the reliability and robust of the MANET.  implement DTN in network layer, thus can be used for MANET.

Thank u again.

From: Scott, Keith L.<mailto:[email-masked]>
Date: 2012-05-09 20:26
To: zhd5408<mailto:[email-masked]>; dtn-interest<mailto:[email-masked]>
Subject: RE: [dtn-interest] Can we implement DTN in Network layer of protocol stack ?
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.:

1.  Routing implementations that drop datagrams when no next hop is available

2.  ARP (which has timeouts)

3.  DNS queries (which have timeouts)

4.  Routing protocols like OSPF (which have timeouts and which typically do not deal well with either scheduled connectivity or temporary partitions)

5.  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: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> 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 ?

---

From: Armando Caro <[email-masked]>
Date: Fri, 11 May 2012 11:19:13 -0400

Vint,

BBN's BP stack uses the IP ToS bits to determine which IP packets can 
tolerate delay and which cannot. BBN's BP implementation provides 
configuration options to control which ToS bits are provided DTN 
service. All IP packets are BP encapsulated, but not all IP packets are 
provided DTN service.

Armando

On 05/11/2012 04:21 AM, Vint Cerf wrote:
> On Fri, May 11, 2012 at 4:18 AM, heyeast<[email-masked]>  wrote:
>> hi Vint Cerf:
>> On Wed, May 9, 2012 at 4:56 AM, zhd5408<[email-masked]>  wrote: