Rate shaping in Active E FTTx networks

Sun Jul 29 14:12:03 UTC 2012

On Thursday, July 26, 2012 09:45:14 PM Jason Lixfeld wrote:

> Is that a lot to ask for one box?  The ridiculously deep
> buffers required in order to shape to PIR vs. police to
> it (because policing to a PIR is just plain ugly) and
> the requirements to perform any sort of preferential
> packet treatment above and beyond that seem like quite a
> lot to ask of one box.  Am I wrong?

Having used middleware in the past to do bandwidth 
management, this doesn't scale well when your network grows, 
and when off-net traffic (including that between your own 
customers) is coming in from several points in the backbone.

On smaller networks, having middleware is easy because your 
exit points are finite and fairly static. When you grow and 
start peering, taking on several large customers that want 
to talk to each other across your network, middleware 
becomes cumbersome to deploy, because then not only can't 
you assume that 80% of your traffic is HTTP, but you also 
can't assume that 80% of your traffic is toward your 
upstreams. Moreover, adding redundancy (as in multiple links 
between routers/switches) makes the situation worse, because 
middleware might not be as inclined, and arbitration of 
bandwidth management across multiple middleware devices to 
avoid accidentally over-provisioning to customers gets 
expensive and complex.

I've since migrated to performing bandwidth management in 
the router gear itself. This is easy if you're using high-
end kit (think Juniper M/MX/T, Cisco ASR1000/9000), but 
significantly less so on wireline Metro-E networks (where 
your Active-E comes in). But not anymore - there have been 
meaningful developments in this area, and for some I've had 
the pleasure of deploying, e.g., Cisco's ME3600X/3800X. 
There also alternatives like Juniper's MX80 (too big, I 
think, but the smallest you can get from them now) and 
Brocade's NetIron CES/CER2000 units. These allow you to not 
only gain decent feature set in the Access, but also let you 
extend IP (and MPLS) into the edge too for additional 
simplicity.

Hope this helps.

Cheers

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120729/a317129c/attachment.sig>