Welcome back. In this lesson we'll talk about Protocol-Independent Packet Processing. I'll describe the need for Protocol-Independent Packet Processing, and we'll talk over this concept in some detail in the context of two examples. I will focus mostly on P4. Programming protocol-independent packet processors. Where appropriate, I'll also bring in motivation and concepts from another related effort called Protocol Oblivious Forwarding. Over the past five years, the number of headers in the OpenFlow specification has proliferated. Some might argue that this proliferation is a good thing because it reflects a lot of activity in the community. On the other hand, as the designers of protocol oblivious forwarding pointed out, control and data plane are not sufficiently decoupled. There's no easy way to modify packet formats. And adding new features requires changing both the forwarding element and the controller. All of these things together make it particularly hard to evolve SDN switches and control protocols independently from the hardware. Ideally we would like to be able to evolve SDN switches as well and be able to define our control protocols according to the requirements of the control programs and not be constrained by the capabilities of current hardware. For this, we'll want a configurable packet parser that's not tied to a specific header format. We'll want flexible match action tables that can match on packets in series or in parallel and can also match on any defined field in the packet. And, finally, we may want general packet processing primitives. Such as the ability to copy, add, remove, and modify fields in packet headers. We want these operations both for the header fields and for any meta-data that's associated with the packet. The current generation of switch ASICs is starting to make this possible. In one of the interviews this week we hear about the Intel FlexPipe and in another we hear about the RMT. Both of these architectures are beginning to make this type of programmable packet processing possible. Still, programming these chips is hard. They only expose custom vendor-specific interfaces, and the programming models are very low-level. Essentially akin to micro-code programming. The design of a higher level language like P4 has three goals. One is protocol independence. So one should be able to configure a packet parser and define a set of typed match action tables independently of any current control plane protocols. The second goal is target independence. Which provides the ability to write a program that processes packets without having deep, intricate knowledge of the switch details. The language essentially relies on a compiler to configure the target switch. The compiler can take this high level description of the packet processing and compile it to the switch in different ways depending on the physical capabilities or limitation of the switch. Finally, there should be some support for reconfiguartion in the field, to change parsing and processing without redeploying new hardware. To draw a comparison, classic open flow had a simple control plane, where a controller would simply install rules directly in the [INAUDIBLE]. The OpenFlow 2.0 proposal, on the other hand has two aspects. One, which takes place on a much slower time scale, is the configuration of the switches themselves. This configuration specifies a parser, tables, and the control flow of packets as they traverse the switch. The second aspect of the control protocol is populating those tables once they've been configured. This second aspect is much more akin to how current open flow... This second aspect of populating the tables is pretty similar to how the current control plane works with the distinction now that we have custom tables to populate. So this compiler that sits in between the control plane, and the switches, has a parser that can fit... has a module that parses this configuration and configures the tables accordingly. As well as a rule translator which may take rules specified in the high level control protocol and translate them down into physical tables that may reside on the switch. To understand how this works a little bit better in the context of P4, let's take a simple motivating example of data-center routing. Consider the topology below which has top-of-rack switches and two tiers of core switches. Let's suppose that the top-of-rack switches would like to perform source routing with the hierarchical tag that contains four one-byte fields each of which specifies a hop in the topology. P4 allows the programmer to specify an ordered list of fields where each field has a name and a width. Here, we see three such example specifications; one for the ethernet header, one for the vlan header, and one for this custom mTag header. In addition to the header format specification, P4 also allows the programmer to describe each packet-processing stage using a mechanism called typed tables. Typed table specification allows the programmer to specify which fields are matched, and how, and what action fuinctions are performed at each stage. Optionally these tables can provide some hint about the maximum number of rules. It might be inserted into that table. Here's an example of a typed table supporting the push of the mTag that we just explored. This table reads the ethernet and the vlan headers and has an action to add an mTag. P4 also has ways of specifying the control flow of a packet from one table to the next. This allows a programmer to express collections of functions, conditionals, and tables. So at a particular top of rack switch, the packet might be coming from the core, or from local hosts. Depending on where it's coming from, it may or may not already have an mTag. First step in the control flow may be to check the table for the source and then consult a local switching table to determine whether the destination for the packet is local to the switch or not. If it's not local, the switch might consult the mTag table to add the appropriate mTag and then push the packet to the appropriate egress pole. The P4 Compiler has a parser which might be a programmable parser, in the context of more programmable switches, or a fixed parser in the case of legacy switches. In the latter case, the fixed parser might simply verify that the description of what is being parsed is consistent with the capabilities of the legacy hardware. The control program has two aspects. One, target-independent aspect. It's simply a table graph. Explaining the dependencies between different match action tables in the control form. The second, is a target dependent mapping of logical tables to the switch based sources depending on the physical constraints of any particular switch. The final component of the compiler is a rule translation module. Which verifies that the rules agree with the logical table types, and translates the logical rules to the physical tables which the switch is capable of supporting. To support the goal of target independence P4 has a vision of compiling to different types of its switches since essentially anything in a logical table graph can be mapped for software. When hardware switches with RAM and TCAM, the RAM can act as a hash table for tables with exact matches, and the TCAM can provide tables with wildcards in the matches. Other switches might provide support for parallel tables, in which case the compiler might want to analyze the table graph to ensure that possible concurrent operations don't introduce correctness problems. Other switch architectures might instantiate tables that generate meta-data along each stage of packet processing and that meta-data could subsequently be used to perform actions at the end of the processing pipeline. This approach is similar to that which is taken by Intel's flex pipe architecture. Finally, the compiler might need to operate on switches that have very few physical tables, such as legacy overflow 1.0 switches. In these cases the compiler might need to map multiple logical physical tables to one physical table. Composing rules for multiple logical tables into a cross product of rules in a single physical table. In conclusion, open flow 1.x protocols provide a vendor-agnostic API but only for very fixed function switches. P4 and protocol oblivious forwarding, envision an alternate future where one can define the hardware independently of the control protocol, and independently of the switch targets. This new paradigm also provides for the ability to reconfigure a switch in the field. P4 is a strawman proposal for a language that might allow a switch to be reconfigured in the field, but there's much work to be done. Just to name one particular challenge is the design of that compiler that takes a high level language like P4, and compiles it to different targets ranging from legacy switches to programmable hardware like FPGAs to software.
