Review of SDN Definition, Applications, Challenges, and Recommendations

SDN Definition Review

Most people now define SDN as the separation of control and forwarding with an open programmable interface; Gartner shares this view but argues that Cisco ACI is not SDN because it does not separate control and forwarding. Lightreading’s definition, which emphasizes an open programmable interface and business agility, is preferred by the author, who argues that debating definitions is less important than the value SDN brings.

SDN Applications in Network Virtualization

Although some claim there are no real SDN deployments, consulting reports show a growing market share, mainly driven by network virtualization. Many overlook virtual switches and cloud platforms as SDN, but solutions like VMware NSX, Juniper Contrail, Midokura MidoNet, and OpenStack Neutron are widely recognized SDN use cases.

Three typical SDN‑based network virtualization solutions are described:

1. Pure‑software solutions (e.g., VMware NSX, Juniper Contrail, etc.) where policy may reside in a controller and forwarding entries are generated by virtual switches or the controller.

2. Hardware‑based solutions, exemplified by Cisco ACI, which implement virtualization in hardware, sometimes with vRouter support.

3. Hybrid software‑plus‑hardware solutions, such as those from Sangfor and Arista, which offload performance‑critical operations to hardware SDN switches while providing a software‑defined tunnel gateway.

Huawei and H3C also offer integrated cloud solutions, though they do not sell networking components separately. In modern data‑center clouds, SDN—whether pure software or hardware‑assisted—is increasingly pervasive.

SDN Applications in Other Domains

Beyond network virtualization, SDN is used in other fields, but its impact is smaller. The main drivers are business‑level flexibility and forwarding‑level flexibility, with the former providing far greater value.

1. Business‑Level Flexibility

Open programmable interfaces enable users to adjust bandwidth, modify topologies, and manage MPLS tunnels on demand, as demonstrated by Pacnet’s IDC deployments using custom SDN switches. Enterprise use cases vary; some networks benefit from SDN’s dynamic reconfiguration, while others do not.

Examples include a TV broadcaster’s network that frequently changes topology for different events, and a laboratory where users request individualized security policies via a self‑service portal.

2. Forwarding‑Level Flexibility

Specific scenarios such as DDoS mitigation, load‑balancing + NAT, TAP functions, and PPPoE/IP separation require packet‑level manipulations not supported by traditional switches, often addressed with SDN or auxiliary FPGA/NP hardware.

Obstacles to SDN Adoption

Hardware‑based SDN deployment progresses slowly due to several Gartner‑identified issues: lack of vendor support through traditional channels, sales difficulty because of SDN’s revolutionary nature, difficulty demonstrating user value in cost analyses, and resistance from operations teams.

The author adds three practical conditions for successful SDN rollout: (1) users must clearly understand their network problems and seek SDN as a solution; (2) decision‑makers need authority and coordination between development and operations; (3) development teams must possess sufficient capability to build SDN applications, as the core of SDN is the application layer, not the switch or controller alone.

Limitations of OpenFlow

OpenFlow is the most known SDN protocol but is not sufficient for many use cases. Technical limitations (e.g., limited flow table size, inflexible match/action sets) are minor compared to functional gaps such as missing operational management features (SNMP, LLDP, authentication) and poor interaction with traditional networks.

Missing Operational Management

Operators require basic management capabilities (SNMP, ping, telnet, RADIUS) that OpenFlow does not define, leading to resistance.

Interaction with Traditional Networks

SDN devices must interoperate with legacy equipment; for example, handling ARP replies locally rather than forwarding every packet to the controller, or supporting routing protocols on the switch to avoid complex controller logic.

Hybrid switches that combine OpenFlow with traditional L2/L3 processing are often the practical solution.

Recommendations for SDN Deployment

1. Recognize that SDN is not suitable for every scenario; it excels where frequent configuration changes, complex policies, or flexible forwarding are needed, such as network virtualization or Google‑style B4 routing.

2. Prioritize open and flexible north‑bound interfaces over strict south‑bound standardization, allowing each vendor to provide plugins for integration.

3. Understand OpenFlow’s role: use it where it adds value, but complement it with traditional processing for other traffic.

4. Do not aim to SDN‑ify the entire network; focus on parts that deliver business value.

5. For SDN startups, concentrate on developing SDN applications rather than building switches or controllers from scratch.

6. Evaluate devices based on programmable interface capabilities rather than specific protocol support (e.g., 12‑tuple matching).

7. Accept that SDN solutions are inherently customized; large‑scale, off‑the‑shelf deployments are unlikely.

8. Anticipate higher upfront costs due to customization, but aim for operational cost reductions.

9. Before investing, ensure the organization has a capable development team or access to third‑party services and is ready to assume the associated risks.

Conclusion

SDN should be viewed as a powerful complement to traditional networking, emphasizing openness over strict standardization. Successful adoption requires decisive leadership, willingness to customize, and a clear understanding of where SDN adds value. Learning SDN also demands solid foundational networking knowledge.