5. Hybrid OpenFlow Switch

5.1. Hybrid OpenFlow Switching

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 rather than 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, and 7950 XRS L3 PBR ACL actions.
Steer IPv4/IPv6 unicast traffic arriving on a Layer 2 interface by programming the 7450 ESS, 7750 SR, and 7950 XRS 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:
1. Steer all traffic arriving on an interface by programming the flow table with a “match all” entry.
2. 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, and 7950 XRS 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:

L3 IES service interfaces
L3 network interfaces in base router context
L3 VPRN service interfaces, including those with NAT
L2 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.

5.1.1. Redundant Controllers and Multiple Switch Instances

The operator can configure one or more instances of an H-OFS (using SNMP or CLI interfaces) with each instance controlled by an OF controller over a unique OF channel using OpenFlow protocol. One OF controller can control multiple H-OFS instances using dedicated channels, or a dedicated OF controller can be deployed per switch. For each switch, up to two OF controllers can be deployed for redundancy. If two controllers are programmed, they can operate in either OFPCR_ROLE_EQUAL roles or in OFPCR_ROLE_MASTER and OFPCR_ROLE_SLAVE roles. Figure 31 shows this architecture.

Figure 31: SR OS/Switch OF Controller/Switch Architecture Overview

5.1.2. GRT-only and Multi-Service H-OFS Modes of Operations

SR OS supports two modes of operation for an H-OFS instance: GRT-only and multi-service. The modes of operation are operator-controlled per H-OFS instance by enabling or disabling the switch-defined-cookie option (config>open-flow>of-switch>flowtable 0). For backward compatibility, GRT-only mode of operation is default but, because multi-service mode is a functional superset, Nokia recommends operating in multi-service mode whenever possible. The operator can change the mode in which an H-OFS instance operates but a shutdown is required first. This purges all the rules forcing the OF controller to reprogram the switch instance after it is re-enabled in a new mode. SR OS supports both H-OFS modes of operation concurrently for different switch instances.

Multi-service modes of operation uses part of the FlowTable cookie field (higher-order 32 bits) to provide the enhanced functionality; the lower-order FlowTable cookie bits are fully controlled by the OF controller. Table 11 depicts higher-order bit Flow Table cookie encoding used when operating in the multi-service mode of operation.

Table 11: Multi-Service Mode — Higher-Order Bit Flow Table Cookie Encoding

sros-cookie Name	sros-cookie Type (Bits 63...60)	sros-cookie Value (Bits 59...32)	FlowTable Entry Interpretation Based on the sros-cookie
grt	0000	0	FlowTable rule is applicable to GRT instance (IES and router interfaces)
system	1000	0	FlowTable rule is applicable to system filters
service	1100	service-id for existing VPLS or VPRN service	FlowTable rule is applicable to an existing VPRN or VPLS service specified by the sros-cookie value

To enable multi-service mode of operation, an operator must embed the OF switch in an ACL filter policy, and, because multi-service H-OFS supports a mix of VPRN/VPLS/GRT/System rules, an additional scope of embedding must be selected (embed open-flow service, embed open-flow system - grt scope used by default). After embedding H-OFS instance, an ACL policy contains rules specific to a VPRN or VPLS service instance or to a GRT or to a System Filter Policy. Therefore, the ACL filter policy can only be used in the scope defined by H-OFS embedding.

Rules programmed by an OF controller with grt, system, and service cookies specified are accepted even if the H-OFS instance is not embedded by a filter activated in a specific context. Rules programmed by an OF controller with a service cookie specified, when the service ID is not one of the supported service types, or when the service with the specified ID does not exist, are rejected with an error returned back to the controller. If an H-OFS is embedded into a line card policy with a specific service context, the embedding must be removed before that service is deleted.

Table 12 summarizes the main differences between the two modes of operation.

Table 12: Differences Between GRT Mode and Multi-service Mode

Function	GRT Mode (no switch-defined-cookie)	Multi-service Mode (switch-defined-cookie)
Support OF on IES access interfaces	Yes	Yes
Support OF on router interfaces in GRT instance	Yes	Yes
Support OF on VPRN access and network interfaces	No (lack of native OF service virtualization)	Yes
Support OF on VPLS access and network interfaces	No (lack of native OF service virtualization)	Yes
Support port and VLAN in flowtable match (see the following section)	No	Yes
Support OF control of System ACL policies	No	Yes
Traffic steering actions	Forward, drop, redirect to LSP, Layer 3 PBR actions only	All
Scale	Up to ingress ACL filter policy entry scale	Up to OF system scale limit per H-OFS instance, and up to 64 534 entries per unique sros-cookie value

Restrictions:

Refer to the SR OS 21.x.Rx Software Release Notes for a full list of GRT/IES/VPRN/VPLS interfaces that support OF control for multi-service mode.
The 7450 ESS, 7750 SR, and 7950 XRS H-OFS always requires an sros-cookie to be provided for FlowTable operations and fails any operation without the cookie when the switch-defined-cookie command is enabled.
OF no-match-action is not programmed in hardware for system filters, because system filters are chained to other filter policies and no-match-action would break the chaining.
An H-OFS instance does not support overlapping of priorities (flow_priority value) within a single sros-cookie (type plus value). The supported values for priority differ based on a value for switch-define-cookie:
1. H-OFS with the switch-defined-cookie command disabled
  1. Valid flow_priority_range 1 to max-size – 1
  2. flow_priority_value 0 is reserved (no match action)
2. H-OFS with the switch-defined-cookie command enabled
  1. Valid flow_priority_range 1 to 65534
  2. flow_priority_value 0 is reserved (no match action)
flow_priority must map to a valid filter ID. The following items show how flow_priority is mapped to a filter policy entry ID:
1. H-OFS with switch-define-cookie disabled
  1. filter entry ID = max-size – flow_priority + embedding offset
2. H-OFS with switch-define-cookie enabled
  1. filter entry ID = 65535 – flow_priority + embedding offset
When multiple H-OFS instances are embedded into a single ACL filter, no two H-OFS instances can program the same filter entry ID.

5.1.2.1. Port and VLAN ID Match in Flow Table Entries

When operating in multi-service mode, SR OS H-OFS supports matching on port and VLAN IDs as part of Flow Table match criteria. When an OF controller specifies incoming port and VLAN values other than "ANY", the H-OFS instance translates them to an SR OS VPLS SAP (sros-cookie must be set to a valid VPLS service ID). If the translation does not result in an existing VPLS SAP, the rule is rejected and an error is returned to the controller.

A flow table rule with a port/VLAN ID match is programmed only if the matching SAP has this H-OFS instance embedded in its ACL ingress filter policy using SAP scope of embedding (embed open-flow sap). See SR OS H-OFS Port and VLAN Encoding for required encoding of port and VLAN IDs.

The SR OS H-OFS supports a mix of rules with service scope and with SAP scope. For VPLS SAPs, an H-OFS instance must be embedded twice: once for the VPLS service and once for the SAP if both service-level and SAP-level rules are to be activated.

An example of activating both service-level and SAP-level rules inside a single ACL policy 1 used on VPLS SAP 1/1/1:100 is as follows:

configure filter ip-filter 1

scope exclusive

embed open-flow "ofs1" service vpls100 offset 100

embed open-flow "ofs1" sap 1/1/1:100 offset 200

Restrictions:

Because an H-OFS instance does not support overlapping priorities within a single sros-cookie (type+value), the priority for rules applicable to different SAPs within the same VPLS service must not overlap.
Masking is not supported when adding a new flow table rule with a port and VLAN ID match.

5.1.3. Hybrid OpenFlow Switch Steering using Filter Policies

A router H-OFS instance is embedded into line card IPv4 and IPv6 filter policies to achieve OF-controlled Policy Based Routing (PBR). When H-OFS instance is created, embedded filters (IP and IPv6) required for that instance are automatically created. The filters are created with names, as follows:

“_tmnx_ofs_<ofs_name>”, with the same name for IPv4 and IPv6 filters used.

If embedded filters cannot be allocated due to the lack of filter policy instances, the creation of an H-OFS instance fails. When the H-OFS instance is deleted, the corresponding embedded filters are freed.

The H-OFS can be embedded only in ingress filter policies on line cards/platforms supporting embedded filters and for services supporting H-OFS. Embedding of an H-OFS in filter policies on unsupported services is blocked. Embedding of an H-OFS in filter policies in unsupported direction or on unsupported hardware follows the general filter policy misconfiguration behavior and is not recommended. Unsupported match fields are ignored. Other match criteria may cause a packet to match an entry.

As soon as an H-OFS instance is created, the controller can program OF rules for that instance. For instance, the rules can be created prior to the H-OFS instance embedding into a filter policy or prior to a filter policy with H-OFS instance embedded being assigned to an interface. This allows the operator to either pre-program H-OFS steering rules, or to disable the rules without removing them from a flow table by removing the embedding. An error is returned to the controller if it attempts to program rules not supported by the system. The following lists examples of the errors returned:

unsupported instr: [OFPET_BAD_INSTRUCTION, OFPBIC_UNSUP_INST]
unsupported action: [OFPET_BAD_ACTION, OFPBAC_BAD_TYPE]?
unsupported output port: [OFPET_BAD_ACTION, OFPBAC_BAD_OUT_PORT]?
unsupported match field: [OFPET_BAD_MATCH, OFPBMC_BAD_FIELD]?
unsupported match value: [OFPET_BAD_MATCH, OFPBMC_BAD_VALUE]?
output port invalid/deleted after flow_mod is sent to filter: OFPET_BAD_ACTION, OFPBAC_BAD_OUT_PORT]?

When the OF controller updates traffic steering rules, the Hybrid OpenFlow Switch updates the flow table rules. This automatically triggers programming of the embedded filter, which consequently causes instantiation of the rules for all services/interfaces that have a filter policy embedding this H-OFS instance. Embedded filter policy configuration/operational rules apply also to embedded filters auto-created for an H-OFS instance (see Embedded Filter Support for ACL Filter Policies section of this guide). MPLS cannot be deleted if OFS rules are created that redirect to an LSP.

The auto-created embedded filters can be viewed through CLI but cannot be modified and/or deleted through filter policy CLI/SNMP. The operator can see the above embedded filters under show filter context, including the details about the filters, entries programmed, interface association, statistics, and so on.

Figure 29 shows the H-OFS to service operator-configurable mapping example.

For an H-OFS with the switch-defined-cookie command enabled, embedded filters are created for each unique context in the H-OFS instead.

Figure 32: OF Flow Table Mapping to Router/Switch Service Infrastructure Example — switch-defined-cookie Disabled

The router allows mixing H-OFS rules from one or more H-OFS instances in a single filter policy. Co-existence of H-OFS rules in a single policy with CLI/SNMP programmed rules and/or BGP FlowSpec programmed rules in a single line card filter policy is also supported. When a management interface and an OF controller flow entry have the same filter policy entry, the management interface-created entry overrides the OF controller-created entry; see the embedded filter functional description. For mixing of the rules from multiple management entities, the controller should not program an entry in its Flow Table that would match all traffic, because this would stop evaluation of the filter policy.

The router supports HA for the OF Flow Table content and statistics. On an activity switch, the channel goes down and is reestablished by the newly active CPM. “Fail secure mode” operation takes place during channel reestablishment (OpenFlow rules continue to be applied to the arriving traffic). The OF controller is expected to resynchronize the OF table when the channel is reestablished. On a router reboot or H-OFS instance shutdown, H-OFS Flow Table rules and statistics are purged. An H-OFS instance cannot be deleted unless the H-OFS instance is first removed from all embedding filter policies.

5.1.4. Hybrid OpenFlow Switch Statistics

The SR OS Hybrid OpenFlow switch supports statistics retrieval using the OpenFlow protocol. There are two types of statistics that can be collected:

Statistics for SR OS H-OFS logical ports
Logical port statistics are available for RSVP-TE and MPLS-TP LSP logical ports. The non-zero statistics are returned as long as an LSP has statistics enabled through an MPLS configuration.
Zero is always returned for logical port statistics for SR-TE LSPs when LSP statistics are not supported on SR-TE LSPs. The statistics can be retrieved regardless of whether an OF switch uses the specified LSP. The returned packet/bytes values are an aggregate of all packets/bytes forwarded over the LSP.
Statistics are not available for any other logical ports encodings.
Statistics for SR OS H-OFS flow table
Flow table statistics can be retrieved for one or more flow table entries of an H-OFS. The returned packet/bytes values are based on ACL statistics collected in the hardware. An OpenFlow controller can retrieve statistics either directly from hardware or from the ACL CPM-based bulk request cache. The ACL cache is used when processing an OpenFlow statistics multi-part aggregate request message (OFPMP_AGGREGATE), or when an OpenFlow statistics multi-part flow message request (OFPM_FLOW) is translated to multiple flow table entries (a bulk request). When an OpenFlow multi-part flow statistics request message (OFPM_FLOW) is translated to a single flow table entries request (a single entry request), the counters are read from hardware in real time.
A mix of the two methods can be used to retrieve some flow table statistics from hardware in real time while retrieving other statistics from the cache. See Filter Policy Statistics for more information about ACL cache and ACL statistics.
When the auxiliary channel is enabled, the switch sets up a dedicated auxiliary channel for statistics. See OpenFlow Switch Auxiliary Channels for more information.

Operational Notes:

Flow table statistics displayed through the CLI debugging tools (tools>dump>open-flow>of-switch) are read in real time from hardware. However, to protect the system, executing CLI debugging tool commands within 5 s returns the same statistics for any flow that had its statistics read from hardware within the last 5 s.
When retrieving flow table statistics at scale, Nokia recommends to either use bulk requests, or to pace single entry requests in order to obtain the desired balance between stats real-time accuracy and CPM activity.

5.1.5. OpenFlow Switch Auxiliary Channels

The H-OFS supports auxiliary channels, as defined in OpenFlow version 1.3.1. The packet-in and statistics functions are supported on the auxiliary channels as well as on the main channel.

When the auxiliary channel is enabled on a switch (using the aux-channel-enable command), the switch sets up a dedicated auxiliary channel for statistics (Auxiliary ID 1) and a dedicated auxiliary channel for packet-in (Auxiliary ID 2) if a packet-in action is configured, to every controller for a given H-OFS switch instance. Auxiliary connections use the same transport as the main connection. The switch handles any requests over any established channel and respond on the same channel even if a specific requested auxiliary channel is available.

The H-OFS instance uses the packet-in connection for packet-in functionality by default and expects (but does not require) the controller to use the statistics channel for statistics processing by default.

The switch uses the auxiliary channels (packet-in for packet-in-specific requests and statistics for statistics-specific requests) as long as they are available. If they are not available, the switch uses the next available auxiliary channel. If none of the auxiliary channels are available, the main channel is used.

Auxiliary connections can be enabled or disabled without shutting down the switch.

5.1.6. Hybrid OpenFlow Switch Traffic Steering Details

As described in the previous section, an update to an OpenFlow Switch’s flow table results in the embedded filter updates, which triggers an update to all filter policies embedding those filters. The router automatically downloads the new set of rules to the line cards as defined through service configuration. The rules become part of an ingress line card pipeline, as shown in Figure 33.

Figure 33: OpenFlow Switch Embedding in Ingress Pipeline Processing

5.1.6.1. SR OS H-OFS Logical Port

Logical ports are used in OpenFlow to encode switch-specific ports. SR OS H-OFS uses logical ports in steering actions by encoding PBR targets. Table 13 lists logical port types supported by SR OS H-OFS:

Table 13: Encoding and Supported Logical Port Types

Bits 31..28	Bits 27..24	Bits 24..0
Logical port type (LPT)	Logical port type sub-type (LPT-S)	Logical port type value (LPT-V) — always padded with leading zeros

The following encoding sample shows logical port types supported by SR OS H-OFS:

RSVP LSP: LPT: 0100, LPT-S: 0000 (tunnel), LPT-V: RSVP TE Tunnel ID

MPLS-TP LSP: LPT: 0100, LPT-S: 0000 (tunnel), LTP-V: MPLS-TP Tunnel Number

SR-TE LSP: LPT: 0100, LPT-S: 0000 (tunnel), LTP-V: SR-TE LSP Index

GRT instance: LPT: 0100, LPT-S: 0001 (L3 routing instance), LPT-V: 0

VPRN Id: LPT: 0100, LPT-S: 0001 (L3 routing instance), LPT-V: VPRN Service ID for a

VPRN instance configured on the system, NAT: LPT 0100, LPT-S: 0020 (NAT), LPT-V: 0

OF is limited to a 24-bit service ID value range (a subset of VPRN IDs supported by the SR OS system).

Logical port values other than RSVP-TE LSP, SR-TE LSP, and MPLS-TP LSP require H-OFS with the switch-defined-cookie command enabled. Only tunnel-encoded ports are stored in the H-OFS logical port table. Therefore, functionality such as retrieving statistics per port is not available for logical ports that are not stored in the H-OFS logical port table.

5.1.6.2. SR OS H-OFS Port and VLAN Encoding

The OF controller can use port and VLAN values other than “ANY” for VPLS SAP match and for VPLS steering to SAP for H-OFS instances with the switch-defined-cookie command enabled.

To specify a port in an OF message, SR OS TmnxPortId encoding must be used. The allowed values are those for Ethernet physical ports and LAG.

To encode VLAN tags, OXM_OF_VLAN_ID and new experimenter OFL_OUT_VLAN_ID fields are used as shown in Table 14.

Table 14: VLAN Tag Encoding

NULL tag, dot1Q tag, inner QinQ tag VlanId	Outer QinQ tag VlanId
OXM_OF_VLAN_VID	OFL_OUT_VLAN_ID (Experimenter field uses same encoding as OXM_OF_VLAN_VID)

Table 15 shows how OF programmed values are translated to SR OS SAPs.

Table 15: Translation of OF Programmed Values to SR OS SAPs

OXM_OF_IN_PORT	OXM_OF_VLAN_VID	OFL_OUT_VLAN_ID	Matching SAP SR OS Encoding	Supported in flow_add	Supported in flow_mod flow_del mp_req	Comment
TmnxPortId for port or LAG	Value: 0x0000 Mask: Absent	Must be absent	port-id lag-id	✓	✓	Mask must be absent
TmnxPortId for port or LAG	Value: 0x1yyy, yyy encodes qtag1 Mask: Absent	Must be absent	port-id:qtag1 lag-id:qtag1	✓	✓	Mask must be absent
TmnxPortId for port or LAG	Value: 0x1FFF Mask: Absent	Must be absent	port-id:* lag-id:*	✓	✓	Mask must be absent
TmnxPortId for port or LAG	Value: 0x1000 Mask: 0x1000	Must be absent	port-id: any lag-id: any where "any" is either * or a valid VLAN-ID (but not NULL)		✓	Mask must be 0x1000
TmnxPortId for port or LAG	Value: 0x1yyy, yyy encodes qtag2 Mask: Absent	Value: 0x1zzz, zzz encodes qtag1 Mask: Absent	port-id:qtag1.qtag2 lag-id:qtag1.qtag2	✓	✓	Mask must be absent
TmnxPortId for port or LAG	Value: 0x1FFF Mask: Absent	Value: 0x1zzz, zzz encodes qtag1 Mask: Absent	port-id: qtag1.* lag-id: qtag1.*	✓	✓	Mask must be absent
TmnxPortId for port or LAG	Value: 0x1FFF Mask: Absent	Value: 0x1FFF Mask: Absent	port-id: . lag-id: .	✓	✓	Mask must be absent
TmnxPortId for port or LAG	Value: 0x1000 Mask: 0x1000	Value: 0x1zzz, zzz encodes qtag1 Mask: Absent	port-id: qtag1.any lag-id: qtag1.any where any is either * or a valid VLAN-ID (but not NULL)		✓	Mask must be absent for OFL_OUT_VLAN_VID
TmnxPortId for port or LAG	Value: 0x1000 Mask: 0x1000	Value: 0x1FFF Mask: Absent	port-id: .any lag-id: .any where "any" is either * or a valid VLAN-ID (but not NULL)		✓	Mask must be absent for OFL_OUT_VLAN_VID
TmnxPortId for port or LAG	Value: 0x1000 Mask: 0x1000	Value: 0x1000 Mask: 0x1000	port-id: any.any lag-id: any.any where "any" is either * or a valid VLAN-ID (but not NULL)		✓	Masks must be 0x1000
TmnxPortId for port or LAG	Value: 0x0000 Mask: Absent	Value: 0x1FFF Mask: Absent	port-id: *.null	✓	✓	Mask must be absent

5.1.6.3. Redirect to IP next-hop

A router supports redirection of IPv4 or IPv6 next-hop for traffic arriving on a Layer 3 interface. An OF controller can rely on this functionality and program PBR next-hop steering actions for H-OFS instances with the switch-defined-cookie command enabled using the following OF encoding:

ALU_IPD_EXPERIMENTER_ID: 0x000025BA

ALU_AXN_REDIRECT_TO_NEXTHOP: 2

flow_mod:

instruction= OFPIT_WRITE_ACTION/OFPIT_APPLY_ACTION,

action= OFPAT_EXPERIMENTER(ALU_AXN_REDIRECT_TO_NEXTHOP),

encoding:

struct alu_axn_redirect_to_nhopv4{

uint16_t type; /* OFPAT_EXPERIMENTER. */

uint16_t len; /* Total Length is a multiple of 8. */

uint32_t experimenter; /* Experimenter ID vendor unique*/

uint8_t redirect_type; /* Type = 1 for Nhop*/

uint8_t flags; /* flags is 0-7 bits:

Bit 0 = Ipv4,

Bit 1 = Ipv6,

Bit 2 = indirect

uint8_t pad[2];

uint32_t ipaddr; /* ipv4 addr */

unit8_t pad[0]; /* Not needed */

}; ASSERT(sizeof(alu_axn_redirect_to_nhopv4) == 16)

struct alu_axn_redirect_to_nhopv6{

uint16_t type; /* OFPAT_EXPERIMENTER. */

uint16_t len; /* Total Length is a multiple of 8. */

uint32_t experimenter; /* Experimenter ID vendor unique*/

uint8_t redirect_type; /* Type = 1 for Nhop*/

uint8_t flags; /* flags is 0-7 bits:

Bit 0 = Ipv4,

Bit 1 = Ipv6,

Bit 2 = indirect

uint8_t pad[2];

uint128_t ip6addr; /* ipv6 addr */

unit8_t pad[4]; /* Make total len multiple of 8 */

}; ASSERT(sizeof(alu_axn_redirect_to_nhopv6) == 32)

In case of erroneous programming, the following experimenter-specific errors are returned to the controller:

enum alu_err_exp_class{

ALU_ERR_CLASS_RD_TO_SDP = 0,

ALU_ERR_CLASS_RD_TO_NHOP = 1,

}

enum alu_err_subtype_redirect_to_nhop

{

ALU_ERR_RN_INVALID_FLAGS = 0

ALU_ERR_RN_INVALID_ARGS = 1

ALU_ERR_RN_INVALID_ADDR = 2

}

5.1.6.4. Redirect to GRT Instance or VRF Instance

A router supports redirection of IPv4 or IPv6 traffic arriving on a Layer 3 interface to a different routing instance (GRT or VRF). An OF controller can rely on this functionality and program PBR actions for GRT/VRF steering for H-OFS instances with the switch-defined-cookie command enabled using the following OF encoding:

flow_mod:

instruction type: OFPIT_WRITE_ACTIONS/OFPIT_APPLY_ACTION,

action type: OFPAT_OUTPUT,

port= SR OS LOGICAL port encoding GRT or VPRN Service ID as described in the SR OS H-OFS Logical Port section.

Because a 24-bit value is used to encode the VPRN service ID in the logical port, redirection to a VPRN service with a service ID above that range is not supported.

5.1.6.5. Redirect to Next-hop and VRF/GRT Instance

A router supports redirection of IPv4 or IPv6 traffic arriving on a Layer 3 interface to a different routing instance (GRT or VRF) and next-hop IP at the same time. An OF controller can rely on this functionality and program PBR steering action for H-OFS instances with the switch-defined-cookie command enabled using the following OF encoding:

ALU_IPD_EXPERIMENT_ID:0X000025BA

ALU_AXN_REDIRECT_TO_NEXTHOP:2

flow_mod:

Instruction 1:

instruction=OFPIT_WRITE_ACTION/OFPIT_APPLY_ACTION

action=OFPAT_EXPERIMENTER(ALU_AXN_REDIRECT_TO_NEXTHOP),

Encoding as described in the Redirect to IP next-hop section (indirect flag must be set).

Instruction 2:

instruction type: OFPIT_WRITE_ACTIONS/OFPIT_APPLY_ACTION,

action type: OFPAT_OUTPUT,

port= SR OS LOGICAL port encoding GRT or VPRN Service ID as described in the SR OS H-OFS Logical Port section.

5.1.6.6. Redirect to ESI (L2)

The router supports redirection of IPv4/IPv6 traffic arriving on a Layer 2 interface to an Ethernet Segment Identifier (ESI) with an EVPN control plane. An OF controller can program Layer 2 ESI steering with the switch-defined-cookie command enabled using the following OF encoding:

flow_mod:

instruction type: OFPIT_WRITE_ACTIONS/OFPIT_APPLY_ACTION,

action type: OFPAT_EXPERIMENTER(ALU_AXN_REDIRECT_TO_ESI_L2)

encoding:

struct alu_axn_redirect_to_ESI_L2{

uint16_t type; /* OFPAT_EXPERIMENTER. */

uint16_t len; /* Total Length is a multiple of 8. */

uint32_t experimenter; /* Experimenter ID vendor unique*/

uint8_t redirect_type ; /* Type = 3 for ESI*/

uint8_t flags; /* flags is 0-7 bits:

Value 0 = L2,

uint8_t esi[10]; /* 10 byte ESI */

uint32_t svcId; /* Svc-Name Using the OF Encoding */

}; ASSERT(sizeof(alu_axn_redirect_to_ESI_L2) == 24)

5.1.6.7. Redirect to ESI (L3)

The router supports redirection of IPv4/IPv6 traffic arriving on a Layer 3 interface to an ESI with an EVPN control plane. An OF controller can program L3 ESI steering with the switch-defined-cookie command enabled using the following OF encoding:

flow_mod:

instruction type: OFPIT_WRITE_ACTIONS/OFPIT_APPLY_ACTION,

action type: OFPAT_EXPERIMENTER(ALU_AXN_REDIRECT_TO_ESI_L3)

encoding:

struct alu_axn_redirect_to_ESI_L3_V4{

uint16_t type; /* OFPAT_EXPERIMENTER. */

uint16_t len; /* Total Length is a multiple of 8. */

uint32_t experimenter; /* Experimenter ID vendor unique*/

uint8_t redirect_type ; /* Type = 3 for ESI*/

uint8_t flags; /* flags is 0-7 bits:

Value 1 = L3 (ipv4)

uint8_t esi[10]; /* 10 byte ESI */

uint32_t svcId; /* Svc-Name Using the OF Encoding */

uint32_t sf-ip; /* v4 address of sf-ip */

uint32_t ifIndex; /* interface id*/

}; ASSERT(sizeof(alu_axn_redirect_to_ESI_L3_V42) == 32)

struct alu_axn_redirect_to_ESI_L3_V6{

uint16_t type; /* OFPAT_EXPERIMENTER. */

uint16_t len; /* Total Length is a multiple of 8. */

uint32_t experimenter; /* Experimenter ID vendor unique*/

uint8_t redirect_type ; /* Type = 1 for Nhop*/

uint8_t flags; /* flags is 0-7 bits:

Value = 2 = L3 (ipv6)

uint8_t esi[10]; /* 10 byte ESI */

uint32_t svcId; /* Svc-Name Using the OF Encoding */

uint128_t sf-ip; /* v6 address of sf-ip */

uint32_t ifIndex; /* interface id*/

uint8_t pad[4];

}; ASSERT(sizeof(alu_axn_redirect_to_ESI_L3_V6) == 48)

5.1.6.8. Redirect to ESI IP VAS-Interface Router

The router supports redirection of IPv4/IPv6 traffic arriving on a Layer 3 interface to a VAS interface bound to an ESI with an EVPN control plane. In this encoding, the SF-IP address represents the VAS interface address, and the ifIndex is the VAS interface ID. An OF controller can program L3 steering with the switch-defined-cookie command enabled using the following OF encoding:

flow_mod:

instruction type: OFPIT_WRITE_ACTIONS/OFPIT_APPLY_ACTION,

action type: OFPAT_EXPERIMENTER(ALU_AXN_REDIRECT_TO_ESI_L3)

encoding:

struct alu_axn_redirect_to_ESI_L3_V4{

uint16_t type; /* OFPAT_EXPERIMENTER. */

uint16_t len; /* Total Length is a multiple of 8. */

uint32_t experimenter; /* Experimenter ID vendor unique*/

uint8_t redirect_type ; /* Type = 2 for ESI*/

uint8_t flags; /* flags is 0-7 bits:

Value 2 = L3 (ipv4)

uint8_t esi[10];

uint32_t svcId; /* Svc-Name Using the OF Encoding */

uint32_t vas-ip; /* v4 address of sf-ip */

uint32_t ifIndex; /* vas interface id*/

}; ASSERT(sizeof(alu_axn_redirect_to_ESI_L3_V4) == 24)

struct alu_axn_redirect_to_ESI_L3_V6{

uint16_t type; /* OFPAT_EXPERIMENTER. */

uint16_t len; /* Total Length is a multiple of 8. */

uint32_t experimenter; /* Experimenter ID vendor unique*/

uint8_t redirect_type ; /* Type = 2 for ESI*/

uint8_t flags; /* flags is 0-7 bits:

Value 4 = L3 (ipv6)

uint8_t esi[10]; /* 10 byte ESI */

uint32_t svcId; /* Svc-Name Using the OF Encoding */

uint128_t vas-ip; /* v6 address of sf-ip */

uint32_t ifIndex; /* vas interface id*/

uint8_t pad[4]

}; ASSERT(sizeof(alu_axn_redirect_to_ESI_L3_V6) == 40)

5.1.6.9. Redirect to LSP

The router supports traffic steering to an LSP. The following shows the OF encoding to be used by an OF controller:

flow_mod:

instruction type: OFPIT_WRITE_ACTIONS or OFPIT_APPLY_ACTION,

action type: OFPAT_OUTPUT,

The port uses SR OS LOGICAL port encoding RSVP-TE, SR-TE, or MPLS-TP LSP as described in the SR OS H-OFS Logical Port section.

An LSP received in a flow rule is compared against those in the H-OFS logical port table. If the table does not contain the LSP, the rule programming fails. Otherwise, the rule is installed in an ACL filter. As long as any path within the LSP is UP, the redirect rule forwards unicast IPv4 or IPv6 traffic on the current best LSP path by adding an LSP transport label and, in the case of IPv6 traffic, also adding an explicit NULL label.

When an LSP in the H-OFS logical port table goes down, the OF switch removes the LSP from its logical port table and notifies the controller of that fact if the logical port status reporting is enabled. It is up to the OF controller to decide whether to remove rules using this LSP. If the rules are left in the flow table, the traffic that was to be redirected to this LSP instead is subject to a forward action for this flow rule. If the controller does not remove the entries and the system reuses the LSP identified for another LSP, the rules left in the flow table start redirecting traffic onto this new LSP.

In some deployments, an SDN controller may need to learn from the router H-OFS logical ports status. To support this function, the OF switch supports optional status reporting using asynchronous OF protocol messages for ports status change.

5.1.6.10. Redirect to NAT

The router supports redirection of IPv4 traffic arriving on a Layer 3 interface for ISA NAT processing. An OF controller can program NAT steering for H-OFS instances with the switch-defined-cookie command enabled using the following OF encoding:

flow_mod:

instruction type: OFPIT_WRITE_ACTIONS/OFPIT_APPLY_ACTION,

action type: OFPAT_OUTPUT,

The port uses SR OS LOGICAL port encoding as described in the SR OS H-OFS Logical Port section.

5.1.6.11. Redirect to SAP

For traffic arriving on a VPLS interface, a router supports PBF to steer traffic over another VPLS SAP in the same service. An OF controller can rely on this functionality and program PBF steering action for H-OFS instances with the switch-defined-cookie command enabled using the following OF encoding:

flow_mod:

instruction type: OFPIT_WRITE_ACTIONS or OFPIT_APPLY_ACTION,

Action 1:

action type: OFPAT_OUTPUT,

The port uses encoding as described in the SR OS H-OFS Port and VLAN Encoding section.

Action 2:

action type=OFPAT_SET_FIELD

OXM TLVs encode SAP VLANs as described in the SR OS H-OFS Port and VLAN Encoding section:

- OXM_OF_VLAN_VID

- OFL_OUT_VLAN_ID (optional)

5.1.6.12. Redirect to SDP

For traffic arriving on a VPLS interface, a router supports PBF to steer traffic over a VPLS SDP in the same service. An OF controller can rely on this functionality and program PBF steering action for H-OFS instances with switched-defined-cookie enabled using the following OF encoding:

ALU_IPD_EXPERIMENTER_ID: 0x000025BA

ALU_AXN_REDIRECT_TO_SDP: 1

flow_mod:

instruction= OFPIT_WRITE_ACTIONS/OFPIT_APPLY_ACTIONS,

action= OFPAT_EXPERIMENTER(ALU_AXN_REDIRECT_TO_SDP),

encoding:

struct alu_axn_redirect_to_sdp{

uint16_t type; /* OFPAT_EXPERIMENTER. */

uint16_t len; /* Total Length is a multiple of 8. */

uint32_t experimenter; /* Experimenter ID vendor unique*/

uint8_t redirect_type; /* Type = 0 for SDP*/

uint8_t flags; /

* Flags that can be used to denote info(reserved)*/

uint16_t sdp-id; /* Sdp-id*/

uint32_t vcId; /* Vc-id*/

unit8_t pad[0]; /* Not needed */

}; ASSERT(sizeof(alu_axn_redirect_to_sdp) == 16)

In case of erroneous programming, the following experimenter-specific errors are returned to the controller:

enum alu_err_exp_class

{

ALU_ERR_CLASS_RD_TO_SDP = 0,

ALU_ERR_CLASS_RD_TO_NHOP = 1,

}

enum alu_err_redirect_to_sdp

{

ALU_ERR_RS_INVALID_FLAGS = 0

ALU_ERR_RS_INVALID_ARGS = 1

ALU_ERR_RS_INVALID_SDP_ID = 2

ALU_ERR_RS_INVALID_VC_ID = 3

}

5.1.6.13. Redirect to a Specific LSP Used by a VPRN Service

The router supports traffic steering within a VPRN, enabling the transport tunnels used by the SDP to be used for specific flows redirected from the system-selected default. This redirection enables large bandwidth flows to be moved to an alternative LSP.

For matching ingress traffic on a VPRN, the switch-defined-cookie command must be enabled, with the cookie encoded to match the ingress VPRN’s service ID.

Traffic can be redirected to the following:

the default PE and a different LSP
a different PE and the default LSP
the default PE and the default LSP (traffic that may otherwise egress a SAP takes a specified BGP next hop)
the default PE and a different VRF
a different PE, the default LSP, and a different prefix

Parameters must be matched in the OF encoding to steer traffic.

flow_mod:

instruction type: OFPIT_WRITE_ACTIONS/OFPIT_APPLY_ACTION,

Action 1:

action type: OFPAT_EXPERIMENTER

ALU_IPD_EXPERIMENTER_ID: 0x000025BA

ExpType= ALU_AXN_REDIRECT_TO_NEXTHOP,

Action 2:

action type: OFPAT_OUTPUT,

port= SR OS LOGICAL port encoding RSVP-TE, MPLS-TP LSP, or segment routing, as described in SR OS H-OFS Logical Port section.

Action 3 (optional): to redirect to a different VPRN

Action 3:

action type: OFPAT_EXPERIMENTER

ALU_IPD_EXPERIMENTER_ID: 0x000025BA

ExpType= ALU_AXN_REDIRECT_TO_VPRN,

Encoding:

struct alu_axn_redirect_to_vprn {

uint16_t type; /* OFPAT_EXPERIMENTER => ff ff */

uint16_t len;

uint32_t experimenter; /

* Vendor specific experimenter id => 00 00 25 ba */

uint8_t exp_axn_type; /* type => 03 */

uint8_t exp_axn_flags; /* flag => any value is accepted */

uint8_t pad[2]; /* pad => 00 00 */

uint32_t vprn; /* vrpn svc id */

};ASSERT(sizeof(alu_axn_redirect_to_vprn) == 16)

Action 4 (optional): to redirect to a different prefix

Action 4:

action type: OFPAT_SET_FIELD

Field is an IP destination address. Subnet masks are not supported in the set_field instruction.

5.1.6.14. Forward Action

An OF controller can program forward action, when a specific flow is to be forwarded using regular router forwarding. This would be a default behavior if the filter-policy embedding this OF switch instance has a default-action forward and no filter policy rule matches the flow. To implement forward action, the following OF encoding is used:

flow_mod:

instruction type: OFPIT_WRITE_ACTIONS or OFPIT_APPLY_ACTION,

action type: OFPAT_OUTPUT,

port= NORMAL

where NORMAL is an OF reserved value.

5.1.6.15. Drop Action

An OF controller can program a drop action, when packets of a specific flow are to be dropped. To implement a drop action, the OF encoding is a wildcard rule with empty action-set.

5.1.6.16. Default No-match Action

Packets that do not match any of the flow table entries programmed by the controller are subject to a default action. The default action is configurable in the CLI using the no-match-action command. Three possible no-match actions are supported: drop, fall-through (packets are forwarded with regular processing by the router), and packet-in.

The packet-in action causes packets that do not match entries in the flow table, as programmed by the OpenFlow controller, to be extracted and sent to the controller in a flow-controlled manner. Because EQUAL is supported, packet-in messages are sent to all controllers in the UP state. To protect the controller, only the first packet of a specific 5-tuple flow (source IP address, destination IP address, source port, destination port, protocol) to which the no-match action is applied is sent to the controller. This 5-tuple flow context ages out after 10 s. Each switch instance maintains contexts for up to 8192 outstanding packet-in messages to the controller. If the packet-in action is used, an auxiliary channel should be enabled for packet-in processing (using the aux-channel-enable command). A count of packets to which packet-in is applied is also available through the OpenFlow channel statistics.

5.1.6.17. Programming of DSCP Remark Action

The router supports DSCP remarking of IPv4/IPv6 packets arriving on VPLS, VPRN, GRT, and system interfaces for OFS instances with the switch-defined-cookie command enabled using the following OF encoding:

flow_mod:

instruction type: OFPIT_METER

action type: with the meterId.

The meters are configured using meter modification messages, and are configured before the flow messages are sent with meter instruction:

typedef struct tOfpMeterModMsg

{

tOfpMsgHeader msgHdr;

uint16_t mtrCommand; /* One of OFP_MTR_CMD_*. */

uint16_t mtrConfig; /* bitmap of OFP_MTR_CFG_*. */

uint32_t mtrId; /* Meter instance. */

tOfpMeterBandHeader bands[0]; /* The band list length is inferred from

the length field in the msgHdr. */

} tOfpMeterModMsg;

typedef struct tOfpMeterBandHeader

{

uint16_t bandType; /* One of OFP_MTR_BAND_*. */

uint16_t length; /* Length in bytes of this band. */

uint32_t rate; /* Rate for this band. */

uint32_t burstSize; /* Size of bursts. */

} tOfpMeterBandHeader;

typedef enum eOfpMeterBandType

{

OFP_MTR_BAND_DROP = 1, /* Drop packet. */

OFP_MTR_BAND_DSCP_REMARK = 2, /* Remark DSCP in the IP header. */

OFP_MTR_BAND_EXPERIMENTER = 0xFFFF /* Experimenter meter band. */

} eOfpMeterBandType;

typedef struct tOfpMeterBandDscpRemark

{

tOfpMeterBandHeader bandHdr; /* OFP_MTR_BAND_DSCP_REMARK */

uint8_t precLevel; /* Number of drop precedence level to add */

uint8_t pad[3];

} tOfpMeterBandDscpRemark;

5.1.7. Support for Secondary Actions for PBR/PBF Redundancy

The router supports “primary and secondary action” for filters (see Primary and Secondary Filter Policy Action for PBR/PBF Redundancy). OpenFlow programming for multiple filter actions is also supported, as follows:

Layer 2 PBF redundancy: 2 PBF actions (SAP/SDP) with optional sticky destination and pbr-on-down

Layer 3 PBR redundancy: 2 PBR actions (IP next-hop and VRF) with optional sticky destination and pbr-on-down

Layer 3 PBR redundancy: 2 PBR actions (next-hop and VRF) with optional sticky destination and pbr-on-down, with DSCP remarking as an extended action

The router supports multi-action using the OpenFlow version 1.3.1 Required Action: Group (For more details, refer to Section 6.4, Flow Table Modification Messages, Section 6.5, Group Table Modification Messages, and Section 5.6.1, Group Types with group type of fast failover of the TS-007, OpenFlow Switch Specification Version 1.3.1 (OpenFlow-hybrid switches)).

Redundancy uses fast failover group modeling as per the OpenFlow specification with two buckets, with liveliness detection provided by the filter module. Note that failover operates independently of the OpenFlow controller.

The router supports the programming of pbr-on-down-override and sticky destination using an experimenter, as follows:

instruction type: OFPIT_WRITE_ACTIONS/OFPIT_APPLY_ACTION,

action type: OFPAT_EXPERIMENTER(ALU_AXN_PBFPBR_REDUNDANCY)

encoding:

struct alu_axn_PBFPBR_Redundancy{

uint16_t type; /* OFPAT_EXPERIMENTER. */

uint16_t len; /* Total Length is a multiple of 8. */

uint32_t experimenter; /* Experimenter ID vendor unique*/

uint8_t redirect_type ; /* Type = 4 for PBR/PBF redundancy*/

uint8_t flags; /* flags is 0-7 bits:

Bit 0 for pbr-down-action-override

Bit 1 for sticky-dest

uint32_t portId; /* to specify pbr-down action portId 0

for drop, OFP_PORT_ID_NORMAL for forward

OFP_PORT_ID_ANY for filter-default-action

uint32_t holdTime; /* Value between 0-65535 seconds for

sticky dest */

};

5.2. Configuration Notes

The following information describes OF implementation restrictions:

SR OS Hybrid OpenFlow Switch requires a software upgrade only and can be enabled on any switch. For full functionality, performance, and future scale, IOM3-XP or newer line cards and CPM4 or newer control cards are recommended.
Some platforms may not support all OF functionality based on the underlying hardware. For example, if the underlying hardware does not support IPv6, OF IPv6 functionality is not supported. If the underlying hardware does not support redirect to LSP, redirect action is ignored.
Each flow in an OF flow table must have unique priority. Overlap is not supported.
Timed expiry of the flow entries is not supported.
The implementation is compliant by design with OpenFlow specification as applicable to supported router functionality only.