From unict.signorello at gmail.com Mon Aug 4 08:55:47 2014 From: unict.signorello at gmail.com (Salvatore Signorello) Date: Mon, 04 Aug 2014 17:55:47 +0200 Subject: [Ndn-interest] NLSR security settings Message-ID: <1407167747.2322.35.camel@localhost.localdomain> Hi all, I'm not able to figure out why they've provided a different sequence of commands into the security settings tutorial "$NLSR_HOME/docs/SECURITY.md" between point 1 and points 2,3,4 into the section "##Example". That is, in point 1 they use two commands to generate a signed-certificate of the key: $ndnsec-key-gen -n /ndn $ndnsec-sign-req /ndn > root.cert even if the same result can be obtained just using the first command $ndnsec-key-gen -n /ndn > root.cert as they do after for the other keys in points 2,3,4. I understand that they wanted to outline that in the first case the key has been self-signed, but I would have used just one command putting some more info into the filename, e.g., $ndnsec-key-gen -n /ndn > self-signed_root.cert imho what could be misleading going through the tutorial is the fact that thereafter in points 2-3-4 they use filenames with the prefix "unsigned-" to name keys that are indeed signed. And what about the option of fetching a unsigned version of the key using another ndnsec tool and passing that one to ndnsec-cert-gen, would it feel better? Please let me know if I've well understood or I've missed something important, best, Salvo From ahoque1 at memphis.edu Mon Aug 4 09:04:07 2014 From: ahoque1 at memphis.edu (A K M Mahmudul Hoque (ahoque1)) Date: Mon, 4 Aug 2014 16:04:07 +0000 Subject: [Ndn-interest] NLSR security settings In-Reply-To: <1407167747.2322.35.camel@localhost.localdomain> References: <1407167747.2322.35.camel@localhost.localdomain> Message-ID: <1407168247137.28968@memphis.edu> ________________________________________ From: Ndn-interest on behalf of Salvatore Signorello Sent: Monday, August 4, 2014 10:55 AM To: ndn-interest at lists.cs.ucla.edu Subject: [Ndn-interest] NLSR security settings Hi all, I'm not able to figure out why they've provided a different sequence of commands into the security settings tutorial "$NLSR_HOME/docs/SECURITY.md" between point 1 and points 2,3,4 into the section "##Example". That is, in point 1 they use two commands to generate a signed-certificate of the key: $ndnsec-key-gen -n /ndn $ndnsec-sign-req /ndn > root.cert even if the same result can be obtained just using the first command $ndnsec-key-gen -n /ndn > root.cert ---- Yes you are correct. We kept two steps here so that every key signing looks same ---- at least the number of steps. Thank you for your feedback as they do after for the other keys in points 2,3,4. I understand that they wanted to outline that in the first case the key has been self-signed, but I would have used just one command putting some more info into the filename, e.g., $ndnsec-key-gen -n /ndn > self-signed_root.cert imho what could be misleading going through the tutorial is the fact that thereafter in points 2-3-4 they use filenames with the prefix "unsigned-" to name keys that are indeed signed. ---- Again you are correct. They are self signed. But Self signed certificate ---- will not serve the purpose of building hierarchy. Thank you for your ---- Nice comments. We will try to make the tutorial free from ambiguity And what about the option of fetching a unsigned version of the key using another ndnsec tool and passing that one to ndnsec-cert-gen, would it feel better? Please let me know if I've well understood or I've missed something important, best, Salvo _______________________________________________ Ndn-interest mailing list Ndn-interest at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest From unict.signorello at gmail.com Tue Aug 5 02:28:26 2014 From: unict.signorello at gmail.com (Salvatore Signorello) Date: Tue, 05 Aug 2014 11:28:26 +0200 Subject: [Ndn-interest] NLSR dissemination of FIB updates Message-ID: <1407230906.2268.22.camel@localhost.localdomain> Hi all, I've noticed that if I register a new name-prefix into the RIB using the command nfdc, the nlsr daemon does not disseminate the new added route to its neighbors. Below the syntax I used: 1) nfdc register ndn:/ndn/finance/colostate udp://IP_address 2) nfdc register -o 128 ndn:/ndn/finance/colostate udp://IP_address (this time is tried the 'origin' option I read on into the nfdc's man page) 3) nfdc register -c 45 -o 128 ndn:/ndn/finance/colostate udp://IP_address (I've added a cost for this route, thinking that a zero cost could stick the protocol) for every attempt the name-prefix registration was successful, but I saw no trace of dissemination for the new name-prefixes. Have I used the right syntax/command? Is this the expected behavior? Further I would be glad if someone could answer two more questions about this behavior: - what's the rationale behind it? I mean, for which reason do they want the name-prefixes registered through this command to not be disseminated to neighbor routers? - as option for launching the nlsr daemon they provide '-p' to specify the "port where api client will connect" (nlsr's usage output). I looked at the code, but I'm not able to find out if they've already implemented/used this functionality. Could you please provide me any hint about its aim/meaning? Thank you in advance for the support, best, Salvo From lanwang at memphis.edu Tue Aug 5 06:31:17 2014 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Tue, 5 Aug 2014 13:31:17 +0000 Subject: [Ndn-interest] NLSR dissemination of FIB updates In-Reply-To: <1407230906.2268.22.camel@localhost.localdomain> References: <1407230906.2268.22.camel@localhost.localdomain> Message-ID: <7B6A7D93-BEB6-480D-8220-3FE8578F937D@memphis.edu> Salvatore, nfdc changes routes in the local RIB and FIB only (you can think of these routes as static routes in the IP forwarding table). It is not designed for advertising routes to other routers. For that, you need to use a routing protocol (e.g., NLSR). Hoque can answer your other question: - as option for launching the nlsr daemon they provide '-p' to specify > the "port where api client will connect" (nlsr's usage output). I looked > at the code, but I'm not able to find out if they've already > implemented/used this functionality. Could you please provide me any > hint about its aim/meaning? Lan On Aug 5, 2014, at 4:28 AM, Salvatore Signorello wrote: > Hi all, > > I've noticed that if I register a new name-prefix into the RIB using the > command nfdc, the nlsr daemon does not disseminate the new added route > to its neighbors. Below the syntax I used: > > 1) nfdc register ndn:/ndn/finance/colostate udp://IP_address > > 2) nfdc register -o 128 ndn:/ndn/finance/colostate udp://IP_address > (this time is tried the 'origin' option I read on into the nfdc's man > page) > > 3) nfdc register -c 45 -o 128 ndn:/ndn/finance/colostate > udp://IP_address > (I've added a cost for this route, thinking that a zero cost could stick > the protocol) > > for every attempt the name-prefix registration was successful, but I saw > no trace of dissemination for the new name-prefixes. Have I used the > right syntax/command? Is this the expected behavior? > > Further I would be glad if someone could answer two more questions about > this behavior: > > - what's the rationale behind it? I mean, for which reason do they want > the name-prefixes registered through this command to not be disseminated > to neighbor routers? > - as option for launching the nlsr daemon they provide '-p' to specify > the "port where api client will connect" (nlsr's usage output). I looked > at the code, but I'm not able to find out if they've already > implemented/used this functionality. Could you please provide me any > hint about its aim/meaning? > > > Thank you in advance for the support, > best, > Salvo > > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest From ahoque1 at memphis.edu Tue Aug 5 06:50:24 2014 From: ahoque1 at memphis.edu (A K M Mahmudul Hoque (ahoque1)) Date: Tue, 5 Aug 2014 13:50:24 +0000 Subject: [Ndn-interest] NLSR dissemination of FIB updates In-Reply-To: <7B6A7D93-BEB6-480D-8220-3FE8578F937D@memphis.edu> References: <1407230906.2268.22.camel@localhost.localdomain>, <7B6A7D93-BEB6-480D-8220-3FE8578F937D@memphis.edu> Message-ID: <1407246624075.70533@memphis.edu> ________________________________________ From: Lan Wang (lanwang) Sent: Tuesday, August 5, 2014 8:31 AM To: Salvatore Signorello Cc: ndn-interest at lists.cs.ucla.edu; A K M Mahmudul Hoque (ahoque1) Subject: Re: [Ndn-interest] NLSR dissemination of FIB updates Salvatore, nfdc changes routes in the local RIB and FIB only (you can think of these routes as static routes in the IP forwarding table). It is not designed for advertising routes to other routers. For that, you need to use a routing protocol (e.g., NLSR). Hoque can answer your other question: - as option for launching the nlsr daemon they provide '-p' to specify > the "port where api client will connect" (nlsr's usage output). I looked > at the code, but I'm not able to find out if they've already > implemented/used this functionality. Could you please provide me any > hint about its aim/meaning? --- It will be implemented in future. The aim of this one to tell NLSR to advertise prefix, --- or even adding neighbors without taking down NLSR. Not only that this API can be --- used to remove old prefixes link that are no longer valid. The objective is to do those --- things without taking shutting down NLSR Lan On Aug 5, 2014, at 4:28 AM, Salvatore Signorello wrote: > Hi all, > > I've noticed that if I register a new name-prefix into the RIB using the > command nfdc, the nlsr daemon does not disseminate the new added route > to its neighbors. Below the syntax I used: > > 1) nfdc register ndn:/ndn/finance/colostate udp://IP_address > > 2) nfdc register -o 128 ndn:/ndn/finance/colostate udp://IP_address > (this time is tried the 'origin' option I read on into the nfdc's man > page) > > 3) nfdc register -c 45 -o 128 ndn:/ndn/finance/colostate > udp://IP_address > (I've added a cost for this route, thinking that a zero cost could stick > the protocol) > > for every attempt the name-prefix registration was successful, but I saw > no trace of dissemination for the new name-prefixes. Have I used the > right syntax/command? Is this the expected behavior? > > Further I would be glad if someone could answer two more questions about > this behavior: > > - what's the rationale behind it? I mean, for which reason do they want > the name-prefixes registered through this command to not be disseminated > to neighbor routers? > - as option for launching the nlsr daemon they provide '-p' to specify > the "port where api client will connect" (nlsr's usage output). I looked > at the code, but I'm not able to find out if they've already > implemented/used this functionality. Could you please provide me any > hint about its aim/meaning? > > > Thank you in advance for the support, > best, > Salvo > > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest From shijunxiao at email.arizona.edu Tue Aug 5 06:55:38 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Tue, 5 Aug 2014 06:55:38 -0700 Subject: [Ndn-interest] NLSR dissemination of FIB updates In-Reply-To: <1407246624075.70533@memphis.edu> References: <1407230906.2268.22.camel@localhost.localdomain> <7B6A7D93-BEB6-480D-8220-3FE8578F937D@memphis.edu> <1407246624075.70533@memphis.edu> Message-ID: Hi Hoque Instead of opening an "API client port", I suggest NLSR to use an Interest-Data based protocol. NFD RIB Management protocol contains "advertise" and "unadvertise" commands that are probably related to this purpose. Yours, Junxiao On Aug 5, 2014 6:51 AM, "A K M Mahmudul Hoque (ahoque1)" < ahoque1 at memphis.edu> wrote: > - as option for launching the nlsr daemon they provide '-p' to specify > > the "port where api client will connect" (nlsr's usage output). I looked > > at the code, but I'm not able to find out if they've already > > implemented/used this functionality. Could you please provide me any > > hint about its aim/meaning? > > > --- It will be implemented in future. The aim of this one to tell NLSR to advertise prefix, > --- or even adding neighbors without taking down NLSR. Not only that this API can be > --- used to remove old prefixes link that are no longer valid. The objective is to do those > --- things without taking shutting down NLSR -------------- next part -------------- An HTML attachment was scrubbed... URL: From ahoque1 at memphis.edu Tue Aug 5 07:00:45 2014 From: ahoque1 at memphis.edu (A K M Mahmudul Hoque (ahoque1)) Date: Tue, 5 Aug 2014 14:00:45 +0000 Subject: [Ndn-interest] NLSR dissemination of FIB updates In-Reply-To: References: <1407230906.2268.22.camel@localhost.localdomain> <7B6A7D93-BEB6-480D-8220-3FE8578F937D@memphis.edu> <1407246624075.70533@memphis.edu>, Message-ID: <1407247244905.43455@memphis.edu> Hi Junxiao, Thank you. We shall implement an interest based protocol for NLSR. The message is old, and I need to modify it. Regards Hoque ________________________________ From: Junxiao Shi Sent: Tuesday, August 5, 2014 8:55 AM To: A K M Mahmudul Hoque (ahoque1) Cc: Salvatore Signorello; ndn-interest at lists.cs.ucla.edu Subject: Re: [Ndn-interest] NLSR dissemination of FIB updates Hi Hoque Instead of opening an "API client port", I suggest NLSR to use an Interest-Data based protocol. NFD RIB Management protocol contains "advertise" and "unadvertise" commands that are probably related to this purpose. Yours, Junxiao On Aug 5, 2014 6:51 AM, "A K M Mahmudul Hoque (ahoque1)" > wrote: > - as option for launching the nlsr daemon they provide '-p' to specify > > the "port where api client will connect" (nlsr's usage output). I looked > > at the code, but I'm not able to find out if they've already > > implemented/used this functionality. Could you please provide me any > > hint about its aim/meaning? > > > --- It will be implemented in future. The aim of this one to tell NLSR to advertise prefix, > --- or even adding neighbors without taking down NLSR. Not only that this API can be > --- used to remove old prefixes link that are no longer valid. The objective is to do those > --- things without taking shutting down NLSR -------------- next part -------------- An HTML attachment was scrubbed... URL: From unict.signorello at gmail.com Tue Aug 5 07:27:34 2014 From: unict.signorello at gmail.com (Salvatore Signorello) Date: Tue, 05 Aug 2014 16:27:34 +0200 Subject: [Ndn-interest] NLSR dissemination of FIB updates In-Reply-To: <7B6A7D93-BEB6-480D-8220-3FE8578F937D@memphis.edu> References: <1407230906.2268.22.camel@localhost.localdomain> <7B6A7D93-BEB6-480D-8220-3FE8578F937D@memphis.edu> Message-ID: <1407248854.2268.44.camel@localhost.localdomain> On Tue, 2014-08-05 at 13:31 +0000, Lan Wang (lanwang) wrote: > Salvatore, > > nfdc changes routes in the local RIB and FIB only (you can think of these routes as static routes in the IP forwarding table). It is not designed for advertising routes to other routers. For that, you need to use a routing protocol (e.g., NLSR). > Sorry, I forgot to say that, because I thought it was implicit, the nlsr daemon was running during the tests. Thank you for the clarification, but I was thinking to something like as the Quagga's redistribute family of commands to trigger the dissemination of routes (my concern is not limited to the ones I can insert through nfdc, I've picked this one as example) that have not been listed into the configuration file of the daemon at the boot. http://www.nongnu.org/quagga/docs/quagga.html#Redistribute-routes-to-OSPF As alternative to shutting down and rebooting the daemon each time. I think that the "-p" option has been left there as an hook for providing this kind of functionality. Anyway I don't see it listed between the features into the redmine site of the project, so sadly it will not appear soon. Thank you > Hoque can answer your other question: > - as option for launching the nlsr daemon they provide '-p' to specify > > the "port where api client will connect" (nlsr's usage output). I looked > > at the code, but I'm not able to find out if they've already > > implemented/used this functionality. Could you please provide me any > > hint about its aim/meaning? > > Lan > On Aug 5, 2014, at 4:28 AM, Salvatore Signorello wrote: > > > Hi all, > > > > I've noticed that if I register a new name-prefix into the RIB using the > > command nfdc, the nlsr daemon does not disseminate the new added route > > to its neighbors. Below the syntax I used: > > > > 1) nfdc register ndn:/ndn/finance/colostate udp://IP_address > > > > 2) nfdc register -o 128 ndn:/ndn/finance/colostate udp://IP_address > > (this time is tried the 'origin' option I read on into the nfdc's man > > page) > > > > 3) nfdc register -c 45 -o 128 ndn:/ndn/finance/colostate > > udp://IP_address > > (I've added a cost for this route, thinking that a zero cost could stick > > the protocol) > > > > for every attempt the name-prefix registration was successful, but I saw > > no trace of dissemination for the new name-prefixes. Have I used the > > right syntax/command? Is this the expected behavior? > > > > Further I would be glad if someone could answer two more questions about > > this behavior: > > > > - what's the rationale behind it? I mean, for which reason do they want > > the name-prefixes registered through this command to not be disseminated > > to neighbor routers? > > - as option for launching the nlsr daemon they provide '-p' to specify > > the "port where api client will connect" (nlsr's usage output). I looked > > at the code, but I'm not able to find out if they've already > > implemented/used this functionality. Could you please provide me any > > hint about its aim/meaning? > > > > > > Thank you in advance for the support, > > best, > > Salvo > > > > > > _______________________________________________ > > Ndn-interest mailing list > > Ndn-interest at lists.cs.ucla.edu > > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > From unict.signorello at gmail.com Tue Aug 5 07:43:07 2014 From: unict.signorello at gmail.com (Salvatore Signorello) Date: Tue, 05 Aug 2014 16:43:07 +0200 Subject: [Ndn-interest] NLSR dissemination of FIB updates In-Reply-To: References: <1407230906.2268.22.camel@localhost.localdomain> <7B6A7D93-BEB6-480D-8220-3FE8578F937D@memphis.edu> <1407246624075.70533@memphis.edu> Message-ID: <1407249787.2268.48.camel@localhost.localdomain> Thank you both, I'm looking at the following documentation to get know the RIB management http://redmine.named-data.net/projects/nfd/wiki/Management , if you want to point me more resources, I would be glad. If I grep the NFD main directory looking for 'advertise', I find no trace of this command, where should it be? Best, Salvo On Tue, 2014-08-05 at 06:55 -0700, Junxiao Shi wrote: > Hi Hoque > > Instead of opening an "API client port", I suggest NLSR to use an > Interest-Data based protocol. > > NFD RIB Management protocol contains "advertise" and "unadvertise" > commands that are probably related to this purpose. > > Yours, Junxiao > > On Aug 5, 2014 6:51 AM, "A K M Mahmudul Hoque (ahoque1)" > wrote: > > - as option for launching the nlsr daemon they provide '-p' to > specify > > > the "port where api client will connect" (nlsr's usage output). I > looked > > > at the code, but I'm not able to find out if they've already > > > implemented/used this functionality. Could you please provide me > any > > > hint about its aim/meaning? > > > > > > --- It will be implemented in future. The aim of this one to tell > NLSR to advertise prefix, > > --- or even adding neighbors without taking down NLSR. Not only that > this API can be > > --- used to remove old prefixes link that are no longer valid. The > objective is to do those > > --- things without taking shutting down NLSR > From lanwang at memphis.edu Tue Aug 5 08:06:25 2014 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Tue, 5 Aug 2014 15:06:25 +0000 Subject: [Ndn-interest] NLSR dissemination of FIB updates In-Reply-To: <1407249787.2268.48.camel@localhost.localdomain> References: <1407230906.2268.22.camel@localhost.localdomain> <7B6A7D93-BEB6-480D-8220-3FE8578F937D@memphis.edu> <1407246624075.70533@memphis.edu> , <1407249787.2268.48.camel@localhost.localdomain> Message-ID: It is not implemented yet. As Junxiao mentioned, we will design an interest/data protocol to allow applications to communicate with NLSR to do this. For now, you can put the prefixes in nlsr.conf. Lan -------- Original message -------- From: Salvatore Signorello Date: 08/05/2014 9:44 AM (GMT-06:00) To: ndn-interest at lists.cs.ucla.edu Subject: Re: [Ndn-interest] NLSR dissemination of FIB updates Thank you both, I'm looking at the following documentation to get know the RIB management http://redmine.named-data.net/projects/nfd/wiki/Management , if you want to point me more resources, I would be glad. If I grep the NFD main directory looking for 'advertise', I find no trace of this command, where should it be? Best, Salvo On Tue, 2014-08-05 at 06:55 -0700, Junxiao Shi wrote: > Hi Hoque > > Instead of opening an "API client port", I suggest NLSR to use an > Interest-Data based protocol. > > NFD RIB Management protocol contains "advertise" and "unadvertise" > commands that are probably related to this purpose. > > Yours, Junxiao > > On Aug 5, 2014 6:51 AM, "A K M Mahmudul Hoque (ahoque1)" > wrote: > > - as option for launching the nlsr daemon they provide '-p' to > specify > > > the "port where api client will connect" (nlsr's usage output). I > looked > > > at the code, but I'm not able to find out if they've already > > > implemented/used this functionality. Could you please provide me > any > > > hint about its aim/meaning? > > > > > > --- It will be implemented in future. The aim of this one to tell > NLSR to advertise prefix, > > --- or even adding neighbors without taking down NLSR. Not only that > this API can be > > --- used to remove old prefixes link that are no longer valid. The > objective is to do those > > --- things without taking shutting down NLSR > _______________________________________________ Ndn-interest mailing list Ndn-interest at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest -------------- next part -------------- An HTML attachment was scrubbed... URL: From soamin at memphis.edu Tue Aug 5 09:45:00 2014 From: soamin at memphis.edu (Syed Obaid Amin) Date: Tue, 5 Aug 2014 11:45:00 -0500 Subject: [Ndn-interest] NLSR dissemination of FIB updates In-Reply-To: <1407249787.2268.48.camel@localhost.localdomain> References: <1407230906.2268.22.camel@localhost.localdomain> <7B6A7D93-BEB6-480D-8220-3FE8578F937D@memphis.edu> <1407246624075.70533@memphis.edu> <1407249787.2268.48.camel@localhost.localdomain> Message-ID: Hi Salvatore, Here is a brief history that maybe of interest to you. nlsr for ccnx can be controlled by CLI or remotely. It does so by listening on a port on which it accepts commands and process them. The '-p ' switch was introduced to change the default port on which it listens for this. nlsr for nfd doesn't support this feature. The consensus was to use Interest/Data model for the communication between nfd and routing protocols(like nlsr). Plus, this functionality should be provided to all routing protocols (not just nlsr). As a result, we added two new commands, *advertise * and *withdraw* in the RibManager, which will allow to specify the routing protocol for disseminating the name prefixes. However, these commands are not supported yet. Regards, Obaid On Tue, Aug 5, 2014 at 9:43 AM, Salvatore Signorello < unict.signorello at gmail.com> wrote: > Thank you both, > > I'm looking at the following documentation to get know the RIB > management > http://redmine.named-data.net/projects/nfd/wiki/Management > , if you want to point me more resources, I would be glad. > > If I grep the NFD main directory looking for 'advertise', I find no > trace of this command, where should it be? > > Best, > Salvo > On Tue, 2014-08-05 at 06:55 -0700, Junxiao Shi wrote: > > Hi Hoque > > > > Instead of opening an "API client port", I suggest NLSR to use an > > Interest-Data based protocol. > > > > NFD RIB Management protocol contains "advertise" and "unadvertise" > > commands that are probably related to this purpose. > > > > Yours, Junxiao > > > > On Aug 5, 2014 6:51 AM, "A K M Mahmudul Hoque (ahoque1)" > > wrote: > > > - as option for launching the nlsr daemon they provide '-p' to > > specify > > > > the "port where api client will connect" (nlsr's usage output). I > > looked > > > > at the code, but I'm not able to find out if they've already > > > > implemented/used this functionality. Could you please provide me > > any > > > > hint about its aim/meaning? > > > > > > > > > --- It will be implemented in future. The aim of this one to tell > > NLSR to advertise prefix, > > > --- or even adding neighbors without taking down NLSR. Not only that > > this API can be > > > --- used to remove old prefixes link that are no longer valid. The > > objective is to do those > > > --- things without taking shutting down NLSR > > > > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > -------------- next part -------------- An HTML attachment was scrubbed... URL: From unict.signorello at gmail.com Tue Aug 5 13:54:04 2014 From: unict.signorello at gmail.com (Salvatore Signorello) Date: Tue, 05 Aug 2014 22:54:04 +0200 Subject: [Ndn-interest] NLSR dissemination of FIB updates In-Reply-To: References: <1407230906.2268.22.camel@localhost.localdomain> <7B6A7D93-BEB6-480D-8220-3FE8578F937D@memphis.edu> <1407246624075.70533@memphis.edu> <1407249787.2268.48.camel@localhost.localdomain> Message-ID: <1407272044.3397.7.camel@localhost.localdomain> Hi Obaid, On Tue, 2014-08-05 at 11:45 -0500, Syed Obaid Amin wrote: > Hi Salvatore, > > > Here is a brief history that maybe of interest to you. nlsr for ccnx > can be controlled by CLI or remotely. It does so by listening on a > port on which it accepts commands and process them. The '-p number>' switch was introduced to change the default port on which it > listens for this. thank you a lot for pointing this out, I will keep it in mind if I need this functionality. > nlsr for nfd doesn't support this feature. The consensus was to use > Interest/Data model for the communication between nfd and routing > protocols(like nlsr). Plus, this functionality should be provided to > all routing protocols (not just nlsr). That's on track and I'm agree with it. > As a result, we added two new commands, advertise and withdraw in > the RibManager, which will allow to specify the routing protocol for > disseminating the name prefixes. However, these commands are not > supported yet. > I hope that they will grow out soon. Thank you a lot for the history. Best, Salvo > > Regards, > Obaid > > > > > On Tue, Aug 5, 2014 at 9:43 AM, Salvatore Signorello > wrote: > Thank you both, > > I'm looking at the following documentation to get know the RIB > management > http://redmine.named-data.net/projects/nfd/wiki/Management > , if you want to point me more resources, I would be glad. > > If I grep the NFD main directory looking for 'advertise', I > find no > trace of this command, where should it be? > > Best, > Salvo > On Tue, 2014-08-05 at 06:55 -0700, Junxiao Shi wrote: > > Hi Hoque > > > > Instead of opening an "API client port", I suggest NLSR to > use an > > Interest-Data based protocol. > > > > NFD RIB Management protocol contains "advertise" and > "unadvertise" > > commands that are probably related to this purpose. > > > > Yours, Junxiao > > > > On Aug 5, 2014 6:51 AM, "A K M Mahmudul Hoque (ahoque1)" > > wrote: > > > - as option for launching the nlsr daemon they provide > '-p' to > > specify > > > > the "port where api client will connect" (nlsr's usage > output). I > > looked > > > > at the code, but I'm not able to find out if they've > already > > > > implemented/used this functionality. Could you please > provide me > > any > > > > hint about its aim/meaning? > > > > > > > > > --- It will be implemented in future. The aim of this one > to tell > > NLSR to advertise prefix, > > > --- or even adding neighbors without taking down NLSR. Not > only that > > this API can be > > > --- used to remove old prefixes link that are no longer > valid. The > > objective is to do those > > > --- things without taking shutting down NLSR > > > > > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > > > From felix at rabe.io Sat Aug 16 14:08:21 2014 From: felix at rabe.io (Felix Rabe) Date: Sat, 16 Aug 2014 23:08:21 +0200 Subject: [Ndn-interest] Needed a logo so I created one (RFC) Message-ID: <53EFC845.80108@rabe.io> Hi NDN folks I needed a logo for NDN, so ... http://i.imgur.com/kSmoNoh.png What do you think? Kind regards - Felix From lixia at CS.UCLA.EDU Sat Aug 16 16:55:58 2014 From: lixia at CS.UCLA.EDU (Lixia Zhang) Date: Sat, 16 Aug 2014 16:55:58 -0700 Subject: [Ndn-interest] Needed a logo so I created one (RFC) In-Reply-To: <53EFC845.80108@rabe.io> References: <53EFC845.80108@rabe.io> Message-ID: we discussed logo on and off for some time now, but never came to a conclusion. I recall Jeff just picked the following image (on NDN website) as sort of a logo for now On Aug 16, 2014, at 2:08 PM, Felix Rabe wrote: > Hi NDN folks > > I needed a logo for NDN, so ... http://i.imgur.com/kSmoNoh.png > > What do you think? > > Kind regards > - Felix > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2014-08-16 at 4.55.33 PM.png Type: image/png Size: 43784 bytes Desc: not available URL: From alexander.afanasyev at ucla.edu Mon Aug 25 18:46:49 2014 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Mon, 25 Aug 2014 18:46:49 -0700 Subject: [Ndn-interest] First public release of NDN Forwarding Daemon (NFD) Message-ID: Dear all, We are pleased to announce the initial public release (version 0.2.0) of the NDN Forwarding Daemon (NFD). NFD is a network forwarder that implements the Named Data Networking (NDN) protocol. More details about NFD, release notes, HOWTOs, a FAQ and other useful resources are available at NFD's official webpage (http://named-data.net/doc/NFD/0.2.0/). Also available is the NFD developer's guide (http://named-data.net/wp-content/uploads/2014/07/NFD-developer-guide.pdf), which provides a detailed description of the implementation internals. An important goal of NFD is to support the broader community to experiment with the NDN architecture. Thus, the current release emphasizes **modularity** and **extensibility** over performance to allow easy experimentation with new protocol features, algorithms, data structures and applications. We invite all interested parties to experiment with the existing code and submit their contributions to NFD Redmine (http://redmine.named-data.net/projects/nfd) or directly to Gerrit Code Review (http://gerrit.named-data.net/#/both) in terms of new architecture features and performance improvements. *** More detailed information about the NFD release is available on the NDN website http://named-data.net/releases/NFD-0.2.0 *** This release is part of the new NDN Platform version 0.3 (http://named-data.net/releases/platform-0.3), which includes the following components: - The NDN Forwarding Daemon (NFD), version 0.2.0 http://named-data.net/doc/NFD/0.2.0/ - The ndn-cxx library, version 0.2.0 http://named-data.net/doc/ndn-cxx/0.2.0/ + The NDN C++ library with eXperimental eXtensions (CXX) + The ndnsec security tools to manage security identities and certificates - The NDN Common Client libraries suite (NDN-CCL), version 0.3 http://named-data.net/releases/CCL-0.3 + The NDN-CPP C++ library + The PyNDN2 Python library + The NDN-JS JavaScript library + (A Java library is coming soon) - The Named Data Link State Routing Protocol (NLSR), version 0.1.0 http://named-data.net/doc/NLSR/0.1.0/ - The next generation of NDN repository (repo-ng), version 0.1.0 http://github.com/named-data/repo-ng - A ping application for NDN (ndn-tlv-ping), version 0.2.0 http://github.com/named-data/ndn-tlv-ping - A traffic generator for NDN (ndn-traffic-generator), version 0.2.0 http://github.com/named-data/ndn-traffic-generator - A packet capture and analysis tool for NDN (ndndump), version 0.5 https://github.com/named-data/ndndump The NFD Team. From felix at rabe.io Wed Aug 27 06:13:00 2014 From: felix at rabe.io (Felix Rabe) Date: Wed, 27 Aug 2014 15:13:00 +0200 Subject: [Ndn-interest] OSX Homebrew formulae Message-ID: <53FDD95C.5040201@rabe.io> Hi Congratulations on the platform release! I'm working on `brew install`-ability of the NDN Platform 0.3 over at https://github.com/felixrabe/homebrew/ (named-data branch). ndn-cxx 0.2 seems to build fine already (tested on OS X 10.9.4, and so far not including any optional dependencies): brew install https://raw.githubusercontent.com/felixrabe/homebrew/named-data/Library/Formula/ndn-cxx.rb # or: cd /usr/local ; git add remote (my repo) ; ... (checkout named-data) ; brew install ndn-cxx This is my first Homebrew formula, so please feel free to send me pull requests. My plan is to gather feedback and pull requests from the NDN community and cover the whole NDN platform before creating pull request(s) to the official https://github.com/Homebrew/homebrew. Sneak preview: I'm also working on Docker images, and I've already succeeded in building ndn-cxx on Ubuntu 14.04 as a Docker image. More on that later. Kind regards - Felix From alexander.afanasyev at ucla.edu Wed Aug 27 14:01:20 2014 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Wed, 27 Aug 2014 14:01:20 -0700 Subject: [Ndn-interest] OSX Homebrew formulae In-Reply-To: <53FDD95C.5040201@rabe.io> References: <53FDD95C.5040201@rabe.io> Message-ID: Hi Felix, Thanks for the brew formula!! We thought of adding this for a loooooong time, but never had enough man power to do that :) I would suggest though a couple of tweaks to the formula, which I will include in pull request later today. It would be awesome if you can make a formula for NFD and some other NDN-related packages (at least, ndn-tlv-ping, repo-ng, ndndump). However, there are complications with NFD, since it is contain two daemons, one should run as super user, the other one as some dedicated ndn user. Initial environment needs to be properly set up for it, nfd-start/nfd-stop should be helpers to launchd (check macports definitions and patches for NFD: https://github.com/named-data/macports/tree/master/net/nfd). I'm not quite sure how much of these is supported by homebrew, maybe all of what I listed can be put just in caveats/user instructions... Do you have ideas about it? I'm also really looking forward to see Docker image for NFD/ndn-cxx. It could really simplify running of NFD on linux platforms different from our supported Ubuntu 14.04 and 12.04. In case you need instructions for .deb packages, you can find the current one here: https://github.com/named-data/ppa-packaging --- Alex On Aug 27, 2014, at 6:13 AM, Felix Rabe wrote: > Hi > > Congratulations on the platform release! > > I'm working on `brew install`-ability of the NDN Platform 0.3 over at https://github.com/felixrabe/homebrew/ (named-data branch). > > ndn-cxx 0.2 seems to build fine already (tested on OS X 10.9.4, and so far not including any optional dependencies): > > brew install https://raw.githubusercontent.com/felixrabe/homebrew/named-data/Library/Formula/ndn-cxx.rb > > # or: cd /usr/local ; git add remote (my repo) ; ... (checkout named-data) ; brew install ndn-cxx > > This is my first Homebrew formula, so please feel free to send me pull requests. My plan is to gather feedback and pull requests from the NDN community and cover the whole NDN platform before creating pull request(s) to the official https://github.com/Homebrew/homebrew. > > Sneak preview: I'm also working on Docker images, and I've already succeeded in building ndn-cxx on Ubuntu 14.04 as a Docker image. More on that later. > > Kind regards > - Felix > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest From felix at rabe.io Sun Aug 31 18:08:27 2014 From: felix at rabe.io (Felix Rabe) Date: Mon, 01 Sep 2014 03:08:27 +0200 Subject: [Ndn-interest] Dockerfile for NFD on Ubuntu Message-ID: <5403C70B.8020103@rabe.io> I've just managed to install NFD on Ubuntu inside Docker, it was straightforward thanks to the instructions on http://named-data.net/doc/NFD/0.2.0/INSTALL.html. Dockerfile: ====== FROM ubuntu:14.04 RUN apt-get update RUN apt-get install -y software-properties-common RUN add-apt-repository -y ppa:named-data/ppa RUN apt-get update RUN apt-get install -y nfd ====== If you want man pages, throw an `apt-get install -y man` in there. Caveat: Have not actually run the software :) will do that on my next opportunity before the meeting. - Felix From alexander.afanasyev at ucla.edu Sun Aug 31 18:38:35 2014 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Sun, 31 Aug 2014 18:38:35 -0700 Subject: [Ndn-interest] Dockerfile for NFD on Ubuntu In-Reply-To: <5403C70B.8020103@rabe.io> References: <5403C70B.8020103@rabe.io> Message-ID: <8AF85944-F5FD-40AD-8E59-02E8706B2B5A@ucla.edu> Cool! When you have time, can you also write some basic steps on how one would start working with Docker? For example, on this wiki page: http://redmine.named-data.net/projects/nfd/wiki/Using_NFD_with_Docker?parent=Wiki (I already linked it from main NFD wiki) I have only read briefly about the Docker and others probably also have very limited knowledge about it. But from what I get, it could be very convenient way to deploy NFD on any linux distribution without the need to tailor the binary packages for each. --- Alex On Aug 31, 2014, at 6:08 PM, Felix Rabe wrote: > I've just managed to install NFD on Ubuntu inside Docker, it was straightforward thanks to the instructions on http://named-data.net/doc/NFD/0.2.0/INSTALL.html. > > Dockerfile: > ====== > FROM ubuntu:14.04 > > RUN apt-get update > RUN apt-get install -y software-properties-common > > RUN add-apt-repository -y ppa:named-data/ppa > RUN apt-get update > RUN apt-get install -y nfd > ====== > > If you want man pages, throw an `apt-get install -y man` in there. > > Caveat: Have not actually run the software :) will do that on my next opportunity before the meeting. > > - Felix > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest