RMT

http://yuba.stanford.edu/~grg/docs/sdn-chip-sigcomm-2013.pdf

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)