Main Idea

  • Trade-offs between programmability and speed

    • can match-action hardware permit (just) enough reconfiguration in the field so that new types of packet processing can be supported at run-time (can this be done at reasonable cost without sacrificing speed)

  • Reconfigurable Match-action Table (RMT) model: Minimal instruction set like RISC, designed to run really fast in heavily pipelined hardware

    • First formal description of a switch architecture providing programmability without giving up performance

    • Flexibility at no cost

      • Allow new fields to be added by modifying the parser

      • Allow new fields to be matched by modifying match memories

      • Allow new actions by modifying stage instructions

      • Allow new queueing by modifying the queue discipline for each queue

    • Flexible

      • Packet parsing: can add new header fields and have the switch match on them

      • Match on new header fields and new combinations of headers

      • Actions (packet editing): modify packet headers in somewhat more arbitrary ways

      • Table sizing: only need to respect overall constraint on SRAM (exact match) and TCAM (tenary match) memory sizes

  • Contributions

    • An architecture for RMT

      • allow definition of arbitrary headers and header sequences, arbitrary matching of fields by an arbitrary number of tables, arbitrary writing of packet header fields, and state update per packet

      • Main abstraction: parse graph (that defines headers), and a table flow graph (that expresses the match table topology)

    • Use cases: implement forwarding using Ethernet and IP headers, and support RCP

    • Chip design and cost: implementation of a 640 Gbps switch chip; detail in logic and circuit design, floorplanning and layout, etc.

  • RMT model: a way to think about programming the network, and direct expression in HW using a configurable pipeline of match tables and action processors

  • Some interesting notes

    • OpenFlow, but more flexible version?

    • How to make data plane programmable as well? (i.e. SDN then was all about control plane programmability, still quite limited by what was provided by the switches)

    • Some restrictions

      • Can't run everything as you can on a CPU

      • isn't Turing complete (?)

      • Can't do packet scheduling, payload manipulation, programmatic state manipulation; can't do packet encryption or regular expression processing on the packet body

    • What's the benefit

      • Researchers trying out new ideas

      • Network operators who want to customize the network to their needs (e.g. traffic engineerings, load balancing)

      • Switch vendors: easier to fix bugs in the software without making new hardware chips

    • Paper notes

      • High- to low-level description, top down approach

      • Combine ideas cross fields (networking, hardware design, compilers, circuit design, algorithms)

Last updated