Jump to: navigation, search

Genius : An Overview


Application Co-existence and Integration Challenges

  • Partitioning of OpenFlow Resources
    • Every application must have their private flow state space (on every switch)
      • Flow tables, group table, meter table, cookies
  • Ingress demultiplexing (aka “Table 0 Problem”)
    • Packets entering the switch have to be directed to the correct application pipeline
    • Applications cannot simply write ingress flow entries into table 0 without coordination
    • Need smaller granularity than OF port (e.g. VLAN, VNI etc) ? generalized interface concept
    • Co-existence of multiple applications on the same interface
    • Multi-tenancy: Several isolated service instances of the same application
  • Integration/Co-operation of different applications
    • Control plane: Service APIs between applications
    • Data plane: Transfer packets between the pipelines of different applications
      • Take the use of various packet metadata into account!
    • Each application comes with its own overlay solution

Case-by-Case Approach

  • Chosen approach in ODL Beryllium between SFC, GPB and Netvirt
    • Partitioning of OpenFlow Resources
      • Design time coordination between different applications
    • Ingress demultiplexing (aka “Table 0 Problem”)
      • All application write into table 0, but the flow entries and priorities have been agreed at design time to avoid unwanted interference
    • Integration/Co-operation of different applications
      • Control plane: MD-SAL service APIs between applications?
      • Data plane: Direct GOTO Table to transfer packet from one application pipeline to another
  • Analysis
    • Can lead to optimal solution for group of specific applications
    • Design time coordination needed for every detail
    • Hard-coded dependencies between applications
    • Does not scale to many applications

Ingress De-multiplexing

  • Multiple applications writing into table 0 (directly or through an Ingress Manager function)
  • Flow conflict detection mechanisms do not allow for any overlap between flows
  • Overlap (or rather refinement) should be allowed using priorities to disambiguate:
    • e.g. packets on in_port with certain DMAC to application A, all the rest to application B
  • How can a generic Ingress Manager ensure that there is no semantic conflict between the flows if the simple non-overlap criterion is not sufficient?

Genius Proposal

Generic Functions for Multi-Network Service Support

  • Any ODL application can use these to achieve at minimum interference-free co-existence with other applications using the services
  • Provide support for co-operation between applications with the minimal amount of design-time coordination and hard-coded dependencies
  • Use APIs to move design-time coordination to run-time
    • Generic infrastructure APIs to avoid direct coupling where possible
    • Direct inter-application (client-server) APIs where necessary for stronger coupling
  • Factor out commonly used functions into shared services to avoid duplication & waste of resources, e.g.
    • Overlay Tunnel Manager
    • ID manager
    • MD-SAL Util

VPN Service Modules and Inter-relationships


Interface Manager

  • Models generic interfaces as attachment point for applications
    • Supports Hierarchy of: Port, VLAN, VXLAN Trunk, VXLAN VNI, GRE Tunnel, ...
    • Extendible to arbitrary other types of interfaces (virtual link, VPN interface, …)
    • Interface ID/tag system wide unique identifier in control/data plane.
    • Ingress interface tag stored in metadata
  • Handles ingress de-capsulation and de-multiplexing
    • Owns table 0 (and possibly additional tables needed for demultiplexing of interfaces)
    • Application bind to interfaces through API and register application-specific instructions/actions to be added to the interfaces ingress flow entry (e.g. write metadata, goto table)
    • Each bound service is assigned to a separate interface handle, no risk of interference on ingress traffic
  • South bound protocol agnostic
    • Ability to plug in different south bound renderers
    • Provides tunnel monitoring services
    • Handles egress encapsulation and output, service processing priority

Defining Granular interfaces (ODL-interfaces data-model)



Binding Services on an Interface

  • Service binding data model used to bind a service on a particular interface
  • Service module configures following parameters
    • Service-Priority
    • Service-Name
    • Service-Type
    • Service-Info
      • (for service-type openflow-based)
      • Flow-priority
      • Instruction-list
  • Interface Manager maintains a Service dispatcher table to regulate pipeline dynamically between services
  • Listens to service-binding changes and accordingly programs the dataplane (Table 0 & Service Dispatcher)

Service binding dataplane semantics


Making SBI protocol agnostic (South bound renderers)

  • Provide a flexible way to support multiple south bound protocols
  • North-bound interface/data-model is decoupled from south bound plugins
  • NBI Data change listeners select and interact with appropriate SBI renderers
  • New renderers can be added to support new Southbound interfaces/protocols/plugins
  • Needs to be re-concilied with Netvirt re-design proposal


Shared Overlay Tunnel Service

  • Provides tunnel creation/management services
    • Can be configured to automatically create a homogenous bi-directional tunnel mesh (VxLAN/GRE/others) between agiven group of DPNs
    • API to add new nodes into an existing tunnel mesh
    • API to create uni-directional tunnels from a DPN to an external IP node (CE router) which may not be under SDN control
    • Support for tunnel level redundancy by creating a logical-group-interface, combining more than one tunnel interfaces, and allow for load-balancing or failovers in the group
  • API support to control monitoring of tunnel interfaces
  • API to get egress-actions and ingress-rules/bindService for specified uni-directional tunnel
  • NB Tunnel Up/Down events for services/ user-facing / analytics apps

Aliveness Monitor

  • Provides Controller driven monitoring services for
    • Point-to-point interfaces (VxLAN/GRE)
    • From an interface to destination IP Node
  • Consumes services from ARP, LLDP, Ping Modules
  • Generate Aliveness Events
  • Interface manager listens to Aliveness events and updates operational-state of interfaces
  • Consumers register for monitoring services specifying monitored interfaces and monitoring parameters
  • Uses –
    • Physical topology monitoring
    • monitoring of non-BFD transport tunnels
    • Service Function Monitoring

ID Manager

  • Generates and provides unique integer IDs from a pre-configured ID-Pool with configured range to requesting services
    • APIs for C/D of ID-Pool, assignment and lookups of IDs to services
  • Dual modes of operation
    • Consistent ID generation – consistently provide the same ID for a particular unique key String, Id-value is retained across cluster restarts, and associated with unique key (implemented)
    • Generic ID assignment, no guarantees of consistency or persistence (not implemented)
  • Can be used to assign IDs for and manage resources such as Openflow Tables, Groups, Meters, Service IDs
  • Used by Interface Manager for mapping service instances to logical tags in the data plane


  • Provides Java interfaces to interact with MD-SAL DS and southbound OF-plugin.
    • APIs for programming Flows & Groups
    • APIs for Data-Store Read/write
    • Generic CDN listener
  • Others?