First Page

Index1

Overview of SAHNRouting in SAHN (SAHNR)

Simulation ResultsFuture Work

Current Project StatusAcknowledgements

Definition1SAHN

Definition

SAHN Definition

An alternative to

existing broadband

services for

cooperative users

using wireless

technology at an

affordable cost

Why not existing

solutions1

Dialup and high speed services (e.g. cable modems & xDSL)

• Provide mostly asymmetric bandwidth utilization

• Inadequate for file transfer, X protocol, interactive graphical programs etc

• Require costly wiring infrastructure

• Impose service charges

• Not widely available

Why not existing solutions2

Nokia RoofTop and other packet radio schemes

• Mostly centrally controlled

• Provide inadequate QoS

• Not optimized for Ad-Hoc networks

SAHN Motivation

• Commercial broadband solutions are:

– Expensive

– Not universally available

– Provide restricted service

• Commercial service restrictions:

– Asymmetric traffic characteristics

– Poor QoS management

– Only supports Internet protocols

– Limited security, management and accounting support

Motivation

• Provide services not offered by commercial service providers

• Bypass expensive infrastructure for broadband

• Provide symmetric bandwidth

• WLAN in inadequate wiring infrastructure

• Bypass ongoing service charges for Telcos independent traffic

Motivation2

• Feature QoS

• Security throughout all layers

• Utilizing link states (e.g. available bandwidth, link stability, latency, jitter and security) to select suitable routes

• Avoid selfish routing strategy

• Proper resource access control and management

SAHN

Definition

• Ideal for cooperative nodes. E.g. spread over a suburban area, connecting houses and business

• Topology is quasi static

• Uses wireless technology

• Multi-hop QoS routing

• Decentralized

• Symmetric broadband, multi Mbits/sec bandwidth

• Security

SAHN Definitio2

• No charges for SAHN traffic

• SAHN services

run alongside

TCP/IP• Conceived by

Ronald Pose & Carlo Kopp

Application

Presentation

Session

Transport

Network

Data Link

Physical

TCP/UDP

IP

Application

Presentation

Session

Transport

Network

Data Link

Physical

TCP/UDP

IP

SAHN

e.g. IEEE 802.11 variants

e.g. IEEE 802.11 variants

AUDIO

VEDIO

OTHER

Who should be using

• Home office and professionals requiring broadband connection to organisation’s systems

• Internetworking of businesses with their offices spread through a suburb, campus buildings etc

• People living around their campus can access the university’s network via SAHN without expensive commercial Telecom services

Users2

• Cooperative users can communicate and share a speedy Internet connection with each other via SAHN

• Houses linked with video clubs can download video streams on demand

• Groups with online gaming interests

Standalone SAHN

• Appears to host like a cable modem

• Functionally more like a

RF LAN repeater

• Embedded

microprocessor

protocol engine

implements all SAHN protocols and manages and configures the system

• Each SAHN node has at least 2 wireless links

• Capable of achieveing link rate throughput

SAHN Issue1

• Investigating wireless technology

• An appropriate routing solution

• A robust node authetication scheme

• Appropriate security models for various layers

• Integrating SAHN specific hardware and software solutions at minimum cost

• A suitable business model for exploiting the SAHN concept

Design Issues2

• Investigating wireless technology

• An appropriate routing solution

• A robust node authetication scheme

• Appropriate security models for various layers

• Integrating SAHN specific hardware and software solutions at minimum cost

• A suitable business model for exploiting the SAHN concept

References1

• R. Pose and C. Kopp. Bypassing the Home

Computing Bottleneck: The Suburban Area

Network. 3rd Australasian Comp. Architecture

Conf. (ACAC). February, 1998. pp.87-100.• A. Bickerstaffe, E. Makalic and S. Garic. CS

honours theses. Monash University.

www.csse.monash.edu.au/~rdp/SAN/. 2001• Paul Conilione, “QoS for Suburban Ad Hoc

Networks”. Honours Interim Presentation,

CSSE, Monash University, 5th June 2003

Index2

Overview of SAHNRouting in SAHN (SAHNR)

Simulation ResultsFuture Work

Current Project StatusAcknowledgements

SAHN Goals

• Wireless medium inherently vulnerable to– Eavesdropping– DoS attacks– Node masquerading

Requires security policies implemented at all levels

• Wireless technologies (e.g. 802.11) do not feature resource– Access control– Management

Requires higher level protocols

SAHN Goals

• Ad-Hoc wireless networks have to– Handle node/link failures– Find routes on demand– Route packets with QoS

Requires an efficient on-demand routing solution

Existing Routing0

• Table Driven

– Maintains multiple tables for route information

– Constant overhead for routing control packets

– e.g. DSDV, WRP, GSP, FSR, HSR

• On Demand

– Finds routes on demand– Reduced overhead of routing control packets– e.g. AODV, DSR, AOMDV, MSR, TORA,

ABR

Existing Routing1

• Hybrid– Employes both table driven and on

demand routing techniques– e.g. LANMAR

• Others

– Ensures QoS routing

– Can be any of the above three types

Existing Routing1

• Dynamic source routing (DSR) – On demand– Emplyes source routing– Can find multiple routes– Network overhead increases for carrying

source routes– No security at network layer– Does not consider QoS for route selection– Does not feature load balancing

Existing Routing1

• Ad Hoc on demand distance vector routing (AODV)– On demand– Cannot find multiple routes to a destination– No security at network layer– Does not consider QoS for route selection– No support for load balancing

Why Hybrid Approach1

Existing solutions do not feautrure one or more of the following attributes– Multiple routes to a destination– Resource Access Control– QoS– Load balancing– Security at network layer– Optimization for quasi-static networks

SAHNR1

• Keeps up-to-date neighbour information

• Employs source routing for route discovery

• Maintains routes dynamically

– Employs features of DSR.

e.g. gratuitous Route replies,

salvaging data/error packets etc.

SAHNR1

• Decreases network overhead– Excludes source route in every data packet

• Avoids selfish/uncoordinated routing strategy– Makes use of available paths having QoS– Chooses least congested paths– Balances load among available paths

• Features network level security by– Node authentication– Encryption of packet header information

SAHNR2

• Neighbour Discovery and Authentication

Periodically and on demand

• Route Discovery

On demand

• Data Transmission

On demand

• Route Maintenance

Periodically and on demand

Neighbor

Discovery1

Performed – When a node is powered up– After an idle period if needed

Main tasks are– Node authentication– Negotiation of security scheme for network layerRequires– ‘Hello’/‘Hello Reply’ packets

SAHNId

TypeLocal

SourceAddress

TotalSize

CRCLevel1

EncryptedLevel2 Payload

TransmissionTime (TT)

Sharedkey

Level 1

Level 2

Nehbourhood Discovery2

Node N wants to join SAHN

NS

G

H

FE

X

D

C

B

Nehbourhood Discovery2

N Generates aShared Key for

encryptionduring

transmittingdata to

neighbors

Encrypts level 2payload using

own Secret Key& generates

cipher text C1

Encrypts C1using SAHNPublic Key &

generatescipher text C2

Prepends C2with the

remaining`Hello'packet

Nehbourhoo

d Discovery2

HelloNS

G

H

FE

X

D

C

B

Hello

HelloHello

Hello

Node N broadcasts Hello packets and S, B, C, F, G receive them

Neighbor

Discovery3

Registers N as avalid SAHNnode. The

Shared Key issaved for future

encryption/decryption of

level 2 header ofthe sent/received

packets.

DeciphersC1 usingNode N's

Public KeyDeciphers C2 bySAHN Secret Key& generates C1

`Hello' packet?

Yes

Searches thedistributed and secured key

database for N'sPublic Key

Found

NotFound

Discardsthe invalid

packet

No

Processesfor other

packet types

Neighbor Discovery3

NS

G

H

FE

X

D

C

BReply

Reply

Reply Reply

Reply

Nodes S, B, C, F and G unicast Hello Reply packet to N

Neighbor

Discovery3

NS

G

H

FE

X

D

C

B

Now node N becomes a part of SAHN

Route Discovery1

• Performed if– Route is not present in routing table– Route has expired

• Requires

– RREQ and RREP packets

• Uses negotiated encrytion/decryption key for RREQ/RREP packet encrytion/decryption

SAHNId

TypeLocal

SourceAddress

TotalSize

CRCLevel1

EncryptedLevel2Header

TransmissionTime (TT)

GlobalSourceAddress

GlobalDestination

Address

RAQL. Each node'saddress & QoS values

Level 1

Level 2 SEQ HCHTL

Level 2 Data

Route

Discovery2

S wants route to X. S broadcasts RREQ packets to its neighbours

NS

G

H

FE

X

D

C

B

RREQ(S,QoSS)

RREQ(S,QoSS)

Route

Discovery2

Intermediate Nodes e.g. B does not have a route to Node X– B updates its routing table/forwarding table

with unknown information– Appends its address and QoS information

in RAQL– Broadcasts RREQ to its neighbours

Route Discovery2

NS

G

H

FE

X

D

C

B

RREQ(S,QoSS)

RAQL={(S,QoSS)}

RAQL={(S,QoSS)(B,QoSB)}

RAQL={(S,QoSS)(B,QoSB)(C,QoSC)(E,QoSE)}

Route Table::(X,QoSX):

Route Discovery3

• Intermediate node H has routes to X– H updates its routing/forwarding table with

unknown information– Appends H and QoSH with RAQL– Appends route to X and QoS information

with RAQL– Reverses RAQL– Forwards RREP to E from RAQL

• Same steps for X if it receives a RREQ

Route Discovery3

NS

G

H

FE

X

D

C

B

Route Table:::

RAQLE{(S,QoSS)(B,QoSB)(C,QoSC)(E,QoSE)}

Route Table(S,QoSS)(B,QoSB)(C,QoSC)(E,QoSE):(X,QoSX):

RAQLH{(X,QoSX)(H,QoSH)(E,QoSE)(C,QoSC)(B,QoSB)(S,QoSS)}

Route Discovery4

• Intermediate Nodes receive RREP packets– Update their routing/forwarding tables– Update QoS values of RAQL– Forward RREP

• Node S receives RREP packets– Updates its routing/forwarding table– Records routes– Selects suitable routes with acceptible

QoS to send data

Route Discovery4

NS

G

H

FE

X

D

C

B

Route Table:(B,QoSB)(C,QoSC)(E,QoSE)(H,QoSH)(X,QoSX)::

Route Table(S,QoSS)(B,QoSB)(C,QoSC)(E,QoSE):(X,QoSX):

RAQLH{(X,QoSX)(H,QoSH)(E,QoSE)(C,QoSC)(B,QoSB)(S,QoSS)}

RAQLE{(X,QoSX)(H,QoSH)(E,QoSE)(C,QoSC)(B,QoSB)(S,QoSS)}

RAQLC{(X,QoSX)(H,QoSH)(E,QoSE)(C,QoSC)(B,QoSB)(S,QoSS)}

RAQLB{(X,QoSX)(H,QoSH)(E,QoSE)(C,QoSC)(B,QoSB)(S,QoSS)}

Data Transmission1

• First few data packets contains full RAQL• An intermediate node

– Updates its routing/forwarding tables with unknown information

– Forwards data packet to the next node from RAQL

TotalSize

Data to be TransmittedCRC

Level3Level 3

SAHNId

TypeLocal

SourceAddress

TotalSize

CRCLevel1

EncryptedLevel2Header

TransmissionTime (TT)

GlobalSourceAddress

GlobalDestination

Address

Level 1

Level 2

SEQ HCHTLEncrypted Level3

Payload

EncryptedLevel 3Payload

RAQL

Data Transmission2

• Remaining data packets do not contain RAQL• An intermediate node

– Finds the next node from the forwarding table with <Global Source, Global Destination>

– Updates Local Source with its own address– Updates its routing/forwarding tables

TotalSize

Data to be TransmittedCRC

Level3Level 3

SAHNId

TypeLocal

SourceAddress

TotalSize

CRCLevel1

EncryptedLevel2Header

TransmissionTime (TT)

GlobalSourceAddress

GlobalDestination

Address

Level 1

Level 2

SEQ HCHTL Encrypted Level3 Payload

EncryptedLevel 3Payload

Route Maintenance1

Takes actions if

• A link fails

• A route error control packet is received

• Data packets are recieved for unknown destinations

• A neighbour/route/forward table entry is too oldSAHN

IdType

LocalSourceAddress

TotalSize

CRCLevel1

EncryptedLevel2Header

TransmissionTime (TT)

GlobalSourceAddress

GlobalDestination

Address

RAQL. Each node'saddress & QoS values

Level 1

Level 2 SEQ HCHTL

Level 2 Data

UnreachableNode

Address

Route Maintenance2

If the route maintenace module senses a link failure, it

• Tries to find alternate route to destination

• Sends RERR of the broken link to its neigbours

• Deletes corresponding entries of broken links from its neighbour/route/forward tables

Route Maintenance3

If a node receives a RERR packet the route maintenance module

– Sends RERR to its neigbours

– Deletes corresponding entries from its

neighbour/route/forward tables

SAHNId

TypeLocal

SourceAddress

TotalSize

CRCLevel1

EncryptedLevel2Header

TransmissionTime (TT)

GlobalSourceAddress

GlobalDestination

Address

RAQL. Each node'saddress & QoS values

Level 1

Level 2 SEQ HCHTL

Level 2 Data

UnreachableNode

Address

Route Maintenance4

If a node receives a data packet for unknown destination, the route maintenance module

– Tries to find a route to the destination

If it fails, it

– Sends RERR to the source of the data packet

Reference2

• A. Bickerstaffe, E. Makalic and S. Garic. CS

honours theses. Monash University.

www.csse.monash.edu.au/~rdp/SAN/. 2001• P. Misra. Routing Protocols for Ad Hoc Mobile

Networks. www.cis.ohio-state.edu/~jain/cis788-99/adhoc_routing/index.html. 02/07/2000

Index2

Overview of SAHNRouting in SAHN (SAHNR)

Simulation ResultsFuture Work

Current Project StatusAcknowledgements

Simulation Setup

110

1 2 3 4 5

6 7 8 9 10

13 14 15

12 17

16

• Node 0 sends node 11 8000 items of 1460 bytes each between simulated times 30 sec to 10 hr through FTP. • Node 11 sends node 0 11000 items of 1400 bytes each between simulated times 70 sec to 10 hr through FTP. • Node 12 sends node 13 9000 items of 1500 bytes each between simulated times 100 sec to 10 hr through FTP. • Node 0 sends node 11 13000 items of 512 bytes each between simulated times 15 sec to 10 hr. The inter

departure time for

each item is 3.1 sec.• Node 11 sends node 0 20000 items of 1024 bytes

each between

simulated times

28.8 sec to 10 hr.

The inter departure

time for each

item is 1.5 sec.

02000000400000060000008000000

100000001200000014000000

0 500 1000 1500 2000Simulation time (second)

No

of b

ytes

re

ceiv

ed

SAHNRDSRAODV

Simulation Result1

session duration for SAHNR

session duration for DSR

session duration for AODV

Comparing data reception rates at FTP server 11 at normal condition

Simulation Result

2

0

20000004000000

6000000

8000000

1000000012000000

14000000

0 500 1000 1500 2000

Simulation time (second)

No

of b

ytes

re

ceiv

ed

SAHNRDSRAODV

session duration for SAHNR

session duration for DSR

session duration for AODV

Comparing data reception rates at FTP server 11 when a node periodically switches off and on

Simulation Result3

Comparing load of CTRL packets in the network at normal condition

0

2000

4000

6000

8000

10000

12000

14000

0 1000 2000 3000 4000 5000

Simulation time (second)

No

of C

TR

L pa

ckte

s tr

ansm

itted

SAHNRDSRAODV

Simulation Result4

Comparing load of CTRL packets in the network when a node periodically switches off and on

0

5000

10000

15000

20000

0 1000 2000 3000 4000 5000

Simulation time (second)

No

of C

TR

L pa

cket

s tr

ansm

itted

SAHNRDSRAODV

Index4

Overview of SAHNRouting in SAHN (SAHNR)

Simulation ResultsFuture Work

Current Project StatusAcknowledgements

Future works

• Integrate all QoS metrics (bandwidth

reservation, error rate, latency) for routing• Incorporate security schemes i.e. node

authentication, encryption/decryption• Define a feasible network size & packet length• Detect non-cooperative nodes• Perform more simulations with varied network

sizes, different topologies with presence of

rouge nodes• Test SAHNR in real environment

Index5

Overview of SAHNRouting in SAHN (SAHNR)

Simulation ResultsFuture Work

Current Project StatusAcknowledgements

Current status

• Eliminated the use of Hello & Hello Reply

cycles for node authentication• Incorporated authentication scheme with route

discovery cycle• Performed more simulations with different

network topology

Current status2

Three more papers in press to be published• Routing In Suburban Ad-Hoc Networks

The 2003 International Conference on Computer Science and its Applications (ICCSA’03)

• A Hybrid QoS Routing Strategy for Suburban Ad-Hoc NetworksThe 11th IEEE International Conference on Networks (ICON’03)

• A Router Architecture To Achieve Link Rate Throughput In Suburban Ad-Hoc NetworksThe Eighth Asia-Pacific Computer Systems Architecture Conference (ACSAC’03)

Index6

Overview of SAHNRouting in SAHN (SAHNR)

Simulation ResultsFuture Work

Current Project StatusAcknowledgements

Acknowledgements

Initial definition of the SAHN architecture was carried out by Adrian Bickerstaffe, Enes

Makalic and Slavisa Garic in their computer science honours projects in 2001 at Monash

University. They also implemented the testbed. The current project builds on their excellent

work.

Part of presentation was partly done with Paul Conilione, using exclusively the abilities given to him by his Chinese Buddhist Taoist Master,

Shifu Chow Yuk Nen