1 / 11

Thoughts on Potential OF 1.1 Features

Thoughts on Potential OF 1.1 Features. Martin Casado, Brandon Heller, Glen Gibb, Rajiv Ramanathan, Leon Poutievski, Edward Crabbe, You. Rough Schedule. This week: TTL decrement LPM on Non-IP fields / Non-contiguous masks Multipath Multiple Tables Next week Tunnels and Tags

dakota
Download Presentation

Thoughts on Potential OF 1.1 Features

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

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 • Explicit Group Definition • Implicit 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 TablesJust 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?

More Related