1 / 41

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. インターネットインフラストラクチャの改変は成功していない

bayard
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 • インターネットインフラストラクチャの改変は成功していない • Mobile IP, IP multicast, Intserv • オーバレイネットワークはインターネットを改変せずに新しい機能を提供できる • RON : resilience to path failures • i3 : mobility, NAT traversal, anycast, multicast • OverQOS : quality of service • しかし普及している実装はない • 少しずつ普及させたい • そのために、一般的なアプリケーションをオーバレイネットワークで利用できればよい (Firefox, IE, samba, ssh)

  3. Legacy Applications on Overlays • Approach 1 : アプリケーションの再実装 • 時間がかかる、面倒である、クローズドソースだと不可能である • Approach 2 :そのままアプリケーションが実行可能なオーバレイネットワークの作成

  4. Goals • 透過性 • Legacy apps unaware of overlay • 相互運用性 • Hosts in different overlays should be able to talk to each other • 個々のオーバレイの機能を利用可能 • User control over which overlay to use, what overlay specific properties to use • 一般的な要求事項の抽出 • 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) Transport Layer とオーバレイの間に Overlay Convergence Layer が割り込む.

  6. 複数のオーバレイネットワークへの同時アクセス複数のオーバレイネットワークへの同時アクセス 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のような名前の割り当て 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 解決アルゴリズム • オーバレイ特有(e.g., hashing names to IDs in i3) • 一般的な手法 (e.g., OpenDHT, DNS, address book) • IDマッピング: OC-D で利用されているフラットなIDを用いる

  8. Bridging Overlays • ホストAのアプリケーションがfoo.ron_bar.i3 へのDNSリクエストをだす • A は bar.i3 (B) over i3 へのトンネル作成 • B はRONを解した foo.ron (C) へのトンネルを作成 • パスの構築完了 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 • サーバーはOCALAをローカルで動作させる必要はない • Legacy Server IP (LSIP) と呼ばれるSpecial OC-D モジュールを用いる • LSIP は NAT のような働きをする 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 • 同様にクライアントもOCALAをローカルで動かす必要はない • ゲートウェイに Legacy Client IP (LCIP) モジュール 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. Design

  12. 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 新規接続の確立 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

  13. data IPAB data IPBA tdAB, data data pdAB IPAB pdAB IPAB IDB pdAB IPAB data データの流れ 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

  14. Overlay Dependent Layer • OC-DがOC-Iに提供するAPI • Setup (tunnel_info) • Close (tunnel_d) • Send (tunnel_d, pkt) • OC-Dによって呼ばれるOC-Iのコールバック関数 • SetupDone (tunnel_d) • Recv(pkt) • i3, RON モジュールを実装

  15. Applications

  16. Applications • 複数のオーバレイネットワークへの同時アクセス • オーバレイの構成 • 複数のオーバレイをユーザは選択して利用できる • Eg: ワイヤレス通信はi3経由で、ワイドエリア通信はRON経由で • Applications enabled by new overlays • Receiver imposed middleboxes • NAT traversal

  17. Receiver Imposed Middleboxes • 受信者 (foo.i3) はすべてのトラフィックをオーバレイの機能を用いてミドルボックスを経由して通信するようにする (e.g., i3) Sets up connection to foo.i3 Host A foo.i3 Appl. Bro Appl. OC-I OC-I OC-I i3 i3 i3 i3

  18. i3 NAT Box NAT Traversal Application • I3サーバを中継に利用する • NAT下同士のノードの直接通信を実現

  19. 実装 • プロキシとして実装 • tun device used to capture packets • Linux and Windows XP/2000 (using cygwin)上で実装 • RON and i3 OC-Dモジュールを実装 • セキュリティ • SSLのような認証および暗号化

  20. 制限 • パケットの中にIPアドレスを含むものは失敗する • Example: ftp, SIP • OCALA専用ヘッダによってオーバヘッドが発生する • 従来のアプリケーションは、オーバレイの新しい機能を利用できない • Example: multicast

  21. まとめ • オーバレイは“Internet の行き詰まり”を打破する • OCALA は従来のアプリケーションを、新しいオーバレイネットワーク上で、新しい機能を用いて動作可能にする • OCALA は異なるオーバレイネットワークの相互運用を可能にする. • 一般的なプロキシとして実装

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

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

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

  25. ????

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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