Summary:
In the software-defined network, the control plane and forwarding plane are physically separated from the control software using open interfaces (e.g. the OpenFlow) of the forwarding plane (e.g., switches and routers) programming.
This article aims to overcome the limitations of the current two-chip and OpenFlow switching protocol:
-
Current hardware switches are very strict, allowing only "matching operation" process on a set of fixed fields
-
OpenFlow specification only defines the limited packet processing operation
We propose RMT (reconfigurable matching table) model, which is a RISC inspired by, for new pipeline architecture switch chip. We identified some basic moves primitives to specify how header in hardware. RMT allowed without changing the forwarding plane hardware changes in the field, as in OpenFlow, the programmer can specify any of a plurality of width and depth match table, and is limited only by the overall resource limit, and each table can be configured as match on any field. However, compared with OpenFlow, RMT allows programmers to more fully modify all header fields.
Our paper describes the 64-port switching chip 10 Gb s design / implementation of RMT model, it showed specific design, flexible OpenFlow switch hardware embodiment or almost no additional cost function can be realized.
Background / problem:
Good abstract crucial in a computer system, because they can change the system to process and simplify the programming at a higher level. The key abstractions, the network has made progress --TCP provides a connection between the endpoint abstraction queue, IP provides a simple datagram abstracted from the endpoint to the edge of the network, but the routing and forwarding within the network is still routing protocols and forwarding behavior complex confusion, the control and forwarding plane always intertwined in a closed internal vertical integration.
SDN forwarding plane programming control allows network owners to add new functionality to the network at the same time to copy an existing protocol behavior, OpenFlow as an interface between the control plane and forwarding plane, it has become the method based Match + Action is well known.
Match achieve the common software on the CPU + Action is not difficult, but for today we hope to achieve speed, about 1TB / s, we need dedicated hardware parallelism. Since the switching speed of the switching chips than two orders of magnitude faster the CPU, an order of magnitude faster than the network processor, and this trend is unlikely to change. Therefore, we need to consider how to implement in hardware Match-Action, to take advantage of pipelining and parallelism, while considering the constraints table memory chip.
There is a natural trade-off between speed and programmability, now support the new features often need to replace hardware. If Match-Action allows only enough hardware reconfiguration in the field, so that you can support new packet processing at runtime, it will change our view of network programming. The real question here is whether a reasonable cost can get the job done without sacrificing speed.
Then there are two alternative ways:
-
Single match table: The easiest method is to (a single match table) referred to the SMT model we abstract semantic matching. In the SMT, the controller will tell the switch to match any single set of header fields in data table entries match, the parser assumes SMT locate and extract the correct header field with the matching tables. However, a closer study shows that the classic problem of the high cost SMT model, the table needs to be stored for each combination of head, in many cases wasteful.
-
Multiple matching table: MMT (multiple matching table) is improved natural SMT model. MMT on a significance beyond the SMT, which allows a plurality of smaller tables matching by matching a subset of a group field, table arranged in pipeline stages. By additional information transmitted to the packet header or modification stage j, i may be the processing stage depends on the stage of j <i processing stage j. However, the existing switching chip small number of tables, sets at the time of manufacturing a chip width, and the depth order of execution, which severely limits the flexibility. Further, the switch chip is provided with corresponding common processing behavior only limited action list, e.g., forwarding, discarding, decrement TTL, push VLAN or MPLS header and the GRE encapsulation. So far, OpenFlow specify only a subset of them, this set of actions is not easy to expand, not very abstract.
Solution:
Reconfigurable matching table: We explored the MMT improved model called RMT (reconfigurable matching table). Like as MMT, RMT is desirable to allow a group of pipeline stages, each stage having a matching table of any depth and width.
RMT beyond the MMT, which allows reconfiguration of the data plane in four ways:
-
You can change the field definition and add new fields
-
You can specify the number of match tables, topology, width and depth, while the overall resource limited only by the match bit
-
You can define new actions, such as writing a new congestion field
-
Any modified data packet may be placed in the specified queue to any subset of the output ports, and rules specified for each queue queue.
We describe a RMT switch architecture, the architecture allows any defined headers and sequence headers, arbitrary match field by any number of tables, any written header field (rather than the package body) in size, and the status of each package updates.
Implementation details:
We RMT called "allows subsequent pipeline stage", each having a matching table of any depth and width that matches the field ", composed by the parser switch RMT to enable the fields match, then the match any number of stages .
A header parser output vector, which is a set of header fields, passing through a series of vectors suitable logic stages, each stage abstracts the packet processing (e.g., Ethernet or IP process) logic cell 1a, each logical configuration allows phase matching to match the size of the table.
Over the RMT allowed to add new fields by modifying the parser, modifying matched by matching the new field memory, to a new stage by modifying the instructions, and to modify the new queues each queue queue's. The most important is that it allows the future to modify the data plane without modifying the hardware.
We promote a architecture shown in FIG implemented, the architecture consists of a number of physical pipeline stages, according to the resource requirements for each logical stage, a smaller number may be mapped to the phase of the RMT logic stage. The advantage is that it uses a tiled architecture is short-term, can be reconfigured with minimal waste of resources.
Stage pipeline architecture requires a physical limit to allow for gigabit speed:
-
Match limitation: the design must contain a fixed number of physical as well as a set of fixed matching phase resources
-
Restriction packet header: packet header must be restricted vector contains fields for operation of matching and
-
Memory Limit: Each physical matching stage includes the same memory size of the table
-
Movement limiting: In order to achieve, must limit the number and complexity of each stage instruction