NDN Managed Gateways and The NDN Testbed John DeHart Computer Science & Engineering Washington University www.arl.wustl.edu
NDN Nodes Types of NDN Nodes » Gatew ay Routers » End User » Application Nodes Gatew ay Router Nodes » Managed • Managed by W ashington U. team so you don’t have to… • ONLY used for: – Gatew ay routing function ( ndnd, OSPFN) – Running a repository ( ndnr) – Operator m anagem ent of site keys and certificates • Each m em ber site w ill provide at least one m anaged gatew ay node – More m ay be provided if desired. • Non-m em ber sites m ay provide m anaged node( s) also » Unm anaged . . .
NDN Nodes Gatew ay Router Nodes ( continued) » Unm anaged • Mem ber sites m ay run additional unm anaged router nodes – Behind the site’s m anaged gatew ay router • Non-m em ber sites w ith a m anaged gatew ay router – May have additional unm anaged router nodes behind the site’s m anaged gatew ay router • Non-m em ber sites w ithout a m anaged gatew ay router – May have unm anaged node( s) connected through a m em ber site » That m em ber site takes on som e responsibility for non-m em ber site • Before any unm anaged node is added to the Testbed W U team needs to be notified To contact W U Testbed Managem ent Team : » Send em ail to: ndntestbed@arl.w ustl.edu
Managed Gateway Router Nodes I nstallation ( Done by local Site personnel) » OS: Ubuntu 1 2 .0 4 LTS Server ( Not Desktop) • http:/ / w w w .ubuntu.com / dow nload/ server • Add ssh server during installation • Tw o accounts: – operator: For local site operator – ndnops: For W U team ( provide us w ith the passw ord so w e can use sudo) » W e w ill provide a public key for ssh access – NO OTHER USER ACCOUNTS. » Firew all I ssues • GRE tunnel access to/ from other gatew ay nodes • ndnx access to/ from clients of a gatew ay node – Port 6 3 6 3 – Broadcast/ Multicast group on UDP 2 2 4 .0 .2 3 .1 7 0 port 5 6 3 6 3 • ssh access for W U team • Probably som e others that w e’ll learn about as w e bring it all up… » Certificates and keys • UCLA team is w orking on a new set of tools. • Local operator w ill be responsible for signing keys for local users
Managed Gateway Router Nodes Configuration and Maintenance ( Done by W U team ) » git vs. apt-get • Tagged versions of packages from git repos and build on each node • I n the future w e m ay build Ubuntu pkgs for installation from a PPA – > sudo apt-get install ndn » W hat NDN related packages? • ndnx: ( ndnd, ndnr, …) • OSPFN3 .0 • ndnxm l client: generates data for ndnm ap • NDN packages to support certificates and keys • Perhaps a few others… » Configuration of a Node • GRE Tunnels • OSPFN Configuration • Configuration files installed from git repo – Separate set of files for each Testbed node » W U team w ill define and m aintain configuration files – May use a private git repo to protect configuration files – I n the future configuration files m ay be installed as part of ‘apt-get’
Managed Gateway Router Nodes Plan for releases » 3 m onth cycle ( 1 1 / 2 0 1 3 , 2 / 2 0 1 4 , …) » Testing of new releases • Unit testing of each individual package is done by ow ner of package • I ntegration testing to be done by W U – W U’s Open Netw ork Lab ( ONL) Testbed ( http:/ / onl.w ustl.edu/ ) » More about this later… Research Testbed vs. Reliable Managed Testbed » W hat are w e allow ed to experim ent w ith? • Strategy layer experim entation? • Caching and forw arding strategy experim entation? • Routing protocol experim entation? » ndnd developm ent responsibilities • Strategy layer • Caching and Forw arding • Bug Fixes • Testing and Release
NDN Testbed Operations Responsible Parties » W ashington U. Team w ill m anage • Rem ote restarts • Rem ote updates • Rem ote configuration » Operator( s) at each site w ill be responsible for: • Physical I nstallation • I nitial OS I nstallation • Manual interventions ( pow er cycle, crash recovery, etc.) • Local user key signing » Testbed Root key m anagem ent
NDN Testbed Operations (continued) Status Monitoring » W e plan to consolidate and augm ent current status m onitoring tools • Mem phis: http:/ / netlab.cs.m em phis.edu/ script/ htm / status.htm • Arizona: http:/ / w w w .cs.arizona.edu/ people/ yifengl/ tbs.htm l » Node status » Link status » ndnd status • Mem ory size? • etc… » Routing/ Prefix/ FI B status » etc… Usage Monitoring » Bandw idth • W ashington U: http:/ / ndnm ap.arl.w ustl.edu/ » I nvestigate w hat ndnd internals can be m onitored effectively • PI T entries? • Content store? » Application specific m onitoring? » etc…
Current NDN Testbed NEU PARC 10.0/24 5.0/24 3.22 SPP UIUC SALT 8.0/24 REMAP 3.21 SPP 11.0/24 KANS UCLA 3.0/24 SPP WASH CSU WashU 4.38 4.37 3.29 4.0/24 9.0/24 UCI 6.0/24 3.30 SPP 4.6 ATLA UCSD UM UA 2.0/24 7.0/24 1.9 1.0/24 1.10 1.29 1.30 SPP HOUS
NDN Testbed Changes Rem oval of W U SPP Nodes » Special purpose ATCA chassis that w ere part of the GENI project » Located at I nternet2 Sites » No longer feasible tim e-w ise to m aintain » W ill not conform to new NDN-NP Testbed policy constraints Change in participating sites Re-organization of inter-node links » Three general regions: • California ( UCLA, UCLA Rem ap, UCSD) Continental Divide ( Arizona, CSU) • • Midw est ( Michigan, Mem phis, UI UC, W ashU) W e already have requests from non-m em bers to join » Beijing and other sites in China » Paris and other sites in Europe » Others?
Proposed NDN-NP Testbed: Geographic View UMich CSU UIUC WU REMAP UCLA UM UA UCSD
Proposed NDN-NP Testbed CSU 4.0/24 MICH 1.6 12.0/24 3.9 UCLA 3.10 REMAP 3.0/24 11.0/24 UIUC 8.0/24 WashU UCSD 9.0/24 7.0/24 1.5 UM UA 2.0/24 1.1 1.2 1.0/24 All I Ps have the form 1 0 .0 .x.y. Last tw o bytes show n in above diagram . Each Site is assigned a / 2 4 subnet Each link is in a / 3 0 subnet » Link 1 0 .0 .x.y/ 1 0 .0 .x.y+ 1 is in a subnet of 1 0 .0 .x.y-1 – 1 0 .0 .x.y+ 2
NDN Testbed Changes (continued) Testbed size? » Are there research goals that require a larger testbed? » Are there any research goals that should influence link choices? • Rich vs. sparse interconnection Alternatives for adding m ore nodes » Extra nodes at m em ber sites » Non-m em ber sites » EC2 I nstances
NDN Testbed Integration Testing using the Open Network Lab (ONL) ONL is an Internet-accessible networking lab (onl.wustl.edu) » built around set of extensible gigabit routers » intuitive Remote Lab Interface makes it easy to get started » extensive facilities for performance monitoring Current Resources: » 14 highly configurable five port Network Processor based Routers » over 100 rack-mount computers that serve as end systems • including multicore servers with 8 cores and 48 cores » Support for ccnx In the works: » Support for ndnx » Support for VMs » 84 new machines (24 12 core, 60 2 core) » 12 5-port software routers » 8 2-port 10Gb/ port (or 16-port 1Gb/ port) software routers
Overview of ONL Remote access through the Internet using a graphical user interface ( called the RLI) Provides access to variety of hardware resources Experimental networks built with configuration switches
NDN Testbed Topology in ONL for Testing
Recommend
More recommend