Re: [dtn-interest] [dtn] DTN static routing

[waldir moreira <[e-mail]>]

Dear Nabil,
You can find dLife and its community version in the same link you mentioned on your email, under the user contribution section. There you will also find a the social-aware content-based opportunistic routing protocol, SCORP. There is nothing static about them as they are for the dynamic scenario we have witnessed for some year now.
http://www.netlab.tkk.fi/tutkimus/dtn/theone/#contrib
BR,

Waldir Aranha Moreira Junior, Ph.D.
Researcher at the Association for Research and Development in Cognition and People Centric Computing - COPELABSInvited Professor at University Lusofona - ULHT/ULPExternal collaborator of the Research Group on Computer Networks and Multimedia Communications - GERCOM/UFPA
LinkedIn profile

> From: [e-mail]
> Date: Thu, 23 Apr 2015 23:56:36 +0200
> To: [e-mail]
> CC: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [dtn] [dtn-interest] DTN static routing
> 
> Hello Nabil,
> 
> I wasn't at the DTNWG session, so I can not say what was discussed, but I have the feeling not everybody has the same idea when talking about "static routing",
> 
> Intuitively I would also argue that there is nothing to „work on" with regard to static routing. Of course implementations such as DTN2 or IBR-DTN already support static in such a way that you can configure rules such as „Forward packets matching this pattern to such and such EID". Granted, you might argue that current implementations are not flexible enough regarding how to specify such routes. But I would see this as an implementation issue, i.e. make feature requests (or better: submit pull requests :) ) to DTN2, ION or IBR-DTN.
> 
> Thinking more broadly this might lead to issues of "firewalling" and more flexible rules to route, mangle and redirecting bundles. As in „BPTables“ (which we had on the agenda for IBR-DTN for quite some time, but so far have only implemented partially). However, again I would say: Implementation issues.
> 
> When talking about working on something in the WG/RG I would expect some draft/RFC (hopefully with a working implementation to back it) to be the goal of any endeavours. So can you maybe state again
>  - What do you mean with „static routing“? What challenges need to be solved?
>  - What do you expect to be the outcome of working on/discussing it? A document? What kind? Some code?
> 
> 
>  Regards
> 
>  Sebastian
> 
> 
> 
> 
> > On 23 Apr 2015, at 23:40, Nabil Benamar <[e-mail]> wrote:
> > 
> > Dear Paulo,
> > 
> > 
> > On Thu, Apr 23, 2015 at 10:24 PM, Paulo Mendes <[e-mail]> wrote:
> > Dear Nabil
> > 
> > For me it makes no sense to talk about static routing when we are talking about networks that should be able exploit any forwarding opportunistic to overcome the problem of facing intermittent Internet connectivity. If you’re talking about Delay-tolerant Networks as in transmissions over long delay links, it makes no sense to talk about routing at all, since the problem is more a reliable transport problem. 
> > 
> > ​Not sure of the point! Many routing protocols in DTN are known and used (see http://www.netlab.tkk.fi/tutkimus/dtn/theone/)
> > ​ 
> > On the other hand if you are talking about Disruptive-tolerant Networks, then you need dynamic routing to overcome the intermittent connectivity, implementing a store-carry-forward algorithm.
> > 
> > ​In DTN, the store-carry-forward paradigm is also used.​ 
> > 
> > What chairs are you referring to? It should be from the new DTNWG and not from DTNRG. 
> > 
> > ​Exact! It was during DTNwg session​ ​in Dallas.
> > ​
> > To the best of my knowledge there were presented at least two routing proposals to DTNRG. One is Prophet, which is now RFC6693, and the other is dLife (https://datatracker.ietf.org/doc/draft-moreira-dlife/ ). dLife last version is the fourth one. In the meantime, due to lack of feedback, we didn’t releases version 5 in the DTNRG. Currently dLife is being exploited in the European project UMOBILE (http://www.umobile-project.eu).
> > 
> > ​May I ask whether dLife is implemented in any network simulator ?​ 
> > 
> > Paulo
> > 
> >> On 22 Apr 2015, at 15:18, Nabil Benamar <[e-mail]> wrote:
> >> 
> >> Hi All,
> >> 
> >> Thank you for your insights and comments!
> >> In fact, I have suggested during the DTN session in Dallas why not to work on Dynamic routing instead of static routing. I got an answer from the chairs that we don't know which routing protocols could be considered !! And this is the reason that pushed John and I to volunteer for static with the intention to provide a document (short or detailed ) on the aspect !
> >> 
> >> We do static routing in some cases even if Dynamic routing is available. It's the case when one wants a stable path (through a firewall) for the packets.
> >> 
> >> 
> >> On Wed, Apr 22, 2015 at 1:53 PM, Ivancic, William D. (GRC-LCA0) <[e-mail]> wrote:
> >> In line.
> >> 
> >> On 4/22/15 8:37 AM, "Greg Troxel" <[e-mail]> wrote:
> >> 
> >> >
> >> >"Ivancic, William D. (GRC-LCA0)" <[e-mail]> writes:
> >> >
> >> >> My understanding is Static mean hard wired.  You know what, where and
> >> >>when
> >> >> - similar to IP static routing where you know what and where.  No
> >> >>protocol
> >> >> is involved.  It is simply configuration.  You propagate the forwarding
> >> >> table.
> >> >>
> >> >> If I recall correctly, static routes usually get preference over dynamic
> >> >> routes.
> >> >
> >> >That makes sense.  I wonder then what it means to work on it
> >> 
> >> Me too.
> >> 
> >> >- to fix up
> >> >the reference implementation so that it has equivalents to "netstat -r",
> >> >"route add", etc.?  Or to write a document giving guidance to people
> >> >deciding which static routes to add?   Or ?
> >> 
> >> 
> >> I guess one thing would be to state whether or not the "when" is required.
> >> 
> >> 
> >> A second is to state whether "Static" or "Dynamic" has precedence.
> >> Actually, I prefer dynamic if it is available. If you are doing Static
> >> routing, it is because you do not have Dynamic routing. Static tends to
> >> get you in trouble.  We may think we know all, but we usually don't.
> >> 
> >> I think this should be a very short document.  Maybe it could actually be
> >> incorporated into 5050bis or some other document that states default
> >> assumptions.
> >> 
> >> Will
> >> 
> >> 
> >> 
> >> 
> >> -- 
> >> 
> >> Best Regards
> >> 
> >> 
> >> 
> >> nabilbenamar.ipv6-lab.net
> >> 
> >> 
> >> 
> >> _______________________________________________
> >> dtn-interest mailing list
> >> [e-mail]
> >> https://www.irtf.org/mailman/listinfo/dtn-interest
> > 
> > Melhores Cumprimentos/Best Regards/Mit Freundlichen Gruessen
> > Paulo Mendes
> > ------------------------------------------------------------
> > Paulo Mendes, Ph.D
> > Vice-director of the Research Unit in Cognition and People Centric Computing (COPELABS)
> > Director of the Ph.D program on Informatics - New Media and Pervasive Systems (NEMPS)
> > Associated Professor at University Lusofona, Portugal
> > 
> > http://copelabs.ulusofona.pt/~pmendes
> > Tel.: [phone]
> > 
> > 
> > 
> > 
> > -- 
> > 
> > Best Regards
> > 
> > نبيل بنعمرو
> > 
> > nabilbenamar.ipv6-lab.net
> > 
> > 
> > 
> > _______________________________________________
> > dtn-interest mailing list
> > [e-mail]
> > https://www.irtf.org/mailman/listinfo/dtn-interest
> 
> _______________________________________________
> dtn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dtn