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]