IP networks originated as private networks to handle data. IP then migrated to a carrier construct, again specifically for data transmission, often encapsulated within asynchronous transfer mode (ATM). As IP networks expanded, costs were significantly reduced; to the point that real-time applications including voice and video began moving to IP transport, using proprietary protocols. Standards-based IP protocols for voice over IP (VoIP) were then created by the International Engineering Task Force (IETF), International Telecommunication Union (ITU), 3GPP, etc. and IP quickly became the choice for enterprises and carriers (IP multimedia subsystem (IMS)/multimedia domain (MMD)).

In the beginning, the quality of VoIP was akin to poor cellular service. Overlay mechanisms were created to create classes of service to prioritize real-time traffic (resource reservation protocol (RSVP), IP Precedence, MPLS). Other overlay mechanisms were created to add security (Internet protocol security (IPSEC)/encryption/firewalls/secure real-time transport protocol (SRTP) /transport layer security (TLS)) and extend LAN functionality (VPN/MPLS/software-defined wide area networking (SD-WAN) to remote locations. More and more overhead to shape traffic; to make traffic behave within the specification of the applications, with the inevitable outcome of burdening the network and literally (overall) slowing things down, and we didn’t include things like load balancers and session border controllers.

Add more devices, multiplying security threats, huge growth in data, lack of control granularity – especially at the edge, multiple systems to coordinate and administer, and the constant user demand for quality of service (QoS) regardless of the location and available services. Yet, we have today’s network – hard to manage, provision, and secure. The idea of throwing bandwidth at everything to solve issues is not efficient or secure and quite often only masks, and sometimes magnifies, the underlying issue(s).

In IP there is also a problem that relates to applications over IP networks being able to handle “state consistent” connections. This is especially noticeable for real-time applications like VoIP and video. This is known as the Two Generals problem, a thought experiment meant to illustrate the pitfalls and design challenges of attempting to coordinate an action by communicating over an unreliable link. It further shows that even though transmission control protocol (TCP)/IP is a stateful protocol, because of the current underlying network construct, it can't guarantee state consistency between endpoints.

Within the LAN, enterprises can address these concerns; enterprises have control and are able to “tune” their LAN to properly handle the applications used. The WAN is another matter; WANs are typically not controlled by the enterprise and are not specifically tuned for their applications set. This leads to inefficiencies and lack of flexibility. In addition, carriers offer little visibility, especially past carrier meet-point ingress/egress. Security concerns are rampant, and no holistic approach has been offered. Enterprises do not drive the WAN.

The amazing news? We can address these issues without forklift upgrades or massive changes to our current infrastructure.

First, IP is a fully meshed network, i.e., there are many paths to each destination. Today’s routers do not take advantage of this built-in capability. A router today makes a judgment, based on the type of traffic it’s told it’s sending, and routes it over the best single-path available at that point in time. Two minutes later, that route may have changed to be the worst possible route, and that session or call may fail or drop completely. So, we need a technology that utilizes the multi-path nature of the fully meshed network. By doing so, we actually address the Two Generals problem mentioned previously; using a multi-path technology the “state” of the session is constantly refreshed. In addition, with proper multi-path management router failures, slowdowns can be avoided.

Second, IP can take many forms: satellite, fiber, cat5, coax cable, wireless, or dial-up. There is an inherent advantage of having multiple Internet service providers (ISPs) (resiliency and redundancy) if the solution is implemented correctly. Most solutions today offer bonding, which is a choice of sending some bits down one path and some down another, or segregating traffic to where some applications always take one route and other applications take the other. Bonding isn’t the solution. True aggregation or inverse multiplexing is a much better approach – all bandwidth is aggregated into one logical pipe, and if an ISP goes down, the size of the pipe shrinks appropriately. By having multiple ISPs, even with basic broadband connections 5-9’s uptime can be achieved.

Third, security is now a major concern in IP networks. Every technology in the market today has been hacked, it is only a matter of time. Multi-path technology also addresses security. By using multiple protocols, encrypting each path, continually rolling these paths, adding red herring information, and using byte slicing techniques, a puzzle can be created that is beyond the desire of hackers to penetrate, and they will seek easier targets.

What else do software-defined networking (SDN) networks offer? Depending on the market positioning of the SDN offering, network elements may also be part of the offered solution, and these additional pieces are very key. For example, if a carrier were to deploy SDN, they can include a cloud network element that will manage the multi-path routing through “deflects” and will hide both originating and destination IP addresses. This is a very important security piece; since the middle of the network is now the entire cloud, and the attack surface has been shifted to the cloud-based deflect elements, distributed denial of service (DDoS), and man-in-the-middle attacks can be basically eliminated.

So far, we’ve increased the efficiency of available bandwidth, increased network reliability and resiliency, added inherent state-of-the-art security, and provided inherent QoS mechanisms, including long-duration stateful sessions.

More is needed. No fork-lift upgrades, no more proprietary “boxes.” True SDN will be provided as software running on standard servers or virtualized only. The addition of SDN will be in a non-disruptive manner to allow partners to move as quickly or as slowly as their need determines. All current systems will be unaffected by the additions of SDN. Whether or not all these systems will be needed after implementing SDN, will be a decision that can be made at a future time.

SDN offerings need to be flexible as well in implementation objectives. Both Layer 2 and layer 3 products should be available to address all possible scenarios and when used in conjunction can address not only major location connectivity, but also connectivity for road-warriors, work-at-home, the Internet of Things (IoT), and supervisory control and data acquisition (SCADA). This ensures a holistic approach — the SDN offering must have options for office locations and individual devices.

Graphic provided by author

Let’s take one more look at some additional benefits SDN can offer: Session performance can now be managed all the way to the edge, even a traveling edge, regardless of carrier meet-point, while maintaining centralized policy and administration. QoS, lower latency and jitter across all applications, and increased throughput and uptime can now be provided to all users regardless of location.