1 / 32

OpenFlow + : Extension for OpenFlow and its Implementation

OpenFlow + : Extension for OpenFlow and its Implementation. Hongyu Hu, Jun Bi, Tao Feng, You Wang, Pingping Lin Tsinghua University 2011-08-12. Outline. Problems about current Internet What OpenFlow brings to us Some aspects need to be Improved in OpenFlow

tola
Download Presentation

OpenFlow + : Extension for OpenFlow and its Implementation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. OpenFlow+: Extension for OpenFlow and its Implementation Hongyu Hu, Jun Bi, Tao Feng, You Wang, Pingping Lin Tsinghua University 2011-08-12

  2. Outline • Problems about current Internet • What OpenFlow brings to us • Some aspects need to be Improved in OpenFlow • OpenFlow+: four extensions for OpenFlow • OpenFlow+’s implementation • Benefits of OpenFlow+ • Applications of OpenFlow+ • Conclusions and future work

  3. Problems about current Internet • Internet has made great success and big progress. • However, the network-layer of Internet and the network devices in Internet have been relatively stagnant. • Few changes or improvements have been made in last forty years, which is a stark contrast to the prosperity of the application-layer of Internet. • In our opnion, all of these is mainly due to the lack of openness in the network-layer.

  4. What OpenFlow brings to us • OpenFlow aims to enable innovation for the network-layer and network devices. • Valuable thoughts that OpenFlow brought to us: • 1) The design of FlowTable in the data plane realized the standardization, simplification and openness of network hardware. • 2) The design of OpenFlow protocol realized the standardization and openness of the access interfaces to network hardware. • 3) User-defined control logics can be easily added to the Controller as new components. • 4) The centralized computing mode designed in OpenFlow makes some functions or services based on global information possible.

  5. What OpenFlow brings to us

  6. Some aspects need to be Improved in OpenFlow • Standard hardware in OpenFlow needs to be extended. • FlowTable hardware in OpenFlow can be realized low-costly and quickly. • Control mode needs to be extended. • Communication interface needs to be extended.

  7. OpenFlow+: four extensions for OpenFlow • We proposed some extensions for OpenFlow (OpenFlow+) in this paper: • Standard hardware extension • Control mode extension • Communication interface extension • Low-cost FlowTable realization

  8. Extensions 1 - More Hardwares • More standard hardware resources need to be exposed and extended • Only FlowTable hardware is not enough • Other hardwares become mature • Little difference of these hardware in different vender’s devices • ACL&QoS, FIB, and Sample hardwares are exposed for outside control logic

  9. Extensions 1 - More Hardwares

  10. Extensions 2 - More Control Modes • A coexisting collaborative mode of distributed computing and centralized computing is needed. • The pure external centralized control mode is deficient in control efficiency and function maturity. • The pure internal distributed control mode is deficient in global coordinate computing.

  11. Extensions 2 - More Control Modes

  12. Extensions 2 - More Control Modes • Rules to confirm both types of computing to work together and collaborate smoothly are designed: • Both type of control logics can exchange data information with each other. • Both type of control logics have the same abilities to control the open hardware resources. • If control conflicts occurs to same hardware resources, we designed some rules to solve these conflicts.

  13. Extensions 2 - More Control Modes • Rules to resolve control conflicts: • Establish an arbitration module to execute the optimal selection for both controls from the inside and outside. • Use fixed priority levels to choose the optimal control. • Both of the control operations will coexist.

  14. Extensions 3-Data reorganized by TLV • To support more types of information exchange between the control plane and the data plane, and to support the easy extension of the length of existing information in the OpenFlow protocol, we introduce TLV (Type Length Value, TLV) format to the OpenFlow protocol to reorganize the information in it.

  15. Extensions 3-Data reorganized by TLV • TLV format can: • Efficiently organize data with variable length • Conveniently implement the extension for the length and type of data • In TLV format, each piece of data is organized by the triple of (Type, Length, Value) • TLV can be used or arranged recursively

  16. Extensions 3-Data reorganized by TLV Table 1. TLV general format.

  17. Extensions 3-Data reorganized by TLV • It will become very easy for us to extend IPv4 address format to IPv6 address format if the TLV format is used in the organization of FlowTable.

  18. Extensions 4 – Using existing hardwares to realize FlowTable • Many mature hardware resources inside devices can be utilized to implement the base functions of FlowTable, such as ACL&QoS hardware tables and FIB hardware tables. • When using the combination of ACL&QoS and FIB hardware to implement FlowTable, two different types of FlowTable are needed: • ACL&QoS-type FlowTable • FIB-type FlowTable

  19. Extensions 4 – Using existing hardwares to realize FlowTable • On the FlowTable Sender side: • FlowTable needs to be organized and described by two kinds of TLVs. • Different values of “Type” field in TLVs identify different types of FlowTable. • Any type of FlowTable contains three sub-TLVs: Header sub-TLV, Action sub-TLV, and Counter sub-TLV(optional). • In different types of FlowTable, the specific content of these three sub-TLVs may be different.

  20. Extensions 4 – Using existing hardwares to realize FlowTable

  21. Extensions 4 – Using existing hardwares to realize FlowTable

  22. Extensions 4 – Using existing hardwares to realize FlowTable • On the FlowTable reseiver side, the FlowTable receivers will: • Analyze the “Type”field of the TLVs received, • Distinguish ACL&QoS-type and FIB-type FlowTables according to the TLV type • Issue a corresponding item to ACL&QoS or to FIB hardware tables • OpenFlow Agent Module will execute the change from FlowTable TLV to ACL&QoS or FIB hardware resources.

  23. OpenFlow+’s implementation • We implemented OpenFlow + in a commercial router (DCRS 5980/5950, DigitalChina Company, RouterSwitch) -- OpenRouter. • There is no FlowTalbe hardware in OpenRouters. FlowTable is replaced by ACL and FIB.

  24. OpenFlow +’s implementation OpenRouter architecture

  25. OpenFlow +’s implementation • The details of OpenRouter: • An OpenFlow Agent module is embedded into the control software of OpenRouter. • OpenFlow protocol is redesigned and reconstructed with TLV. • FlowTable is implemented using existing hardware resources -- ACL&QoS and FIB. • OpenFlow Agent module acts as an interfaces with Routing Table Management (RTM) module and sFlow module. • Two asynchronous messages and a synchronous message are added to transmit FIB and sampling packets.

  26. Benefits of OpenFlow + • More openness for network devices. • More efficient control for the network. • More flexible organization for data in OpenFlow Protocol. • More low-cost implementation for OpenFlow hardware.

  27. Applications of OpenFlow +(1) • Intra-AS Source Address Validation

  28. Applications of OpenFlow +(2) • QoS routing in intra-AS

  29. Conclusions and Future Work • Internet needs innovation. But we still don’t know exactly what functions and features that the future Internet should include. • We think, it may be not proper to build a concrete and fixed network for the future Internet now. • We think, innovation ability is what the future Internet really needs.

  30. Conclusions and Future Work • OpenFlow’s openness and standardization give Internet more powerful abilities to reform and innovate. • In this paper, we made four extensions for OpenFlow and realized these extensions in a type of vender devices. Applications about how to use these extensions are introduced.

  31. Conclusions and Future Work • More hardware resources in devices should be exposed and standardized • The methods for inside or outside control logics to use these open and standard hardware resources should be unified

  32. Thank you! Q&A

More Related