Version 4 (modified by 11 years ago) (diff) | ,
---|
Materials and Guidance for leading this exercise: <CCN ASSIGNMENT>
Exercise materials
Anything that the instructor might need, e.g.:
- Instructions can be found Here
Guidance for leading the exercise
- useful Tools:
- ccnd
The ccnd daemon and its associated software is the reference implementation for the content-centric networking protocol proposed by Project CCNx. This assignment uses release 0.6.1 of the ccnx software package. More information on this package can be found at the Project CCNx web site, http: www.ccnx.org/. The CCN protocol embodied in CCNx is an attempt at a clean-slate architectural redesign of the Internet. - Atmos
The Atmos software package from the NetSec group at Colorado State University will provide named data for your network in the form of precipitation measurements. The Atmos tools are installed in /opt/ccnx-atmos. - NetCDF Tools
NetCDF (Network Common Data Form) is “a set of software libraries and self-describing, machine-independent data formats that support the creation, access, and sharing of array-oriented scientific data.” The NetCDF tools package provides several tools for manipulating NetCDF data, including ncks, a tool for manipulating and creating NetCDF data files; ncdump, a similar tool used for extracting data from NetCDF data files; and ncrcat, a tool for concatenating records from multiple NetCDF data files. - Flack
Flack is a graphical interface for viewing and manipulating GENI resources. It is available on the web at http://www.protogeni.net/trac/protogeni/wiki/Flack. You may use either Omni or Flack to create and manipulate your slices and slivers, but there are certain operations for which you will probably find one or the other easier to use. You will have to use the Flack client to Instrumentize your slices, as you will be directed some exercises.
Solutions
- 3.1 Routing in a Named Data Network
In this exercise, you will build a named data network using the Project CCNx networking daemon ccnd and transfer scientific data in the NetCDF format between data providers and data consumers using routing based on content names. For the purpose of this exercise, the network will use static routes installed at slice setup. Content will be served and consumed by the Atmos software package.
Create a GENI experiment using the precip.rspec file downloaded from here. It will allocate a network such as that depicted in the above figure, with ccnd running on every host and an Atmos server running on the hosts datastore1 and datastore2.
Routing in named data networks takes place using the namespace under which data is stored. In the case of CCNx, the data namespace is a doc/technical/URI.html URI, so it looks similar to the familiar http:// and ftp:// URLs of the World Wide Web. CCNx URIs are of the form ccnx:<path>, where <path> is a typical URI slash-delimited path. The components of the URI path are used by the network to route requests for data from consumers to the providers of that data. Routes have been installed on all of the machines in the network except researcher2, a data consumer node with two connections to the rest of the named data network.- Task 1.1: Finalize Configuration
In this task, you will observe the effects of the missing static routes, and restore them.
Log into the host researcher1. Run the command ccninitkeystore. Issue the command ccndstatus to print the status of the ccnd daemon on the local host. Note the number of content items stored on this host (which should be zero, if you have not yet fetched any content) and the number of interests accepted (under “Interest totals”).
Output for ccndstatus:[shufeng@researcher1 ~]$ ccndstatus researcher1.ccn.panther.emulab.net ccnd[1639] local port 9695 api 6003 start 1369836687.767003 now 1369842181.126690 Content items: 3 accessioned, 3 stored, 3 stale, 0 sparse, 0 duplicate, 3 sent Interests: 9 names, 0 pending, 0 propagating, 0 noted Interest totals: 3 accepted, 0 dropped, 3 sent, 0 stuffed Faces face: 0 flags: 0xc pending: 0 face: 1 flags: 0x400c pending: 0 face: 2 flags: 0x5012 pending: 0 local: 0.0.0.0:9695 face: 3 flags: 0x5010 pending: 0 local: 0.0.0.0:9695 face: 4 flags: 0x4042 pending: 0 local: [::]:9695 face: 5 flags: 0x4040 pending: 0 local: [::]:9695 face: 9 flags: 0x410 pending: 0 remote: 192.168.5.2:9695 Face Activity Rates Bytes/sec In/Out recv data/intr sent sent data/intr recv face: 0 0 / 0 0 / 0 0 / 0 face: 9 0 / 0 0 / 0 0 / 0 Forwarding ccnx:/ccnx/%F8%FD%A2o%23%7C%C7%EE%87w%EC%AA%F6%B6J%83%E4%9C%D9%20%B7%10f9%9D%87%EF%F8%10~%07%AF face: 0 flags: 0x17 expires: 2147478157 ccnx:/ccnx/ping face: 0 flags: 0x3 expires: 2147478157 ccnx:/%C1.M.S.neighborhood face: 0 flags: 0x3 expires: 2147478157 ccnx:/ndn face: 9 flags: 0x3 expires: 2147478172 ccnx:/%C1.M.S.localhost/%C1.M.SRV/ccnd face: 0 flags: 0x3 expires: 2147478157 ccnx:/%C1.M.S.localhost face: 0 flags: 0x23 expires: 2147478157
On researcher1, issue a request for precipitation data from 1902/01/01 through 1902/01/02. To do this, use the Atmos tools by invoking:/opt/ccnx-atmos/client.py
Answer the date questions appropriately, and observe that a .nc NetCDF file is created in the current directory containing precipitation data for the specified dates.
Output for client.py:[shufeng@researcher1 ~]$ /opt/ccnx-atmos/client.py Start Date in YYYY/MM/DD? 1902/01/01 End Date in YYYY/MM/DD? 1902/01/02 Asking for /ndn/colostate.edu/netsec/pr_1902/01/01/00, Saving to pr_1902_01_01.tmp.nc Time for pr_1902_01_01.tmp.nc 0.665292024612= Asking for /ndn/colostate.edu/netsec/pr_1902/01/02/00, Saving to pr_1902_01_02.tmp.nc Time for pr_1902_01_02.tmp.nc 4.67044997215= Joining files.. Concat + write time 0.0258212089539 Wrote to pr_1902_1_1_1902_1_2.nc
The .nc files:[shufeng@researcher1 ~]$ ls pr_1902_01_01.tmp.nc pr_1902_01_02.tmp.nc pr_1902_1_1_1902_1_2.nc
Run ccndstatus again, and look at the statistics on the local ccnd. You should see both that a substantial number of content items are cached on this machine (this is the meaning of the “stored” field under “Content items”) and that many more Interests have been seen.
Output for ccndstatus:[shufeng@researcher1 ~]$ ccndstatus researcher1.ccn.panther.emulab.net ccnd[1639] local port 9695 api 6003 start 1369836687.767003 now 1369842419.431508 Content items: 165 accessioned, 165 stored, 3 stale, 0 sparse, 0 duplicate, 165 sent Interests: 9 names, 0 pending, 0 propagating, 0 noted Interest totals: 166 accepted, 0 dropped, 166 sent, 0 stuffed Faces face: 0 flags: 0xc pending: 0 face: 1 flags: 0x400c pending: 0 face: 2 flags: 0x5012 pending: 0 local: 0.0.0.0:9695 face: 3 flags: 0x5010 pending: 0 local: 0.0.0.0:9695 face: 4 flags: 0x4042 pending: 0 local: [::]:9695 face: 5 flags: 0x4040 pending: 0 local: [::]:9695 face: 9 flags: 0x410 pending: 0 activity: 518 remote: 192.168.5.2:9695 Face Activity Rates Bytes/sec In/Out recv data/intr sent sent data/intr recv face: 0 0 / 0 0 / 0 0 / 0 face: 9 0 / 0 0 / 0 0 / 0 Forwarding ccnx:/ndn face: 9 flags: 0x3 expires: 2147477932 ccnx:/ccnx/ping face: 0 flags: 0x3 expires: 2147477917 ccnx:/%C1.M.S.neighborhood face: 0 flags: 0x3 expires: 2147477917 ccnx:/%C1.M.S.localhost face: 0 flags: 0x23 expires: 2147477917 ccnx:/%C1.M.S.localhost/%C1.M.SRV/ccnd face: 0 flags: 0x3 expires: 2147477917 ccnx:/ccnx/%F8%FD%A2o%23%7C%C7%EE%87w%EC%AA%F6%B6J%83%E4%9C%D9%20%B7%10f9%9D%87%EF%F8%10~%07%AF face: 0 flags: 0x17 expires: 2147477917
Next, log into researcher2 and issue the same command. Observe that it takes much longer at each step, does not terminate, and no .nc file is created. This is because the ccnd on researcher1 had routes to the precipitation data requested by Atmos, but researcher2 does not. Issue the following command to install the appropriate routes:ccndc add ccnx:/ndn tcp router
Note that the ccndc command takes a content path (ccnx:/ndn) and binds it to a network path (in this case, the host router, which is a valid hostname on the experiment topology, resolving to an IP address on the router machine). It can also be used to delete routes with the del subcommand. - Question 1.1 A:
From researcher2, fetch the same data again (from 1902/01/01 to 1902/01/02), and record the fetch times reported by client.py. It prints out the time take to pull each temporary file along with the concatenation and write time. Then fetch 1902/02/03 to 1902/02/04, and record those fetch times. Fetch 1902/02/03 to 1902/02/04 a second time, and record the new times. Which transfer was longest, and which was shortest? Knowing that each ccnd caches data for a short period of time, can you explain this behavior? Outputs:[shufeng@researcher2 ~]$ /opt/ccnx-atmos/client.py Start Date in YYYY/MM/DD? 1902/01/01 End Date in YYYY/MM/DD? 1902/01/02 Asking for /ndn/colostate.edu/netsec/pr_1902/01/01/00, Saving to pr_1902_01_01.tmp.nc Time for pr_1902_01_01.tmp.nc 0.228802204132= Asking for /ndn/colostate.edu/netsec/pr_1902/01/02/00, Saving to pr_1902_01_02.tmp.nc Time for pr_1902_01_02.tmp.nc 0.226236820221= Joining files.. Concat + write time 0.0258860588074 Wrote to pr_1902_1_1_1902_1_2.nc [shufeng@researcher2 ~]$ /opt/ccnx-atmos/client.py Start Date in YYYY/MM/DD? 1902/02/03 End Date in YYYY/MM/DD? 1902/02/04 Asking for /ndn/colostate.edu/netsec/pr_1902/02/03/00, Saving to pr_1902_02_03.tmp.nc Time for pr_1902_02_03.tmp.nc 0.661566972733= Asking for /ndn/colostate.edu/netsec/pr_1902/02/04/00, Saving to pr_1902_02_04.tmp.nc Time for pr_1902_02_04.tmp.nc 4.66726303101= Joining files.. Concat + write time 0.0256381034851 Wrote to pr_1902_2_3_1902_2_4.nc [shufeng@researcher2 ~]$ /opt/ccnx-atmos/client.py Start Date in YYYY/MM/DD? 1902/02/03 End Date in YYYY/MM/DD? 1902/02/04 Asking for /ndn/colostate.edu/netsec/pr_1902/02/03/00, Saving to pr_1902_02_03.tmp.nc Time for pr_1902_02_03.tmp.nc 0.0416989326477= Asking for /ndn/colostate.edu/netsec/pr_1902/02/04/00, Saving to pr_1902_02_04.tmp.nc Time for pr_1902_02_04.tmp.nc 0.0415050983429= Joining files.. Concat + write time 0.0257289409637 Wrote to pr_1902_2_3_1902_2_4.nc
Answer: The first time fetching data from 2/3 to 2/4 took the longest, the 2nd time fetching data from 2/3 to 2/4 took the shortest time.
Since ccnd caches data for a short period of time, the 2nd time researcher2 fetches data from 2/3 to 2/4, it fetches the data from local cache. Since researcher1 already caches data from 1/1 to 1/2, therouter
caches that data. As a result, researcher2 got the data from 1/1 to 1/2 from router cache. - Question 1.1 B:
Browse the content caches and interests seen on various hosts in the network by loading their ccnd status page on TCP port 9695 in your browser (see Section 5, Hints, below). Which hosts have seen interests and have content cached, and why?
Answer: datasource1, datasource2, router, researcher1 and researcher2 have seen interests and content cached. Since the data has passed them. - Task 1.2: Intent Propagation
This task will demonstrate the behavior of Intent filtering during propagation.
Log into the machine datasource1 and run the command tail -f /tmp/atmos-server.log. Next, run /opt/ccnx-atmos/client.py on both of the hosts researcher1 and researcher2. Enter 1902/01/15 as both start and end date on both hosts, and press <ENTER> on both hosts as close to the same time as possible. - Question 1.2 A:
What intents show up at datasource1 for this request? (Use the timestamps in the server log to correlate requests with specific intents.) Will you observe unique or duplicate intents when both researcher1 and researcher2 fetch the same data at precisely the same time? Why?
Answer: I see unique intents when both researcher1 and researcher2 fetch the same data at the same time. ccdn is able to intelligently identify duplicated intent and effectively filter it during propagation.
- Task 1.1: Finalize Configuration
In this task, you will observe the effects of the missing static routes, and restore them.
- Answers can be found Here
Attachments (4)
- CCNAssignment.png (253.3 KB) - added by 11 years ago.
- c1.png (157.3 KB) - added by 11 years ago.
- c2.png (151.1 KB) - added by 11 years ago.
- r2.png (154.5 KB) - added by 11 years ago.
Download all attachments as: .zip