200 likes | 329 Views
Anetd and the Abone. SRI International Livio Ricciulli. ANCORS. Http://www.csl.sri.com/ancors. Merging of Technologies. Network Management. Scalability Flexibility. Fidelity Software Reuse. Active Networking. Distributed Simulation. Design support. Advantages of Merging.
E N D
Anetd and the Abone SRI International Livio Ricciulli
ANCORS Http://www.csl.sri.com/ancors
Merging of Technologies Network Management • Scalability • Flexibility • Fidelity • Software Reuse Active Networking Distributed Simulation • Design support
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
Open Problems • Interoperable specification, modeling and simulation of networks • Simulation scalability • Adaptive monitoring and control • Maximizing reuse of existing software
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 ….)
Network Engineering and Management Hierarchy Automatic Response Control Services Adaptive Learning Heuristic Assessment Assessment Services Anetd Control & Monitoring Network Services Engineering Execution Env.
Load <url> (Digitally Signed) fork fork fork EE Engineering Control & Monitoring Alarms ANCORS Deploys, Configures and Controls Network Services in an Integrated and Extensible Fashion. ANCORS Daemon Network Management Client Trusted HTTP Server Services
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
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
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
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
SRI Abone registration sitewww.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?
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)
Anetd EE EE EE Port x EE EE z y x x x x x Overlay networks through Anetd 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.
Anetd in the protocol stack Option 1 User-level EEs (today) Anetd’s Functionality UDP TCP ICMP ANEP IP EEs Option 2 User-level EEs EEs Anetd’s Functionality ANEP AN Native
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. Anetd’s TODO list
Anetd+Xbone+VAN Other EE VAN Anetd ANEP XBone UDP/TCP IP