OpenFlow 1.5.0逻辑交换机规格与控制器管理协议详解

需积分: 9 23 浏览量更新于2024-07-16 收藏 2.05MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

OpenFlow Switch Specification Version 1.5.0（协议版本0x06），发布于2014年12月19日，是Open Networking Foundation（ONF）制定的一份文档，旨在定义OpenFlow逻辑交换机的需求和功能。这份标准详细阐述了开放网络架构的核心组件，特别是如何通过远程OpenFlow控制器管理OpenFlow交换机。OpenFlow是一种软件定义网络（Software-Defined Networking, SDN）的关键技术，它将网络控制平面从硬件绑定分离出来，允许网络管理员以编程方式管理网络流量。在OpenFlow Switch Specification中，主要内容包括： 1. 逻辑开关组件：文档描述了逻辑交换机的组成，这些组件可能涉及数据包处理单元、交换表、队列以及用于实现南北向通信的接口。它们协同工作，提供了灵活的网络流量转发规则。 2. 协议规范：版本1.5.0定义了OpenFlow交换机协议，该协议定义了控制器与交换机之间的通信协议，如控制消息类型、状态报告、流表操作等。这使得网络管理员能够通过API调用对交换机进行配置和监控。 3. 功能描述：文档详细说明了基本的交换机功能，如学习和维护MAC地址表、处理流量规则、实施安全策略，以及支持QoS（服务质量）等。 4. 安全性与免责声明：ONF强调，本规格书“按现状”提供，不附带任何保证，包括适销性、非侵权性或特定用途的适用性。用户使用此规格书和实施规范时需自行承担风险，ONF不对因使用规格书或其中信息导致的任何损失或损害承担责任，包括但不限于版权侵犯、采购替代品的成本、经济损失、数据丢失等。 5. 许可问题：ONF明确表示，此规格书并不授予任何知识产权许可，无论是明示的还是默示的，或者通过禁止反言等方式。这意味着在遵循规范的同时，用户必须确保其行为不会侵犯ONF成员或其他相关方的知识产权。总结来说，OpenFlow Switch Specification Version 1.5.0是SDN领域的重要参考资料，为构建可编程、灵活且易于管理的数据中心网络提供了基础。它不仅定义了交换机的功能和操作，还为控制器与交换机之间的交互设定了清晰的通信规范，是理解现代网络架构和技术的关键文档。

资源详情

资源推荐

OpenFlow Switch Speciﬁcation Version 1.5.0

4.3 Physical Ports

The OpenFlow physical ports are switch deﬁned ports that correspond to a hardware interface of the

switch. For example, on an Ethernet switch, physical ports map one-to-one to the Ethernet interfaces.

In some deployments, the OpenFlow switch may be virtualised over the switch hardware. In those cases,

an OpenFlow physical port may represent a virtual slice of the corresponding hardware interface of the

switch.

4.4 Logical Ports

The OpenFlow logical ports are switch deﬁned ports that don’t correspond directly to a hardware

interface of the switch. Logical ports are higher level abstractions that may be deﬁned in the switch

using non-OpenFlow methods (e.g. link aggregation groups, tunnels, loopback interfaces).

Logical ports may include packet encapsulation and may map to various physical ports. The processing

done by the logical port is implementation dependant and must be transparent to OpenFlow processing,

and those ports must interact with OpenFlow processing like OpenFlow physical ports.

The only diﬀerences between physical ports and logical ports is that a packet associated with a logical

port may have an extra pipeline ﬁeld called Tunnel-ID associated with it (see 7.2.3.9) and when a packet

received on a logical port is sent to the controller, both its logical port and its underlying physical port

are reported to the controller (see 7.4.1).

4.5 Reserved Ports

The OpenFlow reserved ports are deﬁned by this speciﬁcation. They specify generic forwarding

actions such as sending to the controller, ﬂooding, or forwarding using non-OpenFlow methods, such

as “normal” switch processing.

A switch is not required to support all reserved ports, just those marked “Required” below.

• Required: ALL: Represents all ports the switch can use for forwarding a speciﬁc packet. Can

be used only as an output port. In that case a copy of the packet starts egress processing on all

standard ports, excluding the packet ingress port and ports that are conﬁgured OFPPC_NO_FWD.

• Required: CONTROLLER: Represents the control channel with the OpenFlow controllers. Can

be used as an ingress port or as an output port. When used as an output port, encapsulate the

packet in a packet-in message and send it using the OpenFlow switch protocol (see 7.4.1). When

used as an ingress port, this identiﬁes a packet originating from the controller.

• Required: TABLE: Represents the start of the OpenFlow pipeline (see 5.1). This port is only

valid in an output action in the list of actions of a packet-out message (see 7.3.6), and submits the

packet to the ﬁrst ﬂow table so that the packet can be processed through the regular OpenFlow

pipeline.

• Required: IN PORT: Represents the packet ingress port. Can be used only as an output port,

send the packet out through its ingress port.

OpenFlow Switch Speciﬁcation Version 1.5.0

• Required: ANY: Special value used in some OpenFlow requests when no port is speciﬁed (i.e. port

is wildcarded). Some OpenFlow requests contain a reference to a speciﬁc port that the request

only applies to. Using ANY as the port number in these requests allows that request instance to

apply to any and all ports. Can neither be used as an ingress port nor as an output port.

• Required: UNSET: Special value to specify the that output port has not been set in the

Action-Set. Only used when trying to match the output port in the action set using the

OXM_OF_ACTSET_OUTPUT match ﬁeld (see 7.2.3.7). Can neither be used as an ingress port nor

as an output port.

• Optional: LOCAL: Represents the switch’s local networking stack and its management stack.

Can be used as an ingress port or as an output port. The local port enables remote entities to

interact with the switch and its network services via the OpenFlow network, rather than via a

separate control network. With a suitable set of default ﬂow entries it can be used to implement

an in-band controller connection.

• Optional: NORMAL: Represents forwarding using the traditional non-OpenFlow pipeline of the

switch (see 5.1). Can be used only as an output port and processes the packet using the normal

pipeline. In general will bridge or route the packet, however the actual result is implementation

dependant. If the switch cannot forward packets from the OpenFlow pipeline to the normal

pipeline, it must indicate that it does not support this action.

• Optional: FLOOD: Represents ﬂooding using the traditional non-OpenFlow pipeline of the switch

(see 5.1). Can be used only as an output port, actual result is implementation dependant. In

general will send the packet out all standard ports, but not to the ingress port, nor ports that are

in OFPPS_BLOCKED state. The switch may also use the packet VLAN ID or other criteria to select

which ports to use for ﬂooding.

OpenFlow-only switches do not support the NORMAL port and FLOOD port, while OpenFlow-hybrid

switches may support them (see 5.1). Forwarding packets to the FLOOD port depends on the switch

implementation and conﬁguration, while forwarding using a group of type all enables the controller to

more ﬂexibly implement ﬂooding (see 5.10.1).

4.6 Port changes

A switch conﬁguration, for example using the OpenFlow Conﬁguration Protocol, may add or remove

ports from the OpenFlow switch at any time. The switch may change the port state based on the

underlying port mechanism, for example if the link is going down (see 7.2.1). The controller or a

switch conﬁguration may change the port conﬁguration (see 7.2.1). Any such changes to port state or

conﬁguration must be communicated to the OpenFlow controller (see 7.4.3).

Port addition, modiﬁcation or removal never changes the content of the ﬂow tables, in particular ﬂow

entries referencing those ports are not modiﬁed or removed (ﬂow entries may reference ports via the

match or actions). Packet forwarded to non-existent ports are just dropped (see 5.6). Similarly, Port

addition, modiﬁcation and removal never changes the content of the group table, however the behaviour

of some groups may change through liveness checking (see 6.7).

If a port is deleted and its port number is later reused for a diﬀerent physical or logical port, any

remaining ﬂow entries or group entries still referencing that port number may be eﬀectively re-targeted

OpenFlow Switch Speciﬁcation Version 1.5.0

to the new port, possibly with undesirable results. Therefore, when a port is deleted it is left to the

controller to clean up any ﬂow entries or group entries referencing that port, if needed.

4.7 Port recirculation

Logical ports can optionally be used to insert a network service or complex processing in the OpenFlow

switch (see 4.4). Most often, packets sent to logical ports never return to the same OpenFlow switch,

they are either consumed by the logical port or eventually sent over a physical port. In other cases,

packets sent to a logical port are recirculated back to the OpenFlow switch after the logical port

processing.

Packet recirculation via logical ports is optional, and OpenFlow supports multiple types of port re-

circulation. The simplest recirculation is when a packet sent on a logical port returns back into the

switch via the same logical port. This could be used for a loopback or unidirectional packet processing.

Recirculation can also happen between a port pair, in which a packet sent on a logical port returns back

into the switch via the other logical port of the pair. This could be used to represent tunnel endpoints or

bidirectional packet processing. A port property describes the recirculation relationship between ports

(see 7.2.1.2).

A switch should protect itself from packet inﬁnite loops when using port recirculation. This mechanism

is implementation-speciﬁc and outside the scope of this speciﬁcation. For example, the switch could

attach an internal recirculation count to each packet, which is incremented for each recirculation, and the

switch drops packets for which the counter is above a switch-deﬁned threshold. Controllers are strongly

encouraged to avoid generating combinations of ﬂow entries that may yield recirculation loops.

Because of the wide range of possible processing, very little can be assumed about the packets recircu-

lated back into the switch. Recirculated packets go back to the ﬁrst ﬂow table of the pipeline (see 5.1)

and can be identiﬁed by their new input port. The packet headers may have changed, so the match

ﬁelds are not guaranteed to be the same. The logical port may do packet fragmentation and reassembly,

so the packets may not match one to one and may have diﬀerent sizes.

The Tunnel-ID ﬁeld and some other pipeline ﬁelds associated with the packet may optionally be

preserved through the recirculation and available for matching when returning to the switch, the

pipeline ﬁelds that are preserved are indicated via the port match ﬁeld property (see 7.2.1.2). If a

pipeline ﬁeld is present in both the OFPPDPT_PIPELINE_OUTPUT property of the output port and the

OFPPDPT_PIPELINE_INPUT property of the return port, then this pipeline ﬁeld is preserved with the

packet (its value must remain the same).

5 OpenFlow Tables

This section describes the components of ﬂow tables and group tables, along with the mechanics of

matching and action handling.

OpenFlow Switch Speciﬁcation Version 1.5.0

Ingress

Port

Packet +

pipeline fields

(ingress port,

metadata...)

Flow

Table

Flow

Table

Flow

Table

Execute

Action

Set

Action

Set

Action

Set = {}

Ingress processing

Set

Ingress

Port

Group

Table

Packet +

pipeline fields

(output port,

metadata...)

Flow

Table

Flow

Table

e+1

Flow

Table

e+m

Execute

Action

Set

Action

Set

Action

Set =

{output}

Egress processing

Set

Output

Port

Output

Port

Packet

Out

e = first egress table-id

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 ingress ﬂ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.

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

OpenFlow Switch Speciﬁcation Version 1.5.0

happens in two stages, ingress processing and egress processing. The separation of the two stages is

indicated by the ﬁrst egress table (see 7.3.2), all tables with a number lower than the ﬁrst egress table

must be used as ingress tables, and no table with a number higher than or equal to the ﬁrst egress table

can be used as an ingress table.

Pipeline processing always starts with ingress processing at the ﬁrst ﬂow table: the packet must be

ﬁrst matched against ﬂow entries of ﬂow table 0 (see Figure 3). Other ingress ﬂow tables may be

used depending on the outcome of the match in the ﬁrst table. If the outcome of ingress processing is

to forward the packet to an output port, the OpenFlow switch may perform egress processing in the

context of that output port. Egress processing is optional, a switch may not support any egress tables

or may not be conﬁgured to use them. If no valid egress table is conﬁgured as the ﬁrst egress table (see

7.3.2), the packet must be process by the output port, and in most case the packet is forwarded out of

the switch. If a valid egress table is conﬁgured as the ﬁrst egress table (see 7.3.2), the packet must be

matched against ﬂow entries of that ﬂow table, and other egress ﬂow tables may be used depending on

the outcome of the match in that ﬂow 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.5), 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 a

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

packets to another ﬂow table, the current stage of pipeline processing stops at this table, the packet is

processed with its associated action set and usually forwarded (see 5.6).

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

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.

剩余276页未读，继续阅读

wandonglin

粉丝: 0
资源: 3

OpenFlow 1.5.0逻辑交换机规格与控制器管理协议详解

openflow-switch-v1.5.0

OpenFlow(1.0-1.5)白皮书

OpenFlow Switch v1.5.1.

openvswitch-2.9.2-1.el7.x86_64.rpm下载

以下不属于OpenFlow中Controller-to-Switch消息的子类型的是（ ）

mn --controller=remote,ip=127.0.0.1 --mac --switch=ovsk,protocols=OpenFlow13 --topo=single,4 命令错误

以下不属于OpenFlow中Controller-to-Switch消息的子类型的是（ ） A、 Modify-State B、 Switch features C、 Barrier D、 Packet-in

ovs-vswitchd

ubuntu20.04安装mininet

登录SW1，使用CLI 命令行建立SDN 交换机和SDN 控制器之间的OpenFlow 通道的命令

ubuntu16.04安装mininet

SDN拓扑搭建怎么在使用Mininet可视化工具，生成下图所示的拓扑，并保存拓扑文件名为学号.py（Export Level 2 Script），保存路径为步骤1新建的目录。

写一个八百字的小结，内容是实验环境安装部署，包括niminet，opendaylight，openvswitch，具体功能实现，使用l2switch项目实现负载均衡，meter降速，队列控制流量

pox配置阿里云镜像

OpenFlow Flow-Mod消息学习

ubuntu上，安装pox

在OpenFlow v1.5协议版本中，匹配域中的匹配项的个数已经增加到了45个。

有两个文件simple switch.py和simple switch 13.py，关于他们的说法正确

openflow switch

mininet模拟的openflow交换机叫什么

最新资源

以下不属于OpenFlow中Controller-to-Switch消息的子类型的是（）

以下不属于OpenFlow中Controller-to-Switch消息的子类型的是（） A、 Modify-State B、 Switch features C、 Barrier D、 Packet-in