The "sale" is at the core of this document: a consumer, wishing to solve a problem by applying cloud resources, negotiates with service providers who provide services. To facilitate this, service providers define Service Level Agreements (SLAs). These, in turn, enable the customer to select service providers that satisfy essential requirements (e.g. geographical constraints on the location of the service). As the SLAs will include the price of the service, this infrastructure will enable a market economy of cloud services. While the Contrail SLA work builds on related work, primarily from SLA@SOI, this document describes the SLA implementation in Contrail (in the sense of putting SLAs to practical use in Contrail.) In describing the quality, either of the service (QoS) or of the protection (QoP), we make use of terms, usually defined by SLA@SOI, such as the throughput, bandwidth, "isolation" of a service, etc. We discuss how to deal with uncertainties and other unknowns, and show practical examples of what an SLA would look like for service providers relevant to the Contrail project: namely, a Contrail partner providing an OpenNebula-based service, Azure, and Amazon. For example, for the OpenNebula service we can easily describe the geographic constraints. For Amazon, we can describe the availability (such as advertised by Amazon.) The overall aim is that while we have a template for the SLAs, we need to decide how to use it. What should you publish as your "guaranteed" bandwidth - should it be a value which you can be confident about, which is almost certainly lower than the actual bandwidth, or should you publish a high value which you might fail to deliver? We need to look not just at the syntax of SLAs and the semantics of the terms, but also on how to set the guarantees, or objective (Service Level Objective, SLO.) It follows that monitoring and accounting are both essential parts of an infrastructure which uses SLAs. Monitoring needs to ensure that observable terms are tracked, and that objectives, if applicable, are met. Accounting forms a core part of the federation: as users use resources from multiple providers, there is a common system for tracking their use. Also described in this document is the SLA architecture, i.e., the architecture of the SLA management system and their interactions. SLA Templates (i.e. providers' offers of services, or users' queries for services) are registered with the infrastructure: the consumer and the provider can both initiate and respond to an offer. An SLA Negotiation component, with access to the templates registry, mediates the matching of initiators with responders. Based on the SLA@SOI protocol engine, it is adapted in Contrail to negotiate resources in IaaS (i.e. based on VEP instead of OpenNebula directly, so we can accommodate also other providers of VEP), as well as ConPaaS. Integral to this architecture is the monitoring framework which is responsible for checking whether the SLA agreement is violated or not. As a long-term view of the service may be needed, this monitoring will be integrated with accounting. The accounting and monitoring will be implemented with message queues, which have the advantages that such queues can also be used for notifications. So in Contrail, users have the assurance that their service is being monitored, and they will be notified if something goes wrong. Elasticity - i.e. the ability to scale up, but also to scale down when needed, is often highlighted as an essential feature of the cloud. In a federated cloud the consumer will often have a choice of provider. The federation must manage both upscaling and downscaling carefully, in order to provide both a seamless (i.e. uninterrupted) and cost effective services for the user. One should note that we do not intend to answer all the questions posed in this document. While we describe the framework for SLAs in Contrail, along with how it will be used, we also highlight a few open questions for future study. One of the main conclusions from this document is that Contrail extends existing work with SLAs, not just by extending work of SLA@SOI, but also by enabling smaller service providers to provide cloud resources. You don't have to be the size of Google to run a Contrail cloud. The fact that SLAs are negotiated reduces the risk of overcommitting: service providers will not see services they have not acknowledged. And, perhaps more importantly, from the consumer perspective they can live with some of their services being provided by smaller providers because they can supplement - cloudburst - with services from other providers easily, or even transparently, because they are all in the same Contrail federation.