First, Introduction
This document describes the design requirements of the OpenFlow switch. We recommend that you read the OpenFlow white paper before reading this document."OpenFlow White paper"can be done byOpen Networking Foundation website(Https://www.opennetworking.org/standards/open-flow) obtained. This documentation covers the following:1. The components that make up the OpenFlow switch and the basic functions of the OpenFlow switch;2. OpenFlow protocol (connection to OpenFlow switch and remote controller)
Second, switch components
A OpenFlow switch contains one or more flow tables, a group table, and a OpenFlow secure channel. The above two types of tables are used to do "packet query" and "forward" work. The purpose of the secure channel is to use the OpenFlow protocol to communicate between the switch and the controller, so that the controller manages the switch.
using the OpenFlow protocol, the controller can stream table entries in the Flow table(Flow entries)The operation of "adding, deleting and changing" is carried out. The operation of a convection table entry can be reactive (that is, feedback on the arrival of a particular packet), or it can be pre-installed (that is, the flow table is set up in advance). Each flow table in the switch contains flow table entries, each of which consists of the (1) matching field (Match Fields), (2) counter (counters), and (3) a set of instructions (instructions) that are used to match packets.
The process of matching begins with the first flow table, and there may be other flow tables that participate in the matching process (see section 5.1). Flow entries Items are arranged in priority order. The higher the priority, the higher the position in the flow table. The packet is compared to the flow table item in the flow table in turn until the first match with a flow table entry in the Flow table, and the instruction (instructions) in this flow table entry is executed when a flow table entry is matched. If there is no match to the flow table entry, the execution depends on the configuration of the "Table-miss" Flow table entry (flow entrie) . For example, a packet could be sent to the controller via the OpenFlow secure channel, deleted, or continued to be processed by the next Flow table (see section 5.4).
each instruction associated with a flow table entry (instructions) is either contained in some "actions" (actions) or is used to modify the "Pipeline processing Flow" (Pipeline Processing). The "action" in the directive describes the forwarding of packets, the modification of packets, and the Group table processing flow (processing). The instructions for the pipeline processing Flow are: (1) allow the packet to be sent to the next table for further processing, and (2) allow the exchange of information between tables (tables) in the form of metadata (metadata). The " Pipeline processing Flow" that sends a packet to the next table processing is a stop condition where the packet is matched to a stream table whose associated instruction set no longer specifies the next table (next); This packet is usually modified and forwarded (see section 5.10).
flow Entries may require that packets be forwarded to a port. This port is usually a physical port, but it may also be a switch-Righteousness (switch-defined)(Logic port ) or a reserved port (reserved port) defined by this document. Reserved ports can be used to specify common forwarding behavior (forwarding actions), such as: (1) Send to Controller, (2) Hongfan (flooding), or (3) use non-OpenFlow (such as "normal" switch) toforwardingprocessing (see section 4.5), and the logical port of the switch definition (switch-defined) may specify a "link Fusion Group" ( Link Aggregation Groups), tunnel (tunnels) or loopback interface (loopback interfaces) (see Chapter 4.4).
The actions (actions) in a flow table item may point a packet to a group that specifies additional processing (see section 5.6). Groups (groups) represent the set of actions (sets of actions) associated with "Hongfan" (flooding), which also represents complex forwarding semantics (for example: multipath, fast reroute, link fusion). Group (groups) as an indirect common layer, you can also forward multiple flow table items to a separate "identifier" (identifier). (for example, the IP is forwarded to a common next hop (hop)). This abstraction makes it more efficient to change multiple flow table entries with common outputs .
The Group table contains "group table entries" (Groups entry), and each group table item contains a series of specific semantic "action buckets" (action buckets), while semantics depend on the group type (see section 5.6.1). When a packet is sent to a group, there is one or more action bucket actions that execute to the packet.
switch designers can freely design the internal structure of the hardware, as long as the correct matching (match) semantics and instruction (instruction) semantics are guaranteed. For example, when a flow table entry (flow entrie) wants to use all groups to forward to multiple ports, the designer of the switch can design this feature as a hardware forwarding with only one mask. Another example is "matching", where the "Pipeline" (pipeline) provided by the OpenFlow switch can be implemented by a different number of hardware tables (hardware tables).
Iii. Terminology
This section describes the key terms in the OpenFlow documentation:
*byte: A eight-bit binary.
*packet: A packet, that is, an Ethernet frame, including a letterhead and a load.
*port: Packet entry and exit OpenFlow "Pipeline"(pipeline) location. Can be a physical port, a switch-defined logical port, or a reserved port defined by the OpenFlow protocol.
In the *pipeline:openflow switch, some stream tables are concatenated to provide the functions of "match", "forward" and "packet modification".
*flow table: A stage in the pipeline (pipeline) that contains the flow table entry.
*flow Entry: An element in the flow table that is used to match and process packets. It contains a series of "Match Fields" to match the package, "priority" is used to determine the order of precedence, and some "counters" are used to record packets and some "instructions" to execute.
*match fields: A field that matches a packet that matches the packet header, the port to which the packet is entered, and the metadata (metadata) value. A match field can be a wildcard character (match any value), and in some cases it is a mask.
*metadata: A masked registration value(Register value)that is used to pass information between a table and the next table.
*instruction: Directive (instructions) is associated with a flow table entry that describes the OpenFlow process after a packet has been matched to this flow table entry. An instruction is used to modify the " Pipeline processing Flow ", such as packets the data to another flow table, or to include "actions" to supplement the "action set" or to include a series of "actions" that directly affect the packet.
*action: An action used to forward packets to a port or to modify a packet, such as reducing the TTL field. Actions can be part of a set of instructions in a flow table item, or an action bucket in a group table entry (action bucket). Actions can accumulate in the action set of the corresponding packet, or they can be executed immediately on the packet.
associated with a packet that is being processed .
*group: A series of "action buckets" (action buckets) and the method of selecting one of the one or two "buckets" to apply to each packet.
*action Bucket: Some "actions" and related parameters defined for "group".
can be
*outermost Tag: the tag (tag) that appears at the beginning of the adjacency packet.
*controller: An entity that uses the OpenFlow protocol to communicate with a OpenFlow switch.
*meter: "Meter", the component of a switch, can measure and control the rate of packets. When the packet rate or byte rate passed through a "meter" exceeds a predetermined limit, the meter triggers a "meter bandwidth" (meter band). If the meter bandwidth deletes the packet, it is called rate limiter.
Four, OpenFlow Port
This section describes the abstraction of the OpenFlow port and the various OpenFlow supportedOpenFlow PortType.
4.1 OpenFlow Port
The OpenFlow port is the network interface between the OpenFlow processing process (OpenFlow processing) and the delivery of packets to other network parts. The OpenFlow switch is logically connected to each other via the OpenFlow port.
A openflow switch to &NBSP; openflow processing process open up some number of &NBSP; openflow port. These ports may be different from the network interfaces provided by the switch hardware, while some network interfaces may OpenFlow interfaces and &NBSP; Span style= "line-height:1.5" >openflow switch may also define additional &NBSP; openflow< Span style= "line-height:1.5" > OpenFlow packets on the switch" input port "(ingress Port) and is received by "&NBSP; openflow Pipeline " (&NBSP; openflow pipeline ) Processing (see section 5.1), then the packet may be sent to the switch's "output port". "Packet Ingress Port" is a property of the packet that represents the packet passed out of the " OpenFlow Pipeline"from which input port" is enteredof the switch. The "input port" can be used when matching packets (see section 5.3). By using the output action, the OpenFlow pipeline can determine which output port the packet is sent to (see section 5.12), which determines how the packet is returned to the network.
OneThe OpenFlow switch must support three types of OpenFlow ports: Physical ports, logical ports, reserved ports.
4.2Standard Port
The OpenFlow standard port is defined as a physical port, a logical port, and a LOCAL reserved port (except for other reserved ports) if the switch supports it. Standard ports can be used as input and output ports, they can also be used in "groups" (see section 5.6), and they have port counters (see section 5.8).
4.3Physical Port
The OpenFlow hardware port is a switch-defined port that is associated with the hardware interface of the switch. For example, an Ethernet switch, the physical port is one by one corresponding to the hardware interface of the Ethernet.
In some deployments, The OpenFlow switch may be virtualized by the underlying hardware switch. In this case, a openflow physical port may represent a part of the hardware interface of the corresponding physical switch.
4.4Logical Port
A logical port is a port defined by the switch that is not directly related to the hardware interface. A logical port is a high-level abstraction of a physical port, and its definition may be non-OpenFlow (for example, Link aggregation Group (link aggregation groups), Tunnel, loopback interface (loopback interfaces)).
The packets for the logical port may be encapsulated and may be mapped to multiple physical ports. The processing of the logical ports must be converted to OpenFlow processing, and those ports must be treated as if they were OpenFlow physical ports.
The only difference between a physical port and a logical port is that the packets associated with the logical port may contain additional metadata fields (metadata field), such as Tunnel-id (see a.2.3.7), and when the logical port is exposed to a strange packet and is sent to the controller, its logical port and the underlying physical port need to be reported to the controller (see a.4.1)
4.5 reserved Port
The OpenFlow reserved port is defined by this document's specification. They specify common forwarding actions (actions) such as sending to the controller, Hongfan (flooding), or forwarding in non-openflow way, such as "normal" switch processing processes.
Notall the reserved ports areMandatory requirementsswitch to support, only those labeled "must" need to support.
* must: All: Represents all ports on the switch that can be used to forward a specified packet. Can only be used as an output port. In this case, a copy of a packet can be sent to all standard ports, in addition to the input port of the packet and the port that is registered as OFPPC_NO_FWD.
* must:controller: represents the control channel connected to the OpenFlow controller. Can be used as an input/output port. When used as an output port, encapsulates the packet into the packet-in message and then sends the removal using the OpenFlow protocol (see a.4.1). When used as an input port, it is used to identify packets from the controller.
* must:TABLE: Represents the beginning of the OpenFlow pipeline. This port is valid only in the output action of the packet-out message. The function is to submit the packet to the first flow table so that the packet can be processed by the regular OpenFlow pipeline.
MustIn_port: Represents the input port of the packet. Can only be used as an output port, which is intended to send packets back to the input port of the packet.
Must any: When no port is specified (via port wildcard characterwildcarded)), which is a special port value in some OpenFlow commands. It cannot be either an input port or an output port.
* Optional: Local: Represents the network stack of the switch and its management stack. Can be used as an input/output port. The local port allows remote entities to interact with the switch through the OpenFlow network without requiring a separate control network. With some appropriate default flow table entries, you can implement a In-band controller connection.
* Optional:NORMAL: Represents the traditional Non-openflow switch pipeline (see section 5.1). Can only be used as an output port, in which case the packet is processed using the normal (normal) pipeline. If the switch cannot forward the packet from the OpenFlow pipeline to the normal pipeline, then the switch does not support this "action".
* Optional:FLOOD: Represents the Hongfan (flooding) of the common pipeline using the switch (normal pipeline, relative to the OpenFlow pipeline). Can only be used as an output port, the semantics of which is to send packets to all standard ports, but not to send this packet to the input port of the packet and the port in the ofpps_blocked state. The switch can use the VLAN ID of the packet to choose which ports to "Hongfan".
The openflow-only switch does not support NORMAL ports and FLOOD ports, and Openflow-hybrid switches can support them (see section 5.1). Forwarding packets to the FLOOD port relies on the implementation and configuration of the switch, and a "group" with the type "all" can make the switch more flexible to implement Hongfan.
(Reproduced Please specify Source: http://blog.csdn.net/gulansheng/article/details/46515503)
OpenFlow Switch Specification 1.3.0 (i)
