An Infrastructure Virtualisation SOA for VNO-based Business Models Surya Nepal, Jonathan Chan, Shiping Chen, David Moreland, John Zic Networking Technologies Laboratory, CSIRO ICT Centre, Australia Cnr Vimiera & Pembroke Rds, Marsfield NSW 2122, Australia {FirstName.LastName}@csiro.au Abstract Today’s networking and storage providers can typically offer a limited range of services to their customers because of their reliance on a small, preferred range of infrastructure technologies. The providers do this in order to deliver effective, well-understood services for their customers and minimise the risk associated with developing solutions from a variety of different technologies. They each deliver a particular solution for their customers. However, from the customers’ point of view, the provisioning of innovative, customised services that go beyond the services of a single infrastructure provider is very attractive. This paper presents a service-oriented architecture based on a well-established business model – the Virtual Network Operator (VNO) – that allows the providers to meet their customers’ complex requirements. Our proposed architecture uses virtualisation techniques to abstract the infrastructure services in such a way that new customised, value added services can be composed using existing infrastructure and/or VNO services, and then offered to customers. We illustrate our approach through two case studies of infrastructure services: storage and networking, and present the Web Services technologies we have developed for infrastructure virtualisation. Keywords: SOA, Web Services, Virtualisation, Business Models, Storage, Virtual Network Operator

1. Introduction The Service Oriented Architecture (SOA) approach is advocated for use in the development of new, large scale distributed enterprise applications in the e-health, e-banking and e-government domains. Under this approach, each application is written and developed abstracting the details of its internal operation from other applications, and communicating solely through a well-defined abstract service interface that is in turn defined by the messages that can be exchanged. The SOA methodology has been accepted into the architecture and development communities through the support of tools and standards such as WSDL [1], UDDI [3], and SOAP [2]. It is

important to emphasise here that one of the distinguishing features of SOA is that it enables architects and developers to define and build new services based upon existing services provided by independent partners. Included among the services used by enterprise applications are the third party infrastructure-specific services. Consider an e-government application that uses the network-specific services offered by two different local carriers in providing connectivity between two independent, autonomous government departments in providing their services. As a concrete example, a taxation office may require the establishment of a VPN through one network provider to collect health related expenses from the health department. However, because this network operator is unable to provide connectivity to the department of social security, the taxation office is required to use another, separate network to establish VPN connectivity between itself and the department. The problem with this situation is that now the taxation office must consider the individual services offered by their providers, as well as how these services may be composed in their particular application. This process is repeated for each application developed by the taxation office. One solution to this problem is for the taxation office to develop a “bridge” between these two providers to the taxation office applications. Better still, this function could easily be outsourced to a specialised service provider that offers a uniform connectivity service that is independent of the underlying infrastructure providers, and which hides the technical details of composition and compatibility (which still remains one of the problems for SOA). This transparent connectivity service for enterprise customers under different infrastructures is the original concept of the Virtual Network Operator (VNO) business model. The VNO concept can leverage the recent developments of virtualisation of infrastructure services, where underlying network infrastructures are abstracted and a uniform service is provided to a higher layer. This problem exists not only for the network services as mentioned above, but also for other infra-

structure services. For example, storage services may have been developed using different storage technologies, including NAS (Network-Attached Storage), SAN (Storage Area Network) and DAS (DirectAttached Storage). A virtual customised service is needed in order to provide a uniform access mechanism to these autonomous infrastructure-specific storage services for enterprise applications so that enterprise data can be shared within and across organisations deploying these different storage infrastructures. We therefore propose an infrastructure virtualisation architecture that is inspired by the VNO business model rather than a novel technology [4]. We believe that a diverse range of enterprise customers’ networking and storage requirements presents a unique business opportunity for a VNO-like business, we refer to as a Virtual Service Operator (VSO 1 ), to provide such innovative, customised services. Although the provision of these services has the potential to broaden the base for generating revenue, as well as expanding the customer base of a single service provider, it is likely to be beyond the resources of a single service provider to maximally exploit all the potential opportunities. Therefore, we envisage that there is an emerging market for the existence of many specialist VSOs in providing value added services for different enterprise sectors and different applications within those sectors. It also leaves open the possibility of transitioning to newer underlying, infrastructure technologies in a seamless manner, with the infrastructure providers responsible for ensuring interoperation and compatibility with current systems and is able to continue offering services as a profitable business. In this paper, we illustrate the ideas behind our architecture through case studies of storage and network infrastructures. We develop a Simple Distributed Storage Interface (SDSI) to enable virtualisation of storage infrastructure services, and a Simple Virtual Network Interface (SVNI) for virtualisation of network infrastructure. Our contributions in this paper are, an: • infrastructure virtualisation service-oriented architecture based on the Virtual Network Operator business model; • illustration of this architecture using storage infrastructure including the development of an SDSI and its implementation in the context of secure distributed storage service; and

1

The term VSO is a generalisation of VNO, and refers to service brokers who provide services across different types of infrastructures services such as network and storage.

•

illustration of this architecture using network infrastructure including the development of an SVNI and its implementation in the context of virtual private extranet service [6].

2. Background and Motivation The motivation of our work is based on two concepts: the Virtual Network Operator (VNO) business model and the software architecture models of Service Oriented Architectures (SOA). We believe that the integration of SOA is useful in enabling VNO like business models. This section reviews works on VNO and VSO, leading to the challenges and the problem space. The basic concept of a VNO is not new. By effectively sharing the physical infrastructure, VNOs can quickly develop networking capabilities to address the needs of new and growing niche markets without facing the enormous costs and delays incurred in constructing a physical network. As evidenced by a recent Gartner study [4], the VNO concept appears to be rapidly gaining commercial momentum; with pioneering companies like Vanco [5] reported to be enjoying a year-on-year growth rate of 35.4% in revenue and 99.8% in operating profit. A VNO’s success is based on the aims of highest-quality customer service. On the other hand, the downside of the current VNO model is that VNOs do not have control over the infrastructure upon which they build their services. This makes them highly dependent on their infrastructure providers to have the right capabilities, in terms of service quality and functionality, to satisfy the stringent requirements of their customers. The same principle applies to other infrastructures such as storage and computation power. Many ISPs already offer value-added services, such as email, free gaming, free video streaming, Web hosting, database hosting, and through these additional services, increase their revenue generating potential. We envisage that similar value-added services will become increasingly popular in the enterprise sectors, provided that service quality can be guaranteed. This implies that VSOs are likely to operate on a range of managed infrastructures, each offering their primary services such as network functionality, storage facilities, information services, and computation. Figure 1 shows the emerging enterprise service space, as we see it, which consists of (1) many VSOs providing specialised application services to their enterprise customers, and (2) a diversified infrastructure which is comprised of a variety of network, storage, computation and information resources, and is accessed by a wide range of sophisticated devices. To

join these two highly variant segments of “application services” offered by the VSO and “component services” offered by the infrastructure specific service providers, we need to build a well-engineered service provisioning architecture that has the following properties: many specialised application services

service provisioning architecture

diversified infrastructure

Figure 1: The challenge of the emerging enterprise service space Evolvable: to accommodate an ecosystem of VSOs. In this highly competitive and service centric environment, a VSO acts as a value enhancing autonomous business, similar to a shop owner renting premises and facilities in a shopping mall from its letting-consortium. From a feasibility point of view, this shopping mall business model has proven to be mutually beneficial to shoppers, shop owners and the letting-consortium. Customisable: to enable VSOs to rapidly roll out new services to address the needs of emerging niche markets rather than waiting for the desired embedded functions to be standardized and adopted by the vendors of infrastructure devices. Efficient: to enable VSOs to optimally utilise the underlying heterogeneous infrastructure so that they

can minimise daily operating costs and gain a competitive business advantage. Predictable: to be consistent in performance such that service quality will always be sustained above some minimum requirement despite specified fluctuations in demand and supply. Towards meeting these challenges, this paper proposes an infrastructure virtualisation based on SOA and utilizing Web Services (WS) standards. SOA allows the description and definition of software architecture using of loosely coupled software services to support the requirements of business processes. Networked resources in an SOA environment are made available as independent services that can be accessed without knowledge of their underlying platform implementation. Therefore, the SOA is a preferred style of architecture to meet the challenges faced by the VSO. However, it is important to note that despite the use of WS standards in our work, SOA is not tied to a specific technology. It may be implemented using a wide range of technologies, including J2EE, NET, or CORBA. We have used the base Web Services Protocols in our implementation; they work as follows. Service providers use WSDL to describe services, and publish them to a registry facility using UDDI. Service consumers again use the registry to discover services. Once the services are discovered, the communication between service providers and consumers is done using SOAP-based [2] request and response protocol for exchanging XMLbased messages over the managed network infrastructures.

3. Architecture

Figure 2 VNO-Based Infrastructure Virtualisation Services Architecture

Figure 2 gives an overview of our service provisioning architecture. As can be seen, it is a four-layer architecture, with a set of Common Services spanning the layers that deal with the issues of management, privacy, security and trust. We regard these Common Services as fundamental and integral to our architecture – they are not “add-on” services. An example of one of these common services is that each service operator, broker and application will be provided access and use of a registration service, thereby allowing other services to locate its offered services, as well as other information such as location information and access policies. Another example service is the provisioning of a common certifying authority service, allowing new operators (for example) to become trusted parties in the system. At the top of the architecture are the Application Domains. Education, Health and Finance are used as representative examples here, but other domains such as Government or Enterprise could be added to these. Typically, each domain is primarily differentiated from other domains by the types of Common Services (management, privacy, security and trust requirements) that need to be in place for each of the applications in their specific domain. The second differentiating factor is the actual services required for these applications (such as the usual Quality of Service requirements on bandwidth, latency, or storage capacity). These requirements are expressed through an eContract document [6]. Each eContract is machine interpretable, and is passed onto the Virtual Service Operators (VSOs) to allow these requirements to be realised (ultimately) in the infrastructure. Figure 2 also shows an example application for each domain. For example, in Education, a Trusted Conferencing System may be offered for the delivery of interactive tutorials only to enrolled students in that particular tutorial group. Within the Finance domain, a trusted banking application or service could be offered by the bank to its clients. In the Health domain, a tele-echo cardiograph service may be made available to several specialists engaged in a case review and associated discussions. The next layer down is the Service Brokering layer. This layer is the “home” of the application VSOs, that as their primary business driver, construct value-added services for applications using a set of Infrastructure Service Operators’ (IfSOs) services. Each VSO in this layer has a contractual obligation to meet the eContract requirements specified by a particular user application. When an eContract is passed to a VSO, it is interpreted and potentially conflicting requirements are resolved before it tries to satisfy the service requirements by passing on its request for services from each of the supplying infrastructure service

operators. A binding relationship is already in place between the VSO and the IfSOs via explicit service level agreements (SLAs) that are put in place when the VSO is created as a business entity. By placing this service level agreement in place, the VSO is able to readily determine if the eContract requirements can be met by its provided services. Below the VSO layer is the Infrastructure-specific Service layer. It is this layer that is the “home” of the IfSOs, that as their primary business driver, construct value-added services for infrastructure using a set of single type of Infrastructure Providers’ (IfPs) facilities and services. Example of IfSOs are Network Service Operator (NSO) - this is equivalent to VNO - for network infrastructures and Storage Service Operator (SSO) for storage infrastructures. We assume that each of these operators knows the characteristics of their infrastructure, so can indeed agree to and meet provisioning requests, and has developed a sound business from doing so. It is worthwhile pointing out that it is possible for an application to deal directly with IfSOs. The application itself needs to negotiate a suitable service level agreement with them, and develop value added services provided by application specific VSOs. Indeed, this is exactly how a VSO would be created – and the application may indeed offer some limited services to other applications after registering its capabilities with the Service Registry. The bottom most layer is the Infrastructure Provider layer, owned and managed by the IfPs. Typically it consists of various systems for storage (distributed storage, centralised fast storage, archival quality storage), networking (high capacity networking, sensor networks, low latency networking, QoS sensitive networking) and potentially, computing capacity. It is possible for higher-level services including applications to access services at this layer, but the developers of high-level services would have to take the burden of composing services and dealing with the issues of compatibility as explained in Section 1. In order to build higher-level services, the higher level must have access to services provided by lower layers. We believe that there is a need for standard interfaces between different layers in order to compose services at the higher-level using lower layer services. We have investigated the existing Web Services standards for storage and network infrastructures. Although Web Services standards support basic protocols for service provisioning on a variety of infrastructures, there are not any common standard interfaces defined for infrastructures. We envisage that infrastructure providers will come up with such a set of common interfaces in future. We report our findings and the corresponding technologies that we have de-

veloped to address the existing shortcomings in details in the case studies in the following sections.

4. A Case Study of Storage Infrastructure Service Virtualisation Figure 3 shows the VSO-based storage architecture. The key features of this architecture are: • The underlying (usually heterogeneous) storage infrastructures provided by IfPs, called Storage Providers (SPs), are virtualised and unified via a single interface – the Simple Distributed Storage Interface or SDSI; • A Storage Service Operator (SSO) can provide additional services to those of an SP by combining multiple SPs to deliver new storage services, such as high security and reliability with data partitioning, encryption and replication. Application Domain Enterprises

search

Trusted Conferencing Management

Application

Service Brokering Virtual Service Operator (VSO) Storage Service Operator (SSO) Storage Provider (SP)

Dynamic Collaboration Service

Other Application Services

search pub/sub

Certificate Authority

Storage Service Interface

Storage Service Secure Data Storage Service

Simple Distributed Storage Interface

Common Services

search pub/sub

Service Registry

customisation virtualisation

search pub/sub

Storage Infrastructure

Storage Provider 1

Storage Provider 2

Storage Provider 3

Technology: NAS

Technology: NAS

Technology: DAS

Figure 3: The Storage Service Virtualisation Architecture There is no overhead in managing the storage infrastructure and data from the users’ point of view, because the underlying storage infrastructures are owned and managed entirely by the participating Storage Providers (SPs). Our architecture may be distinguished from other virtualised storage architectures [7] [8] in that it allows the creation of new storage services that run as a business model, and offered by a variety of (possibly competing) storage service providers and operators. As shown in Figure 3, the storage architecture is a slice through the overall architecture presented in Figure 2. In this case study, our focus is on the bottom two layers, as they are specific to the storage infrastructure. The lowest layer contains the storage infrastructure provided by SPs. This layer represents an assembly of heterogeneous storage systems (hardware and software) that are offered by different vendors. Each of these storage systems may have different configurations in terms of devices and protocols, and may be in

turn be tuned to meet application-specific requirements. This layer in our architecture will support the co-existence of heterogeneous storage systems and provide a unified framework for the easy and efficient use of storage facilities. We define our own storage interface, called the Simple Distributed Storage Interface (SDSI) that enables SPs to open their infrastructures to their clients. This uniform interface enables virtualisation of the storage infrastructure. Each SP uses the SDSI to specify the contribution of individual storage infrastructure and to establish a virtual storage pool. This leverages the underlying Storage Infrastructure Layer and provides storage services at a higher level of abstraction, effectively allowing clients (applications, Storage Service Operators and other SPs) to read and write blocks of data to the Storage Infrastructure. Included with this is the ability to provide a logical interconnection between different storage systems. The Storage Service layer provides an opportunity for SSOs to build a variety of new storage services, by using a combination of services offered by one or more SPs. These new services provide value-added services to meet different storage requirements that are not directly supported by individual SPs. The virtual storage services may also customise the storage service to satisfy particular requirements such as performance and reliability. This layer also hides the complex and heterogeneous nature of the underlying storage infrastructures, by providing a virtual global storage infrastructure. The interface between the storage service and the VSO layer depends on the services offered by the storage service. One can use the SDSI or extended SDSI at this layer. In our prototype implementation, we have used the SDSI as a storage service interface.

4.1 SDSI As mentioned earlier, it would be ideal if a “distributed storage interface” standard were available to be used by a SSO, VSO, application, or other SP. However, there is no such standard at the moment. We therefore propose our common interface called the Simple Distributed Storage Interface (SDSI) for the SSO/SP interface, based on Web Services and expressed using XML. We summarise the key characteristics of the implemented version of the SDSI specification in the following section. The detailed SDSI specification is omitted due to the space limitations. The SDSI defines the component structures and basic data types of the APIs. The SDSI exposes sufficient information to the client interface (whether the client is a SSO, another SP, VSO or even an application) so that each client can negotiate and purchase

storage with specific requirements, store and access data, perform enquiries and obtain status information related to their account. In order to cover all these aspects of interaction between client and SP, the SDSI API provides both functional and non-functional components. Functional: The minimal set of requirements for a client is its ability to store data into, and retrieve data from, the storage infrastructure provided via the SP. Our SDSI store and retrieve calls are based on the simplest data types possible – fixed length data blocks, similar to that provided when accessing a hard disk drive volume. We allow more complex data types to be created and used if required by a client, since our SDSI API definitions are extensible. For example, a specialised SP for database storage may provide a set of database operations such as selective retrieval, indexing, or the enforcement of access control policies, and these may be offered as “additional” or valueadded services by this SSP. It is important to note, however, that we allow the designer the flexibility to decide as to whether to provide this extra functionality directly as a part of the SSP data types and function calls, or whether these are constructed at a higher level as a set of calls by an SSO (for example). In our block based implementation, the API allows the authorised person to create, read, update and delete the data in the storage. Bool Create(DataCreatingBlock data) Data Read(DataBlockIndex index) Bool Update(DataUpdatingBlock data) Bool Delete(DataBlockIndex index)

Non-Functional: Any SSP must support administrative APIs that are not directly related to operations on data (and these are referred to as non-functional APIs). In our case, the SDSI supports two types of non-functional APIs: Service–Level agreement (SLA) and Account Management. The current implementation of the SLA API includes: Contract SubmitPurchaseOrder(PurchaseOrder order) AccountDetails SubmitContract(SignedContract contract)

Similarly, the current implementation of the account management APIs includes: StorageUsageInformation GetAccountUsageInformation(UserAccount account) UserAccount CreateUserAccount(UserInformation user)

We omit the detailed description of these APIs due to the space limitations. We also omit the performance results in this paper as the focus of this paper is on architectures. Figure 4 shows a sample SOAP 1.1 request and response taken from our implementation of secure distributed storage at the Virtual Storage layer. The placeholders shown need to be replaced with actual values. We use the same interface for the SSO in our current implementation.

POST /DemoVSO/Storage.asmx HTTP/1.1 Host: perl.centie.net.au Content-Type: text/xml; charset=utf-8 Content-Length: length SOAPAction: "http://ict.csiro.org/Create" base64Binary string string int int int int HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Content-Length: length

Figure 4: A sample SOAP request and response for storing a data block in SSP via SSO.

5 A Case Study of Network Infrastructure

Service Virtualisation A case study of storage framework was illustrated in the previous section. In this section, we adopt a similar framework but in the context of network infrastructure. As shown in Figure 5, the network architecture is a slice through the overall architecture shown in Figure 2. Similar to the storage case study described, our focus here will be on the lowest two layers. The lowest layer is an IfP layer for networks (we call it the Network Provider (NP)), which is a heterogeneous environment in terms of a large range of core and access networking technologies, as well as different equipment vendors within the same technology classes. To be more competitive, the NP may choose to allow third parties to run their customised network functionality in the infrastructure. The idea of a network device running third-party executables is not

new. It was pioneered in Nortel’s “Oplet Runtime Environment” [12] and more recently the GENI facility [10] proposes the use of some customisable and virtualisable network “substrates” for the research community. In our network provisioning architecture, this customised functionality is not necessarily run only inside network devices but also by host computers associated with to the network devices. This looks like a similar situation to today’s ISPs for hosting web pages or databases for their customers, but the third party hosted functionality is able to interact only with the portion of infrastructure the third party has subscribed to. Therefore, the NP should employ virtualisation technologies to prevent the third party’s executables accidentally or maliciously damaging the computation resources or network infrastructure. The Web-Services based management protocol is a suitable candidate to provide an interface to third parties. Although a Web-Services Distributed Management (WSDM) introduction document [13] indicates that WSDM protocol may be used to manage switches and routers, so far only Cisco has joined the WSDM consortium. We may need to wait a while before any webservices based management protocols become mature in the networking domain. Application Domain Enterprises

search

Trusted Conferencing Management

Application

Service Brokering Virtual Service Operator (VSO)

Dynamic Collaboration Service

Other Application Services

Common Services

search pub/sub

Certificate Authority

Simple Virtual Network Interface

Network Service

Network Service Operator WS(NSO) Management

search pub/sub

Extranet Service customisation virtualisation

Service Registry

Interface

Network Provider (NP)

Networking Infrastructure Network Provider 1

Network Provider 2

Network Provider 3

Technology: L3VPN

Technology: L3VPN

Technology: VPWS

search pub/sub

Figure 5 The Network Service Virtualisation Architecture The second layer is the Network Service (NS) layer that provides NSOs with the capability to build a variety of new network services, by using a combination of services offered by one or more NPs. This layer uses a common web-services management protocol such as WS-management or WSDM to interact with the heterogeneous infrastructure. Through the Service Registry, the NSOs can invoke technology specific network services (e.g. Layer 3 VPN, VPWS, light path) from carriers in the infrastructure. Since the NSO is infrastructure-centric, it is responsible for converting the received network services description into

elements that are meaningful and applicable to the underlying infrastructures subscribed to. Being competitive in provisioning, a NSO not only makes and matches services from multiple carriers, but also creates and deploys its own functionality to fulfil the Network Service requirements (such as QoS) and to maximize the potential of the subscribed-to infrastructure. We propose a Simple Virtual Network Interface (SVNI) for VSOs to invoke network services.

5.1 SVNI and WS-Management Facing the VSOs, the NSO offers a Simple Virtual Network Interface (SVNI) to invoke network services. This interface is designed to accommodate structured modularity to hide the technical and organisational complexity of the infrastructure from the VSOs. It consists of two functional operations: Virtual Network (VN) and Access Policy (AP). The VN description identifies all edge nodes of a VPN hose model [15]. Each VN description can be associated with one or more AP descriptions, which are essentially an element list identifying the characteristics of the inprofile traffic entering the VPN. It is the responsibility of the NS to validate any conflicts between a VN description and its associated AP description(s), or among all AP descriptions within the same VN description. For example, the minimum bandwidth requirement in an AP description may exceed the maximum bandwidth specified in the VN description. Figure 6 shows a sample of SOAP messages between a VSO and a NSO when the VSO requests the service of the NSO to build VN and AP through the SVNI interface. In particular, the VSO calls the create_virtualNetwork operation. In return, the NSO indicates the successful creation of this VN. Now, based on the resources contributed in the eContract, the VSO calls the create_accessPolicy operation to constraint traffic entering this VN. The detailed description of this operation is omitted here due to space limitations.



Figure 6 SVNI message from a VSO to a NSO to create a new Virtual Network The NSO then uses the WS-management protocol to interface with carriers for invoking the “customer management functions” to create the required Layer 3 VPN service. In our example scenario various routers in these carriers will be contacted to build MPLS tunnels (if they do not already exist), VRF tables and policy based routing policies [6]. For instance, the MPLS tunnel request stated in WS-management protocol are translated into, say, a series of Cisco CLI commands as shown below in our implementation. interface Tunnel3 ip unnumbered Loopback1 tunnel destination 192.168.1.3 tunnel mode mpls traffic-eng tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng priority 1 1 tunnel mpls traffic-eng bandwidth 500 tunnel mpls traffic-eng path-option 1 dynamic tunnel mpls traffic-eng record-route

5. Conclusions and Future Works This paper presented a service-oriented architecture developed for providing virtual services based on Virtual Network Operator business model [4] as part of the CeNTIE virtual enterprise project [14]. The paper also reported the two case studies for network and storage infrastructures with interfaces designed and used.

We envisage that once underlying infrastructures can be “packaged” or virtualized in a way suitable for such Virtual Service Operators (VSOs), VSOs will be capable of penetrating substantially more enterprise sectors. It is possible that VSOs will become a significant icon for delivering specialised enterprise services, similar to the status of today’s Internet Service Providers (ISPs) by providing best-effort Internet connectivity for the general public. We are currently developing a Virtual Service Operator to provide a Dynamic Collaboration Service (DCS) for e-education. The virtual service operator offering the DCS constructs its services by using the services offered by a Network Service Operator and a Storage Service Operator as well as a set of registration, security, and trust related services offered by a trusted third party that interacts with users.

Acknowledgement Discussion with Glynn Rogers and Darwin Agahari of the prior eContract work and Virtual Network Operator greatly assisted us in developing this architecture. Special thanks go to Darwin and Bo Yan for designing and implementing the case studies discussed in this paper.

6. References [1] [2] [3] [4]

[5] [6]

[7]

[8]

[9] [10] [11] [12] [13] [14] [15]

WSDL http://www.w3.org/TR/wsdl. SOAP http://www.w3.org/TR/soap/ UDDI http://www.uddi.org/ E. Jopling and D. Neill. VNO Phenomenon Could Shake Up the World's Telecom Market. Gartner Research report G00131283. Nov. 2005 http://www.vanco.com J. Chan, G. Rogers, D. Agahari, D. Moreland, John Zic. Enterprise Collaborative Contexts and their Provisioning for Secure Managed Extranets. Proc. IEEE WETICE'06, Jun. 2006. Cisco. Next Generation of Storage Virtualization: EMC Invista Network-Hosted by Cisco. http://www.cisco.co m/application/pdf/en/us/guest/netsol/ns515/c643/cdcco nt_0900aecd803a9f0a.pdf IBM. IBM Storage Virtualization - Value to you. http:// www-03.ibm.com/servers/storage/software/virtualizatio n/wpapers/3182_svc.pdf http://www.openetlab.org/ http://www.geni.net/ http://www.dmtf.org/standards/wsman http://www.oasis-open.org/ www.oasis-open.org/committees/download.php/14351/ cd-wsdm-introduction_v3.doc http://www.ict.csiro.au/page.php?cid=22 N. Duffield, P. Goyal, A. Greenberg, P. Mishra, K. Ramakrishnan and J. van der Merwe. A flexible model for resource management in virtual private networks. Proc. ACM SIGCOMM 1999.