Successfully reported this slideshow.
Your SlideShare is downloading. ×

Rina p4 rina workshop

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad

Check these out next

1 of 16 Ad

More Related Content

Slideshows for you (20)

Similar to Rina p4 rina workshop (20)

Advertisement
Advertisement

Rina p4 rina workshop

  1. 1. A PoC implementation of a RINA interior router using P4 Sergio Fernandez (i2CAT) Eduard Grasa (i2CAT) Steve Bunch (TRIA Network Systems)
  2. 2. Motivation: what? 2 A High performance RINA router implementation At a reasonable cost (in terms of development effort and required hardware)
  3. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
  16. 16. Thank you! Questions? Research Roadmap 2020 - 2025 16

×