PicOS Support for OpenFlow 1.4
The following table contains OpenFlow 1.4 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.4.0.
Table 1 OpenFlow 1.4 Features Supported by PicOS
Pica8 OpenFlow V1.4 Compliance Matrix | ||||||
Chapter | Title | Features | Detail Feature Specification | Optional | R2.3 Support | Remarks |
2 | Switch Components | NA | ||||
Flow table | Y | |||||
Group table | All, indirect, select, fast_failover group table are all supported. | Y | ||||
Add/update/delete flow entries | Y | |||||
Match fields | Y | |||||
Counters | Y | |||||
Set of instructions | Y | |||||
4 | OpenFlow Ports | NA | ||||
4.1 | OpenFlow Ports | see 4.2-4.5 | Y | |||
4.2 | Standard Ports | See 4.2-4.5 | Y | |||
4.3 | Physical Ports | NA | ||||
Ingress | PicOS only supports it as matching port. | Y | ||||
Output | Y | |||||
Hardware interface | Y | |||||
Groups | Y | |||||
Port counters | Y | |||||
4.4 | Logical Ports | NA | The OpenFlow logical ports are switch defined ports that don't correspond directly to a hardware interface of the switch. | |||
Map to various physical ports | Y | |||||
LAG | Y | |||||
Tunnel (GRE) | Y | |||||
Lookback interface | Y | |||||
Ingress | Y | |||||
Output | Y | |||||
Groups | Y | |||||
4.5 | Reserved Ports | NA | ||||
All | Represents all ports the switch can use for forwarding a specific packet. Can be used only as an output port. | Y | ||||
Controller | Represents the control channel with the OpenFlow controller. Can be used as an ingress port or as an output port. | Y | ||||
Table | Represents the start of the OpenFlow pipeline. | Y | ||||
In_port | Represents the packet ingress port. Can be used only as an output port, send the packet out through its ingress port. | Y | Matching must specify the ingress port. | |||
Any | Special value used in some OpenFlow commands when no port is specified. Can neither be used as an ingress port nor as an output port. | N | ||||
Local | Represents the switch's local networking stack and its management stack. | O | Y | |||
Normal | Represents the traditional non-OpenFlow pipeline of the switch. Can be used only as an output port and processes the packet using the normal pipeline. | O | Y | |||
Flood | Represents flooding using the normal pipeline of the switch. Can be used only as an output port. | O | Y | |||
5 | OpenFlow Tables | NA | ||||
5.1 | Pipeline Processing | |||||
Openflow-only | All packets are processed by the OpenFlow pipeline. | Y | ||||
Openflow-hybrid | OpenFlow operation and normal Ethernet switching operation. | N | ||||
L2 Ethernet switching, L3 routing (IPv4 routing, IPv6 routing...), ACL and QoS processing. | N | |||||
VLAN isolation | N | |||||
A classification mechanism outside of OpenFlow that routes traffic to either the OpenFlow pipeline or the normal pipeline. | N | |||||
VLAN tag or input port whether to process the packet using which pipeline. | N | |||||
Normal and flood | N | |||||
Multiple flow tables, each flow table containing multiple flow entries | Y | |||||
Sequentially numbered, start at 0 | Y | |||||
Goto instruction | Y | |||||
Go forward and not backward | Y | |||||
Last table can not include goto instruction | N | |||||
Table miss | Y | |||||
5.2 | Flow Table | NA | ||||
Match fields | To match against packets.. | Y | ||||
Priority | Matching precedence of the flow entry. | Y | ||||
Counters | Updated when packets are matched. | Y | Only count by Byte | |||
Instructions | To modify the action set or pipeline processing. | Y | ||||
Timeouts | Maximum amount of time or idle time before flow is expired by the switch. | Y | ||||
Cookie | Opaque data value chosen by the controller. | Y | ||||
Wildcards all fields and priority equal 0 is table-miss | Y | |||||
5.3 | Matching | NA | ||||
Ingress port | Y | |||||
Metadata fields | N | |||||
Apply-actions | Y | |||||
Any | N | |||||
Highest priority matches packets be selected | Y | |||||
Counters update and instructions applied | Y | |||||
OFPFF_CHECK_OVERLAP | Y | |||||
OFPC_FRAG_REASM | N | |||||
Behavior when a switch receives a corrupted packet | N | |||||
5.4 | Table-miss | NA | ||||
Every flow table support table-miss | Y | |||||
Send packets to controller | Y | |||||
Drop packets | Y | |||||
Direct packets to a subsequent table | Y | |||||
Wildcard all match fields | N | MAC/IP/Port can support wildcard. | ||||
Priority= 0 | Y | |||||
Not exist by default | Y | |||||
Add or remove by controller at any time | Y | |||||
May expire | N | |||||
Match packets unmatched by others | Y | |||||
Instructions applied | Y | |||||
Packet-in reason is table-miss | Y | |||||
Packets unmatched are dropped is not exist table-miss | Y | |||||
5.5 | Flow Removal | NA | ||||
Is run by the switch independently of the controller and is based on the state and configuration of flow entries. | 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 | |||||
A non-zero idle_timeout field causes the flow entry to be removed when it has matched no packets in the given number of seconds. | Y | |||||
The switch must implement flow expiry and remove flow entries from the flow table when one of their timeouts is exceeded. | Y | |||||
OFPFF_SEND_FLOW_REM flag | 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 | ||||
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 | |||||
Eviction | Flow entries may be evicted from flow tables when the switch needs to reclaim resources. | Y | ||||
5.6 | Group Table | NA | ||||
Group identifier | Y | |||||
Group type | Y | |||||
Counters | Y | |||||
Action buckets | Y | |||||
5.6.1 | Group Types | All | Used for multicast or broadcast. | Y | ||
Effectively cloned for each bucket.. | Y | |||||
Process for each bucket. | Y | Some limitation, please see configuration guide. | ||||
Direct out the ingress, packet is dropped. | Y | |||||
Output action to OFPP_IN_PORT | Y | Need to specify the in_port in matching. | ||||
Select | Processed by a single bucket. | Y | ||||
Switch-computed selection algorithm. | Y | |||||
Bucket weight | N | |||||
Forward to live ports | Y | |||||
Indirect | Supports only a single bucket. | Y | ||||
Multiple flow entries or groups to point to a common group identifier. | Y | |||||
Supporting faster, more efficient convergence. | N | |||||
Effectively identical to an all group with one bucket. | Y | |||||
Fast failover | Execute the first live bucket. | Y | ||||
Associated with a port and/or group. | Y | |||||
Change forwarding without request to controller. | Y | |||||
No bucket live, packet dropped. | Y | |||||
5.7 | Meter Table | |||||
Meter entries | Y | |||||
Per-flow meters | Y | |||||
Rate-limit | Y | |||||
Combine with per-port queue | Y | |||||
Measure and control packet rate | Y | |||||
Attached to flow entries | Y | |||||
In flow instruction set | Y | |||||
Multiple meters in the same table | Y | |||||
Multiple meters on the same set of packets | Y | |||||
Meter identifier | Y | |||||
5.7.1 | Meter Bands | |||||
One band | Y | |||||
More meter bands | N | |||||
The rate band applies and the way packets be process | Y | |||||
Processed by a single meter band based on the current measured meter rate | Y | |||||
Configure rate lower than current rate | Y | |||||
No meter band applied if current rate lower than specified rate | Y | |||||
Band type | Y | |||||
Rate | Y | |||||
Counters | Y | |||||
5.8 | Counters | NA | ||||
Per Table Counters | Reference count (active entries) | 32 bits | Y | |||
Packet Lookups | 64 bits | Y | ||||
Packet Matches | 64 bits | Y | ||||
Per Flow Counters | Received Packets | 64 bits | Y | |||
Received Bytes | 64 bits | Y | ||||
Duration (seconds) | 32 bits | Y | ||||
Duration (nanoseconds) | 32 bits | |||||
Per Port Counters | Received Packets | 64 bits | Y | |||
Transmitted Packets | 64 bits | Y | ||||
Received Bytes | 64 bits | Y | ||||
Transmitted Bytes | 64 bits | Y | ||||
Receive Drops | 64 bits | Y | ||||
Transmit Drops | 64 bits | Y | ||||
Receive Errors | 64 bits | Y | ||||
Transmit Errors | 64 bits | Y | ||||
Receive Frame Alignment Errors | 64 bits | Y | ||||
Receive Overrun Errors | 64 bits | Y | ||||
Receive CRC Errors | 64 bits | Y | ||||
Collisions | 64 bits | Y | ||||
Per Queue Counters | Transmit Packets | 64 bits | N | |||
Transmit Bytes | 64 bits | N | ||||
Transmit Overrun Errors | 64 bits | N | ||||
Per Group Counters | Reference Count (flow entries) | 32 bits | Y | |||
Packet Count | 64 bits | Y | ||||
Byte Count | 64 bits | N | ||||
Per Bucket Counters | Packet Count | 64 bits | N | |||
Byte Count | 64 bits | N | ||||
5.9 | Instructions | |||||
The controller can query the switch about which of the “Optional Instructions” it supports. | Y | |||||
Apply-Actions action(s) | Y | |||||
Clear-Actions | Y | |||||
Write-Actions action(s) | Y | |||||
Write-Metadata metadata/mask | Y | |||||
Goto-Table next-table-id | Y | |||||
Clear-Actions instruction is executed before the Write-Actions instruction. | Y | |||||
Goto-Table is executed last. | Y | |||||
Reject a flow entry if it is unable to execute the instructions & return an unsupported flow error. | N | |||||
5.10 | Action Set | |||||
Action set is associated with each packet. | Y | |||||
This set is empty by default. | Y | |||||
Action set is carried between flow tables. | 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 | |||||
Action set contains a maximum of one action of each type. | Y | |||||
The actions in an action set are applied in the order specified below. | Y | |||||
1. copy TTL inwards | N | |||||
2. pop | Y | |||||
3. push | Y | |||||
4. copy TTL outwards | N | |||||
5. decrement TTL | N | |||||
6. set | Y | |||||
7. qos | Y | |||||
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 | ||||
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. | N | ||||
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. | N | |||||
If no output action and no group action were specified in an action set, the packet is dropped. | N | |||||
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. | N | |||||
5.11 | 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 | ||||
The effect of those actions is cumulative. | 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 | |||||
If the list contains a group actions, a copy of the packet in its current state is processed by the relevant group buckets. | Y | |||||
5.12 | Actions | |||||
Output | Support forwarding to physical ports, switch-defined logical ports and the required reserved ports. | 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 | ||||
Drop | Y | |||||
Group | Y | |||||
Push-Tag/Pop-Tag | Order of header fields - Ethernet, VLAN, MPLS, ARP/IP, TCP/UDP/SCTP (IP-only). | 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. | Y | ||||
Pop VLAN header | Pop the outer-most VLAN header from the packet. | Y | ||||
Push MPLS header | Push a new MPLS shim header onto the packet. Only Ethertype 0x8847 and 0x8848 should be used. | Y | ||||
Pop MPLS header | Pop the outer-most MPLS tag or shim header from the packet. | Y | ||||
Push PBB header | Y | |||||
Pop PBB header | Y | |||||
Set-Field | Y | |||||
Set VLAN ID | Y | |||||
Strip VLAN ID | Y | |||||
Change-TTL | Modify the values of the IPv4 TTL, IPv6 Hop Limit or MPLS TTL in the packet. | N | ||||
If it is supported, applied to the outermost-possible header. | 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 | ||||
Decrement MPLS TTL | Decrement the MPLS TTL. Only applies to packets with an existing MPLS shim header. | N | ||||
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 | ||||
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 | ||||
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 | ||||
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 | ||||
5.12.1 | Default values for field 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 | ||||
New fields listed in Table 6 without corresponding existing fields should be set to zero. | VLAN priority ← VLAN priority | Y | ||||
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 | ||||
Fields in new headers may be overridden by specifying a “set” action for the appropriate field(s) after the push operation. | PBB label ← PBB label | Y | ||||
6 | OpenFlow Channel | |||||
6.1 | OpenFlow Protocol Overview | The OpenFlow protocol supports three message types, controller-to-switch, asynchronous, and sym-metric, each with multiple sub-types. | ||||
6.1.1 | Controller-to-Switch | Controller/switch messages are initiated by the controller and may or may not require a response from the switch. | Y | |||
6.1.2 | Asynchronous | Asynchronous messages are sent without a controller soliciting them from a switch. | Y | |||
Switches send asynchronous messages to controllers to denote a packet arrival or switch state change. | Y | |||||
6.1.3 | Symmetric | Symmetric messages are sent without solicitation, in either direction., including Hello, Echo, Error, Experimenter message. | Y | |||
6.2 | Message Handling | The OpenFlow protocol provides reliable message delivery and processing, but does not automatically provide acknowledgements or ensure ordered message processing. | Y | |||
6.3 | OpenFlow Channel Connections | The OpenFlow channel is used to exchange OpenFlow message between an OpenFlow switch and an OpenFlow controller. | ||||
6.3.1 | Connection Setup | The switch must be able to establish communication with a controller at a user-configurable IP address, using either a user-specified transport port or the default transport port. | Y | |||
6.3.2 | Connection Interruption | In the case that a switch loses contact with all controllers the switch must immediately enter either \fail secure mode" or \fail standalone mode", depending upon the switch implementation and configuration. | Y | |||
6.3.3 | Encryption | The switch and controller may communicate through a TLS connection. | Y | |||
6.3.4 | Multiple Controllers | The switch may establish communication with a single controller, or may establish communication with multiple controllers. | Y | |||
6.3.5 | Auxiliary Connections | The OpenFlow channel may also be composed of a main connection and multiple auxiliary connections. | Y | |||
6.4 | Flow Table Modification Messages | Flow table modification messages are used to add, modify, delete flow. | Y | |||
6.5 | Flow Table Synchronization | A flow table may be synchronized with another flow table. with Flow Table Synchronization | N | |||
6.6 | Group Table Modification Messages | Action of group (including add, modify, delete) can be done by Group table modification messages. | Y | |||
6.7 | Meter Modification Messages | Action of meter (including add, modify, delete) can be done by Meter modification messages. | Y | |||
6.8 | Bundle Messages | |||||
6.8.1 | Bundle overview | A bundle is a sequence of OpenFlow modification requests from the controller that is applied as a single OpenFlow operation. | Y | |||
6.8.2 | Bundle example usage | Y | ||||
6.8.3 | Bundle error processing | The OpenFlow messages part of a bundle must be pre-validated before they are stored in the bundle. | Y | |||
6.8.4 | Bundle atomic modifications | Committing the bundle must be controller atomic. | N | |||
6.8.5 | Bundle parallelism | The switch must support exchanging echo request and echo reply messages during the creation and population of the bundle, the switch must reply to an echo request without waiting for the end of the bundle. | Y | |||
7 | The OpenFlow Protocol | |||||
7.1 | OpenFlow Header | Each Openflow message begins with the OpenFlow header | Y | |||
7.1.1 | Padding | Most OpenFlow messages contain padding fields. | Y | |||
7.2 | Common Structures | |||||
7.2.1 | Port Structures | The switch may define physical and logical ports. | Y | |||
7.2.1.1 | Port Description Structures, the physical ports, switch-defined logical ports, and the OFPP_LOCAL reserved port | Ports includes: OFPP_IN_PORT,OFPP_TABLE, OFPP_NORMAL, OFPP_FLOOD, OFPP_ALL, OFPP_CONTROLLER, OFPP_LOCAL,OFPP_ANY | Y | |||
7.2.1.2 | Port Description Properties. A property definition contains the property type, length, and any associated data. | Associated date includes curr, advertised, supported, peer, each one consists of speed, duplexity. | Y | |||
7.2.2 | Flow Match Structures | An OpenFlow match is composed of a flow match header and a sequence of zero or more flow match fields. | Y | |||
7.2.2.1 | Flow Match Header, Fields to match against flows | The flow match header is described by the ofp_match structure, The type field is set to OFPMT_OXM and length field is set to the actual length of ofp_match structure including all match fields. The payload of the OpenFlow match is a set of OXM Flow match fields. | Y | |||
7.2.2.2 | Flow Match Field Structures | The flow match fields are described using the OpenFlow Extensible Match (OXM) format, which is a compact type-length-value (TLV) format. | Y | |||
7.2.2.3 | OXM classes | The match types are structured using OXM match classes, The OpenFlow specification distinguishes two types of OXM match classes, ONF member classes and ONF reserved classes, diferentiated by their high order bit. | Y | |||
7.2.2.4 | Flow Matching | A zero-length OpenFlow match (one with no OXM TLVs) matches every packet. Match fields that should be wildcarded are omitted from the OpenFlow match. | Y | |||
7.2.2.5 | Flow Match Field Masking | The masks are defined such that a 0 in a given bit position indicates a \don't care" match for the same bit in the corresponding field, whereas a 1 means match the bit exactly. | Y | Some limitation, please see the configuration guide. | ||
7.2.2.6 | Flow Match Field Prerequisite | In general, matching header fields of a protocol can only be done if the OpenFlow match explitly matches the corresponding protocol. | Y | |||
7.2.2.7 | Flow Match Fields | Match fields contains: OFPXMT_OFB_IN_PORT, OFPXMT_OFB_IN_PHY_PORT, | Y | |||
OXM_OF_IN_PORT | /* Switch input port. */ | Y | ||||
OXM_OF_IN_PHY_PORT | /* Switch physical input port. */ | O | ||||
OXM_OF_METADATA | /* Metadata passed between tables. */ | O | ||||
OXM_OF_ETH_DST | /* Ethernet destination address. */ | Y | ||||
OXM_OF_ETH_SRC | /* Ethernet source address. */ | Y | ||||
OXM_OF_ETH_TYPE | /* Ethernet frame type. */ | Y | ||||
OXM_OF_VLAN_VID | /* VLAN id. */ | O | Y | |||
OXM_OF_VLAN_PCP | /* VLAN priority. */ | O | Y | |||
OXM_OF_IP_DSCP | /* IP DSCP (6 bits in ToS field). */ | O | Y | |||
OXM_OF_IP_ECN | /* IP ECN (2 bits in ToS field). */ | O | N | |||
OXM_OF_IP_PROTO | /* IP protocol. */ | Y | ||||
OXM_OF_IPV4_SRC | /* IPv4 source address. */ | Y | ||||
OXM_OF_IPV4_DST | /* IPv4 destination address. */ | Y | ||||
OXM_OF_TCP_SRC | /* TCP source port. */ | Y | ||||
OXM_OF_TCP_DST | /* TCP destination port. */ | Y | ||||
OXM_OF_UDP_SRC | /* UDP source port. */ | Y | ||||
OXM_OF_UDP_DST | /* UDP destination port. */ | Y | ||||
OXM_OF_SCTP_SRC | /* SCTP source port. */ | O | N | |||
OXM_OF_SCTP_DST | /* SCTP destination port. */ | O | N | |||
OXM_OF_ICMPV4_TYPE | /* ICMP type. */ | O | Y | |||
OXM_OF_ICMPV4_CODE | /* ICMP code. */ | O | Y | |||
OXM_OF_ARP_OP | /* ARP opcode. */ | O | Y | |||
OXM_OF_ARP_SPA | /* ARP source IPv4 address. */ | O | Y | |||
OXM_OF_ARP_TPA | /* ARP target IPv4 address. */ | O | Y | |||
OXM_OF_ARP_SHA | /* ARP source hardware address. */ | O | N | |||
OXM_OF_ARP_THA | /* ARP target hardware address. */ | O | N | |||
OXM_OF_IPV6_SRC | /* IPv6 source address. */ | Y | ||||
OXM_OF_IPV6_DST | /* IPv6 destination address. */ | Y | ||||
OXM_OF_IPV6_FLABEL | /* IPv6 Flow Label */ | O | N | |||
OXM_OF_ICMPV6_TYPE | /* ICMPv6 type. */ | O | N | |||
OXM_OF_ICMPV6_CODE | /* ICMPv6 code. */ | O | N | |||
OXM_OF_IPV6_ND_TARGET | /* Target address for ND. */ | O | N | |||
OXM_OF_IPV6_ND_SLL | /* Source link-layer for ND. */ | O | N | |||
OXM_OF_IPV6_ND_TLL | /* Target link-layer for ND. */ | O | N | |||
OXM_OF_MPLS_LABEL | /* MPLS label. */ | O | N | |||
OXM_OF_MPLS_TC | /* MPLS TC. */ | O | N | |||
7.2.2.8 | Experimenter Flow Match Fields | Experimenter-specific ow match fields,may be defined using the oxm_class=OFPXMC_EXPERIMENTER | O | N | ||
7.2.3 | Flow Instruction Structures | Flow instructions associated with a flow table entry are executed when a flow matches the entry. | ||||
7.2.4 | Action Structures | |||||
OFPAT_OUTPUT = 0, | /* Output to switch port. */ | Y | ||||
OFPAT_COPY_TTL_OUT = 11, | /* Copy TTL "outwards" -- from next-to-outermost to outermost */ | Y | ||||
OFPAT_COPY_TTL_IN = 12, | /* Copy TTL "inwards" -- from outermost to next-to-outermost */ | Y | ||||
OFPAT_SET_MPLS_TTL = 15, | /* MPLS TTL */ | Y | ||||
OFPAT_DEC_MPLS_TTL = 16, | /* Decrement MPLS TTL */ | N | ||||
OFPAT_PUSH_VLAN = 17, | /* Push a new VLAN tag */ | Y | ||||
OFPAT_POP_VLAN = 18, | /* Pop the outer VLAN tag */ | Y | ||||
OFPAT_PUSH_MPLS = 19, | /* Push a new MPLS tag */ | Y | ||||
OFPAT_POP_MPLS = 20, | /* Pop the outer MPLS tag */ | Y | ||||
OFPAT_SET_QUEUE = 21, | /* Set queue id when outputting to a port */ | Y | ||||
OFPAT_GROUP = 22, | /* Apply group. */ | Y | ||||
OFPAT_SET_NW_TTL = 23, | /* IP TTL. */ | N | ||||
OFPAT_DEC_NW_TTL = 24, | /* Decrement IP TTL. */ | N | ||||
OFPAT_SET_FIELD = 25, | /* Set a header field using OXM TLV format. */ | Y | ||||
OFPAT_PUSH_PBB = 26 | /* Push a new PBB service tag (I-TAG) */ | Y | ||||
OFPAT_POP_PBB = 27 | /* Pop the outer PBB service tag (I-TAG) */ | Y | ||||
OFPAT_EXPERIMENTER = 0xffff | N | |||||
7.2.5 | Experimenter Structure | Experimenter extensions provide a standard way for OpenFlow switches to offer additional functionality within the OpenFlow message type space. | N | |||
7.3 | Controller-to-Switch Messages | |||||
7.3.1 | Handshake | The OFPT_FEATURES_REQUEST message is used by the controller to identify the switch and read its basic capabilities. | Y | |||
7.3.2 | Switch Configuration | The controller is able to set and query configuration parameters in the switch with the OFPT_SET_CONFIG and and OFPT_GET_CONFIG_REQUEST messages, respectively. | Y | |||
7.3.3 | Flow Table Configuration | Flow entries are modified in the flow table using the OFP_FLOW_MOD request. | Y | |||
7.3.4 | Modify State Messages | Y | ||||
7.3.4.1 | Modify Flow Table Message | The controller can configure the dynamic state in a flow table with the OFP_TABLE_MOD request. | Y | |||
7.3.4.2 | Modify Flow Entry Message | Modifications to a flow table from the controller are done with the OFPT_FLOW_MOD message. | Y | |||
7.3.4.3 | Modify Group Entry Message | Modifications to the group table from the controller are done with the OFPT_GROUP_MOD message. | Y | |||
7.3.4.4 | Port Modification Message | The controller uses the OFPT_PORT_MOD message to modify the behavior of the port. | Y | |||
7.3.4.5 | Meter Modification Messages | Modifications to a meter from the controller are done with the OFPT_METER_MOD message. | Y | |||
7.3.5 | Multipart Messages | Multipart messages are used to encode requests or replies that potentially carry a large amount of dataand would not always fit in a single OpenFlow message, which is limited to 64KB. | ||||
7.3.5.1 | Description | Information about the switch manufacturer, hardware revision, software revision, serial number, and adescription field is available from the OFPMP_DESC multipart request type. | Y | |||
7.3.5.2 | Individual Flow Statistics | Information about individual flow entries is requested with the OFPMP_FLOW multipart request type. | Y | |||
7.3.5.3 | Aggregate Flow Statistics | Aggregate information about multiple flow entries is requested with the OFPMP_AGGREGATE multipart request type. | Y | |||
7.3.5.4 | able Statistics | Information about tables is requested with the OFPMP_TABLE multipart request type. | Y | |||
7.3.5.5 | Table Description | The OFPMP_TABLE_DESC multipart request message provides a way to list the current configuration of the tables on a switch, which is set using the OFPT_TABLE_MOD message. | Y | |||
7.3.5.6 | Table Features | The OFPMP_TABLE_FEATURES multipart type allows a controller to both query for the capabilities of existing tables, and to optionally ask the switch to reconfigure its tables to match a supplied configuration. | N | |||
Table Features request and reply | If the OFPMP_TABLE_FEATURES request body is empty the switch will return an array of struct ofp_table_features containing the capabilities of the currently configured flow tables. | N | ||||
Table Features properties | A property definition contains the property type, length, and any associated data. | N | ||||
7.3.5.7 | Port Statistics | Information about ports statistics is requested with the OFPMP_PORT_STATS multipart request type. | Y | |||
7.3.5.8 | Port Description | The port description request OFPMP_PORT_DESCRIPTION enables the controller to get a description of all the ports in the system that support OpenFlow. | Y | |||
7.3.5.9 | Queue Statistics | The OFPMP_QUEUE_STATS multipart request message provides queue statistics for one or more ports and one or more queues. | N | |||
7.3.5.10 | Queue Descriptions | The controller can query the switch for configured queues on a port using OFPMP_QUEUE_DESC multipart request. | Y | |||
7.3.5.11 | Group Statistics | The OFPMP_GROUP multipart request message provides statistics for one or more groups. | Y | |||
7.3.5.12 | Group Description | The OFPMP_GROUP_DESC multipart request message provides a way to list the set of groups on a switch along with their corresponding bucket actions. | Y | |||
7.3.5.13 | Group Features | The OFPMP_GROUP_FEATURES multipart request message provides a way to list the capabilities of groups on a switch. | Y | |||
7.3.5.14 | Meter Statistics | The OFPMT_METER stats request message provides statistics for one or more meters. | Y | |||
7.3.5.15 | Meter Configuration Statistics | The OFPMT_METER_CONFIG stats request message provides configuration for one or more meter. | Y | |||
7.3.5.16 | Meter Features Statistics | The OFPMT_METER_FEATURES stats request message provides the set of features of the metering subsystem. | Y | |||
7.3.5.17 | Flow monitoring | The OFPMP_FLOW_MONITOR multipart type allows a controller to manage flow monitors, that keep track of changes to the flow tables. | N | |||
Flow monitoring request | Flow monitor configuration is done with a OFPMP_FLOW_MONITOR multipart request | N | ||||
Flow monitoring reply | When the switch received a OFPMP_FLOW_MONITOR multipart request, it replies to it using a OFPMP_FLOW_MONITOR multipart reply, the transaction id (xid) of this reply must be the same as the request. | N | ||||
Flow monitoring pause | OpenFlow messages for flow monitor notifications can over flow the buffer space available to the switch either temporarily or more permanently. | N | ||||
7.3.5.18 | Experimenter Multipart | Experimenter-specific multipart messages are requested with the OFPMP_EXPERIMENTER multipart type. | N | |||
7.3.6 | Packet-Out Message | When the controller wishes to send a packet out through the datapath, it uses the OFPT_PACKET_OUT message. | Y | |||
7.3.7 | Barrier Message | When the controller wants to ensure message dependencies have been met or wants to receive notifications for completed operations, it may use an OFPT_BARRIER_REQUEST message. | Y | |||
7.3.8 | Role Request Message | When the controller wants to change its role, it uses the OFPT_ROLE_REQUEST message. | Y | |||
7.3.9 | Bundle messages | |||||
7.3.9.1 | Bundle control messages | The controller can create, destroy and commit bundles with the OFPT_BUNDLE_CONTROL request. | Y | |||
7.3.9.2 | Bundle Add message | The controller can add requests to a bundle using the OFPT_BUNDLE_ADD_MESSAGE message. | Y | |||
7.3.9.3 | Bundle flags | Bundle flags enable to modify the behavior of a bundle. | Y | |||
7.3.9.4 | Bundle properties | A property definition contains the property type, length, and any associated data. | Y | |||
7.3.9.5 | Creating and opening a bundle | To create a bundle, the controller sends a OFPT_BUNDLE_CONTROL message with type OFPBCT_OPEN_REQUEST. | Y | |||
7.3.9.6 | Adding messages to a bundle | The switch adds message to a bundle using the OFPT_BUNDLE_ADD_MESSAGE. | Y | |||
7.3.9.7 | Closing a bundle | To finish recording a bundle, the controller may sends a OFPT_BUNDLE_CONTROL message with type OFPBCT_CLOSE_REQUEST. | Y | |||
7.3.9.8 | Committing Bundles | To finish and apply the bundle, the controller sends a OFPT_BUNDLE_CONTROL message with type OFPBCT_COMMIT_REQUEST. | Y | |||
7.3.9.9 | Discarding Bundles | To finish and discard the bundle, the controller sends a OFPT_BUNDLE_CONTROL message with type OFPBCT_DISCARD_REQUEST. | Y | |||
7.3.9.10 | Other bundle error conditions | If a OFPT_BUNDLE_CONTROL message contains an invalid type, the switch must reject the request and send an ofp_error_msg with OFPET_BUNDLE_FAILED type and OFPBFC_BAD_TYPE code. | N | |||
7.3.10 | Set Asynchronous Configuration Message | The switch manages a per-controller asynchronous configuration, which defines the asynchronous messages that it wants to receive (other than error messages) on a given OpenFlow channel. | Y | |||
7.4 | Asynchronous Messages | |||||
7.4.1 | Packet-In Message | When packets are received by the datapath and sent to the controller, they use the OFPT_PACKET_IN. | Y | |||
7.4.2 | Flow Removed Message | If the controller has requested to be notified when flow entries time out or are deleted from table, the data path does this with the OFPT_FLOW_REMOVED message. | Y | |||
7.4.3 | Port Status Message | As ports are added, modified, and removed from the datapath, the controller needs to be informed with the OFPT_PORT_STATUS message | Y | |||
7.4.4 | Controller Role Status Message | When a controller has its role changed by the switch, and not directly changed by that controller using a OFPT_ROLE_REQUEST message, the corresponding controller must be informed with a OFPT_ROLE_STATUS message. | Y | |||
7.4.5 | Table Status Message | When the table state changes, the controller needs to be informed with the OFPT_TABLE_STATUS message. | Y | |||
7.4.6 | Request Forward Message | When a controller modifies the state a groups and meters, the request that successfully modifies this state may be forwarded to other controller. | Y | |||
7.5 | Symmetric Messages | |||||
7.5.1 | Hello | The OFPT_HELLO message consists of an OpenFlow header plus a set of variable size hello elements. | Y | |||
7.5.2 | Echo Request | An Echo Request message consists of an OpenFlow header plus an arbitrary-length data field. | Y | |||
7.5.3 | Echo Reply | An Echo Reply message consists of an OpenFlow header plus the unmodified data field of an echo request message. | Y | |||
7.5.4 | Error Message | Error messages are used by the switch or the controller to notify the other side of the connection of problems. | Y | |||
7.5.5 | Experimenter Message | N | ||||
A | Header file openflow.h | |||||
B | Release Notes | |||||
B.14 | OpenFlow version 1.4.0 | |||||
B.14.1 | More extensible wire protocol | N | ||||
B.14.2 | More descriptive reasons for packet-in | Y | ||||
B.14.3 | Optical port properties | N | ||||
B.14.4 | Flow-removed reason for meter delete. | Y | ||||
B.14.5 | Flow monitoring | N | ||||
B.14.6 | Role status events | Y | ||||
B.14.7 | Eviction | Y | ||||
B.14.8 | Vacancy events | Y | ||||
B.14.9 | Bundles | Y | ||||
B.14.10 | Synchronized tables | N | ||||
B.14.11 | Group and Meter change notifications | Y | ||||
B.14.12 | Error code for bad priority | N | ||||
B.14.13 | Error code for Set-async-config | Y | ||||
B.14.14 | PBB UCA header field | N | ||||
B.14.15 | Error code for duplicate instruction | Y | ||||
B.14.16 | Error code for multipart timeout | Y | ||||
B.14.17 | Change default TCP port to 6653 | N |
Copyright © 2024 Pica8 Inc. All Rights Reserved.