beba behavioural based forwarding deliverable report d3.1 ... data plane... · beba behavioural...

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




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




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.3 PACKET MATCHING FACILITIES ................................................................................. 22

3.3.1 Objective ................................................................................................. 22 3.3.2 Existing primitives ..................................................................................... 22

BEBA




3.3.3 Extended primitives ................................................................................... 23 3.4 PACKET FORWARDING AND PROCESSING ACTIONS .......................................................... 26


3.5 ADVANCED IN-NODE PROCESSING ............................................................................. 30


3.6 SUMMARY OF EXTENDED PRIMITIVES .......................................................................... 30

4 EXAMPLE WORKFLOW ........................................................................................ 33

CONCLUSION ............................................................................................................ 36

REFERENCES ............................................................................................................. 37

BEBA




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




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




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




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




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




- 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




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




Table 1 - Use case and application scenarios

BEBA




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




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.


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).


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




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




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




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




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




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




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




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).


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.


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




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.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




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.


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




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




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




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.


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).


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




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




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




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




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).


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.


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




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




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




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




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




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




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




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/

beba behavioural based forwarding deliverable report d3.1 ... data plane... · beba behavioural...

Documents