Hybrid OpenFlow switch

Hybrid OpenFlow switching

The hybrid OpenFlow model allows users 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 users 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 users to control traffic using OF, as follows:

  • A user 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, a user 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, a user must:

  1. Create one or more ingress line card policies.

  2. Assign those line card ingress filter policies to the 7450 ESS, 7750 SR, 7950 XRS, and VSR service router interfaces.

  3. Embed an H-OFS instance into those line card policies.

  4. 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. Users 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.

Redundant controllers and multiple switch instances

The user 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 1. SR OS/switch OF controller/switch architecture overview

GRT-only and multi-service H-OFS modes of operations

SR OS supports two modes of operation for an H-OFS instance:

  • GRT-only
  • multi-service

The modes of operation are user-controlled per H-OFS instance by enabling or disabling the switch-defined-cookie option. Use the command in the following context to enable the switch-defined-cookie option:

  • MD-CLI

    configure openflow of-switch flowtable
  • classic CLI

    configure open-flow of-switch flowtable

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 user can change the mode in which an H-OFS instance operates; however, the H-OFS instance must be administratively disabled 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. Multi-service mode — higher-order bit flow table cookie encoding depicts higher-order bit Flow Table cookie encoding used when operating in the multi-service mode of operation.

Table 1. 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, a user must embed the OF switch in an ACL filter policy, and because multi-service H-OFS supports a mix of VPRN, VPLS, GRT, and system rules, an additional scope of embedding must be selected.

Use the commands in the following contexts to embed the OF switch in an ACL filter policy. (GRT scope is used by default.)

  • MD-CLI

    In the MD-CLI, use the embed openflow grt, embed openflow vpls, embed openflow vprn, or embed openflow system options in the following contexts.

    configure filter ip-filter
    configure filter ipv6-filter
  • classic CLI

    In the classic CLI, use the embed-filter open-flow service or embed-filter open-flow system options in the following contexts.

    configure filter ip-filter
    configure filter ipv6-filter
    configure filter mac-filter

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.

The following table summarizes the main differences between the two modes of operation.

Table 2. 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

  • See the SR OS R23.x.Rx Software Release Notes for a full list of GRT, IES, VPRN, and VPLS interfaces that support OF control for multi-service mode.

  • The 7450 ESS, 7750 SR, 7950 XRS, and VSR 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-defined-cookie:

    • H-OFS with the switch-defined-cookie command disabled

      • Valid flow_priority_range 1 to max-size – 1

      • flow_priority_value 0 is reserved (no match action)

    • H-OFS with the switch-defined-cookie command enabled

      • Valid flow_priority_range 1 to 65534

      • 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:

    • H-OFS with the switch-defined-cookie command disabled

      filter entry ID = max-size – flow_priority + embedding offset

    • H-OFS with the switch-defined-cookie command enabled

      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.

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 and VLAN ID match is programmed only if the matching SAP has this H-OFS instance embedded in its ACL ingress filter policy. Use the following commands to configure the SAP scope of embedding:

  • MD-CLI

    configure filter ip-filter embed openflow sap
    configure filter ipv6-filter openflow embed openflow sap
  • classic CLI

    configure filter ip-filter embed-filter open-flow sap
    configure filter ipv6-filter open-flow embed-filter sap
    configure filter mac-filter open-flow embed-filter 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: after for the VPLS service and after for the SAP if both service-level and SAP-level rules are to be activated.

The following example shows the activation of service-level and SAP-level rules inside a single ACL policy.

MD-CLI
[ex:/configure filter ip-filter "1"]
A:admin@node-2# info
    scope exclusive
    embed {
        openflow "ofs1" offset 100 {
            vpls "vpls100"
        }
        openflow "ofs1" offset 200 {
            vpls "vpls100"
            sap 1/1/2:2
        }
    }
classic CLI
A:node-2>config>filter>ip-filter# info
----------------------------------------------
            scope exclusive
            embed-filter open-flow "ofs1" service 5 offset 100
            embed-filter open-flow "ofs1" sap 1/1/2:2 offset 200
----------------------------------------------
Restrictions
  • Because an H-OFS instance does not support overlapping priorities within a single sros-cookie (type plus 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.

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, for example, ‟_tmnx_ofs_<ofs_name>”, with the same name for IPv4 and IPv6 filters used.

If embedded filters cannot be allocated because of 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 before the H-OFS instance embedding into a filter policy or before a filter policy with H-OFS instance embedded being assigned to an interface. This allows the user 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 are 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 or 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. 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 or deleted through filter policy CLI/SNMP. The user can see the above embedded filters under show filter context, including the details about the filters, entries programmed, interface association, statistics, and so on.

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 2. OF flow table mapping to router or 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 or SNMP programmed rules 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.

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:

  1. 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 or byte values are an aggregate of all packets or bytes forwarded over the LSP.

    Statistics are not available for any other logical ports encodings.

  2. 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 combination 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

Consider the following operational notes:

  • Flow Table statistics displayed through the CLI debugging tools 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. Use the following command to display flow table statistics.

    tools dump open-flow of-switch
  • When retrieving FlowTable statistics at scale, Nokia recommends to either use bulk requests, or to pace single entry requests to obtain the balance between stats real-time accuracy and CPM activity.

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 specific H-OFS switch instance. Use the following command to enable the auxiliary channel:

  • MD-CLI

    configure openflow of-switch aux-channel true
  • classic CLI

    configure open-flow of-switch aux-channel-enable

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.

Hybrid OpenFlow switch traffic steering details

As described in OpenFlow switch auxiliary channels, 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 following figure shows how the rules become part of an ingress line card pipeline.

Figure 3. OpenFlow switch embedding in ingress pipeline processing

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. Encoding and supported logical port types lists logical port types supported by SR OS H-OFS:

Table 3. 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 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.

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.

The following table shows how OXM_OF_VLAN_ID and experimenter OFL_OUT_VLAN_ID fields are used to encode VLAN tags.

Table 4. 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)

The following table shows how OF programmed values are translated to SR OS SAPs.

Table 5. 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

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
} 

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.

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.

Redirect to ESI (Layer 2)

The router supports redirection of IPv4 or 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)

Redirect to ESI (Layer 3)

The router supports redirection of IPv4 or IPv6 traffic arriving on a Layer 3 interface to an ESI with an EVPN control plane. An OF controller can program Layer 3 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)

Redirect to ESI IP VAS-interface router

The router supports redirection of IPv4 or 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 Layer 3 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)

Redirect to LSP

The router supports traffic steering to an RSVP, MPLS-TP, IPv4 SR-TE, or IPv6 SR-TE 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.

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.

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)

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
}

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.

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.

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.

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. Use the following command to configure the default action:

  • MD-CLI

    configure openflow of-switch flowtable mismatch-action fall-through
  • classic CLI

    configure open-flow of-switch flowtable no-match-action fall-through

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. Use the following command to enable the packet-in processing:

  • MD-CLI

    configure openflow of-switch aux-channel true
  • classic CLI

    configure open-flow of-switch aux-channel-enable

A count of packets to which packet-in is applied is also available through the OpenFlow channel statistics.

Programming of DSCP remark action

The router supports DSCP remarking of IPv4 and 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;

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

    Two PBF actions (SAP and SDP) with optional sticky destination and pbr-on-down

  • Layer 3 PBR redundancy

    Two PBR actions (IP next-hop and VRF) with optional sticky destination and pbr-on-down

  • Layer 3 PBR redundancy

    Two 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, see 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-dest 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 */
};

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, 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.