<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<div>This depends on the strategy. It could work in the way you described. Or the edge router could forward the interest using one of the delegated names. It should bring back data. If there's no data back, then it could try another one of the delegated
names. </div>
<div><br>
</div>
<div>Note that in NDN, the delegated names are names too, not addresses. For example, /ndnsim/net could be delegated to /com/att/user/alex/ndnsim.</div>
<div apple-content-edited="true">
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px; ">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<br class="Apple-interchange-newline">
Lan</div>
</span></div>
</div>
</div>
<br>
<div>
<div>On Mar 2, 2015, at 2:40 AM, Muhammad Hosain Abdollahi Sabet <<a href="mailto:M.AbdollahiSabet@mail.sbu.ac.ir">M.AbdollahiSabet@mail.sbu.ac.ir</a>> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta name="Generator" content="MS Exchange Server version 6.5.7652.24">
<title>RE: [Ndn-interest] Data Accessibility in VM Live Migration over NDN</title>
<div><!-- Converted from text/plain format -->
<p><font size="2">Hi,<br>
Let assume we have tow copies and the MAP-AND-ENCAP mechanism implemented. Which route would be selected? I mean, the edge router sends the interest to both addresses(the old one, and the new old received from NDNS), right? Then depending on the measurements
done by itself(the edge router), future interest will be sent to the designated route, and the endpoint application won't notify any of this. Am I right?<br>
<br>
Thanks,<br>
Sabet<br>
<br>
-----Original Message-----<br>
From: Ndn-interest on behalf of Xiaoke Jiang<br>
Sent: Sat 2/28/2015 9:38 PM<br>
To: Dejiang Zhou<br>
Cc: <a href="mailto:ndn-interest@lists.cs.ucla.edu">ndn-interest@lists.cs.ucla.edu</a><br>
Subject: Re: [Ndn-interest] Data Accessibility in VM Live Migration over NDN<br>
<br>
Hi Dejiang,<br>
Here is my opinion to your question. What mentioned here seems to be producer mobility support, which is on-going research among NDN. A straightforward solution is to let UMICH router announce the a prefix /ndn/cn/edu/tongji/vm/ping to routing system.
Besides the routing approach, there are some proposals too address this problem<br>
1) Kite: <a href="http://named-data.net/publications/techreports/tr-ndn20-kite/">
http://named-data.net/publications/techreports/tr-ndn20-kite/</a> <<a href="http://named-data.net/publications/techreports/tr-ndn20-kite/">http://named-data.net/publications/techreports/tr-ndn20-kite/</a>> <br>
2) LINK+ Map-and-Encap: may also helps but need more efforts: <a href="http://named-data.net/techreport/ndn-0004-3-scaling-ndn-routing.pdf">
http://named-data.net/techreport/ndn-0004-3-scaling-ndn-routing.pdf</a> <<a href="http://named-data.net/techreport/ndn-0004-3-scaling-ndn-routing.pdf">http://named-data.net/techreport/ndn-0004-3-scaling-ndn-routing.pdf</a>><br>
<br>
p.s., I wonder why not keep the original copy of the vm after migration, therefore you would have two copies can serve future requests.<br>
<br>
Xiaoke (Shock)<br>
<br>
<br>
<br>
> On 28 Feb, 2015, at 2:12 am, Dejiang Zhou <<a href="mailto:dejiang_zhou@163.com">dejiang_zhou@163.com</a>> wrote:<br>
><br>
> Hi everyone,<br>
> I have been studying VM live migration over NDN for mouths and taking some experiments in NDN testbed.<br>
> VM is migrated from China to America with source host connecting NDN testbed node of Tongji and destination host in America connecting UMICH testbed node. Data in VM can be accessed by other host at the beginning. Name of Data can be "/ndn/cn/edu/tongji/vm/ping".
However, this Data cannot be accessed after migration because the name of Data is not registered to FIB of other host. Other host is able to access the Data before migration because Interest can be forwarded to Tongji University by name prefix "/ndn/cn/edu/tongji".
In contrast, Interest with name "/ndn/cn/edu/tongji/vm/ping" cannot be forwarded to VM after migration because VM is behind UMICH testbed node but name prefix of the requested Data is not "/ndn/edu/umich".<br>
> Does anyone have an idea for solving the problem? I think the rule of the solution is that name of Data in VM should not be changed after migration.<br>
> Best regards,<br>
> Dejiang Zhou<br>
><br>
><br>
> _______________________________________________<br>
> Ndn-interest mailing list<br>
> <a href="mailto:Ndn-interest@lists.cs.ucla.edu">Ndn-interest@lists.cs.ucla.edu</a><br>
> <a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><br>
<br>
<br>
<br>
</font></p>
</div>
_______________________________________________<br>
Ndn-interest mailing list<br>
<a href="mailto:Ndn-interest@lists.cs.ucla.edu">Ndn-interest@lists.cs.ucla.edu</a><br>
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest<br>
</blockquote>
</div>
<br>
</body>
</html>