Contents

• 1 Background
• 1.1 Application Co-existence and Integration Challenges
• 1.2 Case-by-Case Approach
• 1.3 Ingress De-multiplexing
• 2 Genius Proposal
  • 2.1 Generic Functions for Multi-Network Service Support
  • 2.2 VPN Service Modules and Inter-relationships
  • 2.3 Interface Manager
    • 2.3.1 Defining Granular interfaces (ODL-interfaces data-model)
    • 2.3.2 Binding Services on an Interface
    • 2.3.3 Service binding dataplane semantics
    • 2.3.4 Making SBI protocol agnostic (South bound renderers)
  • 2.4 Shared Overlay Tunnel Service
  • 2.5 Aliveness Monitor
  • 2.6 ID Manager
  • 2.7 MD-SAL UTIL
    
    

Background

Application Co-existence and Integration Challenges

• Partitioning of OpenFlow Resources
  • Every application must have their private flow state space (on every switch)
    1. 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
    1. 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
    1. Design time coordination between different applications
  • Ingress demultiplexing (aka “Table 0 Problem”)
    1. 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
    1. Control plane: MD-SAL service APIs between applications?
    2. Data plane: Direct GOTO Table to transfer packet from one application pipeline to another
• Analysis
  1. Can lead to optimal solution for group of specific applications
  2. Design time coordination needed for every detail
  3. Hard-coded dependencies between applications
  4. 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:
  1. 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