idnits 2.17.1 draft-ietf-diffserv-header-00.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-26) 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([ARCH], [FWK], [Baker]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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.) -- The document date (May 1998) is 9478 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2309 (ref. 'ACTIVE') (Obsoleted by RFC 7567) -- Possible downref: Non-RFC (?) normative reference: ref. 'AH' -- Possible downref: Non-RFC (?) normative reference: ref. 'ARCH' -- Possible downref: Non-RFC (?) normative reference: ref. 'Baker' -- Possible downref: Non-RFC (?) normative reference: ref. 'CBQ' -- Possible downref: Non-RFC (?) normative reference: ref. 'CONS' -- Possible downref: Non-RFC (?) normative reference: ref. 'CCBES' -- Possible downref: Non-RFC (?) normative reference: ref. 'ECN' -- Possible downref: Non-RFC (?) normative reference: ref. 'FWK' -- Possible downref: Non-RFC (?) normative reference: ref. 'HPFQA' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPv6' ** Obsolete normative reference: RFC 1349 (Obsoleted by RFC 2474) -- Possible downref: Non-RFC (?) normative reference: ref. '2BIT' Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Kathleen Nichols 2 Diffserv Working Group Bay Networks Architecture Lab 3 Expires: November 1998 Steven Blake 4 IBM Microelectronics 6 May 1998 8 Definition of the Differentiated Services Field (DS Byte) 9 in the IPv4 and IPv6 Headers 11 13 Status of This Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 To view the entire list of current Internet-Drafts, please check the 26 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 28 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 29 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 31 Abstract 33 Differentiated services are intended to provide scalable service 34 discrimination in the Internet without the need for per-flow state 35 and signaling at every hop. A variety of services may be built from 36 a small, well-defined set of building blocks which are deployed in 37 network nodes. The services may be either end-to-end or intra- 38 domain. Services can be provided by a combination of: 40 - setting bits in an IP header field at network edges and 41 administrative boundaries, 42 - using those bits to determine how packets are forwarded by the 43 routers inside the network, and 44 - conditioning the marked packets at network boundaries in accordance 45 with the requirements or rules of each service. 47 This document defines the IP header field, called the DS (for 48 differentiated services) byte. In IPv4, it takes the place of the TOS 49 octet; in IPv6, it takes the place of the Traffic Class octet. A 50 differentiated services-capable network node includes a classifier 52 Nichols, Blake Expires: November 1998 [Page 1] 53 that selects packets based on the value of the DS byte and is capable 54 of delivering the specific packet forwarding treatment corresponding 55 to that value. This document defines two packet forwarding 56 treatments, or per-hop behaviors. Setting of the DS byte and other 57 conditioning of the dynamic behavior of marked packets need only be 58 performed at network boundaries and may vary in complexity. 60 For a more complete understanding of differentiated services, this 61 document should be read along with its companion documents, the 62 differentiated services architecture [ARCH], the differentiated 63 services framework [FWK], and other documents which specify 64 additional per-hop behaviors, such as [Baker]. 66 1. Introduction 68 The DS byte is used to mark a packet to receive a particular 69 forwarding treatment, or per-hop behavior, on nodes along its path. 70 Marking is performed by traffic conditioners at network boundaries, 71 including the edges of the network (first hop router or source host) 72 and administrative boundaries. Traffic conditioners may include the 73 primitives of classification, marking, policing and shaping (these 74 mechanisms are described in [ARCH]). Services are realized by the 75 use of particular traffic conditioning at boundaries coupled with the 76 concatenation of per-hop behaviors along the transit path of the 77 traffic (services are discussed in [FWK]). A goal of the 78 differentiated services architecture is to specify these building 79 blocks for future extensibility, both of the number and type of the 80 building blocks and of the services built from them. 82 Terminology used in this draft is defined in Sec. 2. The 83 differentiated services byte definition (DS byte) is given in Sec. 3. 84 In Sec. 4, two specific per-hop behaviors are defined. Sec. 5 85 presents guidelines for per-hop behavior standardization. Sec. 6 86 discusses guidelines for allocation of per-hop behavior codepoints. 87 Sec. 7 covers security considerations. We present two example 88 services which can be built from these differentiated services 89 primitives in the Appendix. 91 This document is a concise description of the DS byte and its uses. 92 It is intended to be read along with its companion documents, the 93 differentiated services architecture [ARCH], the differentiated 94 services framework [FWK], and other documents which specify 95 additional per-hop behaviors, such as [Baker]. 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 Nichols, Blake Expires: November 1998 [Page 2] 102 2. Terminology Used in This Document 104 Behavior aggregate: a collection of packets with the same codepoint 105 crossing a boundary in a particular direction. The terms "aggregate" 106 and "behavior aggregate" are used interchangeably in this document. 108 Boundary: Where two network "clouds" are linked; the "clouds" can 109 represent different administrative domains or autonomous systems, 110 different trust regions, different network technologies (e.g., cell/ 111 frame), hosts and routers, etc. A boundary can be further sub- 112 divided into exit and entry nodes, where the exit/entry nodes are the 113 upstream/downstream nodes of a boundary link in a given traffic 114 direction. 116 Codepoint: a specific value of the PHB field in the DS byte. 118 DS byte: the IPv4 header TOS octet or the IPv6 Traffic Class octet 119 when interpreted in conformance with the definition given in this 120 document. 122 Mechanism: The implementation of a per-hop behavior according to a 123 particular algorithm. 125 Network edge: refers to a particular boundary node, the edge of the 126 differentiated services-compliant area. This typically is at the 127 ingress to the first-hop differentiated services-aware router (or 128 network node) a host's packets traverse, or at the egress of the 129 last-hop differentiated services-aware router or network node packets 130 traverse before arriving at a host. This is sometimes referred to as 131 the boundary at a leaf router. The network edge might be co-located 132 with a host, subject to local policy. 134 Per-hop Behavior: a description of the externally observable 135 forwarding treatment applied at a differentiated services-enabled 136 node to a behavior aggregate. 138 Service: a description of the overall treatment of a customer's 139 traffic within a particular domain or end-to-end. 141 Traffic conditioner: an entity which performs traffic conditioning 142 functions and which may contain header classifiers, meters, policers, 143 shapers, and markers. Traffic conditioners are typically deployed in 144 boundary nodes only. 146 Traffic conditioning: control functions that can be applied to a 147 behavior aggregate, application flow, or other operationally useful 148 subset of traffic, e.g., routing updates. These may include header 149 classification, metering, policing, shaping, and packet marking. 150 Traffic conditioning is used to enforce service level agreements 151 between domains and to condition traffic to receive a differentiated 152 service within a domain. 154 Nichols, Blake Expires: November 1998 [Page 3] 155 To summarize, the DS byte is used to designate behaviors. A DS byte 156 classifier and per-hop behaviors based on those classifications are 157 required in all network nodes of a differentiated services-capable 158 network. More extensive traffic conditioners may appear at 159 boundaries. Multiple services can be supported by a single per-hop 160 behavior used in concert with a range of traffic conditioners. 162 3. Differentiated Services Byte Definition 164 A new header field, called the DS byte, is defined. The DS byte then 165 overrides existing definitions of the IPv4 TOS octet [RFC791] and the 166 IPv6 Traffic Class octet [IPv6]. 168 Six bits of the DS byte are used to define the per-hop behavior (PHB) 169 a packet experiences. A two-bit currently unused (CU) field is 170 reserved and may be assigned later, e.g., for explicit congestion 171 notification [ECN]. The value of the CU bits MUST be ignored by 172 differentiated services-compliant nodes when determining the per-hop 173 behavior to apply to a received packet. 175 The DS byte structure is presented below: 177 0 1 2 3 4 5 6 7 178 +---+---+---+---+---+---+---+---+ 179 | PHB | CU | 180 +---+---+---+---+---+---+---+---+ 182 PHB: per-hop behavior 183 CU: currently unused 185 Implementors should note that the PHB field is 6 bits wide. Routers 186 MUST identify PHBs by matching against the entire 6-bit PHB field, 187 e.g., by treating the value or "codepoint" of the PHB field as a 188 table index or a switch/case statement variable which is used to 189 select a particular packet handling mechanism which has been 190 implemented in that device. Although the IANA may assume some 191 structure within the PHB field when assigning values for new per-hop 192 behaviors, we define it as an unstructured field to facilitate the 193 definition of future per-hop behaviors. 195 Packets received with an unrecognized codepoint SHOULD be forwarded 196 as if they were marked for the Default behavior (see Sec. 4). 198 The structure of the DS byte shown above is incompatible with the 199 existing definition of the IPv4 TOS octet in [RFC791, RFC1349]. The 200 presumption is that differentiated services-aware networks protect 201 themselves by deploying re-marking boundary nodes, as should networks 202 using the RFC 791 Precedence designations. Correct operational 203 procedure should follow [RFC791], which states: "If the actual use of 205 Nichols, Blake Expires: November 1998 [Page 4] 206 these precedence designations is of concern to a particular network, 207 it is the responsibility of that network to control the access to, 208 and use of, those precedence designations." Validating the value of 209 the DS byte at network boundaries is sensible in any case since an 210 upstream node can easily set it to any random value. Differentiated 211 services-enabled networks which are not suitably isolated by a 212 re-marking boundary node may deliver unpredictable service. A 213 companion document [Baker] describes how a minimal necessary amount 214 of compatibility with RFC 791 Precedence can be maintained under use 215 of the DS byte. 217 4. Initial Per-Hop Behavior Definitions 219 Two per-hop behaviors are already in widespread use and we propose 220 them for standardization: Default (DE) is the common, best-effort 221 forwarding behavior available in existing routers and is already 222 standardized in [RFC1812]. Expedited Forwarding (EF) is a "high 223 priority" forwarding behavior such as might be used for delay 224 sensitive traffic such as audio and video. The codepoints for these 225 two behaviors are shown below: 227 Codepoint Behavior name 228 --------- ------------- 230 000000 Default (DE) 231 000010 Expedited Forwarding (EF) 233 and the behaviors are defined as follows: 235 Default: a DE-marked packet is queued for an outgoing interface 236 according to the availability of buffer resources and according to 237 any active queue management policy that may be implemented [ACTIVE]. 238 It is not required that all arriving packets are seen at the output, 239 but it is RECOMMENDED that the aggregate of packets with this marking 240 not be completely starved. Forwarding requirements are as soon as 241 possible, and the corresponding output bandwidth requirements are as 242 much as possible, subject to the other constraints of the router's 243 scheduling and buffer management sub-systems [CCBES]. The Default 244 behavior is intended to closely approximate the best-effort behavior 245 of existing routers. The codepoint chosen for Default behavior is 246 compatible with existing practice [RFC791, RFC1349]. 248 A packet originating from a node and marked for the Default behavior 249 may be re-marked with another PHB codepoint at a downstream network 250 boundary to enable preferential forwarding within that network, 251 possibly subject to some negotiated agreement. 253 Expedited Forwarding: for traffic levels of EF-marked packets which 254 are a small fraction of the link rate of an outgoing interface, the 256 Nichols, Blake Expires: November 1998 [Page 5] 257 implementation of Expedited Forwarding should exhibit the following 258 behavioral characteristics: low absolute delay, low delay variation, 259 and extremely low loss, irrespective of the rate of non-EF-marked 260 traffic which is forwarded through that same outgoing interface. The 261 delay and loss characteristics should be similar to that observed by 262 a single packet traversing an otherwise idle router, and should not 263 vary significantly as the rate of non-EF-marked traffic is increased. 264 The maximum rate of EF-marked traffic which can be forwarded on an 265 outgoing link while satisfying the desired behavioral characteristics 266 is implementation-dependent. The Expedited Forwarding behavior can 267 be realized by a variety of mechanisms, including strict priority 268 queueing, WFQ or variants [HPFQA], weighted round-robin queueing with 269 a large weight for the EF queue, or CBQ [CBQ]. 271 The Expedited Forwarding behavior may be used to implement services 272 requiring low delay and low jitter. Service guarantees for this 273 class of traffic SHOULD depend on conformance to some rate and 274 burstiness constraints which are enforced by traffic conditioners at 275 network boundaries, possibly subject to some negotiated agreement. 276 EF-marked aggregates which are in excess of these constraints may 277 have some or all of their packets delayed (by a shaper) or discarded. 279 Note that conforming implementations will commonly employ separate 280 scheduler queues for DE- and EF-marked packets. Thus it should be 281 expected that packet streams which include both DE- and EF-marked 282 packets may suffer packet reordering when traversing a conforming 283 router. 285 5. Per-Hop Behavior Standardization Guidelines 287 Thirty-two PHB codepoints are reserved for standardization, and 32 288 codepoints are reserved for experimental or local use (EXP/LU) 289 (see Sec. 6 for further details). 291 The behavioral characteristics of a PHB are to be standardized, and 292 not the algorithms or the mechanisms used to implement them. A 293 router may have a (possibly large) set of parameters that can be used 294 to control how packets are scheduled onto an output interface (e.g., 295 N separate queues with settable priorities, queue lengths, round- 296 robin weights, drop algorithm, drop preference weights and 297 thresholds, etc). To illustrate the distinction between a PHB and a 298 mechanism, we point out that the EF PHB might be implemented by 299 several mechanisms, including: strict priority queueing, WFQ or 300 variants [HPFQA], weighted round-robin queueing with a large weight 301 for the EF queue, or CBQ [CBQ]. 303 Router vendors are free to offer whatever parameters and capabilities 304 are deemed useful or marketable. When a particular, standardized PHB 305 is implemented in a router, a vendor may use any algorithm that 306 satisfies the definition of the PHB according to the standard. The 307 router's capabilities and its particular configuration determine the 309 Nichols, Blake Expires: November 1998 [Page 6] 310 different ways that packets can be treated. 312 Service providers are not required to use the same router mechanisms 313 or configurations to enable service differentiation within their 314 networks, and are free to configure the router parameters in whatever 315 way that is appropriate for their service offerings and traffic 316 engineering objectives. Over time certain common per-hop behaviors 317 are likely to evolve (i.e., ones that are particularly useful for 318 implementing end-to-end services) and these may be associated with 319 particular EXP/LU PHB codepoints in the DS byte, allowing use across 320 domain boundaries (see Sec. 6). These PHBs are candidates for future 321 standardization. 323 Only those per-hop behaviors that are not described by an existing 324 PHB standard, and have been implemented, deployed, and shown to be 325 useful, should be standardized. Since current experience with 326 differentiated services is quite limited, it is premature to 327 hypothesize the exact specification of these per-hop behaviors. This 328 specification has left room in the codepoint space to allow for 329 evolution, thus the defined space is intentionally sparse. 331 6. IANA Considerations 333 The PHB field in the DS byte is capable of conveying 64 distinct 334 codepoints. The codepoint space is divided into three pools for the 335 purpose of codepoint assignment and management: a pool of 32 336 codepoints (Pool 1) to be assigned by Standards Action as defined in 337 [CONS], a pool of 16 codepoints (Pool 2) to be reserved for 338 experimental or Local Use (EXP/LU) as defined in [CONS], and a pool 339 of 16 codepoints (Pool 3) which are initially available for 340 experimental or local use, but which should be preferentially 341 utilized for standardized assignments if Pool 1 is ever exhausted. 342 The pools are defined in the following table (where 'x' refers to 343 either '0' or '1'): 345 Pool Codepoint space Assignment Policy 346 ---- --------------- ----------------- 348 1 xxxxx0 Standards Action 349 2 xxxx11 EXP/LU 350 3 xxxx01 EXP/LU (*) 352 (*) may be utilized for future Standards Action allocations as 353 necessary 355 This document defines two per-hop behaviors for standardization, and 356 recommends the assignment of two codepoints (000000 and 000010) which 357 are drawn from Pool 1 above. 359 Nichols, Blake Expires: November 1998 [Page 7] 360 The IANA should note that a companion document may recommend 361 assignment of the codepoint space xxxx00 within Pool 1 for use by 362 per-hop behaviors which provide a minimal level of backwards 363 compatibility with IP Precedence as defined in [RFC791]. 365 7. Security Considerations 367 The IP Security Authentication Header (AH) does not cover the IPv4 368 TOS octet or the IPv6 Traffic Class field in the integrity check 369 value computation [AH]. This behavior is in fact essential for the 370 deployment of differentiated services since the value of the DS byte 371 may be changed in transit so that the source host does not know what 372 value will be delivered to the destination host. Also, since the 373 network is free to ignore the DS byte, end-to-end integrity of a DS 374 byte value does not guarantee that a differentiated service has been 375 delivered. Separate measurement and assurance mechanisms are needed 376 to ensure that any negotiated differentiated services are being 377 provided. 379 Packets marked for Expedited Forwarding receive priority service 380 relative to packets with other markings. The rate of EF-marked 381 packets MUST be regulated to prevent starvation of other traffic. 382 EF-marked traffic received across a boundary link SHOULD be 383 authenticated (e.g., either by IPsec, by header classification, or by 384 aggregate policing). 386 Additional security issues of the general differentiated services 387 architecture are discussed in [ARCH]. 389 8. Acknowledgements 391 The authors would like to acknowledge the Differentiated Services 392 Working Group for discussions which helped shape this document. 394 9. References 396 [ACTIVE] B. Braden, et. al., "Recommendations on Queue Management 397 and Congestion Avoidance in the Internet", Internet RFC 398 2309, April 1998. 400 [AH] S. Kent and R. Atkinson, "IP Authentication Header", 401 Internet Draft , 402 March 1998. 404 [ARCH] Differentiated Services Architecture Document (work in 405 preparation). 407 Nichols, Blake Expires: November 1998 [Page 8] 409 [Baker] F. Baker, S. Brim, T. Li, F. Kastenholz, S. Jagannath, 410 and J. Renwick, "IP Precedence in Differentiated 411 Services Using the Assured Service", Internet Draft 412 , April 1998. 414 [CBQ] S. Floyd and V. Jacobson, "Link-sharing and Resource 415 Management Models for Packet Networks", IEEE/ACM 416 Transactions on Networking, Vol. 3 no. 4, pp. 365-386, 417 August 1995. 419 [CONS] T. Narten and H. Alvestrand, "Guidelines for Writing an 420 IANA Considerations Section in RFCs", Internet Draft 421 , March 1998. 423 [CCBES] C. Lefelhocz, B. Lyles, S. Shenker, and L. Zhang, 424 "Congestion Control for Best-Effort Service: Why We Need 425 a New Paradigm", IEEE Network, Vol. 10, no. 1, January 426 1996. 428 [ECN] K. Ramakrishnan and S. Floyd, "A Proposal to Add Explicit 429 Congestion Notification (ECN) to IPv6 and to TCP", 430 Internet Draft , November 1997. 432 [FWK] Differentiated Services Framework Document (work in 433 preparation). 435 [HPFQA] J. Bennett and Hui Zhang, "Hierarchical Packet Fair 436 Queueing Algorithms", Proc. ACM SIGCOMM 96, August 1996. 438 [IPv6] S. Deering and R. Hinden, "Internet Protocol, Version 6 439 (IPv6) Specification", Internet Draft 440 , November 1997. 442 [RFC791] Information Sciences Institute, "Internet Protocol", 443 Internet RFC 791, September 1981. 445 [RFC1349] P. Almquist, "Type of Service in the Internet Protocol 446 Suite", Internet RFC 1349, July 1992. 448 [RFC1812] F. Baker, editor, "Requirements for IP Version 4 449 Routers", Internet RFC 1812, June 1995. 451 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 452 Requirement Levels", Internet RFC 2119, March 1997. 454 [2BIT] K. Nichols, V. Jacobson, and L. Zhang, "A Two-bit 455 Differentiated Services Architecture for the Internet", 456 http://www-nrg.ee.lbl.gov/papers/2bitarch.pdf. 458 Nichols, Blake Expires: November 1998 [Page 9] 459 Appendix A. Service Examples in this Framework 461 We present two example services which may be implemented using the 462 per-hop behaviors defined in this document. We do not attempt to 463 define "quality of service" for applications nor do we make 464 assumptions about what service a particular application might use. 465 Thus, although we give some example uses, we do not characterize the 466 services as being "for real-time video" or "for file transfer data". 467 Instead, we characterize a service by the type of performance packets 468 of that service can expect from the network. Any IP application can 469 utilize either of these services; the choice is up to the customer. 471 Service: Best Effort 472 PHBs used: Default 473 Service definition: "like today" (as soon as possible; as much as 474 possible [CCBES]). At the network edge, packets of the Best Effort 475 aggregate should be marked with the Default PHB (though this is also 476 the forwarding treatment that a packet with an unknown marking should 477 receive). This might be accomplished by marking all packets at the 478 network edge for the Default PHB which can be changed if the packet 479 header matches an multi-field classifier set up at the network edge. 481 Who/how to use this: The basic service of the Internet, what one gets 482 when merely buying connectivity. 484 Service: Premium 485 PHBs used: Expedited Forwarding 486 Service definition: Premium service is a peak-limited, extremely low- 487 delay service, resembling a leased line [2BIT]. At the network edge, 488 where a Premium aggregate is first created, it must be either shaped 489 or policed to a rate with no more than a two-packet burst. A policer 490 for Premium service is set to drop packets which exceed the 491 configured peak rate. For this service, the peak rate of the Premium 492 aggregate across any boundary must be specified and the rate must be 493 smaller than the link capacity (in practice, it is expected to be a 494 good deal less than the link capacity). Policing to this rate is 495 expected at the ingress of any domain and the policing action taken 496 may be one of two possibilities only: 1) drop the over-rate packet 497 and 2) hold the over-rate packet until it will be in compliance with 498 the peak rate (shaping). 500 Who/how to use this: Voice-over-IP "trunk", videoconference, fixed 501 size transfer in fixed time, virtual leased line, low delay 502 applications. 504 Authors' Addresses 506 Steven Blake 507 IBM Microelectronics 508 C5BA 660/HH007 509 800 Park Offices Drive 510 Research Triangle Park, NC 27709 511 Phone: +1-919-254-2030 512 Fax: +1-919-254-3047 513 E-mail: slblake@raleigh.ibm.com 515 Kathleen Nichols 516 Bay Networks Architecture Lab 517 4401 Great America Parkway 518 SC01-04 519 Santa Clara, CA 95052-8185 520 Phone: +1-408-495-3252 521 Fax: +1-408-495-1299 522 E-mail: knichols@baynetworks.com