Transcript OCALA: An Architecture for Supporting Legacy Applications

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)
Transport Layer とオーバレイの間に Overlay Convergence
Layer が割り込む.
Legacy Applications
(ssh, firefox, explorer, …)
Transport Layer
(TCP, UDP, …)
Overlay Convergence (OC) Layer
Overlay
(DOA, DTN, HIP, i3, RON, …)
OC Independent
(OC-I) Sublayer
OC Dependent
(OC-D) Sublayer
複数のオーバレイネットワークへの
同時アクセス
Host B
Host C
ssh
Host A
IRC
OC-I
Firefox
IRC
ssh
RON
i3
OC-D
OC-I
IP
i3
…
…
OC-I
RON
RON
i3
Internet
…
www.cnn.com
Naming
• DNSのような名前の割り当て
berkeley
berkeley.pl.i3
.pl.i3
Transport
Overlay
type
Overlay specific
name
Overlay
instance
OC-I
Interpreted by OC-I
• OC-I uses suffix to
invoke corresponding
OC-D instance
OC-D
Overlay
by OC-D
• Interpreted
OC-D 解決アルゴリズム
• OC-D
resolves this name hashing names to IDs in i3)
– オーバレイ特有(e.g.,
to
overlay specific
– an
一般的な手法
(e.g., OpenDHT, DNS, address book)
ID/Addr
(e..g, i3 ID,
HIT, で利用されているフラットなIDを用いる
– IDマッピング:
OC-D
EID, IP addr)
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.
OC-I
OC-I
OC-D
Appl.
Host B (bar.i3)
i3
i3
i3
RON
OC-I
RON
tunnel
tunnel
path
RON
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
Overlay (OV)
*.gov  OV
…
Configuration file
OV
LSIP
Internet
Legacy Client Gateways
• 同様にクライアントもOCALAをローカルで動かす必
要はない
• ゲートウェイに Legacy Client IP (LCIP) モジュール
Overlay server (foo.ov)
Legacy gateway
Appl.
OC-I
Legacy Client
OC-I
Internet
DNSreq(foo.ov.ocalaproxy.net)
LCIP
OV
OV
Overlay (OV)
Design
新規接続の確立
Host A
Legacy App.
1.x.x.x
Transport Layer
1 DNSreq(foo.ov)
8 DNSresp(oc_handle = IPAB)
OC-I Layer
2 setup(foo.ov)
3 resolve(foo.ov)
i3
4 IDB
Name Res. Service
(local addrbook,
DNS, OpenDHT…)
7 OCI-Setup (pdAB)
Host B (foo.ov, IDB)
6 tunnel_d = tdAB
RON
…
5 overlay specific
setup protocol
Overlay
(DTN, i3, RON)
OC Layer
データの流れ
Host A (IDA)
Host B (foo.ov, IDB)
Legacy App.
Legacy App.
Transport Layer
Transport Layer
IPAB
OC-I
“foo.ov”  pdAB
pdAB ↔ IPAB
pdAB  tdAB
tdAB, pdAB IPAB
OC-D
IPBA data
data
tdAB IDB
pdAB ↔ IPBA
OC-I
pdAB  tdBA
data
pdAB IPAB
Overlay
(DTN, i3, RON)
IDB pdAB IPAB
data
OC-D
data
tdBAIDA
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
• 受信者 (foo.i3) はすべてのトラフィックをオーバレイの機能を
用いてミドルボックスを経由して通信するようにする (e.g., i3)
Host A
Sets up
connection to
foo.i3
foo.i3
Appl.
Bro
Appl.
OC-I
OC-I
OC-I
i3
i3
i3
i3
NAT Traversal Application
• I3サーバを中継に利用する
• NAT下同士のノードの直接通信を実現
i3
NAT Box
実装
• プロキシとして実装
– 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
•• Sender
traffic to go
Sender wishes
wishes to
to force
communicate
withthrough
foo.i3. a
transcoder not directly on the path.
Sets up connection to
Sets up
foo.i3_mytranscoder.i3
connection to
foo.i3
Host A
mytranscoder.i3
foo.i3
Appl.
Transcoder
Appl.
OC-I
OC-I
OC-I
i3
i3
i3
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
Host B
ssh
ftp
Host A
OC-I
Firefox
ftp
ssh
RON
OC-D
OC-I
IP
i3
…
RON
RON
berkeley.maxbwdth.ron
berkeley.mindelay.ron
Internet
i3
…
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
Interpose an Overlay Convergence Layer between
transport layer and overlay networks.
Legacy Applications
(ssh, firefox, explorer, …)
Transport Layer
(TCP, UDP, …)
Overlay Convergence (OC) Layer
Overlay
(DOA, DTN, HIP, i3, RON, …)
OC Independent
(OC-I) Sublayer
OC Dependent
(OC-D) Sublayer
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
Client
Middlebox M
Hello.i3
Firefox
BRO
apache
OC-I
OC-I
OC-I
i3
i3
i3
i3
i3 Middlebox Demo
iddata
,idR
hello id
idMhello
i3
idMhello
iddata
M IP
idR IPR
data idhello
data idhello
Client
Web Browser
Middlebox M
idhello
data
BRO
IDS
Web Server R
hello.i3
NAT Traversal Demo
i3
idR IP
idRR
data
data idR
Home NAT Box
Client
Receiver R
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
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 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>
Micro-benchmarks
Per-packet overhead while sending data
μs
i3
RON
No 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
Latency
milliseconds
i3
i3-shortcut
RON
IP
No-Encryption
1.42
0.788
0.762
0.488
Encryption
1.74
1.13
1.06
NA
Throughput
kbps
i3
i3-shortcut
RON
IP
No-Encryption
9589
10504
10022
11749
Encryption
5415
5615
5445
NA
Wide Area Experiments
• Proxies running at 3 different locations.
• RON and i3-with-shortcut have latency close
to pure IP.
140
Latency (ms)
120
100
80
60
40
20
0
A --> B
B --> A
i3
A --> C
C --> A
i3-shortcut
RON
B --> C
IP
C --> B
Wide Area Experiments (contd.)
• RON and i3-with-shortcut throughput >= 75%
of throughput of pure IP
• Anomalous behavior of packets sent to A
i3
i3-shortcut
RON
IP
35000
Throughput (kbps)
30000
25000
20000
15000
10000
5000
0
A --> B
B --> A
A --> C
C --> A
B --> C
C --> B