Skip to content

IPPS

Jump to bottom
Baby Bender edited this page Apr 4, 2018 · 29 revisions

Interface Packet Processing Service (IPPS)

Table of Contents

  1. Introduction
  2. Conventions/Requirements
  3. Abbreviations
  4. Summary
  5. Components
  6. Component descriptions

Introduction

This documentation intended to serve the purpose of giving detail level architecture description.

Conventions/Requirements

  • Performance bound
  • IPPS operation will involve partial kernel and user space
  • Bidirectional communication interface from MS to IPPS will be through AMQP
  • Unidirectional communication interface from IPPS to PPP or another new components will be through RXTXAL

Abbreviations

TBD

Summary

IPPS will be launched as a standalone process that pulls packets using RXTXAL DPI API. Packet filtering on the ingress is being done on the L2-L3 layer by specifying libpcap filtering syntax (ex: berkeley packet filter) using RXTXAL DPI library per flow based on 4 tuples (src/dst MAC address, src/dst IP address). Load balancing and clustering will be supported on both the ingress and egress line of the logical interface through RXTXAL DPI library. Input and output line can support multiple logical interfaces. Any interesting packets will be passed from one pipeline to the next from IPPS to PPP or PHS if packet payload parsing is needed (L4 and above). Since load balancing and clustering is being done through RXTXAL DPI library using some type of unique id, multiple IPPS processes are recommended for performance gain. The packet flow will be in the following order:

  1. Packet comes in and passed to RXTXAL on the input line where RXTXAL performs filtering and load balancing on logical interface(s)
  2. Packet being processed and additional operations such as IP address blacklisting can be done at the user level
  3. Packet comes out and passed to RXTXAL on the output line where RXTXAL performs load balancing if need be on logical interface(s)

Note: current implementation will support only two threads per process, background and packet processing threads.

Components 

                              Figure 1 (component stack)
  1. Background configuration/registration thread
  2. RXTXAL input configuration, filtering and load balancing
  3. User level packet processing
  4. RXTXAL output configuration and load balancing
  5. Logging

Component descriptions:

1. Background configuration/registration thread

Background thread that is responsible for configuring and registering IPPS daemon, which uses AMQP/kafka as communication channel to the MS. Responsibilities:

  • The only thread that is up and running when the daemon first started
  • RXTXAL input and output channels configuration
  • Configures L2/L3 Filters
  • Configures any user space filters
  • Idle once configuration and registration have been successfully applied

state machine:

		  |----------------|			     |-----------|
                down -> up -> registering -> registered -> loading -> loaded 
 		   |	|	|		  |		|	|
                    ------------------------------|----------------------		
						error

Below is the bi-directional communication between MS and IPPS:

IPPS -> MS registration:

  • PPP uuid
  • status (state-machine): registering, registered, error

MS -> IPPS registration:

  • status (state-machine): registering, registered, error

MS -> IPPS configuration:

  • RXTXAL
  • user space filters
  • logging

IPPS -> MS configuration:

  • status (state-machine): loading, loaded, error

2. RXTXAL input configuration, filtering and load balancing

Performs kernel level configurations such pcap filtering, load balancing, stream flows, logical interface, etc. Packet L2-L3 processing and filtering functionality (context) will exist within each load balancer. The filters will decide whether packets will be:

  • dropped
  • moved to next processing component

Packets received will be forwarded to user space component for user level packet processing.

example:

{
  "version": "1.0.1",
...
  "io_drivers": {
      "dpi_input": {
        "direction": "rx",
        "core_bind_id":1,
        "watermark": 100,
        "poll_wait_msec":10,
        "ring_cluster_id":55,
        "intf_names": ["enp0s3"]
      },
...
  },
...
}

Note: It is possible to perform L4 filtering but for the sake of modularity and performance, it is highly recommended that L4 or above and payload processing operations being done on the next component, which can be utilized to bypass L2-L3 parsing and focus more on payload processing.

3. User level packet processing

User level packet processing is easy to implement filtering without having to dig into DPI library and also can support any features that might not be supported by RXTXAL library. Any packets received will be forwarded to RXTXAL output component for load balancing.

example: blacklisting IP address can be done at this layer before packets are being forwarded to next component. Other user level functionality can be added here such as packet statistics.

{
  "version": "1.0.1",
...
  "filters": {
    "l3_blacklists": [
      "192.168.56.2",
      "192.168.56.3"
    ]
  }
}

4. RXTXAL output configuration and load balancing

Performs kernel level configurations such load balancing, logical interface, etc. Packets received will be forwarded to next component, which can be PHS, PPP or other component.

example:

{
  "version": "1.0.1",
  ...
  "io_drivers": {
...
      "dpi_output": {
        "direction": "tx",
        "core_bind_id":2,
        "watermark": 1000,
        "poll_wait_msec":100,
        "ring_cluster_id":80,
        "intf_names": ["enp0s3"]
      }
  },
...
}

above explanation can be summarized with figure 3 diagram example.

5. Logging

C++ open source spdlog library

Example configuration:

  • location: /tmp/ipps
  • size: 10 MB
  • max log rotate: 5
  • log level: debug
{
  "version": "1.0.1",
  "log": {
    "dir_location": "/tmp/ipps",
    "size_mb": 10,
    "num": 5,
    "level": "debug"
  },
  ...
}

example format: [date] [location] [debug level]

[2017-02-10 01:15:06.916] [/tmp/ipps/ppthd_0] [info]

Code Location:

https://github.com/tomsumardi/madeline/tree/master/components/ipps/src/ipps https://github.com/tomsumardi/madeline/tree/master/components/ipps/src/main

Clone this wiki locally