B.Parsing graphs and packet parsing 。“dep”/“nondep”:Enabling or disabling the use of From the protocol specification one can easily derive a dependent labels explained in Sec.IV-B. parse graph as in P4.As shown in Fig.9,the parse graph We run the learning switches example using different op- is a directed graph,where nodes represent protocols declared tions and different n(i.e.the number of hosts).We record the in the specification,and edges represent the ordering of number of flow tables.Then we use the"pingall"test provided protocols.The edges are generated from the next block of by Mininet to send packets among hosts.We record the total the specification,and the labels represents the corresponding number of flow table entries and number of packet-in events values of the field that one uses to determine the next protocol. generated during the test,and the execution time. The start node is specified by the start clause. A.The quality of pipelines Both the runtime system of POMP in the control plane and the data plane may use the parse graph for packet parsing. We use the number of flow tables and total number of table 1)Parsing in the control plane:The POMP runtime takes entries to evaluate the quality of pipelines.The result is shown the parse graph and a raw packet as input,and outputs a map in Table IⅢ，from which we can see: from field names to (offset,length)tuples,which can The total number of entries grows quadratically in single- be used to extract values of fields from the raw packet.As table,while it grows linearly in multi-table pipelines. explained before,we use dotted notations (e.g."eth.ipv4.ttl") POMP under the multi-opt-dep setting uses up to 47x for field names to avoid name clash.The parsing starts with fewer number of entries than single-table. the start node and traverses the parse graph.During the process ·Turning on“opt'”reduces the number of tables from5to it also maintains a current pointer pointing to the raw packet. 3.while the number of entries is about the same.This which is used to extract the value of certain field (e.g.type) is because the reduced flow tables (with tid 1 and 2 in to decide the next node to transit to. Fig.6)contain only 3 entries in total. The parsing process is invoked on receiving a Packet In Dependent labels (turning on "dep")save 66%-80% message.In the network policy f(pkt,env),when packet entries,comparing the last two rows of Table III. fields are accessed using string names,we lookup the map B.Performance generated by the parser to find the corresponding (offset, length)tuples,using which we can locate the field and do We use the execution time and the number of PacketIn the read/write of the field. events to evaluate the performance.The result is shown in Since the switch of POF uses (offset,length)tuples Tables IV and V.We also compare our learning switches in the flow table to access packet fields,the runtime system with the built-in learning functionality of Open vSwitch,a also needs to translate field names into (offset,length) production quality soft switch.Its profile is shown as "ovsk". when installing flow table entries for POF switches. From Tables IV and V we can see: 2)Parsing in the data plane:POF and P4 uses different Multi-table pipeline causes significantly less PacketIn strategies to achieve protocol independence.In POF,no parser messages than single table,and is up to 134x faster. is required in the data plane.We use (offset,length) ·Multi--table pipeline is20%-40%slower than“ovsk”. generated by the control plane parser to specify packet fields. This is unsurprising because"ovsk"is a pure data plane On the other hand,our parsing graph also serves as a P4 application,and there is no controller-switch communi- parser,which can be fed into the P4 compiler to generate a cation (i.e.no PacketIn messages). data plane parser.All incoming packets must be parsed at the Dependent labels help reducing the number of PacketIn data plane before being sent to the pipeline. events,thus improve the performance. Note that turning on "opt"alone is not helpful to reduce the VI.EVALUATION number of PacketIn messages.Since the pingall time is spent We compare the effects of different techniques we use, mostly by PacketIn messages,"opt"introduces no obvious and demonstrate that POMP generates high-quality forwarding decrease of pingall time either. pipelines.The evaluation setting is the following: VII.RELATED WORK Hardware:Intel Core I7 4712MQ 2.3GHz,8G RAM. In Sec.I we have pointed out the limitations of many Network Emulator:Mininet [9]. representative languages,including NetKAT [6].NetCore [7]. Switch:P4 bmv2 [10]Open vSwitch [11]2.6.2. Maple [5]and P4 [1].Here we compare our work with some Topology:Single 10 port switch with n hosts. more SDN programming languages. To show the effects of different techniques,POMP provides Magellan [12]also derives and populates multi-table three tunable options: pipelines from algorithmic policies,but it takes very different ·“multi”/“single”:Enabling or disabling the generation approaches from ours.It starts from extremely fine-grained of multi-table pipelines.The"single"option turns off the pipelines by treating every statement as a flow table.Then taint analysis and generates a single monolithic flow table. it recognizes the so called compact operations and merges ·“opt”/“nonopt'":Enabling or disabling the pipeline their corresponding flow tables with others,so that the number optimization shown in Sec.III-C. of flow tables is reduced without significantly increasing theB. Parsing graphs and packet parsing From the protocol specification one can easily derive a parse graph as in P4. As shown in Fig. 9, the parse graph is a directed graph, where nodes represent protocols declared in the specification, and edges represent the ordering of protocols. The edges are generated from the next block of the specification, and the labels represents the corresponding values of the field that one uses to determine the next protocol. The start node is specified by the start clause. Both the runtime system of POMP in the control plane and the data plane may use the parse graph for packet parsing. 1) Parsing in the control plane: The POMP runtime takes the parse graph and a raw packet as input, and outputs a map from field names to (offset, length) tuples, which can be used to extract values of fields from the raw packet. As explained before, we use dotted notations (e.g. “eth.ipv4.ttl”) for field names to avoid name clash. The parsing starts with the start node and traverses the parse graph. During the process it also maintains a current pointer pointing to the raw packet, which is used to extract the value of certain field (e.g. type) to decide the next node to transit to. The parsing process is invoked on receiving a PacketIn message. In the network policy f(pkt, env), when packet fields are accessed using string names, we lookup the map generated by the parser to find the corresponding (offset, length) tuples, using which we can locate the field and do the read/write of the field. Since the switch of POF uses (offset, length) tuples in the flow table to access packet fields, the runtime system also needs to translate field names into (offset, length) when installing flow table entries for POF switches. 2) Parsing in the data plane: POF and P4 uses different strategies to achieve protocol independence. In POF, no parser is required in the data plane. We use (offset, length) generated by the control plane parser to specify packet fields. On the other hand, our parsing graph also serves as a P4 parser, which can be fed into the P4 compiler to generate a data plane parser. All incoming packets must be parsed at the data plane before being sent to the pipeline. VI. EVALUATION We compare the effects of different techniques we use, and demonstrate that POMP generates high-quality forwarding pipelines. The evaluation setting is the following: • Hardware: Intel Core I7 4712MQ 2.3GHz, 8G RAM. • Network Emulator: Mininet [9]. • Switch: P4 bmv2 [10] / Open vSwitch [11] 2.6.2. • Topology: Single 10 port switch with n hosts. To show the effects of different techniques, POMP provides three tunable options: • “multi” / “single”: Enabling or disabling the generation of multi-table pipelines. The “single” option turns off the taint analysis and generates a single monolithic flow table. • “opt” / “nonopt”: Enabling or disabling the pipeline optimization shown in Sec. III-C. • “dep” / “nondep”: Enabling or disabling the use of dependent labels explained in Sec. IV-B. We run the learning switches example using different op￾tions and different n (i.e. the number of hosts). We record the number of flow tables. Then we use the “pingall” test provided by Mininet to send packets among hosts. We record the total number of flow table entries and number of packet-in events generated during the test, and the execution time. A. The quality of pipelines We use the number of flow tables and total number of table entries to evaluate the quality of pipelines. The result is shown in Table III, from which we can see: • The total number of entries grows quadratically in single￾table, while it grows linearly in multi-table pipelines. • POMP under the multi-opt-dep setting uses up to 47x fewer number of entries than single-table. • Turning on “opt” reduces the number of tables from 5 to 3, while the number of entries is about the same. This is because the reduced flow tables (with tid 1 and 2 in Fig. 6) contain only 3 entries in total. • Dependent labels (turning on “dep”) save 66% - 80% entries, comparing the last two rows of Table III. B. Performance We use the execution time and the number of PacketIn events to evaluate the performance. The result is shown in Tables IV and V. We also compare our learning switches with the built-in learning functionality of Open vSwitch, a production quality soft switch. Its profile is shown as “ovsk”. From Tables IV and V we can see: • Multi-table pipeline causes significantly less PacketIn messages than single table, and is up to 134x faster. • Multi-table pipeline is 20% - 40% slower than “ovsk”. This is unsurprising because “ovsk” is a pure data plane application, and there is no controller-switch communi￾cation (i.e. no PacketIn messages). • Dependent labels help reducing the number of PacketIn events, thus improve the performance. Note that turning on “opt” alone is not helpful to reduce the number of PacketIn messages. Since the pingall time is spent mostly by PacketIn messages, “opt” introduces no obvious decrease of pingall time either. VII. RELATED WORK In Sec. I we have pointed out the limitations of many representative languages, including NetKAT [6], NetCore [7], Maple [5] and P4 [1]. Here we compare our work with some more SDN programming languages. Magellan [12] also derives and populates multi-table pipelines from algorithmic policies, but it takes very different approaches from ours. It starts from extremely fine-grained pipelines by treating every statement as a flow table. Then it recognizes the so called compact operations and merges their corresponding flow tables with others, so that the number of flow tables is reduced without significantly increasing the