1 / 42

OCALA: An Architecture for Supporting Legacy Applications over Overlays

OCALA: An Architecture for Supporting Legacy Applications over Overlays. Dilip Antony Joseph 1 , Jayanth Kannan 1 , Ayumu Kubota 2 , Karthik Lakshminarayanan 1 , Ion Stoica 1 , Klaus Wehrle 3. 1 UC Berkeley, 2 KDDI Labs, 3 University of Tübingen. Motivation.

tanuja
Download Presentation

OCALA: An Architecture for Supporting Legacy Applications over Overlays

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. OCALA: An Architecture for Supporting Legacy Applications over Overlays Dilip Antony Joseph1, Jayanth Kannan1, Ayumu Kubota2, Karthik Lakshminarayanan1, Ion Stoica1, Klaus Wehrle3 1UC Berkeley, 2KDDI Labs, 3University of Tübingen

  2. Motivation • Efforts to change Internet infrastructure not successful • Mobile IP, IP multicast, Intserv • Overlays provide new features without changing the Internet • RON : resilience to path failures • i3 : mobility, NAT traversal, anycast, multicast • OverQOS : quality of service • But still no widespread deployment • Inertia in shifting to a new application • Enable popular applications (Firefox, IE, samba, ssh) to benefit from overlay

  3. Legacy Applications on Overlays • Approach 1 : rewrite/port apps for each new overlay • time-consuming, tedious, impossible for closed source apps • Approach 2 : enable support for legacy applications on multiple overlays

  4. Goals • Transparency • Legacy apps unaware of overlay • Inter-operability • Hosts in different overlays should be able to talk to each other • Expose Overlay Functionality • User control over which overlay to use, what overlay specific properties to use • Factor out common requirements • Security, compression

  5. Legacy Applications (ssh, firefox, explorer, …) Transport Layer (TCP, UDP, …) OC Independent (OC-I) Sublayer Overlay Convergence (OC) Layer OC Dependent (OC-D) Sublayer Overlay (DOA, DTN, HIP, i3, RON, …) Overlay Convergence Architecture for Legacy Applications (OCALA) Interpose an Overlay Convergence Layer between transport layer and overlay networks.

  6. Simultaneous access to multiple overlays Host B Host C ssh Host A IRC OC-I Firefox IRC ssh OC-I … RON … OC-I i3 … OC-D IP i3 RON RON www.cnn.com i3 Internet

  7. Overlay specific name Overlay instance Naming • DNS-like names to identify machines (or services) berkeley berkeley .pl.i3 .pl.i3 Transport Overlay type OC-I • Interpreted by OC-I • OC-I uses suffix to • invoke corresponding • OC-D instance OC-D Overlay • Interpreted by OC-D • OC-D resolves this name • to an overlay specific • ID/Addr (e..g, i3 ID, HIT, • EID, IP addr) • OC-D resolution mechanism • Overlay specific (e.g., hashing names to IDs in i3) • General (e.g., OpenDHT, DNS, address book) • Identity mapping: OC-D names can be just flat IDs • Configuration file to store user preferences

  8. Bridging Overlays • Application at host A issues a DNS request for foo.ron_bar.i3 • A sets up tunnel to bar.i3 (B) over i3. • B sets up tunnel to foo.ron (C) over RON. • Path from A to C consisting of the two tunnels. Host A Host C (foo.ron) Appl. Appl. Host B (bar.i3) OC-I OC-I OC-I OC-D i3 RON i3 RON RON i3 tunnel tunnel path

  9. Legacy Server Gateways • Server need not run OCALA locally • Special OC-D module called Legacy Server IP (LSIP) at gateway • LSIP behaves like a software NAT box Overlay client Legacy gateway Appl. Legacy server (www.nasa.gov) OC-I OC-I OV LSIP OV Overlay (OV) Internet *.gov  OV … Configuration file

  10. Legacy Client Gateways • Clients need not run OCALA locally • Gateway has special Legacy Client IP (LCIP) module Overlay server (foo.ov) Legacy gateway Appl. OC-I Legacy Client OC-I OV OV LCIP Internet Overlay (OV) DNSreq(foo.ov.ocalaproxy.net)

  11. Legacy Client Gateway Demo http://flute.i3.6to4.jp:8080/ • Home machine behind NAT running OCALA. • Legacy Client Gateway running OCALA. • No modification to NAT. • Client (your web browser) does not run OCALA.

  12. Design

  13. DNSreq(foo.ov) DNSresp(oc_handle = IPAB) OCI-Setup (pdAB) 1 7 8 Name Res. Service (local addrbook, DNS, OpenDHT…) tunnel_d = tdAB setup(foo.ov) 2 6 resolve(foo.ov) 3 IDB 4 overlay specific setup protocol 5 Setting up a new connection Host A Legacy App. 1.x.x.x Transport Layer Host B (foo.ov, IDB) OC-I Layer OC Layer … Overlay (DTN, i3, RON) i3 RON

  14. data IPAB data IPBA tdAB, data data pdAB IPAB pdAB IPAB IDB pdAB IPAB data Data Flow Host A (IDA) Host B (foo.ov, IDB) Legacy App. Legacy App. Transport Layer Transport Layer “foo.ov”  pdAB OC-I pdAB↔ IPBA OC-I pdAB↔ IPAB pdAB  tdAB pdAB  tdBA Overlay (DTN, i3, RON) OC-D tdABIDB tdBAIDA OC-D

  15. Overlay Dependent Layer • API exposed by OC-D to OC-I layer • Setup (tunnel_info) • Close (tunnel_d) • Send (tunnel_d, pkt) • Callbacks from OC-D to OC-I • SetupDone (tunnel_d) • Recv(pkt) • i3, RON modules implemented

  16. Applications

  17. Applications • Simultaneous access to multiple overlays • Overlay composition • Allows user to merge functionality of various overlays • Eg: Wireless internet access using i3 over the wireless hop and RON over the wide area. • Applications enabled by new overlays • Receiver imposed middleboxes • NAT traversal

  18. Receiver Imposed Middleboxes • Receiver (foo.i3) enforces all traffic to pass through a middlebox using overlay functionality (e.g., i3) • Demonstration of receiver imposed Bro Intrusion Detection System during poster session Sets up connection to foo.i3 Host A foo.i3 Appl. Bro Appl. OC-I OC-I OC-I i3 i3 i3 i3

  19. i3 NAT Box NAT Traversal Application • Using i3 servers as a relaying point • Allows direct communication between NATed hosts • Demo during poster session

  20. Implementation • Implemented as a proxy • tun device used to capture packets • Works on Linux and Windows XP/2000 (using cygwin) • Implemented RON and i3 OC-D modules. • 200 lines of glue code in case of RON • Security • Authentication and Encryption using an ssl-like protocol extended to accommodate middleboxes

  21. Limitations • Applications sending IP addresses in packet payload may fail • Example: ftp, SIP • Increase in packet size due to new headers • Legacy applications cannot leverage all overlay features • Example: multicast

  22. Conclusion • Overlays are a means to overcome the “Internet Impasse”. • OCALA enables legacy applications to benefit from the new features offered by new network architectures. • OCALA enables interoperability between different network architectures. • Generic proxy implementation.

  23. Thank you More information and proxy download at http://i3.cs.berkeley.edu

  24. mytranscoder.i3 Transcoder OC-I i3 Sender Imposed Middleboxes • Sender wishes to communicate with foo.i3. • Sender wishes to force traffic to go through a transcoder not directly on the path. Sets up connection to foo.i3_mytranscoder.i3 Sets up connection to foo.i3 Host A foo.i3 Appl. Appl. OC-I OC-I i3 i3 i3

  25. Transparent use of Overlays • Make legacy apps oblivious to overlays  preserve standard IP interface • OC needs to decide which overlay to use • IP address and port number: • E.g., forward all packets to 64.236.24.8 port 80 over RON • Advantage: works with all applications • Disadvantage: hard to remember and configure • DNS name: • E.g., forward all packets sent to berkeley.ron over RON • Advantages: human readable, flexible • Disadvantage: some applications don’t use DNS names

  26. ????

  27. Goal 1: Achieving Transparency • Make legacy apps oblivious to overlays • Preserve standard IP interface • Deciding which overlay to use • IP address and port number : • E.g., forward all packets sent to 64.236.24.8 port 80 over RON • DNS name: • E.g., forward all packets sent to berkeley.ron over RON • Human readable • Easy to encode user preferences

  28. Goal 3: Customizing Overlay Functionality • Overlays have customizable parameters • Example: OverQoS – maximum acceptable latency, RON – which routing metric (loss, throughput) to use, i3 – enable shortcut • Encode preferences in DNS name • Example: berkeley.mindelay.ron • Example: berkeley.maxbwdth.ron • Max 255 characters • Long names are inconvenient • Use regular expressions in configuration files

  29. berkeley.maxbwdth.ron berkeley.mindelay.ron Customizing Overlay Functionality Host B ssh ftp Host A OC-I Firefox ftp ssh … RON OC-I … OC-D IP i3 RON RON i3 Internet

  30. Goal 4: Common functionality • Functionality required by multiple overlays implemented in the OC-I layer • Example: Security • Similar to SSL • Modifications for supporting middleboxes

  31. Legacy Applications (ssh, firefox, explorer, …) Transport Layer (TCP, UDP, …) OC Independent (OC-I) Sublayer Overlay Convergence (OC) Layer OC Dependent (OC-D) Sublayer Overlay (DOA, DTN, HIP, i3, RON, …) Overlay Convergence Architecture for Legacy Applications Interpose an Overlay Convergence Layer between transport layer and overlay networks.

  32. Overlay Dependent Layer • API exposed by OC-D to OC-I layer • Setup (tunnel_info) • Close (tunnel_d) • Send (tunnel_d, pkt) • Callbacks from OC-D to OC-I • SetupDone (tunnel_d) • Recv(pkt) • i3, RON modules implemented

  33. Client Middlebox M Hello.i3 Firefox BRO apache OC-I OC-I OC-I i3 i3 i3 i3 i3 Middlebox Demo

  34. Web Server R hello.i3 idhello idhello idhello idhello idhello data data data data data idhello idM,idR idM idR IPM IPR i3 Middlebox M BRO IDS Client Web Browser i3 Middlebox Demo

  35. idR idR data data idR IPR i3 Home NAT Box Client NAT Traversal Demo Receiver R

  36. Interfacing middleboxes Middleboxes cleanly fit into the OC architecture. Host A Host M (mbox.i3) Host C (foo.i3) Appl. Middlebox Appl. OC-I OC-I OC-I i3 i3 i3 i3

  37. Evaluation • Micro-benchmarks • ~20 μs overhead each for tun, OC-D and OC-I layers • DNS lookup latency • First time : 169 μs • From cache: 15 μs • LAN experiments • Throughput close to that of pure IP. • Latency less than double that of pure IP. • Wide Area experiments • Throughput close to that of pure IP. • No increase in latency.

  38. Example Configuration File All traffic going to URLs containing “berkeley” or ending with “.gov” should first go through a firewall over i3 and then to the destination over RON. <PathInfo > <Match urlPattern = "*berkeley*" /> <Match urlPattern = "*.gov" /> <Security protocol = "custom SSL" mode = "endhostonly" /> <Compression algo = "zlib" level = "5" /> <Hop overlayId = "PlanetLab.i3" HopEndPointName = “firewall1.berkeley.edu.i3" > <Property name = “shortcut” value = “enabled” /> </Hop> <Hop overlayId = "PlanetLab.i3" HopEndPointName = “RON_i3_Gateway.berkeley.edu.i3" /> <Hop overlayId = "ron.PlanetLab" /> </PathInfo>

  39. Micro-benchmarks Per-packet overhead while sending data Per-packet overhead while receiving data • DNS lookup overhead • First time = 169 microseconds • From cache = 15 microseconds

  40. LAN Experiments • 2 proxies on the same LAN Latency Throughput

  41. Wide Area Experiments • Proxies running at 3 different locations. • RON and i3-with-shortcut have latency close to pure IP.

  42. Wide Area Experiments (contd.) • RON and i3-with-shortcut throughput >= 75% of throughput of pure IP • Anomalous behavior of packets sent to A

More Related