idnits 2.17.1 draft-irtf-sdnrg-pop-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (January 5, 2017) is 2668 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 133, but not defined == Unused Reference: 'OF-SPEC' is defined on line 650, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Y. Tian 3 Intended Status: Informational Univ. Sci. & Tech. of China 4 Expires: July 6, 2017 6 January 5, 2017 8 Programming Model for Protocol Oblivious Forwarding SDN Networks 9 draft-irtf-sdnrg-pop-00 11 Abstract 13 This document presents POP, a Software-Defined Networking (SDN) 14 programming model for the Protocol Oblivious Forwarding (POF) 15 network. POF is an SDN forwarding plane technology proposed by 16 Huawei. A POF forwarding element (FE) does no need to understand the 17 packet format, and can be programmed to support new forwarding 18 protocols. POP enables user to define forwarding protocols and 19 program the POF SDN network on the centralized control plane with 20 algorithmic policies that are expressed with high-level programming 21 languages. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as 31 Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 Copyright and License Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2 Programming Model . . . . . . . . . . . . . . . . . . . . . . . 4 64 3 Protocol Specification Language . . . . . . . . . . . . . . . . 5 65 4 Programming APIs for Protocol Oblivious Networking Algorithm . 7 66 4.1 Packet Operation API . . . . . . . . . . . . . . . . . . . . 7 67 4.2 Net Topology Search API . . . . . . . . . . . . . . . . . . 10 68 3.3 Path Planning API . . . . . . . . . . . . . . . . . . . . . 12 69 5 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 6.1 Normative References . . . . . . . . . . . . . . . . . . . 15 72 6.2 Informative References . . . . . . . . . . . . . . . . . . 15 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 75 1 Introduction 77 Software-Defined Networking (SDN)[RFC7149] gives operators 78 programmatic control over their networks. In SDN, the control plane 79 is physically separate from the forwarding plane, and one control 80 plane controls multiple forwarding devices. In SDN, a common, open, 81 vendor-agnostic interface between the control plane and the 82 forwarding plane, which may contain forwarding devices from different 83 hardware and software vendors, is required. OpenFlow is such an 84 interface. In OpenFlow, operators express their rules with the 85 abstractions that could match packets on a dozen header fields (e.g., 86 MAC addresses, IP addresses, protocol, TCP/UDP port numbers, etc.), 87 and specify the corresponding actions (e.g., output, drop, 88 encapsulate, etc.). 90 Generally speaking, a packet is composed of multiple protocol headers 91 and payload. The protocol headers are parsed and modified by NP 92 micro-code or ASIC logic during the forwarding process. The position 93 of each protocol field, such as the IPv4 source address, is 94 calculated by the code that is preloaded into the devices according 95 to protocol format by the device vendor. If one new protocol needs to 96 be supported, the code must be modified. This will lead to a long 97 deployment cycle for new services based on new protocols. 99 The current OpenFlow-based SDN[RFC7426] cannot resolve the 100 aforementioned problem. The position of the protocol fields cannot be 101 derived from the flow's forwarding instructions. So the position of 102 each protocol fields must be calculated by the code, which means the 103 code of the devices must be modified for processing new protocol 104 headers. 106 For this reason, Huawei presents the Protocol Oblivious Forwarding 107 (POF) technology. The basic idea is to denote any protocol field, as 108 well as the metadata, which is considered as one special protocol 109 header that can be configured by the controller, with a triad of 110 . 112 POF also defines a set of protocol oblivious forwarding 113 actions/instructions. The actions/instructions can realize the 114 functions of all forwarding instructions/actions defined in OpenFlow, 115 not only for the existing protocols but also for any new protocols. 117 With the protocol oblivious data plane that are composed of POF 118 forwarding devices, a programming model that enable user to program 119 such a data plane is required. This memo presents POP, an open, easy- 120 to-use, and efficient programming model. 122 The memo describes a protocol specification language that enable user 123 to specify any network protocol that he intends to program on the POF 124 network. Then the programming API that allows user to program the POF 125 network is introduced. The memo also contains demonstration 126 examples. 128 1.1 Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in RFC 2119 [RFC2119]. 134 Software-Defined Networking (SDN) - A programmable networks approach 135 that supports the separation of control and forwarding planes via 136 standardized interfaces. 138 Forwarding Plane (FP) - The collection of resources across all 139 network devices responsible for forwarding traffic. 141 Control Plane (CP) - The collection of functions responsible for 142 controlling one or more network devices.CP instructs network devices 143 with respect to how to process and forward packets. The control 144 plane interacts primarily with the forwarding plane and, to a lesser 145 extent, with the operational plane. 147 Protocol Oblivious Forwarding (POF) - The protocol that is proposed 148 by Huawei to provide a new way to develop SDN. 150 2 Programming Model 152 To program a protocol oblivious data plane,the POP programming model 153 use protocol specification language to specify the network protocol 154 in the network.Then user can write their own network algorithm to 155 program the POF network with the programming API.The run-time system 156 in the POP Should transfer the algorithm to the accurate protocol 157 oblivious forwarding actions/instructions and send to the POF 158 Switches. 160 +------------------------------------------------------------+ 161 | +-----------------+ +-------------------------------+ | 162 | |Network algorithm| |Protocol Specification Language| User | 163 | +-----------------+ +-------------------------------+ | 164 +------------------------------------------------------------+ 166 +------------------------------------------------------------+ 167 | POP Controller | 168 +--------+--------------------+----------------------+-------+ 169 | | | 170 | | | 171 +--------v--------------------v----------------------v-------+ 173 +------------------------------------------------------------+ 174 | +-------------+ | 175 | | POF Switch | | 176 | +-------------+ | 177 | +-------------+ +-------------| | 178 | | POF Switch | | POF Switch | | 179 | +-------------+ +-------------+ | 180 +------------------------------------------------------------+ 182 3 Protocol Specification Language 184 Protocol Specification Language is learned from P4. It include a 185 number of protocol header definitions and a "start" symbol which 186 represent the starting protocol header while parsing. User can 187 define the protocol header layer by layer. The BNF normal form of 188 Protocol Specification Language is showed as follows. 190 Identifier and unsigned number: The "IDENT" represent Identifier. 191 "NUMBER" represent unsigned number. "e" represent NULL. 192 +------------------------------------------------------------+ 193 |IDENT ::= [_a-zA-Z][_0-9a|zA-Z]* | 194 |NUMBER ::= 0[bB][01]+|0[0|7]*|[1-9][0-9]*|0[xX][0-9a-fA-F]+ | 195 +------------------------------------------------------------+ 197 Main program: a number of protocol header definitions and "start" 198 symbol. 199 +------------------------------------------------------------+ 200 |program ::= headers start | 201 |start ::= "start" IDENT ";" | 202 |headers ::= e | header headers | header_decl headers | 203 +------------------------------------------------------------+ 205 Header definition: Include header name, protocol fields list, 206 header length, next-layer selection. 207 +------------------------------------------------------------+ 208 |header ::= "header" IDENT "{" fields length next "}" | 209 |header_decl ::= "header" IDENT ";" | 210 +------------------------------------------------------------+ 212 Protocol fields: each field include a binary length. A protocol 213 allows at most one field which length is uncertain and mark as 214 "*". Meanwhile, it should at the end of the list. 215 +------------------------------------------------------------+ 216 |program ::= headers start | 217 |start ::= "start" IDENT ";" | 218 |headers ::= e | header headers | header_decl headers | 219 +------------------------------------------------------------+ 221 Header length: option, is a expression consists of field name and 222 constant. When it's implicit, the protocol fields list can 223 calculate header length automatically. 224 +------------------------------------------------------------+ 225 |length ::= e | "length" ":" expr ";" | 226 +------------------------------------------------------------+ 228 Expression: follow language specification of C. Operator have 229 different priority from high to low. Operator which have the same 230 priority cannot bond except bracket. 231 +------------------------------------------------------------+ 232 |expr ::= IDENT | NUMBER | | 233 |"(" expr ")" | (bracket) | 234 |"~" expr | (NOT) | 235 |expr "+" expr | expr "-" expr | (Add/Subtract) | 236 |expr "<>" expr | expr "<>" expr | (shift logical left/right)| 237 |expr "&" expr | (AND) | 238 |expr "^" expr | (XOR) | 239 |expr "|" expr (OR) | 240 +------------------------------------------------------------+ 242 Next-layer selection: according to value of one header field. Each 243 case include the value and next-layer header name. Next header 244 name can be recursive directly or indirectly. But the header name 245 should has been defined or are defined. 246 +------------------------------------------------------------+ 247 |next ::= e | "next" "select" "(" IDENT ")" "{" cases "}" | 248 |cases ::= e | "case" NUMBER ":" IDENT ";" cases | 249 +------------------------------------------------------------+ 251 4 Programming APIs for Protocol Oblivious Networking Algorithm Users 252 make use of a series of API to define network 253 algorithm.Functionly,those APIs include three parts which named 254 'Packet Operation','Net Topology Search' and 'Path Planing'. 256 4.1 Packet Operation API 258 POP supports any kinds of protocol message format that the API for 259 message operation doesn't rely on any specific protocol.As figure 260 2,POP supplies a 'layer-by-layer progressive' method by the 261 concept of network protocol stack that the packet is parsed into 262 many layers. 264 POP supports for the following Packet Operation API: 266 read_packet_inport 267 +------------------------------------------------------------+ 268 |int read_packet_inport(struct packet *pkt); | 269 |function::read the enter port of packet | 270 |input: | 271 | pkt packet | 272 |output: | 273 | current packet enter port number of switch | 274 +------------------------------------------------------------+ 275 read_packet_inswitch 276 +------------------------------------------------------------+ 277 |struct entity *read_packet_inswitch(struct packet *pkt); | 278 |function::read the enter switch of packet | 279 |input: | 280 | pkt packet | 281 |output: | 282 | current packet's enter switch number | 283 +------------------------------------------------------------+ 284 pull_header 285 +------------------------------------------------------------+ 286 | void pull_header(struct packet *pkt); | 287 |function::move current header point to | 288 | the next protocol layer | 289 |input: | 290 | pkt packet | 291 |output: | 292 | none | 293 +------------------------------------------------------------+ 294 read_header_type 295 +------------------------------------------------------------+ 296 |const char *read_header_type(struct packet *pkt); | 297 |function::read the name of current header | 298 |input: | 299 | pkt packet | 300 |output: | 301 | current header's name | 302 +------------------------------------------------------------+ 303 read_packet 304 +------------------------------------------------------------+ 305 |value_t read_packet(struct packet *pkt,const char *field); | 306 |function::read fields of packet | 307 |input: | 308 | pkt packet | 309 | field_name field name | 310 |output | 311 | value of current field_name | 312 | | 313 +------------------------------------------------------------+ 314 test_equal 315 +------------------------------------------------------------+ 316 |bool test_equal(struct packet *pkt,const char *field, | 317 | value_t value); | 318 |function::test value of packet fields | 319 |input: | 320 | pkt packet | 321 | field_name field_name | 322 | value value waiting for test | 323 |output: | 324 | if field_name value is equal to value,return true; | 325 | else return false | 326 +------------------------------------------------------------+ 327 read_payload 328 +------------------------------------------------------------+ 329 |const uint8_t *read_payload(struct packet *pkt,int *length);| 330 |function::read payload of packet | 331 |input: | 332 | pkt packet | 333 |output: | 334 | relative to current header payload:len is output value,| 335 | says return ^alue of byte stream length | 336 +------------------------------------------------------------+ 337 mod_packet 338 +------------------------------------------------------------+ 339 |void mod_packet(struct packet *pkt,const char *field, | 340 | value_t value); | 341 |function::modify current header field value to 'value' | 342 |input: | 343 | pkt pakcet | 344 | field field name | 345 | value modifying value | 346 |output: | 347 | none | 348 +------------------------------------------------------------+ 349 push_header 350 +------------------------------------------------------------+ 351 |void push_header(struct packet *pkt); | 352 |function::recover protocol header which is parser | 353 |input: | 354 | pkt packet | 355 |output: | 356 | none | 357 +------------------------------------------------------------+ 358 add_header 359 +------------------------------------------------------------+ 360 |void add_header(struct packet *pk,const char *proto); | 361 |function::add proto field all zero to current packet header | 362 |note:after use of add_header,you can use mod_packet to | 363 | modify field value | 364 |input: | 365 | pkt packet | 366 | proto name of header | 367 |output: | 368 | none | 369 +------------------------------------------------------------+ 370 add_field 371 +------------------------------------------------------------+ 372 |void add_field(struct packet *pkt,int offb,int lenb, | 373 | value_t value); | 374 |function::add field from offset is offb as current header, | 375 | adding field length is lenb,value is | 376 | value | 377 |input: | 378 | pkt pakcet | 379 | offb offset relative to current head | 380 | lenb length of adding field | 381 | value adding field vlaue | 382 |output: | 383 | none | 384 +------------------------------------------------------------+ 385 del_field 386 +------------------------------------------------------------+ 387 |void del_field(struct packet *pkt,int offb,int lenb); | 388 |function::delete length is lenb's field from offset value | 389 | is offb relative to current header | 390 |input: | 391 | pkt pakcet | 392 | offb offset relative to current head | 393 | lenb field length | 394 |output: | 395 | none | 396 +------------------------------------------------------------+ 398 4.2 Net Topology Search API 400 POP uses a figure to show network topology,entity is the node of 401 figure and every entity is on behalf of a switch or a host which 402 is stored by adjacent list.Users use centralized algorithms in the 403 figure to plan possible paths between any two hosts. 405 Data structure of entity as follows: 406 +------------------------------------------------------------+ 407 |enum entity_type { ENTITY_TYPE_HOST, ENTITY_TYPE_SWITCH }; | 408 |struct entity_adj | 409 |{ | 410 |int out_port; | 411 |int adj_in_port; | 412 |struct entity *adj_entity; | 413 |}; | 414 +------------------------------------------------------------+ 415 get_entity 416 +------------------------------------------------------------+ 417 |struct entity **get_entity(struct entity *e,int port); | 418 |function::get entity which connects current entity | 419 |input: | 420 | e entity | 421 | port port number | 422 |output: | 423 | entity | 424 +------------------------------------------------------------+ 425 get_entity_type 426 +------------------------------------------------------------+ 427 |enum entity_type get_entity_type(struct entity *e); | 428 |function::get the type of entity | 429 |input: | 430 | e entity | 431 |output | 432 | type of entity | 433 +------------------------------------------------------------+ 434 get_switch_dpid 435 +------------------------------------------------------------+ 436 |dpid_t get_switch_dpid(struct entity *e); | 437 |function::get dpid of entity switch | 438 |input: | 439 | e entity | 440 |output: | 441 | dpid | 442 +------------------------------------------------------------+ 443 get_host_adj_switch 444 +------------------------------------------------------------+ 445 |struct entity *get_host_adj_switch(struct entity *e, | 446 | int *sw_port); | 447 |function::get host connecting switch | 448 |input: | 449 | e entity | 450 |output: | 451 | if e is a host,return its connecting switch | 452 | sw_port is output ,return port number of switch | 453 +------------------------------------------------------------+ 454 get_entity_adjs 455 +------------------------------------------------------------+ 456 |const struct entity_adj *get_entity_adjs(struct entity *e, | 457 | int *pnum); | 458 |function::get adjacent list of entity | 459 |input: | 460 | e entity | 461 |output: | 462 | adjacent of entity | 463 | output parameter is pnum,return length of list | 464 +------------------------------------------------------------+ 465 print_entity 466 +------------------------------------------------------------+ 467 |void print_entity(struct entity *e); | 468 |function::output related information of entity | 469 |input: | 470 | e entity | 471 |output: | 472 +------------------------------------------------------------+ 473 get_switches 474 +------------------------------------------------------------+ 475 |struct entity **getswitches(int *pnum); | 476 |function::get all lists of switches in net | 477 |input: | 478 | none | 479 |output: | 480 | return all switch lists | 481 | output parameter is pnum,return number of switches | 482 +------------------------------------------------------------+ 483 get_switch 484 +------------------------------------------------------------+ 485 |struct entity *get_switch(dpid_t dpid); | 486 |function::search the switch according to dpid | 487 |input: | 488 | dpid switch number | 489 |output: | 490 | switch entity whose switch number is dpid | 491 +------------------------------------------------------------+ 492 get_host_by_haddr 493 +------------------------------------------------------------+ 494 |struct entity *get_host_by_haddr(haddr_t addr); | 495 |function::search host according to hardware address | 496 |input: | 497 | addr host hardware address | 498 |output: | 499 | host entity whose hardware address is addr | 500 +------------------------------------------------------------+ 501 get_host_by_paddr 502 +------------------------------------------------------------+ 503 |struct entity *get_host_by_paddr(uint32_t addr); | 504 |function::search host according to protocol address | 505 |input: | 506 | addr host protocol address | 507 |output: | 508 | host entity whose protocol address is addr | 509 +------------------------------------------------------------+ 511 3.3 Path Planning API 513 Network algorithm plans forwarding paths according to content of 514 packet and topology.Type of route is struct route,which consists 515 of some edges connecting source host and destination host.As 516 follows: 518 +------------------------------------------------------------+ 519 |edge_t edge(struct entity *ent1, | 520 | int port1, | 521 | struct entity *ent2, | 522 | int port2); | 523 +------------------------------------------------------------+ 524 edge is a quad(ent1,port1,ent2,port2),shows an edge that comes out 525 from ent1's port1 and comes into ent2's port2. 527 POP supports Path Planning API: 529 route 530 +------------------------------------------------------------+ 531 |struct route *route(void); | 532 |function::create a new empty route | 533 |input: | 534 | none | 535 |output: | 536 | new route | 537 +------------------------------------------------------------+ 538 route_free 539 +------------------------------------------------------------+ 540 |void route_free(struct route *r); | 541 |function::free route | 542 |input: | 543 | r route waiting for free | 544 |output: | 545 | none | 546 +------------------------------------------------------------+ 547 route_add_edge 548 +------------------------------------------------------------+ 549 |void route_add_edge(struct route *r,edge_t e); | 550 |function::add edge into route | 551 |input: | 552 | r route | 553 | e edge | 554 |output: | 555 +------------------------------------------------------------+ 556 route_union 557 +------------------------------------------------------------+ 558 |void route_union(struct route *r1,struct route *r2); | 559 |function::merge route r1 and r2 into r1 | 560 |input: | 561 | r1 route r1 | 562 | r2 route r2 | 563 |output: | 564 | none | 565 +------------------------------------------------------------+ 567 5 Example 569 The following is the example for Ethernet IPv4 unicast. 570 User need to define the protocol as follow: 571 +---------------------------+ 572 | header ipv4; | 573 | header arp; | 574 | header tcp; | 575 | header udp; | 576 | | 577 | header ethernet { | 578 | fields { | 579 | dl_dst : 48; | 580 | dl_src : 48; | 581 | dl_type : 16; | 582 | } | 583 | next select (dl_type) { | 584 | case 0x0800: ipv4; | 585 | case 0x0806: arp; | 586 | } | 587 | } | 588 | header ipv4 { | 589 | fields {ver : 4; | 590 | ihl : 4; | 591 | tos : 8; | 592 | len : 16; | 593 | id : 16; | 594 | flag : 3; | 595 | off : 13; | 596 | ttl : 8; | 597 | nw_proto : 8; | 598 | sum : 16; | 599 | nw_src : 32; | 600 | nw_dst : 32; | 601 | opt : *; | 602 | } length :ihl << 2; | 603 | next select (nw_proto) { | 604 | case 0x06 : tcp; | 605 | case 0x11 : udp; | 606 | } | 607 +---------------------------+ 609 After specifying the protocol,user can write the network algorithm 610 in C language with POP API as follow. 611 +--------------------------------------------------------+ 612 | struct route *f(struct packet *pkt) | 613 | { | 614 | /* operate packet*/ | 615 | assert(strcmp(read_header_type(pkt), "ethernet") == 0);| 616 | pull_header(pkt); | 617 | type = read_header_type(pkt); | 618 | if (strcmp(type, "ipv4") == 0) { | 619 | src_ip = read_packet(pkt, "nw_src"); | 620 | dst_ip = read_packet(pkt, "nw_dst"); | 621 | /* query the network topology*/ | 622 | hsrc = get_host_by_paddr(src_ip); | 623 | hdst = get_host_by_paddr(dst_ip); | 624 | /* Route generate */ | 625 | route = calc_path(hsrc, hdst); | 626 | push_header(pkt); | 627 | return route; | 628 | } | 629 | } | 630 +--------------------------------------------------------+ 631 The algorithm get the host nodes according to the source and 632 destination IP address in the packet.Then it calls the user- 633 defined function calc_path to compute a network path from the 634 source node to the destination node. 636 6 References 638 6.1 Normative References 640 [RFC7149] Boucadair, M., "Software-Defined Networking: A Perspective 641 from within a Service Provider Environment", RFC 7149, 642 March 2014. 644 [RFC7426] E. Haleplidis, Ed., "Software-Defined Networking (SDN): 645 Layers and Architecture Terminology", RFC 7426, January 646 2015. 648 6.2 Informative References 650 [OF-SPEC] Open Networking Foundation, "OpenFlow Switch 651 Specification, version 1.5.1", October 2015, 652 . 654 Authors' Addresses 656 Ye Tian 657 University of Science and Technology of China, 658 96 Jinzhai Rd., Hefei, Anhui, 230026, China. 660 EMail: yetian@ustc.edu.cn