Web Services for the new Internet: Discussion and Evaluation of the Provisioning of Interdomain Services

Transcription

1 Web Services for the new Internet: Discussion and Evaluation of the Provisioning of Interdomain Services Fábio L. Verdi, Student, IEEE, Rafael Pasquini, Student, IEEE, Maurício Magalhães, Member, IEEE and Edmundo Madeira Abstract In these last few years, the Internet as it is today has put some limitations on the evolution of new services. Problems such as address space scarcity, mobility, sensor networks and VoIP are becoming common requirements now and will be more frequent in future. However, the current Internet architecture does not support this evolution. In 2003, Jon Crowcroft [1] discussed the problems of the Internet Architecture. In January 2005, a report from NSF [2] addressed the barriers that need to be faced in order to overcome limitations towards a new internetworking architecture. In this paper, we discuss how Web services can be useful in solving some interdomain problems. The strong interaction between ISPs already exists and will be more necessary as new services appear. We believe that the Web services solution is a facilitator in this path. Our discussion is supported by the CANARIE [3] research point of view that everything is a service. We use this idea in the context of interdomain interactions where each domain is then seen as a service. We developed an architecture to support these interactions and evaluated the prototype in terms of time and bandwidth consumption to provide interdomain services. Index Terms Next Generation Internet, Interdomain Provisioning of Services, Web Services, Optical Networks. I. INTRODUCTION Until some years ago, it was a consensus that the Internet was perfect and nothing had been left to be improved. This consensus is being challenged by the research community since novel and expected forms of data are emerging. Typically, there are two ways to face Internet problems these days. The easiest and most common path is to incrementally add patches to the Internet and solve specific problems. The other way is to break the current infrastructure down and replace it by another one totally renewed that addresses the several challenges for a longer time. The former path is the one chosen by the research community so far. While to incrementally add specific solutions to the Internet is easier and faster, it results in more complexity for management and more vulnerabilities to emerging threats. At the same time, the disruptive solution is not feasible without the intrinsic difficulties for turn the current Internet off, redesign it and deploy a new one. There is no way to stop the Internet and then install a new one as a whole. That should be done in parts by each provider, domain or region considering and assuming Fábio L. Verdi, Rafael Pasquini and Maurício Magalhães are with the Department of Computer Engineering and Industrial Automation (DCA), School of Electrical and Computer Engineering (FEEC), State University of Campinas (Unicamp). {verdi,pasquini,mauricio}@dca.fee.unicamp.br. Edmundo Madeira is with the Institute of Computing (IC), State University of Campinas (Unicamp). edmundo@ic.unicamp.br. the risks separately. The 26 pages report of NSF workshop on barriers to disruptive Internet identifies five limits related to the current incremental path [2]: Minimize trust assumptions: the network traffic should be viewed as adversarial and not as friendly; Enable user choice: economic and commercial aspects of the current transactions need to be taken into account. The new Internet should offer mechanisms to support the dynamic and constant growing of world wide exchanging of data; Allow for edge diversity: the increasing number of sensors and mobile devices makes the current concept of edge connectivity inappropriate; Design for network transparency: originally, the Internet does not expose internal information about its configuration. However, in some cases it would be important to show internal information for external users; and Meet application requirements: QoS is not considered in the current Internet architecture. Only a best-effort packet delivery service is available, but there is value in enhancing the network to meet application requirements. Although the risks mentioned above are pretty much a limitation on the evolution of the current Internet, we believe that the disruptive path will take some time to be really put into practice. The NSF report also agrees that expecting global agreement about a new network architecture is not realistic in an environment dominated by commercial considerations. Also as the NSF report, we believe that an overlay infrastructure together with the virtualization of underlying resources can be a feasible and initial starting point towards the new Internet and towards the solution for the five limits mentioned above. So, if the disruptive solution is not feasible, we will have to walk step-by-step in a way that the problems are solved separately to form the whole solution. At the same time, we are also in line with the ideas presented in [4]. They discuss the future of the Internet and, as such, the authors claim that to reach some objectives, a complete redesign of the Internet might be necessary. However, they also believe that sometimes a number of ideas that already exist can be put together to solve the drawbacks. We support the latter idea in the sense that by using current solutions, it is possible to provide more complex and sophisticated services. The question is how, where and when to start. The answer for the latter question is: it has already started. The develop /06/$ IEEE 279 ITS2006

2 ment of the next generation networking is happening and as expected, specific current solutions are being used to support the advent of the new Internet. In this paper we elaborate the answers for the two first questions specifically for the problem of interdomain provisioning of services. We always see many discussions on how to provide interdomain services (e.g., connections with end-to-end QoS and VPNs). However, most architectures are not practical since they depend on the extensions of BGP to support end-to-end (e2e) interdomain QoS and TE paths. Unfortunately, BGP was initially developed to exchange only reachability information. Adding QoS metrics to it can affect the scalability of the Internet routing [5]. We adopt the idea that each domain can be seen as a set of services that can be invoked to perform specific tasks. The virtualization of resources allows each ISP to expose or hide internal details on a per-domain basis. The information may be aggregated or abstracted to preserve confidentiality. By abstracting the underlying physical topology, the resources of the provider can be shared among different customers increasing the ISPs revenue, decreasing the operational expenditure (OPEX) and the capital expenditure (CAPEX) of their companies. We advocate in favor of a new architecture for each administrative domain. The approach presented in this paper tries to support a new kind of business model that favors some customers - the Virtual Carriers (VC) - allowing them to offer new services at a low investment. VCs can be seen as virtual intermediary carriers (carrier s carrier) that offer high level services to customers. This approach permits carriers to share a network into VC-specific sub-networks, where each VC is given varying levels of management control, including operations, administration, maintenance and provisioning (OAM&P). To support this new vision, we adopt the Web services technology to represent the services that a specific provider can offer. We follow the Service Oriented Architecture (SOA) principles to construct our model. Basically, SOA requires that applications are constructed using a loose coupling design and the services are dynamically discovered. The main objective of SOA is to help organizations drive their business towards a service-oriented enterprise (SOE). In SOA every logical entity is seen as a service. Services can be defined as primitive (selfsufficient) or as composed (need other services to perform its tasks). A network service can be created by composing a set of primitive services. This recurrent definition is important in the sense that it allows a more complex service to be built above a set of already existing services such as back-end, resource management and network management services [6]. Overlay and virtualization walk together and, as mentioned before, they are seen as a promising alternative for dealing with the five challenging points listed above. The overlay has often been used to augment the current Internet features and deploy experimental designs. Overlay networks, in contrast to the traditional physical networks, are not geographically limited. Overlay networks can be accessed by any user through packet-redirection implemented by host proxies. We believe that the functionalities offered by overlay networks and the access to configure proxies can be supported and realized through Web services. Moreover, the virtualization concept is nothing more than a high-level abstraction that hides the underlying implementation details [7]. The Web services technology is again a facilitator to provide the mechanisms on how to support the virtualization concept. In this paper, we instantiate the virtualization and the overlay concepts in a tentative of using them to support interdomain provisioning of services. Each domain can be seen as an overlay network by which its services can be geographically and transparently accessed (using HTTP). The virtualization of the underlying resources (optical resources in our case) is done by masking the internal details of each optical domain. The virtualization of the optical resources is realized by creating virtual topologies over the physical optical network. This virtual topology is then advertised to other optical domains which in turn can calculate interdomain TE routes. The quantity of information that each domain advertises together with the virtual topology is a local policybased decision. By using Web services as the technology to support interdomain provisioning of services we are going towards the development of the new Internet architecture without having to reengineer it. To validate our approach, we test our architecture in an emulated optical network scenario. In this case, each domain offers optical connections for their customers. Such connections can be solely provided or they can make part of an interdomain Optical VPN. The evaluation of our prototype was done using 8 optical domains and the time and bandwidth consumption were collected in order to evaluate the impact of using Web services in this type of scenario. Although preliminar, the evaluation shows that the Web services technology performs well to support interdomain provisioning of services. The architecture being proposed in this work is general enough and can be used in other scenarios. The use of the architecture in an optical context can be seen as an instantiation of it. Then, from now on we will discuss the use of the architecture and its applicability in the optical scenario only. The discussion about the use of the architecture in other domains is easily extended and will not be considered in this paper. Our approach does not preclude the Internet as it is today neither does it exclude the BGP policies. We propose a service layer that facilitates the interactions between providers by using Web services and keep all the legacy Internet infrastructure. We also believe that the usage of XML and Web Services Description Language (WSDL) avoid the tight and long term process of standardization. The WSDL maps the functionalities of each service into an interface that can be freely defined on a per-provider basis. The remaining of this paper is organized as follows: next section discusses some related works. Section III presents the architecture. Section IV details the implementation and the evaluation of the prototype. Section V concludes the paper and draws some future works. 280

3 II. RELATED WORKS The work discussed in [8] focus on a framework to provide a service layer over the Automatically Switched Transport Network (ASTN). Similar to our architecture, the authors idea is to mask the transport-related implementation details by providing a service plane. In that work, the authors do not mention how the service layer is implemented neither do they mention what technology is used to support the service layer. Although there is a common sense that Generalized Multiprotocol Label Switching (GMPLS) will likely be used inside the domains since some tests have been done and proved its feasibility [9], connections between domains are being deeply discussed through the international community and they have not reached a consensus yet. Interdomain signaling and routing being defined in standard bodies and industry forums such as ITU-T, IETF and OIF still remain in an early stage of standardization. The External Network-to-Network Interface (E-NNI) [10] is being specified by the OIF and its purpose is to allow the interactions between different domains by creating a standard interface. Nevertheless, there are no common rules on how to meet the requirements to provide interdomain services since it demands a great effort to establish business models, billing and Service Level Agreements (SLAs). The MESCAL approach [11] presents an architecture to support interdomain QoS. Although the project idea is very interesting, it depends on the extension of BGP [12], what, in our point of view, is a long term process without guarantees of becoming a standard. In [13], [14], the authors discuss how to support interprovider IP/MPLS services. At the same time, the Common Control and Measurement Plane (CCAMP) charter under IETF is defining a framework for establishing and controlling MPLS and GMPLS LSPs in multidomain networks [13]. They take into account the PCE [14] architecture as the black box to advertise and calculate interdomain paths. The PCE working group is in charge of defining the architecture for the computation of paths for MPLS and GMPLS TE LSPs. However, for the time being, there are many points to be discussed and standardized such as the selection of the best interdomain path, the communication protocol between PCEs and again how BGP will support QoS information. Finally, our group has been working to integrate Web services with the establishment of optical connections. In [15] we presented a policy-based Admission Control responsible for managing the installation and aggregation of packet-based LSPs within lightpaths. In that work we defined some policies for performing packet-based grooming in the border of the optical network domain. An evolution of such work is presented in [16] in which several extensions in the policies were done and new ones were defined to take into account the aggregation of flows within a lightpath to minimize the impact of failures. Last but not least, in [17] a Web servicesbased architecture to provide and manage intra-domain Soft Permanent Connections (SPCs) was presented. Our approach benefits from the XML open standard by which the interaction between providers can be easily done without having to follow specific standardization processes of Internet forums. Each provider needs to define the services it wants to expose and advertise them in a public or private centralized registry. Customers that need to invoke a service of a given provider queries the registry, gets the WSDL and learns how to invoke the service. This is done in a dynamic and transparent peering relationship. III. DETAILING THE ARCHITECTURE The design of the architecture adopted the SOA model as the base for creating the services. We started by defining simple or primitive services. Then, other more sophisticated services were created by composing the simple ones. Firstly, we identified what type of services would be necessary to provide interdomain services. Since we are virtualizying the underlying optical resources, we started by creating an Advertising Service (AS) responsible for announcing virtual topologies and membership information to other domains. The latter information is necessary since the architecture supports the interdomain O-VPN service. Such service allows customers to create O-VPNs including sites from different domains spread out around different carriers. The virtual topology represents the lightpaths that cross the optical domain and is formed by Forwarding Adjacencies [18]. Internal details on how the lightpaths were set up is hidden from clients. Each domain establishes the lightpaths using GMPLS, ASON or any other suite. The domain administrator can define a standard virtual topology to be used in normal conditions and other virtual topologies that are used when specific conditions are detected. By using this approach, the domain administrator is able to define rules taking into account business strategies and advertise different virtual topologies to different domains. Fig. 1 below shows a scenario. Fig. 1. A 6 D Virtual Topology Domain C 2 VT1 Advertising Virtual Topologies. E A E Virtual Links B Physical Network C D A Domain 2 7 VT2 3 E C 4 Virtual Topology Observe that two different virtual topologies are being advertised. Domain 1 receives VT 1 and Domain 2 receives VT 2. The quantity of information that can be included together with the virtual topology depends on the peering contracts established by each ISP with other ISPs. The closest level is the one with only nodes and virtual link information. However, more details about each node and each link can be provided such as the type of the node (grooming node, number of transceivers, optical conversors, OEO, etc.) and the type of the virtual link. Each virtual link represents a set of resources (lightpaths) that can be used to establish e2e interdomain connections. The quantity of lightpaths under each virtual link is a local domain decision and depends on the physical 281

4 resources of each optical domain. Information related to the level of protection of each lightpath can be included during the advertising. The openest level of information is the one that includes information related to each wavelength (lambda) in each fiber. Due to confidentiality constraints, this level of information should only be used if a strong relationship between domains is established. Also note in Fig. 1 that there is no physical connection between nodes A and C. However, after creating the lightpaths between the nodes, nodes A and C appear as neighbors in the virtual topologies. This is a very useful way of masking how the local provisioning of connections is established. The internal route of each lightpath is not advertised. Local administrators can play with this mechanism to over provide optical resources and increase their revenue. By adopting this virtualization approach, the interdomain TE is possible since each domain has the virtual topology of all other domains and a simple Constraint Shortest Path First (CSPF) algorithm can be used to find the most appropriate route to attend e2e services. In a certain way, this solution brings the e2e interdomain routing (e.g. BGP routing) to the management plane instead of being at the control plane. The e2e interdomain routing is then seen as a simple service (having its own WSDL) that can be invoked by other services or applications. The Advertising Service (AS) implements the virtualization concept in the optical context. Since the virtualization encompasses the abstraction of underlying details, in the optical network context it consists in abstracting the underlying physical optical network details. Although the relationship between domains is done by defining SLAs, dynamic negotiation is necessary at the time of establishing connections to agree upon the connection parameters. Then, the second primitive network service we have defined is the e2e interdomain negotiation service (E2ENS). It is responsible for doing the negotiation among domains in order to establish e2e interdomain connections. In this negotiation, parameters such as the class of service and the level of protection required by clients are transfered from the head-end domain 1 to other domains in order to negotiate the requisition. A two-phase-star-based protocol is used to perform the negotiation. In phase 1, the resource reservation is done. If all the domains have the resource (lightpath), phase 2 commits the reservation. There is an e2e interdomain connection service (E2ECS) that offers an interface to clients to ask for interdomain connections. The interdomain connection service is a composite network service since it depends on the E2ENS to perform its tasks. Finally, two services were defined to support the interdomain O-VPN service: The Trading Service (TS) responsible for reserving resources between the domains and the O-VPN Service (O-VPNS) itself responsible for activating/deactivating and monitoring the O-VPN on a per-vpn base. These two services are constructed by composing the previously defined services. As an example, the TS uses the E2ENS to negotiate and reserve resources for the O-VPNs. The O-VPN service will not be detailed in this paper. It is just mentioned as an example of services composition and will be 1 The head-end domain is the domain where the requisition was made. addressed in a further work. Besides these services, we have also defined a service responsible for finding the interdomain route. Such service is named Path Computation Element (PCE) and follows the specifications being defined under the IETF [14]. The whole architecture also comprises internal modules to manage external requisitions and local policies. The type and the quantity of local modules depends on local decisions. In our architecture we have defined a Resource Manager (RM), a Policy Manager (PM), an Admission Control (AC) and a Fault Manager (FM). These modules together with the Web services modules gather all the necessary functions to provide intra [17] and interdomain connections. Fig. 2 shows the architecture and how the scenario is realized. The architecture is located on a per-domain basis. Observe that there is a registry where the end point of each service is stored. The Registry acts as a private directory where the service interfaces are registered and a mechanism to query such services is provided. Fig. 2. AC PM domain A Customers RM FM look up invoke Registry Web services Layer Local Modules Interdomain Negotiation domain C Web Services-based Architecture. E2ECS PCE OVPNS E2ENS TS AS domain B To establish an e2e interdomain connection, a given client queries the Registry looking for the service. The end point with the location of the service is returned to the client. After having obtained the end point of the service, clients are able to invoke the E2ECS. The invocation should include all the necessary traffic parameters required by the client. The E2ECS service receives the requisition and forwards it to the Admission Control (AC). The AC validates the requisition and asks the PCE for calculating a route from source to destination nodes informed by the client. Afterwards, a resource must be reserved in the local domain. Policies for admitting the new connection are applied in this phase. Then, after reserving the local resources, the e2e interdomain negotiation using the E2ENS is performed. Each remote domain can also apply local policies to accept or not the connection. The E2ENS does not take any decision on how the selection of resources is done in each optical domain. The E2ENS only carries the parameters that are required by the client to establish the connection. If the negotiation is successfully done (other domains have the required resources and accept the connection), a notification is returned to the customer that can start using the connection. 282

5 The Web Services Layer can be easily extended to support other services. The services listed above, although enough to instantiate our idea, are just examples of services that can be defined. At the same time, the Web Services Layer not only represents the overlaying concept as mentioned in the Introduction but also it opens new opportunities for new entrants to the service provisioning market. A new-generation service provider could deploy an overlay supporting a new architecture and distribute proxies that allow anyone, anywhere to access that overlay [2]. The proxies in this case would be the Web services endpoints (WSDL) of each service defined in each domain. IV. IMPLEMENTATION AND EVALUATION In this section we give some details related to the implementation of a prototype we developed to instantiate our approach. The intention here is to analyze the impact of using Web services and XML as the technologies to support the architecture explained above. The implementation of the prototype was done in a cluster of sixteen nodes running Linux Slackware For this work we used eight nodes each one representing one optical domain. The cluster is not running DNS, routing protocols (OSPF) neither NFS. So, the numbers collected in the simulations represent the time to establish e2e interdomain connections without background networking interference. The prototype was implemented in Java 1.5. The Web services are running over the Apache AXIS 1.2. The internal modules are remote objects developed using the Java RMI technology. The communication between Web services is done through XML-based Simple Object Access Protocol (SOAP) messages over HTTP. Each domain has its virtual topology (represented in XML) and each edge (virtual link) has a cost defined locally by the domain administrator. The PCE uses the CSPF algorithm to find the shortest path taking into account the smallest cost between two nodes across multiple domains. We have also assumed that the border optical devices are OEO (optical-toelectrical-to-optical) and as such, there is no need to advertise details about the wavelengths of the lightpaths since OEO devices are able to electronically crossconnect the optical signal from any lambda that enters the optical device to any lambda that leaves the optical device (full conversion). The evaluation of the prototype took into account two models of Web services communication. In the first evaluation, we used the RPC SOAP binding model to establish the invocations between Web services. For the second test, we used the wrapped SOAP binding model. The differences between both are very perceptible during the simulations since the XML message size of the RPC binding is well greater than the message size of the wrapped binding. As an example, the message size of the E2ENS to E2ENS invocation (reservation phase) is 491 bytes using the wrapped style. The same invocation using the RPC style has a message size of 1502 bytes. The wrapped binding uses the document style and as such, the size of the XML message decreases since no typing information is sent together with the data. The message is clean and the format is validated through an XML schema in the server side. Although the RPC model facilitates the implementation, it not only increases the message size but also breaks the SOA principle of loose coupling. At the same time, using the tools that come together with the suites (e.g., AXIS and Microsoft.NET), the implementation and the deploying of Web services is easily and automatically done. Currently, the Web services community is moving from the RPC model to the document (wrapped) model mainly to follow the SOA principles. The time to establish an e2e interdomain connection depends mainly on where the Web services are located and how the resources are reserved in each domain. As mentioned before, the numbers collected for this paper are based on local times without background interferences and without going out to the Internet. The propagation time (time for network transferring) to send the XML from one Web service to another is very low. Locally it takes on average 350 microseconds. Below, in Fig. 3, we show the times for establishing an e2e interdomain connection for each type of SOAP binding. The numbers were collected after running 1000 requisitions and then the average was calculated. The X axis represents the quantity of domains making requests. The Y axis represents the average time in milliseconds to establish the connection. In our scenario, an e2e interdomain connection crosses 3 domains on average. Based on previous studies [19], the mean e2e communication in the Internet traverses between 3 and 4 domains. Then, the size of the route in our tests is in line with real scenarios. The figures show that the RPC style is worse than the wrapped style in terms of time consumption. While the former takes about 176 ms to establish a connection having one requesting domain, the latter takes about 160 ms. The scalability of the system was tested by having more than one requesting domain making requisitions. As we can see, the times from one to four requesting domains slightly increases. As an example, the wrapped style with one requesting domain takes 160 ms to establish a connection. In the scenario with four requesting domains the time is about 176 ms, a difference of only 16 ms. Time (ms) Fig Variation and Average Time 2 Number of Requesting Domains Times to establish e2e interdomain connections. 3 Legend Wrapped RPC The times obtained in the tests represent a real invocation of a client requiring an e2e interdomain connection. The number of domains slightly impacts the size of the SOAP message. The length of the route is the main factor to increase the size and the time to establish a connection

6 When comparing the wrapped style with the RPC, we clearly see the difference between both. As expected, the message size of the wrapped style is well smaller than the message size of the RPC style. Although there is no other architecture to compare with, the numbers collected in our simulations are quite low and are an estimative for ISPs about the cost of adopting Web services and XML for interdomain interactions. Since there are no underlying interferences during the data transmission, the numbers represent most the time that is necessary for marshalling and unmarshalling the XML SOAP message. Undoubtedly, if putting this solution into a real Internet scenario, the final times would increase due to the normal Internet traffic load. Then, a delay mainly during the negotiation with other domains should be added. However, it is not our intention to analyze the Internet performance, since it has its intrinsic problems that affect any application that goes through it. Also, our intention in this work was not to evaluate all the possible scenarios that exist in interdomain environments neither to collect all the performance measurements for each case. Our goal was to show that the Web services technology can be seen as a feasible solution for ISPs to create e2e interdomain business services at a low cost. V. CONCLUSION It is a consensus that the Internet is facing its limit in terms of architecture. The research community has been adding patches on it for nearly 30 years resulting in narrows and specific solutions for specific problems. Now that the emerging services such as mobile networks, videoconference and telemedicine are appearing, it is necessary to create mechanisms to support all the requirements of each new application. While the total reengineering of the Internet does not happen, the research community needs to create solutions based on what exists today. The overlay networks and the virtualization can be combined to create and support new Internet services. In this paper, each domain is seen as a set of services that can be easily invoked. The virtualization of the underlying resources gives local administrators the capability to abstract local details and maximize the use of physical resources. The interdomain provisioning of services is necessary since no single provider can offer long haul connections. The e2e interdomain connections cannot be established without the cooperating of several different carriers and administrative domains. How to facilitate this interaction is a very challenging topic of research. In this work, we presented our vision on how to solve this problem by using Web services. Such technology has been highly used to support the next step of distributed computing. It enables software components, including application functions, objects and processes from different systems to be exposed as services. The Web services-based architecture discussed here is a starting point towards more sophisticated solutions on how to facilitate interdomain interactions. Our purpose is to discuss how the Web services technology can be used in this type of scenario. The evaluation proved that in terms of time to establish connections and in terms of bandwidth consumption, the Web services can be seen as a promising path to be followed. More studies need to be done to better analyze the virtual topology approach. While it allows the administrators to over provide physical resources, it is necessary a fine control of all the virtual topologies and how their resources are being shared. This is left for further study. Currently, we are also investigating the O-VPN service. We have already implemented and tested it and it will be addressed in a further paper. ACKNOWLEDGMENTS The authors would like to thank CNPq, CAPES, FAPESP, and Ericsson Brazil for their support. REFERENCES [1] J. C. et al., Plutarch: An Argument for Network Pluralism, ACM SIGCOMM, August [2] NSF Report. Overcoming Barriers to Disruptive Innovation in Networking. Report of NSF Workshop, [3] B. Arnaud, CA*net 4 Research Program Update - UCLP Roadmap. Web Services Workflow for Connecting Research Instruments and Sensors to Networks, Draft, December [4] D. C. et al., Making the world (of communications) a different place, Report of a working session of the End-to-End Research Group - Internet Research Task Force, January [5] L. X. et al., Advertising Interdomain Qos Routing, IEEE Journal on Selected Areas in Communications. Vol. 22. No. 10, pp , December [6] V. de Souza and E. Cardozo, A Service Oriented Architecture for Deploying and Managing Network Services, Proceedings of the 3rd International Conference on Service Oriented Computing (ICSOC 05), LNCS-Springer-Verlag, pp , December [7] T. Anderson, Overcoming the Internet Impasse Through Virtualization, IEEE Computer, pp , April [8] B. Martini, F. Baroncelli, and P. Castoldi, A Novel Service Oriented Framework for Automatically Switched Transport Network, IFIP/IEEE International Symposium on Integrated Network Management (IM 2005), May [9] C. C. et al., The IP/MPLS Over ASON/GMPLS Test Bed of the IST Project LION, IEEE Journal of Lightwave Technology, vol. Vol. 21, No. 11, pp , November [10] OIF Intra-Carrier E-NNI 01.0 Signaling Specification. [11] M. P. H. et al., Provisioning for Interdomain Quality of Service: the MESCAL Approach, IEEE Communications Magazine, vol. 43, no. 6, pp , June [12] A solution for providing inter-as mpls-based qos tunnels, IETF draft, work in progress, May [13] L. Fang, N. Bita, J. Roux, and J. Miles, Interprovider IP-MPLS Services: Requirements, Implementations, and Challenges, IEEE Communications Magazine, vol. 43, no. 6, pp , June [14] A. Farrel, J.-F. Vasseur, and J. Ash, Path Computation Element (PCE) Architecture, IETF draft, work in progress, September [15] F. L. Verdi, C. Carvalho, E. Madeira, and M. Magalhães, Policy-based Grooming in Optical Networks, 4th IEEE Latin American Network Operations and Management Symposium (LANOMS 2005), pp , August [16] C. Carvalho, F. L. Verdi, E. Madeira, and M. Magalhães, Policybased Fault Management for Integrating IP over Optical Networks, The 5th IEEE International Workshop on IP Operations & Management (IPOM 05), LNCS-Springer-Verlag, vol. 3751, pp , October [17] F. L. V. et al., Web Services-based Provisioning of Connections in GMPLS Optical Networks. The Brazilian Symposium on Computer Networks (SBRC 2005). Fortaleza, Brazil, May [18] A. Farrel, J.-F. Vasseur, and A. Ayyangar, A Framework for Inter- Domain MPLS Traffic Engineering, IETF draft, work in progress, July [19] J. P. et al., Scalability Analysis of the TurfNet Naming and Routing Architecture, First International ACM Workshop on Dynamic Interconnection of Networks, pp , September