Cisco ONS 1544 and QOS Policing Scenario

[sarahr202]

Hi everyone.

Please consider first scenario ( packet switched network)

CE f0-----------fe PE--rest of network

CE is using CIR 10M CKT,  PE has inbound policer for 10 M, bc 2M ( bits).

CE is shaping its traffic to CIR 10M, with matching bc 2M to ensure Policer never get hits and we can see any drops on CE that gets tail dropped.

So far so good.

Now take 2nd scenario with Cisco ONS 1544

CE f0-------f0 PE -SONET  ( STS-1)

Above we have   packet switched network and SONET ( TDM).  CE has CIR of 50M, but PE is not enforcing any policing on f0. So CE can send more than 50M to PE, how does PE deals with traffic more than CIR? In first case, PE can determine if the traffic is exceeding by using burst size, but in 2nd case PE is not using any  Policer .

This is my hunch:

1) PE can not determine the if the traffic is exceeding CIR or not when received from CE.

2) Traffic will be queued until it can be transmitted out of SONET interface, traffic will continue to be queued until red drop occurs or tail drops occurs or PE can find the time slot to transmit the queued data in SONET frame.

3) Key thing is PE has no way to determine if the traffic is exceeding, it simply queues the traffic until It can be transmitted in SONET frame or queue gets filled.

I do not know much about SONET , so excuse my ignorance.

Thanks and have a nice weekend!!

[Tom Watts]

STS1 is 49 megabit and overhead is 45 megabit, you won't see policing occur since you're not exceeding the CIR or CBR.

[Joseph W. Doherty · Accepted solution]

For your purposes, just consider a SONET interface is just another interface that supports a specific amount of bandwidth.

If the provider only has a 50 Mbps SONET path, they can just allow their equipment to deal with any over subscription "naturally". I.e. interface to SONET link likely queues to some FIFO queue. Of course, if queue fills, you'll have tail drops.

(NB: I've dealt with providers that try to avoid queue drops by having huge interfaces queues, but this then may create huge transient latency, which can create its own set of problems.)

If you would rather manage the available bandwidth, continue with what you've been doing, i.e. shape for the expected bandwidth.

BTW, having a shaper with the same CIR/Bc/Tc as a downstream policer, doesn't guarantee you avoid the downstream policer dropping your packet because it's unlikely the shaper and policer will be exactly in sync regarding the actual real-time when the Bc is being "measured". (I.e. a burst might span two Bcs for your shaper, but be within the same Bc for the provider's policer.) However, your shaper would likely avoid many policer drops. (Also, BTW, I believe some Cisco devices shapers/policer's don't account for L2 overhead, but a provider's CIR may be a true "wire" like bit rate.)