Cyan’s Telesystem win in packet-optical for its Z-series and SDN technology is an interesting indicator of some major metro trends. While it’s victory over TDM is hardly newsworthy, it does show that packet advantages over TDM can justify a technology change—and any time you can justify technology change the barrier to doing something revolutionary is lower. That’s one reason why metro is so important in today’s market.
Metro technology has historically been based on SONET/TDM, which offers high reliability and availability but is not particularly efficient in carrying traffic that’s bursty, like most data traffic. Packet technology was designed (back in 1966 for those history buffs) to fill in the gaps in one user’s traffic with traffic from another, allowing “oversubscription” of trunks that gave as many as four or five users what appeared to be the full use of the path. Obviously that saves money.
The challenge with packet has always been providing reasonable quality of service. If bursty traffic bursts too much, the result is more peak load than a trunk can carry, which will cause at first delay (as devices queue traffic) and then packet loss (as queues overflow). Sometimes packets could be rerouted along alternate paths, but such a move gives risk to a risk of out-of-sequence arrivals (which some protocols tolerate and others don’t). The whole process of getting good utilization from packet trunks to create economic benefits while sustaining reasonable operations burdens to build rather than erode those early savings has become a science. We usually call it “traffic engineering”.
Metro networks are often very sensitive to traffic engineering issues because they often don’t present a high ratio of trunk to port speed, and that means a given port can influence trunk loading more. There are fewer alternate paths available, and metro protocols often can’t reroute quickly and efficiently. Furthermore, since most metro networks are aggregation networks rather than networks providing open connectivity among users, there are fewer service features to justify the multiplicity of protocol layers in a stack. Since every layer adds to cost, the goal is to moosh things down into as few as possible, which is where packet-optical comes in.
Cyan has done a pretty good job of creating a packet-optical ecosystem around SDN concepts, though many of its competitors would argue whether what they do is really SDN. Given the loose state of definition for SDN today I think that’s a meaningless point, but I do think that Cyan may be stopping SDN notions perhaps a layer too short.
Traffic engineering is something that should be done at the aggregate level. We’ve always known that in core networks you don’t want to have application awareness because it’s simply too expensive to provide it when traffic is highly aggregated. As metro networks get fatter, particularly deeper inside, you have the same issue. To me, that means that traffic management should really be applied more at the service policy level than at the forwarding level. For the management of connectivity, the relationships between users and resources at a broad level, you are better off using an overlay virtual network strategy—software networks based on SDN principles rather than forwarding-table control at the hardware level. OpenFlow, as I’ve pointed out many times, isn’t particularly suited to managing optical flows anyway—it demands visibility down to packet headers and so flows are opaque to normal OpenFlow rule-processing.
I think this double-layer SDN model is the emergent reality of SDN. Make the top very agile and very “software-controlled” because software is interested in connectivity not traffic. Make the traffic part as efficient as possible in handling flows with various QoS needs, but don’t couple software down to the hardware layer because you can’t have applications directly influencing forwarding or you’ll have total anarchy. I think that what Cyan has done so far is consistent with the bottom of my dual-model SDN but I’m not convinced that they have played software-overlay SDN to its full potential. Perhaps their Blue Planet ecosystem could support it, but their promotion of the platform talks about devices and not about software tunnels and overlays.
I also think, as I noted yesterday in comments about NSN’s CDN partnership, that we need to realize that SDN will never work at any level if we expect applications to manipulate network forwarding and policy. We have to create services that applications consume, services that abstract sets of forwarding policies upward to applications, and then press the policies down to the lower SDN layer to make traffic flow in an orderly way. That process is ideal for software overlays because it has to be very malleable. We can define a service that looks like a Neutron (what they now call OpenStack’s network interface, formerly Quantum) for the cloud users, we can define it as Ethernet or IP, we can define it as a tunnel, a multicast tree…whatever we like. That’s because software platforms for SDN have low financial cost and inertia so we can change them, or even switch them quickly. Every good SDN strategy that works at the device level needs a smart positioning of a software overlay.
Operations can also be facilitated with this mechanism. As long as we create networks from devices—real or virtual, software or hardware—we will have to manage their cooperation. A service network doesn’t have to be thought of as a device network at all. Its behavior can be abstracted to a black box, and its management can be similarly abstracted. Internal features drive black-box services to perform according to their external mission, and those same features can drive black-box management. We can even create abstract management entities whose boundaries and properties are set to minimize operations costs, even if they don’t correspond to functional boundaries. Virtualization is a powerful thing.
Packet wins over TDM have been ordained for a decade or more, it’s just a matter of waiting until you can write down the old stuff. Packet wins over other packet technology will likely depend on the effective use of SDN-layer principles—and that’s particularly true in metro.