Reference:

Introduction

• SDN

SDN 給予 operators (運營商？) 對網路的程式化控制。
在SDN control 與 forward 分開，一個 control 控制多個 轉發設備。

而 轉發設備可以不同方式程式化，擁有 common，open，vendor-agnostic interface(OpenFlow)的特性。
使得 控制層 控制 來自不同軟硬供應商的轉發設備。

• OpenFlow 2.0 API

從 OF 1.0 ~ OF 1.4 可以發現 Header Fields 數量增加，為了因應需求。
像是 data-center 網路運營商想要使用新型封包的封裝(encapsulation)
ex: NVGRE,VXLAN,and STT <-- 嗯...我都不懂
但是 這也增加了 處理的複雜性。

不想增加複雜性又想 在 switch 部署 新功能。
sol -->
future switches 支援
對於解析封包和匹配表頭欄位的彈性機制、
允許控制器的應用程式透過OpenFlow 2.0 API 利用這些功能。

比起 OpenFlow 1.x 的好處
simpler,more elegant,more future-proof(?)

• 速率的提升
  在 custom ASICs (switch chip) 可以達到 terabit speed 。
  但是呢 ... 程式化 硬體 相當難。
  因此 P4 登場 : 抽象化 編程網路 ~~~ 變相對簡單。

圖解:
P4 : configure a switch :: 告訴 switch 如何處理封包。
existing APIs (OpenFlow) : populate the forwarding tables。

有了 P4 將 不再設限於固定的 switch 設計 ！

Abstract Forwarding Model

• 運作
  在抽象模型中，Switch 經由可編程的Parser 轉送封包，再由 多個階段 match+action 以串聯，並聯或組合方式處理。

• 三個概括
  

--> 在不同轉發設備(負載平衡,路由器,Ethernet switches) 都可適用。 <-- 因為有compiler的幫忙
適用於 slow software switches to the fastest ASIC-based switches 。

• 兩個操作

1. Configure
   Program the parser
   set the order of match+action stages
   specify the header fields processed by each stage

2. Populate

• add(remove) entries to the match+action tables
• determine the policy applied to packets

--> 模型有意達成在重新配置時也不中斷轉送

upgrade with no downtime