CS 5565 Network 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

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 R3R4 R1 R2 R3R4 duplicate creation/transmission 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 F 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 R i router with attached group member router with no attached group member link used for forwarding, i indicates order link added by algorithm LEGEND S: source CS 5565 Spring 2012

Reverse Path Forwarding result is a source-specific reverse shortest path tree (SPT) – unless costs are asymmetric router with attached group member router with no attached group 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 attached group member router with no attached group member prune message LEGEND links with multicast forwarding 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 attached group member router with no attached group member path order in which join messages generated LEGEND 1 R1 R2 R3 R4 R5 R6 R 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

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

Status of IP Multicast MBone exists PIM: ‘Protocol Independent Multicast’ protocol –alternative to DVMRP Sporadically deployed Has not taken off –Despite need (?)