This document discusses a proof-of-concept implementation of a RINA interior router using P4. The goals are to increase RINA credibility by providing a high-performance router implementation at a reasonable cost, and to understand limitations of current network programmability approaches. The implementation targets the BMv2 P4 software switch, demonstrating basic interior router functions for EFCP packets. Future work includes implementing the design on hardware and evaluating the feasibility of a border router.
1. A PoC implementation
of a RINA interior
router using P4
Sergio Fernandez (i2CAT)
Eduard Grasa (i2CAT)
Steve Bunch (TRIA Network Systems)
2. Motivation: what?
2
A High performance RINA router
implementation
At a reasonable cost (in terms of
development effort and required
hardware)
3. Motivation: why?
3
• Increase RINA credibility and decrease perceived adoption risk
• “Great theory, nice prototype but… where is the router?”
• Support new use experimental / PoC use cases beyond existing pure
software prototypes
• Campus Networks, Datacenter Fabrics, 5G network backhaul, etc.
• Understand limitations in current network programmability approaches
4. Potential approaches
4
High performance packet I/O
frameworks
NETMAP
• Software-based, flexible: you can
do anything
• Limited performance (15 Mpps per
core)
FPGA-based
• Hardware acceleration,
high performance. Still
flexible
• Limited hardware choices,
complex development
Programmable ASICs
• Hardware acceleration,
hardware choice, # of
interfaces
• W i l l i t b e f l e x i b l e
enough?
5. Our contributions
5
• Initial analysis of P4 capabilities relevant to the implementation of a
RINA router
• Prototype implementation of a RINA interior router data plane using a P4
software target (BMv2)
• Next steps:
• Do it in hardware! (Barefoot Tofino ASIC)
• Check feasibility of border router, what are the tradeoffs?
6. Use cases
6
• Decrypt (optional, depends on policy)
• Parse EFCP header
• Check CRC
• Check forwarding function, select outer port
• Schedule PDU
• Recompute CRC
• Encode EFCP header
• Encrypt (optional)
• Interior router functions +
• Remove / add headers
• Generate control PDUs
• For flow control
• For rtx control (optional, depends on policy)
• Timers
7. P4 basics: components
7
• P4: Language for expressing how packets are processed by the data
plane of a programmable forwarding element
• P4 Runtime: Platform for loading different pipelines, add/remove entries
from dataplane tables and read/write PDUs from/to dataplane
8. P4 basics: pipeline architectures
8
• P416: Language supports different architectures (specified by ASIC
vendor). Architecture defines the building blocks that can be present in the
pipeline, and the supported packet workflows
• Example: V1Model: Simple architecture used by P4 software targets
9. P4 language limitations
9
• No support for loops
• Can be workarounded via resubmit and recirculate primitives, performance penalty
• No support for timers at the data plane, nor for encryption
• Unless defined in a vendor-specific hardware module
• Packet scheduler cannot be programmed
• No support for fragmentation or reassembly
• No built-in support for generating new PDUs
• May be workarounded via clone and recirculation/resubmission
10. Use cases
10
• Decrypt (optional, depends on policy)
• Parse EFCP header
• Check CRC
• Check forwarding function, select outer port
• Schedule PDU (but not programmable!)
• Recompute CRC
• Encode EFCP header
• Encrypt (optional)
• Interior router functions +
• Remove / add headers
• Generate control PDUs
• For flow control
• For rtx control (optional, depends on policy)
• Timers
11. RINA interior router: basic design
11
• Target control plane: Management agent and layer management components of the IPC
Processes, communicating to the data plane via P4Runtime API
• Target data plane: Data transfer components of the IPC Process.
12. Data plane implementation: RINA interior router P4 pipeline
12
• Based on the BMv2 simple_switch software target (V1model, P416)
• Can process EFCP over Ethernet (with or without VLANs) and IP over
Ethernet (with or without VLANs) -> IP for legacy support
• Dataplane implementation straightforward, P4 file only has 462 LOC
13. Control plane: Verify P4Runtime API
13
• Simple Python script that attacks
the P4Runtime API to:
• Load the hybrid EFCP/IP
pipeline
• Populate the EFCP and IP
match action tables
• Rx packets from the
dataplane and Tx packets
to the dataplane
….
sh.setup(
device_id=1,
grpc_addr='10.0.2.15:50001',
election_id=(0, 1), # (high, low)
config=sh.FwdPipeConfig('p4src/build/p4info.txt', 'p4src/build/bmv2.json')
)
#TABLE ENTRIES
te = sh.TableEntry('MyIngress.efcp_lpm')(action = 'MyIngress.efcp_forward')
te.match['hdr.efcp.dstAddr'] = ('1')
te.action['dstAddr'] = ('00:00:00:00:00:01')
te.action['port'] = ('1')
te.action['vlan_id'] = ('0')
te.insert()
…
connection = sh.client
while True:
print("Waiting for recive something")
packet = connection.stream_in_q.get()
print("Packet received!:" + str(packet))
connection.stream_out_q.put(packet)
sh.teardown()
14. Testing: Stratum and Mininet
14
• Validated interior router behaviour using Mininet and Python programs to
generated and receive EFCP PDUs (hosts and router are containers)
• Minimal performance test (though BMv2 is just a testing tool, not designed
for performance at all) -> up to 1 Gbps throughput (8 CPUs, 15 GB RAM)
15. Conclusions right now
15
• Interior router -> no problem
• Without encryption! And need to check in real hardware
• Border router might be doable (as a prototype), but maybe too constrained
• No fragmentation / reassembly
• Timers only with speficic hardware support (no generic implementation)
• Is packet cloning + recirculation a viable way to generate control packets?
• P4 community very responsive
• All or questions were answered quickly (in less than one week, usually in 1 or 2 days),
interest in supporting our use case
• Understand limitations in current network programmability approaches
