X-Bone Roadmap (1997-2006)

Core Issues

• The X-Bone 1997 NGI Whitepaper

  Presents the basic vision

• The X-Bone 1998 Global Internet at Globecom

  Describes the basic architecture where:

  • Each overlay has one manager
  • Each resource has one manager
  • The two managers interact

  Describes multicast-based resource discovery and control

  • Resource discovery was used; control
  • Was replaced with unicast for security purposes (in original 1997 white paper)

  Describes the need for host and router virtualization and isolation between the interface groups

  • Esp. the need to group interface sets together
  • In hosts this is now supported by Marco Zec's Clonable stacks, but for a different reason (he did it to support different stacks in one host, e.g., Reno and Tahoe)
  • In routers this is now supported by virtual routers in Ciscos etc., but not as much in host-based routers

  Describes how tunnels are key to a virtual network

  Describes how addresses are local to an overlay i.e., there's no such thing as an overlay without addresses

• ** X-Bone 2000 ICNP / 2001 Computer Networks

  Describes architecture in more detail

  Discusses security issues like dynamic routing interactions, IPsec interactions, QoS, automation

• Web service deployment SEID 2000
  Application deployment DANCE (Darpa Active Nets) 2002 
  

  Describes using X-Bone script capabilities to deploy apps on top of an overlay as part of overlay deployment
  
  SEID paper describes early experience; DANCE paper goes into the script structure
  
  This script was used to deploy a PlanetLab-like set of jails on an X-Bone in 2003 on the PLab mailing list
  
  This script was used to help coordinate multi-layer overlays in DynaBone in 2003

• DynaBone 2003 Discex
  

  Describes using multilayer overlays for hiding multipath
  
  Used the X-Bone's application deployment script to configure the multilayer overlays 
  

• ** Virtual Internet Architecture 2003 ISI tech report 570 (presented at FDNA at Sigcomm 2003)

  Describes the network virtualization architecture based on:
  
  • - Per virtual node addresses
  • - Two-layer tunneling to support recursion (for scale) and revisitation (for reuse)
  • - Phantom routers inside hosts
  • - Recursion for control scale vs. recursion for embedding one topology in another

• ** GX-Bone 2005 Tridentcom

  Describes extending the X-Bone system from independent deployments to a single, global, persistent infrastructure
  
  Describes extensions to support registry-based discovery and push-based shared configuration dissemination (for ACLs, logins, etc.)

• X-Bone API 2005 ISI tech report #611

  Describes the XML syntax by which users/applications can interface to the X-Bone to request the deployment of an overlay
  
  Describes both the control API and the sublanguage called "Xbone Overlay Language" to describe (recursively) overlays
  
  The language supports:
  
  • - Registry and multicast-based discovery
  • - Recursion in management (control) and topology (network)
  • - Constraint-based description of an overlay
  • - Topology description of an overlay
  
  Briefly describes extensions to support P2P in-band modification of an overlay

• P2P-XBone 2005 ISI tech report #607

  Accepted to IEICE Transactions spec. issue on overlay tech.
  
  Developed and implemented extensions to the control protocol to allow an overlay to be re-wired (tunnels created/destroyed) from within the overlay
  
  

Other issues (implemented in code except as marked with*)

• Decentralized management

  Resources keep own state, keep it private; respond to invites only when ACL indicates (1998 paper)
  
  • Multicast via expanding ring search (1998 paper)
  • Registry for unicast discovery (LDAP) (2005 tridentcom)
  
  One overlay-manager/overlay for distrib. control (2001 paper)
  
  • *Allows for easier backup OMs (not implemented)
  • *Architecture and API languages support recursion and Divide-and-conquer management (not in code)
  
  Resources are opaque
  
  • Requests are patterns, resources are labeled with IDs
  • Matching is done by applying patterns to IDs
  
  Resources are managed
  
  • Resource counts, resource limits
  • Access control lists based on name patterns

• Robust configuration

  Idempotent operations (just in the code)
  • Replays are ignored
    
    
  Heartbeats for liveness (2001 paper)
  • Overlay comes down when OM disappears
  • Returns to 'safe state' (cleans itself up)
    
    
  Secure communication (2001 paper)
  • SMIME-signed multicast invitations
  • SSL-secured unicast control channels
    
    
  Nested transactions, 3-phase, rollbacks (2001 paper)
  • Cleans up after errors in the middle of deployment
  • *Assumes 3-phase random-delay retry to avoid deadlock
  • *Strict deadlock requires ordered transactions (ISIS)
    
    
  Save-to-disk state (2001 paper)
  • OM, RD both recover and restore after a crash

• Network reentrancy

  Keeps overlays separate, allow revisitation/recursion (2001 paper)
  
  Requires keeping interface groups separate (from 1998 paper)
  
  Requires keeping filesystems, username spaces separate (from 2002 DANCE paper)

• Support for experiments

  Application deployment script (2000 and 2002 script papers, 2003 dynabone paper)
  
  Control from inside the overlay (2005 IEICE paper) 
  

Artifact:

• Implementation

  Multiple Platforms
  • - FreeBSD /usr/ports/net/xbone
  • - Linux RPM
  • - Cisco routers via FreeBSD buddy host
    
    
All done in Perl, all commented throughout (there are perl-to-c translators)

Code and architecture has been "Red Teamed" by Sandia