idnits 2.17.1 draft-ietf-diffserv-model-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 == The page length should not exceed 58 lines per page, but there was 25 longer pages, the longest (page 4) being 60 lines 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 ([EF-PHB], [DSARCH], [DSMIB], [DSFIELD], [AF-PHB]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 52 has weird spacing: '..., Blake exp...' == Line 106 has weird spacing: '..., Blake exp...' == Line 157 has weird spacing: '..., Blake exp...' == Line 211 has weird spacing: '..., Blake exp...' == Line 266 has weird spacing: '..., Blake exp...' == (23 more instances...) -- 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 (June 1999) is 9076 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'COPS' is mentioned on line 215, but not defined ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. 'DSARCH') -- Possible downref: Non-RFC (?) normative reference: ref. 'DSFWK' -- Possible downref: Non-RFC (?) normative reference: ref. 'E2E' ** Obsolete normative reference: RFC 2598 (ref. 'EF-PHB') (Obsoleted by RFC 3246) -- Possible downref: Non-RFC (?) normative reference: ref. 'DSMIB' -- Possible downref: Non-RFC (?) normative reference: ref. 'SRTCM' -- Possible downref: Non-RFC (?) normative reference: ref. 'TRTCM' -- Possible downref: Non-RFC (?) normative reference: ref. 'GTC' Summary: 9 errors (**), 0 flaws (~~), 12 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Differentiated Services Y. Bernet 2 Internet Draft Microsoft 3 Expires December 1999 A. Smith 4 draft-ietf-diffserv-model-00.txt Extreme Networks 5 S. Blake 6 Ericsson Datacom 7 June 1999 9 A Conceptual Model for Diffserv Routers 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet- Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet- 28 Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Distribution of this memo is unlimited. 33 Copyright Notice 35 Copyright (C) The Internet Society (1998). All Rights Reserved. 37 Abstract 39 This draft proposes a conceptual model for use in the management of 40 Differentiated Services (diffserv) routers. We describe the 41 fundamental packet classification principles that allow traffic 42 streams to be differentiated. We describe the fundamental traffic 43 conditioning elements that comprise the traffic conditioning 44 functionality of diffserv routers. We describe the fundamental queue 45 elements that comprise the Per-Hop Behaviour (PHB) functionality of 46 diffserv routers. We propose a formal model for these. We also 47 describe parameters and variables that may be used for monitoring 48 the operation of the elements described above. There is no attempt 49 made to define the packet forwarding behaviours of diffserv routers 50 - these are well described elsewhere in the literature. 52 Bernet, Smith, Blake expires December, 1999 1 53 This draft is preliminary and is known to be inconsistent in some 54 respects with [DSMIB]. It is intended to correct this prior to the 55 next version, as well as to verify full consistency with the 56 published diffserv specifications [DSFIELD], [DSARCH], [AF-PHB], 57 [EF-PHB]. 59 1. Introduction 61 Differentiated Services (diffserv) [DSARCH, DSFWK] is a set of 62 technologies by which network service providers can offer differing 63 levels of network quality-of-service (QoS) to different customers 64 and their traffic streams. The premise of diffserv networks is that 65 routers within the networks handle packets in different traffic 66 streams by applying different per-hop behaviours (PHBs) to the 67 packet forwarding. The PHB to be applied is indicated by a diffserv 68 code-point (DSCP) in the IP header of each packet [DSFIELD]. Note 69 that this document uses the terminology of [DSFWK]. 71 The advantage of such a scheme is that many traffic streams can be 72 aggregated to one of a small number of behaviour aggregates (BA) 73 which are each forwarded using the same PHB at the router, thereby 74 simplifying the processing and associated storage. In addition, 75 there is no signaling, other than what is carried in the DSCP of 76 each packet, and no other related processing that is required in the 77 diffserv network since QoS is invoked on a packet-by-packet basis. 79 Although diffserv itself does not define the services that a 80 diffserv network can provide, its successful deployment depends on 81 the ability to use the technology to provide services. These 82 services are reflected to customers at the edges of the diffserv 83 network in the form of a Service Level Specification (SLS) [DSFWK]. 84 The ability to provide these services depends on the availability of 85 cohesive management tools that can be used to provision and monitor 86 a set of diffserv routers in a coordinated manner. To facilitate the 87 development of such management tools it is helpful to define a 88 conceptual model of a diffserv router that abstracts implementation 89 details of diffserv routers from the management tools used to manage 90 them. The purpose of this draft is to define this conceptual model. 92 The basic forwarding functionality of a diffserv router is defined 93 by other specifications e.g. [DSARCH], [DSFIELD], [AF-PHB], [EF- 94 PHB]. 96 This document is not intended in any way to constrain or to dictate 97 implementations of diffserv routers. We expect that router vendors 98 will demonstrate a great deal of variability in their 99 implementations. To the extent that vendors are able to model their 100 implementations using the abstractions described in this draft, 101 management tools will more readily be able to manage networks 102 incorporating diffserv routers of various implementations. 104 2. Organization of this Document 106 Bernet, Smith, Blake expires December, 1999 2 107 In Section 3 we start by describing the basic high-level functional 108 blocks of a diffserv router and then providing a block diagram and 109 describe the various components. We then focus on the diffserv- 110 specific components of the router and describe a hierarchical 111 management model for these. 113 In Section 4 we describe classification elements and in section 5, 114 we discuss the basic traffic conditioning elements. 116 In Section 6, we show how the basic classification and traffic 117 conditioning elements can be combined to build modules called 118 Traffic Conditioning Blocks (TCBs). 120 In Section 7, we discuss the basic queuing components. 122 In Section 8, we discuss those parameters that it must be possible 123 to monitor for the purposes of managing a diffserv router. 125 3. Elements of a Diffserv Router 127 In this section we introduce a block diagram of a diffserv router 128 and describe the various components illustrated. Note that the 129 functions of a diffserv core router are likely to be a much 130 simplified set of these components: the model we present here is 131 intended to cover the case of a diffserv edge router as well as the 132 core. 134 3.1 Conceptual Model 136 The conceptual model we define includes abstract definitions of the 137 following: 139 1. The basic traffic classification components. 140 2. The basic traffic conditioning components. 141 3. Certain combinations of traffic conditioning components. 142 4. Queuing components. 144 The components and combinations of components described in this 145 document form building blocks that need to be manageable by 146 diffserv management tools. One of the goals of this document is to 147 show how a model of a diffserv device can be built up out of these 148 component blocks. This model is in the form of a connected acyclic 149 directional graph that describes the traffic conditioning behaviour 150 that any particular data packet will experience when submitted to 151 the diffserv router. 153 It is anticipated that these building blocks may also be used as 154 the basis for a diffserv MIB or other such specific device 155 configuration mechanisms. 157 Bernet, Smith, Blake expires December, 1999 3 158 3.2 Block Diagram 160 The following diagram illustrates the major functional blocks of a 161 diffserv router: 163 +--------------+ 164 | diffserv | 165 Mgmt | configuration| 166 <------>| & monitoring |---------------- 167 SNMP,| | interface | | 168 COPS | +--------------+ | 169 etc. | | | 170 | | | 171 | v v 172 | +----------+ +-------+ +---------+ +-------+ 173 data | |ingress | |routing| |egress | |queuing| 174 ------->|-classif. |-->| |-->|-classif.|-->| stuff |--> 175 | |-TCB | +-------+ |-TCB | +-------+ 176 | +----------+ +---------+ 177 | ^ ^ 178 | | | 179 | +----------+ | 180 -->| | | 181 ------->| RSVP |-------------------- 182 RSVP |(optional)| 183 cntl +----------+ 184 msgs 186 In this diagram, a Traffic Conditioning Block (TCB) represents a 187 combination of metering, marking, shaping, dropping elements that 188 are discussed in more detail below. 190 3.2.1 Interfaces, Classification, Traffic Conditioning, Queuing and the 191 Routing Core 193 An ingress interface, routing component and egress interface are 194 illustrated at the center of the diagram. In actual router 195 implementations, there may be an arbitrary number of inbound and 196 outbound interfaces interconnected by the routing core. The 197 components of interest on these interfaces are the traffic 198 classifiers, the traffic conditioning components (TC) and the 199 queuing components that support the Per-Hop Behaviour (PHB) 200 [DSARCH]. These are the fundamental components comprising a diffserv 201 router and will be the focal point of our conceptual model. 203 3.2.2 Diffserv Configuration and Monitoring Interface 205 Diffserv operating parameters are monitored and provisioned through 206 this interface. Monitored parameters include statistics regarding 207 traffic carried at various diffserv service levels. These statistics 208 are important for accounting purposes and for tracking compliance to 209 service level agreements (SLAs [DSARCH]) negotiated with customers. 211 Bernet, Smith, Blake expires December, 1999 4 212 Provisioned parameters are primarily classification rules, PHB and 213 TC configuration parameters. The network administrator interacts 214 with the diffserv configuration and monitoring interface via one or 215 more management protocols, such as SNMP or COPS [COPS] or through 216 other router configuration tools such as serial terminal or telnet 217 consoles. 219 3.2.3 Optional RSVP Module 221 Diffserv routers may snoop or participate in either per-microflow or 222 per-flow-aggregate signaling of QoS requirements [E2E]. The example 223 discussed here uses the RSVP protocol. Snooping of RSVP messages may 224 be used, for example, to learn how to classify traffic without 225 actually participating as a RSVP protocol peer. Diffserv routers may 226 reject or admit RSVP reservation requests to provide a means of 227 admission control to diffserv-based services or they may use these 228 requests to trigger provisioning changes for a flow-aggregation in 229 the diffserv network. A flow-aggregation in this context might be 230 equivalent to a diffserv BA or it may be more fine-grained, relying 231 on a MF classifier. Note that the conceptual model of such a router 232 starts to look the same as a Integrated Services (intserv) router in 233 its component makeup [E2E]. 235 Note that a RSVP component of a diffserv router, if present, might 236 be active only in the control plane and not in the data plane. In 237 this scenario, RSVP is used strictly as a signaling protocol. The 238 data plane of such a diffserv router can still act purely on 239 diffserv DSCPs and PHBs in handling data traffic. 241 3.3 Hierarchical Model of Diffserv Components 243 We focus on the diffserv specific functional components of the 244 router, the traffic conditioning and queuing functionality. The 245 example below is based on the larger block diagram shown above: 247 Interface A Interface B 248 +------------+ +-------+ +------------+ 249 ------->| ingress |---->| |---->| egress |---> 250 |(class.,TC) | | | |(queuing,TC)| 251 +------------+ |routing| +------------+ 252 | | 253 +------------+ | | +------------+ 254 <-------| egress |<----| |<----| ingress |<--- 255 |(queuing,TC)| +-------+ |(class.,TC) | 256 +------------+ +------------+ 258 Figure 1 - Traffic Conditioning and Queuing 260 This diagram illustrates two diffserv router interfaces, each having 261 an ingress and an egress component. It shows classification and TC 262 components on each interface's ingress and it shows both TC and PHB 263 components on each interface's egress. From a management 264 perspective, the following hierarchy exists: 266 Bernet, Smith, Blake expires December, 1999 5 267 At the top level, the router manager manages interfaces. Each 268 interface consists of an ingress component and an egress component. 269 An ingress component contains TC components. An egress component 270 contains PHB components and TC components. (There may be special 271 cases in which a router implements PHB components on an ingress 272 interface. This model is readily extensible to reflect such an 273 implementation. However, we have chosen not to do so in this case.) 275 The TC components on each interface are described by a traffic 276 conditioning table (TCT) corresponding to the interface. The TCT 277 describes traffic classification and conditioning elements and how 278 they are combined to provide the interface's traffic conditioning 279 functionality. Certain traffic conditioning elements may be grouped 280 into traffic conditioning blocks (TCBs). 282 PHB components contain queues and the enqueuing and dequeuing 283 algorithms that serve them. Queues are each independently 284 parameterized. There may also be parameters defining relationships 285 between PHBs. 287 4. Classification Elements 289 Classification is a necessary function for any device that treats 290 certain traffic differently from other traffic. The very nature of a 291 diffserv router is that it treats traffic differentially. Therefore, 292 classification is the most basic function required from a 293 differentiated service router. 295 Classification is performed by a classifier. Classifiers take a 296 single traffic stream as input and generate logically separate 297 traffic streams as output. Packets from the input stream are sorted 298 into various output streams depending on the contents of the packet 299 and possibly on other sources of information e.g. input sub-channel 300 number. The various types of classifiers are described in the 301 following sections. 303 4.1 Behaviour Aggregate (BA) Classifier 305 The simplest diffserv classifier is a behaviour aggregate (BA) 306 classifier. A BA classifier uses only the diffserv codepoint (DSCP) 307 in a packet's IP header to determine the logical output stream to 308 which the packet should be directed. 310 4.2 Multi-Field (MF) Classifier 312 Another type of classifier is a multi-field (MF) classifier. This 313 classifies packets based on one or more fields in the packet header 314 other than the DSCP. A common type of MF classifier is a 5-tuple 315 classifier that classifies based on the five IP header fields of 316 source/destination address, source/destination port and IP protocol 317 number. MF classifiers may classify based on other fields such as 319 Bernet, Smith, Blake expires December, 1999 6 320 MAC addresses, VLANs, link-layer traffic class or other higher layer 321 protocol addresses. 323 4.3 Other Classifier Types 325 Classification may be performed based on implicit information 326 associated with a packet (e.g. the incoming channel number on a 327 channelized interface) or on information derived from a different 328 classification operation (e.g. the outgoing interface determined by 329 the route lookup operation). We do not discuss these further here. 331 4.4 Filters 333 Classifiers are parameterized by filters and output streams. For 334 example, the following classifier separates traffic into one of 335 three output streams based on two filters: 337 Filter Matched Output Stream 338 -------------- --------------- 339 1 A 340 2 B 341 no match C 343 Where filters 01 and 02 are defined to be the following BA filters: 345 Filter DSCP 346 ------ ------ 347 1 101010 348 2 111111 350 A filter consists of a set of conditions on the component values of 351 a classification key. In the BA classifier example above, the 352 classification key consists of one packet header field, the DSCP, 353 and both Filter1 and Filter2 specify exact-match conditions on the 354 value of the DSCP. The third filter is a wildcard default filter 355 which matches every packet, but which is only selected in the event 356 that no other more specific filter matches. 358 In general there are a whole set of possible component conditions 359 including exact, prefix, range, wildcard and masked matches. Note 360 that ranges can be represented (maybe less efficiently) as a set of 361 prefix matches and that prefix matches are just a special case of 362 masked matches. 364 In the case of a MF classifier, the classification key consists of a 365 number of packet header fields. The filter may specify a different 366 condition for each key component, as illustrated in the example 367 below for a TCP/IPv4 classifier: 369 Filter IP Src Addr IP Dest Addr TCP SrcPort TCP DestPort 370 ------ ------------- ------------- ----------- ------------ 371 Filter1 172.31.8.1/32 172.31.3.X/24 X 5003 373 Bernet, Smith, Blake expires December, 1999 7 374 In this example, the fourth octet of the destination IPv4 address 375 and the source TCP port are 'don't cares'. 377 4.5 Diagram of a Classifier 379 We use the following diagram to illustrate a classifier, where the 380 outputs are to be plumbed in to succeeding TC elements: 382 unclassified classified 383 traffic traffic 384 ----------- 385 | |--> match Filter1 --> output A 386 ----->|classifer|--> match Filter2 --> output B 387 | |--> no match --> output C 388 ----------- 390 Figure 2 - An Example Classifier 392 Note that an input interface number can also be considered as an 393 input to the classifier if the classifier is modeled as accepting 394 packets from multiple input ports - this optimisation may be 395 important for scalability in the management plane. 397 4.6 Formal Representation of Classifiers 399 4.6.1 IPv4 5-tuple Classifier 401 The following formal definition can be used to represent a 402 classifier using masked match conditions: 404 408 Classifier0: 409 Filter1: output A 410 Filter2: output B 411 No Match: output C 413 Filter1: Filter2: 414 Type: IPv4 5-tuple Type: IPv4 5-tuple 415 Ipv4SrcAddrValue: 172.31.8.0 Ipv4SrcAddrValue: 172.31.9.0 416 Ipv4DestAddrValue: 0 Ipv4DestAddrValue:0 417 Ipv4SrcPortValue: 0 Ipv4SrcPortValue: 0 418 Ipv4DestPortValue: 5003 Ipv4DestPortValue:5003 419 Ipv4ProtocolValue: 0 Ipv4ProtocolValue:0 420 Ipv4SrcAddrMask: 255.255.255.0 Ipv4SrcAddrMask: 255.255.255.0 421 Ipv4DestAddrMask: 0.0.0.0 Ipv4DestAddrMask: 0.0.0.0 422 Ipv4SrcPortMask: 0 Ipv4SrcPortMask: 0 423 Ipv4DestPortMask: 0xFFFF Ipv4DestPortMask: 0xFFFF 424 Ipv4ProtocolMask: 0 Ipv4ProtocolMask: 0 426 4.6.2 IPv6 5-tuple Classifier 428 Bernet, Smith, Blake expires December, 1999 8 429 The following formal definition can be used to represent a IPv6 430 multi-field classifier using masked match conditions: 432 Classifier1: 433 Filter3: output A 434 No Match: output B 436 Filter3: 437 Type: IPv6 5-tuple 438 Ipv6SrcAddrValue: 0:0:0:0:0:FFFF:32.12.65.0 439 Ipv6SrcAddrMask: FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:255.255.255.0 440 Ipv6DestAddrValue: 1080:0:0:0:0:0:0:0 441 Ipv6DestAddrMask: FFFF:FFFF:FFFF:FFFF:0:0:0:0 442 Ipv6SrcPortValue: 0 443 Ipv6SrcPortMask: 0 444 Ipv6DestPortValue: 5003 445 Ipv6DestPortMask: 0xFFFF 446 Ipv6NextHeaderValue: 6 447 Ipv6NextHeaderMask: 0xFF 449 4.6.3 Behaviour Aggregate Classifier 451 A BA classifier is parameterised by a set of 6-bit DSCP {value, 452 mask} pairs: 454 Classifier1: 455 Filter3: output A 456 Filter4: output B 457 No Match: output C 459 Filter3: Filter4: 460 Type: BA Type: BA 461 Value: 111000 Value: 110000 462 Mask: 111111 Mask: 111111 464 467 4.6.4 IEEE802 MAC Address Classifiers 469 A MacAddress classifier is parameterised by a 6-byte {value, mask} 470 pair for either source or destination MAC address.l for example, the 471 following classifier sends packets matching either DA 01-02-03-04- 472 05-06 or SA 00-E0-2B-XX-XX-XX to output A: 474 Classifier2: 475 Filter5: output A 476 Filter6: output A 477 No Match: output B 479 Filter5: 480 Type: DestMacAddress 482 Bernet, Smith, Blake expires December, 1999 9 483 Value: 01-02-03-04-05-06 (hex) 484 Mask: FF-FF-FF-FF-FF-FF (hex) 486 Filter6: 487 Type: SrcMacAddress 488 DestValue: 00-E0-2B-00-00-00 (hex) 489 DestMask: FF-FF-FF-00-00-00 (hex) 491 4.6.5 Free-form Classifier 493 A FreeForm classifier is made up of a set of user definable 494 arbitrary filters each made up of {bit-field size, offset (from head 495 of packet), mask}: 497 Classifier3: 498 Filter6: output A 499 Filter7: output B 500 No Match: output C 502 Filter6: 503 Type: FreeForm 504 SizeBits: 3 bits 505 Offset: 16 bytes 506 Value: 100 (binary) 507 Mask: 101 (binary) 509 Filter7: 510 Type: FreeForm 511 SizeBits: 12 bits 512 Offset: 16 bytes 513 Value: 100100000000 (binary) 514 Mask: 111111111111 (binary) 516 4.6.6 Other Standard Classifiers 518 e.g. IEEE802.1p, IEEE802.1Q VLAN-ID 520 Classifier4: 521 Filter8: output A 522 Filter9: output B 523 No Match: output C 525 Filter8: 526 Type: IeeePriority 527 Value: 100 (binary) 528 Mask: 101 (binary) 530 Filter9: 531 Type: IeeeVlan 532 Value: 100100000000 (binary) 533 Mask: 111111111111 (binary) 535 4.6.7 Vendor-Specific Classifier 537 Bernet, Smith, Blake expires December, 1999 10 538 Other vendor specific filter formats. 540 4.7 Combinations of Filters 542 Filters may be logically combined. For example, consider the 543 following DestMacAddress filter: 545 Filter3: 546 Type: DestMacAddress 547 Value: 01-02-03-04-05-06 548 Mask: FF-FF-FF-FF-FF-FF 550 Classifier0 could then be declared as: 552 Classifier0: 553 Filter1 and Filter3: output A 554 Filter2 and Filter3: output B 555 No Match: output C 557 4.7.1 Conflicting Filters 559 Note that it is easy to define sets of conflicting filters in a 560 classifier. For example: 562 Filter1: Filter2: 563 Type: BA Type: BA 564 Value: 111000 Value: 000111 (binary) 565 Mask: 111000 Mask: 000111 (binary) 567 A packet containing the DSCP 111111 cannot be uniquely classified by 568 this set of filters and so a precedence must be established between 569 Filter1 and Filter2 in order to break the tie. This precedence must 570 be established either (a) by a manager which knows that the router 571 can accomplish this particular ordering e.g. by means of reported 572 capabilities or (b) by the router along with a mechanism to report 573 to a manager which precedence is being used. These ordering 574 mechanisms must be supported by the management protocol although 575 further discussion of this is outside the scope of this document. 577 5. Traffic-Conditioning Elements 579 Traffic-conditioning is a essential function of a diff-serv router, 580 defined in [DSARCH]. This section defines the elements that can be 581 combined to provide the traffic-conditioning functionality 582 described. These include meters and various action elements. 584 5.1 Meters 586 Metering is the function of monitoring the arrival times of packets 587 on a traffic stream and determining the level of conformance of each 588 packet to a profile. Diffserv network providers may offer services 589 to customers based on a temporal profile within which the customer 591 Bernet, Smith, Blake expires December, 1999 11 592 submits traffic for the service. In this event, a meter might be 593 used to trigger real-time effects (e.g. marking) downstream; it 594 might also just be used for out-of-band management functions like 595 statistics monitoring and billing applications. 597 Meters are parameterized by a temporal profile and by conformance 598 levels. 600 5.1.1 Types of Meters 602 5.1.1.1 Average Rate Meter 604 An example of a very simple meter is an average rate meter. This 605 type of meter measures the average rate at which packets are 606 submitted to it over a specified averaging time. 608 An average rate profile may take the following form: 610 Average Rate: 10 packets per second 611 Averaging Interval: 1 second 613 A meter measuring against this profile would continually maintain a 614 count that indicates the total number of packets arriving between 615 time T (now) and time T-1 second. So long as an arriving packet does 616 not push the count over 10, the packet would be deemed conforming. 617 Any packet that pushes the count over 10, would be deemed non- 618 conforming. Thus, this meter deems packets to correspond to one of 619 two conformance levels - conforming or non-conforming. 621 5.1.1.2 Exponential Weighted Moving Average Meters 623 The EWMA form of meter is easy to implement in silicon and can be 624 parameterised as follows: 626 avg(n+1) = (1-Gain) * avg(n) + Gain * actual(n+1) 627 t(n+1) = t(n) + Delta 629 For a packet arriving at time t(m): 631 if (avg(m) > AverageRate) 632 non-conforming 633 else 634 conforming 636 Gain controls the time constant (e.g. frequency response) of what is 637 essentially a simple IIR low-pass filter. actual(n) and avg(n) 638 measure the number of incoming bytes in a small fixed sampling 639 interval, Delta. Any packet that arrives and pushes the average rate 640 over a predefined rate AverageRate is deemed non-conforming. 642 5.1.1.3 Token Bucket Meters 644 Bernet, Smith, Blake expires December, 1999 12 645 A more sophisticated meter might measure conformance to a token 646 bucket (TB) profile. A TB profile generally has three parameters, an 647 average rate, a peak rate and a burst size. TB meters compare the 648 arrival rate of packets to the average rate specified by the TB 649 profile. Logically, byte tokens accumulate in a bucket at the 650 average rate, up to a maximum credit which is the burst size. 651 Packets of length L bytes are considered conforming if L tokens are 652 available in the bucket at the time of packet arrival. Packets are 653 allowed to exceed the average rate in bursts up to the burst size, 654 so long as they do not exceed the peak rate, at which point the 655 bucket will be drained. Packets which arrive to find a bucket with 656 insufficient tokens in it are deemed non-conforming. 658 More complicated token bucket models might define two burst sizes 659 and three conformance levels. Packets found to exceed the larger 660 burst size are deemed non-conforming. Packets found to exceed the 661 smaller burst size are deemed partially conforming. Packets 662 exceeding neither are deemed conforming. Token bucket meters 663 designed for diff-serv networks are described in more detail in 664 [SRTCM], [TRTCM] and [GTC]: in some of these references, three 665 levels of conformance are discussed in terms of colors, with green 666 representing conforming, yellow representing partially conforming 667 and red representing non-conforming. 669 5.1.2 Diagram of a Meter 671 We use the following diagram to illustrate a meter with 3 levels of 672 conformance: 674 unmetered metered 675 traffic traffic 677 ----------- 678 | |--------> conformanceA 679 --------->| meter |--------> conformanceB 680 | |--------> conformanceC 681 ----------- 683 Figure 3 - An Example Meter 685 In some diffserv examples, three levels of conformance are discussed 686 in terms of colors, with green representing conforming, yellow 687 representing partially conforming and red representing non- 688 conforming. Other example meters use a binary notion of conformance; 689 in the general case there are 'N' levels of conformance. 691 5.1.3 Formal Representations of Meters 693 5.1.3.1 Simple Token Bucket Meter 695 The following formal definition can be used to represent this meter: 697 Meter1: 699 Bernet, Smith, Blake expires December, 1999 13 700 Type: SimpleTokenBucket 701 Profile1: output A 702 NonConforming: output B 704 Profile1: 705 Type: SimpleTokenBucket 706 AverageRate: 100 Kbps 707 PeakRate: 150 Kbps 708 BurstSize 100 Kb 710 5.1.3.2 EWMA Meter 712 Meter2: 713 Type: ExpWeightedMovingAvg 714 Profile2: output A 715 NonConforming: output B 717 Profile2: 718 Type: ExpWeightedMovingAvg 719 Gain: 1/16 720 Delta: 10us 721 AverageRate: 200 Kbps 723 5.1.3.3 Two-level Token Bucket Meter 725 Meter3: 726 Type: TwoLevelTokenBucket 727 Profile3: output A 728 Profile4: output B 729 NonConforming: output C 731 Profile3: 732 Type: SimpleTokenBucket 733 AverageRate: 100 Kbps 734 PeakRate: 150 Kbps 735 BurstSize 50 Kb 737 Profile4: 738 Type: SimpleTokenBucket 739 AverageRate: 120 Kbps 740 PeakRate: 150 Kbps 741 BurstSize 100 Kb 743 5.1.3.4 Average Rate Meter 745 Meter4: 746 Type: AverageRate 747 Profile5: output A 748 NonConforming: output B 750 Profile5: 751 Type: AverageRate 752 AverageRate: 120 Kbps 754 Bernet, Smith, Blake expires December, 1999 14 755 Delta: 100us 757 5.1.3.5 Other Vendor-specific Meters 759 Other vendor specific meters are also possible. 761 5.2 Action Elements 763 Classifiers and meters are generally used to determine the 764 appropriate action to apply to a packet. The set of possible non- 765 exclusive actions include: 767 1) Marking 768 2) Shaping 769 3) Dropping 770 4) Monitoring 772 The corresponding action elements are described in the following 773 paragraphs. Each of these actions has a default treatment which is 774 to simply pass the packet on to a PHB queue. 776 Policing is a general term for the action of preventing a traffic 777 stream from seizing more than its share of resources from a diffserv 778 network. Each of the three action elements described may be used to 779 police traffic. Markers do so by re-marking submitted packets to a 780 DSCP that is entitled to less network resources. Shapers and 781 droppers do so by limiting the rate at which a particular traffic 782 stream is submitted to the network. 784 5.2.1 Markers 786 Markers set the DSCP in a packet header. Markers may act on unmarked 787 packets (submitted with DSCP of zero) or may re-mark previously 788 marked packets. In particular, the model supports the application of 789 marking based on a preceding classifier match. The DSCP set in a 790 packet will determine its subsequent treatment both by any following 791 classifier elements within the same node or by other nodes 792 downstream in the diffserv network. 794 Markers are parameterized by a single parameter - the six-bit DSCP 795 to be marked in packet headers. 797 5.2.1.1 Formal Representation of a Marker 799 The following formal definition can be used to represent a marker: 801 ActionElement1: 802 Type: Marker 803 Mark: 010010 804 5.2.2 Shapers 806 Shapers are used to shape traffic to a certain temporal profile. For 807 example, a shaper can be used to smooth traffic arriving in bursts. 809 Bernet, Smith, Blake expires December, 1999 15 810 Shapers operate by delaying packets that would be deemed non- 811 conforming to the shaper's profile. The packet is delayed until such 812 time that it becomes conforming. Consider the average rate profile 813 described previously. In the case that a burst of 11 packets was 814 submitted simultaneously to a meter using the average rate profile, 815 the 11th packet would be deemed non-conforming. In order to be 816 deemed conforming, the packet would have to be delayed by one 817 second. Thus, a shaper parameterized by the average rate profile 818 (see section 5.1.1.1) would delay the 11th packet for one second. 819 Shapers are parameterized by a single temporal profile e.g. a token 820 bucket. 822 Implicit in the definition of a shaper is a notion of a queue and a 823 queue depth: in order to delay a packet, a shaper must have 824 somewhere to store the packet and that storage area often has finite 825 size. The queue is modeled here as a simple FIFO with a finite 826 depth. Packets are dropped if the depth is exceeded - this is 827 considered to be an error condition. 829 5.2.2.1 Uses of Shapers 831 Shapers are often used to pre-condition traffic such that packets 832 are not deemed non-conforming by subsequent meters, e.g. in 833 downstream diffserv nodes. Shapers may also be used to isolate 834 certain traffic streams from the effects of other traffic streams of 835 the same BA. For example, consider the case of two traffic streams 836 that are submitted to a diffserv network for a particular diffserv 837 service level. The agreement between the customer and the diffserv 838 network provider limits the rate of traffic that can be submitted at 839 a certain service level. In this case, one of the two traffic 840 streams may attempt to seize more than its fair share of the 841 available capacity for the service level. By doing so, it 842 compromises the other traffic stream. A shaper that acts 843 independently on the two streams can be used to limit the effect of 844 the rogue stream. Note also that a BA might be metered against one 845 profile whilst being shaped to a different profile further 846 downstream in the same device. 848 5.2.2.2 Formal Representation of a Shaper 850 The following formal definition can be used to represent a shaper: 852 ActionElement2: 853 Type: Shaper 854 Profile: Profile1 855 QueueDepth: size in bytes and/or packets 857 Profile definitions are identical in format to those described under 858 the formal definition of a meter. 860 862 5.2.3 Droppers 864 Bernet, Smith, Blake expires December, 1999 16 865 Droppers simply discard packets. There are no parameters for 866 droppers. 868 5.2.3.1 Formal Representation of a Dropper 870 The following formal definition can be used to represent a dropper: 872 ActionElement03: 873 Type: Dropper 875 5.2.4 Monitoring 877 One passive form of an action to be taken is simply to account for 878 the fact that a data packet was processed. This might be used later 879 on in presenting statistics for customer usage-based billing. 880 Further discussion of instrumentation for monitoring is provided in 881 section 0 although the topic of accounting is not dealt with in 882 detail here. 884 6. Traffic Conditioning Blocks (TCBs) 886 The classifiers and traffic conditioning elements described above 887 can be combined into traffic conditioning blocks (TCBs). The TCB is 888 an abstraction of a functional block that may be used to facilitate 889 the definition of traffic conditioning functionality. 891 A general TCB consists of three stages: 893 1. Classifier stage 894 2. Metering stage 895 3. Action stage 897 TCBs are constructed by connecting elements corresponding to these 898 stages in any order. It is allowable to omit stages or to 899 concatenate multiple stages of the same type. TCB outputs may drive 900 additional TCBs (on the same interface or on an egress interface) or 901 alternatively, may be directed to a PHB queue on an egress 902 interface. 904 6.1 Example TCB 906 The following diagram illustrates an example TCB: 908 Bernet, Smith, Blake expires December, 1999 17 909 -------------> to Queue A 910 ------- | 911 | |--- 912 -->| | 913 | | |--- ------- 914 | ------- | | | 915 | meter -->| |-----> discard 916 | | | 917 | ------- 918 | dropper 919 | 920 | 921 | -------------> to Queue B 922 submitted ------- | ------- | ^ 923 traffic | A |------- | |--- | 924 --->| B |-------->| | | 925 | C |------- | |--- ------- | 926 | X |---- | ------- | | | | 927 ------- | | meter -->| |--- 928 BA | | | | 929 classifier | | ------- 930 | | shaper 931 | | 932 | | 933 | | -------------> to Queue C 934 | | ------- | 935 | | | |--- 936 | -->| | 937 | | |--- ------- 938 | ------- | | | 939 | meter -->| |---> to Queue D 940 | | | 941 | ------- 942 | re-marker 943 | 944 ----------------------------> to Queue E 946 Figure 4 - An Example Traffic Conditioning Block 948 This sample TCB might be suitable for an ingress interface at a 949 customer/provider interface. A SLA is presumed to have been 950 negotiated between the customer and the provider which specifies the 951 handling of the customer's traffic by the provider's network. The 952 agreement might be of the following form: 954 DSCP PHB Profile Non-Conforming Packets 955 ---- --- ------- ------------------------- 956 001001 PHB1 Profile1 Discarded 957 001100 PHB2 Profile2 Shaped to Profile1 958 001101 PHB3 Profile3 Re-marked to DSCP 001000 960 It is implicit in this agreement that conforming packets are given 961 the PHB originally indicated by the packets' DSCP field. It 963 Bernet, Smith, Blake expires December, 1999 18 964 specifies that the customer may submit packets marked for DSCP 965 001001 which will get PHB1 treatment so long as they remain 966 conforming to Profile1 and will be discarded if they exceed this 967 profile. Similar contract rules are applied for 001100 and 001101 968 traffic. 970 In this example, the classification stage consists of a single BA 971 classifier. The BA classifier is used to separate traffic based on 972 the diffserv service level requested by the customer (as indicated 973 by the DSCP in each submitted packet's IP header). We illustrate 974 three DSCP filter values: A, B and C. The 'X' in the BA classifier 975 indicates 'no match'. 977 The metering stage is next. There is a separate meter for each set 978 of packets corresponding to DSCPs A, B and C. Each meter uses a 979 specific profile as specified in the SLA for the corresponding 980 diffserv service level. The meters in this example indicate one of 981 two conforming levels, conforming or non-conforming. 983 Following the metering stage is the action stage. Packets submitted 984 for DSCP A that are deemed non-conforming are discarded. Packets 985 that are conforming are passed on to the queue for the corresponding 986 PHB. 988 Packets submitted for DSCP B that are deemed non-conforming are 989 delayed in a shaper until they become conforming. Packets that are 990 deemed conforming are allowed to pass directly to the queue for PHB 991 B. 993 Note that in actual implementations, non-conforming packets will 994 cause packets on the same traffic stream that are conforming to be 995 delayed in order to maintain per-stream packet ordering. However, 996 this is an implementation detail and need not be considered from the 997 abstract management perspective. 999 Packets submitted for DSCP C and deemed non-conforming are re-marked 1000 for a less privileged DSCP and are directed to the appropriate PHB 1001 queue. Packets that are deemed conforming are passed directly to the 1002 requested PHB queue. 1004 6.2 Formal Representation of TCB 1006 The following is a formal representation of the interconnection of 1007 the components of the TCB illustrated in Error! Reference source not 1008 found.: 1010 TCB1: 1012 Classifier1: 1013 Output A --> Meter1 1014 Output B --> Meter2 1015 Output C --> Meter3 1016 Output X --> QueueE 1018 Bernet, Smith, Blake expires December, 1999 19 1019 Meter1: 1020 Output A --> QueueA 1021 Output B --> ActionElement1 (dropper) 1023 Meter2: 1024 Output A --> QueueB 1025 Output B --> ActionElement2 (shaper) 1027 ActionElement2: 1028 DefaultOutput --> QueueB 1030 Meter3: 1031 Output A --> QueueC 1032 Output B --> ActionElement3 (marker) 1034 ActionElement3: 1035 DefaultOutput --> QueueD 1037 6.3 Example TCB to Support Multiple Customers 1039 The TCB described above can be installed on an ingress interface to 1040 implement a provider/customer agreement if the interface is 1041 dedicated to the customer. However, if a single interface is shared 1042 between multiple customers, then the TCB above will not suffice, 1043 since it does not differentiate among traffic from different 1044 customers. Its classification stage uses BA classifiers only. 1046 The TCB is readily extended to support the case of multiple 1047 customers per interface, as follows. First, we define a TCB for each 1048 customer to reflect the agreement with that customer. TCB1, defined 1049 above is the TCB for customer 1. We add definitions for TCB2 and for 1050 TCB3 which reflect the agreements with customers 2 and 3 1051 respectively. 1053 Finally, we add a fourth TCB, TCB4, which provides a front end to 1054 separate the traffic from the three different customers. This can be 1055 illustrated as: 1057 submitted +-----+ 1058 traffic | A |--------> TCB1 1059 --->| B |--------> TCB2 1060 | C |--------> TCB3 1061 | X |--------> ActionElement4 (dropper) 1062 +-----+ 1063 TCB4 1065 Figure 5 - An Example Multi-Cusomer Front End TCB 1067 A formal representation of this multi-customer TCB might be: 1069 TCB1: 1071 Bernet, Smith, Blake expires December, 1999 20 1072 (as defined above) 1074 TCB2: 1075 (similar to TCB1, perhaps with different numeric parameters) 1077 TCB3: 1078 (similar to TCB1, perhaps with different numeric parameters) 1080 TCB4: 1082 Classifier2: 1083 Output A --> TCB1 1084 Output B --> TCB2 1085 Output C --> TCB3 1086 Output X --> ActionElement4 (dropper) 1088 Where Classifier2 is defined as follows: 1090 Classifier2: 1091 Filter1: output A 1092 Filter2: output B 1093 Filter3: output C 1094 No Match: output X 1096 and the filters, based on each customer's source MAC address are 1097 defined as follow: 1099 Filter1: 1100 Type: MacAddress 1101 SrcValue: 01-02-03-04-05-06 (source MAC address of customer 1) 1102 SrcMask: FF-FF-FF-FF-FF-FF 1103 DestValue: 00-00-00-00-00-00 1104 DestMask: 00-00-00-00-00-00 1106 Filter2: 1107 (similar to Filter1 but with customer 2's source MAC address as 1108 SrcValue) 1110 Filter3: 1111 (similar to Filter1 but with customer 3's source MAC address as 1112 SrcValue) 1114 In this example, TCB4 separates traffic submitted from different 1115 customers based on the source MAC address in submitted packets. 1116 Those packets with recognized source MAC addresses are passed to the 1117 TCB implementing the agreement with the corresponding customer. 1118 Those packets with unrecognized source MAC addresses are passed to a 1119 dropper. 1121 TCB4 has a classification stage and an action element stage (it is 1122 used only for unrecognized traffic) i.e. all actions are the default 1123 which is to pass through unchanged. Its outputs drive either the 1124 dropper action element or additional TCBs. 1126 Bernet, Smith, Blake expires December, 1999 21 1127 6.4 TCBs Supporting Microflow-based Services 1129 The TCB illustrated above describes a TC configuration that might be 1130 suitable for enforcing a SLA at a router's ingress. It assumes that 1131 the customer marks its own traffic for the appropriate service 1132 level. It then limits the rate of aggregate traffic submitted at 1133 each service level, thereby protecting the resources of the diffserv 1134 network. It does not mark the customer's packets, nor does it 1135 provide any isolation between the customer's individual microflows. 1137 Next we present a TC configuration that offers additional 1138 functionality to the customer. It recognizes individual customer 1139 microflows and marks each one independently. It also isolates the 1140 customer's individual microflows from each other in order to prevent 1141 a single microflow from seizing an unfair share of the resources 1142 available to the customer at a certain service level. This is 1143 illustrated in Figure 6 below: 1145 ------- ------- 1146 | | | |---------------> 1147 -->| |-->| | ------- 1148 ------- | | | | |---->| | 1149 | |---- ------- ------- ------- 1150 ->| |---- marker meter dropper 1151 | |-- | ------- ------- 1152 ------- | | | | | |---------------> 1153 MF | -->| |-->| | ------- 1154 class. | | | | |---->| | 1155 | ------- ------- ------- 1156 | marker meter dropper 1157 | ------- ------- 1158 | | | | |---------------> 1159 |--->| |-->| | ------- 1160 | | | | |---->| | 1161 | ------- ------- ------- 1162 | marker meter dropper 1163 | . . . 1164 V V V V 1166 Figure 6 - An Example of a Marking and Traffic Isolation TCB 1168 Traffic is first directed to an MF classifier which classifies 1169 traffic based on miscellaneous classification criteria, to a 1170 granularity sufficient to identify individual customer microflows. 1171 Each microflow can then be marked for a specific DSCP (in this 1172 particular example we assume that one of two different DSCPs is 1173 marked). The metering stage limits the contribution of each of the 1174 customer's microflows to the service level for which it was marked. 1175 Packets exceeding the allowable limit for the microflow are dropped. 1177 The TCB would be formally specified as follows: 1179 Bernet, Smith, Blake expires December, 1999 22 1180 TCB1: 1181 Classifier1: (MF) 1182 Output A --> Marker1 1183 Output B --> Marker2 1184 Output C --> Marker3 1185 . . . 1187 Marker1 --> Meter1 1188 Marker2 --> Meter2 1189 Marker3 --> Meter3 1191 Meter1: 1192 Output A --> TCB2 1193 Output B --> ActionElement1 (dropper) 1195 Meter2: 1196 Output A --> TCB2 1197 Output B --> ActionElement2 (dropper) 1199 Meter3: 1200 Output A --> TCB2 1201 Output B --> ActionElement3 (dropper) 1203 The actual traffic element declarations are not shown here. 1205 Traffic is either dropped by TCB1 or emerges marked for one of two 1206 DSCPs. This traffic is then passed to TCB2, illustrated below: 1208 ------- 1209 | |---------------> 1210 -->| | ------- 1211 ------- | | |---->| | 1212 | |---- ------- ------- 1213 ->| | meter dropper 1214 | |---| ------- 1215 ------- | | |---------------> 1216 BA -->| | ------- 1217 classifier | |---->| | 1218 ------- ------- 1219 meter dropper 1221 Figure 7 - Additional Example TCB 1223 TCB2 would be formally specified as follows: 1225 Classifier2: (BA) 1226 Output A --> Meter10 1227 Output B --> Meter11 1229 Meter10: 1230 Output A --> PHBQueueA 1231 Output B --> ActionElement10 (dropper) 1233 Bernet, Smith, Blake expires December, 1999 23 1234 Meter11: 1235 Output A --> PHBQueueB 1236 Output B --> ActionElement11 (dropper) 1238 7. Queuing Components 1240 Queuing components are the final conceptual components of the model 1241 of a diffserv router before packets leave a device. The queuing 1242 behaviours implemented on an egress interface are modeled as a set 1243 of inter-dependent queues that are serviced by a queuing algorithm 1244 with certain parameters and profiles. In particular, the scheduling 1245 parameters may be any of the Profile types defined for TC elements 1246 above e.g. SimpleTokenBucket, AverageRate, ExpWeightedMovingAvg. 1248 QueueSet1: 1249 Type: QueueSet 1250 MaxSustRate: 100 Mbps 1251 MinGuarRate: 20 Mbps 1252 Interface: ifIndex 1254 - guaranteed buffer pool for this queue set (?) 1256 QueueA: 1257 Type: Queue 1258 QueueSet: QueueSet1 1259 Profile: Profile1 1260 MinGuarRate: 2 Mbps 1261 QueueDepth: 200 kbytes 1262 Priority: 5 1264 QueueB: 1265 Type: Queue 1266 QueueSet: QueueSet1 1267 Profile: Profile2 1268 MinGuarRate: 2 Mbps 1269 QueueDepth: 200 kbytes 1270 Priority: 3 1272 - guaranteed buffer pool for each queue (?) 1274 1276 8. Monitoring 1278 Generally, it should be possible to retrieve the TCTs and similar 1279 tabular representations of the different diffserv router components. 1280 It should be possible to monitor the count of packets submitted to 1281 each TC element and the disposition of the packet (which of the 1282 element outputs it was directed to). 1284 Bernet, Smith, Blake expires December, 1999 24 1285 In the case of the installation in a router of packet filters that 1286 conflict, it must be possible to determine the relative precedence 1287 of the filters as implemented by the router. 1289 9. Initial State 1291 (TBD) 1293 1296 10. Security Considerations 1298 1300 11. References 1302 [DSARCH] Carson, M., Weiss, W., Blake, S., Wang, Z., Black, D., 1303 Davies, E., "An Architecture for Differentiated Services", RFC 2475, 1304 December 1998 1306 [DSFWK] Davies, E., Keshav, S., Verma, D., Carlson, M., Ohlman, B., 1307 Blake, S., Bernet, Y., Binder, J., Wang, Z., Weiss, W., "A Framework 1308 for Differentiated Services", Internet Draft, February 1999 1309 http://www.ietf.org/internet-drafts/draft-ietf-diffserv-framework- 1310 02.txt 1312 [E2E] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., 1313 Nichols, K., Speer, M., Braden, R., Davie, B., "Integrated Services 1314 Operation over Diffserv Networks", Internet Draft, June 1999, 1315 www.ietf.org/internet-drafts/draft-ietf-issll-diffserv-rsvp-02.txt 1317 [DSFIELD] Nichols, K., Blake, S., Baker, F. and D. Black, 1318 "Definition of the Differentiated Services Field (DS Field) in the 1319 IPv4 and IPv6 Headers", RFC 2474, December 1998. 1321 [EF-PHB] Jacobson, V., Nichols, K., and K. Poduri, "An Expedited 1322 Forwarding PHB", RFC 2598, June 1999. 1324 [AF-PHB] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski " 1325 Assured Forwarding PHB Group", RFC 2597, June 1999. 1327 [DSMIB] Baker, F., Pan, P., Guerin, R., Bernet, Y., "Differentiated 1328 Service Management Information Base using SMIv2", Internet Draft, 1329 June 1999. http://www.ietf.org/internet-drafts/draft-ietf-diffserv- 1330 mib-00.txt 1332 [SRTCM] Heinanen, J., Guerin, R., "A Single Rate Three Color 1333 Marker", Internet Draft, May 1999, www.ietf.org/internet- 1334 drafts/draft-heinanen-diffserv-srtcm-01.txt 1336 Bernet, Smith, Blake expires December, 1999 25 1338 [TRTCM] Heinanen, J., Guerin, R., "A Two Rate Three Color Marker", 1339 Internet Draft, May 1999, www.ietf.org/internet-drafts/heinanen- 1340 diffserv-trtcm-01.txt 1342 [GTC] Lin, L., Lo, J., Ou, F., "A Generic Traffic Conditioner", 1343 Internet Draft, April 1999, www.ietf.org/internet-drafts/draft-lin- 1344 diffserv-qtc-00.txt 1346 12. Author's Addresses 1348 Yoram Bernet 1349 Microsoft 1350 One Microsoft Way 1351 Redmond, WA 98052 1352 Phone: +1 425 936 9568 1353 E-mail: yoramb@microsoft.com 1355 Andrew Smith 1356 Extreme Networks 1357 3585 Monroe St. 1358 Santa Clara, CA 95051 1359 Phone: +1 408 579 2821 1360 E-mail: andrew@extremenetworks.com 1362 Steven Blake 1363 Ericsson Datacom 1364 3000 Aerial Center Parkway, Suite 140 1365 Morrisville, NC 27560 1366 Phone: 919-468-8466 x232 1367 E-mail: slblake@torrentnet.com 1369 Bernet, Smith, Blake expires December, 1999 26