From josh at caida.org Mon May 2 16:33:54 2016 From: josh at caida.org (Josh Polterock) Date: Mon, 2 May 2016 16:33:54 -0700 Subject: [Ndn-interest] Named Data Networking (NDN) Project Monthly Newsletter for April 2016 Message-ID: <20160502233354.GB13061@caida.org> Named Data Networking (NDN) Project Newsletter for April 2016 The NDN project team compiles and publishes this newsletter monthly to inform the community about recent activities, technical news, meetings, publications, presentations, code releases, and upcoming events. You can find these newsletters posted on the Named Data Networking Project blog. COMMUNITY OUTREACH * We are pleased to announce that NIST will host a two-day workshop on Named Data Networking on their campus in Gaithersburg, MD on May 31-June 1, 2016. Day 1 theme will focus on the Internet of Things, Day 2 theme will cover Big Data and Big Media. Please find the agenda and links to registration and hotel information online at http://www.nist.gov/itl/antd/named-data-networking.cfm. Registration will close one week prior to the workshop. TECHNICAL NEWS * We announced the first public release of a micro NDN forwarder as a browser extension built with the NDN-JS library. The initial work on the extension started during the 2nd NDN Hackathon at UCSD last month, with a small team of developers. The group demonstrated the JavaScript-based ChronoChat app in two tabs inside the same browser seamlessly communicating with each other without any dependency on external NFD service. This group's effort won the Best External Impact award (See http://2nd-ndn-hackathon.named-data.net/). The extension source code gets packaged with the NDN-JS codebase at https://github.com/named-data/ndn-js/tree/master/tools/micro-forwarder. The Firefox Add-on package: https://github.com/named-data/ndn-js/raw/master/tools/micro-forwarder/ndn-micro-forwarder.xpi The Chrome extension package: https://github.com/named-data/ndn-js/raw/master/tools/micro-forwarder/extension.crx NDN PUBLICATIONS, PRESENTATIONS, and TECHNICAL REPORTS * Wentao Shang, Adeola Bannis, Teng Liang, Zhehao Wang, Yingdi Yu, Alexander Afanasyev, Jeff Thompson, Jeff Burke, Beichuan Zhang, and Lixia Zhang, "Named Data Networking of Things", 1st IEEE International Conference on Internet-of-Things Design and Implementation, April 2016. http://named-data.net/publications/ndn-iotdi-2016/ * Yu Zhang, Alexander Afanasyev, Jeff Burke, Lixia Zhang, "A Survey of Mobility Support in Named Data Networking" Workshop on Name-Oriented Mobility: Architecture, Algorithms and Applications (NOM), April 2016. http://named-data.net/publications/survey_mobility_support_ndn/ * PI Jeff Burke presented two talks at the Information-Centric Networking Research Group (ICNRG) meeting in Buenos Aires, Argentina this month. He presented "NDN architectural principles" and https://www.ietf.org/proceedings/interim/2016/04/03/icnrg/slides/slides-interim-2016-icnrg-2-2.pdf "Approaching Privacy over ICN: Values-in-Design Approach." https://www.ietf.org/proceedings/interim/2016/04/03/icnrg/slides/slides-interim-2016-icnrg-2-9.pdf * For links to slide presentations and breakout summaries, please see the 6th NDN Retreat 2016 web page at http://www.caida.org/workshops/ndn/1603/ . SEMINARS * The NDN seminars are internally focused. If you would like to participate in the NDN Seminars, please contact the PoC, UCLA PhD. candidate Spyridon Mastorakis for the most up-to-date information regarding upcoming seminars. For more information about the Named Data Networking (NDN) Project please visit http://www.named-data.net/. From yudiandreanp at live.com Tue May 3 08:06:15 2016 From: yudiandreanp at live.com (Yudi Andrean) Date: Tue, 3 May 2016 15:06:15 +0000 Subject: [Ndn-interest] Error compiling ndn-tools Message-ID: Dear all, I've got an error when compiling ndn-tools I cloned from the github repository, here are the stdout lines generated [24/52] Compiling tools/chunks/catchunks/discover-version-iterative.cpp In file included from ../tools/chunks/catchunks/discover-version-iterative.cpp:28:0: ../tools/chunks/catchunks/discover-version-iterative.hpp:88:7: error: expected ';' at end of member declaration run() NDN_CXX_DECL_FINAL; ^ ../tools/chunks/catchunks/discover-version-iterative.hpp:88:9: error: 'NDN_CXX_DECL_FINAL' does not name a type run() NDN_CXX_DECL_FINAL; ^ ../tools/chunks/catchunks/discover-version-iterative.hpp:92:56: error: expected ';' at end of member declaration handleData(const Interest& interest, const Data& data) NDN_CXX_DECL_FINAL; ^ ../tools/chunks/catchunks/discover-version-iterative.hpp:92:58: error: 'NDN_CXX_DECL_FINAL' does not name a type handleData(const Interest& interest, const Data& data) NDN_CXX_DECL_FINAL; ^ ../tools/chunks/catchunks/discover-version-iterative.hpp:95:68: error: expected ';' at end of member declaration handleTimeout(const Interest& interest, const std::string& reason) NDN_CXX_DECL_FINAL; ^ ../tools/chunks/catchunks/discover-version-iterative.hpp:95:70: error: 'NDN_CXX_DECL_FINAL' does not name a type handleTimeout(const Interest& interest, const std::string& reason) NDN_CXX_DECL_FINAL; ^ In file included from ../tools/chunks/catchunks/discover-version-fixed.cpp:26:0: ../tools/chunks/catchunks/discover-version-fixed.hpp:60:7: error: expected ';' at end of member declaration run() NDN_CXX_DECL_FINAL; ^ ../tools/chunks/catchunks/discover-version-fixed.hpp:60:9: error: 'NDN_CXX_DECL_FINAL' does not name a type run() NDN_CXX_DECL_FINAL; ^ ../tools/chunks/catchunks/discover-version-fixed.hpp:64:56: error: expected ';' at end of member declaration handleData(const Interest& interest, const Data& data) NDN_CXX_DECL_FINAL; ^ ../tools/chunks/catchunks/discover-version-fixed.hpp:64:58: error: 'NDN_CXX_DECL_FINAL' does not name a type handleData(const Interest& interest, const Data& data) NDN_CXX_DECL_FINAL; ^ Waf: Leaving directory `/home/ndnuser/NDN/ndn-tools/build' Build failed -> task in 'ndncatchunks-objects' failed (exit status 1): {task 140303682466320: cxx discover-version-iterative.cpp -> discover-version-iterative.cpp.1.o} ['/usr/bin/g++', '-O2', '-g', '-pedantic', '-Wall', '-Wextra', '-Wno-unused-parameter', '-fdiagnostics-color', '-std=c++11', '-I/home/ndnuser/NDN/ndn-tools/build', '-I/home/ndnuser/NDN/ndn-tools', '-I/usr/local/include', '-I/usr/include', '-DNDEBUG', '-DHAVE_INTTYPES_H=1', '-DHAVE_STDINT_H=1', '-DHAVE_SYS_BITYPES_H=1', '-DHAVE_SYS_TYPES_H=1', '-DHAVE_NDN_CXX=1', '../tools/chunks/catchunks/discover-version-iterative.cpp', '-c', '-o', '/home/ndnuser/NDN/ndn-tools/build/tools/chunks/catchunks/discover-version-iterative.cpp.1.o'] -> task in 'ndncatchunks-objects' failed (exit status 1): {task 140303682466192: cxx discover-version-fixed.cpp -> discover-version-fixed.cpp.1.o} ['/usr/bin/g++', '-O2', '-g', '-pedantic', '-Wall', '-Wextra', '-Wno-unused-parameter', '-fdiagnostics-color', '-std=c++11', '-I/home/ndnuser/NDN/ndn-tools/build', '-I/home/ndnuser/NDN/ndn-tools', '-I/usr/local/include', '-I/usr/include', '-DNDEBUG', '-DHAVE_INTTYPES_H=1', '-DHAVE_STDINT_H=1', '-DHAVE_SYS_BITYPES_H=1', '-DHAVE_SYS_TYPES_H=1', '-DHAVE_NDN_CXX=1', '../tools/chunks/catchunks/discover-version-fixed.cpp', '-c', '-o', '/home/ndnuser/NDN/ndn-tools/build/tools/chunks/catchunks/discover-version-fixed.cpp.1.o'] anyone ever encountered this or know how to deal with it? Thanks! --- Regards, Yudi A. Phanama -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Tue May 3 08:12:50 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Tue, 3 May 2016 08:12:50 -0700 Subject: [Ndn-interest] Error compiling ndn-tools In-Reply-To: References: Message-ID: Hi Yudi Thanks for reporting. This is filed as Bug 3613 . Yours, Junxiao On Tue, May 3, 2016 at 8:06 AM, Yudi Andrean wrote: > Dear all, > > > I've got an error when compiling ndn-tools I cloned from the github > repository, here are the stdout lines generated > > > [24/52] Compiling tools/chunks/catchunks/discover-version-iterative.cpp > In file included from > ../tools/chunks/catchunks/discover-version-iterative.cpp:28:0: > ../tools/chunks/catchunks/discover-version-iterative.hpp:88:7: error: > expected ?;? at end of member declaration > run() NDN_CXX_DECL_FINAL; > ^ > ../tools/chunks/catchunks/discover-version-iterative.hpp:88:9: error: > ?NDN_CXX_DECL_FINAL? does not name a type > run() NDN_CXX_DECL_FINAL; > ^ > ../tools/chunks/catchunks/discover-version-iterative.hpp:92:56: error: > expected ?;? at end of member declaration > handleData(const Interest& interest, const Data& data) > NDN_CXX_DECL_FINAL; > ^ > ../tools/chunks/catchunks/discover-version-iterative.hpp:92:58: error: > ?NDN_CXX_DECL_FINAL? does not name a type > handleData(const Interest& interest, const Data& data) > NDN_CXX_DECL_FINAL; > ^ > ../tools/chunks/catchunks/discover-version-iterative.hpp:95:68: error: > expected ?;? at end of member declaration > handleTimeout(const Interest& interest, const std::string& reason) > NDN_CXX_DECL_FINAL; > ^ > ../tools/chunks/catchunks/discover-version-iterative.hpp:95:70: error: > ?NDN_CXX_DECL_FINAL? does not name a type > handleTimeout(const Interest& interest, const std::string& reason) > NDN_CXX_DECL_FINAL; > ^ > > In file included from > ../tools/chunks/catchunks/discover-version-fixed.cpp:26:0: > ../tools/chunks/catchunks/discover-version-fixed.hpp:60:7: error: expected > ?;? at end of member declaration > run() NDN_CXX_DECL_FINAL; > ^ > ../tools/chunks/catchunks/discover-version-fixed.hpp:60:9: error: > ?NDN_CXX_DECL_FINAL? does not name a type > run() NDN_CXX_DECL_FINAL; > ^ > ../tools/chunks/catchunks/discover-version-fixed.hpp:64:56: error: > expected ?;? at end of member declaration > handleData(const Interest& interest, const Data& data) > NDN_CXX_DECL_FINAL; > ^ > ../tools/chunks/catchunks/discover-version-fixed.hpp:64:58: error: > ?NDN_CXX_DECL_FINAL? does not name a type > handleData(const Interest& interest, const Data& data) > NDN_CXX_DECL_FINAL; > ^ > > Waf: Leaving directory `/home/ndnuser/NDN/ndn-tools/build' > Build failed > -> task in 'ndncatchunks-objects' failed (exit status 1): > {task 140303682466320: cxx discover-version-iterative.cpp -> > discover-version-iterative.cpp.1.o} > ['/usr/bin/g++', '-O2', '-g', '-pedantic', '-Wall', '-Wextra', > '-Wno-unused-parameter', '-fdiagnostics-color', '-std=c++11', > '-I/home/ndnuser/NDN/ndn-tools/build', '-I/home/ndnuser/NDN/ndn-tools', > '-I/usr/local/include', '-I/usr/include', '-DNDEBUG', > '-DHAVE_INTTYPES_H=1', '-DHAVE_STDINT_H=1', '-DHAVE_SYS_BITYPES_H=1', > '-DHAVE_SYS_TYPES_H=1', '-DHAVE_NDN_CXX=1', > '../tools/chunks/catchunks/discover-version-iterative.cpp', '-c', '-o', > '/home/ndnuser/NDN/ndn-tools/build/tools/chunks/catchunks/discover-version-iterative.cpp.1.o'] > -> task in 'ndncatchunks-objects' failed (exit status 1): > {task 140303682466192: cxx discover-version-fixed.cpp -> > discover-version-fixed.cpp.1.o} > ['/usr/bin/g++', '-O2', '-g', '-pedantic', '-Wall', '-Wextra', > '-Wno-unused-parameter', '-fdiagnostics-color', '-std=c++11', > '-I/home/ndnuser/NDN/ndn-tools/build', '-I/home/ndnuser/NDN/ndn-tools', > '-I/usr/local/include', '-I/usr/include', '-DNDEBUG', > '-DHAVE_INTTYPES_H=1', '-DHAVE_STDINT_H=1', '-DHAVE_SYS_BITYPES_H=1', > '-DHAVE_SYS_TYPES_H=1', '-DHAVE_NDN_CXX=1', > '../tools/chunks/catchunks/discover-version-fixed.cpp', '-c', '-o', > '/home/ndnuser/NDN/ndn-tools/build/tools/chunks/catchunks/discover-version-fixed.cpp.1.o'] > > anyone ever encountered this or know how to deal with it? > Thanks! > --- > Regards, > Yudi A. Phanama > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aa at CS.UCLA.EDU Fri May 6 12:40:28 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Fri, 6 May 2016 12:40:28 -0700 Subject: [Ndn-interest] [CFP] 1st IEEE Workshop on Named Data Networking for Challenged Communication Environments (NDN-CCE'2016) Message-ID: <6F0245D3-56AB-4A07-8BD1-2D511BB7D8C7@cs.ucla.edu> ========================================================= CALL FOR PAPERS 1st IEEE Workshop on Named Data Networking for Challenged Communication Environments (NDN-CCE'2016) Washington, DC, December 8th 2016 http://www2.mitre.org/public/ndn-cce/ ========================================================= Army tactical networks, first responder communication networks, and interplanetary networks are several examples of challenging communication environments that are typically referred to as DIL (disrupted, intermittently connected, and low bandwidth). Nevertheless, applications that operate in such environments generate mission critical data that must be disseminated promptly and reliably, despite the challenging nature of the communication environment. Many years of research efforts have been invested into IP-based communication networks to achieve the above goals, but only resulted in limited success. The root cause of the difficulties is a fundamental mismatch between the IP-based communication model and the challenged environments. The former assumes communications through established stable infrastructures. It requires the creation and maintenance of end-to-end connectivity between senders and receivers, while neither the infrastructure nor end-to-end connectivity exists in the latter. The key to solving the problem is to identify a new communication model that makes effective use of the heterogeneous network resources of challenged environments, removes dependency on infrastructure components, and emphasizes data dissemination in lieu end-to-end connectivity. Information-Centric Networking (ICN) and Named Data Networking (NDN), as the most prominent realization of the ICN vision, have emerged in recent years as promising directions to address the above stated challenges. By its name, this new networking model focuses on information (named data) retrieval, instead of reachability between nodes and locations. Therefore, it can circumvent the lack of persistent connectivity in challenged environments by focusing on moving data instead of end-to-end connectivity, utilizing any connectivity, as it comes into existence, to move data hop-by-hop towards requesting parties. This workshop aims to provide a timely venue for all interested parties to exchange their ideas and initial results in applying the NDN paradigm to: address the communication needs of mission critical applications in challenged environments, explore different design options, and identify design tradeoffs. Topics of interest includes: - NDN routing for challenged communication environments Supporting - high assurance NDN applications in challenged communication - environments Real deployment and case studies of NDN in challenged - communication environments QoS-aware NDN functionalities for - challenged communication environments Efficient and effective NDN - caching policies for challenged communication environments Modeling, - analysis and characterization of NDN functionalities in challenged - communication network ========================================================= IMPORTANT DATES Submission Deadline: July 1, 2016, 11:59pm Acceptance Notification: September 1, 2016 Camera-Ready Submission: October 1, 2016 ========================================================= Sincerely, Tamer Refaei (The MITRE Corporation) and Alex Afanasyev (UCLA) NDN-CCE Workshop Co-Chairs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From gaurav.barokar at gmail.com Wed May 11 06:54:13 2016 From: gaurav.barokar at gmail.com (Gaurav Barokar) Date: Wed, 11 May 2016 14:54:13 +0100 Subject: [Ndn-interest] Regarding NFD Android Message-ID: Dear all, In NFD Android we have to add the 1st route to global testbed i.e. spurs.ucla or any address of NDN global testbed then and then only we are able to communicate the two nodes by adding their routes afterwards. So my question is whether we can communicate directly two nodes by adding their routes respectively without adding the first route to global NDN testbed.? If not can we modify the code? and where to change that dependencies? Also we have to include the WiFi Direct face to NFD Android. Thank you. From bouacherine.abdelkader at gmail.com Wed May 11 06:59:29 2016 From: bouacherine.abdelkader at gmail.com (Bouacherine Abdelkader) Date: Wed, 11 May 2016 14:59:29 +0100 Subject: [Ndn-interest] Controlling the ressources allocated (Processors and RAM) for each node in NDNsim Message-ID: Hi, I would like to know if there is way to set the ressources to be allocated to each node on the NDNsim scenario. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From malhowaidi at gmail.com Wed May 18 20:17:07 2016 From: malhowaidi at gmail.com (Mohammad Alhowaidi) Date: Wed, 18 May 2016 22:17:07 -0500 Subject: [Ndn-interest] working with repo-ng Message-ID: Hello, I am trying to work with repo-ng , I know to add a file to a repository then we need to use ndnputfile, assume I execute the following line sudo ndnputfile /example/repo/1 /ndn/example/data/1/test.txt test.txt Then if I wanna request the file then which name the consumer should ask for? Also, is there any example for consumer, producer which work with repo-ng? Thanks, Moh'd -------------- next part -------------- An HTML attachment was scrubbed... URL: From malhowaidi at gmail.com Thu May 19 10:37:47 2016 From: malhowaidi at gmail.com (Mohammad Alhowaidi) Date: Thu, 19 May 2016 12:37:47 -0500 Subject: [Ndn-interest] Fwd: working with repo-ng In-Reply-To: References: Message-ID: Hello all, (Sorry if you are getting a duplicate as not sure if the previous one went through) I am trying to work with repo-ng , I know to add a file to a repository then we need to use ndnputfile, assume I execute the following line sudo ndnputfile /example/repo/1 /ndn/example/data/1/test.txt test.txt Then if I wanna request the file then which name the consumer should ask for? Also, is there any example for consumer, producer which work with repo-ng? Thanks, Moh'd -------------- next part -------------- An HTML attachment was scrubbed... URL: From gabesilva2004 at yahoo.com Sat May 21 18:39:10 2016 From: gabesilva2004 at yahoo.com (Gabriel Silva) Date: Sun, 22 May 2016 01:39:10 +0000 (UTC) Subject: [Ndn-interest] nfd and iot? References: <1459981377.374138.1463881150532.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <1459981377.374138.1463881150532.JavaMail.yahoo@mail.yahoo.com> Hello I am interested in using nfd for IoT. However, I am looking for some clarity on how it can be a differentiator from other technologies which route data like mqtt, kafka, wso2 mb etc. Thank you for any help.? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhasabet at gmail.com Sat May 21 21:44:29 2016 From: mhasabet at gmail.com (Muhammad Hosain Abdollahi Sabet) Date: Sun, 22 May 2016 09:14:29 +0430 Subject: [Ndn-interest] Scope of Link object? Message-ID: Hi everyone, We consider Link object as a hint to get an interest to the *place* where the name carried in interests can be directly lookup. My question is about the scope of this *place. *Has it been defined somewhere? Is it an ISP or a router or something? Thanks, Sabet -------------- next part -------------- An HTML attachment was scrubbed... URL: From lixia at CS.UCLA.EDU Sat May 21 22:38:20 2016 From: lixia at CS.UCLA.EDU (Lixia Zhang) Date: Sat, 21 May 2016 22:38:20 -0700 Subject: [Ndn-interest] Scope of Link object? In-Reply-To: References: Message-ID: > On May 21, 2016, at 9:44 PM, Muhammad Hosain Abdollahi Sabet wrote: > > Hi everyone, > > We consider Link object as a hint to get an interest to the place where the name carried in interests can be directly lookup. My question is about the scope of this place. Has it been defined somewhere? Is it an ISP or a router or something? all the above, it is up to the granularity of what the LINK points to. Lixia PS: I'm falling very far behind on the exchanges here, just happened to see this last post. As spring teaching coming to the end soon, will try to catch up the earlier discussions, especially those on design principles. From mhasabet at gmail.com Sat May 21 23:00:09 2016 From: mhasabet at gmail.com (Muhammad Hosain Abdollahi Sabet) Date: Sun, 22 May 2016 10:30:09 +0430 Subject: [Ndn-interest] Scope of Link object? In-Reply-To: References: Message-ID: Could you elaborate a bit more on this? If LINK points to *a place*, what can be granularity of it? Regards, Sabet On Sun, May 22, 2016 at 10:08 AM, Lixia Zhang wrote: > > > On May 21, 2016, at 9:44 PM, Muhammad Hosain Abdollahi Sabet < > mhasabet at gmail.com> wrote: > > > > Hi everyone, > > > > We consider Link object as a hint to get an interest to the place where > the name carried in interests can be directly lookup. My question is about > the scope of this place. Has it been defined somewhere? Is it an ISP or a > router or something? > > all the above, it is up to the granularity of what the LINK points to. > > Lixia > PS: I'm falling very far behind on the exchanges here, just happened to > see this last post. As spring teaching coming to the end soon, will try to > catch up the earlier discussions, especially those on design principles. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Sun May 22 20:44:05 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Sun, 22 May 2016 20:44:05 -0700 Subject: [Ndn-interest] Scope of Link object? In-Reply-To: References: Message-ID: Hi Sabet The granularity is an Autonomous System (AS). Within the AS, the name prefix should be announced into intra-domain routing protocol, and Link object is not used. In NFD implementation, whether to use Link object is determined by tables.network_region configuration option. See NFD devguide for more information. Yours, Junxiao On May 21, 2016 11:02 PM, "Muhammad Hosain Abdollahi Sabet" < mhasabet at gmail.com> wrote: > > Could you elaborate a bit more on this? If LINK points to a place, what can be granularity of it? > > Regards, > Sabet -------------- next part -------------- An HTML attachment was scrubbed... URL: From aa at CS.UCLA.EDU Sun May 22 21:25:24 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Sun, 22 May 2016 21:25:24 -0700 Subject: [Ndn-interest] Scope of Link object? In-Reply-To: References: Message-ID: This is not exactly correct. The granularity of the LINK can be anything. It can be a prefix that correspond to something like an AS (/att), it can be a name that points to a network within the ISP (/att/net1/net2), or it can be a host within the network (/att/net1/net2/net3/host). The specific usage would depend on what make sense for your application and environment. With a more generic name (/att) you're relying on name-based forwarding to direct your interests within that network directly. -- Alex > On May 22, 2016, at 8:44 PM, Junxiao Shi wrote: > > Hi Sabet > > The granularity is an Autonomous System (AS). Within the AS, the name prefix should be announced into intra-domain routing protocol, and Link object is not used. > In NFD implementation, whether to use Link object is determined by tables.network_region configuration option. See NFD devguide for more information. > > Yours, Junxiao > > On May 21, 2016 11:02 PM, "Muhammad Hosain Abdollahi Sabet" > wrote: > > > > Could you elaborate a bit more on this? If LINK points to a place, what can be granularity of it? > > > > Regards, > > Sabet > > _______________________________________________ > 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: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From charif.mahmoudi at nist.gov Mon May 23 06:06:53 2016 From: charif.mahmoudi at nist.gov (Mahmoudi, Charif (IntlAssoc)) Date: Mon, 23 May 2016 13:06:53 +0000 Subject: [Ndn-interest] nfd and iot? In-Reply-To: <1459981377.374138.1463881150532.JavaMail.yahoo@mail.yahoo.com> References: <1459981377.374138.1463881150532.JavaMail.yahoo.ref@mail.yahoo.com> <1459981377.374138.1463881150532.JavaMail.yahoo@mail.yahoo.com> Message-ID: Hi Gabriel, Usually, MQTT is used as a publish/subscribe for IoT where you need to address the host of your data. If you have multiple consumers asking for the same data. All of them will connect to the MQTT broker. With NDN, they will get that data from the first common router. Moreover, with NDN, the subscribers may ask for the content not for a specific sensor. For example, consider a use case where you have multiple sensors to enable failover. With NDN, you interest will be sent to the working sensor by the network. No need to implement this failover mechanism in the application layer. To have an idea about how NDN can be a game changing in term of IoT. Feel free to take a look to our in-network IoT composition approach. https://github.com/usnistgov/NamedIoT We have a poster describing that approach available at : https://github.com/usnistgov/NamedIoT/files/272882/ndn-poster.pptx Dr. Charif Mahmoudi From: Ndn-interest [mailto:ndn-interest-bounces at lists.cs.ucla.edu] On Behalf Of Gabriel Silva Sent: Saturday, May 21, 2016 9:39 PM To: ndn-interest at lists.cs.ucla.edu Subject: [Ndn-interest] nfd and iot? Hello I am interested in using nfd for IoT. However, I am looking for some clarity on how it can be a differentiator from other technologies which route data like mqtt, kafka, wso2 mb etc. Thank you for any help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Marc.Mosko at parc.com Mon May 23 07:10:50 2016 From: Marc.Mosko at parc.com (Marc.Mosko at parc.com) Date: Mon, 23 May 2016 14:10:50 +0000 Subject: [Ndn-interest] nfd and iot? In-Reply-To: References: <1459981377.374138.1463881150532.JavaMail.yahoo.ref@mail.yahoo.com> <1459981377.374138.1463881150532.JavaMail.yahoo@mail.yahoo.com> Message-ID: <3FB9490E-7301-42BE-B2E1-0E06589CE892@parc.com> While I agree that ICN can offer a lot of advantages over IP based IoT solutions, I do not think it?s quite so simple to use opportunistic caching as a replacement for something like an MQTT broker. The broker offers several processing features, like the QoS attribute and wildcarding subscriptions. Using opportunistic caching, consumers can miss publications if the cache gets evicted or maybe just due to adversarial timing of messages. I looked at the poster, but was not able to determine if there was some mechanism you used beyond opportunistic caching and normal NDN data matching. I think there are some shortcomings to using only those mechanisms in a service that is supposed to deliver (perhaps reliably) all messages in a publication stream to all currently subscribed clients. Depending on the timing of publications and Interests, a client could miss messages. For example, a sensor is publishing /sensor/1, /sensor/2, ? /sensor/N. If a consumer is asking for these with exclusions and ?left most child? to try to walk them in order, it could still miss one due to packet loss. Lets say it gets 1 ? 10, then 11 is lost in network, so 12 is the ?left most child? at the closest router. It would then skip to 12, and unless you do some recovery mechanism at the consumer, 11 is lost without even know it. If one is using timestamps or some other non-monotonic sequence number, then it would be very hard to know about the omission. Even without packet loss, one could still miss messages. If two consumers are pulling data but at slightly different rates, one could be on ?10? and the other pulls ?11? and ?12? before the next interest from the first arrives. ?12? is now the ?left most child? so it would miss 11. Marc From: Ndn-interest on behalf of "Mahmoudi, Charif (IntlAssoc)" Date: Monday, May 23, 2016 at 9:06 PM To: "gabesilva2004 at yahoo.com" , "ndn-interest at lists.cs.ucla.edu" Subject: Re: [Ndn-interest] nfd and iot? https://github.com/usnistgov/NamedIoT/files/272882 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Marc.Mosko at parc.com Mon May 23 07:26:06 2016 From: Marc.Mosko at parc.com (Marc.Mosko at parc.com) Date: Mon, 23 May 2016 14:26:06 +0000 Subject: [Ndn-interest] nfd and iot? In-Reply-To: <3FB9490E-7301-42BE-B2E1-0E06589CE892@parc.com> References: <1459981377.374138.1463881150532.JavaMail.yahoo.ref@mail.yahoo.com> <1459981377.374138.1463881150532.JavaMail.yahoo@mail.yahoo.com> <3FB9490E-7301-42BE-B2E1-0E06589CE892@parc.com> Message-ID: I provided an incomplete description of the 2nd case where ?left most child? could fail even without packet loss. A ? B ? C ? D - E |-----------| In this example, node A and E are the consumers from publisher C. Node E can send its interests via B and D. So, it could send the interest for /sensor/11 via D and /sensor/12 via B. Node A, when sending an interest for ?/sensor, exclude up to and including 10, left most child,? would then get /sensor/12 because E had already pulled that via B. It would not get /sensor/11 because that data was never pulled down via B. Node A would need some other mechanism to detect that it missed a message (again, I used simple monotonic sequence numbers so it would be easy, but if you use something else like timestamps its not so easy). Marc From: Ndn-interest on behalf of Marc Date: Monday, May 23, 2016 at 10:10 PM To: "charif.mahmoudi at nist.gov" , "gabesilva2004 at yahoo.com" , "ndn-interest at lists.cs.ucla.edu" Subject: Re: [Ndn-interest] nfd and iot? While I agree that ICN can offer a lot of advantages over IP based IoT solutions, I do not think it?s quite so simple to use opportunistic caching as a replacement for something like an MQTT broker. The broker offers several processing features, like the QoS attribute and wildcarding subscriptions. Using opportunistic caching, consumers can miss publications if the cache gets evicted or maybe just due to adversarial timing of messages. I looked at the poster, but was not able to determine if there was some mechanism you used beyond opportunistic caching and normal NDN data matching. I think there are some shortcomings to using only those mechanisms in a service that is supposed to deliver (perhaps reliably) all messages in a publication stream to all currently subscribed clients. Depending on the timing of publications and Interests, a client could miss messages. For example, a sensor is publishing /sensor/1, /sensor/2, ? /sensor/N. If a consumer is asking for these with exclusions and ?left most child? to try to walk them in order, it could still miss one due to packet loss. Lets say it gets 1 ? 10, then 11 is lost in network, so 12 is the ?left most child? at the closest router. It would then skip to 12, and unless you do some recovery mechanism at the consumer, 11 is lost without even know it. If one is using timestamps or some other non-monotonic sequence number, then it would be very hard to know about the omission. Even without packet loss, one could still miss messages. If two consumers are pulling data but at slightly different rates, one could be on ?10? and the other pulls ?11? and ?12? before the next interest from the first arrives. ?12? is now the ?left most child? so it would miss 11. Marc From: Ndn-interest on behalf of "Mahmoudi, Charif (IntlAssoc)" Date: Monday, May 23, 2016 at 9:06 PM To: "gabesilva2004 at yahoo.com" , "ndn-interest at lists.cs.ucla.edu" Subject: Re: [Ndn-interest] nfd and iot? https://github.com/usnistgov/NamedIoT/files/272882 -------------- next part -------------- An HTML attachment was scrubbed... URL: From charif.mahmoudi at nist.gov Mon May 23 07:59:53 2016 From: charif.mahmoudi at nist.gov (Mahmoudi, Charif (IntlAssoc)) Date: Mon, 23 May 2016 14:59:53 +0000 Subject: [Ndn-interest] nfd and iot? In-Reply-To: References: <1459981377.374138.1463881150532.JavaMail.yahoo.ref@mail.yahoo.com> <1459981377.374138.1463881150532.JavaMail.yahoo@mail.yahoo.com> <3FB9490E-7301-42BE-B2E1-0E06589CE892@parc.com> Message-ID: Hi Marc, Our main support to address that issue is a name delimiter based on naming conventions. for example. If the domain is /dom1. A composition of can be managed in an intuitive way. /dom1/actuator1/dom1/agregator1/dom1/sensor1/dom1/sensor2 |--------1------------|---------2-------------|-------3-----------|---------4---------| We may consider a cross domain composition. In that case, the aggregator should know about all the composition domains. We are experimenting the use of NLSR information to know about the reachable domains in order to consider them in an automatic way. For example, if the NLSR database contains routes for /dom1, /dom2, and /dom2/sub1. We are investigating the behavior when using these entrees as delimiter for our composition : /dom1/actuator1/dom2/agregator1/dom2/sub1/sensor1/dom1/sensor2 |--------1------------|---------2-------------|-------3-----------------|---------4---------| That been said, I agree with you, without naming conventions, it will be too many incertitude on the naming limits. Thanks for your feedback, I hope that we will get more feedback from this mailing list and on the nest NDN workshop. Charif From: Marc.Mosko at parc.com [mailto:Marc.Mosko at parc.com] Sent: Monday, May 23, 2016 10:26 AM To: Mahmoudi, Charif (IntlAssoc) ; gabesilva2004 at yahoo.com; ndn-interest at lists.cs.ucla.edu Subject: Re: [Ndn-interest] nfd and iot? I provided an incomplete description of the 2nd case where ?left most child? could fail even without packet loss. A ? B ? C ? D - E |-----------| In this example, node A and E are the consumers from publisher C. Node E can send its interests via B and D. So, it could send the interest for /sensor/11 via D and /sensor/12 via B. Node A, when sending an interest for ?/sensor, exclude up to and including 10, left most child,? would then get /sensor/12 because E had already pulled that via B. It would not get /sensor/11 because that data was never pulled down via B. Node A would need some other mechanism to detect that it missed a message (again, I used simple monotonic sequence numbers so it would be easy, but if you use something else like timestamps its not so easy). Marc From: Ndn-interest > on behalf of Marc > Date: Monday, May 23, 2016 at 10:10 PM To: "charif.mahmoudi at nist.gov" >, "gabesilva2004 at yahoo.com" >, "ndn-interest at lists.cs.ucla.edu" > Subject: Re: [Ndn-interest] nfd and iot? While I agree that ICN can offer a lot of advantages over IP based IoT solutions, I do not think it?s quite so simple to use opportunistic caching as a replacement for something like an MQTT broker. The broker offers several processing features, like the QoS attribute and wildcarding subscriptions. Using opportunistic caching, consumers can miss publications if the cache gets evicted or maybe just due to adversarial timing of messages. I looked at the poster, but was not able to determine if there was some mechanism you used beyond opportunistic caching and normal NDN data matching. I think there are some shortcomings to using only those mechanisms in a service that is supposed to deliver (perhaps reliably) all messages in a publication stream to all currently subscribed clients. Depending on the timing of publications and Interests, a client could miss messages. For example, a sensor is publishing /sensor/1, /sensor/2, ? /sensor/N. If a consumer is asking for these with exclusions and ?left most child? to try to walk them in order, it could still miss one due to packet loss. Lets say it gets 1 ? 10, then 11 is lost in network, so 12 is the ?left most child? at the closest router. It would then skip to 12, and unless you do some recovery mechanism at the consumer, 11 is lost without even know it. If one is using timestamps or some other non-monotonic sequence number, then it would be very hard to know about the omission. Even without packet loss, one could still miss messages. If two consumers are pulling data but at slightly different rates, one could be on ?10? and the other pulls ?11? and ?12? before the next interest from the first arrives. ?12? is now the ?left most child? so it would miss 11. Marc From: Ndn-interest > on behalf of "Mahmoudi, Charif (IntlAssoc)" > Date: Monday, May 23, 2016 at 9:06 PM To: "gabesilva2004 at yahoo.com" >, "ndn-interest at lists.cs.ucla.edu" > Subject: Re: [Ndn-interest] nfd and iot? https://github.com/usnistgov/NamedIoT/files/272882 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhasabet at gmail.com Mon May 23 12:43:44 2016 From: mhasabet at gmail.com (Muhammad Hosain Abdollahi Sabet) Date: Tue, 24 May 2016 00:13:44 +0430 Subject: [Ndn-interest] Scope of Link object? In-Reply-To: References: Message-ID: Alex, So, the one thing we are sure about, is that Forwarding Hint should be globally routable. It means at least the first two components of it, should be available in DFZ. Is that correct? I'm not looking for this one right now, but I'm curios. When you say Link could point to a network, how could one locate that network if it is available in more that one topologic location. Take /google as an example. Thanks, Sabet On Mon, May 23, 2016 at 8:55 AM, Alex Afanasyev wrote: > This is not exactly correct. The granularity of the LINK can be anything. > It can be a prefix that correspond to something like an AS (/att), it can > be a name that points to a network within the ISP (/att/net1/net2), or it > can be a host within the network (/att/net1/net2/net3/host). > > The specific usage would depend on what make sense for your application > and environment. With a more generic name (/att) you're relying on > name-based forwarding to direct your interests within that network directly. > > -- > Alex > > On May 22, 2016, at 8:44 PM, Junxiao Shi > wrote: > > Hi Sabet > > The granularity is an Autonomous System (AS). Within the AS, the name > prefix should be announced into intra-domain routing protocol, and Link > object is not used. > In NFD implementation, whether to use Link object is determined by > tables.network_region configuration option. See NFD devguide for more > information. > > Yours, Junxiao > > On May 21, 2016 11:02 PM, "Muhammad Hosain Abdollahi Sabet" < > mhasabet at gmail.com> wrote: > > > > Could you elaborate a bit more on this? If LINK points to a place, what > can be granularity of it? > > > > Regards, > > Sabet > _______________________________________________ > 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 aa at CS.UCLA.EDU Mon May 23 14:27:10 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Mon, 23 May 2016 14:27:10 -0700 Subject: [Ndn-interest] Scope of Link object? In-Reply-To: References: Message-ID: Which exactly prefix link points to is up to the environment. In the global environment, it make sense to use globally reachable names as part of hints. As for the second question. Let me use the attached picture to explain If the link includes just /ucla, then the prefix /ndn/ndnsim/... has to be routable within the whole UCLA network. If it is hard/infeasible to achieve (user needs to have some agreement with the campus network about it), then one can use a more specific prefix, e.g., /ucla/cs. This prefix needs to be routable within UCLA network and it is network operator responsibility to make it happen. Within CS dept network, the agreement to announce /net/ndnsim prefix is much simpler accomplish. However, if that part is also hard/infeasible, one can use the most specific prefix (i.e., prefix that is managed by the network operators) that points to the actual server. Consumers don't do anything to determine the link, except they looking it up in the mapping database. For producers, it should be up to agreements between producer and the network to determine where the app's prefix can go. The agreements themselves can be realized in form of proper namespace certificate chains. --- Alex > On May 23, 2016, at 12:43 PM, Muhammad Hosain Abdollahi Sabet wrote: > > Alex, > > So, the one thing we are sure about, is that Forwarding Hint should be globally routable. It means at least the first two components of it, should be available in DFZ. Is that correct? > I'm not looking for this one right now, but I'm curios. When you say Link could point to a network, how could one locate that network if it is available in more that one topologic location. Take /google as an example. > > Thanks, > Sabet > > On Mon, May 23, 2016 at 8:55 AM, Alex Afanasyev wrote: > This is not exactly correct. The granularity of the LINK can be anything. It can be a prefix that correspond to something like an AS (/att), it can be a name that points to a network within the ISP (/att/net1/net2), or it can be a host within the network (/att/net1/net2/net3/host). > > The specific usage would depend on what make sense for your application and environment. With a more generic name (/att) you're relying on name-based forwarding to direct your interests within that network directly. > > -- > Alex > >> On May 22, 2016, at 8:44 PM, Junxiao Shi wrote: >> >> Hi Sabet >> >> The granularity is an Autonomous System (AS). Within the AS, the name prefix should be announced into intra-domain routing protocol, and Link object is not used. >> In NFD implementation, whether to use Link object is determined by tables.network_region configuration option. See NFD devguide for more information. >> >> Yours, Junxiao >> >> On May 21, 2016 11:02 PM, "Muhammad Hosain Abdollahi Sabet" wrote: >> > >> > Could you elaborate a bit more on this? If LINK points to a place, what can be granularity of it? >> > >> > Regards, >> > Sabet >> >> _______________________________________________ >> 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: mapnencap-example-ndn.jpg Type: image/jpeg Size: 62970 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From lixia at CS.UCLA.EDU Mon May 23 14:53:32 2016 From: lixia at CS.UCLA.EDU (Lixia Zhang) Date: Mon, 23 May 2016 14:53:32 -0700 Subject: [Ndn-interest] Scope of Link object? In-Reply-To: References: Message-ID: > On May 23, 2016, at 12:43 PM, Muhammad Hosain Abdollahi Sabet wrote: > > Alex, > > So, the one thing we are sure about, is that Forwarding Hint should be globally routable. It means at least the first two components of it, should be available in DFZ. Is that correct? the forwarding hint (LINK) should be able to find a match from FIB; there isn't any specific limit on the number of components. > I'm not looking for this one right now, but I'm curios. When you say Link could point to a network, how could one locate that network if it is available in more that one topologic location. Take /google as an example. if you use the word "topological" (not geographical): network topology is not equivalent to locations. if the prefix "/google" is announced into the network from multiple places, then a router simply steers interests "/google" prefix (in its name or LINK) toward the nearest carrying announcement location (assuming best path strategy). > On Mon, May 23, 2016 at 8:55 AM, Alex Afanasyev > wrote: > This is not exactly correct. The granularity of the LINK can be anything. It can be a prefix that correspond to something like an AS (/att), it can be a name that points to a network within the ISP (/att/net1/net2), or it can be a host within the network (/att/net1/net2/net3/host). > > The specific usage would depend on what make sense for your application and environment. With a more generic name (/att) you're relying on name-based forwarding to direct your interests within that network directly. > > -- > Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From wentaoshang at gmail.com Mon May 23 16:18:18 2016 From: wentaoshang at gmail.com (Wentao Shang) Date: Mon, 23 May 2016 16:18:18 -0700 Subject: [Ndn-interest] nfd and iot? In-Reply-To: <1459981377.374138.1463881150532.JavaMail.yahoo@mail.yahoo.com> References: <1459981377.374138.1463881150532.JavaMail.yahoo.ref@mail.yahoo.com> <1459981377.374138.1463881150532.JavaMail.yahoo@mail.yahoo.com> Message-ID: Hi Gabriel, We have already ported the current NFD code to Raspberry Pi and a few OpenWRT-based router devices. We also have an on-going effort of a clean-slate implementation of NDN over RIOT-OS, which targets more constrained IoT devices. If you are interested in an overview of supporting IoT using NDN, I recommend you read our latest paper "Named Data Networking of Things": http://named-data.net/publications/ndn-iotdi-2016/ The alternative technologies you mentioned are all based on the pub-sub communication semantics while NDN's Interest-Data mechanism is request-response. The main advantages of NDN for IoT is in the use of expressive data naming, inherent data authentication support (and optional encryption-based access control), name-based forwarding, and in-network caching. None of the existing IoT solutions addresses all those issues together with a single L3 protocol and architecture. My understanding of MQTT is that it simply specifies the messaging interface (wire format and send/receive operations), but does not prescribe the implementation detail of the message brokers, which IMHO is the most challenging part. Kafka is designed for high-performance data center environments with heavy dependency on ZooKeeper. I don't think it is suitable for supporting communication between IoT devices, especially in constrained environments. I'm not familiar with WSO2 MB. Sounds like yet another implementation of MQTT/AMQP based message broker... Wentao On Sat, May 21, 2016 at 6:39 PM, Gabriel Silva wrote: > Hello I am interested in using nfd for IoT. However, I am looking for some > clarity on how it can be a differentiator from other technologies which > route data like mqtt, kafka, wso2 mb etc. Thank you for any help. > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > > -- PhD @ IRL, CSD, UCLA -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Mon May 23 20:33:25 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Mon, 23 May 2016 20:33:25 -0700 Subject: [Ndn-interest] nfd and iot? In-Reply-To: References: <1459981377.374138.1463881150532.JavaMail.yahoo.ref@mail.yahoo.com> <1459981377.374138.1463881150532.JavaMail.yahoo@mail.yahoo.com> Message-ID: Dear folks I have a little bit of experience playing with both NDN and MQTT on a temperature sensor. NDN is a request-response protocol. The temperature must first register a prefix on the router before it could receive Interests. This step is quite difficult given the limited computation power on the sensor. (reply to http://www.lists.cs.ucla.edu/pipermail/ndn-lib/2016-May/000330.html if you have a good idea) After getting past that step, the sensor just needs to respond to Interests. If we want to continuously collect temperature readings, a separate program is needed to continuously send Interests to the sensor. Although NDN allows multiple consumers to send Interests at the same time and the sensor only needs to process an Interest once, this capability is limited by the trust model. To workaround computation power limit, my sensor signs Data packets with HMAC instead of RSA or ECDSA. Since HMAC uses pre-shared key, I cannot tell the world what the key is. If I want the world to trust the temperature readings, my data collection process must re-sign the Data packets with a RSA/ECDSA key. Therefore, the world would only trust the Data packets from the data collection process, not from the sensor. MQTT is a pub-sub protocol over TLS. Both the sensor and the data collection process connect to a MQTT broker. The sensor periodically pushes its temperature reading to the broker, which is then delivered to the data collection process who has subscribed to the sensor's MQTT topic. A benefit of MQTT is that it uses less network bandwidth between sensor and broker. This is especially important if the sensor is connected over a slow and expensive cellular connection, although this may change when NDN has header compression. A drawback of MQTT is that it replies on the sensor to control reporting frequency, and there isn't an easy way to get "the most current reading" between two reports (which is easy in NDN by sending another Interest). If the reports are too frequent, there's more bandwidth overhead and can lead to congestion; if the reports are too infrequent, subscribers cannot get an accurate "current" reading. Finally, in terms of coding efforts, JSON over MQTT is much easier to program than NDN Interest-Data. But this may change when ndn-cpp-lite improves. Yours, Junxiao On Mon, May 23, 2016 at 4:18 PM, Wentao Shang wrote: > My understanding of MQTT is that it simply specifies the messaging > interface (wire format and send/receive operations), but does not prescribe > the implementation detail of the message brokers, which IMHO is the most > challenging part. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lixia at CS.UCLA.EDU Mon May 23 21:55:04 2016 From: lixia at CS.UCLA.EDU (Lixia Zhang) Date: Mon, 23 May 2016 21:55:04 -0700 Subject: [Ndn-interest] Scope of Link object? In-Reply-To: References: Message-ID: <6C544E9E-6385-404D-9D61-18D6B1596311@cs.ucla.edu> > On May 23, 2016, at 2:53 PM, Lixia Zhang wrote: > > >> On May 23, 2016, at 12:43 PM, Muhammad Hosain Abdollahi Sabet > wrote: >> >> Alex, >> >> So, the one thing we are sure about, is that Forwarding Hint should be globally routable. It means at least the first two components of it, should be available in DFZ. Is that correct? > > the forwarding hint (LINK) should be able to find a match from FIB; there isn't any specific limit on the number of components. > >> I'm not looking for this one right now, but I'm curios. When you say Link could point to a network, how could one locate that network if it is available in more that one topologic location. Take /google as an example. > > if you use the word "topological" (not geographical): network topology is not equivalent to locations. > if the prefix "/google" is announced into the network from multiple places, then a router simply steers interests "/google" prefix (in its name or LINK) toward the nearest carrying announcement location (assuming best path strategy). my apology -- I just noticed that my quick cut&paste looked confusing: it should be: if the prefix "/google" is announced into the network from multiple places, then a router simply steers those interests carrying "/google" prefix (in either its name or LINK) toward the nearest announcement location (assuming best path strategy). -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhasabet at gmail.com Mon May 23 22:23:41 2016 From: mhasabet at gmail.com (Muhammad Hosain Abdollahi Sabet) Date: Tue, 24 May 2016 09:53:41 +0430 Subject: [Ndn-interest] Scope of Link object? In-Reply-To: <6C544E9E-6385-404D-9D61-18D6B1596311@cs.ucla.edu> References: <6C544E9E-6385-404D-9D61-18D6B1596311@cs.ucla.edu> Message-ID: ? the forwarding hint (LINK) should be able to find a match from FIB; there isn't any specific limit on the number of components. You're right. I was talking in Web Namespace. By two I meant firstly one for /com, /net, /ir , etc and secondly /prefix. ?? if you use the word "topological" (not geographical): network topology is not equivalent to locations. if the prefix "/google" is announced into the network from multiple places, then a router simply steers those interests carrying "/google" prefix (in its name or LINK) toward the nearest carrying announcement location (assuming best path strategy). Actually geographical location is not matter to me here if there wouldn't be difference in routing costs. I mean for example, I enroll /sabet under /google in a LINK delegation. So interests carrying /sabet when arrive at DFZ will look for /google, then in /google network will be directly looked up. The question is if there are /google in multiple places(like one in US and one in West Asia) which leads to multiple topological places, and I create the LINK in West Asia, how can interests carrying /sabet in EU reach /sabet in West Asia, supposing US is the best path for EU in comparison to West Asia? Solving such situations are on network owners'(e.g /google)? Considerations should be considered by produces(e.g /sabet)? Thanks, Sabet On Tue, May 24, 2016 at 9:25 AM, Lixia Zhang wrote: > > On May 23, 2016, at 2:53 PM, Lixia Zhang wrote: > > > On May 23, 2016, at 12:43 PM, Muhammad Hosain Abdollahi Sabet < > mhasabet at gmail.com> wrote: > > Alex, > > So, the one thing we are sure about, is that Forwarding Hint should be > globally routable. It means at least the first two components of it, should > be available in DFZ. Is that correct? > > > ?? > the forwarding hint (LINK) should be able to find a match from FIB; there > isn't any specific limit on the number of components. > > I'm not looking for this one right now, but I'm curios. When you say Link > could point to a network, how could one locate that network if it is > available in more that one topologic location. Take /google as an example. > > > ?? > if you use the word "topological" (not geographical): network topology is > not equivalent to locations. > if the prefix "/google" is announced into the network from multiple > places, then a router simply steers interests "/google" prefix (in its name > or LINK) toward the nearest carrying announcement location (assuming best > path strategy). > > > my apology -- I just noticed that my quick cut&paste looked confusing: it > should be: > > ?? > if the prefix "/google" is announced into the network from multiple > places, then a router simply steers those interests carrying "/google" > prefix (in either its name or LINK) toward the nearest announcement > location (assuming best path strategy). > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ali.hamdans at yahoo.com Tue May 24 21:27:20 2016 From: ali.hamdans at yahoo.com (ali.hamdans at yahoo.com) Date: Wed, 25 May 2016 04:27:20 +0000 (UTC) Subject: [Ndn-interest] Transfer files using ndn References: <846081722.264370.1464150440549.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <846081722.264370.1464150440549.JavaMail.yahoo@mail.yahoo.com> Dear all, I am new to NDN and my purpose is to transfer files using NDN. I played with the ndnputchunks/ndncatchuncks. but this allow for one file transfer. if I have 2 files foo1 and foo2, the consumer should be able to ask for /test/foo1 and /test/foo2, then ndnputchunks will not work with the two files at same time! So if I have a many files to be transfer then should I push them to NDN first and then the consumer will start asking about them and how to do that? Is there any available example for that? Thanks,Hamdans -------------- next part -------------- An HTML attachment was scrubbed... URL: From ali.hamdans at yahoo.com Wed May 25 13:55:22 2016 From: ali.hamdans at yahoo.com (ali.hamdans at yahoo.com) Date: Wed, 25 May 2016 20:55:22 +0000 (UTC) Subject: [Ndn-interest] Transfer files using NDN References: <1804242267.831211.1464209722941.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <1804242267.831211.1464209722941.JavaMail.yahoo@mail.yahoo.com> Dear all, I am new to NDN and my purpose is to transfer files using NDN. I played with the ndnputchunks/ndncatchuncks. but this allow for one file transfer. if I have 2 files foo1 and foo2, the consumer should be able to ask for /test/foo1 and /test/foo2, then ndnputchunks will not work with the two files at same time! So if I have a many files to be transfer then should I push them to NDN first and then the consumer will start asking about them and how to do that? Is there any available example for that? Thanks,Hamdans -------------- next part -------------- An HTML attachment was scrubbed... URL: From tnsr.chatterjee at gmail.com Mon May 30 09:58:44 2016 From: tnsr.chatterjee at gmail.com (Tanusree Chatterjee) Date: Mon, 30 May 2016 22:28:44 +0530 Subject: [Ndn-interest] NLSR in NDNsim Message-ID: Hello, How can I run NLSR through NDNsim? I have successfully installed the simulator (version 2.1) in ubuntu 14.04 and downloaded the NLSR codes from github from the following link. https://github.com/named-data/NLSR. I have downloaded ndn-cxx and nfd while installing the NDNsim. So, do I need to download it again? Then I need to build the nfd and ndn-cxx? How can I build them? I hope to get help in this regard very soon. -- Regards, Tanusree Chatterjee -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhasabet at gmail.com Tue May 31 08:31:56 2016 From: mhasabet at gmail.com (Muhammad Hosain Abdollahi Sabet) Date: Tue, 31 May 2016 20:01:56 +0430 Subject: [Ndn-interest] NLSR in NDNsim In-Reply-To: References: Message-ID: Well, that is not that simple. As far as I know Anil was porting NLSR to ndnSIM. I dont know what is the last status. Thanks, Sabet On 30 May 2016 21:30, "Tanusree Chatterjee" wrote: Hello, How can I run NLSR through NDNsim? I have successfully installed the simulator (version 2.1) in ubuntu 14.04 and downloaded the NLSR codes from github from the following link. https://github.com/named-data/NLSR. I have downloaded ndn-cxx and nfd while installing the NDNsim. So, do I need to download it again? Then I need to build the nfd and ndn-cxx? How can I build them? I hope to get help in this regard very soon. -- Regards, Tanusree Chatterjee _______________________________________________ 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 lanwang at memphis.edu Tue May 31 18:10:18 2016 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Wed, 1 Jun 2016 01:10:18 +0000 Subject: [Ndn-interest] NLSR in NDNsim In-Reply-To: References: Message-ID: Sabet and Tanusree, Yes, we are still waiting for Anil to release the ndnSIM port of NLSR. Lan On May 31, 2016, at 11:31 AM, Muhammad Hosain Abdollahi Sabet > wrote: Well, that is not that simple. As far as I know Anil was porting NLSR to ndnSIM. I dont know what is the last status. Thanks, Sabet On 30 May 2016 21:30, "Tanusree Chatterjee" > wrote: Hello, How can I run NLSR through NDNsim? I have successfully installed the simulator (version 2.1) in ubuntu 14.04 and downloaded the NLSR codes from github from the following link. https://github.com/named-data/NLSR. I have downloaded ndn-cxx and nfd while installing the NDNsim. So, do I need to download it again? Then I need to build the nfd and ndn-cxx? How can I build them? I hope to get help in this regard very soon. -- Regards, Tanusree Chatterjee _______________________________________________ Ndn-interest mailing list Ndn-interest at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest _______________________________________________ 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 tnsr.chatterjee at gmail.com Tue May 31 22:00:18 2016 From: tnsr.chatterjee at gmail.com (Tanusree Chatterjee) Date: Wed, 1 Jun 2016 10:30:18 +0530 Subject: [Ndn-interest] NLSR in NDNsim In-Reply-To: References: Message-ID: Okay. What is the latest update about that? On Jun 1, 2016 6:40 AM, "Lan Wang (lanwang)" wrote: > Sabet and Tanusree, > > Yes, we are still waiting for Anil to release the ndnSIM port of NLSR. > > Lan > > On May 31, 2016, at 11:31 AM, Muhammad Hosain Abdollahi Sabet < > mhasabet at gmail.com> wrote: > > Well, that is not that simple. As far as I know Anil was porting NLSR to > ndnSIM. I dont know what is the last status. > > Thanks, > Sabet > On 30 May 2016 21:30, "Tanusree Chatterjee" > wrote: > > Hello, > > How can I run NLSR through NDNsim? I have successfully installed the > simulator (version 2.1) in ubuntu 14.04 and downloaded the NLSR codes from > github from the following link. https://github.com/named-data/NLSR. > I have downloaded ndn-cxx and nfd while installing the NDNsim. So, do I > need to download it again? Then I need to build the nfd and ndn-cxx? How > can I build them? > > I hope to get help in this regard very soon. > > -- Regards, > Tanusree Chatterjee > > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > > _______________________________________________ > 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: