idnits 2.17.1 draft-salsano-aquila-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 == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 an Authors' Addresses Section. ** The abstract seems to contain references ([TEQUILA-SLS]), 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 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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? 'TEQUILA-SLS' on line 714 looks like a reference -- Missing reference section? 'AQUILA' on line 711 looks like a reference -- Missing reference section? 'D1201' on line 706 looks like a reference -- Missing reference section? 'D1301' on line 709 looks like a reference -- Missing reference section? 'QB-BB' on line 712 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Stefano Salsano, CoRiTeL 2 Fabio Ricciato, CoRiTeL 3 Martin Winter, Siemens AG 4 Gerald Eichler, T-Nova 5 Anne Thomas, Dresden Univ. of Techn. 6 Falk Fuenfstueck Dresden Univ. of Techn. 7 Thomas Ziegler, Salzburg Research 8 Christof Brandauer, Salzburg Research 10 Internet Draft: draft-salsano-aquila-sls-00.txt 11 November, 2000 12 Expiration: May, 2001 14 Definition and usage of SLSs in the AQUILA consortium 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other 28 documents at any time. It is inappropriate to use Internet-Drafts 29 as reference material or to cite them other than as "work in 30 progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Distribution of this memo is unlimited. 40 Copyright Notice 42 Copyright (C) The Internet Society (2000). All Rights Reserved. 44 Abstract 46 This document describes the usage of Service Level Specifications in 47 framework of the IST-AQUILA consortium. It represents a positive 48 feedback to the draft "Service Level Specification Semantics and 49 Parameters" [TEQUILA-SLS]. 51 The AQUILA consortium agrees on the need to have a standard formalized 52 representation of SLS between the customer and the network. This 53 representation should be very general and capable to express all the 55 AQUILA consortium Expires May 2001 1 56 possible service offerings based on the Diffserv model. The AQUILA 57 consortium also identified the need for a mechanism to simplify the 58 generic description of the SLS. This led to the definition of 59 "predefined SLS types". 61 The described SLS approach is under realization in a demonstrator 62 ("AQUILA first trial"), which can provide valuable feedback. 64 Table of Contents 66 Abstract........................................................1 67 Glossary........................................................2 68 1. Introduction ................................................16 69 2. Rationale for having predefined SLS types ...................16 70 3. Semantic content of SLSs ....................................16 71 4. Predefined SLS types ........................................16 72 5. References ..................................................16 73 6. Author Information and Acknowledgements .....................16 75 Glossary 77 a2p any-to-point 78 ACA Admission Control Agent 79 AQUILA Adaptive Resource Control for QoS Using an IP-based Layered 80 Architecture 81 BSP Bucket Size for PR (bytes) 82 BSS Bucket Size for SR (bytes). 83 DSCP Differentiated Services Codepoint 84 EAR Expected Average Rate 85 EAT End-user Application Toolkit 86 M Maximum Allowed Packet Size 87 m Minimum Policed Unit 88 p2a point-to-any 89 p2m point-to-many 90 p2p point-to-point 91 PCBR Premium Constant Bit Rate 92 PMM Premium MultiMedia 93 PMC Premium Mission Critical) 94 PR Peak Rate (bit/s). 95 PVBR Premium Variable Bit Rate 96 RCA Resource Control Agent 97 SLS Service Level Specification 98 SR Sustainable Rate (bit/s) 100 AQUILA consortium Expires May 2001 2 101 1. Introduction 103 The AQUILA [AQUILA] consortium aims at defining and implementing a 104 layered architecture [D1201] for the support of QoS in IP networks. In 105 the AQUILA architecture (see Figure 1) a reservation request is sent by 106 the so called "End-user Application Toolkit" (EAT) to the "Admission 107 Control Agent" (ACA). The reservation request specifies the required 108 resources and QoS level and provides the information needed to identify 109 the flow(s) to which the reservation applies. Resources are managed by 110 the "Resource Control Agent" (RCA). 112 In the AQUILA approach, the semantic content of the reservation request 113 is identified in chapter 2 of [D1301], and then it is used to define the 114 actual communication protocol, which is based on CORBA. One goal of this 115 document is to compare the approach followed by AQUILA with [TEQUILA- 116 SLS]. Therefore the notation used in this document is harmonized as much 117 as possible with notation in [TEQUILA-SLS]. 119 The AQUILA consortium is in the process of implementing its proposed 120 architecture in a demonstrator. This can give an interesting feedback on 121 the SLS concepts that are discussed here. This document includes 122 comments on what features are implemented in the demonstrator, which 123 will be referred to as "AQUILA first trial". 125 There is a set of commonalties between the AQUILA and TEQUILA 126 approaches. The main difference is that the AQUILA consortium has 127 introduced the concept of predefined SLS types that are based on the 128 generic SLS definition. These predefined SLS types can be used to 129 simplify the interaction between the customer and the network. From the 130 point of view of the applications, a predefined SLS type supports a 131 range of applications that have similar communication behavior and 132 therefore similar QoS requirements, such as for delay, packet loss, etc. 133 From operator's point of view it simplifies the network management and 134 allows efficient flow aggregation. 136 Section 2 describes the rationale for having predefined SLS types, 137 section 3 specifies the semantic content of the generic AQUILA SLS, 138 section 4 provides examples of predefined SLS types, showing the SLS 139 types that will be provided in the AQUILA first trial. 141 AQUILA consortium Expires May 2001 3 142 +-------+ +-------+ 143 | |---------| EAT | +-------+ 144 | | +-------+ -----| RCA | 145 | | | / +-------+ 146 | | +-------+ / 147 | Host | | ACA |/ 148 | | +-------+ Resource Control layer 149 | | - - - | - - - - - - - - - - - - - - - 150 | | | Transport layer 151 | | +-------+ +-------+ 152 | |---------| Edge |---------| Core |-- 153 | | |Router | |Router | 154 +-------+ +-------+ +-------+ 156 Figure 1: Simplified view of AQUILA architecture 158 2. Rationale for having predefined SLS types 160 The Service Level Specification is the technical way to express what the 161 operator of a Diffserv network can provide to a customer. Defining a 162 generic SLS means trying to capture all the possible service offerings 163 that can be provided over a Diffserv network. A quite complex set of 164 parameters will be contained in the generic SLS. 165 An instance of the generic SLS, containing concrete values for the 166 parameters represents an "external" service that is provided to a 167 customer by the Diffserv network operator. 169 The Diffserv network operator will use the SLS parameters to map the 170 user requirements into internal mechanisms (e.g. Diffserv QoS classes). 171 The mapping process between the generic SLS and the concrete QoS 172 mechanisms can be very complex if the user can freely select and combine 173 the parameters. Inefficiencies can also be added. Incidentally, it is 174 commonly believed that only a few QoS classes will be handled in core 175 Diffserv networks. 177 To solve these problems a drastic approach is indeed to standardize the 178 external services offered to the customer, possibly having a one-to-one 179 mapping with the internal mechanisms in the Diffserv network. The idea 180 of having "Globally Well known Services" is for example used in [QB-BB]. 182 The approach proposed in this draft is more generic. The idea is to have 183 a powerful generic SLS description template and to define external 184 services as "predefined SLS type", in terms of the generic SLS template. 185 A "predefined SLS type" fixes values (or range of values) for a subset 186 of the parameters in the generic SLS. It may also fix some relationships 187 or dependencies between some parameters. If this mechanism is used, the 188 SLS that is invoked by the customer will carry an indication of the 189 "predefined SLS type" and it will contain the actual values for the 190 parameters that are not fixed. 191 It is important to note that the proposed mechanism is not mandatory, 192 but it only adds a capability to the SLS negotiation mechanism. It is 194 AQUILA consortium Expires May 2001 4 195 always possible to have unrestricted (or "custom") SLSs between the 196 customer and the network. It is up to the network operator to choose the 197 preferred way of offering services to the customer: by means of the 198 generic SLS template, by using predefined SLS types, or both. 199 As a predefined SLS type is always defined in terms of the generic SLS 200 description template, it represents a "compression" of the latter to 201 optionally ease the mapping process inside the network and the 202 negotiation between the customer and the network. 204 Another technical reason to have predefined SLS can be found looking at 205 the requirements of IP applications. For example three important groups 206 of Internet applications that could benefit from Quality of Service are: 207 - Interactive multimedia applications where multimedia data are 208 exchanged and showed immediately (e.g. Multimedia Conferences, Voice 209 over IP). 210 - Streaming multimedia applications where multimedia data are 211 downloaded by the client and buffered (e.g. Audio/Video on Demand, 212 Internet TV). 213 - Mission critical applications where discrete, real-time data are 214 reliably exchanged (e.g. Business to Business, Online Banking, Online 215 Games). 216 Applications corresponding to one of these groups have relatively 217 similar QoS behavior and requirements: interactive multimedia 218 applications mainly depend on throughput (bandwidth), delay, and jitter; 219 streaming multimedia applications mainly depend on throughput; mission 220 critical applications mainly depend on delay and packet loss whereas 221 their bandwidth need is relatively low. 222 This repartition of widely spread applications into similar QoS behavior 223 and requirement groups is the basic rationale behind providing 224 predefined SLS types. The aim of the design/creation/ realization of a 225 predefined SLS type consists in adjusting its features in order to 226 support one group of applications having similar QoS behavior and 227 requirements. 229 3. Semantic content of SLSs 231 The semantic content of the AQUILA SLS is composed of the following 232 attributes: 234 - SLS type 235 - Scope 236 - Flow identification 237 - Traffic description and conformance testing 238 - Performance guarantees 239 - Service schedule 241 3.1 SLS type 243 The SLS type distinguishes between a CUSTOM SLS and a PREDEFINED SLS 244 type. Within an instance of a CUSTOM SLS all the parameters can be 246 AQUILA consortium Expires May 2001 5 247 freely specified and combined. When a PREDEFINED SLS type is used, only 248 a subset of the parameters must be specified in the SLS instance and 249 some restrictions apply on the range of parameter values and on the 250 allowed combination of parameters. 252 The list of predefined SLS types defined in the AQUILA project is: 253 PCBR - Premium CBR; 254 PVBR - Premium VBR; 255 PMM - Premium MultiMedia; 256 PMC - Premium Mission Critical. 258 A more detailed definition of these SLS types is given in section 4. 260 Note: the CUSTOM SLS is not implemented in the AQUILA first trial. 262 3.2 Scope 264 The Scope attribute indicates the typology of the ongoing reservation 265 with reference to the end-points of the traffic flow. The following 266 Scopes are defined: 267 p2p - point-to-point; 268 p2a - point-to-any; 269 p2m - point-to-many; 270 a2p - any-to-point; 271 m2p _ many-to-point. 273 Point to point scope means that the ingress and egress interfaces of the 274 traffic flow are specified; p2a means that an ingress interface is 275 specified, while the flow can exit the network from any egress 276 interface; p2m means that there is a given ingress interface and a set 277 of possible egress interfaces for the flow (note that only unicast flows 278 are considered, so p2m does not mean multicast); a2p means that the 279 egress point is given and the traffic can enter from any ingress 280 interface; m2p means that there is a given egress interface and a set of 281 possible ingress interfaces. 283 Note: only p2p and p2a scopes are implemented in the AQUILA first trial. 285 3.3 Flow identification 287 Flow identification focuses on the association between packets and SLSs. 288 The term flow refers to a stream of IP packets that are somehow related. 290 3.3.1 Discussion on flow identification 292 The IP header and higher level 4 headers include fields that can be 293 analyzed for appropriate QoS handling decisions, e.g. SLS association. 294 There are four basic types of flow identification that can be combined: 295 Address based, Protocol based, Port Number based, DSCP based flow 296 identification. 298 Address based flow identification: 300 AQUILA consortium Expires May 2001 6 301 Address based flow identification allows to identify packets from a 302 certain source and/or to a certain destination using the address fields 303 in the IP header. Care must be taken when address translation is 304 performed. Beside single addresses also addresses of a sub-network will 305 be supported. 307 Protocol based flow identification: 308 The Layer 4 protocol is indicated within the IP header protocol field. 309 Flows can be classified on the basis or their Layer 4 protocol. 311 Port Number based flow identification: 312 The TCP and UDP header contain source and destination port numbers which 313 typically specify the required service. Instead of single port numbers 314 port number ranges are sometimes required. 316 DS-Byte based flow identification: 317 The Diffserv Code Point (DSCP) is contained in the DS-Byte of the IP 318 header (the former "Type of Service" Byte). In case of DSCP based 319 identification, the Diffserv node uses the DSCP of incoming packets for 320 classification. This means that the packets have been appropriately 321 marked in the upstream nodes (for example using "host marking" if the 322 upstream node is an end-user). 324 3.3.2 Specification of flow identification 326 A flow is identified by matching the fields in the packet headers with 327 the flow ID attributes given in the SLS. An EXTENDED FlowID and a BASIC 328 FlowID are proposed. 330 The Basic FlowID attribute has 6 components: 332 Source IP address 333 Destination IP address 334 Protocol ID 335 Source Port Number / Number Range 336 Destination Port Number / Number Range 337 DS-byte 339 A packet should match all the 6 components in the BASIC FlowID to be 340 associated to the SLS. Each component can be replaced by a wildcard, 341 this means that all the packets match that component. The Source and 342 Destination IP address can have "partial" wildcards to select a range of 343 addresses. For the source and destination ports, a single port number of 344 a range of contiguous ports can be specified. 346 If more complex classifying rules are needed, the EXTENDED FlowID is 347 used. The EXTENDED FlowID is the logical OR of a set of Basic FlowID. 349 Note: in the AQUILA first trial only the Basic FlowID is implemented. 351 3.4 Traffic description and conformance testing 353 AQUILA consortium Expires May 2001 7 354 The Traffic description and conformance testing attributes aim to 355 provide an effective description of the traffic relevant to the 356 reservation. This description is needed by the policing and admission 357 control functions in the Diffserv network. As for the policing, the 358 traffic description should enable simple policing algorithms at the 359 network side, to easily check whether a specific traffic realization is 360 in-profile or out-of-profile. As for the admission control, the traffic 361 description should capture the fundamental characteristics of the 362 traffic, in order to allow the network to perform an effective admission 363 decision. 365 There are a lot of different traffic description models ("Traffic 366 descriptor algorithms"). The SLS must specify which Traffic descriptor 367 algorithm is used and provide the relevant parameters. The following 368 Traffic descriptor algorithms have been defined so far: 370 - Single-Rate (intended for deterministic CBR sources). 371 - Dual-Token-Bucket (for bursty sources with limited peak rate). 372 - Single-Token-Bucket (for adaptive sources, e.g. TCP). 374 The set of parameters for each Traffic descriptor algorithms is provided 375 in Table 1. 377 Table 1: Traffic Description Parameters 378 ---------------------------------------------------------------- 379 Traffic descriptor algorithm | Parameters 380 ------------------------------|--------------------------------- 381 Single-Rate | PR, m, M, BSP, EAR 382 Dual-Token-Bucket | SR, BSS, PR, m, M, BSP, EAR 383 Single-Token-Bucket | SR, BSS, m, M 384 ---------------------------------------------------------------- 386 The parameters are explained hereafter: 388 - PR : Peak Rate (bit/s). 389 - BSP : Bucket Size for PR (bytes). 390 In conjunction with PR the BSP forms a single token bucket meter. The 391 role of BSP is to allow for a little tolerance in the definition/ 392 policing of the peak rate, similarly to CDVT (Cell Delay Variation 393 Tolerance) in ATM, in order to accommodate for the jitter introduced by 394 the elements of the access network. Typically its value is assumed 395 implicitly by the network. Expected typical values are around 4-5 times 396 M. 398 - SR : Sustainable Rate (bit/s). 399 - BSS : Bucket Size for SR (bytes). 400 In conjunction with SR the BSS forms a single token bucket meter. The 401 role of BSS is to allow for some burstiness in the source traffic flow. 403 - M : Maximum Allowed Packet Size. 404 - m : Minimum Policed Unit. 406 - EAR : Expected Average Rate. 408 AQUILA consortium Expires May 2001 8 409 If used it could allow for a better resource allocation. It is well 410 known that the sustainable rate is in general larger than the average 411 rate, and for some traffic sources the difference may be distance is 412 considerable. The customer could be stimulated by means of a tariff 413 policy to provide information about its expected average rate. The 414 network could then check a posteriori if the advertised average rate has 415 been met within some tolerance. Anyway the EAR is not subject to be 416 policed by the ED. 418 Both the Single rate and the Single Token Bucket represent a single 419 token bucket policer. The difference is that the Single rate is meant to 420 police the peak rate, therefore the Burst size is typically few times 421 the maximum packet size. 422 With the Dual Token Bucket both the peak rate and the sustained rate are 423 policed. 425 Note: EAR is not implemented in the AQUILA first trial 427 Note: with respect to the TEQUILA approach, this section has been called 428 "Traffic description and conformance testing" instead of "Traffic 429 conformance testing". The idea is that these attributes also aim to 430 describe the traffic in order to perform proper admission control 431 algorithms. 433 3.5 Performance guarantees 435 The performance guarantee attributes describe the QoS requirements of 436 the customer and the commitment of the network to fulfill these 437 requirements. Both quantitative and qualitative attributes are foreseen. 438 The quantitative values can be maximum values, mean values or 439 percentiles. The qualitative attributes can be used to express relative 440 guarantees between different classes. 442 Table 2: Performance guarantee attributes 443 --------------------------------------------------------------- 444 Attribute | Measurement unit 445 ----------------------------------|---------------------------- 446 Quantitative maximum Delay | (ms) 447 Quantitative maximum Jitter | (ms) 448 Quantitative maximum Loss Ratio | 449 | 450 Quantitative Delay percentile | (percentile; ms) 451 Quantitative Jitter percentile | (percentile; ms) 452 | 453 Quantitative mean Delay | (ms) 454 Quantitative mean Jitter | (ms) 455 | 456 Qualitative Delay | (medium/low/very low) 457 Qualitative Jitter | (medium/low/very low) 458 Qualitative Loss Ratio | (medium/low/very low) 459 --------------------------------------------------------------- 461 AQUILA consortium Expires May 2001 9 462 The delay is meant as the one way delay, the jitter is defined as the 463 variation of one way delay (max delay _ min delay) of a flow. 464 The details of the measurement procedure to evaluate statistic 465 parameters like percentiles or mean values should be defined. This is 466 for further study. 468 Note: in the AQUILA first trial only qualitative attributes have been 469 considered 471 3.6 Service schedule 473 The service schedule attributes are needed to provide the information 474 related to the start and the duration of the service. 475 The basic type of reservation is "semi-permanent", which is configured 476 statically and lasts continuously until de-configured. 477 There can be "immediate" dynamic reservations (just like in the 478 telephone network: the reservation starts immediately and remains valid 479 until the user explicitly releases it). More complex scenarios could 480 foresee advanced reservations with start-time and end-time or periodic 481 reservations (daily, weekly...). 483 Table 3 shows a set of possible Service Schedule attributes with their 484 parameters. 486 Table 3: Service schedule attributes 487 -------------------------------------------------------------------- 488 Service schedule | Parameters 489 ----------------------|--------------------------------------------- 490 Immediate | 491 Advance reservation | Start time, start date, End Time, End date 492 Periodic | For further study 493 Semi-permanent | 494 -------------------------------------------------------------------- 496 Semi-permanent and immediate reservations have a similar meaning (from 497 now until released), the need to differentiate between the two is for 498 further study. 500 Note: in the AQUILA first trial only "immediate" reservation are 501 considered. 503 4. Predefined SLS types 505 In this section the four predefined SLS types supported by the AQUILA 506 consortium in the first trial are described. Note that this draft does 507 not intend to recommend the usage of the described set of SLS types as 508 such. The description represents a concrete application of the concept 509 of predefined SLS. The provided values of the parameters often represent 510 a first guess in the search of useful services, subject to tuning after 511 the trial experience. 513 AQUILA consortium Expires May 2001 10 514 The important goal is to show that a part of the parameters of the 515 generic SLS is fixed in the definition of the SLS type, while the 516 remaining set is open and will be specified by the customer in the SLS 517 instance. Therefore the notation (FIXED) and (OPEN) will be used to 518 highlight this concept. An "X" stands for not applicable. 520 4.1 Premium CBR 522 Characteristics 524 The Premium CBR predefined SLS is intended for applications with 525 stringent requirements concerning delay, delay variation, and loss 526 probability. Applications are not assumed to implement any form of 527 congestion control. This predefined SLS is well suited for constant bit 528 rate applications independently of their bandwidth requirements as well 529 as applications that generate low bandwidth VBR flows. The Premium CBR 530 service can be used by applications whose maximum packet size is small. 532 Sample applications 533 Voice applications, VLL-like and Circuit Emulation-like service. 535 Specification of Premium CBR 537 - Scope 538 p2p (FIXED) 540 - Flow identification: 541 to be filled by the customer in the instance SLS (OPEN) 543 - Traffic description and conformance testing: 544 Traffic descriptor algorithm: Single-Rate. 545 ---------------------------------------------------------------- 546 Parameter | Minimum admitted| Maximum admitted| Default | Note 547 ----------|-----------------|-----------------|---------|------- 548 PR | 0 Kb/s | 200 Kb/s | - | (OPEN) 549 BSP | X | X | 512 B | (FIXED) 550 m | 40 B | 256 B | 40 B | (OPEN) 551 M | X | X | 256 B | (FIXED) 552 ----------------------------------------------------------------- 554 - Performance guarantees 555 Qualitative Delay (low) (FIXED) 556 Qualitative Loss Ratio (very low) (FIXED) 558 - Service schedule 559 Immediate (FIXED) 561 Note: Excess traffic for Premium CBR is dropped. At the moment there is 562 no formal way in the AQUILA SLS to express this behavior. It is for 563 further study the extension of AQUILA SLS including a concept like 564 "Excess Treatment" in [TEQUILA-SLS]. 566 AQUILA consortium Expires May 2001 11 567 4.2 Premium VBR 569 Characteristics 570 The Premium VBR predefined SLS is intended for applications with medium 571 to high bandwidth requirements. The requirements concerning delay and 572 delay variation are the same as for the Premium CBR service. While 573 applications are assumed to generate traffic at a variable bit rate no 574 assumptions concerning congestion control mechanisms are made. A 575 restriction on the maximum packet size is enforced. 577 Sample applications 578 Video and teleconferencing. 580 Specification of Premium VBR 582 - Scope 583 p2p (FIXED) 585 - Flow identification: 586 to be filled by the customer in the instance SLS (OPEN) 588 - Traffic description and conformance testing: 589 Traffic descriptor algorithm: Dual-Token-Bucket. 590 ---------------------------------------------------------------- 591 Parameter | Minimum admitted| Maximum admitted| Default | Note 592 ----------|-----------------|-----------------|---------|------- 593 PR | 0 Kb/s | 1 Mb/s | - | (OPEN) 594 BSP | X | X | 1024 B | (FIXED) 595 SR | 0 Kb/s | PR | PR | (OPEN) 596 BSS | M | 30 M | 10 M | (OPEN) 597 m | 40 B | M | 40 B | (OPEN) 598 M | X | X | 512 B | (FIXED) 599 ----------------------------------------------------------------- 601 - Performance guarantees 602 Qualitative Delay (low) (FIXED) 603 Qualitative Loss Ratio (low) (FIXED) 605 - Service schedule 606 Immediate (FIXED) 608 Note: Excess traffic for Premium VBR is dropped. At the moment there is 609 no formal way in the AQUILA SLS to express this behavior. It is for 610 further study the extension of AQUILA SLS including a concept like 611 "Excess Treatment" in [TEQUILA-SLS]. 613 4.3 Premium MultiMedia 615 Characteristics 616 The Premium MultiMedia predefined SLS is intended for high bandwidth 617 applications that require the delivery of some minimum bandwidth at a 618 high probability. Unlike the services mentioned before, the Premium 620 AQUILA consortium Expires May 2001 12 621 MultiMedia service may provide additional bandwidth to the applications. 622 All applications are assumed to implement some kind of congestion 623 control mechanism whose aggressiveness is somewhat similar to the one of 624 TCP. There are no restrictions concerning the packet size. 626 Sample applications 627 Streaming multimedia, Premium FTP 629 Specification of Premium MultiMedia 631 - Scope 632 p2p (FIXED) 634 - Flow identification: 635 to be filled by the customer in the instance SLS (OPEN) 637 - Traffic description and conformance testing: 638 Traffic descriptor algorithm: Single-Token-Bucket. 639 ---------------------------------------------------------------- 640 Parameter | Minimum admitted| Maximum admitted| Default | Note 641 ----------|-----------------|-----------------|---------|------- 642 SR | 0 Kb/s | 250 Kb/s | 100 Kb/s| (OPEN) 643 BSS | M | 30 M | 10 M | (OPEN) 644 m | 40 B | M | 40 B | (OPEN) 645 M | X | X | 1500 B | (FIXED) 646 ----------------------------------------------------------------- 648 - Performance guarantees 649 Qualitative Loss Ratio (medium/low) (FIXED) 651 - Service schedule 652 Immediate (FIXED) 654 Note: Excess traffic for Premium MultiMedia is forwarded with no QoS 655 guarantee. At the moment there is no formal way in the AQUILA SLS to 656 express this behavior. It is for further study the extension of AQUILA 657 SLS including a concept like "Excess Treatment" in [TEQUILA-SLS]. 659 4.4 Premium Mission Critical 661 Characteristics 662 The Premium Mission Critical predefined SLS is intended for applications 663 that generate non-greedy flows with a rather short lifetime. The 664 applications are assumed to implement some kind of congestion control 665 mechanism whose aggressiveness is somewhat similar to the one of TCP. 667 Sample applications 668 Transaction oriented applications 670 - Scope 671 p2a (FIXED) 673 AQUILA consortium Expires May 2001 13 674 - Flow identification: 675 to be filled by the customer in the instance SLS (OPEN) 677 - Traffic description and conformance testing: 678 Traffic descriptor algorithm: Double-Token-Bucket. 679 ---------------------------------------------------------------- 680 Parameter | Minimum admitted| Maximum admitted| Default | Note 681 ----------|-----------------|-----------------|---------|------- 682 PR | 0 Kb/s | 50 Kb/s | - | (OPEN) 683 BSP | X | X | 2048 B | (FIXED) 684 SR | 0 Kb/s | 5 Kb/s | | (OPEN) 685 BSS | M | 10 M | 10 M | (OPEN) 686 m | 40 B | M | 40 B | (OPEN) 687 M | X | X | 1024 B | (FIXED) 688 ----------------------------------------------------------------- 690 - Performance guarantees 691 Qualitative Loss Ratio (very low) (FIXED) 693 - Service schedule 694 Immediate (FIXED) 696 Note: Excess traffic for Premium MultiMedia is forwarded with no QoS 697 guarantee. At the moment there is no formal way in the AQUILA SLS to 698 express this behavior. It is for further study the extension of AQUILA 699 SLS including a concept like "Excess Treatment" in [TEQUILA-SLS]. 701 5. References 703 [AQUILA] "Adaptive Resource Control for QoS Using an IP-based Layered 704 Architecture" IST project 1999-10077 705 http://www-st.inf.tu-dresden.de/aquila/ 706 [D1201] "System architecture and specification for the first trial", 707 IST-1999-10077-WP1.2-SAG-1201-PU/b0, Public deliverable of the 708 [AQUILA] project 709 [D1301] "Specification of the traffic handling for the first trial", 710 IST-1999-10077-WP1.3-COR-1301-PU/b0, Public deliverable of the 711 [AQUILA] project 712 [QB-BB] "QBone Bandwidth Broker Architecture" _ Work in Progress _ 713 http://qbone.internet2.edu/bb/bboutline2.html 714 [TEQUILA-SLS] "Service Level Specification Semantics and Parameters", D. 715 Goderis et al. _ draft-tequila-sls-00.txt 717 6. Author Information and Acknowledgements 719 Part of this work has been funded under the European Commission 5th 720 framework IST program. 722 The authors would like to acknowledge all their colleagues in the AQUILA 723 project for their important contribution to this work. 725 AQUILA consortium Expires May 2001 14 726 Stefano Salsano 727 CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni 728 Via di Tor Vergata, 135 729 00133 Roma - ITALY 730 e-mail: salsano@coritel.it 732 Fabio Ricciato 733 CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni 734 Via di Tor Vergata, 135 735 00133 Roma - ITALY 736 e-mail: ricciato@coritel.it 738 Martin Winter 739 Siemens AG, ICN WN CC EK A19 740 81359 Munich - Germany 741 e-mail: martin.winter@icn.siemens.de 743 Gerald Eichler 744 T-Nova Deutsche Telekom Innovationsgesellschaft mbH 745 Am Kavalleriesand 3 746 64295 Darmstadt _ GERMANY 747 e-mail: Gerald.Eichler@telekom.de 749 Falk Fuenfstueck 750 Dresden University of Technology 751 Institute for Software- and Multimedia-Technology 752 D-01062 Dresden 753 e-mail: Falk.Fuenfstueck@inf.tu-dresden.de 755 Anne Thomas 756 Dresden University of Technology 757 Institute for Software- and Multimedia-Technology 758 D-01062 Dresden 759 e-mail: Anne.Thomas@inf.tu-dresden.de 761 Thomas Ziegler 762 Salzburg Research Forschungsgesellschaft m.b.H. 763 Jakob HaringerstraBe 5 764 5020 Salzburg - AUSTRIA 765 email: Thomas.Ziegler@salzburgresearch.at 767 Christof Brandauer 768 Salzburg Research Forschungsgesellschaft m.b.H. 769 Jakob HaringerstraBe 5 770 5020 Salzburg - AUSTRIA 771 email: Christof.Brandauer@salzburgresearch.at 773 AQUILA consortium Expires May 2001 15