c 2007)
Journal of Network and Systems Management (
DOI: 10.1007/s10922-007-9060-2
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 Welin3
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: Interdomain provisioning of services; SOA; Optical networks; Web
services.
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, 13083-970 Campinas, Brazil. E-mail: [email protected].
2 Institute of Computing (IC-UNICAMP), 13084-971 Campinas, Brazil.
3 Ericsson Research, Torshamnsgatan 23, 16480 Stockholm, Sweden.
4 To whom correspondence should be addressed. E-mail: [email protected].
C 2007 Springer Science+Business Media, LLC
1064-7570/07 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
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.
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.
2.1. 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
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.
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 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.
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
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.
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 OVPNs. 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
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.
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 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.
Verdi, Magalhães, Cardozo, Madeira, and Welin
5.1.1. 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.
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.
5.1.2. 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
domain6 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 traffic7
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.
5.1.3. 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].
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.
5.1.4. 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).
Provisioning of Interdomain Optical Network Services using SOA
Fig. 4. SOA-based architecture scenario.
5.2. 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.
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.
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.
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 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.
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.
6.2. 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).
6.2.1. 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
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.
6.2.2. 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.
Verdi, Magalhães, Cardozo, Madeira, and Welin
Fig. 7. Example of an O-VPN membership advertising.
Fig. 8. Establishing an interdomain O-VPN.
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.
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).
7.2. 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
Provisioning of Interdomain Optical Network Services using SOA
Table I. Time Consumption for Each SOAP Interaction and the Size of Each SOAP Message
Interaction
Client to E2ECS
AC to PCE
AC to E2ENS
E2ENS to E2ENS (reservation phase)
E2ENS to E2ENS (commit phase)
Total time/size for SOAP
coomunication
Time
consumption (ms)
SOAP message size (bytes)
10
9, 5
9, 4
13, 95
10
52, 85
1156 (req) + 650 (resp) Total = 1806
720 (req) + 593 (resp) Total = 1313
1486 (req) + 581 (resp) Total = 2067
1156 (req) + 564 (resp) Total = 1720
520 (req) + 557 (resp) Total = 1077
7983
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.
7.2.1. 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: 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
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.
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: 4 + 4∗ 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 40000 requests
scenario. In the second case, the average time was calculated over a 10000 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.
Provisioning of Interdomain Optical Network Services using SOA
Fig. 10. Average time to establish an e2e connection. (a) one single requesting domain, (b) many
requesting domains.
By drawing some final comments about the evaluation for single e2e connections, we verified that the average time to establish an e2e interdomain connection
in optical networks using Web services varies from ≈ 80 ms to ≈ 105 ms with one
single requesting domain and scenarios with three to five domains. In scenarios
with more than one requesting domain (1 to 5), the time increases from ≈ 105 ms
to ≈ 135 ms for the number of domains fixed in five. The amount of bytes to
communicate all the SOAP messages that are necessary to establish a single e2e
connection is approximately 8 Kbytes (7893 bytes, see Table I) and the time to
Verdi, Magalhães, Cardozo, Madeira, and Welin
exchange this amount of data is approximately 52, 85 ms. This time is due mostly
to the Web services engine that is responsible for parsing the XML-based message
SOAP, creating the HTTP message, sending it to the remote Web service, and
perform 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 are
also based on virtual topologies.
7.2.2. Evaluation of Interdomain O-VPN
The evaluation of the interdomain O-VPNs establishment becomes simple after analyzing the establishment of single e2e connections. Since the establishment
of an O-VPN is only a matter of establishing a set of e2e connections between
domains, by solving the latter we partially solve the O-VPN scenario. The average
time was calculated after establishing 1000 O-VPNs. Each point in the graphs
shown in Fig. 11(a) and 11(b) were computed as an average of 50 O-VPNs establishment times. Figure 11(a) shows the average time to establish an interdomain
O-VPN having one requesting domain.
The time slightly increases when more CE ports need to be connected. The
average time to establish an O-VPN in the scenario with four ports is about 330 ms
and with six ports it is about 800 ms. This result was expected since the more the
amount 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 needs
15 connections considering that every port will be connected with the n − 1 other
ports (full meshed). In this case, the maximum number of connections to establish
a given O-VPN can be defined by the following expression: i(i − 1)/2, where i
is the number of ports to be connected within the O-VPN. Then, the amount of
SOAP messages that is necessary to establish an interdomain O-VPN is given by
the expression: i(i − 1)/2∗ (4 + 4∗ N ). Observe that the time to establish a single
e2e connection for the O-VPN scenario is smaller than the time for the scenario
shown in Fig. 10(a). As an example, in the scenario with 4 ports that corresponds
to the scenario with 3 domains in Fig. 10(a), each connection takes 55 ms to be
established. This is verified because the average length of the e2e interdomain
route in the O-VPN scenario is smaller than the average length of the route in the
single connection scenario.
Figure 11(b) shows the behavior of the prototype when more than one customer 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 same
analysis presented for Fig. 10(b).
Increasing the amount of requesting customers almost does not affect the
time to establish the O-VPNs. The time slightly increases from the scenario
with one customer (320 ms) to the scenario with three customers (340 ms). This
scenario was stressed and represents a very dynamic and concurrent situation. In
Provisioning of Interdomain Optical Network Services using SOA
Fig. 11. (a) Average time to establish an O-VPN (one requesting domain), (b) More than one requesting
domain.
real scenarios, it is expected that the requests for interdomain O-VPNs will be
dynamic but submitted at a low rate.
7.3. Final Discussion
The times obtained in the tests represent a real invocation of a client requiring an e2e interdomain connection and an interdomain O-VPN. The number of
Verdi, Magalhães, Cardozo, Madeira, and Welin
domains slightly impacts the size of the SOAP message. The length of the route is
the main factor to increase the size and the time to establish a connection. Based
on previous studies [30], the mean e2e communication in the Internet traverses
between 3 and 4 domains. Then, the amount of domains used in our tests is in line
with real scenarios.
The size of the SOAP message in real scenarios can have small variations
depending on the amount of data that needs to be exchanged. However, the parameters used in our tests are mostly enough to represent the QoS requirements to
be negotiated among optical domains. As stated before, we did not use any type
of XML compression. Then, the results obtained in this work are those expected
to be obtained in real scenarios.
In this work we are also interested in investigating the performance of the
star-based negotiation protocol. We could verify that as the number of domains
increases, the time to negotiate with more domains basically keeps the same. Also,
we realized that the virtual topology approach is very useful to provide interdomain services. Further studies are need in order to better analyze the advantages
of advertising virtual topologies. The subject of virtual topologies started to be
investigated by the research community only recently [16, 18]. One of the points
to be addressed is the impact in terms of bandwidth consumption and time to
advertise the virtual topologies.
We also have been working on the idea that every network element (routers
and switches) offers control and management functions through Web services [20].
In this case, the connection establishment within the domain is also performed
via Web services instead of using a signaling protocol such as RSVP-TE. The
integration of this intradomain solution with the interdomain solution presented in
this article is being underway and will offer a more comprehensive Web servicebased framework for provisioning and management of intra and inter domain
optical services. Although in reference [20] the authors used an orchestration and
choreography engine to coordinate the services, in this proposal the coordination
does not employ such an engine. The evaluation of orchestration engines based on
BPEL (Business Process Execution Language) [31] is left for further studies.
8. CONCLUSIONS
We have presented a new approach for interdomain provisioning of services
in optical networks. We claim that the GMPLS-based interdomain control plane
suffers from (as many other specifications) long processes of standardizations and
enforces a tight control plane between different administrative domains. Instead,
the approach presented in this article focuses on the idea of having a service layer
to support the interdomain provisioning of services that results in a loose coupling
approach for interdomain interactions. Web services speeds up the interactions
between ISPs and does not require upgrade of the network infrastructure. By
Provisioning of Interdomain Optical Network Services using SOA
using the readily available products that implement the current Web services
specifications [31], ISPs can support interdomain provisioning of services quickly
and in a cost-effective way. At the same time, the establishment of connections
between domains with QoS by using virtual topologies without declining BGP
policies and peering contracts proved to be feasible. The idea of composing simple
services to form more sophisticated ones was demonstrated in the optical network
context and the same approach can be used in other types of connection-oriented
networks as well.
The proposed architecture has a service layer that abstracts the underlying
functionalities and hides the transport-related details of the network provider. Our
solution adopts the idea of having a virtual topology over the optical physical
topology. Since virtual topologies represent only the ingress and egress forward
adjacencies of the domains, the confidentiality the domains is preserved. This
approach allows the establishment of e2e interdomain QoS-based connections
between multiple domains. Moreover, the e2e interdomain negotiation service
offers a mechanism by which the domains might apply admission control on each
request.
The evaluation of the prototype showed that the bandwidth consumption
demanded by the service layer is very low. The number of messages to execute the
e2e negotiation protocol is minimal and, most importantly, the time to establish e2e
interdomain 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 exist
in interdomain environments neither to collect all the performance measurements
for each case. Our goal was to give carriers some figures related to the behavior
of Web services to provide e2e interdomain services.
By using the Web services technology to provide the access to the management system and to integrate the interactions among domains, new ways of
developing Web-based management solutions can be envisioned. Not only is the
research community committed to SOA and XML-based standards, but also many
consortiums and companies are driving the development for the convergence and
adoption of XML-based integration. The architecture proposed in this article is in
line with this trend.
ACKNOWLEDGMENTS
The authors would like to thank CNPq, CAPES, FAPESP and Ericsson Brazil
for their support.
REFERENCES
1. L. Xiao, J. Wang, K.-S. Lui, and K. Nahrstedt, Advertising Interdomain Qos Routing, IEEE
Journal on Selected Areas in Communications, Vol. 22, No. 10, pp. 1949–1964, December 2004.
Verdi, Magalhães, Cardozo, Madeira, and Welin
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/GMPLS
Test 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 Ethernet
over dynamic DWDM networks. 7th IFIP Working Conference on Optical Network Design and
Modeling (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 International 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 WebServices-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 approach
for 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 Management 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 of
Service: 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, Implementations, and Challenges. IEEE Communications Magazine, Vol. 43, No. 6, pp. 119–128, June
2005.
13. A. Farrel, J.-F. Vasseur, and J. Ash, Path Computation Element (PCE)-based Architecture. IETF
RFC 4655, August 2006.
14. A. Farrel, J.-F. Vasseur, and A. Ayyangar, A Framework for Inter-Domain MPLS Traffic Engineering. 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 Network
Service. IEEE Globecom, pp. 1803–1807, 2004.
17. R. S. Ravindran, P. Ashwood-Smith, H. Zhang, and G.-Q. Wang, Multiple Abstraction Schemes
for Generalized Virtual Private Switched Networks. IEEE Canadian Conference on Electrical and
Computer Engineering – CCECE, pp. 0519–0522, May 2004.
18. H. Ould-Brahim and Y. Rekhter, GVPN Services: Generalized VPN Services using BGP and
GMPLS Toolkit. IETF draft, work in progress, February 2005.
19. B. Arnaud, UCLP Roadmap: Web Services Workflow for Connecting Research Instruments and
Sensors to Networks. Draft, December 2004.
20. V. de Souza and E. Cardozo, A Service Oriented Architecture for Deploying and Managing Network Services. Proceedings of the 3rd International Conference on Service Oriented Computing
(ICSOC ’05), LNCS-Springer-Verlag, Vol. 3826, pp. 465–477, December 2005.
Provisioning of Interdomain Optical Network Services using SOA
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 (of
communications) 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. Magalhães, Web Servicesbased Provisioning of Connections in GMPLS Optical Networks. The Brazilian Symposium on
Computer Networks (SBRC). Fortaleza, Brazil, May 2005.
23. C. Carvalho, F. L. Verdi, E. Madeira, and M. Magalhães, Policy-based Fault Management for
Integrating IP over Optical Networks. The 5th IEEE International Workshop on IP Operations &
Management (IPOM ’05), LNCS-Springer-Verlag, Vol. 3751, pp. 88–97, October 2005.
24. F. L. Verdi, C. Carvalho, E. Madeira, and M. Magalhães, Policy-based Grooming in Optical Networks. 4th IEEE Latin American Network Operations and Management Symposium (LANOMS),
pp. 125–136, August 2005.
25. F. Ricciato, U. Monaco, and D. Ali, Distributed Schemes for Diverse Path Computation in Multidomain MPLS Networks, IEEE Communications Magazine, Vol. 43, No. 6, pp. 38–146, June
2005.
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 Interconnection of Networks, pp. 28–32, September 2005.
31. OASIS Consortium: http://www.oasis-open.org/.
Fábio Luciano Verdi is currently a post-doc student at the Faculty of Electrical and Computer
Engineering (FEEC), State University of Campinas (UNICAMP), Brazil. He received his Master
degree in Computer Science and Ph.D. degree in Electrical Engineering both from State University
of Campinas (UNICAMP). His main interests include computer networks, mobility, routing, service
oriented architectures, inter-domain services and next generation Internet Architectures.
Maurı́cio Ferreira Magalhães received the B.S. in Electrical Engineering from University of
Brası́lia (UnB), Brası́lia, Brazil, M.S. in Automation from School of Electrical Engineering, State University of Campinas (UNICAMP), Campinas, Brazil and Dr. Engineer from Laboratoire d’Automatique
(LAG/CNRS) and Institut National Polytechnique de Grenoble (INPG), Grenoble, France. Currently
he works as a Titular Professor at the School of Electrical and Computer Engineering, State University
of Campinas (UNICAMP), Campinas, Brazil.
Eleri Cardozo received the B.S. degree from University of São Paulo, Brazil, the M.S. degree
from Technological Institute of Aeronautics, Brazil, and the Ph.D. degree from Carnegie Mellon
University, USA. Currently he is a Professor of Electrical and Computer Engineering at the School of
Electrical and Computer Engineering, State University of Campinas (UNICAMP), Brazil.
Edmundo R. M. Madeira is an Associate Professor at the Institute of Computing of State
University of Campinas (UNICAMP), Brazil. He received both his Ph.D. in Electrical Engineering
and M.Sc. in Computer Science from State University of Campinas (UNICAMP), Brazil. His research
interests include network management, optical netwoks and distributed systems. He has published over
Verdi, Magalhães, Cardozo, Madeira, and Welin
100 papers in national and international conferences and journals. He has also supervised more than
30 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 with
optical networks, management plane and control plane interworking to automate fast provisioning.