OpenFlow13协议：互联网革新与新型交换模型

需积分: 27 40 浏览量更新于2024-07-18 收藏 1.58MB PDF 举报

OpenFlow 13协议是在互联网发展和新业务需求推动下，改革派提出的一种新型网络交换模型。它是在面对互联网传输质量提升和传统基础设施局限性的问题时，试图通过全新的设计思路来重构网络架构。OpenFlow协议的核心理念在于提供一种可编程的网络交换机制，允许网络设备（如交换机）与控制器之间进行更直接、灵活的通信，从而实现网络行为的动态控制和优化。 OpenFlow 1.3.5版本于2015年3月发布，标志着该协议的不断发展和完善。该版本的规范提供了详细的接口定义和工作原理，强调了其"无保函"性质，即用户在使用过程中可能面临的风险和责任自负，包括但不限于版权、侵权、适合特定用途的问题以及由此产生的任何损失或损害。协议的核心特性包括以下几个方面： 1. **可编程性**：OpenFlow允许管理员通过软件定义的方式，远程控制和配置交换机的行为，这使得网络管理人员能够根据业务需求动态调整网络策略，增强了网络的灵活性和响应能力。 2. **控制器分离**：OpenFlow交换机与传统的桥接模式不同，它将转发决策从硬件转移到软件控制器，这有助于简化网络管理，提高效率，并便于引入创新功能。 3. **消息交换机制**：协议定义了一套明确的消息交换格式，包括控制消息（如FlowMod请求）和状态报告，这些用于在控制器和交换机之间建立实时通信。 4. **安全与认证**：虽然协议本身不直接处理安全问题，但通常会结合其他安全措施来确保数据传输的安全性，例如身份验证和加密。 5. **版本兼容性**：OpenFlow 1.3.5版本表明协议不断迭代，支持多个版本的存在，确保了旧版设备和新版本网络的兼容性。 OpenFlow论坛作为推动该协议发展的组织，旨在促进OpenFlow技术的标准化和实施，汇集业界专家和利益相关者共同探讨和改进这一新型网络模型。尽管OpenFlow协议带来了一系列优点，但也需要考虑到实施成本、复杂性管理和可能面临的挑战，比如对现有网络基础设施的改造，以及与现有网络管理工具的集成等问题。 OpenFlow 13协议是网络行业的一个重要里程碑，它代表了网络架构从封闭式到开放式的转型，为未来网络灵活性、自动化和效率的提升奠定了基础。然而，其成功实施需要深思熟虑的规划和适配，以确保新旧技术的平稳过渡和业务连续性。

OpenFlow Switch Speciﬁcation Version 1.3.5

Table

Packet

Execute

Action

Set

Packet

Action

Set

Action

Set = {}

OpenFlow Switch

Packet

Out

...

Ingress

port

Packet +

ingress port +

metadata

Action

Set

(a) Packets are matched against multiple tables in the pipeline

Match ﬁelds:

Ingress port +

metadata +

pkt hdrs

Action set

Flow

Table

➀ Find highest-priority matching ﬂow entry

➁ Apply instructions:

i. Modify packet & update match ﬁelds

(apply actions instruction)

ii. Update action set (clear actions and/or

write actions instructions)

iii. Update metadata

➂ Send match data and action set to

next table

➀

➁

➂

Action set

Match ﬁelds:

Ingress port +

metadata +

pkt hdrs

(b) Per-table packet processing

Figure 2: Packet ﬂow through the processing pipeline.

5.1 Pipeline Processing

OpenFlow-compliant switches come in two types: OpenFlow-only, and OpenFlow-hybrid. OpenFlow-

only switches support only OpenFlow operation, in those switches all packets are processed by the

OpenFlow pipeline, and can not be processed otherwise.

OpenFlow-hybrid switches support both OpenFlow operation and normal Ethernet switching opera-

tion, i.e. traditional L2 Ethernet switching, VLAN isolation, L3 routing (IPv4 routing, IPv6 routing...),

ACL and QoS processing. Those switches should provide a classiﬁcation mechanism outside of Open-

Flow that routes traﬃc to either the OpenFlow pipeline or the normal pipeline. For example, a switch

may use the VLAN tag or input port of the packet to decide whether to process the packet using one

pipeline or the other, or it may direct all packets to the OpenFlow pipeline. This classiﬁcation mech-

anism is outside the scope of this speciﬁcation. An OpenFlow-hybrid switch may also allow a packet

to go from the OpenFlow pipeline to the normal pipeline through the NORMAL and FLOOD reserved

ports (see 4.5).

The OpenFlow pipeline of every OpenFlow Logical Switch contains one or more ﬂow tables, each ﬂow

table containing multiple ﬂow entries. The OpenFlow pipeline processing deﬁnes how packets interact

with those ﬂow tables (see Figure 2). An OpenFlow switch is required to have at least one ﬂow table,

and can optionally have more ﬂow tables. An OpenFlow switch with only a single ﬂow table is valid,

in this case pipeline processing is greatly simpliﬁed.

OpenFlow Switch Speciﬁcation Version 1.3.5

The ﬂow tables of an OpenFlow switch are numbered in the order they can be traversed by packets,

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 buckets and meter bands.

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 assumes

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

example some switches may carry the VLAN information in some internal metadata while for the

OpenFlow pipeline it is logically part of the packet. Some OpenFlow switches 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 expects that the mapping to the hardware is consistent, and that the

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

OpenFlow Switch Speciﬁcation Version 1.3.5

• 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 matches 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 groups must be consistent with ﬂow tables. In particular,

actions 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 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.5

• 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

enables 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).

Packet header ﬁelds are extracted from the packet, and packet pipeline ﬁelds are retrieved. Packet

header ﬁelds used for table lookups depend on the packet type, and typically include various protocol

header ﬁelds, such as Ethernet source address or IPv4 destination address (see 7.2.3). In addition to

OpenFlow Switch Speciﬁcation Version 1.3.5

packet headers, matches can also be performed 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

header ﬁelds and pipeline ﬁelds represent the packet in its current state, if actions applied in a previous

table using the Apply-Actions instruction changed the packet headers or pipeline ﬁelds, those changes

are reﬂected in the packet header ﬁelds and pipeline ﬁelds.

A packet matches a ﬂow entry if all the match ﬁelds of the ﬂow entry are matching the corresponding

header ﬁelds and pipeline ﬁelds from the packet. If a match ﬁeld is omitted in the ﬂow entry (i.e. value

ANY), it matches all possible values in the header ﬁeld or pipeline ﬁeld of the packet (see 7.2.3.4). If

the match ﬁeld is present and does not include a mask, the match ﬁeld is matching the corresponding

header ﬁeld or pipeline ﬁeld from the packet if it has the same value. If the switch supports arbitrary

bitmasks on speciﬁc match ﬁelds, these masks can more precisely specify matches, the match ﬁeld is

matching if it has the same value for the bits which are set in the mask (see 7.2.3.5).

The packet is matched against ﬂow entries in the ﬂow 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 (see 5.8) and the instruction set included in the selected ﬂow entry must be executed

(see 5.9). 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 either on an OpenFlow port (see 4.1) or in a Packet-Out message (see

6.1.1).

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), 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), it may expire (see 5.5), and

it may be read by the controller (see 7.3.5.2). 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

剩余176页未读，继续阅读

diaodan

粉丝: 1
资源: 2

OpenFlow13协议：互联网革新与新型交换模型

OpenFlow13流表项

openflow协议以及协议的代码实现

openflow 协议

OpenFlow1.3协议

openflow 1.4 协议框架

OpenFlow1.0协议的分析

openflow1.3.3 协议描述 英文版

openflow协议

OpenFlow协议

Openflow1.3协议的理解与分析

最新资源

openflow1.3.3 协议描述英文版