<div dir="ltr">While any solution must be based on the specific application scenario, there are still some general guidelines that you may consider:<div><br></div><div>1/ Producer mobility is hard because the consumer has to shoot Interest to a moving target. Therefore the principle is to find something invariant and use that as an indirection, which is essentially the same idea as locator/id separation.</div><div><br></div><div>2/ One way to do that is to directly apply the LISP concept to the NDN network: you can assign a location-independent name to the producer and let the producer register its current location to a general mapping system (e.g, NDNS); then the consumer can send Interest to the producer's latest location using either Interest encapsulation or forwarding hint.</div><div><br></div><div>This design is useful if your application must enforce P2P communication (e.g., if you want to send control commands to a specific sensor on a plane that is flying from LAX to JFK).</div><div><br></div><div>3/ A more NDN-ish design (in my opinion) is to use rendezvous point as indirection: you can have your producer publish its data to a well-known location, such as an NDN repo, so that the consumer can fetch data from the repo instead of talking to the producer directly.</div><div><br></div><div>This design also applies to sensor networks where the producer has limited storage capacity and/or low duty-cycle so that it must offload the data storage task to a more powerful device.</div><div><br></div><div>4/ I remember Prof. Lixia showed us some slides in her class about the idea of NDN routing via self-learning. The key idea is to utilize NDN's stateful forwarding plain to estimate the validity of a route on the fly. Unfortunately I couldn't remember any reference for that work.</div><div><br></div><div>Hope this may be helpful to your research.</div><div><br></div><div>Wentao<br><br><div class="gmail_quote">On Sun Feb 15 2015 at 3:47:47 AM Muhammad Hosain Abdollahi Sabet <<a href="mailto:M.AbdollahiSabet@mail.sbu.ac.ir">M.AbdollahiSabet@mail.sbu.ac.ir</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>
<div>
<p><font>Good point! I agree that NDN supports subscriber mobility in it's nature and as you said most of mobility issues in subscriber-side scenarios disappear automatically. But what about some producer ones? As an example, the application scenario we are talking about could be voice/video chat when both caller and callee are mobile. How could we consider it in a non-P2P model?<br>
<br>
Could you please guide me to find about possibility for intelligent broadcast/multicast using self-learning path selection ?</font></p></div><div><p><font><br>
<br>
<br>
-----Original Message-----<br>
From: Wentao Shang [<a href="mailto:wentaoshang@gmail.com" target="_blank">mailto:wentaoshang@gmail.com</a>]<br>
Sent: Sun 2/15/2015 3:47 AM<br>
To: Muhammad Hosain Abdollahi Sabet; Lixia Zhang; <a href="mailto:ndn-interest@lists.cs.ucla.edu" target="_blank">ndn-interest@lists.cs.ucla.edu</a><br>
Subject: Re: [Ndn-interest] NDN-friendly Mobility solutions<br>
<br></font></p></div><div><p><font>
On Sat Feb 14 2015 at 9:26:50 AM Muhammad Hosain Abdollahi Sabet <<br>
<a href="mailto:M.AbdollahiSabet@mail.sbu.ac.ir" target="_blank">M.AbdollahiSabet@mail.sbu.ac.ir</a>> wrote:<br>
<br>
> Thank you so much for answering.<br>
> Actually it struck my mind that "it" is unclear, which I'm sorry for the<br>
> ambiguity. The second one was the closest one. I meant: "Is the solution<br>
> for producer-side mobility clear enough that there hasn't been real attempt<br>
> about it?<br></font></p></div><div><p><font>
> I'll be absolutely glad to help. ?As far as I understand we have another</font></p></div><div><p><font><br>
> paradigm shifting again in some mobility application scenarios like mobile<br>
> caller-callee. NDN shifts networking from host-centric(point to point) to a<br>
> content-centric architecture. And now we want to make point to point<br>
> connection overlay of NDN. Right?<br>
><br>
Not sure why you want to make point-to-point connection over NDN. Is it a<br>
requirement from specific application in your mind? NDN shifts away from<br>
the P2P connection model and therefore provides new opportunity for better<br>
mobility support. Perhaps it is more efficient to design your application<br>
in the NDN model (in which case some mobility issue may disappear<br>
automatically) than to fit the old model into the new architecture.<br>
<br>
<br>
> So I think using some IP-like producer mobility solutions is not<br>
> avoidable. On the other hand some of NDN features like being broadcast<br>
> finendly which is referred to in "A New Perspective in Mobility Support''<br>
> as a suggestion, isn't practical in large scale because of producing heavy<br>
> overhead of controlling data(specially in hard-state mode).<br>
><br>
Broadcast is impractical for large scale IP network. But NDN has a smarter<br>
forwarding plain which opens possibility for intelligent<br>
broadcast/multicast using self-learning path selection and traffic<br>
reduction.<br>
<br>
Different mobility solutions are designed for different application<br>
scenarios. In some extreme cases where the network is so dynamic that it is<br>
impossible to maintain a stable topology, broadcast/multicast may be the<br>
only choice.<br>
<br>
<br>
> Furthermore, hierarchical naming brings some location dependency,<br>
><br>
It is not that hierarchical naming brings location dependency. Any<br>
identifier that is used in routing and forwarding will cause location<br>
dependency. That's why people invented the concept of Locator/ID<br>
separation, which is mentioned in the mobility TR. The "forwarding hint" is<br>
one way to implement that in NDN.<br>
<br>
Wentao<br>
<br>
<br>
> and maybe we need some conventions in this field, in which network can<br>
> approximate location of endpoint while pinpointing location of endpoint can<br>
> be postponed to last steps.<br>
> I just listed some of the challenges I faced till now. I'll be grateful to<br>
> know your opinion about them.<br>
><br>
> Thanks again,<br>
> Sabet<br>
><br>
><br>
><br>
><br>
> -----Original Message-----<br></font></p></div><div><p><font>
> From: Lixia Zhang [<a href="mailto:lixia@cs.ucla.edu" target="_blank">mailto:lixia@cs.ucla.edu</a> <<a href="mailto:lixia@cs.ucla.edu" target="_blank">lixia@cs.ucla.edu</a>>]<br>
> Sent: Fri 2/13/2015 8:26 PM<br>
> To: Muhammad Hosain Abdollahi Sabet<br>
> Cc: <a href="mailto:ndn-interest@lists.cs.ucla.edu" target="_blank">ndn-interest@lists.cs.ucla.edu</a><br>
> Subject: Re: [Ndn-interest] NDN-friendly Mobility solutions<br>
><br>
><br>
> > On Feb 12, 2015, at 2:16 PM, Muhammad Hosain Abdollahi Sabet <<br>
> <a href="mailto:M.AbdollahiSabet@mail.sbu.ac.ir" target="_blank">M.AbdollahiSabet@mail.sbu.ac.ir</a>> wrote:<br>
> ><br>
> > Hello everyone.<br>
> > I've been studying NDN for a couple of months now. For supporting<br>
> mobility in environments without any clear infrastructure and topology like<br>
> MANET (VANET in particular), it's been developing like a charm. But as far<br>
> as I've learned, it's producer-side mobility support in large scales still<br>
> has some serious challenges, particularly in scenarios like mobile<br>
> caller-callee. And as "A New Perspective on Mobility Support" has reported,<br>
> none of the proposed solutions(Proxy based, Rendezvous point based, ...)<br>
> seems to have a NDN-likely technique. I'm eager to work on it as my B.S<br>
> thesis. But the problem is, when I look at the ICN workshops, conferences,<br>
> articles, posters, demos and etc, I cannot find real attempts on<br>
> this(unless Kite I may say). Not that I've seen for example about Routing<br>
> or Security. And now I'm wondering: Is it really that clear?! Maybe you can<br>
> guide me to a vision I don't have.<br>
> ><br>
> > Thanks,<br>
> > Sabet<br>
><br>
> Sabet,<br>
><br>
> thanks for your msg. I wonder what you meant by "Is it really that<br>
> clear?!".<br>
> If you are asking whether it is clear that NDN can offer superior mobility<br>
> support than TCP/IP, then you know the answer is YES, right?<br>
> If you are asking whether mobile producer solutions have been fully<br>
> developed: it is still being developed, hence the need for your effort on<br>
> this problem. We *are* developing solutions, first for specific<br>
> application scenarios, which help us understand how to provide general<br>
> solutions.<br>
> If you are asking for examples of routing solutions: I'm sure you've seen<br>
> NLSR work as an example; we are also actively working on hyperbolic routing<br>
> as potential long term directly.<br>
> For security, you may look into recent NDN retreat which focused on<br>
> security solution development.<br>
><br>
> Lixia<br>
><br>
><br>
><br>
> _______________________________________________<br>
> Ndn-interest mailing list<br>
> <a href="mailto:Ndn-interest@lists.cs.ucla.edu" target="_blank">Ndn-interest@lists.cs.ucla.edu</a><br>
> <a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" target="_blank">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><br>
><br>
<br>
</font></p></div></blockquote></div></div></div>