ACG Research

ACG Research
We focus on the Why before the What

Thursday, October 22, 2015

SDN & Multi-layer Transport SDN: Notes from Layer123 SDN OpenFlow World Congress

This year’s Layer123 SDN OpenFlow World Congress in Dusseldorf, Germany, was quite an expanded event from last year with over more than 1,500 people registering.

There was a great mix of presentations from equipment suppliers, services providers and open source organizations at the event. SDN and NFV were, of course, top of mind at the event. The number of SDN and NFV PoCs and trials continue to grow rapidly, but live commercial deployments outside the data center remain elusive. Our ideas and thinking about the application of this technology in our networks has, however, matured. The focus has shifted, correctly I believe, from minimizing capital costs with COTS hardware to agile revenue generation via network automation and programmability.

Although many challenges remain, the single biggest barrier to mass SDN commercial deployment is operationalization of the technology. It is not just commissioning either. A virtualized and programmable network must still be operated and managed throughout its life-cycle to meet changing networking demands and customer service level agreements. In one conversation with an equipment manufacture, we discussed the simple scenario of a fan failure in a server running multiple VMs and VNFs. Who would know of the failure? How would they know and when would they know? Part of the beauty of an NFV environment is that the VM/VNF can simply be moved to other physical machines. However, financial considerations will always dictate that there is a limit to the number of physical machines (COTS or otherwise) installed in a service provider network. The underlying physical network will have to be maintained and failures addressed lest they eventually lead to poor network performance and customer satisfaction.

The fact that there was broad acknowledgment about the need to close the operational gaps is encouraging and a major step toward increasing commercial deployments.

Multi-layer Transport SDN was another topic that generated a lot of chatter in both Layer123 sessions and at a lunch-time debating table. Is multi-layer only through Layer 2 or 2.5? Or does it involve Layer 3 and IP?

After some discussion, the general consensus emerged that in order to maximize the value of an agile SDN-enabled network, multi-layer SDN and associated path computation must be Layer 0-3. The value of a multi-layer control plane is significantly diminished if IP is not a part of the solution. Independent fault detection and recovery mechanisms (think path computation) is exactly what we have in today’s networks with the packet-optical layers doing their own detection and restoration while IP executes its own Layer 3 detection and restoration mechanisms with protocols such as BFD and EMCP. Break a fiber in a network and all layers work almost completely independently to restore paths and services at their respective protocol layer.

With SDN and centralized control, we have the opportunity to ensure that wavelengths, ports and paths are coordinated and utilized for maximum efficiency. We can simplify our networks and drive out complexity and operational costs. Must a supplier’s controller and path computation element (PCE) contain Layer 0-3 functionality? Not necessarily. The hierarchical nature of SDN control means that hierarchical-PCE across multiple PCEs is a viable option. Packet optical suppliers could focus on Layer 0-2 PCE but then interface in a hierarchical manner with a Layer 3 PCE partner/supplier. Alternatively, a monolithic Layer 0-3 PCE is also possible but might require tighter coordination and integration than an equipment supplier may want to pursue. Either way, packet optical suppliers need to drive their PCE thinking from a Layer 0-3 perspective if we are to simplify the network, improve equipment utilization/efficiency and create agility for the future.

Click for more information about Tim Doiron or to discuss this topic contact Tim at tdoiron@acgcc.com.


   Tim Doiron
   tdoiron@acgcc.com
   www.acgcc.com

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.