2. 数据平面与控制平面分离
传统交换机的转发决策与转发执行是耦合在同一台设备内部的：控制协议（如生成树、OSPF、BGP）计算出路径，转发表由控制逻辑写入，数据包再按表转发。SDN 的核心变化是把这两件事拆开——控制平面负责“决定怎么转发”，数据平面只负责“按既定规则转发”。OpenFlow 就是实现这种分离的第一个标准化南向接口协议，它规定了控制器与交换机之间如何交换流表、如何下发规则、如何上报事件。
一、OpenFlow 的基本角色与通道
在 OpenFlow 架构中，一台 OpenFlow 交换机（或支持 OpenFlow 的软件交换机，如 Open vSwitch）内部至少包含三部分：流表（Flow Table）、安全通道（Secure Channel）和组表/计量表（Group/Meter Table）。控制器通过安全通道与交换机建立 OpenFlow 会话，默认使用 TCP 6653 端口（早期规范为 6633）。会话建立后，双方通过 OpenFlow 消息交互，主要分为三类：
- Controller-to-Switch：控制器主动下发，如
OFPT_FLOW_MOD（增删改流表）、OFPT_PACKET_OUT（指定端口发出报文）、OFPT_STATS_REQUEST（查询统计）。 - Asynchronous：交换机主动上报，如
OFPT_PACKET_IN（未匹配报文上送控制器）、OFPT_FLOW_REMOVED（流表项老化删除）、OFPT_PORT_STATUS（端口状态变化）。 - Symmetric：双向对等消息，如
OFPT_HELLO（版本协商）、OFPT_ECHO_REQUEST/REPLY（保活探测）。
其中 PACKET_IN 与 FLOW_MOD 的配合，构成了 SDN 最典型的“首包上送—控制器决策—下发流表—后续报文线速转发”闭环。理解这条闭环，是理解控制与转发分离的关键。
二、流表结构：多级流水线与匹配字段
OpenFlow 1.3 之后，交换机内部采用多级流表（Multi-Stage Pipeline）结构。每个流表由若干流表项（Flow Entry）组成，一条流表项包含六个核心部分：
| 组成部分 | 作用 | 示例 |
|---|---|---|
| 匹配字段 Match Fields | 定义该表项匹配哪些报文特征 | 入端口=1，目的MAC=00:00:00:00:00:02，以太类型=0x0800 |
| 优先级 Priority | 同表内多条匹配时的选择依据，数值大者优先 | 100 |
| 计数器 Counters | 统计匹配报文数与字节数 | packet_count=1520 |
| 指令 Instructions | 匹配后执行的动作集合 | apply_actions: output:2 |
| 超时 Timeouts | 空闲/硬超时，到期删除表项 | idle_timeout=30s |
| Cookie | 控制器用于标识表项的不透明值 | 0x0000000000000001 |
匹配字段在 OpenFlow 1.3 中已扩展到 40 余项，涵盖二到四层：入端口、源/目的 MAC、以太类型、VLAN ID、源/目的 IP、IP 协议号、TCP/UDP 端口等。需要特别注意的是，OpenFlow 的匹配是精确匹配与通配匹配并存的：未指定的字段视为“任意”，即通配。这与传统路由表的最长前缀匹配逻辑不同，因此优先级字段成为决定匹配结果的关键。
三、匹配与动作机制
报文进入交换机后，从流表 0 开始依次经过流水线。每个流表内的匹配过程是：按优先级从高到低查找第一条匹配成功的表项；若匹配成功，执行其指令集；若未匹配，则执行Table-Miss表项。Table-Miss 表项通常优先级为 0、匹配字段全通配，其指令决定未匹配报文的归宿：上送控制器（CONTROLLER）、丢弃（无指令）、或转到下一张表。
动作分为两类：Apply-Actions 立即执行动作列表，Write-Actions 将动作写入动作集，待流水线结束后统一执行。常见动作包括：
OUTPUT:port：从指定端口发出，可指定物理端口、逻辑端口或CONTROLLER、FLOOD、ALL。DROP：丢弃报文（无输出动作即丢弃）。SET_FIELD：修改报文字段，如改写目的 MAC、VLAN ID、目的 IP。PUSH_VLAN / POP_VLAN：压入或弹出 VLAN 标签。GROUP：交给组表处理，实现组播、负载均衡、快速重路由。
下面这张图展示了一个典型的 OpenFlow 1.3 多级流表处理路径：报文从端口进入，经 Table 0 匹配后可能直接转发、上送控制器，或跳转到 Table 1 继续匹配，最终由动作集统一执行输出。
四、分离架构对网络设备与转发行为的影响
控制与转发分离后，网络设备的角色发生了根本变化。传统交换机需要运行复杂的控制协议、维护全局拓扑视图、参与分布式路由计算；OpenFlow 交换机则退化为一个“可编程的转发执行器”，它不再自主决策，只忠实执行控制器下发的流表。这带来几个直接影响：
第一，转发行为由控制器集中定义。同一台交换机在不同控制器策略下可以表现出完全不同的转发行为——今天作为二层交换机，明天作为防火墙，后天作为负载均衡器。设备本身不需要更换硬件或升级固件，只需更换流表。
第二，转发路径可全局优化。传统分布式协议中，每台设备只掌握局部信息，容易产生次优路径。控制器拥有全局拓扑和链路状态，可以计算出端到端最优路径，并通过逐跳下发流表实现。例如，控制器可以指定流量走 A→B→D 而非 A→C→D，即使 C 路径在传统协议下更短。
第三，转发行为可细粒度控制。流表匹配字段可以精确到 TCP 端口、VLAN、甚至 MPLS 标签，因此控制器可以实现基于应用、用户、业务的差异化转发策略，而传统设备通常只能基于目的 IP 前缀转发。
第四，设备复杂度下降，但控制器成为关键节点。交换机不再需要运行 BGP、OSPF 等复杂协议栈，硬件成本降低；但控制器一旦失联，交换机只能依赖已有流表继续转发，无法学习新路径。因此实际部署中通常需要控制器集群和带外管理网络来保证可靠性。
ovs-ofctl dump-flows br0 查看当前流表，ovs-ofctl add-flow br0 "priority=100,ip,nw_dst=10.0.0.2,actions=output:2" 手动添加一条流表项。观察 PACKET_IN 是否触发，可以判断 Table-Miss 表项是否配置正确。
需要强调的是，OpenFlow 只是控制平面与数据平面之间的接口之一，它并不规定控制器内部如何计算路径，也不规定网络操作系统如何实现。理解 OpenFlow 的流表匹配与动作机制，是理解整个 SDN 转发行为的基础；而理解分离架构对设备角色的重塑，则是理解 SDN 为什么能带来网络可编程性的关键。