INTERNET-DRAFT Zuqing Zhu Intended Status: Informational Univ. Sci. & Tech. of China Expires: Feb 14 , 2019 Aug 14, 2018 Source Routing with Protocol-oblivious Forwarding to Enable Efficient e-Health Data Transfer draft-zhu-srpof-ehdt-00 Abstract It has already been confirmed that software-defined networking (SDN) can make the networks more programmable, adaptive and application aware. However, due to the large-scale and geographically-distributed nature of wide-area networks (WAN), the scalability could become a critical issue if we incorporate SDN for WANs (i.e., realizing SD- WANs). In this paper, we design and implement a novel network system that can leverage source routing with the protocol-oblivious forwarding (POF) to facilitate efficient e-Health data transfers with low setup latency. We develop the POF-based source routing protocol to realize a pipeline based packet processing procedure, which can replace the table-lookup based approach in traditional SDN networks and make the forwarding plane more efficient. The proposed scheme is demonstrated experimentally, and the results verify that with it, the flow-tables installed in each core switches in a POF-controlled SD- WAN can be minimized and the path setup latency of traffic flows can be reduced significantly as well. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html Zuqing Zhu Expires Feb 14, 2019 [Page 1] INTERNET DRAFT draft-zhu-srpof-ehdt-00 Aug 14, 2018 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 2. POF-Based Source Routing in SD-WANs . . . . . . . . . . . . . 5 2.1 Packet Design for source Routing . . . . . . . . . . . . . . 6 2.2 Procedure for Source Routing based Packet Processing . . . . 7 3 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 11 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11 6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1 Normative References . . . . . . . . . . . . . . . . . . . 11 7.2 Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Zuqing Zhu Expires Feb 14, 2019 [Page 2] INTERNET DRAFT draft-zhu-srpof-ehdt-00 Aug 14, 2018 1 Introduction Nowadays, the fast development of data-intensive applications, such as e-Health, e-Science, e-commerce, etc, has brought us into the Big Data era. It is known that certain Big Data applications may generate huge volumes of data, which needs to be transferred over wide-area networks (WANs) for timely processing. For instance, in a telemedicine network, the health-monitoring devices worn by a large population of subscribers can contribute a fair amount of traffic for real-time processing . As the subscribers usually locate in a geographically dispersed manner, it would be challenging to transfer the data to the processing module(s) with low latency. Hence, both flexible architecture and efficient protocols are required to achieve flexible traffic engineering in WANs, especially when cloud-based data gathering and processing are needed. Today's WAN architecture uses distributed traffic engineering mechanisms to reduce bandwidth congestion, but it has been proven to be inefficient due to the close coupling of the control and forwarding planes of the network. In order to support Big Data applications more efficiently, WANs also need a more programmable and adaptive architecture with effective network control and management (NC&M), which is similar to the innovation trends in other types of networks. Recently, software- defined networking (SDN)[RFC7149] has been proposed as a break- through technology that is promising for the next-generation Internet due to the fact that it decouples control and forwarding planes of a network and leverages centralized NC&M to make it more programmable, adaptive and application-aware. Thanks to the advances on SDN, the Big Data related traffic can be managed more efficiently in WANs. However, due to the large-scale and geographically distributed nature of WANs, the scalability could become a critical issue when incorporating SDN for WANs. Specifically, when the traffic volume increases, more and more flow-tables will be installed in the switches, which can use up their memory, make the table look-up and traffic scheduling increasingly complex, and increase the communication overhead significantly. Unfortunately, the aforementioned issue cannot be addressed properly with the initial implementation of SDN, i.e., OpenFlow [RFC7426]. This is because OpenFlow defines protocol dependent flow-matching rules, which can lead to repeated flow-table installations and look- ups in the forwarding plane. In an OpenFlow-controlled WAN, the interactions between the switches and OpenFlow controller need to bear a relatively long communication latency, which is due to the physical distance between them and intrinsic. Hence, when setting up a flow by configuring the flow-table on each switch along the path, the hop-by-hop operation can cause a long setup delay. Note that, this is especially unwanted for the delay-sensitive e-Health data transfers that usually operate as mice flows. On the other hand, the Zuqing Zhu Expires Feb 14, 2019 [Page 3] INTERNET DRAFT draft-zhu-srpof-ehdt-00 Aug 14, 2018 increasing volume of flow-tables could be another killing factor for the software-defined WANs (SD-WANs). Specifically, due to its user population, an OpenFlow-controlled SD-WAN usually needs to deploy a huge number of flows, each of which may require to install a flow- table on all the switches along the routing path. Consequently, the switches' memory space for flow-tables can vanish quickly. Further more, most of the commercially-available OpenFlow-enabled switches cannot achieve a processing throughput of more than 500 FlowMods per second. In order to address the issues of OpenFlow mentioned above, recent researches have considered to enhance the programmability and flexibility of SDN forwarding plane, with the protocol-oblivious forwarding (POF) technology or the programming protocol-independent packet processors (P4). The basic ideas behind POF and P4 are similar, i.e., trying to decouple network protocols from the forwarding procedure in SDN-enabled switches and make the forwarding plane reconfigurable, programmable and future-proof. More specifically, POF develops a protocol-independent instruction set that allows to express much more flexible packet processing than the current OpenFlow specifications , while P4 mainly focuses on designing a high-level network programming language for protocol innovations. Note that both approaches have attracted noticeable interests from the open networking foundation (ONF), and are considered in its project on protocol-independent forwarding (PIF). The memo describes a novel network system that can leverage source routing with POF to facilitate efficient e-Health data transfers with low setup latency. The memo also contains demonstration examples. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Software-Defined Networking (SDN) - A programmable networks approach that supports the separation of control and forwarding planes via standardized interfaces. Protocol Oblivious Forwarding (POF) - The protocol that is proposed by Huawei to provide a new way to develop SDN. Match Fields - POF simply defines the search key of a matching field as a tuple . Here, offset indicates the start- location of the field in a packet, length tells the field's length in bits POF-FIS - All the instructions in POF-FIS utilize the tuple to locate the data that they need to operate on. This provides us the freedom to manipulate any bit(s) in packets at will, Zuqing Zhu Expires Feb 14, 2019 [Page 4] INTERNET DRAFT draft-zhu-srpof-ehdt-00 Aug 14, 2018 which is far more flexible than the scheme in OpenFlow. For instance, in the latest OpenFlow switch specifications, the push action is still protocol-specific and multiple actions have to be defined for each legacy protocol. However, all these push actions can be realized with one generic instruction in POF, which is add-field. Specifically, by using add-field, we can insert any field at any position in a packet. POF-FIS even includes a calculatefield instruction to provide the support on arithmetic and logical operations Flow Tables - The flow tables stored in a POF-enabled switch can be classified into four types, i.e., the maskedmatch (MM) table, the longest-prefix-match (LPM) table, the extract-match (EM) table, and the direct table (DT). These types of tables occupy different memory sizes and can be searched with various table lookup algorithms. Note that, a flow entry in all the tables consists of both matching field(s) and related instruction(s), except for DT, whose flow entries only include instructions. By leveraging these tables, the forwarding procedure in a POF-enabled switch can be abstracted as a data-path pipeline, and hence the network programmability and flexibility can be improved significantly. Metadata Memory - When a switch needs to handle multiple tables in packet forwarding, it uses metadata memory to store the flow information that the current table processing generated for the next. POF-FIS defines three metadata-related instructions. 2. POF-Based Source Routing in SD-WANs In this section, the memo explain the proposed POF-based source routing for SD-WANs, and describe both the network architecture and the forwarding procedure used by the POF enabled switches.The following figure shows the network architecture of a POF-based SD- WAN, which consist of a centralized POF controller, and core and edge switches. Note that, the edge switches work as the gateways to peer networks, while the core switches focus on packet forwarding inside the SD-WAN. Zuqing Zhu Expires Feb 14, 2019 [Page 5] INTERNET DRAFT draft-zhu-srpof-ehdt-00 Aug 14, 2018 +-------------------------------------------------+ | | | POF Controller | | | +-------+----------------+----------------+-------+ | | | | | | Data Plane +-------V----------------V----------------V-------+ | | | +-----------+ | | |core switch| | | +-----------+ | | +-----------+ +-----------+ | | |edge switch| |edge switch| | | +-----------+ +-----------+ | +-------------------------------------------------+ 2.1 Packet Design for source Routing Thanks to the protocol-independent nature of POF, there is no need to reuse the header fields in legacy protocols(e.g., VLAN and MPLS). Basically, the packet fields can be tailored specially to enable efficient source routing. Here, the fields are still designed to store the path information, and the following figure describes the proposed packet format for POFbased source routing. Specifically, the source routing related header fields are inserted in between Ethernet header and IP header. Moreover, after inserting the new fields, we modify the type field in Ethernet header to "0x0908" to indicate that the Ethernet frame contains a POF-based source routing packet. The detailed descriptions on the new fields are as follows. +-----------+---------------------+----------+------------//--+ | Ethernet |Source Routing Header| IP | Data | +-----------+---------------------+----------+-----------//---+ / \ / \ / \ +---+-----+-----+-----+------+ |TTL|Port1|Port2| ... |PortN | +---+-----+-----+-----+------+ 0 8 40 72 Time-to-Live (TTL): This field occupies 8 bits and indicates the remaining hops for the packet to travel to its destination in the POF-based SD-WAN. Therefore, the value of this field will be set at the ingress edge switch, and in each subsequent switch, its value is decreased by 1. When the packet is about to leave the POF-based SDWAN, the egress edge switch remove it by applying the del-field instruction. Zuqing Zhu Expires Feb 14, 2019 [Page 6] INTERNET DRAFT draft-zhu-srpof-ehdt-00 Aug 14, 2018 Port: This field occupies 32 bits , and its value identifies an output port on a POF-enabled switch. Note that, a source routing packet can contain multiple Port fields to represent the forwarding path, and all the fields form a Port stack. Each switch pops the first Port field (i.e., with ) from the Port stack to find the output port for the packet. This is done by writing the value of the Port field to the metadata memory and removing the field from the packet, i.e., with the writedata-from- packet and del-field instructions, respectively. 2.2 Procedure for Source Routing based Packet Processing The following two figures show the principle and detailed procedure of POF-based source routing, respectively. | | +------------|------------------------------------+ | | | | | | | +-----V------+ Table miss | | |Table Lookup|---------+ | | +-----|------+ | | | | Match | | | | | | | +-----V------+ +------V------+ | | |Push source | |Send | | | |routing | |Packet-in to | | | |header | |Controller | | | +-----|------+ +-------------+ | | | | | | | | +-----V------+ | | |Output | | | +-----|------+ | | | Edge Switch | | | | +------------|------------------------------------+ V Zuqing Zhu Expires Feb 14, 2019 [Page 7] INTERNET DRAFT draft-zhu-srpof-ehdt-00 Aug 14, 2018 | | +------------|-------------------------------------+ | | | | +-------V--------+ No | | |EtherType=0x0908|-------------+ | | +-------|--------+ | | | |Yes | | | +-------V--------+ +--------V--------+ | | |Write PortId to | |Other packet | | | |Metadata | |processing | | | +-------|--------+ +-----------------+ | | | | | +-------V--------+ Yes | | | TTL=1 |------------+ | | +-------|--------+ | | | |No | | | +-------V--------+ +-------V--------+ | | |Pop port field | |Pop source | | | +-------|--------+ |routing header | | | | +-------|--------+ | | +-------V--------+ | | | |Send to output | | | | |Port |<-----------+ | | +-------|--------+ | | | Core Switch | +------------|-------------------------------------+ V When the first packet of a flow arrives at an ingress edge switch, it triggers a PacketIn message to be sent to the POF controller, since there is no flow entries to match against. Upon receiving the Packet- In message, the controller calculates a routing path for the flow, and sends a Flow-Mod message to the ingress edge switch, which encodes the designated output port to use on each switch along the path. The ingress edge switch stores the output ports in its metadata memory, and will insert them into every packet of the flow by using POF-FIS. The subsequent core switches use a pre-installed pipeline- like matching rule that consists of multiple flow tables to process the packets. Note that, since the forwarding path is encoded in each packet, the core switches do not need to have any interactions with the controller, and hence the setup latency is reduced significantly. The following figure shows the proposed procedure used to process the flow tables in a core switch for source routing. We use three flow tables, including two MM tables and one DT table, to realize the overall source routing functionality as follows Zuqing Zhu Expires Feb 14, 2019 [Page 8] INTERNET DRAFT draft-zhu-srpof-ehdt-00 Aug 14, 2018 | +---------------------|------------------------------------------+ | +----------------V---------------+ | | | Table 0 (MM) | POF Switch | | +--------------------------------+ | | | Match | Instructions | | | +--------------------------------+ | | |{96b,26b}=0x0908|goto-table1 |--------+ | | +--------------------------------+ | | | | | | +----------------------+ | | | | | +------------------V-------------+ | | | Instructions | | | +--------------------------------+ | | |write-metadata-from-packet | | | |{0b,32b}=={120b,32b} |---------------+ | | | goto-table:table2 |---+ | | | +--------------------------------+ | +---------V---------+| | | |Metadata Memory || | +--------------------+ +-------------------+| | | |Port Buffer{0b,32b}|| | | +-------------------+| | +---------------V-------------------+ | | | Table 2 (MM) | | | +---------------|-------------------+ | | | Match | Instructions | | | +-----------------------------------+ | | | |mod-field{96b,16b} | | | | |output:port{0b,32b}| | | +-----------------------------------+ | | | {112b,8b}==* |del-field{120b,32b}| | | | |output:port{0b,32b}| | | +-----------------------------------+ | | | +----------------------------------------------------------------+ The source routing packet arrives at the switch first goes to Table 0, which includes an entry to check the type field in its Ethernet header, i.e., with equals <96 bits, 16 bits>. If its value equals 0x0908, we determines that it is a source routing packet and should be sent to Table 1. Table 1 is a DT, and the entries in it only include instructions, as shown in the figure. Here, the switch executes the write-metadata- from-packet instruction to copy the value at <120 bits, 32 bits> (i.e., the Port field to encode the output port for this hop) to its metadata memory. Zuqing Zhu Expires Feb 14, 2019 [Page 9] INTERNET DRAFT draft-zhu-srpof-ehdt-00 Aug 14, 2018 Table 2 includes two entries that are used to determine whether the switch is the packet's last hop. Specifically, it checks the TTL field (i.e., <112 bits, 8 bits>). If the value of the TTL field equals 1, the switch is the last hop of this packet and it invokes the del-field instruction to delete the whole source routing related fields in the packet and restore the type field in the Ethernet header to its original value (e.g., 0x0800 for an IPv4 packet). Otherwise, the switch only removes the Port field for this hop. The output instruction is then used to forward the packet to its designated output port 3 Example The following example is to verify the functionality of the proposed POF-based source routing scheme. The figure shows the testbed, it consists of several software-based POFenabled switches and a controller. +---------------+ +------| POF Controller|------+ | +-------|-------+ | | | | | | | | | | +-------+ +--------+ +--------+ +--------+ +------+ | Host |-----| Switch |-----| Switch |-----| Switch |----| Host | +-------+ +--------+ +--------+ +--------+ +------+ An ICMP Request packet first arrives at edge switch S1, where it finds that there is no match rules configured for it. Then, S1 sends a Packet-In message to the POF controller to ask for the forwarding policy. The POF controller handles the Packet-In message, calculates a path together with the output ports on each hop along it, and instructs edge switch S1 to convert the packets to source routing ones by encoding the output port information in them. Zuqing Zhu Expires Feb 14, 2019 [Page 10] INTERNET DRAFT draft-zhu-srpof-ehdt-00 Aug 14, 2018 4 Security Considerations The mechanism described in this document does not raise any new security issues for the PCEP protocols. 5 IANA Considerations This document includes no request to IANA. 6 Conclusion In this memo, designed and implemented a novel network system that could leverage source routing with POF to facilitate efficient e- Health data transfers with low setup latency. We developed the POF- based source routing protocol to realize a pipeline based packet processing procedure, which could replace the table-lookup based approach in traditional SDN networks and make the forwarding plane more efficient. The proposed scheme was demonstrated experimentally, and the results verified that with it, the flow-tables installed in each core switches in a POF-controlled SD-WAN could be minimized and the path setup latency of traffic flows could be reduced significantly as well. convert the packets to source routing ones by encoding the output port information in them. 7 References 7.1 Normative References [RFC7149] Boucadair, M., "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, March 2014. [RFC7426] E. Haleplidis, Ed., "Software-Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426,January 2015. 7.2 Informative References Authors' Addresses Zuqing Zhu University of Science and Technology of China, 96 Jinzhai Rd., Hefei, Anhui, 230026, China. Zuqing Zhu Expires Feb 14, 2019 [Page 11] INTERNET DRAFT draft-zhu-srpof-ehdt-00 Aug 14, 2018 EMail: zqzhu@ustc.edu.cn Zuqing Zhu Expires Feb 14, 2019 [Page 12]