Violin Virtual internetworking on overlay infrastructure

VIOLIN:Virtual Internetworking on Overlay

Infrastructure

Xuxian Jiang and Dongyan Xu

Purdue University,West Lafayette,IN47907,USA

{jiangx,dxu}@05c5e5c458f5f61fb7366637

Abstract.We propose a novel application-level virtual network archi-

tecture called VIOLIN(Virtual Internetworking on OverLay INfrastruc-

ture).VIOLINs are isolated virtual networks created on top of an over-

lay infrastructure(e.g.,PlanetLab).Entities in a VIOLIN include virtual

end-hosts,routers,and switches implemented by software and hosted by

physical overlay hosts.Novel features of VIOLIN include:(1)a VIOLIN

is a“virtual world”with its own IP address space.All its computa-

tion and communications are strictly con?ned within the VIOLIN.(2)

VIOLIN entities can be created,deleted,or migrated on-demand.(3)

Value-added network services not widely deployed in the real Internet

can be provided in a VIOLIN.We have designed and implemented a

prototype of VIOLIN in PlanetLab.

1Introduction

Current Internet only provides basic network services such as IP unicast.In recent years,overlay networks have emerged as application-level realization of value-added network services,such as anycast,multicast,reliable multicast,and active networking.While highly practical and e?ective,overlays have the follow-ing problems:(1)Application functions and network services are often closely coupled in an overlay,making the development and management of overlays com-plicated.(2)The development of overlay network services is mainly individual e?orts,leading to few standards and reusable protocols.Meanwhile,advanced network services[1][2][3][4][5]have been developed but not widely deployed.(3) It is hard to isolate an overlay from the rest of the Internet,making it easy for a compromised overlay node to attack other Internet hosts.

In this paper,we propose a novel virtual network architecture called VIOLIN (Virtual Internetworking on OverLay INfrastructure),motivated by recent ad-vances in virtual machine technologies[6][7].The idea is to create virtual isolated network environments on top of an overlay infrastructure.A VIOLIN1consists of virtual routers,LANs,and end-hosts,all being software entities hosted by over-lay hosts.The key di?erence between VIOLIN and application-level overlay is that VIOLIN re-introduces system(OS)-enforced boundary between applications

and network services.As a result,a VIOLIN becomes an“advanced Internet”running value-added network-level protocols for routing,transport,and manage-ment.

The novel features of VIOLIN include:(1)Each VIOLIN is a“virtual world”with its own IP address space.All its computation and communications are strictly con?ned within the VIOLIN.(2)All VIOLIN entities are software-based, leading to high?exibility by allowing on-demand addition/deletion/migration/ con?guration.(3)Value-added network services not widely deployed in the real Internet can be provided in a VIOLIN.(4)Legacy applications can run in a VIOLIN without modi?cation,while new applications can leverage the advanced network services provided in VIOLIN.

We expect VIOLIN to be a useful complement to application-level overlays. First,VIOLIN can be used to create testbeds for network-level experiments. Such a testbed contains more realistic network entities and topology,and pro-vides researchers with more convenience in experiment setup and con?guration. Second,VIOLIN can be used to create a service-oriented(virtual)IP network with advanced network services such as IP multicast and anycast,which will bene?t distributed applications such as video conferencing,on-line community, and peer selection.

We have designed and implemented a prototype of VIOLIN in PlanetLab.

A number of distributed applications have also been deployed in VIOLIN.The rest of the paper is organized as follows.Section2provides an overview of VI-OLIN.Section3justi?es the design of VIOLIN and its bene?t to distributed applications.Section4describes the implementation and ongoing research prob-lems of VIOLIN.Section5presents preliminary performance measurements in PlanetLab.Section6compares VIOLIN with related works.Finally,section7 concludes this paper and outlines our ongoing work.

2VIOLIN Overview

The concept of VIOLIN is illustrated in Figure1.The low-level plane is the real IP network;the mid-level plane is an overlay infrastructure such as PlanetLab; and the top-level plane shows one VIOLIN created on the overlay infrastructure. All entities in the VIOLIN are hosted by overlay hosts;and there are three types of entities like in the real network:end-host,LAN,and router.

–A virtual end-host(vHost)is a virtual machine running in a physical over-lay host.Meanwhile,it is possible that one physical overlay host supports multiple vHosts belonging to di?erent VIOLINs.

–A virtual LAN(vLAN)is constructed by creating one virtual switch(vSwitch, not shown in Figure1)that connects multiple vHosts.

–A virtual router(vRouter)is also a virtual machine with multiple virtual NICs(vNICs).A vRouter interconnects two or more vLANs.

Figure2shows a simple VIOLIN we create in PlanetLab.Two vLANs are interconnected by one vRouter(vRouter1hosted by 05c5e5c458f5f61fb7366637):

v

v

v

v

v

v

Overlay infrastructure

Internet

One VIOLIN

Virtual end?host Virtual router

Overlay host

v

Internet router

v

Fig.1.VIOLIN,overlay infrastructure,and underlying IP network

One vLAN comprises vHost1,vHost2,and vSwitch1;while the other one com-prises vHost3,vHost4,and vSwitch2.The links between these entities emulate cables in the real world.The IP address space of the VIOLIN is completely inde-pendent.Therefore,it can safely overlap the address space of another VIOLIN or the real Internet.

3VIOLIN Design Justi?cation

In this section,we make the case for VIOLIN and describe how applications (including network experiments)can bene?t from VIOLIN.

3.1Virtualization and Isolation

Analogous with the relation between virtual machine and its host machine,VI-OLIN involves network virtualization and leads to isolation between a VIO-LIN and the underlying IP network.Virtualization makes it possible to run unmodi?ed Internet protocols in VIOLINs.Furthermore,entities in a VIOLIN are decoupled from the underlying Internet.For example,if we perform tracer-oute from vHost1(hosted by 05c5e5c458f5f61fb7366637)to vHost3(hosted by 05c5e5c458f5f61fb7366637)in Figure2,we will only see vRouter1as the intermediate router and the hop count is two,although the PlanetLab hosts at Princeton and at UW are many more hops apart in the actual Internet.More interestingly,it is potentially feasible to repeat such virtualization recursively: a level-n VIOLIN can be created on a level-(n?1)VIOLIN,with level-0being the real Internet.

One simple VIOLIN in PlanetLab

Fig.2.A VIOLIN in PlanetLab(with names of physical PlanetLab hosts and virtual IP addresses)

Network isolation is with respect to(1)administration:the owner of a VIO-LIN has full administrator privilege-but only within this VIOLIN;(2)address space and protocol:the IP address spaces of two VIOLINs can safely overlap and the versions and implementations of their network protocols can be di?er-ent-for example,one running IPv4while the other running IPv6;(3)attack and fault impact:any attack or fault in one VIOLIN will not a?ect the rest of the Internet;(4)resources:if the underlying overlay infrastructure provides QoS support[8][9],VIOLIN will be able to achieve resource isolation for local resources(such as CPU and memory[10])of VIOLIN entities and for network bandwidth between them.

Bene?t to applications System-level virtualization and isolation provide a con?ned and dedicated environment for untrusted distributed applications and risky network experiments.From another perspective,applications requir-ing strong con?dentiality can use VIOLIN to prevent both internal information leakage and external attacks.

3.2System-Enforced Layering

Contrary to application-level overlays,VIOLIN enforces strong layering in or-der to disentangle application functions and network services.In addition,OS-enforced layering provides better protections to network services after the appli-cation level software is compromised.We note that layering itself does not incur more performance overhead compared with application-level overlays.We also note that layering is between application and network functions,not between network protocols.In fact,VIOLIN can be used as a testbed for the protocol heap architecture[11].

Bene?t to applications Application developers will be able to focus on ap-plication functions rather than network services,leading to clean design and easy

implementation.In addition,legacy applications can run in a VIOLIN without modi?cation and re-compilation.

3.3Network Service Provisioning

VIOLIN provides a new opportunity to deploy and evaluate advanced network services.There exist a large number of well-designed network protocols that are not yet widely deployed.Examples include IP multicast,scalable reliable multi-cast[2][4],IP anycast[3],and active networking[1][5].There are also protocols that are still in the initial stage of incremental deployment(e.g.,IPv6).VIOLIN is a platform to make these protocols a(virtual)reality.

Bene?t to applications VIOLIN allows applications to take full advantage of value-added network services.For example,in a VIOLIN capable of IP mul-ticast,applications such as publish-subscribe,layered media broadcast can be more conveniently developed than in the real Internet.We further envision the emergence of service-oriented VIOLINs,each with high-performance vRouters and vSwitches deployed at strategic locations(for example,vRouters close to Internet routing centers,vSwitches close to domain gateways),so that clients can connect to the VIOLIN to access its advanced network services.

3.4Easy Recon?gurability

Based on all-software virtualization techniques,VIOLIN achieves easy recon?g-urability.Di?erent from a physical network,vRouters,vSwitches,and vHosts can be added,removed,or migrated dynamically.Also,vNICs can be dynam-ically added to or removed from vHosts or vRouters;and the number of ports supported by a vSwitch is no longer a hardware constraint.

Bene?t to applications The easy recon?gurability and hot vNIC plug-and-play capability of VIOLIN is especially useful to handle the dynamic load and/or membership of distributed applications.Not only can a VIOLIN be created/torn down on-demand for an application,its scale and topology can also be adjusted in a demand-driven fashion.For example,during a multicast session,a new vLAN can be dynamically grafted on a vRouter to accommodate more participants. 4VIOLIN Implementation

4.1Virtual Machine

All VIOLIN entities are implemented as virtual machines(VMs)in overlay hosts. We adopt User-Mode Linux(UML)[12]as the VM technology.UML allows most Linux-based applications to run on top of it without any modi?cation.Based on ptrace mechanism,UML-the guest OS for a virtual machine,performs system call redirection and signal handling to emulate a real OS.More speci?cally,the guest OS will be noti?ed when an application running in the virtual machine issues a system call,the guest OS will then redirect the system call into its own

implementation and nullify the original call.One important feature of UML is that it is completely implemented at user level without requiring host OS kernel modi?cations.

Unfortunately,the original UML has a serious limitation:both virtual NICs and virtual links of virtual machines are restricted within the same physical host. Inter-host virtual links,which are essential to VIOLIN,have not been reported in current VM projects[6][7][13].To break the physical host boundary,we have performed non-trivial extension to UML and introduced transport-based inter-host tunneling.

More speci?cally,we use UDP tunneling in the Internet domain to emulate the physical layer in the VIOLIN domain.For example,to emulate the physical link between a vHost and a vSwitch,the guest OS for the vHost opens a UDP transport connection for the vNIC and obtains a?le descriptor-both in the host OS domain.To receive data from the vSwitch,SIGIO signal will be generated by the host OS for the?le descriptor whenever data are available.The vSwitch maintains the IP address and UDP port number(in the Internet domain)for the vNIC of the vHost,so that the vSwitch can correctly emulate data link layer frame forwarding.Such virtualization is transparent to the network protocol stack in the guest OS.Finally,inter-host tunneling enables hot plug-and-play of vNICs(Section3.4);and it does not exhibit MTU e?ect as in the EtherIP[14] and IP-in-IP[15]approaches.

4.2Virtual Switch

A vSwitch is created for each vLAN and is responsible for packet forwarding at the(virtual)data link layer.Figure3shows a vSwitch which connects multiple vHosts.vSwitch is emulated by a UDP daemon in the host OS domain.The poll system call is used to poll the arrival of data and perform data queuing, forwarding,or dropping.More delicate link characteristics may also be imple-mented in the UDP daemon.The poll system call also noti?es the UDP daemon of the arrival of a connect request from a new vHost joining the vLAN,so that

a new port can be created for the vHost,as shown in Figure3.

4.3Virtual Router

Interestingly,there is no intrinsic di?erence in implementation between vHost and vRouter,except that the latter has additional packet forwarding capability and user level routines for the con?guration of packet processing policies.Linux source tree makes it possible to accommodate versatile and extensible packet processing capabilities.

When a UML is bootstrapped,a recognizable?le system will be located and mounted as root?le system.Based on UML,the vRouter requires kernel-level support for the capability of packet forwarding,as well as user-level routines, namely route,iproute2,ifcon?g for the con?guration of interface addresses and routing table entries.Beyond the packet forwarding capability,it is also easy to add?rewall,NAT,and other value-added services to the UML kernel.In the

Setp 1: Request from a new vHost

Setp 2: New port created for vHost

Step 3: Physical connection established

Fig.3.vSwitch and steps of port creation

VIOLIN implementation,we adopt the zebra[16]open-source routing package, which provides a comprehensive suite of routing protocol implementations.Re-cently,to enable active network services,we have also incorporated Click[17]as an optional package for vRouters.

5VIOLIN Performance

We have implemented a VIOLIN prototype and deployed it in PlanetLab.To evaluate the performance of VM communications in a VIOLIN,we have per-formed end-to-end throughput and latency measurement between VMs.Figures 4(a)and4(b)show a set of representative results.Two VMs are hosted by Plan-etLab nodes 05c5e5c458f5f61fb7366637 and 05c5e5c458f5f61fb7366637,respectively. We measure the TCP throughput and ICMP latency between the VMs,with and without the vSwitches performing UDP payload encryption.As a comparison, we also measured the TCP throughput and ICMP latency between the two Plan-etLab hosts.Our measurement results show that VIOLIN introduces an average of5%degradation in TCP throughput,compared with the TCP throughput be-tween the two underlying physical hosts.The addition degradation due to VM tra?c encryption is5%on the average.The degree of ICMP latency degradation (increase)is even less than that of TCP throughput.

To demonstrate VIOLIN’s support for advanced network services,we run WaveVideo,a legacy video streaming application,in VIOLIN.WaveVideo re-quires IP multicast and therefore is not runnable in PlanetLab.However,Wave-Video is able to execute in a VIOLIN with9VMs.The VM hosted by 05c5e5c458f5f61fb7366637 is the source of the video multicast session.It streams a short 300-frame video clip using(virtual)IP multicast address224.0.0.5.The other8 VMs are all receivers in three di?erent domains:Princeton,Purdue,and Duke. The average peak signal noise ratios(PSNR)of video frames observed by VMs in the three domains are shown in Figure5.

(a)TCP

throughput (b)ICMP latency

Fig.4.TCP throughput and ICMP latency between two VMs in VIOLIN 0 5

10

15

20

25

30

35

40

45

50

80 100 120 140 160 180

200 220 240 260 280

P S N R (d b )Frame number Purdue Princeton Duke Fig.5.Video streaming quality in an IP-multicast-enabled VIOLIN

6Related Work

VIOLIN is made possible by PlanetLab [18],which itself provides resource vir-tualization capability called 05c5e5c458f5f61fb7366637bed [19]is another wide-area testbed for network and distributed system experiments.Because of its high portability,VIOLIN can also be deployed in Netbed.

Application-level overlays have achieved signi?cant success in recent years.For example,RON [20]achieves robust routing and packet forwarding for appli-cation end-hosts;and the Narada protocol [21]brings high network e?ciency to end system multicast.VIOLIN is proposed as an alternative and complement to application-level overlays,especially for legacy applications or untrusted appli-cations that require strong network con?nement.

Machine virtualization has recently received tremendous attention.VMware

[13]fully virtualizes the PC hardware,while Denali [7]and Xen [6]take the paravirtualization approach by creating a virtual machine similar (instead of identical)to the physical machine.Inspired by machine virtualization,VIOLIN is our initial e?ort toward network virtualization.

The X-Bone[15]provides automated deployment and remote monitoring of overlays,and allows network entities(hosts,routers)to participate in multiple overlays simultaneously.By taking the two-layer“IP-in-IP”tunneling approach, X-Bone makes real Internet IPs visible to entities in the overlay domain,leading to a lower degree of isolation and con?nement than VIOLIN.

7Conclusion and Ongoing Work

We present VIOLIN as a novel alternative and useful complement to application-level overlays.Based on all-software virtualization techniques,VIOLIN creates a virtual internetworking environment for the deployment of advanced network services,with no modi?cations to the Internet infrastructure.The properties of isolation,enforced-layering,and easy recon?gurability make VIOLIN an excel-lent platform for the execution of high-risk network experiments,legacy appli-cations unaware of overlay APIs,as well as untrusted and potentially malicious applications.Our ongoing work includes:

–Performance evaluation and comparison VIOLIN involves virtualization tech-niques and is based on the overlay infrastructure.How to evaluate the per-formance,resilience,and adaptability of VIOLIN,compared with the real Internet and with application-level overlays?Especially,to match the perfor-mance of application-level overlays,how much additional computation and communication capacity need to be allocated?Our video multicast appli-cation in VIOLIN demonstrates performance comparable to its counterpart in an application-level overlay.However,more in-depth evaluation and mea-surement are needed before these questions can be answered.

–Re?nement of network virtualization technique Our inter-host tunneling im-plementation is initial and there is plenty of room for re?nement and im-provement.For example,how to improve the reliability of virtual links?

Should we adopt another transport protocol(such as TCP),or integrate error correction(such as FEC)into UDP,or simply let the transport pro-tocols in the VIOLIN domain to achieve reliability?To monitor the status of virtual links,is it possible to leverage the routing underlay[22]for better Internet friendliness?

–Topology planning and optimization Our implementation provides mecha-nisms for dynamic VIOLIN topology setup and adjustment.However,we have not studied the the problem of VIOLIN topology planning and opti-mization.More speci?cally,given the overlay infrastructure,where to place the vRouters and vSwitches,in order to achieve Internet bandwidth e?-ciency and satisfactory application performance?How should a VIOLIN re-act to the dynamics of Internet condition and application workload using its dynamic recon?gurability(Section3.4)?

Acknowledgments

We thank the anonymous reviewers for their reviews.This work is supported in part by the National Science Foundation(NSF)under the grant SCI-0438246. References

1.Calvert,K.,Bhattacharjee,S.,Zegura,E.,Sterbenz,J.:Directions in Active Net-

works.IEEE Communications Magazine(1998)

2.Kasera,S.,Hjalmtysson,G.,Towsley,D.,Kurose,J.:Scalable Reliable Multicast

Using Multiple Multicast Channels.IEEE/ACM Trans.on Networking(2000) 3.Katabi,D.,Wroclawski,J.:A Framework for Scalable Global IP-Anycast(GIA).

Proc.of ACM SIGCOMM2000(2000)

4.Liu,C.,Estrin,D.,Shenker,S.,Zhang,L.:Local Error Recovery in SRM:Com-

parison of Two Approaches.IEEE/ACM Trans.on Networking(1998)

5.Wetherall,D.,Guttag,J.,Tennenhouse,D.:ANTS:Network Services without the

Red Tape.IEEE Computer32(1999)

6.Dragovic,B.,Fraser,K.,Hand,S.,Harris,T.,Ho,A.,Pratt,I.,War?eld,A.,

Barham,P.,Neugebauer,R.:Xen and the Art of Virtualization.Proc.of ACM SOSP2003(2003)

7.Whitaker,A.,Shaw,M.,Gribble,S.D.:Scale and Performance in the Denali

Isolation Kernel.Proc.of USENIX OSDI2002(2002)

8.Stoica,I.,Shenker,S.,Zhang,H.:Core-Stateless Fair Queueing:a Scalable Ar-

chitecture to Approximate Fair Bandwidth Allocations in High-speed Networks.

IEEE/ACM Trans.on Networking11(2003)

9.Subramanian,L.,Stoica,I.,Balakrishnan,H.,Katz,R.:OverQoS:O?ering Internet

QoS Using Overlays.Proc.of ACM HotNets-I(2002)

10.Jiang,X.,Xu,D.:vBET:a VM-Based Emulation Testbed.Proc.of ACM SIG-

COMM2003Workshops(MoMeTools)(2003)

11.Braden,R.,Faber,T.,Handley,M.:From Protocol Stack to Protocol Heap Role-

Based Architecture.Proc.of ACM HotNets-I(2002)

12.Dike,J.:User Mode Linux.(05c5e5c458f5f61fb7366637)

13.:VMware.(05c5e5c458f5f61fb7366637)

14.Housley,R.,Hollenbeck,S.:EtherIP:Tunneling Ethernet Frames in IP Datagrams.

05c5e5c458f5f61fb7366637/rfcs/rfc3378(2002)

15.Touch,J.:Dynamic Internet Overlay Deployment and Management Using the

X-Bone.Proc.of IEEE ICNP2000(2000)

16.Ishiguro,K.:Zebra.(05c5e5c458f5f61fb7366637/)

17.Kohler,E.,Morris,R.,Chen,B.,Jannotti,J.,Kaashoek,M.F.:The Click Modular

Router.ACM Trans.on Computer Systems(2000)

18.Peterson,L.,Anderson,T.,Culler,D.,Roscoe,T.:A Blueprint for Introducing

Disruptive Technology into the Internet.Proc.of ACM HotNets-I(2002)

19.White,B.,Lepreau,J.,Stoller,L.,Ricci,R.,Guruprasad,S.,Newbold,M.,Hi-

bler,M.,Barb,C.,Joglekar,A.:An Integrated Experimental Environment for Distributed Systems and Networks.Proc.of USENIX OSDI2002(2002)

20.Andersen,D.G.,Balakrishnan,H.,Kaashoek,M.F.,Morris,R.:Resilient Overlay

Networks.Proc.of ACM SOSP2001(2001)

21.Chu,Y.H.,Rao,S.G.,Zhang,H.:A Case For End System Multicast.Proc.of

ACM SIGMETRICS2000(2000)

22.Nakao,A.,Peterson,L.,Bavier,A.:Routing Underlay for Overlay Networks.

Proc.of ACM SIGCOMM2003(2003)

本文来源：https://www.bwwdw.com/article/eegq.html