idnits 2.17.1 draft-ietf-intserv-svc-template-02.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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 315: '...rvice definition MUST specify the form...' RFC 2119 keyword, line 336: '...rvice definition SHOULD additionally s...' RFC 2119 keyword, line 425: '... document MUST contain the sections ...' RFC 2119 keyword, line 426: '...d. Each document SHOULD contain each o...' RFC 2119 keyword, line 509: '... 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) -- Missing reference section? '1' on line 264 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 1 warning (==), 3 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-02.txt Xerox PARC/MIT LCS 4 November, 1995 5 Expires: 5/96 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 framework for specifying services provided 35 by network elements, and available to applications, in an 36 internetwork which offers multiple qualities of service. The 37 document first provides some necessary context -- including 38 relevant definitions and suggested data formats -- and then 39 specifies a "template" which service specification documents 40 should follow. The specification template includes per-element 41 requirements such as the service's packet handling behavior, 42 parameters required and made available by the service, traffic 43 specification and policing requirements, and traffic ordering 44 relationships. It also includes evaluation criteria for elements 45 providing the service, and examples of how the service might be 46 implemented (by network elements) and used (by applications). 48 Introduction 50 This document defines the framework used to specify the functionality 51 of internetwork system components which support the the ability to 52 provide multiple, dynamically selectable qualities of service to 53 applications using an internetwork. The behavior of individual 54 routers and subnetworks is captured as a set of "services", some or 55 all of which may be offered by each element. The concatenation of 56 these services along the end-to-end data paths used by an application 57 provides overall quality of service control. 59 The definition of a service states what is required of a router (or, 60 more generally, any network element; a router, switch, subnet, etc.) 61 which supports a particular service. The service definition also 62 specifies parameters used to invoke the service, the relationship 63 between those parameters and the service delivered, and the end-to- 64 end behavior obtained by concatenating several instances of the 65 service. 67 Each service definition also specifies the interface between that 68 service and the environment. This includes the parameters needed to 69 invoke the service, informational parameters which the service must 70 make available for use by setup, routing, and management mechanisms, 71 and information which should be carried between end-nodes and network 72 elements by those mechanisms in order to achieve the desired end-to- 73 end behavior. However, a service definition does not describe the 74 specific protocols or mechanisms used to establish state in the 75 network elements for flows that use the described service. 77 Services defined following the guidelines of this document are 78 intended for use both within the global Internet and private IP 79 networks. In certain cases a concatenation of network element 80 services may be used to provide a range of end-to-end behaviors, some 81 more suited to a decentralized internet and some more appropriate for 82 a tightly managed private network. This document points out places 83 where such distinction may be appropriate. 85 This document is comprised of three parts. The first defines some 86 terms used both in this document and in the various service 87 specification documents. The second discusses data formats and 88 representations. The third portion of the document describes the 89 various components of the service specification template. 91 Definitions 93 The following terms are used throughout this document. Service 94 specification documents should employ the same terms to express these 95 concepts. 97 o Quality of Service (QoS) 99 In the context of this document, quality of service refers to the 100 nature of the packet delivery service provided, as described by 101 parameters such as achieved bandwidth, packet delay, and packet loss 102 rates. Traditionally, the Internet has offered a single quality of 103 service, best-effort delivery, with available bandwidth and delay 104 characteristics dependent on instantaneous load. Control over the 105 quality of service seen by applications is exercised by adequate 106 provisioning of the network infrastructure. In contrast, a network 107 with dynamically controllable quality of service allows individual 108 application sessions to request network packet delivery 109 characteristics according to their perceived needs, and may provide 110 different qualities of service to different applications. It should 111 be understood that there is a range of useful possibilities between 112 the two endpoints of providing no dynamic QoS control at all and 113 providing extremely precise and accurate control of QoS parameters. 115 o Network Element 117 A "Network Element" (or the equivalent shorter form "Element"), is 118 any component of an internetwork which directly handles data packets 119 and thus is potentially capable of exercising QoS control over data 120 flowing through it. Network elements include routers, subnetworks, 121 and end-node operating systems. A QoS-capable network element is one 122 which offers one or more of the services defined according to the 123 rules given in this document. Note that this definition, by itself, 124 preclude QoS-capable network elements that meet performance goals 125 purely through adequate provisioning rather than active admission and 126 traffic control mechanisms. A "QoS-aware" network element is one 127 which supports the interfaces (described below) required by the 128 service definitions. Thus, a QoS-aware network element need not 129 actually offer any of the services defined according to the format of 130 this document; it merely needs to know how to deny service requests. 132 o Flow 134 For the purposes of this document a flow is a set of packets 135 traversing a network element all of which are covered by the same 136 request for control of quality of service. At a given network element 137 a flow may consist of the packets from a single application session, 138 or it may be an aggregation comprising the combined data traffic from 139 a number of application sessions. 141 NOTE: this definition of a flow is different from that used in 142 IPv6, where a flow is defined as those packets with the same 143 source address and FlowID. 145 Mechanisms used to associate a request for quality of service control 146 with the packets covered by that request are beyond the scope of this 147 document. 149 o Service 151 The word "service" describes a named, coordinated set of QoS control 152 capabilities provided by a single network element. The definition of 153 a service includes a specification of the functions to be performed 154 by the network element, the information required by the element to 155 perform these functions, and the information made available by the 156 element to other elements of the system. A service is conceptually 157 implemented within the "service module" contained within the network 158 element. 160 NOTE: The above defines a precise meaning for the word "service". 161 Service is a word which has a variety of meanings throughout the 162 networking community; the definition of "service" given here 163 refers specifically to the actions and responses of a single 164 network element such as a router or subnet. This contrasts with 165 the more end-to-end oriented definition of the same word seen in 166 some other networking contexts. 168 o Behavior 170 A "behavior" is the QoS-related end-to-end performance seen by an 171 application session. This behavior is the end result of composing the 172 services offered by each network element along the path of the 173 application's data flow. 175 When each network element along a data flow path offers the same 176 service, it is frequently possible to explain the resulting end-to- 177 end behavior in a straightforward fashion. The behavior of a data 178 flow path comprised of elements using different services is more 179 complicated, and may in fact be undefined. A future version of this 180 document may impose additional requirements on the service 181 specification relating to multi-service concatenation. 183 o Characterization 185 A characterization is a computed approximation of the actual end-to- 186 end behavior which would be seen by a flow requesting specific QoS 187 services from the network. By providing additional information to 188 the end-nodes before a flow is established, characterizations assist 189 the end-nodes in choosing the services to be requested from the 190 network. 192 o Characterization Parameters 194 Characterizations are computed from a set of characterization 195 parameters provided by each network element on the flow's path, and a 196 composition function which computes the end-to-end characterization 197 from those parameters. The composition function may in practice be 198 executed in a distributed fashion by the setup or routing protocol, 199 or the characterization parameters may be gathered to a single point 200 and the characterization computed at that point. 202 Several characterizations may be computed for a single candidate data 203 flow. Conversely, a service may provide no characterizations, and 204 under some conditions no characterizations may be available to the 205 end-nodes requesting QoS services. 207 o Composition Function 209 A composition function accepts characterization parameters as input 210 and computes a characterization, as described above. 212 o Traffic Specification (TSpec) 214 A Traffic Specification, or TSpec, is a description of the traffic 215 pattern for which service is being requested. In general, the TSpec 216 forms one side of a "contract" between the data flow and the service. 217 Once a service request is accepted, the service module has agreed to 218 provide a specific QoS as long as the flow's data traffic continues 219 to be accurately described by the TSpec. 221 As examples, this specification might take the form of a token bucket 222 filter (defined below) or an upper bound on the peak rate. Note that 223 the traffic specification specifies the flow's *allowed* traffic 224 pattern, not the flows *actual* traffic pattern. The behavior of a 225 service when a flow's actual traffic does not conform to the traffic 226 specification must be defined by the service (see "Policing" below). 228 o Service Request Specification (RSpec) 230 A Service Request Specification, or RSpec, is a specification of the 231 quality of service a flow wishes to request from a network element. 232 The contents of a service request specification is highly specific to 233 a particular service. As examples, these specifications might contain 234 information about bandwidth allocated to the flow, maximum delays, or 235 packet loss rates. 237 o Setup Protocol 239 A setup protocol is used to carry QoS-related information from the 240 end-nodes requesting QoS control to network elements which must 241 exercise that control, and to install and maintain to required QoS 242 control state in those network elements. A setup protocol may also 243 be used to collect QoS-related information from interior network 244 elements along an application's data flow path for ultimate delivery 245 to end nodes. Examples of protocols which perform setup functions are 246 RSVP (RFC to be determined), ST-II (RFC 1819), and Q.2931. 248 Note that other mechanisms, such as network management protocols, may 249 also perform this function. The phrase "setup protocol" 250 conventionally refers to a protocol with this function as its primary 251 purpose. 253 o Token Bucket 255 A Token Bucket is a particular form of traffic specification 256 consisting of a "token rate" r and a "bucket size" b. Essentially, 257 the r parameter specifies the continually sustainable data rate, 258 while the b parameter specifies the extent to which the data rate can 259 exceed the sustainable level for short periods of time. More 260 specifically, the traffic must obey the rule that over all time 261 periods, the amount of data sent cannot exceed rT+b, where T is the 262 length of the time period. 264 Token buckets are further discussed in [1]. 266 o Token Bucket Filter 268 A Token Bucket Filter is a filtering or policing function which 269 differentiates those packets in a traffic flow which conform to a 270 particular token bucket specification from those packets which do 271 not. The specific treatment accorded nonconforming packets is not 272 specified in this definition; common actions are relegating the 273 packet to best effort service, discarding the packet, or marking the 274 packet in some fashion. 276 o Admission Control 278 Admission control is the process of deciding whether a newly arriving 279 request for service from a network element can be granted. This 280 action must be performed by any service which wishes to offer 281 absolute quantitative bounds on overall performance. It is not 282 necessary for services which provide only relative statements about 283 performance, such as the Internet's current best-effort service. The 284 precise criteria for making the admission control decision are a 285 specific to each particular service. 287 o Policing 289 Policing is the set of actions triggered when a flow's actual data 290 traffic characteristics exceed the expected values given in the 291 flow's traffic specification. Services which require policing 292 functions to operate correctly must specify both the action to be 293 taken when such discrepancies occur and the locations in the network 294 where discrepancies are to be detected. Examples of such actions 295 might include relegating the packet to best effort service, dropping 296 packets, reshaping the traffic, or marking non-conforming traffic in 297 some fashion. 299 o Interfaces 301 The service module conceptually interacts with other portions of the 302 network element through a number of interfaces. The service 303 specification document should clearly define the specific data, 304 including formats, which moves across each conceptual interface, and 305 ensure that the mapping between conceptual interfaces and the 306 specific mechanisms of the service being defined are clear. 308 NOTE: The interfaces required by the service module are currently 309 documented only by this note. 311 Data Format and Representation 313 A service module will import and export a variety of data according 314 to the specific requirements of the services the network element 315 supports. Each service definition MUST specify the format of each 316 such data item in an abstract manner. The information specified must 317 be sufficient for the designer of a setup protocol to correctly 318 select an appropriate concrete (packet) format for variables 319 containing this data. At minimum, the following information must be 320 given: 322 - Type: whether the quantity is an enumeration, a numerical value, 323 etc. 325 - Range: for numerical quantities, the minimum and maximum values 326 the quantity must be able to represent. For enumerated quantities, 327 an estimate of the maximum number of items which may need be 328 enumerated in the future, even if many of the values are currently 329 unused. 331 - Precision: the precision with which a numerical quantity must be 332 represented, and whether that precision is absolute (calling for an 333 integer quantity) or a percentage of the value (allowing for a 334 floating point quantity). 336 The service definition SHOULD additionally specify a preferred 337 concrete format for each data field, in the usual packet-layout 338 format used in current Internet Standard documents. If the service 339 definition contains these concrete definitions, they should be 340 sufficiently complete and detailed to allow the service definition to 341 be incorporated by reference into the specifications for setup 342 protocols and other users of the specified data. 344 NOTE: The wording above is intended to encourage the use of common 345 data formats by all protocols carrying data related to a specific 346 service, while not mandating this common format or infringing on 347 the freedom of protocol specification designers to define data 348 representations using alternative mechanisms such as ASN.1 or XDR. 350 Service and Data Element Naming 352 End-nodes, network elements, setup protocols, and management entities 353 within an integrated services internetwork frequently need to 354 exchange information about services, service invocation parameters, 355 characterization parameters, and the intermediate variables and end 356 results of composition functions. To support this requirement, a 357 single uniform namespace is established for services and their 358 parameters. 360 The namespace is a two-level hierarchy: 362 .. 364 Each of these elements is a integer numerical quantity. 366 is an integer in the range 1 to 254. The number space 367 is broken into two regions. The range from 1 to 127 is managed by the 368 IANA. Procedures for allocating service numbers in this region will 369 be established by the IETF INT-SERV WG and the IANA. Services 370 designed for public use should obtain a number from this space. The 371 minimum requirement for doing so is a published RFC following the 372 format described in this note. 374 Numbers in the region above 127 are reserved for experimental or 375 private services. Service designers may allocate numbers from this 376 space at random for local experimental use. A policy for global but 377 temporary allocation of these numbers may be established in the 378 future if necessary. 380 The value 0 is left unused to allow the direct mapping of parameter 381 names to MIB object names, as described below. 383 The value 255 is reserved to facilitate future expansion of the 384 service number space, if required. 386 is a number in the range 1 to 254, allocated on a 387 per-service basis. Within this range, the values 1 to 16 are 388 reserved for assignment as "well-known" numbers, representing 389 parameters common to most or all services. Numbers for parameters 390 specific to a service are assigned from the range 17-254 by the 391 author of the service specification document. 393 The value 0 is left unused to allow the direct mapping of parameter 394 names to MIB object names, as described below. 396 The value 255 is reserved to facilitate future expansion of the 397 parameter number space, if required. 399 In addition to their uses within the integrated services framework, 400 these . pairs should be used as 401 last two levels of the MIB name when the corresponding values are 402 made available to network management protocols. 404 Certain values of the namespace are allocated to well-known objects. 406 The well-known service Number 1 is reserved for the "general" 407 parameters described above. Parameter numbers within this space are 408 allocated by IANA. 410 The well-known parameter number 1 is reserved for the TSpec parameter 411 in all services, including service 1. The well-known parameter number 412 2 is reserved for the RSpec parameter in all services, including 413 service 1. No other well-known parameter numbers are assigned at this 414 time. 416 NOTE: Number assignments in the current service specification 417 documents do not match this description due to parallel 418 development. The wording here supercedes the assignments in the 419 current service specification documents. 421 Specification Document Format 423 The following portion of this document describes the layout and 424 contents of a service specification. Each service specification 425 document MUST contain the sections marked [required] below, in the 426 order listed. Each document SHOULD contain each of the remaining 427 sections in the list below, unless there is a compelling argument 428 that the presence of the section is not beneficial. Additional 429 material, including references, should be included at the end of the 430 document. 432 Some of these sections are normative, in that they describe specific 433 requirements to which conformant implementations must adhere. Other 434 sections are informational in nature, in that they describe necessary 435 context and technical considerations important to the implementor of 436 a service. The sections, and their nature (required or optional, and 437 informational or normative) are listed below: 439 o Components 441 The body of a service specification document incorporates the 442 following sections: 444 - End-to-End Behavior [required] [informational] 446 - Motivation [required] [informational] 448 - Network Element Data Handling Requirements [required] [normative] 450 - Invocation Information [required] [normative] 452 - Exported Information [required] [normative] 454 - Policing [required] [normative] 456 - Ordering and Merging [required] [normative] 458 - Guidelines for Implementors [optional] [informational] 460 - Evaluation Criteria [required] [informational] 462 - Examples of Implementation [optional] [informational] 464 - Examples of Use [optional] [informational] 466 o End-to-end Behavior 468 This is a description of the behavior that results if all network 469 elements along the path offer the same service, invoked with a 470 defined set of parameters. 472 In private networks it will generally be the case that the required 473 end-to-end behavior is obtained by concatenation of network elements 474 utilizing the same service and making significant use of 475 characterizations. 477 In the global Internet, this will not always be true. End-to-end 478 behaviors will frequently be obtained through a concatenation of 479 network elements supporting different services, including in some 480 cases elements which exercise no QoS control at all. Mechanisms to 481 characterize end-to-end behavior in this circumstance are not fully 482 established at this time. Future versions of this document may impose 483 additional requirements on service specifications to facilitate 484 inter-service composition. 486 This section is for informational purposes only. 488 o Motivation 490 This section discusses why this service is being defined. It 491 describes what kinds of applications might make use of this service, 492 and why this service might be more appropriate for those applications 493 than other possible choices. This section is for informational 494 purposes only. 496 o Network Element Data Handling Requirements 498 This section contains a description of the QoS properties seen by 499 data packets processed by a network element using this service. The 500 description must clearly explain what variables are controlled, the 501 degree of control exercised, and what aspects of the service's 502 handling model are fixed or assumed. Examples of degree of control 503 information include "this property must be mathematically assured" 504 and "this property should be met under most conditions". An example 505 of a stated assumption is "this service is assumed to have extremely 506 low packet loss; delay targets must be met using admission control 507 rather than by discarding packets when overloaded". 509 Requirements on packet handling SHOULD, when at all possible, be 510 expressed as performance requirements rather than by specifying a a 511 particular packet scheduling algorithm. The performance requirements 512 might, for example, be a specification of the maximal packet delays 513 or the minimal bandwidth share given to a flow. 515 This section also specifies actions which the packet handling path is 516 required to take to actively provide feedback to end-nodes about 517 conditions at the network element. Such actions might include 518 explicitly generated congestion feedback, indicated either as bits 519 set in the header of data packets or separate control messages sent. 521 When writing this section of the service specification document, the 522 authors' goal should be to specify the required behavior as precisely 523 as necessary while still leaving adequate room for the implementation 524 and architectural tradeoffs appropriate to different circumstances 525 and classes of network elements. Successfully achieving this balance 526 may require some care. 528 o Invocation Information 530 This section describes the set of parameters required by a service 531 module to invoke the service, and a description of how the parameter 532 values are used by the service module. For example, a hypothetical 533 "bounded delay" service might be described as accepting a request 534 indicating a delay target for the network element and the set of 535 packets subject to that delay target, and processing packets in the 536 given set with a delay of the target value or less. 538 Necessary invocation information for most services can be broken into 539 two parts, the Traffic Specification (TSpec) and the Service Request 540 Specification (RSpec). The TSpec gives characteristics of the data 541 traffic to be handled, while the Rspec specifies the properties 542 desired from the service. For example, a service offering a 543 mathematical bound on delay might accept a TSpec giving the traffic 544 flow's bandwidth and burstiness specified as a Token Bucket, and an 545 RSpec giving the maximum tolerable queueing delay. 547 A service accepting an invocation request may be thought of as 548 entering into a "contract" to provide the service described by the 549 RSpec as long as the flow's traffic continues to be described by the 550 TSpec. If the flow's traffic pattern falls outside the bounds of the 551 TSpec, the QoS provided to the flow may change. The precise nature of 552 this change is also described by the service specification (see 553 "Policing" below). 555 The RSPec and TSpec components of the invocation information should 556 be specified separately and independently, as they will often be 557 generated by different elements of the internetwork 559 All quantitative information specifications in this section should 560 follow the guidelines given in the Data Formats section of this 561 document, above. 563 o Exported Information and Characterization Parameters 565 This section describes information which must be collected and 566 exported by the service module. Exported information is available to 567 other modules of the network element, and by extension to setup 568 protocols, routing protocols, network management tools, and the like. 570 Information exported by service modules may be used in several ways. 571 For example, quantities such as the amount of link bandwidth 572 dedicated to the service and the set of data flows currently 573 receiving the service are appropriate pieces of information to make 574 available as network management variables. 576 A service definition may identify a particular subset of the 577 information exported by a service module as characterization 578 parameters. These characterization parameters may be used to compute 579 or estimate the end-to-end behavior of a data flow traversing a 580 concatenation of network service elements. They may also be used to 581 characterize portions of the path for use by network elements (e.g., 582 in computing the buffer necessary, an element may need to know 583 something about the service characteristics of the upstream portion 584 of the path). A service which defines characterization parameters 585 also specifies the characterizations they are used to generate and 586 the composition functions used to generate the characterizations. 588 NOTE: Characterization parameters are identified as such by virtue 589 of being the inputs to a service's defined composition functions. 590 Because characterization parameters are part of a service's 591 overall exported data set, they are also available to other 592 functions, such as network management. The discussion below 593 relates solely to their use as characterization parameters, and is 594 not intended to limit other uses. 596 Characterization parameters may be relatively static quantities, such 597 as the bandwidth available on a specific link, or relatively dynamic 598 quantities, such as a running estimation of current packet delay. 600 Support for a service's defined characterization parameters is 601 mandatory. Any network element offering this service must be able to 602 measure, compute, or, if allowed by the specification, estimate the 603 service's characterization parameters. Service designers are 604 encouraged to understand the implications of specifying 605 characterization parameters for a service, particularly with respect 606 to not unduly restricting the choice of hardware and software 607 architectures used to implement the network element. 609 Characterization parameters are used by composing the values exported 610 by each network element along a data flow's path according to a 611 composition rule. For each parameter or set of parameters used to 612 develop a characterization, the service specification must specify 613 the composition rule to be used. These composition rules should 614 result in characterizations that are independent of the order in 615 which the element are composed; commutativity and associativity are 616 sufficient but not necessary conditions for this. 618 Characterization parameters are available through a general 619 interface, and are provided in response to a request from some other 620 module, such as a setup protocol or the routing protocol. The 621 question of exactly how, or if, a specific protocol (e.g., RSVP) uses 622 characterization parameters to generate characterizations is 623 described in the specification of that specific protocol. 625 The correct use of characterization parameters supplied by service 626 modules is a function of the setup, routing, or management protocol 627 controlling the module. There is no absolute guarantee that 628 characterizations will be available to end-nodes desiring to use a 629 QoS control service. Service designers targeting services for the 630 global Internet may wish to ensure that a service is useful even in 631 the absence of characterizations, and to exhibit such uses in the 632 "Examples" sections of the service description document. 634 Conversely, the availability of characterizations may be mandatory in 635 certain circumstances, particularly for private IP networks providing 636 tightly controlled qualities of service for specific applications. 637 Service designers targeting this environment should particularly 638 ensure that the service provides adequate characterization parameters 639 and composition functions to meet the needs of target audiences. It 640 may be appropriate to specify the same basic service with additional 641 characterizations for meeting specific requirements beyond those of 642 the global Internet. 644 Some useful "general" characterization parameters and corresponding 645 composition rules are not associated with any specific service. 646 These include the speed-of-light latency of communication links and 647 available link bandwidth. These general characterization parameters 648 are defined in (RFC to be announced). 650 Although every conformant implementation of a service is required to 651 provide that service's characterization parameters, it is still 652 possible that the desired characterization parameters will not be 653 available for composition at all network elements in a path. This 654 situation may arise when different network element services are used 655 at different points in the end-to-end path, as may be required in a 656 heterogeneous internetworking environment. For this reason, 657 characterization parameters and composition function results 658 conceptually include a "validity flag". A network element which is 659 unable to provide the characterization parameter must set this flag, 660 and otherwise leave parameter or composed value unchanged. Once set, 661 the flag is preserved by the composition function, and serves as an 662 indicator of the validity of the data when the final composed result 663 is delivered to its destination. 665 Protocols which transport characterization parameters and composition 666 data must define and support a concrete representation for this 667 validity flag, as well as for the characterization parameters 668 themselves. 670 NOTE: This service specification template does not allow a service 671 definition to *require* that a setup or invocation mechanism used 672 with the service perform any function other than transport of 673 invocation parameters to the network elements and signalling of 674 errors generated by the network elements to the end nodes. A notable 675 example of this is that service specification documents may not 676 require or assume that characterizations defined in the specification 677 are actually computed or presented to the end nodes. 679 Further, the current integrated services architecture does not 680 provide a way for the invoking protocol to deliver any information to 681 the service module about the availability of capabilities such as the 682 support for characterizations. 684 That point notwithstanding, the practical usefulness of a specific 685 service may be highly dependent on the presence of some additional 686 behavior in the networked system, such as the computation and 687 presentation of characterizations to end-nodes or the reliable 688 assurance that every network element in the path from sender to 689 receivers supports the given service. Service specification authors 690 are strongly encouraged to clearly explain the situation of their 691 service in this regard. Statements such as: 693 The characterizations defined by this service serve as useful 694 hints to the application. However, the service is specifically 695 intended to be useful even if characterizations are not available. 697 or 699 The usefulness of this service depends strongly on the delivery of 700 both characterizations and the knowledge that all network elements 701 on the path support the service. Requests for this service when 702 characterizations are not available are likely to lead to 703 incorrect or misleading results. 705 are appropriate. It may also be useful to consider this point in the 706 "Examples of Use" section described below. 708 NOTE: The possibility of modifying the overall architecture to 709 provide information about the invoking protocol in a service request, 710 and to allow a service to require that the invocation protocol 711 support specific additional functionality, is an area of active 712 study. 714 o Policing 716 This portion of the service description describes the nature of 717 policing used to enforce adherence to a flow's Traffic Specification. 718 The specification document must specify the following points 720 - Expected policing action. This is the action taken when packets 721 not conforming to the TSpec are detected. Example actions include 722 relegating nonconforming packets to best effort, immediately 723 dropping nonconforming packets, delaying these packets until they 724 once again "fit" into the TSpec, or "marking" nonconforming packets 725 in some way. 727 - Legality of alternative policing actions. The section must 728 specify whether actions not specifically mentioned in 729 specification's description of policing behavior are legal. For 730 example, a service description which specifies that nonconforming 731 packets are to be dropped should state whether an alternate action, 732 such as delaying these packets, is acceptable. 734 - Location of policing actions in the internetwork. The description 735 of policing must specify where that policing is done. Possibilities 736 include "at the edges of the network only", "at every hop", 737 "heterogeneous branch points" (points where the branches of a 738 multicast tree converge and have different TSpecs reserved 739 downstream), and "source merge points" (points where multiple data 740 streams covered by a single resource reservation converge). The 741 specification should clearly state requirements about topology 742 information (for example "this is an edge node" or "this is a 743 source merge point") which must be available from the setup 744 protocol or another source. 746 In this section the specification should also specify the legality 747 of policing at additional points in the network, beyond those 748 listed above. This is important due to technical effects such as 749 are described in the next paragraph. 751 - Applicable additional technical considerations. If policing of 752 data flows is required or legal at points other than the flow's 753 first entry into the network, the service definition should 754 describe any additional technical considerations which affect the 755 design of such policing. For example, many potential services will 756 allow a data flow to become more bursty as it progresses through 757 the network. If such a service allows policing at points other than 758 the network edge, the traffic specification describing the flow 759 will have to be modified from that given by the application to the 760 network to account for this growing burstiness. Otherwise, it is 761 likely that the flow will be overpoliced, with packets being 762 penalized unnecessarily. 764 o Ordering and Merging 766 Ordering and merging come into play when a network element receives 767 several invocation requests covering the same data flow. As examples, 768 this could occur if several receivers of a multicast data flow 769 requested QoS services for that flow using the RSVP setup protocol, 770 or if a flow was subject to both a statically installed permanent 771 invocation request and a dynamic request from a resource setup 772 protocol. 774 In this situation the service module must be able to answer questions 775 about the ordering between different invocation requests, and must be 776 able to generate a single new invocation request which meets the 777 requirements of all the original requesters. This new request is a 778 "merged" request. It may be equal to one of the original requests, or 779 it may be a newly computed request. Operationally, this is achieved 780 by having the invoking protocol ask the service module, given a set 781 of invocation requests I1...In, to compute an merged request which 782 results in service to the merged flow at least equivalent to that 783 which any of the original requests would obtain for its corresponding 784 unmerged flow. Hence, the merged invocation request represents an 785 "upper bound" on the set of original invocation requests. This upper 786 bound calculation must be performed by the service module because it 787 is specific to a particular service. 789 The calculated upper bound need not be a least upper bound, nor do 790 the various network elements along the path need to all use the same 791 choice of upper bound. Any selection of invocation parameters Iu is 792 compliant as long as it substitutable for each of the parameters 793 I1...In from which it is calculated. Intuitively, one set of 794 parameters is substitutable for another if the resulting quality of 795 service is at least as desirable to all applications. A precise 796 definition of this "substitutable for" function; the ordering 797 relation, MUST be specified in the service definition. (It may be 798 specified as the empty set, in which case merging of dissimilar 799 requests will not be allowed). A merging computation (upper bound 800 calculation) MAY be given in the document as well. 802 Typically the ordering relation will be described separately for the 803 service's TSpec and RSpec. An invocation request is ordered with 804 respect to another if and only if both its TSpec and its RSpec are 805 similarly ordered with respect to each other. 807 For TSpecs, the basic ordering relation is well defined. TSpec A is 808 substitutable for TSpec B if and only any flow that is compliant with 809 TSpec B is also compliant with TSpec A. The service specification 810 must explain how to compare two TSpecs to determine whether this is 811 true. 813 For RSpecs, the ordering relation is dependent on the service. RSpec 814 A is substitutable for RSpec B if the quality of service invoked by 815 RSpec A is at least as good as the quality of service invoked by 816 RSpec B. Since there is no precise mathematical description of 817 "goodness" of quality of service, these ordering relations must be 818 spelled out explicitly in the service description. 820 This portion of the service description may also note any ordering 821 relationships with other services which are strictly ordered with 822 respect to the service being defined. Two services A and B are 823 strictly ordered if it is always possible to substitute service B for 824 the service A given a set of invocation parameters for service A. 825 This ordering information may be used to allow network elements which 826 provide service B to respond to requests for service A, even if the 827 element does not provide service A directly. If the service 828 specification describes such an inter-service ordering, it MUST also 829 include a description of the invocation parameter mapping function 830 for that ordering. 832 Substitution of of one service for another in cases where they are 833 not strictly ordered is currently not supported. A future version of 834 this document may augment the service specification format to support 835 this capability. 837 o Guidelines for Implementors 839 Many services may be defined in a manner which allows the range of 840 behavior of a compliant network element to be rather broad. This 841 section should provide some guidance as to what range of behaviors 842 the author of the service specification expects the community to 843 desire in their implementations. Because these guidelines depend on 844 such imprecise and undefinable notions at "typical loads", these 845 guidelines cannot be incorporated as part of a strict compliance 846 test. Instead, they are for informational purposes only. 848 o Evaluation Criteria 850 Specific functional behaviors required of an implementation for 851 conformance to a service specification is detailed in the previous 852 sections. However, the service specifications are intended to allow 853 a wide range of implementations, and these implementations will 854 differ in performance. This section describes tests that can be used 855 to evaluate a network element's implementation of a given service. 857 Implementors of service modules face a number of tradeoffs, and it is 858 unlikely that a single implementation would be considered "best" 859 under all circumstances. For instance, given the same service 860 specification, an implementation appropriate for a low-speed link 861 might target extremely high link utilization, while a different 862 implementation might attempt to reduce non-loaded packet forwarding 863 delay to the minimum at the expense of somewhat lower utilization of 864 the link. The intention of the tests specified in this section should 865 be to probe the tradeoffs made by the implementation designer, and to 866 provide metrics useful to guide the customer's choice of an 867 appropriate implementation for her needs. 869 The tests specified in this section should be designed to operate on 870 a single network element in isolation. This enables their use in a 871 comparative rating system for QoS-aware network elements. In 872 production networks, users will be more concerned with the end-to-end 873 behavior obtained, which will depend not just on the particular 874 network elements selected, but also on other factors such as the 875 setup protocol and the bandwidth of the links. Some user-relevant 876 performance factors are the rate of admission control rejections, the 877 range of services offered, and the packet delay and drop rates in the 878 various service classes. The form of any standardized end-to-end 879 metrics and measurement tools for integrated service internetworks is 880 not specified by this document or by service specification document 881 which follow the format given here. 883 This section is for informational purposes only. 885 o Examples of Implementation 887 This section describes example instantiations of the service. Often 888 these will just be references to the literature, or brief sketches of 889 how the service could be implemented. The purposes of the section 890 are to to provide a more concrete sense of the service being 891 specified and to provide pointers and hints to aid the implementor. 892 However, the descriptions in this section are specifically not 893 intended to exclude other implementation strategies. 895 This section is for informational purposes only. 897 o Examples of Use 899 In order to provide more a more concrete sense of how this service 900 might be used, this section describes some example uses of the 901 service, for informational purposes only. The examples here are not 902 meant to be exhaustive, and do not exclude in any way other uses of 903 the service. 905 This section is for informational purposes only. 907 Security Considerations 909 Security considerations are not discussed in this memo. 911 References 913 1. C. Partridge, Gigabit Networking, Addison Wesley Publishers 914 (1994). 916 Authors' Address: 918 Scott Shenker 919 Xerox PARC 920 3333 Coyote Hill Road 921 Palo Alto, CA 94304-1314 922 shenker@parc.xerox.com 923 415-812-4840 924 415-812-4471 (FAX) 926 John Wroclawski 927 MIT Laboratory for Computer Science 928 545 Technology Sq. 929 Cambridge, MA 02139 930 jtw@lcs.mit.edu 931 617-253-7885 932 617-253-2673 (FAX)