Software defined networking is all the rage this year, and service providers are starting to take notice of its potential beyond the data center and into wide area networks. Service provider networks are much different than what you find in a data center, and automation of provisioning and service delivery causes an expanded set of problems. With us today to delve further into the subject and to let us know where Ciena stands on the subject is Mitch Auster, Ciena’s Senior Director of Market Development.
TR: Why have early implementations of Software Defined Networking been focused on the data center as opposed to service provider networks?
MA: SDN started within the data centers because operators were looking for ways to orchestrate or program the network within the data center to more efficiently enable server-to-server and server-to-storage communications. SDN mainly concerned itself with programming the networks to allow subsets of virtual machines and virtual storage elements to communicate in a logically segregated fashion over a shared network fabric. Within the data center, the fabrics have become flat and non-blocking , so for the most part SDN control was about virtual network addressing and not so much about ensuring the capacity required between server and storage devices. It assumed the capacity was there, so the goal was to isolate workloads from one another. And of course within the data center transport was static and essentially free, a pittance compared to digging fiber in the wide-area network (WAN).
TR: What types of new hurdles do Service Providers need to take into account as they look to deploy SDN in the WAN?
MA: There's a big difference between SDN in the data center environment and the carrier/service provider WAN. SDN in the WAN has to concern itself with not just packet networking over static fibers, but packet and optical networking. Service providers have a much scarcer and more valuable resource in terms of the optical capacity; therefore they need to be able to optimize the utilization of the photonic layer as well as the packet and OTN layer switches it connects. They also have a much greater likelihood of interruptions (e.g. a backhoe), you've got latency considerations, and you've got amplifiers. It's a much more complex infrastructure to software define within a carrier environment.
TR: What is Ciena focusing on in order to make service provider SDN a reality?
MA: Since Ciena has product solutions deployed across multiple network layers), we are taking an approach to SDN that is different from the type of SDN deployment you’d find in a data center. SDN controllers within the carrier WAN really need to be multi-layer and optimize packet, circuit, and photonics conjointly and holistically. The control infrastructure within the carrier environment must also be much more scalable and fault tolerant. And the SDN architecture needs to be expansively open.
TR: Could you elaborate further on what it means to be expansively open?
MA: There are three areas where openness is critical – above, below and within the control layer. Everyone agrees on the importance of an open northbound API between the customer-facing application layer and the network control layer; however, some vendors want to keep the control layer closed and the communications between the control layer and the infrastructure or data-plane layer proprietary. But that doesn't do anything to break the stranglehold some of the larger vendors have on service provider networks, and you're still relying on embedded, proprietary, bloated protocol implementations. I would submit that model will be challenged by providers that opt for an open, modular control layer architecture and an open southbound interface, such as OpenFlow, between the control layer and the infrastructure layer. This will lead to service innovation and differentiation, and result in lower operating costs, making those service providers more competitive.
TR: Service providers are also looking at Network Functions Virtualization (NFV), how does that fit with SDN?
MA: When people today talk of NFV, they are primarily talking about running layer 4 to 7 control and data plane functions, such as deep packet inspection, video transcoding, and firewall functions in virtual machines on COTS servers. In the past, those functions were provided by purpose-built appliances or embedded in routers. If you wanted some flows to be processed by those appliances, then ALL traffic of a particular class had to run through them since coarse policy-based routing is not practical on a per user or per session basis. If the signature of the flow matched then it was processed, otherwise it flowed through unadulterated. That means these appliances had to be grossly over-provisioned, which was costly. A key thing that SDN provides is the ability to steer individual flows to or around these virtual appliances. Rather than depend on distributed routing protocols based on source and destination IP addresses, with SDN we can steer traffic at any hop based on very granular information. So within the carrier environment, SDN goes hand in hand with NFV.
TR: So combining SDN and NFV will enable carriers to get more out of the gear they have?
MA: That's right. It will also allow them to be more creative in terms of service handling. For example, they could chain various subsets of network services functions together to offer certain businesses certain value added processing, and other businesses a different set. So this combination would enable cost avoidance as well as a revenue generation.
TR: How close do you think OpenFlow is to being ready for prime time?
MA: OpenFlow holds great promise in enabling a logically centralized network controller to subsume more and more of the embedded control plane and vendor-distinct management system functions; however, within the carrier WAN environment it’s going to be a couple of years before we see a pure, OpenFlow-based SDN in production other than in small contained domains. There are several issues that need to be advanced for packet OpenFlow particularly with regard to fault and performance management. Additionally, while the Open Networking Foundation (ONF) has spun up the Optical Transport Working Group, which Ciena chairs, to define extensions to allow OpenFlow to control layer 0 and 1 networking, their recommendations aren’t planned for completion until April 2014.
TR: Where will we see it first in real world applications?
MA: We see OpenFlow starting out in some contained environments already. An early use case is at the edge of the data center where it connects to VPNs. There is also the data center interconnect use case that Google made famous. We're actually seeing that kind of implementation based on our VWAN software, which enables SDN with an open API between the application layer and control layer, and also leverages our OneControl network management system to connect to orchestrate multi-layer connections across Ciena devices. (We use OneControl today because OpenFlow doesn't support the optical layer, thus we need to use our own technology to provide multi-layer control between data centers.)
TR: When you implement OpenFlow for your products, is it just a software upgrade or does equipment need to be replaced?
MA: It depends on the particular product. There are some devices for which a software upgrade will be sufficient, but there are other devices where we might want to create new line cards to provide full functionality or optimize performance. And for some other devices, particularly photonic layer devices, the ONF's optical transport working group is defining an abstract model for OpenFlow control. So instead of having OpenFlow agents running directly on and configuring the low-level parameters of a ROADM or a line amplifier, the OpenFlow agent will run on a piece of mediation software that would translate to the commands optical equipment understands today – TL1 or CORBA, for example. This is important in a carrier environment. Line amplifiers, for example, have a long lifespan with some deployed undersea or in sewer vaults and such and it would be a challenge to go and replace them. So it's useful to have mediation software that can sit in data centers or central offices and translate OpenFlow commands from the control layer to the commands that the already deployed devices understand today.
TR: Thank you for talking with Telecom Ramblings!