BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
I've encountered an assumption that SDN is simply a mechanism for automating network configurations. While an automation system can help many organizations, it is not where the real value lies.
My view of SDN has several characteristics:
- Applications and the network exchange information about requirements and changes to the network.
- Forwarding is based on multiple fields in the IP header, not just the destination IP address.
- Security defaults to whitelist -- SDN doesn't forward by default -- entries must be made to permit forwarding.
- A policy is needed to define how requirement conflicts are resolved.
When applications talk to the network, UC apps tell the network when a new call is starting, the status of the call while it is under way, and when the call terminates. The network can then program itself to handle the call.
When the network talks to the application, call admission control is implemented. When UC apps tell the network of a new call, the network may reply that the call cannot be handled with the current bandwidth allocation. Ideally, the network would tell the application some additional information, such as the amount of remaining bandwidth.
The UC app can then reject the call or take some other action, such as change to a lower bandwidth codec. Or perhaps it could change the codec used by other calls to make room for the new call. At call termination, which causes bandwidth to become available, the UC system could return calls to a higher bandwidth codec.
Support for forwarding based on more than destination IP address
Current packet forwarding is based on the destination IP address. But what if you wanted to create a policy that directed UC traffic over separate links that were designed for relatively low bandwidth, low latency and low jitter typical of UC traffic? Today's mechanism is policy-based routing, which has to be consistently implemented across the network. It is a complex and static configuration. An SDN should allow for packet forwarding using multiple fields in the packet header, making it easy to do policy-based routing.
SDN can also improve security. SDN uses a whitelist model in which the default is to deny forwarding, and entries must be made to permit forwarding. Traditional access lists on many devices default to "permit any," and access control lists (ACLs) must be created to deny specific traffic. While it is easy to create an ACL to deny traffic by default, it is seldom done. One of the big reasons is that many organizations don't know the applications that are in use on the network. This makes it difficult to create ACLs to permit the desired traffic. SDN will require organizations to understand their applications to a greater degree than they do today.
Policy in an SDN can provide resolution of conflicts between the traffic from multiple applications. For example, two health care organizations may have merged. Let's assume that each organization has different UC systems. Add bedside monitoring systems to the mix, which uses UDP traffic that is best transported in the Express Forwarding (EF) queue. How is priority determined between the different traffic types? This is a policy decision.
The obvious decision is to prioritize health-monitoring traffic above voice traffic that is also handled in the EF queue. Policy may also be used to identify emergency calls with higher priority than normal voice calls, even if it means the network must re-mark an existing set of voice calls to Best Effort (CS0).
Policy isn't needed as long as the EF queue has sufficient bandwidth for all the traffic. But when all bandwidth allocated to the EF queue is being used, policy determines which traffic gets priority treatment.
In summary, SDN is much more than simply network automation. Significant features will improve networking and our ability to support UC apps. It will take time for vendors to build SDN services and modify applications to talk with the network. Customers should become educated about SDN and whether vendors' services are acceptable for their future business needs.
About the author
Terry Slattery is principal architect at NetCraftsmen, a network engineering consulting firm. He is the founder of Netcordia, a network configuration management company. Slattery has 20 years of network consulting and design work experience.
SDN promises real-time UC app, network dialogue
SDN could deliver radical upgrade for needy UC apps
SDN could give UC performance a boost