Simple One Dimensional Routing in TinyOS 2.x /2.10

Program listing: Routing in one dimension
OS: TinyOS 2.10/ TinyOS 2.x
Tools used : none
Assumptions: You are able to understand BlinkToRadio example from Tinyos tutorials.
Concept used: TX_POWER is set when sending a data to do multiple node transmission in a small room testbed. ( If you want to use it, you need to include the following in the AppC
components CC2420PacketC;
App.CC2420Packet->CC2420PacketC;
)

When a packet is received, it check for the target. If target is not current node, it compares its own id with target. Nexthop id is chosen accordingly.

Running the program:
1)Modify the BlinkToRadio application in receiving packets and include the routing decision.
2) Write a test program. Fuse it to say nodeid 10. Try to send data to 14 and 3. For 14 it should hop right. For 3 it should hop left.


void sendMessage(uint8_t data, uint16_t nodeid)
{

if (!busy) {
BlinkToRadioMsg* btrpkt =
(BlinkToRadioMsg*)(call Packet.getPayload(&pkt, sizeof(BlinkToRadioMsg)));
if (btrpkt == NULL)
{
return;
}
btrpkt->nodeid = nodeid;
btrpkt->counter = data;
call CC2420Packet.setPower(&pkt,MY_TX_POWER);
//routing decision
if(nodeid
{
//send left
if (call AMSend.send(TOS_NODE_ID-1,
&pkt, sizeof(BlinkToRadioMsg)) == SUCCESS)
{
busy = TRUE;
}
}
else

{
//send right
if (call AMSend.send(TOS_NODE_ID+1,
&pkt, sizeof(BlinkToRadioMsg)) == SUCCESS)
{
busy = TRUE;
}
}
}
}


// The Header file is modified to get desired output
//Transmission power is set to two. This will help to run the program in actual mote with multiple hops in a small room.

#ifndef BLINKTORADIO_H
#define BLINKTORADIO_H

enum {
AM_BLINKTORADIO = 6,
TIMER_PERIOD_MILLI = 250,
MY_TX_POWER=1
};

typedef nx_struct BlinkToRadioMsg {
nx_uint16_t nodeid;
nx_uint16_t counter;
} BlinkToRadioMsg;

#endif

If you could implement this, try to do it for 2 dimension.

Hands on experiments with micaz, MTS310 and MIB520

This post is after the first set of trials with micaz mote. Till now worked only with telosb, which has usb interface and programming in single board including sensors on board.
This experiment is not conducted in avrora or any emulator.

Mote used- Micaz- CC2420 Radio (Zig-Bee compliant) : The range was much better than Telosb. It gave 21metres compared to 8 metres in telosb.
Following image shows Micaz mounted with MTS310 sensor board

Sensor Board- MTS310 ( light, temp, acoustic,acoustic actuator, seismic, magnetometer sensors)

Programming board- MIB520CB USB/JTAG

The first program came to my mind was to make buzzer on. After searching for the platform files, in mts300 board folder (/opt/tinyos-2.1.0/tos/sensorboards) I found Sounder file.
The application I wrote has 2 files BuzzerC and BuzzerP
BuzzerC
configuration BuzzerC {
}
implementation {
components MainC, BuzzerP, LedsC,SounderC ,new TimerMilliC() as MyTimer;;

MainC.Boot <- BuzzerP;
BuzzerP.Mts300Sounder -> SounderC;
BuzzerP.Leds -> LedsC;
BuzzerP.Beep -> MyTimer;
}

BuzzerP
module BuzzerP
{
uses
{
interface Boot;
interface Mts300Sounder;
interface Timer as Beep;
interface Leds;
}
}
implementation
{
uint8_t count=0;
event void Boot.booted()
{
call Beep.startPeriodic(500);

}
event void Beep.fired()
{

count++;

if((count==2))
{
call Leds.led0Toggle();
call Leds.led1Toggle();
call Leds.led2Toggle();
count=0;
call Mts300Sounder.beep(10);
}
}
}

The code is self explanatory....

Following was the error came while compiling
"Programmer is not responding"
This is because MIB520 has 2 usb ports. One used for programming and other for data.
The "motelist" command will not list any mote connected to MIB520. Instead you have to go to system log and check for the two usb ports activated after pluging in the board. Assuming that first one is usb0 and second one is usb1, the syntax for uploading a new program is "make micaz reinstall.2 mib510,/dev/ttyUSB0" where 2 is the node id

Now you can test the "Antitheft" application which worked fine after giving /dev/ttyUSB1:micaz for serialforwarder

Tracking Using RSSI: application in tinyos2.10+ubuntu+java

This small project was done as part of our OpenHouse event during Tech Fest Shaastra2008 atIIT Madras. It's the first application of its kind I have written.
Please read my previous posts to understand basics, if you are not familiar with basic terms

Project : Target tracking using RSSI with TelosB
Types of nodes: Mobile node, Static nodes and base station
Tools: Java serialforwarder and customized extension of listen class
Routing protocol used: Collection
Tracking scenario: 1 Dimensional

The details
Mobile node will send a blank packet with specific interval while moving. The static nodes will catch that signal and measure the RSSI value. It will be transmitted to BaseStation. Base station is the multihoposcilloscope base. The value received by base station node can be read using java serialforwarder and Listen class.
However the Listen class gives only raw information. So the program is modified and customized to get values. RSSI values are scaled to a positive value. Value we have got are between 0 and 89 using telosb motes.
The GUI is having 10 grids with 6 static nodes, but can scale to any number of nodes.

Code can be downloaded from here

Using SerialForwarder Interface of TinyOS with Avrora

Dear reader,
Special thanks for the feedback and comments. Please continue supporting this small effort of mine to tinyos community.
As I promised in last post, here is the first step to analyze the RSSI values from a mote. In order to understand concept of base station and how things are done in real world, the following tutorial may help you.
As usual, sample code is provided at the end

Assumptions:
1) You have done up to the previous post, radio communication using cthreads. If not, please have a look at it. We are using the same program here for further analysis with a base station.
2) The username is "test"
3) You have eclipse installed and running.
4) You know how to add CLASSPATH for custom jar library

Before we begin, a small note on base station. Base station in real time can be a sophisticated node with high transmission range or a normal mote connected to computer. In either way, it act as a sink for data collection. That means, every application you develop using WSN needs to run the base station.

With this, here we begin.
Part 1: Making program ready for SerialForwarder
  1. Copy the folder BaseStation from /opt/tinyos-2.1.0/apps to /home/test/Serial
  2. Take shell and navigate to ~/Serial
  3. Compile the program. "make mica2"
  4. Convert the main program to avrora compatible format convert-avrora build/mica2/main.exe base.od
  5. Move the base.od to parent folder. mv base.od ../
  6. Copy the sender.od from previous example to Serial folder
  7. Instead of our previous post step, command for avrora is different here. " avrora -simulation=sensor-network -seconds=160.0 -monitors=serial,real-time -platform=mica2 -nodecount=1,1 base.od sender.od"
  8. This will give a display "Waiting for serial connection on port 2390..."
If everything is fine, the O/P will be similar to the following


Part 2: Opening a new project in Eclipse and adding TinyOS library
  1. Open a new java project in Eclipse
  2. Copy the following code

Running Program
  1. Add java library path for suport for TinyOS serialforwarder
  2. Compile.
  3. Run the serialforwarder
  4. Modify the entry in serialforwarder to "network@localhost:2390"
  5. Start Server
  6. Now the counter will be running for "packets received"
  7. With out closing the serialforwarder, go back to eclipse and run the Listen
  8. Observe the output.

For those who are done with this.
Please have a look at Octopus project
If you are able to run the code from Octopus in avrora, it's a good sign!!!
Cheers

Download java code
Links you may be interested in
  1. Radio Communication using cthreads(tosthreads library)
  2. Running cthreads (tosthreads) program in Avrora
  3. BlinkToRadio in Avrora
  4. Running TinyOS programs using Avrora

Radio Communication Simplified Using TOSTHREADS

Dear reader,
Welcome back again with another post on tosthreads or cthreads in TinyOS. As usual my assumption is that you have followed up to my last post on cthreads. If not, it's beter to do it now before continuing!!!
If you have visited tinyos wiki, you may wonder how complex the radio communication code for BlinkToRadio. All that we are trying is to send a simple msg and it needs lot of files. Till now I have not seen a better way of doing that communication. (I am also learning things in NesC)
What we are trying to do is , to use 2 nodes "a sender and a receiver". Sender will send the data and receiver will receive it and blink the leds. We will write the program and will test it using Avrora as usual.

Algorithm Sender
  1. Initialise radio
  2. Create packet
  3. Set count
  4. Send the data
  5. Increment count and repeat 4
Here, we need to create a nx_struct as a wrapper. Those who tried to implement BlinkToRadio will see that this part is same
After that create a thread which will continuously send the data.
#include "tosthread.h"
#include "tosthread_amradio.h"
#include "tosthread_leds.h"
typedef nx_struct RadioMsg {
nx_uint8_t counter;
} RadioMsg;
//Initialize variables associated with each thread
tosthread_t radio_thread;
void radio_thread_foo(void* arg);
message_t send_msg;
RadioMsg* rdata; //pointer into message structure
//Initialize messages for sending out over the radio


void tosthread_main(void* arg)
{
while( amRadioStart() != SUCCESS ); //wait till radio is ready
tosthread_create(&radio_thread, radio_thread_foo, NULL, 200);
}
void radio_thread_foo(void* arg)
{
uint8_t count;
rdata=radioGetPayload(&send_msg, sizeof(RadioMsg));

for(;;)
{
count++;
rdata->counter=count;
if(amRadioSend(AM_BROADCAST_ADDR,&send_msg, sizeof(RadioMsg), 2) == SUCCESS)
{

setLeds(count);
tosthread_sleep(1000);
}

}
}

The code is self explanatory!!!!

Algorithm Receiver
  1. Initialise the radio
  2. Wait for a packet
  3. Get the data
  4. Blink LED s
#include "tosthread.h"
#include "tosthread_amradio.h"
#include "tosthread_leds.h"
typedef nx_struct RadioMsg {
nx_uint8_t counter;
} RadioMsg;
//Initialize variables associated with each thread
tosthread_t radio_thread;
void radio_thread_foo(void* arg);

//Initialize messages for sending out over the radio
message_t radiomsg;

void tosthread_main(void* arg)
{
while( amRadioStart() != SUCCESS ); //wait till radio is ready
tosthread_create(&radio_thread, radio_thread_foo, &radiomsg, 200);
}
void radio_thread_foo(void* arg)
{
message_t* m = (message_t*)arg;
RadioMsg *rm;
uint8_t count=0;
for(;;)
{
if((amRadioReceive(m, 50, 2))== SUCCESS)
{

// if(radioGetPayloadLength(m)==sizeof(RadioMsg))
{
rm=radioGetPayload(m,sizeof(RadioMsg));
setLeds(rm->counter);
tosthread_sleep(1000);

}
}
}
}


Create makefile for each and compile the code using "make mica2 cthreads"
Follow the steps in last post, you can run it using avrora.

Download Code

Links you may be interested in
  1. Working with serialforwarder in Avrora
  2. Running cthreads (tosthreads) program in Avrora
  3. BlinkToRadio in Avrora
  4. Running TinyOS programs using Avrora

Working with motes using TOSTHREADS... An easier way to do TinyOS programming

Dear reader,
Thanks a lot for responses and comments to make my small efforts on TinyOS programming a success. So here is another good news for C programmers who wants to work on TinyOS. No more NesC codes and hurdles of it.
TinyOS 2.10 comes with integrated library for tinythreads. The library examples can be found in "/opt/tinyos-2.1.0/apps/tosthreads" for a default installation.
The directory under it, "capps" is specially interesting to us.

Here I assume that you have done TinyOS installation and Avrora configuration from my past posts and enjoyed testing the blink application and blink2radio application.Also you have done programming in Threads using C.

What is so exciting in this folder? Well we are back to our favourite language "C". Let's rewrite the program using C and tosthreads

Quick refresh on Posix standard Thread in C

  • Declare thread_t instances
  • Define functions of void* foo(void*)
  • Create thread using pthread_create()
TOSTHREADS programming
Revisiting Blink

#include "tosthread.h"
#include "tosthread_leds.h"
tosthread_t blink;

void blink_thread(void* arg);
void tosthread_main(void*arg)

{

tosthread_create(&blink,blink_thread,NULL,400);
}
void blink_thread(void*arg)
{
uint8_t counter;
for(counter=0;counter<8;counter++)
{
setLeds(counter) ; tosthread_sleep(200);
}
}

Save the above code as Blink.c
Making the program : Makefile

TOSTHREAD_MAIN=Blink.c
include $(MAKERULES)
Save above code as Makefile

Compiling the program
Open a shell in the same folder where Makefile and Blink.c are stored. Type
make mica2 cthreads
If everything goes fine you will get output similar to


Running the program using Avrora
From shell change directory to "mica2/build"
cd mica2/build
Convert the main.exe to blink.od
convert-avrora main.exe blink.od
Run the simulation
avrora -platform=mica2 -seconds=3 blink.od
Output will be similar to the following


Tip: Modify the program to make the thread running for ever instead of 8 counts.
Keep reading!!!!
I will be back with more programs.
Meanwhile if you have any simple code, please send it or add as comments so that others will be benefited.

Links you might be interested

Running TinyOS Programs using Avrora

Running multiple node simulation using Avrora: Example BlinkToRadio


Installation of TinyOS 2.10 in Ubuntu

WSN: A layman's view

Running BlinkToRadio using Avrora

Dear reader,
So it's time to test something more interesting. Here I assume that you have already installed tinyos2.10 and Avrora using my previous posts and you have gone through the TinyOS wiki about BlinkToRadio. The tinyos install directory contains app/tutorials folder where you can find implemented code of all these programs.

I am not explaing the code, but just try to demonstrate how to run the code using Avrora

Step1
Build the program using "make mica2"

Step 2
Convert the main.exe file to radio.od
"convert-avrora main.exe radio.od"

Step 3
Run the program using sensor network mode of avrora
"avrora -simulation=sensor-network -seconds=2.0 -nodecount=2 radio.od"

If things work fine, output will be similar to the following


Play around with the avrora monitor options to see more options
Have fun!!!!!!

Running TinyOS programs using Avrora

Avrora
The readers may be wondering, the post for installation of TinyOS does not have TOSSIM installation steps. It's because I have found Avrora emulator more easier than TOSSIM scripts. Avrora is emulator/simulator for wireless sensor networks, written in Java by UCLA group. It takes an object dump of tinyos programs over AVR platforms ( mica2/micaz) and is capable of single node emulation for verification of the program as well as multiple node simulation. The gui provided with Avrora is not functional when this document is written.

Here I assume that username is "test", tinyos 2.10 and java run time environent are installed. The code used for illustration along with one more application is given for download at end of tutorial

Download the Avrora [Beta 1.7.105] from the site.

Setting up the environment
  1. Copy the avrora jar file in a directory say "home/test/avrora/avrora.jar"
  2. Download the converter.sh
  3. Extract the tar file and get the converter.sh
  4. Assuming that path for converter.sh is "home/test/avrora/converter.sh" copy the following code to ".bashrc"

  5. alias avrora='java -jar /home/test/avrora/avrora.jar'
    alias convert-avrora='sh /home/test/avrora/converter.sh'
  6. Close all the shells opened
  7. Take a new shell and type avrora /convert-avrora, it should produce the following output



Writing our first program: Blink
Please note that this is not blink program described in TinyOS wiki. This is much more simpler version of it.
This consist of following steps
  1. Interfaces : Boot, Leds
  2. Implementation file BlinkC
  3. Define Wiring
  4. BlinkC -> MainC.Boot
  5. BlinkC.Leds -> LedsC ( 3-5 steps is in BlinkAppC )
  6. Write the implementation file BlinkC.nc
  7. Write the Makefile
  8. Compiling
  9. Running the application using Avrora
Save all the following codes in "blink" folder ( say /home/test/tinyospgs/blink)

#include "Timer.h" module BlinkC { uses interface Leds; uses interface Boot; } implementation { event void Boot.booted() { call Leds.set(1) ; call Leds.set(2); call Leds.set(3); call Leds.set(4); call Leds.set(5); call Leds.set(6); call Leds.set(7); } }
Save the above code as "BlinkC.nc"
configuration BlinkAppC
{
}
implementation
{
components MainC, BlinkC, LedsC;
BlinkC -> MainC.Boot;
BlinkC.Leds -> LedsC;
}
Save above code as BlinkAppC.nc
COMPONENT=BlinkAppC
include $(MAKERULES)

Save above as Makefile

Now take a shell, navigate to this folder
Type "make mica2 "
If everything is correct, it will create build/mica2 folder
Navigate to mica2 folder in shell (cd build/mica2)
Type "convert-avrora main.exe blink.od"


Run the simulation by "avrora -seconds=5.0 -platform=mica2 blink.od"
Output will be similar to the following


Congratulations!!!!!!!
You are successfully emulated the first program
Note that only AVR platforms such as Mica2/Micaz is supported by Avrora

Links you might be interested in
Code Download this code and blink with timer here

Radio communication simulation simulation using Avrora

TinyOS programming using C an eazier way : tosthreads simulation using Avrora

Installation of TinyOS in Ubuntu

TinyOS is becoming the defacto standard OS for sensor network platforms and Ubuntu is most popular distro in Linux flavours. The follwing steps helps to install the TinyOS environment and compile and run the programs.

After everything is done, download this skelton code and verify the installation

UPDATED FOR TINYOS 2.1.1
Assumptions

Distribution is Ubuntu Hardy Heron

TinyOS version is TinyOS 2.1.0/ 2.1.1

Username is "test"

If this is not, update information is given at each step with your version

Installation

  1. Go to System -> Administration-> Synaptic Package Manager ( from the Top Panel )
  2. In Synaptic Package Manager go to settings ->repositories.
  3. Take 3rd party Software . Click on Add and copy the following. Assuming that your distribution is Hardy.
                deb http://tinyos.stanford.edu/tinyos/dists/ubuntu hardy main
    or for a different distribution of Ubuntu
    (deb http://tinyos.stanford.edu/tinyos/dists/ubuntu * main)
  4. Click OK and then reload repositories
  5. After reload is done, Search for TinyOS and set install and apply changes.
  6. Once the installation is finished, set the shell environment. Take a shell and type
    gedit ~/.bashrc and add follwing lines at bottom
     source /opt/tinyos-2.1.0/tinyos.sh   
    OR
       source /opt/tinyos-2.1.1/tinyos.sh 
Checking the Installation
  1. Close the previous shell. Take a new Shell
  2. Type echo $MAKERULES. If everything is ok, it will display the path.

First Program in TinyOS
Follwing is the simplest program which can be written for TinyOS
Take gedit, copy paste following code.
/* */
configuration SkelAppC {
}
implementation
{
components MainC, SkelC;
SkelC -> MainC.Boot;
}
Save as SkelAppC.nc
Take new file in gedit. Type follwing code
/* The SKEL application */
module SkelC

{
uses interface Boot;

}
implementation
{

event void Boot.booted()
{
1;
}
}
Save the file as SkelC.nc
Take new file in gedit
Type following

COMPONENT=SkelAppC
include $(MAKERULES)
Save as Makefile

Verification

Assuming that username is "test" and your files "SkelC.nc, SkelAppC.nc and Makefile" are in /home/test/tinyos/apps
Take a shell. Type following
cd /home/test/tinyos/apps make telosb

If everything is fine, your output should look similar to above one.

(Same code is provided for download)

Links you may be interested
Running TinyOS Programs using Avrora
Running multiple node simulation using Avrora: Example BlinkToRadio

Introduction to Wireless Sensor Networks

What are sensor networks?

Sensor networks consist of many - up to several thousand - small distributed computing devices that sense and interact with the environment. Various sensors allow a sensor node to measure
temperature, sound, vibration, pressure, motion or pollution. Their low price and low energy
ensures that sensor networks can be deployed in large numbers. A sensor node consists of a smal
microcontroller, a radio device, some sensors, and a power supply, usually a battery. Their resources in terms of energy, memory, computational power and bandwidth are severely limited, making sensor nodes an interesting research topic. Due to their processing and communication abilities sensor networks are intelligent. Thus, the network can independently from human interaction deal with node failure, aggregate measurements from various nodes into meaningful data, reprogram selected nodes for new tasks

Why are sensor networks cool?

In the 1980s, the PC revolution put computing at our fingertips.
In the 1990s, the Internet revolution connected us to an information web that spans the planet.
And now the next revolution is connecting the Internet back to the physical world we live in-in
effect, giving that world its first electronic nervous system.
Call it the Sensor Revolution: an outpouring of devices that monitor our surroundings in ways we
could barely imagine a few years ago. Some of it is already here. The rest is coming soon

What are the real time applications?

WSN applications can be classified into two categories. monitoring and tracking. Monitoring applications include indoor/outdoor environmental monitoring, health and wellness monitoring, power monitoring, inventory location monitoring, factory and process automation, and seismic and structural monitoring. Tracking applications include tracking objects, animals, humans, and vehicles.



Road tunnel fire rescue with wireless sensor networks ( from Discovery)



There is more to go. Currently it's hardly 8-10 year old technology. The researchers are facing challenges in
  • Limited power
  • Ad-Hoc operation ( there is no centralized control over network )
  • Diversity in applications
  • Limited radio communication and computation capabilities
Quick Links and References

Crossbow blog for interesting applications currently deployed
National Science Foundation :WSN Page
Wireless sensor network survey : Jennifer Yick, Biswanath Mukherjee, Dipak Ghosal(Article in press) ScienceDirect 2008

Security in Wireless Sensor Networks

Security in Sensor Networks

Introduction

Wireless Sensor Networks are expected to be a solution to applications. Two categories of applications are monitoring and tracking. This include industrial/health/millitary applications which are mission critical and often handle sesitive data. But because of the peculiar nature of network, the traditional security mechanisms are often can not be applied to WSN.
The major obstacles are
  1. Very limited resources: Computing, commnication and energy
  2. Unreliable communication: Unreliable transfer, conflicts because of broadcast/multicast nature of network and latency in communication
  3. Unattended operation: Nodes are exposed to physical attacks. They are managed remotely and there is no central management point.
These differences greately affect how secure data transfer schemes are implemented. The limited computing and communication power make WSN succeptible to DoS attacks. The public key cryptographic schemes currently deployed needs lot of computing and can not be ported in WSN. Thus most of the security schemes employ symmetric key cryptography.

Security Requirements

WSN's are application specific. The requirements mainly depend on the nature of data, WSN handles. Broadly the requirements can be viewed as
  1. Data Confidentiality: It's important in applications such as millitary operations or when the network handles sensitive data
  2. Data integrity: WSN should be able to tolerate active attacks such as tampering of messages which may be due to a mallicious node trying to modify the traffic passing through it or due to communication errors or node malfunctioning
  3. Data freshness: Data freshness suggest that the data is recent and no old messages has been replayed. Normally achieved using a nonce or packet id.
  4. Availability: The network can undergo node failures due to energy drain or malfunctioning of nodes. The increase in computation itself can make a node run out of energy.
  5. Self organization: WSN is a typical ad-hoc network which requires every node to self organize and self heal according to situations.
  6. Time Synchronization: The nodes need time synchronization for effective data transfer. Also the node may wish to find end-end delay for data transfer.
  7. Secure Localization: Often the node has to identify its correct location. This is important to application such as fault location or tracking applications
  8. Authentication: The receiver node has to make sure that data originated from correct source. This is important when base station issues commands / send program updates( migratable code).

Typical Attacks

  1. DoS attacks: Violation of communication protocols, jamming
  2. Sybil Attack: A malicious node illegimately taking on multiple identities. It's major attack on routing algorithms , data aggregation, voting, fair resource allocation and foiling misbehavior detection.
  3. Traffic analysis attacks: The sensor nodes normally route the information to base station. Often the traffic analysis can easily detect the base and make the network useless. Two basic and blind attacks are rate monitoring attack and time correlation attack.
  4. Node replication attacks: An attacker replicate the node ID of existing node by copying which can result in disconnected network or false sensor reading etc.
  5. Attacks against privacy: The traffic analysis by intruder can capture the entire information remotely. The major attacks agains sensor privacy are a) monitor and eavesdropping, traffic analysis and camouflage ( where attacker insert hidden nodes and re route information)
  6. Physical attacks: Include tampering the node/extract the cryptographic information etc.

Dealing with DoS



References

  1. Wireless Sensor NetworkSecurity : A Survey :- John Paul Walters, Zhengqiang Liang,
    Weisong Shi, and Vipin Chaudhary. 2006 Auerbach Publications, CRC Press
  2. A survey of Security Issues in WSN : Yong Wang, Garhan Attebury and Byrav Ramamurthy (2005)
  3. Taxonomy of Security Attacks in Sensor Networks and Countermeasures:- Tanya Roosta, ShiuhpyngShieh Shankar Sastry



Group

Review on Rethinking the Internet Design by Kahn

The article by David Clark on rethinking the design of internet analyses the original design goals v/s the current scenario of internet. The internet was designed to be based on end-to-end system with intelligence in hosts which communicates and not rely on the underlying architecture of communication. Thus it’s responsibility of the users/system at end to check for validity of data/information, process it/ discard it. The intermediate systems facilitate minimum functionality. This obviously made internet most popular with simple system designs and minimum effort to attach an end node.
The internet was designed and was believed to be used by experts basically for scientific or military applications. But analyzing the current trends and parties involved in internet, this is not the case.
The original assumption of trusted end systems totally vanished
The internet is used now for real time streaming which was not considered in the original design goal
The role of ISP’s for providing the services and involvement of 3rd parties and
Less sophisticated users
The Internet is currently used by all age groups, which means its beneficiaries are not only scientific community. Thus it invites public interests in content. The government and managements need control over the message delivered. Also there are scenarios where uses want a proof of transaction and some other time they want to be anonymous. There are issues in how much one can trust a software or hardware, as applications can monitor user activities and hardware properties can track a user from any part of the world with out knowledge of the user. Also the use of internet for spreading unwanted messages or SPAM or making denial of a service makes end systems to be more and more sophisticated (means it’s more complicated day by day).
The possible ways are
Modify the end node to have settings to control the applications. For eg: adult content to be used by children or tracking the user transaction under law by modifying the browser design. But the monitoring of contents by government takes away the assumption of end-end approach.
We can add functionality to the core by using firewalls, traffic filters and NAT elements. Firewalls are used widely to protect an island of nodes with rest by filtering normally done in network layer. There are application layer filters also such as application proxies. The design of NAT boxes removed the fear of running out of public IPs. But it removed the original design principle that addressing is unchanged during end-end transmission
The operation of ISP can be modified to control the contents passed. But with encryption mechanisms, the 3rd party interests are not preserved.
We can label the content like “Adv” for advertisement messages, or metadata content in the web site.
End-End design can use anonimisers, content filters and content caches for improved performance and less overhead to the end user.
We can use trusted parties service for PKI and content analysis.
We can have non technical solutions such as imposing law and order with cyber laws by modifying the existing ones.
The bad side of internet is that we are getting any kind of data in cheapest possible way. From the experience as a user of internet we see that the number of spam messages and porn advertisements increases day by day. There are reports of more and more cyber crime and issues related to content delivered especially to spread terrorism. We can never trust either the system or the software we are using, the license agreement says “use it as it is and the vendors are not responsible” for the losses caused by using it and if it’s objectionable, it is under court of XXX country and YYY place. News papers describe how internet fraud made loss of property for many or about new culture of social networking and private communication mechanisms. These are in fact the wrong sides of the internet.
The good side is that we are getting any kind of data in cheapest possible way. Again, the internet made possible to exploit the information available all over the world. It made possible , the users to share and collaborate for any kind of work they need, in more efficient way than earlier methods. It made revolution in many areas like human genome project or SETI@home distributed computing models for solving unsolved problems of public interest. It’s now used by all the people irrespective of the issues in it. This shows the success of the internet and computerization in general.
The question is what do we lack or who will improve the situations? Is it the private billion dollar companies or military or government to decide the future of internet or the ways in which it should be used? To answer that, let’s compare it with existing technologies, how they addressed certain issues
With telephone or post, anybody can post any objectionable content in past. They also keep anonymity. People used encryption from long time back in communication medium. The magazines or TV channels deliver any kind of matter including objectionable material. Hardly have they showed any warning to the viewers that it’s meant for adults.
The way in which they were controlled is collective by parties involved. An individual who use TV or magazine is aware of the possible content and prevent it to reach a kid. The organizations both profitable and non profitable works together to address the control of matter delivered through media. The postal and telephone companies have monitoring facilities, which can be used for the law enforcing agencies.
What is not there in internet and what do these systems have? It is the collective control. Currently the internet uses software or hardware which does not have “auditable” property. Also its design is controlled not by non profitable/ law making organizations for public interest. It’s by the corporate with their own vision to make more profit make the standards. ISP’s decide to charge based on the service and not the size of data. It’s so funny like some one charge you a paper with 20 bucks if you use it for essay writing and 2 bucks for the same, if it’s used for covering a material. Instead ISP should look for quality of service like “24 hr uptime, minimum congestion, preservation of offered bandwidth etc. Just like the first postal office and last postal office stamps the messages, which are trustable, we need stamps made by the ISP to make sure that any data delivered is traceable with trust.
The other thing to consider is, who can be the trusted parties? And do we need trusted parties per country/jurisdiction or we can have a consortium
A short set of suggestions for better internet
Trustable Stamping to trace the communication by ISP
Open architecture of system and network auditable by the experts of public interest and non profitable organizations
Making cyber laws in national and international level and co operative efforts by all parties for controlling objectionable material
A person holding world’s most accurate gun is not called secure if he does not know what he holds. So Creating awareness to the users for effective use of the internet than trying to create so called “more secure” machines.
Quality based charging with cost effective service design according to the demand of the society.
Monitoring facilities at ISP level to track terrorism and public threat matters and filtering facilities if needed subjected to court of jurisdiction of the country in which it’s offered.
Good morning/afternoon/evening dear reader
For many years we have seen the growth of internet and its good and bad use. This article is not commenting on that, but on the paper "The Design Philosophy of the DARPA Internet Protocols" David D. Clark* SIGCOMM ‘88.
I did this as a part of my course work, but felt to make it available for others also. Feel free to comment on my review, so that I can improve it.

Review on "The Design Philosophy of the DARPA Internet Protocols"

DARPA started the project of ARPANET on 1966 for reliable communication between two geographically separated “hosts”. They came up with packet switching instead of circuit switching, which uses store and forward technique for reliability compared to dedicated circuit switching. In 1970’s it was aimed to use services remotely using Telecommunication Networks protocol (TELNET) which ran above a 3 layer ARPANET protocol.(HOST/IMP, HOST/HOST and ICP) . The architecture proposed in 1974 by Robert Kahn and Vinton G Cerf used the term TCP as a protocol which used to mask any heterogeneity present in the underlying network architecture. The TCP has to address fragmentation, reassembly, reliable delivery with retransmission, routing and multiplexing. Notion of Gateway is used to transmit data between heterogeneous networks and unique addressing scheme was proposed to address end host nodes. It does not contain the notion of IP or internet protocol.

The paper by Clark describes the incorporation of “IP” or internet protocol which is used for unreliable packet transmission through available route. The end to end addressing is done by IP. Fragmentation and reassembly and virtual end to end connection retained in TCP. The reason of split was TCP will handle reliable sequencing of streams while IP attempt to provide basic building block “packet” to incorporate various service offered by higher layers.

The assumption was that TCP/IP is not suitable for real time data transmission systems such as voice traffic, since network does not define maximum end to end delay. Also the cross network debugger was removed from TCP/IP since it is not feasible through the unreliable IP with heterogeneous networks. Thus it’s the application designer’s job to do the debugging.

The idea of fate sharing, describes how “best effort” algorithm works. The design says, IP or intermediate gateway should not have any information about connections made by upper layer. Thus, the fragmented packets are reassembled by TCP at end host to deliver to an application.

The TCP/IP protocol architecture was evolved from practical issues faced during its development in ARPANET and later NSFNET. Thus it avoided the overhead caused by the 7 layer architecture. Comparing the same with 7 layer OSI, the visible difference in session and presentation logic as a full stack of protocols does not exist. Instead session management and presentation logic is made part of application layer. Thus TCP/IP was optimized in design which proved to be successful over other competing technologies of that age such as SNA by IBM and X.25.

However the design had a set of assumptions which ignored the end to end security. It is highly unlikely for a military application framework ignored such an important issue. There was no thought of implementing security at application level, since the applications Telnet, SMTP POP or FTP which was applications designed at that time, never had any security mechanisms. Anyone can wiretap the information, do any damage, still can hide since route information is never preserved. According to the design, the TCP uses sequence numbers, which can be generated using API creating. The IP source routing method was another flaw which make an attacker to re route the traffic to his machine. The routing protocol does not check the authenticity of the route information received. The management services in TCP/IP were poor in design which made it practically difficult to manage huge networks.

If the TCP/IP had incorporated a kernel level security module which uses PKI(Public Key Infrastructure) which can be used if an application needs security, it might have been much better. PKI was proposed in 1976 and in 1977 RSA algorithm was proposed. This paper and TCP/IP development was in 1982-87 where there were enough methodologies available to at least propose a security layer.

The architecture could have standardization in the service offered such as ISP and gateway should check, the ip forwarded is of its own network, which could have saved much threats including DoS and DDoS. Instead, for faster growth with competition the TCP/IP did not do it. The design goals does not took the fact who could be future users, when they expected faster growth in this kind of communication technology. Thus even now the SMTP and FTP servers run with plain text mechanisms

--------------------------------------


Other References:

  1. CERF and Kahn : A Protocol for Packet network inter communication IEEE 1974

  2. S M Bellovin Security problems in TCP/IP protocol suite ACM 1989

  3. Davidson et al The ARPANET TELNET protocol IEEE 1974