作為用戶，從 P4 程序開始。
使用編譯器生成特定於目標的配置 blob。 - BMv2 中的 test.json
編譯器還會生成一個名為 P4Info 的特殊文件，在運行時安裝表條目時需要該文件
啟動處於這種狀態的交換機不知道如何處理數據包，因為還沒有加載 P4 程序
使用 P4Runtime 靜態控制器，安裝在 runtime.json 文件中指定的流規則
通過 linux 虛擬接口連接 mininet 主機來啟動網絡
此外，BMv2 還提供調試和日志記錄功能。
in pseudocode
P4C_ARGS = --p4runtime-file $(basename $@).p4info
--p4runtime-format text
RUN_SCRIPT = ../../utils/run_exercise.py
TOPO = topology.json
dirs:
mkdir -p build pcaps logs
build: for each P4 program, generate BMv2 json file
p4c-bm2-ss --p4v 16 $(P4C_ARGS) -o $@ $<
run: build, then [default target]
sudo python $(RUN_SCRIPT) -t $(TOPO)
stop: sudo mn -c
clean: stop, then
rm -f *.pcap
rm -rf build pcaps logs
step1
使用各種flag調用編譯器以創建 JSON 配置和 P4Info 文件
step2 run_exercise.py
(1)根據拓撲topology.json構建網絡
(2)stast
simple_switch_grpc
(3)使用P4Runtime 進行P4程序（P4Info和BMv2 JSON）
(4)增加在runtime.json中定義的靜態規則
step3 運行流量生成器和監測器
send.py and receive.py（some exercises）
or
ping（like Linux programs）
in P4 use：mycontroller.py
Runtime對P4數據平面的控制
綠色:用戶定義
橙色：供應商提供
一旦准備好控制平面和數據平面，我們就需要一種機制讓它們通信和支持相同的協議。
runtime控制已實現的方法
1）P4編譯器自動生成runtime APIs（C++ APIs）用於增加/刪除規則
如果P4程序改變了，API也需要更改，然后我們需要重啟controller
2）BMv2 CLI 目標非獨立性，P4程序獨立性
P4程序更變的情況下無需更變BMv2 CLI
但是，此 API 綁定到特定目標 - BMv2，無法移植到其他目標。
3）OpenFlow
OpenFlow 是獨立於目標的，它不依賴於底層目標和架構。 您=可以對軟件交換機或來自多個供應商的硬件交換機使用相同的協議
然而，OpenFlow 支持的協議集是內置的，擴展它並非易事。
例如，基本隧道示例，OpenFlow 將無法支持新的表頭字段。
4）OCP Switch Abstraction Interface（SAI） 目標獨立性，協議非獨立性
runtime control API 的特性
P4Runtime希望能實現一個目標獨立、協議獨立的控制平面API
P4Runtime
1）是P4目標運行時的控制框架
2）基於 Protobuf 的 API 定義
gRPC 作為默認傳輸機制
3）獨立於P4程序
4）實現可重構（在不重編譯交換機的軟件棧情況下，更新P4程序）
Protocol Buffers Basics
gRPC Basics
使用 Protocol Buffers 定義服務 API 和消息
根據HTTP/2.0 以及TLS進行傳輸
支持雙向流的高效單向 TCP 連接實現
gRPC Service Example
P4Runtime 服務
使本地或遠程實體能夠加載管道/程序、發送/接收數據包以及讀寫轉發表條目、計數器和其他芯片功能。
P4Runtime Write Request
Runtime 表條目
若要新增一個表條目，控制平面需要知道
1）P4條目的id
Tables，field matched, actions, params,etc
2）字段匹配
Match type, bitwidth etc
3)特定action的參數
4）其他 P4 課程屬性
P4Runtime語法以Protobuf格式定義
（protobuf全稱Google Protocol Buffers，是google開發的的一套用於數據存儲，網絡通信時用於協議編解碼的工具庫。）
arbitration仲裁：指P4Runtime確定在任何時間，只有一個給定主控制器有寫權限，也被稱作“client arbitration”
client
The gRPC client is the software entity which controls the P4 target or device by communicating
with the gRPC agent or server. The client may be local (within the device) or remote (for example,
an SDN controller).
grpc：A high-performance, open-source universal RPC framework
所謂RPC(remote procedure call 遠程過程調用)框架實際是提供了一套機制，使得應用程序之間可以進行通信，而且也遵從server/client模型。使用的時候客戶端調用server端提供的接口就像是調用本地的函數一樣。
entity
實例化的 P4 程序對象，例如表或外部
p4info
Metadata which specifies the P4 entities which can be accessed via P4Runtime. These entities have a one-for-one correspondence with instantiated objects in the P4 source code
protobuf
P4Runtime 的有線序列化格式，用於定義P4Runtime接口
server
在設備或目標上接受 P4Runtime 請求的 gRPC 服務器。它使用工具將P4Runtime API的調用轉換為用於特定目標的操作
target
“執行” P4 pipeline並運行 P4Runtime 服務的硬件或軟件實體；
P4Runtime Reference Architecture
The P4Runtime API defines the messages and semantics of the interface between the client(s) and the server. The API is specified by the p4runtime.proto Protobuf file
控制器可以訪問在 P4Info 元數據中聲明的 P4 實體。
P4Info結構由 p4info.proto 定義，這是標准中提供的另一個 Protobuf 文件
P4Runtime API 由運行 gRPC 服務器的程序實現，這個服務器綁定了一個自動生成的 P4Runtime 服務接口。
控制器可以在沒有P4源程序的情況下運行，因為因為 P4Info 文件提供了描述 P4Runtime API 所需的所有信息
雖然P4程序可以呈現出對數據平面行為的精確描述，但是這在編寫控制平面軟件時是不必要的，在一些情況下，控制平面軟件開放商擁有控制平面的API和就足夠了，並且一些開發商不希望將p4源代碼公開，因而P4Info文件便為此提供了便利，一個controller可以加載P4info文件，呈現出正確的P4RuntimeAPI
P4Runtime 接口允許多個客戶端（即控制器）連接到 P4Runtime
服務器同時在設備上運行：
原因如下：
1）控制平面的分區：多個控制器可能具有正交、非重疊的“roles”（領域）且應能夠同時發送P4條目。
一個控制平面可以被划分成很多個領域，在每個領域中可能有很多controllers，其中之一是主要的，其他的則為備份
2）冗余和容錯：支持多個控制器允許擁有一個或多個備用備份控制器，他們可能已連接好，便於能夠快速的編程Primary控制器。
嵌入式加兩個遠程高可用性控制器
為了支持多個控制器，P4Runtime使用流式通道（可通過 StreamChannel 獲得
RPC) 用於會話管理。 工作流程描述如下：
·每一個控制器可以加入>=1個領域（roles），s. For each
(device_id, role), the control This election_id can be the same forler receives an election_id，different roles and/or devices, as long as the tuple (device_id, role, election_id) is unique.