Network Working Group K. Nichols
`Request for Comments: 2638 V. Jacobson
`Category: Informational Cisco
` L. Zhang
` UCLA
` July 1999
`
` A Two-bit Differentiated Services Architecture for the Internet
`
`Status of this Memo
`
` This memo provides information for the Internet community. It does
` not specify an Internet standard of any kind. Distribution of this
` memo is unlimited.
`
`Copyright Notice
`
` Copyright (C) The Internet Society (1999). All Rights Reserved.
`
`Abstract
`
` This document was originally submitted as an internet draft in
` November of 1997. As one of the documents predating the formation of
` the IETF’s Differentiated Services Working Group, many of the ideas
` presented here, in concert with Dave Clark’s subsequent presentation
` to the December 1997 meeting of the IETF Integrated Services Working
` Group, were key to the work which led to RFCs 2474 and 2475 and the
` section on allocation remains a timely proposal. For this reason, and
` to provide a reference, it is being submitted in its original form.
` The forwarding path portion of this document is intended as a record
` of where we were at in late 1997 and not as an indication of future
` direction.
`
` The postscript version of this document includes Clark’s slides as an
` appendix. The postscript version of this document also includes many
` figures that aid greatly in its readability.
`
`1. Introduction
`
` This document presents a differentiated services architecture for the
` internet. Dave Clark and Van Jacobson each presented work on
` differentiated services at the Munich IETF meeting [2,3]. Each
` explained how to use one bit of the IP header to deliver a new kind
` of service to packets in the internet. These were two very different
` kinds of service with quite different policy assumptions. Ensuing
` discussion has convinced us that both service types have merit and
` that both service types can be implemented with a set of very similar
`
`Nichols, et al. Informational [Page 1]
`
`Arista Networks, Inc.
`Ex. 1024, p. 1
`
`

`

`RFC 2638 Two-bit Differentiated Services Architecture July 1999
`
` mechanisms. We propose an architectural framework that permits the
` use of both of these service types and exploits their similarities in
` forwarding path mechanisms. The major goals of this architecture are
` each shared with one or both of those two proposals: keep the
` forwarding path simple, push complexity to the edges of the network
` to the extent possible, provide a service that avoids assumptions
` about the type of traffic using it, employ an allocation policy that
` will be compatible with both long-term and short-term provisioning,
` make it possible for the dominant Internet traffic model to remain
` best-effort.
`
` The major contributions of this document are to present two distinct
` service types, a set of general mechanisms for the forwarding path
` that can be used to implement a range of differentiated services and
` to propose a flexible framework for provisioning a differentiated
` services network. It is precisely this kind of architecture that is
` needed for expedient deployment of differentiated services: we need a
` framework and set of primitives that can be implemented in the
` short-term and provide interoperable services, yet can provide a
` "sandbox" for experimentation and elaboration that can lead in time
` to more levels of differentiation within each service as needed.
`
` At the risk of belaboring an analogy, we are motivated to provide
` services tiers in somewhat the same fashion as the airlines do with
` first class, business class and coach class. The latter also has
` tiering built in due to the various restrictions put on the purchase.
` A part of the analogy we want to stress is that best effort traffic,
` like coach class seats on an airplane, is still expected to make up
` the bulk of internet traffic. Business and first class carry a small
` number of passengers, but are quite important to the economics of the
` airline industry. The various economic forces and realities combine
` to dictate the relative allocation of the seats and to try to fill
` the airplane. We don’t expect that differentiated services will
` comprise all the traffic on the internet, but we do expect that new
` services will lead to a healthy economic and service environment.
`
` This document is organized into sections describing service
` architecture, mechanisms, the bandwidth allocation architecture, how
` this architecture might interoperate with RSVP/int-serv work, and
` gives recommendations for deployment.
`
`Nichols, et al. Informational [Page 2]
`
`Arista Networks, Inc.
`Ex. 1024, p. 2
`
`

`

`RFC 2638 Two-bit Differentiated Services Architecture July 1999
`
`2. Architecture
`
`2.1 Background
`
` The current internet delivers one type of service, best-effort, to
` all traffic. A number of proposals have been made concerning the
` addition of enhanced services to the Internet. We focus on two
` particular methods of adding a differentiated level of service to IP,
` each designated by one bit [1,2,3]. These services represent a
` radical departure from the Internet’s traditional service, but they
` are also a radical departure from traditional "quality of service"
` architectures which rely on circuit-based models. Both these
` proposals seek to define a single common mechanism that is used by
` interior network routers, pushing most of the complexity and state of
` differentiated services to the network edges. Both use bandwidth as
` the resource that is being requested and allocated. Clark and
` Wroclawski defined an "Assured" service that follows "expected
` capacity" usage profiles that are statistically provisioned [3]. The
` assurance that the user of such a service receives is that such
` traffic is unlikely to be dropped as long as it stays within the
` expected capacity profile. The exact meaning of "unlikely" depends on
` how well provisioned the service is. An Assured service traffic flow
` may exceed its Profile, but the excess traffic is not given the same
` assurance level. Jacobson defined a "Premium" service that is
` provisioned according to peak capacity Profiles that are strictly not
` oversubscribed and that is given its own high-priority queue in
` routers [2]. A Premium service traffic flow is shaped and hard-
` limited to its provisioned peak rate and shaped so that bursts are
` not injected into the network. Premium service presents a "virtual
` wire" where a flow’s bursts may queue at the shaper at the edge of
` the network, but thereafter only in proportion to the indegree of
` each router. Despite their many similarities, these two approaches
` result in fundamentally different services. The former uses buffer
` management to provide a "better effort" service while the latter
` creates a service with little jitter and queueing delay and no need
` for queue management on the Premium packets’s queue.
`
` An Assured service was introduced in [3] by Clark and Wroclawski,
` though we have made some alterations in its specification for our
` architecture. Further refinements and an "Expected Capacity"
` framework are given in Clark and Fang [10]. This framework is
` focused on "providing different levels of best-effort service at
` times of network congestion" but also mentions that it is possible to
` have a separate router queue to implement a "guaranteed" level of
` assurance. We believe this framework and our Two-bit architecture
` are compatible but this needs further exploration. As Premium
` service has not been documented elsewhere, we describe it next and
` follow this with a description of the two-bit architecture.
`
`Nichols, et al. Informational [Page 3]
`
`Arista Networks, Inc.
`Ex. 1024, p. 3
`
`

`

`RFC 2638 Two-bit Differentiated Services Architecture July 1999
`
`2.2 Premium service
`
` In [2], a Premium service was presented that is fundamentally
` different from the Internet’s current best effort service. This
` service is not meant to replace best effort but primarily to meet an
` emerging demand for a commercial service that can share the network
` with best effort traffic. This is desirable economically, since the
` same network can be used for both kinds of traffic. It is expected
` that Premium traffic would be allocated a small percentage of the
` total network capacity, but that it would be priced much higher. One
` use of such a service might be to create "virtual leased lines",
` saving the cost of building and maintaining a separate network.
` Premium service, not unlike a standard telephone line, is a capacity
` which the customer expects to be there when the receiver is lifted,
` although it may, depending on the household, be idle a good deal of
` the time. Provisioning Premium traffic in this way reduces the
` capacity of the best effort internet by the amount of Premium
` allocated, in the worst case, thus it would have to be priced
` accordingly. On the other hand, whenever that capacity is not being
` used it is available to best effort traffic. In contrast to normal
` best effort traffic which is bursty and requires queue management to
` deal fairly with congestive episodes, this Premium service by design
` creates very regular traffic patterns and small or nonexistent
` queues.
`
` Premium service levels are specified as a desired peak bit-rate for a
` specific flow (or aggregation of flows). The user contract with the
` network is not to exceed the peak rate. The network contract is that
` the contracted bandwidth will be available when traffic is sent.
` First-hop routers (or other edge devices) filter the packets entering
` the network, set the Premium bit of those that match a Premium
` service specification, and perform traffic shaping on the flow that
` smooths all traffic bursts before they enter the network. This
` approach requires no changes in hosts. A compliant router along the
` path needs two levels of priority queueing, sending all packets with
` the Premium bit set first. Best-effort traffic is unmarked and queued
` and sent at the lower priority. This results in two "virtual
` networks": one which is identical to today’s Internet with buffers
` designed to absorb traffic bursts; and one where traffic is limited
` and shaped to a contracted peak-rate, but packets move through a
` network of queues where they experience almost no queueing delay.
`
` In this architecture, forwarding path decisions are made separately
` and more simply than the setting up of the service agreements and
` traffic profiles. With the exception of policing and shaping at
` administrative or "trust" boundaries, the only actions that need to
` be handled in the forwarding path are to classify a packet into one
` of two queues on a single bit and to service the two queues using
`
`Nichols, et al. Informational [Page 4]
`
`Arista Networks, Inc.
`Ex. 1024, p. 4
`
`

`

`RFC 2638 Two-bit Differentiated Services Architecture July 1999
`
` simple priority. Shaping must include both rate and burst parameters;
` the latter is expected to be small, in the one or two packet range.
` Policing at boundaries enforces rate compliance, and may be
` implemented by a simple token bucket. The admission and set-up
` procedures are expected to evolve, in time, to be dynamically
` configurable and fairly complex while the mechanisms in the
` forwarding path remain simple.
`
` A Premium service built on this architecture can be deployed in a
` useful way once the forwarding path mechanisms are in place by making
` static allocations. Traffic flows can be designated for special
` treatment through network management configuration. Traffic flows
` should be designated by the source, the destination, or any
` combination of fields in the packet header. First-hop (of leaf)
` routers will filter flows on all or part of the header tuple
` consisting of the source IP address, destination IP address, protocol
` identifier, source port number, and destination port number. Based on
` this classification, a first-hop router performs traffic shaping and
` sets the designated Premium bit of the precedence field. End-hosts
` are thus not required to be "differentiated services aware", though
` if and when end-systems become universally "aware", they might do
` their own shaping and first-hop routers merely police.
`
` Adherence to the subscribed rate and burst size must be enforced at
` the entry to the network, either by the end-system or by the first-
` hop router. Within an intranet, administrative domain, or "trust
` region" the packets can then be classified and serviced solely on the
` Premium bit. Where packets cross a boundary, the policing function is
` critical. The entered region will check the prioritized packet flow
` for conformance to a rate the two regions have agreed upon,
` discarding packets that exceed the rate. It is thus in the best
` interests of a region to ensure conformance to the agreed-upon rate
` at the egress. This requirement means that Premium traffic is burst-
` free and, together with the no oversubscription rule, leads directly
` to the observation that Premium queues can easily be sized to prevent
` the need to drop packets and thus the need for a queue management
` policy. At each router, the largest queue size is related to the in-
` degree of other routers and is thus quite small, on the order of ten
` packets.
`
` Premium bandwidth allocations must not be oversubscribed as they
` represent a commitment by the network and should be priced
` accordingly. Note that, in this architecture, Premium traffic will
` also experience considerably less delay variation than either best
` effort traffic or the Assured data traffic of [3]. Premium rates
` might be configured on a subscription basis in the near-term, or on-
` demand when dynamic set-up or signaling is available.
`
`Nichols, et al. Informational [Page 5]
`
`Arista Networks, Inc.
`Ex. 1024, p. 5
`
`

`

`RFC 2638 Two-bit Differentiated Services Architecture July 1999
`
` Figure 1 shows how a Premium packet flow is established within a
` particular administrative domain, Company A, and sent across the
` access link to Company A’s ISP. Assume that the host’s first-hop
` router has been configured to match a flow from the host’s IP address
` to a destination IP address that is reached through ISP. A Premium
` flow is configured from a host with a rate which is both smaller than
` the total Premium allocation Company A has from the ISP, r bytes per
` second, and smaller than the amount of that allocation has been
` assigned to other hosts in Company A. Packets are not marked in any
` special way when they leave the host. The first-hop router clears the
` Premium bit on all arriving packets, sets the Premium bit on all
` packets in the designated flow, shapes packets in the Premium flow to
` a configured rate and burst size, queues best-effort unmarked packets
` in the low priority queue and shaped Premium packets in the high
` priority queue, and sends packets from those two queues at simple
` priority. Intermediate routers internal to Company A enqueue packets
` in one of two output queues based on the Premium bit and service the
` queues with simple priority. Border routers perform quite different
` tasks, depending on whether they are processing an egress flow or an
` ingress flow. An egress border router may perform some reshaping on
` the aggregate Premium traffic to conform to rate r, depending on the
` number of Premium flows aggregated. Ingress border routers only need
` to perform a simple policing function that can be implemented with a
` token bucket. In the example, the ISP accepts all Premium packets
` from A as long as the flow does not exceed r bytes per second.
`
` Figure 1. Premium traffic flow from end-host to organization’s ISP
`
`2.3 Two-bit differentiated services architecture
`
` Clark’s and Jacobson’s proposals are markedly similar in the location
` and type of functional blocks that are needed to implement them.
` Furthermore, they implement quite different services which are not
` incompatible in a network. The Premium service implements a
` guaranteed peak bandwidth service with negligible queueing delay that
` cannot starve best effort traffic and can be allocated in a fairly
` straightforward fashion. This service would seem to have a strong
` appeal for commercial applications, video broadcasts, voice-over-IP,
` and VPNs. On the other hand, this service may prove both too
` restrictive (in its hard limits) and overdesigned (no overallocation)
` for some applications. The Assured service implements a service that
` has the same delay characteristics as (undropped) best effort packets
` and the firmness of its guarantee depends on how well individual
` links are provisioned for bursts of Assured packets. On the other
` hand, it permits traffic flows to use any additional available
` capacity without penalty and occasional dropped packets for short
` congestive periods may be acceptable to many users. This service
` might be what an ISP would provide to individual customers who are
`
`Nichols, et al. Informational [Page 6]
`
`Arista Networks, Inc.
`Ex. 1024, p. 6
`
`

`

`RFC 2638 Two-bit Differentiated Services Architecture July 1999
`
` willing to pay a bit more for internet service that seems unaffected
` by congestive periods. Both services are only as good as their
` admission control schemes, though this can be more difficult for
` traffic which is not peak-rate allocated.
`
` There may be some additional benefits of deploying both services. To
` the extent that Premium service is a conservative allocation of
` resources, unused bandwidth that had been allocated to Premium might
` provide some "headroom" for underallocated or burst periods of
` Assured traffic or for best effort. Network elements that deploy both
` services will be performing RED queue management on all non-Premium
` traffic, as suggested in [4], and the effects of mixing the Premium
` streams with best effort might serve to reduce burstiness in the
` latter. A strength of the Assured service is that it allows bursts to
` happen in their natural fashion, but this also makes the
` provisioning, admission control and allocation problem more difficult
` so it may take more time and experimentation before this admission
` policy for this service is completely defined. A Premium service
` could be deployed that employs static allocations on peak rates with
` no statistical sharing.
`
` As there appear to be a number of advantages to an architecture that
` permits these two types of service and because, as we shall see, they
` can be made to share many of the same mechanisms, we propose
` designating two bit-patterns from the IP header precedence field. We
` leave the explicit designation of these bit-patterns to the standards
` process thus we use the shorthand notation of denoting each pattern
` by a bit, one we will call the Premium or P-bit, the other we call
` the assurance or A-bit. It is possible for a network to implement
` only one of these services and to have network elements that only
` look at the one applicable bit, but we focus on the two service
` architecture. Further, we assume the case where no changes are made
` in the hosts, appropriate packet marking all being done in the
` network, at the first-hop, or leaf, router. We describe the
` forwarding path architecture in this section, assuming that the
` service has been allocated through mechanisms we will discuss in
` section 4.
`
` In a more general sense, Premium service denotes packets that are
` enqueued at a higher priority than the ordinary best-effort queue.
` Similarly, Assured service denotes packets that are treated
` preferentially with respect to the dropping probability within the
` "normal" queue. There are a number of ways to add more service levels
` within each of these service types [7], but this document takes the
` position of specifying the base-level services of Premium and
` Assured.
`
`Nichols, et al. Informational [Page 7]
`
`Arista Networks, Inc.
`Ex. 1024, p. 7
`
`

`

`RFC 2638 Two-bit Differentiated Services Architecture July 1999
`
` The forwarding path mechanisms can be broken down into those that
` happen at the input interface, before packet forwarding, and those
` that happen at the output interface, after packet forwarding.
` Intermediate routers only need to implement the post packet
` forwarding functions, while leaf and border routers must perform
` functions on arriving packets before forwarding. We describe the
` mechanisms this way for illustration; other ways of composing their
` functions are possible.
`
` Leaf routers are configured with a traffic profile for a particular
` flow based on its packet header. This functionality has been defined
` by the RSVP Working Group in RFC 2205. Figure 2 shows what happens to
` a packet that arrives at the leaf router, before it is passed to the
` forwarding engine. All arriving packets must have both the A-bit and
` the P-bit cleared after which packets are classified on their header.
` If the header does not match any configured values, it is immediately
` forwarded. Matched flows pass through individual Markers that have
` been configured from the usage profile for that flow: service class
` (Premium or Assured), rate (peak for Premium, "expected" for
` Assured), and permissible burst size (may be optional for Premium).
` Assured flow packets emerge from the Marker with their A-bits set
` when the flow is in conformance to its Profile, but the flow is
` otherwise unchanged. For a Premium flow, the Marker will hold packets
` when necessary to enforce their configured rate. Thus Premium flow
` packets emerge from the Marker in a shaped flow with their P-bits
` set. (It is possible for Premium flow packets to be dropped inside of
` the Marker as we describe below.) Packets are passed to the
` forwarding engine when they emerge from Markers. Packets that have
` either their P or A bits set we will refer to as Marked packets.
`
` Figure 2. Block diagram of leaf router input functionality
`
` Figure 3 shows the inner workings of the Marker. For both Assured and
` Premium packets, a token bucket "fills" at the flow rate that was
` specified in the usage profile. For Assured service, the token bucket
` depth is set by the Profile’s burst size. For Premium service, the
` token bucket depth must be limited to the equivalent of only one or
` two packets. (We suggest a depth of one packet in early deployments.)
` When a token is present, Assured flow packets have their A-bit set to
` one, otherwise the packet is passed to the forwarding engine. For
` Premium-configured Marker, arriving packets that see a token present
` have their P-bits set and are forwarded, but when no token is
` present, Premium flow packets are held until a token arrives. If a
` Premium flow bursts enough to overflow the holding queue, its packets
` will be dropped. Though the flow set up data can be used to configure
` a size limit for the holding queue (this would be the meaning of a
` "burst" in Premium service), it is not necessary. Unconfigured
` holding queues should be capable of holding at least two bandwidth-
`
`Nichols, et al. Informational [Page 8]
`
`Arista Networks, Inc.
`Ex. 1024, p. 8
`
`

`

`RFC 2638 Two-bit Differentiated Services Architecture July 1999
`
` delay products, adequate for TCP connections. A smaller value might
` be used to suit delay requirements of a specific application.
`
` Figure 3. Markers to implement the two different services
`
` In practice, the token bucket should be implemented in bytes and a
` token is considered to be present if the number of bytes in the
` bucket is equal or larger to the size of the packet. For Premium, the
` bucket can only be allowed to fill to the maximum packet size; while
` Assured may fill to the configured burst parameter. Premium traffic
` is held until a sufficient byte credit has accumulated and this
` holding buffer provides the only real queue the flow sees in the
` network. For Assured, traffic, we just test if the bytes in the
` bucket are sufficient for the packet size and set A if so. If not,
` the only difference is that A is not set. Assured traffic goes into a
` queue following this step and potentially sees a queue at every hop
` along its path.
`
` Each output interface of a router must have two queues and must
` implement a test on the P-bit to select a packet’s output queue. The
` two queues must be serviced by simple priority, Premium packets
` first. Each output interface must implement the RED-based RIO
` mechanism described in [3] on the lower priority queue. RIO uses two
` thresholds for when to begin dropping packets, a lower one based on
` total queue occupancy for ordinary best effort traffic and one based
` on the number of packets enqueued that have their A-bit set. This
` means that any action preferential to Assured service traffic will
` only be taken when the queue’s capacity exceeds the threshold value
` for ordinary best effort service. In this case, only unmarked packets
` will be dropped (using the RED algorithm) unless the threshold value
` for Assured service is also reached. Keeping an accurate count of the
` number of A-bit packets currently in a queue requires either testing
` the A-bit at both entry and exit of the queue or some additional
` state in the router. Figure 4 is a block diagram of the output
` interface for all routers.
`
` Figure 4. Router output interface for two-bit architecture
`
` The packet output of a leaf router is thus a shaped stream of packets
` with P-bits set mingled with an unshaped best effort stream of
` packets, some of which may have A-bits set. Premium service clearly
` cannot starve best effort traffic because it is both burst and
` bandwidth controlled. Assured service might rely only on a
` conservative allocation to prevent starvation of unmarked traffic,
` but bursts of Assured traffic might then close out best-effort
` traffic at bottleneck queues during congestive periods.
`
`Nichols, et al. Informational [Page 9]
`
`Arista Networks, Inc.
`Ex. 1024, p. 9
`
`

`

`RFC 2638 Two-bit Differentiated Services Architecture July 1999
`
` After [3], we designate the forwarding path objects that test flows
` against their usage profiles "Profile Meters". Border routers will
` require Profile Meters at their input interfaces. The bilateral
` agreement between adjacent administrative domains must specify a peak
` rate on all P traffic and a rate and burst for A traffic (and
` possibly a start time and duration). A Profile Meter is required at
` the ingress of a trust region to ensure that differentiated service
` packet flows are in compliance with their agreed-upon rates. Non-
` compliant packets of Premium flows are discarded while non-compliant
` packets of Assured flows have their A-bits reset. For example, in
` figure 1, if the ISP has agreed to supply Company A with r bytes/sec
` of Premium service, P-bit marked packets that enter the ISP through
` the link from Company A will be dropped if they exceed r. If instead,
` the service in figure 1 was Assured service, the packets would simply
` be unmarked, forwarded as best effort.
`
` The simplest border router input interface is a Profile Meter
` constructed from a token bucket configured with the contracted rate
` across that ingress link (see figure 5). Each type, Premium or
` Assured, and each interface must have its own profile meter
` corresponding to a particular class across a particular boundary.
` (This is in contrast to models where every flow that crosses the
` boundary must be separately policed and/or shaped.) The exact
` mechanisms required at a border router input interface depend on the
` allocation policy deployed; a more complex approach is presented in
` section 4.
`
` Figure 5. Border router input interface Profile Meters
`
`3. Mechanisms
`
`3.1 Forwarding Path Primitives
`
` Section 2.3 introduced the forwarding path objects of Markers and
` Profile Meters. In this section we specify the primitive building
` blocks required to compose them. The primitives are: general
` classifier, bit-pattern classifier, bit setter, priority queues,
` policing token bucket and shaping token bucket. These primitives can
` compose a Marker (either a policing or a shaping token bucket plus a
` bit setter) and a Profile Meter (a policing token bucket plus a
` dropper or bit setter).
`
` General Classifier: Leaf or first-hop routers must perform a
` transport-level signature matching based on a tuple in the packet
` header, a functionality which is part of any RSVP-capable router. As
` described above, packets whose tuples match one of the configured
` flows are conformance tested and have the appropriate service bit
` set. This function is memory- and processing-intensive, but is kept
`
`Nichols, et al. Informational [Page 10]
`
`Arista Networks, Inc.
`Ex. 1024, p. 10
`
`

`

`RFC 2638 Two-bit Differentiated Services Architecture July 1999
`
` at the edges of the network where there are fewer flows.
`
` Bit-pattern classifier: This primitive comprises a simple two-way
` decision based on whether a particular bit-pattern in the IP header
` is set or not. As in figure 4, the P-bit is tested when a packet
` arrives at a non-leaf router to determine whether to enqueue it in
` the high priority output queue or the low priority packet queue. The
` A-bit of packets bound for the low priority queue is tested to 1)
` increment the count of Assured packets in the queue if set and 2)
` determine which drop probability will be used for that packet.
` Packets exiting the low priority queue must also have the A-bit
` tested so that the count of enqueued Assured packets can be
` decremented if necessary.
`
` Bit setter: The A-bits and P-bits must be set or cleared in several
` places. A functional block that sets the appropriate bits of the IP
` header to a configured bit-pattern would be the most general.
`
` Priority queues: Every network element must include (at least) two
` levels of simple priority queueing. The high priority queue is for
` the Premium traffic and the service rule is to send packets in that
` queue first and to exhaustion. Recall that Premium traffic must never
` be oversubscribed, thus Premium traffic should see little or no
` queue.
`
` Shaping token bucket:This is the token bucket required at the leaf
` router for Premium traffic and shown in figure 3. As we shall see,
` shaping is also useful at egress points of a trust region. An
` arriving packet is immediately forwarded if there is a token present
` in the bucket, otherwise the packet is enqueued until the bucket
` contains tokens sufficient to send it. Shaping requires clocking
` mechanisms, packet memory, and some state block for each flow and is
` thus a memory and computation-intensive process.
`
` Policing token bucket: This is the token bucket required for Profile
` Meters and shown in figure 5. Policing token buckets never hold
` arriving packets, but check on arrival to see if a token is available
` for the packet’s service class. If so, the packet is forwarded
` immediately. If not, the policing action is taken, dropping for
` Premium and reclassifying or unmarking for Assured.
`
`3.2 Passing configuration information
`
` Clearly, mechanisms are required to communicate the information
` about the request to the leaf router. This configuration information
` is the rate, burst, and whether it is a Premium or Assured type.
` There may also need to be a specific field to set or clear this
` configuration. This information can be passed in a nu