Openflow的思路很简单，网络设备维护一个FlowTable并且只按照FlowTable进行转发，Flowtable本身的生成、维护、下发完全由外置的Controller来实现，注意这里的FlowTable并非是指IP五元组，事实上OpenFlow 1.0定义的了包括端口号、VLAN、L2/L3/L4信息的10个关键字，但是每个字段都是可以通配的，网络的运营商可以决定使用何种粒度的流，比如运营商只需要根据目的IP进行路由，那么流表中就可以只有目的IP字段是有效的，其它全为通配。
这种控制和转发分离的架构对于L2交换设备而言，意味着MAC地址的学习由Controller来实现，V-LAN和基本的L3路由配置也由Controller下发给交换机。对于L3设备，各类IGP/EGP路由运行在Controller之上，Controller根据需要下发给相应的路由器。流表的下发可以是主动的，也可以是被动的，主动模式下，Controller将自己收集的流表信息主动下发给网络设备，随后网络设备可以直接根据流表进行转发;被动模式是指网络设备收到一个报文没有匹配的FlowTable记录时，将该报文转发给Controller，由后者进行决策该如何转发，并下发相应的流表。被动模式的好处是网络设备无需维护全部的流表，只有当实际的流量产生时才向Controller获取流表记录并存储，当老化定时器超时后可以删除相应的流表，故可以大大节省TCAM空间。当一个Controller同时控制多个交换机/路由器设备时，它们看起来就像一个大的逻辑交换机，各个交换机/路由器硬件就如同这个逻辑网络设备的远程线卡，类似的概念Cisco称之为nV(Network Virtualization)技术。
OpenFlow 1.0的流表分为Match Fields、计数器和指令集三个部分，Match Fields是报文匹配的输入关键字，计数器是管理所需，指令集是决定报文如何转发，最基本的转发行为包括转发给某个端口、封装改写报文后转发以及丢弃。 OpenFlow 1.1增加了对MPLS以及UDP/SCTP传输层协议的支持，同时针对流表开销过大的情况设计了多级流表，并增加分组策略功能。
Openflow的推广除了面临上一章所述的产业博弈的问题外，目前还面临着一些技术的难点。其中之一就是路由器/交换机中广为使用的快速查找TCAM 存储器成本的问题。在传统设备中，需要采用TCAM的表包括FIB、MAC、MPLS Lable和ACL表，每个表的匹配字段长度不一，分开设计，并且设计了最大容量，以期达到最小的开销。而在Openflow设备中，不再区分匹配长度短的FIB、MAC、MPLS Lable表以及较长的ACL表，一律采用最大长度的FlowTable记录代替，对于OpenFlow1.0而言，Flow table的匹配字段长度长达252比特，而一般IPV4 RIB TCAM匹配字段长度只有60-80个比特，开销增加了3倍以上，而对于路由器的线卡而言，TCAM成本占了约20-30%，功耗也占了很大一部分。因此如何减少FlowTable尺寸将是OpenFlow体系面临的一个极大问题，此外，TCAM体系下FlowTable记录的动态插入算法将更为复杂。
OpenFlow1.1设计了多级流表来减少Flowtable的开销，将流表进行特征提取，分解成多个步骤，形成流水线处理形式，从而降低总的流表记录条数，比如原始流表共有10000条，分解成先匹配VLAN+MAC，再匹配IP和传输层头部的两个独立流表，每个流表的数量可能均小于1000条，使得流表总数小于2000条。但流水线式架构使得匹配时延增加，而且流量的生成、维护算法复杂度提高，至今也未见到针对真实网络的效果评估报告。
OpenFlow的关键是通过OpenFlow将网络转发的原子操作抽象出来，并以流表来驱动流程，我们所论述的一切好处是建立在OpenFlow FlowTable能够很好地将Primitive和WorkFlow抽象，支持设计新的协议在大部分情况下的确可以通过只修改Controller的逻辑来实现这一假定上。在OpenFlow最初应用的Switch领域，OpenFlow已经有杀鸡用牛刀的嫌疑了。但是路由网络，尤其是包含有大量用户控制逻辑的边界路由器，如BRAS、无线网络的GGSN/PDSN/xGW等设备，OpenFlow需要扩展将用户控制逻辑抽象为原子操作和流程，那可能已经不适合叫FlowTable，叫AccessControlTable更合适，转发操作本身的匹配规则、转发操作中也需要增加对现存的各种接入协议和表征接入会话的协议字段的支持，比如PPPoE、GTP-U、PDP激活操作的匹配和转发封装支持。