Content
Background
Application Co-existence and Integration Challenges
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