| <html> |
| <head> |
| <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> |
| |
| <!-- |
| Include the title here. We will parse it out of here and include it on the |
| rendered webpage. Do not duplicate the title within the text of your page. |
| --> |
| |
| <title>Krikkit</title> |
| <style> |
| dt { |
| display: list-item; |
| list-style-position: outside; |
| list-style-image: |
| url(/eclipse.org-common/themes/Phoenix/images/arrow.gif); |
| margin-left: 16px; |
| } |
| |
| dd { |
| margin-left: 25px; |
| margin-bottom: 5px; |
| } |
| </style> |
| </head> |
| |
| <!-- |
| We make use of the 'classic' HTML Definition List (dl) tag to specify |
| committers. I know... you haven't seen this tag in a long while... |
| --> |
| |
| |
| |
| <body> |
| <p> |
| The Krikkit project is a proposed open source project under the <a |
| href="http://www.eclipse.org/projects/project_summary.php?projectid=technology">Technology |
| Top-level Project</a>. |
| </p> |
| |
| <!-- |
| The communication channel must be specified. Typically, this is the |
| "Proposals" forum. In general, you don't need to change this. |
| --> |
| <p> |
| This proposal is in the Project Proposal Phase (as defined in the |
| Eclipse Development Process) and is written to declare its intent and |
| scope. We solicit additional participation and input from the Eclipse |
| community. Please send all feedback to the <a |
| href="http://www.eclipse.org/forums/eclipse.proposals">Eclipse |
| Proposals</a> Forum. |
| </p> |
| |
| <h2>Background</h2> |
| |
| <!-- |
| Optionally provide the background that has lead you to creating this project. |
| --> |
| <p>The next step in the evolution of the Internet is what is being |
| termed as The Internet of Things or IoT (also referred to as Internet |
| of Everything in some contexts). It is expected that the next phase |
| will see a paradigm shift in the way we communicate with a host of low |
| powered devices such as sensors. As billions of sensor devices and |
| nodes are attached to the network, they will generate vast amounts of |
| data that will need to be processed. The amount of data generated will |
| dwarf the already huge amount of Internet traffic generates today. The |
| amount of processing that is required to sift through this raw data to |
| glean useful information and knowledge will be huge and it will be a |
| challenge to do it efficiently with current approaches. The current |
| approach of "store first, analyze later" where all the data is |
| processed in the cloud/backend at a later time may not be feasible not |
| only due to the large amounts of data but also the need to take |
| actions in real time based on the streaming data i.e. on data that is |
| in motion and not static.</p> |
| <p>To address these forthcoming challenges, we need to rethink the |
| way we acquire and manage data. Instead of capturing all the data to |
| be processed at the edge, we need a way to instruct the low powered, |
| memory and resource constrained edge devices such as sensors and |
| sensor gateways as to what data is of interest and what aspects of it |
| to capture. From a user point of view, not all data is of interest and |
| the ability to set rules/policies on the edge devices along with |
| capabilities to search the data in real time and trigger subsequent |
| actions will engender powerful advantages. The key benefit would be |
| dramatic bandwidth reduction as we reduce the amount of data being |
| sent back by eliminating data that is not needed. Secondly, devices at |
| the edge may have the ability to understand the data and the ability |
| to query the devices for semantic information available in sensor data |
| will be valuable.</p> |
| <p>To realize this vision of acquiring and managing data in motion |
| in real time, we need a mechanism to communicate with the edge devices |
| and a common language for doing so. This communication must provide |
| the ability to set rules to describe data of interest, ability to |
| understand and search the data including content and payload and the |
| ability to trigger actions (e.g. actuate sensors) in response to |
| events conditioned on rules. This proposal attempts to address the |
| need for such a communication paradigm by providing an |
| publish/subscribe architecture and API. This API will enable users to |
| program the edge devices to acquire, search and deliver only data of |
| interest while minimizing the bandwidth requirements. This will allow |
| the scalability needed to manage a large number of devices in the IoT |
| space.</p> |
| <h2>Scope</h2> |
| <p>The Krikkit Eclipse project provides an API through a software |
| library that will enable a user or developer to 'program' IoT edge devices |
| such as sensor gateways and make it easy to acquire and manage data. Such a |
| library could also potentially be used as a plug-in in Eclipse |
| frameworks to ease the programming of IoT devices.</p> |
| |
| <p>Specifically, Krikkit library provides a REST ful API for a |
| programmer to specify and describe the data of interest. The edge |
| devices may also have the ability to understand the semantics of the |
| content/payload of the sensor data. The API, in this case can also be |
| used to write queries describing the content which if matched against |
| can result in further actions.</p> |
| <p>The API translates these policies into an open format that can |
| be understood by the edge devices. Krikkit also includes in its scope |
| the format and definition for the JSON messages that will be used to |
| communicate with the devices.</p> |
| <p>Different edge devices may have different internal |
| representations and different capabilities. For example, not all edge |
| devices may be able to understand and search the payload. The scope of |
| the proposal is only to describe what data is to be acquired, not the |
| specification on how the capabilities of the device are to be |
| implemented or even what the capabilities should be. The proposal also |
| does not specify how the rules are to be represented internally on the |
| edge devices.</p> |
| |
| <!-- |
| All projects must have a well-defined scope. Describe, concisely, what |
| is in-scope and (optionally) what is out-of-scope. An Eclipse project |
| cannot have an open-ended scope. |
| --> |
| |
| |
| <h2>Description</h2> |
| |
| <!-- |
| Describe the project here. Be concise, but provide enough information that |
| somebody who doesn't already know very much about your project idea or domain |
| has at least a fighting chance of understanding its purpose. |
| --> |
| <p>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.</p> |
| |
| <p>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.</p> |
| <h2>Why Eclipse?</h2> |
| <p>There are currently several machine-to-machine and IoT related |
| projects under the Eclipse Foundation umbrella. Since this a related |
| area of work, we would like to leverage the expertise and community |
| around these projects. Moreover, we see some areas where we can |
| co-ordinate with existing projects such as the Ponte project which |
| already aims to build a flexible M2M RESTful communication framework.</p> |
| |
| <p>Beyond this, we would like to contribute to the programmability |
| of IoT devices by releasing open source software. This open source |
| implementation of the API will accelerate the deployment of IoT |
| devices.</p> |
| |
| <p>The Eclipse Foundation can help is in achieving the goals above |
| and we see it as a perfect vehicle to take our vision of IoT forward.</p> |
| |
| <!-- Answer these two questions: What value does this project bring to |
| the Eclipse community? What value do you expect to obtain from hosting your |
| project at Eclipse? |
| |
| What value do you get by having your project at Eclipse over and above |
| the value of hosting at Eclipse Labs? --> |
| |
| <h2>Initial Contribution</h2> |
| <p>Our existing code implements our vision of the API described |
| above. The code is still being extended to support additional features |
| and community feedback is expressly desired.</p> |
| <p>Code copyright is held by Cisco Systems. There are no libraries |
| beyond normal C libraries. The project will use the Eclipse Public |
| License.</p> |
| <p>The code contains 2 components:</p> |
| <p>1: The main component is a C library that provides an API (the |
| Krikkit API ) that allows a user to specify the policy expressing how |
| to acquire the data and what to do with it. The library runs in the |
| user's programming environment and converts the API inputs into a JSON |
| payload, encapsulates it in a REST message and registers it at the |
| edge device. To make it easier to use the Krikkit library, a plug-in |
| for Eclipse frameworks may be provided.</p> |
| <p>2: The second component is the software running on the edge |
| device that parses the JSON payload of incoming policies and |
| translates them into a format understood by the edge device. Since |
| different edge devices may have different internal formats that |
| describe different capabilities, we will provide a simple reference |
| example. The translation of the JSON payload into internal device |
| representation and the way it is used is beyond the scope of this |
| proposal. What will be provided is only an example of how this can be |
| done.</p> |
| |
| <!-- |
| Projects are expected to arrive at Eclipse with existing code. |
| |
| Describe the existing code that will be contributed to the project. Please provide |
| a couple of paragraphs describing the code with modest detail, including important |
| information like code ownership (who holds the copyright?), and some consideration |
| of community that exists around the code. Include a listing of third-party libraries |
| and associated licenses. |
| --> |
| |
| <h2>Legal Issues</h2> |
| |
| <!-- |
| Please describe any potential legal issues in this section. Does somebody else |
| own the trademark to the project name? Is there some issue that prevents you |
| from licensing the project under the Eclipse Public License? Are parts of the |
| code available under some other license? Are there any LGPL/GPL bits that you |
| absolutely require? |
| --> |
| <p>As far as we know, there are no legal issues associated with |
| this project. There are no trademark issues relating to the project |
| name. All the code was written for this project with the intention to release |
| it inder the Eclipe Public License. The API currently supports the |
| ability to use SSL for communication for which the OpenSSL package is |
| being used.</p> |
| |
| <h2>Committers</h2> |
| |
| <!-- |
| List any initial committers that should be provisioned along with the |
| new project. Include affiliation, but do not include email addresses at |
| this point. |
| --> |
| |
| <p>The following individuals are proposed as initial committers to |
| the project:</p> |
| |
| <dl> |
| <dt>Vijay Subramanian, Cisco Systems</dt> |
| <dt>Raghuram Sudhaakar, Cisco Systems</dt> |
| </dl> |
| |
| <p>We welcome additional committers and contributions.</p> |
| |
| <!-- |
| Describe any initial contributions of code that will be brought to the |
| project. If there is no existing code, just remove this section. |
| --> |
| |
| <h2>Mentors</h2> |
| |
| <!-- |
| New Eclipse projects require a minimum of two mentors from the Architecture |
| Council. You need to identify two mentors before the project is created. The |
| proposal can be posted before this section is filled in (it's a little easier |
| to find a mentor when the proposal itself is public). |
| --> |
| |
| <p>The following Architecture Council members will mentor this |
| project:</p> |
| |
| <ul> |
| <li>Naci Dai</li> |
| <li>Denis Roy</li> |
| </ul> |
| |
| <h2>Interested Parties</h2> |
| |
| <!-- |
| Provide a list of individuals, organisations, companies, and other Eclipse |
| projects that are interested in this project. This list will provide some |
| insight into who your project's community will ultimately include. Where |
| possible, include affiliations. Do not include email addresses. |
| --> |
| |
| <p>The following individuals, organisations, companies and projects |
| have expressed interest in this project:</p> |
| |
| <ul> |
| <li>Wes Johnson, Eurotech</li> |
| <li><a href="http://www.davranetworks.com">Davra Networks</a></li> |
| </ul> |
| |
| <h2>Project Scheduling</h2> |
| |
| <!-- |
| Describe, in rough terms, what the basic scheduling of the project will |
| be. You might, for example, include an indication of when an initial contribution |
| should be expected, when your first build will be ready, etc. Exact |
| dates are not required. |
| --> |
| |
| <h2>Changes to this Document</h2> |
| |
| <!-- |
| List any changes that have occurred in the document here. |
| You only need to document changes that have occurred after the document |
| has been posted live for the community to view and comment. |
| --> |
| |
| <table> |
| <tbody> |
| <tr> |
| <th>Date</th> |
| <th>Change</th> |
| </tr> |
| <tr> |
| <td>11-October-2013</td> |
| <td>Document created</td> |
| </tr> |
| </tbody> |
| </table> |
| |
| |
| </body> |
| </html> |