Differentiated Services Y. Bernet Internet Draft Microsoft Expires December 1999 A. Smith draft-ietf-diffserv-model-00.txt Extreme Networks S. Blake Ericsson Datacom June 1999 A Conceptual Model for Diffserv Routers Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet- Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract This draft proposes a conceptual model for use in the management of Differentiated Services (diffserv) routers. We describe the fundamental packet classification principles that allow traffic streams to be differentiated. We describe the fundamental traffic conditioning elements that comprise the traffic conditioning functionality of diffserv routers. We describe the fundamental queue elements that comprise the Per-Hop Behaviour (PHB) functionality of diffserv routers. We propose a formal model for these. We also describe parameters and variables that may be used for monitoring the operation of the elements described above. There is no attempt made to define the packet forwarding behaviours of diffserv routers - these are well described elsewhere in the literature. Bernet, Smith, Blake expires December, 1999 1 draft-ietf-diffserv-model-00.txt June, 1999 This draft is preliminary and is known to be inconsistent in some respects with [DSMIB]. It is intended to correct this prior to the next version, as well as to verify full consistency with the published diffserv specifications [DSFIELD], [DSARCH], [AF-PHB], [EF-PHB]. 1. Introduction Differentiated Services (diffserv) [DSARCH, DSFWK] is a set of technologies by which network service providers can offer differing levels of network quality-of-service (QoS) to different customers and their traffic streams. The premise of diffserv networks is that routers within the networks handle packets in different traffic streams by applying different per-hop behaviours (PHBs) to the packet forwarding. The PHB to be applied is indicated by a diffserv code-point (DSCP) in the IP header of each packet [DSFIELD]. Note that this document uses the terminology of [DSFWK]. The advantage of such a scheme is that many traffic streams can be aggregated to one of a small number of behaviour aggregates (BA) which are each forwarded using the same PHB at the router, thereby simplifying the processing and associated storage. In addition, there is no signaling, other than what is carried in the DSCP of each packet, and no other related processing that is required in the diffserv network since QoS is invoked on a packet-by-packet basis. Although diffserv itself does not define the services that a diffserv network can provide, its successful deployment depends on the ability to use the technology to provide services. These services are reflected to customers at the edges of the diffserv network in the form of a Service Level Specification (SLS) [DSFWK]. The ability to provide these services depends on the availability of cohesive management tools that can be used to provision and monitor a set of diffserv routers in a coordinated manner. To facilitate the development of such management tools it is helpful to define a conceptual model of a diffserv router that abstracts implementation details of diffserv routers from the management tools used to manage them. The purpose of this draft is to define this conceptual model. The basic forwarding functionality of a diffserv router is defined by other specifications e.g. [DSARCH], [DSFIELD], [AF-PHB], [EF- PHB]. This document is not intended in any way to constrain or to dictate implementations of diffserv routers. We expect that router vendors will demonstrate a great deal of variability in their implementations. To the extent that vendors are able to model their implementations using the abstractions described in this draft, management tools will more readily be able to manage networks incorporating diffserv routers of various implementations. 2. Organization of this Document Bernet, Smith, Blake expires December, 1999 2 draft-ietf-diffserv-model-00.txt June, 1999 In Section 3 we start by describing the basic high-level functional blocks of a diffserv router and then providing a block diagram and describe the various components. We then focus on the diffserv- specific components of the router and describe a hierarchical management model for these. In Section 4 we describe classification elements and in section 5, we discuss the basic traffic conditioning elements. In Section 6, we show how the basic classification and traffic conditioning elements can be combined to build modules called Traffic Conditioning Blocks (TCBs). In Section 7, we discuss the basic queuing components. In Section 8, we discuss those parameters that it must be possible to monitor for the purposes of managing a diffserv router. 3. Elements of a Diffserv Router In this section we introduce a block diagram of a diffserv router and describe the various components illustrated. Note that the functions of a diffserv core router are likely to be a much simplified set of these components: the model we present here is intended to cover the case of a diffserv edge router as well as the core. 3.1 Conceptual Model The conceptual model we define includes abstract definitions of the following: 1. The basic traffic classification components. 2. The basic traffic conditioning components. 3. Certain combinations of traffic conditioning components. 4. Queuing components. The components and combinations of components described in this document form building blocks that need to be manageable by diffserv management tools. One of the goals of this document is to show how a model of a diffserv device can be built up out of these component blocks. This model is in the form of a connected acyclic directional graph that describes the traffic conditioning behaviour that any particular data packet will experience when submitted to the diffserv router. It is anticipated that these building blocks may also be used as the basis for a diffserv MIB or other such specific device configuration mechanisms. Bernet, Smith, Blake expires December, 1999 3 draft-ietf-diffserv-model-00.txt June, 1999 3.2 Block Diagram The following diagram illustrates the major functional blocks of a diffserv router: +--------------+ | diffserv | Mgmt | configuration| <------>| & monitoring |---------------- SNMP,| | interface | | COPS | +--------------+ | etc. | | | | | | | v v | +----------+ +-------+ +---------+ +-------+ data | |ingress | |routing| |egress | |queuing| ------->|-classif. |-->| |-->|-classif.|-->| stuff |--> | |-TCB | +-------+ |-TCB | +-------+ | +----------+ +---------+ | ^ ^ | | | | +----------+ | -->| | | ------->| RSVP |-------------------- RSVP |(optional)| cntl +----------+ msgs In this diagram, a Traffic Conditioning Block (TCB) represents a combination of metering, marking, shaping, dropping elements that are discussed in more detail below. 3.2.1 Interfaces, Classification, Traffic Conditioning, Queuing and the Routing Core An ingress interface, routing component and egress interface are illustrated at the center of the diagram. In actual router implementations, there may be an arbitrary number of inbound and outbound interfaces interconnected by the routing core. The components of interest on these interfaces are the traffic classifiers, the traffic conditioning components (TC) and the queuing components that support the Per-Hop Behaviour (PHB) [DSARCH]. These are the fundamental components comprising a diffserv router and will be the focal point of our conceptual model. 3.2.2 Diffserv Configuration and Monitoring Interface Diffserv operating parameters are monitored and provisioned through this interface. Monitored parameters include statistics regarding traffic carried at various diffserv service levels. These statistics are important for accounting purposes and for tracking compliance to service level agreements (SLAs [DSARCH]) negotiated with customers. Bernet, Smith, Blake expires December, 1999 4 draft-ietf-diffserv-model-00.txt June, 1999 Provisioned parameters are primarily classification rules, PHB and TC configuration parameters. The network administrator interacts with the diffserv configuration and monitoring interface via one or more management protocols, such as SNMP or COPS [COPS] or through other router configuration tools such as serial terminal or telnet consoles. 3.2.3 Optional RSVP Module Diffserv routers may snoop or participate in either per-microflow or per-flow-aggregate signaling of QoS requirements [E2E]. The example discussed here uses the RSVP protocol. Snooping of RSVP messages may be used, for example, to learn how to classify traffic without actually participating as a RSVP protocol peer. Diffserv routers may reject or admit RSVP reservation requests to provide a means of admission control to diffserv-based services or they may use these requests to trigger provisioning changes for a flow-aggregation in the diffserv network. A flow-aggregation in this context might be equivalent to a diffserv BA or it may be more fine-grained, relying on a MF classifier. Note that the conceptual model of such a router starts to look the same as a Integrated Services (intserv) router in its component makeup [E2E]. Note that a RSVP component of a diffserv router, if present, might be active only in the control plane and not in the data plane. In this scenario, RSVP is used strictly as a signaling protocol. The data plane of such a diffserv router can still act purely on diffserv DSCPs and PHBs in handling data traffic. 3.3 Hierarchical Model of Diffserv Components We focus on the diffserv specific functional components of the router, the traffic conditioning and queuing functionality. The example below is based on the larger block diagram shown above: Interface A Interface B +------------+ +-------+ +------------+ ------->| ingress |---->| |---->| egress |---> |(class.,TC) | | | |(queuing,TC)| +------------+ |routing| +------------+ | | +------------+ | | +------------+ <-------| egress |<----| |<----| ingress |<--- |(queuing,TC)| +-------+ |(class.,TC) | +------------+ +------------+ Figure 1 - Traffic Conditioning and Queuing This diagram illustrates two diffserv router interfaces, each having an ingress and an egress component. It shows classification and TC components on each interface's ingress and it shows both TC and PHB components on each interface's egress. From a management perspective, the following hierarchy exists: Bernet, Smith, Blake expires December, 1999 5 draft-ietf-diffserv-model-00.txt June, 1999 At the top level, the router manager manages interfaces. Each interface consists of an ingress component and an egress component. An ingress component contains TC components. An egress component contains PHB components and TC components. (There may be special cases in which a router implements PHB components on an ingress interface. This model is readily extensible to reflect such an implementation. However, we have chosen not to do so in this case.) The TC components on each interface are described by a traffic conditioning table (TCT) corresponding to the interface. The TCT describes traffic classification and conditioning elements and how they are combined to provide the interface's traffic conditioning functionality. Certain traffic conditioning elements may be grouped into traffic conditioning blocks (TCBs). PHB components contain queues and the enqueuing and dequeuing algorithms that serve them. Queues are each independently parameterized. There may also be parameters defining relationships between PHBs. 4. Classification Elements Classification is a necessary function for any device that treats certain traffic differently from other traffic. The very nature of a diffserv router is that it treats traffic differentially. Therefore, classification is the most basic function required from a differentiated service router. Classification is performed by a classifier. Classifiers take a single traffic stream as input and generate logically separate traffic streams as output. Packets from the input stream are sorted into various output streams depending on the contents of the packet and possibly on other sources of information e.g. input sub-channel number. The various types of classifiers are described in the following sections. 4.1 Behaviour Aggregate (BA) Classifier The simplest diffserv classifier is a behaviour aggregate (BA) classifier. A BA classifier uses only the diffserv codepoint (DSCP) in a packet's IP header to determine the logical output stream to which the packet should be directed. 4.2 Multi-Field (MF) Classifier Another type of classifier is a multi-field (MF) classifier. This classifies packets based on one or more fields in the packet header other than the DSCP. A common type of MF classifier is a 5-tuple classifier that classifies based on the five IP header fields of source/destination address, source/destination port and IP protocol number. MF classifiers may classify based on other fields such as Bernet, Smith, Blake expires December, 1999 6 draft-ietf-diffserv-model-00.txt June, 1999 MAC addresses, VLANs, link-layer traffic class or other higher layer protocol addresses. 4.3 Other Classifier Types Classification may be performed based on implicit information associated with a packet (e.g. the incoming channel number on a channelized interface) or on information derived from a different classification operation (e.g. the outgoing interface determined by the route lookup operation). We do not discuss these further here. 4.4 Filters Classifiers are parameterized by filters and output streams. For example, the following classifier separates traffic into one of three output streams based on two filters: Filter Matched Output Stream -------------- --------------- 1 A 2 B no match C Where filters 01 and 02 are defined to be the following BA filters: Filter DSCP ------ ------ 1 101010 2 111111 A filter consists of a set of conditions on the component values of a classification key. In the BA classifier example above, the classification key consists of one packet header field, the DSCP, and both Filter1 and Filter2 specify exact-match conditions on the value of the DSCP. The third filter is a wildcard default filter which matches every packet, but which is only selected in the event that no other more specific filter matches. In general there are a whole set of possible component conditions including exact, prefix, range, wildcard and masked matches. Note that ranges can be represented (maybe less efficiently) as a set of prefix matches and that prefix matches are just a special case of masked matches. In the case of a MF classifier, the classification key consists of a number of packet header fields. The filter may specify a different condition for each key component, as illustrated in the example below for a TCP/IPv4 classifier: Filter IP Src Addr IP Dest Addr TCP SrcPort TCP DestPort ------ ------------- ------------- ----------- ------------ Filter1 172.31.8.1/32 172.31.3.X/24 X 5003 Bernet, Smith, Blake expires December, 1999 7 draft-ietf-diffserv-model-00.txt June, 1999 In this example, the fourth octet of the destination IPv4 address and the source TCP port are 'don't cares'. 4.5 Diagram of a Classifier We use the following diagram to illustrate a classifier, where the outputs are to be plumbed in to succeeding TC elements: unclassified classified traffic traffic ----------- | |--> match Filter1 --> output A ----->|classifer|--> match Filter2 --> output B | |--> no match --> output C ----------- Figure 2 - An Example Classifier Note that an input interface number can also be considered as an input to the classifier if the classifier is modeled as accepting packets from multiple input ports - this optimisation may be important for scalability in the management plane. 4.6 Formal Representation of Classifiers 4.6.1 IPv4 5-tuple Classifier The following formal definition can be used to represent a classifier using masked match conditions: Classifier0: Filter1: output A Filter2: output B No Match: output C Filter1: Filter2: Type: IPv4 5-tuple Type: IPv4 5-tuple Ipv4SrcAddrValue: 172.31.8.0 Ipv4SrcAddrValue: 172.31.9.0 Ipv4DestAddrValue: 0 Ipv4DestAddrValue:0 Ipv4SrcPortValue: 0 Ipv4SrcPortValue: 0 Ipv4DestPortValue: 5003 Ipv4DestPortValue:5003 Ipv4ProtocolValue: 0 Ipv4ProtocolValue:0 Ipv4SrcAddrMask: 255.255.255.0 Ipv4SrcAddrMask: 255.255.255.0 Ipv4DestAddrMask: 0.0.0.0 Ipv4DestAddrMask: 0.0.0.0 Ipv4SrcPortMask: 0 Ipv4SrcPortMask: 0 Ipv4DestPortMask: 0xFFFF Ipv4DestPortMask: 0xFFFF Ipv4ProtocolMask: 0 Ipv4ProtocolMask: 0 4.6.2 IPv6 5-tuple Classifier Bernet, Smith, Blake expires December, 1999 8 draft-ietf-diffserv-model-00.txt June, 1999 The following formal definition can be used to represent a IPv6 multi-field classifier using masked match conditions: Classifier1: Filter3: output A No Match: output B Filter3: Type: IPv6 5-tuple Ipv6SrcAddrValue: 0:0:0:0:0:FFFF:32.12.65.0 Ipv6SrcAddrMask: FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:255.255.255.0 Ipv6DestAddrValue: 1080:0:0:0:0:0:0:0 Ipv6DestAddrMask: FFFF:FFFF:FFFF:FFFF:0:0:0:0 Ipv6SrcPortValue: 0 Ipv6SrcPortMask: 0 Ipv6DestPortValue: 5003 Ipv6DestPortMask: 0xFFFF Ipv6NextHeaderValue: 6 Ipv6NextHeaderMask: 0xFF 4.6.3 Behaviour Aggregate Classifier A BA classifier is parameterised by a set of 6-bit DSCP {value, mask} pairs: Classifier1: Filter3: output A Filter4: output B No Match: output C Filter3: Filter4: Type: BA Type: BA Value: 111000 Value: 110000 Mask: 111111 Mask: 111111 4.6.4 IEEE802 MAC Address Classifiers A MacAddress classifier is parameterised by a 6-byte {value, mask} pair for either source or destination MAC address.l for example, the following classifier sends packets matching either DA 01-02-03-04- 05-06 or SA 00-E0-2B-XX-XX-XX to output A: Classifier2: Filter5: output A Filter6: output A No Match: output B Filter5: Type: DestMacAddress Bernet, Smith, Blake expires December, 1999 9 draft-ietf-diffserv-model-00.txt June, 1999 Value: 01-02-03-04-05-06 (hex) Mask: FF-FF-FF-FF-FF-FF (hex) Filter6: Type: SrcMacAddress DestValue: 00-E0-2B-00-00-00 (hex) DestMask: FF-FF-FF-00-00-00 (hex) 4.6.5 Free-form Classifier A FreeForm classifier is made up of a set of user definable arbitrary filters each made up of {bit-field size, offset (from head of packet), mask}: Classifier3: Filter6: output A Filter7: output B No Match: output C Filter6: Type: FreeForm SizeBits: 3 bits Offset: 16 bytes Value: 100 (binary) Mask: 101 (binary) Filter7: Type: FreeForm SizeBits: 12 bits Offset: 16 bytes Value: 100100000000 (binary) Mask: 111111111111 (binary) 4.6.6 Other Standard Classifiers e.g. IEEE802.1p, IEEE802.1Q VLAN-ID Classifier4: Filter8: output A Filter9: output B No Match: output C Filter8: Type: IeeePriority Value: 100 (binary) Mask: 101 (binary) Filter9: Type: IeeeVlan Value: 100100000000 (binary) Mask: 111111111111 (binary) 4.6.7 Vendor-Specific Classifier Bernet, Smith, Blake expires December, 1999 10 draft-ietf-diffserv-model-00.txt June, 1999 Other vendor specific filter formats. 4.7 Combinations of Filters Filters may be logically combined. For example, consider the following DestMacAddress filter: Filter3: Type: DestMacAddress Value: 01-02-03-04-05-06 Mask: FF-FF-FF-FF-FF-FF Classifier0 could then be declared as: Classifier0: Filter1 and Filter3: output A Filter2 and Filter3: output B No Match: output C 4.7.1 Conflicting Filters Note that it is easy to define sets of conflicting filters in a classifier. For example: Filter1: Filter2: Type: BA Type: BA Value: 111000 Value: 000111 (binary) Mask: 111000 Mask: 000111 (binary) A packet containing the DSCP 111111 cannot be uniquely classified by this set of filters and so a precedence must be established between Filter1 and Filter2 in order to break the tie. This precedence must be established either (a) by a manager which knows that the router can accomplish this particular ordering e.g. by means of reported capabilities or (b) by the router along with a mechanism to report to a manager which precedence is being used. These ordering mechanisms must be supported by the management protocol although further discussion of this is outside the scope of this document. 5. Traffic-Conditioning Elements Traffic-conditioning is a essential function of a diff-serv router, defined in [DSARCH]. This section defines the elements that can be combined to provide the traffic-conditioning functionality described. These include meters and various action elements. 5.1 Meters Metering is the function of monitoring the arrival times of packets on a traffic stream and determining the level of conformance of each packet to a profile. Diffserv network providers may offer services to customers based on a temporal profile within which the customer Bernet, Smith, Blake expires December, 1999 11 draft-ietf-diffserv-model-00.txt June, 1999 submits traffic for the service. In this event, a meter might be used to trigger real-time effects (e.g. marking) downstream; it might also just be used for out-of-band management functions like statistics monitoring and billing applications. Meters are parameterized by a temporal profile and by conformance levels. 5.1.1 Types of Meters 5.1.1.1 Average Rate Meter An example of a very simple meter is an average rate meter. This type of meter measures the average rate at which packets are submitted to it over a specified averaging time. An average rate profile may take the following form: Average Rate: 10 packets per second Averaging Interval: 1 second A meter measuring against this profile would continually maintain a count that indicates the total number of packets arriving between time T (now) and time T-1 second. So long as an arriving packet does not push the count over 10, the packet would be deemed conforming. Any packet that pushes the count over 10, would be deemed non- conforming. Thus, this meter deems packets to correspond to one of two conformance levels - conforming or non-conforming. 5.1.1.2 Exponential Weighted Moving Average Meters The EWMA form of meter is easy to implement in silicon and can be parameterised as follows: avg(n+1) = (1-Gain) * avg(n) + Gain * actual(n+1) t(n+1) = t(n) + Delta For a packet arriving at time t(m): if (avg(m) > AverageRate) non-conforming else conforming Gain controls the time constant (e.g. frequency response) of what is essentially a simple IIR low-pass filter. actual(n) and avg(n) measure the number of incoming bytes in a small fixed sampling interval, Delta. Any packet that arrives and pushes the average rate over a predefined rate AverageRate is deemed non-conforming. 5.1.1.3 Token Bucket Meters Bernet, Smith, Blake expires December, 1999 12 draft-ietf-diffserv-model-00.txt June, 1999 A more sophisticated meter might measure conformance to a token bucket (TB) profile. A TB profile generally has three parameters, an average rate, a peak rate and a burst size. TB meters compare the arrival rate of packets to the average rate specified by the TB profile. Logically, byte tokens accumulate in a bucket at the average rate, up to a maximum credit which is the burst size. Packets of length L bytes are considered conforming if L tokens are available in the bucket at the time of packet arrival. Packets are allowed to exceed the average rate in bursts up to the burst size, so long as they do not exceed the peak rate, at which point the bucket will be drained. Packets which arrive to find a bucket with insufficient tokens in it are deemed non-conforming. More complicated token bucket models might define two burst sizes and three conformance levels. Packets found to exceed the larger burst size are deemed non-conforming. Packets found to exceed the smaller burst size are deemed partially conforming. Packets exceeding neither are deemed conforming. Token bucket meters designed for diff-serv networks are described in more detail in [SRTCM], [TRTCM] and [GTC]: in some of these references, three levels of conformance are discussed in terms of colors, with green representing conforming, yellow representing partially conforming and red representing non-conforming. 5.1.2 Diagram of a Meter We use the following diagram to illustrate a meter with 3 levels of conformance: unmetered metered traffic traffic ----------- | |--------> conformanceA --------->| meter |--------> conformanceB | |--------> conformanceC ----------- Figure 3 - An Example Meter In some diffserv examples, three levels of conformance are discussed in terms of colors, with green representing conforming, yellow representing partially conforming and red representing non- conforming. Other example meters use a binary notion of conformance; in the general case there are 'N' levels of conformance. 5.1.3 Formal Representations of Meters 5.1.3.1 Simple Token Bucket Meter The following formal definition can be used to represent this meter: Meter1: Bernet, Smith, Blake expires December, 1999 13 draft-ietf-diffserv-model-00.txt June, 1999 Type: SimpleTokenBucket Profile1: output A NonConforming: output B Profile1: Type: SimpleTokenBucket AverageRate: 100 Kbps PeakRate: 150 Kbps BurstSize 100 Kb 5.1.3.2 EWMA Meter Meter2: Type: ExpWeightedMovingAvg Profile2: output A NonConforming: output B Profile2: Type: ExpWeightedMovingAvg Gain: 1/16 Delta: 10us AverageRate: 200 Kbps 5.1.3.3 Two-level Token Bucket Meter Meter3: Type: TwoLevelTokenBucket Profile3: output A Profile4: output B NonConforming: output C Profile3: Type: SimpleTokenBucket AverageRate: 100 Kbps PeakRate: 150 Kbps BurstSize 50 Kb Profile4: Type: SimpleTokenBucket AverageRate: 120 Kbps PeakRate: 150 Kbps BurstSize 100 Kb 5.1.3.4 Average Rate Meter Meter4: Type: AverageRate Profile5: output A NonConforming: output B Profile5: Type: AverageRate AverageRate: 120 Kbps Bernet, Smith, Blake expires December, 1999 14 draft-ietf-diffserv-model-00.txt June, 1999 Delta: 100us 5.1.3.5 Other Vendor-specific Meters Other vendor specific meters are also possible. 5.2 Action Elements Classifiers and meters are generally used to determine the appropriate action to apply to a packet. The set of possible non- exclusive actions include: 1) Marking 2) Shaping 3) Dropping 4) Monitoring The corresponding action elements are described in the following paragraphs. Each of these actions has a default treatment which is to simply pass the packet on to a PHB queue. Policing is a general term for the action of preventing a traffic stream from seizing more than its share of resources from a diffserv network. Each of the three action elements described may be used to police traffic. Markers do so by re-marking submitted packets to a DSCP that is entitled to less network resources. Shapers and droppers do so by limiting the rate at which a particular traffic stream is submitted to the network. 5.2.1 Markers Markers set the DSCP in a packet header. Markers may act on unmarked packets (submitted with DSCP of zero) or may re-mark previously marked packets. In particular, the model supports the application of marking based on a preceding classifier match. The DSCP set in a packet will determine its subsequent treatment both by any following classifier elements within the same node or by other nodes downstream in the diffserv network. Markers are parameterized by a single parameter - the six-bit DSCP to be marked in packet headers. 5.2.1.1 Formal Representation of a Marker The following formal definition can be used to represent a marker: ActionElement1: Type: Marker Mark: 010010 5.2.2 Shapers Shapers are used to shape traffic to a certain temporal profile. For example, a shaper can be used to smooth traffic arriving in bursts. Bernet, Smith, Blake expires December, 1999 15 draft-ietf-diffserv-model-00.txt June, 1999 Shapers operate by delaying packets that would be deemed non- conforming to the shaper's profile. The packet is delayed until such time that it becomes conforming. Consider the average rate profile described previously. In the case that a burst of 11 packets was submitted simultaneously to a meter using the average rate profile, the 11th packet would be deemed non-conforming. In order to be deemed conforming, the packet would have to be delayed by one second. Thus, a shaper parameterized by the average rate profile (see section 5.1.1.1) would delay the 11th packet for one second. Shapers are parameterized by a single temporal profile e.g. a token bucket. Implicit in the definition of a shaper is a notion of a queue and a queue depth: in order to delay a packet, a shaper must have somewhere to store the packet and that storage area often has finite size. The queue is modeled here as a simple FIFO with a finite depth. Packets are dropped if the depth is exceeded - this is considered to be an error condition. 5.2.2.1 Uses of Shapers Shapers are often used to pre-condition traffic such that packets are not deemed non-conforming by subsequent meters, e.g. in downstream diffserv nodes. Shapers may also be used to isolate certain traffic streams from the effects of other traffic streams of the same BA. For example, consider the case of two traffic streams that are submitted to a diffserv network for a particular diffserv service level. The agreement between the customer and the diffserv network provider limits the rate of traffic that can be submitted at a certain service level. In this case, one of the two traffic streams may attempt to seize more than its fair share of the available capacity for the service level. By doing so, it compromises the other traffic stream. A shaper that acts independently on the two streams can be used to limit the effect of the rogue stream. Note also that a BA might be metered against one profile whilst being shaped to a different profile further downstream in the same device. 5.2.2.2 Formal Representation of a Shaper The following formal definition can be used to represent a shaper: ActionElement2: Type: Shaper Profile: Profile1 QueueDepth: size in bytes and/or packets Profile definitions are identical in format to those described under the formal definition of a meter. 5.2.3 Droppers Bernet, Smith, Blake expires December, 1999 16 draft-ietf-diffserv-model-00.txt June, 1999 Droppers simply discard packets. There are no parameters for droppers. 5.2.3.1 Formal Representation of a Dropper The following formal definition can be used to represent a dropper: ActionElement03: Type: Dropper 5.2.4 Monitoring One passive form of an action to be taken is simply to account for the fact that a data packet was processed. This might be used later on in presenting statistics for customer usage-based billing. Further discussion of instrumentation for monitoring is provided in section 0 although the topic of accounting is not dealt with in detail here. 6. Traffic Conditioning Blocks (TCBs) The classifiers and traffic conditioning elements described above can be combined into traffic conditioning blocks (TCBs). The TCB is an abstraction of a functional block that may be used to facilitate the definition of traffic conditioning functionality. A general TCB consists of three stages: 1. Classifier stage 2. Metering stage 3. Action stage TCBs are constructed by connecting elements corresponding to these stages in any order. It is allowable to omit stages or to concatenate multiple stages of the same type. TCB outputs may drive additional TCBs (on the same interface or on an egress interface) or alternatively, may be directed to a PHB queue on an egress interface. 6.1 Example TCB The following diagram illustrates an example TCB: Bernet, Smith, Blake expires December, 1999 17 draft-ietf-diffserv-model-00.txt June, 1999 -------------> to Queue A ------- | | |--- -->| | | | |--- ------- | ------- | | | | meter -->| |-----> discard | | | | ------- | dropper | | | -------------> to Queue B submitted ------- | ------- | ^ traffic | A |------- | |--- | --->| B |-------->| | | | C |------- | |--- ------- | | X |---- | ------- | | | | ------- | | meter -->| |--- BA | | | | classifier | | ------- | | shaper | | | | | | -------------> to Queue C | | ------- | | | | |--- | -->| | | | |--- ------- | ------- | | | | meter -->| |---> to Queue D | | | | ------- | re-marker | ----------------------------> to Queue E Figure 4 - An Example Traffic Conditioning Block This sample TCB might be suitable for an ingress interface at a customer/provider interface. A SLA is presumed to have been negotiated between the customer and the provider which specifies the handling of the customer's traffic by the provider's network. The agreement might be of the following form: DSCP PHB Profile Non-Conforming Packets ---- --- ------- ------------------------- 001001 PHB1 Profile1 Discarded 001100 PHB2 Profile2 Shaped to Profile1 001101 PHB3 Profile3 Re-marked to DSCP 001000 It is implicit in this agreement that conforming packets are given the PHB originally indicated by the packets' DSCP field. It Bernet, Smith, Blake expires December, 1999 18 draft-ietf-diffserv-model-00.txt June, 1999 specifies that the customer may submit packets marked for DSCP 001001 which will get PHB1 treatment so long as they remain conforming to Profile1 and will be discarded if they exceed this profile. Similar contract rules are applied for 001100 and 001101 traffic. In this example, the classification stage consists of a single BA classifier. The BA classifier is used to separate traffic based on the diffserv service level requested by the customer (as indicated by the DSCP in each submitted packet's IP header). We illustrate three DSCP filter values: A, B and C. The 'X' in the BA classifier indicates 'no match'. The metering stage is next. There is a separate meter for each set of packets corresponding to DSCPs A, B and C. Each meter uses a specific profile as specified in the SLA for the corresponding diffserv service level. The meters in this example indicate one of two conforming levels, conforming or non-conforming. Following the metering stage is the action stage. Packets submitted for DSCP A that are deemed non-conforming are discarded. Packets that are conforming are passed on to the queue for the corresponding PHB. Packets submitted for DSCP B that are deemed non-conforming are delayed in a shaper until they become conforming. Packets that are deemed conforming are allowed to pass directly to the queue for PHB B. Note that in actual implementations, non-conforming packets will cause packets on the same traffic stream that are conforming to be delayed in order to maintain per-stream packet ordering. However, this is an implementation detail and need not be considered from the abstract management perspective. Packets submitted for DSCP C and deemed non-conforming are re-marked for a less privileged DSCP and are directed to the appropriate PHB queue. Packets that are deemed conforming are passed directly to the requested PHB queue. 6.2 Formal Representation of TCB The following is a formal representation of the interconnection of the components of the TCB illustrated in Error! Reference source not found.: TCB1: Classifier1: Output A --> Meter1 Output B --> Meter2 Output C --> Meter3 Output X --> QueueE Bernet, Smith, Blake expires December, 1999 19 draft-ietf-diffserv-model-00.txt June, 1999 Meter1: Output A --> QueueA Output B --> ActionElement1 (dropper) Meter2: Output A --> QueueB Output B --> ActionElement2 (shaper) ActionElement2: DefaultOutput --> QueueB Meter3: Output A --> QueueC Output B --> ActionElement3 (marker) ActionElement3: DefaultOutput --> QueueD 6.3 Example TCB to Support Multiple Customers The TCB described above can be installed on an ingress interface to implement a provider/customer agreement if the interface is dedicated to the customer. However, if a single interface is shared between multiple customers, then the TCB above will not suffice, since it does not differentiate among traffic from different customers. Its classification stage uses BA classifiers only. The TCB is readily extended to support the case of multiple customers per interface, as follows. First, we define a TCB for each customer to reflect the agreement with that customer. TCB1, defined above is the TCB for customer 1. We add definitions for TCB2 and for TCB3 which reflect the agreements with customers 2 and 3 respectively. Finally, we add a fourth TCB, TCB4, which provides a front end to separate the traffic from the three different customers. This can be illustrated as: submitted +-----+ traffic | A |--------> TCB1 --->| B |--------> TCB2 | C |--------> TCB3 | X |--------> ActionElement4 (dropper) +-----+ TCB4 Figure 5 - An Example Multi-Cusomer Front End TCB A formal representation of this multi-customer TCB might be: TCB1: Bernet, Smith, Blake expires December, 1999 20 draft-ietf-diffserv-model-00.txt June, 1999 (as defined above) TCB2: (similar to TCB1, perhaps with different numeric parameters) TCB3: (similar to TCB1, perhaps with different numeric parameters) TCB4: Classifier2: Output A --> TCB1 Output B --> TCB2 Output C --> TCB3 Output X --> ActionElement4 (dropper) Where Classifier2 is defined as follows: Classifier2: Filter1: output A Filter2: output B Filter3: output C No Match: output X and the filters, based on each customer's source MAC address are defined as follow: Filter1: Type: MacAddress SrcValue: 01-02-03-04-05-06 (source MAC address of customer 1) SrcMask: FF-FF-FF-FF-FF-FF DestValue: 00-00-00-00-00-00 DestMask: 00-00-00-00-00-00 Filter2: (similar to Filter1 but with customer 2's source MAC address as SrcValue) Filter3: (similar to Filter1 but with customer 3's source MAC address as SrcValue) In this example, TCB4 separates traffic submitted from different customers based on the source MAC address in submitted packets. Those packets with recognized source MAC addresses are passed to the TCB implementing the agreement with the corresponding customer. Those packets with unrecognized source MAC addresses are passed to a dropper. TCB4 has a classification stage and an action element stage (it is used only for unrecognized traffic) i.e. all actions are the default which is to pass through unchanged. Its outputs drive either the dropper action element or additional TCBs. Bernet, Smith, Blake expires December, 1999 21 draft-ietf-diffserv-model-00.txt June, 1999 6.4 TCBs Supporting Microflow-based Services The TCB illustrated above describes a TC configuration that might be suitable for enforcing a SLA at a router's ingress. It assumes that the customer marks its own traffic for the appropriate service level. It then limits the rate of aggregate traffic submitted at each service level, thereby protecting the resources of the diffserv network. It does not mark the customer's packets, nor does it provide any isolation between the customer's individual microflows. Next we present a TC configuration that offers additional functionality to the customer. It recognizes individual customer microflows and marks each one independently. It also isolates the customer's individual microflows from each other in order to prevent a single microflow from seizing an unfair share of the resources available to the customer at a certain service level. This is illustrated in Figure 6 below: ------- ------- | | | |---------------> -->| |-->| | ------- ------- | | | | |---->| | | |---- ------- ------- ------- ->| |---- marker meter dropper | |-- | ------- ------- ------- | | | | | |---------------> MF | -->| |-->| | ------- class. | | | | |---->| | | ------- ------- ------- | marker meter dropper | ------- ------- | | | | |---------------> |--->| |-->| | ------- | | | | |---->| | | ------- ------- ------- | marker meter dropper | . . . V V V V Figure 6 - An Example of a Marking and Traffic Isolation TCB Traffic is first directed to an MF classifier which classifies traffic based on miscellaneous classification criteria, to a granularity sufficient to identify individual customer microflows. Each microflow can then be marked for a specific DSCP (in this particular example we assume that one of two different DSCPs is marked). The metering stage limits the contribution of each of the customer's microflows to the service level for which it was marked. Packets exceeding the allowable limit for the microflow are dropped. The TCB would be formally specified as follows: Bernet, Smith, Blake expires December, 1999 22 draft-ietf-diffserv-model-00.txt June, 1999 TCB1: Classifier1: (MF) Output A --> Marker1 Output B --> Marker2 Output C --> Marker3 . . . Marker1 --> Meter1 Marker2 --> Meter2 Marker3 --> Meter3 Meter1: Output A --> TCB2 Output B --> ActionElement1 (dropper) Meter2: Output A --> TCB2 Output B --> ActionElement2 (dropper) Meter3: Output A --> TCB2 Output B --> ActionElement3 (dropper) The actual traffic element declarations are not shown here. Traffic is either dropped by TCB1 or emerges marked for one of two DSCPs. This traffic is then passed to TCB2, illustrated below: ------- | |---------------> -->| | ------- ------- | | |---->| | | |---- ------- ------- ->| | meter dropper | |---| ------- ------- | | |---------------> BA -->| | ------- classifier | |---->| | ------- ------- meter dropper Figure 7 - Additional Example TCB TCB2 would be formally specified as follows: Classifier2: (BA) Output A --> Meter10 Output B --> Meter11 Meter10: Output A --> PHBQueueA Output B --> ActionElement10 (dropper) Bernet, Smith, Blake expires December, 1999 23 draft-ietf-diffserv-model-00.txt June, 1999 Meter11: Output A --> PHBQueueB Output B --> ActionElement11 (dropper) 7. Queuing Components Queuing components are the final conceptual components of the model of a diffserv router before packets leave a device. The queuing behaviours implemented on an egress interface are modeled as a set of inter-dependent queues that are serviced by a queuing algorithm with certain parameters and profiles. In particular, the scheduling parameters may be any of the Profile types defined for TC elements above e.g. SimpleTokenBucket, AverageRate, ExpWeightedMovingAvg. QueueSet1: Type: QueueSet MaxSustRate: 100 Mbps MinGuarRate: 20 Mbps Interface: ifIndex - guaranteed buffer pool for this queue set (?) QueueA: Type: Queue QueueSet: QueueSet1 Profile: Profile1 MinGuarRate: 2 Mbps QueueDepth: 200 kbytes Priority: 5 QueueB: Type: Queue QueueSet: QueueSet1 Profile: Profile2 MinGuarRate: 2 Mbps QueueDepth: 200 kbytes Priority: 3 - guaranteed buffer pool for each queue (?) 8. Monitoring Generally, it should be possible to retrieve the TCTs and similar tabular representations of the different diffserv router components. It should be possible to monitor the count of packets submitted to each TC element and the disposition of the packet (which of the element outputs it was directed to). Bernet, Smith, Blake expires December, 1999 24 draft-ietf-diffserv-model-00.txt June, 1999 In the case of the installation in a router of packet filters that conflict, it must be possible to determine the relative precedence of the filters as implemented by the router. 9. Initial State (TBD) 10. Security Considerations 11. References [DSARCH] Carson, M., Weiss, W., Blake, S., Wang, Z., Black, D., Davies, E., "An Architecture for Differentiated Services", RFC 2475, December 1998 [DSFWK] Davies, E., Keshav, S., Verma, D., Carlson, M., Ohlman, B., Blake, S., Bernet, Y., Binder, J., Wang, Z., Weiss, W., "A Framework for Differentiated Services", Internet Draft, February 1999 http://www.ietf.org/internet-drafts/draft-ietf-diffserv-framework- 02.txt [E2E] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., Nichols, K., Speer, M., Braden, R., Davie, B., "Integrated Services Operation over Diffserv Networks", Internet Draft, June 1999, www.ietf.org/internet-drafts/draft-ietf-issll-diffserv-rsvp-02.txt [DSFIELD] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [EF-PHB] Jacobson, V., Nichols, K., and K. Poduri, "An Expedited Forwarding PHB", RFC 2598, June 1999. [AF-PHB] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski " Assured Forwarding PHB Group", RFC 2597, June 1999. [DSMIB] Baker, F., Pan, P., Guerin, R., Bernet, Y., "Differentiated Service Management Information Base using SMIv2", Internet Draft, June 1999. http://www.ietf.org/internet-drafts/draft-ietf-diffserv- mib-00.txt [SRTCM] Heinanen, J., Guerin, R., "A Single Rate Three Color Marker", Internet Draft, May 1999, www.ietf.org/internet- drafts/draft-heinanen-diffserv-srtcm-01.txt Bernet, Smith, Blake expires December, 1999 25 draft-ietf-diffserv-model-00.txt June, 1999 [TRTCM] Heinanen, J., Guerin, R., "A Two Rate Three Color Marker", Internet Draft, May 1999, www.ietf.org/internet-drafts/heinanen- diffserv-trtcm-01.txt [GTC] Lin, L., Lo, J., Ou, F., "A Generic Traffic Conditioner", Internet Draft, April 1999, www.ietf.org/internet-drafts/draft-lin- diffserv-qtc-00.txt 12. Author's Addresses Yoram Bernet Microsoft One Microsoft Way Redmond, WA 98052 Phone: +1 425 936 9568 E-mail: yoramb@microsoft.com Andrew Smith Extreme Networks 3585 Monroe St. Santa Clara, CA 95051 Phone: +1 408 579 2821 E-mail: andrew@extremenetworks.com Steven Blake Ericsson Datacom 3000 Aerial Center Parkway, Suite 140 Morrisville, NC 27560 Phone: 919-468-8466 x232 E-mail: slblake@torrentnet.com Bernet, Smith, Blake expires December, 1999 26