|
Multi-Domain Self Aware Management : Negotiation and
Monitoring |
|
Armen Aghasaryan, Sophie Piekarec, Hélia Pouyllau, Stefan Haar,
Eric Fabre, Laurent Ciarletta, Nader Mbarek, and Eric Moreau |
We focus first on the provisioning phase where a negotiation
algorithm is proposed to obtain a recursive/nested contract chain; then we
consider the assurance phase, where a so-called middle-to-end monitoring procedure
is introduced.
Index Terms—Cross-domain
service management, quality of service, negotiation, monitoring.
I.
INTRODUCTION
|
W |
HILE emerging technologies allow end-users an
ubiquitous and high-speed access to data, there is a growing need for
high-quality on-demand services such as video-conferencing or large multiplayer
games. Such services should adapt to the users’ needs, the offers from
independent service providers, and the state of the underlying backbone.
In order to ensure a
predictive and assured QoS across multiple heterogeneous and independent
domains, new architectures must be developed. Obviously, the management task of
such services, be it their configuration and maintenance at a local level, or
even more so in a cross domain scenario
where contracts (Service Level Agreements, SLAs) have to be negotiated, can not
be reasonably handled by human beings and must be automated as much as
possible. Projects like Mescal [2] and
Cadenus [3]
contributed in enhancing service level negotiation and guarantee, to enable a
dynamic service offer. In the SWAN (Self-aWare manAgemeNt) project [1], we
are developing a novel solution based on autonomous management principles.
This paper is structured as follows. We first
detail our architecture, showing its different elements and their interactions.
The complete life-cycle of a service, from initialization to monitoring is
presented next. Then we conclude with what may lie ahead.
II.
Multi-Domain QoS-enabled architecture
Building around the idea of Management Using Web
Services [4], we
advocate a vision in which independent network domains expose high-level
services, and service providers use these declarations to build commercial
service offers. The underlying mechanisms ensure that the end-to-end QoS
requirements in terms of Service Level Objectives (SLO) are “distributed” along
the chain of network domains involved in the service delivery. The QoS configuration/reconfiguration
and monitoring is performed in an autonomous way. The overall process combines
the following functions:
·
For each domain, a
configuration of “Service Trails” corresponding to the generic classes of
the application services supported by the domain. Also, a configuration of
adjacency service contracts, describing links between peer domains for each
application service type.
·
Cross-domain service routing:
an automatic and distributed computation of the “best” path for a given type of
service from a source to a destination using local service trails and peer
adjacency services.
·
For an end-to-end service
request, determination of QoS commitments of each domain such that the QoS
requirements of the global request are fulfilled. We call this recursive
bargaining process a “negotiation”; the entire negotiation process has been
detailed in [5].
·
Multi-domain
service signalling: auto-configuration of
network resources in accordance with committed parameters.
·
Auto-configuration of the
corresponding monitoring tools along the provisioned path.
·
Renegotiation : path
reconfiguration in case of faults.
Fig.1 summarizes the elements involved in the
overall process, on top of multiple independent and heterogeneous domains,
where an end-user is requesting a specific application service (e.g., a
video-conference with another end-user).
End-User Managers (EUM) situated at the
extremities of the management architecture are entities present in each domain
that includes an access part and interfaces with the end-users. These entities
provide commercial offers to end-users, manage subscriptions and addressing,
control access capabilities, and implement the
logic of application services.
The other components of this architecture
outlined below are concerned with autonomous management of the service
transport aspects including the multi-domain service path computation, QoS
resource allocation and supervision.
Fig. 1.Global multi-domain
architecture
A.
Intra
domain management
1)
Application SLS Registry and
Service Manager
The service pipes deployed in a domain
correspond to service type specifications defined within the Application SLS
Registry. Those specifications inspired from Tequila SLS template [6]
indicate an overlay topology with predefined QoS levels for each service type
(video conference, video on-demand, IPTV, etc.). We suppose that service
type names are common to all the domains, but the QoS characteristics are
specific to each one. The SLS Registry contains also the definitions of
adjacency links and supported services. The Service Manager ensures the
provisioning and supervision of the application service types via the support of
lower layers.
2)
Domain Manager (static
configuration) - DM
The DM is in charge of configuring the Service
Trails and Adjacency Links. As these
elements are described in a generic format common to all the domains, a
translation in terms of a specific domain network manager is necessary. In
particular, a mapping between the application service specifications (e.g. QoS
requirements for video-conference) and the network service specifications (e.g.
QoS classes).
Other important functions at this layer are the
service trail monitoring and the alarm generation in case of QoS violation.
that are handled by the DM-MON (DM Monitoring) according to the service trails
specifications and monitoring requirements received from the DM. More details
are given in section III.
3)
Network Management Layer – NML
This module is in charge of configuration and
supervision of the specific domain network and of the adjacency links with the
peer domains in conformance with the requests of higher level components,
namely the Domain Manager.
B. X-domain interactions management
1)
Network Service Registry - NSR
For the sake simplicity, this centralized
component does not appear in Fig.1. However, it is an important element of the
X-domain interactions, in that it ensures publishing of domain Web Services.
Namely, each Service Manager/Provider and EUM are registered in the NSR under
its domain name.
2)
Service Provider - SP
In order to respond to an end-to-end service
request, a chain of contracts meeting the requested QoS requirements must be
established along a chain of SPs. To this end, SPs are enabled to negotiate
contracts with their peers in adjacent
domains.
3)
Domain Manager (service
routing)
Service Routing information is stored in a
“routing table” called Reachability Information Base (RIB). For each service
type, the RIB contains the correspondences between the domains and the
adjacency links to reach them. The routing protocol used to build the RIB has
been inspired by BGP.
4)
Monitoring component - SP-MON
X-domain service monitoring is realized by the
SP-MON modules which interact with the SP and DM-MON components of its domain
and cooperate with their homologue modules of adjacent domains (see more
details section III).
III.
A service life cycle: from initialization to
monitoring
A.
Initialization and service
request
At the initialization stage, each domain has to
configure its service trails, establish adjacency links with its neighbors, and
register itself in the NSR. So, the service routes can be permanently
calculated for each application service type. Of course, new domains can join
this system, which brings in new service routes or modification of the existing
ones.
Then, upon a reception of a service request from
its end-user, the EUM can determine the accessibility of the destination
parties as shown in Fig.2, and launches a negotiation process across the chain
of intermediate domains.
Fig. 2. Initialization and Service Request
B.
Multi-Hop Negotiation and
dynamic contracting
The goal is to provide a QoS contract chain that
will satisfy (and optimize) an overall QoS
budget from SP0 (serving the initiator of a
service request) to the SPn (the target domain).
After appropriate pre-treatment, QoS budgets can be captured by real-valued
additive vectors in each domain that contain quantitative SLS parameters such
as delay, jitter and loss ratio, associated to a cost value in that domain.
Such QoS offers in a domain are called “admissible contracts”. Notice that our
approach can also capture stochastic SLOs..
The (asymmetric) dynamic programming strategy
proposed in [7]
allows us to break the sharing (and optimization) of the global QoS budget into
a neighbor-to-neighbor negotiation problem along the transmission chain. In our
recursive process, an SPi is responsible for
finding a valid solution and realizing the actual contractualization for the
remaining path to SPn. It will propose to the SPs,
that are valid next steps on the route to SPn, a set Q of possible budget vectors Qi for the end of the chain. Those vectors are computed as a function
of its local admissible contracts Ci
and the possible budget vectors received from SPi-1. Those contracts are taking into account the availability of local
resources on domain I, their cost, and are influenced by the instantiated
contracts and the pre-reservation of resources that is done when SPi propagates its budget requests. SPi being responsible for the residual contract chain i to n, we are
calling this process a nesting contractualization. One needs to store in each
domain the correspondence between the propagated budget vectors and the
associated local admissible contracts. When the procedure reaches the
destination SPn, the cost-optimal budget
vector is chosen, its corresponding contract is set-up, and the result of that
choice is sent back along the chain SPn-1,, SPn-2, … so that each domain
knows what local contract must apply. On return to SP0, an optimal path has been reserved. The Negotiation Module is a
part of the Service Provider component. Fig.3 illustrates the message exchanges
between the different “actors” of the process. The user manager sends a request
to the Service Manager which initiates the negotiation along the chain by
invoking the negotiate Web Service.
Fig. 3. Multi-Hop negotiation and nested contracting
The Negotiation Module
retrieves contract data from the Service Manager, then computes the local
admissible contract set C and the corresponding QoS budget set Q . The next hop address can be given only by the Domain Manager that
interacts with the Network Manager Layer. Therefore, the Service Manager
forwards the Negotiation Module request and returns the correct next-hop
address. With this address, the Negotiation Module can invoke the negotiation
process on the next Service Provider, with the QoS budget set Q as a parameter
(see Fig.4).
Fig.
4.Negotiation process
C.
Service provisioning
The commitments
of the Service Providers resulting from the negotiation process are
communicated to their respective Domain Managers; a service request Id specific
to the given negotiation process references them. Then, upon the termination of
the negotiation process, the originating SP launches the service signalling
across the chain of DMs. In each DM the request will be correlated by the
service request Id with the QoS commitment of the given domain and the
respective QoS resources will be allocated to the local part of the end-to-end
service instance.
D.
Monitoring
The
monitoring is carried out at two levels, intra-domain (DM-MON) and inter-domain
(SP-MON). At the intra-domain level, a classical centralized monitoring
approach is applied in order to supervise the configured service trails. This
is done by interfacing with the DM-MON module, which in its turn relies on legacy monitoring tools. In
fact, the DM MON can be seen as a proxy monitoring agent to gather all the
necessary performance information from the existing monitoring tools. As a
concrete ISP legacy monitoring application case, a proxy interface for all
existing IPFIX/Netflow stats was taken into consideration in the Swan project.
This approach used IPFIX templates proposals for common ISP usages defined on
recent IETF drafts [13][14] to
solve interoperability issues. DM-MON interface allows, on the one hand, to
communicate the trail specifications to the DM-MON, and on the other hand, to
receive alarms and warnings on the state of these trails. The DM can carry out
a basic correlation operation in order to determine which end-to-end service
instances are potentially impacted by a problem in a particular service trail.
This information will then be used to enrich the domain operators’ display, and
to give an input to the cross-domain supervision at SP level.
At
the inter-domain level, the objective of monitoring is to detect a contract
violation, in order to recover from it, or to launch a new negotiation
(re-negotiation) process if some contract is considered as definitively
abandoned.
Note that in the nested contract approach there
are n contracts (including the global one with the end-user) in a SP
chain of n domains. Although each contract covers a different portion of
the cross-domain service instance, these portions are nested like Russian
dolls. It is clear that execution of n independent cross-domain
monitoring processes is not feasible, and therefore a solution based on
cooperation between the SP-MON modules is needed.
The solution we advocate consists in installing
monitoring agents in the two end-points (or network edge nodes) of the global
service instance and executing a single end-to-end test in a way that all the
intermediate (middle-to-end) measures are also obtained. In fact, this
is possible if the time-stamped test packets are observed at each domain’s
entry point, and the SP-MON modules cooperate on a pair-wise basis in order to
aggregate the middle-to-end, and finally, the end-to-end measures. For example,
the SP-MON “n” can compare the timestamps of the packets entering its domain
(from the domain “n-1”) with those observed in the end-point and deduce the
delay measure for its portion (n,n). Then, similarly the measure (n-1,n)
can be deduced by the exchange of information between the SP-MONs of domains
“n-1” and “n”. Similar approaches are promoted in recent IETF drafts [9][10][11] as techniques of spatial metrology.
IV.
Future work
A.
Negotiation
The cost function
associated with a QoS budget chain is a central element of the final decision.
In our current prototype, this function consists in the accumulation of the
contract prices. It is a straightforward extension to use a more elaborated
cost function with weights that express preferences on SLS parameters (delay,
bandwidth, jitter etc.). The negotiation protocol we describe is applied to a
linear structure of SPs corresponding to the request for a single service type.
Our future work will also include symmetrical dynamic programming (launching
two negotiation processes from both the initiator and the target SPs), and the
optimization of the contract selection under global constraints; this is needed
when local resources are to be optimized with respect to several requests have
treated on the same domain.
B.
Post-monitoring actions
Within
a contract chain, for a given domain "i", four types of data are
available from the contracts and by means of the intra- and inter-domain
monitoring:
·
the local nominal QoS to which
the SP has committed during the negotiation process,
·
the DM-MON’s estimation of the
effective local QoS,
·
the nominal
"middle-to-end" (i,n) QoS which was contracted between the
domains "i" et "i-1",
·
the SP-MON’s estimation of the
effective "middle-to-end" QoS..
Given these four types of data, various
post-monitoring behaviors are possible for each SP. For example, one domain may
decide to inform its client domain about the QoS violation on its portion of
responsibility (a cooperative behavior), while another one may want to hide it
from its client party in order to avoid penalties and hoping that the global
end-to-end QoS is compensated thanks to the over-performance of some other
domains (a selfish behavior). The possible local behaviors and their
combinations have to be studied and compared, and finally specified in such a
way that the global system stability, fairness, and convergence properties are
respected.
References
[1]
SWAN project. URL http://swan.elibel.tm.fr
[2]
Mescal D1.2 “Initial
specification of protocols and algorithms for inter-domain SLS management and
traffic engineering for QoS-based IP service delivery and their test
requirements”, January 2004. Available: http://www.mescal.org
[3]
Olivier Dugeon, «From SLA to
SLS up to QoS control : The CADENUS Framework», 2002. Available: http://www.cadenus.org
[4]
Management using Web Services, OASIS consortium, http://docs.oasis-open.org/wsdm/2004/12/wsdm-muws-part1-.0.pdf
[8]
Telecommunications
and Internet Protocol Harmonization Over Networks (TIPHON). Part3: Signalling
and Control of end-to-end Quality Of Service (QoS). ETSI, 2002.
[9] IETF : IP Performance Metrics for spatial
and Multicast – October 2005, www.ietf.org/internet-drafts/draft-stephan-ippm-multimetrics-02.txt
[10] IETF : Spatial Composition of Metrics – October
2005, www.ietf.org/internet-drafts/draft-morton-ippm-composition-01.txt
[11] IETF : OWAMP (One Way Active Measurement
Tools) – November 2005, www.ietf.org/internet-drafts/draft-ietf-ippm-owdp-15.txt
[12]
F. Cuervo, A. Jansen, P. Guingo, M. Sim, XIP: A
Scalable and Distributed Architecture for Cross-domain Services, Integrated
Network Management IX , IM'05, 15-19 May 2005, Nice, France
[13] IETF : IPFIX templates for common ISP usages –
October 2005, http://www.ietf.org/internet-drafts/draft-stephan-isp-templates-01.txt
[14] IETF : IPFIX
Protocol Specification - September 2005, http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-19.txt