INTERNET-DRAFT Y. Tian Intended Status: Informational Univ. Sci. & Tech. of China Expires: July 6, 2017 January 5, 2017 Programming Model for Protocol Oblivious Forwarding SDN Networks draft-irtf-sdnrg-pop-00 Abstract This document presents POP, a Software-Defined Networking (SDN) programming model for the Protocol Oblivious Forwarding (POF) network. POF is an SDN forwarding plane technology proposed by Huawei. A POF forwarding element (FE) does no need to understand the packet format, and can be programmed to support new forwarding protocols. POP enables user to define forwarding protocols and program the POF SDN network on the centralized control plane with algorithmic policies that are expressed with high-level programming languages. 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 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Expires [Page 1] INTERNET DRAFT Copyright and License Notice Copyright (c) 2016 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 Programming Model . . . . . . . . . . . . . . . . . . . . . . . 4 3 Protocol Specification Language . . . . . . . . . . . . . . . . 5 4 Programming APIs for Protocol Oblivious Networking Algorithm . 7 4.1 Packet Operation API . . . . . . . . . . . . . . . . . . . . 7 4.2 Net Topology Search API . . . . . . . . . . . . . . . . . . 10 3.3 Path Planning API . . . . . . . . . . . . . . . . . . . . . 12 5 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.1 Normative References . . . . . . . . . . . . . . . . . . . 15 6.2 Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Expires [Page 2] INTERNET DRAFT 1 Introduction Software-Defined Networking (SDN)[RFC7149] gives operators programmatic control over their networks. In SDN, the control plane is physically separate from the forwarding plane, and one control plane controls multiple forwarding devices. In SDN, a common, open, vendor-agnostic interface between the control plane and the forwarding plane, which may contain forwarding devices from different hardware and software vendors, is required. OpenFlow is such an interface. In OpenFlow, operators express their rules with the abstractions that could match packets on a dozen header fields (e.g., MAC addresses, IP addresses, protocol, TCP/UDP port numbers, etc.), and specify the corresponding actions (e.g., output, drop, encapsulate, etc.). Generally speaking, 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[RFC7426] cannot resolve the aforementioned problem. 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. For this reason, Huawei presents the Protocol Oblivious Forwarding (POF) technology. The basic idea is to denote any protocol field, as well as the metadata, which is considered as one special protocol header that can be configured by the controller, with a triad of . POF also defines a set of protocol oblivious forwarding actions/instructions. The actions/instructions can realize the functions of all forwarding instructions/actions defined in OpenFlow, not only for the existing protocols but also for any new protocols. With the protocol oblivious data plane that are composed of POF forwarding devices, a programming model that enable user to program such a data plane is required. This memo presents POP, an open, easy- to-use, and efficient programming model. The memo describes a protocol specification language that enable user Expires [Page 3] INTERNET DRAFT to specify any network protocol that he intends to program on the POF network. Then the programming API that allows user to program the POF network is introduced. 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. Forwarding Plane (FP) - The collection of resources across all network devices responsible for forwarding traffic. Control Plane (CP) - The collection of functions responsible for controlling one or more network devices.CP instructs network devices with respect to how to process and forward packets. The control plane interacts primarily with the forwarding plane and, to a lesser extent, with the operational plane. Protocol Oblivious Forwarding (POF) - The protocol that is proposed by Huawei to provide a new way to develop SDN. 2 Programming Model To program a protocol oblivious data plane,the POP programming model use protocol specification language to specify the network protocol in the network.Then user can write their own network algorithm to program the POF network with the programming API.The run-time system in the POP Should transfer the algorithm to the accurate protocol oblivious forwarding actions/instructions and send to the POF Switches. +------------------------------------------------------------+ | +-----------------+ +-------------------------------+ | | |Network algorithm| |Protocol Specification Language| User | | +-----------------+ +-------------------------------+ | +------------------------------------------------------------+ +------------------------------------------------------------+ | POP Controller | +--------+--------------------+----------------------+-------+ Expires [Page 4] INTERNET DRAFT | | | | | | +--------v--------------------v----------------------v-------+ +------------------------------------------------------------+ | +-------------+ | | | POF Switch | | | +-------------+ | | +-------------+ +-------------| | | | POF Switch | | POF Switch | | | +-------------+ +-------------+ | +------------------------------------------------------------+ 3 Protocol Specification Language Protocol Specification Language is learned from P4. It include a number of protocol header definitions and a "start" symbol which represent the starting protocol header while parsing. User can define the protocol header layer by layer. The BNF normal form of Protocol Specification Language is showed as follows. Identifier and unsigned number: The "IDENT" represent Identifier. "NUMBER" represent unsigned number. "e" represent NULL. +------------------------------------------------------------+ |IDENT ::= [_a-zA-Z][_0-9a|zA-Z]* | |NUMBER ::= 0[bB][01]+|0[0|7]*|[1-9][0-9]*|0[xX][0-9a-fA-F]+ | +------------------------------------------------------------+ Main program: a number of protocol header definitions and "start" symbol. +------------------------------------------------------------+ |program ::= headers start | |start ::= "start" IDENT ";" | |headers ::= e | header headers | header_decl headers | +------------------------------------------------------------+ Header definition: Include header name, protocol fields list, header length, next-layer selection. +------------------------------------------------------------+ |header ::= "header" IDENT "{" fields length next "}" | |header_decl ::= "header" IDENT ";" | +------------------------------------------------------------+ Protocol fields: each field include a binary length. A protocol allows at most one field which length is uncertain and mark as "*". Meanwhile, it should at the end of the list. +------------------------------------------------------------+ |program ::= headers start | Expires [Page 5] INTERNET DRAFT |start ::= "start" IDENT ";" | |headers ::= e | header headers | header_decl headers | +------------------------------------------------------------+ Header length: option, is a expression consists of field name and constant. When it's implicit, the protocol fields list can calculate header length automatically. +------------------------------------------------------------+ |length ::= e | "length" ":" expr ";" | +------------------------------------------------------------+ Expression: follow language specification of C. Operator have different priority from high to low. Operator which have the same priority cannot bond except bracket. +------------------------------------------------------------+ |expr ::= IDENT | NUMBER | | |"(" expr ")" | (bracket) | |"~" expr | (NOT) | |expr "+" expr | expr "-" expr | (Add/Subtract) | |expr "<>" expr | expr "<>" expr | (shift logical left/right)| |expr "&" expr | (AND) | |expr "^" expr | (XOR) | |expr "|" expr (OR) | +------------------------------------------------------------+ Next-layer selection: according to value of one header field. Each case include the value and next-layer header name. Next header name can be recursive directly or indirectly. But the header name should has been defined or are defined. +------------------------------------------------------------+ |next ::= e | "next" "select" "(" IDENT ")" "{" cases "}" | |cases ::= e | "case" NUMBER ":" IDENT ";" cases | +------------------------------------------------------------+ Expires [Page 6] INTERNET DRAFT 4 Programming APIs for Protocol Oblivious Networking Algorithm Users make use of a series of API to define network algorithm.Functionly,those APIs include three parts which named 'Packet Operation','Net Topology Search' and 'Path Planing'. 4.1 Packet Operation API POP supports any kinds of protocol message format that the API for message operation doesn't rely on any specific protocol.As figure 2,POP supplies a 'layer-by-layer progressive' method by the concept of network protocol stack that the packet is parsed into many layers. POP supports for the following Packet Operation API: read_packet_inport +------------------------------------------------------------+ |int read_packet_inport(struct packet *pkt); | |function::read the enter port of packet | |input: | | pkt packet | |output: | | current packet enter port number of switch | +------------------------------------------------------------+ read_packet_inswitch +------------------------------------------------------------+ |struct entity *read_packet_inswitch(struct packet *pkt); | |function::read the enter switch of packet | |input: | | pkt packet | |output: | | current packet's enter switch number | +------------------------------------------------------------+ pull_header +------------------------------------------------------------+ | void pull_header(struct packet *pkt); | |function::move current header point to | | the next protocol layer | |input: | | pkt packet | |output: | | none | +------------------------------------------------------------+ Expires [Page 7] INTERNET DRAFT read_header_type +------------------------------------------------------------+ |const char *read_header_type(struct packet *pkt); | |function::read the name of current header | |input: | | pkt packet | |output: | | current header's name | +------------------------------------------------------------+ read_packet +------------------------------------------------------------+ |value_t read_packet(struct packet *pkt,const char *field); | |function::read fields of packet | |input: | | pkt packet | | field_name field name | |output | | value of current field_name | | | +------------------------------------------------------------+ test_equal +------------------------------------------------------------+ |bool test_equal(struct packet *pkt,const char *field, | | value_t value); | |function::test value of packet fields | |input: | | pkt packet | | field_name field_name | | value value waiting for test | |output: | | if field_name value is equal to value,return true; | | else return false | +------------------------------------------------------------+ read_payload +------------------------------------------------------------+ |const uint8_t *read_payload(struct packet *pkt,int *length);| |function::read payload of packet | |input: | | pkt packet | |output: | | relative to current header payload:len is output value,| | says return ^alue of byte stream length | +------------------------------------------------------------+ Expires [Page 8] INTERNET DRAFT mod_packet +------------------------------------------------------------+ |void mod_packet(struct packet *pkt,const char *field, | | value_t value); | |function::modify current header field value to 'value' | |input: | | pkt pakcet | | field field name | | value modifying value | |output: | | none | +------------------------------------------------------------+ push_header +------------------------------------------------------------+ |void push_header(struct packet *pkt); | |function::recover protocol header which is parser | |input: | | pkt packet | |output: | | none | +------------------------------------------------------------+ add_header +------------------------------------------------------------+ |void add_header(struct packet *pk,const char *proto); | |function::add proto field all zero to current packet header | |note:after use of add_header,you can use mod_packet to | | modify field value | |input: | | pkt packet | | proto name of header | |output: | | none | +------------------------------------------------------------+ add_field +------------------------------------------------------------+ |void add_field(struct packet *pkt,int offb,int lenb, | | value_t value); | |function::add field from offset is offb as current header, | | adding field length is lenb,value is | | value | |input: | | pkt pakcet | | offb offset relative to current head | | lenb length of adding field | | value adding field vlaue | |output: | | none | +------------------------------------------------------------+ Expires [Page 9] INTERNET DRAFT del_field +------------------------------------------------------------+ |void del_field(struct packet *pkt,int offb,int lenb); | |function::delete length is lenb's field from offset value | | is offb relative to current header | |input: | | pkt pakcet | | offb offset relative to current head | | lenb field length | |output: | | none | +------------------------------------------------------------+ 4.2 Net Topology Search API POP uses a figure to show network topology,entity is the node of figure and every entity is on behalf of a switch or a host which is stored by adjacent list.Users use centralized algorithms in the figure to plan possible paths between any two hosts. Data structure of entity as follows: +------------------------------------------------------------+ |enum entity_type { ENTITY_TYPE_HOST, ENTITY_TYPE_SWITCH }; | |struct entity_adj | |{ | |int out_port; | |int adj_in_port; | |struct entity *adj_entity; | |}; | +------------------------------------------------------------+ get_entity +------------------------------------------------------------+ |struct entity **get_entity(struct entity *e,int port); | |function::get entity which connects current entity | |input: | | e entity | | port port number | |output: | | entity | +------------------------------------------------------------+ Expires [Page 10] INTERNET DRAFT get_entity_type +------------------------------------------------------------+ |enum entity_type get_entity_type(struct entity *e); | |function::get the type of entity | |input: | | e entity | |output | | type of entity | +------------------------------------------------------------+ get_switch_dpid +------------------------------------------------------------+ |dpid_t get_switch_dpid(struct entity *e); | |function::get dpid of entity switch | |input: | | e entity | |output: | | dpid | +------------------------------------------------------------+ get_host_adj_switch +------------------------------------------------------------+ |struct entity *get_host_adj_switch(struct entity *e, | | int *sw_port); | |function::get host connecting switch | |input: | | e entity | |output: | | if e is a host,return its connecting switch | | sw_port is output ,return port number of switch | +------------------------------------------------------------+ get_entity_adjs +------------------------------------------------------------+ |const struct entity_adj *get_entity_adjs(struct entity *e, | | int *pnum); | |function::get adjacent list of entity | |input: | | e entity | |output: | | adjacent of entity | | output parameter is pnum,return length of list | +------------------------------------------------------------+ print_entity +------------------------------------------------------------+ |void print_entity(struct entity *e); | |function::output related information of entity | |input: | | e entity | |output: | +------------------------------------------------------------+ Expires [Page 11] INTERNET DRAFT get_switches +------------------------------------------------------------+ |struct entity **getswitches(int *pnum); | |function::get all lists of switches in net | |input: | | none | |output: | | return all switch lists | | output parameter is pnum,return number of switches | +------------------------------------------------------------+ get_switch +------------------------------------------------------------+ |struct entity *get_switch(dpid_t dpid); | |function::search the switch according to dpid | |input: | | dpid switch number | |output: | | switch entity whose switch number is dpid | +------------------------------------------------------------+ get_host_by_haddr +------------------------------------------------------------+ |struct entity *get_host_by_haddr(haddr_t addr); | |function::search host according to hardware address | |input: | | addr host hardware address | |output: | | host entity whose hardware address is addr | +------------------------------------------------------------+ get_host_by_paddr +------------------------------------------------------------+ |struct entity *get_host_by_paddr(uint32_t addr); | |function::search host according to protocol address | |input: | | addr host protocol address | |output: | | host entity whose protocol address is addr | +------------------------------------------------------------+ 3.3 Path Planning API Network algorithm plans forwarding paths according to content of packet and topology.Type of route is struct route,which consists of some edges connecting source host and destination host.As follows: Expires [Page 12] INTERNET DRAFT +------------------------------------------------------------+ |edge_t edge(struct entity *ent1, | | int port1, | | struct entity *ent2, | | int port2); | +------------------------------------------------------------+ edge is a quad(ent1,port1,ent2,port2),shows an edge that comes out from ent1's port1 and comes into ent2's port2. POP supports Path Planning API: route +------------------------------------------------------------+ |struct route *route(void); | |function::create a new empty route | |input: | | none | |output: | | new route | +------------------------------------------------------------+ route_free +------------------------------------------------------------+ |void route_free(struct route *r); | |function::free route | |input: | | r route waiting for free | |output: | | none | +------------------------------------------------------------+ route_add_edge +------------------------------------------------------------+ |void route_add_edge(struct route *r,edge_t e); | |function::add edge into route | |input: | | r route | | e edge | |output: | +------------------------------------------------------------+ route_union +------------------------------------------------------------+ |void route_union(struct route *r1,struct route *r2); | |function::merge route r1 and r2 into r1 | |input: | | r1 route r1 | | r2 route r2 | |output: | | none | +------------------------------------------------------------+ Expires [Page 13] INTERNET DRAFT 5 Example The following is the example for Ethernet IPv4 unicast. User need to define the protocol as follow: +---------------------------+ | header ipv4; | | header arp; | | header tcp; | | header udp; | | | | header ethernet { | | fields { | | dl_dst : 48; | | dl_src : 48; | | dl_type : 16; | | } | | next select (dl_type) { | | case 0x0800: ipv4; | | case 0x0806: arp; | | } | | } | | header ipv4 { | | fields {ver : 4; | | ihl : 4; | | tos : 8; | | len : 16; | | id : 16; | | flag : 3; | | off : 13; | | ttl : 8; | | nw_proto : 8; | | sum : 16; | | nw_src : 32; | | nw_dst : 32; | | opt : *; | | } length :ihl << 2; | | next select (nw_proto) { | | case 0x06 : tcp; | | case 0x11 : udp; | | } | +---------------------------+ After specifying the protocol,user can write the network algorithm in C language with POP API as follow. +--------------------------------------------------------+ | struct route *f(struct packet *pkt) | | { | | /* operate packet*/ | Expires [Page 14] INTERNET DRAFT | assert(strcmp(read_header_type(pkt), "ethernet") == 0);| | pull_header(pkt); | | type = read_header_type(pkt); | | if (strcmp(type, "ipv4") == 0) { | | src_ip = read_packet(pkt, "nw_src"); | | dst_ip = read_packet(pkt, "nw_dst"); | | /* query the network topology*/ | | hsrc = get_host_by_paddr(src_ip); | | hdst = get_host_by_paddr(dst_ip); | | /* Route generate */ | | route = calc_path(hsrc, hdst); | | push_header(pkt); | | return route; | | } | | } | +--------------------------------------------------------+ The algorithm get the host nodes according to the source and destination IP address in the packet.Then it calls the user- defined function calc_path to compute a network path from the source node to the destination node. 6 References 6.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. 6.2 Informative References [OF-SPEC] Open Networking Foundation, "OpenFlow Switch Specification, version 1.5.1", October 2015, . Authors' Addresses Ye Tian Expires [Page 15] INTERNET DRAFT University of Science and Technology of China, 96 Jinzhai Rd., Hefei, Anhui, 230026, China. EMail: yetian@ustc.edu.cn Expires [Page 16]