Routing Protocol Comparison for 6LoWPAN Ki-Hyung Kim (Ajou - - PowerPoint PPT Presentation

▶
routing protocol comparison for 6lowpan
SMART_READER_LITE
LIVE PREVIEW

Routing Protocol Comparison for 6LoWPAN Ki-Hyung Kim (Ajou - - PowerPoint PPT Presentation

Nov 09, 2022 109 likes •607 views

6LoWPAN WG, IETF64, Vancouver Routing Protocol Comparison for 6LoWPAN Ki-Hyung Kim (Ajou University) and S. Daniel Park (SAMSUNG Electronics) Contents 6LoWPAN Ad Hoc On-Demand Distance Vector R outing (LOAD)

slide-1
SLIDE 1

Routing Protocol Comparison for 6LoWPAN

Ki-Hyung Kim (Ajou University) and

  • S. Daniel Park (SAMSUNG Electronics)

6LoWPAN WG, IETF64, Vancouver

slide-2
SLIDE 2

2

Interoperability – IETF64 - Vancouver 07 Nov 2005

Contents

  • 6LoWPAN Ad Hoc On-Demand Distance Vector R
  • uting (LOAD)
  • draft-daniel-6lowpan-load-adhoc-routing-01.txt
  • Route Error Reporting Schemes
  • Dynamic MANET On-demand for 6LoWPAN (DYM

O-low) Routing

  • draft-montenegro-6lowpan-dymo-low-routing-00.

txt

  • Comparison of routing protocols for 6lowpan
  • Interoperability Issues with external IPv6 networks
slide-3
SLIDE 3

3

Interoperability – IETF64 - Vancouver 07 Nov 2005

Mesh Routing underneath to IPv6 Layer

PHY 802.15.4 MAC Adaptation IPv6 Transport Application PHY 802.15.4 MAC Adaptation IPv6 Transport Application PHY 802.15.4 MAC Adaptation IPv6 Transport Application

slide-4
SLIDE 4

4

Interoperability – IETF64 - Vancouver 07 Nov 2005

Inter-PAN Routing Protocol

  • LOAD is an Interworking Routing Protocol for a PAN of Multi

ple PANs

  • Furthermore, LOAD supports for Internet of PANS (i.e. Sea

mless All IP-based Wired Networks and Wireless PANs)

slide-5
SLIDE 5

6LoWPAN Ad Hoc On-Demand Dista nce Vector Routing (LOAD)

Ki-Hyung Kim (Ajou Univ),

  • S. Daniel Park (SAMSUNG Electronics)
  • G. Montenegro (Microsoft Corporation)
  • S. Yoo (Ajou Univ)

(draft-daniel-6lowpan-load-adhoc-routing-01.txt)

slide-6
SLIDE 6

6

Interoperability – IETF64 - Vancouver 07 Nov 2005

Introduction

  • 6LoWPAN Ad hoc Routing Protocol (LOAD) i

s a simplified on-demand routing protocol ba sed on AODV[RFC3561] for 6LoWPAN

  • Change-Log
  • This draft (01) is the merged version of
  • draft-daniel-6lowpan-load-adhoc-routing-00.txt
  • draft-montenegro-lowpan-aodv-00.txt
slide-7
SLIDE 7

7

Interoperability – IETF64 - Vancouver 07 Nov 2005

Main Features of LOAD

  • Use EUI-64 or 16 bit addresses
  • Use broadcast in the route discovery
  • Do not use the destination sequence number
  • Only destination Replies to RREQ by RREP
  • Do not use the local repair
  • Report back to the originator by RERR upon a link break
  • Do not maintain the precursorlist
  • Send RERR only to the originator of the data which caused the link

break

  • Use the route cost by utilizing the LQI of the 6LoWPAN PH

Y

  • Allow multiple schemes such as hop counts, aggregated LQI values,

and minimum LQI value along a route

  • Use the Acknowledged transmission option for keeping the

connectivity of a route (Does not use HELLO)

  • Maintains two tables: Route Request table, Routing table
slide-8
SLIDE 8

8

Interoperability – IETF64 - Vancouver 07 Nov 2005

Route Request (RREQ) Message LOAD: AODV:

slide-9
SLIDE 9

9

Interoperability – IETF64 - Vancouver 07 Nov 2005

Route Reply (RREP) Message

LOAD: AODV:

slide-10
SLIDE 10

10

Interoperability – IETF64 - Vancouver 07 Nov 2005

Route Error (RERR) Message

LOAD: AODV:

slide-11
SLIDE 11

Route Error Reporting Schem es

slide-12
SLIDE 12

12

Interoperability – IETF64 - Vancouver 07 Nov 2005

  • AODV
  • Utilize Precursorlist to reach the originators
  • LOAD
  • Does not use precursorlist -- to reduce the overhead of

RERR processing

  • Use the originator address of data packets
  • If the future revision of the format document allows the source ad

dress for multihop packets

  • Maintain symmetric forward and backward route on intermediate

nodes

  • Does not allow local repair
  • Unicast one-hop back propagation when there is no way

to know the route to the originator

RERR Back Propagation

slide-13
SLIDE 13

13

Interoperability – IETF64 - Vancouver 07 Nov 2005

Handling of Link Breaks in AODV

  • Local Repair
  • Precursorlist for RERR delivery

D S1 S2 S3 a b c e f

Dest NH HC Precursorlist

D f 2 a,b,c Routing Table of e g

slide-14
SLIDE 14

14

Interoperability – IETF64 - Vancouver 07 Nov 2005

Handling of Link Breaks in LOAD

  • Solution 1)
  • Utilize the source address of data packet to send RERR t
  • the originator (without precursorlist)
  • Node on an active route keeps a reverse route entry for s

ending RERR to the originator

D S1 S2 S3 a b c e f g

slide-15
SLIDE 15

15

Interoperability – IETF64 - Vancouver 07 Nov 2005

Handling of Link Breaks in LOAD (2)

  • Solution 2)
  • Unicast RERR back only to the previous hop nod

e D l m n a b c e f g S1 S2 S3

Data packet RERR

slide-16
SLIDE 16

16

Interoperability – IETF64 - Vancouver 07 Nov 2005

Handling of Link Breaks in LOAD (3)

  • Solution 3)
  • Broadcast RERR back by utilizing Routing table

entries

slide-17
SLIDE 17

17

Interoperability – IETF64 - Vancouver 07 Nov 2005

End-to-End Delay

slide-18
SLIDE 18

18

Interoperability – IETF64 - Vancouver 07 Nov 2005

Throughput

slide-19
SLIDE 19

19

Interoperability – IETF64 - Vancouver 07 Nov 2005

Delivery Ratio

slide-20
SLIDE 20

Dynamic MANET On-demand for 6LoWPAN (DYMO-low) Routing

Ki-Hyung Kim, (Ajou University)

  • G. Montenegro(Microsoft Corporation)
  • S. Daniel Park (SAMSUNG Electronics)
  • I. Chakeres (Boeing Phantom Works)
  • S. Yoo(Ajou University)

draft-montenegro-6lowpan-dymo-low-routing-00.txt

slide-21
SLIDE 21

21

Interoperability – IETF64 - Vancouver 07 Nov 2005

Simplification from DYMO

  • Obviates UERR (Unsupported Element Error)
  • DYMOcast is mapped as broadcast
  • No path accumulation
  • Only one Routing Block (RBlock)
  • Only the final destination responds
  • Allow Multiple Routing Elements (RE)
  • Possibly reduce the number of control messages by aggregation
  • Limit on the number of control message
  • Inserted the Error Code field into RERR
  • Utilize LQI for route cost calculation
  • Do not use HELLO message and Sequence Number
slide-22
SLIDE 22

22

Interoperability – IETF64 - Vancouver 07 Nov 2005

Generic Element Structure

DYMO: DYMO-low:

slide-23
SLIDE 23

23

Interoperability – IETF64 - Vancouver 07 Nov 2005

Routing Element (RE)

DYMO: DYMO-low:

slide-24
SLIDE 24

24

Interoperability – IETF64 - Vancouver 07 Nov 2005

Routing Block (RBlock)

DYMO: DYMO-low:

slide-25
SLIDE 25

25

Interoperability – IETF64 - Vancouver 07 Nov 2005

Route Error (RERR)

DYMO: DYMO-low:

slide-26
SLIDE 26

26

Interoperability – IETF64 - Vancouver 07 Nov 2005

Comparison of Routing Protocols for 6lowpan

Mobile Mobile/Stati c Mobile Mobile Mobile/Stati c Mobile/Stati c Mobility No Use Use Low Low No Use No Use Opt No Use No Use No Use Use

LOAD

Use Use Low Low No Use No Use Opt No Use No Use Use Use

DYMO-low

No Use Opt Low Low Use No Use No Use No Use No Use No Use Use

ZigBee

No Use No Low Low No Use No Use Use No Use No Use Use Use

TinyAODV

No Use No Use Control Packet Aggregation No Opt Link-layer feed back Low High Memory Usage Low High Energy Usage No Use Use Local repair No Use Use Hello message s No Use Use Hop count No Use Use Gratuitous RR EP No Use Use Precursor lists No Use Use Sequence num ber No Use Use RERR Messag e

AODVjr AODV

slide-27
SLIDE 27

27

Interoperability – IETF64 - Vancouver 07 Nov 2005

Interoperability with Internet

  • How can we route traffic to the external IPv6

network?

  • Allow different IPv6 Prefixes on WPANs?
  • If 6lowpan allows inter-PAN routing, this isn’t enough f
  • r identifying outbound traffic to external IPv6 network
  • Use of default GW?
  • Add 1 bit flag(E) in the Adaptation layer format for ide

ntifying outbound traffic to external IPv6 networks  F FDs forward those packets(E=1) to the default GW.

  • GW MAY advertise itself periodically
slide-28
SLIDE 28

28

Interoperability – IETF64 - Vancouver 07 Nov 2005

Handling outbound traffic to external IPv6 networ ks IPv6 prefix=0x6 IPv6 prefix=0x7 GW IPv6

Data(E=1)

slide-29
SLIDE 29

29

Interoperability – IETF64 - Vancouver 07 Nov 2005

Open Issues

  • Considering the route cost
  • Leave the route cost to be the implementation is

sues?

  • Parameters: Hop counts, LQI, remaining energy of no

des, etc.

  • Use of the 16bit address/EUI-64 address
  • Routing scalability
  • Limit the size of the 6lowpan?
  • Interoperability with Internet – Default Router
slide-30
SLIDE 30

6LoWPAN Evaluation Results

Ki-Hyung Kim (Ajou University) and

  • S. Daniel Park (SAMSUNG Electronics)

6LoWPAN WG, IETF64, Vancouver

slide-31
SLIDE 31

31

Interoperability – IETF64 - Vancouver 07 Nov 2005

Contents

  • Realization Platform
  • Implementation of 6lowpan
  • Implemented Protocol Stack
  • Preliminary Evaluation Results for Implementatio

n

  • Simulation model of 6lowpan on NS-2
  • Preliminary Simulation Results
  • Hierarchical Routing Protocol (HiLow)
  • Simple Service Location Protocol (SSLP)
slide-32
SLIDE 32

32

Interoperability – IETF64 - Vancouver 07 Nov 2005

Realization Platform

  • Hardware Platform
  • Custom built protototype referenced from c

c2420dbk of Chipcon

  • MCU: AVR Atmega128L, MAC: Chipcon C

C2420

  • Implemented Protocols
  • draft-ietf-6lowpan-format
  • draft-daniel-6lowpan-load-adhoc-routing
  • draft-daniel-6lowpan-hilow-hierarchical-rou

ting

  • Currently Implementing
  • draft-daniel-6lowpan-sslp
  • draft-montenegro-6lowpan-dymo-low-routi

ng

slide-33
SLIDE 33

33

Interoperability – IETF64 - Vancouver 07 Nov 2005

Protocol Stack

IEEE 802.15.4 PHY IEEE 802.15.4 MAC IPv6

Transport (UDP) 6Lowpan Specific Application (Socket Interface) (ex. SSLP, Serial port interface applications)

LOAD/ DYMO-low HiLow

Frag./Reassembly Adtl Formatting

Adaptation Mgmt

slide-34
SLIDE 34

34

Interoperability – IETF64 - Vancouver 07 Nov 2005

Testbed Setup

slide-35
SLIDE 35

35

Interoperability – IETF64 - Vancouver 07 Nov 2005

Topologies for Evaluation

  • Topology 1:
  • Varying # Nodes (3, 6, 9, 12)
  • Topology 2:
  • Varying # Nodes (4,6,8,10,12)
slide-36
SLIDE 36

36

Interoperability – IETF64 - Vancouver 07 Nov 2005

Delivery Ratio for Topology 1

slide-37
SLIDE 37

37

Interoperability – IETF64 - Vancouver 07 Nov 2005

Delivery Ratio for Topology 2

slide-38
SLIDE 38

38

Interoperability – IETF64 - Vancouver 07 Nov 2005

  • Num. of RERRs for Topology 2
slide-39
SLIDE 39

39

Interoperability – IETF64 - Vancouver 07 Nov 2005

Simulation Framework

  • Implements LOAD by NS-2
  • Uses IEEE 802.15.4 MAC by CUNY
  • Topology
  • 7x7 Grid
  • 7 Sources
  • 1 Destination
slide-40
SLIDE 40

40

Interoperability – IETF64 - Vancouver 07 Nov 2005

Delivery Ratio

slide-41
SLIDE 41

41

Interoperability – IETF64 - Vancouver 07 Nov 2005

Generated RERRs

slide-42
SLIDE 42

42

Interoperability – IETF64 - Vancouver 07 Nov 2005

Dynamic Assignment of Short Address (HiLow)

  • No Depth Limitation of trees
  • The only parameter is MC: Maximum number of Children
  • Efficient for gradually incremental networks

5 1 2 3 4 6 7 8 19 20 69 70 71 72

slide-43
SLIDE 43

43

Interoperability – IETF64 - Vancouver 07 Nov 2005

Hierarchical Routing (HiLow)

  • No need of routing tables

5 1 2 3 4 6 7 8 19 20 69 70 71 72 S D

slide-44
SLIDE 44

44

Interoperability – IETF64 - Vancouver 07 Nov 2005

Routing Algorithm for HiLow

  • If C is the member of SA:
  • The next hop node is AA(DC+1, D).
  • If C is the member of SD:
  • The next hop node is AA(DC-1, C).
  • Otherwise:
  • The next hop node is AA(DC-1, C).

, Where AA (D, k) : the address of the ascendant node of depth D of the node k SA, SD: Sets of ascendant nodes and descendant nodes C: Current node

slide-45
SLIDE 45

45

Interoperability – IETF64 - Vancouver 07 Nov 2005

Simple Service Location Protocol(SSLP)

  • When 6lowpan nodes come in close proximity, they need to

locate one another and services in proximity

  • Related Works
  • SLPv2 in Internet
  • SSDP(Simple Service Discovery Protocol) of UPnP
  • Jini
  • These are not suitable for 6lowpan
  • Limited packet size
  • Limited processing power
  • Dynamic nature of network topology
  • SSLP
  • Provides mechanisms for locating services and peer nodes in proxi

mity

  • Interoperates with SLPv2 on Internet
slide-46
SLIDE 46

46

Interoperability – IETF64 - Vancouver 07 Nov 2005

SSLP Header Format (1)

  • SSLP General Header
  • Message Type Abbreviation Msg-ID
  • Service Request SREQ 1
  • Service Reply SREP 2
  • Service Registration SREG 3
  • Service Deregistration SDER 4
  • Service Acknowledge SACK 5
  • DA Advertisement DADV 6
  • SA Advertisement SADV 7
slide-47
SLIDE 47

47

Interoperability – IETF64 - Vancouver 07 Nov 2005

SSLP Header Format(2)

Service Request: Service Reply:

slide-48
SLIDE 48

48

Interoperability – IETF64 - Vancouver 07 Nov 2005

Next steps

  • Feedback is welcome
  • Any comments/suggestions?