1. Anetd and the Abone SRI International Livio Ricciulli

2. ANCORS Http://www.csl.sri.com/ancors

3. Scalability Flexibility Merging of Technologies Fidelity Software Reuse Design support

4. Advantages of Merging Enhanced functionality –Simulation as a network resource –Load and fault models can be derived from real network Software reuse –Common deployment mechanism –Reuse NM to retrieve and analyze simulation results –Management of models through NM infrastructure

5. Open Problems Interoperable specification, modeling and simulation of networks Simulation scalability Adaptive monitoring and control Maximizing reuse of existing software

6. Three basic classes of deployable services Execution Environments (ANTS, PLAN, NetScript ….) Monitoring and Control (SNMP agents, Emerald monitors, RSVP....) Engineering (new) (ANCORS’s virtual kernel, Xkernel ….)

7. Engineering Control & Monitoring Execution Env. Network Services Assessment Services Adaptive Learning Heuristic Assessment Control Services Automatic Response Network Engineering and Management Hierarchy Anetd

9. ANCORS Deploys, Configures and Controls Network Services in an Integrated and Extensible Fashion. ANCORS Daemon Network Management Client Services Trusted HTTP Server Load (Digitally Signed) EE fork Control & Monitoring fork Engineering fork Alarms

10. Security Reuse Unix security mechanisms to specify and enforce: –Access to local resources (files, devices, CPU) –non-interference Use public key cryptography (RSA) to authenticate who is pushing (client) Restrict where code comes from –clients are not allowed to upload code directly but can only specify a trusted code servers

11. ANEP demultiplexing If ANEP packet is type 51 signature is verified and Anetd commands are executed –If command=Load a new EE is spawned, If T=id is present, future ANEP packets with Type=id will be forwarded to standard input of this EE if T is not present EE is just spawned; EE is on its own If ANEP packet is not type 51 try to forward to previously spawned EE For each Anetd, each ANEP type can only map to one EE

12. EE Requirements EE code should be placed on a trusted code server (ex. sequoia.csl.sri.com) If EE wants demultiplexing, it should read ANEP data from standard input and should be able to parse ANEP

13. EE requirements (cont.) Java –All native methods calls should be grouped in a small set of classes to be explicitly preloaded through Anetd together with the native libraries. –Need to use Anetd’s class loader http://sequoia.csl.sri.com:7000/netscript-0.10/src/netscript/kernel/Box.java –Since code comes from trusted code server we are liberal about Java security checks (almost everything is allowed) Native –Portable code, statically linked and compiled for Linux 2.x FreeBSD 2.x or 3.x and Solaris

14. SRI Abone registration site www.csl.sri.com/ancors/abone EE developers register their public keys and their intent of using the Abone. Node administrators register Abone nodes and pick EE developers to authorize. EE developers can find out (in real-time) which Abone nodes authorize them and pick nodes to build overlay networks. –Question: How do we let node administrators know about new EE developers that come along later?

15. Anetd-based ABONE today Anetd is deployed at: Columbia, Bellcore, CNR, ISI, MIT, SRI, TIS, UPM, Utah, Virginia Tech, Navy, Aerospace, Upenn, Hanyang, INRIA,U Washington, KU, UCLA. Students are beginning to do homework with Anetd and some EEs Anetd can build networks with the following EEs ANTS (Pure Java) (3 versions) PLAN (Ocaml) ARP (Java+Native) NetScript (Java+Native) ANCORS (Java+Native)

16. Abone Connectivity

17. y z x x x x x Overlay networks through Anetd Port x Anetd EE x Each Abone node runs multiple Anetd daemons each listening on ports x,y,z, etc.. Deamons can deploy and manage one-another including themselves! When an EE developer wants to build an overlay network he/she chooses an available port x, y, z, etc.. Since different EEs types can share the same input port through Anetd’s demultiplexing, EE developers can share same ports.

18. Anetd in the protocol stack IP TCP UDP ICMPANEP Anetd’s Functionality User-level EEs (today) EEs AN Native Anetd’s Functionality User-level EEs EEs Option 1 Option 2 ANEP

19. Anetd’s TODO list More documentation Make Anetd enforce persistence so that, after reboot, EEs are restarted automatically. Log all Anetd commands. Use HTTP caching to avoid downloading the same code. Authenticate code. Add debugging support. Port Anetd to more platforms. Public key update. Anetd as a component of the protocol stack.

20. Anetd+Xbone+VAN IP XBone Anetd UDP/TCP VAN Other EE ANEP