CS 5565 Network Architecture and Protocols

1. CS 5565Network Architecture and Protocols Godmar Back Lecture 22

2. 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

3. Other Routing Protocols • Ad-hoc Routing • Broadcast Routing • Multicast Routing CS 5565 Spring 2012

4. AODV

5. 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

6. AODV • Suppose A wants to know route to I • Starts broadcasting route requests CS 5565 Spring 2012

7. AODV: Packet Types Route Request • Sequence numbers used to weed out duplicates & decide on age of routes • Hop counts to learn length of routes Route Reply CS 5565 Spring 2012

8. 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

9. duplicate creation/transmission duplicate duplicate (b) (a) R2 R3 R4 R2 R3 R4 R1 R1 Broadcast Routing • Motivation: • Use in-network duplication (b) rather than source-duplication (a) CS 5565 Spring 2012

10. 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

11. A D G B 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

12. A A D D G G E B B E F F C C Broadcast using spanning tree • Same spanning tree can be used for all sources! CS 5565 Spring 2012

13. 3 4 2 5 1 A D G A D B E G F C B E F C Spanning Tree Construction • Center-based: all nodes send “tree-join” message to known or elected center node CS 5565 Spring 2012

14. Source-based trees Shared tree 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 CS 5565 Spring 2012

15. 1 i 5 4 3 6 2 Shortest Path Tree • mcast forwarding tree: tree of shortest path routes from source to all receivers • Dijkstra’s algorithm S: source LEGEND R1 R4 router with attached group member R2 router with no attached group member R5 link used for forwarding, i indicates order link added by algorithm R3 R7 R6 CS 5565 Spring 2012

16. S: source R1 R4 R2 R5 R3 R7 R6 Reverse Path Forwarding LEGEND router with attached group member router with no attached group member datagram will be forwarded datagram will not be forwarded • result is a source-specific reverse shortest path tree (SPT) – unless costs are asymmetric CS 5565 Spring 2012

17. S: source R1 R4 R2 P R5 P R3 R7 R6 Reverse Path Forwarding: Pruning LEGEND • 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 P prune message links with multicast forwarding CS 5565 Spring 2012

18. 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

19. 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

20. R1 R4 3 R2 2 R5 R3 1 R7 R6 Center-based Trees Suppose R6 chosen as center: LEGEND router with attached group member router with no attached group member 1 path order in which join messages generated CS 5565 Spring 2012

21. 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

22. 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

23. 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?) CS 5565 Spring 2012

24. Tunneling Q: How to connect “islands” of multicast routers in a “sea” of unicast routers? logical topology physical topology • 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 CS 5565 Spring 2012

25. Status of IP Multicast • MBone exists • PIM: ‘Protocol Independent Multicast’ protocol • alternative to DVMRP • Sporadically deployed • Has not taken off • Despite need (?) CS 5565 Spring 2012