a service oriented architecture-based approach for ...verdi/jnsmpublished.pdf ·...

Journal of Network and Systems Management ( c© 2007)DOI: 10.1007/s10922-007-9060-2

A Service Oriented Architecture-based Approachfor Interdomain Optical Network Services

Fabio L. Verdi,1,4 Maurıcio F. Magalhaes,1 Eleri Cardozo,1Edmundo R. M. Madeira,2 and Annikki Welin3

This work presents a service-oriented architecture for interdomain service provisioningin optical networks. The architecture introduces a service layer that concentrates all theinteractions among domains necessary for service provisioning. A service layer is analternative to the GMPLS (Generalized Multiprotocol Label Switching) architecture,but without a rigid control plane as found in GMPLS. We start by defining a set ofbasic services to provide single end-to-end (e2e) interdomain connections. Then, moresophisticated services are created through the composition of these basic services. Theinterdomain Optical VPN (Virtual Private Network) service is considered in order toillustrate the composition of services. A prototype of the architecture was designed andimplemented using Web services as the main technology. The architecture was evaluatedin terms of speed, scalability, and bandwidth consumption necessary to establish e2einterdomain connections and Optical VPNs.

KEY WORDS: Interdomain provisioning of services; SOA; Optical networks; Webservices.

1. INTRODUCTION

The Internet as it is today imposes several limitations to the introduction ofnew services and evolution of existing ones. For instance, a single domain isnot able to establish end-to-end (e2e) connections across different AutonomousSystems (ASes). The collaboration among domains is essential for supportingmore sophisticated services that demand long-haul connections.

One of the main problems when considering interdomain connections isrelated to how Traffic Engineering (TE) and other local constraints are satisfied.

1Department of Computer Engineering and Industrial Automation (DCA), Electrical EngineeringFaculty (FEEC)-UNICAMP, 13083-970 Campinas, Brazil. E-mail: [email protected].

2Institute of Computing (IC-UNICAMP), 13084-971 Campinas, Brazil.3Ericsson Research, Torshamnsgatan 23, 16480 Stockholm, Sweden.4To whom correspondence should be addressed. E-mail: [email protected].

1064-7570/07 C© 2007 Springer Science+Business Media, LLC

Verdi, Magalhaes, Cardozo, Madeira, and Welin

Clients that need an e2e connection crossing multiple domains should have amechanism to choose the interdomain route that takes into account TE parameterssuch as bandwidth and delay. These parameters can be used to compute the costof each edge connecting the nodes among all the domains. Currently, interdomainrouting protocols (e.g., Border Gateway Protocol-BGP) do not carry any sort ofTE information. Although BGP has some policies by which domains can definesimple 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 initiallydeveloped for the exchanging of reachability information, adding QoS metrics toBGP can compromise the scalability of the Internet routing [1].

The Generalized Multiprotocol Label Switching (GMPLS) suite of routingand signaling protocols is currently the only technology that provides mechanismsfor supporting the provisioning of connections in optical networks. AlthoughGMPLS proved its feasibility inside domains [2, 3], the networking communityhas not reached yet a consensus about the best way to establish connections acrossdomains. Interdomain signaling and routing protocols being defined by standardbodies and industry forums such as ITU-T (International TelecommunicationUnion—Telecommunication Standardization Sector), IETF (Internet EngineeringTask Force), and OIF (Optical Internet Working Forum) still remain in an earlystage of standardization. At the same time, the current interfaces that are beingdefined (e.g., the External Network-to-Network Interface, E-NNI [4]) lack veryimportant features such as pre-reservation of resources and abstraction of routinginformation. There was also an attempt to create an Optical BGP [5] to join bothrouting and signaling functions in the same protocol.

While GMPLS is a very prominent solution due to strong standardizationand industry support, its deployment results in a tight-coupled control plane whenthe interdomain scenario is considered. This means that the control planes ofdifferent domains have to interact to support the provisioning of connections.Such interaction is necessary for the purposes of sharing topology information andallocation of resources. To support a complete and automatic e2e provisioning ofservices it is required that every single administrative domain deploys GMPLS. Inour point of view, this is a very strong requirement since domain should be able tochoose the mechanisms to establish internal connections that best fit their needs.Moreover, a domain can establish connections through management functionswithout the need of a control plane at all. Finally, GMPLS requires investmentto upgrade the network equipments and introduction of new management andoperation practices.

This paper proposes a new approach to support the provisioning of serviceacross multiple domains. Instead of having a GMPLS-based control plane, wefavor an interdomain service layer for interdomain interactions. This approachconsiders that the control plane within each domain offers a set of services for

Provisioning of Interdomain Optical Network Services using SOA

installing and removing network connections.5 The service layer is in charge ofcontrolling all the tasks related to the provisioning of e2e interdomain services(e.g., routing, signaling, admission control, policy enforcement, and interdomainnegotiation). The interdomain service layer allows a domain to define its own setof service interfaces for interacting with other domains. Only a set of commonfunctions supported by the interfaces must be standardized. This is the mainmotivation for this work since it is a consensus that it is easier to standardizeinterfaces than to standardize protocols. The two main functions necessary toprovide interdomain services are routing and signaling functions. Routing consistsof the advertising of virtual topologies among domains, while signaling consistsof interdomain e2e negotiation. The set of services and their interfaces resultin a loose-coupled solution, in opposition to a tight-coupled control plane. Asan immediate result, the costs to support interdomain provisioning of servicesare reduced when compared to the GMPLS solution. Since the provisioning ofservices depends basically on defining interfaces in the service layer, it is notnecessary to upgrade the network infrastructure (e.g., hardware and software) tosupport the GMPLS protocols.

The service plane abstracts the underlying details on how the provisioningof connections is performed by each network provider. In this work we proposeto implement the service layer using the Web services technology, the mostappropriate technology for service-oriented architectures (SOA) [6]. The mainobjective of SOA is to help organizations to drive their business towards aservice-oriented enterprise (SOE). In SOA every logical entity is seen as a service.Services can be defined as primitive (self-sufficient) or as composed (dependantof other services). A network service can be created through the composition ofa set of primitive services. In this work, the interdomain Optical VPN (O-VPN)service was considered as an example of service composition. Although somesolutions for Layer 1 VPN (L1VPN) in single domains have been addressed[7], almost nothing related to interdomain O-VPNs has been proposed. Thearchitecture presented in this article extends the ideas discussed in the scope ofsingle domain O-VPNs to interdomain O-VPNs.

The main idea behind our proposal is to facilitate the interaction betweenclient networks (e.g., IP/MPLS networks) and the optical network provider aswell as between optical network providers. By adopting the Extensible MarkupLanguage (XML) to exchange data and the Web Services Description Language(WSDL) to describe the interfaces of the services, the integration of different ap-plications and the interaction between different administrative domains are easilyachieved without the need of following complex specifications. Each domain candefine its services and advertise their WSDL interfaces in a Web services registry.

5These connections can be established using any solution, for instance, GMPLS. The exposed serviceshide the technology used in the control plane inside each domain.


The proposed approach also addresses the support of a new kind of businessmodel, the Virtual Carriers (VC). VCs can be seen as virtual intermediarycarriers (carrier’s carrier) that offer specialized services to customers at a lowinvestment. This approach allows carriers to share an optical network intoVC-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 opticalwavelength services market—facilitating the selling, buying and management ofwavelengths—and will most likely act as a catalyst for market opportunities.

We have implemented and tested a prototype of a service-oriented archi-tecture aiming at evaluating the approach in terms of feasibility of using Webservices 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 serviceprovisioning. Section 6 discusses the interdomain O-VPN service. Section 7presents the implementation details and the evaluation of a prototype developedaccording to the proposed architecture. Finally, Section 8 concludes the article.

2. RELATED WORK

This section is dedicated to compare the architecture proposed in this articlewith other related proposals addressing Web services in the management of opticalnetworks and interdomain service provisioning.

2.1. Web Services in the Management of Optical Networks

One of the early architectures applying Web services to the management ofoptical networks is presented in reference [8]. The work considers that users canlease and manage their own resources (lightpaths). By means of a managementsystem users can concatenate, partition, advertise/lease, and establish end-to-endlightpaths. Although the approach is very promising, it does not consider the con-straints imposed by each domain since the establishment of end-to-end lightpathsdoes 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 ofeach domain are enforced. The authors showed a Web services-based architec-ture to establish end-to-end lightpaths considering policy utilization in admissionand resource reservation control. Our approach considers some aspects of bothworks in the sense that we are also using Web services. However, we are takinginto account the provisioning of interdomain services via composition of services


and negotiation between domains. Another difference is that in our approach thecontrol and management of the lightpaths are not given to the user. The providerentity has the control of the resources.

The work presented in reference [10] discusses a customer-oriented GMPLSservice. The focus is to provide a management architecture for resilience differen-tiation based on the Telecommunication Management Network (TMN) referencemodel. The work does not consider multidomain management.

2.2. 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 ser-vices. One reason is the lack of business models that address interdomain billing,resource allocation, and Service Level Agreements (SLAs). The MESCAL ap-proach [11] presents an architecture to support interdomain QoS. Although theproject 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 becomingstandardized. In references [12, 13], the authors discuss how to support inter-provider IP/MPLS services. At the same time, the IETF Common Control andMeasurement Plane (CCAMP) charter is defining a framework for establishingand controlling MPLS and GMPLS LSPs in multidomain networks [14]. CCAMPtakes into account the Path Computation Element (PCE) [13] architecture as theblack box to advertise and compute interdomain paths. The PCE working groupis in charge of defining the architecture for the computation of paths for MPLSand GMPLS Label Switch Paths (LSPs). However, for the time being, there aremany points to be discussed and standardized such as the selection of the best in-terdomain path, the communication protocol between PCEs and, again, how BGPwill support QoS information. Reference [15] presents the concept of L1VPN.Nevertheless, the authors do not consider the provisioning of L1VPN service inmultidomain scenarios.

The works referred above do not consider the idea of having virtual topologiesbeing advertised among optical domains. Recently, such an approach has beengaining attention [16, 17]. Reference [16] shortly introduces the mechanisms forresource provisioning with virtual network services and reference [17] presentssome schemes for GMPLS Virtual Private Networks (GVPN). The GVPN service[18] describes VPN services that rely on BGP for VPN auto-discovery and onGMPLS for signaling. We have gathered the main concepts related to virtualtopologies, mainly those related to the abstraction of the physical details, in orderto test their feasibility and identify the challenges they impose. In our point ofview, the virtual topology approach outlines novel models on how the interactionbetween domains can be accomplished.


3. ISSUES ON INTERDOMAIN SERVICE PROVISIONING

The proposed architecture for interdomain service provisioning is in line withthe CANARIE roadmap [19] where the network is abstracted as a set of services.Such abstraction offers more functionality and flexibility for Internet ServiceProviders (ISPs). Routing protocols like OSPF (Open Shortest Path First) andBGP can be exposed as services. Services can be built from scratch or from legacysystems by using wrappers [20]. WSDL maps the functionalities of each serviceinto an interface that can be freely defined on a per-provider basis. This approachdoes not need to follow the tight and long-term process of standardization. Servicesare 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 completeredesign of the Internet might be necessary. As an alternative, the authors considerthat a number of ideas that already exist can be put together to solve the currentbottlenecks. We support this alternative in the sense that, by using current solutionssuch as Web services, it is possible to provide more complex and sophisticatedservices over the existing network infrastructure.

We also believe that the network can no longer be seen as a simple physicalinfrastructure, but as a seamless part of an entire distributed application [19]. Sincethe solutions that lie on the extension of BGP to offer QoS have not evolved, wefocus on virtual topologies for supporting interdomain QoS. By advertising virtualtopologies, each domain will have a full graph of the network and then can applypath computation algorithms to find an optimal path for a given source/destinationinterdomain pair. At the same time, this solution can still take into account BGPpolicies in order to satisfy peering contracts of each domain.

As mentioned before, the way lightpaths are established within each opticaldomain is a local decision. A domain can use a specific protocol (e.g., GMPLS) andfollow local policies to create and remove connections. The architecture is seenas a set of primitive and composed services. It is an alternative for GMPLS witha key difference: the establishment of e2e services between domains is performedby Web services, not by GMPLS signaling. This approach frees the providers fromwaiting for standardization, since the GMPLS specification for protocol extensionsto enable cross-domain reachability and TE advertisements has recently becomean 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 partof the same condominium obtain the virtual topologies of other domains. These


condominiums of domains could define business rules in an attempt to create newrelationships that make the interactions more customer-oriented. Giving morepower of decision for customers will foster competition among ISPs imposing adifferent economic discipline and offering better services at lower prices. It is aconsensus that monopoly is not consumer-driven but provider-driven. If end-userscan choose the domain route observing prices and the quality of the service, ISPswill have to face a competitive pressure to drive the deployment of good and newservices in order to attract and maintain clients.

4. IDENTIFICATION OF SERVICES FOR THEPROPOSED ARCHITECTURE

Although there exist several technologies for distributed computing such asCORBA (Common Object Request Broker Architecture), DCOM (DistributedComponent Object Model), and Java RMI (Remote Method Invocation), thesetechnologies adopt a tightly coupled synchronous communication model (re-quest/response) and show low level of interoperability. On the other hand, byusing XML standards and Internet protocols—such as HTTP (Hypertext TransferProtocol), FTP (File Transfer Protocol), and SMTP (Simple Message TransferProtocol)—Web services offer a loosely coupled asynchronous communicationmodel with high degree of interoperability. Figure 1(a) shows the SOA’s find-bind-execute paradigm in which providers register their services in a public orprivate registry and consumers query this registry to find services that attendcertain criteria. After obtaining the address of the services, consumers can bindand invoke the services.

Fig. 1. (a) SOA paradigm, (b) Services composition.


The strategy used to define the architecture described in this article consistsin the identification of primitive services that are necessary to support other moresophisticated services as shown in Fig. 1(b). Services A and B are primitive,bottom-level services. Service C is constructed by composing/aggregating the twoprimitive services. Since a composed service is itself a service, this mechanism canbe recursively applied to create other composed services. We believe that servicecomposition is the key towards new ways of designing, deploying, and managingnetwork services [20].

The services defined in the sequence represent the tasks that are necessaryto support interdomain interactions in order to establish e2e connections and O-VPNs. To some extent, such services incorporate the functionalities provided bythe GMPLS signaling and routing protocols. The advertising service (AS) is aprimitive network service responsible for advertising the virtual topology of eachdomain to other domains (routing function). The second primitive network serviceis the e2e interdomain negotiation service (E2ENS). It is responsible for perform-ing the negotiation among domains in order to establish e2e interdomain con-nections (signaling function). The e2e interdomain connection service (E2ECS)offers an interface from which clients request interdomain connections. The in-terdomain connection service is a composed network service since it depends onE2ENS to perform its tasks. Finally, two services were defined to support theinterdomain O-VPN service: The trading service (TS) responsible for reservingresources between the domains and the O-VPN service (O-VPNS) responsiblefor activating/deactivating and monitoring the O-VPN on a per-VPN basis. Thesetwo services are constructed by composing the previously defined services, for in-stance, TS uses E2ENS to reserve resources for the O-VPNs. A service responsiblefor finding interdomain routes (routing function) was also defined. Such service isthe path computation element (PCE) service and follows the specifications beingdefined by the IETF [13] for this element.

The architecture also comprises internal modules to manage external re-quests and enforce local policies. These modules together with the Web servicesmodules gather all the necessary functions to provide intra [22] and interdomainconnections.

The next section details the proposed architecture and how it provides e2einterdomain services.

5. THE SOA-BASED ARCHITECTURE FOR INTERDOMAINSERVICE PROVISIONING

In this section we detail the proposed architecture presenting its componentsand their interactions. The management plane of the architecture is divided intotwo logical parts (see Fig. 2(a)). The first part, or service layer, groups the Webservices that are responsible for offering to external entities (clients and other


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 howinternal tasks are implemented. This view is shown in Fig. 2(b). In this way, theoptical domain is seen as a set of primitive or composed Web services, each oneresponsible for providing specific functionalities.

The service layer is still divided into two parts: e2e services and legacyservices. E2e services are constructed from scratch and perform e2e iterdomaininteractions, while legacy services expose legacy systems such as routing andbilling systems as Web services.

The second logical part of the management plane is related to the internalmodules that are necessary to manage the control and admission of requests aswell as the application of local policies. The service layer and the internal modulesare detailed next.

5.1. 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 ser-vices, defines their behavior and publishes the interfaces in a registry so that theservices can be looked up and accessed by external entities. The Web services atthe service layer are described in the sequence.


5.1.1. Advertising Service – ASThe advertising service is responsible for advertising the virtual topology to

other domains. This virtual topology represents the lightpaths that cross the opticaldomain and is formed by Forwarding Adjacencies [14]. The details on how thelightpaths were set up are hidden from the clients. By adopting this approach, theinterdomain QoS-based provisioning of services is possible since each domainhas the virtual topology of all other domains and a simple Constraint ShortestPath First (CSPF) algorithm suffices to find the most appropriate route to attende2e constraints. The virtual topology to be announced is defined by the domainadministrator. A given domain may have different virtual topologies that areadvertised following specific rules such as the variation of the amount of trafficduring the day, services being offered, availability of resources, and presenceof failures or bottlenecks. For instance, the domain administrator may define a“standard” virtual topology to be used under normal conditions and other virtualtopologies that are advertised when specific conditions are detected. By using thisapproach, the domain administrator is able to define rules taking into accountbusiness strategies. The virtual topology can have an expiration time, forcing itscontinuous actualization. Clients are able to contract the AS by defining rules onwhen the virtual topology should be advertised and what level of information isto be advertised together with the virtual topology. Figure 3 shows two domainsand their virtual topologies being advertised to each other. The cost of each virtualedge is directional, i.e., there is no relation between the cost from node i to nodej with the cost from node j to node i. We show only one cost for the sake ofsimplicity. The interdomain path selection is computed by considering the virtualtopology advertised by the optical domains.

Fig. 3. Advertising virtual topologies.


Each virtual link represents a set of resources (lightpaths) that can be used toestablish e2e connections (e.g., to create an interdomain O-VPN). The amount oflightpaths under each virtual link is a domain local decision and depends on thephysical resources available at each optical domain. The cost of each virtual linkdoes not change as the lightpaths are consumed and/or released. This cost reflectsthe cost to use a single lightpath under that virtual link. When there are no morelightpaths under a given virtual link, new lightpaths can be created between thetwo nodes. How and when to create lightpaths is up to the local domain adminis-trator. The AS and the PCE together perform the routing function in the servicesplane.

5.1.2. End-to-End Negotiation Service – E2ENSThis service is responsible for negotiating e2e interdomain connections with

other domains. We adopted a two-phase-star-based model by which the head-enddomain6 negotiates with other domains asking for an available resource (lightpath).The first phase queries and reserves the resource. During the first phase, the trafficparameters are analyzed in each domain in order to verify if the connection canbe accepted. The second phase confirms the reservation in the case where allthe domains involved in the negotiation have the required resource. If one of thedomains does not have the required resource, the reservation needs to be released.Currently we are using the bandwidth, level of protection, and type of traffic7

as the QoS traffic parameters to be negotiated. Each domain is responsible forfinding a resource using local constraints. E2ENS does not take any decision onhow the selection of resources is conducted in each optical domain. The serviceonly carries the parameters passed by the client in the connection request. Thevirtual topology as explained above gives a general view about the routing betweendomains. The difference between the advertised virtual topology and the actualamount of resources in each optical domain is resolved by E2ENS. The negotiationservice 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 reservethe resources in each optical domain. E2ENS performs the signaling function inthe service plane.

5.1.3. End-to-End Connection Service – E2ECSThis 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 routeby invoking the PCE service. Note that to find the route, the PCE service depends

6The domain where the service request was received.7We handle two types of traffic: High Priority (HP) and Low Priority (LP). By having these two classesof services we are able to apply grooming policies as shown in [23, 24].


on the AS. It is through the virtual topology of each domain that the interdomainroute is computed. Finally, E2ECS invokes E2ENS to negotiate resources withthe involved domains. After performing these phases and considering that the e2econnection is established across the domains, the client is able to start sendingdata through the connection.

5.1.4. PCE ServiceThe PCE service is invoked by the internal modules of its domain. It is

responsible for finding an interdomain route so that an e2e interdomain connectioncan be established. Since the virtual topology of each domain was advertised bythe domain’s AS, finding an interdomain route is just a matter of applying arouting 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 morefunctionalities specifically for certain types of services such as O-VPN, and thismodularization allows to develop each module independently. Although the PCEservice is being currently invoked only by local modules, it can represent a givenregion or area. Other domains that do not have such service can use the PCEservice from a third-party provider. This is a typical SOA scenario where servicesare offered, queried and used.

The trading service (TS) and the O-VPN service shown in Fig. 2 are explainedin Section 6.

Finally, to have a complete SOA scenario it is necessary to provide a mecha-nism where services are published and discovered. The Registry is a module wherethe end point of each service is stored. The architecture does not use the UniversalDescription, Discovery and Integration (UDDI) repository [26] since UDDI hasmore functionalities than is needed in this work. Many current works have usedthe same simpler approach [9]. The registry acts as a private directory where theservice interfaces are registered and a mechanism for querying such services isprovided.

Figure 4 shows how the architecture performs service-oriented computing.The domain publishes its services in the registry through a Web-based inter-face and sets information about the service (service name, service description,interface endpoint, and service endpoint) (step 1). A given user queries the avail-able services in the Registry database (step 2) and retrieves WSDL interface andendpoint of the service that best matches the query. Since a WSDL interface is self-describing, it is possible to generate in run time the infrastructure necessary to in-voke the service (step 3). Finally, the client application invokes the service througha client application using SOAP (Simple Object Access Protocol) over HTTP(step 4).


Fig. 4. SOA-based architecture scenario.

5.2. Internal Modules

The internal modules perform local domain tasks to support the provisioningof services. The admission control (AC) module receives connection requestsand verifies pre-defined SLAs. These SLAs are defined in a customer-providercontract and specify what type of connection or service a given client can request.The policy manager (PM) module is responsible for applying the policies definedby the domain. Policies for grooming and fault management were defined [23,24]. The resource manager (RM) module manages all the information related tothe usage of the virtual topology and optical resources. The fault manager (FM)module receives link failure events generated by the optical network equipmentsand prepare the lightpaths contained in the failed fiber. In this work we are onlyconsidering fiber failures although there are other types of failures in opticalnetworks such as lightpath failures and optical device failures. The lightpathscontained 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 thatin its turn applies the defined policies for failures treatment [23]. Finally, themembership manager (MM) module is responsible for the management of themembership information of each O-VPN.


Fig. 5. Provisioning of an e2e interdomain connection.

Figure 5 depicts how the internal modules interact to each other to establish ane2e interdomain connection. During step 1, the client queries the registry lookingfor the e2e interdomain connection service. The end point with the location of theservice is returned to the client. After having obtained the interface and endpointof the service, clients are able to invoke this service. The invocation should includeall the necessary traffic parameters required by the client (step 2). E2ECS receivesthe request and forwards it to the admission control (step 3) module. AC validatesthe request and asks PCE for a route (step 4). Afterwards, a resource must bereserved in the local domain (step 5). Policies for admitting the new connectionare applied in step 6. Steps 7 and 8 perform the e2e interdomain negotiation usingthe e2e interdomain negotiation service. For sake of simplicity, step 8 representsboth 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, thePCE takes into account the whole topology formed by each optical domain virtualtopology. This route represents the shortest path with the smallest cost. How-ever, such route does not follow BGP routing neither peering contracts betweendomains. Then, after computing the e2e multidomain route based on the virtualtopology, the legacy services (e.g., BGP and peering contracts) should be accessedin order to verify if peering policies are respected. If the peering contracts acceptthe route calculated by the PCE service, then such route will be used to establishthe e2e interdomain connection. If not accepted, then the route without QoS givenby BGP should be used. Furthermore, final agreements could be done through thee2e interdomain negotiation service (E2ENS).

The negotiation between domains is performed in parallel. The head-endE2ENS 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 con-nection. E2ENS of each domain returns back confirming or denying the request.


Currently, the negotiation protocol does not support counter-proposals by thedownstream domains. If the invoked domain does not have the resource requiredduring the reservation phase, the e2e connection will not be accepted. However,another e2e interdomain route could be found and negotiated. The number ofnegotiation attempts can be defined by the client.

Next section discusses the O-VPN service and how this service is providedbetween different administrative domains.

6. THE O-VPN SERVICE

This section shows how composition of services facilitates the creation ofnovel network services. We do not intend to discuss O-VPN in details, but presentsome key concepts to better understand the evaluated scenario. More informationabout the O-VPN service can be obtained in the cited references.

6.1. 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 theprovider. Provider Edge (PE) devices are provider nodes that are connected to atleast one CE. Provider (P) devices are core provider nodes that are not connectedto customer nodes.

There are two resource allocation models for L1VPN. In the shared model, thenetwork resources are used by multiple VPNs in a time-sharing manner. In other

Fig. 6. Optical VPN Service A and B.


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 andthese resources can not be used by another VPN. The L1VPN functional modelis presented in reference [7]. It includes functions for membership informationmaintenance, route computation and route information maintenance, connectioncontrol, and service management. Only functionalities related to membershipinformation maintenance are specific for L1VPN. The other three functions arecommon to single connections.

There are three types of architectures for L1VPN service provisioning [27]. Inthe centralized architecture there are no distributed routing or signaling functions.In the distributed architecture, L1VPN service functions make use of distributedsignaling and routing within the provider network. PE and CE communicatethrough a common control plane. There is also a hybrid architecture in whichsome functions are centralized and other functions are distributed. In this case,specific VPN functions are centralized and common functions such as connectionprovisioning within the domain are distributed using, for instance, GMPLS.

Our architecture supports both the dedicated and shared models and is basedon the management service model by which customers access the provider man-agement system to request connections. Furthermore, the distribution of the func-tionalities follows the hybrid model where some tasks are performed by the controlplane (distributed) and other tasks are performed by the management system (cen-tralized). Connection provisioning within the optical domain is performed by thecontrol plane while membership maintenance and connection provisioning be-tween domains are performed by the management system. This solution is in linewith the ideas presented in reference [7].

The physical details of the optical network are abstracted by using the virtualtopology concept, as explained in Section 5. The O-VPN is established over suchvirtual topology by reserving e2e connections between multiple interdomain CEports. Such approach applied to VPNs is very shortly commented in reference[28]. At the same time, the management service model is well indicated forinterdomain O-VPN service since it facilitates the negotiation of the e2e resourcesin each domain.

6.2. Interdomain O-VPN Establishment

To support interdomain O-VPN, two services were defined: The tradingservice (TS) and the O-VPN service itself (Fig. 2).

6.2.1. Trading Service – TSThis 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 canuse that resource. This service allows a customer to reserve the necessary resources


in order to guarantee that when the O-VPN is installed the reserved resources willbe available. When TS receives a request to reserve resources, it forwards suchrequest to the Admission Control module for validating the request. During thereservation phase, the customer sends information related to the establishment ofthe O-VPN (type of traffic, level of protection, etc.). The O-VPN CE ports tobe connected are also informed by the customer and the combination of ports isverified by the membership manager module.

6.2.2. O-VPN Service – O-VPNSThis 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 opticalresources.8 The O-VPNS allows each customer to get the O-VPN membershipinformation and monitor each O-VPN without interfering in O-VPNs establishedfor other customers. The amount of information that can be delivered to customersdepends on the type of agreements that are pre-established between clients andproviders.

The advertising service (AS) was firstly proposed for advertising virtualtopologies. By adding the O-VPN service to the architecture, AS became alsoresponsible for advertising the membership information of each O-VPN. Eachdomain defines the mapping between CE and PE ports for each O-VPN. Theidentification of a CE port is known as Customer Port Identifier (CPI) and itsequivalent in the provider side is known as Provider Port Identifier (PPI) [18].These mappings are statically configured in each optical domain (forming a PortInformation Table – PIT) and advertised to other domains that belong to theinterdomain O-VPN. Domains that do not have at least one port in the O-VPNwill not receive the membership information. Figure 7 shows an example of anO-VPN membership information being advertised to other domains.

The advertising service receives the PITs (from other domains) and forwardssuch tables to the membership manager (MM) in order to merge them with thelocal PIT. When a customer requests the establishment of an O-VPN, MM verifiesif the CE ports informed by the customer are valid. After the advertising phase,each optical domain will have the complete membership information about theinterdomain 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 establishmentof interdomain O-VPNs. Figure 8 shows how the modules interact to each otherto establish an interdomain O-VPN.

Observe that by using the idea of services composition, the establishmentof an interdomain O-VPN is performed by using the services already defined for

8Since the charging model depends on local decisions, we have not defined a billing module for ourarchitecture.


Fig. 7. Example of an O-VPN membership advertising.

Fig. 8. Establishing an interdomain O-VPN.


the establishment of single e2e connections. Basically, it was necessary to addonly one new step (membership verification) to provide the O-VPN service. Theremaining 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 amountof tasks that need to be processed during the activation phase can vary in eachdomain. Typical tasks include the crossconnection of the lightpaths of each e2econnection and the activation of the billing system. A given provider can use thereserved resources to carry low priority traffic until the owner of such resourcesdoes 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 ismasked from the clients and does not affect the reservation of resources.

The key point of composition of services is well illustrated in the O-VPNservice example. To provide such service, it is necessary to have other servicesresponsible for advertising the topology of each domain, compute interdomainroutes, and negotiating single connections with other domains. Since these areprimitive e2e interdomain services, the provisioning of more complex and sophis-ticated services (such as the O-VPN service) is just a matter of using/composingthe previously defined ones. In terms of designing and implementation, such ap-proach 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 intranetusing five Pentium 4 3 GHz processors (with Hyper Threading enabled) with 1 GBRAM and running Linux Slackware. All the machines have 10/100 Mbs networkinterface cards. The modules were developed in Java and public domain toolswere used to facilitate the implementation. All the Web services are created usingthe Apache AXIS 1.2 suite. The internal modules are remote objects developedusing the Java RMI technology. Web services are accessed through XML-basedSOAP messages over HTTP. The management information is mostly representedin XML and manipulated with native Java XML tools.

The virtual topology and the O-VPNs employed in the tests are shown inFig. 9. The domains are named from A to E. The scenario considered here isthe one with IP/MPLS clients and Wavelength Division Multiplexing (WDM)optical providers. We defined three O-VPNs that are spread out over five opticaldomains. VPN 1 has 6 ports, VPN 2 has 4 ports, and VPN 3 has 5 ports. Each localMM keeps the mapping between CPI/PPI that composes the local PIT of eachO-VPN.


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 PCEservice uses the CSPF algorithm to find the shortest path taking into account thesmallest cost across multiple domains. The abstract cost gathers the QoS of thevirtual 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, duringthe negotiation, each domain should inform the values for each parameter to benegotiated as well as the meaning the abstract cost over each virtual link. Theseparameters are the ones supplied by the client and validated by the AC moduleas explained in Section 5.2. The bandwidth, the type of traffic, and the level ofprotection are the parameters that are negotiated between domains.

Specifically for this work, a high number of lightpaths was defined for eachvirtual 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. Wehave also assumed that the border optical devices are OEO (optical-to-electrical-to-optical) and, as such, there is no need to advertise details about the wavelengthsof the lightpaths since OEO devices are able to electronically crossconnect theoptical signal from any wavelength that enters the optical device to any wavelengththat leaves the optical device (full conversion of wavelengths).

7.2. Evaluation

In order to evaluate the prototype, we have conducted some performanceevaluation in order to assess the impact of using Web services to provide and


Table I. Time Consumption for Each SOAP Interaction and the Size of Each SOAP Message

InteractionTime

consumption (ms) SOAP message size (bytes)

Client to E2ECS 10 1156 (req) + 650 (resp) Total = 1806AC to PCE 9, 5 720 (req) + 593 (resp) Total = 1313AC to E2ENS 9, 4 1486 (req) + 581 (resp) Total = 2067E2ENS to E2ENS (reservation phase) 13, 95 1156 (req) + 564 (resp) Total = 1720E2ENS to E2ENS (commit phase) 10 520 (req) + 557 (resp) Total = 1077Total time/size for SOAP

coomunication52, 85 7983

manage e2e interdomain connections and interdomain O-VPNs. In terms of band-width consumption, it is important to estimate the overhead due to the introductionof XML-based SOAP messages. The size of SOAP messages affect not only thebandwidth consumption but also the time necessary for message processing (mar-shaling, unmarshaling, and parsing). SOAP messages are longer when comparedto common network protocols due to the textual nature of the messages and theamount of meta-information transferred with the message contents (e.g., headers,data types, and security attachments). Therefore, the required bandwidth and pro-cessing time of a service depend significantly of the complexity of the serviceinterfaces. Proposals for shortening SOAP messages (e.g., message compression)were not used since they can compromise interoperability. In this article we showsome performance figures taking into account the time to communicate betweenmodules and the size of each SOAP message involved to establish the proposede2e interdomain services.

We firstly focus on the establishment of single e2e connections. Afterwards,the establishment of interdomain O-VPNs is evaluated.

7.2.1. Evaluation of Interdomain E2E Connection EstablishmentThe total time to establish an e2e interdomain connection depends on the

time of each interaction between every pair of modules. Table I shows such timesconsidering only SOAP messages. This average size of each message is shownin the last column. The average was obtained after running 1000 executions. It isdepicted the size for the request and for the response. Notice that this size is amean estimate and can vary depending on the value of each element/attribute.

The amount of SOAP messages to establish a single e2e interdomain con-nection can be drawn as follows: 2 + 2∗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

9We are not considering the client to E2ECS message since in some cases such request does not comefrom a Web service client but from a simple HTTP request without the SOAP payload.


part comes from the negotiation protocol where it is necessary one message forthe reservation phase and another one for the commit phase, and N is the num-ber of domains involved in the neotiation. If the response for each request iscounted, then we have: 4 + 4∗N SOAP messages. This is valid for the success-ful case, i.e., when all the downstream domains have the resource available. Ifthe reservation fails (in this context, fail means not having enough resources),the number of SOAP messages is lower since the rollback is only propagated tothe 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 faileddomains).

Figure 10(a) shows the approximated time to establish an e2e connectionhaving only one requesting domain (one single domain requesting for connections)and Fig. 10(b) illustrates the scalability of the prototype to attend many requestingdomains. In the first case, the average time was calculated over a 40000 requestsscenario. In the second case, the average time was calculated over a 10000 requestsscenario. Each request is immediately sent after receiving the answer from theprevious one. Figure 10 gives an idea of variation of the average time. Each pointin the graph shown in this figure is computed as the average of 500 subsequentrequests.

The numbers in Fig. 10(a) depict that as the complexity of the scenarioincreases (more domains added), the time to establish an e2e connection variesslightly, proving the efficiency of using a star-based negotiation protocol. Whenthe scenario has 3 domains, the average time to establish an e2e connection isabout 81 ms. Increasing to 5 domains this time is around 105 ms. This increasingin time is due to the longer length of the e2e route as more domains were addedand does not belong to the e2e negotiation. The length of the route has an impacton the final time due to the amount of resources that need to be reserved along theroute. 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 theaverage. This effect is due to the loading of Java classes when they were accessedfor the first time. Subsequent accesses to these classes will found them alreadyloaded in memory.

Figure 10(b) shows assess the impact in a specific domain when other domainsare making requests at the same time. For this scenario, we analyzed the domainA with 5 domains in the tests. The numbers show that when only domain A ismaking 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. With5 domains requesting for connections, the time in the domain A is approximately135 ms. Considering that many domains are making requests, this increasing intime is almost irrelevant. If we analyze the mean time from 1 to 5 domains for allthe scenarios, there is an increase of only 30 ms.


Fig. 10. Average time to establish an e2e connection. (a) one single requesting domain, (b) manyrequesting domains.

By drawing some final comments about the evaluation for single e2e connec-tions, we verified that the average time to establish an e2e interdomain connectionin optical networks using Web services varies from ≈ 80 ms to ≈ 105 ms with onesingle requesting domain and scenarios with three to five domains. In scenarioswith more than one requesting domain (1 to 5), the time increases from ≈ 105 msto ≈ 135 ms for the number of domains fixed in five. The amount of bytes tocommunicate all the SOAP messages that are necessary to establish a single e2econnection is approximately 8 Kbytes (7893 bytes, see Table I) and the time to


exchange this amount of data is approximately 52, 85 ms. This time is due mostlyto the Web services engine that is responsible for parsing the XML-based messageSOAP, creating the HTTP message, sending it to the remote Web service, andperform the reverse operations on the replied message.

Although the numbers shown above refer to account optical network domains,they can be an estimate for other types of transport network technologies that arealso based on virtual topologies.

7.2.2. Evaluation of Interdomain O-VPNThe evaluation of the interdomain O-VPNs establishment becomes simple af-

ter analyzing the establishment of single e2e connections. Since the establishmentof an O-VPN is only a matter of establishing a set of e2e connections betweendomains, by solving the latter we partially solve the O-VPN scenario. The averagetime was calculated after establishing 1000 O-VPNs. Each point in the graphsshown in Fig. 11(a) and 11(b) were computed as an average of 50 O-VPNs estab-lishment times. Figure 11(a) shows the average time to establish an interdomainO-VPN having one requesting domain.

The time slightly increases when more CE ports need to be connected. Theaverage time to establish an O-VPN in the scenario with four ports is about 330 msand with six ports it is about 800 ms. This result was expected since the more theamount of ports to be connected the more the amount of connections needed. Then,an O-VPN with 4 ports needs 6 connections and an O-VPN with 6 ports needs15 connections considering that every port will be connected with the n − 1 otherports (full meshed). In this case, the maximum number of connections to establisha given O-VPN can be defined by the following expression: i(i − 1)/2, where iis the number of ports to be connected within the O-VPN. Then, the amount ofSOAP messages that is necessary to establish an interdomain O-VPN is given bythe expression: i(i − 1)/2∗(4 + 4∗N ). Observe that the time to establish a singlee2e connection for the O-VPN scenario is smaller than the time for the scenarioshown in Fig. 10(a). As an example, in the scenario with 4 ports that correspondsto the scenario with 3 domains in Fig. 10(a), each connection takes 55 ms to beestablished. This is verified because the average length of the e2e interdomainroute in the O-VPN scenario is smaller than the average length of the route in thesingle connection scenario.

Figure 11(b) shows the behavior of the prototype when more than one cus-tomer is requesting the establishment of interdomain O-VPNs at the same time.All the O-VPNs have 4 ports and the analysis of this graph follows the sameanalysis presented for Fig. 10(b).

Increasing the amount of requesting customers almost does not affect thetime to establish the O-VPNs. The time slightly increases from the scenariowith one customer (320 ms) to the scenario with three customers (340 ms). Thisscenario was stressed and represents a very dynamic and concurrent situation. In


Fig. 11. (a) Average time to establish an O-VPN (one requesting domain), (b) More than one requestingdomain.

real scenarios, it is expected that the requests for interdomain O-VPNs will bedynamic but submitted at a low rate.

7.3. Final Discussion

The times obtained in the tests represent a real invocation of a client requir-ing an e2e interdomain connection and an interdomain O-VPN. The number of


domains slightly impacts the size of the SOAP message. The length of the route isthe main factor to increase the size and the time to establish a connection. Basedon previous studies [30], the mean e2e communication in the Internet traversesbetween 3 and 4 domains. Then, the amount of domains used in our tests is in linewith real scenarios.

The size of the SOAP message in real scenarios can have small variationsdepending on the amount of data that needs to be exchanged. However, the pa-rameters used in our tests are mostly enough to represent the QoS requirements tobe negotiated among optical domains. As stated before, we did not use any typeof XML compression. Then, the results obtained in this work are those expectedto be obtained in real scenarios.

In this work we are also interested in investigating the performance of thestar-based negotiation protocol. We could verify that as the number of domainsincreases, the time to negotiate with more domains basically keeps the same. Also,we realized that the virtual topology approach is very useful to provide interdo-main services. Further studies are need in order to better analyze the advantagesof advertising virtual topologies. The subject of virtual topologies started to beinvestigated by the research community only recently [16, 18]. One of the pointsto be addressed is the impact in terms of bandwidth consumption and time toadvertise the virtual topologies.

We also have been working on the idea that every network element (routersand switches) offers control and management functions through Web services [20].In this case, the connection establishment within the domain is also performedvia Web services instead of using a signaling protocol such as RSVP-TE. Theintegration of this intradomain solution with the interdomain solution presented inthis article is being underway and will offer a more comprehensive Web service-based framework for provisioning and management of intra and inter domainoptical services. Although in reference [20] the authors used an orchestration andchoreography engine to coordinate the services, in this proposal the coordinationdoes not employ such an engine. The evaluation of orchestration engines based onBPEL (Business Process Execution Language) [31] is left for further studies.

8. CONCLUSIONS

We have presented a new approach for interdomain provisioning of servicesin optical networks. We claim that the GMPLS-based interdomain control planesuffers from (as many other specifications) long processes of standardizations andenforces a tight control plane between different administrative domains. Instead,the approach presented in this article focuses on the idea of having a service layerto support the interdomain provisioning of services that results in a loose couplingapproach for interdomain interactions. Web services speeds up the interactionsbetween ISPs and does not require upgrade of the network infrastructure. By


using the readily available products that implement the current Web servicesspecifications [31], ISPs can support interdomain provisioning of services quicklyand in a cost-effective way. At the same time, the establishment of connectionsbetween domains with QoS by using virtual topologies without declining BGPpolicies and peering contracts proved to be feasible. The idea of composing simpleservices to form more sophisticated ones was demonstrated in the optical networkcontext and the same approach can be used in other types of connection-orientednetworks as well.

The proposed architecture has a service layer that abstracts the underlyingfunctionalities and hides the transport-related details of the network provider. Oursolution adopts the idea of having a virtual topology over the optical physicaltopology. Since virtual topologies represent only the ingress and egress forwardadjacencies of the domains, the confidentiality the domains is preserved. Thisapproach allows the establishment of e2e interdomain QoS-based connectionsbetween multiple domains. Moreover, the e2e interdomain negotiation serviceoffers a mechanism by which the domains might apply admission control on eachrequest.

The evaluation of the prototype showed that the bandwidth consumptiondemanded by the service layer is very low. The number of messages to execute thee2e negotiation protocol is minimal and, most importantly, the time to establish e2einterdomain connections and interdomain O-VPNs in our prototype is fairly low.Our intention in this work was not to evaluate all the possible scenarios that existin interdomain environments neither to collect all the performance measurementsfor each case. Our goal was to give carriers some figures related to the behaviorof Web services to provide e2e interdomain services.

By using the Web services technology to provide the access to the man-agement system and to integrate the interactions among domains, new ways ofdeveloping Web-based management solutions can be envisioned. Not only is theresearch community committed to SOA and XML-based standards, but also manyconsortiums and companies are driving the development for the convergence andadoption of XML-based integration. The architecture proposed in this article is inline with this trend.

ACKNOWLEDGMENTS

The authors would like to thank CNPq, CAPES, FAPESP and Ericsson Brazilfor their support.

REFERENCES

1. L. Xiao, J. Wang, K.-S. Lui, and K. Nahrstedt, Advertising Interdomain Qos Routing, IEEEJournal on Selected Areas in Communications, Vol. 22, No. 10, pp. 1949–1964, December 2004.


2. C. Cavazzoni, V. Barosco, A. Alessandro, A. Manzalini, S. Milani, G. Ricucci, R. Morro, R.Geerdsen, U. Hartmer, G. Lehr, U. Pauluhn, S. Wevering, D. Pendarakis, N. Wauters, R. Gigantino,J. P. Vasseur, K. Shimano, G. Monari, and A. Salvioni, The IP/MPLS Over ASON/GMPLSTest Bed of the IST Project LION, IEEE Journal of Lightwave Technology, Vol. 21, No. 11,pp. 2791–2803, November 2003.

3. R. Munoz, C. Pinart, and G. Junyent, A GMPLS optical control plane for IP/Gigabit Ethernetover dynamic DWDM networks. 7th IFIP Working Conference on Optical Network Design andModeling (ONMD), February 2003.

4. OIF Intra-Carrier E-NNI 01.0 Signaling Specification.5. M. J. Francisco, et al., End-to-End Signaling and Routing for Optical IP Networks. IEEE Interna-

tional Conference on Communications – ICC ’02, pp. 2870–2875, 2002.6. M. P. Papazoglou and D. Georgakopoulos, Service Oriented Computing, Communications of the

ACM, Vol. 46, No. 10, pp. 25–28, October 2003.7. T. Takeda, I. Inoue, R. Aubin, and M. Carugi, Layer 1 Virtual Private Networks: Service Concepts,

Architecture Requirements, and Related Advances in Standardization. Communications Magazine,IEEE, Vol. 42, No. 6, pp. 132–138, 2004.

8. R. Boutaba, W. Golab, Y. Iraqui, and B. St. Arnaud, Lightapths on Demand: A Web-Services-Based Management System. IEEE Communications Magazine, Vol. 42, No. 7, pp. 2–9,July 2004.

9. D. L. Truong, O. Cherkaoui, H. Elbiaze, N. Rico, and M. Aboulhamid, A Policy-based approachfor user controlled Lightpath Provisioning. IFIP/IEEE NOMS, pp. 859–872, April 2004.

10. M. Brunner, G. Nunzi, T. Dietz, and I. Kazuhiko, Customer-Oriented GMPLS Service Man-agement and Resilience Differentation. eTransactions on Network and Service Management,pp. 2–12, Fourth Quarter 2004.

11. M. P. Howarth, P. Flegkas, G. Pavlou, N. Wang, P. Trimintzios, D. Griffin, J. Griem, M.Boucadair, P. Morand, A. Asgari, and P. Georgatsos, Provisioning for Interdomain Quality ofService: the MESCAL Approach. IEEE Communications Magazine, Vol. 43, No. 6, pp. 129–137,June 2005.

12. L. Fang, N. Bita, J. Roux, and J. Miles, Interprovider IP-MPLS Services: Requirements, Imple-mentations, and Challenges. IEEE Communications Magazine, Vol. 43, No. 6, pp. 119–128, June2005.

13. A. Farrel, J.-F. Vasseur, and J. Ash, Path Computation Element (PCE)-based Architecture. IETFRFC 4655, August 2006.

14. A. Farrel, J.-F. Vasseur, and A. Ayyangar, A Framework for Inter-Domain MPLS Traffic Engi-neering. IETF RFC 4726, November 2006.

15. T. Takeda, D. Brungard, D. Papadimitriou, and H. Ould-Brahim, Layer 1 Virtual Private Networks:Driving Forces and Realization by GMPLS. IEEE Communications Magazine, Vol. 43, No. 7,pp. 60–67, 2005.

16. S. Tomic, Issues of Resource Management in Two-Layer GMPLS Networks with Virtual NetworkService. IEEE Globecom, pp. 1803–1807, 2004.

17. R. S. Ravindran, P. Ashwood-Smith, H. Zhang, and G.-Q. Wang, Multiple Abstraction Schemesfor Generalized Virtual Private Switched Networks. IEEE Canadian Conference on Electrical andComputer Engineering – CCECE, pp. 0519–0522, May 2004.

18. H. Ould-Brahim and Y. Rekhter, GVPN Services: Generalized VPN Services using BGP andGMPLS Toolkit. IETF draft, work in progress, February 2005.

19. B. Arnaud, UCLP Roadmap: Web Services Workflow for Connecting Research Instruments andSensors to Networks. Draft, December 2004.

20. V. de Souza and E. Cardozo, A Service Oriented Architecture for Deploying and Managing Net-work Services. Proceedings of the 3rd International Conference on Service Oriented Computing(ICSOC ’05), LNCS-Springer-Verlag, Vol. 3826, pp. 465–477, December 2005.


21. D. Clark, C. Partridge, R. T. Braden, B. Davie, S. Floyd, V. Jacobson, D. Katabi, G. Minshall,K. K. Ramakrishnan, T. Roscoe, I. Stoica, J. Wroclawski, and L. Zhang, Making the world (ofcommunications) a different place. Report of a working session of the End-to-End Research Group– Internet Research Task Force, January 2005.

22. F. L. Verdi, R. Duarte, F. de Lacerda, E. Madeira, E. Cardozo, and M. Magalhaes, Web Services-based Provisioning of Connections in GMPLS Optical Networks. The Brazilian Symposium onComputer Networks (SBRC). Fortaleza, Brazil, May 2005.

23. C. Carvalho, F. L. Verdi, E. Madeira, and M. Magalhaes, Policy-based Fault Management forIntegrating IP over Optical Networks. The 5th IEEE International Workshop on IP Operations &Management (IPOM ’05), LNCS-Springer-Verlag, Vol. 3751, pp. 88–97, October 2005.

24. F. L. Verdi, C. Carvalho, E. Madeira, and M. Magalhaes, Policy-based Grooming in Optical Net-works. 4th IEEE Latin American Network Operations and Management Symposium (LANOMS),pp. 125–136, August 2005.

25. F. Ricciato, U. Monaco, and D. Ali, Distributed Schemes for Diverse Path Computation in Mul-tidomain MPLS Networks, IEEE Communications Magazine, Vol. 43, No. 6, pp. 38–146, June2005.

26. OASIS UDDI Specification: http://www.uddi.org/.27. T. Takeda, H. Kojima, and I. Inoue, Layer 1 VPN architecture and its evaluation, 5th International

Symposium on Multi-Dimensional Mobile Communications, Vol. 2, pp. 612–616, September 2004.28. T. Takeda, H. Kojima, and I. Inoue, Optical VPN architecture and mechanisms. The 9th Asia-Pacific

Conference, (APCC), pp. 751–755, 2003.29. E. Gamma, Design Patterns – Elements of Reusable Object-Oriented Software. Addison-Wesley,

1995.30. J. Pujol, S. Schmid, L. Eggert, M. Brunner, and J. Quittek, Scalability Analysis of the TurfNet

Naming and Routing Architecture. First International ACM Workshop on Dynamic Interconnec-tion of Networks, pp. 28–32, September 2005.

31. OASIS Consortium: http://www.oasis-open.org/.

Fabio Luciano Verdi is currently a post-doc student at the Faculty of Electrical and ComputerEngineering (FEEC), State University of Campinas (UNICAMP), Brazil. He received his Masterdegree in Computer Science and Ph.D. degree in Electrical Engineering both from State Universityof Campinas (UNICAMP). His main interests include computer networks, mobility, routing, serviceoriented architectures, inter-domain services and next generation Internet Architectures.

Maurıcio Ferreira Magalhaes received the B.S. in Electrical Engineering from University ofBrasılia (UnB), Brasılia, Brazil, M.S. in Automation from School of Electrical Engineering, State Uni-versity of Campinas (UNICAMP), Campinas, Brazil and Dr. Engineer from Laboratoire d’Automatique(LAG/CNRS) and Institut National Polytechnique de Grenoble (INPG), Grenoble, France. Currentlyhe works as a Titular Professor at the School of Electrical and Computer Engineering, State Universityof Campinas (UNICAMP), Campinas, Brazil.

Eleri Cardozo received the B.S. degree from University of Sao Paulo, Brazil, the M.S. degreefrom Technological Institute of Aeronautics, Brazil, and the Ph.D. degree from Carnegie MellonUniversity, USA. Currently he is a Professor of Electrical and Computer Engineering at the School ofElectrical and Computer Engineering, State University of Campinas (UNICAMP), Brazil.

Edmundo R. M. Madeira is an Associate Professor at the Institute of Computing of StateUniversity of Campinas (UNICAMP), Brazil. He received both his Ph.D. in Electrical Engineeringand M.Sc. in Computer Science from State University of Campinas (UNICAMP), Brazil. His researchinterests include network management, optical netwoks and distributed systems. He has published over


100 papers in national and international conferences and journals. He has also supervised more than30 master and Ph.D. students.

Annikki Welin is a Senior Researcher in the Ericsson Research, (Ericsson AB) Broadband &Transport department. Her research interests are protocols and architectures. Presently she works withoptical networks, management plane and control plane interworking to automate fast provisioning.

a service oriented architecture-based approach for ...verdi/jnsmpublished.pdf ·...

Documents