P4 is a high-level language for programming protocol-independent packet processors. It works with SDN control protocols like OpenFlow. OpenFlow currently specifies a fixed set of header fields, which has grown from 12 to 41 fields, increasing complexity without flexibility. This paper proposes P4 as a solution for future OpenFlow evolution. The goals are: (1) reconfigurability in the field, (2) protocol independence, and (3) target independence. P4 allows programmers to describe packet processing independently of hardware specifics. An example shows how to use P4 to configure a switch to add a new hierarchical label. SDN provides programmatic control over networks, with the control plane separate from the forwarding plane. OpenFlow enables control over different hardware and software vendors. The OpenFlow interface started simple but has grown more complex over time, with more header fields and multiple stages of rule tables. New header fields continue to proliferate, requiring flexible mechanisms for parsing and matching. P4 offers a general, extensible approach, allowing controller applications to leverage capabilities through a common interface. Recent chip designs show that flexibility can be achieved in custom ASICs at terabit speeds. Programming these chips is complex, requiring a higher-level language like P4. P4 is designed to abstract the network programming level and serve as a general interface between the controller and switches. It allows the controller to define how switches operate, not just be constrained by fixed designs. P4's three main goals are reconfigurability, protocol independence, and target independence. The paper introduces an abstract forwarding model where switches forward packets via a programmable parser followed by multiple stages of match+action. This model generalizes packet processing in various devices and technologies. P4 is used to represent packet processing in terms of this model, enabling target-independent programs that can be mapped to different devices. The paper discusses the abstract forwarding model, which includes configure and populate operations. Configure operations program the parser and match+action stages, while populate operations add or remove entries to these tables. The model allows for reconfiguration without interrupting forwarding. P4 is designed to make it easy to translate programs into a table dependency graph (TDG), facilitating dependency analysis and mapping to specific switch targets. The paper presents a simple example of P4, the mTag example, which combines hierarchical routing with MPLS-like tags. The mTag header is defined, and the parser is described to extract fields from the packet. The match+action tables are defined to process these fields, and the control program specifies the flow of control between tables. P4 includes definitions for headers, parsers, tables, actions, and control programs. Headers define the sequence and structure of fields. Parsers identify headers within packets. Tables perform packet processing, and actions define how fields are processed. Control programs determine the order of tables applied to a packet. The paper discusses the compilation of P4 programs into target-specific configurations. It covers theP4 is a high-level language for programming protocol-independent packet processors. It works with SDN control protocols like OpenFlow. OpenFlow currently specifies a fixed set of header fields, which has grown from 12 to 41 fields, increasing complexity without flexibility. This paper proposes P4 as a solution for future OpenFlow evolution. The goals are: (1) reconfigurability in the field, (2) protocol independence, and (3) target independence. P4 allows programmers to describe packet processing independently of hardware specifics. An example shows how to use P4 to configure a switch to add a new hierarchical label. SDN provides programmatic control over networks, with the control plane separate from the forwarding plane. OpenFlow enables control over different hardware and software vendors. The OpenFlow interface started simple but has grown more complex over time, with more header fields and multiple stages of rule tables. New header fields continue to proliferate, requiring flexible mechanisms for parsing and matching. P4 offers a general, extensible approach, allowing controller applications to leverage capabilities through a common interface. Recent chip designs show that flexibility can be achieved in custom ASICs at terabit speeds. Programming these chips is complex, requiring a higher-level language like P4. P4 is designed to abstract the network programming level and serve as a general interface between the controller and switches. It allows the controller to define how switches operate, not just be constrained by fixed designs. P4's three main goals are reconfigurability, protocol independence, and target independence. The paper introduces an abstract forwarding model where switches forward packets via a programmable parser followed by multiple stages of match+action. This model generalizes packet processing in various devices and technologies. P4 is used to represent packet processing in terms of this model, enabling target-independent programs that can be mapped to different devices. The paper discusses the abstract forwarding model, which includes configure and populate operations. Configure operations program the parser and match+action stages, while populate operations add or remove entries to these tables. The model allows for reconfiguration without interrupting forwarding. P4 is designed to make it easy to translate programs into a table dependency graph (TDG), facilitating dependency analysis and mapping to specific switch targets. The paper presents a simple example of P4, the mTag example, which combines hierarchical routing with MPLS-like tags. The mTag header is defined, and the parser is described to extract fields from the packet. The match+action tables are defined to process these fields, and the control program specifies the flow of control between tables. P4 includes definitions for headers, parsers, tables, actions, and control programs. Headers define the sequence and structure of fields. Parsers identify headers within packets. Tables perform packet processing, and actions define how fields are processed. Control programs determine the order of tables applied to a packet. The paper discusses the compilation of P4 programs into target-specific configurations. It covers the