Programmable Data-planes

5.2 Programmable Data-planes

The rst generation of IP routers were software programs running on general purpose processors [152]. The use of generic platforms eased the design and implementation of packet processing functions at a high level at a time where network throughput was not a prime requirement. In fact, general purpose chips and architectures were not designed to optimize few specic tasks, rather to be generic enough to perform a vast set of operations. Today, network functions are mostly implemented with Application Specic Integrated Circuits (ASICs) to meet strict latency and network throughput requirements imposed by higher link-speeds. Meanwhile, more versatile chips, like Network Processor Units (NPUs), can be used in less time-critical network environ- ments where, however, changes of the network behavior may be required on the eld.

Wisely looking at the design of forwarding devices, i.e., switches and routers, over the past decades, two important facts emerge. First, new protocols have always been rst standardized and then implemented in network equipment (among them, the recent proliferation of encapsu- lation protocols like VxLAN, PBB, GRE). Second, today's forwarding devices oer more func- tionalities (QoS, security, etc.) in addition to the simple L2 and L3 forwarding. In either case, a new protocol or a new functionality may lead to the design of a new chip whether that is not supported by the latest hardware. The latter operation is a few-year long process which slows down the adoption of a technology at best, or discourages it at worst. Since the introduction of new protocols and functions seems to be more and more commonplace, several chip designs for high-speed recongurable packet processors have been proposed [153, 79, 154]. Novel pro- grammable packet processors come together with new programming languages to express the network behavior into an easy and reusable way [153, 80]. Among those languages, the Pro- gramming Protocol-independent Packet Processors (P4) [80] has gained notable traction since its inception in 2014.

As explained in detail in the previous chapters, an ICN network layer routes content requests toward nearby content sources using their content identiers rather than specic host addresses. In NDN/CCN-like networks, routers feature the three functional blocks, namely PIT, CS, FIB, working on named data. The NDN data-plane involves new and unconventional processing to be performed at line-speed. For each NDN packet, several lookups on variable length names may be required, further, some related state has to be stored and/or updated. The design of NDN- enabled routers turns to be challenging because of two main issues: i) the algorithmic challenges that still need to be solved [155, 156, 84], ii) the evident lack of adequate hardware support to describe this data-plane behavior [157, 96]. Existing designs of an NDN router have been engineered by leveraging specic features of the target software/hardware platform. As result, those designs cannot be easily shared and leveraged for either further research or operational deployment.

We believe that the emergence of a new generation of fully programmable forwarding elements represents an opportunity to advance the research on ICN. In fact, if the next generation of programmable networking devices has the right feature set to fully describe any ICN packet processing, then there will be more chances to showcase the potential benets of ICN architec- tures. More broadly, we consider the advent of this technology as an inection point [158] for a conuence between the Software-Dened Networking stream of thought and the ICN one. To promote the description of ICN protocols in a unied open-source way, which would made the related designs sharable and re-usable, the work NDN.p4 in [81] has rst been conducted. NDN.p4, which is presented in this section, has been the rst attempt to implement an ICN protocol using the P4 language for packet processors. Sec. 5.2.1 introduces the P4 language, the main syntax and the related programming model. Sec. 5.3 describes the implementation of the

NDN protocol in P4. Finally, Sec. 5.3.6 recapitulates the main lessons learned during the design of the NDN.p4 solution.

5.2.1 The P4 language

P4 [80] is a programming language to congure the data-plane of network forwarding elements. The aim of the P4 language is to abstract how packets are processed by dierent devices in a high-level target-independent description. Then, target-specic compilers are supposed to map and optimize the high-level description in a P4 program to the low-level intricacies of the respec- tive target architectures. The idea behind the language was rst proposed in [80] and since then collaboratively developed by a rich community made of academics, network equipment vendors, telco providers under the umbrella of an open non-prot consortium [159].

Since the rst language specication, called P4_14, the language has considerably evolved and become mature in a new language version, called P4_16. P4_16 is not backward compatible with P4_14. Both language specications are available at [159]. However, NDN.p4 was imple- mented in P4_14, so the description of the language which follows refers to that early version. A P4 program congures the supported protocols and the packet processing operations in a forwarding element. A forwarding element which can run P4 programs is called a P4 target or simply a target. The P4_1413 _{language specication is based on a specic abstract model of a}

forwarding element. The forwarding model is composed of a programmable parser, a buer for packet headers and metadata, an ingress and an egress pipelines of match-action tables as shown in Fig. 5.2.1 (the processing pipeline of this model mimics the commonplace design of some of the latest fully-programmable forwarding devices [79, 160]).

Figure 5.1  The abstract forwarding model for the P4_14 language specication.

13_{For the sake of clarity, from now on until the end of this section, the abbreviation P4 is used whenever the} text refers to the P4_14 language specication.

5.2. Programmable Data-planes Usually ve parts are needed to describe the behavior of a forwarding device in P4: the headers, the parser, the actions, the tables and the control ow. Those parts compose the yellow and red blocks in the abstract model [161] reported in Fig. 5.2.1. A small snippet of code for each program block is illustrated in Table 5.2 where a simple P4 program is dissected. The illustrative program in Table 5.2 describes the behavior of a simplied IPv4 router which parses Ethernet and IPv4 headers in incoming packets and then forwards those based on their IP destination addresses. Finally, the P4 program rewrites the packet's MAC source and destination addresses based on the output port the packet is transmitted to.

The headers are the denition of protocols that the P4 target uses to parse the incoming bit stream to identify the protocols in a packet and extract the elds necessary to the processing. A P4 header contains a list of elds and eld widths in bits arranged in a C struct-like layout, as shown in the A cell of Table 5.2 where the structure of an ethernet header is specied. Headers represent types that can be instantiated and initialized once found and parsed in packets, as shown in the B cell of Table 5.2.

The parser is a nite-state machine that determines and extracts the protocols seen in a packet according to the headers denition. The parser is made of parser states whose transitions can be determined according to header eld values (e.g., the Ethernet's ethertype eld in our example). A simple parser for the ethernet and IPv4 protocols is shown in the cells B and C of Table 5.2. Actions are language primitives to express common packet editing tasks, like modifying header elds, selecting output ports, adding/removing headers, etc. Primitive actions can be combined in bundles to create compound user-dened functions. For example, the set_nexthop action in the D cell of Table 5.2 combines the two primitive actions, modify_eld and subtract_from_eld, to perform the packet editing necessary to forward the IP packet to the nexthop and decrement the TTL count. Compound actions are meant to be linked to table entries.

P4 tables are logical tables used to trigger the activation of actions for packets. The table in the F cell of Table 5.2 species a longest prex match type on the IPv4 destination address to activate either the set_nexthop action or the on_miss one. The table in the G cell translates the information about a next-hop to an output port and re-writes the packet's MAC addresses based on the selected output port. Table denitions in P4 programs only specify the logical skeleton of the table. Table entries are then populated at run-time by a control plane logic. A run-time insertion command lls a table entry with specic values for the matching elds, an indication of the action to associate to the entry and possibly some optional parameters.

The control ow denes the program execution path. The programming model in Fig. 5.2.1 includes two pipelines, one for the ingress stage and another one for the egress. The ingress pipeline contains a sequence of match-action tables to be executed sequentially and/or according to some branching conditions. The ingress pipeline produces an egress specication in terms of output ports and number of packet copies. The egress specication is later used in the egress pipeline to correctly forward the packets. The illustrative P4 program of Table 5.2 has a very simple control ow, illustrated in the H cell, which consists of the application of the two dened tables. First, the table ipv4_b_lpm is applied in the ingress pipeline to select the next-hop address. Then, the table forward selects the output port and rewrites the MAC addresses in the egress pipeline.

Table 5.2  Snippets of code showing some of the P4_14 syntax.

A - Header Denition and Instantiation B - Parser part 1

header_type e t h e r n e t _ t { f i e l d s { dstAddr : 4 8 ; srcAddr : 4 8 ; etherType : 1 6 ; } } header e t h e r n e t _ t e t h e r n e t ; parser s t a r t { return parse_eth ; } parser parse_eth { extract ( e t h e r n e t ) ; return s e l e c t ( e t h e r n e t . etherType ) { 0 x0800 : parse_ipv4 ; default : i n g r e s s ; } }

C - Parser part 2 D - Action denition 1

parser parse_ipv4 { extract ( ip v4 ) ; return i n g r e s s ; }

action set_nexthop ( nexthop ) {

m o d i f y _ f i e l d ( standard_metadata . e g r e s s _ s p e c , nexthop ) ; s u b t r a c t _ f r o m _ f i e l d ( i p v4 . t t l , 1 ) ; } action on_miss ( ) { no_op ( ) ; }

E - Action denition 2 F - Table denition 1

action rewrite_macs ( smac , dmac ) {

m o d i f y _ f i e l d ( e t h e r n e t . srcAddr , smac ) ; m o d i f y _ f i e l d ( e t h e r n e t . dstAddr , dmac ) ; } action no_rewrite ( ) { drop ( ) ; } table ipv4_fib_lpm { reads { i p v4 . dstAddr : lpm ; } actions { set_nexthop ; on_miss ; } s i z e : 5 0 0 0 ; }

G - Table denition 2 H - Control Flow

table forward { reads { standard_metadata . e g r e s s _ p o r t : e x a c t ; } actions { rewrite_macs ; no_rewrite ; } s i z e : 6 4 ; } control i n g r e s s {

apply ( ipv4_ fib_lpm ) ; }

control e g r e s s { apply ( forward ) ; }