Mobile’and’Wireless’Networks’2’Topic’3. Mobile’Ad’Hoc ... ·...

RETI WIRELESS E MOBILI -‐ 2013

A.  Specific properties B.  Flooding as a basic mechanism C.  Basic routing protocols

¢  DSR ¢  AODV y DYMO ¢  OLSR y OLSRv2

D.  Advanced protocols and techniques

E.  Delay Tolerant Networks

Mobile and Wireless Networks -‐ Topic 3. Mobile Ad Hoc Networks

Acknowledgments : u  Nitin H. Vaidya, “Tutorial on Mobile Ad Hoc Networks: Routing, MAC and Transport Issues” u  Available at: http://www.crhc.illinois.edu/wireless/tutorials.html

Routing basics

¡ Goal: transfer messages from one node to another £ Which is the “best path”? Generally

try to optimize one of the following: ¢  Shortest path (fewest hops) ¢  Shortest time (lowest latency) ¢  Shortest weighted path (utilize

available bandwidth, battery)

¡ Who decides: source or intermediate nodes? £ Source (“path”) routing

¢  Source specifies entire route ¢  Intermediate nodes just forward to

specified next hop £ Destination (“hop-‐by-‐hop”)

¢  Source specifies only destination in message header

¢  Intermediate nodes look at destination in header, consult internal tables to determine appropriate next hop

2

Unit Disk Graphs

¡ Motivation: £ Received Signal Strength decreases

proportionally to d-‐γ, ¢ where γ is the path loss exponent

£ Connections only exists if the signal/noise ratio is beyond a threshold

¡ Definition £ Given a finite point set V in R2 or R3, then: £ a Unit Disk Graph with radius r G=(V,E) of the

point set is defined by the undirected edge set:

£ where ||u,v||2 is the Euclidean distance:

3

MANET Routing Properties

¡ Distributed operation ¡ No external network setup è “self-‐configuring” ¡ Efficient when network topology is dynamic

£ links break, nodes come and go, …

¡ And also: £ Loop Freedom £ Sleep period operation £ Unidirectional link support £ Security

¡ Quantitative Properties £ End-‐to-‐End data throughput £ Delays £ Route Acquisition time £ Out of order delivery (percentage)

4

Types of protocols behaviour

¡ Proactive protocols £ They determine routes independently from the traffic patterns £ Traditional protocols like link-‐state and distance-‐vector are proactive

¡ Reactive protocols £ They create a route only if required

¡ There are also hybrid solutions ¡ Aspects to take into consideration

£  Waiting time for getting a route ¢  Proactive protocols are typically faster ¢  Reactive protocols normally have a higher latency

£  Overhead for route discover and maintenance ¢  Proactive protocols typically have an higher overhead because they are always updating routing

tables ¢  Reactive protocols normally have a lower overhead because they add control traffic only when

necessary

5

The solution to adopt depends on the type of the data traffic and the type of mobility!

manet Working Group

¡ IETF WG: Mobile Ad-‐hoc Networks (manet) £ http://www.ietf.org/html.charters/manet-‐charter.html £ Additional MANET links:

http://www.ianchak.com/manet/ £ Additional information is available at:

http://tools.ietf.org/wg/manet

¡ Purpose of MANET working group £ “Standardize IP routing protocol functionality suitable for wireless routing application

within both static and dynamic topologies with increased dynamics due to node motion or other factors.”

£ Approaches are intended to be: ¢ relatively lightweight in nature ¢ suitable for multiple hardware and wireless environments, and address scenarios ¢ hybrid mesh infrastructures (e.g., a mixture of fixed and mobile routers) should

also be supported by MANET specifications and management features.

6

Most relevant routing protocols

¡ D. Johnson, D. Maltz, and Y-‐C. Hu. The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks (DSR), RFC 4728, February 2007. http://tools.ietf.org/html/rfc4728

¡ C. Perkins, E. Belding-‐Royer, and S. Das. Ad hoc On-‐Demand Distance Vector (AODV) Routing. RFC 3561, July 2003. http://tools.ietf.org/html/rfc3561 £  I. Chakeres, C. Perkins.

Dynamic MANET On-‐demand (DYMO) Routing. draft-‐ietf-‐manet-‐dymo

¡  T. Clausen et al. The Optimized Link-‐State Routing Protocol version 2. draft-‐ietf-‐manet-‐olsrv2 £  T. Clausen and P. Jacquet.

Optimized Link State Routing Protocol (OLSR). RFC 3626, October 2003. http://www.ietf.org/rfc/rfc3626.txt

7

Proposed protocols

¡ Here: http://en.wikipedia.org/wiki/Ad_hoc_protocol_list

8







u Acknowledgments : u Nitin H. Vaidya, “Tutorial on Mobile Ad Hoc Networks:

Routing, MAC and Transport Issues” u Available at: http://www.crhc.uiuc.edu/wireless/

tutorials.html

Flooding as a basic mechanism 1/6

10

A

B

S

H

C

E

Z

I

G

F

K

N

L

J

M

D

Y

Node that just received a frame

Frame broadcasted

Node that just forwarded a frame

destination


11

A

B

S

H

C

E

Z

I

G

F

K

N

L

J

M

D

Y

possible collision!!


Frame broadcasted



12

A

B

S

H

C

E

Z

I

G

F

K

N

L

J M

D

Y

Receives the frame but does not forward it. Already done


Frame broadcasted



13

A

B

S

H

C

E

Z

I

G

F

K

N

L

J

M

D

Y

Receives the frame form J and from K (which are mutually hidden) ð possible collision


Frame broadcasted



14

A

B

S

H

C

E

Z

I

G

F

K

N

L

J

M

D

Y

D does not forward it because is the final destination


Frame broadcasted



15

A

B

S

H

C

E

Z

I

G

F

K

N

L

J

M

D

Y

Flooding is over!


Frame broadcasted


Flooding as a basic mechanism: a few considerations

u Many protocols use limited flooding of the control packets. u Control packets are used to discover the routes.

u  Advantage: Simplicity u  Disadvantage: Overhead possibly very high

u The established routes are then used to send packets of data.

16









tutorials.html

Dynamic Source Routing (DSR)

¡ For networks of medium size (200 nodes), admits high speeds ¡ When node S wants to send a packet to node D, but does not have a route to D, begins a route discovery process.

¡ Source node S floods Route Request (RREQ) packets ¡ Each node adds its own id when it forwards a RREQ.

£ Use of the “send buffer”

18

Route Request in DSR, 1/5

19

A

B

S [S]

H

C

E

I

G

F

K

N

J

M

D

destination

Node that just received a RREQ

IDs list added to the RREQ

Node that just forwarded an RREQ

[X,Y]

Y


20

A

B

S

H

C [S,C]

E [S,E]

Z

I

G

F

K

N

L

J

M

D

Y

Possible collision!!




[X,Y]


21

A

B

S

H

C

E

Z

I

G [S,C,G]

F [S,E,F]

K

N

L

J M

D

Y

RREQ is not forwarded




[X,Y]


22

A

B

S

H

C

E

Z

I

G

F

K[S,C,G,K]

N

L

J [S,E,F,J] M

D

Y

Possible collision




[X,Y]


23

A

B

S

H

C

E

Z

I

G

F

K

N

L

J

M [S,E,F,J,M]

D

Y




[X,Y]

Route Reply

¡ Destination D, when receiving the first RREQ send a Route Reply (RREP)

¡ RREP is sent using the route obtained by reversing the one that is in the received RREQ

24

Y

A

B

S

H

C

E

Z

I

G

F

K

N

L

J

M

D

RREP [S,E,F,J,D]

Route Reply en DSR

¡ Route Reply can be sent by reversing the route in Route Request (RREQ) only if links are guaranteed to be bi-‐directional £ To ensure this, RREQ should be forwarded only if it received on a link that is known

to be bi-‐directional

¡ If unidirectional (asymmetric) links are allowed, then RREP may need a route discovery for S from node D £ Unless node D already knows a route to node S £ If a route discovery is initiated by D for a route to S, then the Route Reply is

piggybacked on the Route Request from D.

¡ If IEEE 802.11 MAC is used to send data, then links have to be bi-‐directional (since ACK is used)

25

Dynamic Source Routing (DSR)

¡ Node S on receiving RREP, caches the route included in the RREP

¡ When node S sends a data packet to D, the entire route is included in the packet header £ hence the name source routing

¡ Intermediate nodes use the source route included in a packet to determine to whom a packet should be forwarded

26

Data Delivery in DSR

27

Packet header size grows with route length

A

B

S

H

C

E

Z

I

G

F

K

N

L

J

M

D

Y

DATA [S,E,F,J,D]

DSR Optimization: Route Caching (1/2)

¡ Each node caches a new route it learns by any means £ When node S finds route [S,E,F,J,D] to node D, node S also learns route [S,E,F] to

node F £ When node K receives Route Request [S,C,G] destined for node D, node K learns

route [K,G,C,S] to node S £ When node F forwards Route Reply RREP [S,E,F,J,D], node F learns route [F,J,D] to

node D £ When node E forwards Data [S,E,F,J,D] it learns route [E,F,J,D] to node D £ A node may also learn a route when it overhears Data packets

28

A

B

S

H

C

E

Z

I

G

F

K N

L

J

M

D

Y

DSR Optimization: Route Caching (2/2)

¡ When node S learns that a route to node D is broken, it uses another route from its local cache, if such a route to D exists in its cache. Otherwise, node S initiates route discovery by sending a route request

¡ Node X on receiving a Route Request for some node D can send a Route Reply if node X knows a route to node D

¡ Use of route cache £ can speed up route discovery £ can reduce propagation of route requests

29

A

B

S

H

C

E

Z

I

G

F

K N

L

J

M

D

Y

Route Error (RERR)

¡ J sends a route error to S along route J-‐F-‐E-‐S when its attempt to forward the data packet S (with route SEFJD) on J-‐D fails

¡ Nodes hearing RERR update their route cache to remove link J-‐D

¡ Each node is responsible for confirming that the link can be used to transmit data. £ Ack del MAC (p.ej., 802.11) £ Passive acks £ DSR-‐specific ACK

30

Y

A

B

S

H

C

E

Z

I

G

F

K

N

L

J

M

D

RERR [J-D]

DSR additional techniques

¡ “Expading ring” technique playing with the TTL of the packets £ “non propagating” Route Request

¡ “Route salvaging” technique for route maintenance £ Dynamic substitution of routes for intermediate ndoes

¡ “Automatic route shortening” technique for routes optimization £ Based on “gratuitous” Route Reply

¡ The “flows”

31

DSR: advantages and disadvantages

¡ Routes maintained only between nodes who need to communicate £  reduces overhead of route maintenance

¡ Route caching can further reduce route discovery overhead

¡ A single route discovery may yield many routes to the destination, due to intermediate nodes replying from local caches

¡ Packet header size grows with route length due to source routing

¡ Flood of route requests may potentially reach all nodes in the network

¡ Care must be taken to avoid collisions between route requests propagated by neighboring nodes £  insertion of random delays before

forwarding RREQ

¡ Increased contention if too many route replies come back due to nodes replying using their local cache £  Route Reply Storm problem £  Reply storm may be eased by preventing a

node from sending RREP if it hears another RREP with a shorter route

32









tutorials.html

First Back to basics J: Distance Vector Algorithms (1)

¡ “Distance” of each link in the network is a metric that is to be minimized £ Each link may have “distance” 1 to minimize hop count £ Algorithm attempts to minimize distance

¡ The routing table at each node… £ Specifies the next hop for each destination £ Specifies the distance to that destination

¡ Neighbors can exchange routing table information to find a route (or a better route) to a destination

¡ Count-‐to-‐infinity problem

34


35

A

B

C D

B Dest Next Metric

B 1 C B 2 D B 3

A Dest Next Metric

A 1 C C 1 D C 2

A Dest Next Metric

B 2 B B 1 D D 1

A Dest Next Metric

C 3 B C 2 C C 1


36

¡ Node A will learn of Node C’s shorter path to Node D and update its routing table

A

B

C D

B Dest Next Metric

B 1 C C 1 D C 2

A Dest Next Metric

A 1 B B 1 D D 1

Ad Hoc On-‐Demand Distance Vector Routing (AODV)

¡ AODV attempts to improve on DSR by maintaining routing tables at the nodes, so that data packets do not have to contain routes £ DSR includes source routes in packet headers. This results in large headers that can

degrade performance, particularly when data contents of a packet are small.

¡ AODV retains the feature of DSR that routes are maintained only between nodes which need to communicate £ Route Requests (RREQ) are forwarded in a manner similar to DSR £ When a node re-‐broadcasts a Route Request, it sets up a reverse path pointing

towards the source (originator) ¢ AODV assumes symmetric (bi-‐directional) links

£ When the intended destination receives a Route Request, it replies by sending a Route Reply (RREP)

£ Route Reply travels along the reverse path set-‐up when Route Request is forwarded

¡ Local HELLO messages are used to determine local connectivity £ Can reduce response time to routing requests £ Can trigger updates when necessary

37

Controlling loops

¡ Every node maintains two counters £ The node's own sequence number (node_seq_num), incremented when:

¢ Immediately before a node originates a route discovery. ¢ Immediately before a destination node originates a RREP in response to a RREQ.

The sequence number is updated to the maximum of its current sequence number and the destination sequence number in the RREQ packet.

£ The RREQ (or broadcast) ID (node_RREQ_ID)

¡ Sequence numbers are assigned to routes and routing table entries £ Used to supersede stale cached routing entries £ Source sequence indicates “freshness” of reverse route to the source £ Destination sequence number indicates freshness of route to the destination

38

Route table entry

39

Destination IP Address

Destination Sequence Number

Valid Destination Sequence Number flag

Other state and routing flags (e.g., valid, invalid, repairable, being repaired)

Network Interface

Hop Count (number of hops needed to reach destination)

Next Hop

List of Precursors (neighboring nodes to which a route reply was generated or forwarded)

Lifetime (expiration or deletion time of the route)

the latest information available about the sequence number for the IP address of the destination node. It is updated whenever a node receives new (i.e., not stale) information about the sequence number from RREQ, RREP, or RERR messages that may be received related to that destination.

AODV Route Request (1)

¡ Initiated when a node wants to communicate with another node, but does not have a route to that node

¡ Originator node broadcasts a route request (RREQ) packet to its neighbors

40

AODV Route Request (3)

¡ The pair (originator address, RREQ_ID) uniquely identifies the RREQ £ Receivers can identify and discard duplicate RREQ packets £ RREQ_ID is incremented for every RREQ packet sent

¡ Every neighbor receives the RREQ and either … £ Returns a route reply (RREP) packet, or £ Forwards the RREQ to its neighbors

¡ If a node forwards the RREQ to its neighbors: £ The node saves in the routing table information to implement a reverse path

¢ An entry to the previous hop ¢ An entry to the originator

£ The node increments the hop count in the RREQ packet

41

AODV Example (1)

¡ Node 1 needs to send a data packet to Node 7 ¡ Assume Node 6 knows a current route to Node 7 ¡ Assume that no other route information exists in the network (related to Node 7)

42

1 4

3 5 2

6

7

AODV Example (2)

¡ Node 1 sends a RREQ packet to its neighbors

43

1 4

3 5 2

6

7

1

7

node_RREQ_ID (previously incremented by 1) 0

last_dest_seq (node 7)

node_seq_num (previously incremented by 1)

AODV Example (3)

¡ Nodes 2 and 4 verify that this is a new RREQ and that the originator sequence number is not stale with respect to the reverse route to Node 1

¡ Nodes 2 and 4 forward the RREQ £ Increment hop_cnt in the RREQ packet £ Update originator sequence number for Node 1

44

1 4

3 5 2

6

7

AODV Example (4)

¡ RREQ reaches Node 6, which knows a route to 7 £ Node 6 must verify that the destination sequence number in the packet is

smaller than or equal to the destination sequence number it has recorded for Node 7

¡ Nodes 3 and 5 will forward the RREQ packet, but the receivers recognize the packets as duplicates

45

1 4

3 5 2

6

7

AODV Route Reply (1)

¡ If a node receives an RREQ packet and it has a current route to the target destination, then it unicasts a route reply packet (RREP) to the neighbor that sent the RREQ packet

46

AODV Route Reply (2)

¡ Intermediate nodes propagate the first RREP for the source towards the source using cached reverse route entries

¡ Other RREP packets are discarded unless… £ Destination sequence number number is higher than the previous, or £ Destination sequence number is the same, but hop_cnt is smaller (i.e., there’s a

better path)

¡ RREP eventually makes it to the source, which can use the neighbor sending the RREP as its next hop for sending to the destination

¡ Cached reverse routes will timeout in nodes not seeing a RREP packet

47

AODV Example (5)

¡ Node 6 knows a route to Node 7 and sends an RREP to Node 4

48

1 4

3 5 2

6

7

1

7

1

Stored sequence number

AODV Example (6)

¡ Node 4 verifies that this is a new route reply (the case here) or one that has a lower hop count and, if so, propagates the RREP packet to Node 1 £ Increments hop_cnt in the RREP packet

49

1 4

3 5 2

6

7

AODV Example (7)

¡ Node 1 now has a route to Node 7 in three hops and can use it immediately to send data packets

¡ Note that the first data packet that prompted path discovery has been delayed until the first RREP was returned

50

1 4

3 5 2

6

7

Dest Next Hops 7 4 3

AODV Route Maintenance

¡ Route changes can be detected by… £ Failure of periodic HELLO packets £ Failure or disconnect indication from the link level £ Failure of transmission of a packet to the next hop (can detect by listening for the

retransmission if it is not the final destination)

¡ The upstream (toward the source) node detecting a failure propagates an route error (RERR) packet with a new destination sequence number and a hop count of infinity (unreachable)

¡ The source (or another node on the path) can rebuild a path by sending a RREQ packet

51

AODV Example (8)

¡ Assume that Node 7 moves and link 6-‐7 breaks ¡ Node 6 issues an RERR packet indicating the broken path ¡ The RERR propagates back to Node 1 ¡ Node 1 can discover a new route

52

1 4

3 5 2

6

7

7

DYMO vs AODV

¡ Answers by Ian Chakeres to the question: “could you briefly explain what are the differences between DYMO and AODV “ £ 8 Mar 2005

¢ There are several differences between AODV, AODV-‐bis, DSR and DYMO. To list just a few. ¡ New packet format. ¡ Generic packet handling. ¡ Unsupported element handling. ¡ Optional path accumulation. ¡ Much more.

£ 23 Mar 2006 ¢ DYMO is a simpler version of AODV. DYMO is easier to implement and has

lower requirements (in terms of memory, code, etc.) than AODV. DYMO is close to what has been implemented for sensor networks, such as tinyAODV. AODV is no longer being explored in the MANET WG.

53

DYMO

54

¡ DYMO – Reactive Protocol like AODV, but with path accumulation feature

DYMO Path accumulation

¡ Path accumulation reduces the number of RREQs ¡ Topology information is discovered much more quickly ¡ However, it also increases the packet size

£ Packet size is often a burden that negates some of the benefit of path accumulation

¡ And, the benefit is reduced if newly discovered routes are not used before being purged from the routing cache

55









tutorials.html

First Back to basics J: Link-‐State Algorithms (1)

¡ Each node shares its link information so that all nodes can build a map of the full network topology

¡ Link information is updated when a link changes state (goes up or down) £ Link state determined by sending small “hello” packets to neighbors

¡ Given full topology information, a node can determine the next best hop or a route from the source

57


¡ Assuming the topology is stable for a sufficiently long period, all nodes will have the same topology information

58

A

B

C D A-B Link

B-C C-D

A-B Link

B-C C-D

A-B Link

B-C C-D

A-B Link

B-C C-D


¡ Nodes A and C propagate the existence of link A-‐C to their neighbors and, eventually, to the entire network

59

A

B

C D

A-B Link

B-C C-D

A-C

A-B Link

B-C C-D

A-C

A-B Link

B-C C-D

A-C

A-B Link

B-C C-D

A-C

A-C A-C

A-C

Optimized Link State Routing (OLSR)

¡ Proactive scheme based on the link-‐state mechanism. £ Each node periodically floods status of its links £ Each node re-‐broadcasts link state information received from its neighbor £ Each node keeps track of link state information received from other nodes £ Each node uses above information to determine next hop to each destination

¡ The overhead of flooding link state information is reduced by requiring fewer nodes to forward the information

¡ Does not require modifying the structure of the IP packets

60

OLSR v2

¡ Compared to OLSRv1, OLSRv2 retains the same basic mechanisms and algorithms, while providing an even more flexible signaling framework and some simplification of the messages being exchanged.

¡ OLSRv2 takes care to accommodate both IPv4 and IPv6 addresses in a compact fashion.

¡ The message exchange format has been factored out to an independent specification £ Clausen, T., Dean, J., Dearlove, C., and C. Adjih, "Generalized MANET Packet/

Message Format", work in progress.

¡ The OLSRv2 neighborhood discovery protocol using HELLO messages has been factored out to an independent specification £ Clausen, T., Dean, J., and C. Dearlove, "MANET Neighborhood Discovery Protocol

(NHDP)", work in progress.

61

LSR vs. OLSR

¡  The overload of broadcasting the status information on the links is reduced by limiting the number of nodes which forward this information £  A broadcast from node X is forwarded only

by its multipoint relays £  The multipoint relays of X are its neighbors

chosen so that every two-‐hops neighbors of X is a one-‐hop neighbors of at least one of its multipoint relay

£  Each node periodically transmits the list of its neighbors so that all nodes can know which are their two-‐hops neighbors, therefore being able to choose their multipoint relays

62

11 broadcasts are needed to spread the message up to three hops away

24 broadcasts are needed to spread the message up to three hops away

Sending node

Sending node

Terminology

¡ Nodes can have various OLSR interfaces, each with its own IP address £  Each node is assigned a unique reference IP

(‘main address’) ¡  neighbor: x is a neighbor of y if y can receive x

signal £  2-‐hop neighbor: a node whose signal is

received by its neighbor. £  strict 2-‐hop neighbor:

¢  a 2-‐hop neighbor which is not the node itself or a neighbor of the node, and in addition is a neighbor of a neighbor, with willingness different from WILL_NEVER, of the node.

¡ multipoint relay (MPR): £  A node selected by its neighbor x, to forward

all the broadcast messages received from x, if it is not a duplicate message and if life-‐time is >1

¡ multipoint relay selector (MS) £  A node that selected its neighbor x as a MPR

63

S

M

X Y Z

P

Neighbor sensing

¡  Each node periodically broadcasts Hello messages: £  List of neighbors with bi-‐directional link £  List of other known neighbors.

¡ Hello messages permit each node to learn topology up to 2 hops

¡ Based on Hello messages each node selects its set of MPR’s

64

MPR selection algorithm

¡ Each point u has to select its set of MPR. ¡ Goal: select in the 1-‐neighborhood of u (N1(u)) a set of nodes as small as possible which covers the whole 2-‐neighborhood of u (N2(u)), in two steps : £ Step 1: Select nodes of N1(u) which cover isolated points of N2(u).

(That we call MPR1(u).) £ Step 2: Select among the nodes of N1(u) not selected at the first step, the node

which covers the highest number of points (not already covered) of N2(u) and go on till every points of N2(u) are covered.

65

MPR selection algorithm : example

66

u

First step: select nodes in N1(u) which cover « isolated points » of N2(u).

MPR selection algorithm : example

67

u

Second step: Consider in N1(u) only points which are not already selected at the first step MPR1(u) and points in N2(u) which are not covered by the MPR1(u).

While there exists points in N2(u) not covered by the selected MPR, select in N1(u), the node which covers the highest number of non-covered nodes in N2(u).

MPR selection algorithm: example; final result

68

u

Multipoint Relay Selector Set

¡ The multipoint relay selector set for Node N, MS(N), is the set of nodes that choose Node N in their multipoint relay set £ Only links N-‐M, for all M such that N∈MS(M) will be advertised in control messages

69

MS(3) = {…, 4, …} MS(6) = {…, 4, …}

(Assuming bidirectional links)

1 4

3 5 2

6

7

HELLO Messages (1)

¡ Each node uses HELLO messages to determine its MPR set ¡ All nodes periodically broadcast HELLO messages to their one-‐hop neighbors (bidirectional links)

¡ HELLO messages are not forwarded

70

1 4

3 5 2

6

7

HELLO: NBR(4) = {1,3,5,6}

HELLO Messages (2)

¡ Using the neighbor list in received HELLO messages, nodes can determine their two-‐hop neighborhood and an optimal (or near-‐optimal) MPR set

¡ A sequence number is associated with this MPR set £ Sequence number is incremented each time a new set is calculated

71

1 4

3 5 2

6

7

At Node 4: NBR(1) = {2} NBR(3) = {2,5} NBR(5) = {3,6} NBR(6) = {5,7} MPR(4) = {3,6}

HELLO Messages (3)

¡ Subsequent HELLO messages also indicate neighbors that are in the node’s MPR set

¡ MPR set is recalculated when a change in the one-‐hop or two-‐hop neighborhood is detected

72

1 4

3 5 2

6

7

HELLO: NBR(4) = {1,3,5,6}, MPR(4) = {3,6}

MS(6) = {…, 4,…}

MS(3) = {…, 4,…}

TC Messages

¡ Nodes send topology information in Topology Control (TC) messages £ List of advertised neighbors (link information) £ Sequence number (to prevent use of stale information)

¡ A node generates TC messages only for those neighbors in its MS set £ Only MPR nodes generate TC messages £ Not all links are advertised

¡ A nodes processes all received TC messages, but only forwards TC messages if the sender is in its MS set £ Only MPR nodes propagate TC messages

73

OLSR Example (1)

74

1 4

3 5 2

6

7

MPR(1) = { 4 } MPR(2) = { 3 } MPR(3) = { 4 } MPR(4) = { 3, 6 } MPR(5) = { 3, 4, 6 } MPR(6) = { 4 } MPR(7) = { 6 }

MS(1) = { } MS(2) = { } MS(3) = { 2, 4, 5 } MS(4) = { 1, 3, 5, 6 } MS(5) = { } MS(6) = { 4, 5, 7 } MS(7) = { }

OLSR Example (2)

¡ Node 3 generates a TC message advertising nodes in MS(3) = {2, 4, 5}

¡ Node 4 forwards Node 3’s TC message since Node 3 ∈ MS(4) = {1, 3, 5, 6}

¡ Node 6 forwards TC(3) since Node 4 ∈ MS(6)

75

1 4

3 5 2

6

7

TC(3) = <2,4,5>

OLSR Example (3)

¡ Node 4 generates a TC message advertising nodes in MS(4) = {1, 3, 5, 6}

¡ Nodes 3 and 6 forward TC(4) since Node 4 ∈ MS(3) and Node 4 ∈ MS(6)

76

1 4

3 5 2

6

7

TC(4) = <1,3,5,6>

OLSR Example (4)

¡ Node 6 generates a TC message advertising nodes in MS(6) = {4, 5, 7}

¡ Node 4 forwards TC(6) from Node 6 and Node 3 forwards TC(6) from Node 4

¡ After Nodes 3, 4, and 6 have generated TC messages, all nodes have link-‐state information to route to any node

77

1 4

3 5 2

6

7

TC(6) = <4,5,7>

OLSR Example (5)

¡ Given TC information, each node forms a topology table

¡ A routing table is calculated from the topology table

¡ Note that Link 1-‐2 is not visible except to Nodes 2 and 3

78

TC(3) = <2,4,5>

TC(4) = <1,3,5,6> TC(6) = <4,5,7> 1

3 5 2

6

7

4

Dest Next Hops 1 4 2 2 2 1 4 4 1 5 5 1 6 4 (5) 2 7 4 (5) 3

Routing table

¡ All nodes manage a routing table ¡ Its structure is:

1. R_dest_addr R_next_addr R_dist R_iface_addr!2. R_dest_addr R_next_addr R_dist R_iface_addr!3. ,, ,, ,, ,,!

¡ Each entry indicates that node R_dest_addr is R_dist hops away, and the first hop is through R_next_addr. This node can be reached through the local interface R_iface_addr

¡ There is an entry for each destination in the network ¡ The table is updated each time a change is detected in:

£ the link set, £ the neighbor set, £ the 2-‐hop neighbor set, £ the topology set, £ the Multiple Interface Association Information Base,

¡ The table is built using a shortest path algorithm 79







Zone Routing Protocol (ZRP)

¡ Hybrid reactive/proactive protocol £ Proactive procedure only to the nodes within a routine zone of radius ρ £ Reactive procedure to nodes beyond the routing zone by querying only a subset of

the network nodes

81 M. R. Pearlman, and Z. J. Haas, “Determining the Optimal Configuration for the Zone Routing Protocol,” IEEE JSAC, Aug. 1999, vol. 17, no. 8, pp. 1395-1414

Routing zone of radius = 2 hops

S

Neighbor node

Peripheral node

ZRP -‐ Routing Zones

¡ A routing zone is the collection of nodes which are within the zone radius of another node

¡ Zone radius of a node is defined in terms of number of hops from that node

¡ Each node has its own routing zone ¡ Routing zones of different nodes may overlap ¡ Each node maintains routing information to all nodes within its own routing zone

¡ The nodes uses a proactive mechanism to learn about the topology of its routing zone, this mechanism is called Intrazone Routing Protocol (IARP)

82

ZRP – Interzone Routine

¡ The Interzone Routing Protocol (IERP) is responsible for reactively discovering routes to destinations located beyond a node’s routing zone

¡ The Bordercast Resolution Protocol (BRP) allows the node to send messages only to its peripheral nodes £ Efficient querying of specific nodes rather than flooding the whole network £ Bordercasting can be implemented using efficient multicast techniques

¡ A single route query returns multiple route replies, which can be used to determine the best route based on relative quality

¡ Because the routing zones overlap, a node can be a member of many routing zones £ It is important to have a mechanism to detect duplicate route queries and reduce

excessive control traffic

83

ZRP – IERP (example)

q Source S needs to send a packet to destination D q S checks whether D is within its routing zone. If yes, S knows a path to D q If not S bordercasts a query to its peripheral nodes (C, G, and H) q These nodes, after verifying that D is not within their routing zones,

bordercast the query to their peripheral nodes q B, a peripheral node of H, recognizes D as being in its routing zone and

responds to the query indicating the path S→H →B →D

84

S B

Q

C

H

D F

E

G

Geographic routing -‐ GeoNet

¡ Geographic routing applied specifically to VANETs. Uses the geographic position and movement information of vehicles to route data packets.

¡ Each node maintains a location table including location related information for itself and a list of its neighbouring nodes.

¡ Position information, including speed and direction, exchanged in beacon packets

¡ Forwarding uses Greedy Perimeter Stateless Routing (GPSR) protocol ¡ Communication modes:

£ GeoUnicast – from a node to a known location £ GeoAnyCast – from a node to any node in a geographic area £ GeoBroadCast – from a node to all nodes in a geographic area £ Topo-‐Broadcast – from a node to all nodes a given number of hops away

85

Greedy Mode

¡ Nodes learn 1-‐hop neighbors’ positions from beaconing ¡ A node forwards packets to its neighbor closest to D ¡ Greedy traversal not always possible!

86

x is a local maximum to D; w and y are further from D

Recovery/Perimeter Mode

¡ Face traversal by right-‐hand rule

87

Walking sequence: F1 -> F2 -> F3 -> F4

x

y z

S

D

F1

F2

F3

F4

A

B

C

D

E

I1 I2

I3

Planarization

¡ Face traversal requires planar graph: cross edges result in routing loops

¡ GG and RNG planarization algorithms

¡ Their disadvantages £ Planarization overhead £ High hop count £ Unit disk assumption, GPS

accuracy, etc

88






Mobile and Wireless Networks -‐ Topic 3.E Mobile Ad Hoc Networks

DTN Quick history

¡ ~1998 Vint Cerf and various people at JPL started to work on Interplanetary Internet (IPN)

¡ Became clear (~2002) that its hard to do many experiments on the solar system

¡ Luckily the generalisation of an IPN also has terrestrial applications – generalised to Delay Tolerant Networking

¡ DARPA (US DoD) started funding (~2005) Disruption Tolerant Networking projects (~US$20M) £ DTN expanded whichever way you prefer

90

Delay-‐Tolerant Network (DTN)

¡ Store-‐carry-‐and-‐forward paradigm ¡ Overlays a protocol layer, called bundle layer, that it is meant to provide internetworking on heterogeneous networks operating on different transmission media

¡ These networks experience any combination of the following: £ Sparse connectivity £ Long or variable delay £ Intermittent connectivity £ Asymmetric data rate £ High latency £ High error rates £ No end-‐to-‐end connectivity

91

Delay-‐Tolerant Network (DTN)

¡ Application Domains £ Vehicular networks £ Underwater networks £ Wildlife tracking networks £ Rural area networks / Data MULEs £ Transient networks £ People (crowdsourcing) networks £ Disaster recovery networks £ Military tactical networks £ Interplanetary networks

92 92

Vehicular Delay-‐Tolerant Network (VDTN)

¡ VDTN architecture appears as a network architecture proposal based on the DTN architecture, that aims to provide innovative solutions for challenged vehicular communications

¡ Urban Scenario £ Disseminate information advertisements £ Disseminate safety related information £ Distribute multimedia content £ Monitoring networks to collect data £ …

93 93

Cooperation in DTN-‐Based Networks

¡ Cooperation is a key issue to the success of data communication in DTNs ¡ In a cooperative environment, network nodes collaborate with each other, storing and distributing bundles not only in their own interest, but also in the interest of other nodes £ This increases the number of possible transmission paths, improving the robustness

to failure of individual nodes

94

!

94

Cooperation in DTN-‐Based Networks

¡ In a non-‐cooperative environment, network nodes exhibit a selfish behavior £ This behavior can be caused by several reasons, such as, resource limitations (e.g.

storage, energy) or rogue operation (malicious behavior) £ This leads to degradation of the network performance

95 95

DTN Research Group

¡ DTNRG is an IRTF research group; the IRTF (http://www.irtf.org/) is the “research arm” of the IETF £ http://www.dtnrg.org/

¢ Specs, Code, Papers, Project links… £ IRTF: DTNRG is an open group – just get on the mailing list (dtn-‐interest) and off

you go...

¡ Two main protocols being developed: £ Bundle Protocol (BP) £ Licklider Transmission Protocol (LTP)

96

Bundle protocol

¡ The bundle protocol (BP) is the main focus of the work in DTNRG ¡ BP is a delay/disruption tolerant overlay network protocol ¡ Multiple implementations exist, some interop. happened in

Nov’06 and again (though more limited) in March ‘08

97

TKK DTN2 MITRE* BBN* GA Tech ION

Language C++ C++ C++ C++, Java C# C

Platform Symbian cell phone

MacOS and Linux on PC and (Nokia

770)

Linux on PC,

external router

Linux on PC,

external CL adapter

.NET on Win32 & Linux on PC, PDA

Linux on PC

Custody transfer P P P P P

Status rpts P P P P P

TCP CL P P P P

UDP CL P P P P P

DTN2 reference code is available from http://www.dtnrg.org/

BP documents

¡ Mature: £ DTN Architecture: RFC 4838

¢ Note: not really the architecture for all of DTN, but actually fairly specific to the bundle protocol

£ BP spec: RFC 5050 ¡ Maturing...

£ draft-‐irtf-‐dtnrg-‐bundle-‐security £ draft-‐irtf-‐dtnrg-‐sec-‐overview £ draft-‐irtf-‐dtnrg-‐prophet

¢ Co-‐authored by Anders Lindgren formerly of LTU £ draft-‐irtf-‐dtnrg-‐tcp-‐clayer

¡ Less mature... £ multicast, last-‐hop, header compression, retransmission

98

DTN and layering

¡ What layer is best to try tackle delay and/or disruption? £ No single answer, as usual

¡ BP chooses the overlay approach on the basis that highly challenged networks/nodes may have to use “strange” communications layers £ Original IPN concept of “regions” £ Late binding of names

99

Application

Bundle Endpoint

Transport (TCP)

Network (IP)

Bundle Endpoint

Transport (TCP)

Network (IP)

Application

Bundle Endpoint

Transport (SCTP)

Network (IP)

Bundle Endpoint

Transport (SCTP)

Network (IP)

Application

Bundle Endpoint

Transport (TCP)

Network (IP)

Bundle Endpoint

Transport (TCP)

Network (IP)

Application

Bundle Endpoint

Transport (SCTP)

Network (IP)

Bundle Endpoint

Transport (SCTP)

Network (IP)

Application

Bundle Endpoint

Transport (TCP)

Network (IP)

Application

Bundle Endpoint

Transport (TCP)

Network (IP)

Bundle Endpoint

Transport (TCP)

Network (IP)

Bundle Endpoint

Transport (TCP)

Network (IP)

Application

Bundle Endpoint

Transport (SCTP)

Network (IP)

Application

Bundle Endpoint

Transport (SCTP)

Network (IP)

Bundle Endpoint

Transport (SCTP)

Network (IP)

Bundle Endpoint

Transport (SCTP)

Network (IP)

Licklider Transmission Protocol (LTP)

¡ LTP is a point-‐to-‐point protocol for DTNs £ Designed as a BP convergence layer for deep space (v. high latency) links £ Think of it as somewhere from layer 2 up to maybe layer 4! £ Encoding is terse and binary £ LTP is highly stateful

¢ Needed to avoid negotiation exchanges

¡ Named for J.C.R. Licklider ¡ CCSDS have defined CFDP (CCSDS File Delivery Protocol) that is quite like LTP, but: £ LTP spec. is much less OSI-‐like

¢ “Internet” approach better for more open development environments £ CFDP security…hmm £ CCSDS: http://www.ccsds.org/

¡ So LTP is sort-‐of another “go” at CFDP in a more open development environment

100

LTP Documents

¡ draft-‐irtf-‐dtrng-‐ltp-‐motivation £ Background and reasons for…

¡ draft-‐irtf-‐dtnrg-‐ltp £ Core LTP protocol

¡ draft-‐irtf-‐drnrg-‐ltp-‐extensions £ Extensions (security)

¡ Documents are currently with the RFC editor £ Usual IRSG/IESG/IANA/RFC-‐ed procedural wrangling on-‐going

101

An LTP Session

102

Source Destination

Light TripTime

Data SegmentData SegmentData Segment (EOB)

Report Segment

Report Acknowledgement

LTP Layering

¡ LTP runs on top of some MAC layer or deep space lower layer ¡ LTP assumes lower layer “cues” are provided so that some infrastructure (e.g. ephemeris handler + scheduler or proximity detector) tells the stack when to expect to receive or transmit with a given peer

¡ Sessions/Segments £ A single “block” is sent per “session” using multiple “segments”

¢ Segment size is limited by the underlying MTU £ Session-‐ID is src-‐ID + number

¢ Recommended to use a (P)RNG for the number

¡ Red/green parts – Partial Reliability £ Data is ACKed (red) or not (green) £ Not ACKing is easier, but doesn't fulfill all appn. Requirements £ Red part first (if any), then green (if any) £ Each segment in a session is entirely red or entirely green

103

Mobility-‐assisted routing

¡ How data can be delivered? £ path between a source and a destination maybe always won’t exist

¡ Solution £ Traditional protocols: Internet (RIP, OSPF); Ad hoc (DSR, AODV) would fail £ Formerly, mobility viewed as evil; Now, it’s perfect £ Node mobility would be exploited to help deliver message (mobility-‐assisted or

store-‐carry-‐and-‐forward)

¡ Zhang, Z., “Routing in Intermittently Connected Mobile Ad Hoc Networks and Delay Tolerant Networks: Overview and Challenges,” IEEE Communications Surveys and Tutorials, 8(1), 2006.

104

Overview of Routing schemes

¡ Two categories £ auxiliary nodes assisted (ANA) routing

¢ a set of special auxiliary nodes needed to assist data delivery £  independent mobile nodes (IMN) routing

¢ there is not any additional participants in the deployment area ¢ message delivery achieved by node’s inherent movement ¢ Proactive & reactive

105

ANA routing scheme

¡ Auxiliary Nodes Assisted routing £ there are a set of special auxiliary nodes around the deployment area and are

responsible for carrying data between nodes

¡ Idea £ creating more contact opportunities actively

¡ Typical works £ Message Ferry [Zhao et al. 2004, 2005] £ ThrowBoxes [Zhao et al. 2006] £ Autonomous agents [Burns 2005] £ Courier nodes [Koc 2005], etc.

106

Message Ferrying

S

D

107

¡  Scheduled mobility: use special mobile nodes (Ferry nodes) and designed trajectory £ Suitable for in the presence of network partitions £ Controlled mobility £ Predetermined node trajectory

Ferry

Message Ferrying

¡ Determine the ferry routes: satisfy a required performance ¡ The problem: design optimal trajectories

108

S

D

Ferry

Ferry

Ferry

Ferry

DTN without Throwboxes

109

DTN with Throwboxes

110

IMN routing scheme

¡ Independent mobile nodes routing £ exploits existing node mobility to help deliver data, i.e., message delivery solely

relies on node’s inherent movement rather than any additional participants

¡ Idea £ a mobile node carries a packet for a period of time as part of realizing a path from

source to the destination

¡ Two categories £ Flooding-‐based £ Knowledge-‐based

111

Flooding-‐based Proposals

¡ Flooding: everyone gets a copy (Epidemic Routing -‐ Vahdat et al. ‘00): £ Note: optimal delay only when traffic is very low!

¡ Reducing the overhead of flooding £ Randomized Flooding (Y. Tseng et al. ’02):

¢ handover a copy with probability p < 1 £ Utility-‐based Flooding (A. Lindgren et al. ’03):

¢ handover a copy to a node with a utility at least Uth higher than current £ Can use p and Uth to tradeoff transmissions for delay, BUT:

112

Dilemma:

low p / high Uth? significant delay increase

high p / low Uth? degenerates to flooding

Epidemic Routing

¡ Give a message copy to every node encountered £ essentially: flooding in a disconnected context

113

A

C

B

D

D

E F

D

D

D

D

Generate too much transmissions!

Direct transmission

¡ Forward message only to its destination £ simplest strategy £ minimizes transmissions

114

S

C

B

D

D

E F

D

Randomized Flooding (Gossiping)

¡ “Spread” the message with a probability p ≤ 1 (Y. Tseng et al. ‘02) £ p = 1 è epidemic £ p = 0 è direct transmission

115

D

E

D

Outcome < p è Give a copy

D

Outcome > p è Don’t give copy

K-‐neighbor Epidemic

¡ Each node receiving a copy, can copy it again up to K times (spray and wait, Spyropoulos et al ’05)

116

F

E

D

D

G

J

K = 2

D

Already given 2 copies! Node E cannot fwd more

Utility-‐based Routing

117

(A. Lindgren et al. ‘03)

tX(Y): time since X last saw Y Indirect location information

l  diffused with node mobility

smaller timer ⇒ closer distance l  For most mobility models

A

D

B tB(D) = 100

t(D) = 0

t(D) = 26

t(D) = 68

tA(D) = 138

t(D) = 218

Last encounter timers

D D

Utility UX(Y) = f(tX(Y))

Policy: forward to B if UB(D) > UA(D) + Uth

Routing objective

¡ Performance metric £ Message delivery ratio

¢ The fraction of generated messages that are correctly delivered to the final destination within a given time period

£ Transmission delay ¢ The time from a message is generated through it is received by destination

£ Number of transmissions ¢ The number of message exchange occurred between two nodes

118

Date post:	01-Sep-2018
Category:	Documents
Upload:	phunglien
View:	218 times
Download:	0 times