没有合适的资源?快使用搜索试试~ 我知道了~
首页可编程交换机p4语法文档.pdf
资源详情
资源评论
资源推荐
The P4 Language Specification
Version 1.0.3
November 2, 2016
The P4 Language Consortium
1 Introduction
P4 is a declarative language for expressing how packets are processed by the pipeline
of a network forwarding element such as a switch, NIC, router or network function ap-
pliance. It is based upon an abstract forwarding model consisting of a parser and a set
of match
+
action table resources, divided between ingress and egress. The parser iden-
tifies the headers present in each incoming packet. Each match
+
action table performs
a lookup on a subset of header fields and applies the actions corresponding to the first
match within each table. Figure 1 shows this model.
P4 itself is protocol independent but allows for the expression of forwarding plane pro-
tocols. A P4 program specifies the following for each forwarding element.
• Header definitions: the format (the set of fields and their sizes) of each header
within a packet.
• Parse graph: the permitted header sequences within packets.
• Table definitions: the type of lookup to perform, the input fields to use, the actions
that may be applied, and the dimensions of each table.
• Action definitions: compound actions composed from a set of primitive actions.
• Pipeline layout and control flow: the layout of tables within the pipeline and the
packet flow through the pipeline.
P4 addresses the configuration of a forwarding element. Once configured, tables may
be populated and packet processing takes place. These post-configuration operations
are referred to as "run time" in this document. This does not preclude updating a for-
warding element’s configuration while it is running.
1.1 The P4 Abstract Model
The following diagram shows a high level representation of the P4 abstract model.
The P4 machine operates with only a few simple rules.
© 2014-2016, The P4 Language Consortium
1.1 The P4 Abstract Model 1 INTRODUCTION
Figure 1: Abstract Forwarding Model
• For each packet, the parser produces a Parsed Representation on which match
+
action tables operate.
• The match
+
action tables in the Ingress Pipeline generate an Egress Specification
which determines the set of ports (and number of packet instances for each port)
to which the packet will be sent.
• The Queuing Mechanism processes this Egress Specification, generates the nec-
essary instances of the packet and submits each to the Egress Pipeline. Egress
queuing may buffer packets when there is over-subscription for an output port,
although this is not mandated by P4.
• A packet instance’s physical destination is determined before entering the Egress
Pipeline. Once it is in the Egress Pipeline, this destination is assumed not to
change (though the packet may be dropped or its headers further modified).
• After all processing by the Egress Pipeline is complete, the packet instance’s header
is formed from the Parsed Representation (as modified by match
+
action process-
ing) and the resulting packet is transmitted.
Although not shown in this diagram, P4 supports recirculation and cloning of packets.
This is described in detail in Section 14.
2
1.2 The mTag Example 1 INTRODUCTION
P4 focuses on the specification of the parser, match
+
action tables and the control flow
through the pipelines. Programmers control this by writing a P4 program which speci-
fies the switch configuration as shown at the top of Figure 1.
A machine that can run a P4 program is called target. Although a target may directly
execute a P4 program, it is assumed in this document that the program is compiled
into a suitable configuration for the target.
In the current version, P4 does not expose, for example, the functionality of the Queu-
ing Mechanism and does not specify the semantics of the Egress Specification beyond
what is mentioned above. Currently they are defined in target specific input to the
compiler and exposed in conjunction with other interfaces that provide run time sys-
tem management and configuration. Future versions of P4 may expose configuration
of these mechanisms allowing consistent management of such resources from the P4
program.
1.2 The mTag Example
The original P4 paper [1] includes an example called mTag. We use this example through-
out this specification as a means of explaining the basic language features as they are
presented. Complete source for this example, including sample run-time APIs, is avail-
able at the P4 web site [2].
We give an overview of the mTag example here. Quoting from the original paper:
Consider an example L2 network deployment with top-of-rack (ToR) switches
at the edge connected by a two-tier core. We will assume the number of
end-hosts is growing and the core L2 tables are overflowing. . . . P4 lets us
express a custom solution with minimal changes to the network architec-
ture. . . . The routes through the core are encoded by a 32-bit tag composed
of four single-byte fields. The 32-bit tag can carry a "source route".... Each
core switch need only examine one byte of the tag and switch on that infor-
mation. [1]
Two P4 programs are defined for this example: One for edge switches (called "ToR"
above) and one for aggregation switches (called "core switches" above). These two pro-
grams share definitions for packet headers, the parser and actions.
1.3 P4 Abstractions
P4 provides the following abstractions. A P4 program consists of instances of each.
• Header type: A specification of fields within a header.
• Header instance: A specific instance of a packet header or metadata.
3
1.4 Structure of the P4 Language 1 INTRODUCTION
• Parser state function: Defines how headers are identified within a packet.
• Action function: A composition of primitive actions that are to be applied to-
gether.
• Table instance: Specified by the fields to match and the permitted actions.
• Control flow function: Imperative description of the table application order.
• Stateful memories: Counters, meters and registers which persist across packets.
In addition to these high level abstractions, the following are used
• For a header instance:
– Metadata: Per-packet state which may not be derived from packet data.
Otherwise treated the same as a packet header.
– Header stack: a contiguous array of header instances.
– Dependent fields: Fields whose values depend on a calculation applied to
other fields or constants.
• For a parser:
– Value set: run-time updatable values used to determine parse state transi-
tions.
– Checksum calculations: The ability to apply a function to a set of bytes from
the packet and test that a field matches the calculation.
1.4 Structure of the P4 Language
This section (work in progress) provides a brief overview of the structure of the P4 lan-
guage.
The P4 language uses a flat typing structure, inferring types for most function param-
eters. In general each P4 level declaration has its own namespace, though potential
ambiguities are identified in the spec.
Constant values can be expressed in P4 in binary, decimal and hexadecimal. Base spec-
ifications 0x and 0b are used to indicate binary and hexadecimal respectively.
It is sometimes necessary to indicate the number of bits that should be used to repre-
sent the value. P4 allows this by means of a width indication preceding the base speci-
fication. See Section 1.5.1 below.
P4 allows value expressions with operators so long as they can be evaluated at compile
time.
4
1.5 Specification Conventions 1 INTRODUCTION
1.5 Specification Conventions
This document represents P4 grammatical constructs using BNF with the following
conventions:
• The BNF is presented in green boxes.
• Terminal nodes are indicated with bold.
• A node with a name ending in _name is implicitly a string whose first character is
a letter (not a digit).
• Nodes followed by + indicate one or more instances.
• Nodes followed by
*
indicate zero or more instances.
• A vertical bar, |, separates options from which exactly one must be selected.
• Square brackets, [], are used to group nodes. A group is optional unless it is fol-
lowed by +. A group may be followed by * indicating zero or more instances of the
group.
• Symbols with special significance (e.g., [ ]
*
+ |) may be used as terminal nodes
by enclosing them in quotes: for example "
*
".
• Symbols other than those listed above are literals. Examples include curly braces,
colon, semi-colon, parentheses, and comma.
• If a rule does not fit on one line, a new line immediately follows ::= and the de-
scription ends with a blank line.
• Examples code appears in blue boxes to differentiate them more clearly from BNF
rules.
• To emphasize those locations where a field width is indicated (the width of the
value’s representation may matter), the node field_value is used. This is a syn-
onym for any other constant value, const_value.
Header types and table definitions are specified declaratively. These typically consist of
a set of attribute/value pairs separated by a colon.
Parsers, actions and control flow are specified imperatively with untyped parameters (if
any) and a limited set of operations.
1.5.1 Value Specifications
As noted above in Section 1.4, P4 supports generic and bit-width specific values. These
are unified through the following representation.
5
剩余96页未读,继续阅读
maotoula
- 粉丝: 68
- 资源: 26
上传资源 快速赚钱
- 我的内容管理 收起
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
会员权益专享
最新资源
- c++校园超市商品信息管理系统课程设计说明书(含源代码) (2).pdf
- 建筑供配电系统相关课件.pptx
- 企业管理规章制度及管理模式.doc
- vb打开摄像头.doc
- 云计算-可信计算中认证协议改进方案.pdf
- [详细完整版]单片机编程4.ppt
- c语言常用算法.pdf
- c++经典程序代码大全.pdf
- 单片机数字时钟资料.doc
- 11项目管理前沿1.0.pptx
- 基于ssm的“魅力”繁峙宣传网站的设计与实现论文.doc
- 智慧交通综合解决方案.pptx
- 建筑防潮设计-PowerPointPresentati.pptx
- SPC统计过程控制程序.pptx
- SPC统计方法基础知识.pptx
- MW全能培训汽轮机调节保安系统PPT教学课件.pptx
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
评论0