A Framework for Multi-Class Based Multicast Routing

1. 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. 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. 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…? Build a “tree” of nodes, joining multiple senders and receivers, that minimize packet replication inside network CBT, PIM-SM, MOSPF, etc Most are QoS sensitive, by nature

4. 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. 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 protocolsto such environments...

6. 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. Proposed framework Source joins • Generate traffic towards a RP, marked in only one class! • Class is selected according to its own requirements Receiver joins • 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 • 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 Receiver adjusts Source decides • Sources decide if they generate traffic marked in new class of service, since it might affect its service contract

8. 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. Join to Shared Tree S S S1 S RP R R classe i R R classe j

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

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

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

13. Join to Shared Tree Source S1marking for class j S S S1 S RP R R classe i R R classe j

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

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

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

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

18. Join to Shared Tree Join message: Don’t generate state info at nodes! S S S1 S RP Shared Tree JoinRequest R R classe i R R classe j

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

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

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

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

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

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

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

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

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

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

29. classe i classe j Join to Source Based Tree S S S1 S Prune <s1,i> RP Join Ack R R R R

30. classe i classe j Join to Source Based Tree S S S1 Install <s1,i> route entry at node S Prune <s1,i> RP Join Ack R R R R

31. classe i classe j Join to Source Based Tree Create <s1,i> entry, without that interface! S S S1 S Prune <s1,i> RP Join Ack R R R R

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

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

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

35. 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. Implementation • Simulation was the first step: • Started with a PIM-SM implementation (close to) • Existing module in NS2 (ST), isn’t close enough • NS´s implementation is centralized • It doesn’t 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. Discussion • Expected improvements: • Flexibility in element membership requirements • Sources, receivers, or both… • Doesn’t 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. 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. 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. 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”…