OpenFlow Switch规范1.3.4版详解

需积分: 9 181 浏览量更新于2024-07-21 收藏 1.3MB PDF 举报

"本文档是OpenFlow Switch规范的1.3.4版本，由软件定义网络组织发布。它详细描述了OpenFlow协议的这一特定版本，该协议是SDN（软件定义网络）的核心组成部分，用于控制网络设备的行为，特别是交换机。" OpenFlow是一种开放的通信协议，它允许网络管理员或控制器远程编程网络设备，如交换机和路由器，以实现更灵活、可编程的网络架构。在OpenFlow 1.3.4版本中，主要的知识点包括： 1. **版本与协议号**：OpenFlow 1.3.4对应的协议版本号是0x04，表明了这个规范相对于早期版本的更新和改进。 2. **交换机功能**：OpenFlow交换机是SDN架构中的关键组件，它们接收来自控制器的指令并执行相应的转发决策。1.3.4版本可能包括对多表匹配、流表项优先级、流统计和QoS策略等方面的增强。 3. **流表机制**：OpenFlow允许控制器定义流表条目，这些条目基于数据包的特定字段（如源/目的IP、端口等）来决定如何处理数据包。1.3.4可能扩展了匹配字段和动作集，增强了流表的灵活性。 4. **协议扩展性**：OpenFlow 1.3.4可能引入了新的消息类型、结构体和错误代码，以支持新功能和更好的互操作性。 5. **安全特性**：SDN的安全性是至关重要的，OpenFlow 1.3.4可能包含了强化的安全措施，如加密通信、身份验证和访问控制。 6. **错误处理与诊断**：规范可能会详细描述如何处理协议交互中的错误，以及如何通过控制器获取交换机的运行状态和诊断信息。 7. **版权与免责声明**：文档明确指出，提供此规范时不附带任何明示或暗示的保证，包括但不限于适销性、不侵权、适用于特定目的的保证。使用该规范时，用户需自行承担可能的风险和责任。 8. **知识产权**：ONF（Open Networking Foundation）声明不授予任何许可证，无论是明示的还是默示的，对于其或其成员的任何知识产权。学习OpenFlow 1.3.4规范，网络工程师可以理解如何利用SDN的灵活性来创建和管理网络，包括流量工程、故障检测与恢复、动态负载均衡和高级安全策略。此外，它对于开发网络应用程序、控制器和交换机固件的开发者来说，是不可或缺的参考材料。

OpenFlow Switch Speciﬁcation Version 1.3.4

The ﬂow tables of an OpenFlow switch are sequentially numbered, starting at 0. Pipeline processing

always starts at the ﬁrst ﬂow table: the packet is ﬁrst matched against ﬂow entries of ﬂow table 0.

Other ﬂow tables may be used depending on the outcome of the match in the ﬁrst table.

When processed by a ﬂow table, the packet is matched against the ﬂow entries of the ﬂow table to

select a ﬂow entry (see 5.3). If a ﬂow entry is found, the instruction set included in that ﬂow entry is

executed. These instructions may explicitly direct the packet to another ﬂow table (using the Goto-

Table Instruction, see 5.9), where the same process is repeated again. A ﬂow entry can only direct a

packet to a ﬂow table number which is greater than its own ﬂow table number, in other words pipeline

processing can only go forward and not backward. Obviously, the ﬂow entries of the last table of the

pipeline can not include the Goto-Table instruction. If the matching ﬂow entry does not direct packets

to another ﬂow table, pipeline processing stops at this table, the packet is processed with its associated

action set and usually forwarded (see 5.10).

If a packet does not match a ﬂow entry in a ﬂow table, this is a table miss. The behavior on a table miss

depends on the table conﬁguration (see 5.4). The instructions included in the table-miss ﬂow entry in

the ﬂow table can ﬂexibly specify how to process unmatched packets, useful options include dropping

them, passing them to another table or sending them to the controllers over the control channel via

packet-in messages (see 6.1.2).

There are few cases where a packet is not fully processed by a ﬂow entry and pipeline processing stops

without processing the packet’s action set or directing it to another table. If no table-miss ﬂow entry

is present, the packet is dropped (see 5.4). If an invalid TTL is found, the packet may be sent to the

controller (see 5.12).

The OpenFlow pipeline and various OpenFlow operations process packets of a speciﬁc type in con-

formance with the speciﬁcations deﬁned for that packet type, unless the present speciﬁcation or the

OpenFlow conﬁguration specify otherwise. For example, the Ethernet header deﬁnition used by Open-

Flow must conform to IEEE speciﬁcations, and the TCP/IP header deﬁnition used by OpenFlow must

conform to RFC speciﬁcations. Additionally, packet reordering in an OpenFlow switch must conform

to the requirements of IEEE speciﬁcations, provided that the packets are processed by the same ﬂow

entries, group bucket and meter band.

5.1.1 Pipeline Consistency

The OpenFlow pipeline is an abstraction that is mapped to the actual hardware of the switch. In some

cases, the OpenFlow switch is virtualised on the hardware, for example to support multiple OpenFlow

switch instances or in the case of an hybrid switch. Even if the OpenFlow switch is not virtualised, the

hardware typically will not correspond to the OpenFlow pipeline, for example OpenFlow assume packets

to be Ethernet, so non-Ethernet packets would have to be mapped to Ethernet, in another example some

switch may carry the VLAN information in some internal metadata while for the OpenFlow pipeline it

is logically part of the packet. Some OpenFlow switch may deﬁne logical ports implementing complex

encapsulations that extensively modify the packet headers. The consequence is that a packet on a link

or in hardware may be mapped diﬀerently in the OpenFlow pipeline.

However, the OpenFlow pipeline expect that the mapping to the hardware is consistent, and that the

OpenFlow pipeline behave consistently. In particular, this is what is expected :

OpenFlow Switch Speciﬁcation Version 1.3.4

• Tables consistency: the packet must match in the same way in all the OpenFlow ﬂow tables,

and the only diﬀerence in matching must be due to the ﬂow table content and explicit OpenFlow

processing done by those ﬂow tables. In particular, headers can not be transparently removed,

added or changed between tables, unless explicitly speciﬁed by OpenFlow processing.

• Flow entry consistency: the way the actions of a ﬂow entry apply to a packet must be consistent

with the ﬂow entry match. In particular, if a match ﬁeld in the ﬂow entry match a speciﬁc packet

header ﬁeld, the corresponding set-ﬁeld action in the ﬂow entry must modify the same header

ﬁeld, unless explicit OpenFlow processing has modiﬁed the packet.

• Group consistency: the application of group must be consistent with ﬂow tables. In particular,

actions parts of a group bucket must apply to the packet the same way as if they were in a ﬂow

table, the only diﬀerence must be due to explicit OpenFlow processing.

• Packet-in consistency: the packet embedded in the packet-in messages must be consistent with

the OpenFlow ﬂow tables. In particular, if the packet-in was generated directly by a ﬂow entry,

the packet received by the controller must match the ﬂow entry that sent it to the controller.

• Packet-out consistency: the packet generated as the result of a packet-out request must be

consistent with the OpenFlow ﬂow tables and the packet-in process. In particular, if a packet

received via a packet-in is is sent directly without modiﬁcations out a port via a packet-out, the

packet on that port must be identical as if the packet had been sent to that port instead of

encapsulated in a packet-in. Similarly, if a packet-out is directed at ﬂow tables, the ﬂow entries

must match the encapsulated packet as expected by the OpenFlow matching process.

• Port consistency: the ingress and egress processing of an OpenFlow port must be consistent

with each other. In particular, if an OpenFlow packet is output on a port and generates a physical

packet on a switch physical link, then if the reception by the switch of the same physical packet

on the same link generates an OpenFlow packet on the same port, the OpenFlow packet must be

identical.

5.2 Flow Table

A ﬂow table consists of ﬂow entries.

Match Fields Priority Counters Instructions Timeouts Cookie Flags

Table 1: Main components of a ﬂow entry in a ﬂow table.

Each ﬂow table entry (see Table 1) contains:

• match ﬁelds: to match against packets. These consist of the ingress port and packet headers,

and optionally other pipeline ﬁelds such as metadata speciﬁed by a previous table.

• priority: matching precedence of the ﬂow entry.

• counters: updated when packets are matched.

• instructions: to modify the action set or pipeline processing.

• timeouts: maximum amount of time or idle time before ﬂow is expired by the switch.

OpenFlow Switch Speciﬁcation Version 1.3.4

• cookie: opaque data value chosen by the controller. May be used by the controller to ﬁlter ﬂow

entries aﬀected by ﬂow statistics, ﬂow modiﬁcation and ﬂow deletion requests. Not used when

processing packets.

• ﬂags: ﬂags alter the way ﬂow entries are managed, for example the ﬂag OFPFF_SEND_FLOW_REM

triggers ﬂow removed messages for that ﬂow entry.

A ﬂow table entry is identiﬁed by its match ﬁelds and priority: the match ﬁelds and priority taken

together identify a unique ﬂow entry in a speciﬁc ﬂow table. The ﬂow entry that wildcards all ﬁelds

(all ﬁelds omitted) and has priority equal to 0 is called the table-miss ﬂow entry (see 5.4).

A ﬂow entry instruction may contain actions to be performed on the packet at some point of the pipeline

(see 5.12). The set-ﬁeld action may specify some header ﬁelds to rewrite. Each ﬂow table may not

support every match ﬁeld, every instruction, every action or every set-ﬁeld deﬁned by this speciﬁcation,

and diﬀerent ﬂow tables of the switch may not support the same subset. The table features request

enable the controller to discover what each table supports (see 7.3.5.5).

5.3 Matching

Packet In

Start at table 0

Match in

table n?

Update counters

Execute instructions:

• update action set

• update packet/match set ﬁelds

• update metadata

Goto-

Table n?

Execute action

set

Yes

No No

Table-

miss ﬂow

entry

exists?

Drop packet

Yes

Figure 3: Flowchart detailing packet ﬂow through an OpenFlow switch.

On receipt of a packet, an OpenFlow Switch performs the functions shown in Figure 3. The switch starts

by performing a table lookup in the ﬁrst ﬂow table, and based on pipeline processing, may perform

table lookups in other ﬂow tables (see 5.1.1).

Packet match ﬁelds are extracted from the packet. Packet match ﬁelds used for table lookups depend

on the packet type, and typically include various packet header ﬁelds, such as Ethernet source address

or IPv4 destination address (see 7.2.3). In addition to packet headers, matches can also be performed

OpenFlow Switch Speciﬁcation Version 1.3.4

against the ingress port, the metadata ﬁeld and other pipeline ﬁelds. Metadata may be used to pass

information between tables in a switch. The packet match ﬁelds represent the packet in its current state,

if actions applied in a previous table using the Apply-Actions instruction changed the packet headers,

those changes are reﬂected in the packet match ﬁelds.

A packet matches a ﬂow table entry if the values in the packet match ﬁelds used for the lookup match

those deﬁned in the ﬂow table entry. If a ﬂow table entry ﬁeld has a value of ANY (ﬁeld omitted), it

matches all possible values in the header. If the switch supports arbitrary bitmasks on speciﬁc match

ﬁelds, these masks can more precisely specify matches.

The packet is matched against the table and only the highest priority ﬂow entry that matches the

packet must be selected. The counters associated with the selected ﬂow entry must be updated and the

instruction set included in the selected ﬂow entry must be applied. If there are multiple matching ﬂow

entries with the same highest priority, the selected ﬂow entry is explicitly undeﬁned. This case can only

arise when a controller writer never sets the OFPFF_CHECK_OVERLAP bit on ﬂow mod messages and adds

overlapping entries.

IP fragments must be reassembled before pipeline processing if the switch conﬁguration contains the

OFPC_FRAG_REASM ﬂag (see 7.3.2).

This version of the speciﬁcation does not deﬁne the expected behavior when a switch receives a mal-

formed or corrupted packet.

5.4 Table-miss

Every ﬂow table must support a table-miss ﬂow entry to process table misses. The table-miss ﬂow entry

speciﬁes how to process packets unmatched by other ﬂow entries in the ﬂow table (see 5.1.1), and may,

for example, send packets to the controller, drop packets or direct packets to a subsequent table.

The table-miss ﬂow entry is identiﬁed by its match and its priority (see 5.2), it wildcards all match

ﬁelds (all ﬁelds omitted) and has the lowest priority (0). The match of the table-miss ﬂow entry

may fall outside the normal range of matches supported by a ﬂow table, for example an exact match

table would not support wildcards for other ﬂow entries but must support the table-miss ﬂow entry

wildcarding all ﬁelds. The table-miss ﬂow entry may not have the same capability as regular ﬂow entry

(see 7.3.5.5). The table-miss ﬂow entry must support at least sending packets to the controller using the

CONTROLLER reserved port (see 4.5) and dropping packets using the Clear-Actions instruction (see

5.9). Implementations are encouraged to support directing packets to a subsequent table when possible

for compatibility with earlier versions of this speciﬁcation.

The table-miss ﬂow entry behaves in most ways like any other ﬂow entry: it does not exist by default in

a ﬂow table, the controller may add it or remove it at any time (see 6.4), and it may expire (see 5.5). The

table-miss ﬂow entry matches packets in the table as expected from its set of match ﬁelds and priority

(see 5.3): it matches packets unmatched by other ﬂow entries in the ﬂow table. The table-miss ﬂow

entry instructions are applied to packets matching the table-miss ﬂow entry (see 5.9). If the table-miss

ﬂow entry directly sends packets to the controller using the CONTROLLER reserved port (see 4.5), the

packet-in reason must identify a table-miss (see 7.4.1).

OpenFlow Switch Speciﬁcation Version 1.3.4

If the table-miss ﬂow entry does not exist, by default packets unmatched by ﬂow entries are dropped

(discarded). A switch conﬁguration, for example using the OpenFlow Conﬁguration Protocol, may

override this default and specify another behaviour.

5.5 Flow Removal

Flow entries are removed from ﬂow tables in two ways, either at the request of the controller or via the

switch ﬂow expiry mechanism.

The switch ﬂow expiry mechanism is run by the switch independently of the controller and is based on

the state and conﬁguration of ﬂow entries. Each ﬂow entry has an idle_timeout and a hard_timeout

associated with it (see 7.3.4.1). If the hard_timeout ﬁeld is non-zero, the switch must note the ﬂow

entry’s arrival time, as it may need to evict the entry later. A non-zero hard_timeout ﬁeld causes

the ﬂow entry to be removed after the given number of seconds, regardless of how many packets it

has matched. If the idle_timeout ﬁeld is non-zero, the switch must note the arrival time of the last

packet associated with the ﬂow, as it may need to evict the entry later. A non-zero idle_timeout ﬁeld

causes the ﬂow entry to be removed when it has matched no packets in the given number of seconds.

The switch must implement ﬂow expiry and remove ﬂow entries from the ﬂow table when one of their

timeouts is exceeded.

The controller may actively remove ﬂow entries from ﬂow tables by sending delete ﬂow table modiﬁca-

tion messages (OFPFC_DELETE or OFPFC_DELETE_STRICT - see 6.4). Flow entries may also be removed

as the result of removal of a group (see 6.5) or a meter (see 6.6) by the controller. On the other hand,

when a port is added, modiﬁed or removed, ﬂow entries are never removed or modiﬁed, the controller

explicitly need to remove those ﬂow entries if needed (see 4.6).

When a ﬂow entry is removed, either by the controller or the ﬂow expiry mechanism, the switch must

check the ﬂow entry’s OFPFF_SEND_FLOW_REM ﬂag. If this ﬂag is set, the switch must send a ﬂow removed

message to the controller (see 7.4.2). Each ﬂow removed message contains a complete description of

the ﬂow entry, the reason for removal (expiry or delete), the ﬂow entry duration at the time of removal,

and the ﬂow statistics at the time of removal.

5.6 Group Table

A group table consists of group entries. The ability for a ﬂow entry to point to a group enables OpenFlow

to represent additional methods of forwarding (e.g. select and all).

Group Identiﬁer Group Type Counters Action Buckets

Table 2: Main components of a group entry in the group table.

Each group entry (see Table 2) is identiﬁed by its group identiﬁer and contains:

• group identiﬁer: a 32 bit unsigned integer uniquely identifying the group on the OpenFlow

switch.

• group type: to determine group semantics (see Section 5.6.1).

• counters: updated when packets are processed by a group.

剩余170页未读，继续阅读

sinat_31655523

粉丝: 0
资源: 2

OpenFlow Switch规范1.3.4版详解

open flow协议标准

open_flow_spec

openflow协议1.3.0中文版---完整版.pdf

openflow-switch-v1.5.0

openflow switch specification V1.4 (Wire Protocol ox05)

OpenFlow协议详解：控制器与交换机的通信规范

基于MATLAB打地鼠游戏源码界面版.zip

Android开发：Android Architecture Components教程.pdf

红薯发布文章艾特.zip

【双足机器人】基于matlab双足机器人零动力学控制仿真（含动力学 控制模块）【含Matlab源码 8930期】.mp4

最新资源

【双足机器人】基于matlab双足机器人零动力学控制仿真（含动力学控制模块）【含Matlab源码 8930期】.mp4