Upload
bayard
View
54
Download
0
Embed Size (px)
DESCRIPTION
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. インターネットインフラストラクチャの改変は成功していない - PowerPoint PPT Presentation
Citation preview
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
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)
Legacy Applications on Overlays
• Approach 1 : アプリケーションの再実装– 時間がかかる、面倒である、クローズドソー
スだと不可能である
• Approach 2 : そのままアプリケーションが実行可能なオーバレイネットワークの作成
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
Overlay Convergence Architecture for Legacy Applications (OCALA)
Overlay Convergence (OC) Layer
Overlay(DOA, DTN, HIP, i3, RON, …)
Legacy Applications(ssh, firefox, explorer, …)
Transport Layer(TCP, UDP, …)
OC Independent (OC-I) SublayerOC Dependent (OC-D) Sublayer
Transport Layer とオーバレイの間に Overlay Convergence Layer が割り込む .
複数のオーバレイネットワークへの
同時アクセス
OC-I
i3
FirefoxOC-I
RON
ssh
www.cnn.comRON
IRC ssh
…
OC
-D
i3RON
Internet
…OC-I
i3
IRC
…
Host A
Host B
Host C
IP
Naming• DNS のような名前の割り当て
berkeley.pl.i3 berkeley
Interpreted by OC-I• OC-I uses suffix to invoke corresponding OC-D instance
Overlay type
Overlay instance
.pl.i3
Overlay specific name
OC-I
OC-D
Transport
Overlay
• OC-D 解決アルゴリズム– オーバレイ特有 (e.g., hashing names to IDs in i3)– 一般的な手法 (e.g., OpenDHT, DNS, address book)– ID マッピング : OC-D で利用されているフラットな ID を用いる
Interpreted by OC-D• OC-D resolves this name to an overlay specific ID/Addr (e..g, i3 ID, HIT, EID, IP addr)
Bridging Overlays• ホスト A のアプリケーションが foo.ron_bar.i3 への DNS リクエストを
だす• A は bar.i3 (B) over i3 へのトンネル作成• B は RON を解した foo.ron (C) へのトンネルを作成 • パスの構築完了
OC-I
Host A
Appl.
OC-I
Host C (foo.ron)
Appl.
OC-I
Host B (bar.i3)
i3
OC
-D
i3 RONi3 RON
RON
tunnel tunnel
path
Legacy Server Gateways• サーバーは OCALA をローカルで動作させる必要はない• Legacy Server IP (LSIP) と呼ばれる Special OC-D モジュールを用い
る• LSIP は NAT のような働きをする
OC-I
Appl.
OC-I
OV LSIP
Legacy gateway
Overlay (OV) Internet
Overlay client
OV
Legacy server(www.nasa.gov)
*.gov OV…
Configuration file
Legacy Client Gateways
• 同様にクライアントも OCALA をローカルで動かす必要はない
• ゲートウェイに Legacy Client IP (LCIP) モジュール
OC-I
Appl.
OC-I
LCIP OV
Legacy gateway
Overlay (OV)Internet
Legacy Client
OV
Overlay server (foo.ov)
DNSreq(foo.ov.ocalaproxy.net)
Design
新規接続の確立
Legacy App.
Transport Layer
OC-I Layer
OC Layer
1 DNSreq(foo.ov)
Name Res. Service (local addrbook,
DNS, OpenDHT…)
Host A
Host B (foo.ov, IDB)
Overlay(DTN, i3, RON)
i3 RON …
2 setup(foo.ov)
3 resolve(foo.ov)
4 IDB5 overlay specific
setup protocol
DNSresp(oc_handle = IPAB)8
tunnel_d = tdAB6
1.x.x.x
OCI-Setup (pdAB)7
データの流れ
Overlay(DTN, i3, RON)
pdAB ↔ IPAB
pdAB tdAB
tdAB IDB
Legacy App.
Transport Layer
IPAB data
pdAB dataIPABtdAB,
pdAB dataIPABIDB
pdAB ↔ IPBA
tdBAIDA
Legacy App.
Transport Layer
IPBA data
pdAB dataIPAB
Host A (IDA) Host B (foo.ov, IDB)
OC-I
OC-D OC-D
OC-I“foo.ov” pdAB
pdAB tdBA
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 モジュールを実装
Applications
Applications• 複数のオーバレイネットワークへの同時アクセス
• オーバレイの構成– 複数のオーバレイをユーザは選択して利用できる– Eg: ワイヤレス通信は i3 経由で、ワイドエリア通信は
RON 経由で
• Applications enabled by new overlays– Receiver imposed middleboxes– NAT traversal
Receiver Imposed Middleboxes
OC-I
i3
Appl.
OC-I
i3
Appl.
OC-I
i3
foo.i3
i3
Host A
Bro
• 受信者 (foo.i3) はすべてのトラフィックをオーバレイの機能を用いてミドルボックスを経由して通信するようにする (e.g., i3)
Sets up connection to
foo.i3
NAT Traversal Application• I3 サーバを中継に利用する• NAT 下同士のノードの直接通信を実現
NAT Box
i3
実装
• プロキシとして実装– tun device used to capture packets
• Linux and Windows XP/2000 (using cygwin)上で実装
• RON and i3 OC-D モジュールを実装• セキュリティ
– SSL のような認証および暗号化
制限
• パケットの中に IP アドレスを含むものは失敗する– Example: ftp, SIP
• OCALA 専用ヘッダによってオーバヘッドが発生する
• 従来のアプリケーションは、オーバレイの新しい機能を利用できない– Example: multicast
まとめ
• オーバレイは“ Internet の行き詰まり”を打破する
• OCALA は従来のアプリケーションを、新しいオーバレイネットワーク上で、新しい機能を用いて動作可能にする
• OCALA は異なるオーバレイネットワークの相互運用を可能にする .
• 一般的なプロキシとして実装
Thank you
More information and proxy download at http://i3.cs.berkeley.edu
Sender Imposed Middleboxes
OC-I
i3
Appl.
OC-I
i3
Appl.
foo.i3
i3
Host A
• Sender wishes to force traffic to go through a transcoder not directly on the path.
OC-I
i3
mytranscoder.i3
Transcoder
• Sender wishes to communicate with foo.i3.
Sets up connection to
foo.i3
Sets up connection to foo.i3_mytranscoder.i3
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
????
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
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
Customizing Overlay Functionality
OC-I
i3
FirefoxOC-I
RON
ssh
RON
ftp ssh
…
OC
-D
i3RON
Internet
…
Host A
Host B
IP
berkeley.mindelay.ron
ftp
berkeley.maxbwdth.ron
Goal 4: Common functionality
• Functionality required by multiple overlays implemented in the OC-I layer
• Example: Security– Similar to SSL– Modifications for supporting middleboxes
Overlay Convergence Architecture for Legacy Applications
Overlay Convergence (OC) Layer
Overlay(DOA, DTN, HIP, i3, RON, …)
Legacy Applications(ssh, firefox, explorer, …)
Transport Layer(TCP, UDP, …)
OC Independent (OC-I) SublayerOC Dependent (OC-D) Sublayer
Interpose an Overlay Convergence Layer between transport layer and overlay networks.
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
i3 Middlebox Demo
OC-I
i3
Firefox
OC-I
i3
apache
OC-I
i3
Middlebox M Hello.i3
i3
Client
BRO
i3
Web Server Rhello.i3
idM,idR
idhello
Middlebox MBRO IDS
IPMidM
IPRidR
ClientWeb Browser
idhellodata
idhellodata
idhellodata
idhellodata
idhellodata
i3 Middlebox Demo
Home NAT Box
NAT Traversal Demo
i3
Client
IPRidR
idRdata
idRdata
Receiver R
Interfacing middleboxes
OC-I
i3
Appl.
OC-I
i3
Appl.
OC-I
i3
Host M (mbox.i3) Host C (foo.i3)
i3
Host A
Middlebox
Middleboxes cleanly fit into the OC architecture.
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.
Example Configuration FileAll 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>
Micro-benchmarksPer-packet overhead while sending data
μs i3 RONNo Encryption Encryption No Encryption Encryption
OC-I 19 93 18 91
OC-D 20 20 28 28
tun 24 25 24 24
Per-packet overhead while receiving dataμs i3 RON
No Encryption Encryption No Encryption Encryption
OC-I 8 84 6 82
OC-D 44 43 36 35
Tun 16 20 15 16
• DNS lookup overhead– First time = 169 microseconds– From cache = 15 microseconds
LAN Experiments• 2 proxies on the same LAN
milliseconds i3 i3-shortcut RON IP
No-Encryption 1.42 0.788 0.762 0.488
Encryption 1.74 1.13 1.06 NA
kbps i3 i3-shortcut RON IP
No-Encryption 9589 10504 10022 11749
Encryption 5415 5615 5445 NA
Latency
Throughput
Wide Area Experiments
0
20
40
60
80
100
120
140
A --> B B --> A A --> C C --> A B --> C C --> B
Late
ncy
(ms)
i3 i3-shortcut RON IP
• Proxies running at 3 different locations.• RON and i3-with-shortcut have latency close to
pure IP.
Wide Area Experiments (contd.)
0
5000
10000
15000
20000
25000
30000
35000
A --> B B --> A A --> C C --> A B --> C C --> B
Thro
ughp
ut (k
bps)
i3 i3-shortcut RON IP
• RON and i3-with-shortcut throughput >= 75% of throughput of pure IP
• Anomalous behavior of packets sent to A