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激活操作的比對和轉發封裝支援。