📚 课程目录第1章 SDN与OpenFlow全景认知

1. SDN与OpenFlow全景认知

传统网络设备把控制逻辑和转发硬件焊死在同一台机器里：路由协议进程算出转发表，芯片按表转发，两者无法拆开。SDN（Software-Defined Networking，软件定义网络）做的第一件事，就是把这两件事在架构上分开——控制平面负责"怎么算路径、下发什么规则"，数据平面只负责"按规则把包从某个口送到某个口"。理解这一点，是理解后面所有控制器编程、流表下发、OpenFlow 消息交互的前提。

一、三层架构：应用、控制、数据

SDN 的经典参考架构自上而下分为三层，层与层之间通过明确接口通信：

应用层：承载业务意图，例如"财务网段与研发网段互访需经防火墙""视频流量优先转发"。应用不直接碰交换机，而是调用控制器提供的北向接口（REST API、编程语言绑定等）。
控制层：即 SDN 控制器，是全局网络的"大脑"。它维护全网拓扑、主机位置、链路状态，把应用意图翻译成设备可执行的转发规则，并通过南向接口下发。
数据层：由交换机、路由器等转发设备组成，只保留流表、组表、计量表等转发资源，按控制器下发的规则执行匹配与动作。

三层之间有两个关键接口：北向接口面向应用，抽象程度高、与具体硬件无关；南向接口面向设备，需要标准化，OpenFlow 就是其中最主流的一种。控制器位于中间，既是南向协议的"翻译官"，也是北向能力的"提供者"，这正是它在 SDN 中处于核心位置的原因。

二、OpenFlow 的定位：南向接口的事实标准

控制平面与数据平面分离后，两者之间必须有一套"共同语言"：控制器说"匹配目的 IP 为 10.0.0.5 的包，从端口 3 转发出去"，交换机要能听懂并执行。OpenFlow 就是这套语言的标准协议，由 ONF（Open Networking Foundation）维护，目前工程中广泛使用的是 OpenFlow 1.3。

OpenFlow 的核心抽象是流表（Flow Table）。一条流表项由三部分组成：

匹配域（Match Fields）：可匹配入端口、源/目的 MAC、源/目的 IP、TCP/UDP 端口、VLAN ID 等，OpenFlow 1.3 支持多级流表，匹配字段可跨表传递。
优先级（Priority）：数值越大越优先，多条表项匹配同一包时按优先级决定。
指令/动作（Instructions/Actions）：如 output 到某端口、drop 丢弃、set_field 修改字段、goto_table 跳转到下一张流表、group 做组播或负载均衡。

交换机收到包后，从流表 0 开始逐级匹配。若命中，执行对应动作；若未命中，默认行为通常是Packet-In——把包封装后上报控制器，由控制器决定是下发新流表还是丢弃。这条"未命中上报—控制器决策—下发流表"的闭环，是 SDN 可编程性的直接体现。

三、控制器为什么是核心

控制器不是简单的协议转换器，它承担了四类关键职责：

全局视图维护：通过 LLDP 等机制发现链路，通过 Packet-In 学习主机位置，形成全网拓扑图。没有全局视图，路径计算就无从谈起。
策略翻译：把应用层的"高优先级转发"翻译成具体的流表项，包括匹配字段、优先级、动作序列。
状态同步：监听交换机的端口状态变化、流表超时、链路故障，及时更新拓扑并重新计算路径。
资源抽象：向上提供统一的网络视图，屏蔽底层不同厂商设备的差异。

以开源控制器 Ryu 为例，一个最简单的"交换机接入即下发默认丢弃流表"的逻辑，核心代码大致如下：

from ryu.base import app_manager
from ryu.controller import ofp_event
from ryu.controller.handler import CONFIG_DISPATCHER, MAIN_DISPATCHER
from ryu.controller.handler import set_ev_cls
from ryu.ofproto import ofproto_v1_3

class SimpleSwitch(app_manager.RyuApp):
    OFP_VERSIONS = [ofproto_v1_3.OFP_VERSION]

    @set_ev_cls(ofp_event.EventOFPSwitchFeatures, CONFIG_DISPATCHER)
    def switch_features_handler(self, ev):
        datapath = ev.msg.datapath
        ofproto = datapath.ofproto
        parser = datapath.ofproto_parser
        # 默认流表：未命中则上报控制器
        match = parser.OFPMatch()
        actions = [parser.OFPActionOutput(ofproto.OFPP_CONTROLLER,
                                          ofproto.OFPCML_NO_BUFFER)]
        self.add_flow(datapath, 0, match, actions)

    def add_flow(self, datapath, priority, match, actions):
        ofproto = datapath.ofproto
        parser = datapath.ofproto_parser
        inst = [parser.OFPInstructionActions(
                    ofproto.OFPIT_APPLY_ACTIONS, actions)]
        mod = parser.OFPFlowMod(datapath=datapath, priority=priority,
                                match=match, instructions=inst)
        datapath.send_msg(mod)

这段代码展示了控制器与交换机交互的基本模式：交换机连接后触发 EventOFPSwitchFeatures，控制器构造 OFPFlowMod 消息下发流表。优先级 0 表示最低优先级，匹配所有包，动作是送到控制器。后续再根据 Packet-In 事件下发更精确的转发规则。

四、典型应用场景

SDN 的价值在需要"全局视角 + 动态调整"的场景中最明显：

数据中心网络：多租户隔离、虚拟机迁移时策略跟随、大二层互通。控制器可根据 VM 位置变化实时更新流表，避免手工改配置。
园区网策略集中管理：把 ACL、QoS 策略统一在控制器上定义，下发到所有接入交换机，减少逐台配置的不一致。
流量工程与负载均衡：根据链路利用率动态调整路径，把大象流调度到空闲链路。
网络实验与教学：Mininet + Ryu/ONOS 可以在单机上模拟完整拓扑，快速验证新协议和新算法。

学习建议：先跑通"Mininet 建拓扑 → Ryu 启动控制器 → 交换机连接 → 下发流表 → ping 通"这条最小链路，再逐步加入多级流表、组表、计量表等特性。不要一开始就陷入 OpenFlow 消息字段的细节，先建立"控制器决策、交换机执行"的整体直觉。

总结来看，SDN 的本质是控制与转发分离，OpenFlow 是连接两者的标准化南向协议，控制器则是承载全局逻辑、翻译业务意图、驱动设备转发的核心组件。三者构成一个闭环：应用提出需求，控制器计算并下发规则，交换机执行转发，状态变化再反馈回控制器。理解这个闭环，后续的流表编程、拓扑发现、路径计算才有落脚点。