CS 5565Network Architecture and

Protocols

Godmar Back

Lecture 22

Announcements

• Project 2B due in 2 parts• Extra Credit Opportunities:

– Expand simulator (and your implementation) to introduce multiple link failures and link resurrection

CS 5565 Spring 2012

CS 5565 Spring 2012

Other Routing Protocols

• Ad-hoc Routing • Broadcast Routing• Multicast Routing

AODV

CS 5565 Spring 2012

Ad Hoc Routing

• Suppose routers can join & leave network at will

• Example: multiple wireless PCs with no base station

• AODV (Ad-Hoc On-Demand Distance Vector) Routing– “on-demand” compute routes only when

needed

CS 5565 Spring 2012

AODV

• Suppose A wants to know route to I– Starts broadcasting route requests

CS 5565 Spring 2012

AODV: Packet Types

• Sequence numbers used to weed out duplicates & decide on age of routes

• Hop counts to learn length of routes

Route Request

Route Reply

CS 5565 Spring 2012

AODV (cont’d)

• To limit load, broadcast scope is limited– Using IP TTL (AODV runs over IP!)

• To keep up with changes, nodes monitor traffic passing through them and inform neighbors (back-propagate) when links fail

• Difference to classic DV routing:– No periodic DV broadcasts to neighbors –

routes are learned only when needed

CS 5565 Spring 2012

(a) (b)

R1

R2

R3 R4

R1

R2

R3 R4

duplicatecreation/transmissionduplicate

duplicate

Broadcast Routing

• Motivation:– Use in-network duplication (b) rather than

source-duplication (a)

CS 5565 Spring 2012

Broadcast Routing (2)

• Simplest approach: simple flooding– Forward every packet from every link to all

other links every time– Inefficient, loops, “broadcast storms”

• Sequence-number controlled flooding– Only forward new packets to all other links

CS 5565 Spring 2012

A

B

G

D

E

C

F

Reverse Path Forwarding

• Only forward packets from link that lies on shortest path to the source– Assume unicast

routing has run & every node knows shortest path to source

CS 5565 Spring 2012

A

B

G

D

E

C

F

A

B

G

D

E

C

F

Broadcast using spanning tree

• Same spanning tree can be used for all sources!

CS 5565 Spring 2012

A

B

G

D

E

C

F1

2

3

4

5

A

B

G

D

E

C

F

Spanning Tree Construction

• Center-based: all nodes send “tree-join” message to known or elected center node

Multicast Routing

• Goal: find a tree (or trees) connecting routers having local mcast group members – tree: not all paths between routers used– source-based: different tree from each sender to rcvrs– shared-tree: same tree used by all group members

Shared tree Source-based trees

CS 5565 Spring 2012

Shortest Path Tree• mcast forwarding tree: tree of shortest

path routes from source to all receivers– Dijkstra’s algorithm

R1

R2

R3

R4

R5

R6 R7

21

6

3 4

5

i

router with attachedgroup member

router with no attachedgroup member

link used for forwarding,i indicates order linkadded by algorithm

LEGENDS: source

CS 5565 Spring 2012

Reverse Path Forwarding

• result is a source-specific reverse shortest path tree (SPT) – unless costs are asymmetric

router with attachedgroup member

router with no attachedgroup member

datagram will be forwarded

LEGEND

R1

R2

R3

R4

R5

R6 R7

S: source

datagram will not be forwarded

CS 5565 Spring 2012

Reverse Path Forwarding: Pruning

• no need to forward datagrams down subtrees with no group members

• “prune” msgs sent upstream by router with no downstream group members

router with attachedgroup member

router with no attachedgroup member

prune message

LEGEND

links with multicastforwarding

R1

R2

R3

R4

R5

R6 R7

S: source

P

P

P

CS 5565 Spring 2012

Shared-Tree: Steiner Tree

• Steiner Tree: minimum cost tree connecting all routers with attached group members

• problem is NP-complete (if intermediate nodes must be found)– excellent heuristics exists

• not used in practice:– computational complexity– information about entire network needed– monolithic: rerun whenever a router needs to

join/leave

CS 5565 Spring 2012

Center-Based trees

• single delivery tree shared by all• one router identified as “center” of tree• to join:

– edge router sends unicast join-msg addressed to center router

– join-msg “processed” by intermediate routers and forwarded towards center

– join-msg either hits existing tree branch for this center, or arrives at center

– path taken by join-msg becomes new branch of tree for this router

CS 5565 Spring 2012

Center-based Trees

Suppose R6 chosen as center:

router with attachedgroup member

router with no attachedgroup member

path order in which join messages generated

LEGEND

1

R1

R2

R3

R4

R5

R6 R7

2

3

1

CS 5565 Spring 2012

Internet Multicasting Routing: DVMRP

• DVMRP: distance vector multicast routing protocol, RFC1075

• flood and prune: reverse path forwarding, source-based tree– RPF tree based on DVMRP’s own routing tables

constructed by communicating DVMRP routers – no assumptions about underlying unicast– initial datagram to mcast group flooded everywhere

via RPF– routers not wanting group: send upstream prune

msgs

CS 5565 Spring 2012

DVMRP: continued…• soft state: DVMRP router periodically (1 min.)

“forgets” branches are pruned: – mcast data again flows down unpruned branch– downstream router: reprune or else continue to

receive data

• routers can quickly regraft to tree – following IGMP join at leaf

• odds and ends– commonly implemented in commercial routers– Mbone routing done using DVMRP

CS 5565 Spring 2012

CS 5565 Spring 2012

IGMP• Internet Group Management Protocol• Local protocol used by hosts to inform

their routers that they’d like to join a mcast group– MCast addresses are 224.x.x.x

• 28bits for groups, address indirection

• Simple protocol– Join– Leave (optional)– Membership Query (still interested?)

Tunneling

Q: How to connect “islands” of multicast routers in a “sea” of unicast routers?

mcast datagram encapsulated inside “normal” (non-multicast-addressed) datagram

normal IP datagram sent thru “tunnel” via regular IP unicast to receiving mcast router which undoes encapsulation

physical topology logical topology

CS 5565 Spring 2012

CS 5565 Spring 2012

Status of IP Multicast

• MBone exists• PIM: ‘Protocol Independent Multicast’

protocol– alternative to DVMRP

• Sporadically deployed• Has not taken off

– Despite need (?)