MESCAL
has developed a framework for ordering and negotiating pSLSes between
providers, an essential part of the MESCAL solution for inter-domain
QoS delivery. In addition to providing the appropriate enabling
means for realising these processes, the framework aims at further
facilitating these processes by providing increased levels of automation
and flexibility.
Evidently,
carrying out the processes of pSLS establishment through automated
and flexible ordering and negotiation means, as opposed to manually
and monolithically is beneficial in many aspects. It reduces unnecessary
human intervention and hides underlying complexity; it enables the
application of more comprehensive policies than simple ‘yes/no’
decisions; and, contributes to a fully automated service provisioning
process, accelerating the introduction of new services. On these
grounds, this result also facilitates the deployment of the MESCAL
solution.
The specified ordering and negotiations framework realises
the behaviour of the Ordering and Order Handling components of the
general MESCAL functional architecture. It consists of two elements,
which are regarded as results on their own right:
Service
Negotiation Protocol (SrNP): It is an application
level protocol for negotiating the establishment, modification,
termination of pSLSes. Being designed to be completely decoupled
from the negotiation logic, it provides for the necessary primitives
required for enabling negotiations –based on which, specific negotiation
logics can operate, as desired. The offered negotiation features
include: responses within set time periods, revisions instead of
monolithic ‘yes/no’ answers, ‘please more time’ and ‘take it or
leave it’. SrNP is session-oriented and adopts a client-server,
dialogue-based (half-duplex) approach along multiple tracks corresponding
to different pSLS instances. It is not specific to the particular
contents of the pSLSes, nor is it specific to particular transport,
policy or information exchange protocols. Initially specified in
TEQUILA, SrNP has been appropriately enhanced to meet the requirements
of MESCAL for transactional pSLS negotiations; one provider to negotiate
a set of pSLSes with its peer providers at the same time, whereby
the outcome of the negotiations with one provider may affect the
negotiations with another provider.
Ordering
Language: A language has been specified for ordering
the pSLSes a provider needs to establish with its peers. The language
allows specifying the pSLSes to be ordered with values belonging
to an interval instead of being fixed. It also allows specifying
sets of pSLSes, options, for selecting the best one(s) according
to specific conditions on well-defined metrics; furthermore, it
allows for alternative pSLSes to be ordered in case the negotiations
of an original set of pSLSes fails. Evidently, these features provide
adequate degrees of flexibility in expressing the pSLSes determined,
by TE and respective business policies, for accommodating inter-domain
QoS traffic requirements. As such, they provide additional, to TE,
means to feasibly and optimally dimensioning the network in terms
of to the required inter-domain resources -pSLSes. The specified
ordering language can be mapped to the appropriate SrNP-based negotiation
logic for actually undertaking the required orders -pSLS establishments.
The
above results have been validated through implementation and experimentation.
Finally, it should be noted that although driven by the MESCAL needs,
the proposed ordering and negotiations framework has been designed
so that it can apply to diverse application domains pertinent to
orders and negotiations for purchasing commodities in a general
e-commerce context.
Further
reading:
MESCAL
deliverable D1.3, "Final specification of protocols and algorithms
for inter-domain SLS management and traffic engineering for QoS-based
IP service delivery", Chapter 9. [link]
MESCAL
deliverable D3.2, "Final
experimental results: validation and performance assessment of algorithms
and protocols for inter-domain QoS through service-driven traffic
engineering", Chapter 5,
sections 5.1-5.2. [link] |