Traffic Steering and OpenFlow

Many protocol combinations produce an SDN-based architecture, native OpenFlow is only one of those protocols. Some companies view OpenFlow as a core SDN design component while others don’t even include it aka BGP SDN controller and BGP SDN. The Forwarding and Control Element Separation ( ForCES) working group has spent a number of years working on mechanisms for separation of control and data plane. They created their own southbound protocol and don’t use OpenFlow to connect the data and control planes together. NEC, on the other hand, was one of the first organisations to take full advantage of the OpenFlow protocol. The markets acceptance of SDN use cases has created products that fall into an OpenFlow or non-OpenFlow bucket. The following post discusses traffic steering that outright requires OpenFlow. The OpenFlow protocol offers additional granular control to steer traffic through an ordered list of user-specific services. A task that traditional IP destination based forwarding struggles to do efficiently. OpenFlow not only offers additional flow granularity but provides topology-independent service insertion, required by network overlays, such a VXLAN.
OpenFlow Service Chaining

“User-specific services may include firewall, deep packet inspection, caching, WAN acceleration and authentication”

 

Traditional Layer 2 and Layer 3 Service Insertion

In a flat Layer 2 environment, everybody can reach each other by their MAC address. There is no IP routing. If you want to intercept traffic, the switch in the middle must intercept and forward to a service device, such as a firewall. The firewall doesn’t change anything, it’s a transparent bump in the wire. You would usually insert the same service in both directions so the firewall will see both directions of the TCP session. Service insertion at Layer 2 is achieved with VLAN chaining. For example, VLAN-1 is used on one side and VLAN-2 on the other; areas are linked by separate VLAN numbers. VLAN chaining is limited and impossible to implement for individual applications. It is also a great source of creating network loops. You may come across challenges when firewalls or other service nodes do not pass Bridge Protocol Data Unit (BPDU). Be careful to use this for large-scale service insertion production environments.

Layer 3 service insertion is much safer as forwarding is based on IP headers, not Layer 2 MAC addresses. Layer 3 IP headers have a “time-to-live” field that prevents loops from looping around the network. Layer 2 frames are redirected to a transparent or inter-subnet appliance. Meaning, the firewall device can do MAC header rewrite on layer 2 or if the firewall is placed in different subnets, the MAC rewrite would be automatic as you will be doing layer 3 forwarding. Layer 3 service insertion is typically implemented with Policy-Based Routing (PBR).

 

It’s hard to implement service insertion for appliance not close to the forwarding paths.

 

 

Traffic Steering, Service Function Chaining and Dynamic Service Insertion

Traffic steering, service function chaining and dynamic service insertion functionally mean the same thing. They want to insert networking functions in the forwarding path based on endpoints or applications. Service chaining applies a specific list of ordered services (service changing) to individual traffic flows. The main challenge point is the ability to steer traffic to the various list of devices. Such devices may be physical appliances or follow the Network Function Virtualization (NFV) format. Designing with traditional mechanisms leads to cumbersome configurations and multiple device touch points. Service appliances that need to intercept and analyse traffic could potentially be centralised in a data centre or service provider network. Service centralisation results in users traffic “tromboning” to the central service device for interaction. Traffic tromboning may not be an issue for data centre leaf and spine architecture that have equidistant endpoints. But other aggregated network designs that don’t follow the leaf and spine model may run into interesting problems. A central service network point also represents a “choking point” and may increase path latency. Service integration should be flexible and not designed with a “meet me” style architecture. Traditional routing is based on destination based forwarding and cannot provide the granularity needed for topology independent traffic steering. You may implement tricks with PBR and ACL, but they increase complexity and have vendor-specific configurations. Efficient traffic steering requires a granular “flow” level of interaction, not offered by default destination-based forwarding.

The requirement for large-scale cloud networks is driving multitenancy and network overlays are becoming the defacto technology used to meet this requirement. Network overlays require new services to be topology independent. Unfortunately, IP routing is limited and cannot distinguish between different types of traffic going to the same destination. Traffic steering based on traditional Layer 2 or Layer 3 mechanism is not efficient and does not allow for dynamic capabilities.

 

OpenFlow Service Chaining

 

A single OpenFlow rule pushed down from the central SDN controller provides the same effect as complex PBR and ACL designs. Traffic steering is accomplished with OpenFlow at an IP destination layer or IP flow layer of granularity. This greatly simplifies network operations as there is no need for PBR and ACL configurations. There is less network and component state as all the rules and intelligence is maintained at the SDN central controller. A holistic viewpoint enables singular points for configuration, not numerous touch points throughout the network. There are alternative for pushing ACL rules down to network device, such as RFC 5575, Dissemination of Flow Specification Rules. It works in conjunction with a BGP control plane (BGP flow spec) that can install rules and ACL to network devices. One major difference between BGP flow spec and OpenFlow for traffic steering is that the OpenFlow method has a central control policy. BGP flow spec consists of a number of distributed devices and any configuration changes will require multiple touch points in the network.

 

 

 

 

About Matt Conran

Matt Conran has created 184 entries.

2 Comments

Leave a Reply