Openflow Switch(II)

Meter Table

A meter table consists of meter entries, defining per-flow meters. Per-flow meters enable OpenFlow to implement various simple QoS operations, such as rate-limiting, and can be combined with per-port queues (see 5.8) to implement complex QoS frameworks, such as DiffServ.


A meter measures the rate of packets assigned to it and enables controlling the rate of those packets. Meters are attached directly to flow entries (as opposed to queues which are attached to ports). Any flow entry can specify a meter in a list of actions (see 5.8): the meter measures and controls the rate of the aggregate of all flow entries to which it is attached. Multiple meters can be used in the same table, either in an exclusive way (disjoint 不相交 set of flow entries), or using multiple meter action per flow entry if the switch supports it. Multiple meters can be used on the same set of packets, either by using them in successive flow tables, or using multiple meter action per flow entry if the switch supports it.

Each meter entry (see Table 7) is identified by its meter identifier and contains:

• meter identifier: a 32 bit unsigned integer uniquely identifying the meter
• meter bands: an unordered list of meter bands, where each meter band specifies the rate of the band and the way to process the packet
• counters: updated when packets are processed by a meter

5.11.1 Meter Bands

Each meter may have one or more meter bands. Each band specifies the rate at which the band applies and the way packets should be processed. Packets are processed by a single meter band based on the current measured meter rate. The meter applies the meter band with the highest configured rate that is lower than the current measured rate. If the current rate is lower than any specified meter band rate, no meter band is applied.

Each meter band (see Table 8) is identified by its rate and contains:

• band type: defines how packet are processed

• rate: used by the meter to select the meter band, defines the lowest rate at which the band can apply

• burst: defines the granularity of the meter band (粒度)

• counters: updated when packets are processed by a meter band

• type specific arguments: some band types have optional arguments

There is no band type “Required” by this specification. The controller can query the switch about which of the “Optional” meter band types it supports.

• Optional: drop: drop (discard) the packet. Can be used to define a rate limiter band.

• Optional: dscp remark: increase the drop precedence of the DSCP field in the IP header of the packet. Can be used to define a simple DiffServ policer.

每个meter band （见表8）由其rate 识别，并包含：

•band type：定义如何处理数据包

•rate：仪表用于选择meter band 波段，定义波段可应用的最低速率

•burst：定义米带的粒度（granularity）

•计数器：在通过meter band 处理数据包时更新

•类型特定的参数：一些带类型具有可选参数

本规范没有带类型“必需”。 控制器可以查询交换机关于它支持哪些“可选”仪表带类型。

•可选：drop：丢弃（丢弃）数据包。 可用于定义速率限制器频带。

•可选：dscp remark：增加报文IP头中DSCP字段的丢弃优先级。 可以用来定义一个简单的DiffServ策略器。

6.8 Meter Modification Messages
Meter modification messages can have the following commands :

/* Meter commands */
enum ofp_meter_mod_command
{
   OFPMC_ADD,
   OFPMC_MODIFY, OFPMC_DELETE,
};

A meter-mod request with an add command (OFPMC_ADD) adds a new meter entry in the switch. If the specified meter already exist, the switch must return a Meter Exist error message (see 7.5.4.13).具有添加命令（OFPMC_ADD）的仪表模式请求在交换机中添加新的meter entry。 如果指定的meter已经存在，交换机必须返回Meter Exist错误消息（见7.5.4.13）。

For modify requests (OFPMC_MODIFY), if a meter entry with the specified meter identifier already exists, then the configuration of that meter entry, including its flags and bands, must be removed (cleared), and the meter entry must use the new configuration included in the request. For that entry, meter top-level statistics are preserved (continued), meter band statistics are reset (cleared). If a meter entry with the specified meter identifier does not already exist then the switch must refuse the meter mod and send a Unknown Meter error message (see 7.5.4.13).对于修改请求（OFPMC_MODIFY），如果具有指定的meter identifier 的meter entry 已存在，则必须删除（清除）该meter entry 的配置（ flags and bands），并且meter entry 必须使用在请求中的新配置。 对于该条目，保存仪表顶级统计（续），重置（清除）仪表波段统计。 如果具有指定的仪表标识符的仪表条目不存在，则交换机必须拒绝仪表mod并发送未知仪表错误消息（参见7.5.4.13）。

For delete requests (OFPMC_DELETE), if no meter entry with the specified meter identifier currently exists, no error is recorded, and no meter modification occurs. Otherwise, the meter is removed, and all flows that include the meter in their instruction set are also removed. Only the meter identifier need to be specified for the delete request, other fields such as bands can be omitted.
To delete all meters with a single message, specify OFPM_ALL as the meter value. Virtual meters can never be deleted and are not removed when deleting all meters.

对于删除请求（OFPMC_DELETE），如果当前不存在具有指定的仪表标识符的仪表条目，则不记录错误，并且不发生仪表修改。 否则，仪表将被删除，并且包括仪表在其指令集中的所有流也被删除。 仅需要为删除请求指定仪表标识符，可以省略诸如频带的其他字段。
要使用单条消息删除所有仪表，请将OFPM_ALL指定为仪表值。 虚拟仪表永远不能删除，删除所有仪表时不会删除。

5.12 Ingress and egress processing differences

Flow tables can be used for ingress or egress processing (see 5.1). Ingress processing is the main processing that happens when the packet enters the OpenFlow switch, and may involve one or more flow tables. Egress processing is the processing that happens after the determination of the output port, it happens in the context of the output port and may involve zero or more flow tables.

There are few differences between flow table used for ingress and egress processing, the flow entries have the same components (see 5.2), flow table matching is the same (see 5.3) and execution of instructions is the same (see 5.5). Table miss processing is the same (see 5.4), and therefore the controller is strongly advised to set a table-miss flow entry in each egress table to avoid dropped packets. In some cases, a flow table can be reconfigured for ingress or egress processing by changing the first egress table (see
7.3.2).

流表可用于入口或出口处理（见5.1）。 入口处理是当分组进入OpenFlow 交换机时发生的主要处理，并且可以涉及一个或多个流表flow tables。 出口处理是在确定输出端口之后发生的处理，它在输出端口的上下文中发生，并且可以涉及零个或多个流表。

入口或出口处理使用的流表之间几乎没有区别，flow entries具有相同的组件（见5.2），流表匹配是相同的（见5.3），指令的执行是相同的（见5.5）。 Table miss 处理是相同的（见5.4），因此强烈建议控制器在每个egress table中设置一个表table-miss flow entry，以避免丢失数据包。 在一些情况下，可以通过改变the first egress table 来重新配置流表以用于入口或出口处理
7.3.2）。

6 OpenFlow Channel and Control Channel

The OpenFlow channel is the interface that connects each OpenFlow Logical Switch to an OpenFlow controller. Through this interface, the controller configures and manages the switch, receives events from the switch, and sends packets out the switch. The Control Channel of the switch may support a single OpenFlow channel with a single controller, or multiple OpenFlow channels enabling multiple controllers to share management of the switch.

Between the datapath and the OpenFlow channel, the interface is implementation-specific, however all OpenFlow channel messages must be formatted according to the OpenFlow switch protocol. The OpenFlow channel is usually encrypted using TLS, but may be run directly over TCP.





6.1 OpenFlow Switch Protocol Overview


The OpenFlow switch protocol supports three message types, controller-to-switch, asynchronous, and symmetric, each with multiple sub-types. Controller-to-switch messages are initiated by the controller and used to directly manage or inspect the state of the switch. Asynchronous messages are initiated by the switch and used to update the controller of network events and changes to the switch state. Symmetric messages are initiated by either the switch or the controller and sent without solicitation.
The message types used by OpenFlow are described below.



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.

Features: The controller may request the identity and the basic capabilities of a switch by sending a features request; the switch must respond with a features reply that specifies the identity and basic capabilities of the switch. This is commonly performed upon establishment of the OpenFlow channel.

Configuration: The controller is able to set and query configuration parameters in the switch. The switch only responds to a query from the controller.

Modify-State: Modify-State messages are sent by the controller to manage state on the switches. Their primary purpose is to add, delete and modify flow/group entries and insert/remove action buckets of group in the OpenFlow tables and to set switch port properties.

Read-State: Read-State messages are used by the controller to collect various information from the switch, such as current configuration, statistics and capabilities. Most Read-State requests and replies are implemented using multipart message sequences (see 7.3.5).


Packet-out: These are used by the controller to send packets out of a specified port on the switch, and to forward packets received via Packet-in messages. Packet-out messages must contain a full packet or a buffer ID referencing a packet stored in the switch. The message must also contain a list of actions to be applied in the order they are specified; an empty list of actions drops the packet.

Barrier: Barrier request/reply messages are used by the controller to ensure message dependencies have been met or to receive notifications for completed operations.

Role-Request: Role-Request messages are used by the controller to set the role of its OpenFlow channel, set its Controller ID, or query these. This is mostly useful when the
switch connects to multiple controllers (see 6.3.6).

Asynchronous-Configuration: The Asynchronous-Configuration messages are used by the controller to set an additional filter on the asynchronous messages that it wants to receive on its OpenFlow channel, or to query that filter. This is mostly useful when the switch connects to multiple controllers (see 6.3.6) and commonly performed upon establishment of the OpenFlow channel.

Controller-to-Switch 消息由控制器发起，并且可以或可以不需要来自switch 的响应。
特性：控制器可以通过发送特性请求来请求交换机的身份和基本能力;交换机必须用指定交换机的身份和基本能力的特征应答来响应。这通常在建立OpenFlow信道时执行。
配置：控制器能够在交换机中设置和查询配置参数。交换机仅响应来自控制器的查询。
修改状态：修改状态消息由控制器发送以管理交换机上的状态。它们的主要目的是在OpenFlow表中添加，删除和修改流/组条目以及插入/删除组的操作桶，并设置交换机端口属性。
读状态：读状态消息由控制器用于从交换机收集各种信息，例如当前配置，统计和功能。大多数读状态请求和应答是使用多部分消息序列实现的（见7.3.5）。

分组输出：控制器使用这些分组从交换机上的指定端口发送分组，以及转发通过分组输入消息接收的分组。分组输出消息必须包含引用存储在交换机中的分组的完整分组或缓冲区ID。消息还必须包含要按其指定的顺序应用的操作列表;一个空的操作列表将丢弃数据包。

屏障：屏障请求/回复消息由控制器使用，以确保已满足消息相关性或接收已完成操作的通知。

角色请求：角色请求消息由控制器用来设置其OpenFlow通道的角色，设置其控制器ID或查询这些。 这是最有用的时候开关连接到多个控制器（见6.3.6）。

异步配置：异步配置消息由控制器用于在要在其OpenFlow通道上接收的异步消息上设置附加过滤器，或者查询该过滤器。 当交换机连接到多个控制器（见6.3.6）时，这通常是有用的，并且在建立OpenFlow信道时通常执行。

6.1.2 Asynchronous

Asynchronous messages are sent without a controller soliciting them from a switch. Switches send asynchronous messages to controllers to denote a packet arrival or switch state change. The main asynchronous message types are described below.

Packet-in: Transfer the control of a packet to the controller. For all packets forwarded to the CONTROLLER reserved port using a flow entry or the table-miss flow entry, a packet-in event is always sent to controllers (see 5.8). Other processing, such as TTL checking, may also generate packet-in events to send packets to the controller.


Packet-in events can be configured to buffer packets. For packet-in generated by an output action in a flow entries or group bucket, it can be specified individually in the output action itself (see 7.2.6.1), for other packet-in it can be configured in the switch configuration (see 7.3.2). If the packet-in event is configured to buffer packets and the switch has sufficient memory to buffer them, the packet-in event contain only 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. Switches that do not support internal buffering, are configured to not buffer packets for the packet-in event, or have run out of internal buffering, must send the full packet to controllers as part of the event. Buffered packets will usually be processed via a Packet-out or Flow-mod message from a controller, or automatically expired after some time.

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. For packet-in generated by an output action in a flow entries or group bucket, it can be specified individually in the output action itself (see 7.2.6.1), for other packet-in it can be configured in the switch configuration (see 7.3.2).

Packet-in ：
把packet的控制交给controller。对于所有使用flow entry或table-miss flow entry来转发给CONTROLLER reserved port的packet，都会有一个Packet-in事件发送给controller。packet-in事件可以用来缓存packet。如果packet-in事件被设置为可缓存packet而且switch有足够的内存来缓存，当switch准备转发packet时，一个packet-in事件只包含部分的packet header和一个缓存ID给controller。如果不支持内部缓存，必须发送完整的packet作为packet-in事件。被缓存的packet通常被controller通过Packet-out 或 Flow-mod message 处理，或者自动过时。
如果packet被缓存，可以设置原packet的多少byte包含在packet-in信息中。默认是128 bytes

Flow-Removed: Inform the controller about the removal of a flow entry from a flow table. FlowRemoved messages are only sent for flow entries with the OFPFF_SEND_FLOW_REM flag set. They are generated as the result of a controller flow delete request or the switch flow expiry process when one of the flow timeouts is exceeded (see 6.5). 通知控制器一个flow entry被移除。使用OFPFF_SEND_FLOW_REM flag。是controller 的flow删除请求或flow过时程序的结果。

Port-status: Inform the controller of a change on a port. The switch is expected to send port-status messages to controllers as port configuration or port state changes. These events include change in port configuration events, for example if it was brought down directly by a user, and port state change events, for example if the link went down. 通知控制器端口更改。

Role-status: Inform the controller of a change of its role. When a new controller elects itself master, the switch is expected to send role-status messages to the former master controller (see 6.3.6). 当有了新的控制器时，向旧控制器发送Role-status。

Controller-Status: Inform the controller when the status of an OpenFlow channel changes. The switch sends these messages to all controllers when the status of the OpenFlow channel to any switch changes. This can assist failover processing if controllers lose the ability to communicate among themselves.  通知OpenFlow channel更改。向所有控制器发送，协助故障转移。

Flow-monitor: Inform the controller of a change in a flow table. A controller may define a set of monitors to track changes in flow tables (see 7.3.5.19). 通知controller关于flow table的更改。

6.1.3 Symmetric

Symmetric messages are sent without solicitation, in either direction.

Hello: Hello messages are exchanged between the switch and controller upon connection startup. 连接建立阶段。

Echo: Echo request/reply messages can be sent from either the switch or the controller, and must return an echo reply. They are mainly used to verify the liveness of a controller-switch connection, and may as well be used to measure its latency or bandwidth.

Echo请求/回复用于验证 controller-switch 的连接和测量延迟和带宽。

Error: Error messages are used by the switch or the controller to notify problems to the other side of the connection. They are mostly used by the switch to indicate a failure of a request initiated by the controller.

Error用于通知对方出现的问题。通常被switch用于通知由controller发起的request失败。

Experimenter: Experimenter messages provide a standard way for OpenFlow switches to offer additional functionality within the OpenFlow message type space. This is a staging area for features meant for future OpenFlow revisions.

Experimenter提供OpenFlow信息内的附加功能。

6.2 Message Handling

Message Delivery: Messages are guaranteed delivery, unless the OpenFlow channel fails entirely, in which case the controller should not assume anything about the switch state (e.g., the switch may have gone into “fail standalone mode”).

Message Processing: Switches must process every message received from a controller in full, possibly generating a reply. If a switch cannot completely process a message received from a controller, it must send back an error message. For packet-out messages, fully processing the message does not guarantee that the included packet actually exits the switch. The included packet may be silently dropped after OpenFlow processing due to congestion at the switch, QoS policy, or if sent to a blocked or invalid port.

消息处理：交换机必须处理从控制器接收的每个消息，可能产生一个答复。 如果交换机不能完全处理从控制器接收的消息，则它必须发回错误消息。 对于packet-out 消息，完全处理消息不能保证所包括的分组实际上退出交换机。 由于交换机上的拥塞，QoS策略或者如果发送到阻塞或无效的端口，在OpenFlow处理之后，所包括的分组可能被静默地丢弃。

In addition, switches must send to the controller all asynchronous messages generated by OpenFlow state changes, such as flow-removed, port-status or packet-in messages, so that the controller view of the switch is consistent with its actual state. Those messages may get filtered out based on the Asynchronous Configuration (see 6.1.1). Moreover, conditions that would trigger an OpenFlow state change may get filtered prior to causing such change. For example, packets received on data ports that should be forwarded to the controller may get dropped due to congestion or QoS policy within the switch and generate no packet-in messages. These drops may occur for packets with an explicit output action to the controller. These drops may also occur when a packet fails to match any entries in a table and that table’s default action is to send to the controller. The policing of packets destined to the controller is advised, to prevent denial of service of the controller connection, this can be done via a queue on the controller port (see 7.3.5.8) or using per-flow meters (see 5.11).

此外，交换机必须向控制器发送由OpenFlow状态更改生成的所有异步消息，例如流去除，端口状态或数据包入消息，以便交换机的控制器视图与其实际状态一致。这些消息可能会基于异步配置过滤掉（请参阅6.1.1）。此外，可以在引起这种改变之前过滤将触发OpenFlow状态改变的条件。例如，在应该被转发到控制器的数据端口上接收的分组可能由于交换机内的拥塞或QoS策略而被丢弃，并且不生成分组输入消息。对于具有对控制器的显式输出动作的数据包，可能发生这些丢弃。当数据包无法匹配表中的任何条目并且表的默认操作要发送到控制器时，也可能发生这些丢弃。建议对发往控制器的数据包进行管制，以防止控制器连接的拒绝服务，这可以通过控制器端口上的队列（见7.3.5.8）或使用每流量计（见5.11）。