The hybrid OpenFlow model allows operators to deploy SDN traffic steering using OpenFlow on top of the existing routing and switching infrastructure. Some of the main benefits of the hybrid model include:
Increased flexibility and speed for new service deployment. The Hybrid OpenFlow switching (H-OFS) model implements flexible, policy-driven, standard-based H-OFS traffic steering that allows deployment of new services and on-demand services through policy updates instead of service and infrastructure programming.
Evolutionary CAPEX/OPEX-optimized SDN deployment. The H-OFS functionality can be deployed on the existing hardware through software upgrade to realize the benefits of FlexPath programmability. The OpenFlow traffic placement is focused access only (that is, flexible, fast, on-demand service deployment) while network infrastructure provides robustness, resiliency, scale, and security.
In a basic mode of operation, a single OpenFlow Switch instance is configured on the router and controlled by a single OpenFlow controller.
The OF controllers and router exchange OF messages using the OF protocol (version 1.3.1) over the TCP/IP control channel. IPv4 and IPv6 controller addressing are supported. Both out-of-band (default) and in-band management are supported for connectivity to the controller. Transport Layer Security (TLS) is also supported on the control channel. An OF message is processed by the OF switch instance on the router that installs all supported H-OFS traffic steering rules in a flow table for the H-OFS instance. A single table per H-OFS instance is supported.
The H-OFS allows operators to:
Steer IPv4/IPv6 unicast traffic arriving on a Layer 3 interface by programming the 7450 ESS, 7750 SR, 7950 XRS, and VSR L3 PBR ACL actions.
Steer IPv4/IPv6 unicast traffic arriving on a Layer 2 interface by programming the 7450 ESS, 7750 SR, 7950 XRS, and VSR L2 PBF ACL actions.
Drop traffic by programming ACL action drop.
Forward traffic using regular processing by programming ACL action forward.
Steering actions programmed using OpenFlow are functionally equivalent to ACL actions.
The router allows operators to control traffic using OF, as follows:
An operator can select a subset of interfaces on the router to have OF rules enabled, by embedding a specific instance of H-OFS in filter policies used only by those interfaces.
For the interfaces with an H-OFS instance enabled, an operator can:
Steer all traffic arriving on an interface by programming the flow table with a ‟match all” entry.
Steer a subset of traffic arriving on an interface with this H-OFS instance enabled by programming the flow table with match rules that select a subset of traffic (OpenFlow match criteria are translated to ACL filter match criteria). Unless explicitly listed as a limitation, the SR OS H-OFS supports any OpenFlow match criteria that can be translated to ACL IPv4/IPv6 filter policy match criteria. A default rule can be assigned for packets that do not match specific rules. These packets can be dropped, forwarded, or sent to the OpenFlow controller.
To enable rules in an H-OFS on an existing service router interface, an operator must:
Create one or more ingress line card policies.
Assign those line card ingress filter policies to the 7450 ESS, 7750 SR, 7950 XRS, and VSR service router interfaces.
Embed an H-OFS instance into those line card policies.
Program OF rules as required.
OpenFlow can be embedded in IPv4/IPv6 ACL filter policies deployed on:
Layer 3 IES service interfaces
Layer 3 network interfaces in base router context
Layer 3 VPRN service interfaces, including those with NAT
Layer 2 VPLS service interfaces
IES/VPRN r-VPLS service interfaces, including those with NAT
System ACL filters
OpenFlow functionality can be enabled with no effect on forwarding performance. Operators can move from CLI/SNMP programmed steering rules to OpenFlow operational model in service without service disruption.
The control channel is routed via the GRT, meaning that the controller must be reachable via GRT, or it may be routed via a VPRN. VPRN support requires that a loopback interface corresponding to each OpenFlow switch, reachable via the VPRN, is configured in the VPRN. Then, the VPRN service ID or name and the corresponding OpenFlow control channel loopback address are specified in the OpenFlow switch control channel configuration.