From programmers'point of view,f(pkt,env)is in- header spec. network policy f(pkt,env) Taint Analysis voked upon the arrival of every packet pkt in each data- Parser Gen API Calls plane switch.f also takes a centralized view of the network environment env.It calculates the routing path and returns Parser Runtime System Pipeline the port number to forward the packet.The return value can packet-In flow entries also be 0 or negative,which means to drop the packet or P4 Compiler Switch Abstraction Layer to broadcast it,respectively.f may also call POMP APIs to modify the global environment or to modify fields of packets. P4 protocol. POF protocol What really happens is that the controller (the runtime P4 Switch POF Switch system)invokes f(pkt,env)when it receives a PacketIn Fig.1.Structure of POMP message,and passes the packet to f.The runtime then monitors the execution of f and generates an execution trace, which records the sequence of API calls made by f to read is done statically before the deployment of the controller, or update packet header fields or the environment data.Based therefore it does not introduce any runtime overhead. on the dependence between actions and values of packet fields We extend the taint analysis with a novel notion of reflected in the trace,the runtime automatically generates flow dependent labels,which further refines the dependence table entries and install them on switches. relation and allows it to be conditional upon the if So far the ideas all come from Maple,but Maple does not statement branches taken at runtime.Combining the support multi-table pipelining and protocol-oblivious forward- dependent labels with the runtime execution traces of the ing.As we demonstrate in Sec.III,the dependence derived network policy,the runtime system can further reduce the by Maple from the execution trace is way too imprecise and number of flow table entries.Our experiments show that, leads to flow tables with O(n2)forwarding rules for learning for learning switches,POMP generates flow tables with switches with n hosts,even though O(n)rules are sufficient. up to 47x fewer table entries and being 137x faster than POMP introduces a static taint analysis phase to analyse the the traditional single flow table (as generated in Maple). code of f,from which it infers the fine-grained dependence Inspired by P4,POMP incorporates a packet header spec- between actions and packet fields.Based on the fine-grained ification language,with which programmers can specify dependence,it automatically generates a multi-table pipeline. the format of packet headers.Based on the specification The runtime takes the multi-table pipeline into account and we can automatically generate parsers for packets.This generates table entries accordingly. makes POMP a protocol oblivious programming environ- To support protocol-oblivious programming,we follow the ment.Our runtime system can support two main emerging ideas in P4 and ask programmers to provide a header format SDN platforms:POF and P4.It makes network policies specification written in a specification language.Then the written in our language portable over any SDN chipsets parser generator automatically generates parsers for packets. and software switches that support POF or P4. POMP supports both POF and P4.For POF,the runtime In the remaining part of the paper,we give a system queries the parser to map the string field names to the overview and introduce a running example in Sec.II.We (offset,length)tuples.For P4,the generated parser present the taint analysis and the pipeline generation in and forwarding pipeline are fed into the P4 compiler to configure the switch.We also introduce a switch abstraction Sec.III,and propose the dependent labels and the runtime generation of table entries in Sec.IV.We then introduce the layer,which accepts P4 or POF messages separately and then packet parsing for protocol oblivious programming in Sec.V. converts them into a uniform format for the runtime system We show evaluation results in Sec.VI.Finally we discuss B.Learning Switches:a running example related work in Sec.VII and conclude in Sec.VIII. We use learning switches to demonstrate how the system II.OVERVIEW works.It is also used as a running example to illustrate the key ideas in the following sections.As shown in Fig.1,our system In this section we first give an overview of the system takes as inputs a protocol specification and a network policy structure of POMP.Then we introduce learning switches as f,which are shown in Figs.2 and 3 respectively.(Ignore the a running example used in the following sections. comments in Fig.3,which shows the result of taint analysis and is explained in Sec.II). A.System structure The protocol specification describes the eth and ipv4 Figure 1 shows the system structure.Following Maple,protocols.Each is defined by a header block.For each POMP allows programmers to implement the network policy header block,there are the fields section that describes as an algorithmic sequential program with a centralized view the fields of the protocol,and the next section that describes of the network environment.The network policy is imple-the inner protocols.For example,the eth protocol has three mented as a function f(pkt,env).It is a C program with fields:48 bits dst,48 bits src and 16 bits type.Depending API calls of the POMP library. on the values of type,the protocol follows the eth is ipv4Fig. 1. Structure of POMP is done statically before the deployment of the controller, therefore it does not introduce any runtime overhead. • We extend the taint analysis with a novel notion of dependent labels, which further refines the dependence relation and allows it to be conditional upon the if statement branches taken at runtime. Combining the dependent labels with the runtime execution traces of the network policy, the runtime system can further reduce the number of flow table entries. Our experiments show that, for learning switches, POMP generates flow tables with up to 47x fewer table entries and being 137x faster than the traditional single flow table (as generated in Maple). • Inspired by P4, POMP incorporates a packet header spec￾ification language, with which programmers can specify the format of packet headers. Based on the specification we can automatically generate parsers for packets. This makes POMP a protocol oblivious programming environ￾ment. Our runtime system can support two main emerging SDN platforms: POF and P4. It makes network policies written in our language portable over any SDN chipsets and software switches that support POF or P4. In the remaining part of the paper, we give a system overview and introduce a running example in Sec. II. We present the taint analysis and the pipeline generation in Sec. III, and propose the dependent labels and the runtime generation of table entries in Sec. IV. We then introduce the packet parsing for protocol oblivious programming in Sec. V. We show evaluation results in Sec. VI. Finally we discuss related work in Sec. VII and conclude in Sec. VIII. II. OVERVIEW In this section we first give an overview of the system structure of POMP. Then we introduce learning switches as a running example used in the following sections. A. System structure Figure 1 shows the system structure. Following Maple, POMP allows programmers to implement the network policy as an algorithmic sequential program with a centralized view of the network environment. The network policy is imple￾mented as a function f(pkt, env). It is a C program with API calls of the POMP library. From programmers’ point of view, f(pkt, env) is in￾voked upon the arrival of every packet pkt in each data￾plane switch. f also takes a centralized view of the network environment env. It calculates the routing path and returns the port number to forward the packet. The return value can also be 0 or negative, which means to drop the packet or to broadcast it, respectively. f may also call POMP APIs to modify the global environment or to modify fields of packets. What really happens is that the controller (the runtime system) invokes f(pkt, env) when it receives a PacketIn message, and passes the packet to f. The runtime then monitors the execution of f and generates an execution trace, which records the sequence of API calls made by f to read or update packet header fields or the environment data. Based on the dependence between actions and values of packet fields reflected in the trace, the runtime automatically generates flow table entries and install them on switches. So far the ideas all come from Maple, but Maple does not support multi-table pipelining and protocol-oblivious forward￾ing. As we demonstrate in Sec. III, the dependence derived by Maple from the execution trace is way too imprecise and leads to flow tables with O(n 2 ) forwarding rules for learning switches with n hosts, even though O(n) rules are sufficient. POMP introduces a static taint analysis phase to analyse the code of f, from which it infers the fine-grained dependence between actions and packet fields. Based on the fine-grained dependence, it automatically generates a multi-table pipeline. The runtime takes the multi-table pipeline into account and generates table entries accordingly. To support protocol-oblivious programming, we follow the ideas in P4 and ask programmers to provide a header format specification written in a specification language. Then the parser generator automatically generates parsers for packets. POMP supports both POF and P4. For POF, the runtime queries the parser to map the string field names to the (offset, length) tuples. For P4, the generated parser and forwarding pipeline are fed into the P4 compiler to configure the switch. We also introduce a switch abstraction layer, which accepts P4 or POF messages separately and then converts them into a uniform format for the runtime system. B. Learning Switches: a running example We use learning switches to demonstrate how the system works. It is also used as a running example to illustrate the key ideas in the following sections. As shown in Fig. 1, our system takes as inputs a protocol specification and a network policy f, which are shown in Figs. 2 and 3 respectively. (Ignore the comments in Fig. 3, which shows the result of taint analysis and is explained in Sec. III). The protocol specification describes the eth and ipv4 protocols. Each is defined by a header block. For each header block, there are the fields section that describes the fields of the protocol, and the next section that describes the inner protocols. For example, the eth protocol has three fields: 48 bits dst, 48 bits src and 16 bits type. Depending on the values of type, the protocol follows the eth is ipv4