Download The Center for Autonomic Computing

Autonomic Virtual Networks and
Applications in Cloud and
Collaborative Computing
Environments
Renato Figueiredo
Associate Professor
Center for Autonomic Computing
ACIS Lab
University of Florida
Center for Autonomic Computing
Intel Portland, April 30, 2010
Outlook

Architecting autonomic virtual networks



Isolation, security, encapsulation, dynamic configuration,
migration
Self-configuration, self-healing, self-optimization
Applications in cloud and collaborative environments


Virtual Private Clusters
Social VPNs

Archer: a collaborative environment for computer
architecture simulation

Ongoing/future work
2
Background
Collaboration, entertainment:
streaming, data sharing, games
N Self-configuring
Public
Internet
A
End-to-end
T Virtual Private Network
Resource aggregation:
Cross-institution sharing,
opportunistic computing,
on-demand provisioning
N
A
T
3
Self-organizing virtual networks

Focus:


Why virtual?



Software overlays that provide virtual network
infrastructure over existing Internet infrastructure
Support unmodified TCP/IP applications and existing
Internet physical infrastructure
Hide heterogeneity of physical network (firewalls,
NATs), avoid IPv4 address space constraints
Why self-organizing?


Autonomous behavior: low management cost
compared to typical VPNs
Decentralized architecture for scalability and fault
tolerance
4
Virtual networking

Isolation: dealt with similarly to VMs

Multiple, isolated virtual networks time-share physical
network
Key technique: tunneling (VPNs)
 Related work


Grid computing





VNET (P. Dinda at Northwestern U.)
Violin (D. Xu at Purdue U.)
ViNe (J. Fortes at U. Florida)
PVC (F. Cappello at INRIA)
“P2P” VPNs

Hamachi, tinc, Gbridge
5
The IP-over-P2P (IPOP) Approach

Isolation


Virtual address space decoupled from Internet
address space
Self-managing

Self-organizing, self-healing topology

Decentralized – structured peer-to-peer (P2P)
 No global state, no central points of failure

Self-optimizing IP overlay routing


On-demand direct/relay connections
Self-configuring decentralized NAT traversal
6
Use case scenarios

Sharing resources/services in a virtual end host



VM provides isolation
Virtual appliances provide software encapsulation
Distributed virtual appliance clusters



Homogeneous software environment on top of
heterogeneous infrastructure
Homogeneous virtual network on top of wide-area,
NATed environments
Cross-institution collaboration; cloud-bursting
7
Example: virtual clusters
NOWs, COWs
“WOWs”
•Local-area
•Wide-area
•Physical machines
•Virtual machines (VMs)
•Self-organizing switching
•Self-organizing overlay
(e.g. Ethernet spanning tree)
IP tunnels, P2P routing
Installation
image
Switched
network
Physical machines
Virtual machines
VM image
8
Use case scenarios

There are various successful overlays enabling
peer-to-peer communication among users



VoIP sessions over skype
File transfers over bittorrent
iChat (video, chat, desktop sharing)
Application (and/or platform) specific
 Users: richer set of applications over a generic
IP network for communication and collaboration



But they don’t have public IPs, and don’t want to
directly connect to all users – hence NATs
And they don’t want to or know how to configure and
discover network services manually
9
Example: Social VPNs
carol.facebook.ipop
10.10.0.2
node0.alice.facebook.ipop
10.10.0.3
Overlay network
(IPOP)
Bob: browses Alice’s SMB share
Social
Network API
Alice’s services:
Samba share
RDP server
VoIP, Chat
Advertise to Bob, Carol
Alice’s public keys
Bob’s public keys
Carol’s public key
Social network Information system
Social network
(e.g. Facebook)
Alice
Social
Network
Web interface
Bob
Carol
10
IP-over-P2P Tunneling

As in many other VPNs, use virtual network
device to capture/inject IP (e.g. tap/tun)


Tunnel IP over UDP or TCP
Unlike traditional VPNs, tunnels are not
established by an administrator


Rather, IPOP implements self-organizing techniques
to discover, establish and maintain overlay links
Each IPOP peer is capable of picking packets,
injecting packets, and routing
11
Virtual network architecture
Unmodified applications
Connect(10.10.1.2,80)
Application
VNIC
Capture/tunnel, scalable,
resilient, self-configuring
routing and object store
Virtual
Router
Wide-area
Overlay network
10.10.1.1
Isolated,
private virtual
address space
Virtual
Router
Application
VNIC
10.10.1.2
12
Overlay architecture




Bi-directional structured overlay (Brunet library)
Constant number of edges (K) per node
O((1/k)log2(n)) overlay hops
Self-organizing topology
Ordered
ID space
Near
edge
Overlay
router
Shortcut
(far) edge
Overlay
router
13
Overlay Edges



Abstract bi-directional communication channels
Edges can use various transports:
 UDP; TCP; DTLS; Tunnel
UDP
TCP edge
UDP/DTLS:
edge
 NAT traversal
“Tunnel” edge
Overlay
router
Overlay
router
14
NAT traversal



Reflection: learn NAT-mapped endpoints
 From public overlay peers
Peers exchange “connect to me” through overlay
 Set up hole punching
Self-configuring
2. Exchange learned
Endpoint with peer
1. Reflection:
udp://IP:port
3. Simultaneous
open: NAT traversal
15
Self-healing structure



Greedy routing relies on consistent bi-directional
ring topology
Faults in structure due to routing outages,
symmetric NATs
Tunnel near edges Tunnel
edge
Unavailable
physical path
Peers exchange
neighbor set
16
Self-optimization

Create direct edges based on traffic inspection



O(log2(N)) -> O(1)
Direct connection when NAT traversal possible
Relay through a peer – “far” tunnel edge
2. Exchange learned
Endpoint with peer
1. Reflection:
udp://IP:port
3. Simultaneous
open: NAT traversal
17
Bootstrapping
Received by left and
right neighbors
Forwarder
CTM request
New P2P
node
Forms
a “leaf” connection with a well-known node
Selected at random from list of “bootstrap” nodes
Sends “Connect to me” CTM request addressed to itself
Received by nearest neighbors
18
Autonomous IP allocation

One P2P overlay supports multiple IPOP namespaces


IP routing within a namespace
Each IPOP namespace: a unique string

Distributed Hash Table (DHT) stores mapping



IPOP node configured with a namespace



Query namespace for DHCP configuration
Guess an IP address at random within range
Attempt to store in DHT



Key=namespace
Value=DHCP configuration (IP range, lease, ...)
Key=namespace+IP
Value=IPOPid (160-bit)
IP->P2P Address resolution:

Given namespace+IP, lookup IPOPid
19
Avoiding overlay overheads
LAN Router
Application
Virtual
Router
NIC
VNIC
Wide-area
Overlay network
Local
Interface
Application
NIC
Virtual
Router
Application
VNIC
20
VN Interfaces
●
●
Each machine has local
VN Interface
ARP, DHCP captured
locally
●
●
Router responds as
gateway
DHCP: DHT put/get
VPN
Overlay
NIC
NIC
VPN Client
Software
VPN Client
Software
Virtual Network
Device
APP
Virtual
LAN
Virtual Network
Device
APP
21
Supporting VN Routers
●
●
●
Single VN (Router) for
entire cluster
Avoid need for VN
software stack on end
host
Avoid VN overhead on
LAN communication
Virtual Router
TAP
Device
VPN
Software
NIC0
IP=10.1.1.2
Eth=A:B:C:D:E:0
NIC1
Internet
IP=10.1.1.4
IP=10.1.1.3
Eth=A:B:C:D:E:2 Eth=A:B:C:D:E:1
22
VN Hybrid
●
VN instance for each
member in a cluster
VPN
Software
TAP
Device
BRIDGE
128.227.56.40/24
VETH0_0
●
VN hosts in the same
LAN bypass VN
software stack
VETH0_1
10.250.1.25/16
IP0=128.227.56.41/24
IP1=10.250.5.5/16
ETH0
Internet
IP0=128.227.56.21/24 IP0=128.227.56.33/24
IP1=10.250.255.1/16
23
Autonomic features

Self-configuration [IPDPS’06, HPDC’06, PCgrid’07]



Self-optimization [HPDC’06]



Direct shortcut connections created/trimmed based upon IP
traffic inspection for fast end-to-end IP tunnels
Proximity neighbor selection based on network coordinate
estimates for improved structured routing
Self-healing [HPDC’08]


Routing tables using structured P2P links
NAT traversal, DHCP over DHT
“Tunnel” edges created to maintain overlay structure to deal
with routing outages and NATs/firewalls that are not traversable
VLAN routers, overlay bypass within VLAN [VTDC09,
SC09]
24
Overlay security architecture

Abstract senders encapsulate security logic


Supports both edge (point-to-point) and IPOP (endto-end) authentication and encryption
Public key infrastructure



DTLS (Datagram TLS) library or native IPOP stack


Keys/certificates
Symmetric key exchange
UDP-based; amenable to NAT traversal
IPsec tunneling also supported
25
Performance

IPOP implementation


C# user-level router
Tap virtual network device
Latency (ms) Bwidth (Mb/s) Mem (KB)
Host
0.27
941
n/a
C
0.34
738
9988
C#
0.37
716
21500
IPOP
0.52
284
38312
IPOP sec
0.75
55
50976
26
Security management

Overlay point-to-point and/or end-to-end
security need to be configured

PKI management can be complex and error-prone


Certificate signing/distribution, revocation
Approach: leverage Web 2.0, social networking
infrastructures for security management


SocialVPN: enable point-to-point VPN connectivity
among socially-networked peers
GroupVPN: enable sharing of resources with all-to-all
VPN connectivity within a group of users
27