Dropped image 170
0 likes373 views
The packet relay system encapsulates IP packets and performs network address translation (NAT) to hide IP address changes from the guest operating system and servers when VPN gateways fail over. It uses a simple IP-in-IP encapsulation and NAT to translate the source address of IP packets to allow connections to be maintained across gateway failures. The packet relay client runs as a module in the virtualization layer and the packet relay server runs as a user-level process on the server.
![multiple sessions may reduce the time required to fail over.
However, as shown in the experimental results in Section 5,
current VPN switching is fast enough to hide VPN failures
from OSs and maintain TCP connections.
4.2. Packet Relay System
Our packet relay system implementation performs two
operations: IP capsuling and NAT. IP capsuling is used
for identifying clients from servers and hiding IP address
changes from the guest OS. NAT is used for hiding IP ad-
dress changes from servers. Figure 6 shows these opera-
tions when an IP packet is sent from a client to a server.
The packet relay system uses a simple IP header like IP
over IP (IPIP) [5] to encapsule IP packets. When a packet
is sent from a client to a server, the capsuling IP header has
the relay client IP as the source and the relay server IP as the
destination (see Figure 6). The relay client IP is assigned by
VPN gateways and different from the IP address assigned to
the guest OS (guest IP). We currently assume that the guest
IP is unique in a cloud and can be used as a client ID. When
there are many clients, we can append a large (e.g., 128bits)
unique identifier, after the capsule IP header.
The relay server manages the relationship between the
guest and gateway IPs. In Figure 6, it records the rela-
tionship between “Guest IP” and “VPN GW IP”, allowing
the relay server to determine the appropriate gateway for a
client. The relay server updates the relationship manage-
ment table every time it receives an IP packet from clients.
The relay server also translates the source address of the
original IP header to its own IP address. This allows the
server to use the same IP address even when the relay client
IP address is changed. It also recalculates the check-sum of
IP packets. When the server sends back an IP packet to the
client, the packet follows a reverse flow path.
The packet relay client is implemented as a module run-
ning in BitVisor, and the packet relay server is implemented
as a user-level process running on the server.
5. Experiments
This section shows the experimental results of evaluating
our scheme. We first show the results of measuring failover
time. Then we show the results of measuring the perfor-
mance overhead of our virtualization layer.
5.1. Setup
We conducted the experiments in a wide-area distributed
Internet environment in Japan. We placed a client at
Tsukuba, and connected it to VPN gateways in data centers
in Tokyo, Yokohama, and Fukuoka. The straight-line dis-
tances from Tsukuba is approximately 56 km to Tokyo, 84
0
5
10
15
20
25
30
35
40
45
50
0 100 200 300 400 500 600 700 800 900
Yokohama
Fukuoka
Tokyo
1000
Latency[msec]
Elapsed time [sec]
Figure 7. Transition of Latency to Data Cen-
ters
0
2
4
6
8
10
0 5 10 15 20 25 30
VPNthroughput[Mbit/sec]
Elapsed time [sec]
Failure occurred point Failure recovered point
15.1 19.2
Figure 8. Throughput Transition over Failure
km to Yokohama, and 926 km to Fukuoka. These data cen-
ters are connected via leased lines with a maximum speed
of 100 Mbps. The leased lines are actually implemented
with yet another VPN provided by an ISP.
We used a PC equipped with Intel Core 2 Duo E8600
(3.33 GHz), PC2-6400 4 GB memory, and Intel X25-V
SSD 40 GB as the client machine at Tsukuba. The base
VMM is BitVisor 1.1, available from sourceforge site, and
the guest OS is Windows XP. Server machines are an HP
ProLiand BL280c blade server equipped with Xeon E5502
(1.86 GHz), 2 GB memory, and 120 GB 5400 rpm 2.5 inch
HDD. We used a Kernel-based Virtual Machine (KVM) and
CentOS 5.4 for both guest and host OSs. A cloud server and
the packet relay server each ran on a virtual machine.
5.2. Failover Time
The VPN failover time consists of the time to (1) detect a
VPN failure, (2) switch VPN gateways, and (3) restart TCP
transmission. According to our scheme, the time to detect a
VPN failure is expected to be (n+1)×RT O, where RT O is
calculated by Jacobson’s algorithm and n is the retry num-
ber. To verify estimated RT O, we first measured the tran-
sition of the network latency to each data center. Figure 7
shows the results. The latency to both Tokyo and Yokoyama
was around 15 msec and Fukuoka was 35 msec. In these la-
tencies, the estimated RT O for Tokyo was about 1 s.
We then measured the failover time. We intentionally
caused a VPN failure and measured the transition of TCP
6](https://image.slidesharecdn.com/droppedimage-170-140812000057-phpapp01/85/Dropped-image-170-1-320.jpg)
Dropped image 170
- 1. multiple sessions may reduce the time required to fail over. However, as shown in the experimental results in Section 5, current VPN switching is fast enough to hide VPN failures from OSs and maintain TCP connections. 4.2. Packet Relay System Our packet relay system implementation performs two operations: IP capsuling and NAT. IP capsuling is used for identifying clients from servers and hiding IP address changes from the guest OS. NAT is used for hiding IP ad- dress changes from servers. Figure 6 shows these opera- tions when an IP packet is sent from a client to a server. The packet relay system uses a simple IP header like IP over IP (IPIP) [5] to encapsule IP packets. When a packet is sent from a client to a server, the capsuling IP header has the relay client IP as the source and the relay server IP as the destination (see Figure 6). The relay client IP is assigned by VPN gateways and different from the IP address assigned to the guest OS (guest IP). We currently assume that the guest IP is unique in a cloud and can be used as a client ID. When there are many clients, we can append a large (e.g., 128bits) unique identifier, after the capsule IP header. The relay server manages the relationship between the guest and gateway IPs. In Figure 6, it records the rela- tionship between “Guest IP” and “VPN GW IP”, allowing the relay server to determine the appropriate gateway for a client. The relay server updates the relationship manage- ment table every time it receives an IP packet from clients. The relay server also translates the source address of the original IP header to its own IP address. This allows the server to use the same IP address even when the relay client IP address is changed. It also recalculates the check-sum of IP packets. When the server sends back an IP packet to the client, the packet follows a reverse flow path. The packet relay client is implemented as a module run- ning in BitVisor, and the packet relay server is implemented as a user-level process running on the server. 5. Experiments This section shows the experimental results of evaluating our scheme. We first show the results of measuring failover time. Then we show the results of measuring the perfor- mance overhead of our virtualization layer. 5.1. Setup We conducted the experiments in a wide-area distributed Internet environment in Japan. We placed a client at Tsukuba, and connected it to VPN gateways in data centers in Tokyo, Yokohama, and Fukuoka. The straight-line dis- tances from Tsukuba is approximately 56 km to Tokyo, 84 0 5 10 15 20 25 30 35 40 45 50 0 100 200 300 400 500 600 700 800 900 Yokohama Fukuoka Tokyo 1000 Latency[msec] Elapsed time [sec] Figure 7. Transition of Latency to Data Cen- ters 0 2 4 6 8 10 0 5 10 15 20 25 30 VPNthroughput[Mbit/sec] Elapsed time [sec] Failure occurred point Failure recovered point 15.1 19.2 Figure 8. Throughput Transition over Failure km to Yokohama, and 926 km to Fukuoka. These data cen- ters are connected via leased lines with a maximum speed of 100 Mbps. The leased lines are actually implemented with yet another VPN provided by an ISP. We used a PC equipped with Intel Core 2 Duo E8600 (3.33 GHz), PC2-6400 4 GB memory, and Intel X25-V SSD 40 GB as the client machine at Tsukuba. The base VMM is BitVisor 1.1, available from sourceforge site, and the guest OS is Windows XP. Server machines are an HP ProLiand BL280c blade server equipped with Xeon E5502 (1.86 GHz), 2 GB memory, and 120 GB 5400 rpm 2.5 inch HDD. We used a Kernel-based Virtual Machine (KVM) and CentOS 5.4 for both guest and host OSs. A cloud server and the packet relay server each ran on a virtual machine. 5.2. Failover Time The VPN failover time consists of the time to (1) detect a VPN failure, (2) switch VPN gateways, and (3) restart TCP transmission. According to our scheme, the time to detect a VPN failure is expected to be (n+1)×RT O, where RT O is calculated by Jacobson’s algorithm and n is the retry num- ber. To verify estimated RT O, we first measured the tran- sition of the network latency to each data center. Figure 7 shows the results. The latency to both Tokyo and Yokoyama was around 15 msec and Fukuoka was 35 msec. In these la- tencies, the estimated RT O for Tokyo was about 1 s. We then measured the failover time. We intentionally caused a VPN failure and measured the transition of TCP 6