Internet DRAFT - draft-irtf-sdnrg-pop
draft-irtf-sdnrg-pop
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
<Author> Expires <Expiry Date> [Page 1]
INTERNET DRAFT <Document Title> <Issue Date>
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
<Author> Expires <Expiry Date> [Page 2]
INTERNET DRAFT <Document Title> <Issue Date>
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
<type, offset, length>.
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
<Author> Expires <Expiry Date> [Page 3]
INTERNET DRAFT <Document Title> <Issue Date>
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 |
+--------+--------------------+----------------------+-------+
<Author> Expires <Expiry Date> [Page 4]
INTERNET DRAFT <Document Title> <Issue Date>
| | |
| | |
+--------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 |
<Author> Expires <Expiry Date> [Page 5]
INTERNET DRAFT <Document Title> <Issue Date>
|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 |
+------------------------------------------------------------+
<Author> Expires <Expiry Date> [Page 6]
INTERNET DRAFT <Document Title> <Issue Date>
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 |
+------------------------------------------------------------+
<Author> Expires <Expiry Date> [Page 7]
INTERNET DRAFT <Document Title> <Issue Date>
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 |
+------------------------------------------------------------+
<Author> Expires <Expiry Date> [Page 8]
INTERNET DRAFT <Document Title> <Issue Date>
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 |
+------------------------------------------------------------+
<Author> Expires <Expiry Date> [Page 9]
INTERNET DRAFT <Document Title> <Issue Date>
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 |
+------------------------------------------------------------+
<Author> Expires <Expiry Date> [Page 10]
INTERNET DRAFT <Document Title> <Issue Date>
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: |
+------------------------------------------------------------+
<Author> Expires <Expiry Date> [Page 11]
INTERNET DRAFT <Document Title> <Issue Date>
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:
<Author> Expires <Expiry Date> [Page 12]
INTERNET DRAFT <Document Title> <Issue Date>
+------------------------------------------------------------+
|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 |
+------------------------------------------------------------+
<Author> Expires <Expiry Date> [Page 13]
INTERNET DRAFT <Document Title> <Issue Date>
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*/ |
<Author> Expires <Expiry Date> [Page 14]
INTERNET DRAFT <Document Title> <Issue Date>
| 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,
<https://www.opennetworking.org>.
Authors' Addresses
Ye Tian
<Author> Expires <Expiry Date> [Page 15]
INTERNET DRAFT <Document Title> <Issue Date>
University of Science and Technology of China,
96 Jinzhai Rd., Hefei, Anhui, 230026, China.
EMail: yetian@ustc.edu.cn
<Author> Expires <Expiry Date> [Page 16]
