Network Service Innovation with SDN and OpenFlow

Going one level deeper into how SDN-driven traffic engineering works, there are three key aspects to a network service: aggregation (connecting many things to one), filtering (dropping or passing traffic at an aggregation point), and mirroring (copying traffic at an aggregation point). With these three OpenFlow-based building blocks, we can show how to build any service.

• Aggregation – many to one. This element helps to put like traffic onto the same pipe. In a data center, we think in terms of servers getting aggregated, or think FTTP – were we are aggregating customer premises. OpenFlow delivers this functionality innately and gives the architect many levels of freedom beyond IP and MAC addresses. For example, let’s say we want to aggregate traffic for a 5 p.m. daily DR event; this is no problem with OpenFlow.
  

• Filtering delivers on the need to separate traffic, dropping packets that do not fit the policy. Like ACLs today, OpenFlow-based filtering “black holes” bad stuff and keeps good stuff forwarding. Expanding on the example above, let’s now only send Oracle data from cabinets 1 and 2 in our data center to our DR site at 5 p.m

• Mirroring delivers on the need to copy or replicate traffic. Port mirroring does this today, but OpenFlow throws in more tricks, and would extend our DRaaS idea above by sending a copy of all that Oracle traffic to a SAN as well as ensuring that a copy gets sent onto the remote DR site.

Figure 3: Aggregation, Filtering, and Mirroring

The capability to use OpenFlow to program MPLS or BGP or to program the ASIC directly presents another degree of operational freedom. And the best path can be externally programmed into the physical network based on real-time information because OpenFlow additionally supports statistics that give providers visibility into application performance. Building intelligence into the network and leveraging the idea of central control through SDN can deliver business-driven services today.

Integrating SDN with Layer 2/Layer 3 Networking

Because Layer 2-Layer 3 networking and SDN are not mutually exclusive, it’s possible to add SDN on top of a Layer 2 or Layer 3 network. With a capability called CrossFlow Networking, users can selectively integrate OpenFlow into certain parts of their network for specific applications, while maintaining the efficiency and performance of the tried-and-true Layer 2 and Layer 3 protocols.

OpenFlow allows users to stitch in a unique path for a specific application. OpenFlow can fine-tune or override the switching or router tables in the switch. These tables are “wired” by how Layer 2 and Layer 3 protocols converge to a best path for the traffic. In some cases, that path may not be ideal for the application (for example, you may want a specific application to access data or a network service that resides somewhere else in the network). One possible solution would be to adjust the switching and routing topology to get the desired behavior, but that takes time and is disruptive. CrossFlow Networking solves this by allowing an OpenFlow rule to trigger specific behavior, and then modifying the packet appropriately to use the existing switching and routing tables. This gives users granular control to allow a specific policy to change behavior, without disrupting the topology of the existing network.