Principle and Implementation of. Protocol Oblivious Forwarding

Transcription

1 Principle and Implementation of Protocol Oblivious Forwarding PUBLICATION DATE DECEMBER 27, 2012 Contents Principle and Implementation of... 1 Protocol Oblivious Forwarding... 1 AUTHORS... 错 误! 未 定 义 书 签 PUBLICATION DATE... 1 Contents... 1 Glossary Summary Problem of the OpenFlow-based SDN Principle of Protocol Oblivious Forwarding Abstraction of Protocol Forwarding Goto-Table Set-Field Write-Metadata-From-Packet Forwarding Procedure Configuration of flow tables Implementation of Protocol Oblivious Forwarding How POF Device Interoperates with Standard OpenFlow Controller Challenges for Protocol Oblivious Forwarding Contact Information References Page1, Total15

2 Glossary SDN POF OF QoS NP ASIC MAC ACL GUI UI Software Defined Networking Protocol Oblivious Forwarding OpenFlow Quality of Service Network Processor Application Specific Integrated Circuit Media Access Control Access Control List Graphic User Interface User Interface Page2, Total15

3 1. Summary Protocol Oblivious Forwarding (POF) is an enhancement to the current OpenFlow-based SDN forwarding architecture. It will improve the programmability of SDN. POF enables forwarding devices to support any new protocols without modifying any code of the devices. An abstraction of protocols is used to realize this target. To support new protocols, the operators only need to download some flows with associated instructions into the forwarding devices after implementing POF. POF can help carriers to deploy any new policies or services based on new protocols more conveniently and rapidly. For example, carriers can implement security or QoS policies on any video, voice, or P2P protocols easily by implementing POF. 2. Problem of the OpenFlow-based SDN The current OpenFlow-based SDN promotes the programmability of network devices by downloading flows into devices from the controller; but it cannot support new protocols automatically. The programmability can only apply to the existing protocols. If one service based on a new protocol needs to be implemented, the operator has to ask the device vendor to modify the code of the devices to support the new service. A packet is composed of multiple protocol headers and payload. The protocol headers are parsed and modified by NP micro-code or ASIC logic during the forwarding process. The position of each protocol field, such as the IPv4 source address, is calculated by the code that is preloaded into the devices according to protocol format by the device vendor. If one new protocol needs to be supported, the code must be modified. This will lead to a long deployment cycle for new services based on new protocols. The current OpenFlow-based SDN cannot resolve the aforementioned problem. In the OpenFlow specifications, the protocol field is only identified by the field type. The position of the protocol fields cannot be derived from the flow s forwarding instructions. So the position of each protocol fields must be calculated by the code, which means the code of the devices must be modified for processing new protocol headers. 3. Principle of Protocol Oblivious Forwarding 3.1 Abstraction of Protocol POF denotes any protocol field with the following structure. The metadata is considered as one special protocol header that can be configured by the controller. Any metadata field is also denoted in the same way as below. field { type; offset; length; }; Page3, Total15

4 The type is used to indicate the field type, for which the value 0 means the field is a packet data field and the value 1 means it is a metadata field. The offset is the field s start position relative to the current protocol head. The following example shows the MAC protocol header format. MAC dst src type There are three fields: dst, src, and type. They are denoted as follows: dst: {0, 0, 48}; /*packet field, offset is 0bit, length is 48bit*/ src: {0, 48, 48}; /*packet field, offset is 48bit, length is 48bit*/ type: {0, 96, 16}; /*packet field, offset is 96bit, length is 16bit*/ It is easy to see that any existing or new protocols can be denoted in the similar way. 3.2 Forwarding POF can realize the functions of all forwarding instructions/actions defined in OpenFlow 1.3.0, not only for the existing protocols but also for any new protocols. The followings are the definitions of three classic forwarding instructions/actions in POF. For the definitions of all other instructions/actions, interested readers can refer to the User Manual of POF Controller.pdf Goto-Table The Goto-Table Instruction instructs micro-code to match one table with keys extracted from the packet data or the metadata. The structure of Goto-Table instruction is: Goto-Table { type; next_table_id; packet_offset; match_field_num; fields_array[]; } The type indicates the instruction type, which is Goto-Table in this example. The next_table_id indicates the table to search. The match_field_num indicates the number of match fields. The fields_array[] indicates the fields of packet data or metadata used for match. The structure of each field is described in section 3.1. The packet offset instructs the micro-code to move forward Packet Process Pointer first before extract match field from the packet. In the figure below, one new protocol IPvX is defined, which comprises three fields: Dst_Addr, Src_Addr, and Type. Page4, Total15

5 IPvX Dst_Addr Src_Addr Type Dst_Addr: {0, 0, 64}; /*packet field, offset is 0bit, length is 64bit*/ Src_Addr: {0, 64, 64}; /*packet field, offset is 64bit, length is 64bit*/ Type: {0, 128, 8}; /*packet field, offset is 128bit, length is 8bit*/ In POF, the packet header is processed layer by layer, and the position of one protocol field is relative to its own protocol header. For example, the Src_Addr position has a 64-bit offset relative to the starting position of the IPvX header field. The following figure shows the process of IPvX packets by using the instruction Goto-Table. Flow Table 0 (Dst, Type) Flow Table 1 (Src_Addr) Goto-Table{ Table 1, /*Flow Table 1*/ 14, /*Packet Process Pointer move forward 14bytes */ 1, /*match field number is 1*/ {0, 64,64}, /*match field is Src_Addr*/ } Packet Process Pointer Packet Process Pointer MAC IPvX MAC IPvX Dst_Addr Src_Addr Type Dst_Addr Src_Addr Type Figure 1: Instance for Goto-Table Instruction In Flow Table 0, the destination address and the type of the MAC header are used as the match fields. Flow Table 0 has one flow entry configured by controller which instructs the microcode to go to Flow Table 1 for further processing. In Flow Table 1, the Src_Addr of IPvX is used as the match field. Flow Table 1 consists of some flow entries configured by the controller. A packet with the Ethernet type being IPvX will match a flow entry in Flow Table 0.The Goto-Table instruction in the flow entry will instruct the microcode to move the Packet Process Pointer forward 14 bytes first (i.e. the length of the MAC header), and then extract the Src_Addr field at the 64-bit offset position relative to the Packet Process Pointer. Finally the microcode will use the extracted Src_Addr field as the match key to search Flow Page5, Total15

6 Table 1 and do the further processing as instructed by the matching flow entry Set-Field The Set-Field instruction assigns the value of a protocol field in a packet header. The structure of the Set-Field instruction is shown below: Set-Field { type; field; value; } The type indicates the instruction type, which is Set-Field. The field identifies one field of the current protocol layer for which the structure is described in section 3.1. The value is what to be set in the field. The following figure is an example of Set-Field process on the IPvX Dst_Addr. In Flow Table 1, the matched flow entry 1 has a Set-Field instruction which instructs the microcode to set Dst_Addr of IPvX to 0x Flow Table 1 (Src_Addr) Set-Field{ {0, 0, 64}, /*field to be set is Dst_Addr*/ 0x , /*value */ } Packet Process Pointer 0 14 MAC IPvX Dst_Addr Src_Addr Type Figure 2: Instance for Set-Field Instruction Write-Metadata-From-Packet The Write-Metadata-From-Packet instruction copies the value of one packet field to the metadata memory. This instruction helps the microcode to fetch and retain the value of preceding protocol layers fields for process such as ACL. The structure of Write-Metadata-From-Packet is shown below. Write-Metadata-From-Packet { type; metadata_offset; Page6, Total15

7 } packet_field_offset; length; The type indicates the instruction type, which is Write-Metadata-From-Packet. The metadata_offset is the starting position to write in the metadata memory. The packet_field_offset is the starting position of the packet field to be copied. The length is the length of the field to be copied. The following figure is an instance of the Write-Metadata-From-Packet process. In Flow Table 1, the matched flow entry 1 has one Write-Metadata-From-Packet instruction which instructs the microcode to copy Dst_Addr of IPvX to the designated position of metadata memory. Flow Table 1 (Src_Addr) 0 Metadata Memory Write_Metadata_From_Packet{ 512, /*metadata offset*/ 0, /*packet field offset*/ 64, /*packet field length */ } Packet Process Pointer 0 14 MAC IPvX Dst_Addr Src_Addr Type Figure 3: Instance for Write-Metadata-From-Packet Instruction 3.3 Forwarding Procedure POF uses multiple flow tables for packet processing. Each flow table can realize one or more functions of the following: - Parsing the type of the next protocol header. - Set/Modify the current protocol header. - Add/Delete a protocol header. - Copy the current protocol field to the metadata. - Set the packet s committed access rate. - Set the packet s queue ID. - Access control: forward/drop/send upward a packet. - Output packet to designated port(s): unicast/multicast. Page7, Total15

8 POF handles packet headers layer by layer. Each layer has one or more relative flow tables for parsing the next protocol, setting/modifying the current protocol fields, adding/deleting protocol headers to/from the packet, or copying the protocol header to the metadata. The flow tables dedicated to one layer cannot handle any other preceding or rear protocol headers. Metadata can be used to hold the previous protocol headers. One Flow table executing match across multiple protocol layers will be introduced later. As shown in figure 4, one packet contains four layers of protocol header, Header0 ~ Header 3. The microcode uses Flow Table 0 to handle Header 0, and then go to Flow Table 1 to process Header 1. The Packet Process Pointer is moved forward to the start position of Header 1 as instructed by the Goto-Table instruction. Header 2 and Header 3 are processed in the same way. fields fields fields fields fields fields Goto Table 3 Goto Table 1 Flow Table 1 fields fields fields Goto Table 2 Flow Table 3 fields fields fields Packet Process Pointer Header 0 Header 1 Header 2 Header 3 Payload Figure 4: Forwarding procedure Each protocol layer can have multiple flow tables for processing the current protocol layer. For example, we can use one small flow table to parse the next protocol type and write the protocol fields into the metadata; meanwhile we use one big flow table to do other processes on the protocol layer. The small flow table can locate on chip and the big flow table can locate off chip for the best efficiency. If one flow table such as ACL needs to use multiple fields across multiple protocols as the match key, these fields should be copied from the protocol headers to the metadata memory first during the layer-by-layer packet parsing process. For example, in Figure 5 below, Flow Table 0 will instruct the microcode to write Header 0 s fields into one place of the metadata memory, and Flow Table 1will instruct the microcode to write Header 1 s fields into another place of the metadata memory, and so on. In Flow Table 3, after copying the fields of Header 3 into the metadata memory, the instruction Goto-Table instructs the microcode to extract those fields from the metadata memory as the match key and then execute the search in Flow table 4 for a match (note that we do not need to copy all the fields of a protocol header to the metadata memory, but only those fields needed for table match). Page8, Total15

9 Metadata Memory 0 32bit Flow Table 0 Goto Table Write Metadata From Packet Flow Table 1 Flow Table 2 Flow Table 3 Goto Table Write Metadata From Packet Write Metadata From Packet Goto Table Write Metadata From Packet Goto Table Flow Table 4 Packet Process Pointer Header 0 Header 1 Header 2 Header 3 Payload Figure 5: Match multiple fields across multiple protocol headers Each protocol field for match has its identified position in the metadata memory. The position can be configured by the controller. The following configuration is one example: the controller can add new fields to the metadata for any new protocol field which is needed for match. VLAN_ID_Outer VPN_ID TCP_Src_Port UDP_Src_Port VLAN_ID_Inner Rsv IPv4_Protocol_1 IPv4_Protocol_2 IPv4_Src_1 IPv4_Dst_1 IPv4_Src_2 IPv4_Dst_2 TCP_Dst_Port UDP_Dst_Port 3.4 Configuration of flow tables Figure6: Metadata Format All flow tables in a device are configured by a controller. The flow entries in any flow table are configured automatically by applications or manually through GUI on the controller. The controller provides the user interface for configuring protocols and metadata. The controller stores all protocols in one database in the format described in section 3.1. During configuring flow entries, applications on the controller may reference any protocol field in the protocol database for building the flow entries match fields and instructions (note that the Page9, Total15

10 metadata is considered as one special protocol header in controller). Figure 7 is a sketch map of POF architecture. Operator can configure protocol/metadata through an UI. Applications create flow tables as services required. During the procedure, the protocol database may be referenced. Applications download all flow tables entries into the designated device through the OpenFlow channel. Controller Protocol Database UI Metadata Protocol 0 Protocol 1 Protocol 2 Protocol 3 Protocol 4 Protocol 5 Application 0 Application 1 Application n Flow Table 0 Flow Table 1 Flow Table n Device OpenFlow Flow Table 0 Flow Table 1 Flow Table n Packet Forwarding Engine Metadata Figure 7: Sketch Map of POF Architecture 4. Implementation of Protocol Oblivious Forwarding In order to demonstrate the capability of POF and evaluate the possibility of using the existing hardware to support POF, we have finished developing two prototypes in parallel. One is an open-source software prototype. The other is based on one of our NP-based router platforms. The POF controller in our prototypes is responsible for managing devices resource like flow tables, group tables, counters, meters and so on. The POF device will report the capacity of each kind of resource to the POF controller during handshaking. The POF controller uses GUI to create and configure flow tables in the designated POF device. The POF controller stores the protocols formats which are configured through GUI by user. The POF controller also stores packets and error messages received from POF devices. For the detail information of the POF controller, interested readers can refer to POFController Introduction(1.0).pdf and Page10, Total15

11 User Manual of POF Controller.pdf. The hardware-based POF prototype is realized on a core router. We add a POF hardware abstraction layer in the core router s control plane for configuring POF flow tables, and add microcode in forwarding engine for parsing and executing POF instructions. The software architecture of POF device is shown in Figure 8. Our tests verify that the POF router can realize packet forwarding for any existing or user-defined packet formats. There are two classical use cases in the user manual of POF for demonstrating the flexible forwarding capability of POF router. Controller MPU HUAWEI Core Router OpenFlow Connection Management LPU OpenFlow Parse OpenFlow Encap HAL of POF Forwarding Engine Driver Forwarding Engine Figure 8: Software Architecture of POF device The POF software switch is implemented with a similar POF driver and software forwarding code on LINUX. The POF software switch can almost realize all forwarding functions as the POF hardware device. For the detail information of the POF software switch, interested readers can refer to the introduction document of the POF software switch POFSwitch Introduction(1.0).pdf. The POF controller communicates with the POF device through the OpenFlow protocol. POF uses the same control command as the standard OpenFlow 1.3. The data structure of the most control commands remains unchanged. POF only changes the data structure of forwarding instructions/actions of the standard OpenFlow How POF Device Interoperates with Standard OpenFlow Controller Page11, Total15

12 Now many vendors have developed their standard OpenFlow (OF) controllers. In order to enable POF devices to interoperate with standard OF controllers, the POF device should implement one translation layer on the POF driver as shown in Figure 9. Standard OF / POF Controller OpenFlow Channel POF Device POF Standard OF Translate OF Instruction to POF Instruction. Protocol Description Database POF Driver POF Forwarding Engine Figure 9: Translate Standard OF into POF In Figure 9, the POF device is able to interoperate with both standard OpenFlow controllers and POF controllers. If the POF device receives one control command from a standard OpenFlow controller, it will translate the OpenFlow instructions into the POF instructions by referencing the protocol database. The protocol database is prebuilt in the device and new protocol cannot be supported automatically while interoperating with the standard OpenFlow controller. (New protocol can be supported unless that the standard OpenFlow controller implements new control command for configuring protocol database in the POF device.) As discussed in section 3.3, each flow table can only process one protocol layer in the POF device. If one application flow table needs multiple protocol fields for match, metadata must be used. But the existing applications on standard OpenFlow controllers may not conform to the aforementioned limitation. Some existing applications on standard OpenFlow controllers may not be able to work and need to be rewritten while interoperating with POF devices. An alternative scheme can be used to avoid the problem above. As shown in Figure 10, we make POF instructions as an extending part of the standard OpenFlow instructions, and the POF instructions types are different from the standard OpenFlow instructions types. Page12, Total15

13 Standard OF/ POF Controller OpenFlow Channel POF Device Standard OF POF Standard OF Driver POF Driver (Standard OF + POF) Forwarding Engine Figure 10: Extend Standard OF with POF In Figure 10, the forwarding engine of the POF device supports both standard OpenFlow instructions and POF instructions. The standard OpenFlow configuration commands are executed by the standard OpenFlow driver and the POF configuration commands are executed by the POF driver. In this way, the POF device can interoperate with the standard OpenFlow controller or POF controller automatically. This scheme needs the forwarding engine of POF devices to implement both standard OpenFlow instructions and POF instructions, which require much more microcode to be stored in NP s instruction buffer. Actually, a POF device can realize all functions of a standard OpenFlow device as discussed in section 3. In our opinion, the POF scheme should be included into the OpenFlow specification for denoting match fields in instructions/actions, and then eventually SDN forwarding devices will not need to support the current OpenFlow instructions any more in the future. 6. Challenges for Protocol Oblivious Forwarding POF enables network devices to support full programmability for any new services based on existing or new protocols. While it is great to achieve this aim, there are still a number of challenges to address. The challenges we have identified are: Standardization and Interoperability. Many vendors have developed their SDN forwarding devices and controllers without supporting POF. We need to make POF standardized as one necessary part of SDN implementation (At least should be an extending part as discussed in section 5). Otherwise the devices/controllers implementing POF may not be able to interoperate with the controllers/devices which do not implement POF. Performance. Performance is a challenge not only for POF but also for the current Page13, Total15

14 OpenFlow-based SDN as many flow tables are accessed, translated, and performed during the forwarding procedure. The following are the possible causes that make the performance drop: - Too many clock cycles are used for accessing flow tables, translating SDN instructions, and performing instructions. The process latency of SDN is longer than that of the traditional process. - The bandwidth of the on-chip and off-chip memory is not enough for storing/accessing so many flow tables. We propose the following methods to improve the performance of SDN devices: - Create as few flow tables as possible. We should combine multiple flow tables to one table if possible. By this way, forwarding engine has fewer flow tables to access. - Use hardware to execute the complex instructions to reduce process latency. - Put small flow tables on chip as accessing on-chip memory is much faster than accessing off-chip memory and on-chip memory provides higher bandwidth. - If necessary, duplicate some small flow tables to provide high bandwidth as required. - Divide on-chip memory into many small blocks to provide enough bandwidth for flow tables. - Embed one or multiple small TCAMs on chip to store small flow tables, such as those tables for parsing the type of the next protocol layer. Simplicity. In OpenFlow specifications, Flow Table can comprise more than ten match fields. The match fields can be wild card and the maximum length of match key can reach more than 512 bits. In this condition, it is difficult to match the flow table quickly if the flow table is too large to be stored in TCAM. Sophisticated algorithms have to be implemented to do the job. The algorithm may consume much resource including memory space, memory bandwidth, and logic units. It can cause the forwarding engine to be very complex and large. Even the complicated algorithm can be realized, the lookup performance is still in doubt. In order to avoid the complexity of flow tables, we should design flow tables with as few match fields as possible. But it may result in too many flow tables and the performance suffers. The tradeoff between the complexity of flow tables and the number of flow tables must be considered carefully during the application design. Contact Information Please provide your feedback to any of the following. Haoyu Song: haoyu.song@huawei.com Jun Gong: gongjun@huawei.com Xiaozhong Wang: rossel.wangxiaozhong@huawei.com Yuanming Zheng: zhengyuanming@huawei.com Jian Song: jack.songjian@huawei.com Page14, Total15

15 Zhen Wang: Jinzhou Yu: References 1. openflow-spec-v1.3.0.pdf: Page15, Total15