SDN Applications

SDN Applications

A discussion of technology always has inherent value, particularly from an educational perspective. But from a practical standpoint, the reason technology exists is to deliver functional benefits. In SDN that value largely derives from what the applications can do for you. Therefore no discussion of SDN is complete without considering the specific benefits of applications.

Note that it is not within the scope of this paper to discuss the exact details of how to program an application. Specific implementations are based upon the controller or orchestrator interface as it was built by the vendor. Most interfaces will be RESTful with JSON and/or XML for data transport, 

but vendors are not constrained to these and individual interfaces may vary. The vendor should provide a well-documented SDK for interface building. 

Many applications can be used in an SDN network. Figure 4 shows a list of examples, broken down by application type. This list is by no means exhaustive; it also contains some examples that may not apply to the transport network. However, while some of the functions may not apply to 

the transport section, having the orchestration layer means that you can control many different sections of your network, including those that are not transport-related. As such the list in Figure 4 is informative as to the tremendous number of functions that can be used in an SDN-capable 

network.

Path Computation

Let's consider a few examples of the SDN applications that specifically apply to service provider networks. One common application will be path computation, or end-to-end provisioning. Over the years there have been many methods that have sought to provide a PCE. One attempt was to 

embed the PCE into the NEs. This idea is, in fact, the opposite concept from SDN, because it mingles the control and data layers. From a practical standpoint, merging these two layers has several limitations. One is that, because the hardware on the NEs is limited, the scale of the domain 

this hardware manages is also limited. SDN overcomes this issue by the very nature of the hardware it runs on, specifically a server. Should the server become unable to manage the network due to size, additional capacity can be added by simply increasing the hardware (e.g. adding a blade or hard drive) or, if running on an elastic computing platform, by simply requesting additional computing resources. Another limitation of merged control and data layers is interoperability with other devices via the control layer. Since not all systems share common signaling protocols, the systems with embedded controls will become isolated. In the case of SDN, the southbound adaptors mitigate this issue by not only being able to work with disparate protocols but also by being able to manage systems that do not have embedded controllers.

With the ability to compute a path across the network, another logical application is workflow or flow-through provisioning. Order entry systems can query the SDN layer to see what resources are available. These are real time queries of the actual network, and not just of a database that could potentially have out-of-date information. This means the network is used more efficiently. The order system can then programmatically build the RESTful commands needed to tell the SDN orchestrator or controller what the endpoints, bandwidth demands, and restrictions of the needed services are, and the SDN layer can automatically provision them. Additionally the SDN system can interface with the billing system for auditing purposes.

SDN and OTN Applications

A prime example of SDN being used to configure services can be seen when it is applied to OTN. OTN is a multilayered technology that allows users to densely and efficiently pack different service types into a single DWDM wavelength. OTN can greatly benefit the network by optimizing 

transport, but it does add some complexity that can be simplified using SDN.

A user might have multiple Ethernet flows that are headed to the same destination (perhaps a datacenter). OTN can optimally transport all of them in an aggregate flow. Assuming that the flows are smaller services (1 Gb or smaller), these can be mapped into a LO ODU0. SDN can multiplex the multiple LO containers bound for a particular destination into HO OTU containers. It can then map the HO containers onto wavelengths that connect the two points so there is no regeneration in between, which makes the network more efficient.

Needless to say, not all flows will be carried by LO ODUs. As such, SDN can determine what type of container or transport is available and required for the service. As mentioned above, SDN could map the service to an aggregated flow in an OTN container, which is riding on a wavelength. But perhaps a needed segment does not have OTN, or perhaps the service is large in and of itself (e.g. 100 Gb), so that it does not need to be combined with another service. In that case, SDN could map the service directly to a wavelength. The decision of whether to aggregate into an LO or HO OTU, or to just use a wavelength, can be made from the logic programmed into the SDN application, making the network even more efficient. 

Network Optimization 

Another area where SDN can improve network utilization is by optimizing the network so that over time, it can make better use of resources. Again, using the example of OTN, SDN applications can be used to reroute OTN paths to minimize latency, to prepare for cutovers, or based on churn in demand. The application can run as a background scheduled task to automatically look for opportunities to perform optimizations. It can then generate executive reports showing how it has performed the optimization. 

Automated Testing

Once the system has created the end-to-end service, another application (or perhaps part of the turn-up application) can perform automated testing. Where software test connections are possible, the system can not only turn up the cross connects for the test but can activate the testing protocols. For example, as part of turning up an Ethernet service, the system could create a Y.1564 service “birth certificate.” Once the test is complete, the SDN system can take the report that is generated on the test gear and, if it fails, notify a technician that there is a problem with the circuit. If the circuit passes the test, the system can send the report to the inventory database, where it can be archived with the other circuit information.

Protection and Restoration

Another application that can be built is for protection and restoration. As mentioned earlier, in order to meet the required 50 ms protection needed in carrier-class networks much of the switching must take place in the hardware on the NEs. This means the SDN controller will be passing to the hardware messages that define the protection path. One advantage is that the SDN system can systematically search for the best possible restoration paths, even as new links are added to the existing network. It can search and find the most efficient path as they become available. This means the system could discover and utilize a 1:n protection scheme instead of using a less effective one-for-one method. It also means that if there is a failure, the system can dynamically compute additional protection paths. Today there are systems that can do this using embedded controllers. Unfortunately after multiple failures, the network becomes fragmented as the system moves services to different links. This can be thought of as being similar to the fragmentation of a hard drive. Typically, tools need to be run to optimize the network, much like the manual defragmentation process that needed to be run in older versions of Windows. Like the newer versions of Windows, SDN can automatically “defragment” to optimize the network as part of the protection application

SLA Management

Another possible application is SLA management, which has become a key challenge for many customers. End customers have SLA requirements associated with the services they have purchased, and they want to have a Web portal to view conformance data. The Web portal can be of great 

benefit, premiums are charged for both the SLA and the Web portal. If the user thinks they are having an issue and they look at their portal they may find that they have more traffic than what is covered by the SLA. This means more than just saving a troubleshooting call to the service department. It means that the customer may look at adding additional bandwidth, driving new revenue for the service provider. It is important to understand, whether adding an SLA portal or using an existing system, pulling the information via SDN is simpler, especially given the fact that REST is a web interface.

Custom Applications

Custom applications can also be written to meet a service provider's specific needs. One example might be an application to backup large databases without affecting traffic. Using SDN you can not only schedule the backup itself, but also an increase in available bandwidth during the file transfer. The timing can be set to a known off-peak time when transport bandwidth is underutilized. After the transfer is over the bandwidth can be restored to the original size, causing no impact to customer traffic. 

Network Function Virtualization (NFV)

In addition to applications, SDN becomes an enabler of NFV. NFV allows companies to provide services that currently run on dedicated hardware located on the end user's premises by moving the functionality to the network. Content delivery, such as Netflix video on demand, is a prime 

example of this. Content (movies) that was once delivered exclusively on VCRs, DVDs and BluRay, can now be streamed over the network with full pause, rewind, and fast-forward functions. An example of an NFV function that service providers can deliver in context of network services would 

be a firewall. Instead of a customer (who is using a service-provider Internet connection) setting up and maintaining a firewall in their office, they could subscribe to the service. In NFV this is known as a virtual appliance.