idnits 2.17.1 draft-ietf-intserv-svc-template-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 283: '...uirements. The service definition MUST...' RFC 2119 keyword, line 304: '...rvice definition SHOULD additionally s...' RFC 2119 keyword, line 332: '... document MUST contain the sections ...' RFC 2119 keyword, line 333: '...d. Each document SHOULD contain each o...' RFC 2119 keyword, line 387: '... packet handling SHOULD, when at all p...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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) No issues found here. Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Integrated Services WG 2 INTERNET-DRAFT S. Shenker/J. Wroclawski 3 draft-ietf-intserv-svc-template-01.txt Xerox PARC/MIT LCS 4 June, 1995 5 Expires: 12/25/95 7 Network Element Service Specification Template 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress". 21 To learn the current status of any Internet-Draft, please check the 22 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 This draft is a product of the Integrated Services Working Group of 28 the Internet Engineering Task Force. Comments are solicited and 29 should be addressed to the working group's mailing list at int- 30 serv@isi.edu and/or the author(s). 32 Abstract 34 This document defines a format for specifying services provided by 35 network elements, and available to applications, in a network 36 which offers multiple classes of service. The document provides 37 necessary context, including definitions, data formats, and 38 interfaces; then specifies a "template" which service 39 specification documents should follow. The specification template 40 includes per-element requirements such as the service's packet 41 handling behavior, parameters required and made available by the 42 service, traffic specification and policing requirements, and 43 traffic ordering relationships. It also includes evaluation 44 criteria for elements providing the service, and examples of how 45 the service might be implemented (by network elements) and used 46 (by applications). 48 Introduction 50 This document defines the format used to specify the functionality of 51 internetwork system components related to "Integrated Services"; the 52 ability to provide multiple, dynamically selectable qualities of 53 service to applications using the internetwork. The behavior of 54 individual routers and subnetworks is captured as a set of 55 "services", some or all of which may be offered by each element. The 56 concatenation of these services along the end-to-end data paths used 57 by an application provides overall quality of service control. 59 The definition of a service, as specified by this document, states 60 what is required of a router (or, more generally, any network 61 element; a router, switch, subnet, etc.) which supports a particular 62 service. The service definition also specifies parameters used to 63 invoke the service, the relationship between those parameters and the 64 service delivered, and the end-to-end behavior obtained by 65 concatenating several instances of the service. 67 The service definition does not describe the protocols or mechanisms 68 used to establish state in the network elements for flows that use 69 the described service, but may specify information which must be 70 carried between end-nodes and network elements by those mechanisms. 72 Services defined following the guidelines of this document are 73 intended for use both within the global Internet and private IP 74 networks. In certain cases a concatenation of network element 75 services may be used to provide a range of end-to-end behaviors; some 76 more suited to a decentralized internet and some more appropriate for 77 a tightly managed private network. This document points out places 78 where such distinction may be appropriate. 80 Definitions 82 The following terms are used throughout this document. Service 83 specification documents should employ the same terms to express these 84 concepts. 86 o Quality of Service (QoS) 88 In the context of this document, quality of service refers to the 89 suitability of a packet delivery service for the needs of a 90 particular application, as defined by parameters such as achieved 91 bandwidth, packet delay, and packet loss rates. Traditionally, the 92 Internet has offered a single quality of service; best-effort 93 delivery with available bandwidth and delay characteristics dependent 94 on instantaneous load. Control over the quality of service seen by 95 applications is exercised by adequate provisioning of the network 96 infrastructure. In contrast, a network with dynamically controllable 97 quality of service allows individual application sessions to request 98 network packet delivery characteristics according to their perceived 99 needs, and may provide different qualities of service to different 100 applications. It should be understood that there is a range of useful 101 possibilities between the two endpoints of providing no dynamic QoS 102 control at all and providing extremely precise and accurate control 103 of QoS parameters. 105 o Network Element 107 A "Network Element" (or the equivalent shorter form "Element"), is 108 any component of an internetwork which directly handles data packets 109 and thus is potentially capable of exercising QOS control over data 110 flowing through it. Network elements include routers, subnetworks, 111 and end-node operating systems. A "QOS-aware" network element is one 112 which offers one or more of the services defined according to the 113 format of this document. Note that this definition does not by itself 114 preclude QoS-aware network elements which meet performance goals 115 purely through adequate provisioning, rather than active control 116 mechanisms. 118 o Flow 120 For the purposes of this document a flow is a set of packets 121 traversing a network element all of which are covered by the same 122 request for control of quality of service. At a given network element 123 a flow may consist of the packets from a single application session, 124 or it may be an aggregation comprising the combined data traffic from 125 a number of application sessions. 127 Mechanisms used to associate a request for quality of service control 128 with the packets covered by that request are beyond the scope of this 129 document. 131 o Service 133 The word "service" describes a named, coordinated set of QoS control 134 capabilities provided by a single network element. The definition of 135 a service includes a specification of the functions to be performed 136 by the network element, the information required by the element to 137 perform these functions, and the information made available by the 138 element to other elements of the system. 140 A service is conceptually implemented within a "service module" 141 contained within the network element. A network element may and 142 generally will contain more than one service module and hence offer 143 more than one service. 145 NOTE: The above defines a precise meaning for the word "service"; 146 a word which has a variety of meanings throughout the networking 147 community. The definition of "service" given here refers 148 specifically to the actions and responses of a single network 149 element such as a router or subnet. This contrasts with the more 150 end-to-end oriented definition of the same word seen in some other 151 networking contexts. 153 o Behavior 155 A "behavior" is the QoS-related end-to-end performance seen by an 156 application session. This behavior is the end result of composing the 157 services offered by each network element along the path of the 158 application's data flow. 160 When each network element along a data flow path offers the same 161 service, it is frequently possible to explain the resulting end-to- 162 end behavior in a straightforward fashion. The behavior of a data 163 flow path comprised of elements using different services is more 164 complicated, and may in fact be undefined. A future version of this 165 document may impose additional requirements on the service 166 specification relating to multi-service concatenation. 168 o Characterization 170 A characterization is a computed approximation of the actual end-to- 171 end behavior which would be seen by a flow requesting specific QoS 172 services from the network. By providing additional information to 173 the end-nodes before a flow is established, characterizations assist 174 the end-nodes in choosing the services to be requested from the 175 network. 177 o Characterization Parameters 179 Characterizations are computed from a set of characterization 180 parameters provided by each network element on the flow's path, and a 181 composition function which computes the end-to-end characterization 182 from those parameters. The composition function may in practice be 183 executed in a distributed fashion by the setup or routing protocol, 184 or the characterization parameters may be gathered to a single point 185 and the characterization computed at that point. 187 Several characterizations may be computed for a single candidate data 188 flow. Conversely, characterizations are not mandatory, and under some 189 conditions no characterizations may be available to the end-nodes 190 requesting QoS services. 192 o Composition Function 194 A composition function accepts characterization parameters as input 195 and computes a characterization, as described above. 197 o Traffic Specification (TSpec) 199 A Traffic Specification, or TSpec, is a specification of the traffic 200 pattern which a flow expects to exhibit. As examples, this 201 specification might take the form of a token bucket filter (defined 202 below) or an upper bound on the peak rate. Note that the traffic 203 specification specifies the flow's -expected- traffic pattern, not 204 the flows -actual- traffic pattern. The behavior of a service when a 205 flow's actual traffic does not conform to the traffic specification 206 must be defined by the service (see "Policing" below). 208 Traffic specifications are most frequently created by the originator 209 of the data flow. 211 o Service Request Specification (RSpec) 213 A Service Request Specification, or RSpec, is a specification of the 214 quality of service a flow desires from a network element. The form of 215 a service request specification is highly specific to a particular 216 service. As examples, these specifications might contain information 217 about bandwidth allocated to the flow, maximum delays, or packet loss 218 rates. Service request specifications may originate from either the 219 sender or receiver(s) of a data flow. 221 o Setup Protocol 223 A setup protocol is used to carry QoS-related information from the 224 end-nodes requesting QoS control to network elements which must 225 exercise that control, and to install and maintain to required QoS 226 control state in those network elements. A setup protocol may also 227 be used to collect QoS-related information from interior network 228 elements along an application's data flow path for ultimate delivery 229 to end nodes. Examples of protocols which perform setup functions are 230 RSVP [xxx], ST-II [xxx] and Q.2931 [xxx]. 232 o Token Bucket 234 A particular form of traffic specification consisting of a "token 235 rate" R and a "bucket size" B. Essentially, the R parameter specifies 236 the continually sustainable data rate, while the B parameter 237 specifies the extent to which the data rate can exceed the 238 sustainable level for short periods of time. 240 Token buckets are further discussed in [xxx]. 242 o Token Bucket Filter 244 A filtering or policing function which differentiates those packets 245 in a traffic flow which conform to a particular token bucket 246 specification from those packets which do not. The specific treatment 247 accorded nonconforming packets is not specified in this definition; 248 common actions are discarding of the packet or marking the packet in 249 some fashion. 251 NOTE: The definition of token bucket in this document does not 252 allow for token bucket filters with a "backing buffer" which 253 queues packets that do not immediately pass through the filter. 254 The intent is to cleanly distinguish the bufferless case from the 255 buffer case through the use of different names; however this draft 256 does not yet provide a definition for the second case. 258 o Admission Control 260 Admission control is the process of deciding whether a newly arriving 261 request for service from a network element can be granted, or must be 262 refused due to scarcity of resources. This action must be performed 263 by any service which wishes to offer absolute quantitative bounds on 264 overall performance. It is not necessary for services which provide 265 only relative statements about performance, such as the Internet's 266 current best-effort service. The precise criteria for making the 267 admission control decision are a specific to each particular service. 269 o Policing 271 Policing is the set of actions triggered when a flow's actual data 272 traffic characteristics exceed the expected values given in the 273 flow's traffic specification. Services which require policing 274 functions to operate correctly must specify the locations in the 275 network where discrepancies are to be detected and the action to be 276 taken when such discrepancies occur. Examples of such actions might 277 include dropping packets, reshaping the traffic, or marking non- 278 conforming traffic for later discard if necessary. 280 Data Format and Representation 282 Each service module will import and export a variety of data 283 according to its specific requirements. The service definition MUST 284 specify the format of each such data item in an abstract manner. The 285 information specified must be sufficient for the designer of a setup 286 protocol to correctly select an appropriate concrete (packet) format 287 for variables containing this data. At minimum, the following 288 information must be given: 290 - Type: whether the quantity is an enumeration, a numerical value, 291 etc. 293 - Range: for numerical quantities, the minimum and maximum values 294 the quantity must be able to represent. For enumerated quantities, 295 an estimate of the maximum number of items which may need be 296 enumerated in the future, even if many of the values are currently 297 unused. 299 - Precision: the precision with which a numerical quantity must be 300 represented, and whether that precision is absolute (calling for an 301 integer quantity) or a percentage of the value (allowing for a 302 floating point quantity). 304 The service definition SHOULD additionally specify a preferred 305 concrete format for each data field, in the usual packet-layout 306 format used in current Internet Standard documents. If the service 307 definition contains these concrete definitions, they should be 308 sufficiently complete and detailed to allow the service definition to 309 be incorporated by reference into the specifications for setup 310 protocols and other users of the specified data. 312 NOTE: The wording above is intended to encourage the use of common 313 data formats by all protocols carrying data related to a specific 314 service, while not mandating this common format or infringing on 315 the freedom of protocol specification designers to define data 316 representations using alternative mechanisms such as ASN.1 or XDR. 318 Interfaces 320 The service module conceptually interacts with other portions of the 321 network element through a number of interfaces. These interfaces are 322 documented in [xxx; the non-existent new IS - Overview RFC]. The 323 service specification document should clearly define each the 324 specific data, including formats, which moves across each conceptual 325 interface, and ensure that the mapping between conceptual interfaces 326 and the specific mechanisms of the service being defined are clear. 328 Specification Document Format 330 The following portion of this document describes the layout and 331 contents of a service specification. Each service specification 332 document MUST contain the sections marked [required] below, in the 333 order listed. Each document SHOULD contain each of the remaining 334 sections in the list below, unless there is a compelling argument 335 that the presence of the section is not beneficial. Additional 336 material, including references, should be included at the end of the 337 document. 339 o Components 341 The body of a service specification document incorporates the 342 following sections: 344 - Motivation [required] 346 - Network Element Data Handling Requirements [required] 348 - Invocation Information [required] 350 - Exported Information [required] 352 - Policing [required] 354 - Ordering and Merging [required] 356 - Resulting Service [required] 358 - Guidelines for Implementors 360 - Evaluation Criteria [required] 362 - Examples of Implementation 364 - Examples of Use 366 o Motivation 368 This section discusses why this service is being defined. It 369 describes what kinds of applications might make use of this service, 370 and why this service might be more appropriate for those applications 371 than other possible choices. This section is for informational 372 purposes only. 374 o Network Element Data Handling Requirements 376 This section contains a description of the QoS properties seen by 377 data packets processed by a network element using this service. The 378 description must clearly explain what variables are controlled, the 379 degree of control exercised, and what aspects of the service's 380 handling model are fixed or assumed. Examples of degree of control 381 information include "this property must be mathematically assured" 382 and "this property should be met under most conditions". An example 383 of a stated assumption is "this service is assumed to have extremely 384 low packet loss; delay targets must be met using admission control 385 rather than by discarding packets when overloaded". 387 Requirements on packet handling SHOULD, when at all possible, be 388 expressed as performance requirements rather than by specifying a a 389 particular packet scheduling algorithm. The performance requirements 390 might, for example, be a specification of the maximal packet delays 391 or the minimal bandwidth share given to a flow. 393 This section also specifies actions which the packet handling path is 394 required to take to actively provide feedback to end-nodes about 395 conditions at the network element. Such actions might include the 396 explicitly generated congestion feedback, indicated either as bits 397 set in the header of data packets or separate control messages sent. 399 When writing this section of the service specification document, the 400 authors' goal should be to specify the required behavior as precisely 401 as necessary while still leaving adequate room for the implementation 402 and architectural tradeoffs appropriate to different circumstances 403 and classes of network elements. Successfully achieving this balance 404 may require some care. 406 o Invocation Information 408 This section describes the set of parameters required by a service 409 module to invoke the service, and a description of how the parameter 410 values are used by the service module. For example, a hypothetical 411 "bounded delay" service might be described as accepting a request 412 indicating a delay target for the network element and the set of 413 packets subject to that delay target, and processing packets in the 414 given set with a delay of the target value or less. 416 Necessary invocation information for most services can be broken into 417 two parts, the Traffic Specification (TSpec) and the Service Request 418 Specification (RSpec). The TSpec gives characteristics of the data to 419 be handled, while the Rspec specifies the properties desired from the 420 service. For example, a service offering a mathematical bound on 421 delay might accept a TSpec giving the traffic flow's bandwidth and 422 burstiness specified as a Token Bucket, and an RSpec giving the 423 maximum tolerable queueing delay. These two components of the 424 invocation information should be specified separately and 425 independently, as they will often be generated and transported by 426 different elements of the internetwork 428 All quantitative information specifications in this section should 429 follow the guidelines given in the Data Formats section of this 430 document, above. 432 o Exported Information and Characterization Parameters 434 This section describes information which must be collected and 435 exported by the service module. Exported information is available to 436 other portions of the network element, and by extension to setup 437 protocols, routing protocols, network management tools, and the like. 439 Information exported by service modules may be used in several ways. 440 For example, quantities such as the amount of link bandwidth 441 dedicated to the service and the set of data flows currently 442 receiving the service are appropriate pieces of information to make 443 available as network management variables. 445 A service definition may identify a particular subset of the 446 information exported by a service module as characterization 447 parameters. These characterization parameters may be used to compute 448 or estimate the end-to-end behavior of a data flow traversing a 449 concatenation of network service elements. A service which defines 450 characterization parameters also specifies the characterizations they 451 are used to generate and the composition functions used to generate 452 the characterizations. 454 NOTE: Characterization parameters are identified as such by virtue 455 of being the inputs to a service's defined composition functions. 456 Because characterization parameters are part of a service's 457 overall exported data set, they are also available to other 458 functions, such as network management. The discussion below 459 relates soley to their use as characterization parameters, and is 460 not intended to limit other uses. 462 Characterization parameters may be relatively static quantities, such 463 as the bandwidth available on a specific link, or relatively dynamic 464 quantities, such as a running estimation of current packet delay. 466 Support for a service's defined characterization parameters is 467 mandatory. Any network element offering this service must be able to 468 measure, compute, or, if allowed by the specification, estimate the 469 service's characterization parameters. Service designers are 470 encouraged to understand the implications of specifying 471 characterization parameters for a service, particularly with respect 472 to not unduly restricting the choice of hardware and software 473 architectures used to implement the network element. 475 Characterization parameters are used by composing the values exported 476 by each network element along a data flow's path according to a 477 composition rule. For each parameter or set of parameters used to 478 develop a characterization, the service specification must specify 479 the composition rule to be used. These composition rules should 480 result in characterizations that are independent of the order in 481 which the element are composed; commutativity and associativity are 482 sufficient but not necessary conditions for this. 484 Characterization parameters are available through a general 485 interface, and are provided in response to a request that would most 486 likely come from either the setup protocol or the routing protocol. 487 The issue of exactly how, or if, a specific protocol (e.g., RSVP) 488 uses characterization parameters to generate characterizations should 489 be described in the specification of that specific protocol. 491 There is no requirement that setup and routing protocols use the 492 characterization parameters supplied by service modules, and there is 493 no guarantee that characterizations will be available to end-nodes 494 desiring to use a QOS control service. Service designers targeting 495 services for the global Internet may wish to ensure that a service is 496 useful even in the absence of characterizations, and to exhibit such 497 uses in the "Examples" sections of the service description document. 499 Conversely, the availability of characterizations may be mandatory in 500 certain circumstances, particularly for private IP networks providing 501 tightly controlled qualities of service for specific applications. 502 Service designers targeting this environment should particularly 503 ensure that the service provides adequate characterization parameters 504 and composition functions to fully meet the needs of target 505 audiences. It may be appropriate to specify the same basic service 506 with additional characterizations for meeting specific requirements 507 beyond those of the global Internet. 509 It may be useful to define "generic" characterization parameters not 510 associated with any specific service. These might include the 511 speed-of-light latency of communication links (additive composition 512 rule) and available link bandwidth (minimum composition rule). 513 Eventually, these generic parameters should be defined in the 514 Integrated Services overview document, and incorporated by reference 515 in the Router Requirements document and the relevant service 516 specification documents. 518 Characterization parameters are named, so that protocols which 519 transport and use these parameters can uniquely identify them. The 520 namespace is a two-level hierarchy: .; 521 each of these elements is a numerical quantity. This same namespace 522 is used to name the results of composition functions which are made 523 available to end-nodes. The service specification author may also 524 choose to name intermediate data which might be transported as part 525 of a distributed composition function computation. The reason for 526 assigning names to these data objects is to support a variety of 527 styles for calculating the composition function, and to ensure that 528 the end-nodes can clearly determine the meaning of data delivered to 529 them as part of a characterization. 531 - is a 16-bit number. The number space is broken 532 into two regions. The region below 32768 (high bit 0) is managed by 533 the IANA. Procedures for allocating service numbers in this region 534 will be established by the IETF INT-SERV WG and the IANA. Services 535 designed for public use should obtain a number from this space; the 536 minimum requirement is a published RFC following the format 537 described in this note. 539 Numbers in the region above 32768 are reserved for experimental or 540 private services. Service designers may allocate numbers from this 541 space at random for local experimental use. A policy for global but 542 temporary allocation of these numbers may be appropriate in the 543 future. 545 - is a 16-bit number assigned on a per-service 546 basis. Numbers are allocated by the author of the service 547 specification document. 549 [ Is 16 bits too big? Could be 8.8, or a non-byte split such as 550 6.10 ] 552 Service Number 0 (zero) is reserved for the "generic" parameters 553 described above. Parameter numbers within this space are initially 554 allocated by the INT-SERV WG, and may in the future be allocated by 555 IANA. 557 These . pairs should be used as 558 last two levels of the MIB name when the parameters are made 559 available to network management protocols. 561 o Policing 563 This portion of the service description describes the nature of 564 policing used to enforce adherence to a flow's Traffic Specification. 565 The specification document must specify the following points 567 - Expected policing action. This is the action taken when packets 568 not conforming to the TSpec are detected. Example actions include 569 immediately dropping nonconforming packets, delaying these packets 570 until they once again "fit" into the TSpec, or "marking" 571 nonconforming packets in some way, to enable dropping them 572 preferentially if a later network element in the marked packet's 573 path should be overloaded. 575 - Legality of alternative policing actions. The section must 576 specify whether actions not specifically mentioned in 577 specification's description of policing behavior are legal. For 578 example, a service description which specifies that nonconforming 579 packets are to be dropped should state whether an alternate action, 580 such as delaying these packets, is acceptable. 582 - Location of policing actions in the internetwork. The description 583 of policing must specify where that policing is done. Possibilities 584 include "at the edges of the network only", "at every hop", and 585 "source merge points" (points where multiple data streams covered 586 by a single resource reservation converge). The specification 587 should clearly state requirements about topology information (for 588 example "this is an edge node" or "this is a source merge point") 589 which must be available from the setup protocol or another source. 591 In this section the specification should also specify the legality 592 of policing at additional points in the network, beyond those 593 listed above. This is important due to technical effects such as 594 are described in the next paragraph. 596 - Applicable additional technical considerations. If policing of 597 data flows is required or legal at points other than the flow's 598 first entry into the network, the service definition should 599 describe any additional technical considerations which affect the 600 design of such policing. For example, many potential services will 601 allow a data flow to become more bursty as it progresses through 602 the network. If such a service allows policing at points other than 603 the network edge, the traffic specification describing the flow 604 will have to be modified from that given by the application to the 605 network to account for this growing burstiness. Otherwise, it is 606 likely that the flow will be overpoliced, with packets being 607 penalized unnecessarily. 609 o Ordering and Merging 611 Ordering and merging come into play when a service receives several 612 invocation requests covering the same data flow. As examples, this 613 could occur if several receivers of a multicast data flow requested 614 QOS services for that flow using the RSVP setup protocol, or if a 615 flow was subject to both a statically installed permanent invocation 616 request and a dynamic request from a resource setup protocol. 618 In this situation the service module must be able to answer questions 619 about the ordering between different invocation requests, and must be 620 able to generate a single new invocation request which meets the 621 requirements of all the original requesters. This new request is a 622 "merged" request. It may be equal to one of the original requests, or 623 it may be a newly computed request. Operationally, this is achieved 624 by having the setup protocol ask the service module, given a set of 625 requests R1...Rn, to compute an merged request which which results in 626 service to the merged flow at least equivalent to that which any of 627 the original requests would obtain for its corresponding unmerged 628 flow. Hence, the merged invocation request represents an "upper 629 bound" on the set of original invocation requests. This upper bound 630 calculation must be performed by the service module because it is 631 specific to a particular service. 633 The calculated upper bound need not be a least upper bound, nor do 634 the various network elements along the path need to all use the same 635 choice of upper bound. Any selection of invocation parameters Ru is 636 compliant as long as it substitutable for each of the parameters 637 R1...Rn from which it is calculated. Intuitively, one set of 638 parameters is substitutable for another if the resulting quality of 639 service is at least as desirable to all applications. A precise 640 definition of this "substitutable for" function; the ordering 641 relation, MUST be specified in the service definition. (It may be 642 specified as the empty set, in which case merging of dissimilar 643 requests will not be allowed). A merging computation (upper bound 644 calculation) MAY be given in the document as well. 646 Typically the ordering relation will be described separately for the 647 service's TSpec and RSpec. An invocation request is ordered with 648 respect to another if and only if both its TSpec and its RSpec are 649 similarly ordered with respect to each other. 651 For TSpecs, the basic ordering relation is well defined. TSpec A is 652 substitutable for TSpec B if and only any flow that is compliant with 653 TSpec B is also compliant with TSpec A. The service specification 654 must explain how to compare two TSpecs to determine whether this is 655 true. 657 For RSpecs, the ordering relation is dependent on the service. RSpec 658 A is substitutable for RSpec B if the quality of service invoked by 659 RSpec A is at least as good as the quality of service invoked by 660 RSpec B. Since there is no precise mathematical description of 661 "goodness" of quality of service, these ordering relations must be 662 spelled out explicitly in the service description. 664 This portion of the service description may also note any ordering 665 relationships with other services which are strictly ordered with 666 respect to the service being defined. Two services A and B are 667 strictly ordered if it is always possible to substitute service B for 668 the service A given a set of invocation parameters for service A. 669 This ordering information may be used to allow network elements which 670 provide service B to respond to requests for service A, even if the 671 element does not provide service A directly. If the service 672 specification describes such an inter-service ordering, it SHOULD 673 also include a description of the invocation parameter mapping 674 function for that ordering. 676 Substitution of of one service for another in cases where they are 677 not strictly ordered is currently not supported. A future version of 678 this document may augment the service specification format to support 679 this capability. 681 o End-to-end Behavior 683 This is a description of the behavior that results if all network 684 elements along the path offer the same service, invoked with a 685 defined set of parameters. This section should be as detailed as 686 possible. There are certain services where the end-to-end behavior 687 is a highly nontrivial result of the concatenation of per-hop 688 services; one purpose of this section is that such nontrivial results 689 are not left unrevealed to the reader of this document. 691 In private networks it will generally be the case that the required 692 end-to-end behavior is obtained by concatenation of network elements 693 utilizing the same service and making significant use of 694 characterizations. 696 In the global Internet, this will not always be true. End-to-end 697 behaviors will frequently be obtained through a concatenation of 698 network elements supporting different services, including in some 699 cases elements which exercise no QoS control at all. Mechanisms to 700 characterize end-to-end behavior in this circumstance are not fully 701 established at this time. Future versions of this document may impose 702 additional requirements on service specifications to facilitate 703 inter-service composition. 705 NOTE: This service specification template does not allow a service 706 definition to -require- that a setup or invocation mechanism used 707 with the service perform any function other than transport of 708 invocation parameters to the network elements and signalling of 709 errors generated by the network elements to the end nodes. A 710 notable example of this is that service specification documents 711 may not require or assume that characterizations defined in the 712 specification are actually computed or presented to the end nodes. 714 That point notwithstanding, the practical usefulness of a specific 715 service may be highly dependent on the presence of some additional 716 behavior in the networked system, such as the computation and 717 presentation of characterizations to end-nodes or the reliable 718 assurance that every network element in the path from sender to 719 receivers supports the given service. Service specification 720 authors are strongly encouraged to clearly explain the situation 721 of their service in this regard. Statements such as: 723 "The characterizations defined by this service serve as useful 724 hints to the application. However, the service is specifically 725 intended to be useful even if characterizations are not 726 available. 728 or 730 The usefulness of this service depends strongly on the delivery 731 of both characterizations and the knowledge that all network 732 elements on the path support the service. Requests for this 733 service when characterizations are not available are likely to 734 lead to incorrect or misleading results. 736 are appropriate. It may also be useful to consider this point in 737 the "Examples of Use" section described below. ] 739 NOTE: The possibility of adopting alternative wording for this 740 document which allows a service to require that the invocation 741 protocol support specific additional functionality or return an 742 error is a topic open to discussion. 744 o Guidelines for Implementors 746 Many services may be defined in a manner which allows the range of 747 behavior of a compliant network element to be rather broad. This 748 section should provide some guidance as to what range of behaviors 749 the author of the service specification expects the community to 750 desire in their implementations. Because these guidelines depend on 751 such imprecise and undefinable notions at "typical loads", these 752 guidelines cannot be incorporated as part of a strict compliance 753 test. Instead, they are for informational purposes only. 755 o Evaluation Criteria 757 Specific functional behaviors required of an implementation for 758 conformance to a service specification is detailed in the previous 759 sections. However, the service specifications are intended to allow 760 a wide range of implementations, and these implementations will 761 differ in performance. This section describes tests that can be used 762 to evaluate a network element's implementation of a given service. 764 Implementors of service modules face a number of tradeoffs, and it is 765 unlikely that a single implementation would be considered "best" 766 under all circumstances. For instance, given the same service 767 specification, an implementation appropriate for a low-speed link 768 might target extremely high link utilization, while a different 769 implementation might attempt to reduce non-loaded packet forwarding 770 delay to the minimum at the expense of somewhat lower utilization of 771 the link. The intention of the tests specified in this section should 772 be to probe the tradeoffs made by the implementation designer, and to 773 provide metrics useful to guide the customer's choice of an 774 appropriate implementation for her needs. 776 The tests specified in this section should be designed to operate on 777 a single network element in isolation. This enables their use in a 778 comparative rating system for QoS-aware network elements. In 779 production networks, users will be more concerned with the end-to-end 780 behavior obtained, which will depend not just on the particular 781 network elements selected, but also on other factors such as the 782 setup protocol and the bandwidth of the links. Some user-relevant 783 performance factors are the rate of admission control rejections, the 784 range of services offered, and the packet delay and drop rates in the 785 various service classes. The form of any standardized end-to-end 786 metrics and measurement tools for integrated service internetworks is 787 not specified by this document or by service specification document 788 which follow the format given here. 790 o Examples of Implementation 792 This section describes example instantiations of the service. Often 793 these will just be references to the literature, or brief sketches of 794 how the service could be implemented. The purposes of the section 795 are to to provide a more concrete sense of the service being 796 specified and to provide pointers and hints to aid the implementor. 797 However, the descriptions in this section are specifically not 798 intended to exclude other implementation strategies. 800 o Examples of Use 802 In order to provide more a more concrete sense of how this service 803 might be used, this section describes some example uses of the 804 service, for informational purposes only. The examples here are not 805 meant to be exhaustive, and do not exclude in any way other uses of 806 the service. 808 Security Considerations 810 Security considerations are not discussed in this memo. 812 Authors' Address: 814 Scott Shenker 815 Xerox PARC 816 3333 Coyote Hill Road 817 Palo Alto, CA 94304-1314 818 shenker@parc.xerox.com 819 415-812-4840 820 415-812-4471 (FAX) 822 John Wroclawski 823 MIT Laboratory for Computer Science 824 545 Technology Sq. 825 Cambridge, MA 02139 826 jtw@lcs.mit.edu 827 617-253-7885 828 617-253-2673 (FAX)