API Design Challenges for Open Router Platforms on Proprietary Hardware

Jeffrey C. Mogul, Praveen Yalagandula, Jean Tourrilhes, Rick McGeer, Sujata Banerjee, Tim Connors, Puneet Sharma HP Labs, Palo Alto {Jeff.Mogul,Praveen.Yalagandula,Jean.Tourrilhes,Rick.McGeer,Sujata.Banerjee,Tim.Connors,Puneet.Sharma}@hp.com

ABSTRACT ern router hardware, while maintaining the useful prop- erties of commodity operating systems: software porta- Most switch vendors have launched “open” platform de- bility between vendors, isolation between software com- signs for routers and switches, allowing code from cus- ponents, easy management, etc. Such an API would also tomers or third-party vendors to run on their proprietary be the boundary between open-source upper layers, and hardware. An open platform needs a programming in- lower layers that the router vendors insist on maintaining terface, to provide switchlets sufficient access to plat- as proprietary trade secrets. form features without exposing too much detail. We dis- cuss the design of an abstraction layer and API designed Previously, Handley et al. [7, 8] described XORP, an to support portability between vendor platforms, isola- eXtensible Open Router Platform. XORP provides a tion between switchlets and both the platform and other nice abstraction for building relatively high-performance switchlets, high performance, and programming simplic- routers on top of commodity platforms. While XORP ity. The API would also support resource-management potentially could run on a proprietary-hardware open abstractions; for example, to allow policy-based alloca- router platform (PHORP), we are not aware of such an tion of TCAM entries among multiple switchlets. implementation. We also believe that XORP’s abstrac- tions, such as its Forwarding Engine Abstraction (FEA), 1 INTRODUCTION expose too little of the power of modern router hardware, and do not sufficiently address the scarcity of certain 1 Traditionally, router and switch platforms have either hardware resources. been commodity platforms running open but slow im- In this paper we explore the design requirements for an plementations, or proprietary hardware running closed “Open Router Proprietary-Hardware Abstraction Layer,” but fast implementations. Most router vendors currently or Orphal. Orphal’s goals include support for portability follow the closed-but-fast model, which gives them com- of third-party components between different proprietary plete control over system quality, but has become a bar- platforms; isolation between these components; expos- rier to innovation. ing as much of the hardware’s functionality as possible; Recently, major router vendors have initiated pro- and managing scarce hardware resources. grams to provide open router platforms (ORPs), which Casado et al. [4] argue that software-only routers are allow third parties to develop software extensions for not fast enough, network processors are too complex to proprietary hardware. ORPs potentially support faster program, and hardware-based designs (including com- deployment of novel networking features; for example, modity forwarding chips) have been too inflexible. They one could deploy Stanford’s OpenFlow [13] on an ORP. propose a redesign of hardware-level forwarding mech- While the typical vendor’s approach to an ORP is to anisms to provide a clean, simple, and flexible interface provide a Linux environment running on an x86 proces- between hardware and software. We agree with them that sor as part of the platform, the traditional Linux API is the best path to flexible and efficient routers depends on the wrong abstraction. These boxes are interesting pre- co-evolving router hardware, extensible router software, cisely because they have specialized hardware features and a clean interface between them. that standard Linux does not (should not) support. Figure 1 shows how Orphal fits into a PHORP archi- We need an ORP API that offers controlled access tecture. Orphal sits above the vendor-proprietary hard- to these hardware features. Ideally, this API would ex- ware and software, and also above the commodity hard- pose all of the functionality and performance of mod- ware and operating system, although we see no reason to modify the standard OS APIs. (The figure shows Linux 1We use “router” and “switch” interchangeably in this paper. as the OS, but it could be any reasonable OS, and per- haps a virtual-machine layer as well.) In practice, Or- phal would be implemented as a combination of device XORP Ethane Controlled sharing Orphal must provide controlled sharing of abstract resources such as forwarding-table . . . Click OpenFlow . . . entries, as well as the real resources (such as hash-table Orphal and TCAM entries) used to implement these abstrac-

Vendor tions. Linux software For example, if two switchlets want to control the ac- Proprietary x86 hardware tions for packets for a given destination – e.g., a firewall switchlet and a QoS switchlet – how should Orphal de- Figure 1: Layering in an open router platform cide which switchlets get that control? If two switch- drivers and user-mode libraries. lets want to process the same packet, which one gets it One or more switchlet modules run above Orphal. In first? We believe that prior work on kernel packet fil- the figure, we show two: a Click [10]+XORP stack, and ters [15, 20] provides some useful models; for example, an OpenFlow [13]+Ethane [3] stack, but these are just Orphal could assign precedence (priority) levels to each examples. This is not an “active networks” approach; we switchlet, and let each switchlet declare whether lower- expect switchlets to be installed by the router’s owner. precedence switchlets should see the packets it handles. This position paper describes some of the design Isolation One goal of an ORP is to allow composition challenges for Orphal. We first describe a high-level of switchlets from different third-party component ven- overview of a plausible design. Then, for concreteness, dors. While we need not assume that switchlets might we focus on issues related to one particular kind of spe- be malicious, the potential remains for unexpected “fea- cialized hardware: Ternary Content Addressable Memo- ture interactions.” (This is a problem even when all com- ries (TCAMs) used for line-rate lookups. This is moti- ponents come from the same vendor.) Two switchlets vated by our experience porting OpenFlow (see sec. 4). running on top of Orphal should not accidentally inter- fere with each other, either directly or indirectly. Thus, 2 ORPHAL API DESIGN OVERVIEW the system must prevent switchlets from interfering with Orphal’s goals include resource management; controlled each other’s code and private state. Isolation is usually sharing; isolation; hardware reprogrammability; perfor- accomplished either with a process-like abstraction, or mance; portability; and manageability. Orphal differs using a virtual machine abstraction. This choice is likely from the API of a general-purpose OS mostly because to be made by the router vendor, and Orphal should sup- Orphal must expose interesting, router-specific hardware port either model, as transparently as possible. without sacrificing run-time efficiency. Hardware reprogrammability We expect some Resource management A high-performance router is router platforms to provide programmable hardware inherently a real-time environment, with potentially (not just configurable hardware, such as TCAM tables). scarce resources both in the commodity computation For example, an ASIC in the packet-processing fast platform, and in the proprietary hardware. Routers are path could support programmability for deep-packet often required to enforce QoS requirements, which can- inspection (DPI) operations [9]; NetFPGA [16] is not be maintained if the router itself mis-manages its re- another example. Given these programmable features, sources. Orphal needs to support resource management, should Orphal provide an API allowing switchlets to, including allocation of resources among switchlets, con- for example, push arbitrary microcode into an ASIC, sistent with the overall QoS policy and performance con- or would it be safer to simply provide access to a straints of the system. platform-defined library of such functions? Which resources need to be managed? We can as- Performance Orphal must deal with many sume that the commodity OS will manage commodity- performance-related issues, such as support for multi- hardware resources (CPU, RAM, stable storage), while core parallelism in switchlet execution; prioritizing CPU Orphal will manage router-specific resources such as sharing among switchlets; rate-limiting features of the TCAM entries, hash-table entries, buffer space, pro- platform; etc. We have neither the experience nor the grammable ASICs, etc. We also want to manage power- space to discuss these further. related resources (powering down idle line cards, per- port rate scaling, etc.) using Orphal. One challenge Portability Orphal must expose the platform’s hard- is to define Orphal’s resource management so that it is ware details enough to support high performance, but portable across a range of router hardware with various without exposing too much detail: that would compro- interesting kinds of resources; we believe that this can mise portability, and perhaps isolation. This is a difficult be done using vendor-specific switchlets that Orphal in- challenge, especially since we lack enough experience to vokes via upcalls (see section 2.1). know what really matters. We describe, in sec. 4, our initial experiences trying to map Ethane’s 10-tuple flow- software. XORP provides a useful framework for description model onto a TCAM that supports 5-tuples. these functions. • optimizer/helper modules: We expect that the pro- Manageability Routers must already address many cess of matching higher-level abstractions needed management issues, such as port and routing-protocol by switchlets to the lower-level hardware abstrac- configuration. The introduction of open router architec- tions will require the use of optimization algo- tures creates a new problem: given a multitude of sepa- rithms. Orphal invokes these via upcalls to opti- rately developed switchlets, how does the router admin- mizer switchlets. This form of policy-mechanism istrator create and preserve a stable configuration? separation allows third parties to develop improved XORP, for example, provides a “router manager pro- versions of these modules. cess” (rtmgr) [19] to handle some of these issues. Sup- Optimizer modules can also be used, for example, to port for proprietary hardware probably complicates this provide a backing store for space-limited hardware task, because the introduction of a new switchlet can cre- resources. For example, Orphal could manage the ate new resource conflicts (e.g., not enough TCAM en- hardware TCAM as a cache for a larger table man- tries) and new feature interactions (competing uses for a aged by an optimizer module, in much the same way given TCAM entry). that an OS kernel manages a hardware Translation We believe the router manager will have to check that Buffer as a cache for its page tables. the system can support the switchlet’s minimal require- Additional “helper” switchlets can be used to pro- ments (e.g., that there are enough available TCAM en- vide policy-mechanism separation for functions tries for the switchlet to function) and to provide rollback such as detecting inter-switchlet conflicts in TCAM to a previous configuration if a new one causes trouble. entries. The manager will also have to monitor each switch- let’s dynamic resource consumption, including special- Orphal needs to balance switchlet portability against ized hardware resources, so that the router administrator aggressive use of hardware functions that might not be can make informed decisions. present on all platforms. Thus, a switchlet can provide We also expect administrators will want to upgrade a an optional software implementation for a function, to switchlet to a new version without rebooting the entire be used if Orphal cannot provide the necessary hardware router. This may require Orphal support, especially to support (either because it isn’t there, or because it is over- cleanly undo the hardware-related effects of an old (or subscribed). failed) switchlet. For example, when a switchlet fails or For example, consider a Click module, such as the is removed, its updates to the TCAM should be reversed. existing NetFlow package, that is most naturally imple- mented in hardware if the hardware is available. The 2.1 What is a switchlet? module author could supply both a hardware-based (e.g., A switchlet is simply a module that runs on top of Orphal, NetFPGA) version and a (less efficient) software-based with its own address space and thread(s) of control.2 Or- version, and Orphal could transparently instantiate the phal will support several switchlet categories, including: most efficient version possible. (This leaves open the question of whether Orphal could feasibly change be- • per-packet switchlets: These are invoked, simi- tween versions dynamically; state synchronization and larly to Click elements [10], to handle specific pack- QoS maintenance might make this difficult.) ets. Since high-performance router designs try to avoid handling most packets in software, per-packet 2.2 Example of Switchlets switchlets are mostly useful for exceptional packets. • per-flow switchlets: Some router functions, espe- We describe our initial experience implementing Open- cially for monitoring and sometimes for firewalling, Flow, and how it might be structured as switchlet, in sec. are invoked once or a few times per flow. This 4. Beyond that, we lack space to give detailed examples is less likely to cause performance problems, al- of possible switchlets, but here is a partial list: though given mean flow lengths in the ballpark of • Specialized firewall switchlets could be triggered 12 UDP packets to 50 TCP packets [2], such switch- by DPI hardware to check unusual flows against se- lets might still be reserved for exceptions. curity policies. • control-plane functions: These functions, such • Specialized monitoring switchlets could report on as routing protocols, management protocols, etc., suspicious patterns of flow creations. typically are not directly related to the packet- • NAT switchlets might require access to pro- forwarding fast path, and so are often handled in grammable packet-header rewriting hardware. • Dynamic VLAN switchlets could implement setup 2Others have defined “switchlet” in different ways [1, 5, 17], but we can’t think of a better term. protocols used to establish VLAN membership. 3 APIDESIGN ISSUES switchlets might want packets that match the same TCAM row (e.g., “all TCP packets to port 80”); the The goal of Orphal is to provide a clean interface API needs to manage these conflicts. (See sec. 3.4.) between router-specific programmable hardware, and • Multiple matching rows: Because TCAMs sup- switchlets running on general-purpose CPUs within the port wildcards, two different rows might match the router platform. Routers often have a number of inter- same packet. But TCAM-based designs always re- esting hardware features, such as programmable DPI en- turn the lowest-index entry that matches the packet. gines, TCAMs for route lookups, and other route-lookup Two switchlets might create distinct TCAM entries hardware such as hash tables and programmable header that either overlap, or where one covers the other; extractors. Future routers might have additional spe- what should the system do in this case? The API cialized hardware, such as programmable packet-header needs to manage these conflicts, too. (See sec. 3.4.) rewriters. • TCAM optimization: Given an abstract set of In this paper we limit our detailed discussion to matching rules, one can generate an optimized set of TCAMs, since they are widely used for high-speed for- TCAM entries that provide the most compact (and warding, present some interesting challenges, and are the hence most space- and energy-efficient) representa- focus of our current implementation work (see sec. 4). tion [12, 14]. • 3.1 TCAM API and Resource Management TCAM update (insertion) costs: TCAM-based designs generally must trade off efficient lookups Most high-performance router hardware includes against insertion costs, which can be as high as Ternary Content Addressable Memories (TCAMs). O(n) in the number of rows [6]. The API might One can think of a CAM as a table whose rows each need to manage this tradeoff; it might also need include a tag field to match against; the CAM returns the to synchronize between updates and lookups (or matching row (if any). In a TCAM, tag-field entries are else lookups could yield bad results during up- composed not just of binary 1s and 0s, but also “X” or dates) [18]. “don’t care” values. TCAMs thus allow more compact representations of lookup tables whose tag values can 3.2 A typical TCAM-based hardware design include wildcards. Routers use TCAMs for functions Figure 2 sketches part of an idealized TCAM-based hard- such as IP address lookups and firewall lookups, where ware design, to make some of these design challenges these wildcards are common. concrete. Each line card would have an instance, possi- While TCAMs are often the preferred solution for bly serving several ports. lookup functions, various TCAM parameters are con- An incoming packet is first processed by a pseudo- strained by expense (TCAM structures take a lot of header generator, adding to the real packet header such die area) and power consumption (a TCAM lookup fields as a VLAN tag, the ID of the port where the requires all rows to be active, and TCAMs consume packet arrived, etc. Assuming that the TCAM is not ca. 15W/chip [21].) Thus, TCAMs present some chal- wide enough to do a full lookup in one step, the header lenges for an open router platform, and we explore these extractor manages a multi-stage lookup; it recognizes as an example of a larger set of challenges that the API certain high-level patterns (e.g., “IPv4 packet” or “IPv6 must meet: packet”), extracts the header fields used in each stage • Limited tag-field size: TCAM tag widths are typ- (e.g., first the layer-2 headers, then the layer 3+4 head- ically limited, often to ca. 144 bits (enough for ers), passes these to the TCAM, and decides whether to an IP/TCP 5-tuple) [14]. A single TCAM entry do the next lookup stage. might therefore be insufficient to support a firewall- Many routers use one or more hash tables in addition entry match in a single lookup, since (especially to the TCAM. Hash tables provide a cheaper mechanism with IPv6), too many packet-header bits must be for doing exact-match lookups, such as “what’s the next checked. This can force the hardware to support hop for this flow?”, while TCAMs are appropriate for multiple lookups per packet. The API must allow more complex lookups – especially those including wild- switchlets to express such multi-lookup rules. cards – typical of QoS and firewall (access control list) • Limited number of rows: TCAMs are typically functions. For firewall functions, the line card might also limited to a few thousand rows. Thus, the platform include a port-range classifier, since arbitrary ranges of must treat TCAM rows as a scarce resource, to be port numbers (e.g., “1023–65535”) could consume too allocated among potentially competing switchlets, many TCAM entries. Liu [11] described a range classi- and the API must allow switchlets to express re- fier that uses a modest-sized RAM-based lookup table. source requirements. Additional sequencer/combiner logic coordinates the • Multiple “owners” for one row: Two different multiple lookup stages and combines partial results to L2 addrs Packet Input port L2 fields Metadata L3 addrs Hash table Expanded L3 fields Packet Packet Pseudo− headers Header action Input port header Extractor L4 fields Metadata Generator L4 ports TCAM Port−range Packet classifier Input port Metadata Sequencer/combiner

Figure 2: Idealized TCAM-based lookup path generate a final result, indicating the action to take with a row with a given tag value and action, and an intra- the packet, such as the next-hop address and the output switchlet value to control how rules are ordered. switch port. Returns either an opaque handle for the row, or a The TCAM, of course, is a programmable resource, failure indication. but potentially so are the other functional blocks • tcamDeleteRow(handle): does the obvious thing. (pseudo-header generator, header extractor, port-range • tcamGetRow(handle): returns the corresponding classifier, hash table, sequencer/combiner). TCAM entry, including statistics. Unlike a more abstract API such as XORP, Orphal ex- • tcamRegisterInterest(handle, callbackFunc- poses all of these distinct programmable resources, since tion): specifies a switchlet function to be called they have differing characteristics that could be exploited with each packet that matches the row; the default by sophisticated switchlets. is no callback. This is the way that switchlets can receive packets and/or discover flows. 3.3 What should the TCAM API expose? • tcamConflictCallback(handle, callbackFunc- tion): If another, higher-priority switchlet creates a There are many ways to organize TCAMs and the asso- TCAM row that conflicts with the one associated ciated hardware, and if switchlets are to be portable be- with the handle, this callback informs the current tween hardware platforms, the API must either hide this switchlet that the row has been reassigned to the variation, or expose it in a useful way. Given the chal- other switchlet’s purposes. Section 3.4 discusses lenges listed in section 3.1 (and there are others), perhaps conflicts in more detail. it is implausible to create an API that provides any gen- erality across models and vendors. However, we suspect The TCAM-optimizer API will need to provide certain that by choosing the right level of abstraction for expos- functions, including (among many others): ing the TCAM hardware, Orphal can meet its goals. • Loading a set of TCAM rows: The optimizer’s For example, XORP exposes a high-level “forward- output needs to be loaded into the TCAM; possi- ing engine abstraction” (FEA), but Orphal must expose bly this will require some synchronization so that a lower-level abstraction if the switchlets are to exploit packets are not processed when the TCAM is in an specialized hardware features. There are things that can- inconsistent state. not be expressed explicitly at the FEA level – for exam- • Obtaining the abstract state of the TCAM ple, that certain rules should be stored in the hash table database: The optimizer’s input from Orphal will instead of the TCAM. consist primarily of the union of the TCAM-user There is a useful API abstraction intermediate between requests, plus some policy settings provided by a a raw-hardware “TCAM row” and a high-level “forward- management layer. ing table entry.” Although a TCAM optimizer mod- • TCAM usage statistics: Typically, TCAMs sup- ule will need access to the raw row-level version (“put port hit counters for each row. these bits here”), most switchlets will use a paravirtu- alized view of the TCAM (PV-TCAM), which will en- 3.4 TCAM row conflicts able Orphal to provide the controlled sharing, isolation, Multiple switchlets might try to create conflicting TCAM and resource management properties described in section rows. Orphal’s approach is to detect these conflicts and 2. PV-TCAM rows look almost like real TCAM rows, resolve them using an inter-switchlet priority ranking. but with some additional meta-information, and without (This seems like the simplest approach, but we are ex- a fixed mapping to actual hardware rows. ploring others.) When a low-ranking switchlet tries to The TCAM-user API will need to provide certain create a new row that conflicts, Orphal simply rejects the functions, including (among many others): attempt. However, a high-ranking switchlet can create a • tcamAddRow(tag, action, ordering): Used to add row that conflicts with an existing lower-ranking row, in which case Orphal removes the low-ranking row, inserts 5 SUMMARY the new one, and informs (via tcamConflictCallback) Open router platforms offer tremendous flexibility, but the low-ranking switchlet that it has lost the row. Orphal exploiting the rich variety of router hardware creates lets the switchlets figure out what to do in that case. complexity. Our goal for Orphal is to tame that com- It is not easy to define what a “conflict” is, and plexity; we hope to demonstrate working systems in the conflict-checking is an expensive (NP-complete) pro- near future. cess [12], so checking should not be embedded in Or- phal per se. Instead, Orphal supports plug-in conflict- REFERENCES checking implementations using “helper” switchlets. [1] D. S. Alexander and J. M. Smith. The Architecture of ALIEN. In Proc. Intl. Working Conf. on Active Networks, pages 1–12, 1999. [2] M. Arlitt. Personal communication, 2008. [3] M. Casado, M. J. Freedman, J. Pettit, J. Luo, N. McKeown, and S. Shenker. Ethane: taking control of the enterprise. In Proc. 4 OUR EXPERIENCE WITH OPENFLOW SIGCOMM, pages 1–12, Aug. 2007. [4] M. Casado, T. Koponen, D. Moon, and S. Shenker. Rethinking OpenFlow [13] is a centrally-managed flow-based net- Packet Forwarding Hardware. In Proc. HotNets, Oct. 2008. [5] N. da Fonseca, J. Castro, A.P., and A. Rios. A procedure for work where switches are simple forwarding engines that resource allocation in switchlet networks. In Proc. GLOBECOM, classify packets into flows and act on them according to volume 2, pages 1885–1888, Nov. 2002. a policy supplied by a central controller. We are porting [6] B. Gamache, Z. Pfeffer, and S. P. Khatri. A fast ternary CAM OpenFlow to a commercial switch, the ProCurve model design for IP networking applications. In Proc. ICCCN, pages 434–439, Oct. 2003. 5406ZL, and here report some of the challenges. [7] M. Handley, O. Hodson, and E. Kohler. XORP: an open platform OpenFlow could run entirely in the switch’s software, for network research. SIGCOMM CCR, 33(1):53–57, 2003. [8] M. Handley, E. Kohler, A. Ghosh, O. Hodson, and P. Radoslavov. but that would not support line-rate forwarding, so we Designing extensible IP router software. In Proc. NSDI, pages need to use the TCAM hardware. The controller ex- 189–202, Boston, MA, 2005. pects a flexible flow classifier, so the tricky part is to [9] HP ProCurve. ProVisionTM ASIC: Built for the future. http: match OpenFlow’s flow descriptions (a 10-tuple of phys- //www.hp.com/rnd/itmgrnews/built_for_future.htm. [10] E. Kohler, R. Morris, B. Chen, J. Jannotti, and M. F. Kaashoek. ical ingress port and VLAN IDs; Ethernet source, desti- The Click Modular Router. TOCS, 18(3):263–297, 2000. nation and type; and the standard IP/TCP 5-tuple) with [11] H. Liu. Efficient Mapping of Range Classifier into Ternary-CAM. what the hardware supports. The challenges include: In Proc. Hot Interconnects, pages 95–100, Aug. 2002. [12] R. McGeer and P. Yalagandula. Minimizing Rulesets for TCAM • Limited number of TCAM rows: means not all Implementation. Tech. Rep. HPL-2008-106, HP Labs, 2008. flows can be classified in hardware. So, we insert a [13] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Pe- terson, J. Rexford, S. Shenker, and J. Turner. OpenFlow: enabling final wild card entry in the TCAM to divert packets innovation in campus networks. SIGCOMM CCR, 38(2):69–74, from other flows to the software stack. We try to 2008. minimize such slow-path packets by keeping busy [14] C. R. Meiners, A. X., and L. E. Torng. Algorithmic Approaches flows in the TCAM. to Redesigning TCAM-Based Systems. In Proc. SIGMETRICS, • June 2008. Limited tag-field size: TCAM widths (e.g., 144 [15] J. Mogul, R. Rashid, and M. Accetta. The packer filter: an ef- bits) are typically chosen to support lookup on the ficient mechanism for user-level network code. In Proc. SOSP, IP/TCP 5-tuple (32+32+16+16+8 = 104 bits). pages 39–51, 1987. OpenFlow’s 10-tuple, which includes 48-bit MAC [16] J. Naous, G. Gibb, S. Bolouki, and N. McKeown. A Program- ming Model for Reusable Hardware in NetFPGA. In Proc. addresses, is too big for such TCAMs. However, PRESTO, Aug. 2008. our switch supports multiple TCAM lookups/packet [17] J. E. van der Merwe and I. M. Leslie. Switchlets and Dynamic at line rates, so we support the OpenFlow tuple with Virtual ATM Networks. In Proc. 5th IFIP/IEEE Intl. Symp. on a multi-stage lookup. Integrated Network Management, pages 355–368, 1997. [18] Z. Wang, H. Che, and S. K. Das. CoPTUA: Consistent Policy Ta- ble Update Algorithm for TCAM without Locking. IEEE Trans. When a packet arrives for an unknown flow, the Open- Comput., 53(12):1602–1614, 2004. Flow forwards it to the central controller, which updates [19] XORP Project. XORP Router Manager Process (rtrmgr) Version that switch (and perhaps others) with new flow-specific 1.4. http://www.xorp.org/releases/1.4/docs/rtrmgr/ forwarding rules. Using Orphal, we could implement rtrmgr.pdf, 2007. [20] M. Yuhara, B. N. Bershad, C. Maeda, and J. E. B. Moss. Efficient OpenFlow as a switchlet that forwards no-match pack- packet demultiplexing for multiple endpoints and large messages. ets to the controller, and installs controller-supplied re- In Proc. USENIX Winter Tech. Conf., pages 153–165, 1994. sponses into the forwarding table. The controller deals in [21] F. Zane, G. Narlikar, and A. Basu. Coolcams: power-efficient 10-tuples; we intend to use a helper switchlet to convert TCAMs for forwarding engines. In Proc. INFOCOM, volume 1, pages 42–52, 2003. these into patterns that the switch’s TCAM can handle. This helper could also be used by other switchlets, such as firewalls.