Media Coverage

Is a “metro” a single class of device, a collection of devices, a reuse of current technology, an on-ramp to a new generation of technology? We really need to talk about how the new missions that drive metro deployment would impact the characteristics of the infrastructure and architecture that frame that deployment.

There’s a fundamental tension in metro architecture. On one hand, it’s always important to support efficient hosting and operations, so it would be helpful to have a single pool of resources and a single management framework. On the other hand, too much unification would compromise the requirement that we be able to partition resources. But if we were to build a metro infrastructure with discrete resources per mission, the result would be inefficient from a capital-equipment utilization perspective, and management complexity would be considerably higher.

A potential compromise could be achieved if we assumed that our metro deployment was connected using a cluster device rather than a single fabric or a traditional switch hierarchy.

I’ve mentioned one cluster router/switch vendor, DriveNets, in some other blogs. The company launched in part because of AT&T’s desire to get a disaggregated open-model-hardware router, and it’s been gaining traction with other operators since. DriveNets offers three features that facilitate a metro deployment model, and none of these features are automatic properties of a cluster architecture, so we can’t be sure that other vendors (when and if they emerge, and tackle the space) will have them. Still, these features pose a baseline requirements set that anyone else will have to address to be credible.

Read More…