1. Universidade do Minho A Framework for Multi-Class Based Multicast Routing TNC 2002 Maria João Nicolau, António Costa, Alexandre Santos {joao, costa, alex}@uminho.pt Universidade do Minho 5 June 2002

2. Universidade do Minho Outline Introduction: –Diffserv architecture and multicast: current situation –Why they don fit well: problem presentation and solution requirements Proposed Framework: –A model for multi-class based multicast routing –Multicast tree construction mechanism –Multiple trees for multiple classes –Support for different membership QoS requirements Discussion –Advantages and major expected improvements –Known issues and drawbacks Current and Future Work

3. Universidade do Minho Introduction: Multicast & QoS Multicast routing goal: However... –Multicast applications have requirements... since they are usually largely affected by bandwidth restrictions, packet losses and delays... Etc. –Multiple members with different requirements... Who should specify QoS requirements? Senders or Receivers? Or both? And when, since they join and leave at any moment…? Most are QoS sensitive, by nature Build a tree of nodes, joining multiple senders and receivers, that minimize packet replication inside network CBT, PIM-SM, MOSPF, etc

4. Universidade do Minho Introduction: current situation Many proposals, and some new protocols Most used strategy is Path Probing: –New member, in-tree node (or even both!), sends probe messages… over different possible routes… collecting information on path… –New member selects the one that satisfies its requirements (if any!) –Routing entries are then created over the selected path, connecting the new member to the tree… –Some resource reservation protocol may be used to preserve path quality QoSMIC, YAM, PTMR Better suited for integrated service approach

5. Universidade do Minho Introduction: current situation Due to simplicity and scalability features, a new class of service paradigm is emerging: –No per flow guaranties… only per class differentiation… –Packets are initially marked in one of the (few) classes available… –Every node, coherently inside a domain, gives different treatment to packets according only to its class… Difficulties: –Data packets are marked by sources…. How can receivers specify their own requirements? How can sources know how to mark? According to their requirements? Challenges: –Can routing help to provide class differentiation? –In conjugation with inside node mechanisms? Or by itself? Need to adequate multicast protocols to such environments...

6. Universidade do Minho Proposed framework One key idea (inspired on PIM-SM): Can it be done? –Multicast trees are usually build with unicast routing information –One unicast route per destination, means only one tree… –Need alternative (if any) unicast paths (according to class) –Routing algorithms, find shortest paths, according to some criteria they can find, coherently, more than one route if available… … perhaps according to each class quality of service metrics.. The usage of multiple trees, one per class of service Use both: shared and source distribution trees

7. Universidade do Minho Proposed framework Source joins Receiver joins Generate traffic towards a RP, marked in only one class! Class is selected according to its own requirements Before joining, no knowledge of group, no requirements Join all shared tree classes available… (rooted at RP) Initial period of membership used by receivers to know sources Source decides Receiver adjusts According to its own requirements, and after knowing sources, receiver try to receive in some other class Receiver explicitly join source(s) in desired classes Sources decide if they generate traffic marked in new class of service, since it might affect its service contract

8. Universidade do Minho Proposed framework Proposal is aligned with current IP multicast model: –Sources and receivers join and leave at any time… –No previous group membership knowledge is assumed… And it fits very well in class based environments… –… without breaking its inside domain simplicity principle Tree construction, however, as to be modified: –Per class treatment is, by definition, unidirectional… –Protocol must construct directed trees: from sources to receivers… –There is more than one way to do it… –Our approach is inspired in PIM-SIM RPF check technics must be avoided

9. Universidade do Minho Join to Shared Tree RP R S1 R R R S S S classe j classe i

10. Universidade do Minho Join to Shared Tree RP R S1 R R R S S S classe j classe i Two classes of service: i, j

11. Universidade do Minho Join to Shared Tree RP R S1 R R R S S S classe j classe i Two shared trees, rooted at RP

12. Universidade do Minho Join to Shared Tree RP R S1 R R R S S S classe j classe i Source marking for class i

13. Universidade do Minho Join to Shared Tree RP R S1 R R R S S S classe j classe i Source S1 marking for class j

14. Universidade do Minho Join to Shared Tree RP R S1 R R R S S S classe j classe i Receivers may receive i and j

15. Universidade do Minho Join to Shared Tree RP R S1 R R R S S S classe j classe i No packet duplications here: i from i-sources, j from j-sources

16. Universidade do Minho Join to Shared Tree RP R S1 R R R S S S classe j classe i New receiver joins group by sending join message to RP

17. Universidade do Minho Join to Shared Tree RP R S1 R R R S S S classe j classe i Shared Tree JoinRequest Join message: Follows best unicast path to RP!

18. Universidade do Minho Join to Shared Tree RP R S1 R R R S S S classe j classe i Shared Tree JoinRequest Join message: Dont generate state info at nodes!

19. Universidade do Minho Join to Shared Tree RP R S1 R R R S S S classe j classe i Join Ack Join Ack Ack messages, follow best unicast routes for each class!

20. Universidade do Minho Join to Shared Tree RP R S1 R R R S S S classe j classe i Join Ack Join Ack Install route entry At node!

21. Universidade do Minho Join to Shared Tree RP R S1 R R R S S S classe j classe i Join Ack Join Ack

22. Universidade do Minho Join to Shared Tree RP R S1 R R R S S S classe j classe i Join Ack Join Ack

23. Universidade do Minho Join to Shared Tree RP R S1 R R R S S S classe j classe i Join Ack

24. Universidade do Minho Join to Shared Tree RP R S1 R R R S S S classe j classe i

25. Universidade do Minho Join to Shared Tree RP R S1 R R R S S S classe j classe i After receiving S1 data packets, receiver decides to require i class

26. Universidade do Minho Join to Source Based Tree RP R S1 R R R S S S classe j classe i Source Tree JoinRequest

27. Universidade do Minho Join to Source Based Tree RP R S1 R R R S S S Join Ack classe j classe i

28. Universidade do Minho Join to Source Based Tree RP R S1 R R R S S S Join Ack classe j classe i

29. Universidade do Minho Join to Source Based Tree RP R S1 R R R S S S Prune classe j classe i Join Ack

30. Universidade do Minho Join to Source Based Tree RP R S1 R R R S S S Prune classe j classe i Join Ack Install route entry at node

31. Universidade do Minho Join to Source Based Tree RP R S1 R R R S S S Prune classe j classe i Join Ack Create entry, without that interface!

32. Universidade do Minho Join to Source Based Tree RP R S1 R R R S S S classe j classe i Join Ack

33. Universidade do Minho Join to Source Based Tree RP R S1 R R R S S S Join Ack classe j classe i

34. Universidade do Minho Join to Source Based Tree RP R S1 R R R S S S classe j classe i

35. Universidade do Minho Proposed Framework: major elements A Multicast protocol –Constructs directed trees, from tree roots to receivers… –Two type of trees: shared trees (rooted at RP) and source trees (rooted at sources) –Both receivers and sources can specify their requirements –Avoids initial negotiation A Unicast CoS routing –Traffic of different classes may follow different paths, inside the multi-class domain… –One route entry per class of service, if necessary… Joining those two pieces together – to achieve multi-class based multicast routing

36. Universidade do Minho Implementation Simulation was the first step: –Started with a PIM-SM implementation (close to) –Existing module in NS2 (ST), isnt close enough NS´s implementation is centralized It doesnt send control messages periodically Either Shared Trees or Sources Trees: – change from one to other, is done by an explicit command –Modified version of that implementation derived to current proposed multicast protocol: New tree construction mechanism was implemented Use of Join Acks was included –Using LS (Link State) module to achieve multi-class unicast routing: Modified algorithm to find one route per class Not the subject of this presentation…

37. Universidade do Minho Discussion Expected improvements: –Flexibility in element membership requirements Sources, receivers, or both… –Doesnt break current IP multicast model –A multicast approach that fits in class of service domains No per flow, or per path computation… no flooding… Multiple trees – one per class of service (using pre- computed unicast per class routes) –Routing differentiation can help in per class differentiation at domain level

38. Universidade do Minho Discussion Major known issues and drawbacks of this proposal: –An increase in the size of routing tables is expected… Because of different routes per different classes… On the limit, one routing entry per class –But, it is expected to have only a few (very small) number of classes traffic is distributed by different trees… by more nodes and links –Perhaps a grater join time latency for receivers… Join requests must reach tree roots (either RP or Sources) –But, That is the price to have directed trees! Directed trees are better in presence of link asymmetries A class of service environment is unidirectional …

39. Universidade do Minho Current Work Multicast routing: –Detailed protocol description available and stable –First prototype implementation is complete and is currently being tested on Network Simulator (NS2) In a standard DiffServ domain, with no routing differentiation mechanisms yet –More comparative results needed, but the protocol seems to be feasible and has expected behaviour; Unicast class of service based routing is essential: –Work is being carried on a proposal based on Link State –Implementation on NS2 completed. No results yet.

40. Universidade do Minho Future Work Extensive evaluation of the multicast routing protocol –several topologies, and group compositions… –comparative results with commonly used protocols Finish testing multi-class unicast proposal –clearly evaluate benefits of having routing differentiation –evaluate impact of using it in conjugation with commonly used inside node queue engineering methods… Evaluate the behaviour of the two pieces together… And.. –Conclude about advantages or disadvantages of having multi-class based multicast routing…