Skip to content

PHS

Jump to bottom
Baby Bender edited this page Jun 29, 2017 · 9 revisions

Packet Handling Service (PHS)

Table of Contents

  1. Introduction
  2. Convention/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
  • Bidirectional communication interface from MS to PHS will be through AMQP
  • Default PHS plugin will be ‘Packet Injection’

Abbreviations

TBD

Summary

PHS is a broker service that interacts with 3rd party components such as HTTP webserver, caching server, storage and other services through service plugin. PHS will be launched as a standalone process that pulls packets using RXTXAL API with load balancing and clustering supported on both input and output lines through RXTXAL library. Input and output line should also support multiple communication channels. In order to achieve high level throughput performance, multiple IPPS can be launched together as standalone processes. The packet flow will be in the following order:

  • Packet comes in and passed to RXTXAL on the input line where RXTXAL performs load balancing on communication channel(s)
  • Packet being filtered by plugin at user space with “null” as the default plugin
  • Packet comes out and passed to RXTXAL on the output line where RXTXAL performs load balancing if need be on communication channel(s)

Based on application goal, PHS plugin can be in "passive" or "active" mode. In "passive" mode, the traffic will be forwarded to destination without anything being done to it. for example, packets being forwarded to storage cluster. In "active" mode, packets payload is being modified and forwarded to webserver. This service can be chained together with IPPS, PPP or new component.

Components 

       Figure 1 (component stack)
  1. Background configuration/registration thread
  2. RXTXAL input configuration and load balancing
  3. User level vendor specific service plugin
  4. RXTXAL output configuration and load balancing
  5. Logging

Component descriptions:

1. Background configuration/registration thread

Background thread is responsible for configuring and registering PHS component, which uses AMQP 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
  • Configure plugin (default: 'null' plugin)
  • Idle once configuration and registration have been successfully applied

Configuration can only be done once PHS component has been successfully registered.

state machine:

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

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

PHS -> MS registration:

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

MS -> PHS registration:

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

MS -> PHS configuration:

  • RXTXAL
  • User level vendor specific service plugin
  • logging

PHS -> MS configuration:

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

2. RXTXAL input configuration and load balancing

Performs configurations for input channels and load balancing for all the input channels using RXTXAL library. Packets received will be forwarded to user space component for user level Layer 4 protocol plugin processing.

example:

{
  "version": "1.0.0",
...
  "io_drivers": {
      "dpi_input": {
        "direction": "rx",
        "core_bind_id":1,
        "watermark": 100,
        "poll_wait_msec":10,
        "ring_cluster_id":55,
        "intf_names": ["enp0s4"],
        "qinq_vlan_pop": {
          "tpid": "0x8100",
          "pcp": 4,
          "dei": 0,
          "vid": 254
        }
      },
...
  },
...
}

3. Packet Handling Plugin

The packet handling plugin acts as a broker to 3rd party vendor specific services. The plugin will need to be implemented to meet the specifications of target endpoint service and the responsibility of PHS to send the processed message to the final endpoint node. The endpoint can be caching server, storage backend, etc.

example1:

{
  "version": "1.0.0",
...
  "plugins":
  {
    "type": "http_inj",
    "services": [{
        "name": "hbo_driver",
        "src_ipaddr_repl": "",
        "dst_ipaddr_repl": "",
        "src_port_repl": 80,
        "dst_port_repl": 765,
        "regex_payload_repl": {
          "url": [],
          "header": [],
          "body": []
       }
    }]
  }
}

example2:

{
  "version": "1.0.0",
...
  "plugins":
  {
    "type": "object_store",
    "services": [
      {
        "name": "ceph_driver"
      }
    ]
  }
}

4. RXTXAL output configuration and load balancing

Performs configurations for output channels and load balancing for all the output channels using RXTXAL library. Plugin can forward packets to new component or 3rd party service.

example:

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

5. Logging

C++ open source spdlog library

Example configuration:

  • location: /tmp/phs
  • size: 10 MB
  • max log rotate: 5
  • log level: debug
{
  "version": "1.0.0",
  "log": {
    "dir_location": "/tmp/phs",
    "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]

Clone this wiki locally