作为用户，从 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.