CONTENT
BACKGROUND
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 the packet from one application pipeline to another
Analysis
Can lead to an optimal solution for a 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