<div dir="ltr">Thanks a lot Klaus. In my previous email what I meant by<i> If the router is temporarily down, it can resume to its normal operations sometime later </i>is when the router resumes, what about the LSAs it had before going down? Of course for access router has to re-establish the tunnel for further operations.</div><br><div class="gmail_quote"><div dir="ltr">On Tue, Nov 20, 2018 at 3:03 AM Klaus Schneider <<a href="mailto:klaus@cs.arizona.edu">klaus@cs.arizona.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> The nfd connection states that after installing NFD in a client machine, <br>
>> we can specify the IP address and port number of the remote NFD, so that <br>
>> NDN packets get encapsulated into UDP or TCP packets and sent to the <br>
>> remote NFD. e.g. nfdc create udp4://<a href="http://192.0.2.1:6363" rel="noreferrer" target="_blank">192.0.2.1:6363</a> <br>
<br>
You are talking about running NDN over IP tunnels (here, UDP tunnels). <br>
However, these tunnels only exist for point-to-point communication <br>
between routers to make NDN run over IP networks. They could easily be <br>
replaced by an Ethernet face (if there was a direct Layer 2 connection <br>
between two routers).<br>
<br>
When using the word connection in your earlier sense ("and the <br>
connections [a router] holds", "take care the connections of the nodes") <br>
I assumed you are talking about a transport layer connection as it <br>
exists in TCP between client and server.<br>
<br>
However, this transport layer connection does not exist in NDN. A router <br>
does not maintain any connection state, thus nothing dramatic happens to <br>
the packet flow after a router goes down. You will lose a number of <br>
Interests/Data packets that would have gone through the router, but <br>
these can quickly be retransmitted, and will find a different path to <br>
the repository (if it exists).<br>
<br>
> when a <br>
>> new ndn node wants to enter in an existing network and establish a <br>
>> connection with a node of the network, it does the above thing, isn't <br>
>> it?<br>
<br>
This is different from the idea of a transport-layer connection, as <br>
described above. If your node could have a wired Ethernet connection to <br>
an NDN router, this step wouldn't be necessary. You could just send <br>
Interests to that router without needing an IP address.<br>
<br>
Moreover, I don't think it's related to routers going down, unless you <br>
are talking about your access router. In this case, you will (of course) <br>
need to re-establish the tunnel to the access router after it comes back up.<br>
<br>
<br>
<br>
Best regards,<br>
Klaus<br>
<br>
<br>
<br>
<br>
On 11/19/18 2:15 PM, Tanusree Chatterjee wrote:<br>
> Hello Klaus,<br>
> <br>
> Thank you. It cleared my doubts to some extent. But, you said that there <br>
> is no notion of connection in NDN and I did not understand what does it <br>
> exactly mean.<br>
> The nfd connection states that after installing NFD in a client machine, <br>
> we can specify the IP address and port number of the remote NFD, so that <br>
> NDN packets get encapsulated into UDP or TCP packets and sent to the <br>
> remote NFD. e.g. nfdc create udp4://<a href="http://192.0.2.1:6363" rel="noreferrer" target="_blank">192.0.2.1:6363</a> <br>
> <<a href="http://192.0.2.1:6363/" rel="noreferrer" target="_blank">http://192.0.2.1:6363/</a>> states the client machine wants to establish a <br>
> connection with <a href="http://192.0.2.1:6363" rel="noreferrer" target="_blank">192.0.2.1:6363</a> <<a href="http://192.0.2.1:6363/" rel="noreferrer" target="_blank">http://192.0.2.1:6363/</a>>. Also as <br>
> Junaxio's explained in my last email answer that NDN-FCH service tells <br>
> us the IP of the routers near by. However, here I am a bit confused why <br>
> there is no notion of a connection. As my previous question was when a <br>
> new ndn node wants to enter in an existing network and establish a <br>
> connection with a node of the network, it does the above thing, isn't <br>
> it? Please tell me if I understood anything wrong.<br>
> <br>
> Thanks & Regards,<br>
> Tanusree Chatterjee<br>
> <br>
> On Nov 19, 2018 11:08 PM, "Klaus Schneider" <<a href="mailto:klaus@cs.arizona.edu" target="_blank">klaus@cs.arizona.edu</a> <br>
> <mailto:<a href="mailto:klaus@cs.arizona.edu" target="_blank">klaus@cs.arizona.edu</a>>> wrote:<br>
> <br>
> Hey Tanusree,<br>
> <br>
> I think it's useful to distinguish between 3 logical entities:<br>
> <br>
> 1. Router -- forwards packets towards a storage location<br>
> 2. Content Store -- a temporary storage location (can be cleared at<br>
> any time)<br>
> 3. Content Repository -- a permanent storage location (in the same<br>
> sense as today's web servers are "permanent")<br>
> <br>
> These can all be on the same machine or on a different machine. For<br>
> example, a core NDN router will probably have a content store, but<br>
> not a content repository.<br>
> <br>
> Now to answer your questions:<br>
> <br>
> So, if a router is down for some reason, what about the data it<br>
> <br>
> stores in its CS and the connections it hold?<br>
> <br>
> <br>
> Well, the content store will be unreachable. There is usually no<br>
> notion of a "connection" in NDN, so other routers should be able to<br>
> fetch the data from somewhere else.<br>
> <br>
> If the router is<br>
> <br>
> temporarily down, it can resume to its normal operations<br>
> sometime later<br>
> <br>
> <br>
> Sure. Why not?<br>
> <br>
> But if the router is permanently down and there are several data<br>
> <br>
> it produce and there are no more copies of all the data.<br>
> <br>
> <br>
> That only matters if the last content repository is down. In this<br>
> case the data might become unavailable, if all the content stores<br>
> have cleared the data as well (which they are free to do).<br>
> <br>
> NDN does not have the goal to permanently replicate every content<br>
> piece inside the network. The content provider is still responsible<br>
> for keeping their content repository up and running, and likely<br>
> wants to provide some redundancy here.<br>
> <br>
> NDN, however, can help with the scalability: it reduces the load on<br>
> the content repository when its content objects become more popular.<br>
> <br>
> <br>
> Best regards,<br>
> Klaus<br>
> <br>
> <br>
> <br>
> On 11/19/18 2:32 AM, Tanusree Chatterjee wrote:<br>
> <br>
> Hello all,<br>
> <br>
> In NDN the routers are the busiest and most responsible entity<br>
> in the network. So, if a router is down for some reason, what<br>
> about the data it stores in its CS and the connections it hold?<br>
> If the router is temporarily down, it can resume to its normal<br>
> operations sometime later. But if the router is permanently<br>
> down and there are several data it produce and there are no more<br>
> copies of all the data. Can there be any network administrator<br>
> which can have the copies of the data of a router when it is<br>
> down? If it is a high connectivity node, can network<br>
> administrator can play a vital roll to take care the connections<br>
> of the nodes?<br>
> <br>
> -- Thanks & Regards,<br>
> Tanusree Chatterjee<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>
> <mailto:<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" rel="noreferrer" target="_blank">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><br>
> <<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" rel="noreferrer" target="_blank">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a>><br>
> <br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Tanusree Chatterjee<br>M:9836337175</div>