1 / 26

OCALA: Architecture for Supporting Legacy Applications over Overlays

OCALA proposes an architecture to enable legacy applications to function over new network overlays, ensuring interoperability and common functionality while offering simultaneous access to different overlays. The design, applications, and implementation of OCALA are detailed in this paper.

sileas
Télécharger la présentation

OCALA: 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 Joseph1, Jayanth Kannan1, Ayumu Kubota2, Karthik Lakshminarayanan1, Ion Stoica1, Klaus Wehrle3 1UC Berkeley, 2KDDI Labs, 3RWTH Aachen University

  2. 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

  3. 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

  4. Simultaneous access to different overlays Host B (India) Host C (China) sshd Host A (San Jose) IRC Firefox IRC ssh RON i3 Internet www.cnn.com

  5. 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

  6. i3 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) Host B (India) Gateway (SFO) ssh sshd

  7. 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

  8. Contents • Introduction • Design • Applications • Implementation • Conclusion

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

  10. 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 Transport OC-I OC-D • Interpreted by OC-D • OC-D resolves this name • to an overlay specific • ID/Address • 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 Overlay

  11. Host A (IDA) Host B (ucb.i3, IDB) “ucb.i3”  pdAB pdAB↔ IPAB pdAB  tdAB Legacy App. Legacy App. Transport Layer Transport Layer DNSreq(ucb.i3) DNSresp(IPAB) OCI-Setup (pdAB) 1 7 8 pdAB↔ IPBA OC-I OC-I pdAB  tdBA tunnel_d = tdAB setup(ucb.i3) 2 6 resolve (ucb.i3) 3 i3 i3 … … RON i3 i3 RON RON IDB tdABIDB tdBAIDA 4 OC-D OC-D overlay specific setup protocol 5 Name Res. Service (local addrbook, DNS, OpenDHT…) Setting up a new connection 1.0.0.0/8 i3

  12. Host A (IDA) Host B (ucb.i3, IDB) pdAB IPAIPAB data IPBA IPB Legacy App. Legacy App. data Transport Layer Transport Layer IPAIPAB data OC-I OC-I tdAB, i3 i3 data pdAB IPAIPAB OC-D OC-D IDB pdAB IPAIPAB data Data Flow “ucb.i3”  pdAB pdAB↔ IPBA pdAB↔ IPAB pdAB  tdAB pdAB  tdBA tdABIDB tdBAIDA i3

  13. Simultaneous access to different overlays Host B (India) iitm.ac.in.ron Host C (China) chinairc.i3 ssh Host A (San Jose) IRC OC-I Firefox IRC ssh OC-I … RON … OC-I i3 … OC-D IP i3 RON RON i3 Internet www.cnn.com

  14. Stitching together different overlays • A sets up tunnel to sfgateway.i3 over i3. • B sets up tunnel to iitm.ac.in.ron over RON. Host B (India) iitm.ac.in.ron Host A (Berkeley) Gateway (SFO) sfgateway.i3 ssh sshd *.ron  sfgateway.i3 OC-I OC-I OC-I OC-D RON i3 i3 RON i3 RON

  15. Contents • Introduction • Design • Applications • Implementation • Conclusion

  16. Applications • New functionality enabled by the overlay • Example: i3 enables hosts to force all incoming traffic through off-path middleboxes

  17. Web Browser Remote Client Proxy R Bro Middlebox (In office) Webserver dilip-secure.pli3 Demo • Communication between non-overlay host and overlay host • Web server dilip-secure.pli3 imposes Bro IDS on its path using i3 GET dilip-secure.pli3.ocalaproxy.net i3 GET dilip-secure.pli3 GET dilip-secure.pli3 Internet (At home)

  18. Applications • Robust connections over RON • Access to machines behind NATs using i3 • OCALA Secure Connection • Unsecured wireless prone to eavesdropping

  19. 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

  20. Contents • Introduction • Design • Applications • Implementation • Conclusion

  21. 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

  22. 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

  23. 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 • …

  24. 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

  25. Thank you http://ocala.cs.berkeley.edu

More Related