SLA/SLS Fundamental concepts SLAs/SLSs are the essential mechanisms for agreeing, configuring, delivering, guaranteeing and evaluating the obtained QoS The SLA specification requires extensive testing of the available infrastructure. Usually only upper bounds of QoS parameter ranges can be specified. SLA definition between two peers is the structural unit for the establishment of end-to-end services There are always two SLAs, one for each direction. The contracted values might be different.

Fundamental concepts (continued) The SLA/SLS is in reality a chain of SLA/SLS between neighbour domains and a final end-to-end one User 1 User 2 User 1 NREN1 GÉANT NREN2 User 2 + In the first phase the end-to-end SLS negotiation will be performed manually (no BB), specified as the worst case scenario.

The IP Premium service is aimed at providing end-to-end QoS. To fulfil this goal the establishment of a particular service instance must be made known to all domains involved. The service must be defined both as an end-to-end service level agreement and be accepted as a modification in the chain of service level agreements between all involved domains. Debugging can be assigned to a single specific entity. Fundamental concepts (continued)

Definition of SLAs between GEANT and NRENs Administrative/legal part SLS part: defining the set of parameters (SLS template) and their values, such as a Traffic Conditioning Specification (TCS) Matrix for NREN-to-NREN traffic IP Premium Current status

Define SLA between end-user and end-user domain Define the mechanisms for SLA negotiation Define the mechanisms for the establishment of end-to-end services based in the individual SLAs. Next steps

SLA templates & instantiations

Administrative and technical parties involved (scope) Duration in time (scope) Availability guarantees (scope, process, remedy) Monitoring (scope, process) Response times (scope) Fault handling-trouble ticket procedures (scope, process, remedy) Quality and performance of support and helpdesk (scope, process) Pricing of the contracted service Description of the service The administrative/legal part of the SLA

Scope This field, according to [RFC 2475], must specify where packets conforming to the SLS are entering and exiting a DiffServ domain (in our case GEANT). Recommended: (ingress interface, set of egress interfaces) Proposed Template for SLS Between an NREN and GEANT

Flow description A SLA can contain more than one SLSs (and consecutively SLOs) but each one of them has to concern one strictly specified flow in one direction. The flow description field will indicate which packets will receive the PHB treatment resulting in the QoS guarantees of the SLS. Recommended: (QoS tag attribute, source attribute, destination attribute) Proposed Template for SLS Between an NREN and GEANT

Performance guarantees Depict the guarantees that the network offers to the customer for the packet stream described by the flow descriptor over the topological extent given by the scope value. Delay IPDV Packet loss Rate MTU Proposed Template for SLS Between an NREN and GEANT

Traffic Envelope and Traffic Conformance Describes how the stream of traffic from the NREN towards GEANT should look like The conformance parameters for IP Premium are conformance to a shape and a limit of throughput/capacity: (b,r) token bucket Proposed: –Conformance parameters = (b, r) –Conformance algorithm = the (b,r) token bucket b = f(number of router interfaces on the same router that are part of the service, distance from the source ) r = 1.5*th Proposed Template for SLS Between an NREN and GEANT

Excess treatment Specifies how excess traffic (or out-of-profile traffic, according to the profile described by the traffic envelope and traffic conformance field) is treated. -> dropping Service schedule Indicates the start time and end time of the period for which the service is provided Reliability –Allowed mean downtime per year (MDT) –Maximum allowed time to repair (TTR) in case of breakdown Proposed Template for SLS Between an NREN and GEANT