HP OpenFlow Protocol Overview Technical Solution Guide Version: 1 September 2013
Table of Contents Introduction: Traditional Switch and Openflow... 2 Destination Address-based Switching... 2 Flow-based Switching... 2 OpenFlow Architecture... 3 OpenFlow Switch Components... 4 Operational Planes... 5 OpenFlow Protocol... 6 OpenFlow Pipelines... 7 Matching... 8 Actions... 9 Counters... 10 OpenFlow Security... 10 Centralized and Distributed Control... 10 OpenFlow and SDN Standardization... 10 Appendix 1: OpenFlow 1.3 Match Options... 12 Appendix 2: OpwnFlow Table Counters... 12 Resources, contacts, or additional links... 16 Learn more at hp.com/networking... 16
Introduction: Traditional Switch and Openflow Destination Address-based Switching In a traditional layer 2 switching environment, switching is performed based on destination MAC address. Each switch has its own MAC address table and each switch learns where devices are located. Figure 1: Switching decisions based on destination MAC address Process: 1. Frame arrives at Switch 1 from PC A (MAC = AAAA.AAAA.AAAA) to PC B (MAC = BBBB.BBBB.BBBB) 2. MAC address table is checked for location of PC B 3. Entry is found in forwarding table 4. Frame is transmitted out of port 2 This process is repeated at every switch in the network. A router would use a similar type of process based on destination IP address (unicast routing) and a routing table (RIB) and forwarding information based (FIB). Flow-based Switching In an OpenFlow environment, flow tables are used by devices rather than routing or MAC address tables. Figure 2: Flow-based forwarding table configuration Each flow entry has an action associated with it. The three actions that all dedicated OpenFlow switches must support are: Forward: The first options is to forward this flow s packets to a given port (or set of ports). This allows packets to be switched through the network. In most switches it is expected that this takes place at line rate speeds. Redirect: The second option is to encapsulate the packet and forward this flow s packets to the SDN controller. The packet is delivered via a secure channel using TLS. The controller makes a decision and forwards the packet back to the switch. Typically, this method is only used for the first packet in a new flow, so a controller can decide if the flow should be added to the Flow Table. Or in some experiments, it could be used to forward all packets to a controller for processing. 2
HP OpenFlow Technical Overview Drop: The third option is to drop this flow s packets. This can be be used for security reasons to block unauthorized traffic, to stop denial of service attacks, or to reduce spurious broadcast traffic from end-hosts. HP s Sentinel application can be used for this purpose. Figure 3: OpenFlow table entries An entry in the Flow-Table has three fields: A packet header that defines the flow (TCP port 80 traffic for example) The action that defines how the packets should be processed (Forward out of port G1/0/1) Statistics that keep track of the number of packets and bytes for each flow. (100 packets 8000 bytes for example). The time since the last packet matched the flow is also recorded so as to remove inactive flows. This can be configured within the HP SDN Controller. The default is a flow is active for 300 seconds. OpenFlow Architecture HP s SDN Controller supports OpenFlow versions from 1.0 to 1.3.1. In 2006, Standford PhD student, Martin Casado and others developed Ethane. This used the idea and approach to effectively and centrally manage global network policy. Ethane uses a flow based network and central controller with a focus on network security. Ethane later inspired the concept of OpenFlow. Figure 4: OpenFlow roadmap OpenFlow is a standards based protocol allowing for a centralized control plane in a separate device (the controller). Openflow provides hardware abstraction providing the controller a method to communicate with multiple vendor devices, multiple hardware types (routers, switches, load balancers and others), using a standard interface. This takes the control logic on how to perform packet forwarding and packet rules and putting those rules down into a hardware abstraction here where they can be followed by the individual network device. Most initial SDN devices are routers and switches. However, OpenFlow and SDN make provision for many device types and are not restricted to routers or switches. Other devices such as load balancers, firewalls and WAN optimization devices may also support SDN in future - any network forwarding device that can programmed to perform variety of activities is envisioned as part of SDN and OpenFlow. OpenFlow is managed by the Open Networking Foundation (ONF). OpenFlow is asynchronous. Switches can initiate conversations to the controller and the controller can initiate conversations to switches. 3
The Openflow protocol is a specification that defines the API to the forwarding point of an individual device. Figure 5: SDN architecture OpenFlow Switch Components An OpenFlow Switch consists of one or more flow tables and a group table, which perform packet lookups and forwarding, and an OpenFlow channel to the HP SDN Controller. The switch communicates with the HP SDN controller and the controller manages the switch via the OpenFlow protocol. Is OpenFlow secure? Is there a security risk of someone hacking into my device and injecting rules that affect the traffic flows? The OpenFlow protocol provides a secure channel that is certificate based. This is TLS (Transport Layer Security) based. TLS is the successor to SSL (Secure Sockets Layer) and provides cryptographic protocols for communication security. TLS is used widely for secure transmissions on the Internet. Figure 6: OpenFlow switch components Using the OpenFlow protocol, the controller can add, update, and delete flow entries in flow tables, both reactively (in response to packets) and proactively. Each flow table in the switch contains a set of flow entries; each flow entry consists of match fields, counters, and a set of instructions to apply to matching packets. Figure 7: Proactive and reactive flow table updates Matching starts at the first flow table and may continue to additional flow tables. Flow entries match packets in priority order, with the first matching entry in each table being used. If a matching entry is found, the 4
HP OpenFlow Technical Overview instructions associated with the specific fow entry are executed. If no match is found in a fow table, the outcome depends on configuration of the table-miss flow entry: for example, the packet may be forwarded to the controller over the OpenFlow channel, dropped, or may continue to the next flow table. Instructions associated with each flow entry either contain actions or modify pipeline processing. Actions included in instructions describe packet forwarding, packet modification and group table processing. Pipeline processing instructions allow packets to be sent to subsequent tables for further processing and allow information, in the form of metadata, to be communicated between tables. Table pipeline processing stops when the instruction set associated with a matching flow entry does not specify a next table; at this point the packet is usually modifed and forwarded. Operational Planes Traditional Switch In traditional network devices there are three planes of operation Management Plane Control Plane Forwarding Plane Figure 8: Traditional device architecture In a traditional router or switch, the forwarding or data plane and the high level routing decisions (control plane) occur on the same device. Examples of control plane protocols include OSPF, BGP, ISIS and LDP. Tables used in the data plane include the Forwarding information base (FIB) or Label Forwarding information base (LFIB). Pure OpenFlow Switch A pure OpenFlow Switch separates these two functions. The data path portion still resides on the switch, while high-level routing decisions are moved to a separate controller, typically a standard server. The OpenFlow Switch and Controller communicate via the OpenFlow protocol, which defines messages, such as packet-received, send-packet-out, modify-forwarding-table, and get-stats. A pure OpenFlow switch is essentially a dumb device that forwards packets between ports, as directed by the SDN Controller. In this context, flows are broadly defined, and are limited only by the capabilities of the particular implementation of the Flow Table. Figure 9: OpenFlow switch architecture 5
Hybrid Switch The hybrid mode answers the question: Do I have to have a green field environment to build an Openflow network? The answer is No. The approach that HP taken is to allow hybrid mode where a single VLAN can be run in OpenFlow while other VLANs run in traditional mode using traditional protocols. This occurs within the same network device. Figure 10: Hybrid switch architecture This approach allows for simple migration starting with a set of Openflow devices connected to the openflow VLAN. OpenFlow Protocol With OpenFlow: Many criteria can be matched simultaneously providing flow granularity. Masks can be used to match on broader entries. Multiple actions can be performed on packets. Figure 11: Matching arbitrary bits OpenFlow is very flexible. Packets can be matched on many options such as ingress port, VLAN ID, Layer 3 source destination, Layer 4 source and destination ports and so forth. Once a rule is matched, actions can be performed. A packet could be forwarded as unicast or to multiple ports, it could be droped, encapsulated, or modified. Table 1: OpenFlow 1.0 Table Components Rule (Criterion) Action Stats Switch port VLAN ID VLAN PCP MAC Source Address MAC Destination Address Ethernet Type IP Source Address IP Destination Address IP ToS IP Protocol L4 Source Port L4 Destination Port Forward to one or more ports Drop Encapsulate and forward to controller Send to normal processing pipeline Modify fields Packet Counter Byte Counter One of the issues raised is that there may be 5 or 6 devices in a sequence that perform various functions. That may be switching, routing, load balancing, firewall, intrusion protection, WAN optimization and so on. This not only adds latency and delay, but each device can also be a single point of failure or a bottleneck. So it is 6
HP OpenFlow Technical Overview benefitial to have a generic device that performs a variety of functions at line rate because they re not limited to individual devices and the latency involved. Another benefit is the placement of devices. In many cases having only a few firewalls requires to put them at the core, and to redirect traffic to this security device creating a bottleneck. OpenFlow allows distributing security everywhere. Every Openflow device can run a variety of security features to perform basic functions at every single device. OpenFlow adds more flexibility in the network design. OpenFlow can match on something as simple as inbound port. But, metadata inside the frame or packet can also be matched on. Options such as Ethernet type, Ethernet destination MAC address or Source MAC address could also be matched on. Mulitple actions can be applied including QOS actions, forwarding actions and modify actions. VLAN IDs could be stripped or changed for example. MPLS labels can be popped or pushed or swapped. Openflow is a very flexible protocol and is being updated regularly. These are just sub-set of the functions and the actions that can be performed. OpenFlow 1.3 has extended the flow table entry. Table 2: OpenFlow 1.3 flow table entry The options now include: Match fields: to match against packets. These consist of the ingress port and packet headers, and optionally metadata specied by a previous table. Priority: matching precedence of the flow entry. Counters: updated when packets are matched. Instructions: to modify the action set or pipeline processing. Timeouts: maximum amount of time or idle time before flow is expired by the switch. Cookie: opaque data value chosen by the controller. May be used by the controller to filter flow statistics, flow modification and flow deletion. Not used when processing packets. OpenFlow Pipelines There are two types of OpenFlow switches: OpenFlow-only OpenFlow-hybrid OpenFlow only switches support only OpenFlow operation. All packets are processed using OpenFlow. There is no other way to process packets. OpenFlow hybrid switches support both OpenFlow operation and normal Ethernet switching operation. Certain VLANs would use traditional L2 Ethernet switching, VLAN isolation, L3 routing, ACL and QoS processing and so forth. This type of switches must provide a classification mechanism outside of OpenFlow that routes traffic to either the OpenFlow pipeline or the normal pipeline. HP switches use VLANs (one or more) for this purpose. Table 3: Multiple table pipeline The OpenFlow pipeline of every OpenFlow switch contains multiple flow tables, each flow table containing multiple flow entries. The OpenFlow pipeline processing defines how packets interact with those fow tables. An OpenFlow switch is required to have at least one flow table, and can optionally have more. An OpenFlow switch with a single flow table is valid and in this case pipeline processing is greatly simplified. 7
The Flow tables of an OpenFlow switch are sequentially numbered, starting at 0. Pipeline processing always starts at the first flow table: the packet is first matched against flow entries of flow table 0. Other flow tables may be used depending on the outcome of the match in the first table. When processed by a flow table, the packet is matched against the entries of the flow table. If a flow entry is found, the instruction set included in that flow entry is executed, those instructions may explicitly direct the packet to another flow table, where the same process is repeated again. Figure 12: Flow table process A flow entry can only direct a packet to a flow table number which is greater than its own flow table number, in other words pipeline processing can only go forward and not backward. The flow entries of the last table of the pipeline cannot include the Goto instruction. If the matching flow-entry does not direct packets to another flow table, pipeline processing stops at this table. When pipeline processing stops, the packet is processed with its associated action set and usually forwarded. If a packet does not match a flow entry in a flow table, this is a table miss. The behavior on a table miss depends on the table configuration. A table-miss flow entry in the flow table may specify how to process unmatched packets: Options include dropping them, passing them to another table or sending them to the controller over the control channel via packet-in messages. In the HP configuration, the packet is forwarded to the SDN controller. Matching On receipt of a packet, an OpenFlow Switch performs the functions shown in the slide. The switch starts by performing a table lookup in the first flow table, and based on pipeline processing, may perform table lookups in other flow tables. Packet match fields are extracted from the packet. Packet match fields used for table lookups depend on the packet type, and typically include various packet header fields, such as Ethernet source address or IPv4 destination address. In addition to packet headers, matches can also be performed against the ingress port and metadata fields. Metadata may be used to pass information between tables in a switch. The packet match fields represent the packet in its current state, if actions applied in a previous table using the Apply-Actions changed the packet headers, those changes are rejected in the packet match fields. A packet matches a flow table entry if the values in the packet match fields used for the lookup match those defined in the flow table entry. If a flow table entry field has a value of ANY (field omitted), it matches all possible values in the header. If the switch supports arbitrary bitmasks on specific match fields, these masks can more precisely specify matches. Figure 13: Matching process 8
HP OpenFlow Technical Overview The packet is matched against the table and only the highest priority flow entry that matches the packet must be selected. The counters associated with the selected flow entry must be updated and the instruction set included in the selected flow entry must be applied. If there are multiple matching flow entries with the same highest priority, the selected flow entry is explicitly undefined. This case can only arise when a controller writer never sets the OFPFF_CHECK_OVERLAP bit on flow mod messages and adds overlapping entries. Note: IP fragments must be reassembled before pipeline processing if the switch configuration contains the OFPC_FRAG_REASM flag. This version of the specification does not define the expected behavior when a switch receives a malformed or corrupted packet. Actions A switch is not required to support all action types, just those marked Required Action" below. The controller can also query the switch about which of the Optional Action" it supports. Table 4: OpenFlow actions Action Description Type Output Forwards a packet to a specified OpenFlow port. Required OpenFlow switches must support forwarding to physical ports, switch-defined logical ports and the required reserved ports. Set-Queue Sets the queue id for a packet. Optional When the packet is forwarded to a port using the output action, the queue id determines which queue attached to this port is used for scheduling and forwarding the packet. Forwarding behavior is dictated by the configuration of the queue and is used to provide basic Quality-of-Service (QoS) support. Drop Packets whose action sets have no output actions should be Required dropped. This result could come from empty instruction sets or empty action buckets in the processing pipeline, or after executing a Clear-Actions instruction Group Process the packet through the specified group. The exact interpretation depends on group type. Required Push-Tag / Pop-tag Set-Field Change-TTL Switches may support the ability to push/pop tags (VLANs, MPLS). To aid integration with existing networks, it is suggestes that the ability to push/pop VLAN tags be supported. The various Set-Field actions are identified by their field type and modify the values of respective header fields in the packet. While not strictly required, the support of rewriting various header fields using Set-Field actions greatly increases the usefulness of an OpenFlow implementation. To aid integration with existing networks, it is suggestes that VLAN modification actions be supported. Set-Field actions should always be applied to the outermostpossible header (e.g. a Set VLAN ID" action always sets the ID of the outermost VLAN tag), unless the field type specified otherwise. The various Change-TTL actions modify the values of the IPv4 TTL, IPv6 Hop Limit or MPLS TTL in the packet. Change-TTL actions should always be applied to the outermost-possible header. Optional Optional Optional 9
Counters Counters are maintained for each flow table, flow entry, port, queue, group, group bucket, meter and meter band. OpenFlow-compliant counters may be implemented in software and maintained by polling hardware counters with more limited ranges. Table 5: Required Counters Per flow table Per flow entry Per port Per queue Counter Reference Count (active entries) Duration (seconds) Received Packets Transmitted Packets Received Packets Transmitted Packets For a detailed list of counters see Appendix 2 OpenFlow Security As OpenFlow is a critical component of the network, the communication between the controller and the devices needs to be protected. The OpenFlow protocol provides a secure channel that is certificate based. This is TLS (Transport Layer Security) based. TLS is the successor to SSL (Secure Sockets Layer) and provides cryptographic protocols for communication security. TLS is used widely for secure transmissions on the Internet. Figure 14: OpenFlow Secure Channel Centralized and Distributed Control Another important question is redundancy. A federated set of controllers that cover multiple devices can be deployed, so redundancy is built in. OpenFlow and SDN Standardization Openflow standardization is different to other types of protocols in the past. Typically there s two ways networks have been innovated in the last 20 to 30 years: 10
HP OpenFlow Technical Overview A vendor designs and writes a new protocol to solve a problem. The problem with this method is that the new protocol becomes vendor s specific. It is proprietary and not open or multi vendor. The other approach which is multivendor is one that is driven by the standard bodies; typically the IEEE or the IETF (and others). The issue is that the process is slow. Things often happen so slowly that by the time the protocol comes out for standardization it s already too late. Some vendors have already jumped the gun and come up with a technical solution. This is currently happening with some fabric technologies with regards to TRILL or SPB. Some Vendors are already implementing their own fabric technologies that are proprietary. Open Networking Foundation (ONF) ONF s mission is to promote the development and use of Software-Defined Networking ( SDN ) technologies. These SDN technologies embody two basic principles: Software-Defined Forwarding: Forwarding functionality should be controllable by software through an open interface. OpenFlow is an example of such an interface. Global Management Abstractions: Networks should support a basic set of global management abstractions upon which more advanced management tools can be built. These global management abstractions might include, for example, a global view of the network, triggers on network events (such as topology changes or new flows), and the ability to control network elements by inserting entries into their hardware forwarding tables. The ONF is different from the previous protocol development options. The ONF is driven primarily by customers. It is an open source type of arrangement. No vendor owns the protocol and no standard bodies are slowly developing it. Some of the members are well known. These are large service provider and content provider customers that have huge networks that want to provide a solution for them so they can get out of thumb of their networking vendor. Some of them are currently tied down to a specific vendor or specific protocol. Customers want hardware standardization, they want abstraction on the network and they want their network completely managed using software. The Board of Directors members are all customers. The technical advisory team members are vendors that provide advice. 11
Appendix 1: OpenFlow 1.3 Match Options OpenFlow 1.3 has extended the match options. A switch must support each required match field must be supported in at least one flow table of the switch. OFPXMT_OFB_IN_PORT = 0 /* Switch input port. */ OFPXMT_OFB_IN_PHY_PORT = 1 /* Switch physical input port. */ OFPXMT_OFB_METADATA = 2 /* Metadata passed between tables. */ OFPXMT_OFB_ETH_DST = 3 /* Ethernet destination address. */ OFPXMT_OFB_ETH_SRC = 4 /* Ethernet source address. */ OFPXMT_OFB_ETH_TYPE = 5 /* Ethernet frame type. */ OFPXMT_OFB_VLAN_VID = 6 /* VLAN id. */ OFPXMT_OFB_VLAN_PCP = 7 /* VLAN priority. */ OFPXMT_OFB_IP_DSCP = 8 /* IP DSCP (6 bits in ToS field). */ OFPXMT_OFB_IP_ECN = 9 /* IP ECN (2 bits in ToS field). */ OFPXMT_OFB_IP_PROTO = 10 /* IP protocol. */ OFPXMT_OFB_IPV4_SRC = 11 /* IPv4 source address. */ OFPXMT_OFB_IPV4_DST = 12 /* IPv4 destination address. */ OFPXMT_OFB_TCP_SRC = 13 /* TCP source port. */ OFPXMT_OFB_TCP_DST = 14 /* TCP destination port. */ OFPXMT_OFB_UDP_SRC = 15 /* UDP source port. */ OFPXMT_OFB_UDP_DST = 16 /* UDP destination port. */ OFPXMT_OFB_SCTP_SRC = 17 /* SCTP source port. */ OFPXMT_OFB_SCTP_DST = 18 /* SCTP destination port. */ OFPXMT_OFB_ICMPV4_TYPE = 19 /* ICMP type. */ OFPXMT_OFB_ICMPV4_CODE = 20 /* ICMP code. */ OFPXMT_OFB_ARP_OP = 21 /* ARP opcode. */ OFPXMT_OFB_ARP_SPA = 22 /* ARP source IPv4 address. */ OFPXMT_OFB_ARP_TPA = 23 /* ARP target IPv4 address. */ OFPXMT_OFB_ARP_SHA = 24 /* ARP source hardware address. */ OFPXMT_OFB_ARP_THA = 25 /* ARP target hardware address. */ OFPXMT_OFB_IPV6_SRC = 26 /* IPv6 source address. */ OFPXMT_OFB_IPV6_DST = 27 /* IPv6 destination address. */ OFPXMT_OFB_IPV6_FLABEL = 28 /* IPv6 Flow Label */ OFPXMT_OFB_ICMPV6_TYPE = 29 /* ICMPv6 type. */ OFPXMT_OFB_ICMPV6_CODE = 30 /* ICMPv6 code. */ OFPXMT_OFB_IPV6_ND_TARGET = 31 /* Target address for ND. */ OFPXMT_OFB_IPV6_ND_SLL = 32 /* Source link-layer for ND. */ OFPXMT_OFB_IPV6_ND_TLL = 33 /* Target link-layer for ND. */ OFPXMT_OFB_MPLS_LABEL = 34 /* MPLS label. */ OFPXMT_OFB_MPLS_TC = 35 /* MPLS TC. */ OFPXMT_OFP_MPLS_BOS = 36 /* MPLS BoS bit. */ OFPXMT_OFB_PBB_ISID = 37 /* PBB I-SID. */ OFPXMT_OFB_TUNNEL_ID = 38 /* Logical Port Metadata. */ OFPXMT_OFB_IPV6_EXTHDR = 39 /* IPv6 Extension Header pseudo-field */ Appendix 2: OpwnFlow Table Counters Per Flow Table Counter Bits Required? Reference Count (active entries) 32 Required Packet Lookups 64 Optional Packet Matches 64 Optional Per Flow Entry Counter Bits Required? Received Packets 64 Optional 12
HP OpenFlow Technical Overview Received Bytes 64 Optional Duration (seconds) 32 Required Duration (nanoseconds) 32 Optional Per Port Counter Bits Required? Received Packets 64 Required Transmitted Packets 64 Required Received Bytes 64 Optional Transmitted Bytes 64 Optional Receive Drops 64 Optional Transmit Drops 64 Optional Receive Errors 64 Optional Transmit Errors 64 Optional Receive Frame Alignment Errors 64 Optional Receive Overrun Errors 64 Optional Receive CRC Errors 64 Optional Collisions 64 Optional Duration (seconds) 32 Required Duration (nanoseconds) 32 Optional Per Queue Counter Bits Required? Transmit Packets 64 Required Transmit Bytes 64 Optional Transmit Overrun Errors 64 Optional Duration (seconds) 32 Required Duration (nanoseconds) 32 Optional Per Group Counter Bits Required? Reference Count (Flow entries) 32 Optional Packet Count 64 Optional Byte Count 64 Optional Duration (seconds) 32 Required Duration (nanoseconds) 32 Optional Per Group Bucket Counter Bits Required? Packet Count 64 Optional Byte Count 64 Optional Per Meter Counter Bits Required? Flow Count 32 Optional Input Packet Count 64 Optional 13
Input Byte Count 64 Optional Duration (seconds) 32 Required Duration (nanoseconds) 32 Optional Per Meter Band Counter Bits Required? In Band Packet Count 64 Optional In Band Byte Count 64 Optional 14
HP OpenFlow Technical Overview 15
Resources, contacts, or additional links HP SDN: http://hp.com/sdn HP SDN SDK and documentation: http://sdndevcenter.hp.com Learn more at hp.com/networking Sign up for updates hp.com/go/getupdated Share with colleagues Rate this document Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. October 2013