idnits 2.17.1 draft-zhu-srpof-ehdt-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 139 has weird spacing: '...hnology or th...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (Aug 14, 2018) is 2054 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 160, but not defined Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Zuqing Zhu 3 Intended Status: Informational Univ. Sci. & Tech. of China 4 Expires: Feb 14 , 2019 Aug 14, 2018 6 Source Routing with Protocol-oblivious Forwarding 7 to Enable Efficient e-Health Data Transfer 8 draft-zhu-srpof-ehdt-00 10 Abstract 12 It has already been confirmed that software-defined networking (SDN) 13 can make the networks more programmable, adaptive and application 14 aware. However, due to the large-scale and geographically-distributed 15 nature of wide-area networks (WAN), the scalability could become a 16 critical issue if we incorporate SDN for WANs (i.e., realizing SD- 17 WANs). In this paper, we design and implement a novel network system 18 that can leverage source routing with the protocol-oblivious 19 forwarding (POF) to facilitate efficient e-Health data transfers with 20 low setup latency. We develop the POF-based source routing protocol 21 to realize a pipeline based packet processing procedure, which can 22 replace the table-lookup based approach in traditional SDN networks 23 and make the forwarding plane more efficient. The proposed scheme is 24 demonstrated experimentally, and the results verify that with it, the 25 flow-tables installed in each core switches in a POF-controlled SD- 26 WAN can be minimized and the path setup latency of traffic flows can 27 be reduced significantly as well. 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as 37 Internet-Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/1id-abstracts.html 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html 49 Copyright and License Notice 51 Copyright (c) 2018 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. POF-Based Source Routing in SD-WANs . . . . . . . . . . . . . 5 69 2.1 Packet Design for source Routing . . . . . . . . . . . . . . 6 70 2.2 Procedure for Source Routing based Packet Processing . . . . 7 71 3 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 11 73 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11 74 6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 7.1 Normative References . . . . . . . . . . . . . . . . . . . 11 77 7.2 Informative References . . . . . . . . . . . . . . . . . . 11 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 80 1 Introduction 82 Nowadays, the fast development of data-intensive applications, such 83 as e-Health, e-Science, e-commerce, etc, has brought us into the Big 84 Data era. It is known that certain Big Data applications may generate 85 huge volumes of data, which needs to be transferred over wide-area 86 networks (WANs) for timely processing. For instance, in a 87 telemedicine network, the health-monitoring devices worn by a large 88 population of subscribers can contribute a fair amount of traffic for 89 real-time processing . As the subscribers usually locate in a 90 geographically dispersed manner, it would be challenging to transfer 91 the data to the processing module(s) with low latency. Hence, both 92 flexible architecture and efficient protocols are required to achieve 93 flexible traffic engineering in WANs, especially when cloud-based 94 data gathering and processing are needed. Today's WAN architecture 95 uses distributed traffic engineering mechanisms to reduce bandwidth 96 congestion, but it has been proven to be inefficient due to the close 97 coupling of the control and forwarding planes of the network. In 98 order to support Big Data applications more efficiently, WANs also 99 need a more programmable and adaptive architecture with effective 100 network control and management (NC&M), which is similar to the 101 innovation trends in other types of networks. Recently, software- 102 defined networking (SDN)[RFC7149] has been proposed as a break- 103 through technology that is promising for the next-generation Internet 104 due to the fact that it decouples control and forwarding planes of a 105 network and leverages centralized NC&M to make it more programmable, 106 adaptive and application-aware. Thanks to the advances on SDN, the 107 Big Data related traffic can be managed more efficiently in WANs. 108 However, due to the large-scale and geographically distributed nature 109 of WANs, the scalability could become a critical issue when 110 incorporating SDN for WANs. Specifically, when the traffic volume 111 increases, more and more flow-tables will be installed in the 112 switches, which can use up their memory, make the table look-up and 113 traffic scheduling increasingly complex, and increase the 114 communication overhead significantly. 116 Unfortunately, the aforementioned issue cannot be addressed properly 117 with the initial implementation of SDN, i.e., OpenFlow [RFC7426]. 118 This is because OpenFlow defines protocol dependent flow-matching 119 rules, which can lead to repeated flow-table installations and look- 120 ups in the forwarding plane. In an OpenFlow-controlled WAN, the 121 interactions between the switches and OpenFlow controller need to 122 bear a relatively long communication latency, which is due to the 123 physical distance between them and intrinsic. Hence, when setting up 124 a flow by configuring the flow-table on each switch along the path, 125 the hop-by-hop operation can cause a long setup delay. Note that, 126 this is especially unwanted for the delay-sensitive e-Health data 127 transfers that usually operate as mice flows. On the other hand, the 128 increasing volume of flow-tables could be another killing factor for 129 the software-defined WANs (SD-WANs). Specifically, due to its user 130 population, an OpenFlow-controlled SD-WAN usually needs to deploy a 131 huge number of flows, each of which may require to install a flow- 132 table on all the switches along the routing path. Consequently, the 133 switches' memory space for flow-tables can vanish quickly. Further 134 more, most of the commercially-available OpenFlow-enabled switches 135 cannot achieve a processing throughput of more than 500 FlowMods per 136 second. In order to address the issues of OpenFlow mentioned above, 137 recent researches have considered to enhance the programmability and 138 flexibility of SDN forwarding plane, with the protocol-oblivious 139 forwarding (POF) technology or the programming protocol-independent 140 packet processors (P4). The basic ideas behind POF and P4 are 141 similar, i.e., trying to decouple network protocols from the 142 forwarding procedure in SDN-enabled switches and make the forwarding 143 plane reconfigurable, programmable and future-proof. More 144 specifically, POF develops a protocol-independent instruction set 145 that allows to express much more flexible packet processing than the 146 current OpenFlow specifications , while P4 mainly focuses on 147 designing a high-level network programming language for protocol 148 innovations. Note that both approaches have attracted noticeable 149 interests from the open networking foundation (ONF), and are 150 considered in its project on protocol-independent forwarding (PIF). 152 The memo describes a novel network system that can leverage source 153 routing with POF to facilitate efficient e-Health data transfers with 154 low setup latency. The memo also contains demonstration examples. 156 1.1 Terminology 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in RFC 2119 [RFC2119]. 161 Software-Defined Networking (SDN) - A programmable networks approach 162 that supports the separation of control and forwarding planes via 163 standardized interfaces. 165 Protocol Oblivious Forwarding (POF) - The protocol that is proposed 166 by Huawei to provide a new way to develop SDN. 168 Match Fields - POF simply defines the search key of a matching field 169 as a tuple . Here, offset indicates the start- 170 location of the field in a packet, length tells the field's length in 171 bits 173 POF-FIS - All the instructions in POF-FIS utilize the tuple to locate the data that they need to operate on. This 175 provides us the freedom to manipulate any bit(s) in packets at will, 176 which is far more flexible than the scheme in OpenFlow. For instance, 177 in the latest OpenFlow switch specifications, the push action is 178 still protocol-specific and multiple actions have to be defined for 179 each legacy protocol. However, all these push actions can be realized 180 with one generic instruction in POF, which is add-field. 181 Specifically, by using add-field, we can insert any field at any 182 position in a packet. POF-FIS even includes a calculatefield 183 instruction to provide the support on arithmetic and logical 184 operations 186 Flow Tables - The flow tables stored in a POF-enabled switch can be 187 classified into four types, i.e., the maskedmatch (MM) table, the 188 longest-prefix-match (LPM) table, the extract-match (EM) table, and 189 the direct table (DT). These types of tables occupy different memory 190 sizes and can be searched with various table lookup algorithms. Note 191 that, a flow entry in all the tables consists of both matching 192 field(s) and related instruction(s), except for DT, whose flow 193 entries only include instructions. By leveraging these tables, the 194 forwarding procedure in a POF-enabled switch can be abstracted as a 195 data-path pipeline, and hence the network programmability and 196 flexibility can be improved significantly. 198 Metadata Memory - When a switch needs to handle multiple tables in 199 packet forwarding, it uses metadata memory to store the flow 200 information that the current table processing generated for the next. 201 POF-FIS defines three metadata-related instructions. 203 2. POF-Based Source Routing in SD-WANs 205 In this section, the memo explain the proposed POF-based source 206 routing for SD-WANs, and describe both the network architecture and 207 the forwarding procedure used by the POF enabled switches.The 208 following figure shows the network architecture of a POF-based SD- 209 WAN, which consist of a centralized POF controller, and core and edge 210 switches. Note that, the edge switches work as the gateways to peer 211 networks, while the core switches focus on packet forwarding inside 212 the SD-WAN. 214 +-------------------------------------------------+ 215 | | 216 | POF Controller | 217 | | 218 +-------+----------------+----------------+-------+ 219 | | | 220 | | | Data Plane 221 +-------V----------------V----------------V-------+ 222 | | 223 | +-----------+ | 224 | |core switch| | 225 | +-----------+ | 226 | +-----------+ +-----------+ | 227 | |edge switch| |edge switch| | 228 | +-----------+ +-----------+ | 229 +-------------------------------------------------+ 231 2.1 Packet Design for source Routing 233 Thanks to the protocol-independent nature of POF, there is no need to 234 reuse the header fields in legacy protocols(e.g., VLAN and MPLS). 235 Basically, the packet fields can be tailored specially to enable 236 efficient source routing. Here, the fields are still designed to 237 store the path information, and the following figure describes the 238 proposed packet format for POFbased source routing. Specifically, the 239 source routing related header fields are inserted in between Ethernet 240 header and IP header. Moreover, after inserting the new fields, we 241 modify the type field in Ethernet header to "0x0908" to indicate that 242 the Ethernet frame contains a POF-based source routing packet. The 243 detailed descriptions on the new fields are as follows. 245 +-----------+---------------------+----------+------------//--+ 246 | Ethernet |Source Routing Header| IP | Data | 247 +-----------+---------------------+----------+-----------//---+ 248 / \ 249 / \ 250 / \ 251 +---+-----+-----+-----+------+ 252 |TTL|Port1|Port2| ... |PortN | 253 +---+-----+-----+-----+------+ 254 0 8 40 72 255 Time-to-Live (TTL): This field occupies 8 bits and indicates the 256 remaining hops for the packet to travel to its destination in the 257 POF-based SD-WAN. Therefore, the value of this field will be set at 258 the ingress edge switch, and in each subsequent switch, its value is 259 decreased by 1. When the packet is about to leave the POF-based 260 SDWAN, the egress edge switch remove it by applying the del-field 261 instruction. 263 Port: This field occupies 32 bits , and its value identifies an 264 output port on a POF-enabled switch. Note that, a source routing 265 packet can contain multiple Port fields to represent the forwarding 266 path, and all the fields form a Port stack. Each switch pops the 267 first Port field (i.e., with ) from 268 the Port stack to find the output port for the packet. This is done 269 by writing the value of the Port field to the metadata memory and 270 removing the field from the packet, i.e., with the writedata-from- 271 packet and del-field instructions, respectively. 273 2.2 Procedure for Source Routing based Packet Processing 275 The following two figures show the principle and detailed procedure 276 of POF-based source routing, respectively. 278 | 279 | 280 +------------|------------------------------------+ 281 | | | 282 | | | 283 | +-----V------+ Table miss | 284 | |Table Lookup|---------+ | 285 | +-----|------+ | | 286 | | Match | | 287 | | | | 288 | +-----V------+ +------V------+ | 289 | |Push source | |Send | | 290 | |routing | |Packet-in to | | 291 | |header | |Controller | | 292 | +-----|------+ +-------------+ | 293 | | | 294 | | | 295 | +-----V------+ | 296 | |Output | | 297 | +-----|------+ | 298 | | Edge Switch | 299 | | | 300 +------------|------------------------------------+ 301 V 302 | 303 | 304 +------------|-------------------------------------+ 305 | | | 306 | +-------V--------+ No | 307 | |EtherType=0x0908|-------------+ | 308 | +-------|--------+ | | 309 | |Yes | | 310 | +-------V--------+ +--------V--------+ | 311 | |Write PortId to | |Other packet | | 312 | |Metadata | |processing | | 313 | +-------|--------+ +-----------------+ | 314 | | | 315 | +-------V--------+ Yes | 316 | | TTL=1 |------------+ | 317 | +-------|--------+ | | 318 | |No | | 319 | +-------V--------+ +-------V--------+ | 320 | |Pop port field | |Pop source | | 321 | +-------|--------+ |routing header | | 322 | | +-------|--------+ | 323 | +-------V--------+ | | 324 | |Send to output | | | 325 | |Port |<-----------+ | 326 | +-------|--------+ | 327 | | Core Switch | 328 +------------|-------------------------------------+ 329 V 330 When the first packet of a flow arrives at an ingress edge switch, it 331 triggers a PacketIn message to be sent to the POF controller, since 332 there is no flow entries to match against. Upon receiving the Packet- 333 In message, the controller calculates a routing path for the flow, 334 and sends a Flow-Mod message to the ingress edge switch, which 335 encodes the designated output port to use on each switch along the 336 path. The ingress edge switch stores the output ports in its metadata 337 memory, and will insert them into every packet of the flow by using 338 POF-FIS. The subsequent core switches use a pre-installed pipeline- 339 like matching rule that consists of multiple flow tables to process 340 the packets. Note that, since the forwarding path is encoded in each 341 packet, the core switches do not need to have any interactions with 342 the controller, and hence the setup latency is reduced significantly. 344 The following figure shows the proposed procedure used to process the 345 flow tables in a core switch for source routing. We use three flow 346 tables, including two MM tables and one DT table, to realize the 347 overall source routing functionality as follows 348 | 349 +---------------------|------------------------------------------+ 350 | +----------------V---------------+ | 351 | | Table 0 (MM) | POF Switch | 352 | +--------------------------------+ | 353 | | Match | Instructions | | 354 | +--------------------------------+ | 355 | |{96b,26b}=0x0908|goto-table1 |--------+ | 356 | +--------------------------------+ | | 357 | | | 358 | +----------------------+ | 359 | | | 360 | +------------------V-------------+ | 361 | | Instructions | | 362 | +--------------------------------+ | 363 | |write-metadata-from-packet | | 364 | |{0b,32b}=={120b,32b} |---------------+ | 365 | | goto-table:table2 |---+ | | 366 | +--------------------------------+ | +---------V---------+| 367 | | |Metadata Memory || 368 | +--------------------+ +-------------------+| 369 | | |Port Buffer{0b,32b}|| 370 | | +-------------------+| 371 | +---------------V-------------------+ | 372 | | Table 2 (MM) | | 373 | +---------------|-------------------+ | 374 | | Match | Instructions | | 375 | +-----------------------------------+ | 376 | | |mod-field{96b,16b} | | 377 | | |output:port{0b,32b}| | 378 | +-----------------------------------+ | 379 | | {112b,8b}==* |del-field{120b,32b}| | 380 | | |output:port{0b,32b}| | 381 | +-----------------------------------+ | 382 | | 383 +----------------------------------------------------------------+ 384 The source routing packet arrives at the switch first goes to Table 385 0, which includes an entry to check the type field in its Ethernet 386 header, i.e., with equals <96 bits, 16 bits>. If its 387 value equals 0x0908, we determines that it is a source routing packet 388 and should be sent to Table 1. 390 Table 1 is a DT, and the entries in it only include instructions, as 391 shown in the figure. Here, the switch executes the write-metadata- 392 from-packet instruction to copy the value at <120 bits, 32 bits> 393 (i.e., the Port field to encode the output port for this hop) to its 394 metadata memory. 396 Table 2 includes two entries that are used to determine whether the 397 switch is the packet's last hop. Specifically, it checks the TTL 398 field (i.e., <112 bits, 8 bits>). If the value of the TTL field 399 equals 1, the switch is the last hop of this packet and it invokes 400 the del-field instruction to delete the whole source routing related 401 fields in the packet and restore the type field in the Ethernet 402 header to its original value (e.g., 0x0800 for an IPv4 packet). 403 Otherwise, the switch only removes the Port field for this hop. The 404 output instruction is then used to forward the packet to its 405 designated output port 407 3 Example 408 The following example is to verify the functionality of the proposed 409 POF-based source routing scheme. The figure shows the testbed, it 410 consists of several software-based POFenabled switches and a 411 controller. 413 +---------------+ 414 +------| POF Controller|------+ 415 | +-------|-------+ | 416 | | | 417 | | | 418 | | | 419 +-------+ +--------+ +--------+ +--------+ +------+ 420 | Host |-----| Switch |-----| Switch |-----| Switch |----| Host | 421 +-------+ +--------+ +--------+ +--------+ +------+ 423 An ICMP Request packet first arrives at edge switch S1, where it 424 finds that there is no match rules configured for it. Then, S1 sends 425 a Packet-In message to the POF controller to ask for the forwarding 426 policy. The POF controller handles the Packet-In message, calculates 427 a path together with the output ports on each hop along it, and 428 instructs edge switch S1 to convert the packets to source routing 429 ones by encoding the output port information in them. 431 4 Security Considerations 432 The mechanism described in this document does not raise any new 433 security issues for the PCEP protocols. 435 5 IANA Considerations 437 This document includes no request to IANA. 439 6 Conclusion 441 In this memo, designed and implemented a novel network system that 442 could leverage source routing with POF to facilitate efficient e- 443 Health data transfers with low setup latency. We developed the POF- 444 based source routing protocol to realize a pipeline based packet 445 processing procedure, which could replace the table-lookup based 446 approach in traditional SDN networks and make the forwarding plane 447 more efficient. The proposed scheme was demonstrated experimentally, 448 and the results verified that with it, the flow-tables installed in 449 each core switches in a POF-controlled SD-WAN could be minimized and 450 the path setup latency of traffic flows could be reduced 451 significantly as well. convert the packets to source routing ones by 452 encoding the output port information in them. 454 7 References 456 7.1 Normative References 458 [RFC7149] Boucadair, M., "Software-Defined Networking: A 459 Perspective from within a Service Provider 460 Environment", RFC 7149, March 2014. 462 [RFC7426] E. Haleplidis, Ed., "Software-Defined Networking (SDN): 463 Layers and Architecture Terminology", RFC 7426,January 464 2015. 466 7.2 Informative References 468 Authors' Addresses 470 Zuqing Zhu 471 University of Science and Technology of China, 472 96 Jinzhai Rd., Hefei, Anhui, 230026, China. 474 EMail: zqzhu@ustc.edu.cn