1. 南向接口协议
南向接口协议是实现控制平面的控制器与数据平面的交换机之间的信息交互及部分配置管理功能，北向接口协议实现控制器与开发者间的交互，东西向接口协议负责控制器间的协同。
1.1 南向接口的设计目标
- 实现数据平面和控制平面的信息交互，向上收集交换机信息，向下下发控制策略，指导转发行为 。
- 实现网络的配置与管理
- 实现路径计算，包括传送链路的带宽与开销等属性、链路状态和拓扑信息等。
1.2 已实现的南向接口协议
|
南向接口协议 |
设计目标 |
|
OpenFlow |
用于OF交换机与控制器的信息交互 |
|
OF-Config |
用于OF交换机的配置与管理 |
|
NETCONF |
用于网络设备的配置与管理 |
|
OVSDB |
用于Open vSwitch的配置与管理 |
|
XMPP |
用于即时同i性能、游戏平台、语音与视频会议系统，OpenContrail控制器利用XMPP与vRouter进行信息交互 |
|
PCEP |
PCEP为PCE和PCC之间的通信协议，实现路径计算 |
|
I2RS |
I2RS体系架构中的南向接口协议 |
|
OpFlex |
思科ACI体系中的策略控制协议 |
2.OpenFlow端口类型
OF交换机的端口是交换机传递数据包的网络接口，交换机通过端口与其他交换机建立逻辑连接。端口分为物理端口、逻辑端口和保留端口。
2.1 物理端口
物理端口与交换机的硬件接口一一对应。在交换机硬件虚拟化情况下，物理端口可能对应交换机硬件接口的一个虚拟切片。
2.2 逻辑端口
逻辑端口是交换机定义的建立在物理端口之上的高层抽象，用于完成某种特定的功能，如隧道、链路汇聚、环回等。一个逻辑端口可以映射到多个物理端口。
2.3 保留端口
保留端口由OF交换机规范定义，用于通用的转发动作，如发送到控制器、洪泛或采用非OF方法转发（如传统交换机处理过程）。
OF定义了ALL、CONTROLLER、TABLE、IN_PORT、ANY、LOCAL、NORMAL和FLOOD八种保留端口。
纯OF交换机不支持NORMAL和FLOOD端口，混合交换机可能支持。在实现泛洪功能时，不同交换机可能采用不同的方式。可能直接将数据包转发到FLOOD端口，也可能使用类型为ALL的组进行转发以利用控制器实现更灵活的泛洪。
|
类型 |
端口名 |
说明 |
|
必备
|
ALL |
代表所有可用于转发数据包的端口，只能用作输出端口，将数据包发往除输入端口和配置为OFPPC_NO_FWD端口之外的所有端口 |
|
CONTROLLER |
代表与控制器相连的控制通道，可用作输入端口或输出端口。用作输出端口时，使用OF协议将数据包发往控制器（packet_in）；用作输入端口时，表明数据包来自控制器 |
|
|
TABLE |
代表OF流水线处理的起点，只用在控制器发出的转发包指令（packet_out）中，将数据包交给第一张流表，完成常规流水线处理过程 |
|
|
IN_PORT |
代表数据包的入端口，只能用作输出端口，将数据包从入端口发送出去 |
|
|
ANY |
当没有端口被指定时，用作特殊值被某些OF指令使用，既不能作为输入端口也不能作为输出端口 |
|
|
可选
|
LOCAL |
代表交换机本地网络栈和管理栈，可用作输入或输出端口。通过该端口，远端实体可通过OF网络访问交换机及其网络服务，而不需要通过单独的控制网络。LOCAL端口可用于实现带内控制器连接 |
|
NORMAL |
代表传统的非OF流水线，只能用作输出端口，指明采用常规流水处理数据包。如果交换机不能将数据包从OF流水线转发到常规流水线，它需要声明不支持这一动作 |
|
|
FLOOD |
代表使用交换机常规流水线进行泛洪，只能用作输出端口。通常会把数据包发送给除输入端口和OFPS_BLOCKED状态的端口之外的所有标准接口。交换机也可以使用VLAN ID来选择需要洪泛的端口 |
3. OpenFlow v1.0架构
OF交换机基于安全连接的OF协议与控制器进行通信。在OF协议v1.0中，流表、安全通道与OF协议是最为核心的概念。流表是一些针对特定“流”的策略表项的集合，负责数据分组的查询与转发。OF交换机通过安全通道与控制器相连，安全通道上传输的就是OF协议消息。负责控制器与交换机的交互。
3.1 OF流表
OpenFlow 控制器通过部署流表来指导数据平面流量。OpenFlow v1.0 中每台 OF 交换机只有一张流表，这张流表中存储着许多的表项，每一个表项都表征了一个“流”及其对应的处理方法——动作表（Action），一个数据分组进入 OF 交换机后需要先匹配流表，若符合其中某条表项的特征，则按照相应的动作进行转发，否则封装为Packet-in消息通过安全通道交给控制器，再由控制器决定如何处理，例如是否封装 Flow-mod 消息下发新的流表项。另外，每条流表项都存在一个有效期，过期之后流表会自动删除。流表就是特定流的策略表项的集合，负责数据包的查找与转发。
3.1.1 流表项的结构
以OpenFlowV1.0的表项主要由三部分组成，分别是用于匹配的分组头域，用于统计流表匹配情况的计数器，和匹配表项后需要对数据分组执行的动作表。
3.1.2 分组头域
分组头域是数组分组匹配流表时参照的依据，作用上类似传统交换机进行二层交换时匹配数据分组的MAC地址、路由器进行三层路由时匹配的IP地址。在OpenFlowV1.0中，流表项的分组头域包含了12个字段，协议称其为12元组，负责提供1-4层的网络控制信息。其中，交换机入端口属于一层标识；源MAC、目的MAC、以太网类型、VLAN标签、VLAN优先级属于二层标识；源IP、目的IP、IP协议字段、IP服务类型属于三层标识；TCP/UDP源端口、TCP/UDP目的端口属于四层标识。
3.1.3 计数器
流表项中的计数器用于统计数据相关“流”的一些信息，对每张流表、每个流表项、每个端口、每个转发队列进行维护。对每张流表，统计当前活动的表项数、数据包查找次数以及数据包匹配次数等；对每个流表项，统计接收到的数据包数、字节数以及数据流持续时间等；对每个设备端口，统计接收到的数据包数、发送数据包数、接收字节数、发送字节数、错误发生的次数（接收出现的错误、发送出现的错误、接手后丢弃的数据包数、发送时丢弃的数据包数、接收的帧排列错误、溢出错误、CRC校验错误、帧冲突）；对每个转发队列，统计发送的数据包数、发送的字节数、溢出错误次数等。
3.1.4 动作表
- 指定了OF交换机处理相应“流”的行为。
动作表可以包含0个或多个动作，交换机会按照这些动作的先后顺序依次执行，如果其中不包含转发动作的话，数据分组就会被丢弃掉。
- 多个动作的执行可以具有不同的优先级，但是OpenFlowV1.0无法保证不同的数据分组的发送顺序。
- 当流表项中存在OF交换机不支持的动作时，将向控制器返回错误消息。
- 流表项的动作分为两种：必选动作Required Action和可选动作Optional Action。必选动作是默认支持的，而交换机需要通知控制器它支持的可选动作。
|
类型 |
名称 |
说明 |
|
必备动作
|
转发 |
交换机必须支持将数据分组转发给设备的物理端口以及下面的保留端口。ALL：数据分组复制为多份转发到所有端口（不包括入端口和STP）； CONTROLLER：将数据分组封装为packet-in消息并转发给控制器； LOCAL：转发给本地网络栈； TABLE：对控制器packet-out数据分组执行流表的匹配； IN_PORT：把数据分组从它的入端口发回去 |
|
丢弃 |
没有明确指明处理行动的表项，所匹配的所有王分组默认被丢弃 |
|
|
可选动作
|
转发 |
NORMAL：按照OF交换机所支持的传统交换机的二层或三层策略进行转发； FLOOD：通过最小STP从出端口洪泛发出，但不包括入端口 |
|
入队 |
将分组转发到某个端口上已配置号的队列中，队列的配置OF无法实现 |
|
|
修改域 |
交换机将修改数据分组的分组头，可以为12元组中的任意字段 |
2.1.5 流表的匹配
每个数据分组按照优先级依次去匹配流表项中表项，匹配包的优先级最高的表项即为匹配结果。匹配成功，对应的计数器将更新，同时实施转发动作；如果没能找到匹配的表项，则转发给控制器。
3.1.6 分组头解析匹配流程
分组头解析（Parse Header）是为了得到所收到数据分组的12元组。OF交换机首先根据收到的数据分组解析出它的输入端口、以太网源地址、目的地址和协议类型，根据以太网类型得到VLAN或三层IP的信息，再根据IP分组头中的协议类型得到ICMP信息或四层的源、目的端口号；得到了数据分组的12元组，就可以用它与流表项中的分组头域进行匹配。
3.2 OF安全通道
OF安全通道承载着OF协议的消息，不管是流表的下发还是其他的控制消息都要经过这条通道。这部分流量属于OF网络的控制指令，有别于数据平面的网络“流”，不需要通过交换机流表的检查。为了保证本地流量安全可靠的传输，OF v1.0中规定通过建立在TCP连接之上，采用TLS安全传输层协议进行加密。
首先是连接的建立：控制器开启TCP的6633端口等待交换机的连接；交换机启动时，尝试连接到指定控制器端口；安全通道采用TLS连接加密；双方通过交换证书进行认证。控制器与OF交换机建立TLS隧道后，双方发送Hello消息进行版本的协商；若协议版本协商成功，则连接建立；否则。发送error消息描述失败的原因并终止连接。
协商完成后，控制器发送FEATURES_REQUEST消息获取交换机的参数，交换机回复FEATERS_REPLY消息将交换机的详细参数告知给控制器，包括支持的Buffer数目、流表数以及Actions等。
控制器发送SET_CONFIG消息向交换机下发配置参数，然后通过GET_CONFIG_REQUEST消息来请求交换机上场修改后的配置信息，交换机通过GET_CONFIG_REPLY响应请求。
控制器与OF交换机通之间发送packet_out、packet_in消息，通过packet_out种内置的LLDP包进行网络拓扑的探测，通过FLOW_MOD消息向控制器下发流表操作，比如增删改等。
3.3 OF消息类型
OpenFlow v1.0支持3种消息类型：Controller-to-Switch（控制器—交换机）、Asynchronous（异步）和 Symmetric（对称），每一类消息又有多个自消息类型。
3.3.1 Controller-to-Switch消息
这类消息由控制器发起，包括Features、Configuration、Modify-State、Read-State、Send-Packet、Barrier等几类消息，用于对OF交换机的管理。控制器通过其中各种请求（Request）消息来查询OF交换机的状态，OF交换机收到后需回复相应的响应（Reply）消息。
|
名称 |
说明 |
|
Features |
安全通道建立以后，控制器立即发送Features-request消息给交换机以获得它支持的特性 |
|
Configuration |
控制器可以通过Set-config消息设置或通过Get-config消息查询交换机上的配置信息，交换机需要通过Config-reply消息做出应答 |
|
Modify-State |
控制器通过Port-mod消息用来管理端口状态，通过Flow-mod消息增删交换机的流表项 |
|
Read-State |
当控制器需要统计信息时，会向交换机发送相关的Request消息以进行信息的请求 |
|
Send-Packet |
通过 Packet-out 消息封装好数据分组传给 OF 交换机；并在该消息中指定特定的动作表指导交换机处理这个数据分组，而不再进行流表的匹配除非动作表中包含转发到 TABLE的动作） |
|
Barrier |
确保之前下发的一些消息已经被交换机执行完毕，保证策略一致性 |
3.3.2 Asynchronous消息
用来将网络事件或交换机状态的变化更新到控制器。Asynchronous是“异步”的意思，也就是说这类消息的触发不是由于控制器的请求，而是由交换机主动发起的，控制器也不知道交换机什么时候会发送这类消息。SDN是集中式管控的架构，当交换机不知道该怎样处理流量，或者它的状态发生了改变又或者发生了一些异常的时候，OF交换机会通过这类消息将相应情况上报控制器，由控制器完成决策。这类消息主要包括以下4种子类型。
|
名称 |
说明 |
|
Packet-in |
收到的数据分组如果在流表中没有匹配项，或者匹配的流表项中给出了转发动作中指定端口为CONTROLLER的动作时， OF交换机会封装Packet-in消息把这个数据分组上交控制器。封装时，如果交换机本地的缓存足够，数据分组将被临时放在缓存中，它分组头中的控制信息（默认128 Byte）和在交换机缓存中的序号一同发给控制器，这个序号就是之前多次提到的buffer_id，控制器可以根据这个字段通过 Packet-out 消息处理缓存中的数据分组；如果交换机不支持本地缓存，或缓存容量不足则将整个数据分组封装进Packet-in消息发给控制器。往往“流”的首个数据分组会触发这类消息，也正是通过这个消息，控制器才能提取“流”的特征，以决定如何处理后续的流量。
|
|
Flow-Removed |
交换机中的流表项因为超时或修改等原因被删除掉的时候，会触发Flow-removed消息，前提是这条流表项在下发时flags字段置位了OFPFF_SEND_FLOW_REM。 |
|
Port-status |
交换机端口状态发生变化时（例如Up/Down），会触发Port-status消息报告端口的信息以及发生的状态变化（Add、Delete或者Modify）。 |
|
Error |
交换机通过Error消息来通知控制器发生的错误信息。 |
3.3.3 Symmetric消息
与前两类消息不同的是，Symmetric类的消息可由控制器或者OF交换机中的任意一侧发起，这类消息包括以下3种类型。
|
名称 |
说明 |
|
Hello |
认证通过后，双方通过握手消息 Hello 建立安全通道。该消息携带发送方支持的最高协议版本号，接收方将采用双方都支持的最低协议版本进行通信。一旦发现两者拥有共同支持的协议版本则建立安全通道，否则发送错误消息Hello-failed，描述失败原因，并终止连接。 |
|
Echo |
双方均可以主动向对方发出Echo-request消息，接收者需要回复Echo-reply。该消息用来保活，也可以测量延迟、带宽。 |
|
Vendor |
为未来的协议版本预留，以允许OF交换机厂商提供额外的OpenFlow功能。 |