Thoughts on Potential OF Features Martin Casado Brandon

Thoughts on Potential OF     Features Martin Casado  Brandon

Thoughts on Potential OF Features Martin Casado Brandon Heller Glen Gibb Rajiv Ramanathan Leon Poutievski Edward Crabbe You Rough S

About Thoughts on Potential OF Features Martin Casado Brandon

PowerPoint presentation about 'Thoughts on Potential OF Features Martin Casado Brandon'. This presentation describes the topic on Thoughts on Potential OF Features Martin Casado Brandon Heller Glen Gibb Rajiv Ramanathan Leon Poutievski Edward Crabbe You Rough S. The key topics included in this slideshow are . Download this presentation absolutely free.

Presentation Transcript

1. Thoughts on Potential OF 1.1 Features Martin Casado, Brandon Heller, Glen Gibb, Rajiv Ramanathan, Leon Poutievski, Edward Crabbe, You

2. Rough Schedule This week: TTL decrement LPM on Non-IP fields / Non-contiguous masks Multipath Multiple Tables Next week Tunnels and Tags Misc Openflow Changes uint32 for port speeds and port ID space Ability to add and delete ports dynamically Multiple tables Following Weeks Multiple Tables

3. TTL Decrement Required for loop prevention, diagnostics Generalized vs proto specific implementation: Perception is not a great deal of demand for generalized field decrement Required for IP, MPLS, various diagnostic tools (traceroute etc) protocol changes for IP/MPLS field decrement: Match on TTL TTL decrement action Action on ttl 0 would generally be to forward to controller Chksum computation implied

4. LPM on Non-IP Required for some proposed DC architectures (eg: Portland) Perhaps also allow Non-contiguous masks? (some odd use cases such as overloading IPv4 addresses in MAC for in DC src routing) Perhaps just non-contiguous IP and MAC fields How to implement in backwards compatible manner

5. Multipath Simple use case: load balance packets across k parallel links based on routing protocol decision Flows are mapped to link based on results of n tuple hash (typically across src/dst IP, src/dst TCP port or similar) to avoid flow reordering

6. Multipath Implementation based on concept of a multipath group Each group represents a set of action buckets, one of which is chosen for each packet. For LAG: bucket port For L3 ECMP: bucket port, MAC rewrite Group existence and membership established dynamically via OF protocol. This decouples config protocol from routing decisions / time scales. Group management implemented on the controller Eg: remove/add group on port down/up events when some capacity threshold is reached The following operations would be required, whether explicit of implicit: Create/delete multipath group Add/delete port from group Query group membership Perhaps a generalized set of actions on flow

7. Multipath Implementation Example (1) Implicit Group Definition (1) Implicit Group Definition (1) Explicit Group Definition (1) Explicit Group Definition

8. Implicit VS Explicit Groups Implicit Advantages: simpler for developer no need to consider two messages, message order or consistency Explicit Advantages: simpler, dumber switch Provides level of indirection, more efficient

9. Multiple Tables Single table leads to combinatoric explosion in both table size and number of flow mod messages eg: from any, to any, tcp port 179, count, drop Each action must be expanded across every re;evant address in table, resulting in cartesian product of fields matched against

10. Multiple Tables Model is based on pipeline register (lookup scratchpad) Is used to track progress of lookup through pipeline Model requires addition of two new actions: Resubmit: resubmit packet for another lookup Write: write a value into the register. Register value should increase monotonically to prevent loops. Model also requires ability to match on register

11. Multiple Tables Just A Few of the Open Issues Conflicts between actions in both parallel and serial pipelines HAL to determine conflict or programmers responsibility? Override / accumulate action flag ? table type conflicts - send a reject message? table overflow - send a reject message? exposure of parallel tables is there any use case of non serializable action?