Virtualized Network Infrastructure Supporting Co-existence of Parallel ...

2012 13th ACIS International Conference on Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing

Virtualized network infrastructure supporting co-existence of Parallel Internets Wojciech Burakowski, Halina Tarasiuk and Andrzej Beben Institute of Telecommunications Warsaw University of Technology Warsaw, Poland {wojtek; halina; abeben}@tele.pw.edu.pl

Grzegorz Danilewicz Poznan University of Technology Poznan, Poland [email protected]

Abstract— In this paper we describe the IIP System designed, implemented and currently tested in the frame of the Polish national project entitled “Future Internet Engineering” 1 (in Polish “Inynieria Internetu Przyszoci”- IIP). The IIP system uses virtualized network infrastructure that allows to set a number of, named, Parallel Internets essentially differing in solutions for the data and control planes. More precisely, we design three Parallel Internets: (1) IPv6 QoS that basically explores DiffServ and NGN architectures and uses TCP/IP, (2) Content Aware Network (CAN) specially designed for efficient content delivery, and (3) Data Streams Switching (DSS) for handling constant rate traffic with strong QoS requirements. For the IIP System we design a novel network infrastructure, which is based on the virtualization of the network elements (links and nodes). Such approach is on the line with the expectations of the network infrastructure for the Future Internet. In the paper we mainly focus on the system architecture, Parallel Internets and some aspects of network virtualization.

revolutionary approach, named clean slate, that tends to design a novel architecture but the network transformation process from TCP/IP to a new one should be done in an evolutionary way. In this paper we present a novel open architecture for the Future Internet, that maintains TCP/IP but also provides the opportunities to implement new post-IP network solutions. The system, which we design, prototype and test, we name as the IIP System (the acronym of Polish name of the project “Inynieria Internetu Przyszoci - IIP” – “Future Internet Engineering”) [13], [14]. In order to implement this system, we use a physical infrastructure consisting of connected devices enabling virtualization, that we use for creating the virtual nodes and the virtual links. These devices allow us to build a number of virtual nodes working in parallel, each of them possibly operating with different data and control planes. The examples of such devices are shortly described in [19] and they are the EZappliance, the NetFPGA card and the XEN. Furthermore, we create a number of parallel networks, named as Parallel Internets. Then, a Parallel Internet is visible as a separate network operating on its virtual nodes and links. More specifically, we consider three Parallel Internets: the IPv6 QoS and two proposals for post-IP networks, that are the Content Aware Network (CAN) and the Data Streams Switching (DSS). Each of the above networks is dedicated to handle traffic generated by the different applications requiring specific data transfer quality level. Especially, the CAN and the DSS are designed for supporting applications, which cannot be effectively handled due to limitations of the TCP/IP architecture. We believe that the proposed architecture is a “milestone forward” comparing to the TCP/IP mainly due to offering the capabilities for implementing new post-IP solutions while still maintaining operability with TCP/IP world. Currently, the research activities in defining Future Internet architectures are very intensive mainly in Europe, US and Asia-Pacific. These activities are well summarized e.g. in [2]. In the frame of FP7 European Research Program, this subject is extensively discussed covering also non-European activities as Internet 3.0 in US and Akari project in Japan. Studied issues correspond to application areas, business models, architectures, protocols and management. The presented architecture of the IIP System takes into account some lessons learnt from the following architectures:

Keywords- architecture; Future Internet; Parallel Internets; virtualization

I.

INTRODUCTION

The great success of the Internet over the world and its usefulness in many areas of human activities provoked new expectations about the Internet for the future. That is a reason why we need new generation of the Internet. The common understanding is that the progress of the Internet will have important (or even essential) impact on the civilization level. This is mainly due to a potentiality of extending Internet into new areas of applications corresponding to such activities as healthcare, business, home live, entertainment, administration, education etc. On the other hand, there is recognized that further development of the Internet needs a new network infrastructure, no longer based on TCP/IP protocol stack only. The main limitations of the current TCP/IP Internet are well summarized in [1]. Then, from the technical point of view, the main question is about new network architecture for the Future Internet. For now, research activities are polarized in two main directions: (1) the evolutionary approach that assumes some enhancements of the capabilities of current TCP/IP architecture by adding new functionalities e.g. for TCP, (2) the 1

This work is partially funded by the European Union, European Funds 20072013, under contract number POIG.01.01.02-00-045/09-00 “Future Internet Engineering”.

978-0-7695-4761-9/12 $26.00 © 2012 IEEE DOI 10.1109/SNPD.2012.67

679

(i) Internet 3.0 project, Generalized Networking Architecture (GINA) [3], (ii) Akari project, New Generation Networks (NWGN) [4], (iii) 4WARD FP7 project, Virtual Networks (VNet) [5], and (iv) Future Internet Assembly (FIA), Management and Service-Aware Networking Architectures for Future Internet (MANA) [6]. Notice, that the above mentioned architectures are also deeply analysing by the important Future Internet forums, e.g. FIA, ITU-T, ETSI and IETF. Based on our analysis of the above architectures we conclude that the VNet is an excellent example of prototyped and tested architecture. It is based on new business and management roles as well as provides new players: Physical Infrastructure Provider, Virtual Network Provider, Virtual Network Operator and Service Provider. However, based on our best knowledge this architecture has been tested only for IPv4 best effort network. On the other hand, the GINA and the NWGN architectures are currently under prototyping phase. The MANA group, which is initiative in scope of FP7 Program, has defined mainly a general framework of the architecture with pointing out on the research topics to be solved. Concluding, activities on defining architecture for the Future Internet are still in progress. We believe that the presented architecture of the IIP System will support these activities to design Future Internet. The paper is organized as follows. In section 2 we present the architecture of the IIP System and shortly describe designed Parallel Internets. The required functionalities for the devices enabling virtualization of network resources are discussed in section 3. Finally, the section 4 summarizes the paper.

II.

THE IIP SYSTEM

We design the IIP System to show that we can significantly extend the capabilities of network infrastructure in providing more effective data transfer comparing to this offered by current TCP/IP-based Internet. New capabilities in our system mainly correspond to possibilities of supporting: (i) a number of Parallel Internets that share common physical network infrastructure, (ii) specific data and control planes for each Parallel Internet, not limited to TCP/IP. In particular, each of Parallel Internets may serve traffic generated by a specific set of applications/services for which we can assure QoS guarantees for data transfer thanks to adequate data and control planes. Finally, we stress that virtualization is excellent way to implement Parallel Internets concept. Parallel Internets will operate on virtual nodes and links. For building them, we use devices enabling virtualization, as e.g. the mentioned above EZappliance, NetFPGA, XEN or others. Anyway, we expect that in the future we will have such products which will work more efficiently. A. Architecture Complete architecture of the IIP System consists of 6 levels, as depicted in Figure 1. The lower four levels, from 1 to 4, correspond to network infrastructure and cover areas from physical resources up to virtual networks created on the top of particular Parallel Internets. The upper levels correspond to applications/services (Level 5) and users (Level 6). Moreover, the management system is a part of the architecture. It is responsible for the management at each level as well as for inter-level communication.

Users Applications/Services Level 4 Virtual networks

VN2

VN1

VN2

VN1

VN1

IPv6 QoS Virtual nodes: IPv6 QoS, CAN, DSS

Level 2 Virtualization

DSS

CAN Virtual nodes: IPv6 QoS, CAN, DSS Virtual links: IPv6 QoS, CAN, DSS

Virtual nodes: IPv6 QoS, CAN, DSS Virtual links: IPv6 QoS, CAN, DSS

Creation of virtual nodes and links for IPv6 QoS, CAN and DSS Level 1 Physical infrastructure

Physical infrastructure enabling for creating virtual nodes, links (NetFPGA, XEN, EZAppliance)

Figure 1 Architecture of the IIP System.

680

Management

Level 3 Parallel Internets

VN2

Comparing to the current Internet, we introduce two new levels, Level 2 and 3 that are responsible for resource virtualization and enabling us to set Parallel Internets, respectively. Below, we shortly describe the functionalities of levels 1-4. Level 1. Physical Infrastructure: The physical infrastructure of the IIP System consists of the nodes enabling virtualization and the links connecting them. There is no limitations about topology of this network and it may consist of single or many domains. This network should have its own addressing scheme and management system. The network may contain wired and wireless parts as well as access and core networks. In the prototype version of the IIP System, we use Ethernet links to connect the devices enabling virtualization. Level 2. Virtualization: This level is responsible for creating and maintaining virtual nodes and links for particular Parallel Internets, in our case for the IPv6 QoS, the CAN and the DSS. Furthermore, at this level we need to provision each of Parallel Internets. The task of provisioning is to allocate physical resources for virtual links and nodes. While we can dimension the desired capacities of particular virtual links by applying appropriate schedulers, in the case of virtual nodes provisioning the problem becomes more complicated. In particular, we can provision CPU, memory and storage but these elements have no straightforward mapping on virtual nodes capacities, measured e.g. in number of data units handled in given time interval. A

Net A Sie Alink A Virtual

Net B Sie Blink B Virtual

A

A A B

B A A

A

B

Net A Sie A Virtual link A

B

Net B

B

Device enabling virtualization

Sie B Virtual link B Wze z moliwoci wirtualizacji

Figure 3 An exemplary network with two Parallel Internets (A and B).

isolation between them despite that they share the same physical resources. Comparing to the solution with one type of the Internet, now we have open network infrastructure to implement new post-IP solutions. On the other hand, maintaining one of the Parallel Internets using TCP/IP we have still connectivity with existing network. In the prototype, we implement three Parallel Internets that are: the IPv6 QoS, the CAN and the DSS. Among them, the CAN and the DSS are post-IP while the IPv6 QoS uses TCP/IP witch enhanced control plane. Figure 3 illustrates an exemplary network with two Parallel Internets, say A and B, each of possibly different topology. In our solution, the users and servers have opportunity to connect any of Parallel Internets, depending on their needs. We can expect a limited number of Parallel Internets working simultaneously on the same physical/virtual infrastructure. This is mainly due to some difficulties in defining too many Parallel Internets differing in protocol stacks and the needs. According to our best knowledge, we may expect (at least in the foreseeable future) between 3 and 5 final proposals in this area. On the other hand, we expect also some limitations of the capabilities of the devices enabling virtualization in supporting effective operation of too many virtual nodes working in parallel. At least for now, it is hard to assume that the number of virtual nodes will be count in dozens of hundreds. In the light of the above, the Parallel Internets allow us to aggregate traffic handled by the same protocol stack. This supports scalability of the proposed solution. When we distinguish between three Parallel Internets in the IIP System, we require maximum only three different virtual nodes running on the single physical node (the device enabling virtualization). Level 4. Virtual Networks: At this level we create virtual networks using resources of given Parallel Internet. These networks have its own addressing scheme and routing. Comparing with the current Internet, the virtual networks at Level 4 share the virtual resources (the virtual nodes and links) instead of the physical ones. So, in our architecture we have deep two-level virtualization. Anyway, it seems that to design a virtual network we may use similar methodology as in the current Internet. Finally, the virtual networks have the interface with the applications/services offered to the users.

B

Device enabling virtualization Wze z moliwoci wirtualizacji

Figure 2 Example with two virtual nodes and links set on a device enabling virtualization.

In Figure 2 we show an example with two different virtual nodes (say A and B) and links operating on a single node enabling virtualization. Each virtual node sends/receives its data units by dedicated virtual links sharing the same physical link. In order to assure isolation between the virtual nodes A and B as well as between the virtual links A and B, we need to apply adequate solutions. Level 3. Parallel Internets: This level is the “heart” of the proposed architecture. At this level, we establish different Internets that are working in parallel and using the same physical infrastructure, it means the devices enabling virtualization and the links. We name these Internets as Parallel Internets. The network resources for the Parallel Internets are the virtual nodes and virtual links “leased” from the Level 2 of the architecture. In general, each Parallel Internet may use different protocol stack, and, as a consequence, may have its own control and data planes. In order to control Parallel Internets, we have to assure full

681

B. Types of Parallel Internets In this section we describe the main characteristics of the Parallel Internets: the IPv6 QoS, the CAN and the DSS. IPv6 QoS: The IPv6 QoS is an enhanced TCP/IP network, which is aimed at offering the strict QoS guarantees for selected flows with respect to packet transfer that should meet a priori predefined maximum values of the following parameters: IPTD (Internet Packet Time Delay), IPDV (Internet Packet Delay Variation) and IPLR (Internet Packet Loss Ratio). For this purpose, in the network we set a number of, so called, Classes of Service (CoS) [7], [8], each of them dedicated for handling specific traffic profiles, as e.g. the Telephony CoS is for handling real time traffic emitted by VoIP applications. To meet the above QoS requirements we propose the following IPv6 QoS architectural model, see Figure 4. In this model we assume emerging of two architectures that are DiffServ [11] and NGN [12].

and it means that they should be able to send QoS request to the network by indicating the CoS for data transfer and the required throughput inside this class. We have selected the following groups of applications as the test applications of the IPv6 QoS Parallel Internet, which are e-health -SmartFit, eDiab [16] and eAsthma, public security - video surveillance, HomeNetEnergy [17] and e-learning [18]. For each of the mentioned groups we have developed a dedicated service control function at the service stratum of the architecture. Content Aware Network: The CAN network is designed to natively support access and delivery of multimedia content. The motivation for CAN comes from significant proliferation of multimedia content available in the current Internet and widely recognised limitations of TCP/IP architecture related to content dissemination [1], [9], [10]. Among them, the most crucial are: (i) segmentation of content coming from the lack of global naming scheme, (ii) inefficient content delivery due to network unawareness, and (iii) URL (Universal Resource Locator) broken-link problem due to location dependency of content identifiers. The designed CAN network is a post-IP content distribution system, whose primary objective is to deliver content in the most efficient way. The CAN system optimises content delivery thanks to information about the content transfer requirements, the location of consumers and available content replicas, traffic conditions in the network and content servers load. The CAN defines new architecture with associated protocols, mechanisms and algorithms strictly focused on content delivery. In this architecture, we distinguish three planes, which bring together operations performed in similar time scales. The Control Plane (CP) is mainly responsible for: (i) finding available replicas of content requested by the content consumer, (ii) selection the most appropriate content server and content delivery path going from the server to the consumer, and (iii) configuration of CAN nodes for content delivery. Note that the CP performs functions initiated by consumption requests. The Management Plane (MP) covers processes related to content management, content routing and path management, server and network awareness as well as CAN management. The primary objective of the content management process is (i) allocation of unique content identifiers, which enables consumers to access a content independently from content location and distribution mode, and (ii) distribution of content replicas on the surrogate content servers. The content routing and path management process is responsible for calculation and enforcing of content delivery paths used for content consumption. The server and network awareness process is responsible for gathering information about traffic carried in the CAN network and monitoring the load of content servers. This information allows CAN for selecting the best server and the best path used for content consumption. The last but not least is the CAN management process responsible for provisioning of CAN network, management of virtual resource leased from the IIP System,

Figure 4 The IPv6 QoS architectural model.

The model consists of two main stratums: service stratum, transport stratum, and applications as well as cross layer management. We have developed functionalities that support three main processes of the IPv6 QoS System, i.e. management, signalling, and data transfer. Among management processes the most important is the network provisioning process with routing settings and resource allocations. Moreover, the system manages the processes of virtual network establishing or removing. Virtual networks exploit the IPv6 in IPv6 tunnels in the network. The signalling processes correspond to call level and are responsible of call setup/release. The data transfer process is responsible for packet transport in the network. For guaranteeing QoS in the network, we have implemented functional elements of all levels and all processes of presented architectural model [15]. In particular, in order to deploy CoSs, we have implemented in the IPv6 QoS the virtual network nodes (as routers, access points) appropriate QoS mechanisms (as packet shapers, classifiers, policers, markers, droppers and schedulers) operating on the packet level (transport functions) as well as we use the admission control function (transport control functions) for controlling the volume of submitted traffic. The above mechanisms and algorithms should assure isolation between particular CoSs. In other words, traffic handled in one CoS should not disturb the assumed quality of traffic served by other CoSs. For using benefits from the QoS network, the applications should be of QoS-aware type

682

failure monitoring, etc. Note, that all management processes are performed in an off-line manner. The Forwarding Plane (FP) is responsible for delivering requested content from the content server to the consumer through content delivery path. The key elements of the FP are Content Aware Forwarding Entities (CAFE). They play the role of content routes responsible for transferring content packets, handling control and management messages as well as in network caching of popular content. The CAFEs take advantage of new content forwarding approach, which allows flexible selection of content delivery path for each content request. In this approach, the CAFEs maintain only the neighbourhood (local) information, i.e. how to forward content packet to the peering CAFE. The information about content delivery path is stored in the header of content packet. The CAFEs use this information to forward packets along the selected path. The content packet header is attached and removed by edge CAFEs located close to the content server and the consumer, respectively. Basically, our approach follows the source routing principle, which is limited to the interdomain level. The CAN network is designed to support innovative multimedia applications. We develop three exemplary applications that are: Distributed Virtual Museum (DVM), Private Family eHealth Network (PFEN) and HomeNetMedia (HNM). The DVM allows to retrieve and present 3D objects in interactive and progressive manner. The HNM enables unified, personalised and contextualised access to multimedia content provided from home and CAN networks. The PFEN creates personalised, patient digital library, which allows patients to control access and distribution of medical objects related to his/her health. Data Streams Switching: The DSS network is dedicated to handle traffic generated by the applications producing constant bit rate (rather of high bit rate as e.g. 3D video) and requiring real time transmission with strict QoS guarantees. The best solution for such network would be based on the traditional circuit switching. On the other hand, the circuit switching requires a synchronization in the network that is quite hard to achieve. In the DSS, we use a modification of Rate Envelope Multiplexing (REM) scheme that was originally defined for handling real time traffic in ATM networks and is also implemented in the IPv6 QoS. The modification, comparing to the traditional REM scheme, assumes that each connection running in the network has its own short buffer while in the REM the buffered is shared by more connections. Such approach allows us to control each connection in a separate way. The following parameters should be ensured by the DSS: bandwidth, overall delay and jitter. The network should provide such bandwidth, that the buffering of DSS packets will be very limited. In DSS we require the connection set-up phase before starting to send data (signalling system procedures). In the DSS we have edge and core nodes. The edge nodes connects the user terminals and handle user signalling. They also perform call admission control function based on the information

provided by the centralized Network Controller (NC). Control plane agents, named Switching Node Proxy (SNP) on edge and core nodes are responsible for sending signalling messages to the NC. The NC is responsible for provisioning DSS network by setting up data paths between each pair of edge nodes in the network. Possible reprovisioning of the network will deal with dimensioning of the paths and can be updated off-line. Applications are connected to the network by the adaptation modules. which adapt the messages transmitted by applications into frame format accepted by the DSS (specific DSS frame contains a DSS header with stream identifier value and payload) and vice versa. Moreover, the adaptation modules shape the data stream generated by applications to the form of the ON/OFF Constant Bit Rate data stream, as required by the DSS. The special DSS signalling system is used for setting up/release uni- or bidirectional connections and to register new user. Summarising, each of the Parallel Internets is dedicated to serve traffic emitted by a specific set of applications /services for which we require QoS guarantees for data transfer. The characteristics of handled traffic are different, so we need different solutions for data and control planes. III.

REQUIRED CAPABILITIES OF THE DEVICES ENABLING VIRTUALIZATION

The nodes of the IIP System are the devices enabling virtualization. In these devices we locate the virtual nodes and links belonging to the Parallel Internets. In this section we shortly describe how such device should operate. Figure 5 shows the format of received/sending data blocks from/to transmission system while Figure 6 depicts the scheme of the ideal device enabling virtualization in the case when three Parallel Internets (the IPv6 QoS, the CAN and the DSS) have been installed. The format of the transmitted/received data blocks contains the transmission system header (TS header), the header for distinguishing between the Parallel Internets (PI header) and Protocol Data Units specific for given Parallel Internet (PI PDU). The ideal device enabling virtualization consists of input ports, classifiers, virtual nodes, schedulers and management agent. Let us to look through a process of handling the incoming PI PDUs e.g. belonging to the CAN. This PI PDU may arrive to one of the input ports (say A or B) and, after processing by CAN virtual node, it should be submitted to one of the output ports (say C or D) depending on its next hop node. The ideal processing of this PI PDU should be as follows. First of all, the transmission system serves all Internets and, as a consequence, should be governed by special protocol, say e.g. Ethernet protocol. For this purpose we use TS header, marked in Figure 6 by white colour. Suppose that the discussed PI PDU arrives to the port A. TSH

payload PI header

payload

Transmission System Frame PI PDU

Figure 5 Format of received/sending data blocks.

683

A

A

C l a s i e f i e r

B

B A B

C l a s i e f i e r

Ethernet header PI header

A B A

PI PDU

B

IPv6 QoS Node

C D C

CAN Node

D C

DSS Node

D

MGT Agent

D

C

infrastructure consisting of connected devices enabling virtualization. These devices allow us to build the virtual nodes and the virtual links for Parallel Internets. Finally, we created three Parallel Internets i.e. the IPv6 QoS, the CAN and the DSS, which differ in the organization of data and control planes. The IIP System is currently under tests. The first results indicate, that it works according to the expectations. Finally, we argue that the virtualization is an excellent way to implement the Parallel Internets. Parallel Internets will operate on virtual nodes and links. For building them, we use the devices enabling virtualization, as e.g. the EZappliance, the NetFPGA, the XEN or others.

C

S c h e d u l e r

D S c h e d u l e r

Figure 6 Ideal device enabling to build virtual nodes and links.

REFERENCES

This PI PDU, after removing the TS header, enters the classifier which is responsible to deliver this PI PDU to CAN virtual node, more precisely, to port A of this virtual node. To classify the PI PDU to appropriate virtual node, we use the PI header. Next, the PI PDU is processed by CAN node and it is switched to the appropriate output port, say C, accordingly to assumed routing rules. Before its transmission by output port C, this PI PDU should pass by special scheduler associated to this port. The role of scheduler is to divide the output link rate between the running Parallel Internets while assuring isolation. For this purpose we use cycle-based scheduler (this scheduler is of non-work conserving type) as depicted on Figure 7. DSS

D DSS

[1] [2]

[3]

[4] [5] [6]

First level scheduling cycle-based

FIFO

[7]

A number of CoS CAN scheduler

Second level

CAN

DSS

A number of CoS QoS

CAN

IP QoS

MGT

[9]

DSS

scheduler

Second level

IPv6 QoS

[8]

D DSS

[10]

FIFO

System IIP management (MGT)

[11]

Figure 7 Cycle-Based scheduler for creating virtual links.

[12]

Apart the virtual nodes for each Parallel Internet, we also have management agent (MGT agent). The transmitted management messages correspond to management of the IIP System (not management corresponding to the Parallel Internet level) and are treated in the same way by the classifier as traffic belonging to particular Parallel Internets. The task of the management system is to tune the parameters of the device enabling virtualisation to dimension of each Parallel Internet. The dimensioning process is performed off line and is responsible for partitioning rate of output links as well as CPU, storage and cache memories between Parallel Internets. When we have these data, next step is to configure the device enabling virtualization by the management system. IV.

[13]

[14]

[15]

[16]

[17]

[18]

SUMMARY

In this paper we have presented the architecture of the IIP System. This architecture assumes co-existence of a number of Parallel Internets sharing common physical network

[19]

684

T. Zahariadis et al., Towards a Future Internet Architecture, The Future Internet (ed. John Domingue et al.), LNCS 6656 S. Paul, J.Pan, R.Jain R., Architectures for future networks and the next generation Internet: A survey, Computer Communications 34(2011), pp. 2-42 R.Jain, Internet 3.0: Ten Problems with Current Internet Architecture and Solutions for the Next Generation, Military Communications Conference, Washington, DC, October 23-25, 2006. T. Aoyama, A New Generation Network: Beyond the Internet and NGN, IEEE Communications Magazine, May 2009. G.Schaffrath et al., Network Virtualization Architecture: Proposal and Initial Prototype, VISA'09, August 2009, Barcelona, Spain A.Galis et al., Management and Service-aware Networking Architectures (MANA) for Future Internet. System Functions, Capabilities and Requirements, Position Paper, Version V6.0, 3rd May 2009. J. Babiarz, et al., “Configuration Guidelines for DiffServ Service Classes”, Internet RFC 4594, August 2006. F. Baker, J. Polk, M. Dolly, “A Differentiated Services Code Point for Capacity-Admitted Traffic”, Internet RFC 5865, May 2010. V. Jacobson, et al., “Networking Named Content”, CoNEXT 2009, Rome, Italy, December 2009 M. D. Ambrosio, et al., “Second NetInf architecture description”, Deliverable 6.2 of project 4WARD, FP7-ICT-2007-1-2160414WARD/D-6.2, January 2010, Y. Bernet, et al., “An Informal Management Model for Diffserv Routers”, Internet RFC 3290, May 2002. ITU-T Rec. Y.2012, “Functional requirements and architecture of next generation net-works”, (04/2010). W.Burakowski et al., The IIP System: Architecture, Parallel Internets, Virtualization and Applications, Future Network and Mobile Summit Conference, Warsaw 15-17 June 2011 W.Burakowski, H.Tarasiuk, A. Beben, P.Zwierko, Future Internet architecture based on virtualization and co-existence of different data and control planes, 5th Workshop on Future Internet Cluster, 15 June, Warsaw 2011 H. Tarasiuk, et al, “A Proposal of the IPv6 QoS System Implementation in Virtual Infrastructure”, To appear on Proc. of Networks 2012, Rome, Italy, October 2012. P. Swiatek, et al., “Supporting Content, Context and User Awareness in Future Internet Applications”, F. Alvares, et al. (Eds), FIA book 2012, LNCS 2012, Vol. 7281, pp. 154-165. D. Walczak, et al., "Machine-to-machine communication and data processing approach in Future Internet applications", To appear on Proc. of CSNDSP 2012, Poznan, Poland, July 2012. K. Gierowski, et al, "An integrated e-learning services management system providing videoconference HD and CAA services", To appear on Proc. of CSNDSP 2012, Poznan, Poland, July 2012. Andrzej Chydzinski et al., “Virtualization Devices for Prototyping of Future Internet”, SNDP 2012, Kioto, Japan