Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
BEBA
Behavioural Based Forwarding
Grant Agreement: 644122
BEBA/WP3 – D3.1 Version: 2.0 Page 1 of 37
BEBA Behavioural Based
Forwarding
Deliverable Report
D3.1 – BEBA data plane extensions
Deliverable title BEBA data plane extensions
Version 2.0
Due date of deliverable (month)
June 2015
Actual submission date of the deliverable (dd/mm/yyyy)
30th June 2015
Start date of project (dd/mm/yyyy)
01/01/2015
Duration of the project 27 months
Work Package WP3
Task T3.1
Leader for this deliverable Thales Communications & Security (TCS)
Other contributing partners NEC, CNIT, CESNET
Authors
TCS: J. Boite, M. Bouet ; NEC: F. Huici ;
CNIT: G. Procissi, N. Bonelli ; CES: V. Bartoš, L. Kekely, V. Puš, M. Žádníkall
Deliverable reviewer(s) - M. Bonola (CNIT) - R. Bifulco (NEC)
Deliverable abstract
This deliverable presents the BEBA data plane extensions. From the requirements identified through
the analysis of the use cases proposed in D5.1, this deliverable gives a first list of primitives to be included in the BEBA data plane API. This API will allow to set-up
programmable advanced data plane functionalities in the BEBA nodes. This deliverable describes which
functionalities are required and identifies whether or not existing SDN implementations provide those features. It also gives a first generic description of the extensions
that are required and that will be implemented in other WP3 tasks. This initial description will be refined in
deliverable D3.2.
Keywords Data plane requirements, API, specification
BEBA
Behavioural Based Forwarding
Grant Agreement: 644122
BEBA/WP3 – D3.1 Version: 2.0 Page 2 of 37
Project co-funded by the European Commission within the Horizon 2020
(H2020) Programme
DISSEMINATION LEVEL PU Public X PP Restricted to other programme participants (including the Commission
Services)
RE Restricted to a group specified by the consortium (including the Commission Services)
CO Confidential, only for members of the consortium (including the Commission Services)
REVISION HISTORY
Revision Date Author Organisation Description
0.1 12-02-2015 J. Boite TCS First draft of the document, with ToC
0.2 08-06-2015 J. Boite TCS First contributions integrated
0.3 16-06-2015 J. Boite TCS Integration of other contributions
1.0 23-06-2015 J. Boite TCS Integration of last contributions + improvements
1.1 26-06-2015 J. Boite TCS Adjustments and improvements
2.0 30-06-2015 J. Boite TCS Integration of internal reviewers’ comments and changes; final revision
PROPRIETARY RIGHTS STATEMENT
This document contains information, which is proprietary to the BEBA consortium. Neither this document nor the
information contained herein shall be used, duplicated or communicated by any means to any third party, in whole or
in parts, except with the prior written consent of the BEBA consortium. This restriction legend shall not be altered or
obliterated on or from this document.
STATEMENT OF ORIGINALITY
This deliverable contains original unpublished work except where clearly indicated otherwise. Acknowledgement of
previously published material and of the work of others has been made through appropriate citation, quotation or
both.
BEBA
Behavioural Based Forwarding
Grant Agreement: 644122
BEBA/WP3 – D3.1 Version: 2.0 Page 3 of 37
TABLE OF CONTENT
EXECUTIVE SUMMARY ................................................................................................ 6
INTRODUCTION .......................................................................................................... 7
1 BEBA ARCHITECTURE OVERVIEW......................................................................... 8
1.1 BEBA OBJECTIVE AND GENERAL ARCHITECTURE ............................................................... 8
1.2 RELATIONSHIPS WITH OTHER BEBA WORK PACKAGES AND TASKS ......................................... 9
2 BEBA REQUIREMENTS FOR ADVANCED IN-SWITCH PROCESSING ...................... 11
2.1 LIST OF RELEVANT REQUIREMENTS ............................................................................ 11
2.1.1 REQ-D1 Programmable memory pool ........................................................... 11 2.1.2 REQ-D2 Access packet metadata (input port, packet length, timestamp).......... 11 2.1.3 REQ-D3 Support for basic mathematical/logic operations ............................... 11 2.1.4 REQ-D4 Flow counters ............................................................................... 13 2.1.5 REQ-D5 Modification/insertion of forwarding entries ...................................... 13 2.1.6 REQ-D6 Timers ......................................................................................... 13 2.1.7 REQ-D7 Configurable Packet queues ............................................................ 13 2.1.8 REQ-D8 Configurable Packet schedulers ....................................................... 13 2.1.9 REQ-D9 Extended Flow Match ..................................................................... 13 2.1.10 REQ-D10 Support for comparison operations (=, >=, etc.).......................... 13 2.1.11 REQ-D11 Update flow state action ............................................................ 14 2.1.12 REQ-D12 Definition of triggers to update memory content .......................... 14 2.1.13 REQ-D13 Support for special purpose modules e.g., DPI, encryption ............ 14 2.1.14 REQ-D14 Set up tunnel end-points ........................................................... 14 2.1.15 REQ-D15 Packet generation .................................................................... 14 2.1.16 REQ-D16 Read different flow states for different flow keys .......................... 14 2.1.17 REQ-D17 Flexible state key definition (e.g., range, wildcard) ....................... 15 2.1.18 REQ-D18 Push/pop of labels .................................................................... 15 2.1.19 REQ-P3 Programmable data collection/export (IPFIX like) ........................... 15
2.2 CLASSIFICATION OF REQUIREMENTS .......................................................................... 15
3 BEBA DATA PLANE API ....................................................................................... 17
3.1 STATISTICS, METERING COLLECTION AND SIMPLE IN-NODE PROCESSING ................................ 17
3.1.1 Objective ................................................................................................. 17 3.1.2 Existing primitives ..................................................................................... 17 3.1.3 Extended primitives ................................................................................... 18
3.2 PROGRAMMABLE TRIGGERING CONDITIONS .................................................................. 21
3.2.1 Objective ................................................................................................. 21 3.2.2 Existing primitives ..................................................................................... 21 3.2.3 Extended primitives ................................................................................... 21
3.3 PACKET MATCHING FACILITIES ................................................................................. 22
3.3.1 Objective ................................................................................................. 22 3.3.2 Existing primitives ..................................................................................... 22
BEBA
Behavioural Based Forwarding
Grant Agreement: 644122
BEBA/WP3 – D3.1 Version: 2.0 Page 4 of 37
3.3.3 Extended primitives ................................................................................... 23 3.4 PACKET FORWARDING AND PROCESSING ACTIONS .......................................................... 26
3.4.1 Objective ................................................................................................. 26 3.4.2 Existing primitives ..................................................................................... 26 3.4.3 Extended primitives ................................................................................... 26
3.5 ADVANCED IN-NODE PROCESSING ............................................................................. 30
3.5.1 Objective ................................................................................................. 30 3.5.2 Existing primitives ..................................................................................... 30 3.5.3 Extended primitives ................................................................................... 30
3.6 SUMMARY OF EXTENDED PRIMITIVES .......................................................................... 30
4 EXAMPLE WORKFLOW ........................................................................................ 33
CONCLUSION ............................................................................................................ 36
REFERENCES ............................................................................................................. 37
BEBA
Behavioural Based Forwarding
Grant Agreement: 644122
BEBA/WP3 – D3.1 Version: 2.0 Page 5 of 37
LIST OF FIGURES
Figure 1 - BEBA general architecture and components........................................................ 8
Figure 2 - Simple in-node processing in BEBA ................................................................. 19
Figure 3 - Flexible matching in BEBA .............................................................................. 25
Figure 4 - Overall architecture for use case UC05 ............................................................ 33
Figure 5 - State machine for UC05 ................................................................................. 34
LIST OF TABLES
Table 1 - Use case and application scenarios ................................................................... 12
Table 2 - Parameters for tunnel enpoints ........................................................................ 28
BEBA
Behavioural Based Forwarding
Grant Agreement: 644122
BEBA/WP3 – D3.1 Version: 2.0 Page 6 of 37
Executive summary
This document corresponds to the deliverable D3.1, “BEBA data plane extensions” of the
H2020 BEBA project. From the requirements previously identified in deliverable D5.1 “Use case
and application scenarios”, this deliverable studies which dataplane primitives must be
available to setup BEBA’s advanced in-network functionalities. This document provides an
analysis of the requirements extracted from use cases, and identifies which existing primitives
will be necessary and which primitives must be extended or defined to go beyond traditional
SDN networks capabilities.
This deliverable provides a first list of extended primitives that will be developed in other tasks
(especially T3.2). This list will be refined along with a collaborative work with other tasks, not
only in WP3 but also in WP2 and WP4. A more precise and definitive list of primitives will be
provided in deliverable D3.2 (December 2015).
BEBA
Behavioural Based Forwarding
Grant Agreement: 644122
BEBA/WP3 – D3.1 Version: 2.0 Page 7 of 37
Introduction
In this deliverable, we propose a first list of dataplane extended primitives that must be
available to provide BEBA’s in-network advanced functionalities. We first analyse the set of
dataplane requirements identified in deliverable D5.1, and propose to classify them according
to their role. For each of those categories, we then identify which primitives are already offered
by the traditional SDN approach (OpenFlow), and derive a list of extended primitives that will
be developed to enable advanced in-network functionalities beyond those offered by traditional
SDN networks. This list will be refined and detailed in a future deliverable (D3.2), after
collaborative work among work packages.
This document is organized as follows: section 1 provides an architecture overview. It reminds
the general SDN architecture, and helps in identifying where data-plane and control-plane
extensions take place and which work packages and tasks are responsible for the definition of
each kind of extensions. Section 2 reminds the relevant dataplane requirements and proposes
a classification of those requirements. Section 3 provides a list of existing and extended
primitives for each class of requirements. Before concluding this document, section 4
illustrates how some of the extended primitives will be used with a use case example.
BEBA
Behavioural Based Forwarding
Grant Agreement: 644122
BEBA/WP3 – D3.1 Version: 2.0 Page 8 of 37
1 BEBA architecture overview
This section proposes a summary that reminds how BEBA will operate to provide advanced in-
switch functionalities and delegate some control tasks to a BEBA node. Since some interactions
with other tasks and work packages (WP2, WP4, other tasks into WP3) are fundamental to
define a consolidated set of instructions to be available at different levels of interfaces, we also
remind those interactions in this section.
1.1 BEBA objective and general architecture
First of all, the objective of BEBA is extending the SDN protocols and functionalities that are
available today, while remaining fully compatible with them. As such, the traditional SDN
architecture is considered as the starting point. One goal of BEBA is to enable the
programming of the network’s behaviour by specifying network applications as finite state
machines (FSM). Basically, the idea is to specify how a BEBA node is supposed to behave
under the form of a FSM, and to rely on the SDN controller to set this specified behaviour into
the BEBA switches. While the SDN controller keeps full control of the network, the FSM loaded
into BEBA nodes sets up some new stateful rules locally. Those rules allow specifying and
managing specific conditions, events and advanced actions that drive the behaviour of the
BEBA switches.
The components of the BEBA architecture necessary to achieve this general principle are
represented in Figure 1. The role of each category of components is detailed below.
Figure 1 - BEBA general architecture and components
BEBA
Behavioural Based Forwarding
Grant Agreement: 644122
BEBA/WP3 – D3.1 Version: 2.0 Page 9 of 37
Three categories of components have been identified:
- Switch/Controller (SW/CTRL) interactions: components belonging to this category
(blue boxes in Figure 1) deal with control plane interactions between the controller and
BEBA switches. This covers both “traditional” control plane interactions that exist
between a switch and its controller (OpenFlow), but also new elements introduced with
BEBA. In particular, they also support, e.g., sending notifications from a switch to the
controller and controlling in-switch packet generation.
- Finite State Machine (FSM) definition and processing: the components
represented in orange in Figure 1 deal with the FSM machinery. They cover both the
definition of a FSM, the initialization of specific state table and several elements such as
timers or counters that are necessary to manage the state machine lifecycle (transitions
from one state to another etc.). Finally, those components allow one at setting up the
required elements into the BEBA switch to make it behave according to the state
machine received from the controller.
- In-switch processing: this interface covers the elements that must exist in a BEBA
switch to enable advanced data path and switching functionalities. It includes specific
internal treatments such as monitoring of flows, extensions to allow the switch to self-
modify its forwarding rules or fill-in some fields of packets it generates according to the
state machine lifecycle or to instructions sent by the controller.
1.2 Relationships with other BEBA work packages and tasks
The separation of the control and data planes is a clear statement of the SDN approach, and
BEBA keeps this separation. With BEBA, however, some control plane actions are going to be
implemented into the switches, directly. These actions are programmed by the controller,
which remains in full control of the switch behaviour while being offloaded of some tasks. This
scheme allows not only improving scalability and reaction times, but also decreasing latency
and avoiding the presence of a single point of failure. Because the BEBA switch has to deal
with some control tasks beyond communicating with the controller, it is important to clarify the
role of each previously described category of components and to identify which of them
addresses new functionalities related to the control plane, the data plane, or the programming
of nodes.
Several work packages in the project focus on one of those activities:
- WP2: programming of nodes,
- WP3: data plane extensions,
- WP4: control plane extensions.
As explained before, the whole BEBA node APIs are finally going to cover multiple actions
related to those three activities. We decided to split the work of describing the API primitives
that are required for setting up BEBA’s advanced in-switch functionalities among work
packages, according to their respective activities. As a consequence:
- WP2 deals with the specification of the programming abstraction and extensions that
are required in a BEBA switch, including initialization of the state machine structure and
execution of its lifecycle. This maps the definition of the “FSM definition and processing”
components shown in Figure 1.
BEBA
Behavioural Based Forwarding
Grant Agreement: 644122
BEBA/WP3 – D3.1 Version: 2.0 Page 10 of 37
- WP4 deals with the specification of the control plane extensions that are required to
enable BEBA specific communications, i.e. potential extensions to allow the
management of notifications and the control of state queries and packet generation.
This maps the definition of the “SW/CTRL interactions” components shown in Figure 1.
- WP3, and this deliverable in particular, deals with the specification of data plane
extensions that enable advanced monitoring, packet matching, and forwarding
functionalities. This maps the definition of the “in-switch processing” components shown
in red in Figure 1. This deliverable also covers the specification of switch-internal
mechanisms that are required as enablers for the extensions defined in other work
packages. For instance, programming the behaviour of a switch may require configuring
some timers in order to trigger events (state transitions) or perform advanced actions.
The primitives that are necessary for setting up such timers, as well as primitives to
allow performing advanced actions are covered in this deliverable.
Assumptions about how the whole BEBA ecosystem will operate and how all the components
interact are unavoidable at this stage of the project. In this deliverable, we cover the in-switch
processing requirements in a generic way. The descriptions will be revised according to
ongoing discussions with other work packages and implementation work. Other primitives are
analysed in WP2 or WP4 deliverables.
BEBA
Behavioural Based Forwarding
Grant Agreement: 644122
BEBA/WP3 – D3.1 Version: 2.0 Page 11 of 37
2 BEBA requirements for advanced in-switch processing
From the deliverable D5.1 provided by WP5, we have extracted a list of requirements that are
particularly relevant for studying dataplane functionalities and specifying which new primitives
will be developed and made available through the so called “BEBA dataplane API”. Those
requirements are given in the next subsection, and then classified according to the extended
functionalities they offer.
Use cases and application scenarios are referenced by their number in the description of
requirements. Table 1 provides the list of use cases that have been described in deliverable
D5.1 (for more details, the reader is invited to refer to deliverable D5.1).
2.1 List of relevant requirements
2.1.1 REQ-D1 Programmable memory pool
Description: A programmable memory pool offers an area to store variable values that can be
referenced later on by a logic, e.g. implemented by a FSM.
Used for: use case 2 uses the memory area to store flow statistics that will be eventually
reported to a controller. Use case 6 uses it to store flow information such as the round trip
time between packets in bidirectional flows, while use case 8 uses the memory area to store
e.g., expected minimum packets inter-arrival time. Likewise, use case 9 uses the memory to
store threshold values to compare against.
Support in OpenFlow: the closer OpenFlow features to a memory pool are synchronized
table, introduced in OpenFlow 1.4, and flows’ metadata. However, synchronized tables are still
far from a general memory pool that can be accessed by the switch logic when required. The
OpenFlow set metadata instruction can be used to attach only a small fixed amount of data to
a specific flow entry.
2.1.2 REQ-D2 Access packet metadata (input port, packet length, timestamp)
Description: each packet is enriched with additional metadata information that are packet-
specific instead of flow-specific. This may include information like packet length or reception
timestamp.
Used for: Use cases like use case 2 and 3 use this metadata to detect specific flow behaviours
and state.
Support in OpenFlow: OpenFlow currently defines only per-flow behaviours using the flow
tables. Per-packet behaviours can be specified in a group table but currently the implemented
logic is limited and fixed by the switch vendor.
2.1.3 REQ-D3 Support for basic mathematical/logic operations
Description: mathematical and logical operations (SUB, ADD, OR, etc.) are used to perform
processing on memory stored values and flows or packets related data, such as header values
or metadata.
Used for: the operations are required to e.g., collect aggregated statistics for a flow or for a
set of flows (see use case 2).
Support in OpenFlow: OpenFlow currently only performs per flow addition operation of the
flow counters.
BEBA
Behavioural Based Forwarding
Grant Agreement: 644122
BEBA/WP3 – D3.1 Version: 2.0 Page 12 of 37
Table 1 - Use case and application scenarios
BEBA
Behavioural Based Forwarding
Grant Agreement: 644122
BEBA/WP3 – D3.1 Version: 2.0 Page 13 of 37
2.1.4 REQ-D4 Flow counters
Description: collect per-flow statistics such as transferred bytes, packets and flow duration
Used for: monitor the status and behaviour of a flow. This is a common requirement reported
by many use cases such as use case 4, 5 and 13.
Support in OpenFlow: OpenFlow currently supports flow counters.
2.1.5 REQ-D5 Modification/insertion of forwarding entries
Description: enable the switch at creating or modifying flow entries.
Used for: monitor the status and behaviour of a flow. This is a common requirement reported
by many use cases such as use case 4, 5, 11 and 13.
Support in OpenFlow: OpenFlow currently supports automatic entries modification only for
synchronized tables. Entries deletion can be also in some way automated using timeouts.
2.1.6 REQ-D6 Timers
Description: introduce the possibility of having timed events.
Used for: timers are used in many use cases to implement timeouts, for instance to check if a
tunnel (use case 10 and 13) or an end-point (use case 3) are alive. Also they can be used to
perform calculation of some advanced flow statistics such as packet rates, or simply to rollback
a flow status to a default value.
Support in OpenFlow: OpenFlow currently supports timeout definition for flow entries but
there is not explicit way to define other timers.
2.1.7 REQ-D7 Configurable Packet queues
Description: monitor the occupation of the packet queues and modify their size dynamically.
Used for: this is used to implement some adaptive QoS on network flows (use case 4).
Support in OpenFlow: currently not supported.
2.1.8 REQ-D8 Configurable Packet schedulers
Description: change the packet scheduler behavior.
Used for: this is used to implement some adaptive QoS on network flows (use case 4).
Support in OpenFlow: group table selection logic may be used to implement something
similar to a packet scheduler. However, current OpenFlow specification does not give the
possibility of changing it.
2.1.9 REQ-D9 Extended Flow Match
Description: enable flow table entries at matching on additional packet headers such as TTL
and TCP flags.
Used for: implementing some anomaly detection logic.
Support in OpenFlow: in version 1.5 OpenFlow introduces the matching on TCP flags.
2.1.10 REQ-D10 Support for comparison operations (=, >=, etc.)
Description: enable the switch at performing comparison operations between variables taken
from e.g., packet’s header values, stored memory variables, etc.
Used for: comparison is required in all the use cases that use threshold verification to detect
the occurrence of some network events. Examples include anomaly detection use cases, such
BEBA
Behavioural Based Forwarding
Grant Agreement: 644122
BEBA/WP3 – D3.1 Version: 2.0 Page 14 of 37
as use case 5, but also other use cases that perform load balancing (use case 6) or policy
enforcement (use case 13).
Support in OpenFlow: no support in OpenFlow.
2.1.11 REQ-D11 Update flow state action
Description: introduces an action for a flow entry which updates the corresponding entry
state.
Used for: implementing state transition in the switch.
Support in OpenFlow: no support in OpenFlow.
2.1.12 REQ-D12 Definition of triggers to update memory content
Description: introduces of a mechanism that changes stored memory values in response to
an event, such as the reception of a packet.
Used for: implementing dynamic condition checking, e.g., round trip time evaluation (use
case 6).
Support in OpenFlow: no support in OpenFlow.
2.1.13 REQ-D13 Support for special purpose modules e.g., DPI, encryption
Description: introduces the possibility to send the traffic to a special purpose processing
module that extends the switch functions.
Used for: implementing advanced use cases that require e.g., Deep Packet Inspection,
encryption, etc.
Support in OpenFlow: OpenFlow can support this by dedicating some switch’s port to the
special purpose module, or by defining special logical ports.
2.1.14 REQ-D14 Set up tunnel end-points
Description: allows the creation of tunnel end-points in the switch
Used for: adding tunnel termination to a switch (e.g., use cases 11 and 13).
Support in OpenFlow: OpenFlow has support for identifying a logical tunnel termination port
but does not support directly the tunnel creation.
2.1.15 REQ-D15 Packet generation
Description: enables the switch to create packets that are injected in the datapath.
Used for: creating probe packets (use case 6), answering tunnelling protocols echo messages
(use cases 11 and 13), etc.
Support in OpenFlow: OpenFlow requires an interaction with the controller to generate a
packet, using the OFP_PACKET_OUT message.
2.1.16 REQ-D16 Read different flow states for different flow keys
Description: introduces the possibility to write or read state associated to a given flow
(identified by a key).
Used for: implementing the basic mechanisms behind the FSM abstraction realization. It
allows retrieving the state associated with a given flow.
Support in OpenFlow: no support.
BEBA
Behavioural Based Forwarding
Grant Agreement: 644122
BEBA/WP3 – D3.1 Version: 2.0 Page 15 of 37
2.1.17 REQ-D17 Flexible state key definition (e.g., range, wildcard)
Description: introduces the possibility of using wildcard values for the flow keys used to
retrieve a flow state.
Used for: some use cases adopt the wildcard to identify state associated to e.g., an IP subnet
(use case 10).
Support in OpenFlow: no support.
2.1.18 REQ-D18 Push/pop of labels
Description: add or remove labels from packet headers.
Used for: used to implement tunnels and packet marking.
Support in OpenFlow: OpenFlow currently supports labelling operations (e.g., VLAN and
MPLS).
2.1.19 REQ-P3 Programmable data collection/export (IPFIX like)
This requirement relates to the possibility of a programmer to instantiate an IPFIX[6]-like data
collection process in the switch and to instruct the switch itself to provide the gathered data to
a collector node (e.g. the controller). Building blocks of such a feature can be found in the
ability of OpenFlow to maintain counters and statistics for each flow. Unfortunately, OpenFlow
does not allow defining aggregates of such counters or even to program more complex
monitoring functionalities. This feature is required, for example, by use case 2 in order to
export portion of traffic for post-processing by external modules performing deeper analysis.
2.2 Classification of requirements
We propose to classify the requirements into different categories according to what
functionality they bring or enhance. More particularly, we identified the following categories:
- Statistics, metering collection and simple in-node processing:
o This category includes requirements D1, D3, D4, D10, D16, D17 and P3.
o This set of requirements covers extensions to program and maintain a dataset
collection in a BEBA node, and to perform simple processing on this information.
- Programmable triggering conditions:
o This category includes requirements D6 and D12.
o This set of requirements covers extensions to allow programming of timers that
trigger automatic or pre-configured actions.
- Packet matching facilities:
o This category includes requirement D9.
o This requirement covers extensions for packet matching, such as parsing
packets’ headers or metadata.
- Packet forwarding and processing actions:
o This category includes requirements D2, D5, D7, D8, D11, D14, D15 and D18.
o This set of requirements covers existing and new forwarding actions to control
packets forwarding and manipulation.
- Advanced in-node processing:
o This category includes requirement D13.
o This requirement covers the new ability of running in a BEBA node specific
computation modules (e.g. DPI).
BEBA
Behavioural Based Forwarding
Grant Agreement: 644122
BEBA/WP3 – D3.1 Version: 2.0 Page 16 of 37
For each category, we studied the requirements and analysed whether or not the existing
primitives fulfil them. We then identified a set of new functionalities or extensions that must be
developed. A first description of those extended primitives is given in the next section. This
description remains generic at this stage of the project. Ongoing discussions and collaborative
work among work packages to define more precisely the whole BEBA ecosystem will allow
refining those primitives in a second deliverable (D3.2, due in December 2015).
BEBA
Behavioural Based Forwarding
Grant Agreement: 644122
BEBA/WP3 – D3.1 Version: 2.0 Page 17 of 37
3 BEBA data plane API
In this section, we analyse the existing primitives for each category of requirements. We
identify some primitive extensions and some new primitives that must be developed to allow
setting up BEBA’s advanced in-switch functionalities.
3.1 Statistics, metering collection and simple in-node processing
3.1.1 Objective
The main objective of this part of the API is to satisfy requirements of BEBA use cases
proposed in deliverable D5.1. Especially, the use case UC02: Programmable network flow
measurement explicitly requires support of statistics and metering collection functionality.
Other use cases also require some basic in-node processing support, for example, UC05:
Adaptive treatment of unexpected traffic and UC06: Forwarding Consistency both need some
in-node threshold verification functionality, or UC13: Flexible Evolved Packet Core works with
information about the status and behaviour of flows.
Data plane requirements derived in D5.1, which can be included into statistics metering and
simple in-node processing functionality in BEBA, are:
REQ-D1: Programmable memory pool
REQ-D3: Support for basic mathematical/logic operations
REQ-D4: Flow counters
REQ-D10: Support for comparison operations
REQ-D16: Read different flow states for different flow keys
REQ-D17: Flexible state key definition (e.g., range, wildcard).
BEBA nodes programmability requirement REQ-P3: Programmable data collection / export
(IPFIX like) can be also included into this group.
Only a few of these requirements are (at least to some extent) met by existing primitives in current OpenFlow standard [1]. Therefore, some additional extended primitives must be
defined in BEBA API to fully support the given requirements.
3.1.2 Existing primitives
The latest OpenFlow specification defines only one basic primitive for traffic metering that can
be used to derive just simple volumetric statistics. Specifically, OpenFlow directly defines a set
of 40 numerical counters in domains of flows, packets, bytes or time. Collection of any other
(more detailed) statistics as well as any more advanced in-node processing required in BEBA
are not supported in current OpenFlow. Therefore, the BEBA API must possess a significantly
richer set of primitives compared to OpenFlow.
3.1.2.1 Metering using counters in OpenFlow
As simple means for traffic metering, the OpenFlow standard defines several numerical
counters. Some counters are maintained for each flow table, flow entry, port, queue, group,
BEBA
Behavioural Based Forwarding
Grant Agreement: 644122
BEBA/WP3 – D3.1 Version: 2.0 Page 18 of 37
group bucket, meter and meter band. Here follows the set of all counters defined by the
specification:
Per Flow Table: reference count (flow entries), packet lookups, packet matches.
Per Flow Entry: received packets, received bytes, duration (seconds), duration
(nanoseconds).
Per Port: received packets, transmitted packets, received bytes, transmitted bytes,
receive drops, transmit drops, receive errors, transmit errors, receive frame alignment
errors, receive overrun errors, receive CRC errors, collisions, duration (seconds),
duration (nanoseconds).
Per Queue: transmit packets, transmit bytes, transmit overrun errors, duration
(seconds), duration (nanoseconds).
Per Group: reference count (flow entries), packet count, byte count, duration
(seconds), duration (nanoseconds).
Per Group Bucket: packet count, byte count.
Per Meter: flow count, input packet count, input byte count, duration (seconds),
duration (nanoseconds).
Per Meter Band: in band packet count, in band byte count.
A switch is not required to support all forty above counters, just those nine marked by bold
font. Counters are 32 or 64 bits wide, unsigned and wrap around with no overflow indicator. If
a specific numeric counter is not available in the switch, its value must be set to the maximum
field value (the unsigned equivalent of -1).
All counter values can be periodically polled by OpenFlow controllers (StatsRequest messages).
Additionally, values of per flow counters can be automatically sent from the switch to the
controller upon flow entry removal (FlowRemoved message).
For purposes of BEBA, per-flow counters are the most significant as they completely satisfy
REQ-D4: Flow counters and can be taken as partially satisfying REQ-D3: Support for basic
mathematical/logic operations (per-flow addition) and REQ-P3: Programmable data
collection/export (IPFIX like). Using these per-flow counters, basic volumetric statistics about
flows can be obtained, like for example duration and size (in packet and bytes). Furthermore,
packet rate or byte rate of individual flows can be obtained by periodical polling of these
counters values.
3.1.3 Extended primitives
The goal of BEBA is to extend OpenFlow to bring better programmability and flexibility to the
switches, enabling their deployment in wider scale of use cases. As OpenFlow defines only very
basic statistics and metering collection primitives, a whole new concept of basic in-node
processing primitives has to be specified in BEBA to meet all of the given requirements.
3.1.3.1 Simple in-node processing concept
The in-node processing is performed upon reception of a packet. It can be decomposed into
three consecutive steps: Search, Update and Comparison. A basic conceptual schema of the
BEBA in-node processing architecture is shown in Figure 2.
BEBA
Behavioural Based Forwarding
Grant Agreement: 644122
BEBA/WP3 – D3.1 Version: 2.0 Page 19 of 37
Figure 2 - Simple in-node processing in BEBA
The packet metadata extracted by the switch’s packet parser (described in later sections) is
used as an input for the processing engine. This metadata is composed of multiple individual
fields of different types and sizes, like source IP address or frame byte length. In each of the
Search/Update/Comparison steps, the in-node processing makes use of a memory pool of
arbitrary data records, also composed from individual fields of different types and sizes.
The role of Search is to select the correct update action for a received packet. The Search
record selection is based only on the values of some packet metadata fields, which are used to
perform a lookup in the memory pool. Arbitrary fields can be selected for searching and
different types of key matching criterion can be specified (like exact match, LPM or wildcard
match). Also, Search can work with multiple sets of different rules grouped into logical tables.
The result of Search is an Update action, which consists of a record address (records
addresses) into memory pool and an update operation (operations) that will be performed on
that record(s). Each operation specifies the update function(s) that will be used to update
BEBA
Behavioural Based Forwarding
Grant Agreement: 644122
BEBA/WP3 – D3.1 Version: 2.0 Page 20 of 37
individual record’s field values. The functionality of Search is provided by the following new
primitive:
UPDATE_ACTION search(TABLE_ID, PACKET_METADATA, params...)
The Update step represents the very core of BEBA in-node processing functionality. First, a
data record, selected by Search, is retrieved from the memory pool. Then, values of all of its
fields are individually updated based on the operation selected also by Search. A new value of
each record field is computed using as operand one or more of the following: the current
record’s value, the value of a selected packet metadata’s field, or a defined constant. The
selected operation specifies an individual update function used for each record field. Values of
different fields from the same record may be updated using different functions. Supported
update functions include basic mathematical and logical operations (like SUB, ADD, OR). The
functionality of Update requires creating the following new primitive:
FLOW_RECORD update(MEMORY_POOL, UPDATE_ACTION, PACKET_METADATA)
An updated record is passed from Update into Comparison, which performs comparison
operations (=, >=, always true, etc.) on the record field (or packet metadata field) values with
other fields or predefined constants. Depending on the result of comparison operation, a record
field value can be further altered (reset to default, advance state, etc.). After that, a final
version of the record is written-back into the memory. Additionally, a message for the BEBA
controller could be created (report event, export record fields, etc.). The functionality of
Comparison requires creating the following new primitive:
MESSAGE comparison(MEMORY_POOL, FLOW_RECORD, PACKET_METADATA)
The definition of these primitives is not definitive at this stage of the project. Indeed, we define
generic primitives in pseudo-code that may be decomposed into multiple primitives once
implementation details will be known more precisely. Refined specifications, resulting from
ongoing interactions among work packages, will be proposed in a future deliverable (D3.2).
3.1.3.2 BEBA in-node processing concept and requirements
BEBA processing concept, as described in previous section, fulfills all of the posed
requirements for statistics and metering collection and simple in-node processing:
REQ-D1: Programmable memory pool – processing operates with memory pool
consisting of data records with arbitrary length and format.
REQ-D3: Support for basic mathematical/logic operations – directly supported in
computation of new data record field values in Update.
REQ-D4: Flow counters – special case of REQ-D3 support in Update, e.g.:
o Record.packet_counter += const1
o Record.bytes_counter += Metadata.frame_length
o etc.
REQ-D10: Support for comparison operations – directly supported in Comparison.
REQ-D16: Read different flow states for different flow keys – state can be viewed as a
special type of data record field so, each record can have its own state. Also, different
search keys can be associated with different records, therefore, with different states.
BEBA
Behavioural Based Forwarding
Grant Agreement: 644122
BEBA/WP3 – D3.1 Version: 2.0 Page 21 of 37
REQ-D17: Flexible state key definition (e.g., range, wildcard) – directly supported in
Search.
REQ-P3: Programmable data collection/export (IPFIX like) – designed concept of simple
BEBA in-node processing as a whole enables for flexible and programmable statistics
collection and export.
3.2 Programmable triggering conditions
3.2.1 Objective
As with previous sections, the objective here is to ensure that we meet the requirement set of
the use cases described in deliverable 5.1. In particular, triggering conditions are contained in
(1) REQ-D6 (timers), needed for instance to check if a tunnel or end-point is alive for UC10,
UC13, UC03), and (2) REQ-D12, defining triggers to update memory content (e.g., RTT
evaluation in UC06).
3.2.2 Existing primitives
The OpenFlow standard comes with little support for the triggering conditions described above.
Regarding timeouts (REQ-D6), it has the ability to define per-flow idle (i.e., it triggers when no
packets for the flow are seen after a while) and hard (i.e., trigger the timeout irrespective of
what the flow’s traffic may be) timeouts, but no explicit way to define other types of timeouts.
Regarding REQ-D12 (triggers to update memory content), OpenFlow provides no support. The
sections below show this in terms of the API.
3.2.2.1 Existing primitives for REQ-D6: Timers
BOOL register_idle_timeout_trigger(TABLE_ID, FLOW_ID, TIMEOUT) BOOL register_hard_timeout_trigger(TABLE_ID, FLOW_ID, TIMEOUT)
These two functions act on a per-flow basis and remove a flow entry when no packets are seen
for a flow after TIMEOUT time (register_idle_timeout) or when TIMEOUT time has elapsed
(register_hard_timeout).
3.2.2.2 Existing primitives for REQ-D12: Triggers to update memory content
Not supported by Openflow.
3.2.3 Extended primitives
In this section we described the extended primitives regarding programmable triggers that the
BEBA API will support.
3.2.3.1 Primitives for REQ-D6: Timers
BOOL register_table_timeout_trigger(TABLE_ID, TIMEOUT, FCTN_PTR)
BOOL register_flow_timeout_trigger(TABLE_ID, FLOW_ID, TIMEOUT, FCTN_PTR)
BOOL register_packet_timeout_trigger(PACKET_DESCR, TIMEOUT, FCTN_PTR)
BEBA
Behavioural Based Forwarding
Grant Agreement: 644122
BEBA/WP3 – D3.1 Version: 2.0 Page 22 of 37
The set of functions above all execute a registered function, given by the function pointer
FCTN_PTR, when triggered. The return value is 0 when the trigger is successfully registered, -1
otherwise. TIMEOUT is specified in milliseconds.
The first of the functions, register_table_timeout, acts as a hard timeout on an entire table and
is useful for running periodic management tasks (e.g., exporting of statistics or clean-up
functions). The second one, register_flow_timeout, triggers when no packets for a flow have
been seen for TIMEOUT milliseconds. The register_packet_timeout triggers when no packets
matching the description have been seen for TIMEOUT milliseconds.
In addition, the API provides the ability to force a timeout to trigger (e.g., if the BEBA
controller needs to do so):
BOOL force_flow_timeout(TIMEOUT_ID)
3.2.3.2 Primitives for REQ-D12: Triggers to update memory content
BOOL register_memory_update_trigger(TABLE_ID, PACKET_DESCR, FCTN_PTR,
params...)
This function executes the given FCTN_PTR function whenever a packet matches
PACKET_DESCR, and passes params as parameters (params can be a number of packet
fields). The return value is 0 when the trigger is successfully registered, -1 otherwise.
3.3 Packet matching facilities
3.3.1 Objective
The objective of this set of extensions is to satisfy the use cases defined in deliverable D5.1. In
particular, the use case UC07: Advanced packet processing makes explicit note about flexible
packet matching facilities. Other use cases, such as UC02: Programmable network flow
measurement and UC12: DDoS detection and mitigation can also benefit from the introduction
of programmable packet parsers, even though such a requirement is not explicitly stated in
their description. The requirement derived in D5.1 to address this functionality in BEBA is REQ-
P6: Programmable packet parsing.
One goal of the BEBA API is to provide means for configuration of BEBA nodes’ packet
matching facilities. Since those facilities extend the capabilities of the current OpenFlow
specifications, also the API must be more complex than the OpenFlow protocol.
3.3.2 Existing primitives
3.3.2.1 OpenFlow
OpenFlow [1] directly supports matching on 41 fields, most of them being packet header
fields. This enforces a switch support for the associated protocols. While that may seem
enough for most applications, such a design is far from future-proof and requires extending the
OpenFlow specification every time a new protocol needs to be added.
Following is an example abstract notation of header parsing routine for a specific protocol:
BEBA
Behavioural Based Forwarding
Grant Agreement: 644122
BEBA/WP3 – D3.1 Version: 2.0 Page 23 of 37
T_PARSER_OUTPUT parse_ipv4 (PACKET, OFFSET)
The function takes two inputs: a field of actual packet bytes, and an offset of the header within
that packet (which is essentially a pointer relative to packet start). The output of any parser
function is a structure containing the extracted fields (one or more of those 41 matching
fields), and the type and offset of the protocol header that follows. By proper calling of
individual parsing functions based on the packet content, the whole packet is parsed and all
supported fields are extracted.
3.3.2.2 OpenFlow Table Type Patterns
TTPs represent acknowledgement of the evolving nature of the OpenFlow specification. The
goal is to allow for an OpenFlow controller and OpenFlow switch to agree on a set of
functionality to help manage the increased diversity made possible with OpenFlow versions
1.1+. TTPs, however, do not provide ways to extend the matching capabilities by a new
protocol.
3.3.3 Extended primitives
The aim of BEBA is not only to extend OpenFlow to support some specific protocols, but to
provide extensibility at runtime, after the BEBA switches have been physically deployed in the
network.
3.3.3.1 P4: a candidate approach for flexible packet matching
The P4 language (Programming Protocol independent Packet Processors) [2][3] proposes an
elegant way to describe an abstract model of a network switch. It provides means to describe:
Header formats,
Packet parsers,
Table specification,
Action specification,
Control program.
The description is meant to be compiled into a device dependent code on the actual switch in a
way that corresponds to the switch’s internal implementation. For example, ASIC-based switch
configures its internal hardware pipeline, FPGA-based switch builds a new firmware that
matches exactly the required protocol structure, software-based switch compiles its own data
path executable to match this configuration. This way, Software Defined Networking can
achieve protocol independence, which it currently lacks.
The P4 language is being developed beyond its original conference paper on the P4 website [4], and the Open Networking Foundation (ONF [5]) is actively seeking a systematic
way of introducing P4 concepts into the OpenFlow specification. BEBA considers P4 as a
candidate approach rather than a definitive choice since P4 has not been standardized yet.
While the overall goal of P4 is rather broad and not well fitting the strongly focused aim of
BEBA, the first two concepts of P4 (generic description of header formats and packet parsers)
are helpful in defining switch support for virtually any new protocol. For example, the Ethernet
header format is described as:
BEBA
Behavioural Based Forwarding
Grant Agreement: 644122
BEBA/WP3 – D3.1 Version: 2.0 Page 24 of 37
header ethernet { fields { dst_addr : 48; src_addr : 48; ethertype : 16; } }
The corresponding part of the packet parser code then may look like this:
parser ethernet { switch(ethertype) { case 0x8100: vlan; case 0x9100: vlan; case 0x0800: ipv4; } }
The BEBA API will, in addition to the current OpenFlow API, take advantage of concepts similar
to those defined by the P4 language to support flexible packet matching facilities. This requires
defining a new primitive that is shared in both data plane and control plane. This primitive
extends the communication scheme between the BEBA controller and BEBA nodes to allow
loading flexible packet parsing instructions into switches:
BOOL load_parser (PARSER_DESCRIPTION)
The function accepts the parser description and generates the BEBA node's platform dependent
code for the parser. Individual protocol header parsing functions are generated specifically to
conform the given description. Their general prototype is as follows:
T_PARSER_OUTPUT parse_header (PACKET, OFFSET, TYPE)
Compared to the existing primitives, this function adds the TYPE parameter which represents
the type of the protocol to be parsed within that function. This way, the parser is more flexible
than the traditional OpenFlow parser. The new primitives may be used in conjunction with the
existing primitives for fixed parsing, or the new primitives may completely replace the old
ones, providing a superset of the original functionality.
To map P4-described packet matching facilities to the description in terms of Events, Actions
and Conditions, we proceed as follows:
Events are values of found packet header fields. For example finding value 0x0800 in the
EtherType field is an event for the Ethernet parser.
Actions are of two types: Type 1 is a call of a subordinate parser. For example the Ethernet
parser calls IPv4 parser. Each call is associated with a pointer to the packet where the next
header starts. Type 2 is the extraction of value from the packet for further processing. The
extracted value is put into packet’s metadata and can be used in the subsequent steps of
packet processing.
BEBA
Behavioural Based Forwarding
Grant Agreement: 644122
BEBA/WP3 – D3.1 Version: 2.0 Page 25 of 37
Conditions are special purpose assertions on the packet header fields. These can be used to
check for valid header checksum, non-zero TTL field etc.
Figure 3 illustrates the placement of the flexible matching facilities of BEBA nodes within the
BEBA ecosystem.
Figure 3 - Flexible matching in BEBA
BEBA
Behavioural Based Forwarding
Grant Agreement: 644122
BEBA/WP3 – D3.1 Version: 2.0 Page 26 of 37
3.4 Packet forwarding and processing actions
3.4.1 Objective
The following primitives deal with data plane actions invoked by the in-switch XFSM
machinery. Some of them have counterparts already specified by OpenFlow as message-
triggered functionalities. Hence, such primitives are listed in the existing subsection, and their
implementation could be possibly wrapped by and/or built on top of OF internals.
3.4.2 Existing primitives
As previously mentioned, this section lists the in-switch data plane primitives referring to
operations specified by OF. As a consequence their actual implementation could be defined in
terms of already existing primitives, by adapting passed arguments and return values and
possibly enriching their functionalities.
3.4.2.1 Primitives for REQ-D5: Modification/insertion of forwarding entries
FLOW_ENTRY action_flow_entry_create(TABLE_ID, params...) BOOL action_flow_entry_modify(TABLE_ID, FLOW_ENTRY, params...)
BOOL action_flow_entry_delete(TABLE_ID, FLOW_ENTRY) This set of actions deals with the operations of creating, modifying and removing a flow entry
in the table specified by the abstract type TABLE_ID. The abstract FLOW_ENTRY type
represents a generic reference to a specific entry in the table; whether this type is a pointer to
a custom data structure or a numeric index is an implementation detail. Instead, the variadic arguments params are derived by the structure of the message defined
in the OpenFlow MSG_FLOW_MOD (see [1], sections 7.3.4.1 and 7.3.4.2).
3.4.2.2 Primitives for REQ-D18: Push/pop of labels
BOOL actions_label_push(PACKET_DESCR, ACTION_PUSH) BOOL actions_label_pop(PACKET_DESCR, ACTION_POP)
The push and pop action primitives allow to add/remove labels to packet headers. They are
listed here as OF supports analogous messages for adding removing specific labels such as VLANs, MPLS, PBB (see [1], section 7.2.6.6).
Push and pop operations are intended to be more general than their message-wise
counterpart. As such, they are specified with the abstract types ACTION_PUSH and
ACTION_POP, respectively, that include the information required to perform the action (e.g.
the kind of label to add and the related parameters).
3.4.3 Extended primitives
This section lists brand new primitives required by BEBA uses cases that have no direct
counterpart as protocol messages in the current OpenFlow specification.
BEBA
Behavioural Based Forwarding
Grant Agreement: 644122
BEBA/WP3 – D3.1 Version: 2.0 Page 27 of 37
3.4.3.1 Primitives for REQ-D2: Access packet metadata
INTEGER action_get_inport(PACKET_DESCR) INTEGER action_get_outport(PACKET_DESCR) INTEGER action_get_table_id(PACKET_DESCR) INTEGER action_get_packet_length(PACKET_DESCR)
These actions return the input port, the output port, the table identifier and the packet length
associated with the packet specified by the abstract type PACKET_DESCR (the real type name
is again implementation dependent). TIMESTAMP action_get_timestamp(PACKET_DESCR)
This action returns the arrival timestamp of the packet referred to by PACKET_DESCR.
TIMESTAMP is an abstract type that represents the absolute time – generally a pair of
uint32_t. For example, the absolute time can be expressed in seconds and microseconds
since a certain epoch (UNIX time refers to January 1st 1970 UTC).
These primitives are also candidate to be refined or re-defined according to the information
shared through packets’ metadata, and according to the needs of the different components in
the whole BEBA ecosystem and their interactions.
3.4.3.2 Primitives for REQ-D11: Update flow state action
BOOL state_mod(MSG_STATE_MOD) BOOL flag_mod(MSG_FLAG_MOD)
BOOL action_set_state(XFSM_ID, ACTION_SET_STATE) BOOL action_set_flag(FLAG_ID, ACTION_SET_FLAG)
This set of primitives triggers the internal state modifications of the XFSM as defined in OpenState 37[6]. The first two functions are triggered by STATE_MOD and FLAG_MOD
messages. Although they belong to the control plane of the BEBA switch (and, as such, should
not appear here), they are shown as they are strictly related to the latter two primitives which,
instead, trigger in-switch internal state modifications actions and operate upon the XFSM and
FLAG specified by their respective IDs.
3.4.3.3 Primitives for REQ-D14: Tunnel end-points management
PORT_NUMBER open_tunnel(TUNNEL_KIND, params...) BOOL close_tunnel(PORT_NUMBER)
In this section the primitives required to manage tunnels are reported. In particular two
actions emerged from the REQ-D14: a primitive required to setup and another to shutdown
tunnels.
The open_tunnel function takes TUNNEL_KIND, a type that enumerates all possible tunnels the
implementation is able to handle, and a set of generic arguments specific of each type of
tunnel.
Table 2 reports, as an example, the minimum set of arguments for two specific tunnels: IPsec
and GTP/LTE.
BEBA
Behavioural Based Forwarding
Grant Agreement: 644122
BEBA/WP3 – D3.1 Version: 2.0 Page 28 of 37
Table 2 - Parameters for tunnel enpoints
Tunnel TYPE Parameters Comments
GTP v1/v2 INTEGER version
IP_ADDR src_endpoint
IP_ADDR dst_endpoint
INT32_T teid
IPsec IP_ADDR left_ip
NET_ADDR left_subnet
String left_id
String
left_rsa_sigkey
String left_next_hop
IP_ADDR right_ip
NET_ADDR right_subnet
String right_id
String
right_rsa_sigkey
String right_next_hop
…
This represents the minimum
set of parameters required to
setup a IPsec tunnel
according to a common
opensource implementation
FreeS/WAN project.
3.4.3.4 Primitives for REQ-D15: Packet generation
The primitives reported herein represent the actions used by XFSM to inject a packet in the
system.
BOOL action_packet_outport(PORT_ID, PACKET) BOOL action_packet_inport(PORT_ID, PACKET)
Two distinct primitives are implemented: one is used to transmit the packet directly to a
certain port; the other is used to inject a packet into the BEBA switch from a given input port.
The PACKET type represents the content of the packet to be injected. For instance, it could be
a data structure that contains the binary representation of the packet itself.
At this stage of the project, it is not yet clear whether the dataplane will have to deal with the
simple action of sending packets, or the more complex action of fulfilling packet templates sent
by the controller with dynamic data (e.g., MAC addresses in ARP replies). In the latter case,
these primitives will be extended to deal with both a reference to a registered packet template
and to data to be used to forge the packet before sending it.
BEBA
Behavioural Based Forwarding
Grant Agreement: 644122
BEBA/WP3 – D3.1 Version: 2.0 Page 29 of 37
3.4.3.5 Primitives for REQ-D7-8: Traffic Control
OpenFlow provides a limited support for QoS management by a simple queuing mechanism (see [1], section 7.3.5.8). However, queue configuration is not included in the protocol
specifications, nor is scheduling management. Therefore, to fulfil the requirements REQ-D7
and D8, new specific in-switch primitives must be designed within the BEBA node.
INTEGER action_get_queue_length(PORT_NUMBER, QUEUE_ID) BOOL action_set_queue_maxlength(PORT_NUMBER, QUEUE_ID, INTEGER length)
INTEGER action_get_queue_maxlength(PORT_NUMBER, QUEUE_ID)
The first primitive specifically refers to REQ-D7 and is used to monitor the actual queue
occupancy, whereas the other two are used to set and read the maximum queue size,
respectively. In compliance with OpenFlow specifications, each queue in the switch is uniquely
identified by the pair (port_number, queue_ID). The first action returns the number of packets
standing in the output queue indexed by queue_id (of generic type QUEUE_ID) of the port
indexed by port_number (of generic type PORT_NUMBER). The second function sets the
maximum queue length of queue indexed by queue_id within port_number port. Its return
value is Boolean to notify possible failure of the action. The third function returns the
maximum queue length.
REQ-D8, instead, requires the BEBA switch to dynamically manage properties (scheduling,
priorities, dropping policies, etc.) of output ports. Once again, as OpenFlow does not natively
support this set of operations, two specific APIs must be designed.
BOOL action_set_port_scheduler_property(SCHEDULER_PROPERTY, PORT_NUMBER) BOOL action_set_queue_property(QUEUE_PROPERTY, PORT_NUMBER, QUEUE_ID)
The first primitive refers to the management of the scheduler for the port indexed by
port_number, i.e. the discipline regulating all queues defined for that port. The generic type
SCHEDULER_PROPERTY includes a scheduler type which enumerates the models supported by
the implementation (WRR, WFQ, WF2Q+, HBT, etc. ) as well as the specific parameters
associated with the scheduler (e.g., weights, priorities).
The second primitive refers more specifically to the management of a single queue and is used
to set specific queuing parameters such as dropping policy (droptail, RED, etc.), dropping
thresholds, etc.
In the actual implementation, and depending on the development platform, the previous
primitives may be built on top of existing functions or tools (e.g., exposed by third party
applications such as Traffic Control for Linux operating system).
BEBA
Behavioural Based Forwarding
Grant Agreement: 644122
BEBA/WP3 – D3.1 Version: 2.0 Page 30 of 37
3.5 Advanced in-node processing
3.5.1 Objective
This set of primitives is needed to handle modules for specific computations (e.g. DPI etc.).
The approach here pursued is to send traffic to specific modules in charge of the above
advanced operation(s).
3.5.2 Existing primitives
The approach of sending traffic to either specific modules or logical ports is exactly the approach supported by OpenFlow (see [1], section 4.4). However, as we aim at proposing a
more general purpose API, we present them in the next section as extended primitives.
3.5.3 Extended primitives
To deal with special end-points, two specific primitives are required, one to set-up and one to
shutdown respectively.
PORT_NUMBER open_processing_endpoint(CHANNEL_ID) BOOL close_processing_endpoint(PORT_NUMBER)
These endpoints are used as special communication channels toward external and/or third
party applications involved for very specific topics.
open_processing_endpoint takes an abstract CHANNEL_ID that identifies a specific
endpoint type and returns the descriptor for the logical port associated (PORT_NUMBER).
Such a descriptor is used to send or receive packets to and from a certain application and it is
also passed to the close_processing_endpoint funciton to shutdown the associated
ports when required.
3.6 Summary of extended primitives
We propose a summary of the primitives identified in the previous sections that will be used in
BEBA nodes to perform advanced dataplane functionalities. We remind existing elements and
list new primitives, classified according to the capabilities they offer.
A first category of primitives concerns the ability for a node to maintain, query and process
statistics and metrics at different levels of granularity (flows, packets, packets’ metadata). To
achieve this goal, existing counters maintained by OpenFlow will be used for basic statistics,
and the following new primitives will allow to setup in-node processing of information:
UPDATE_ACTION search(TABLE_ID, PKT_METADATA, params...)
FLOW_RECORD update(MEM_POOL, UPDATE_ACTION, PKT_METADATA)
MESSAGE comparison(MEM_POOL, FLOW_RECORD, PKT_METADATA)
BEBA
Behavioural Based Forwarding
Grant Agreement: 644122
BEBA/WP3 – D3.1 Version: 2.0 Page 31 of 37
Another category of primitives allows defining new conditions that must be met to trigger some
actions. In particular, BEBA requires more granularity than the existing OpenFlow timers used,
e.g. to remove flow entries from tables when thay are not used anymore. We thus define the
possibility to set timers on tables, flows or packets and call a specific function on timeout, with
the following new primitives:
BOOL register_table_timeout_trigger(TABLE_ID, TIMEOUT, FCTN_PTR)
BOOL register_flow_timeout_trigger(TABLE_ID, FLOW_ID, TIMEOUT, FCTN_PTR)
BOOL register_packet_timeout_trigger(PKT_DESCR, TIMEOUT, FCTN_PTR)
Detecting specific events to trigger actions is also a capability that BEBA aims at offering. In
particular, we aim at matching on specific packets’ header fields or metadata going beyond the existing protocol fields which OpenFlow can match on. That is why we plan to use P4 [2][3] for
modelling packets and defining how to parse them in order to detect specific information they
carry either in their header or in associated metadata. We thus define the following primitives
to load new parsers and perform flexible packet matching:
BOOL load_parser(PARSER_DESCR)
T_PARSER_OUTPUT parse_header(PKT, OFFSET, TYPE)
Finally, BEBA aims at extending the set of actions that can be performed by a switch. Beyond
traditional forwarding actions or manipulations of packets (PUSH/POP label, etc.), BEBA specifies the following new in-switch actions (primitives identified in sections 3.43.5 and 3.5
are considered together in this summary):
- modify itself some entries in its flow tables. For this purpose, it is possible to use the existing primitives (cf. section 3.4.2.1).
- modify some entries related to the state machine. Entries from a state table
implementing the state machine will change over time. WP2 defines more precisely how
the state machine evolves, but we also described in this document some primitives to modify or set states and flags (cf. section 3.4.3.2).
- take benefit of metadata associated to packets to offer more flexibility in actions applied
at the granularity of packets (instead of flows). The following primitives allow to access
packets’ metadata:
INTEGER action_get_inport(PKT_DESCR)
INTEGER action_get_outport(PKT_DESCR) INTEGER action_get_table_id (PKT_DESCR) INTEGER action_get_packet_length (PKT_DESCR) TIMESTAMP action_get_timestamp (PKT_DESCR)
- manage tunnel endpoints (cf. section 3.4.3.3 for more details):
BEBA
Behavioural Based Forwarding
Grant Agreement: 644122
BEBA/WP3 – D3.1 Version: 2.0 Page 32 of 37
PORT_NUMBER open_tunnel (TUNNEL_KIND, params…)
BOOL close_tunnel (PORT_NUMBER)
- generate packets when specified by the state machine or requested by the controller:
BOOL action_packet_outport (PORT_ID, PACKET)
BOOL action_packet_inport (PORT_ID, PACKET)
- control traffic, i.e. manage the length of several queues and the schedulers used to
empty them:
INTEGER action_get_queue_length (PORT_NUMBER, QUEUE_ID)
BOOL action_set_queue_maxlength (PORT_NUMBER, QUEUE_ID, INTEGER length) INTEGER action_get_queue_maxlength (PORT_NUMBER, QUEUE_ID) BOOL action_set_port_scheduler_property (SCHEDULER_PROPERTY, PORT_NUMBER) BOOL action_set_queue_property (QUEUE_PROPERTY, PORT_NUMBER, QUEUE_ID)
- run advanced processing (e.g. DPI, encryption etc.) in the BEBA node. The general
scheme for this will be to manage specific endpoints with the following primitives, and
send traffic towards those endpoints:
PORT_NUMBER open_processing_endpoint (CHANNEL_ID)
BOOL close_processing_endpoint (PORT_NUMBER)
As already mentioned, all these generic primitives will be refined in deliverable D3.2. A more
precise specification will result from ongoing interactions with other Work Packages regarding
both specification and implementation work.
BEBA
Behavioural Based Forwarding
Grant Agreement: 644122
BEBA/WP3 – D3.1 Version: 2.0 Page 33 of 37
4 Example workflow
In this section we take one of the use cases defined in deliverable D5.1 (“Use Cases and
Application Scenarios”) and use it as an example of flow to give an understanding of how the
various parts of the BEBA ecosystem, from the controller down to the various components of
the switch, interact. This draft description also includes the use of some of the API functions
defined in this deliverable. A more detailed workflow will be given in deliverable D3.2.
For the use case, we settled on UC05, titled “Adaptive treatment of unexpected traffic”, since it
is complex enough to require functionality from all components of the BEBA environment. As a
reminder, UC05 consisted of flow or prefix-based anomaly detection based on thresholds, with
suspect flows being subjected to either filtering/dropping or redirection (e.g., to a lawful
interception box). Figure 4, taken from D5.1, illustrates the overall architecture for the use
case.
Figure 4 - Overall architecture for use case UC05
In addition, the use case requires a finite state machine to be installed in the BEBA switch. This
state machine, represented by Figure 5, has two states: a normal one and an anomalous one,
with thresholds and timers triggering transitions between them. Further, the BEBA controller is
notified whenever a transition from the normal to the anomalous state is done.
BEBA
Behavioural Based Forwarding
Grant Agreement: 644122
BEBA/WP3 – D3.1 Version: 2.0 Page 34 of 37
Figure 5 - State machine for UC05
With this background in mind, the BEBA workflow for this particular use case would be as
follows:
At start-up:
1. The BEBA controller installs the Finite State Machine (FSM) shown in Figure 5. The set
of instructions required to define the state machine and install it into the BEBA switch
will be defined by WP2. This includes defining the states and transitions, the flow or
prefix the FSM applies to, the thresholds for anomaly detection (e.g., the number of
TCP SYN per second, throughput, etc.), and the action(s) to take (either drop packets
or redirect them).
2. The switch uses the register_flow_timeout_trigger API call to periodically reset the
statistics (e.g., once a second, if a threshold is set in terms of TCP SYNs per second).
This corresponds to the lower arch coming out of the “Normal” state in the FSM.
On packet arrival:
1. Any counters related to the flow are updated either using standard Openflow
mechanisms (e.g., in the case of supported statistics such as byte and packet counts)
or through the register_memory_update_trigger API call for more advanced
statistics.
2. The switch performs any necessary transitions in the FSM by using the
action_set_state API call. If a transition to the anomalous state takes place, the
BEBA controller is notified (the primitive for sending notifications will be defined by
WP4).
3. If in the anomalous state, either:
a. Drop the packet (if so defined by the FSM),
b. Redirect the packet (if so defined by the FSM, e.g., to a lawful interception box).
BEBA
Behavioural Based Forwarding
Grant Agreement: 644122
BEBA/WP3 – D3.1 Version: 2.0 Page 35 of 37
Finally, at any one point in time the BEBA controller may issue a return to the normal state
and a reset of statistics (see Figure 2) using the action_set_state and the
force_flow_timeout API calls.
BEBA
Behavioural Based Forwarding
Grant Agreement: 644122
BEBA/WP3 – D3.1 Version: 2.0 Page 36 of 37
Conclusion
This document has presented a first analysis of the primitives that should be provided by the
BEBA dataplane. From the requirements identified in deliverable D5.1, we identified which
functionalities are necessary to setup in-node advanced forwarding and processing functions.
Some existing OpenFlow primitives achieve only parts of the requirements. We detail in this
deliverable how existing primitives must be extended and which new primitives must be
developed to be integrated in BEBA nodes.
This deliverable proposes a first version of the BEBA dataplane API description. It will be
revised according to the ongoing work among the project’s work packages (especially WP2,
WP3 and WP4), and a final version will be delivered in December 2015 with deliverable D3.2.
BEBA
Behavioural Based Forwarding
Grant Agreement: 644122
BEBA/WP3 – D3.1 Version: 2.0 Page 37 of 37
References
[1]. Open Networking Foundation, OpenFlow Switch Specification version 1.5.0 (Protocol
version 0x06), ONF TS-020, December 19, 2014
[2]. Pat Bosshart, Dan Daly, Glen Gibb, Martin Izzard, Nick McKeown, Jennifer Rexford,
Cole Schlesinger, Dan Talayco, Amin Vahdat, George Varghese, David Walker ACM
Sigcomm Computer Communications Review (CCR). Volume 44, Issue #3, July 2014
[3]. The P4 Language Consortium. The P4 Language Specification Version 1.0.2. March
2015. http://p4.org/wp-content/uploads/2015/04/p4-latest.pdf
[4]. P4 website, http://p4.org, 2015
[5]. Open Networking Foundation (ONF) website, https://www.opennetworking.org, 2015
[6]. Giuseppe Bianchi, Marco Bonola, Antonio Capone, and Carmelo Cascone. 2014.
OpenState: programming platform-independent stateful openflow applications inside
the switch. SIGCOMM Comput. Commun. Rev. 44, 2 (April 2014), 44-51
[7]. Claise, B., Ed., "Specification of the IP Flow Information Export (IPFIX) Protocol for
the Exchange of IP Traffic Flow Information", RFC 5101, January 2008
http://p4.org/wp-content/uploads/2015/04/p4-latest.pdfhttp://p4.org/https://www.opennetworking.org/