OCALA: An Architecture for Supporting Legacy Applications over Overlays Dilip Joseph 1, Jayanth...
-
Upload
dorcas-walton -
Category
Documents
-
view
218 -
download
0
Transcript of OCALA: An Architecture for Supporting Legacy Applications over Overlays Dilip Joseph 1, Jayanth...
OCALA: An Architecture for Supporting Legacy Applications
over Overlays
Dilip Joseph1, Jayanth Kannan1,
Ayumu Kubota2, Karthik Lakshminarayanan1, Ion Stoica1, Klaus Wehrle3
1UC Berkeley, 2KDDI Labs, 3RWTH Aachen University
Motivation• Efforts to change Internet : limited success
– IP multicast, QoS
• Overlays provide new features without changing the Internet– Resilient Overlay Networks (RON) : resilience to path failures– Internet Indirection Infrastructure (i3) : mobility, NAT
traversal, anycast, multicast
• But still no widespread deployment– Users unwilling to shift to new application programs– No interoperability between different overlays
Goal 1 – Legacy Application Support
• Enable legacy applications to work over new network architectures and overlays– Applications that work on IP– Unmodified– Users choose the best overlay for a particular
application
Simultaneous access to different overlays
FirefoxFirefox
sshdsshd
www.cnn.com
IRCIRC sshssh
i3RON
Internet
IRCIRCHost A (San Jose)
Host B (India)
Host C (China)
Goal 2 - Interoperability
• Enable hosts in different overlays to talk to each other– Interoperability between hosts in different
overlays– Interoperability between overlay hosts and
pure IP hosts– Combined benefits of different overlays
RON
Stitching together different overlays
• Mobility of i3 available for the first hop to the gateway
• Robustness of RON available for the second hop to the final destination
Host A (Berkeley)
ssh
Host B (India)
sshd
Gateway (SFO)
i3
Goal 3 – Factoring out Common Functionality
• Lower barrier of providing support for legacy applications over new overlays– Concentrate on architecture; not on
supporting legacy applications– Factor out common functionality
• Example: Authentication & encryption
– Plug-in overlays into a common framework
Contents
Introduction
Design
Applications
Implementation
Conclusion
Overlay Convergence Architecture for Legacy Applications (OCALA)
Overlay Convergence (OC) LayerOverlay Convergence (OC) Layer
Overlay(i3, RON, DOA, HIP …)
Overlay(i3, RON, DOA, HIP …)
Legacy Applications(ssh, firefox, explorer, …)
Legacy Applications(ssh, firefox, explorer, …)
Transport Layer(TCP, UDP, …)Transport Layer(TCP, UDP, …)
OC Independent (OC-I) Sublayer
OC Dependent (OC-D) Sublayer
Interpose an Overlay Convergence Layer between transport layer and overlay networks
Interpose an Overlay Convergence Layer between transport layer and overlay networks
Application LayerApplication Layer
Transport LayerTransport Layer
Network LayerNetwork Layer
Link LayerLink Layer
Expressing which overlay to use
• DNS-like names to identify machines (or services)
ucb .i3 Interpreted by OC-I• OC-I uses suffix to invoke corresponding OC-D instance OC-I
OC-D
Transport
Overlay• OC-D resolution mechanism
– General (e.g., OpenDHT, DNS, address book)– Overlay specific (e.g., hashing names to IDs in i3)
• Configuration file– Support applications not using DNS names– Store user preferences
Interpreted by OC-D• OC-D resolves this name to an overlay specific ID/Address
Legacy App.
Transport Layer
Host A (IDA)
OC-I
OC-D
Setting up a new connection
i3
Legacy App.
Transport Layer
Host B (ucb.i3, IDB)
OC-I
OC-D
1 DNSreq(ucb.i3)
2 setup(ucb.i3)
Name Res. Service (local addrbook,
DNS, OpenDHT…)
3 resolve(ucb.i3)
RONi3 RON … i3 RON …
4 IDB
5 overlay specificsetup protocol
tdAB IDB tdBAIDA
i3 i3
tunnel_d = tdAB6
OCI-Setup (pdAB)7pdAB ↔ IPAB
pdAB tdAB
“ucb.i3” pdAB pdAB ↔ IPBA
pdAB tdBA
DNSresp(IPAB)8
1.0.0.0/8
Legacy App.
Transport Layer
Host B (ucb.i3, IDB)
OC-I
OC-Di3
Legacy App.
Transport Layer
Host A (IDA)
OC-I
OC-Di3
Data Flow
i3
tdAB IDB tdBAIDA
pdAB ↔ IPAB
pdAB tdAB
“ucb.i3” pdAB pdAB ↔ IPBA
pdAB tdBA
IPAIPAB data
tdAB, pdAB dataIPAIPAB
pdAB dataIPAIPABIDB
pdAB dataIPAIPAB
IPBA IPB data
Simultaneous access to different overlays
OC-IOC-I
i3
FirefoxFirefox
OC-IOC-I
RON
sshssh
www.cnn.com
RON
IRCIRC sshssh
…
OC
-D
i3RON
Internet
…OC-IOC-I
i3
IRCIRC
…
Host A (San Jose)
Host B (India)iitm.ac.in.ron
Host C (China)chinairc.i3
IP
Stitching together different overlays
• A sets up tunnel to sfgateway.i3 over i3.• B sets up tunnel to iitm.ac.in.ron over RON.
OC-I
Host A (Berkeley)
ssh
OC-I
Host B (India)iitm.ac.in.ron
sshd
OC-I
Gateway (SFO)sfgateway.i3
i3
OC
-D
i3 RON
RONi3 RON
*.ron sfgateway.i3
Contents
Introduction
Design
Applications
Implementation
Conclusion
Applications
• New functionality enabled by the overlay
• Example: i3 enables hosts to force all incoming traffic through off-path middleboxes
Demo
i3
Webserverdilip-secure.pli3
Remote Client ProxyR
Web Browser
GET dilip-secure.pli3.ocalaproxy.net
GET dilip-secure.pli3
Bro Middlebox(In office)
GET dilip-secure.pli3
Internet
• Communication between non-overlay host and overlay host
• Web server dilip-secure.pli3 imposes Bro IDS on its path using i3
(At home)
Applications
• Robust connections over RON
• Access to machines behind NATs using i3
• OCALA Secure Connection– Unsecured wireless prone to eavesdropping
Applications
• Robust connections over RON
• Access to machines behind NATs using i3
• OCALA Secure Connection– Unsecured wireless prone to eavesdropping– Use encrypted tunnel to gateway– Similar to Google secure wifi
Contents
Introduction
Design
Applications
Implementation
Conclusion
Implementation
• A user-level proxy• tun device used to capture packets• Linux, Windows XP and Mac OS X – 40k SLOC of C++• OC-D modules
– Dynamically loadable libraries– Simple 5 function call interface – less than 200 lines of glue code– i3, RON OC-D modules written internally– Host Identity Protocol (Andrei Gurtov, HIIT, Helsinki)– Delegation Oriented Architecture (Evelyn Eastmond, Daniel
Wendel, Lev Popov, MIT)– OverDoSe (Runting Shi, CMU)
• GUI for configuring OCALA written in Java
Overheads and Limitations
• OC-I headers – 14 bytes
• Micro-benchmarks– OC-I : 40 microseconds per packet– i3, RON OC-Ds : 20-30 microseconds per
packet
• LAN experiments– 90% of the TCP throughput over direct IP
• Packet rewriting FTP, SIP will not work
Related Work
• Overlay-specific application support:– RON, i3, HIP
• Stitching together multiple address spaces:– AVES, TRIAD, UIP
• OASIS (U. Wash. & U. Mass.) – Provide isolation, but no interoperability
• …
Conclusion
• Enable evaluation of new architectures with real users and real applications– Simplify legacy application support– Bring benefits of new architectures to real
users
http://ocala.cs.berkeley.edu
Thank you
http://ocala.cs.berkeley.edu