OpenFlow Switch规范1.5.1：软件定义网络的基石

需积分: 9 64 浏览量更新于2024-07-18 收藏 3.16MB PDF 举报

"OpenFlow Switch v1.5.1 是Open Networking Foundation (ONF)发布的一个版本号为0x06的OpenFlow协议规范。该文档详细阐述了OpenFlow逻辑交换机的需求，以及如何通过远程OpenFlow控制器管理OpenFlow交换机的协议。此版本发布于2015年3月26日，编号为ONFTS-025。" OpenFlow是一种网络协议，它定义了如何在软件定义网络（SDN）环境中控制网络设备，如交换机。OpenFlow交换机是SDN架构的关键组件，它负责执行由远程OpenFlow控制器发出的指令，实现对网络流量的精细化控制。 OpenFlow Switch Specification v1.5.1包含以下关键知识点： 1. **协议版本**：v1.5.1对应的协议版本号是0x06，这表明了交换机支持的OpenFlow通信协议的特定版本，每个版本可能会有新的特性和改进。 2. **逻辑开关**：OpenFlow逻辑开关是一种虚拟化的网络设备，它可以被控制器编程以执行各种网络策略，如流表项的添加、修改或删除，从而实现数据包的转发决策。 3. **控制器通信**：OpenFlow交换机与控制器之间的通信基于OpenFlow协议，允许控制器远程管理和配置交换机，实现网络的动态配置、故障检测、性能优化和安全策略实施。 4. **流表**：流表是OpenFlow交换机的核心组件，存储了匹配条件和相应的处理动作。当数据包到达交换机时，会根据流表进行匹配，并执行对应的动作，如转发、丢弃或修改包头等。 5. **协议组件**：规范涵盖了OpenFlow交换机的组件，包括端口管理、流表管理、统计信息收集、错误处理和安全机制等。 6. **功能扩展**：v1.5.1可能引入了对新功能的支持，比如更复杂的流表匹配条件、更大的流表大小或者更丰富的动作集，以满足不断增长的网络需求。 7. **版权声明**：文档明确指出，ONF提供的此规范没有任何明示或暗示的保证，包括但不限于适销性、非侵权、针对特定目的的适用性等。ONF不承担任何由于使用此规范或其实施而产生的间接、偶然、特殊或后果性的损害责任。 OpenFlow Switch Specification v1.5.1是SDN领域的重要参考文献，对于理解OpenFlow交换机的工作原理和实现，以及如何利用OpenFlow进行网络编程具有重要意义。无论是网络设备制造商、网络管理员还是研究者，都需要深入理解这一规范，以便更好地利用SDN技术构建灵活、可编程的网络环境。

OpenFlow Switch Speciﬁcation Version 1.5.1

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 dependent 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, encapsulates the

packet in a packet-in message and sends 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,

sends the packet out through its ingress port.

OpenFIow

Switch

Specification

Version

1.5.1

4.3

Physical

Ports

The

OpenFlow

physical

ports

are

switch

deﬁned

ports

that

correspond

hardware

interface

the

switch.

For

example,

on an

Ethernet

switch,

physical

ports

map

one—to-one

the

Ethernet

interfaces.

some

deployments,

the

OpenFlow

switch

may

virtualised

over

the

switch

hardware.

those

cases,

OpenFlow

physical

port

may

represent

virtual

slice

the

corresponding

hardware

interface

the

switch.

4.4

Logical

Ports

The

OpenFlow

logical

ports

are

switch

deﬁned

ports

that

don’t

correspond

directly

hardware

interface

the

switch.

Logical

ports

are

higher

level

abstractions

that

may

deﬁned

the

switch

using

non—OpenFlow

methods

(e.g.

link

aggregation

groups,

tunnels,

loopback

interfaces).

Logical

ports

may

include

packet

encapsulation

and

may

map

various

physical

ports.

The

processing

done

the

logical

port

implementation

dependent

and

must

transparent

OpenFlow

processing,

and

those

ports

must

interact

with

OpenFlow

processing

OpenFlow

physical

ports.

The

only

differences

between

physical

ports

and

logical

ports

that

packet

associated

with

logical

port

may

have

extra

pipeline

ﬁeld

called

Tunnel-ID

associated

with

(see

and

when

packet

received

logical

port

sent

the

controller,

both

its

logical

port

and

its

underlying

physical

port

are

reported

the

controller

(see

7.4.1l.

4.5

Reserved

Ports

The

OpenFlow

reserved

ports

are

deﬁned

this

speciﬁcation.

They

specify

generic

forwarding

actions

such

sending

the

controller,

ﬂooding,

forwarding

using

non-OpenFlow

methods,

such

“normal”

switch

processing.

switch

not

required

support

all

reserved

ports,

just

those

marked

“Required”

below.

Required:

ALL:

Represents

all

ports

the

switch

can

use

for

forwarding

speciﬁc

packet.

Can

used

only

output

port.

that

case

copy

the

packet

starts

egress

processing

all

standard

ports,

excluding

the

packet

ingress

port

and

ports

that

are

conﬁgured

0FPPC_N0_FWD.

Required:

CONTROLLER:

Represents

the

control

channel

with

the

OpenFlow

controllers.

Can

used

ingress

port

output

port.

When

used

output

port,

encapsulates

the

packet

packet-in

message

and

sends

using

the

OpenFlow

switch

protocol

(see

When

used

ingress

port,

this

identiﬁes

packet

originating

from

the

controller.

Required:

TABLE:

Represents

the

start

the

OpenFlow

pipeline

(see

.D.

This

port

only

valid

output

action

the

list

actions

packet-out

message

(see

-l,

and

submits

the

packet

the

ﬁrst

ﬂow

table

that

the

packet

can

processed

through

the

regular

OpenFlow

pipeline.

Required:

IN_PORT:

Represents

the

packet

ingress

port.

Can

used

only

output

port,

sends

the

packet

out

through

its

ingress

port.

2015;

The

Open

Networking

Foundation

OpenFlow Switch Speciﬁcation Version 1.5.1

• 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 that the 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 an appropriate set of ﬂow entries, it can be used to implement an

in-band controller connection (this is outside the scope of this speciﬁcation).

• 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

dependent. 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 dependent. 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). Packets 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

Specification

Version

1.5.1

Required:

ANY:

Special

value

used

some

OpenFlow

requests

when

port

speciﬁed

(i.e.

port

wildcarded).

Some

OpenFlow

requests

contain

reference

speciﬁc

port

that

the

request

only

applies

to.

Using

ANY

the

port

number

these

requests

allows

that

request

instance

apply

any

and

all

ports.

Can

neither

used

ingress

port

nor

output

port.

Required:

UNSET:

Special

value

specify

that

the

output

port

has

not

been

set

the

Action-Set.

Only

used

when

trying

match

the

output

port

the

action

set

using

the

OXM_OF_ACTSET_OUTPUT

match

ﬁeld

(see

Can

neither

used

ingress

port

nor

output

port.

Optional:

LOCAL:

Represents

the

switch’s

local

networking

stack

and

its

management

stack.

Can

used

ingress

port

output

port.

The

local

port

enables

remote

entities

interact

with

the

switch

and

its

network

services

via

the

OpenFlow

network,

rather

than

via

separate

control

network.

With

appropriate

set

ﬂow

entries,

can

used

implement

in—band

controller

connection

(this

outside

the

scope

this

speciﬁcation).

Optional:

NORMAL:

Represents

forwarding

using

the

traditional

non—OpenFlow

pipeline

the

switch

(see

Can

used

only

output

port

and

processes

the

packet

using

the

normal

pipeline.

general

will

bridge

route

the

packet,

however

the

actual

result

implementation

dependent.

the

switch

cannot

forward

packets

from

the

OpenFlow

pipeline

the

normal

pipeline,

must

indicate

that

does

not

support

this

action.

Optional:

FLOOD:

Represents

ﬂooding

using

the

traditional

non-OpenFlow

pipeline

the

switch

(see

Can

used

only

output

port,

actual

result

implementation

dependent.

general

will

send

the

packet

out

all

standard

ports,

but

not

the

ingress

port,

nor

ports

that

are

OFPPS_BLOCKED

state.

The

switch

may

also

use

the

packet

VLAN

other

criteria

select

which

ports

use

for

ﬂooding.

OpenFlow-only

switches

not

support

the

NORMAL

port

and

FLOOD

port,

while

OpenFlow-hybrid

switches

may

support

them

(see

Forwarding

packets

the

FLOOD

port

depends

the

switch

implementation

and

conﬁguration,

while

forwarding

using

group

type

all

enables

the

controller

ﬂexibly

implement

ﬂooding

(see

5.10.1’.

4.6

Port

changes

switch

conﬁguration,

for

example

using

the

OpenFlow

Conﬁguration

Protocol,

may

add

remove

ports

from

the

OpenFlow

switch

any

time.

The

switch

may

change

the

port

state

based

the

underlying

port

mechanism,

for

example

the

link

going

down

(see

The

controller

switch

conﬁguration

may

change

the

port

conﬁguration

(see

Any

such

changes

port

state

conﬁguration

must

communicated

the

OpenFlow

controller

(see

7.4.3’.

Port

addition,

modiﬁcation

or removal

never

changes

the

content

the

ﬂow

tables,

particular

ﬂow

entries

referencing

those

ports

are

not

modiﬁed

removed

(ﬂow

entries

may

reference

ports

via

the

match

actions).

Packets

forwarded

non-existent

ports

are

just

dropped

(see

Similarly,

Port

addition,

modiﬁcation

and

removal

never

changes

the

content

the

group

table,

however

the

behaviour

some

groups

may

change

through

liveness

checking

(see

port

deleted

and

its

port

number

later

reused

for

different

physical

logical

port,

any

remaining

ﬂow

entries

group

entries

still

referencing

that

port

number

may

effectively

re—targeted

2015;

The

Open

Networking

Foundation

OpenFlow Switch Speciﬁcation Version 1.5.1

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

Specification

Version

1.5.1

the

new

port,

possibly

with

undesirable

results.

Therefore,

when

port

deleted

left

the

controller

clean

any

ﬁow

entries

group

entries

referencing

that

port,

needed.

4.7

Port

recirculation

Logical

ports

can

optionally

used

insert

network

service

complex

processing

the

OpenFlow

switch

(see

Most

often,

packets

sent

logical

ports

never

return

the

same

OpenFlow

switch,

they

are

either

consumed

the

logical

port

eventually

sent

over

physical

port.

other

cases,

packets

sent

logical

port

are

recirculated

back

the

OpenFlow

switch

after

the

logical

port

processing.

Packet

recirculation

via

logical

ports

optional,

and

OpenFlow

supports

multiple

types

port

re-

circulation.

The

simplest

recirculation

when

packet

sent

logical

port

returns

back

into

the

switch

via

the

same

logical

port.

This

could

used

for

loopback

unidirectional

packet

processing.

Recirculation

can

also

happen

between

port

pair,

which

packet

sent

logical

port

returns

back

into

the

switch

via

the

other

logical

port

the

pair.

This

could

used

represent

tunnel

endpoints

bidirectional

packet

processing.

port

property

describes

the

recirculation

relationship

between

ports

(see-.

switch

should

protect

itself

from

packet

inﬁnite

loops

when

using

port

recirculation.

This

mechanism

implementation—speciﬁc

and

outside

the

scope

this

speciﬁcation.

For

example,

the

switch

could

attach

internal

recirculation

count

each

packet,

which

incremented

for

each

recirculation,

and

the

switch

drops

packets

for

which

the

counter

above

switch-deﬁned

threshold.

Controllers

are

strongly

encouraged

avoid

generating

combinations

ﬂow

entries

that

may

yield

recirculation

loops.

Because

the

wide

range

possible

processing,

very

little

can

assumed

about

the

packets

recircu-

lated

back

into

the

switch.

Recirculated

packets

back

the

ﬁrst

ﬁow

table

the

pipeline

(see

and

can

identiﬁed

their

new

input

port.

The

packet

headers

may

have

changed,

the

match

ﬁelds

are

not

guaranteed

the

same.

The

logical

port

may

packet

fragmentation

and

reassembly,

the

packets

may

not

match

one

and

may

have

different

sizes.

The

Tunnel-ID

ﬁeld

and

some

other

pipeline

ﬁelds

associated

with

the

packet

may

optionally

preserved

through

the

recirculation

and

available

for

matching

when

returning

the

switch,

the

pipeline

ﬁelds

that

are

preserved

are

indicated

via

the

port

match

ﬁeld

property

(see

pipeline

ﬁeld

present

both

the

0FPPDPT_PIPELINE_0UTPUT

property

the

output

port

and

the

0FPPDPT_PIPELINE_INPUT

property

the

return

port,

then

this

pipeline

ﬁeld

preserved

with

the

packet

(its

value

must

remain

the

same).

OpenFlow

Tables

This

section

describes

the

components

ﬂow

tables

and

group

tables,

along

with

the

mechanics

matching

and

action

handling.

2015;

The

Open

Networking

Foundation

OpenFlow Switch Speciﬁcation Version 1.5.1

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 numbered in the order they can be traversed by packets,

OpenFlow

Switch

Specification

Version

1.5.1

Packet

Ingress

processing

Packeﬁ

Set

pipeline

ﬁelds

lngress

(ingress

port,

ress

Port

Flow Flow

metadata...)

Flow

Execute

Sort

Table Table

—>---—>

Table

Action

ACtiO“

Action

Set

Set={}

Set

Group

Table

Egress

processing

Packet+

Packet

Set

pipeline

ﬁelds

Output

(output

port,

0'“

Port

Flow Flow

metadata...)

Flow

Execute

—)

Table Table

—>-

- -

—>

Table

Action

e+1

Action

e+m

Set

{output}

Output

Port

ﬁrst

egress

table-id

Figure

Packet

ﬂow

through

the

processing

pipeline.

5.1

Pipeline

Processing

OpenFlow-compliant

switches

come

two

types:

OpenFlow-only,

and

OpenFlow-hybrid.

OpenFlow-

only

switches

support

only

OpenFlow

operation,

those

switches

all

packets

are

processed

the

OpenFlow

pipeline,

and

can

not

processed

otherwise.

OpenFlow-hybrid

switches

support

both

OpenFlow

operation

and

normal

Ethernet

switching

opera-

tion,

i.e.

traditional

Ethernet

switching,

VLAN

isolation,

routing

(IPv4

routing,

IPv6

routing...),

AOL

and

QoS

processing.

Those

switches

should

provide

classiﬁcation

mechanism

outside

Open-

Flow

that

routes

trafﬁc

either

the

OpenFlow

pipeline

the

normal

pipeline.

For

example,

switch

may

use

the

VLAN

tag

input

port

the

packet

decide

whether

process

the

packet

using

one

pipeline

the

other,

may

direct

all

packets

the

OpenFlow

pipeline.

This

classiﬁcation

mech-

anism

outside

the

scope

this

speciﬁcation.

OpenFlow-hybrid

switch

may

also

allow

packet

from

the

OpenFlow

pipeline

the

normal

pipeline

through

the

NORMAL

and

FLOOD

reserved

ports

(see

The

OpenFlow

pipeline

every

OpenFlow

Logical

Switch

contains

one

ﬁow

tables,

each

ﬂow

table

containing

multiple

ﬁow

entries.

The

OpenFlow

pipeline

processing

deﬁnes

how

packets

interact

with

those

ﬁow

tables

(see

Figure

OpenFlow

switch

required

have

least

one

ingress

ﬂow

table,

and

can

optionally

have

ﬂow

tables.

OpenFlow

switch

with

only

single

ﬂow

table

valid,

this

case

pipeline

processing

greatly

simpliﬁed.

The

ﬂow

tables

OpenFlow

switch

are

numbered

the

order

they

can

traversed

packets,

2015;

The

Open

Networking

Foundation

OpenFlow Switch Speciﬁcation Version 1.5.1

starting at 0. Pipeline processing 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 processed by the output port, and in most cases 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.

OpenFIow

Switch

Specification

Version

1.5.1

starting

Pipeline

processing

happens

two

stages,

ingress

processing

and

egress

processing.

The

separation

the

two

stages

indicated

the

ﬁrst

egress

table

(see

all

tables

with

number

lower

than

the

ﬁrst

egress

table

must

used

ingress

tables,

and

table

with

number

higher

than

equal

the

ﬁrst

egress

table

can

used

ingress

table.

Pipeline

processing

always

starts

with

ingress

processing

the

ﬁrst

ﬂow

table:

the

packet

must

ﬁrst

matched

against

ﬂow

entries

ﬂow

table

(see

Figure

Other

ingress

ﬁow

tables

may

used

depending

the

outcome

the

match

the

ﬁrst

table.

the

outcome

ingress

processing

forward

the

packet

output

port,

the

OpenFlow

switch

may

perform

egress

processing

the

context

that

output

port.

Egress

processing

optional,

switch

may

not

support

any

egress

tables

may

not

conﬁgured

use

them.

valid

egress

table

conﬁgured

the

ﬁrst

egress

table

(see

the

packet

must

processed

the

output

port,

and

most

cases

the

packet

forwarded

out

the

switch.

valid

egress

table

conﬁgured

the

ﬁrst

egress

table

(see

the

packet

must

matched

against

ﬂow

entries

that

ﬂow

table,

and

other

egress

ﬁow

tables

may

used

depending

the

outcome

the

match

that

ﬂow

table.

When

processed

ﬂow

table,

the

packet

matched

against

the

ﬂow

entries

the

ﬂow

table

select

ﬂow

entry

(see

ﬂow

entry

found,

the

instruction

set

included

that

ﬂow

entry

executed.

These

instructions

may

explicitly

direct

the

packet

another

ﬁow

table

(using

the

Goto-

Table

Instruction,

see

where

the

same

process

repeated

again.

ﬂow

entry

can

only

direct

packet

ﬂow

table

number

which

greater

than

its

own

ﬁow

table

number,

other

words

pipeline

processing

can

only

forward

and

not

backward.

Obviously,

the

ﬂow

entries

the

last

table

pipeline

stage

can

not

include

the

Goto-Table

instruction.

the

matching

ﬁow

entry

does

not

direct

packets

another

ﬁow

table,

the

current

stage

pipeline

processing

stops

this

table,

the

packet

processed

with

its

associated

action

set

and

usually

forwarded

(see

packet

does

not

match

ﬂow

entry

ﬂow

table,

this

table

miss.

The

behavior

table

miss

depends

the

table

conﬁguration

(see

The

instructions

included

the

table-miss

ﬁow

entry

the

ﬂow

table

can

ﬁexibly

specify

how

process

unmatched

packets,

useful

options

include

dropping

them,

passing

them

another

table

sending

them

the

controllers

over

the

control

channel

via

packet—in

messages

(see

There

are

few

cases

where

packet

not

fully

processed

ﬂow

entry

and

pipeline

processing

stops

without

processing

the

packet’s

action

set

directing

another

table.

table—miss

ﬁow

entry

present,

the

packet

dropped

(see

.D.

invalid

TTL

found,

the

packet

may

sent

the

controller

(see

The

OpenFlow

pipeline

and

various

OpenFlow

operations

process

packets

speciﬁc

type

con-

formance

with

the

speciﬁcations

deﬁned

for

that

packet

type,

unless

the

present

speciﬁcation

the

OpenFlow

conﬁguration

specify

otherwise.

For

example,

the

Ethernet

header

deﬁnition

used

Open-

Flow

must

conform

IEEE

speciﬁcations,

and

the

TCP

header

deﬁnition

used

OpenFlow

must

conform

RFC

speciﬁcations.

Additionally,

packet

reordering

OpenFlow

switch

must

conform

the

requirements

IEEE

speciﬁcations,

provided

that

the

packets

are

processed

the

same

ﬁow

entries,

group

buckets

and

meter

bands.

2015;

The

Open

Networking

Foundation

剩余282页未读，继续阅读

aidong20181008

粉丝: 0
资源: 10

OpenFlow Switch规范1.5.1：软件定义网络的基石

最新的OpenFlow v1.5规范

OpenFlow(1.0-1.5)白皮书

OpenFlow Switch Specification V1.4.0

ns3 find_external_library: openflow was not found. missing headers: "openflo

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

simple_switch_13.py

openflow switch

如何切割ODL的源代码，只保留OVSDB和OPENFLOW部分，再重新编译

SDN实验 xterm h1 h4 没有反映

OpenFlow 命令

最新资源