E2E Interdomain Optical Network Services

Transcription

1 Journal of Network and Systems Management ( c 2007) DOI: /s A Service Oriented Architecture-based Approach for Interdomain Optical Network Services Fábio L. Verdi, 1,4 Maurício F. Magalhães, 1 Eleri Cardozo, 1 Edmundo R. M. Madeira, 2 and Annikki Welin 3 This work presents a service-oriented architecture for interdomain service provisioning in optical networks. The architecture introduces a service layer that concentrates all the interactions among domains necessary for service provisioning. A service layer is an alternative to the GMPLS (Generalized Multiprotocol Label Switching) architecture, but without a rigid control plane as found in GMPLS. We start by defining a set of basic services to provide single end-to-end (e2e) interdomain connections. Then, more sophisticated services are created through the composition of these basic services. The interdomain Optical VPN (Virtual Private Network) service is considered in order to illustrate the composition of services. A prototype of the architecture was designed and implemented using Web services as the main technology. The architecture was evaluated in terms of speed, scalability, and bandwidth consumption necessary to establish e2e interdomain connections and Optical VPNs. KEY WORDS: services. Interdomain provisioning of services; SOA; Optical networks; Web 1. INTRODUCTION The Internet as it is today imposes several limitations to the introduction of new services and evolution of existing ones. For instance, a single domain is not able to establish end-to-end (e2e) connections across different Autonomous Systems (ASes). The collaboration among domains is essential for supporting more sophisticated services that demand long-haul connections. One of the main problems when considering interdomain connections is related to how Traffic Engineering (TE) and other local constraints are satisfied. 1 Department of Computer Engineering and Industrial Automation (DCA), Electrical Engineering Faculty (FEEC)-UNICAMP, Campinas, Brazil. verdi@dca.fee.unicamp.br. 2 Institute of Computing (IC-UNICAMP), Campinas, Brazil. 3 Ericsson Research, Torshamnsgatan 23, Stockholm, Sweden. 4 To whom correspondence should be addressed. verdi@dca.fee.unicamp.br /07 C 2007 Springer Science+Business Media, LLC

2 Verdi, Magalhães, Cardozo, Madeira, and Welin Clients that need an e2e connection crossing multiple domains should have a mechanism to choose the interdomain route that takes into account TE parameters such as bandwidth and delay. These parameters can be used to compute the cost of each edge connecting the nodes among all the domains. Currently, interdomain routing protocols (e.g., Border Gateway Protocol-BGP) do not carry any sort of TE information. Although BGP has some policies by which domains can define simple rules applied to specific traffic flows, no real e2e quality of service (QoS) metrics (e.g., bandwidth and delay) are taken into account. Since BGP was initially developed for the exchanging of reachability information, adding QoS metrics to BGP can compromise the scalability of the Internet routing [1]. The Generalized Multiprotocol Label Switching (GMPLS) suite of routing and signaling protocols is currently the only technology that provides mechanisms for supporting the provisioning of connections in optical networks. Although GMPLS proved its feasibility inside domains [2, 3], the networking community has not reached yet a consensus about the best way to establish connections across domains. Interdomain signaling and routing protocols being defined by standard bodies and industry forums such as ITU-T (International Telecommunication Union Telecommunication Standardization Sector), IETF (Internet Engineering Task Force), and OIF (Optical Internet Working Forum) still remain in an early stage of standardization. At the same time, the current interfaces that are being defined (e.g., the External Network-to-Network Interface, E-NNI [4]) lack very important features such as pre-reservation of resources and abstraction of routing information. There was also an attempt to create an Optical BGP [5] to join both routing and signaling functions in the same protocol. While GMPLS is a very prominent solution due to strong standardization and industry support, its deployment results in a tight-coupled control plane when the interdomain scenario is considered. This means that the control planes of different domains have to interact to support the provisioning of connections. Such interaction is necessary for the purposes of sharing topology information and allocation of resources. To support a complete and automatic e2e provisioning of services it is required that every single administrative domain deploys GMPLS. In our point of view, this is a very strong requirement since domain should be able to choose the mechanisms to establish internal connections that best fit their needs. Moreover, a domain can establish connections through management functions without the need of a control plane at all. Finally, GMPLS requires investment to upgrade the network equipments and introduction of new management and operation practices. This paper proposes a new approach to support the provisioning of service across multiple domains. Instead of having a GMPLS-based control plane, we favor an interdomain service layer for interdomain interactions. This approach considers that the control plane within each domain offers a set of services for

3 Provisioning of Interdomain Optical Network Services using SOA installing and removing network connections. 5 The service layer is in charge of controlling all the tasks related to the provisioning of e2e interdomain services (e.g., routing, signaling, admission control, policy enforcement, and interdomain negotiation). The interdomain service layer allows a domain to define its own set of service interfaces for interacting with other domains. Only a set of common functions supported by the interfaces must be standardized. This is the main motivation for this work since it is a consensus that it is easier to standardize interfaces than to standardize protocols. The two main functions necessary to provide interdomain services are routing and signaling functions. Routing consists of the advertising of virtual topologies among domains, while signaling consists of interdomain e2e negotiation. The set of services and their interfaces result in a loose-coupled solution, in opposition to a tight-coupled control plane. As an immediate result, the costs to support interdomain provisioning of services are reduced when compared to the GMPLS solution. Since the provisioning of services depends basically on defining interfaces in the service layer, it is not necessary to upgrade the network infrastructure (e.g., hardware and software) to support the GMPLS protocols. The service plane abstracts the underlying details on how the provisioning of connections is performed by each network provider. In this work we propose to implement the service layer using the Web services technology, the most appropriate technology for service-oriented architectures (SOA) [6]. The main objective of SOA is to help organizations to 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 (self-sufficient) or as composed (dependant of other services). A network service can be created through the composition of a set of primitive services. In this work, the interdomain Optical VPN (O-VPN) service was considered as an example of service composition. Although some solutions for Layer 1 VPN (L1VPN) in single domains have been addressed [7], almost nothing related to interdomain O-VPNs has been proposed. The architecture presented in this article extends the ideas discussed in the scope of single domain O-VPNs to interdomain O-VPNs. The main idea behind our proposal is to facilitate the interaction between client networks (e.g., IP/MPLS networks) and the optical network provider as well as between optical network providers. By adopting the Extensible Markup Language (XML) to exchange data and the Web Services Description Language (WSDL) to describe the interfaces of the services, the integration of different applications and the interaction between different administrative domains are easily achieved without the need of following complex specifications. Each domain can define its services and advertise their WSDL interfaces in a Web services registry. 5 These connections can be established using any solution, for instance, GMPLS. The exposed services hide the technology used in the control plane inside each domain.

4 Verdi, Magalhães, Cardozo, Madeira, and Welin The proposed approach also addresses the support of a new kind of business model, the Virtual Carriers (VC). VCs can be seen as virtual intermediary carriers (carrier s carrier) that offer specialized services to customers at a low investment. This approach allows carriers to share an optical network into VC-specific sub-networks, given each VC different levels of management control, including operations, administration, maintenance, and provisioning (OAM&P). We believe that this approach can contribute to the extension of the optical wavelength services market facilitating the selling, buying and management of wavelengths and will most likely act as a catalyst for market opportunities. We have implemented and tested a prototype of a service-oriented architecture aiming at evaluating the approach in terms of feasibility of using Web services in this type of scenario. The prototype was evaluated in terms of speed, scalability and bandwidth consumption to establish e2e interdomain services. The paper is organized as follows. Section 2 presents some related work. Section 3 describes some important aspects of interdomain service provisioning. Section 4 presents the identification of services for the proposed architecture. Section 5 describes the service oriented architecture for interdomain service provisioning. Section 6 discusses the interdomain O-VPN service. Section 7 presents the implementation details and the evaluation of a prototype developed according to the proposed architecture. Finally, Section 8 concludes the article. 2. RELATED WORK This section is dedicated to compare the architecture proposed in this article with other related proposals addressing Web services in the management of optical networks and interdomain service provisioning Web Services in the Management of Optical Networks One of the early architectures applying Web services to the management of optical networks is presented in reference [8]. The work considers that users can lease and manage their own resources (lightpaths). By means of a management system users can concatenate, partition, advertise/lease, and establish end-to-end lightpaths. Although the approach is very promising, it does not consider the constraints imposed by each domain since the establishment of end-to-end lightpaths does not take into account domain policies. The work presented in reference [9] discusses a solution for that problem in order to ensure that management rules of each domain are enforced. The authors showed a Web services-based architecture to establish end-to-end lightpaths considering policy utilization in admission and resource reservation control. Our approach considers some aspects of both works in the sense that we are also using Web services. However, we are taking into account the provisioning of interdomain services via composition of services

5 Provisioning of Interdomain Optical Network Services using SOA and negotiation between domains. Another difference is that in our approach the control and management of the lightpaths are not given to the user. The provider entity has the control of the resources. The work presented in reference [10] discusses a customer-oriented GMPLS service. The focus is to provide a management architecture for resilience differentiation based on the Telecommunication Management Network (TMN) reference model. The work does not consider multidomain management Interdomain Service Provisioning Although the provisioning of interdomain services is of great interest today, there are no common rules on how to meet the requirements imposed by such services. One reason is the lack of business models that address interdomain billing, resource allocation, 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 extensions to the BGP protocol, what, in our point of view, is a long-term process without guarantees of becoming standardized. In references [12, 13], the authors discuss how to support interprovider IP/MPLS services. At the same time, the IETF Common Control and Measurement Plane (CCAMP) charter is defining a framework for establishing and controlling MPLS and GMPLS LSPs in multidomain networks [14]. CCAMP takes into account the Path Computation Element (PCE) [13] architecture as the black box to advertise and compute interdomain paths. The PCE working group is in charge of defining the architecture for the computation of paths for MPLS and GMPLS Label Switch Paths (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. Reference [15] presents the concept of L1VPN. Nevertheless, the authors do not consider the provisioning of L1VPN service in multidomain scenarios. The works referred above do not consider the idea of having virtual topologies being advertised among optical domains. Recently, such an approach has been gaining attention [16, 17]. Reference [16] shortly introduces the mechanisms for resource provisioning with virtual network services and reference [17] presents some schemes for GMPLS Virtual Private Networks (GVPN). The GVPN service [18] describes VPN services that rely on BGP for VPN auto-discovery and on GMPLS for signaling. We have gathered the main concepts related to virtual topologies, mainly those related to the abstraction of the physical details, in order to test their feasibility and identify the challenges they impose. In our point of view, the virtual topology approach outlines novel models on how the interaction between domains can be accomplished.

6 Verdi, Magalhães, Cardozo, Madeira, and Welin 3. ISSUES ON INTERDOMAIN SERVICE PROVISIONING The proposed architecture for interdomain service provisioning is in line with the CANARIE roadmap [19] where the network is abstracted as a set of services. Such abstraction offers more functionality and flexibility for Internet Service Providers (ISPs). Routing protocols like OSPF (Open Shortest Path First) and BGP can be exposed as services. Services can be built from scratch or from legacy systems by using wrappers [20]. WSDL maps the functionalities of each service into an interface that can be freely defined on a per-provider basis. This approach does not need to follow the tight and long-term process of standardization. Services are defined by the providers and then registered in a public or private registry. Services can then be discovered, bound, and executed dynamically. In this work, the term service means a network service. The proposed architecture is also in line with the ideas presented in reference [21]. The authors discuss the future of the Internet and suggest that a complete redesign of the Internet might be necessary. As an alternative, the authors consider that a number of ideas that already exist can be put together to solve the current bottlenecks. We support this alternative in the sense that, by using current solutions such as Web services, it is possible to provide more complex and sophisticated services over the existing network infrastructure. We also believe that the network can no longer be seen as a simple physical infrastructure, but as a seamless part of an entire distributed application [19]. Since the solutions that lie on the extension of BGP to offer QoS have not evolved, we focus on virtual topologies for supporting interdomain QoS. By advertising virtual topologies, each domain will have a full graph of the network and then can apply path computation algorithms to find an optimal path for a given source/destination interdomain pair. At the same time, this solution can still take into account BGP policies in order to satisfy peering contracts of each domain. As mentioned before, the way lightpaths are established within each optical domain is a local decision. A domain can use a specific protocol (e.g., GMPLS) and follow local policies to create and remove connections. The architecture is seen as a set of primitive and composed services. It is an alternative for GMPLS with a key difference: the establishment of e2e services between domains is performed by Web services, not by GMPLS signaling. This approach frees the providers from waiting for standardization, since the GMPLS specification for protocol extensions to enable cross-domain reachability and TE advertisements has recently become an RFC [14]. Finally, the approach presented in this article focuses on a regional scenario. We envisage that this regional scenario is formed by condominiums of domains by which a group of domains agrees on advertising virtual topologies to each other. This advertising follows a peering model where all the domains that make part of the same condominium obtain the virtual topologies of other domains. These

7 Provisioning of Interdomain Optical Network Services using SOA condominiums of domains could define business rules in an attempt to create new relationships that make the interactions more customer-oriented. Giving more power of decision for customers will foster competition among ISPs imposing a different economic discipline and offering better services at lower prices. It is a consensus that monopoly is not consumer-driven but provider-driven. If end-users can choose the domain route observing prices and the quality of the service, ISPs will have to face a competitive pressure to drive the deployment of good and new services in order to attract and maintain clients. 4. IDENTIFICATION OF SERVICES FOR THE PROPOSED ARCHITECTURE Although there exist several technologies for distributed computing such as CORBA (Common Object Request Broker Architecture), DCOM (Distributed Component Object Model), and Java RMI (Remote Method Invocation), these technologies adopt a tightly coupled synchronous communication model (request/response) and show low level of interoperability. On the other hand, by using XML standards and Internet protocols such as HTTP (Hypertext Transfer Protocol), FTP (File Transfer Protocol), and SMTP (Simple Message Transfer Protocol) Web services offer a loosely coupled asynchronous communication model with high degree of interoperability. Figure 1(a) shows the SOA s findbind-execute paradigm in which providers register their services in a public or private registry and consumers query this registry to find services that attend certain criteria. After obtaining the address of the services, consumers can bind and invoke the services. Fig. 1. (a) SOA paradigm, (b) Services composition.

8 Verdi, Magalhães, Cardozo, Madeira, and Welin The strategy used to define the architecture described in this article consists in the identification of primitive services that are necessary to support other more sophisticated services as shown in Fig. 1(b). Services A and B are primitive, bottom-level services. Service C is constructed by composing/aggregating the two primitive services. Since a composed service is itself a service, this mechanism can be recursively applied to create other composed services. We believe that service composition is the key towards new ways of designing, deploying, and managing network services [20]. The services defined in the sequence represent the tasks that are necessary to support interdomain interactions in order to establish e2e connections and O- VPNs. To some extent, such services incorporate the functionalities provided by the GMPLS signaling and routing protocols. The advertising service (AS) is a primitive network service responsible for advertising the virtual topology of each domain to other domains (routing function). The second primitive network service is the e2e interdomain negotiation service (E2ENS). It is responsible for performing the negotiation among domains in order to establish e2e interdomain connections (signaling function). The e2e interdomain connection service (E2ECS) offers an interface from which clients request interdomain connections. The interdomain connection service is a composed network service since it depends on 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) responsible for activating/deactivating and monitoring the O-VPN on a per-vpn basis. These two services are constructed by composing the previously defined services, for instance, TS uses E2ENS to reserve resources for the O-VPNs. A service responsible for finding interdomain routes (routing function) was also defined. Such service is the path computation element (PCE) service and follows the specifications being defined by the IETF [13] for this element. The architecture also comprises internal modules to manage external requests and enforce local policies. These modules together with the Web services modules gather all the necessary functions to provide intra [22] and interdomain connections. The next section details the proposed architecture and how it provides e2e interdomain services. 5. THE SOA-BASED ARCHITECTURE FOR INTERDOMAIN SERVICE PROVISIONING In this section we detail the proposed architecture presenting its components and their interactions. The management plane of the architecture is divided into two logical parts (see Fig. 2(a)). The first part, or service layer, groups the Web services that are responsible for offering to external entities (clients and other

9 Provisioning of Interdomain Optical Network Services using SOA Fig. 2. (a) The proposed architecture, (b) The optical domain seen as a group of Web services. domains) an interface for accessing the functionalities of the management system. These Web services form the SOA architecture and abstract the details on how internal tasks are implemented. This view is shown in Fig. 2(b). In this way, the optical domain is seen as a set of primitive or composed Web services, each one responsible for providing specific functionalities. The service layer is still divided into two parts: e2e services and legacy services. E2e services are constructed from scratch and perform e2e iterdomain interactions, while legacy services expose legacy systems such as routing and billing systems as Web services. The second logical part of the management plane is related to the internal modules that are necessary to manage the control and admission of requests as well as the application of local policies. The service layer and the internal modules are detailed next Service Layer The service layer provides an interface that is invoked by other applications (e.g., Web browser or other services). The domain administrator models the services, defines their behavior and publishes the interfaces in a registry so that the services can be looked up and accessed by external entities. The Web services at the service layer are described in the sequence.

10 Verdi, Magalhães, Cardozo, Madeira, and Welin Advertising Service AS The advertising service is responsible for advertising the virtual topology to other domains. This virtual topology represents the lightpaths that cross the optical domain and is formed by Forwarding Adjacencies [14]. The details on how the lightpaths were set up are hidden from the clients. By adopting this approach, the interdomain QoS-based provisioning of services is possible since each domain has the virtual topology of all other domains and a simple Constraint Shortest Path First (CSPF) algorithm suffices to find the most appropriate route to attend e2e constraints. The virtual topology to be announced is defined by the domain administrator. A given domain may have different virtual topologies that are advertised following specific rules such as the variation of the amount of traffic during the day, services being offered, availability of resources, and presence of failures or bottlenecks. For instance, the domain administrator may define a standard virtual topology to be used under normal conditions and other virtual topologies that are advertised when specific conditions are detected. By using this approach, the domain administrator is able to define rules taking into account business strategies. The virtual topology can have an expiration time, forcing its continuous actualization. Clients are able to contract the AS by defining rules on when the virtual topology should be advertised and what level of information is to be advertised together with the virtual topology. Figure 3 shows two domains and their virtual topologies being advertised to each other. The cost of each virtual edge is directional, i.e., there is no relation between the cost from node i to node j with the cost from node j to node i. We show only one cost for the sake of simplicity. The interdomain path selection is computed by considering the virtual topology advertised by the optical domains. Fig. 3. Advertising virtual topologies.

11 Provisioning of Interdomain Optical Network Services using SOA Each virtual link represents a set of resources (lightpaths) that can be used to establish e2e connections (e.g., to create an interdomain O-VPN). The amount of lightpaths under each virtual link is a domain local decision and depends on the physical resources available at each optical domain. The cost of each virtual link does not change as the lightpaths are consumed and/or released. This cost reflects the cost to use a single lightpath under that virtual link. When there are no more lightpaths under a given virtual link, new lightpaths can be created between the two nodes. How and when to create lightpaths is up to the local domain administrator. The AS and the PCE together perform the routing function in the services plane End-to-End Negotiation Service E2ENS This service is responsible for negotiating e2e interdomain connections with other domains. We adopted a two-phase-star-based model by which the head-end domain 6 negotiates with other domains asking for an available resource (lightpath). The first phase queries and reserves the resource. During the first phase, the traffic parameters are analyzed in each domain in order to verify if the connection can be accepted. The second phase confirms the reservation in the case where all the domains involved in the negotiation have the required resource. If one of the domains does not have the required resource, the reservation needs to be released. Currently we are using the bandwidth, level of protection, and type of traffic 7 as the QoS traffic parameters to be negotiated. Each domain is responsible for finding a resource using local constraints. E2ENS does not take any decision on how the selection of resources is conducted in each optical domain. The service only carries the parameters passed by the client in the connection request. The virtual topology as explained above gives a general view about the routing between domains. The difference between the advertised virtual topology and the actual amount of resources in each optical domain is resolved by E2ENS. The negotiation service is used not only to carry the real traffic parameters required by the client, but also to confirm if there still exist resources under the virtual links and to reserve the resources in each optical domain. E2ENS performs the signaling function in the service plane End-to-End Connection Service E2ECS This composed service is invoked by clients in order to ask for a single e2e interdomain connection. Firstly, the service needs to find an e2e interdomain route by invoking the PCE service. Note that to find the route, the PCE service depends 6 The domain where the service request was received. 7 We handle two types of traffic: High Priority (HP) and Low Priority (LP). By having these two classes of services we are able to apply grooming policies as shown in [23, 24].

12 Verdi, Magalhães, Cardozo, Madeira, and Welin on the AS. It is through the virtual topology of each domain that the interdomain route is computed. Finally, E2ECS invokes E2ENS to negotiate resources with the involved domains. After performing these phases and considering that the e2e connection is established across the domains, the client is able to start sending data through the connection PCE Service The PCE service is invoked by the internal modules of its domain. It is responsible for finding an interdomain route so that an e2e interdomain connection can be established. Since the virtual topology of each domain was advertised by the domain s AS, finding an interdomain route is just a matter of applying a routing algorithm. Notice that PCE is responsible not only for finding the route (path computation) but also for getting the virtual topology from other domains [13, 25]. In our architecture these functions are performed by different modules (PCE and AS). In our point of view, the advertising mechanism can offer more functionalities specifically for certain types of services such as O-VPN, and this modularization allows to develop each module independently. Although the PCE service is being currently invoked only by local modules, it can represent a given region or area. Other domains that do not have such service can use the PCE service from a third-party provider. This is a typical SOA scenario where services are offered, queried and used. The trading service (TS) and the O-VPN service shown in Fig. 2 are explained in Section 6. Finally, to have a complete SOA scenario it is necessary to provide a mechanism where services are published and discovered. The Registry is a module where the end point of each service is stored. The architecture does not use the Universal Description, Discovery and Integration (UDDI) repository [26] since UDDI has more functionalities than is needed in this work. Many current works have used the same simpler approach [9]. The registry acts as a private directory where the service interfaces are registered and a mechanism for querying such services is provided. Figure 4 shows how the architecture performs service-oriented computing. The domain publishes its services in the registry through a Web-based interface and sets information about the service (service name, service description, interface endpoint, and service endpoint) (step 1). A given user queries the available services in the Registry database (step 2) and retrieves WSDL interface and endpoint of the service that best matches the query. Since a WSDL interface is selfdescribing, it is possible to generate in run time the infrastructure necessary to invoke the service (step 3). Finally, the client application invokes the service through a client application using SOAP (Simple Object Access Protocol) over HTTP (step 4).

13 Provisioning of Interdomain Optical Network Services using SOA Fig. 4. SOA-based architecture scenario Internal Modules The internal modules perform local domain tasks to support the provisioning of services. The admission control (AC) module receives connection requests and verifies pre-defined SLAs. These SLAs are defined in a customer-provider contract and specify what type of connection or service a given client can request. The policy manager (PM) module is responsible for applying the policies defined by the domain. Policies for grooming and fault management were defined [23, 24]. The resource manager (RM) module manages all the information related to the usage of the virtual topology and optical resources. The fault manager (FM) module receives link failure events generated by the optical network equipments and prepare the lightpaths contained in the failed fiber. In this work we are only considering fiber failures although there are other types of failures in optical networks such as lightpath failures and optical device failures. The lightpaths contained in the failed fiber are grouped according to their level of protection. Then, the FM module sends each group of lightpaths to the policy manager that in its turn applies the defined policies for failures treatment [23]. Finally, the membership manager (MM) module is responsible for the management of the membership information of each O-VPN.

14 Verdi, Magalhães, Cardozo, Madeira, and Welin Fig. 5. Provisioning of an e2e interdomain connection. Figure 5 depicts how the internal modules interact to each other to establish an e2e interdomain connection. During step 1, the client queries the registry looking for the e2e interdomain connection service. The end point with the location of the service is returned to the client. After having obtained the interface and endpoint of the service, clients are able to invoke this service. The invocation should include all the necessary traffic parameters required by the client (step 2). E2ECS receives the request and forwards it to the admission control (step 3) module. AC validates the request and asks PCE for a route (step 4). Afterwards, a resource must be reserved in the local domain (step 5). Policies for admitting the new connection are applied in step 6. Steps 7 and 8 perform the e2e interdomain negotiation using the e2e interdomain negotiation service. For sake of simplicity, step 8 represents both the reservation and confirmation phases. Note that in each domain, steps 3 (dispatched by the E2ENS), 5 and 6, are performed. The e2e multidomain route is computed in two steps. In the first step, the PCE takes into account the whole topology formed by each optical domain virtual topology. This route represents the shortest path with the smallest cost. However, such route does not follow BGP routing neither peering contracts between domains. Then, after computing the e2e multidomain route based on the virtual topology, the legacy services (e.g., BGP and peering contracts) should be accessed in order to verify if peering policies are respected. If the peering contracts accept the route calculated by the PCE service, then such route will be used to establish the e2e interdomain connection. If not accepted, then the route without QoS given by BGP should be used. Furthermore, final agreements could be done through the e2e interdomain negotiation service (E2ENS). The negotiation between domains is performed in parallel. The head-end E2ENS invokes E2ENS of the domains belonging to the e2e interdomain route. Local constraints in each domain are applied in order to accept or not the connection. E2ENS of each domain returns back confirming or denying the request.

15 Provisioning of Interdomain Optical Network Services using SOA Currently, the negotiation protocol does not support counter-proposals by the downstream domains. If the invoked domain does not have the resource required during the reservation phase, the e2e connection will not be accepted. However, another e2e interdomain route could be found and negotiated. The number of negotiation attempts can be defined by the client. Next section discusses the O-VPN service and how this service is provided between different administrative domains. 6. THE O-VPN SERVICE This section shows how composition of services facilitates the creation of novel network services. We do not intend to discuss O-VPN in details, but present some key concepts to better understand the evaluated scenario. More information about the O-VPN service can be obtained in the cited references L1VPN Background Figure 6 shows two optical VPNs with their corresponding virtual topologies. Customer Edge (CE) devices are customer nodes that receive the service from the provider. Provider Edge (PE) devices are provider nodes that are connected to at least one CE. Provider (P) devices are core provider nodes that are not connected to customer nodes. There are two resource allocation models for L1VPN. In the shared model, the network resources are used by multiple VPNs in a time-sharing manner. In other Fig. 6. Optical VPN Service A and B.

16 Verdi, Magalhães, Cardozo, Madeira, and Welin words, a resource that has been released by one VPN can be used by another VPN. In the dedicated model, resources are reserved to a specific VPN for its lifetime and these resources can not be used by another VPN. The L1VPN functional model is presented in reference [7]. It includes functions for membership information maintenance, route computation and route information maintenance, connection control, and service management. Only functionalities related to membership information maintenance are specific for L1VPN. The other three functions are common to single connections. There are three types of architectures for L1VPN service provisioning [27]. In the centralized architecture there are no distributed routing or signaling functions. In the distributed architecture, L1VPN service functions make use of distributed signaling and routing within the provider network. PE and CE communicate through a common control plane. There is also a hybrid architecture in which some functions are centralized and other functions are distributed. In this case, specific VPN functions are centralized and common functions such as connection provisioning within the domain are distributed using, for instance, GMPLS. Our architecture supports both the dedicated and shared models and is based on the management service model by which customers access the provider management system to request connections. Furthermore, the distribution of the functionalities follows the hybrid model where some tasks are performed by the control plane (distributed) and other tasks are performed by the management system (centralized). Connection provisioning within the optical domain is performed by the control plane while membership maintenance and connection provisioning between domains are performed by the management system. This solution is in line with the ideas presented in reference [7]. The physical details of the optical network are abstracted by using the virtual topology concept, as explained in Section 5. The O-VPN is established over such virtual topology by reserving e2e connections between multiple interdomain CE ports. Such approach applied to VPNs is very shortly commented in reference [28]. At the same time, the management service model is well indicated for interdomain O-VPN service since it facilitates the negotiation of the e2e resources in each domain Interdomain O-VPN Establishment To support interdomain O-VPN, two services were defined: The trading service (TS) and the O-VPN service itself (Fig. 2) Trading Service TS This service is responsible for reserving and releasing the optical resources for a given O-VPN. Once a resource is reserved for an O-VPN, no other O-VPN can use that resource. This service allows a customer to reserve the necessary resources

17 Provisioning of Interdomain Optical Network Services using SOA in order to guarantee that when the O-VPN is installed the reserved resources will be available. When TS receives a request to reserve resources, it forwards such request to the Admission Control module for validating the request. During the reservation phase, the customer sends information related to the establishment of the O-VPN (type of traffic, level of protection, etc.). The O-VPN CE ports to be connected are also informed by the customer and the combination of ports is verified by the membership manager module O-VPN Service O-VPNS This service is responsible for activating and deactivating O-VPNs as well as triggering the billing system to start charging the client for the usage of the optical resources. 8 The O-VPNS allows each customer to get the O-VPN membership information and monitor each O-VPN without interfering in O-VPNs established for other customers. The amount of information that can be delivered to customers depends on the type of agreements that are pre-established between clients and providers. The advertising service (AS) was firstly proposed for advertising virtual topologies. By adding the O-VPN service to the architecture, AS became also responsible for advertising the membership information of each O-VPN. Each domain defines the mapping between CE and PE ports for each O-VPN. The identification of a CE port is known as Customer Port Identifier (CPI) and its equivalent in the provider side is known as Provider Port Identifier (PPI) [18]. These mappings are statically configured in each optical domain (forming a Port Information Table PIT) and advertised to other domains that belong to the interdomain O-VPN. Domains that do not have at least one port in the O-VPN will not receive the membership information. Figure 7 shows an example of an O-VPN membership information being advertised to other domains. The advertising service receives the PITs (from other domains) and forwards such tables to the membership manager (MM) in order to merge them with the local PIT. When a customer requests the establishment of an O-VPN, MM verifies if the CE ports informed by the customer are valid. After the advertising phase, each optical domain will have the complete membership information about the interdomain O-VPNs. As part of the contract between customers and providers, the PIT of each O-VPN can be obtained by the CEs to request the establishment of interdomain O-VPNs. Figure 8 shows how the modules interact to each other to establish an interdomain O-VPN. Observe that by using the idea of services composition, the establishment of an interdomain O-VPN is performed by using the services already defined for 8 Since the charging model depends on local decisions, we have not defined a billing module for our architecture.

18 Verdi, Magalhães, Cardozo, Madeira, and Welin Fig. 7. Example of an O-VPN membership advertising. Fig. 8. Establishing an interdomain O-VPN.

19 Provisioning of Interdomain Optical Network Services using SOA the establishment of single e2e connections. Basically, it was necessary to add only one new step (membership verification) to provide the O-VPN service. The remaining steps are the same needed by single e2e connections. The reservation of resources for O-VPNs is performed by the trading service (TS) and O-VPN activation is performed by the O-VPN service. The amount of tasks that need to be processed during the activation phase can vary in each domain. Typical tasks include the crossconnection of the lightpaths of each e2e connection and the activation of the billing system. A given provider can use the reserved resources to carry low priority traffic until the owner of such resources does not activate the O-VPN. When the O-VPN is activated (effectively used), the low priority traffic is diverted from the O-VPN ligthpaths. This mechanism is masked from the clients and does not affect the reservation of resources. The key point of composition of services is well illustrated in the O-VPN service example. To provide such service, it is necessary to have other services responsible for advertising the topology of each domain, compute interdomain routes, and negotiating single connections with other domains. Since these are primitive e2e interdomain services, the provisioning of more complex and sophisticated services (such as the O-VPN service) is just a matter of using/composing the previously defined ones. In terms of designing and implementation, such approach speeds up the creation of new services in a way similar to software reuse [29]. 7. ARCHITECTURE PROTOTYPING 7.1. Implementation Details The validation of the implemented architecture was conducted in our intranet using five Pentium 4 3 GHz processors (with Hyper Threading enabled) with 1 GB RAM and running Linux Slackware. All the machines have 10/100 Mbs network interface cards. The modules were developed in Java and public domain tools were used to facilitate the implementation. All the Web services are created using the Apache AXIS 1.2 suite. The internal modules are remote objects developed using the Java RMI technology. Web services are accessed through XML-based SOAP messages over HTTP. The management information is mostly represented in XML and manipulated with native Java XML tools. The virtual topology and the O-VPNs employed in the tests are shown in Fig. 9. The domains are named from A to E. The scenario considered here is the one with IP/MPLS clients and Wavelength Division Multiplexing (WDM) optical providers. We defined three O-VPNs that are spread out over five optical domains. VPN 1 has 6 ports, VPN 2 has 4 ports, and VPN 3 has 5 ports. Each local MM keeps the mapping between CPI/PPI that composes the local PIT of each O-VPN.

20 Verdi, Magalhães, Cardozo, Madeira, and Welin Fig. 9. Virtual topology and the O-VPNs used in the tests. 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 service uses the CSPF algorithm to find the shortest path taking into account the smallest cost across multiple domains. The abstract cost gathers the QoS of the virtual link in terms of protection, bandwidth, BER (Bit Error Rate, a.k.a. q-factor) and price. In theory, the higher the cost the better the service is. However, during the negotiation, each domain should inform the values for each parameter to be negotiated as well as the meaning the abstract cost over each virtual link. These parameters are the ones supplied by the client and validated by the AC module as explained in Section 5.2. The bandwidth, the type of traffic, and the level of protection are the parameters that are negotiated between domains. Specifically for this work, a high number of lightpaths was defined for each virtual link: 400 thousands for interdomain and 200 thousands for intra-domain. Such a high number is justified by our interest in accepting all the connections. We have also assumed that the border optical devices are OEO (optical-to-electricalto-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 wavelength that enters the optical device to any wavelength that leaves the optical device (full conversion of wavelengths) Evaluation In order to evaluate the prototype, we have conducted some performance evaluation in order to assess the impact of using Web services to provide and

21 Provisioning of Interdomain Optical Network Services using SOA Table I. Time Consumption for Each SOAP Interaction and the Size of Each SOAP Message Interaction Time consumption (ms) SOAP message size (bytes) Client to E2ECS (req) (resp) Total = 1806 AC to PCE 9, (req) (resp) Total = 1313 AC to E2ENS 9, (req) (resp) Total = 2067 E2ENS to E2ENS (reservation phase) 13, (req) (resp) Total = 1720 E2ENS to E2ENS (commit phase) (req) (resp) Total = 1077 Total time/size for SOAP coomunication 52, manage e2e interdomain connections and interdomain O-VPNs. In terms of bandwidth consumption, it is important to estimate the overhead due to the introduction of XML-based SOAP messages. The size of SOAP messages affect not only the bandwidth consumption but also the time necessary for message processing (marshaling, unmarshaling, and parsing). SOAP messages are longer when compared to common network protocols due to the textual nature of the messages and the amount of meta-information transferred with the message contents (e.g., headers, data types, and security attachments). Therefore, the required bandwidth and processing time of a service depend significantly of the complexity of the service interfaces. Proposals for shortening SOAP messages (e.g., message compression) were not used since they can compromise interoperability. In this article we show some performance figures taking into account the time to communicate between modules and the size of each SOAP message involved to establish the proposed e2e interdomain services. We firstly focus on the establishment of single e2e connections. Afterwards, the establishment of interdomain O-VPNs is evaluated Evaluation of Interdomain E2E Connection Establishment The total time to establish an e2e interdomain connection depends on the time of each interaction between every pair of modules. Table I shows such times considering only SOAP messages. This average size of each message is shown in the last column. The average was obtained after running 1000 executions. It is depicted the size for the request and for the response. Notice that this size is a mean estimate and can vary depending on the value of each element/attribute. The amount of SOAP messages to establish a single e2e interdomain connection can be drawn as follows: N, where the first two messages are fixed, being one from the AC to PCE and another one from AC to E2ENS. 9 The 2 N 9 We are not considering the client to E2ECS message since in some cases such request does not come from a Web service client but from a simple HTTP request without the SOAP payload.

22 Verdi, Magalhães, Cardozo, Madeira, and Welin part comes from the negotiation protocol where it is necessary one message for the reservation phase and another one for the commit phase, and N is the number of domains involved in the neotiation. If the response for each request is counted, then we have: N SOAP messages. This is valid for the successful case, i.e., when all the downstream domains have the resource available. If the reservation fails (in this context, fail means not having enough resources), the number of SOAP messages is lower since the rollback is only propagated to the domains that have the resource reserved during the reservation phase. Then, in case of failure, the expression would be: (4 + 4 N) (2 amount of failed domains). Figure 10(a) shows the approximated time to establish an e2e connection having only one requesting domain (one single domain requesting for connections) and Fig. 10(b) illustrates the scalability of the prototype to attend many requesting domains. In the first case, the average time was calculated over a requests scenario. In the second case, the average time was calculated over a requests scenario. Each request is immediately sent after receiving the answer from the previous one. Figure 10 gives an idea of variation of the average time. Each point in the graph shown in this figure is computed as the average of 500 subsequent requests. The numbers in Fig. 10(a) depict that as the complexity of the scenario increases (more domains added), the time to establish an e2e connection varies slightly, proving the efficiency of using a star-based negotiation protocol. When the scenario has 3 domains, the average time to establish an e2e connection is about 81 ms. Increasing to 5 domains this time is around 105 ms. This increasing in time is due to the longer length of the e2e route as more domains were added and does not belong to the e2e negotiation. The length of the route has an impact on the final time due to the amount of resources that need to be reserved along the route. As the length of the route increases, more resources must be reserved. As can be seen in Fig. 10, the first connections take more time than the average. This effect is due to the loading of Java classes when they were accessed for the first time. Subsequent accesses to these classes will found them already loaded in memory. Figure 10(b) shows assess the impact in a specific domain when other domains are making requests at the same time. For this scenario, we analyzed the domain A with 5 domains in the tests. The numbers show that when only domain A is making requests the time is about 105 ms. By increasing the number of domains, the time to establish an e2e connection in the domain A slightly increases. With 5 domains requesting for connections, the time in the domain A is approximately 135 ms. Considering that many domains are making requests, this increasing in time is almost irrelevant. If we analyze the mean time from 1 to 5 domains for all the scenarios, there is an increase of only 30 ms.