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
• 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
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
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
Overlay Convergence Architecture
for Legacy Applications (OCALA)
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
Simultaneous access to multiple
overlays
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-like names to identify machines (or services)
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
by OC-D mechanism
• Interpreted
OC-D resolution
• OC-D
resolves
this name
– Overlay
specific
(e.g., hashing names to IDs in i3)
to–anGeneral
overlay specific
(e.g., OpenDHT, DNS, address book)
ID/Addr (e..g, i3 ID, HIT,
– Identity mapping: OC-D names can be just flat IDs
EID, IP addr)
• Configuration file to store user preferences
OC-D
Overlay
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.
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
• 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
Overlay (OV)
*.gov  OV
…
Configuration file
OV
LSIP
Internet
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
Internet
DNSreq(foo.ov.ocalaproxy.net)
LCIP
OV
OV
Overlay (OV)
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.
Design
Setting up a new connection
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
Data Flow
Host A (IDA)
Host B (foo.ov, IDB)
Legacy App.
Legacy App.
Transport Layer
Transport Layer
IPAB
OC-I
“foo.ov”  pdAB
tdAB IDB
pdAB ↔ IPBA
OC-I
pdAB ↔ IPAB
pdAB  tdAB
tdAB, pdAB IPAB
OC-D
IPBA data
data
pdAB  tdBA
data
pdAB IPAB
Overlay
(DTN, i3, RON)
IDB pdAB IPAB
data
OC-D
data
tdBAIDA
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
Applications
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
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
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
• Using i3 servers as a relaying point
• Allows direct communication between NATed
hosts
• Demo during poster session
i3
NAT Box
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
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
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.
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