How to Implement Software Defined Networking – A Pragmatic Approach to SDN Implementation

Software defined networking (SDN) is no longer the exclusive domain of academic research. Communication service providers (CSPs) make many announcements about rolling out SDN (and NFV) technology in their networks, or about running industry proofs of concept. The problem is that SDN concepts are considered “open to interpretation” so, when we talk about implementing SDN telecom implementation, what exactly do we mean?

The answer lies in understanding the essence of SDN – which, given that the initial definition of SDN is both precise and enigmatic, is no mean feat.

One the one hand, SDN is about separating the data plane from control plane, and centralizing control plain logic in the SDN controller. Although presented in short form, this SDN concept is certainly precise in the sense that this new type of division will, when its only functionality is limited to data forwarding with no control logic, result in a “pure” SDN-based network. OpenFlow switches are examples of such devices, which expose their functionally via the OpenFlow protocol. The beauty of this is that the OpenFlow protocol has such a narrow functionality (there’s no control plane logic involved) that, even if you knew nothing about SDN, you would, by following this path, end up implementing “pure” SDN. So, based on the “precise” definition, we may say that you are definitely implementing SDN if you are using the OpenFlow protocol.

This isn’t the only option, though.

BGP-LS, PCEP-rich IP/MPLS Routers – How to Implement SDN Pragmatically

The problem with the “pure” approach to SDN implementation (employing OpenFlow switches) is that requires all equipment in which CSPs have invested a great deal of money to be scrapped, and replaced with new kit. This is obviously key among the SDN challenges, as it is impractical and very costly. So, can SDN be introducing using legacy equipment such as IP routers?

It is certainly possible – except IP routers provide quite rich functionality, including control plane logic (for example, implementation of routing protocols, BGP-LS, PCEP, and more). It follows that, if you are going to use such equipment, you are still going to have a control plane bundled with a data plane inside the network device (routers). At first glance, this appears to be everything that the definition of SDN as a “separation of powers” is not.

Path Computation Entity (PCE) Implanted by SDN Controller

It seems that there is a way to implement SDN idea (and take the benefits of that) while still using “legacy” IP/MPLS routers

Prior to SDN, the concept of separating the PCE from router functionality existed. Moreover, the concept of centralized PCE was assumed by the PCEP protocol. That, from the SDN perspective, means the separation of an important part of the control plane from the data plane. The expected benefits are that, due to the centralized nature of the PCE, the path calculation algorithms can be more intelligent than if they were implemented inside an individual router with a limited view of the network. So, when centralized, PCE can be perceived as SDN concept implementation. The benefit is that this approach to SDN implementation involves the smooth transformation from a legacy network to one based on SDN. The result? A much more pragmatic solution than ripping out all legacy equipment and replacing it with kit based purely on OpenFlow protocol.

PCE as an SDN Controller Application – Does it Live up to the Claim of an SDN-based Network?

The problem with PCE is that PCEP protocol specification which defines how it is to control the network states that in fact the PCE, when returning the calculated paths, does no such thing – as the PCC (which may be a router) may ignore the PCE calculations or apply additional rules or logic. That would cast the PCE as “off-stage prompter” rather than in the controller role. For the term “SDN controller” term to be meaningful, it must take that lead role, truly controlling the network in a manner that no other entity can upstage. Therefore, any claim that SDN concepts have really been implemented requires both the PCE and the PCC function to be centralized in the SDN controller. That, ideally, should also mean that the SDN controller does not only have the traffic engineering databased (TED) needed to perform path computation, but should also have an internal inventory of all links and paths to be configured in the network.

That could also lead to an interesting and controversial concept, that implementing SDN may mean that the auto-discovery functionality is no longer needed. After all, if the SDN controller is supposed to define what should be in the network, this data should be pushed to the routers, not the other way round. So, for example, if a disconnected router connects to the SDN controller, it is not the SDN controller inventory that should be updated; rather, the router should be forced to reset to the configuration defined by the SDN controller. That idea is probably the most radical, as it requires a new approach to router configuration – that such devices cannot be configured directly (with no telnet to the router), but should always be configured via the SDN controller.

As noted back at the beginning Part I of this post, SDN is “open to interpretation”; and, it’s probably not a black and white concept. Yet, while it doesn’t have to be all or nothing, SDN should mean centralized control plane logic which takes advantage of a full view of the network in order to make more intelligent controlling decisions.