Evaluation
9.2 Physical Pipelines
The evaluation uses physical pipelines based on the target hardware identified in chapter 4. The pipelines recreate the functionality of the hardware’s support for SDN standards in the SPA as faithfully as possible. However, without ac-
cess to the full specification of each vendor’s ASIC, the evaluation must make assumptions about how best to define the SPA pipeline. While these assump- tions mean that this is not a perfect demonstration of Shoehorn’s suitability for mapping to real world hardware, the physical pipelines do represent a diverse range of configurable and fixed-function pipelines.
Most significantly, this evaluation assumes that hardware is capable of recircu- lating packets, while retaining the ingress port metadata, and keeping track of the number of times the packet has been recirculated. Recirculation can always be achieved through the use of loop-back transceivers or similar methods, but retaining the metadata may be more challenging. This evaluation assumes any table that matches ingress port or tunnel ID is capable of inferring the recircu- lation metadata, and that if such a table can set a metadata field (for instance the VRF field in the OF-DPA), then any subsequent table that matches that metadata field can also infer the recirculated metadata.
This section describes each physical implementation, and notes any assump- tions that the evaluation made.
9.2.1 Aruba
The Aruba uses a configurable pipeline, and consequently is very easy to define in the SPA. There are two major assumptions that this evaluation has made about the Aruba pipelines.
The first is that the pipeline is capable of performing lpm matches on IP source and destination fields. Both the Cisco and the Aruba use OpenFlow Table-Features messages to configure their pipelines, but Table-Features messages cannot indicate alpmmatch. This evaluation assumes that this hard- ware can support these matches as lpm matches are a fundamental feature of
Layer 3 switches. This assumption had little impact on the outcome of the eval- uation for the Aruba pipeline, however, as it does not support decrementing TTL fields, which every virtual pipeline that used lpmmatches also required.
The second assumption, is that actions can be deferred arbitrarily throughout the pipeline. The Aruba OpenFlow implementation supports bothApply-Actions and Write-Actionsinstructions, but in the Shoehorn architecture actions are applied by Action Modules at arbitrary points throughout the pipeline. An OpenFlow implementation could support this by writing to metadata and then, in a subsequent table, match the metadata, and apply the appropriate actions, but the Aruba OpenFlow implementation does not support metadata. This evaluation assumes that the Aruba pipeline can achieve this result using a similar method.
The Aruba OpenFlow implementation is unable to recirculate packets. It has a flexible pipeline, however, so it did not require recirculation to map any of the virtual pipelines in this evaluation.
9.2.2 Cisco
The Cisco OpenFlow implementation uses Table-Features messages to con- figure its pipeline, similar to the Aruba implementation. Consequently this evaluation makes the same assumptions as with the Aruba pipeline. Unlike the Aruba pipeline, the Cisco pipeline can decrement TTL fields, so assuming that it can perform lpm matches is more impactful.
Discussion with engineers at Cisco has indicated that the Cisco ASIC is capable of supporting metadata in the OpenFlow pipeline, although the OpenFlow implementation does not currently support this [44]. Therefore, the method proposed above to support Action Modules is possible with the Cisco ASIC.
Furthermore, the Cisco ASIC can recirculate packets natively, and therefore could achieve the same result using packet recirculation.
9.2.3 OF-DPA
The OF-DPA pipeline is well specified, and requires few modifications to be expressed in the SPA. The OF-DPA has a Policy ACL table, which performs ternarymatches on a variety of fields, and can drop packets or send them to group tables. The OF-DPA applies the Policy ACL table near the end of the pipeline, to allow its actions to overwrite the actions of previous tables, such as the Routing table. In the Shoehorn architectures, however, overwriting actions is not possible. Instead, our evaluation places the Policy ACL table in a control block before the Routing table, so that if the Policy ACL table applies actions to a packet, it will not reach the subsequent tables. This ensures the packet handling is correct, but may cause inaccurate counters in some tables.
9.2.4 SAI
The SAI has an existing P4 definition for the behavioural model architecture, making translation into Shoehorn simple. The P4 definition does not support ACL tables, however. This evaluation assumes that the ACL tables can support any entry supportable by both the Nvidia and OF-DPA pipelines.
The SAI pipeline makes extensive use of metadata, which is largely unutilised by Shoehorn. Consequently, the evaluation implementation does not expose the full functionality of the SAI pipeline, such as STP tables.
9.2.5 Nvidia
The Nvidia OpenFlow pipeline frequently redirects traffic to the legacy pipeline for additional processing. As the legacy pipeline is not clearly defined, this evaluation omits that functionality. The only other assumption the evaluation implementation required was that the pipeline is capable of applying actions throughout the pipeline, in a similar manner to the Cisco and Aruba. The Nvidia OpenFlow implementation does include metadata, so the only assump- tion is that the metadata can be written to combine actions accurately.