<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>