May
22

This blog post reviews and compares two most common types of traffic contracts – single rate and dual-rate agreements and their respective implementations using single-rate and dual-rate (two-rate) policing. We are also going to briefly discuss effects of packet remarking on end-to-end throughput and finally look at some examples of IOS configuration.

What is Traffic Contract

Service-providers network topology typically follows core/aggregation model, where network core has meshed topology and aggregation layers use some variation of tree topology. This design results in bandwidth aggregation when flows converge toward the core. Therefore, to avoid network resource oversubscription, accurate admission control is necessary at the network edge. The admission operation was trivial with circuit-switched TDM-based networks, but became significantly more complicated in packet switched networks. In a packet network, there is no such thing as a constant traffic flow rate, as flows only exist “temporarily” when packets are transmitted. In packet networks, it is common for service providers to connect customer using a sub-rate connection. Sub-rate a connection that provides only a fraction of the maximum possible link bandwidth, e.g. 1Mbps on a 100Mbps connection.

Implementing sub-rate access requires special agreement between service provider and customer – a specification known as “traffic contract”. Traffic contracts are enforced both at customer and SP sides by using traffic shaping and policing respectively. Traffic contracts may vary and include multiple QoS parameters, but there are two most common types that we are going to look at today: single-rate and dual-rate traffic contracts.

Single Rate Traffic Contract

Single-rate traffic contract is normally defined for a sub-rate connection over a physical link with maximum transmission rate of AR (Access Rate). There are three main parameters associated with this type of contract:

  • Committed Information Rate (CIR). Defines the average traffic rate that a customer is allowed to send traffic into the network. Notice the term “average” as packets are still being sent at the line rate (AR), and the information rate is defined by averaging measurement over some time interval. Per the definition, CIR is assumed to be less than AR
  • Committed Burst Size (Bc). This value defines the maximum amount of contiguous packets that a customer is allowed to send in a single “batch”. Packet traffic is commonly bursty, e.g. TCP connection is normally “clocked” by the rate of incoming TCP ACK’s, and the burst size is typically two segments, though the sender may send up to a full TCP window, when possible. After a customer has sent a contiguous block of “Bc” bytes, it must pause for some time before sending the next batch. This is normally implemented using traffic-shaping at customer side.
  • Excessive Burst Size (Be). This is a non-mandatory parameter that could be used to improve admission control “fairness”. Let’s say a customer connection has been idle for some time, and then customer got new traffic to send. Regardless of the previous idle interval, only Bc bytes could be sent in a single burst, and after that customer needs to wait and accumulate more sending credit. By allowing customer to accumulate up to Be extra bytes during longer than normal wait intervals, it is possible to compensate for idle times and send Bc+Be bytes momentarily for a short time. Notice that longer-term average rate still remains equal to CIR, the excessive bursting mechanism only allows for occasional bursting.

Pay attention to the implicit value of Tc=Bc/CIR – this time interval is known as metering “averaging interval”. It defines a time window to count bytes in traffic flow for the purpose of finding the average rate. You may find more information about the use of Tc with traffic policing, look at the following publication: The meaning of Bc with Traffic Policing. Normally, either Tc or Bc value is explicitly defined in the contract, and for IP networks this value should be large enough to allow efficient work of TCP end-to-end between customer locations. Therefore, the lowest value of Tc (or Bc) is effectively based on the SP SLAs and RTT times from one customer site to another. At the very least, the equation Bc >= CIR*RTT should hold, where RTT is the maximum round-trip time site-to-site, per the SLA. At this moment, it is worth reminding that QoS tools are used to control connection quality end-to-end between two different sites connected to the same SP, or different SPs that share some sort of QoS agreements. It is important to point out that that in order to allow for any QoS, complete network should be under the control of a service provider.

What about the Be value? If this one is ever used in contract, it defines the amount of “unused time intervals” that could be “reclaimed” back by the sender. If the customer is allowed to reclaim back N*Tc intervals, then Be could be found simply as N*Bc. Most commonly, if Be is used, N equals to 1, which means the customer may reclaim a single “wasted” Tc interval. The more you grow Be, the more fair would the bandwidth utilization look to a customer, but the sporadic peak rates would tend to exceed CIR more than normal. There is no “best” value for Be, it depends on type of traffic.

Implementation wise, single-rate traffic policing is implemented by tracking the current burst size using token-bucket mechanics, and discarding packets that exceed CIR. The so-called, Single-rate, Three-Color Marker (srTCM) is the RFC name for ingress tool used to implement admission control at the network edge. The “three color” term means that any incoming burst could be classified as either conforming (green, under Bc), exceeding (yellow, over Bc but under Be) or violating (red, over Be). Depending on the implementation, exceeding packets could be admitted, but have their QoS marking changed to show higher drop precedence in the network core. Here is how the srTCM implementation looks like on a diagram:

Pay attention to the fact that there is a single flow of the tokens that fills the Bc bucket (CBS, committed burst size) first and then continues to filling the Be bucket (EBS, excess burst size). The second bucket is only filled if there was enough idle time to let the first bucket fill up completely. Every arriving packet is first compared to CBS and then to the EBS to determine the next action. The “Ti” interval is the special periodic timer that is used to add tokens to the token buckets. Ideally, Ti should be 1/CIR, but this is normally not possible due to limited resolution of hardware clock, so a small enough value of Ti is chosen.

Dual Rate Traffic Contract

The drawback of single-rate traffic contracts is that SP should be cautions assigning CIR bandwidth, and may effectively “undersell” itself, by offering less bandwidth than it can actually service at any given moment of type. The reason for this is the fact that not all customers send traffic simultaneously, so network links may effectively become underutilized even at the “weak spots”. This brings the idea of dual-rate traffic contract: supply customer with two sending rates, but only guarantee the smaller one. In case of congestion in the network, discard traffic that exceeds the committed rate more aggressively and signal the customer to slow down to the committed rate. This principle was first widely implemented in Frame-Relay networks, but could be easily replicated using any packet-switching technology. There are four main parameters in a dual-rate traffic contract.

  • Committed information Rate (CIR). Same meaning as with a single-rate contract.
  • Committed burst size (Bc). Same meaning as with a single rate contract, and once again, Tc – the averaging interval – is implicitly defined as Tc=Bc/CIR.
  • Peak Information Rate (PIR). Additional parameter – defines the maximum average sending rate for the customer. Traffic bursts that exceed CIR but remain under PIR are allowed in the network, but marked for more aggressive discarding. Marking depends on the transport technology, e.g. it could be DSCP bits, ATM CLP or Frame-Relay DE bit.
  • Excessive Burst Size (Be). This value has different meaning, compared to a single-rate contract. Be is the maximum size of the packet burst that could be accepted to sustain the PIR rate. Effectively, Be defines the second averaging interval, Te=Be/PIR, the averaging rate for PIR metering. Keep in mind that just like with any packet networks packets are sent at the AR, the actual physical rate – CIR and PIR are just average values.

Compared to a single-rate traffic contract, dual-rate has two major differences. Firstly, incoming traffic bursts are metered and compared to CIR and PIR rates simultaneously, using the corresponding Bc and Be burst sizes. Depending on the comparison results, different actions could be taken with regards to the packets. Normally, if a burst is under CIR, it is admitted into the network without any modifications. If the burst exceeds CIR, but remains under PIR (e.g. current burst is still under Be), the burst has marking changed, but still admitted into the network. Finally, if the burst exceeds PIR, it is typically being discarded. Dual-rate contracts are normally implemented using some sort of two-rate, three color marker (trTCM), that compares incoming bursts to Bc and Be and decides on the color to be assigned: conforming (green, under Bc), exceeding (yellow, under Be) or violating (red, over Be). Traffic bursts that exceed Bc will have their marking changed to signalized higher drop precedence. The values for Bc and Be should be selected to be no less than RTT*CIR and RTT*PIR respectively, to allow for efficient TCP performance end-to-end. Here is how a two-rate three color marker implementation would look like if using a token-bucket model:

As compared to a single-rate model, this one uses two separate flow of tokens filling the CBS (Bc) and EBS (Be) buckets. Overflowing tokens are simply spilled an not stored everywhere, there is no “fairness” mechanism in trTCM. Every incoming packet is compared to the amount of tokens in CBS and EBS, but this time it results in comparing the traffic flow to separate pre-defined rates.

Handling Exceeding Packets in SP Network

The dual-rate contracts result in two interesting problems. Firstly, the exceeding packets should be handled differently in the SP network. Secondly, congestion needs to be signaled to the customer reaction point. Let’s start with the packet burst that were marked as exceeding on the reception from the customer. Under congestion, those packets should have more chances of being dropped, as compared to “conforming” packets. This behavior could be implemented in two different ways:

  • Assigning the packets into separate queues, e.g. assign them to a best-effort queue. While this looks logical, it may result in packet reordering. Imagine a TCP flow going between customer site, consuming maximum allowed bandwidth (PIR). Some of the packet burst in this connection may actually conform to CIR, while others may be marked as exceeding. As a result, flow packets may be ordered even under moderate congestion in the network. In result, this will affect TCP performance as packet reordering may trigger TCP Congestion Avoidance process, resulting in less than possible TCP sending rate. The problem is that TCP cannot reliable tell if packet reordering is a result of packet drop or network queueing.
  • Assigning the packets to a lower drop threshold in the same queue as the conforming traffic. This could be implemented in many different ways, e.g. using different WRED thresholds for different DSCP values or having different drop limit for DE-marked Frame-Relay packets. Using this method will reduce chances of packet re-ordering but may increase end-to-end delay for all traffic. Due to the serious impact of packet re-ordering on TCP congestion avoidance mechanism, using this method is the recommended treatment.

Signaling a network congestion might be difficult in some networks. Not every packet switching technology supports this feature, and many of them may support different signaling. In the most simple case, there is no explicit congestion signaling, like in IP networks (ignoring the obsolete ICMP source quench message). In this case, upper-level protocol is supposed to recognize quality degradation and respond by slowing sending rate. This is automatically done by the commonly used TCP protocol. As another example, you may consider the use of RTP and RTCP protocols, where RTCP is used to control call quality and may change codecs in response to network condition degradation. Consider Frame-Relay next – congestion may be signaled using BECN bit to signal traffic source to slow down its sending rate. Notice that in Frame-Relay there are no further hints about congestion, e.g. no indication on how far the sender should go down, so the reaction point may only implement a pre-programmed response. There are numerous other implementation of explicit congestion notification, such as ones used in ATM or Data-Center bridging, or more well-known TCP ECN. Those, however, are out of the scope of this blog post. We will mainly consider the Frame-Relay BECNs and in-built TCP congestion response.

What is the difference between Tc in traffic shaping in policing

The value of Tc is often used in traffic shaping calculating. However, the meaning and the use of the shaping time interval is different from policing Tc. When traffic is metered, Tc defines the length of sliding window over a time axis that is effectively used to find the average traffic rate. With traffic shaping, Tc defines the periodic scheduling interval to be used when emitting traffic bursts by the shaper’s leaky bucket algorithm. When you match shaping settings against the ingress policing, you need to make sure that shaping Tc does not exceed the configured policing Tc – otherwise, the shaper may produce bursts that are always rejected by the policer. The same logic applies to the Be burst values used in traffic shaping and policing. There is a substantial difference in Cisco IOS implementation. For traffic shaping, sBc+sBe is the maximum amount of bits you can send during a single interval. This cumulative burst will be compared to either policing pBc value or policing pBe value independently, when using ingress MQC policing. Therefore, you need to make sure that pBe>=sBc+sBe, or the excessive burst may be rejected by the policer. Finally, notice that if shaping Be is set to a value above (AR-CIR)*Tc it will take more than single Tc interval to schedule sending of excessive traffic. Effectively, during a single Tc interval a shaper cannot send more than AR*Tc bits, which means the maximum excessive burst value is (AR-CIR)*Tc during a single Tc. Setting Be over this value will result in excessive bursting split across multiple scheduling intervals.

Implementing Single Rate Traffic Contracts in Cisco IOS

We’ll be using Frame-Relay as the SP access technology for our examples. Let’s assume that we have a traffic contract for CIR=256Kbps and a normal burst size of Bc=25600 bits. The contract should be implemented on a T1 connection with a bit-rate of 1544000 bps. These values translate in policing averaging interval of Tc=25600/256000=100ms (1/10 of second). The contact needs to be enforced on customer side using traffic shaping with a Tc value <= 100ms to be admitted by SP. Let's also assume that the SP agrees to allow excessive bursting to compensate for a single idle Tc interval. The final values becomes will look as following (notice that policing values are given in bytes, to match Cisco IOS syntax).

Shaping:

CIR=256000 bps
Bc=25600 bits
Be=Bc=25600 bits.

Policing:

CIR=256000 bps
Bc=3200 bytes
Be=6400 bytes (to allow admission of shaping Bc+Be)

Look at how this policy could be implemented on customer side using legacy Frame-Relay Traffic Shaping:

map-class frame-relay SHAPE_256K
 frame-relay cir 256000
 frame-relay bc 25600
 frame-relay be 25600
 frame-relay mincir 256000
!
interface Serial 0/0/0
 frame-relay traffic-shaping
!
interface Serial 0/0/0.1
 frame-relay interface-dlci 101
  class SHAPE_256K

Notice that we set MinCIR value in the FRTS map-class to the same value as CIR to ensure that potential QoS policy would use proper absolute bandwidth values. Here is how an ingress SP policy would look like if MQC traffic policing is used:

class-map DLCI_101
 match fr-dlci 101
!
policy-map POLICE_INTERFACE
 class DLCI_101
  police cir 256000 bc 3200 be 6400
   conform-action transmit
   exceed-action set-frde-transmit
   violate-action drop
!
interface Serial 0/0/0
 service-policy input POLICE_INTERACE

Notice the use of MQC syntax and class-map matching FR DLCI. Cisco IOS supports feature known as Frame-Relay Traffic Policing (FRTP) that could be used to implement the same functions using the "legacy" map-class syntax, but the use of MQC is more common nowadays. How would the shaping implementation look if we were using MQC for traffic shaping?

policy-map SHAPE_256K
 class class-default
   shape average 256000 25600 25600
!
map-class frame-relay SHAPE_256K
 service-policy output SHAPE_256K
!
interface Serial 0/0/0.1
 frame-relay interface-dlci 101
  class SHAPE_256K

If you are looking for more information on FRTS flavors, take a look at the following blog post: The four flavors of Frame-Relay Traffic Shaping

Implementing Dual-Rate Traffic Contracts in Cisco IOS

Let's take the traffic contract from previous example with CIR=256Kbps and AR=1544Kbps and normal burst size of 25600 bits. Next, add PIR=512Kbps to these values along with Be=51200. Make a quick list of shaping/policing values:

Shaping:

minCIR=256000 bps
CIR=512000 bps
Bc=51200 bits
Be=0 bits.

Policing:

CIR=256000 bps
PIR=512000 bps
Bc=3200 bytes
Be=6400 bytes

Pay special attention to the shaping parameters. First of all, Be=0, which means sporadic sending of excessive traffic bursts is disabled. Secondly, the CIR is set to 512Kbps, or in other words to the SP's Peak Rate. This means the customer is allowed to send at the rate of 512Kbps at any time. The minCIR is set to 256Kbps, meaning the customer will throttle down to contracted CIR upon reception of BECNs (if configured).The Bc size corresponds to the policing Be size - in case of congestion, the shaper will automatically shrink the burst size down to the value matching the CIR. Here is how a legacy FRTS configuration would look on customer side:

map-class frame-relay SHAPE_256K
 frame-relay cir 512000
 frame-relay bc 51200
 frame-relay be 0
 frame-relay mincir 256000
 frame-relay adaptive-shaping becn
!
interface Serial 0/0/0
 frame-relay traffic-shaping
!
interface Serial 0/0/0.1
 frame-relay interface-dlci 101
  class SHAPE_256K

Once again, notice that shaping CIR equals the SP's PIR and shaping minCIR corresponds to the actual SP CIR. Also notice that adaptive-shaping is now enabled under the map-class to allow dynamic response to BECN messages. The SP-side configuration would look as following, using MQC syntax:

class-map DLCI_101
 match fr-dlci 101
!
policy-map POLICE_INTERFACE
 class DLCI_101
  police cir 256000 bc 3200 pir 512000 be 6400
   conform-action transmit
   exceed-action set-frde-transmit
   violate-action drop
!
interface Serial 0/0/0
 service-policy input POLICE_INTERACE

Which looks very similar to the single-rate example, just now PIR is explicitly configured. Finally, let's see how the shaping configuration would look like when using MQC syntax:

policy-map SHAPE_256K
 class class-default
   shape average 512000 51200 0
   shape adaptive 256000
!
map-class frame-relay SHAPE_256K
 service-policy output SHAPE_256K
!
interface Serial 0/0/0.1
 frame-relay interface-dlci 101
  class SHAPE_256K

Notice the use of adaptive shaping in MQC syntax. This command will only work if you apply shaping using the map-class model, and won't work if you simply apply a policy to interface. It is also possible to re-write the shaping configuration using the "shape peak" command (see more about this command in the blog post titled Understanding the "shape peak" command:

policy-map SHAPE_256K
 class class-default
   shape peak 256000 25600 25600
   shape adaptive 256000
!
map-class frame-relay SHAPE_256K
 service-policy output SHAPE_256K
!
interface Serial 0/0/0.1
 frame-relay interface-dlci 101
  class SHAPE_256K

Using this syntax allows for clearly showing the Bc and Be portions of the traffic contract, even though the result will be the same as if using the "shape average" command.

Summary

This blog post illustrated the two most commonly used types of traffic contracts in their basic forms and explained the concepts of various bursts used in the specification. Furthermore, there are some examples of enforcing the traffic contracts on both customer and SP sides.

About Petr Lapukhov, 4xCCIE/CCDE:

Petr Lapukhov's career in IT begain in 1988 with a focus on computer programming, and progressed into networking with his first exposure to Novell NetWare in 1991. Initially involved with Kazan State University's campus network support and UNIX system administration, he went through the path of becoming a networking consultant, taking part in many network deployment projects. Petr currently has over 12 years of experience working in the Cisco networking field, and is the only person in the world to have obtained four CCIEs in under two years, passing each on his first attempt. Petr is an exceptional case in that he has been working with all of the technologies covered in his four CCIE tracks (R&S, Security, SP, and Voice) on a daily basis for many years. When not actively teaching classes, developing self-paced products, studying for the CCDE Practical & the CCIE Storage Lab Exam, and completing his PhD in Applied Mathematics.

Find all posts by Petr Lapukhov, 4xCCIE/CCDE | Visit Website


You can leave a response, or trackback from your own site.

21 Responses to “Understanding Single-Rate and Dual-Rate Traffic Policing”

 
  1. Ash says:

    Perfect!!!

  2. Ash says:

    Was extremely helpful.

  3. TiFFolk says:

    Nice topic, Petr! Happy to see new tech posts on this blog

    Do you have any plans to continue BGP topic? As you said:

    “We didn’t not concentrate on the detailed mechanics of BGP fast peering session deactivation e.g. for multihop
    sessions and we did not cover the MP­BGP specific features. Some MP­BGP extensions such as the additional
    import scan interval and edge control plane interworking have their effects on end­to­end convergence, but this is
    a topic for another discussion.”

  4. Wayne says:

    Petr,

    In trTCM you have S1 and S2, and S. Can you please clarify their definition?

    • Wayne, S1 and S2 are the amounts of tokens added to each bucket during every replenish interval Ti. Ideally, a single token should be added every 1/CIR ms interval to CBS bucket, but it’s not possible to set hardware time support any resolution for token bucket algorithm. Therefore, the token bucket scheduler normally runs every Ti ms and CIR*Ti tokens are added to CBS bucket while PIR*Ti to the EBS bucket (for dual-rate policing). It is also possible to implement token bucket differently, but using fixed timer ensures that computation complexity is kept the same, regardless of the packet rate.

  5. Deepak Arora says:

    Any plans for redoing CCIP QOS class or doing a new CCIE QOS Deev Dive class?

  6. Matt says:

    Hi Petr,

    Nice article, however there is one thing that is not clear to me: in the case of the “Single Rate Traffic Contracts”, why should the pBe equals sBc+sBe ? You wrote above that during a Tc, the policer will let through pBc+pBe so I am confused as to why pBe cant be equal to just sBe ?

    Thanks,
    Matt

    • Matt, I think I might have made a mistake there. At any given time, the policer compares current burst with *either* Bc *or* Be – that’s what displayed on the diagram. Therefore, the policer Be should be at least as large as the total amount of bit emitted by the shaper, which could be as high as sBc + sBe (or, to be more accurate, it’s as much as AR*Tc).

      • Matt says:

        Well, looking at the formula in the diagram (and racking my brain on it!), as long as CBS is big enough, then we aren’t going to decrement EBS. Only once CBS is too low will we decrement EBS. So we are really going to let through CBS+EBS, no ?

        Looking at cisco’s documentation that also the way I understand it.

        http://www.cisco.com/en/US/docs/ios/qos/command/reference/qos_n1.html#wp1060117

      • Turgay says:

        Thank You for reply on my previous question.
        But I have the same question as Matt. I agree that policer Be should be above or equal then sBc + sBe in the case of dual-rate contract. But in my opinion this is true for single-rate only if we consider the burst as indivisible. If the burst consists of several frames policer sBe should be above or equal sBe.

  7. Turgay says:

    Hello Petr,
    I don’t understand one issue with policing and shaping.
    What a Cisco device would do if it receives packet whose size is greater than allowed burst? For example,
    CIR = 128000 bps
    Bc = 1280 bits = 160 bytes
    Be = 0
    If shaper needs send a packet of 1500 bytes it will never accumulate required quantity of tokens. So the packet isn’t schedule from queue forever.

    • In short, the shaper/policer burst should always be above maximum packet size. Normally, this is based on common MTU, but keep in mind that IP packet could be as large as 64Kbytes, theoretically. While shaper will still emit packets even if the Bc < MTU (there are certain approximations) the policer will not admit a single packet if the Bc < MTU.

  8. Al says:

    With regards to dual-rate 3 color policers, I don’t understand the below:

    “The values for Bc and Be should be selected to be no less than RTT*CIR and RTT*PIR respectively, to allow for efficient TCP performance end-to-end. ”

    What is the consequence of having Bc < RTT*CIR ?

    Also, great article, thank you!

    Regards,

    Al

  9. Babak says:

    Sorry another question just popped up and I think this is because I am trying to grasp the concept so hard. This is a very basic question that stems from my confusion:

    The concept behind policing is to keep the bit rate at an average constant and drop or remark the excess. Now if we want to configure a police rate of for example 64Kbps, we definetly have to specify the Bc in order to reach that rate. Am I correct? In other words, we need to specify the Bc to be 1 second worth of traffic converted to bytes or 64000/8=8000 Bytes. Is this correct?

    Now what happens when we do not specify the Bc in the police command? I assume that the IOS default is to set the Bc to one forth of the police rate. For example if police rate = 64000 Kbps then the IOS default is to set the BC according to the following formula:
    BC default = 64000/(4*8)=2000 Bytes
    Does this mean that our actual police rate is 64000/4=16 Kbps?

    Thanks again for answering these questions.

    • Vinoth Kumar says:

      @Babak,

      I had a similar question. Did you find any answers for the one you posted last year. I have a customer for whom we have configured 8Mbps on the PE as ingress policer. They left the decision on IOS and it selected a bc as 250000 which is 2Mega Bits per interval with 4 intervals for 1 second.

      Now my question is if the IOS would work to reach 8Mbps over one second or would have challenges.

      Vinoth

  10. Thomas says:

    You seem to have a typo in one of the diagrams. It says “Size1=Size1-S”. I think you mean “EBS=EBS-S”.

    I blogged about this back in January of 2010 because the Internet seemed to be missing articles about that were actually *accurate*:

    http://blog.habets.pp.se/2010/01/Shaping-and-policing-on-Cisco

    Your blog post here seems to also add sanity to the field of QoS, but I expect nothing less from you Petr. :-)

  11. Andres Cervantes says:

    I have not been able to undestood why using the new MQC model Be changes from 25600bits to 6400bytes.

    Be=6400 bytes (to allow admission of shaping Bc+Be)

    How did you came up with this mumber please explain me.

  12. Andres Cervantes says:

    From what I understood the Be bucket get fill with tokens that overflow the BC bucket , then if I do not have information to send during a Tc at my next Tc I will be able to spill the tokens to the Be bucket but from your example Be its only 6400 bytes then I will never be able to recover one Tc that as for the example the provider agree to compensate for idle times.

    Then Be should be equal to Bc even if you use the new format that is the only way I will be able to recovery a full time slot after idle time.

  13. Jey says:

    Hi Petr

    I do understand how shaping and policing works, however I am in doubt about something when given 2 time intervals, lets say 400ms for CIR and Normal burst and then PIR Be time interval set to 200ms.

    It is almost like task 10.26 in Workbook 1.

    I understand the Be is calculated from the PIR value but also read that when you do a two-rate policer that it equals 2 * Bc.

    Could you explain this ?

 

Leave a Reply

Categories

CCIE Bloggers