xKernel: An Operating System Designed For Protocol Composition

1
x-KernelAn Operating System Designed For
Protocol Composition

• Developed at the University of Arizona byNorman
  C. Hutchinson and Larry L Peterson
• Presented by Ben Voigt
• 25 June 2003

2
Outline

• Motivation for x-Kernel
• Previous Network Operating Systems
• New Requirements
• x-Kernel Architecture
• Design Priorities
• Components
• Application Examples
• standards-compliant TCP/UDP/IP stack on Ethernet
• Sun RPC and Sprite RPC
• Results
• Protocols Implemented in x-Kernel
• Performance comparison with SunOS 4.0.3

3
Motivation

• Deficiencies of Previous Operating Systems
• Mandate a particular protocol suite
• Require redesign to add new protocols
• Or implement protocols in user space
• Data crossing network layer boundaries must use
  inter-process communication performance suffers
• No standard buffer/memory-management
• Each protocol developer must implement and debug
• Protocols designed independently cannot share
  buffer space

4
New Requirements

• Well-defined Interface all Protocol Elements
  Adhere to
• Arbitrary Composition
• Encapsulated Design hides Protocol Implementation
  Details
• High-Performance Kernel Implementation
• Direct Access to Hardware Resources
• Different Scheduling than User Processes

5
x-Kernel Architecture

• Design Priorities
• Maximize Composition Flexibility
• Minimize Protocol Implementation Effort
• Maximize Throughput
• Minimize Resource Usage

6
x-Kernel Architecture

• Provides Uniform Interface Between Protocols
• Interface is Designed for Efficiency
• shared address space
• process-per-message scheduling
• Provides Efficient glue code for Compositing
  Protocols
• Provides Standard Routines
• facilitates shared memory designs, eliminates
  unnecessary copy operations
• provides abstract interface to hardware resources
  such as timers and memory needed by intermediate
  protocols only device drivers need a-priori
  knowledge of hardware components

7
Buffer Management

• allocate and free
• concatenate two buffers into one buffer
• split a buffer into two buffers
• truncating either end of a buffer
• allow multiple references without copying

8
Protocol Interface

• Protocol Object
• active open
• passive open (similar to listen/accept in
  Berkeley Sockets, except event-driven)
• demux
• Session Object
• push (messages moving down the stack)
• pop (messages moving up the stack)

9
(No Transcript)
10
Protocol Composition

• defined prior to x-Kernel initialization
• construct a protocol graph, assigning each
  protocol an identifier in the address space of
  the protocol below (i.e. port number)
• applications are added as leaf nodes of the graph
  at run-time
• graph is assumed to be tree-like
• graph must be acyclic

11
Application Examples

• TCP/UDP over IP over Ethernet
• Not truly a layered protocol!
• monolithic approach benefits from cross-layer
  data sharing, x-kernel cannot
• Sun RPC, Sprite RPC (layered on UDP)
• x-kernel implements these protocols in the kernel

12
Results

• A small number of protocols were implemented
• Application-level protocols Sun NFS, TFTP, DNS,
  the run time support system for the Emerald
  programming language, the run time support system
  for the SR programming language
• Interprocess communication protocols UDP, TCP,
  Psync, VMTP, Sun RPC, Sprite RPC
• Network protocols IP
• Auxiliary protocols ARP, ICMP
• Device protocols ethernet drivers, display
  drivers, serial line drivers

13
Performance vs SunOS 4.0.3
14
Performance vs Sprite
15
Conclusions

• Primitives for buffer-management are much more
  efficient and scaleable than the implementations
  in Unix
• x-Kernel allows protocol encapsulation without
  sacrificing performance
• Protocols executing in kernel have significant
  advantages over user-mode

16
for APNets?

• Kernel Implementation is desirable
• We want dynamic reconfiguration
• Can we get cross-protocol optimization without
  hand-tuning?
• Capability of cyclic graphs?