|
|
ViewsOpenFlow 0.8.9 release notesFrom OpenFlow WikiOpenFlow Protocol ChangesIP NetmasksIt is now possible for flow entries to contain IP subnet masks. This is done by changes to the wildcards field, which has been expanded to 32-bits:
/* Flow wildcards. */
enum ofp_flow_wildcards {
OFPFW_IN_PORT = 1 << 0, /* Switch input port. */
OFPFW_DL_VLAN = 1 << 1, /* VLAN. */
OFPFW_DL_SRC = 1 << 2, /* Ethernet source address. */
OFPFW_DL_DST = 1 << 3, /* Ethernet destination address. */
OFPFW_DL_TYPE = 1 << 4, /* Ethernet frame type. */
OFPFW_NW_PROTO = 1 << 5, /* IP protocol. */
OFPFW_TP_SRC = 1 << 6, /* TCP/UDP source port. */
OFPFW_TP_DST = 1 << 7, /* TCP/UDP destination port. */
/* IP source address wildcard bit count. 0 is exact match, 1 ignores the
* LSB, 2 ignores the 2 least-significant bits, ..., 32 and higher wildcard
* the entire field. This is the *opposite* of the usual convention where
* e.g. /24 indicates that 8 bits (not 24 bits) are wildcarded. */
OFPFW_NW_SRC_SHIFT = 8,
OFPFW_NW_SRC_BITS = 6,
OFPFW_NW_SRC_MASK = ((1 << OFPFW_NW_SRC_BITS) - 1) << OFPFW_NW_SRC_SHIFT,
OFPFW_NW_SRC_ALL = 32 << OFPFW_NW_SRC_SHIFT,
/* IP destination address wildcard bit count. Same format as source. */
OFPFW_NW_DST_SHIFT = 14,
OFPFW_NW_DST_BITS = 6,
OFPFW_NW_DST_MASK = ((1 << OFPFW_NW_DST_BITS) - 1) << OFPFW_NW_DST_SHIFT,
OFPFW_NW_DST_ALL = 32 << OFPFW_NW_DST_SHIFT,
/* Wildcard all fields. */
OFPFW_ALL = ((1 << 20) - 1)
};
The source and destination netmasks are each specified with a 6-bit number in the wildcard description. It is interpreted similar to the CIDR suffix, but with the opposite meaning, since this is being used to indicate which bits in the IP address should be treated as "wild". For example, a CIDR suffix of "24" means to use a netmask of "255.255.255.0". However, a wildcard mask value of "24" means that the least-significant 24-bits are wild, so it forms a netmask of "255.0.0.0". New Physical Port StatsThe ofp_port_stats message has been expanded to return more information. If a switch does not support a particular field, it should set the value to have all bits enabled (i.e., a "-1" if the value were treated as signed). This is the new format:
/* Body of reply to OFPST_PORT request. If a counter is unsupported, set
* the field to all ones. */
struct ofp_port_stats {
uint16_t port_no;
uint8_t pad[6]; /* Align to 64-bits. */
uint64_t rx_packets; /* Number of received packets. */
uint64_t tx_packets; /* Number of transmitted packets. */
uint64_t rx_bytes; /* Number of received bytes. */
uint64_t tx_bytes; /* Number of transmitted bytes. */
uint64_t rx_dropped; /* Number of packets dropped by RX. */
uint64_t tx_dropped; /* Number of packets dropped by TX. */
uint64_t rx_errors; /* Number of receive errors. This is a super-set
of receive errors and should be great than or
equal to the sum of al rx_*_err values. */
uint64_t tx_errors; /* Number of transmit errors. This is a super-set
of transmit errors. */
uint64_t rx_frame_err; /* Number of frame alignment errors. */
uint64_t rx_over_err; /* Number of packets with RX overrun. */
uint64_t rx_crc_err; /* Number of CRC errors. */
uint64_t collisions; /* Number of collisions. */
};
IN_PORT Virtual PortThe behavior of sending out the incoming port was not clearly defined in earlier versions of the specification. It is now forbidden unless the output port is explicitly set to OFPP_IN_PORT virtual port (0xfff8) is set. The primary place where this is used is for wireless links, where a packet is received over the wireless interface and needs to be sent to another host through the same interface. For example, if a packet needed to be sent to all interfaces on the switch, two actions would need to be specified: "actions=output:ALL,output:IN_PORT". Port and Link Status and ConfigurationThe switch should inform the controller of changes to port and link status. This is done with a new flag in ofp_port_config:
... and a new flag in ofp_port_state:
The switch should support enabling and disabling a physical port by modifying the OFPPFL_PORT_DOWN flag (and mask bit) in the ofp_port_mod message. Note that this is not the same as adding or removing the interface from the list of OpenFlow monitored ports; it is equivalent to "ifconfig eth0 down" on Unix systems. Echo Request/Reply MessagesThe switch and controller can verify proper connectivity through the OpenFlow protocol with the new echo request (OFPT_ECHO_REQUEST) and reply (OFPT_ECHO_REPLY) messages. The body of the message is undefined and simply contains uninterpreted data that is to be echoed back to the requester. The requester matches the reply with the transaction id from the OpenFlow header. Vendor ExtensionsVendors are now able to add their own extensions, while still being OpenFlow compliant. The primary way to do this is with the new OFPT_VENDOR message type. The message body is of the form:
/* Vendor extension. */
struct ofp_vendor {
struct ofp_header header; /* Type OFPT_VENDOR. */
uint32_t vendor; /* Vendor ID:
* - MSB 0: low-order bytes are IEEE OUI.
* - MSB != 0: defined by OpenFlow
* consortium. */
/* Vendor-defined arbitrary additional data. */
};
The vendor field is a 32-bit value that uniquely identifies the vendor. If the most significant byte is zero, the next three bytes are the vendor's IEEE OUI. If vendor does not have (or wish to use) their OUI, they should contact the OpenFlow consortium to obtain one. The rest of the body is uninterpreted. It is also possible to add vendor extensions for stats messages with the OFPST_VENDOR stats type. The first four bytes of the message are the vendor identifier as described earlier. The rest of the body is vendor-defined. To indicate that a switch does not understand a vendor extension, a OFPBRC_BAD_VENDOR error code has been defined under the OFPET_BAD_REQUEST error type. Vendor-defined actions are described below in the "Variable Length and Vendor Actions" section. Explicit Handling of IP FragmentsIn previous versions of the specification, handling of IP fragments was not clearly defined. The switch is now able to tell the controller whether it is able to reassemble fragments. This is done with the following capabilities flag passed in the ofp_switch features message: OFPC_IP_REASM = 1 << 5 /* Can reassemble IP fragments. */ The controller can configure fragment handling in the switch through the setting the following new ofp_config_flags in the ofp_switch_config message: /* Handling of IP fragments. */ OFPC_FRAG_NORMAL = 0 << 1, /* No special handling for fragments. */ OFPC_FRAG_DROP = 1 << 1, /* Drop fragments. */ OFPC_FRAG_REASM = 2 << 1, /* Reassemble (only if OFPC_IP_REASM set). */ OFPC_FRAG_MASK = 3 << 1 "Normal" handling of fragments means that an attempt should be made to pass the fragments through the OpenFlow tables. If any field is not present (e.g., the TCP/UDP ports didn't fit), then the packet should not match any entry that has that field set. 802.1D Spanning TreeOpenFlow now has a way to configure and view results of on-switch implementations of 802.1D Spanning Tree Protocol. A switch that implements STP must set the new OFPC_STP bit in the 'capabilities' field of its OFPT_FEATURES_REPLY message. A switch that implements STP at all must make it available on all of its physical ports, but it need not implement it on virtual ports (e.g. OFPP_LOCAL). Several port configuration flags are associated with STP. The complete set of port configuration flags are: enum ofp_port_config { OFPPC_PORT_DOWN = 1 << 0, /* Port is administratively down. */ OFPPC_NO_STP = 1 << 1, /* Disable 802.1D spanning tree on port. */ OFPPC_NO_RECV = 1 << 2, /* Drop most packets received on port. */ OFPPC_NO_RECV_STP = 1 << 3, /* Drop received 802.1D STP packets. */ OFPPC_NO_FLOOD = 1 << 4, /* Do not include this port when flooding. */ OFPPC_NO_FWD = 1 << 5, /* Drop packets forwarded to port. */ OFPPC_NO_PACKET_IN = 1 << 6 /* Do not send packet-in msgs for port. */ }; The controller may set OFPPFL_NO_STP to 0 to enable STP on a port or to 1 to disable STP on a port. (The latter corresponds to the Disabled STP port state.) The default is switch implementation-defined; the OpenFlow reference implementation by default sets this bit to 0 (enabling STP). When OFPPFL_NO_STP is 0, STP controls the OFPPFL_NO_FLOOD and OFPPFL_STP_* bits directly. OFPPFL_NO_FLOOD is set to 0 when the STP port state is Forwarding, otherwise to 1. The bits in OFPPFL_STP_MASK are set to one of the other OFPPFL_STP_* values according to the current STP port state. When the port flags are changed by STP, the switch sends an OFPT_PORT_STATUS message to notify the controller of the change. The OFPPFL_NO_RECV, OFPPFL_NO_RECV_STP, OFPPFL_NO_FWD, and OFPPFL_NO_PACKET_IN bits in the OpenFlow port flags may be useful for the controller to implement STP, although they interact poorly with in-band control. Modify Actions in Existing Flow EntriesNew ofp_flow_mod commands have been added to support modifying the actions of existing entries: OFPFC_MODIFY and OFPFC_MODIFY_STRICT. They use the match field to describe the entries that should be modified with the supplied actions. OFPFC_MODIFY is similar to OFPFC_DELETE, in that wildcards are "active". OFPFC_MODIFY_STRICT is similar to OFPFC_DELETE_STRICT, in that wildcards are not "active", so both the wildcards and priority must match an entry. When a matching flow is found, only its actions are modified--information such as counters and timers are not reset. If the controller uses the OFPFC_ADD command to add an entry that already exists, then the new entry replaces the old and all counters and timers are reset. More Flexible Description of TablesPrevious versions of OpenFlow had very limited abilities to describe the tables supported by the switch. The n_exact, n_compression, and n_general fields in ofp_switch_features have been replaced with n_tables, which lists the number of tables in the switch. The behavior of the OFPST_TABLE stat reply has been modified slightly. The ofp_table_stats body now contains a wildcards field, which indicates the fields for which that particular table supports wildcarding. For example, a direct look-up hash table would have that field set to zero, while a sequentially searched table would have it set to OFPFW_ALL. The ofp_table_stats entries are returned in the order that packets traverse the tables. When the controller and switch first communicate, the controller will find out how many tables the switch supports from the Features Reply. If it wishes to understand the size, types, and order in which tables are consulted, the controller sends a OFPST_TABLE stats request. Lookup Count in TablesTable stats returned ofp_table_stats structures now return the number of packets that have been looked up in the table--whether they hit or not. This is stored in the lookup_count field. Modifying Flags in Port-Mod More ExplicitThe "ofp_port_mod" is used to modify characteristics of a switch's ports. A supplied ofp_phy_port structure describes the behavior of the switch through its flags field. However, it's possible that the controller wishes to change a particular flag and may not know the current status of all flags. A mask field has been added which has a bit set for each flag that should be changed on the switch. The new ofp_port_mod message looks like the following:
/* Modify behavior of the physical port */
struct ofp_port_mod {
struct ofp_header header;
uint32_t mask; /* Bitmap of "ofp_port_flags" that should be
changed. */
struct ofp_phy_port desc;
};
New Packet-Out Message FormatThe previous version's packet-out message treated the variable-length array differently depending on whether the buffer_id was set or not. If set, the array consisted of actions to be executed and the out_port was ignore. If not, the array consisted of the actual packet that should be placed on the wire through the out_port interface. This was a bit ugly, and it meant that in order for a non-buffered packet to have multiple actions executed on it, that a new flow entry be created just to match that entry. A new format is now used, which cleans the message up a bit. The packet always contains a list of actions. An additional variable-length array follows the list of actions with the contents of the packet if buffer_id is not set. This is the new format:
struct ofp_packet_out {
struct ofp_header header;
uint32_t buffer_id; /* ID assigned by datapath (-1 if none). */
uint16_t in_port; /* Packet's input port (OFPP_NONE if none). */
uint16_t n_actions; /* Number of actions. */
struct ofp_action actions[0]; /* Actions. */
/* uint8_t data[0]; */ /* Packet data. The length is inferred
from the length field in the header.
(Only meaningful if buffer_id == -1.) */
};
Hard Timeout for Flow EntriesA hard timeout value has been added to flow entries. If set, then the entry must be expired in the specified number of seconds regardless of whether or not packets are hitting the entry. A hard_timeout field has been added to the flow_mod message to support this. The max_idle field has been renamed idle_timeout. A value of zero means that a timeout has not been set. If both idle_timeout and hard_timeout are zero, then the flow is permanent and should not be deleted without an explicit deletion. The new ofp_flow_mod format looks like this:
struct ofp_flow_mod {
struct ofp_header header;
struct ofp_match match; /* Fields to match */
/* Flow actions. */
uint16_t command; /* One of OFPFC_*. */
uint16_t idle_timeout; /* Idle time before discarding (seconds). */
uint16_t hard_timeout; /* Max time before discarding (seconds). */
uint16_t priority; /* Priority level of flow entry. */
uint32_t buffer_id; /* Buffered packet to apply to (or -1).
Not meaningful for OFPFC_DELETE*. */
uint32_t reserved; /* Reserved for future use. */
struct ofp_action actions[0]; /* The number of actions is inferred from
the length field in the header. */
};
Since flow entries can now be expired due to idle or hard timeouts, a reason field has been added to the ofp_flow_expired message. A value of 0 indicates an idle timeout and 1 indicates a hard timeout:
enum ofp_flow_expired_reason {
OFPER_IDLE_TIMEOUT, /* Flow idle time exceeded idle_timeout. */
OFPER_HARD_TIMEOUT /* Time exceeded hard_timeout. */
};
The new ofp_flow_expired message looks like the following:
struct ofp_flow_expired {
struct ofp_header header;
struct ofp_match match; /* Description of fields */
uint16_t priority; /* Priority level of flow entry. */
uint8_t reason; /* One of OFPER_*. */
uint8_t pad[1]; /* Align to 32-bits. */
uint32_t duration; /* Time flow was alive in seconds. */
uint8_t pad2[4]; /* Align to 64-bits. */
uint64_t packet_count;
uint64_t byte_count;
};
Reworked initial handshake to support backwards compatibilityOpenFlow now includes a basic "version negotiation" capability. When an OpenFlow connection is established, each side of the connection should immediately send an OFPT_HELLO message as its first OpenFlow message. The 'version' field in the hello message should be the highest OpenFlow protocol version supported by the sender. Upon receipt of this message, the recipient may calculate the OpenFlow protocol version to be used as the smaller of the version number that it sent and the one that it received. If the negotiated version is supported by the recipient, then the connection proceeds. Otherwise, the recipient must reply with a message of OFPT_ERROR with a 'type' value of OFPET_HELLO_FAILED, a 'code' of OFPHFC_COMPATIBLE, and optionally an ASCII string explaining the situation in 'data', and then terminate the connection. The OFPT_HELLO message has no body; that is, it consists only of an OpenFlow header. Implementations must be prepared to receive a hello message that includes a body, ignoring its contents, to allow for later extensions. Description of Switch StatThe OFPST_DESC stat has been added to describe the hardware and software running on the switch:
#define DESC_STR_LEN 256
#define SERIAL_NUM_LEN 32
/* Body of reply to OFPST_DESC request. Each entry is a NULL-terminated
* ASCII string. */
struct ofp_desc_stats {
char mfr_desc[DESC_STR_LEN]; /* Manufacturer description. */
char hw_desc[DESC_STR_LEN]; /* Hardware description. */
char sw_desc[DESC_STR_LEN]; /* Software description. */
char serial_num[SERIAL_NUM_LEN]; /* Serial number. */
};
It contains a 256 character ASCII description of the manufacturer, hardware type, and software version. It also contains a 32 character ASCII serial number. Each entry is padded on the right with 0 bytes. Variable Length and Vendor ActionsVendor-defined actions have been added to OpenFlow. To enable more versatility, actions have switched from fixed-length to variable. All actions have the following header:
struct ofp_action_header {
uint16_t type; /* One of OFPAT_*. */
uint16_t len; /* Length of action, including this
header. This is the length of action,
including any padding to make it
64-bit aligned. */
uint8_t pad[4];
};
The length for actions must always be a multiple of eight to aid in 64-bit alignment. The action types are as follows:
enum ofp_action_type {
OFPAT_OUTPUT, /* Output to switch port. */
OFPAT_SET_VLAN_VID, /* Set the 802.1q VLAN id. */
OFPAT_SET_VLAN_PCP, /* Set the 802.1q priority. */
OFPAT_STRIP_VLAN, /* Strip the 802.1q header. */
OFPAT_SET_DL_SRC, /* Ethernet source address. */
OFPAT_SET_DL_DST, /* Ethernet destination address. */
OFPAT_SET_NW_SRC, /* IP source address. */
OFPAT_SET_NW_DST, /* IP destination address. */
OFPAT_SET_TP_SRC, /* TCP/UDP source port. */
OFPAT_SET_TP_DST, /* TCP/UDP destination port. */
OFPAT_VENDOR = 0xffff
};
The vendor-defined action header looks like the following:
struct ofp_action_vendor_header {
uint16_t type; /* OFPAT_VENDOR. */
uint16_t len; /* Length is 8. */
uint32_t vendor; /* Vendor ID, which takes the same form
as in "struct ofp_vendor". */
};
The vendor field uses the same vendor identifier described earlier in the "Vendor Extensions" section. Beyond using the ofp_action_vendor header and the 64-bit alignment requirement, vendors are free to use whatever body for the message they like. VLAN Action ChangesIt is now possible to set the priority field in VLAN tags and stripping VLAN tags is now a separate action. The OFPAT_SET_VLAN_VID action behaves like the former OFPAT_SET_DL_VLAN action, but no longer accepts a special value that causes it to strip the VLAN tag. The OFPAT_SET_VLAN_PCP action modifies the 3-bit priority field in the VLAN tag. For existing tags, both actions only modify the bits associated with the field being updated. If a new VLAN tag needs to be added, the value of all other fields is zero. The OFPAT_SET_VLAN_VID action looks like the following:
struct ofp_action_vlan_vid {
uint16_t type; /* OFPAT_SET_VLAN_VID. */
uint16_t len; /* Length is 8. */
uint16_t vlan_vid; /* VLAN id. */
uint8_t pad[2];
};
The OFPAT_SET_VLAN_PCP action looks like the following::
struct ofp_action_vlan_pcp {
uint16_t type; /* OFPAT_SET_VLAN_PCP. */
uint16_t len; /* Length is 8. */
uint8_t vlan_pcp; /* VLAN priority. */
uint8_t pad[3];
};
The OFPAT_STRIP_VLAN action takes no argument and strips the VLAN tag if one is present. Max Supported Ports Set to 65280What: Increase maximum number of ports to support large vendor switches; was previously 256, chosen arbitrarily. Why: The HP 5412 chassis supports 288 ports of Ethernet, and some Cisco switches go much higher. The current limit (OFPP_MAX) is 255, set to equal the maximum number of ports in a bridge segment in the 1998 STP spec. The RSTP spec from 2004 supports up to 4096 (12 bits) of ports. How: Change OFPP_MAX to 65280. (However, out of the box, the reference switch implementation supports at most 256 ports.) Send Error Message When Flow Not Added Due To Full TablesThe switch now sends an error message when a flow is added, but cannot because all the tables are full. The message has an error type of OFPET_FLOW_MOD_FAILED and code of OFPFMFC_ALL_TABLES_FULL. If the Flow-Mod command references a buffered packet, then actions are not performed on the packet. If the controller wishes the packet to be sent regardless of whether or not a flow entry is added, then it should use a Packet-Out directly. Behavior Defined When Controller Connection LostWhat: Ensure that all switches have at least one common behavior when the controller connection is lost. Why: When the connection to the controller is lost, the switch should behave in a well-defined way. Reasonable behaviors include 'do nothing - let flows naturally timeout', 'freeze timeouts', 'become learning switch', and 'attempt connection to other controller'. Switches may implement one or more of these, and network admins may want to ensure that if the controller goes out, they know what the network can do. The first is the simplest: ensure that every switch implements a default of 'do nothing - let flows timeout naturally'. Changes must be done via vendor-specific command line interface or vendor extension OpenFlow messages. The second may help ensure that a single controller can work with switches from multiple vendors. The different failure behaviors, plus 'other', could be feature bits set for the switch. A switch would still only have to support the default. The worry here is that we may not be able to enumerate in advance the full range of failure behaviors, which argues for the first approach. How: Added text to spec: "In the case that the switch loses contact with the controller, the default behavior must be to do nothing - to let flows timeout naturally. Other behaviors can be implemented via vendor-specific command line interface or vendor extension OpenFlow messages." ICMP Type and Code Fields Now MatchableWhat: Allow matching ICMP traffic based on type or code. Why: We can't distinguish between different types of ICMP traffic (e.g., echo replies vs echo requests vs redirects). How: Changed spec to allow matching on these fields. As for implementation: The type and code are each a single byte, so they easily fit in our existing flow structure. Overload the "tp_src" field to ICMP type and "tp_dst" to ICMP code. Since they are only a single byte, they will reside in the low-byte of these two byte fields (stored in network-byte order). This will allow a controller to use the existing wildcard bits to wildcard these ICMP fields. Output Port Filtering for Delete*, Flow Stats and Aggregate StatsAdd support for listing and deleting entries based on an output port. To support this, an "out_port" field has been added to the "ofp_flow_mod", "ofp_flow_stats_request", and "ofp_aggregate_stats_request" messages. If an "out_port" contains a value other than "OFPP_NONE", it introduces a constraint when matching. This constraint is that the rule must contain an output action directed at that port. Other constraints such as ofp_match structs and priorities are still used; this is purely an *additional* constraint. Note that to get previous behavior, though, "out_port" must be set to "OFPP_NONE", since "0" is a valid port id. This only applies to the delete and delete_strict flow mod commands; the field is ignored by add, modify, and modify_strict. |
Quick NavigationOpenFlow White Paper Download the OpenFlow Whitepaper (PDF).
SIGCOMM Demo Video Watch the Video of theOpenFlow Demo that received the best demo award at SIGCOMM 2008. About OpenFlow OpenFlow is supported bythe Stanford Clean Slate Program. Wiki ToolsPersonal toolsProjects |