idnits 2.17.1 draft-tequila-sls-00.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: ---------------------------------------------------------------------------- == 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 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([DS-TERMS], [RFC2475]), 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 == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 42 has weird spacing: '...ocument ident...' == Line 329 has weird spacing: '... set of sourc...' == Line 952 has weird spacing: '...icating incap...' == Line 967 has weird spacing: '... - The proto...' -- 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 (March 2001) is 8440 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: 'RFC-2119' is mentioned on line 96, but not defined == Missing Reference: 'RFC-2475' is mentioned on line 358, but not defined == Missing Reference: 'RFC-2598' is mentioned on line 209, but not defined ** Obsolete undefined reference: RFC 2598 (Obsoleted by RFC 3246) == Missing Reference: 'RFC-2597' is mentioned on line 209, but not defined == Missing Reference: 'RFC-1661' is mentioned on line 969, but not defined == Missing Reference: 'RFC-2474' is mentioned on line 327, but not defined == Missing Reference: 'REF' is mentioned on line 478, but not defined == Missing Reference: 'Figure 4' is mentioned on line 891, but not defined == Missing Reference: 'RFC-2205' is mentioned on line 969, but not defined == Unused Reference: 'RFC 1661' is defined on line 1006, but no explicit reference was found in the text == Unused Reference: 'RFC 2205' is defined on line 1012, but no explicit reference was found in the text == Unused Reference: 'RFC 2474' is defined on line 1022, but no explicit reference was found in the text == Unused Reference: 'RFC 2598' is defined on line 1033, but no explicit reference was found in the text == Unused Reference: 'RFC 2698' is defined on line 1036, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'TEQUILA' -- Duplicate reference: RFC2205, mentioned in 'RFC 2205', was also mentioned in 'RFC-1771'. ** Downref: Normative reference to an Informational RFC: RFC 2475 ** Obsolete normative reference: RFC 2598 (Obsoleted by RFC 3246) ** Downref: Normative reference to an Informational RFC: RFC 2698 == Outdated reference: A later version (-06) exists of draft-ietf-diffserv-model-03 ** Downref: Normative reference to an Informational draft: draft-ietf-diffserv-model (ref. 'DS-MODEL') == Outdated reference: A later version (-08) exists of draft-ietf-diffserv-new-terms-02 ** Downref: Normative reference to an Informational draft: draft-ietf-diffserv-new-terms (ref. 'DS-TERMS') -- Possible downref: Non-RFC (?) normative reference: ref. 'QBONE' -- Possible downref: Non-RFC (?) normative reference: ref. 'TWOBIT' Summary: 11 errors (**), 0 flaws (~~), 23 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Danny Goderis, Alcatel 3 Yves T'joens, Alcatel 4 Christian Jacquenet, France Telecom R&D 5 George Memenios, NTUA 6 George Pavlou, UniS 7 Richard Egan, Racal Research Ltd 8 David Griffin, UCL 9 Panos Georgatsos, AlgoSystems 10 Leonidas Georgiadis, Univ. Thessaloniki 11 Pim Van Heuven, IMEC 13 INTERNET DRAFT 14 November, 2000 15 Expires March 2001 17 Service Level Specification Semantics and Parameters. 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC2026. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Abstract 42 This document identifies the basic information to be included in 43 Service Level Specifications (SLS, [RFC 2475], [DS-TERMS]) when 44 considering the deployment of value-added IP service offerings over 45 the Internet. Such IP service offerings can be provided together with 46 a given quality of service (QoS), which is expected to be defined in 47 such SLS, from a technical perspective. Since these IP services are 48 likely to be provided over the whole Internet, their corresponding 49 QoS will be based upon a set of technical parameters that both 50 customers and services providers will have to agree upon. From this 51 perspective, this draft aims at listing (and promoting a standard 52 formalism for) a set of basic parameters which will actually compose 53 the elementary contents of an SLS. 55 Such a specification effort tries to address the following concerns: 57 - Provide a standard set of information to be negotiated between a 58 customer and a service provider or amongst services providers within 59 the context of processing an SLS; 61 - Provide the corresponding semantics of such information, so that it 62 might be appropriately modeled and processed by the above-mentioned 63 parties (in an automated fashion). 65 Table of Contents 67 1. Introduction 68 1.1 Motivation 69 1.2 Objective 70 2. Basic assumptions and terminology 71 3. SLS content & template 72 3.1. Scope 73 3.2. Flow Description 74 3.3. Traffic Envelop and Traffic Conformance 75 3.4. Excess Treatment 76 3.5. Performance Guarantees 77 3.6. Service Schedule 78 3.7. Reliability 79 4. Service Level Specification examples 80 4.1. Virtual Leased Line 81 4.2. Bandwidth Pipe for data-services 82 4.3. Real-time micro-flows 83 4.4. Minimum rate guarantee with allowed excess 84 4.5. Qualitative Olympic Services 85 4.6. The funnel services 86 4.7. Best Effort Traffic 87 5. SLS negotiation requirements 88 6. Security considerations 89 7. Acknowledgements 91 0. Conventions used in this document 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC 2119 ([RFC-2119]). 97 1. Introduction 99 1.0 Changes w.r.t. the previous version 101 This is the second version of an Internet Draft of the issue of 102 Service Level Specifications (SLS). The first version 1) 268 - (1,any) - one-to-any communication 270 - (N,1) - many-to-one communication (N>1) 272 - (any,1) - any-to-one communication 274 The above taxonomy excludes the many-to-many communication (M,N). 275 Either ingress OR egress MUST be specified to exactly ONE interface 276 identifier (with a non-exclusive OR). Many-to-many communication 277 (M,N) can be decomposed into M times one-to-many communication (1,N). 279 This taxonomy SHOULD avoid all ambiguity about the IP flow (defined 280 as a set of IP datagrams sharing at least one common characteristic, 281 like e.g. the same [source address; destination address] pair), and 282 its corresponding description. (see section 3.2 and 3.3). If the 283 ingress is a single interface identifier, then the traffic envelop 284 and flow description concerns the incoming IP packet stream at the 285 unique ingress point. If (only) the egress is a single interface, 286 i.e. (N|any,1), then the traffic envelop and flow description 287 concerns the outgoing (aggregate) traffic on the egress link. More 288 details about the latter can be found in the example 4.5. 290 In the remaining part of this document SLSs with an associated scope 291 (topology) of (1,1) ; (1,N) ; (N,1) will be called respectively Pipe, 292 Hose and Funnel SLSs. 294 Disclaimer: 296 An ingress (or egress) interface identifier should uniquely determine 297 the boundary link as defined in [RFC-2475] on which packets 298 arrive/depart at the border of a DS domain. This link identifier MAY 299 be an IP address, but it may also be any other mutually agreed upon 300 identifier which uniquely identifies a boundary link. Fore example a 301 layer-two identifier in case of e.g. ethernet, or for unnumbered 302 links like in e.g. PPP(Point-to-Point Protocol, [RFC-1661])-based 303 access configurations. The interface identifier(s) may also 304 implicitly be derived from the source or destination address 305 information in the Flow Description field (see next section 3.2) 306 combined with e.g. BGP4 (Border Gateway Protocol, version 4, [RFC- 307 1771]) routing information. 309 3.2. Flow Description 311 The flow description of an SLS associated to a given service offering 312 indicates for which IP packets the QoS guarantees for that specific 313 service offering is to be enforced. 315 A flow description identifies a stream of IP datagrams sharing at 316 least one common characteristic. An SLS contains one (and only one) 317 flow description, which MAY formally be specified by providing one or 318 more of the following attributes: 320 flow description = (Differentiated Services information, source 321 information, destination information, application information) 323 - Differentiated Services information = DSCP value | set of DSCP 324 values | any 326 The Differentiated Services Code Point (DSCP) IP header field is 327 defined in [RFC-2474]. 329 - Source information = source address | set of source addresses | 330 source prefix | set of source prefixes | any 332 - Destination information = destination address | set of 333 destination addresses | destination prefix | set of destination 334 prefixes | any 336 - Application information = protocol number | protocol number and 337 source port, destination port | any 339 Note: "any" is again logically equivalent with unspecified. 341 Thus, the flow description may be expressed by information attributes 342 related to the source/destination nodes, the application or the DS 343 field in the IP header. The flow description provides the necessary 344 information for classifying the packets at a DS boundary node. 346 This datagram classification can either be Behaviour Aggregate (BA) 347 or Multi-Field (MF)classification based. 349 In case of MF-classification all attributes MAY be specified, 350 including the DSCP field. MF classification may depict as well 351 micro-flows as aggregate macro-flows, based on e.g. source network 352 prefix [DS-MODEL]. Also the "set-of" semantics allows for the 353 specification of aggregate flows. If a flow description is e.g. 354 specified by a set of two IP source addresses, then any packet with 355 either of the two concerned source addresses belongs to the IP packet 356 stream identified by this flow description. 358 In case of BA-classification [RFC-2475], the DSCP attribute MUST be 359 specified and the other attributes MUST NOT be specified. If a set of 360 DSCP-values is specified, then any packet having a DSCP belonging to 361 this set is part of the Flow (description) packet stream (analogous 362 to the example above with the IP source addresses). As an example 363 consider an Ordered Aggregate (OA) IP packet stream of a particular 364 Assured Forwarding Class AFx (AF1,AF2,AF3,AF4 - see [RFC 2597]). This 365 stream could be specified within one flow description using three 366 DSCP-values, indicating the three drop precedences levels, 367 respectively colored in green, yellow and red. 369 It should however be noticed that the DSCP-value(s) specified in the 370 SLS has (have) as such nothing to do with the DSCP-marking of packets 371 inside the DiffServ network. The latter, i.e. the "interior" DSCP is 372 used for differentiating packets according to Per Hop Behaviours 373 (PHBs). The former, i.e. the "ingress" DSCP value (specified in the 374 SLS), is just another way of identifying a packet stream, eventually 375 in combination with other IP header fields. At the ingress DiffServ 376 node (incoming) packets are classified based on the "ingress" DSCP 377 value (amongst others), after which they may be re-marked by the 378 "interior" DSCP-value. 380 Finally note also that the IP routing scheme MAY put restrictions on 381 combining scope and flow description within an SLS. 383 In general, if (only) the flow description is specified by source and 384 destination IP address (IP-src, IP-dest), and the scope is 385 unspecified, then there is no a-priori assumption about the actual 386 ingress/egress points that this traffic will use. Indeed, it is the 387 responsibility of the service provider to define the most appropriate 388 route for this traffic, by enforcing the corresponding traffic 389 engineering and routing policy. Thus, the (ingress, egress) 390 information (which is in this case not in the SLS) is then derived 391 from the flow description and the routing policy of the service 392 provider. 394 On the other hand, if the flow description AND scope are specified in 395 the SLS, respectively by the pairs (IP-src, IP-dest) and (IP-ingr, 396 IP-egr) then it is clear that the IP packets MUST follow the route 397 (IP-src,...,IP-ingr,...,IP-egr,...,IP-dest). Thus the restriction is 398 that the scope (IP-ingr, IP-egr) is part of the route from IP-src to 399 IP-dest. 401 Further routing considerations are outside the scope of this 402 document. 404 Finally remark that the exclusion of the many-to-many communication 405 scope model puts similar constraints on the source/destination fields 406 of the Flow Description. 408 3.3 Traffic Envelop and Traffic Conformance 410 The traffic envelop describes the traffic (conformance) 411 characteristics of the IP packet stream identified by the flow 412 description. The traffic envelop is a set of Traffic Conformance 413 Parameters, describing how the packet stream should look like to get 414 the guarantees indicated by the performance parameters (defined in 415 section 3.5) 417 The Traffic Conformance Parameters are the basic input for the 418 Traffic Conformance Algorithm. Traffic Conformance Testing as the 419 combination of the Traffic Conformance Parameters and the Traffic 420 Conformance Algorithm. This will usually be done at a DS-boundary 421 node. 423 The algorithm and the conformance test can be binary-based or multi- 424 level based. 426 Binary Traffic Conformance Testing is a set of actions which uniquely 427 identifies the "in-profile" and "out-of profile" (or excess) packets 428 of an IP stream (identified by Flow-Id). In this case the Traffic 429 Conformance Parameters describe the reference values the traffic 430 (identified by the flow description) will have to comply with, thus 431 yielding the notions of "in" and "out" of profile traffics. The 432 Traffic Conformance Algorithm is the mechanism enabling unambiguously 433 to identify all "in" or "out" of profile packets based on these 434 Conformance parameters. 436 In case of multi-level (n) Traffic Conformance Testing a packet will 437 be tagged (by the algorithm) as belonging to a particular level 438 (1...n). Packets tagged as level n are called "excess" packets. 440 The SLS MUST indicate the concerned level (n) of the conformance 441 testing algorithm: 443 - Multi-level conformance testing n (integer) 445 The following gives a (non-exhaustive) list of potential conformance 446 parameters. 448 - Peak rate p (bits per second) 450 - Token bucket rate r (bits per second) 452 - bucket depth b (bytes) 454 - Maximum Transport Unit (MTU) M (bytes) 456 - Minimum packet size (bytes) 458 Binary-based Traffic Conformance Testing examples: 460 - Conformance parameters = token bucket parameters (b,r); 461 conformance algorithm = token bucket algorithm. 463 - Conformance parameters = token bucket parameters and peak rate 464 (b,r,p) with p larger than r; conformance algorithm = the combined 465 token bucket (b,r) and (b,p). This is the conformance test for 466 Integrated Services Controlled Load and Guaranteed Service IP 467 flows in the IntSer QoS architecture [RFC-2211, RFC-2212]. The 468 scheme permits bursty traffic to be sent, limited to a burst of b 469 bytes, with a (long-term) average rate of r and a peak rate of no 470 more than p. 472 - Conformance parameters = MTU; conformance algorithm = all 473 packets allowed with size smaller than MTU; packets larger than 474 MTU are fragmented or dropped. 476 Three-level based Traffic Conformance Testing example 478 - The Two-rate Three-colour marker [REF] is based on two token 479 buckets with rates r1 and r2 (larger than r1), containing 480 respectively green and yellow tokens. The simplest operational 481 mode is the "colour-blank" mode. A packet is tagged "green" if 482 there are green and yellow tokens available, yellow if only yellow 483 tokens are available and otherwise it is tagged red. 485 3.4. Excess Treatment 487 This section describes how the service provider will process excess 488 traffic, i.e. out-of-profile traffic (in case of binary conformance 489 testing) or n-level traffic (in case of n-level conformance testing). 490 The process takes place after Traffic Conformance Testing, described 491 previously. 493 Excess traffic may be dropped, shaped and/or remarked. The SLS MUST 494 specify the appropriate action by the following attribute. 496 - Excess Treatment 498 If Excess Treatment is not indicated, then excess traffic is dropped. 499 Depending on the appropriate action, more parameters MAY be required 500 The following is an indication in case of binary conformance testing. 501 Multi-level conformance testing (like the definition of a 502 hierarchical drop preference model) MAY also be enforced, but this 503 concern has been left for further study. 505 - If excess traffic is dropped, then all packets marked as "out- 506 of-profile" by the Traffic Conformance Algorithm are dropped. No 507 extra parameters are needed. 509 - If excess traffic is shaped, then all packets marked as "out- 510 of-profile" by the Traffic Conformance Algorithm are delayed until 511 they are "in-profile". The shaping rate is the policing/token 512 bucket rate r. The extra parameter is the buffer size of the 513 shaper. 515 - If excess traffic is marked or remarked, then all packets marked 516 as "out-of-profile" by the Traffic Conformance Algorithm are (re-) 517 marked with a particular DSCP-value (yellow or red). The extra 518 parameter is the DSCP. 520 3.5. Performance Guarantees 522 The performance parameters describe the service guarantees the 523 network offers to the customer for the packet stream described by the 524 flow description and over the geographical/topological extent given 525 by the scope. 527 There are four performance parameters: 529 - delay, time interval, optional quantile 531 - jitter, time interval, optional quantile 533 - packet loss, time interval 535 - throughput, time interval 537 Delay, jitter and packet loss guarantees are for the in-profile 538 traffic in case of binary conformance testing. For multi-level (n) 539 conformance testing, delay, jitter and loss guarantees MAY be 540 specified for each conformance level-i, except the last one (n). For 541 example if n = 3, one can have a delay guarantee for the "conformance 542 level-1" packets and a different delay guarantee for the "conformance 543 level-2" packets. No guarantees are given for excess ("conformance 544 level-n") traffic. 546 The throughput is an overall guarantee for the IP packet stream, 547 independent of a particular level (see below). 549 The following definitions always consider the (measurable) 550 performance parameters related to the packet stream specified by the 551 flow description. For simplicity the definitions below are given for 552 binary conformance testing (n=2), but generalisation is 553 straightforward. 555 The delay and jitter indicate respectively the maximum packet 556 transfer delay and packet transfer delay variation from ingress to 557 egress, measured over (any) time period with a length equal to the 558 (indicated) time interval. 560 Delay and jitter may either be specified as worst case 561 (deterministic) bounds or as quantiles. Indeed, the worst case 562 delay/jitter bounds will be very rare events and customers may find 563 measurements of e.g. 99.5th percentile a more relevant empirical 564 gauge of delay/jitter. 566 Suppose e.g. that the SLS specifies the triple (delay = 10ms, time 567 interval = 5 minutes, quantile = 10E-3). Then the probability that 568 the transfer delay of a packet (between ingress-egress) is larger 569 than 10ms, is less than 10E-3; and this for any measurement period of 570 5 minutes. 572 The above syntax for delay/jitter can be generalised by specifying in 573 the SLS an array of e.g. N (delay/jitter, quantile)-couples. The more 574 couples, the better the delay probability tail distribution can be 575 approximated. Such a specification together with the eventual need of 576 such a generalisation is for further study. 578 The packet loss probability is ratio of the lost (in-profile) packets 579 between ingress and egress and the offered (in-profile) packets at 580 ingress. 582 lost packets between (and including) ingress and egress 583 packet loss = ------------------------------------------------------- 584 offered (injected) packets at ingress 586 The ratio is measured over (any) time period with a length equal to 587 the (indicated) time interval. 589 The throughput is the rate measured at egress counting all packets 590 identified by the flow description. Notice that all packets, 591 independently of their conformance level (in/out-of-profile) 592 contribute. Indeed, if the customer (only) wants a throughput 593 guarantee, then he/she does not care whether in- or out-profile 594 packets are dropped, but is only interested in the overall throughput 595 of its packet stream. 597 Note on the relation with the Traffic Conformance Parameters (section 598 3.3) in case of a binary-based conformance testing algorithm: 600 - The Traffic Conformance Algorithm (and parameters) MUST be 601 specified when guaranteeing delay/jitter or packet loss, i.e. if 602 one of these performance parameters is quantified in the SLS. 603 Conformance testing is required because the delay/jitter and loss 604 guarantees are only for the stream of in-profile packets. 606 - When only guaranteeing a throughput, or if non of the other 607 performance parameters is quantified, the traffic conformance 608 algorithm MAY be specified. It is not required to specify the 609 Conformance Algorithm, because the (eventual) troughput guarantee 610 does not require the strict distinction between in/out-of-profile 611 traffic. However, the network operator will probably protect his 612 network by implementing a Traffic Conditioner at Ingress and 613 specifying the token policing rate (r) (almost) equal to the 614 throughput guarantee R, r~R. He may or may not tag/mark excess 615 traffic, according to his own - internal - policy rules. See also 616 example 4.2. 618 Note on the relation between throughput R, packet loss p and excess 619 treatment in case of a binary-based conformance testing algorithm: 621 - First consider the case where excess traffic is dropped (or 622 shaped to in-profile) based on the token bucket (b,r) traffic 623 conformance algorithm. As only in-profile packets are allowed at 624 ingress, the following equality holds: 626 throughput R = (1-p) * token rate r 628 Thus the throughput guarantee can be derived from the loss 629 probability and token rate and is therefore not an independent 630 parameter. 632 - If excess traffic is allowed (and marked accordingly), then 633 "throughput" is an independent parameter because it also takes 634 into account the out-of-profile packets (measured at egress). One 635 has obviously the inequality: 637 throughput R >= (1-p) * token rate r 639 Quantitative performance guarantees 641 A performance parameter is said to be quantified if its value is 642 specified to a numeric (quantitative) value. 644 The service guarantee described by the SLS is said to be quantitative 645 IF at least one of the 4 performance parameters is quantified. 647 Qualitative performance guarantees 649 If non of the SLS performance parameters are quantified, then the 650 performance parameters "delay" and "packet loss" MAY be "qualified". 652 Possible qualitative values (for delay and/or loss): high, medium, 653 low. 655 Relative delay guarantees: 657 - gold service : value = low 659 - silver service : value = medium 661 - bronze service : value = high or not indicated 663 Relative loss guarantees 664 - green service : value = low 666 - yellow service : value = medium 668 - red service : value = high or not indicated 670 The quantification of relative difference between 671 is a provider policy (e.g. high = 2 x medium ; medium = 2 x low). 673 The above taxonomy yields the following combinations of qualitative 674 services. 676 ------------------------------------------------------- 677 |\ delay | | | | 678 | \------| low | medium |high | 679 | loss | | | | 680 |------------------------------------------------------| 681 | low | gold green | silver green | bronze green | 682 | medium | gold yellow | silver yellow | bronze yellow | 683 | high | gold red | silver red | bronze red | 684 |------------------------------------------------------| 685 Combinations table 687 The service guarantee described by the SLS is said to be qualitative 688 if it is NOT quantitative and either delay or loss (non-exclusive) 689 are qualified to "medium" or "low", i.e. excluding bronze/red from 690 the above. 692 The service guarantee described by the SLS is said to be best-effort 693 if it is NOT quantified nor qualified. 695 3.6. Service schedule 697 The service schedule indicates the start time and end time of the 698 service, i.e. when is the service available. 700 This might be expressed as collection of the following parameters: 702 - Time of the day range 704 - Day of the week range 706 - Month of the year range 708 Some examples are: 709 - Time of the day range 710 08h00-18h00 712 - Day of the week range 713 A single day 715 A group of sequential days 717 - Month of the year range 718 A single month 720 A group of sequential months 722 - Year range 723 A single year 725 A group of sequential years 727 Remark: service schedule "from now on" [now, infinity] can be 728 captured by putting the above to their full range. 730 3.7. Reliability 732 Reliability indicates the maximum allowed mean downtime per year 733 (MDT) and the maximum allowed time to repair (TTR) in case of service 734 breakdown (e.g. in case of cable cut). 736 The Mean Down Time might be expressed in minutes per year and the 737 Maximum Time To Repair might be expressed in seconds. 739 3.8 Others 741 Other parameters such as route, reporting guarantees, security, 742 scheduled maintenance, etc... remain for further study. 744 4. Service Level Specification examples. 746 Within this section a number of example instantiations of SLSs are 747 presented to illustrate the potential use of the SLS template defined 748 above. 750 4.1. Virtual Leased Line 752 The following specifies the SLS for a (uni-directional) VLL with 753 quantified throughput guarantee of e.g 1 Mbps, a delay guarantee of 754 20 ms for a 10E-3 quantile and zero packet loss. 756 - Scope: one-to-one communication (Ingress, Egress) specified 758 - Flow description: (source,destination) IP-addresses, DSCP=EF. 760 - Traffic Conditioning: token bucket (b,r), r = 1 Mbps 762 - Excess Treatment = dropping. Thus only in-profile packets are 763 allowed. 765 - Delay guarantee = (d = 20 ms, t = 5 minutes, q = 10E-3) 767 - Loss guarantee p = 0 (imlying a throughput guarantee R = r) 769 - Service Schedule: may be indicated 771 - Reliability: may be indicated 773 Notice that in this example, the throughput guarantee is a derived 774 parameter from the packet loss p=0, the conditioning token bucket 775 parameter r=1 Mbps and the excess treatment=dropping. 777 4.2 Bandwidth Pipe for data-services 779 The following SLS specifies a bandwidth pipe with a strict throughput 780 guarantee, but with only a loose requirements for packet loss, i.e. 781 "low". Thus, the SLS only mentiones the scope (pipe), the flow 782 description and a throughput guarantee. Remark that there are now 783 traffic conformance parameters (and consequently no excess treatment 784 indication). 786 - Scope: one-to-one communication (Ingress, Egress) specified 788 - Flow description: (source,destination) IP-addresses 790 - Throughput guarantee R = 1 Mbps 792 - Service Schedule: may be indicated 794 - Reliability: may be indicated 796 Although there is no (explicit) traffic conditioning agreement 797 between the customer and the network operator (i.e. not mentioned in 798 the SLS), the operator is likely to protect his network by 799 implementing a traffic conditioner token bucket (b,r). If the 800 operator can guarantee a zero packet loss for the bandwidth pipe, 801 then the token rate equals the throughput guarantee. However, the SLS 802 can also be met by the operator without such a stringent loss 803 requirement, say p = 10E-5. In this case the token rate is derived 804 from the throughput guarantee and the loss probability: 806 token rate r = R / (1-p) 808 The in-profile packet stream (according to the conditioner (b,r)) has 809 a throughput guarantee of R = r * (1-p) = 1 Mbps. 811 Further, it is up to the operator's policy whether or not excess 812 traffic (again according to the operator's conditioner (b,r), which 813 is not mentioned in the SLS agreement) is allowed or not in his 814 network. 816 4.3. Real-time micro-flows 818 - Scope: one-to-one communication (Ingress, Egress) specified 820 - Flow description: (source IP-address, destination IP-address, 821 source port number, destination port number, protocol) 823 - Traffic Conditioning: token bucket (b,r), peak rate p= r = 64 Kbps 825 - Excess Treatment = dropping. 827 - Performance Parameters: delay = 10 msec, packet loss = 10E-6, 828 guaranteed throughput R ~ r. 830 4.4 Minimum rate guarantee with allowed excess 832 The following could be for bulk FTP traffic that requires a minimum 833 throughput, but would take everything it can get (TCP). Also adaptive 834 applications, like video streaming, that however require a minimum 835 throughput for the service. 837 - Scope: one-to-one (Pipe) 839 - Flow description: e.g. DSCP-value indicating a possible AF-PHB. 841 - Traffic Conformance Parameters: (b,r) MUST be indicated 843 - Excess Treatment: Remarking MUST be indicated (excess is given a 844 higher drop precedence) 846 - Performance guarantees: guaranteed throughput R = r. 848 4.5. Qualitative Olympic services 850 The following SLS is meant for the Olympic Service. It could be used 851 for differentiating applications such as web-browsing and e-mail 852 traffic. 854 SLS 1 (on-line web-browsing) - Scope: one-to-one (pipe) or one-to- 855 many (hose) 857 - Flow description: MAY be indicated 859 - Traffic Conformance Parameters: token parameters (b,r) The token 860 bucket rate r indicates an (average) maximum Committed Information 861 Rate (CIR) for which "better-than-best-effort" treatment will be 862 applied. 864 - Excess Treatment: remarking. 866 - Performance Parameter: Delay and Packet loss are indicated as 867 "low": gold/green class 869 SLS2 : (background e-mail traffic) 871 This is identical to SLS1 but targeting the silver/green class. 873 4.6. The Funnel service 875 The service offered by the funnel model is primarily a protection 876 service: the customer wants to set a maximum on the amount of traffic 877 (characterized by a DSCP) entering his network. It could e.g. be used 878 for business customers to restrict the amount of web browsing traffic 879 entering their network. 881 /---------------\ 882 |Network _____|______ B 883 | _____/ | 884 A__________|___.___________|______ C 885 /_____ | _____ | 886 \a(out) | \_____|_______D 887 \---------------/ 889 Figure 4: Funnel model 891 In [Figure 4], customer A requires that specific traffic entering his 892 network from B,C and D does not exceed the rate a_out. 894 - Scope: Funnel (N|all,1). 896 - Flow description: DSCP MUST be indicated. The filter (see below) is 897 applied to all traffic characterized by the DSCP -value. 899 - Traffic Conformance Parameters: (b, r) MUST be indicated. The token 900 bucket parameters indicate the maximum allowed throughput (r = a_out) 901 towards the customer network on the specified egress interface. This 902 maximum or filter is applied to all packets marked with the DSCP- 903 value indicated above. 905 - Excess treatment: dropping (this is actually the service offered by 906 the network). 908 - Performance Parameter: not specified. 910 4.7. Best effort traffic 912 - Scope : all models 914 - Flow description : none 916 - Traffic Conformance Parameters: if not indicated, then the full 917 link capacity is allowed 919 - Excess Treatment: not specified 921 - Performance Parameters: none 923 - Service Schedule: may be indicated. 925 - Reliability: may be indicated. 927 5. SLS negotiation requirements 929 [This section is informational and preliminary. More detailed study 930 is required.] 932 A major goal of the availability of an SLS template is helping in the 933 deployment of dynamical SLS negotiation procedures between customer 934 and providers or between providers. This draft only discussed the SLS 935 template and its basic contents. The SLS negotiation protocol is for 936 further study. The following lists a number of conditions which 937 should be met by a (to be defined) SLS negotiation protocol. 939 The SLS negotiation protocol MUST allow for: 941 - Original service requests, according the components of the 942 specified SLS. 944 - Service acknowledgement (ACK), indicating agreement with the 945 requested service level. 947 - Service rejection (NAK) but indicating the possibility of offering 948 a closely related service (or indication of alternative DSCP to use 949 for a particular service). The reply message may indicate the related 950 offering by overwriting the proposed SLS attributes (hints). 952 - Service rejection (REJECT) indicating incapability of providing 953 the service. 955 - The ACK/NACK procedures require a reliable transport mode for such 956 a negotiation protocol. 958 - Service modification from both user and provider. 960 The following are further requirements for the overall network 961 architecture which SHOULD be fulfilled. 963 - The protocol should be able to interact with feedback of events 964 related to the service. For example performance degradation MAY 965 result in re-negotiation of the SLS. 967 - The protocol should preferentially make use of / be an 968 extension of existing specifications protocol design work available 969 such as RSVP ([RFC-2205]) or PPP/IPCP ([RFC-1661]). 971 6. Security considerations 973 The information which will yield the instantiation of an SLS template 974 to address the specific requirements of a customer in terms of the 975 quality associated to the service it has subscribed to may require 976 the activation of security features so that: 978 - Identification and authentication of the requesting entity needs to 979 be performed; 981 - Identification and authentication of the peering entities which 982 will participate in the SLS negotiation process needs to be 983 performed; 985 - Preservation of the confidentiality of the information to be 986 conveyed during the SLS negotiation and instantiation procedures 987 between the peering entities is a MUST. 989 7. Acknowledgements 991 Part of this work has been funded under the European Commission 5th 992 framework IST program. 994 The authors would like to acknowledge all their colleagues in the 995 TEQUILA project for their input and reflection on this work. 997 The authors also would like to acknowledge Werner Almesberger, Marcus 998 Brunner, Stefaan De Cnodder, Stefano Salsano, Alberto Kamienski and 999 Abdul Malick for their useful comments and suggestions on the mailing 1000 list sls@ist-tequila.org and during private conversation. 1002 References 1004 [TEQUILA] IST-Tequila project http://www.ist-tequila.org/ 1006 [RFC 1661] "The Point-to-Point Protocol (PPP)", W. Simpson, 1007 http://www.ietf.org/rfc/rfc1661.txt?number=1661 1009 [RFC-1771] A Border Gateway Protocol 4 (BGP-4). Y. Rekhter, T. 1010 Li. March 1995. http://www.ietf.org/rfc/rfc2205.txt?number=1771 1012 [RFC 2205] "Resource ReSerVation Protocol (RSVP)- Version 1 1013 Functional Specification", R. Braden et al. 1014 http://www.ietf.org/rfc/rfc2205.txt?number=2205 1016 [RFC-2211] J. Wroclawski, "Specification of the Controlled-Load 1017 Network Element Service", RFC 2211, September 1997. 1019 [RFC-2212] S. Shenker, C. Partridge, R. Guerin, "Specification 1020 of Guaranteed Quality of Service", RFC 2212, September 1997. 1022 [RFC 2474] "Definition of the Differentiated Services Field (DS 1023 Field) in the IPv4 and IPv6 Headers", K.Nichols, S. Blake, F. Baker, 1024 D. Black, www.ietf.org/rfc/rfc2474.txt 1026 [RFC 2475] "An Architecture for Differentiated Services", S. Blake, 1027 D. Black, M.Carlson,E.Davies,Z.Wang,W.Weiss, 1028 www.ietf.org/rfc/rfc2475.txt 1030 [RFC 2597] "Assured Forwarding PHB Group", F. Baker, J. Heinanen, W. 1031 Weiss, J. Wroclawski, www.ietf.org/rfc/rfc2597.txt 1033 [RFC 2598] "An Expedited Forwarding PHB", V.Jacobson, K.Nichols, 1034 K.Poduri, www.ietf.org/rfc/rfc2598.txt 1036 [RFC 2698] "A Two Rate Three Color Marker." J. Heinanen, R. Guerin. 1037 September 1999. www.ietf.org/rfc/rfc2698.txt 1039 [DS-MODEL] "A Conceptual Model for Diffserv Routers", Y. Bernet et 1040 al., draft-ietf-diffserv-model-03.txt, Work in Progress, May 2000 1042 [DS-TERMS] "New terminology for diffserv", D. Grossman, draft-ietf- 1043 diffserv-new-terms-02.txt, work in progress 1045 [QBONE] "Qbone Architecture (v1.0), Ben Teitelbaum (1999), 1046 http://www.internet2.edu/qos/wg/papers/qbArch/ 1048 [TWOBIT] "A Two-bit Differentiated Services Architecture for the 1049 Internet", ftp://ftp.ee.lbl.gov/parpers/dsarch.pdf, 1997 1051 Full copyright statement 1053 Copyright (C) The Internet Society (1999). All Rights Reserved. 1055 This document and translations of it may be copied and furnished to 1056 others, and derivative works that comment on or otherwise explain it 1057 or assist its implementation may be prepared, copied, published and 1058 distributed, in whole or in part, without restriction of any kind, 1059 provided that the above copyright notice and this paragraph are 1060 included on all such copies and derivative works. 1062 However, this document itself may not be modified in any way, such as 1063 by removing the copyright notice or references to the Internet 1064 Society or other Internet organizations, except as needed for the 1065 purpose of developing Internet standards in which case the procedures 1066 for copyrights defined in the Internet Standards process must be 1067 followed, or as required to translate it into languages other than 1068 English. 1070 The limited permissions granted above are perpetual and will not be 1071 revoked by the Internet Society or its successors or assigns. 1073 This document and the information contained herein is provided on an 1074 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1075 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1076 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1077 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1078 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1080 Authors Addresses 1082 Danny Goderis 1083 Alcatel Corporate Research Center 1084 Fr. Wellesplein 1, 2018 Antwerpen, Belgium. 1085 Tel : +32 3 240 7853 1086 Fax : +32 3 240 9932 1087 E-mail: Danny.Goderis@Alcatel.be 1088 Yves T'Joens 1089 Alcatel Corporate Research Center 1090 Fr. Wellesplein 1, 2018 Antwerpen, Belgium. 1091 Tel : +32 3 240 7890 1092 Fax : +32 3 240 9932 1093 E-mail: Yves.TJoens@Alcatel.be 1095 Christian Jacquenet 1096 France Telecom Research and Development (FT R&D) 1097 Rue des Coutures 42, BP6243, 14066 CAEN CEDEX 04 France 1098 Tel : +33 2 31 75 94 28 1099 Fax : +33 2 31 73 56 26 1100 E-mail: christian.jacquenet@francetelecom.fr 1102 George Memenios 1103 Research Associate, Telecommunications Laboratory NTUA 1104 Heroon Polytechniou 9, 157 73 Zografou, Athens, Greece 1105 Tel : +30 1 772 1494 1106 Fax : +30 1 772 2534 1107 E-mail: gmemen@telecom.ntua.gr 1109 George Pavlou 1110 Centre for Communication Systems Research (CCSR) 1111 Univ. of Surrey, Guildford, Surrey GU2 7XH, UK 1112 Tel : +44 (0)1483 259480 1113 Fax : +44 (0)1483 876011 1114 E-mail: G.Pavlou@eim.surrey.ac.uk 1116 Richard Egan 1117 Racal Research Ltd 1118 Worton Drive, Worton Grange Industrial Estate 1119 Reading, Berkshire RG2 OSB, UK 1120 Tel : +44 118 986 8601 1121 Fax : +44 118 923 8399 1122 E-mail: richard.egan@rrl.co.uk 1124 David Griffin 1125 Department of Electronic and Electrical Engineering 1126 University College London, Torrington Place, London WC1E 7JE, UK 1127 Tel : +44 (0)20 7679 3557 1128 Fax : +44 (0)20 7388 9325 1129 E-mail: D.Griffin@ee.ucl.ac.uk 1130 Panos Georgatsos 1131 Algosystems S.A. 1132 Sardeon str. 4, 172 34 Athens, Greece 1133 Tel : +30 1 93 10 281 1134 Fax : +30 1 93 52 873 1135 E-mail: pgeorgat@algo.com.gr 1137 Leonidas Georgiadis 1138 Aristotel Univ. of Thessaloniki, Faculty of Engineering 1139 School of Electrical and Computer Engineering, Telecommunications Dept. 1140 PO Box 435, Thessaloniki, 54006, Greece 1141 Tel : +30 31 996385 1142 Fax : +30 31 996312 1143 E-mail: leonid@eng.auth.gr 1145 Pim Van Heuven 1146 Inter-University Micro-Electronics Centre 1147 Tel : +32 9 267 3592 1148 E-mail: pvheuven@intec.rug.ac.be