OpenBox

OpenBox: Enabling Innovation in MiddleBox Applications

Structure:

Abstract

1.Introduction

2.Related Work

3.Unified Processing

-3.1.Unifying Processing Stages
-3.2.Enhanced Performance
-3.3.Dependencies and Precedence
-3.4.Room for Innovation

4.OpenBox Architechture

-4.1.Data Plane
-4.2.The OpenBox Protocol
-4.3.Rules
-4.4.Control Plane
-4.5.OpenBox Applications

5.Initial Implementation

6.Conclusions and Future Work

7.References

Abstract and Introduction

Key words:

1.Currently, a special box is tailored to provide each such function. These special boxes are usually proprietary, and operators control over them is limited to the set of capabilities defined by the provider of each box.

Note: introduced why OpenBox appeared.

2.In this paper we present OpenBox: a logically-centralized framework that makes advanced packet processing and monitoring easier, faster, more scalable, flexible, and innovative…

Note: logically-centralized framework; decouples the DP and CP on MiddleBox; unifies MiddleBox Applications by service instances.

3.decouples DP and CP => make life easier :P => “makes it easier to innovate both high-level applications and low-level data plane features”

Note: similarly to SDN.

Table: see table 1

xOMB, Kekely, Gember, Sherry and so on.

Related: P4.

Unified Processing

1.Survey on MiddleBox Applications => Table 2

2.Sample rules in MiddleBox => Table 3

3.1 Unifying Processing Stages

key words:

1.middleboxes use some rule mechanism => see Table 2 as an example => Match & Action

Note: Match and Action.

2.Thus, matches define the behavior of ingress processing stages, while actions define the behavior of egress processing stages. => pipeline processing;

Note: pipeline

3.merge multiple rulesets to define the logic of a single logical middlebox application that fulfills the union of all.

Note: OpenBox => merge rulesets => performance++

3.2 Enhanced Performance

Note: merge stages => a potential performance gain exists.

3.3 Dependencies and Precedence

Key words:

1.The order in which a packet should go through multiple services or middlebox is usually called a policy chain or a service chain.

Note: a policy chain => processing in order

2.However, this may produce incorrect results in the cases when the result of one application (such as NAT) should be the input of a second application (such as a firewall).

Note: OpenBox => produce incorrect? “output as input” => multiple processing => solve the problem => that’s “dependencies”

3.4 Room for Innovation

Note: A lot of types of MiddleBox need to do.

Table: see Table 4

4.OpenBox Architechture

4.1 Data Plane

Key Words:

1.OpenBox service instances (OBIs): low-level processing entities => one or more stages of the unified processing

Note: what is OBI? ans: processing entities.

2.Each such OBI receives a processing graph (PG) and a set of processing rules from the OpenBox controller.

Note: PG(define the processing logic) + rules from Controller ==input==> OBI

4.1.1 Hardware or Software Implementation

Note: general-purpose CPU or virtual machine; specialized hardware; programmable

4.1.2 Multiple OBIs

Key words:
1.Each OBI may implement all or part of the required processing steps; metadata(network service header).

Note: pkt => OBI1 => pkt+metadata1 => OBI2 => pkt+metadata1+metadata2 => …

2.also to load-balance network resources such as links and servers.

Note: load balance

4.2 OpenBox Protocol

Note: the communication protocol between OBIs and the control plane; Messages => JSON

4.3 Rules

Note: rule = header match structure(specifies values) + payload match structure(patterns to be searched) + instructions set(actions) + priority + cookies = match + action

4.4 Controller Plane

Key words:

1.The OpenBox controller (OBC): logically centralized software server;

2.Using the Box abstraction layer it exposes, OpenBox applications can be written on top of it to define the desired traffic monitoring and classification tasks in the network.

OpenBox Applications: APP1 + APP2 + ...
    |
(Box Abstraction Layer, BAL)
    |
Control Plane: OBC1 + OBC2 + ... + OBCN
    |
(OpenBox Protocol)
    |
Data Plane: OBI1 + OBI2 + ... + OBIN

Note:
(1) OBA = specifies a processing path + rules;
(2) BAL = a set of classes and interfaces
(3) OBC = Target Specific OpenFlow Controller

OBC -> PG -> OBI; OBI -> status -> OBC

4.5 OpenBox Applications

Note:

(1) Each processing step produces metadata that may be used by later steps.

(2) Box applications are mostly proactive => preserve high performance = request to DP frequently.

(3) session analyzer => State Management

(4) Content Storage

5. Initial Implementation

Note:

OpenBox Framework => https://github.com/ DeepnessLab/moonlight

OBI => https://github.com/DeepnessLab/obsi

6. Conclusion and Future Work

Note:

1.provide more flexible and scalable development and deployment of applications with the same roles, and allow innovative solutions to be easily created.

2.allow all vendor element.

Chen, 2017.3.26