SLA Negotation

The Negotiation Common Capability relates to the procedure of parties (consumer and providers) agreeing on the terms of an SLA governing the exchange of resources. The parties try to reach a deal based on a consensus after exchanging (possibly several) non-binding probes called quotes hereafter.

One important part is that in any such type of trade agreement, the provider never publishes offers. Instead, the provider waits for the client to send a pre-signed agreement. The provider expects the client’s agreement to be based on a previous template. The client can reasonably know what the provider is ready to offer based on quotes that the provider has issued previously on demand. The steps are the following:

1. The provider publishes a template describing the service and its possible terms, including the QoS and possible compensations in case of violation. This template leaves several fields blank or modifiable, which are meant to hold the user specific needs.
2. The client fetches the template, and fills it in with values which describe the planned resource usage. Some terms of the template may be removed or added or changed, but may lead to a rejection in step 5. This new document, which engages neither party, called a quote request, is sent to the provider.
3. Sending the quote request is equivalent to asking the provider to give a provisional answer, saying whether the deal could be accepted. Receiving this, the provider, based on the current resource availability and customer policies, sends back to the client a quote. This quote corresponds to values on which the provider would probably agree (but this is by no means binding), based on the client’s needs expressed in the quote request.
4. The client, if satisfied with the quote, applies his/her signature to the document, and sends it back to the provider as a proposal. This proposal corresponds to an agreement that the user is ready to comply with. Effectively, the client is already proposing an SLA to the provider, but the provider’s signature is missing.
5. The provider, receiving the proposal, is free to reject or accept it. In the latter case, the proposal becomes an SLA officially signed by both parties, and starts to be a valid legal document.

Requesting the template is only done once for every type of service the provider offers. The quotes exchange (steps 2 and 3) can be repeated any number of times. The user can tune the terms in the quote request until the provider’s quote is in line with what the client is ready to accept. The last step for the client, step 4, requesting the real SLA, has a Boolean answer: the SLA is either accepted or rejected by the provider. In the latter case, the user can go back to asking for a quote, as the provider might have changed his conditions. This procedure allows the provider to have the final decision in accepting or not the contract (this is crucial to avoid pre-reserving resources which may not be attributed if the client disengages).

The steps 2-3 are the core part of the negotiation, as each party can pull the deal in any direction. The parties may freely modify the different terms: lower fees, lower QoS, longer time slots, fewer resource needs, lower compensations, etc.

Once a contract has been signed and agreed, the necessity of changing it could be envisaged (see re-negotiation). In that case, the same quote framework could be used. The main difference comes from the already allocated resources, and the existence of a first contract to modify. Technical difficulties appear on the provider side in this case, but the framework presented to the parties to sign a new contract stays basically the same. The getTemplate() first call would contain as parameter the previous contract, to signify that it should be renegotiated. The procedure then stays the same as presented above.

On the technical side, there are existing protocols and pre-standards existing. For example, the format of the SLA templates, quotes, and proposals described in this framework could be based on the WS-Agreement XML schemas.