[c-nsp] Revisiting ethernet bandwidth management

[Rick Ernst]

I'm working on a network refresh that includes the customer aggregation. 
Services to customers are primarily across ethernet (LAN and MAN).

I've been researching/fighting/experimenting with methods to handle
per-port bidirectional bandwidth control.  The legacy configuration uses
Cisco's CAR, and I've been looking at traffic-shaping and policing. From
what I can see, the various bandwidth management techniques require
increasing CPU as the traffic rate increase (more packets/bytes == more
work for the CPU).

I need a device that does at least HSRP/VRRP/equivalent plus OSPF and
handles the bandwidth management.  The 3550G (playing with it for a
different project) reportedly has problems with multiple ports/streams
above 1Mbs.  The chassis-based devices (6500/7600) appear to punt at least
some of the traffic to CPU, plus I'd like to deploy small devices per
patch-panel and backhaul to the aggregation or core (depending on how much
functionality is in the device).

I'd like either a stackable or small chassis device that I can either
configure "M"Mbs per port/VLAN or "P"percent per port, not necessarily
with bursting capability. The extreme hypothetical environment would be
24ea 10/100/1000 ports each configured for 1Mbs bandwidth and hosts on all
ports attempting to send and/or receive at line rate without cratering the
device.

I've also considered essentially aggregating multiple ports/VLANs on a
switch and uplinking with a 100Mbs port.  This would require monitoring
and manual intervention to ensure the aggregate doesn't exceed 100mbs.  We
also have customers that need more than 100mbs which means I'd somehow
have to ensure that a single customer couldn't consume the capacity of an
entire GigE (unless provisioned for it).

Am I missing a feature/device/configuration that is obvious to somebody
else, or.... ?  My concern with any CPU-based solution is that it won't
scale as customer bandwidth needs continue to increase.  I'd also prefer
small, stand-alone devices and distribute them at the patch-panel level
for "light bulb" replacement and ease of cable management.

Thanks,