idnits 2.17.1 draft-tequila-sls-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' scope model puts similar constraints on the source/destination' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 7 Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 692 instances of too long lines in the document, the longest one being 15 characters in excess of 72. ** The abstract seems to contain references ([RFC2638], [RFC2205], [DS-TERMS], [RFC2475], [RFC2597], [RFC2598], [RFC1661], [RFC2698], [RFC-2211], [Figure2], [RFC3086], [RFC-2212], [TEQUILA], [0611], [RFC-2474], [1531], [RFC-2475], [RFC-2597], [DS-MODEL], [RFC-2211,RFC-2212], [RFC-1661], [RFC-2598], [RFC2474]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 43 has weird spacing: '...ocument ident...' == Line 130 has weird spacing: '...". This secti...' == Line 339 has weird spacing: '... access links...' == Line 363 has weird spacing: '... set of sourc...' == Line 986 has weird spacing: '...work by over-...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2002) is 8107 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC 2475' on line 1306 looks like a reference -- Missing reference section? 'DS-TERMS' on line 1332 looks like a reference -- Missing reference section? 'TEQUILA' on line 1285 looks like a reference -- Missing reference section? 'DS-MODEL' on line 1328 looks like a reference -- Missing reference section? 'RFC-2475' on line 392 looks like a reference -- Missing reference section? 'RFC-2598' on line 227 looks like a reference -- Missing reference section? 'RFC-2597' on line 227 looks like a reference -- Missing reference section? 'RFC-1661' on line 340 looks like a reference -- Missing reference section? 'RFC-2474' on line 361 looks like a reference -- Missing reference section? 'RFC 2597' on line 1310 looks like a reference -- Missing reference section? 'RFC-2211' on line 1294 looks like a reference -- Missing reference section? 'RFC-2212' on line 1297 looks like a reference -- Missing reference section? '06 11' on line 783 looks like a reference -- Missing reference section? '15 31' on line 785 looks like a reference -- Missing reference section? 'RFC 3086' on line 1323 looks like a reference -- Missing reference section? 'Figure 2' on line 1208 looks like a reference -- Missing reference section? 'RFC 1661' on line 1287 looks like a reference -- Missing reference section? 'RFC 2205' on line 1290 looks like a reference -- Missing reference section? 'RFC 2474' on line 1301 looks like a reference -- Missing reference section? 'RFC 2598' on line 1313 looks like a reference -- Missing reference section? 'RFC 2638' on line 1316 looks like a reference -- Missing reference section? 'RFC 2698' on line 1320 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 24 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Danny Goderis, Alcatel 3 Internet Draft Sven Van Den Bosch, Alcatel 4 Document: draft-tequila-sls-02.txt Yves T'joens, Alcatel 5 Expires: August - 2002 Olivier Poupel, Alcatel 6 Christian Jacquenet, France 7 Telecom R&D 8 George Memenios, NTUA 9 George Pavlou, UniS 10 Richard Egan, Thales Research Ltd 11 David Griffin, UCL 12 Panos Georgatsos, AlgoSystems 13 Leonidas Georgiadis, Univ. 14 Thessaloniki 15 Pim Van Heuven, IMEC 16 February 2002 18 Service Level Specification Semantics and Parameters 19 21 Status of this Memo 23 This document is an Internet-Draft and is in full conformance 24 with all provisions of Section 10 of RFC2026. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other documents 33 at any time. It is inappropriate to use Internet-Drafts as 34 reference material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Abstract 43 This document identifies the basic information to be handled by 44 Service Level Specifications (SLS, [RFC 2475], [DS-TERMS]) when 45 considering the deployment of value-added IP service offerings over 46 the Internet. IP service offerings can be provided together with a 47 given quality of service (QoS), whose definition can be conveyed in 48 an SLS, from a technical standpoint. Since these IP services are 49 likely to be provided over the whole Internet, their corresponding 50 QoS will be based upon a set of technical parameters that both 51 customers and network providers will have to agree upon. From this 52 Semantics and Parameters 54 perspective, this draft aims at listing (and promoting a standard 55 formalism for) a set of basic parameters which will actually compose 56 the elementary contents of an SLS. 58 Such a specification effort tries to address the following concerns: 60 - Provide a standard set of information to be negotiated 61 between a customer and a network provider or between network 62 providers; 64 - Provide the corresponding semantics of such information, so 65 that it might be appropriately modeled and processed by the 66 above-mentioned parties (in an automated fashion). 68 Table of Contents 70 Status of this Memo................................................1 71 Abstract...........................................................1 72 Table of Contents..................................................2 73 0 Conventions used in this document..............................3 74 1 Introduction...................................................3 75 1.1 Changes w.r.t. the previous version..........................3 76 1.2 Motivation...................................................3 77 1.3 Objectives...................................................4 78 2 Basic assumption and terminology...............................5 79 3 SLS content & template.........................................5 80 3.1 SLS Identification...........................................5 81 3.2 Scope........................................................6 82 3.3 Flow Identification..........................................7 83 3.4 Traffic Envelop and Traffic Conformance......................9 84 3.5 Excess Treatment............................................11 85 3.6 Performance Guarantees......................................11 86 3.7 Service schedule............................................15 87 3.8 Reliability.................................................16 88 3.9 Monitoring..................................................16 89 3.10 Others.....................................................17 90 4 Service Level Specifications and Per Domain Behaviours........17 91 4.1 DiffServ Terminology........................................18 92 4.1.1 About Service Level Specifications.........................18 93 4.1.2 About Per Domain Behaviors.................................18 94 4.1.3 About SLS and PDB relationships............................18 95 4.2 SLS and PDB similarities and differences....................19 96 4.2.1 A subset of common parameters..............................19 97 4.2.2 External interfaces versus intra-domain QoS building blocks 19 98 4.3 From PHB to value-added IP services: a layered DiffServ view 20 99 5 Service Level Specification examples..........................21 100 Semantics and Parameters 102 5.1 Virtual Leased Line.........................................21 103 5.2 Bandwidth Pipe for data-services............................22 104 5.3 Minimum rate guarantee with allowed excess..................22 105 5.4 Qualitative Olympic services................................23 106 5.5 The Funnel service..........................................23 107 5.6 Best effort traffic.........................................24 108 6 SLS negotiation requirements..................................24 109 7 Security Considerations.......................................24 110 8 Acknowledgment................................................25 111 References........................................................25 112 Author's Addresses................................................26 113 Full Copyright Statement..........................................28 115 0 Conventions used in this document 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 119 this document are to be interpreted as described in RFC 2119. 121 1 Introduction 123 1.1 Changes w.r.t. the previous version 125 This is the fourth version of an Internet Draft on the issue of 126 Service Level Specifications (SLSs). This version contains some 127 editorial changes, some additions of parameters for identification 128 and monitoring, new service scheduling parameters and an update of 129 the section 4 entitled "Service Level Specifications and Per Domain 130 Behaviors". This section discusses the similarities and differences 131 between SLSs and PDBs. Also some minor editing changes and reference 132 updates have been incorporated in this version. 134 1.2 Motivation 136 This document is presented to the IETF community to gauge the 137 interest for advancing the work on the specification of an SLS 138 definition, its semantics and its potential negotiation protocol(s). 139 The deployment of QoS-based value-added IP services over the global 140 Internet is one of the most exciting challenges that the network 141 providers try to currently address, especially when considering the 142 deployment of such service over administrative domains. From this 143 standpoint, it seems useful to consider the specification of an SLS 144 template these network providers would agree upon, so as e.g. to 145 facilitate the enforcement of an inter-domain QoS policy. 147 Semantics and Parameters 149 1.3 Objectives 151 This document presents an outline for the definition of the Service 152 Level Specification parameters and the semantics that go behind this 153 representation for a transport service. 155 The need to have such an agreed set of Service Level Specification 156 parameters and semantics is manifold. 158 First, it is necessary to be able to allow for a highly developed 159 level of automation and dynamic negotiation of Service Level 160 Specifications between customers and network providers. Automation 161 and dynamics are indeed helpful in providing customers (as well as 162 providers) the technical means for the dynamic provisioning of 163 quality of service configuration information. 165 Second, the design and the deployment of QoS-aware and capable 166 Network and Element Management system in a multi-vendor environment 167 requires a standardized set of semantics for Service Level 168 Specifications being negotiated at different locations, such as: 170 - within an administrative domain (for intra-domain SLS 171 negotiation purposes); 173 - between the customer and the network provider, where the 174 customer might be e.g. a company, an application service 175 provider (e.g. a voice over IP provider), another network 176 provider, etc. 178 - between administrative domains (for inter-domain negotiation 179 purposes). 181 While the representation and semantics behind a Service Level 182 Specification need to be standardized, this document does not assume 183 that the syntax, nor the SLS negotiation protocol need to be 184 uniquely defined. The SLS negotiation protocol and associated 185 requirements is out of scope of this document. 187 The document is structured as follows. 189 Section 2 lists the basic assumptions underlying this work and some 190 terminology. 192 Section 3 describes the parameters of the Service Level 193 Specification (template) for a transport service. This draft only 194 describes the semantics of the SLS-parameters, omitting all 195 implementation details as for instance the parameter data types (at 196 this moment). 198 Section 4 provides some examples of relevant SLS specifications, 199 with the aim to show the usage of the templates. The SLS formalism 200 defined in section 3 allows making a distinction between qualitative 201 and quantitative SLSs: 203 Semantics and Parameters 205 - SLSs depicting qualitative services should yield the 206 specification of relative QoS indicators, such as a "low" IP 207 packet loss. From this standpoint, best effort traffic is 208 expected to be qualified by an SLS of that range of 209 qualitative services. 211 - SLSs depicting quantitative services should yield the 212 accurate measurement of QoS indicators, such as e.g., transit 213 delay. 215 Sections 5 and 6 finally describe some SLS (protocol) negotiation 216 requirements and security considerations respectively. 218 The material presented in this draft derives from work within the 219 IST-TEQUILA project [TEQUILA]. 221 2 Basic assumption and terminology 223 The basic assumption of this draft is that IP services will be 224 deployed over a public IP infrastructure, which will be (partly if 225 not completely) composed of diffserv-aware network elements ([RFC- 226 2475], [DS-MODEL]). These network elements are able to implement Per 227 Hop Behaviors (PHBs), including the Assured Forwarding PHB ([RFC- 228 2597]), and the Expedited Forwarding PHB ([RFC-2598]. 230 In this document, the owner of the transport network equipment, i.e. 231 the IP network, is called network provider. The network provider 232 offers IP transport services to its customers. The IP transport 233 services are technically described by SLSs. The customers of the 234 network provider may be corporates, application service providers 235 (themselves offering e.g. voice or video to residential users) or 236 other network providers. 238 The terminology used in this draft is in agreement with the DiffServ 239 Working Group terminology introduced in [RFC-2475], section 1.2 240 "terminology" and further specified in [DS-TERMS]). 242 3 SLS content & template 244 The following describes the attributes of the Service Level 245 Specification. 247 3.1 SLS Identification 249 The SLS Identification is a field used by the service provider and 250 the customer to identify the SLS and the service the SLS is related 251 to. 253 Semantics and Parameters 255 SLS Identification = (SLS Id, Service Id) 257 - SLS Id: This is the parameter identifying the SLS 259 - Service Id: This the parameter identifying the service the 260 SLS is related to. 262 The SLS Identification is mainly dedicated to the classification of 263 multiple SLSs that can composed a service. 265 3.2 Scope 267 The scope of an SLS associated to a given service offering indicates 268 where the Quality of Service (QoS) policy for that specific service 269 offering is to be enforced. Therefore the scope uniquely identifies 270 the geographical/topological region over which the QoS is to be 271 enforced by indicating the boundaries of that region. 273 An SLS is associated with uni-directional traffic flows. Note 274 however that this does not exclude the provisioning of bidirectional 275 technical agreements, by combining one or more SLSs. 277 The associated scope of the SLS MUST be expressed by a couple of 278 ingress and egress interfaces. Ingress/egress denote respectively 279 the entry/exit points of the IP packets relative to the region 280 (network). 282 Scope = (ingress, egress) with ingress/egress defined as 284 - Ingress: interface identifier | set of interface identifiers 285 | any 287 - Egress : interface identifier | set of interface identifiers 288 | any 290 Remarks: 292 - "|" denotes an exclusive OR. 294 - "any" is logically equivalent with unspecified. 296 The following combinations of (ingress, egress) interfaces are 297 allowed: 299 - (1,1) - one-to-one communication 301 - (1,N) - one-to-many communication (N>1) 303 - (1,any) - one-to-any communication 304 Semantics and Parameters 306 - (N,1) - many-to-one communication (N>1) 308 - (any,1) - any-to-one communication 310 The above taxonomy excludes the many-to-many communication (M,N). 311 Either ingress OR egress MUST be specified to exactly ONE interface 312 identifier (with a non-exclusive OR). Many-to-many communication 313 (M,N) can be decomposed into M times one-to-many communication 314 (1,N). 316 This taxonomy SHOULD avoid all ambiguity about the IP flow (defined 317 as a set of IP datagrams sharing at least one common characteristic, 318 like e.g. the same [source address; destination address] pair), and 319 its corresponding identification. (see section 3.2 and 3.3). If the 320 ingress is a single interface identifier, then the traffic envelop 321 and flow id concerns the incoming IP packet stream at the unique 322 ingress point. If (only) the egress is a single interface, i.e. 323 (N|any,1), then the traffic envelop and flow id concerns the 324 outgoing (aggregate) traffic on the egress link. More details about 325 the latter can be found in the example given in section 4.5. 327 In the remaining part of this document SLSs with an associated scope 328 (topology) of (1,1) ; (1,N) ; (N,1) will be called respectively 329 Pipe, Hose and Funnel SLSs. 331 Disclaimer: 333 An ingress (or egress) interface identifier should uniquely 334 determine the boundary link as defined in [RFC-2475] on which 335 packets arrive/depart at the border of a DS domain. This link 336 identifier MAY be an IP address, but it may also be any other 337 mutually agreed upon identifier which uniquely identifies a boundary 338 link. For example a layer-two identifier in case of Ethernet or 339 unnumbered PPP-based access links in (Point-to-Point Protocol, 340 [RFC-1661]). 342 3.3 Flow Identification 344 The flow identification (Flow Id) of an SLS associated to a given 345 service offering indicates for which IP packets the QoS policy for 346 that specific service offering is to be enforced. 348 A Flow Id identifies a stream of IP datagrams sharing at least one 349 common characteristic. An SLS contains one (and only one) Flow Id, 350 which MAY formally be specified by providing one or more of the 351 following attributes: 353 Flow Id = (Differentiated Services information, source information, 354 destination information, application information) 356 - Differentiated Services information = DSCP value | set of 357 DSCP values | any 358 Semantics and Parameters 360 The Differentiated Services Code Point (DSCP) IP header field 361 is defined in [RFC-2474]. 363 - Source information = source address | set of source 364 addresses | source prefixe | set of source prefixes | any 366 - Destination information = destination address | set of 367 destination addresses | destination prefixe | set of 368 destination prefixes | any 370 - Application information = protocol number | protocol number 371 and source port, destination port | any 373 Note: "any" is again logically equivalent with unspecified. 375 Thus, the Flow Id may be expressed by information attributes related 376 to the source/destination nodes, the application or the DS field in 377 the IP header. The Flow Id provides the necessary information for 378 classifying the packets at a DS boundary node. 380 This datagram classification can either reflect a Behaviour 381 Aggregate (BA) or Multi-Field (MF)classification. 383 In case of MF-classification all attributes MAY be specified, 384 including the DSCP field. MF classification may depict as well 385 micro-flows as aggregate macro-flows, based on e.g. source network 386 prefix [DS-MODEL]. Also the "set-of" semantics allows for the 387 specification of aggregate flows. If a Flow Id is e.g. specified by 388 a set of two IP source addresses, then any packet with either of the 389 two concerned source addresses in its header belongs to the IP 390 packet stream identified by Flow Id. 392 In case of BA-classification [RFC-2475], the DSCP attribute MUST be 393 specified and the other attributes MUST NOT be specified. If a set 394 of DSCP-values is specified, then any packet having a DSCP belonging 395 to this set is part of the Flow Id packet stream. As an example 396 consider an Ordered Aggregate (OA) IP packet stream of a particular 397 Assured Forwarding Class AFx (AF1,AF2,AF3,AF4 - see [RFC 2597]). 398 This stream could be specified within one Flow Id using three DSCP- 399 values, indicating the three drop precedences levels. 401 It should however be noticed that the DSCP-value(s) specified in the 402 SLS has (have) as such nothing to do with the DSCP-marking of 403 packets inside the DiffServ network. The latter, i.e. the "interior" 404 DSCP is used for differentiating packets according to Per Hop 405 Behaviours (PHBs). The former, i.e. the "ingress" DSCP value 406 (specified in the SLS), is just another way of identifying a packet 407 stream, eventually in combination with other IP header fields. At 408 the ingress DiffServ node (incoming) packets are classified based on 409 the "ingress" DSCP value (amongst others), after which they may be 410 re-marked by the "interior" DSCP-value. 412 Semantics and Parameters 414 Finally note also that the IP routing scheme MAY put restrictions on 415 combining scope and flow identification within an SLS. 417 In general, if (only) Flow ID is specified by source and destination 418 IP address (IP-src, IP-dest), and the scope is unspecified, then 419 there is no a-priori assumption about the actual ingress/egress 420 points that this traffic will cross. Indeed, it is the 421 responsibility of the network provider to define the most 422 appropriate route for this traffic, by enforcing the corresponding 423 traffic engineering and routing policies. Thus, the (ingress, 424 egress) information (which in this case is NOT part of the SLS 425 template instance) is then derived from the Flow Id and the routing 426 policy of the network provider. 428 On the other hand, if both Flow Id AND scope are specfied in the 429 SLS, resp. by the pairs (IP-src, IP-dest) and (IP-ingr, IP-egr) 430 pairs then it is clear that the IP packets MUST follow the route 431 (IP-src,...,IP-ingr,...,IP-egr,...,IP-dest). Thus the restriction is 432 that the scope (IP-ingr, IP-egr) is part of the route from IP-scr to 433 IP-dest. 435 Also remark that the exclusion of the many-to-many communication 436 scope model puts similar constraints on the source/destination 437 fields of the Flow Identification. 439 3.4 Traffic Envelop and Traffic Conformance 441 The traffic envelop describes the traffic (conformance) 442 characteristics of the IP packet stream identified by the Flow Id. 443 The traffic envelop is a set of Traffic Conformance Parameters, 444 describing how the packet stream should look like to get the 445 guarantees indicated by the performance parameters (defined in 446 section 3.5) 448 The Traffic Conformance Parameters are the basic input for the 449 Traffic Conformance Algorithm. Traffic Conformance Testing is the 450 combination of the Traffic Conformance Parameters and the Traffic 451 Conformance Algorithm. This will usually be done at a DS-boundary 452 node. 454 The algorithm and the conformance test can be binary-based or multi- 455 level based. 457 Binary Traffic Conformance Testing is a set of actions which 458 uniquely identifies the "in-profile" and "out-of profile" (or 459 excess) packets of an IP stream (identified by Flow-Id). In this 460 case the Traffic Conformance Parameters describe the reference 461 values the traffic (identified by the Flow ID.) will have to comply 462 with, thus yielding the notions of "in" and "out" of profile 463 traffics. The Traffic Conformance Algorithm is the mechanism 464 enabling unambiguously to identify all "in" or "out" of profile 465 packets based on these Conformance parameters. 467 Semantics and Parameters 469 In case of multi-level (n) Traffic Conformance Testing a packet will 470 be tagged (by the algorithm) as belonging to a particular level 471 (1...n). Packets tagged as level n are called "excess" packets. 473 The SLS MUST indicate the concerned level (n) of the conformance 474 testing algorithm: 476 - Multi-level conformance testing n (integer) 478 The following gives a (non-exhaustive) list of potential conformance 479 parameters. 481 - Peak rate p (bits per second) 483 - Token bucket rate r (bits per second) 485 - Bucket depth b (bytes) 487 - Maximum Transfer Unit (MTU) M (bytes) 489 - Minimum packet size (bytes) 491 Binary-based Traffic Conformance Testing examples: 493 - Conformance parameters = token bucket parameters (b,r); 494 conformance algorithm = token bucket algorithm. 496 - Conformance parameters = token bucket parameters and peak 497 rate (b,r,p) with p larger than r; conformance algorithm = 498 the combined token bucket (b,r) and (b,p). This is the 499 conformance test for Integrated Services Controlled Load and 500 Guaranteed Service IP flows in the IntSer QoS architecture 501 [RFC-2211, RFC-2212]. The scheme permits bursty traffic to be 502 sent, limited to a burst of b bytes, with a (long-term) 503 average rate of r and a peak rate of no more than p. 505 - Conformance parameters = MTU; conformance algorithm = all 506 packets allowed with size smaller than MTU; packets larger 507 than MTU are fragmented or dropped. 509 Three-level based Traffic Conformance Testing example 511 - The Two-rate Three-colour marker is based on two token 512 buckets with rates r1 and r2 (r2 being greater than r1), 513 containing respectively green and yellow tokens. The simplest 514 operational mode is the "colour-blank" mode. A packet is 515 tagged "green" if there are green and yellow tokens 516 available, yellow if only yellow tokens are available and 517 otherwise it is tagged red. 519 Semantics and Parameters 521 3.5 Excess Treatment 523 This section describes how the network provider will process excess 524 traffic, i.e. out-of-profile traffic (in case of binary conformance 525 testing) or n-level traffic (in case of n-level conformance 526 testing). The process takes place after Traffic Conformance Testing, 527 described previously. 529 Excess traffic may be dropped, shaped and/or remarked. The SLS MUST 530 specify the appropriate action by the following attribute. 532 - Excess Treatment 534 If Excess Treatment is not indicated, then excess traffic is 535 dropped. Depending on the appropriate action, more parameters MAY be 536 required The following is an indication in case of binary 537 conformance testing. Multi-level conformance testing (like the 538 definition of a hierarchical drop preference model) MAY also be 539 enforced, but this concern has been left for further study. 541 - If excess traffic is dropped, then all packets marked as 542 "out-of-profile" by the Traffic Conformance Algorithm are 543 dropped. No extra parameters are needed. 545 - If excess traffic is shaped, then all packets marked as "out- 546 of-profile" by the Traffic Conformance Algorithm are delayed 547 until they are "in-profile". The shaping rate is the 548 policing/token bucket rate r. The extra parameter is the 549 buffer size of the shaper. 551 - If excess traffic is marked or remarked, then all packets 552 marked as "out-of-profile" by the the Traffic Conformance 553 Algorithm are (re-) marked with a particular DSCP-value 554 (yellow or red). The extra parameter is the DSCP. 556 3.6 Performance Guarantees 558 The performance parameters describe the service guarantees the 559 network offers to the customer for the packet stream described by 560 the Flow Id and within the limits of the geographical/topological 561 extent given by the scope. 563 There are four performance parameters: 565 - one-way transit delay, optional quantile 567 - packet delay variation or jitter, optional quantile 569 - packet loss 571 - throughput 572 Semantics and Parameters 574 Delay, jitter and packet loss guarantees are for the in-profile 575 traffic in case of binary conformance testing. For multi-level (n) 576 conformance testing, delay, jitter and loss guarantees MAY be 577 specified for each conformance level-i, except the last one (n). For 578 example if n = 3, one can have a delay guarantee for the 579 "conformance level-1" packets and a different delay guarantee for 580 the "conformance level-2" packets. No guarantees are given for 581 excess ("conformance level-n") traffic. 583 The throughput is an overall guarantee for the IP packet stream, 584 independent of a particular level (see below). 586 The following definitions always consider the (measurable) 587 performance parameters related to the packet stream specified by the 588 Flow Id. For simplicity the definitions below are given for binary 589 conformance testing (n=2), but generalisation is straightforward. 591 The delay and jitter indicate respectively the maximum packet 592 transfer delay and packet transfer delay variation from ingress to 593 egress. 595 Delay and jitter may either be specified as worst case 596 (deterministic) bounds or as quantiles. Indeed, the worst case 597 delay/jitter bounds will be very rare events and customers may find 598 measurements of e.g. 99.5th percentile a more relevant empirical 599 gauge of delay/jitter. 601 Suppose e.g. that the SLS specifies the triple (delay = 10ms, 602 quantile = 10E-3). Then the probability that the transfer delay of a 603 packet (between ingress-egress) is larger than 10ms, is less than 604 10E-3. 606 The above syntax for delay/jitter can be generalised by specifying 607 in the SLS an array of e.g. N (delay/jitter, quantile)-couples. The 608 more couples, the better the delay probability tail distribution can 609 be approximated. Such a specification together with the eventual 610 need of such a generalisation is for further study. 612 The packet loss probability is ratio of the lost (in-profile) 613 packets between ingress and egress and the offered (in-profile) 614 packets at ingress. 616 lost packets between (& including) ingress and egress 617 packet loss = ------------------------------------------------------ 618 offered (injected) packets at ingress 620 The throughput is the rate measured at egress counting all packets 621 identified by Flow Id. Notice that all packets, independently of 622 their conformance level (in/out-of-profile) contribute. Indeed, if 623 the customer (only) wants a throughput guarantee, then he/she does 624 not care whether in- or out-profile packets are dropped, but is only 625 interested in the overall throughput of its packet stream. 627 Semantics and Parameters 629 Note on the relation with the Traffic Conformance Parameters 630 (section 3.3) in case of a binary-based conformance testing 631 algorithm: 633 - The Traffic Conformance Algorithm (and parameters) MUST be 634 specified when guaranteeing delay/jitter or packet loss, i.e. 635 if one of these performance parameters is quantified in the 636 SLS. Conformance testing is required because the delay/jitter 637 and loss guarantees are only for the stream of in-profile 638 packets. 640 - When only guaranteeing a throughput, or if non-of the other 641 performance parameters is quantified, the traffic conformance 642 algorithm MAY be specified. It is not required to specify the 643 Conformance Algorithm, because the (eventual) throughput 644 guarantee does not require the strict distinction between 645 in/out-of-profile traffic. However, the network operator will 646 probably protect his network by implementing a Traffic 647 Conditioner at Ingress and specifying the token policing rate 648 (r) (almost) equal to the throughput guarantee R, r~R. He 649 may or may not tag/mark excess traffic, according to his own 650 - internal - policy rules. See also example 4.2. 652 Note on the relation between throughput R, packet loss p and excess 653 treatment in case of a binary-based conformance testing algorithm: 655 - First consider the case where excess traffic is dropped (or 656 shaped to in-profile) based on the token bucket (b,r) traffic 657 conformance algorithm. As only in-profile packets are allowed 658 at ingress, the following equality holds: 660 throughput R = (1-p) * token rate r 662 Thus the throughput guarantee can be derived from the loss 663 probability and token rate and is therefore not an independent 664 parameter. 666 - If excess traffic is allowed (and marked accordingly), then 667 "throughput" is an independent parameter because it also 668 takes into account the out-of-profile packets (measured at 669 egress). One has obviously the inequality: 671 throughput R >= (1-p) * token rate r 673 Quantitative performance guarantees 675 A performance parameter is said to be quantified if its value is 676 specified to a numeric (quantitative) value. 678 The service guarantee offered by the SLS is said to be quantitative 679 IF at least one of the 4 performance parameters is quantified. 681 Semantics and Parameters 683 Qualitative performance guarantees 685 If non of the SLS performance parameters are quantified, then the 686 performance parameters "delay" and "packet loss" MAY be "qualified". 688 Possible qualitative values (for delay and/or loss): high, medium, 689 low. 691 Relative delay guarantees: 693 - gold service : value = low 695 - silver service : value = medium 697 - bronze service : value = high or not indicated 699 Relative loss guarantees 701 - green service : value = low 703 - yellow service : value = medium 705 - red service : value = high or not indicated 707 The quantification of relative difference between 708 is a matter of provider's policy (e.g. high = 2 x medium ; medium = 709 2 x low). 711 The above taxonomy yields the following combinations of qualitative 712 services (Table 1). 714 |------------------------------------------------------| 715 |\ delay | | | | 716 | \------| low | medium | high | 717 | loss | | | | 718 |------------------------------------------------------| 719 | low | gold green | silver green | bronze green | 720 | medium | gold yellow | silver yellow | bronze yellow | 721 | high | gold red | silver red | bronze red | 722 |------------------------------------------------------| 723 Table 1: Combinations table 725 The service guarantee offered by the SLS is said to be qualitative 726 if it is NOT quantitative and either delay or loss (non-exclusive) 727 are qualified to "medium" or "low", i.e. excluding bronze/red from 728 the above. 730 The service guarantee offered by the SLS is said to be best-effort 731 if it is NOT quantified nor qualified. 733 Semantics and Parameters 735 3.7 Service schedule 737 The service schedule indicates the start and the end of the service, 738 i.e. when the service is available. 740 The Service schedule MAY be specified with the following parameters: 742 Service schedule = (Start date, End date, MonthMask, DayMask, 743 TimeMask) 745 - Start date: Date and hour from which the service becomes 746 available. 748 - End date: Date and hour from which the service becomes 749 unavailable. 751 Start date and End date MUST be specified and End date MUST be 752 greater than End date. 754 Remark: service schedule "from now on" [now, infinity] can be 755 captured by putting the above to their full range. 757 - MonthMask: Month of the year range | set of Month of the year 758 range 760 - DayMask: Day of the month range | set of Day of the month 761 range 763 - TimeMask: Time of the day range | set of Time of the day 764 range 766 An SLS is active between the Start date and the End date. MonthMask, 767 DayMask and TimeMask MAY be specified to refine the periods of 768 activation of the SLS. 770 MonthMask, DayMask and TimeMask respectively identify the months of 771 the year, the days of the month and the time of the day in which the 772 SLS is valid. 774 For example, to define an SLS from the 01/01/02 at 0:00AM to 775 12/31/05 at 11:59PM, in January, March, and from June to November, 776 only the second half of these months, from 2:00AM to 7:00AM and from 777 8:00PM to 11:00PM, the Service schedule is specified as follow: 779 - Start date: (01012002, 00:00:00AM) 781 - End Date: (12312005, 11:59:59PM) 783 - MonthMask: (01, 03, [06 11]) 785 - DayMask: ([15 31] 786 Semantics and Parameters 788 - TimeMask: ([02:00:00AM 07:00:00AM], [08:00:00PM 11:00:00PM]) 790 3.8 Reliability 792 Reliability indicates the maximum allowed mean downtime per year 793 (MDT) and the maximum allowed time to repair (TTR) in case of 794 service breakdown (e.g. in case of cable cut). 796 The Mean Down Time might be expressed in minutes per year and the 797 Maximum Time To Repair might be expressed in seconds. 799 3.9 Monitoring 801 The monitoring indicates the QoS parameters that have to be 802 monitored and reported. They will be applied on the set of 803 interfaces defined in the Scope block of the SLS Template. 805 The monitoring part is composed of the following parameters: 807 - Delay Measurement Period: Describes the period for measuring 808 the delay. 810 - Delay Reporting: Indicates when the delay measurement reports 811 have to be sent to the customer. 813 - Delay Notification Threshold: Indicates a delay threshold 814 that triggers a notification to the customer if the threshold 815 is reached. 817 - Jitter Measurement Period: Describes the period for measuring 818 the jitter. 820 - Jitter Reporting: Indicates when the jitter measurement 821 reports have to be sent to the customer. 823 - Jitter Notification Threshold: Indicates a jitter threshold 824 that triggers a notification to the customer if the threshold 825 is reached. 827 - Packet Loss Measurement Period: Describes the period for 828 measuring the packet loss. 830 - Packet Loss Reporting: Indicates when the packet loss 831 measurement reports have to be sent to the customer. 833 - Packet Loss Notification Threshold: Indicates a packet loss 834 threshold that triggers a notification to the customer if the 835 threshold is reached. 837 Semantics and Parameters 839 - Throughput Measurement Period: Describes the period for 840 measuring the throughput. 842 - Throughput Reporting: Indicates when the packet loss 843 measurement reports have to be sent to the customer. 845 - Throughput Notification Threshold: Indicates a throughput 846 threshold that triggers a notification to the customer if the 847 threshold is reached. 849 - Maximum outage time: Indicates the duration of outage that is 850 allowed for any interfaces described in the Scope. If the 851 value overtakes the threshold, the provider sends a 852 notification describing this event to the customer. 854 - Maximum bandwidth: Indicates the maximum bandwidth that can 855 be used on any interface described in the Scope. If the value 856 overtakes the threshold, the provider sends a notification 857 describing this event to the customer. Maximum Bandwidth 858 utilization reflects the maximum bandwidth usage that is set 859 on each interfaces. It indicates a percentage of the capacity 860 bandwidth of the interface (if speed SNMP variable). 862 - Total number of outage: Indicates for each interface 863 described in the Scope the maximum number of outage 864 authorized. If the value overtakes the threshold, the 865 provider sends a notification describing this event to the 866 customer 868 - Reporting Document Type: Describes which kind of documents 869 have to be sent to the customer (word, excel, HTML, etc.). 871 - Reporting Destination Address: Indicates where the provider 872 has to send the reports (email, postal, fax, etc.). 874 3.10 Others 876 Other parameters such as route, security, scheduled maintenance, 877 etc... remain for further study. 879 4 Service Level Specifications and Per Domain Behaviours 881 Recently the IETF DiffServ working group has documented in an 882 informational RFC [RFC 3086] the concept of DiffServ Per Domain 883 Behaviours (PDBs). Although this [RFC 3086] clearly specifies the 884 difference between PDBs and SLSs, it is worthwile to further 885 elaborate communalities and differences between PDBs and SLSs. 887 We first recall the DiffServ working group terminology. 889 Semantics and Parameters 891 4.1 DiffServ Terminology 893 4.1.1 About Service Level Specifications 895 According to the IETF DiffServ working group, a Service Level 896 Agreement (SLA) is "the documented result of a negotiation between a 897 customer and a provider of an IP service that specifies the levels 898 of availability, serviceability, performance, operation or other 899 attributes of the transport service" [DS-TERMS]. 901 The SLA contains technical and non-technical terms and conditions. 902 The technical specification of the IP connectivity service is given 903 in Service Level Specifications (SLSs). An SLS "is a set of 904 technical parameters and their values, which together define the 905 service, offered to a traffic stream by a DiffServ domain". SLSs 906 describe the traffic characteristics of IP flows and the QoS 907 guarantees offered by the network to these flows. 909 4.1.2 About Per Domain Behaviors 911 In [RFC 3086] a "Per Domain Behavior is the expected treatment that 912 an identifiable or target group of packets will receive from "edge- 913 to-edge" of a DS domain. A particular PHB (or, if applicable, list 914 of PHBs) and traffic conditioning requirements are associated with 915 each PDB". 917 "A PDB is characterized by specific metrics that quantify the 918 treatment a set of packets with a particular DSCP (or set of DSCPs) 919 will receive as it crosses a DS domain" 921 4.1.3 About SLS and PDB relationships 923 [RFC 3086] clearly states that "there is a clear distinction between 924 the definition of a Per-Domain Behavior in a DS domain and a service 925 that might be specified in a Service Level Agreement. The PDB 926 definition is a technical building block...in configuring DS 927 domains, but the PDB (or PDBs) used by a provider is not expected to 928 be visible to customers any more than the specific PHBs employed in 929 the provider's network would be." 931 However, "the measurable parameters of a PDB should be suitable for 932 use in Service Level Specifications at the network edge." 934 Vice versa, SLSs are "expected to include specific values or bounds 935 for PDB parametersd." 937 Therefore SLSs and PDBs are different concepts but there is clearly 938 a relationship between both. We now further elaborate on this 939 relationship. 941 Semantics and Parameters 943 4.2 SLS and PDB similarities and differences. 945 4.2.1 A subset of common parameters 947 Both an SLS and a PDB try to capture the technical "terms and 948 conditions" for describing the behavior of an (aggregate) packet 949 stream crossing a (DiffServ) domain. Roughly speaking, if the 950 incoming packet stream behaves appropriately, then the network will 951 treat the packet stream as can be expected (from the SLS or the 952 PDB). 954 Within the context of this draft, the incoming packet stream is 955 identified by a "Flow Identifier", which may be mapped accordingly 956 on PDB classifiers and packet filters. "Behaving appropriately" 957 means that the packet stream should be conformant with the Traffic 958 Envelop (section 3.3). As in a PDB, excess packets are subject to a 959 Traffic Conditioner which may mark, drop or shape these packets. 961 The resulting packet stream, called the foo traffic aggregate in 962 [RFC 3086] is conditioned such that it may expect reasonable 963 treatment in the DS domain. In the context of this draft, the foo 964 traffic aggregate is the "in-profile" stream and should get the QoS 965 performance guarantees as defined in section 3.5. 967 Clearly [RFC 3086] states correctly that (some) paparameters of SLSs 968 should be mapped on PDB characteristics and that (some) PDB 969 parameters should be suitable for SLSs. Obviously the definition of 970 specific PDBs and those of SLS template(s) should be correlated. 972 4.2.2 External interfaces versus intra-domain QoS building blocks 974 Although SLSs and PDBs may have a common parameter subset, the 975 concepts themselves are substantially different. 977 In summary, an SLS and PDB differ along the following lines: 979 - An SLS is an external interface between two legal entities, 980 i.e. a customer and a provider. A PDB is a technical intra- 981 domain QoS building block. 983 - An SLS should be (QoS) technology independent while a PDB is 984 clearly a DiffServ concept. For example, as mentioned in [RFC 985 3086], it should be possible to offer "premium IP services" 986 over a Best-Effort network by over-provisioning the network 987 resources. Thus delay-sensitive services must not necessarily 988 be mapped on a PDB like a "Virtual Wire", but as in the 989 example above, the service may simply use a best-effort 990 "PDB". There is no one to one mapping; the mapping will be 991 determined by the provider policy. (Analogously the mapping 992 of PDB to PHB is not one-to-one neither). 994 - An SLS is itself a (service) building bilding block for 995 constructing (complex) IP transport services. For example, a 996 Semantics and Parameters 998 bi-directional Virtual Leased Line has two SLSs. Multi-edge 999 VPNs may be very complex and require multiple SLSs. In 1000 general, an {SLS}-set is needed for describing the technical 1001 (QoS & traffic-related) characteristics of an IP transport 1002 service. 1004 - Finally, an SLS and a PDB also have some distinct parameters. 1005 For example, the scope and the service schedule of an SLS 1006 specify respectively where (the geographical region) and when 1007 this typical service is applicable. It is unlikely that a 1008 PDB, as a generic service independent building block, will 1009 specify such parameters. 1011 4.3 From PHB to value-added IP services: a layered DiffServ view 1013 We end this PDB-SLS discussion by a high-level view on a possible 1014 layered ("object") model for describing and enabling value-added IP 1015 services over DiffServ networks. 1017 |--------------------------------------------| 1018 | IP Transport Services - SLA | 1019 | - non-technical terms & conditions | 1020 | - technical parameters {SLS}-set | 1021 |--------------------------------------------| 1022 | Service Level Specifications - SLS | 1023 | - IP service traffic characteristics | 1024 | - offered network QoS guarantees | 1025 |--------------------------------------------| 1026 | Per Domain Behaviors - PDB | 1027 | - network QoS capabilities | 1028 | - DiffServ edge-to-edge aggregates | 1029 |--------------------------------------------| 1030 | Per Hop Behaviors - PHB | 1031 | Traffic Conditioning Block - TCB | 1032 | - generic router QoS capabilities | 1033 | - DiffServ edge & core routers | 1034 |--------------------------------------------| 1035 | Schedulers (e.g. WFQ, WTP) | 1036 | Algorithmic Droppers (e.g. RED) | 1037 | Markers (e.g. SRTCM, TRTCM) | 1038 | - implementation | 1039 | - vendor & product specific | 1040 |--------------------------------------------| 1042 Figure 1: A layered service-object model for DiffServ 1044 Each of the underlying "layers" or "objects" exposes its (QoS) 1045 capabilities to the upper layer. Conversely, an upper-layer object 1046 makes use of the lower-layer capabilities and therefore should be 1047 mapped onto the lower layer objects. 1049 Semantics and Parameters 1051 According to [RFC 3086] the specification of a PDB type should 1052 e.g.include the (lower-layer) PHB or PHB-group on which the PDB is 1053 build. 1055 On the othe hand, the mapping of SLSs to PDBs (and therefore PHBs) 1056 is a rather unexplored area. For example, it is clear that an SLS is 1057 service and customer specific; and is part of the service management 1058 system of the provider. A PDB is customer agnostic and could be a 1059 prefered object for (longer-term) traffic engineering and resource 1060 management. 1062 Clearly the mapping from SLS to PDB involves an aggregation policy 1063 of the provider, i.e. mapping of customer aware objects to non- 1064 custome aware entities. This is a non-straightforward problem. It 1065 may be very much determined by the provider policy, but some general 1066 "service mapping" and "customer aggregation" guidelines should be 1067 very useful. 1069 This is for further study. 1071 5 Service Level Specification examples. 1073 Within this section several instantiations of SLSs are presented to 1074 illustrate the potential use of the SLS template defined above. 1076 5.1 Virtual Leased Line 1078 The following specifies the SLS for a (uni-directional) VLL with 1079 quantified throughput guarantee of 1 Mbps, a delay guarantee of 20 1080 ms for a 10E-3 quantile and zero packet loss. 1082 - Scope: one-to-one communication (Ingress, Egress) specified 1084 - Flow identification: (source,destination) IP-addresses, 1085 DSCP=EF. 1087 - Traffic Conditioning: token bucket (b,r), r = 1 Mbps 1089 - Excess Treatment = dropping. Thus only in-profile packets are 1090 allowed. 1092 - Delay guarantee = (d = 20 ms, t = 5 minutes, q = 10E-3) 1094 - Loss guarantee p = 0 (imlying a throughput guarantee R = r) 1096 - Service Schedule: may be indicated 1098 - Reliability: may be indicated 1099 Semantics and Parameters 1101 Notice that in this example, the throughput guarantee is a derived 1102 parameter from the packet loss p=0, the the conditioning token 1103 bucket parameter r=1 Mbps and the excess treatment=dropping. 1105 5.2 Bandwidth Pipe for data-services 1107 The following SLS specifies a bandwidth pipe with a strict 1108 throughput guarantee, but with only a loose requirements for packet 1109 loss, i.e. "low". Thus, the SLS only mentions the scope (pipe), the 1110 Flow Id and a throughput guarantee. Remark that there are now 1111 traffic conformance parameters (and consequently no excess treatment 1112 indication). 1114 - Scope: one-to-one communication (Ingress, Egress) specified 1116 - Flow identification: (source,destination) IP-addresses 1118 - Throughput guarantee R = 1 Mbps 1120 - Service Schedule: may be indicated 1122 - Reliability: may be indicated 1124 Although there is no (explicit) traffic conditioning agreement 1125 between the customer and the network operator (i.e. such parameters 1126 are not mentioned in the SLS), the operator is likely to protect his 1127 network by implementing a traffic conditioner token bucket (b,r). If 1128 the operator can guarantee a zero packet loss for the bandwidth 1129 pipe, then the token rate equals the throughput guarantee. However, 1130 the SLS can also be met by the operator without such a stringent 1131 loss requirement, say p = 10E-5. In this case the token rate is 1132 derived from the throughput guarantee and the loss probability: 1134 token rate r = R / (1-p) 1136 The in-profile packet stream (according to the conditioner (b,r)) 1137 has a throughput guarantee of R = r * (1-p) = 1 Mbps. 1139 Further, it is up to the operator's policy whether or not excess 1140 traffic (again according to the operator's conditioner (b,r), which 1141 is not mentioned in the SLS agreement) is allowed or not in his 1142 network. 1144 5.3 Minimum rate guarantee with allowed excess 1146 The following SLS could be applied for bulk FTP traffic that 1147 requires a minimum throughput, but would take everything it can get 1148 (TCP). Also adaptive applications, like video streaming, that 1149 however require a minimum throughput for the service. 1151 - Scope: one-to-one (Pipe) 1152 Semantics and Parameters 1154 - Flow identification: e.g. DSCP-value indicating a possible 1155 AF-PBH. 1157 - Traffic Conformance Parameters: (b,r) MUST be indicated 1159 - Excess Treatment: Remarking MUST be indicated (excess is 1160 given a higher drop precedence) 1162 - Performance guarantees: guaranteed throughput R = r. 1164 5.4 Qualitative Olympic services 1166 The following SLS is meant for the Olympic Service. It could be used 1167 for differentiating applications such as web-browsing and e-mail 1168 traffic. 1170 SLS 1 (on-line web-browsing) 1171 - Scope: one-to-one (pipe) or one-to-many (hose) 1173 - Flow identification: MAY be indicated 1175 - Traffic Conformance Parameters: token parameters (b,r) The 1176 token bucket rate r indicates an (average) maximum Committed 1177 Information Rate (CIR) for which "better-than-best-effort" 1178 treatment will be applied. 1180 - Excess Treatment: remarking. 1182 - Performance Parameter: Delay and Packet loss are indicated as 1183 "low": gold/green class 1185 SLS2 : (background e-mail traffic) 1187 This is identical to SLS1 but targeting the silver/green class. 1189 5.5 The Funnel service 1191 The service offered by the funnel model is primarily a protection 1192 service: the customer wants to set a maximum on the amount of 1193 traffic (characterized by a DSCP) entering his network. It could 1194 e.g. be used for business customers to restrict the amount of web 1195 browsing traffic entering their network. 1197 /---------------\ 1198 |Network _____|______ B 1199 | _____/ | 1200 A__________|___.___________|______ C 1201 /_____ | _____ | 1202 \a(out) | \_____|_______D 1203 \---------------/ 1204 Semantics and Parameters 1206 Figure 2: Funnel model 1208 In [Figure 2], the customer A requires that the traffic entering his 1209 network from B,C and D does not exceed the rate a_out. 1211 - Scope: Funnel (N|all,1). 1213 - Flow identification: DSCP MUST be indicated. The filter (see 1214 below) is applied to all traffic characterized by the DSCP - 1215 value. 1217 - Traffic Conformance Parameters: (b, r) MUST be indicated. The 1218 token bucket parameters indicate the maximum allowed 1219 throughput (r = a_out) towards the customer network on the 1220 specified egress interface. This maximum or filter is applied 1221 to all packets marked with the DSCP-value indicated above. 1223 - Excess treatment: dropping (this is actually the service 1224 offered by the network). 1226 - Performance Parameter: not specified. 1228 5.6 Best effort traffic 1230 - Scope : all models 1232 - Flow identification : none 1234 - Traffic Conformance Parameters: if not indicated, then the 1235 full link capacity is allowed 1237 - Excess Treatment: not specified 1239 - Performance Parameters: none 1241 - Service Schedule: may be indicated. 1243 - Reliability: may be indicated. 1245 6 SLS negotiation requirements 1247 The SLS negotiation protocol is for further study. 1249 7 Security Considerations 1251 The information which will yield the instantiation of an SLS 1252 template to address the specific requirements of a customer in terms 1253 Semantics and Parameters 1255 of the quality associated to the service it has subscribed to may 1256 require the activation of security features so that: 1258 - Identification and authentication of the requesting entity 1259 needs to be performed; 1261 - Identification and authentication of the peering entities 1262 which will participate in the SLS negotiation process needs 1263 to be performed; 1265 - Preservation of the confidentiality of the information to be 1266 conveyed during the SLS negotiation and instantiation 1267 procedures between the peering entities is a MUST. 1269 8 Acknowledgment 1271 Part of this work has been funded under the European Commission 5th 1272 framework IST program. 1274 The authors would like to acknowledge all their colleagues in the 1275 TEQUILA project for their input and reflection on this work. 1277 The authors also would like to acknowledge Werner Almesberger, 1278 Marcus Brunner, Stefaan De Cnodder, Stefano Salsano, Alberto 1279 Kamienski and Abdul Malick for their useful comments and suggestions 1280 on the mailing list sls@ist-tequila.org and during private 1281 conversation. 1283 References 1285 [TEQUILA] IST-Tequila project http://www.ist-tequila.org/ 1287 [RFC 1661] "The Point-to-Point Protocol (PPP)", W. Simpson, 1288 http://www.ietf.org/rfc/rfc1661.txt?number=1661 1290 [RFC 2205] "Resource ReSerVation Protocol (RSVP)- Version 1 1291 Functional Specification", R. Braden et al. 1292 http://www.ietf.org/rfc/rfc2205.txt?number=2205 1294 [RFC-2211] "Specification of the Controlled-Load Network Element 1295 Service", J. Wroclawski, RFC 2211, September 1997. 1297 [RFC-2212] "Specification of Guaranteed Quality of Service", S. 1298 Shenker, C. Partridge, R. Guerin, RFC 2212, September 1299 1997. 1301 [RFC 2474] "Definition of the Differentiated Services Field (DS 1302 Field) in the IPv4 and IPv6 Headers", K.Nichols, S. 1303 Blake, F. Baker, D. Black, www.ietf.org/rfc/rfc2474.txt 1304 Semantics and Parameters 1306 [RFC 2475] "An Architecture for Differentiated Services", S. Blake, 1307 D. Black, M.Carlson,E.Davies,Z.Wang,W.Weiss, 1308 www.ietf.org/rfc/rfc2475.txt 1310 [RFC 2597] "Assured Forwarding PHB Group", F. Baker, J. Heinanen, 1311 W. Weiss, J. Wroclawski, www.ietf.org/rfc/rfc2597.txt 1313 [RFC 2598] "An Expedited Forwarding PHB", V.Jacobson, K.Nichols, 1314 K.Poduri, www.ietf.org/rfc/rfc2598.txt 1316 [RFC 2638] "A Two-bit Differentiated Services Architecture for the 1317 Internet", K. Nichols, V. Jacobson, L. Zhang, July 1999. 1318 www.ietf.org/rfc/rfc2638.txt 1320 [RFC 2698] "A Two Rate Three Color Marker." J. Heinanen, R. Guerin. 1321 September 1999. www.ietf.org/rfc/rfc2698.txt 1323 [RFC 3086] "Definition of Differentiated Services Per Domain 1324 Behaviors and Rules for their specification". K. 1325 Nichols, B. Carpenter April 2001 1326 http://www.ietf.org/rfc/rfc3086.txt 1328 [DS-MODEL] "A Conceptual Model for Diffserv Routers", Y. Bernet et 1329 al., draft-ietf-diffserv-model-06.txt, Work in Progress, 1330 February 2001 1332 [DS-TERMS] "New Terminology and Clarifications for Diffserv", D. 1333 Grossman, draft-ietf-diffserv-new-terms-08.txt, work in 1334 progress, January 2002 1336 Author's Addresses 1338 Danny Goderis 1339 Alcatel Corporate Research Center 1340 Fr. Wellesplein 1, 2018 Antwerpen, Belgium. 1341 Phone : 32-3-240-7853 1342 Fax : 32-3-240-9932 1343 E-mail: Danny.Goderis@Alcatel.be 1345 Yves T'Joens 1346 Alcatel Corporate Research Center 1347 Fr. Wellesplein 1, 2018 Antwerpen, Belgium. 1348 Phone : 32-3-240-7890 1349 Fax : 32-3-240-9932 1350 E-mail: Yves.TJoens@Alcatel.be 1352 Sven Van den Bosch 1353 Alcatel Corporate Research Center 1354 Fr. Wellesplein 1, 2018 Antwerpen, Belgium. 1355 Phone : 32-3-240-8103 1356 Fax : 32-3-240-9932 1357 Semantics and Parameters 1359 E-mail: sven.van_den_bosch@alcatel.be 1361 Olivier Poupel 1362 Alcatel Research & Innovation 1363 Route de Nozay, F-91461 Marcoussis, France 1364 Phone : 33-1-69-63-47-07 1365 Fax : 33-1-69-63-44-50 1366 E-mail: Olivier.Poupel@alcatel.fr 1368 Christian Jacquenet 1369 France Telecom Research and Development 1370 FT R&D /DMI 1371 42, rue des Coutures 1372 BP6243 1373 14066 CAEN CEDEX 04 1374 France 1375 Phone : +33 2 31 75 94 28 1376 Fax : +33 2 31 73 56 26 1377 E-mail: christian.jacquenet@francetelecom.fr 1379 George Memenios 1380 Research Associate, Telecommunications Laboratory NTUA 1381 Heroon Polytechniou 9 1382 157 73 Zografou, Athens, Greece 1383 Phone : +30 1 772 1494 1384 Fax : +30 1 772 2534 1385 E-mail: gmemen@telecom.ntua.gr 1387 George Pavlou 1388 Centre for Communication Systems Research (CCSR) 1389 Univ. of Surrey, Guildford, Surrey GU2 7XH, UK 1390 Phone : +44 (0)1483 259480 1391 Fax : +44 (0)1483 876011 1392 E-mail: G.Pavlou@eim.surrey.ac.uk 1394 Richard Egan 1395 Thales Research Ltd 1396 Worton Drive 1397 Worton Grange Industrial Estate 1398 Reading, Berkshire RG2 OSB 1399 Phone : +44 118 986 8601 1400 Fax : +44 118 923 8399 1401 E-mail : richard.egan@uk.thalesgroup.com 1403 David Griffin 1404 Department of Electronic and Electrical Engineering 1405 University College London 1406 Torrington Place, London WC1E 7JE, UK 1407 Phone : +44 (0)20 7679 3557 1408 Fax : +44 (0)20 7388 9325 1409 E-mail: D.Griffin@ee.ucl.ac.uk 1411 Panos Georgatsos 1412 Semantics and Parameters 1414 Algosystems S.A. 1415 4, Sardeon str., 172 34 Athens, Greece 1416 Phone : 30-1-93-10-281 1417 Fax : 30-1-93-52-873 1418 E-mail: pgeorgat@algo.com.gr 1420 Leonidas Georgiadis 1421 Aristotel Univ. of Thessaloniki, Faculty of Engineering 1422 School of Electrical and Computer Engineering, Telecommunications 1423 Dept. 1424 PO Box 435, Thessaloniki, 54006, Greece 1425 Phone : 30-31-996385 1426 Fax : 30-31-996312 1427 E-mail: leonid@eng.auth.gr 1429 Full Copyright Statement 1431 Copyright (C) The Internet Society (2001). All Rights Reserved. 1433 This document and translations of it may be copied and furnished to 1434 others, and derivative works that comment on or otherwise explain it 1435 or assist in its implementation may be prepared, copied, published 1436 and distributed, in whole or in part, without restriction of any 1437 kind, provided that the above copyright notice and this paragraph 1438 are included on all such copies and derivative works. However, this 1439 document itself may not be modified in any way, such as by removing 1440 the copyright notice or references to the Internet Society or other 1441 Internet organizations, except as needed for the purpose of 1442 developing Internet standards in which case the procedures for 1443 copyrights defined in the Internet Standards process must be 1444 followed, or as required to translate it into languages other than 1445 English. 1447 The limited permissions granted above are perpetual and will not be 1448 revoked by the Internet Society or its successors or assigns. 1450 This document and the information contained herein is provided on an 1451 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1452 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1453 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1454 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1455 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.