Content

Table of Contents
outline true

Background

Application Co-existence and Integration Challenges

• Partitioning of OpenFlow Resources

  1. 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”)
  1. Packets entering the switch have to be directed to the correct application pipeline
  2. Applications cannot simply write ingress flow entries into table 0 without coordination
  3. Need smaller granularity than OF port (e.g. VLAN, VNI, etc)? generalized interface concept
  4. Co-existence of multiple applications on the same interface
  5. Multi-tenancy: Several isolated service instances of the same application
• Integration/Co-operation of different applications
  1. Control plane: Service APIs between applications
  2. Data plane: Transfer packets between the pipelines of different applications
     1. Take the use of various packet metadata into account!
  3. Each application comes with its own overlay solution

Case-by-Case Approach

• Chosen approach in ODL Beryllium between SFC, GPB and Netvirt
  1. Partitioning of OpenFlow Resources
     1. Design time coordination between different applications
  2. 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
  3. Integration/Co-operation of different applications
     1. Control plane: MD-SAL service APIs between applications?
     2. Data plane: Direct GOTO Table to transfer the packet from one application pipeline to another
• Analysis
  1. Can lead to an optimal solution for a 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