PicOS Support for OpenFlow 1.3
The following table contains OpenFlow 1.3 features supported by PicOS. For clarity, the feature names in this table are identical to the feature names found in OpenFlow Switch Specification Version 1.3.0.
Table 1 OpenFlow 1.3 Features Supported by PicOS
OpenFlow V1.3 Section # | Title | Features | Additional Feature Specification | R2.0OVS | R2.0XF TCAM | R2.1OVS | R2.1XF TCAM | R2.0 Limitation |
1 | Introduction | NA |
|
|
|
|
|
|
2 | Switch Components | Flow tables |
| Y | Y | Y | Y |
|
|
| Group table |
| Y | N | Y | Y | Select & fast Fail over are not supported |
3 | Glossary |
|
|
|
|
|
|
|
4 | OpenFlow Ports | See Section 4.3 - 4.5 |
| Y | Y | Y | Y |
|
4.1 | OpenFlow Ports | See Section 4.3 - 4.5 |
| Y | Y | Y | Y |
|
4.2 | Standard Ports | See Section 4.3 - 4.5 |
| Y | Y | Y | Y |
|
4.3 | Physical Ports | Ingress | OpenFlow packets are received on an ingress port, processed by the OpenFlow pipeline. The packet ingress port is a property of the packet throughout the OpenFlow pipeline and represents the OpenFlow port on which the packet was received into the OpenFlow switch | Y | Y | Y | Y |
|
|
| Output | The OpenFlow pipeline can decide to send the packet on an output port using the output action (see 5.9), which defines how the packets goes back to the network | Y | Y | Y | Y |
|
|
| Groups |
| Y | Y | Y | Y |
|
|
| Hardware interface |
| N | N | N | N |
|
|
| Virtual slicing of hardware interface |
| Y | Y | Y | Y |
|
4.4 | Logical Ports | Logical ports are switch defined ports that don't correspond directly to a hardware interface of the switch | Logical ports are higher level abstractions that may be defined in the switch using non-OpenFlow methods |
|
|
|
|
|
|
|
| LAG | Y | N | Y | Y |
|
|
|
| Tunnels | Y | N | Y | N |
|
|
|
| Loopback interface | N | N | N | N |
|
|
| Ingress |
| Y | Y | Y | Y |
|
|
| Output |
| Y | Y | Y | Y |
|
|
| Groups |
| Y |
| Y | Y |
|
|
| Map to various physical port |
| N | N | N | N |
|
|
| PACKET_IN reports logical port and its underlying physical port (GRE & LAG) |
| N | N | N | N | only logical port |
4.5 | Local Reserved Port | Ingress |
| N | N | N | N |
|
|
| Output |
| Y | Y | Y | Y |
|
|
| Groups |
| Y | N | Y | Y |
|
|
| ALL | Only as an output port | Y | Y | Y | Y |
|
|
| CONTROLLER | Represent the control channel with the OpenFlow controller | Y | Y | Y | Y |
|
|
| TABLE | Represent the start of the OpenFlow pipeline | Y | Y | Y | Y |
|
|
| IN_PORT | Used only as an output port, send the packet out its ingress port | N | N | N | N |
|
|
| ANY | Cannot be used as an ingress port nor as an output port | Y | Y | Y | Y |
|
|
| LOCAL | Represent the switch's local networking stack. Can be used as an ingress port or as an output port | Y | Y | Y | Y | Linux networking stack |
|
|
| The local port enables remote entities to interact with the switch via the OpenFlow network, rather than via a separate control network. it can be used to implement an in-band controller connection |
|
|
|
|
|
|
| NORMAL | Non-OpenFlow pipelineused only as an output port | N | N | N | Y |
|
|
| FLOOD | Flooding using the normal pipeline of the switch, used only as an output port | Y | Y | Y | Y |
|
|
|
| Packet out all standard ports | Y | Y | Y | Y |
|
|
|
| But not to the ingress port or ports that are in OFPPS_BLOCKED state | Y | Y | Y | Y |
|
5 | OpenFlow Tables |
|
|
|
|
|
|
|
5.1 | Pipeline Processing | OpenFlow-only | All packets are processed by the OpenFlow pipeline | Y | N | Y | Y | Software Implementation for ARP match/action, multiple tables |
|
| OpenFlow-hybrid | OpenFlow operation and normal Ethernet switching operation | N | N | N | Y |
|
|
|
| VLAN tag to decide whether to process the packet using which pipeline | N | N | N | N | Port based since R2.0 |
|
|
| Input port to decide whether to process the packet using which pipeline | N | N | N | N |
|
|
|
| Allow a packet to go from the OpenFlow pipeline to the normal pipeline through the NORMAL and FLOOD reserved ports | N | Y | N | Y |
|
|
| Multiple flow tables |
| Y | N | Y | Y | Multiple flow tables are logical tables maintained by software, then mergered & installed in one physical flow table. Certain restrictions of flow rule across tables are prohibited (e.g., modify field in table 1 then matched in table 2, error should returned) |
|
| Sequentially numbered, starting at 0. |
| Y | Y | Y | Y |
|
|
| Only go forward and not backward |
| Y | Y | Y | Y |
|
|
| Last table of the pipeline can not include the Goto instruction |
| Y | N | Y | Y |
|
|
| Table miss behavior configuration | Send packets to the controller | Y | Y | Y | Y |
|
|
|
| Drop the packet | Y | Y | Y | Y |
|
|
|
| The packet is processed by the next sequentially numbered table | N | N | N | N |
|
|
|
| The packet is processed by L2/L3 pipelines | N | N | N | N |
|
5.2 | Flow Table | Flow table entry | Match fields | Y | Y | Y | Y | set vlans dot1q-tunneling egress t2 from customer-vlan 10 |
|
|
| Counters | Y | Y | Y | Y | set vlans dot1q-tunneling egress t2 from service-vlan 200 |
|
|
| Instructions | Y | Y | Y | Y | set vlans dot1q-tunneling egress t2 then action change |
|
|
|
|
|
|
|
| set vlans dot1q-tunneling egress t2 then service-vlan 100 |
5.3 | Matching | Packet headers |
| Y | Y | Y | Y |
|
|
| Ingress port |
| Y | Y | Y | Y |
|
|
| Metadata fields | Used to pass information between tables | N | N | N | N |
|
|
| State transition | Actions applied in a previous table using the Apply-Actions are reflected in the packet match field | N | N | N | N |
|
|
| Support ANY | Matches all possible values in the header | Y | Y | Y | Y |
|
|
| Support arbitrary bitmasks on specific match fields |
| Y | Y | Y | Y |
|
|
| Select highest priority flow entry |
| Y | Y | Y | Y |
|
|
| Counters associated with the selected flow entry must be updated |
| Y | Y | Y | Y |
|
|
| CHECK_OVERLAP bit on flow mod messages to avoid overlapping entries |
| Y | N | Y | Y | software check |
|
| Multiple matching flow entries with the same highest priority |
| N | N | N | N | Chip limitation |
|
| Support OFPC_FRAG_REASM flag | IP fragments must be reassembled before pipeline processing | N | N | N | N |
|
|
| Behavior when a switch receives a corrupted packet |
| N | N | N | N |
|
|
|
|
|
|
|
|
|
|
5.4 | Group Table | Group identifier | A 32 bit unsigned integer | Y | N | Y | Y |
|
|
| Group type | To determine group semantics | Y | N | Y | Y | Select, indirect, fast failover group table types are not supported |
|
| Counters | Updated when packets are processed by a group | Y | N | Y | Y |
|
|
| Action buckets | An ordered list of action buckets | Y | N | Y | Y |
|
|
|
|
|
|
|
|
|
|
5.4.1 | Group Types | All | Execute all buckets in the group for multicast or broadcast | Y | N | Y | Y |
|
|
|
| Packet clone is dropped if a bucket directs a packet explicitly out the ingress port | Y | N | Y | Y |
|
|
|
| Support output action to the OFPP_IN_PORT reserved port | Y | N | Y | Y |
|
|
| Select | Execute one bucket in the group based on a switch-computed selection algorithm | N | N | Y | Y |
|
|
| Indirect | Execute the one defined bucket in this group | Y | Y | Y | Y |
|
|
| Fast failover | Execute the first live bucket which is associated with a live port/group is selected | Y | Y | Y | Y |
|
| ECMP |
| Hashing | N | N | Y | Y | Restrcicted match & actions |
|
|
| Round robin | N | N | N | N |
|
|
|
|
|
|
|
|
|
|
5.5 | Per Table Counters | Reference count (active entries) | 32 bits | N | N | N | N |
|
|
| Packet Lookups | 64 bits | N | N | N | N |
|
|
| Packet Matches | 64 bits | N | N | N | N |
|
| Per Flow Counters | Received Packets | 64 bits | N | N | N | N |
|
|
| Received Bytes | 64 bits | Y | Y | Y | Y |
|
|
| Duration (seconds) | 32 bits | Y | Y | Y | Y |
|
|
| Duration (nanoseconds) | 32 bits | N | N | N | N |
|
| Per Port Counters | Received Packets | 64 bits | Y | Y | Y | Y |
|
|
| Transmitted Packets | 64 bits | Y | Y | Y | Y |
|
|
| Received Bytes | 64 bits | Y | Y | Y | Y |
|
|
| Transmitted Bytes | 64 bits | Y | Y | Y | Y |
|
|
| Receive Drops | 64 bits | Y | Y | Y | Y |
|
|
| Transmit Drops | 64 bits | Y | Y | Y | Y |
|
|
| Receive Errors | 64 bits | Y | Y | Y | Y |
|
|
| Transmit Errors | 64 bits | Y | Y | Y | Y |
|
|
| Receive Frame Alignment Errors | 64 bits | Y | Y | Y | Y |
|
|
| Receive Overrun Errors | 64 bits | Y | Y | Y | Y |
|
|
| Receive CRC Errors | 64 bits | Y | Y | Y | Y |
|
|
| Collisions | 64 bits | Y | Y | Y | Y |
|
| Per Queue Counters | Transmit Packets | 64 bits | N | N | N | N |
|
|
| Transmit Bytes | 64 bits | N | N | N | N |
|
|
| Transmit Overrun Errors | 64 bits | N | N | N | N |
|
| Per Group Counters | Reference Count (flow entries) | 32 bits | Y | Y | Y | Y |
|
|
| Packet Count | 64 bits | N | N | N | N |
|
|
| Byte Count | 64 bits | Y | Y | Y | Y |
|
| Per Bucket Counters | Packet Count | 64 bits | N | N | N | N |
|
|
| Byte Count | 64 bits | N | N | N | N |
|
|
|
|
|
|
|
|
|
|
5.6 | Instructions | The controller can query the switch about which of the "Optional Instruction" it supports |
| Y | Y | Y | Y |
|
|
| Apply-Actions action(s) | Applies the specific action(s) immediately, without any change to the Action Set | Y | Y | Y | Y | All of these feature are implemented by software |
|
| Clear-Actions | Clears all the actions in the action set immediately | N | N | N | N |
|
|
| Write-Actions action(s) | Merges the specified action(s) into the current action set | N | N | N | N |
|
|
| Write-Metadata metadata / mask | Writes the masked metadata value into the metadata field | N | N | N | N |
|
|
| Goto-Table next-table-id | Indicates the next table in the processing pipeline | Y | Y | Y | Y |
|
|
| Clear-Actions instruction is executed before the Write-Actions instruction |
| N | N | N | N |
|
|
| Goto-Table is executed last |
| Y | Y | Y | Y |
|
|
| Reject a flow entry if it is unable to execute the instructions and return an unsupported flow error |
| Y | Y | Y | Y |
|
|
|
|
|
|
|
|
|
|
5.7 | Action Set | Action set is associated with each packet |
| Y | Y | Y | Y | All of these feature are implemented by software |
|
| Set is empty by default |
| Y | Y | Y | Y |
|
|
| Action set is carried between flow tables |
| Y | Y | Y | Y |
|
|
| When the instruction set of a flow entry does not contain a Goto-Table instruction, pipeline processing stops and the actions in the action set of the packet are executed |
| Y | Y | Y | Y |
|
|
| Action set contains a maximum of one action of each type |
| Y | Y | Y | Y |
|
|
| The actions in an action set are applied in the order specified below |
| Y | Y | Y | Y |
|
|
| 1. copy TTL inwards |
| N | N | N | N |
|
|
| 2. pop |
| Y | Y | Y | Y |
|
|
| 3. push |
| Y | Y | Y | Y |
|
|
| 4. copy TTL outwards |
| N | N | N | N |
|
|
| 5. decrement TTL |
| N | N | N | N |
|
|
| 6. set |
| Y | Y | Y | Y |
|
|
| 7. qos |
| Y | N | Y | N |
|
|
| 8. group | If a group action is specified, apply the actions of the relevant group bucket(s) in the order specified by this list. | Y | N | Y | Y |
|
|
| 9. output | If no group action is specified, forward the packet on the port specified by the output action. The output action in the action set is executed last. | Y | Y | Y | Y |
|
|
|
| If both an output action and a group action are specified in an action set, the output action is ignored and the group action takes precedence. | Y | Y | Y | Y |
|
|
|
| If no output action and no group action were specified in an action set, the packet is dropped. | Y | Y | Y | Y |
|
|
|
| The execution of groups is recursive if the switch supports it; a group bucket may specify another group, in which case the execution of actions traverses all the groups specified by the group configuration. | Y | Y | Y | Y |
|
|
|
|
|
|
|
|
|
|
5.8 | Action List | Apply-Actions instruction and the Packet-out message include an action list | The actions of an action list are executed in the order specified by the list, and are applied immediately to the packet. | Y | Y | Y | Y |
|
|
|
| The effect of those actions is cumulative. | Y | Y | Y | Y |
|
|
|
| If the action list contains an output action, a copy of the packet is forwarded in its current state to the desired port. | Y | Y | Y | Y |
|
|
|
| If the list contains a group actions, a copy of the packet in its current state is processed by the relevant group buckets. | N | N | Y | Y |
|
|
|
|
|
|
|
|
|
|
5.9 | Actions | The controller can also query the switch about which of the "Optional Action" it supports |
| Y | Y | Y | Y |
|
|
| Output | Support forwarding to physical ports, switch-defined logical ports and the required reserved ports. | Y | Y | Y | Y |
|
|
| Set-Queue | The set-queue action sets the queue ID for a packet and is used to provide basic Quality-of-Service (QoS) support. | Y | Y | Y | Y |
|
|
| Drop |
| Y | Y | Y | Y |
|
|
| Group |
| Y | Y | Y | Y |
|
|
| Push-Tag/Pop-Tag | Order of header fields - Ethernet, VLAN, MPLS, ARP/IP, TCP/UDP/SCTP (IP-only). | Y | Y | Y | Y |
|
|
| Push VLAN header | Push a new VLAN header onto the packet. The Ethertype is used as the Ethertype for the tag. Only Ethertype 0x8100 and 0x88a8 should be used. | N | N | Y | N | VCAP implementation, VLAN only actions allowed |
|
| Pop VLAN header | Pop the outer-most VLAN header from the packet. | N | N | Y | N |
|
|
| Push MPLS header | Push a new MPLS shim header onto the packet. Only Ethertype 0x8847 and 0x8848 should be used. | Y | Y | Y | Y |
|
|
| Pop MPLS header | Pop the outer-most MPLS tag or shim header from the packet. | Y | Y | Y | Y |
|
|
| Set-Field |
|
|
|
|
|
|
|
| Set VLAN ID |
| Y | Y | Y | Y |
|
|
| Strip VLAN ID |
| N | N | Y | N | Use reserved VLAN ID 4095 as special VLAN for stripping, 2 VLAN tags are supported |
|
| Change-TTL | Modify the values of the IPv4 TTL, IPv6 Hop Limit or MPLS TTL in the packet. | N | N | N | N |
|
|
|
| If it is supported, applied to the outermost-possible header. | N | N | N | N |
|
|
| Set MPLS TTL | 8 bits: New MPLS TTL, Replace the existing MPLS TTL. Only applies to packets with an existing MPLS shim header. | Y | Y | Y | Y |
|
|
| Decrement MPLS TTL | Decrement the MPLS TTL. Only applies to packets withan existing MPLS shim header. | Y | Y | Y | Y |
|
|
| Set IP TTL | Replace the existing IPv4 TTL or IPv6 Hop Limit and update the IP checksum. Only applies to IPv4 and IPv6 packets. | N | N | N | N |
|
|
| Decrement IP TTL | Decrement the IPv4 TTL or IPv6 Hop Limit field and update the IP checksum. Only applies to IPv4 and IPv6 packets. | N | N | N | N |
|
|
| Copy TTL outwards | Copy the TTL from next-to-outermost to outermost header with TTL. Copy can be IP-to-IP, MPLS-to-MPLS, or IP-to-MPLS. | N | N | N | N |
|
|
| Copy TTL inwards | Copy the TTL from outermost to next-to-outermost header with TTL. Copy can be IP-to-IP, MPLS-to-MPLS, or MPLS-to-IP. | N | N | N | N |
|
|
|
|
|
|
|
|
|
|
5.9.1 | Default Values (for Fields on Push | Field values for all fields specified in Table 6 should be copied from existing outer headers to new outer headers | VLAN ID ← VLAN ID | Y | Y | Y | N |
|
|
| New fields listed in Table 6 without corresponding existing fields should be set to zero | VLAN priority ← VLAN priority | Y | Y | Y | N |
|
|
| Fields in new headers may be overridden by specifying a "set" action for the appropriate field(s) after the push operation | MPLS label ← MPLS label | Y | N | Y | N |
|
|
|
| MPLS traffic class ← MPLS traffic class | N | N | N | N |
|
|
|
| MPLS TTL ← MPLS TTL & IP TTL | N | N | N | N |
|
|
|
|
|
|
|
|
|
|
6 | OpenFlow Channel | Encrypted using TLS |
| Y | Y | Y | Y |
|
|
| Directly over TCP |
| Y | Y | Y | Y |
|
|
|
|
|
|
|
|
|
|
6.1 | OpenFlow Protocol Overview | Controller-to-switch message type | Initiated by the controller and used to directly manage or inspect the state of the switch. | Y | Y | Y | Y |
|
|
| Asynchronous message type | Initiated by the switch and used to update the controller of network events and changes to the switch state. | Y | Y | Y | Y |
|
|
| Symmetric message type | Initiated by either the switch or the controller and sent without solicitation. | Y | Y | Y | Y |
|
|
|
|
|
|
|
|
|
|
6.1.1 | Controller-to-Switch | Features | Request the capabilities of a switch; the switch must respond with a features reply. | Y | Y | Y | Y |
|
|
| Configuration | Set and query configuration parameters in the switch; switch only responds to a query from the controller. | Y | Y | Y | Y |
|
|
| Modify-State | Add, delete and modify flow/group entries in the OpenFlow tables and to set switch port properties. | Y | Y | Y | Y |
|
|
| Read-State | Used by the controller to collect statistics from the switch. | Y | Y | Y | Y |
|
|
| Packet-out | Used by the controller to send packets out of a specified port on the switch, and to forward packets received via Packet-in messages. | Y | Y | Y | Y |
|
|
| Barrier | Barrier request/reply messages are used by the controller to ensure message dependencies have been met or to receive notifications for completed operations. | Y | Y | Y | Y |
|
|
|
|
|
|
|
|
|
|
6.1.2 | Asynchronous | Switches send asynchronous messages to controllers to denote a packet arrival, switch state change, or error |
|
|
|
|
|
|
|
| Packet-in | For all packets that do not have a matching flow entry, the if table configuration is configured for packets forwarded to the CONTROLLER reserved port, a packet-in event is always sent to controllers. | Y | Y | Y | Y |
|
|
|
| If the packet-in event is configured to buffer packets then the packet-in events contain some fraction of the packet header and a buffer ID to be used by a controller when it is ready for the switch to forward the packet. | Y | Y | Y | Y |
|
|
|
| If the packet is buffered, the number of bytes of the original packet to include in the packet-in can be configured. By default, it is 128 bytes. | Y | Y | Y | Y |
|
|
|
| Or table miss it can be configured in the switch configuration. | Y | Y | Y | Y |
|
|
|
| For packet forwarded to the controller it can be configured in the output action. | Y | Y | Y | Y |
|
|
| Flow-Removed | Only sent for flow with the OFPFF_SEND_FLOW_REM flag set. | Y | Y | Y | Y |
|
|
|
| Generated as the result of a controller flow delete requests or the switch flow expiry process when one of the flow timeout is exceeded. | Y | Y | Y | Y |
|
|
| Port-status | Send port-status messages to controllers as port configuration or port state changes. | Y | Y | Y | Y |
|
|
| Error | Notify controllers of problems using error messages. | Y | Y | Y | Y |
|
|
|
|
|
|
|
|
|
|
6.1.3 | Symmetric | Sent without solicitation, in either direction |
|
|
|
|
|
|
|
| Hello | Exchanged between the switch and controller upon connection startup. | Y | Y | Y | Y |
|
|
| Echo | Sent from either the switch or the controller, and must return an echo reply. | Y | Y | Y | Y |
|
|
| Experimenter | A standard way for OpenFlow switches to offer additional functionality within the OpenFlow message type space. | Y | Y | Y | Y |
|
|
|
|
|
|
|
|
|
|
6.2 | Connection Setup | Establish communication with a controller at a user-configurable (but otherwise fixed) IP address, using a user-specified port | Traffic to and from the OpenFlow channel is not run through the OpenFlow pipeline. Therefore, the switch must identify incoming traffic as local before checking it against the flow tables. | Y | Y | Y | Y |
|
|
|
| Each side of the connection must immediately send an OFPT_HELLO message with the version field set to the highest OpenFlow protocol version supported by the sender. | Y | Y | Y | Y |
|
|
|
| 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. | Y | Y | Y | Y |
|
|
|
| If the negotiated version is not supported by the recipient, the recipient must reply with an OFPT_ERROR message with a type field of OFPET_HELLO_FAILED, a code field of OFPHFC_COMPATIBLE, and then terminate the connection. | Y | Y | Y | Y |
|
|
|
| Optionally an ASCII string explaining the situation in data. | Y | Y | Y | Y |
|
|
|
|
|
|
|
|
|
|
6.3 | Multiple Controllers | Establish communication withmultiple controllers | Controller fail-over. | Y | Y | Y | Y | Active & Standby controllers |
|
|
| Controller load balancing. | N | N | N | N |
|
|
|
| Switch virtualisation. | Y | Y | Y | Y |
|
|
|
| Switch must connect to all controllers it is configured with, and try to maintain connection with all of them concurrently. | Y | Y | Y | Y |
|
|
|
| The reply or error messages related to those command must only be sent on the controller connection associated with that command. | Y | Y | Y | Y |
|
|
|
| Asynchronous messages may need to be send to multiple controllers, the message is duplicated for each eligible controller connection and each message sent when the respective controller connection allows it. | Y | Y | Y | Y |
|
|
| The default role of a controller is OFPCR_ROLE_EQUAL | Controller has full access to the switch and is equal to other controllers in the same role. | Y | Y | Y | Y |
|
|
|
| Controller receives all the switch asynchronous messages (such as packet-in, flow-removed). | Y | Y | Y | Y |
|
|
|
| The controller can send controller-to-switch commands to modify the state of the switch. | Y | Y | Y | Y |
|
|
|
| The switch does not do any arbitration or resource sharing between controllers. | Y | Y | Y | Y |
|
|
| Controller can request its role to be changed to OFPCR_ROLE_SLAVE | Controller has read-only access to the switch. | Y | Y | Y | Y |
|
|
|
| Controller does not receive switch asynchronous messages, apart from Port-status messages. | Y | Y | Y | Y |
|
|
|
| The controller is denied ability to send controller-to-switch commands that modify the state of the switch, OFPT_PACKET_OUT, OFPT_FLOW_MOD, OFPT_GROUP_MOD, OFPT_PORT_MODand OFPT_TABLE_MOD. | Y | Y | Y | Y |
|
|
|
| If the controller sends one of those commands, the switch must reply with an OFPT_ERROR message with a type field of OFPET_BAD_REQUEST, a code field of OFPBRC_IS_SLAVE. | Y | Y | Y | Y |
|
|
|
| Othercontroller-to-switch messages, such as OFPT_STATS_REQUEST and OFPT_ROLE_REQUEST, should be processed normally. | Y | Y | Y | Y |
|
|
| A controller can request its role to be changed to OFPCR_ROLE_MASTER | The switch makes sure there is only a single controller in this role. | Y | Y | Y | Y |
|
|
|
| When a controller change its role to OFPCR_ROLE_MASTER, the switch change all other controllers which role is OFPCR_ROLE_MASTER to have the role OFPCR_ROLE_SLAVE. | Y | Y | Y | Y |
|
|
|
| When the switch perform such role change, no message is generated to the controller which role is changed (in most case that controller is no longer reachable). | Y | Y | Y | Y |
|
|
| A switch may be simultaneously connected to multiple controllers in Equal state, multiple controllers in Slave state, and at most one controller in Master state | Each controller may communicate its role to the switch via a OFPT_ROLE_REQUEST message, and the switch must remember the role of each controller connection. A controller may change role at any time. | Y | Y | Y | Y |
|
|
|
| To detect out-of-order messages during a master/slave transition, the OFPT_ROLE_REQUEST message contains a 64-bit sequence number field, generation_id, that identifies a given mastership view. | Y | Y | Y | Y |
|
|
| On receiving a OFPT_ROLE_REQUEST with role equal to OFPCR_ROLE_MASTER or OFPCR_ROLE_SLAVEthe switch must compare the generation_id in the message against the largest generation id seen sofar | A message with a generation_id smaller than a previously seen generation id must be considered stale and discarded. The switch must respond to stale messages with an error message with typeOFPET_ROLE_REQUEST_FAILED and code OFPRRFC_STALE. | Y | Y | Y | Y |
|
|
|
|
|
|
|
|
|
|
6.4 | Connection Interruption | A switch loses contact with all controllers, the switch should immediately enter either "fail secure mode" or "fail standalone mode" | In "fail secure mode", the only change to switch behavior is that packets and messages destined to the controllers are dropped. | Y | Y | Y | Y |
|
|
|
| Flows should continue to expire according to their timeouts in "fail secure mode." | Y | Y | Y | Y |
|
|
|
| In "fail standalone mode," the switch processes all packets using the OFPP_NORMAL port; in other words, the switch acts as a legacy Ethernet switch or router. | Y | Y | Y | Y |
|
|
|
| Upon connecting to a controller again, the existing flow entries remain. | Y | Y | Y | Y |
|
|
|
| The controller then has the option of deleting all flow entries, if desired. | Y | Y | Y | Y |
|
|
| The first time a switch starts up, it will operate in either "fail secure mode" or "fail standalone mode" mode, until is successfully connects to a controller |
| Y | Y | Y | Y |
|
6.5 | Encryption | The switch and controller may communicate through a TLS connection | The TLS connection is initiated by the switch on startup to the controller, which is located by default on TCP port 6633 | Y | Y | Y | Y |
|
|
|
| Each switch must be user-configurable with one certificate for authenticating the controller (controller certificate) and the other for authenticating to the controller (switch certificate) | Y | Y | Y | Y |
|
|
|
|
|
|
|
|
|
|
6.6 | Message Handling | Message Delivery | Messages are guaranteed delivery, unless the connection fails entirely. | Y | Y | Y | Y |
|
|
| Message Processing | Switches must process every message received from a controller in full, possibly generating a reply. | Y | Y | Y | Y |
|
|
|
| If a switch cannot completely process a message received from a controller, it must send back an error message. | Y | Y | Y | Y |
|
|
|
| Switches must send to the controller all asynchronous messages generated by internal state changes, such as flow-removed or packet-in messages. | Y | Y | Y | Y |
|
| Message Ordering | Ordering can be ensured through the use of barrier messages | In the absence of barrier messages, switches may arbitrarily reorder messages to maximize performance. | N | N | N | N |
|
|
|
| Messages must not be reordered across a barrier message and the barrier message must be processed only when all prior messages have been processed. | Y | Y | Y | Y |
|
|
|
| Messages before a barrier must be fully processed before the barrier, including sending any resulting replies or errors. | Y | Y | Y | Y |
|
|
|
| The barrier must then be processed and a barrier reply sent. | Y | Y | Y | Y |
|
|
|
| Messages after the barrier may then begin processing. | Y | Y | Y | Y |
|
|
|
|
|
|
|
|
|
|
6.7 | Flow Table Modification Messages | OFPFC_ADD | For add requests (OFPFC_ADD) with the OFPFF_CHECK_OVERLAP flag set, the switch must first check for any overlapping flow entries in the requested table | Y | Y | Y | Y |
|
|
|
| If an overlap conflict exists between an existing flow entry and the add request, the switch must refuse the addition and respond with an ofp_error_msg with OFPET_FLOW_MOD_FAILED type and OFPFMFC_OVERLAP code | Y | Y | Y | Y |
|
|
|
| If a flow entry with identical match fields and priority already resides in the requested table, then that entry, including its duration, must be cleared from the table, and the newflow entry added | Y | Y | Y | Y |
|
|
|
| If the OFPFF_RESET_COUNTS flag is set, the flow entry counters must be cleared, otherwise they should be copied from the replaced flow | N | N | N | N |
|
|
|
| No flow-removed message is generated for the flow entry eliminated as part of an add request; if the controller wants a flow-removed message it should explicitly send a DELETE STRICT for the old flow prior to adding the new one | Y | Y | Y | Y |
|
|
|
| If a switch cannot find any space in the requested table in which to add the incoming flow entry, the switch should send an ofp_error_msg with OFPET_FLOW_MOD_FAILED type and OFPFMFC_TABLE_FULL code. | N | N | N | N |
|
|
| OFPFC_MODIFY or OFPFC_MODIFY_STRICT | If a matching entry exists in the table, the instructions field of this entry is updated with the value from the request, whereas its cookie, idle_timeout, hard_timeout, flags, counters and duration fields are left unchanged. | Y | Y | Y | Y |
|
|
|
| If the OFPFF_RESET_COUNTS flag is set, the flow entry counters must be cleared. | N | N | N | N |
|
|
|
| If no flow currently residing in the requested table matches the request, no error is recorded, and no flow table modification occurs. | Y | Y | Y | Y |
|
|
|
| In the strict versions, the set of match fields, all match fields, including their masks, and the priority, are strictly matched against the entry, and only an identical flow is modified or removed. | Y | Y | Y | Y |
|
|
|
| If the match in a flow mod specifies an arbitrary bitmask for another field which the switch cannot support, the switch must return an ofp_error_msg with OFPET_BAD_MATCH type and OFPBMC_BAD_MASK code. | Y | Y | Y | Y |
|
|
|
| If the match in a flow mod specifies values that cannot be matched, for example, a VLAN ID greater than 4095 and not one of the reserved values, or a DSCP value with one of the two higher bits set, the switch must return an ofp_error_msg with OFPET_BAD_MATCH type and OFPBMC_BAD_VALUE code. | Y | Y | Y | Y |
|
|
|
| If the match in a flow mod message specifies a field that is unsupported in the table, the switch must return an ofp_error_msg with OFPET_BAD_MATCH type and OFPBMC_BAD_FIELD code. | Y | Y | Y | Y |
|
|
|
| If the match in a flow mod message specifies a field more than once, the switch must return an ofp_error_msg with OFPET_BAD_MATCH type and OFPBMC_DUP_FIELD code. | Y | Y | Y | Y |
|
|
|
| If the match in a flow mod message specifies a field but fail to specify its associated prerequisites, for example specifies an IPv4 address without matching the EtherType to 0x800, the switch must return an ofp_error_msg with OFPET_BAD_MATCH type and OFPBMC_BAD_PREREQ code. | Y | Y | Y | Y |
|
|
|
| If the match in a flow mod specifies an arbitrary bitmask for either the datalink or network addresses which the switch cannot support, the switch must return an ofp_error_msg with OFPET_BAD_MATCH type and either OFPBMC_BAD_DL_ADDR_MASK or OFPBMC_BAD_NW_ADDR_MASK. | Y | Y | Y | Y |
|
|
|
| If an action in a flow mod message references a group that is not currently defined on the switch, or is a reserved group, such as OFPG_ALL, the switch must return an ofp_error_msg with OFPET_BAD_ACTION type and OFPBAC_BAD_OUT_GROUP code. | Y | Y | Y | Y |
|
|
|
| If an action in a flow mod message has a value that is invalid, for example a Set VLAN ID action with value greater than 4095, or a Push action with an invalid Ethertype, the switch should return an ofp_error_msg with OFPET_BAD_ACTION type and OFPBAC_BAD_ARGUMENT code. | Y | Y | Y | Y |
|
|
|
| If an action in a flow mod message performs an operation which is inconsistent with the match, for example, a pop VLAN action with a match specifying no VLAN, or a set IPv4 address action with a match wildcarding the Ethertype, the switch may optionally reject the flow and immediately return an ofp_error_msg with OFPET_BAD_ACTION type and OFPBAC_MATCH_INCONSISTENT code. | Y | Y | Y | Y |
|
|
|
| If any other errors occur during the processing of the flow mod message, the switch may return an ofp_error_msg with OFPET_FLOW_MOD_FAILED type and OFPFMC_UNKNOWN code. | Y | Y | Y | Y |
|
|
| OFPFC_DELETE or OFPFC_DELETE_STRICT | If a matching entry exists in the table, it must be deleted. | Y | Y | Y | Y |
|
|
|
| If the entry has the OFPFF_SEND_FLOW_REM flag set, it should generate a flow removed message. | Y | Y | Y | Y |
|
|
|
| If no flow currently residing in the requested table matches the request, no error is recorded, and no flow table modification occurs. | Y | Y | Y | Y |
|
|
|
| In the strict versions, the set of match fields, all match fields, including their masks, and the priority, are strictly matched against the entry, and only an identical flow is modified or removed. | Y | Y | Y | Y |
|
|
|
| For non-strict modify and delete commands, all flows that match the flow mod description are modified or removed. | Y | Y | Y | Y |
|
|
|
| In the non-strict versions, a match will occur when a flow entry exactly matches or is more specific than the description in the flow mod command; in the flow mod the missing match fields are wildcarded, field masks are active, and other flow mod fields such as priority are ignored. | Y | Y | Y | Y |
|
|
|
| Delete commands can be optionally filtered by destination group or output port. | N | N | N | N |
|
|
|
| If the out_port field contains a value other than OFPP_ANY, it introduces a constraint when matching. | Y | Y | Y | Y |
|
|
|
| Modify and delete commands can also be filtered by cookie value. | Y | Y | Y | Y |
|
|
|
| Delete commands can use the OFPTT_ALL value for table-id to indicate that matching flows are to be deleted from all flow tables. | Y | Y | Y | Y |
|
|
|
| If the flow modification message specifies an invalid table-id, the switch should send an ofp_error_msg with OFPET_FLOW_MOD_FAILED type and OFPFMFC_BAD_TABLE_ID code. | Y | Y | Y | Y |
|
|
|
| If the instructions requested in a flow mod message are unknown the switch must return an ofp_error_msg with OFPET_BAD_INSTRUCTION type and OFPBIC_UNKNOWN_INST code. | Y | Y | Y | Y |
|
|
|
| If the instructions requested in a flow mod message are unsupported the switch must return an ofp_error_msg with OFPET_BAD_INSTRUCTION type and OFPBIC_UNSUP_INST code. | Y | Y | Y | Y |
|
|
|
| If the instructions requested contain a Goto-Table and the next-table-id refers to an invalid table the switch must return an ofp_error_msg with OFPET_BAD_INSTRUCTION type and OFPBIC_BAD_TABLE_ID code. | Y | Y | Y | Y |
|
|
|
| If the instructions requested contain a Write-Metadata and the metadata value or metadata mask value is unsupported then the switch must return an ofp_error_msg with OFPET_BAD_INSTRUCTION type and OFPBIC_UNSUP_METADATA or OFPBIC_UNSUP_METADATA_MASK code. | Y | Y | Y | Y |
|
|
|
| If the bitmasks specified in both the datalink and network addresses are not supported then OFPBMC_BAD_DL_ADDR_MASK should be used. | Y | Y | Y | Y |
|
|
|
| If any action references a port that will never be valid on a switch, the switch must return an ofp_error_msg with OFPET_BAD_ACTION type and OFPBAC_BAD_OUT_PORT code. | Y | Y | Y | Y |
|
|
|
| If the referenced port may be valid in the future, e.g. when a linecard is added to a chassis switch, or a port is dynamically added to a software switch, the switch may either silently drop packets sent to the referenced port, or immediately return an OFPBAC_BAD_OUT_PORT error and refuse the flow mod. | Y | Y | Y | Y |
|
|
|
| If an action list contain a sequence of actions that the switch can not support in the specified order, the switch should return an ofp_error_msg with OFPET_BAD_ACTION type and OFPBAC_UNSUPPORTED_ORDER code. | Y | Y | Y | Y |
|
|
|
|
|
|
|
|
|
|
6.8 | Flow Removal | Switch flow expiry mechanism | Is run by the switch independently of the controller and is based on the state and configuration of flow entries. | Y | Y | Y | Y |
|
|
|
| A non-zero hard_timeout field causes the flow entry to be removed after the given number of seconds, regardless of how many packets it has matched. | Y | Y | Y | Y |
|
|
|
| A non-zero idle_timeout field causes the flow entry to be removed when it has matched no packets in the givennumber of seconds. | Y | Y | Y | Y |
|
|
|
| The switch must implement flow expiry and remove flow entries from the flow table when one of their timeout is exceeded. | Y | Y | Y | Y |
|
|
|
| When a flow entry is removed, the switch must check the flow entry's OFPFF_SEND_FLOW_REM flag. If this flag is set, the switch must send a flow removed message to the controller. | Y | Y | Y | Y |
|
|
|
| Each flow removed message contains a complete description of the flow entry, the reason for removal (expiry or delete), the flow entry duration at the time of removal, and the flow statistics at time of removal. | Y | Y | Y | Y |
|
6.9 | Group Table Modification Messages | OFPGC_ADD | Groups may consist of zero or more buckets. | Y | Y | Y | Y |
|
|
|
| A group may also include buckets which themselves forward to other groups if the switch supports it. | Y | Y | Y | Y |
|
|
|
| The action set for each bucket must be validated using the same rules as those for flow mods (Section 6.7), with additional group-specific checks. | Y | Y | Y | Y |
|
|
|
| If an action in one of the buckets is invalid or unsupported, the switch should return an ofp_error_msg with OFPET_BAD_ACTION type and code corresponding to the error. | Y | Y | Y | Y |
|
|
|
| If a group entry with the specified group identifier already resides in the group table, then the switch must refuse to add the group entry and must send an ofp_error_msg with OFPET_GROUP_MOD_FAILED type and OFPGMFC_GROUP_EXISTS code. | Y | Y | Y | Y |
|
|
|
| If a specified group type is invalid then the switch must refuse to add the group entry and must send an ofp_error_msg with OFPET_GROUP_MOD_FAILED type and OFPGMFC_INVALID_GROUP code. | Y | Y | Y | Y |
|
|
|
| If a switch does not support unequal load sharing with select groups (buckets with weight different than 1), it must refuse to add the group entry and must send an ofp_error_msg with OFPET_GROUP_MOD_FAILED type and OFPGMFC_WEIGHT_UNSUPPORTED code. | Y | Y | Y | Y |
|
|
|
| If a switch cannot add the incoming group entry due to lack of space, the switch must send an ofp_error_msg with OFPET_GROUP_MOD_FAILED type and OFPGMFC_OUT_OF_GROUPS code. | Y | Y | Y | Y |
|
|
|
| If a switch cannot add the incoming group entry due to restrictions (hardware or otherwise) limiting the number of group buckets, it must refuse to add the group entry and must send an ofp_error_msg with OFPET_GROUP_MOD_FAILED type and OFPGMFC_OUT_OF_BUCKETS code. | Y | Y | Y | Y |
|
|
|
| If a switch cannot add the incoming group because it does not support the proposed liveliness configuration, the switch must send an ofp_error_msg with OFPET_GROUP_MOD_FAILED type and OFPGMFC_WATCH_UNSUPPORTED code. | N | N | N | N |
|
|
| OFPGC_MODIFY | if a group entry with the specified group identifier already resides in the group table, then that entry, including its type and action buckets, must be removed, and the new group entry added. | Y | Y | Y | Y |
|
|
|
| If a group entry with the specified group identifier does not already exist then the switch must refuse the group mod and send an ofp_error_msg with OFPET_GROUP_MOD_FAILED type and OFPGMFC_UNKNOWN_GROUP code | Y | Y | Y | Y |
|
|
| OFPGC_DELETE | If no group entry with the specified group identifier currentlyexists in the group table, no error is recorded, and no group table modification occurs | Y | Y | Y | Y |
|
|
|
| To delete all groups with a single message, specify OFPG_ALL as the group value | Y | Y | Y | Y |
|
|
| Groups | Groups may be chained if the switch supports it, when at least one group forward to another group, or in more complex configuration | Y | Y | Y | Y |
|
|
|
| If a switch does not support groups of groups, it must send an ofp_error_msg with OFPET_GROUP_MOD_FAILED type and OFPGMFC_CHAINING_UNSUPPORTED code. | Y | Y | Y | Y |
|
|
|
| A switch may support checking that no loop is created while chaining groups. | Y | Y | Y | Y |
|
|
|
| If a group mod is sent such that a forwarding loop would be created, the switch must reject the group mod and must send an ofp_error_msg with OFPET_GROUP_MOD_FAILED type and OFPGMFC_LOOP code. | Y | Y | Y | Y |
|
|
|
| A switch may support checking that groups forwarded to by other groups are not removed. | N | N | N | N |
|
|
|
| If a switch cannot delete a group because it is referenced by another group, it must refuse to delete the group entry and must send an ofp_error_msg with OFPET_GROUP_MOD_FAILED type and OFPGMFC_CHAINED_GROUP code. | Y | Y | Y | Y |
|
|
|
|
|
|
|
|
|
|
A | Appendix A The OpenFlow Protocol |
|
|
|
|
|
|
|
A.2.1 | Port Structures | Port_no field uniquely identifies a port within a switch | Ports are numbered starting from 1. | Y | Y | Y | Y |
|
|
| Name field is a null-terminated string containing a human-readable name for the interface |
| Y | Y | Y | Y |
|
|
| Port administrative settings support the following states | The OFPPC_PORT_DOWN bit indicates that the port has been administratively brought down and should not be used by OpenFlow. | Y | Y | Y | Y |
|
|
|
| The OFPPC_NO_RECV bit indicates that packets received on that port shouldbe ignored. | Y | Y | Y | Y |
|
|
|
| The OFPPC_NO_FWD bit indicates that OpenFlow should not send packets to that port. | Y | Y | Y | Y |
|
|
|
| The OFPPC_NO_FWD bit indicates that OpenFlow should not send packets to that port. | Y | Y | Y | Y |
|
|
|
| The OFPPFL_NO_PACKET_IN bit indicates that packets on that port that generate a table miss should never trigger a packet-in message to the controller | Y | Y | Y | Y |
|
|
|
| The port config bits are set by the controller and not changed by the switch. |
|
|
|
|
|
|
|
| If the port config bits are changed by the switch through another administrative interface, the switch sends an OFPT_PORT_STATUS message to notify the controller of the change. | Y | Y | Y | Y |
|
|
| State field describes the port internal state that supports the following states | OFPPS_LINK_DOWN bit indicates the physical link is not present. | Y | Y | Y | Y |
|
|
|
| The OFPPS_BLOCKED bit indicates that a switch protocol outside of OpenFlow, such as 802.1D Spanning Tree, is preventing the use of that port with OFPP_FLOOD. | Y | Y | Y | Y |
|
|
|
| OFPPS_LIVE indicates Live for Fast Failover Group. | N | N | N | N |
|
|
|
| All port state bits are read-only and cannot be changed by the controller. | Y | Y | Y | Y |
|
|
|
| When the port flags are changed, the switch sends an OFPT_PORT_STATUS message to notify the controller of the change. | Y | Y | Y | Y |
|
|
| Curr, advertised, supported, and peer fields indicate link modes (speed and duplexity), link type (copper/fiber) and link features (auto negotiation and pause) |
| Y | Y | Y | Y |
|
|
| Curr_speed and max_speed fields indicate the current and maximum bit rate (raw transmission speed) of the link in kbps |
| Y | Y | Y | Y |
|
|
|
|
|
|
|
|
|
|
A.2.2 | Queue Structures | QoS (DSCP & Q mapping?) | An OpenFlow switch provides limited Quality-of-Service support (QoS) through a simple queuing mechanism. One (or more) queues can attach to a port and be used to map flows on it. Flows mapped to a specific queue will be treated according to that queue's configuration. | Y | Y | Y | Y |
|
A.2.3 | Flow Match Structures | OpenFlow match is composed of a flow match header and a sequence of zero or more flow match fields | The only valid match type in this specification is OFPMT_OXM, the OpenFlow 1.1 match type OFPMT_STANDARD is deprecated. | Y | Y | Y | Y |
|
|
|
| The flow match fields are described using the OpenFlow Extensible Match (OXM) format. | Y | Y | Y | Y |
|
|
| OpenFlow specification distinguishes two types of OXM match classes | ONF member classes. |
|
|
|
|
|
|
|
| ONF reserved classes. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Flow Match Fields |
|
|
|
|
|
|
|
| OXM_OF_IN_PORT | /* Switch input port. */ | Y | Y | Y | Y |
|
|
| OXM_OF_IN_PHY_PORT | /* Switch physical input port. */ | Y | Y | Y | Y |
|
|
| OXM_OF_METADATA | /* Metadata passed between tables. */ | N | N | N | N |
|
|
| OXM_OF_ETH_DST | /* Ethernet destination address. */ | Y | Y | Y | Y |
|
|
| OXM_OF_ETH_SRC | /* Ethernet source address. */ | Y | Y | Y | Y |
|
|
| OXM_OF_ETH_TYPE | /* Ethernet frame type. */ | Y | Y | Y | Y |
|
|
| OXM_OF_VLAN_VID | /* VLAN id. */ | Y | Y | Y | Y |
|
|
| OXM_OF_VLAN_PCP | /* VLAN priority. */ | Y | Y | Y | Y |
|
|
| OXM_OF_IP_DSCP | /* IP DSCP (6 bits in ToS field). */ | Y | Y | Y | Y |
|
|
| OXM_OF_IP_ECN | /* IP ECN (2 bits in ToS field). */ | N | N | N | N |
|
|
| OXM_OF_IP_PROTO | /* IP protocol. */ | Y | Y | Y | Y |
|
|
| OXM_OF_IPV4_SRC | /* IPv4 source address. */ | Y | Y | Y | Y |
|
|
| OXM_OF_IPV4_DST | /* IPv4 destination address. */ | Y | Y | Y | Y |
|
|
| OXM_OF_TCP_SRC | /* TCP source port. */ | Y | Y | Y | Y |
|
|
| OXM_OF_TCP_DST | /* TCP destination port. */ | Y | Y | Y | Y |
|
|
| OXM_OF_UDP_SRC | /* UDP source port. */ | Y | Y | Y | Y |
|
|
| OXM_OF_UDP_DST | /* UDP destination port. */ | Y | Y | Y | Y |
|
|
| OXM_OF_SCTP_SRC | /* SCTP source port. */ | N | N | N | N |
|
|
| OXM_OF_SCTP_DST | /* SCTP destination port. */ | N | N | N | N |
|
|
| OXM_OF_ICMPV4_TYPE | /* ICMP type. */ | N | N | N | N |
|
|
| OXM_OF_ICMPV4_CODE | /* ICMP code. */ | N | N | N | N |
|
|
| OXM_OF_ARP_OP | /* ARP opcode. */ | Y | Y | Y | N | All ARP matches are supported via software |
|
| OXM_OF_ARP_SPA | /* ARP source IPv4 address. */ | Y | Y | Y | N |
|
|
| OXM_OF_ARP_TPA | /* ARP target IPv4 address. */ | Y | Y | Y | N |
|
|
| OXM_OF_ARP_SHA | /* ARP source hardware address. */ | Y | Y | Y | N |
|
|
| OXM_OF_ARP_THA | /* ARP target hardware address. */ | Y | Y | Y | N |
|
|
| OXM_OF_IPV6_SRC | /* IPv6 source address. */ | Y | Y | Y | Y |
|
|
| OXM_OF_IPV6_DST | /* IPv6 destination address. */ | Y | Y | Y | Y |
|
|
| OXM_OF_IPV6_FLABEL | /* IPv6 Flow Label */ | N | N | N | N |
|
|
| OXM_OF_ICMPV6_TYPE | /* ICMPv6 type. */ | N | N | N | N |
|
|
| OXM_OF_ICMPV6_CODE | /* ICMPv6 code. */ | N | N | N | N |
|
|
| OXM_OF_IPV6_ND_TARGET | /* Target address for ND. */ | N | N | N | N |
|
|
| OXM_OF_IPV6_ND_SLL | /* Source link-layer for ND. */ | N | N | N | N |
|
|
| OXM_OF_IPV6_ND_TLL | /* Target link-layer for ND. */ | N | N | N | N |
|
|
| OXM_OF_MPLS_LABEL | /* MPLS label. */ | Y | Y | Y | Y |
|
|
| OXM_OF_MPLS_TC | /* MPLS TC. */ | N | N | N | N |
|
|
|
|
|
|
|
|
|
|
|
| Required match fields |
|
|
|
|
|
|
|
| OXM_OF_IN_PORT | Ingress port. This may be a physical or switch-defined logical port. | Y | Y | Y | Y |
|
|
| OXM_OF_ETH_DST | Ethernet source address. Can use arbitrary bitmask. | Y | Y | Y | Y |
|
|
| OXM_OF_ETH_SRC | Ethernet destination address. Can use arbitrary bitmask. | Y | Y | Y | Y |
|
|
| OXM_OF_ETH_TYPE | Ethernet type of the OpenFlow packet payload, after VLAN tags. | Y | Y | Y | Y |
|
|
| OXM_OF_IP_PROTO | IPv4 or IPv6 protocol number. | Y | Y | Y | Y |
|
|
| OXM_OF_IPV4_SRC | IPv4 source address. Can use subnet mask or arbitrary bitmask. | Y | Y | Y | Y |
|
|
| OXM_OF_IPV4_DST | IPv4 destination address. Can use subnet mask or arbitrary bitmask. | Y | Y | Y | Y |
|
|
| OXM_OF_IPV6_SRC | IPv6 source address. Can use subnet mask or arbitrary bitmask. | Y | Y | Y | Y |
|
|
| OXM_OF_IPV6_DST | IPv6 destination address. Can use subnet mask or arbitrary bitmask. | Y | Y | Y | Y |
|
|
| OXM_OF_TCP_SRC | TCP source port. | Y | Y | Y | Y |
|
|
| OXM_OF_TCP_DST | TCP destination port. | Y | Y | Y | Y |
|
|
| OXM_OF_UDP_SRC | UDP source port. | Y | Y | Y | Y |
|
|
| OXM_OF_UDP_DST | UDP destination port. | Y | Y | Y | Y |
|
|
|
|
|
|
|
|
|
|
A.2.4 | Flow Instruction Structures | See Section 5.6 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
A.2.5 | Action Structures | A number of actions may be associated with flows, groups or packets. The currently defined action types are |
|
|
|
|
|
|
|
| OFPAT_OUTPUT = 0, | /* Output to switch port. */ | Y | Y | Y | Y |
|
|
| OFPAT_COPY_TTL_OUT = 11, | /* Copy TTL "outwards" – from next-to-outermost to outermost */ | N | N | N | N |
|
|
| OFPAT_COPY_TTL_IN = 12, | /* Copy TTL "inwards" – from outermost to next-to-outermost */ | N | N | N | N |
|
|
| OFPAT_SET_MPLS_TTL = 15, | /* MPLS TTL */ | Y | Y | Y | Y |
|
|
| OFPAT_DEC_MPLS_TTL = 16, | /* Decrement MPLS TTL */ | Y | Y | Y | Y |
|
|
| OFPAT_PUSH_VLAN = 17, | /* Push a new VLAN tag */ | N | N | Y | N |
|
|
| OFPAT_POP_VLAN = 18, | /* Pop the outer VLAN tag */ | N | N | Y | N |
|
|
| OFPAT_PUSH_MPLS = 19, | /* Push a new MPLS tag */ | Y | Y | Y | Y |
|
|
| OFPAT_POP_MPLS = 20, | /* Pop the outer MPLS tag */ | Y | Y | Y | Y |
|
|
| OFPAT_SET_QUEUE = 21, | /* Set queue id when outputting to a port */ | Y | Y | Y | Y |
|
|
| OFPAT_GROUP = 22, | /* Apply group. */ | Y | Y | Y | Y |
|
|
| OFPAT_SET_NW_TTL = 23, | /* IP TTL. */ | N | N | N | N |
|
|
| OFPAT_DEC_NW_TTL = 24, | /* Decrement IP TTL. */ | N | N | N | N |
|
|
| OFPAT_SET_FIELD = 25, | /* Set a header field using OXM TLV format. */ | Y | Y | Y | Y |
|
|
| OFPAT_EXPERIMENTER = 0xffff |
| Y | Y | Y | Y |
|
|
|
|
|
|
|
|
|
|
|
| The type of a set-field action can be any valid OXM header type | OXM types OFPXMT_OFB_IN_PORT and OFPXMT_OFB_METADATA are not supported, because those are not header fields. |
|
|
|
|
|
|
| OXM_OF_IN_PHY_PORT | /* Switch physical input port. */ | N | N | N | N |
|
|
| OXM_OF_ETH_DST | /* Ethernet destination address. */ | Y | Y | Y | Y |
|
|
| OXM_OF_ETH_SRC | /* Ethernet source address. */ | Y | Y | Y | Y |
|
|
| OXM_OF_ETH_TYPE | /* Ethernet frame type. */ | Y | Y | Y | Y |
|
|
| OXM_OF_VLAN_VID | /* VLAN id. */ | Y | Y | Y | Y |
|
|
| OXM_OF_VLAN_PCP | /* VLAN priority. */ | Y | Y | Y | Y |
|
|
| OXM_OF_IP_DSCP | /* IP DSCP (6 bits in ToS field). */ | Y | Y | Y | Y |
|
|
| OXM_OF_IP_ECN | /* IP ECN (2 bits in ToS field). */ | N | N | N | N |
|
|
| OXM_OF_IP_PROTO | /* IP protocol. */ | N | N | N | N |
|
|
| OXM_OF_IPV4_SRC | /* IPv4 source address. */ | N | N | N | N |
|
|
| OXM_OF_IPV4_DST | /* IPv4 destination address. */ | N | N | N | N |
|
|
| OXM_OF_TCP_SRC | /* TCP source port. */ | N | N | N | N |
|
|
| OXM_OF_TCP_DST | /* TCP destination port. */ | N | N | N | N |
|
|
| OXM_OF_UDP_SRC | /* UDP source port. */ | N | N | N | N |
|
|
| OXM_OF_UDP_DST | /* UDP destination port. */ | N | N | N | N |
|
|
| OXM_OF_SCTP_SRC | /* SCTP source port. */ | N | N | N | N |
|
|
| OXM_OF_SCTP_DST | /* SCTP destination port. */ | N | N | N | N |
|
|
| OXM_OF_ICMPV4_TYPE | /* ICMP type. */ | N | N | N | N |
|
|
| OXM_OF_ICMPV4_CODE | /* ICMP code. */ | N | N | N | N |
|
|
| OXM_OF_ARP_OP | /* ARP opcode. */ | Y | Y | Y | Y |
|
|
| OXM_OF_ARP_SPA | /* ARP source IPv4 address. */ | Y | Y | Y | Y |
|
|
| OXM_OF_ARP_TPA | /* ARP target IPv4 address. */ | Y | Y | Y | Y |
|
|
| OXM_OF_ARP_SHA | /* ARP source hardware address. */ | Y | Y | Y | Y |
|
|
| OXM_OF_ARP_THA | /* ARP target hardware address. */ | Y | Y | Y | Y |
|
|
| OXM_OF_IPV6_SRC | /* IPv6 source address. */ | N | N | N | N |
|
|
| OXM_OF_IPV6_DST | /* IPv6 destination address. */ | N | N | N | N |
|
|
| OXM_OF_IPV6_FLABEL | /* IPv6 Flow Label */ | N | N | N | N |
|
|
| OXM_OF_ICMPV6_TYPE | /* ICMPv6 type. */ | N | N | N | N |
|
|
| OXM_OF_ICMPV6_CODE | /* ICMPv6 code. */ | N | N | N | N |
|
|
| OXM_OF_IPV6_ND_TARGET | /* Target address for ND. */ | N | N | N | N |
|
|
| OXM_OF_IPV6_ND_SLL | /* Source link-layer for ND. */ | N | N | N | N |
|
|
| OXM_OF_IPV6_ND_TLL | /* Target link-layer for ND. */ | N | N | N | N |
|
|
| OXM_OF_MPLS_LABEL | /* MPLS label. */ | Y | Y | Y | Y |
|
|
| OXM_OF_MPLS_TC | /* MPLS TC. */ | Y | Y | Y | Y |
|
|
|
|
|
|
|
|
|
|
A.3 | Controller-to-Switch Messages |
|
|
|
|
|
|
|
A.3.1 | Handshake | Datapath_id | The datapath_id field uniquely identifies a datapath. The lower 48 bits are intended for the switch MAC address, while the top 16 bits are up to the implementer. | Y | Y | Y | Y |
|
|
|
| Use datapath_id to distinguish multiple virtual switch instances on a single physical switch. | Y | Y | Y | Y |
|
|
| Capabilities supported by the datapath | OFPC_FLOW_STATS = 1 << 0, /* Flow statistics. */ | Y | Y | Y | Y |
|
|
|
| OFPC_TABLE_STATS = 1 << 1, /* Table statistics. */ | Y | Y | Y | Y |
|
|
|
| OFPC_PORT_STATS = 1 << 2, /* Port statistics. */ | Y | Y | Y | Y |
|
|
|
| OFPC_GROUP_STATS = 1 << 3, /* Group statistics. */ | Y | Y | Y | Y |
|
|
|
| OFPC_IP_REASM = 1 << 5, /* Can reassemble IP fragments. */ | N | N | N | N |
|
|
|
| OFPC_QUEUE_STATS = 1 << 6, /* Queue statistics. */ | N | N | N | N |
|
|
|
| OFPC_PORT_BLOCKED = 1 << 8 /* Switch will block looping ports. */ | Y | Y | Y | Y |
|
|
|
|
|
|
|
|
|
|
A.3.2 | Switch Configuration | Controller is able to set and query configuration parameters in the switch with the OFPT_SET_CONFIG and OFPT_GET_CONFIG_REQUEST messages, respectively |
| Y | Y | Y | Y |
|
|
| OFPC_* flags | /* Handling of IP fragments. /OFPC_FRAG_NORMAL = 0, / No special handling for fragments. */ | Y | Y | Y | Y |
|
|
|
| OFPC_FRAG_DROP = 1 << 0, /* Drop fragments. */ | N | N | N | N |
|
|
|
| OFPC_FRAG_REASM = 1 << 1, /* Reassemble (only if OFPC_IP_REASM set). */ | N | N | N | N |
|
|
|
| OFPC_FRAG_MASK = 3, | N | N | N | N |
|
|
|
| /* TTL processing - applicable for IP and MPLS packets /OFPC_INVALID_TTL_TO_CONTROLLER = 1 << 2, / Send packets with invalid TTL to the controller */ | N | N | N | N |
|
|
| Miss_send_len | Defines the number of bytes of each packet sent to the controller as a result of flow table miss when configured to generate packet-in messages. | Y | Y | Y | Y |
|
|
|
| If this field equals 0, the switch must send zero bytes of the packet in the ofp_packet_in message. | Y | Y | Y | Y |
|
|
|
| If the value is set to OFPCML_NO_BUFFER the complete packet must be included in the message, and should not be buffered. | Y | Y | Y | Y |
|
|
|
|
|
|
|
|
|
|
A.3.3 | Flow Table Configuration | Flow tables are numbered from 0 and can take any number until OFPTT_MAX | OFPTT_MAX = 0xfe | Y | Y | Y | Y |
|
|
| Controller can configure and query table state in the switch with the OFP_TABLE_MOD and OFPST_TABLE_STATS requests, respectively | The switch responds to a table stats request with aOFPT_STATS_REPLY message. | Y | Y | Y | Y |
|
|
| OFP_TABLE_MOD | If the table_id is OFPTT_ALL, the configuration is applied to all tables in the switch. | Y | Y |