Eclipse Krikkit

The Krikkit architecture is a publish/subscribe mechanism where rules/policies are registered on edge routers/gateways that have visibility into and communicate with sensors. The rules can be used to describe what data should be acquired. For example, we can acquire data based on network parameters such as protocol, IP address or port. We can also specify that content payload that matches certain criteria should be processed. For example, we could write a rule that says we wish to acquire data from sensors where the temperature is within a certain range. The Krikkit library provides the API and runs in the user's programming environment and can be linked against. In essence, a user writes a C program that specifies what data he is interested in. The API helps the user translate this program into a standard and open JSON format encapsulated as a REST message that can be understood by any edge device that supports the Krikkit API. A key part of the project is to work towards community consensus (de facto standardization) regarding the format of the JSON format used to express a policy. This policy is then sent by the API to the edge device of interest using a RESTful communication paradigm. This is the publish part of the architecture.

An edge device supporting the Krikkit API will listen to the REST messages containing the JSON payloads that express the rules and will register them. A component of Krikkit runs on the edge devices and translates the rules from JSON format to the internal format of the device. The device will be responsible for translating the JSON messages into internal representations that it can understand since these representations are specific to each device. Traffic that flows through the device will be searched against the rules. The devices may have the ability to index and search the payload and content in the sensor data and also to execute queries on the payload. In this manner, the data at the edge of the network can be searched in real-time using the API to discover nuggets of information from the mountain of raw data. The rules may also specify what should be done with the matching traffic. Results of successful hits could be sent (again in a RESTful manner) to an endpoint which will be listening for responses from the edge device. This is the subscribe part of the architecture.