Danny Goderis, Alcatel Yves T'joens, Alcatel Christian Jacquenet, France Telecom R&D George Memenios, NTUA George Pavlou, UniS Richard Egan, Racal Research Ltd David Griffin, UCL Panos Georgatsos, AlgoSystems Leonidas Georgiadis, Univ. Thessaloniki Pim Van Heuven, IMEC INTERNET DRAFT June, 2001 Expires December 2001 Service Level Specification Semantics, Parameters and negotiation requirements. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document identifies the basic information to be handled by Service Level Specifications (SLS, [RFC 2475], [DS-TERMS]) when considering the deployment of value-added IP service offerings over the Internet. Such IP service offerings can be provided together with a given quality of service (QoS), which is expected to be defined in such SLS, from a technical standpoint. Since these IP services are TEQUILA consortium Expires December 2001 [Page 1] Internet Draft draft-tequila-sls-01.txt June, 2001 likely to be provided over the whole Internet, their corresponding QoS will be based upon a set of technical parameters that both customers and services providers will have to agree upon. From this perspective, this draft aims at listing (and promoting a standard formalism for) a set of basic parameters which will actually compose the elementary contents of an SLS. Such a specification effort tries to address the following concerns: - Provide a standard set of information to be negotiated between a customer and a service provider or amongst services providers within the context of processing an SLS; - Provide the corresponding semantics of such information, so that it might be appropriately modeled and processed by the above-mentioned parties (in an automated fashion). Table of Contents 1. Introduction 1.1 Motivation 1.2 Objective 2. Basic assumptions and terminology 3. SLS content & template 3.1. Scope 3.2. Flow Identification 3.3. Traffic Envelop and Traffic Conformance 3.4. Excess Treatment 3.5. Performance Guarantees 3.6. Service Schedule 3.7. Reliability 4. Service Level Specifications and Per Domain Behaviors 4.1 DiffServ Terminology 4.2. SLS and PDB similarities and differences. 4.2.1. A subset of common parameters 4.2.2. Inter-domain interfaces versus intra-domain QoS building blocks 4.3. From PHB to value-added IP service: a layered DiffServ view 5. Service Level Specification examples 5.1. Virtual Leased Line 5.2. Bandwidth Pipe for data-services 5.3. Real-time micro-flows 5.4. Minimum rate guarantee with allowed excess 5.5. Qualitative Olympic Services 5.6. The funnel services 5.7. Best Effort Traffic 6. SLS negotiation requirements 7. Security considerations 8. Acknowledgements TEQUILA consortium Expires December 2001 [Page 2] Internet Draft draft-tequila-sls-01.txt June, 2001 0. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 ([RFC-2119]). 1. Introduction 1.0 Changes w.r.t. the previous version This is the third version of an Internet Draft on the issue of Service Level Specifications (SLSs). The first version was the draft , while the second version was . The major change of this version is a new section 4 "Service Level Specifications and Per Domain Behaviors". This new section discusses the simillarities and differences between SLSs and PDBs. Also some minor editing changes and reference updates have been incorporated in this version. 1.1 Motivation This document is presented to the IETF community to gauge the interest for advancing the work on the specification of an SLS definition, its semantics and its potential negotiation protocol(s). The deployment of QoS-based value-added IP services over the global Internet is one of the most exciting challenges that the service providers try to currently address, especially when considering the deployment of such service over administrative domains. From this standpoint, it seems useful to consider the specification of an SLS template these service providers would agree upon, so as to enforce an inter-domain QoS policy. This is the basic motivation for presenting this document to the IETF community. 1.2 Objective This document presents an outline for the definition of the Service Level Specification parameters, the semantics that go behind this representation, and some early ideas on the requirements on negotiation of SLSs. The need to have such an agreed set of Service Level Specification parameters and semantics is manifold. First, it is necessary to be able to allow for a highly developed level of automation and dynamic negotiation of Service Level Specifications between customers and providers. Automation and dynamics are indeed helpful in providing customers (as well as providers) the technical means for the dynamic provisioning of TEQUILA consortium Expires December 2001 [Page 3] Internet Draft draft-tequila-sls-01.txt June, 2001 quality of service. The automation in itself is e.g. necessary to allow roaming (dial-in) and to enable mobile users to have access and negotiate a transport Service Level, independent of their point of attachment to the network. Second, the design and the deployment of Bandwidth Broker capabilities [TWOBIT] in a multi-vendor environment requires a standardized set of semantics for Service Level Specifications being negotiated at different locations: - between the customer and the service provider (namely between the Customer Premises Equipment (CPE) and its point of attachment to the IP network managed by the service provider); - within an administrative domain (for intra-domain SLS negotiation purposes); - between administrative domains (for inter-domain negotiation purposes). While the representation and semantics behind a Service Level Specification need to be standardized, this document does not assume that the syntax, nor the SLS negotiation protocol need to be uniquely defined. E.g, the negotiation could make use of various other protocols such as http, rsvp, IPCP, DHCP, etc. The latter is ffs, and as such not part of this document. The document is structured as follows. Section 2 lists the basic assumptions underlying this work and some terminology. Section 3 describes the parameters of the Service Level Specification (template). This draft only describes the semantics of the SLS- parameters, omitting all implementation details as for instance the parameter data types (at this moment). Section 4 provides some examples of relevant SLS specifications, with the aim to show the usage of the templates. The SLS formalism defined in section 3 allows making a distinction between qualitative and quantitative SLSs: - SLSs depicting qualitative services should yield the specification of relative QoS indicators, such as a low IP datagram loss ratio. From this standpoint, best effort traffic is expected to be qualified by an SLS of that range of qualitative services. TEQUILA consortium Expires December 2001 [Page 4] Internet Draft draft-tequila-sls-01.txt June, 2001 - SLSs depicting quantitative services should yield the accurate measurement of QoS indicators, such as e.g., transit delay. Sections 5 and 6 finally describe some SLS (protocol) negotiation requirements and security considerations respectively. The material presented in this draft derives from work within the IST-TEQUILA project [TEQUILA]. 2. Basic assumptions and terminology The basic assumption of this draft is that IP services will be deployed over a public IP infrastructure, which will be (partly if not completely) composed of diffserv-aware network elements ([RFC- 2475], [DS-MODEL]). These network elements are able to implement Per Hop Behaviors (PHBs), including the Assured Forwarding PHB ([RFC- 2597]), and the Expedited Forwarding PHB ([RFC-2598]. Customers of such services include Internet Service Providers (ISP), who may well establish QoS-based peering agreements between themselves, and usual customers of ISPs, like those who compose both the residential and the corporate market. The terminology used in this draft is in agreement with the DiffServ Working Group terminology introduced in [RFC-2475], section 1.2 "terminology" and further specified in [DS-TERMS]. 3. SLS content & template The following describes the attributes of the Service Level Specification. It should be remarked that some SLS-features are not yet specified in this draft. For example, the Internet2 QoS Working Group specifies an SLS for the EF-based Premium Service [QBONE]. One of the attributes, i.e. "Route", is used for inter-domain routing aspects. This and other SLS features are for further study. 3.1. Scope The scope of an SLS associated to a given service offering indicates where the Quality of Service (QoS) policy for that specific service offering is to be enforced. Therefore the scope uniquely identifies the geographical/topological region over which the QoS is to be enforced by indicating the boundaries of that region. An SLS is associated with uni-directional traffic flows. Note however that this does not exclude the provisioning by providers of bidirectional contracts, by combining one or more SLSs. TEQUILA consortium Expires December 2001 [Page 5] Internet Draft draft-tequila-sls-01.txt June, 2001 The associated scope of the SLS MUST be expressed by a couple of ingress and egress interfaces. Ingress/egress denote respectively the entry/exit points of the IP packets relative to the region (network). Scope = (ingress, egress) with ingress/egress defined as - Ingress: interface identifier | set of interface identifiers | any - Egress : interface identifier | set of interface identifiers | any Remarks: - "|" denotes an exclusive OR. - "any" is logically equivalent with unspecified. The following combinations of (ingress, egress) interfaces are allowed: - (1,1) - one-to-one communication - (1,N) - one-to-many communication (N>1) - (1,any) - one-to-any communication - (N,1) - many-to-one communication (N>1) - (any,1) - any-to-one communication The above taxonomy excludes the many-to-many communication (M,N). Either ingress OR egress MUST be specified to exactly ONE interface identifier (with a non-exclusive OR). Many-to-many communication (M,N) can be decomposed into M times one-to-many communication (1,N). This taxonomy SHOULD avoid all ambiguity about the IP flow (defined as a set of IP datagrams sharing at least one common characteristic, like e.g. the same [source address; destination address] pair), and its corresponding identification. (see section 3.2 and 3.3). If the ingress is a single interface identifier, then the traffic envelop and flow id concerns the incoming IP packet stream at the unique ingress point. If (only) the egress is a single interface, i.e. (N|any,1), then the traffic envelop and flow id concerns the outgoing (aggregate) traffic on the egress link. More details about the latter can be found in the example 4.5. In the remaining part of this document SLSs with an associated scope TEQUILA consortium Expires December 2001 [Page 6] Internet Draft draft-tequila-sls-01.txt June, 2001 (topology) of (1,1) ; (1,N) ; (N,1) will be called respectively Pipe, Hose and Funnel SLSs. Disclaimer: An ingress (or egress) interface identifier should uniquely determine the boundary link as defined in [RFC-2475] on which packets arrive/depart at the border of a DS domain. This link identifier MAY be an IP address, but it may also be any other mutually agreed upon identifier which uniquely identifies a boundary link. Fore example a layer-two identifier in case of e.g. ethernet, or for unnumbered links like in e.g. PPP(Point-to-Point Protocol, [RFC-1661])-based access configurations. The interface identifier(s) may also implicitly be derived from the source or destination address information in the Flow Identification field (see next section 3.2) combined with e.g. BGP4 (Border Gateway Protocol, version 4, [RFC- 1771]) routing information. 3.2. Flow Identification The flow identification (Flow Id) of an SLS associated to a given service offering indicates for which IP packets the QoS policy for that specific service offering is to be enforced. A Flow Id identifies a stream of IP datagrams sharing at least one common characteristic. An SLS contains one (and only one) Flow Id, which MAY formally be specified by providing one or more of the following attributes: Flow Id = (Differentiated Services information, source information, destination information, application information) - Differentiated Services information = DSCP value | set of DSCP values | any The Differentiated Services Code Point (DSCP) IP header field is defined in [RFC-2474]. - Source information = source address | set of source addresses | source prefixe | set of source prefixes | any - Destination information = destination address | set of destination addresses | destination prefixe | set of destination prefixes | any - Application information = protocol number | protocol number and source port, destination port | any TEQUILA consortium Expires December 2001 [Page 7] Internet Draft draft-tequila-sls-01.txt June, 2001 Note: "any" is again logically equivalent with unspecified. Thus, the Flow Id may be expressed by information attributes related to the source/destination nodes, the application or the DS field in the IP header. The Flow Id provides the necessary information for classifying the packets at a DS boundary node. This datagram classification can either be Behaviour Aggregate (BA) or Multi-Field (MF)classification based. In case of MF-classification all attributes MAY be specified, including the DSCP field. MF classification may depict as well micro-flows as aggregate macro-flows, based on e.g. source network prefix [DS-MODEL]. Also the "set-of" semantics allows for the specification of aggregate flows. If a Flow Id is e.g. specified by a set of two IP source addresses, then any packet with either of the two concerned source addresses belongs to the IP packet stream identified by Flow Id. In case of BA-classification [RFC-2475], the DSCP attribute MUST be specified and the other attributes MUST NOT be specified. If a set of DSCP-values is specified, then any packet having a DSCP belonging to this set is part of the Flow Id packet stream (analogous to the example above with the IP source addresses). As an example consider an Ordered Aggregate (OA) IP packet stream of a particular Assured Forwarding Class AFx (AF1,AF2,AF3,AF4 - see [RFC 2597]). This stream could be specified within one Flow Id using three DSCP-values, indicating the three drop precedences levels, respectively colored in green, yellow and red. It should however be noticed that the DSCP-value(s) specified in the SLS has (have) as such nothing to do with the DSCP-marking of packets inside the DiffServ network. The latter, i.e. the "interior" DSCP is used for differentiating packets according to Per Hop Behaviours (PHBs). The former, i.e. the "ingress" DSCP value (specified in the SLS), is just another way of identifying a packet stream, eventually in combination with other IP header fields. At the ingress DiffServ node (incoming) packets are classified based on the "ingress" DSCP value (amongst others), after which they may be re-marked by the "interior" DSCP-value. Finally note also that the IP routing scheme MAY put restrictions on combining scope and flow identification within an SLS. In general, if (only) Flow ID is specified by source and destination IP address (IP-src, IP-dest), and the scope is unspecified, then there is no a-priori assumption about the actual ingress/egress points that this traffic will use. Indeed, it is the responsibility TEQUILA consortium Expires December 2001 [Page 8] Internet Draft draft-tequila-sls-01.txt June, 2001 of the service provider to define the most appropriate route for this traffic, by enforcing the corresponding traffic engineering and routing policy. Thus, the (ingress, egress) information (which is NOT in the SLS) is then derived from the Flow Id and the routing policy of the service provider. On the other hand, if Flow Id AND scope are specfied in the SLS, resp. by the pairs (IP-src, IP-dest) and (IP-ingr, IP-egr) then it is clear that the IP packets MUST follow the route (IP-src,...,IP- ingr,...,IP-egr,...,IP-dest). Thus the restriction is that the scope (IP-ingr, IP-egr) is part of the route from IP-scr to IP-dest. Also remark that the exclusion of the many-to-many communication scope model puts similar constraints on the source/destination fields of the Flow Identification. 3.3 Traffic Envelop and Traffic Conformance The traffic envelop describes the traffic (conformance) characteristics of the IP packet stream identified by the Flow Id. The traffic envelop is a set of Traffic Conformance Parameters, describing how the packet stream should look like to get the guarantees indicated by the performance parameters (defined in section 3.5) The Traffic Conformance Parameters are the basic input for the Traffic Conformance Algorithm. Traffic Conformance Testing is the combination of the Traffic Conformance Parameters and the Traffic Conformance Algorithm. This will usually be done at a DS-boundary node. The algorithm and the conformance test can be binary-based or multi- level based. Binary Traffic Conformance Testing is a set of actions which uniquely identifies the "in-profile" and "out-of profile" (or excess) packets of an IP stream (identified by Flow-Id). In this case the Traffic Conformance Parameters describe the reference values the traffic (identified by the Flow ID.) will have to comply with, thus yielding the notions of "in" and "out" of profile traffics. The Traffic Conformance Algorithm is the mechanism enabling unambiguously to identify all "in" or "out" of profile packets based on these Conformance parameters. In case of multi-level (n) Traffic Conformance Testing a packet will be tagged (by the algorithm) as belonging to a particular level (1...n). Packets tagged as level n are called "excess" packets. TEQUILA consortium Expires December 2001 [Page 9] Internet Draft draft-tequila-sls-01.txt June, 2001 The SLS MUST indicate the concerned level (n) of the conformance testing algorithm: - Multi-level conformance testing n (integer) The following gives a (non-exhaustive) list of potential conformance parameters. - Peak rate p (bits per second) - Token bucket rate r (bits per second) - bucket depth b (bytes) - Maximum Transport Unit (MTU) M (bytes) - Minimum packet size (bytes) Binary-based Traffic Conformance Testing examples: - Conformance parameters = token bucket parameters (b,r); conformance algorithm = token bucket algorithm. - Conformance parameters = token bucket parameters and peak rate (b,r,p) with p larger than r; conformance algorithm = the combined token bucket (b,r) and (b,p). This is the conformance test for Integrated Services Controlled Load and Guaranteed Service IP flows in the IntSer QoS architecture [RFC-2211, RFC-2212]. The scheme permits bursty traffic to be sent, limited to a burst of b bytes, with a (long-term) average rate of r and a peak rate of no more than p. - Conformance parameters = MTU; conformance algorithm = all packets allowed with size smaller than MTU; packets larger than MTU are fragmented or dropped. Three-level based Traffic Conformance Testing example - The Two-rate Three-colour marker [REF] is based on two token buckets with rates r1 and r2 (larger than r1), containing respectively green and yellow tokens. The simplest operational mode is the "colour-blank" mode. A packet is tagged "green" if there are green and yellow tokens available, yellow if only yellow tokens are available and otherwise it is tagged red. 3.4. Excess Treatment TEQUILA consortium Expires December 2001 [Page 10] Internet Draft draft-tequila-sls-01.txt June, 2001 This section describes how the service provider will process excess traffic, i.e. out-of-profile traffic (in case of binary conformance testing) or n-level traffic (in case of n-level conformance testing). The process takes place after Traffic Conformance Testing, described previously. Excess traffic may be dropped, shaped and/or remarked. The SLS MUST specify the appropriate action by the following attribute. - Excess Treatment If Excess Treatment is not indicated, then excess traffic is dropped. Depending on the appropriate action, more parameters MAY be required The following is an indication in case of binary conformance testing. Multi-level conformance testing (like the definition of a hierarchical drop preference model) MAY also be enforced, but this concern has been left for further study. - If excess traffic is dropped, then all packets marked as "out- of-profile" by the Traffic Conformance Algorithm are dropped. No extra parameters are needed. - If excess traffic is shaped, then all packets marked as "out- of-profile" by the Traffic Conformance Algorithm are delayed until they are "in-profile". The shaping rate is the policing/token bucket rate r. The extra parameter is the buffer size of the shaper. - If excess traffic is marked or remarked, then all packets marked as "out-of-profile" by the the Traffic Conformance Algorithm are (re-) marked with a particular DSCP-value (yellow or red). The extra parameter is the DSCP. 3.5. Performance Guarantees The performance parameters describe the service guarantees the network offers to the customer for the packet stream described by the Flow Id and over the geographical/topological extent given by the scope. There are four performance parameters: - delay, time interval, optional quantile - jitter, time interval, optional quantile - packet loss, time interval TEQUILA consortium Expires December 2001 [Page 11] Internet Draft draft-tequila-sls-01.txt June, 2001 - throughput, time interval Delay, jitter and packet loss guarantees are for the in-profile traffic in case of binary conformance testing. For multi-level (n) conformance testing, delay, jitter and loss guarantees MAY be specified for each conformance level-i, except the last one (n). For example if n = 3, one can have a delay guarantee for the "conformance level-1" packets and a different delay guarantee for the "conformance level-2" packets. No guarantees are given for excess ("conformance level-n") traffic. The throughput is an overall guarantee for the IP packet stream, independent of a particular level (see below). The following definitions always consider the (measurable) performance parameters related to the packet stream specified by the Flow Id. For simplicity the definitions below are given for binary conformance testing (n=2), but generalisation is straightforward. The delay and jitter indicate respectively the maximum packet transfer delay and packet transfer delay variation from ingress to egress, measured over (any) time period with a length equal to the (indicated) time interval. Delay and jitter may either be specified as worst case (deterministic) bounds or as quantiles. Indeed, the worst case delay/jitter bounds will be very rare events and customers may find measurements of e.g. 99.5th percentile a more relevant empirical gauge of delay/jitter. Suppose e.g. that the SLS specifies the triple (delay = 10ms, time interval = 5 minutes, quantile = 10E-3). Then the probability that the transfer delay of a packet (between ingress-egress) is larger than 10ms, is less than 10E-3; and this for any measurement period of 5 minutes. The above syntax for delay/jitter can be generalised by specifying in the SLS an array of e.g. N (delay/jitter, quantile)-couples. The more couples, the better the delay probability tail distribution can be approximated. Such a specification together with the eventual need of such a generalisation is for further study. The packet loss probability is ratio of the lost (in-profile) packets between ingress and egress and the offered (in-profile) packets at ingress. TEQUILA consortium Expires December 2001 [Page 12] Internet Draft draft-tequila-sls-01.txt June, 2001 lost packets between (and including) ingress and egress packet loss = ------------------------------------------------------- offered (injected) packets at ingress The ratio is measured over (any) time period with a length equal to the (indicated) time interval. The throughput is the rate measured at egress counting all packets identified by Flow Id. Notice that all packets, independently of their conformance level (in/out-of-profile) contribute. Indeed, if the customer (only) wants a throughput guarantee, then he/she does not care whether in- or out-profile packets are dropped, but is only interested in the overall throughput of its packet stream. Note on the relation with the Traffic Conformance Parameters (section 3.3) in case of a binary-based conformance testing algorithm: - The Traffic Conformance Algorithm (and parameters) MUST be specified when guaranteeing delay/jitter or packet loss, i.e. if one of these performance parameters is quantified in the SLS. Conformance testing is required because the delay/jitter and loss guarantees are only for the stream of in-profile packets. - When only guaranteeing a throughput, or if non-of the other performance parameters is quantified, the traffic conformance algorithm MAY be specified. It is not required to specify the Conformance Algorithm, because the (eventual) troughput guarantee does not require the strict distinction between in/out-of-profile traffic. However, the network operator will probably protect his network by implementing a Traffic Conditioner at Ingress and specifying the token policing rate (r) (almost) equal to the throughput guarantee R, r~R. He may or may not tag/mark excess traffic, according to his own - internal - policy rules. See also example 4.2. Note on the relation between throughput R, packet loss p and excess treatment in case of a binary-based conformance testing algorithm: - First consider the case where excess traffic is dropped (or shaped to in-profile) based on the token bucket (b,r) traffic conformance algorithm. As only in-profile packets are allowed at ingress, the following equality holds: throughput R = (1-p) * token rate r Thus the throughput guarantee can be derived from the loss TEQUILA consortium Expires December 2001 [Page 13] Internet Draft draft-tequila-sls-01.txt June, 2001 probability and token rate and is therefore not an independent parameter. - If excess traffic is allowed (and marked accordingly), then "throughput" is an independent parameter because it also takes into account the out-of-profile packets (measured at egress). One has obviously the inequality: throughput R >= (1-p) * token rate r Quantitative performance guarantees A performance parameter is said to be quantified if its value is specified to a numeric (quantitative) value. The service guarantee offered by the SLS is said to be quantitative IF at least one of the 4 performance parameters is quantified. Qualitative performance guarantees If non of the SLS performance parameters are quantified, then the performance parameters "delay" and "packet loss" MAY be "qualified". Possible qualitative values (for delay and/or loss): high, medium, low. Relative delay guarantees: - gold service : value = low - silver service : value = medium - bronze service : value = high or not indicated Relative loss guarantees - green service : value = low - yellow service : value = medium - red service : value = high or not indicated The quantification of relative difference between is a provider policy (e.g. high = 2 x medium ; medium = 2 x low). The above taxonomy yields the following combinations of qualitative TEQUILA consortium Expires December 2001 [Page 14] Internet Draft draft-tequila-sls-01.txt June, 2001 services. ------------------------------------------------------- |\ delay | | | | | \------| low | medium |high | | loss | | | | |------------------------------------------------------| | low | gold green | silver green | bronze green | | medium | gold yellow | silver yellow | bronze yellow | | high | gold red | silver red | bronze red | |------------------------------------------------------| Combinations table The service guarantee offered by the SLS is said to be qualitative if it is NOT quantitative and either delay or loss (non-exclusive) are qualified to "medium" or "low", i.e. excluding bronze/red from the above. The service guarantee offered by the SLS is said to be best-effort if it is NOT quantified nor qualified. 3.6. Service schedule The service schedule indicates the start time and end time of the service, i.e. when is the service available. This might be expressed as collection of the following parameters: - Time of the day range - Day of the week range - Month of the year range Some examples are: - Time of the day range 08h00-18h00 - Day of the week range A single day A group of sequential days - Month of the year range A single month A group of sequential months TEQUILA consortium Expires December 2001 [Page 15] Internet Draft draft-tequila-sls-01.txt June, 2001 - Year range A single year A group of sequential years Remark: service schedule "from now on" [now, infinity] can be captured by putting the above to their full range. 3.7. Reliability Reliability indicates the maximum allowed mean downtime per year (MDT) and the maximum allowed time to repair (TTR) in case of service breakdown (e.g. in case of cable cut). The Mean Down Time might be expressed in minutes per year and the Maximum Time To Repair might be expressed in seconds. 3.8 Others Other parameters such as route, reporting guarantees, security, scheduled maintenance, etc... remain for further study. 4. Service Level Specifications and Per Domain Behaviours Recently the IETF DiffServ working group has documented in an informational RFC [RFC 3086] the concept of DiffServ Per Domain Behaviours (PDBs). Although this [RFC 3086] clearly specifies the difference between PDBs and SLSs, it is worthwile to further elaborate communalities and differences between PDBs and SLSs. We first recall the DiffServ working group terminology. 4.1 DiffServ Terminology 4.1.1. About Service Level Specifications According to the IETF DiffServ working group, a Service Level Agreement (SLA) is "the documented result of a negotiation between a customer and a provider of an IP service that specifies the levels of availability, serviceability, performance, operation or other attributes of the transport service" [DS-TERMS]. The SLA contains technical and non-technical terms and conditions. The technical specification of the IP connectivity service is given in Service Level Specifications (SLSs). An SLS "is a set of technical parameters and their values, which together define the service, offered to a traffic stream by a DiffServ domain". SLSs describe the traffic characteristics of IP flows and the QoS guarantees offered by TEQUILA consortium Expires December 2001 [Page 16] Internet Draft draft-tequila-sls-01.txt June, 2001 the network to these flows. 4.1.2. About Per Domain Behaviors In [RFC 3086] a "Per Domain Behavior is the expected treatment that an identifiable or target group of packets will receive from "edge- to-edge" of a DS domain. A particular PHB (or, if applicable, list of PHBs) and traffic conditioning requirements are associated with each PDB". "A PDB is characterized by specific metrics that quantify the treatment a set of packets with a particular DSCP (or set of DSCPs) will receive as it crosses a DS domain" 4.1.3. About SLS and PDB relationships [RFC 3086] clearly states that "there is a clear distinction between the definition of a Per-Domain Behavior in a DS domain and a service that might be specified in a Service Level Agreement. The PDB definition is a technical building block...in configuring DS domains, but the PDB (or PDBs) used by a provider is not expected to be visible to customers any more than the specific PHBs employed in the provider's network would be." However, "the measurable parameters of a PDB should be suitable for use in Service Level Specifications at the network edge." Vice versa, SLSs are "expected to include specific values or bounds for PDB parametersd." Therefore SLSs and PDBs are different concepts but there is clearly a relationship between both. We now further elaborate on this relationship. 4.2. SLS and PDB simularities and differences. 4.2.1. A subset of common parameters Both an SLS and a PDB try to capture the technical "terms and conditions" for describing the behavior of an (aggregate) packet stream crossing a (DiffServ) domain. Roughly speaking, if the arriving packet stream behaves appropriately, then the network will treat the packet stream as can be expected (from the SLS or the PDB). Within the context of this draft, the arriving packet stream is identified by a "Flow Identifier", which may be mapped accordingly on PDB Classifiers and packet Filters. "Behaving appropriately" means that the packet stream should be conformant with the Traffic Envelop TEQUILA consortium Expires December 2001 [Page 17] Internet Draft draft-tequila-sls-01.txt June, 2001 (section 3.3). As in a PDB, excess packets are subject to a Traffic Conditioner which may mark, drop or shape these packets. The resulting packet stream, called the foo traffic aggregate in [RFC 3086] is conditioned such that it may expect reasonable treatment in the DS domain. In the context of this draft, the foo traffic aggregate is the "in-profile" stream and should get the QoS performance guarantees as defined in section 3.5. Clearly [RFC 3086] states correctly that (some) paparameters of SLSs should be mapped on PDB characteristics and that (some) PDB parameters should be suitable for SLSs. Undoubtfully the definition of specific PDBs and those of SLS template(s) should be correlated. 4.2.2. Inter-domain interfaces versus intra-domain QoS building blocks At first sight, the simularities between SLSs and PDBs might be dominant. However, it appears so because only intra-domain aspects were discussed. Although SLSs and PDBs may have a common parameter subset, the concepts themselves are substantially different. In summary, an SLS and PDB differ along the following lines: - An SLS is an external interface between two legal entities, i.e. a customer and a provider or a provider-provider. A PDB is a technical intra-domain QoS building block. - An SLS should be (QoS) technology independent while a PDB is clearly a DiffServ concept. For example, as correctly mentioned in RFC [3086], it should be possible to offer "premium IP services" over a Best-Effort network by simply overprovisioning. Thus delay-sensitive services must not necessarily be mapped on a PDB like a "Virtual Wire", but as in the example above, the service may simply use a best-effort "PDB". There is no one to one mapping; the mapping will be determined by the provider policy. (Analogously the mapping of PDB to PHB is not one-to-one neither). - The main use of an SLS is inter-domain, i.e. a unique (standardised) interface for enabling inter-domain QoS. A PDB is by definition single domain. Moreover a service specified by a SLS is not necessarly restricted to one domain. All depends on the established business relations. For example, a network provider may offer (inter-domain) services to a company (e.g. a Virtual Private Network - VPNs) by subcontracting other providers. The SLSs specified between the company and the (main) provider will also span the domains of sub contracters (and the company should even not be aware of it). TEQUILA consortium Expires December 2001 [Page 18] Internet Draft draft-tequila-sls-01.txt June, 2001 - An SLS is itself a (service) building bilding block for constructing (complex) IP transport services. For example, a bi- directional Virtual Leased Line has two SLSs. Multi-edge VPNs may be very complex and require multiple SLSs. In general, an {SLS}- set is needed for describing the technical (QoS & traffic-related) characteristics of an IP transport service. - Finally, an SLS and a PDB also have some distinct parameters. For example, the scope and the service schedule of an SLS specify respectively where (the geographical region) and when this typical service is applicable. It is unlikely that a PDB, as a generic service independent building block, will specify such parameters. 4.3. From PHB to value-added IP services: a layered DiffServ view We end this PDB-SLS discussion by a high-level view on a possible layered ("object") model for describing and enabling value-added IP services over DiffServ networks. ---------------------------------------------| | IP Transport Services - SLA | | - non-technical terms & conditions | | - technical parameters {SLS}-set | |--------------------------------------------| | Service Level Specifications - SLS | | - IP service traffic characteristics | | - offered network QoS guarantees | |--------------------------------------------| | Per Domain Behaviors - PDB | | - network QoS capabilities | | - DiffServ edge-to-edge aggregates | |--------------------------------------------| | Per Hop Behaviors - PHB | | Traffic Conditioning Block - TCB | | - generic router QoS capabilities | | - DiffServ edge & core routers | |--------------------------------------------| | Schedulers (e.g. WFQ, WTP) | | Algorithmic Droppers (e.g. RED) | | Markers (e.g. SRTCM, TRTCM) | | - implementation | | - vendor & product specific | |--------------------------------------------| A layered service-object model for DiffServ Each of the underlying "layers" or "objects" exposes its (QoS) capabilities to the upper layer. Conversely, an upper-layer object TEQUILA consortium Expires December 2001 [Page 19] Internet Draft draft-tequila-sls-01.txt June, 2001 makes use of the lower-layer capabilities and therefore should be mapped onto the lower layer objects. According to [RFC 3086] the specification of a PDB type should e.g.include the (lower-layer) PHB or PHB-group on which the PDB is build. On the othe hand, the mapping of SLSs to PDBs (and therefore PHBs) is a rather unexplored area. For example, it is clear that an SLS is service and customer specific; and is part of the service management system of the provider. A PDB is customer agnostic and could be a prefered object for (longer-term) traffic engineering and resource management. Clearly the mapping from SLS to PDB involves an aggregation policy of the provider, i.e. mapping of customer aware objects to non- custome aware entities. This is a non-straightforward problem. It may be very much determined by the provider policy, but some general "service mapping" and "customer aggregation" guidelines should be very useful. This is for further study. 5. Service Level Specification examples. Within this section a number of example instantiations of SLSs are presented to illustrate the potential use of the SLS template defined above. 5.1. Virtual Leased Line The following specifies the SLS for a (uni-directional) VLL with quantified throughput guarantee of e.g 1 Mbps, a delay guarantee of 20 ms for a 10E-3 quantile and zero packet loss. - Scope: one-to-one communication (Ingress, Egress) specified - Flow identification: (source,destination) IP-addresses, DSCP=EF. - Traffic Conditioning: token bucket (b,r), r = 1 Mbps - Excess Treatment = dropping. Thus only in-profile packets are allowed. - Delay guarantee = (d = 20 ms, t = 5 minutes, q = 10E-3) - Loss guarantee p = 0 (imlying a throughput guarantee R = r) TEQUILA consortium Expires December 2001 [Page 20] Internet Draft draft-tequila-sls-01.txt June, 2001 - Service Schedule: may be indicated - Reliability: may be indicated Notice that in this example, the throughput guarantee is a derived parameter from the packet loss p=0, the the conditioning token bucket parameter r=1 Mbps and the excess treatment=dropping. 5.2 Bandwidth Pipe for data-services The following SLS specifies a bandwidth pipe with a strict throughput guarantee, but with only a loose requirements for packet loss, i.e. "low". Thus, the SLS only mentiones the scope (pipe), the Flow Id and a throughput guarantee. Remark that there are now traffic conformance parameters (and consequently no excess treatment indication). - Scope: one-to-one communication (Ingress, Egress) specified - Flow identification: (source,destination) IP-addresses - Throughput guarantee R = 1 Mbps - Service Schedule: may be indicated - Reliability: may be indicated Although there is no (explicit) traffic conditioning agreement between the customer and the network operator (i.e. not mentioned in the SLS), the operator is likely to protect his network by implementing a traffic conditioner token bucket (b,r). If the operator can guarantee a zero packet loss for the bandwidth pipe, then the token rate equals the throughput guarantee. However, the SLS can also be met by the operator without such a stringent loss requirement, say p = 10E-5. In this case the token rate is derived from the throughput guarantee and the loss probability: token rate r = R / (1-p) The in-profile packet stream (according to the conditioner (b,r)) has a throughput guarantee of R = r * (1-p) = 1 Mbps. Further, it is up to the operator's policy whether or not excess traffic (again according to the operator's conditioner (b,r), which is not mentioned in the SLS agreement) is allowed or not in his network. 5.3. Real-time micro-flows TEQUILA consortium Expires December 2001 [Page 21] Internet Draft draft-tequila-sls-01.txt June, 2001 - Scope: one-to-one communication (Ingress, Egress) specified - Flow identification: (source IP-address, destination IP-address, source port number, destination port number, protocol) - Traffic Conditioning: token bucket (b,r), peak rate p= r = 64 Kbps - Excess Treatment = dropping. - Performance Parameters: delay = 10 msec, packet loss = 10E-6, guaranteed throughput R ~ r. 5.4 Minimum rate guarantee with allowed excess The following could be for bulk FTP traffic that requires a minimum throughput, but would take everything it can get (TCP). Also adaptive applications, like video streaming, that however require a minimum throughput for the service. - Scope: one-to-one (Pipe) - Flow identification: e.g. DSCP-value indicating a possible AF-PBH. - Traffic Conformance Parameters: (b,r) MUST be indicated - Excess Treatment: Remarking MUST be indicated (excess is given a higher drop precedence) - Performance guarantees: guaranteed throughput R = r. 5.5. Qualitative Olympic services The following SLS is meant for the Olympic Service. It could be used for differentiating applications such as web-browsing and e-mail traffic. SLS 1 (on-line web-browsing) - Scope: one-to-one (pipe) or one-to- many (hose) - Flow identification: MAY be indicated - Traffic Conformance Parameters: token parameters (b,r) The token bucket rate r indicates an (average) maximum Committed Information Rate (CIR) for which "better-than-best-effort" treatment will be applied. - Excess Treatment: remarking. TEQUILA consortium Expires December 2001 [Page 22] Internet Draft draft-tequila-sls-01.txt June, 2001 - Performance Parameter: Delay and Packet loss are indicated as "low": gold/green class SLS2 : (background e-mail traffic) This is identical to SLS1 but targeting the silver/green class. 5.6. The Funnel service The service offered by the funnel model is primarily a protection service: the customer wants to set a maximum on the amount of traffic (characterized by a DSCP) entering his network. It could e.g. be used for business customers to restrict the amount of web browsing traffic entering their network. /---------------\ |Network _____|______ B | _____/ | A__________|___.___________|______ C /_____ | _____ | \a(out) | \_____|_______D \---------------/ Figure 4: Funnel model In [Figure 4], the customer A requires that the traffic entering his network from B,C and D does not exceed the rate a_out. - Scope: Funnel (N|all,1). - Flow identification: DSCP MUST be indicated. The filter (see below) is applied to all traffic characterized by the DSCP -value. - Traffic Conformance Parameters: (b, r) MUST be indicated. The token bucket parameters indicate the maximum allowed throughput (r = a_out) towards the customer network on the specified egress interface. This maximum or filter is applied to all packets marked with the DSCP- value indicated above. - Excess treatment: dropping (this is actually the service offered by the network). - Performance Parameter: not specified. 5.7. Best effort traffic - Scope : all models TEQUILA consortium Expires December 2001 [Page 23] Internet Draft draft-tequila-sls-01.txt June, 2001 - Flow identification : none - Traffic Conformance Parameters: if not indicated, then the full link capacity is allowed - Excess Treatment: not specified - Performance Parameters: none - Service Schedule: may be indicated. - Reliability: may be indicated. 6. SLS negotiation requirements [This section is informational and preliminary. More detailed study is required.] A major goal of the availability of an SLS template is helping in the deployment of dynamical SLS negotiation procedures between customer and providers or between providers. This draft only discussed the SLS template and its basic contents. The SLS negotiation protocol is for further study. The following lists a number of conditions which should be met by a (to be defined) SLS negotiation protocol. The SLS negotiation protocol MUST allow for: - Original service requests, according the components of the specified SLS. - Service acknowledgement (ACK), indicating agreement with the requested service level. - Service rejection (NAK) but indicating the possibility of offering a closely related service (or indication of alternative DSCP to use for a particular service). The reply message may indicate the related offering by overwriting the proposed SLS attributes (hints). - Service rejection (REJECT) indicating incapability of providing the service. - The ACK/NACK procedures require a reliable transport mode for such a negotiation protocol. - Service modification from both user and provider. The following are further requirements for the overall network architecture which SHOULD be fulfilled. TEQUILA consortium Expires December 2001 [Page 24] Internet Draft draft-tequila-sls-01.txt June, 2001 - The protocol should be able to interact with feedback of events related to the service. For example performance degradation MAY result in re-negotiation of the SLS. - The protocol should preferentially make use of / be an extension of existing specifications protocol design work available such as RSVP ([RFC-2205]) or PPP/IPCP ([RFC-1661]). 7. Security considerations The information which will yield the instantiation of an SLS template to address the specific requirements of a customer in terms of the quality associated to the service it has subscribed to may require the activation of security features so that: - Identification and authentication of the requesting entity needs to be performed; - Identification and authentication of the peering entities which will participate in the SLS negotiation process needs to be performed; - Preservation of the confidentiality of the information to be conveyed during the SLS negotiation and instantiation procedures between the peering entities is a MUST. 8. Acknowledgements Part of this work has been funded under the European Commission 5th framework IST program. The authors would like to acknowledge all their colleagues in the TEQUILA project for their input and reflection on this work. The authors also would like to acknowledge Werner Almesberger, Marcus Brunner, Stefaan De Cnodder, Stefano Salsano, Alberto Kamienski and Abdul Malick for their useful comments and suggestions on the mailing list sls@ist-tequila.org and during private conversation. References [TEQUILA] IST-Tequila project http://www.ist-tequila.org/ [RFC 1661] "The Point-to-Point Protocol (PPP)", W. Simpson, http://www.ietf.org/rfc/rfc1661.txt?number=1661 TEQUILA consortium Expires December 2001 [Page 25] Internet Draft draft-tequila-sls-01.txt June, 2001 [RFC-1771] A Border Gateway Protocol 4 (BGP-4). Y. Rekhter, T. Li. March 1995. http://www.ietf.org/rfc/rfc2205.txt?number=1771 [RFC 2205] "Resource ReSerVation Protocol (RSVP)- Version 1 Functional Specification", R. Braden et al. http://www.ietf.org/rfc/rfc2205.txt?number=2205 [RFC-2211] J. Wroclawski, "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997. [RFC-2212] S. Shenker, C. Partridge, R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997. [RFC 2474] "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", K.Nichols, S. Blake, F. Baker, D. Black, www.ietf.org/rfc/rfc2474.txt [RFC 2475] "An Architecture for Differentiated Services", S. Blake, D. Black, M.Carlson,E.Davies,Z.Wang,W.Weiss, www.ietf.org/rfc/rfc2475.txt [RFC 2597] "Assured Forwarding PHB Group", F. Baker, J. Heinanen, W. Weiss, J. Wroclawski, www.ietf.org/rfc/rfc2597.txt [RFC 2598] "An Expedited Forwarding PHB", V.Jacobson, K.Nichols, K.Poduri, www.ietf.org/rfc/rfc2598.txt [RFC 2638] "A Two-bit Differentiated Services Architecture for the Internet"[RFC-2638] K. Nichols, V. Jacobson, L. Zhang, July 1999. www.ietf.org/rfc/rfc2638.txt [RFC 2698] "A Two Rate Three Color Marker." J. Heinanen, R. Guerin. September 1999. www.ietf.org/rfc/rfc2698.txt [RFC 3086] "Definition of Differentiated Services Per Domain Behaviors and Rules for their specification". K. Nichols, B. Carpenter April 2001 http://www.ietf.org/rfc/rfc3086.txt [DS-MODEL] "A Conceptual Model for Diffserv Routers", Y. Bernet et al., draft-ietf-diffserv-model-06.txt, Work in Progress, February 2001 [DS-TERMS] "New terminology for diffserv", D. Grossman, draft-ietf- diffserv-new-terms-04.txt, work in progress, March 2001 [QBONE] "Qbone Architecture (v1.0), Ben Teitelbaum (1999), http://www.internet2.edu/qos/wg/papers/qbArch/ TEQUILA consortium Expires December 2001 [Page 26] Internet Draft draft-tequila-sls-01.txt June, 2001 Full copyright statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Authors Addresses Danny Goderis Alcatel Corporate Research Center Fr. Wellesplein 1, 2018 Antwerpen, Belgium. Phone : 32-3-240-7853 Fax : 32-3-240-9932 E-mail: Danny.Goderis@Alcatel.be Yves T'Joens Alcatel Corporate Research Center Fr. Wellesplein 1, 2018 Antwerpen, Belgium. Phone : 32-3-240-7890 Fax : 32-3-240-9932 E-mail: Yves.TJoens@Alcatel.be TEQUILA consortium Expires December 2001 [Page 27] Internet Draft draft-tequila-sls-01.txt June, 2001 Christian Jacquenet France Telecom Research and Development FT R&D /DMI 42, rue des Coutures BP6243 14066 CAEN CEDEX 04 France Tel : +33 2 31 75 94 28 Fax : +33 2 31 73 56 26 e-mail : christian.jacquenet@francetelecom.fr George Memenios Research Associate, Telecommunications Laboratory NTUA Heroon Polytechniou 9 157 73 Zografou, Athens, Greece Phone : +30 1 772 1494 Fax : +30 1 772 2534 E-mail: gmemen@telecom.ntua.gr George Pavlou Centre for Communication Systems Research (CCSR) Univ. of Surrey, Guildford, Surrey GU2 7XH, UK Phone : +44 (0)1483 259480 Fax : +44 (0)1483 876011 E-mail: G.Pavlou@eim.surrey.ac.uk Richard Egan Racal Research Ltd Worton Drive Worton Grange Industrial Estate Reading, Berkshire RG2 OSB tel: +44 118 986 8601 fax: +44 118 923 8399 e-mail : richard.egan@rrl.co.uk David Griffin Department of Electronic and Electrical Engineering University College London Torrington Place, London WC1E 7JE, UK Phone: +44 (0)20 7679 3557 Fax: +44 (0)20 7388 9325 Email: D.Griffin@ee.ucl.ac.uk TEQUILA consortium Expires December 2001 [Page 28] Internet Draft draft-tequila-sls-01.txt June, 2001 Panos Georgatsos Algosystems S.A. 4, Sardeon str., 172 34 Athens, Greece Phone: 30-1-93-10-281 Fax: 30-1-93-52-873 E-mail: pgeorgat@algo.com.gr Leonidas Georgiadis Aristotel Univ. of Thessaloniki, Faculty of Engineering School of Electrical and Computer Engineering, Telecommunications Dept. PO Box 435, Thessaloniki, 54006, Greece Phone: 30-31-996385 Fax: 30-31-996312 E-mail: leonid@eng.auth.gr TEQUILA consortium Expires December 2001 [Page 29]