Plugin Framework for the MSR

1. Plugin Frameworkfor the MSR 11/15/2000 Ralph Keller

2. Programming Active Nets: Big Picture • Network Control Software (NCS) is a distributed system that • allows application to setup an active session • maps application requirements onto nodes (routing) • uses signaling to install plugins and add route table entries to route through processing sites install plugin and add route entry NCS API API NCS NCS Application Application NCS

3. MultiService Router Architecture install route signaling message install plugin signaling message OSPF RIP NCS NCS RSVP SSP Plugin Policy Controller Plugin Requester Plugin DB Routing table Resource Manager Active Plugin Loader Control Processor PE PE Router Router 8-Port ATM Switch (20Gb/s) Router Router PE PE

4. “Generic” Processing Element Architecture ANPE (WaveVideo) APIC ANPE (IP lookup) ANPE (Encryption) APIC APIC Switch LCs ANPEs IPPs OPPs ANPEs LCs • ANPEs can be plugged in on both input and output ports • Several ANPEs can be stacked on a port (e.g., FPX combined with SPC)

5. SPC Processing Element Architecture active processing path Runtime Environment Encryption Plugin WaveVideo Plugin SPC SW interrupt Active Resource Controller Compression Plugin IP Classifier Scheduler/DQ SPC HW interrupt Network APIC driver APIC Switch …

6. SPC Plugin Environment:Objectives • High performance • kernel space execution environment • code as loadable kernel modules • plugins operate in kernel address space • only active packets transit plugin environment, traditional IP traffic uses short-cut forwarding • active traffic processed at software interrupt level, short-cut forwarding at hardware interrupt level • Resource control • admission and policing should be performed by a higher instance (e.g., control processor) • routing table computed by CP and distributed to PEs

7. SPC Plugin Environment: Software Components • Plugin Runtime Environment • load plugins, create instances • bind flows to instances • handles control path and execution of plugins • Active Resource Controller • schedules a packet for active processing • removes packet from active processing queue, processes packet, and enqueues after processing for forwarding

8. Plugins Installed Through Signaling • All connections requiring active processing must pre-establish a routed path through the network • Required plugins are installed where needed through a signaling mechanism • Signaling setup message contains plugin reference and a flow table entry • If plugin not yet downloaded on PE, CP downloads plugin from code repository and installs plugin on PE by sending ATM control cells • CP also installs a specific route for new active flow, CP propagates route to PE by changing forwarding table

9. Plugin API • Each plugin supports: • load, unload: load plugin class • create, free: create instances of plugins • bind, unbind: bind an instance to a flow • ioctl: configuration of plugin • Should create and bind be combined? • yes: simpler API • no: more than one flow can be bound to instance • Two approaches for plugin-specific configuration: • generic method that takes plugin-specific parameters and returns plugin-specific data (e.g., ioctl) • plugin instances appear as file in /proc and using write and read syscalls instance can be configured

10. Implementation Phases • Phase 1: light-weight, simple plugin environment • load kernel modules, create instances, bind to flows • Controlled by a user space program running on PE • Phase 2: Implement protocol between CP and PE • User space program replaced by CP • Phase 3: Implement Active Resource Manager • remove active packets based on priority (rather than FIFO as in phase 1) • Gather some resource usage information, punish plugins that use more resources (CPU, memory) than they advertised