P4 (programming language): Difference between revisions

Revision as of 23:46, 12 July 2017

Latest revision as of 14:09, 9 June 2025

(46 intermediate revisions by 29 users not shown)

Line 1:

{{Short description|Language for controlling network data forwarding}}

{{about|the programming language|the perforce version control system|Perforce|other uses|P4 (disambiguation)}}

{{more footnotes|date=May 2015}}

{{Multiple issues|

{{more footnotes|date=May 2015}}

{{Third-party|date=July 2019}}

}}

{{Infobox programming language

| name = P4

| logo = P4-logo.svg

| paradigm = [[compiled language|compiled]], [[Domain-specific language|___domain-specific]], [[imperative programming|imperative]]

| year = {{start date and age|2013}}

| developer = [[TheOpen P4Networking Language ConsortiumFoundation]]

| latest_release_version = version 1.0.2.5<ref>{{cite web|title=P4P416 languageLanguage specSpecification |url=httphttps://p4.org/wp-content/uploads/2024/10/P4-16-spec-v1.2.5.html |accessdate=713 AprilNovember 20152024}}</ref>

| latest_release_date = {{start date and age|df=yes|20152024|02|1710}}

| license = [[Apache Licence|Apache]]-style

| website = {{URL|httphttps://p4.org}}

| file_ext = .p4

}}

'''P4''' is a [[programming language]] designedfor to allow programming ofcontrolling [[Network packet|packet]] [[forwarding plane]]s in networking devices, such as routers and switches. In contrast to a general purpose language such as [[C (programming language)|C]] or [[Python (programming language)|Python]], P4 is a [[___domain-specific language]] with a number of constructs optimized aroundfor [[Packet forwarding|network data forwarding]]. P4 is andistributed as [[open Open-source software|open-source]], [[Permissive free software licence|permissively licensed]] languagecode, and is maintained by athe non-profitP4 organizationProject called(formerly the P4 Language Consortium. The language was originally described in), a SIGCOMM CCR paper in 2014 titled “Programming Protocolnot-Independent Packet Processors”<ref>{{cite web|url=http://www.sigcomm.org/node/3503|title=P4: Programming Protocolfor-Independentprofit Packetorganization Processors|date=Julyhosted 2014|accessdate=7 April 2015}}</ref> –by the alliterative[[Open nameNetworking shortens to “P4”Foundation]].

== History ==

== Language overview and design considerations ==

P4 was originally described in a 2014 [[Computer Communication Review|SIGCOMM ''CCR'']] paper titled “Programming Protocol-Independent Packet Processors”<ref>{{cite web

|url=https://dl.acm.org/doi/10.1145/2656877.2656890

|title=P4: Programming Protocol-Independent Packet Processors

|author1=P. Bosshart

|author2=D. Daly

|author3=G. Gibb

|author4=M. Izzard

|author5=N. McKeown

|author6=J. Rexford

|author7=C. Schlesinger

|author8=D. Talayco

|author9=A. Vahdat

|author10=G. Varghese

|author11=D. Walker

|date=July 2014

|work=[[Computer Communication Review]]

|access-date=9 June 2025

}}</ref>—the alliterative name shortens to "P4". The first P4 workshop took place in June 2015 at [[Stanford University]].<ref>{{cite web |title=1st P4 Workshop |url=https://p4.org/events/2015-06-04-p4-workshop/ |website=P4 Official Website |date=4 June 2015 |accessdate=1 August 2019}}</ref> An updated specification of P4, called P4-16, was released between 2016 and 2017,<ref name="P4-16">{{cite web |title=Specifications |url=https://p4.org/specs/ |website=P4 Official Website |accessdate=7 June 2022}}</ref> replacing P4-14, the original specification of P4.

==Design==

As the language is specifically targeted at packet forwarding applications, the list of requirements or design choices is somewhat unusualspecific to those use cases. The language is designed to meet a number of theseseveral goals:

===Target independence===

P4 programs are designed to be '''implementation-independent''', meaning: they can be compiled against many different types of execution machines such as general-purpose CPUs, [[Field-programmable gate array|FPGAs]], [[System on a chip|system(s)-on-chip]], network processors, and ASICs. These different types of machines are known as ''P4 '''targets''', and each target must be provided along with a [[compiler]] that maps the P4 source code into a target switch model. The compiler may be embedded in the target device, an externally running software, or even a cloud service. As many of the initial targets for P4 programs were used for simple packet switching it is very common to hear the term “P4"P4 switch”switch" used, even though “P4"P4 target”target" is more formally correct.

P4 programs are designed to be '''implementation-independent''', meaning they can be compiled against many different types of execution machines such as general-purpose CPUs, FPGAs, system(s)-on-chip, network processors, and ASICs. These different types of machines are known as P4 '''targets''', and each target must be provided along with a [[compiler]] that maps the P4 source code into a target switch model. As many of the initial targets for P4 programs were used for simple packet switching it is very common to hear the term “P4 switch” used, even though “P4 target” is more formally correct.

===Protocol independence===

P4 is designed to be '''protocol-independent''', meaning that: the language has no native support even for even common protocols such as IP, Ethernet, TCP, [[Virtual Extensible LAN|VxLAN]], or [[Multiprotocol Label Switching|MPLS]]. Instead, the P4 programmer describes the header formats and field names of the required protocols in the program, which are in turn interpreted and processed by the compiled program and target device.

===Reconfigurability===

Protocol independence and the abstract language model allow for '''reconfigurability''' – P4reconfigurability–P4 targets should be able to change the way they process packets (perhaps multiple times) after they are deployed. This capability is traditionally associated with forwarding planes built on [[History of general-purpose CPUs|general-purpose CPUs]] or [[network processor]]s, rather than the fixed function [[Application-specific integrated circuit|ASICs]]. Although within the language there is nothing to prevent a given target from optimizing around a certain set of protocols, these optimizations are invisible to the language author and may ultimately reduce the system’ssystem's flexibility and reconfigurability goals.

==Components==

Protocol independence and the abstract language model allow for '''reconfigurability''' – P4 targets should be able to change the way they process packets (perhaps multiple times) after they are deployed. This capability is traditionally associated with forwarding planes built on [[History of general-purpose CPUs|general-purpose CPUs]] or [[network processor]]s, rather than the fixed function [[Application-specific integrated circuit|ASICs]]. Although within the language there is nothing to prevent a given target from optimizing around a certain set of protocols, these optimizations are invisible to the language author and may ultimately reduce the system’s flexibility and reconfigurability goals.

P4 programs typically have the following components:

===Parsing logic===

==Match-Action processing==

P4 allows the specification of custom packet header parsing logic<ref name="P4-16"/> including but not limited to parsing typical headers used in the TCP/IP protocol suite and application specific headers.

Fundamental to P4 is the concept of '''match-action pipelines'''. Conceptually, forwarding network packets or frames can be broken down into a series of table lookups and corresponding header manipulations. In P4 these manipulations are known as “actions” and generally consist of things such as copying byte fields from one ___location to another based on the lookup results on learned forwarding state. P4 addresses only the data plane of a packet forwarding device, it does not specify the control plane nor any exact protocol for communicating state between the control and data planes. Instead, P4 uses the concept of tables to represent forwarding plane state. An interface between the control plane and the various P4 tables must be provided to allow the control plane to inject/modify state in the program. This interface is generally referred to as the “program API”.

==Language components==

===Headers===

Header definitions describe packet formats and provide names for the fields within the packet. The language allows customized header names and fields of arbitrary length, although many header definitions use widely known protocol names and fields widths. For example, an [[IEEE 802.3|802.3]] Ethernet header definition might be called “Ethernet” and consist of the a 48-bit field named “dest” followed by a 48-bit “src” field, followed by a 16-bit “type” field. The names in a header definition are used later in the P4 program to reference these fields.

Header definitions describe packet formats and provide names for the fields within the packet. The language allows customized header names and fields of arbitrary length, although many header definitions use widely known protocol names and fields widths. For example, an [[IEEE 802.3|802.3]] Ethernet header definition might be called “Ethernet” and consist of the a 48-bit field named “dest” followed by a 48-bit “src” field, followed by a 16-bit “type” field. The names in a header definition are used later in the P4 program to reference these fields.

===Parsers===

The P4 '''parser''' is a finite state machine that walks an incoming byte-stream and extracts headers based on the programmed parse graph. A simple example would be a parser that extracts the Ethernet source and destination and type fields, then performs a further extraction based on the value in the type field (common values might be ipv4, ipv6, or MPLS).

===Stateful processing===

The P4 '''parser''' is a finite state machine that walks an incoming byte-stream and extracts headers based on the programmed parse graph. A simple example would be a parser that extracts the Ethernet source and destination and type fields, then performs a further extraction based on the value in the type field (common values might be ipv4, ipv6, or MPLS).

P4 allows the programmer to maintain state in the form of registers, counters and meters.<ref name="P4-16"/>

===Generic match action tables===

===Tables===

The primary component of a P4 program is a set of user-defined match action tables. P4 treats all match action tables as generic, leaving the user to add their match-action rules via the control plane.<ref name="P4-16"/>

====Match-Actionaction processing====

P4 '''tables''' contain the state used to forward packets. Tables are composed of lookup keys and a corresponding set of actions and their parameters. A trivial example might be to store a set of destination MAC addresses as the lookup keys, and the corresponding action could set the output port on the device, and/or increment a counter. Tables and their associated actions are almost always chained together in sequence to realize the full packet forwarding logic, although in the abstract it is possible to build a single table that includes all the lookup key information and the full output action set.

Fundamental to P4 is the concept of '''match-action pipelines'''. Conceptually, forwarding network packets or frames can be broken down into a series of table lookups and corresponding header manipulations. In P4 these manipulations are known as “actions”''actions'' and generally consist of things such as copying byte fields from one ___location to another based on the lookup results on learned forwarding state. P4 addresses only the data plane of a packet forwarding device,. itIt does not specify the control plane nor any exact protocol for communicating state between the control and data planes. Instead, P4 uses the concept of tables to represent forwarding plane state. An interface between the control plane and the various P4 tables must be provided to allow the control plane to inject/modify state in the program. This interface is generally referred to as the “program''program API”API''.

===Actions=Tables====

P4 '''tables''' contain the state used to forward packets. Tables are composed of lookup keys and a corresponding set of actions and their parameters. A trivial example might be to store a set of destination MAC addresses as the lookup keys, and the corresponding action could set the output port on the device, and/or increment a counter. Tables and their associated actions are almost always chained together in sequence to realize the full packet forwarding logic, although in the abstract it is possible to build a single table that includes all the lookup key information and the full output action set.

====Actions====

'''Actions''' in P4 describe packet field and [[metadata]] manipulations. In P4 context, metadata is information about a packet that is not directly derived from the parser, such as the input interface that the frame arrived on. English descriptions of an example action might be “decrement"decrement the IPv4 [[Time to live|TTL]] field by one”one" or “copy"copy the MAC address from the output port table into the outgoing packet header.” "<ref>{{cite web |url=http://maillists.p4.org/pipermail/p4-dev_p4.org/ |title=P4 developersMailing mailingLists list|date=July 2015 |accessdate=15 July 2015}}</ref> P4 defines both standard metadata that must be provided by all targets as well as target-specific metadata, which is provided by the author of specific targets.

===Control Flow===

===Control Flow=flow==

The control flow in P4 determines the relative sequence of tables, and allows for [[Conditional (computer programming)|conditional execution]] of tables based on if/then/else constructions.

==References==

{{reflist}}

==External links==

* {{Official website|http://p4.org}}

==References==

{{reflist}}

[[Category:Computer networking]]