Univ

ers

idade d

o M

inho

Univ

ers

idade d

o M

inho

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 Minho5 June 2002

Univ

ers

idade d

o M

inho

Univ

ers

idade d

o M

inho

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

Univ

ers

idade d

o M

inho

Univ

ers

idade d

o M

inho

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

Univ

ers

idade d

o M

inho

Univ

ers

idade d

o M

inho

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

Univ

ers

idade d

o M

inho

Univ

ers

idade d

o M

inho

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

Univ

ers

idade d

o M

inho

Univ

ers

idade d

o M

inho

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

Univ

ers

idade d

o M

inho

Univ

ers

idade d

o M

inho

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

Univ

ers

idade d

o M

inho

Univ

ers

idade d

o M

inho

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

Univ

ers

idade d

o M

inho

Univ

ers

idade d

o M

inho

Join to Shared Tree

RP

R

S1

R

R

R

S

S

S

classe jclasse i

Univ

ers

idade d

o M

inho

Univ

ers

idade d

o M

inho

Join to Shared Tree

RP

R

S1

R

R

R

S

S

S

classe jclasse i

Two classes of service: i, j

Univ

ers

idade d

o M

inho

Univ

ers

idade d

o M

inho

Join to Shared Tree

RP

R

S1

R

R

R

S

S

S

classe jclasse i

Two shared trees, rooted at RP

Univ

ers

idade d

o M

inho

Univ

ers

idade d

o M

inho

Join to Shared Tree

RP

R

S1

R

R

R

S

S

S

classe jclasse i

Source marking for class i

Univ

ers

idade d

o M

inho

Univ

ers

idade d

o M

inho

Join to Shared Tree

RP

R

S1

R

R

R

S

S

S

classe jclasse i

Source S1marking for class j

Univ

ers

idade d

o M

inho

Univ

ers

idade d

o M

inho

Join to Shared Tree

RP

R

S1

R

R

R

S

S

S

classe jclasse i

Receivers may receive i and j

Univ

ers

idade d

o M

inho

Univ

ers

idade d

o M

inho

Join to Shared Tree

RP

R

S1

R

R

R

S

S

S

classe jclasse i

No packet duplications here:i from i-sources, j

from j-sources

Univ

ers

idade d

o M

inho

Univ

ers

idade d

o M

inho

Join to Shared Tree

RP

R

S1

R

R

R

S

S

S

classe jclasse i

New receiver joins group by sending join

message to RP

Univ

ers

idade d

o M

inho

Univ

ers

idade d

o M

inho

Join to Shared Tree

RP

R

S1

R

R

R

S

S

S

classe jclasse i

Shared TreeJoinRequest

Join message:Follows best

unicast path to RP!

Univ

ers

idade d

o M

inho

Univ

ers

idade d

o M

inho

Join to Shared Tree

RP

R

S1

R

R

R

S

S

S

classe jclasse i

Shared TreeJoinRequest

Join message:Don’t generate

state info at nodes!

Univ

ers

idade d

o M

inho

Univ

ers

idade d

o M

inho

Join to Shared Tree

RP

R

S1

R

R

R

S

S

S

classe jclasse i

JoinAck

JoinAck

Ack messages, follow best

unicast routes for each class!

Univ

ers

idade d

o M

inho

Univ

ers

idade d

o M

inho

Join to Shared Tree

RP

R

S1

R

R

R

S

S

S

classe jclasse i

JoinAck

JoinAck

Install route entry At node!

Univ

ers

idade d

o M

inho

Univ

ers

idade d

o M

inho

Join to Shared Tree

RP

R

S1

R

R

R

S

S

S

classe jclasse i

JoinAck

JoinAck

Univ

ers

idade d

o M

inho

Univ

ers

idade d

o M

inho

Join to Shared Tree

RP

R

S1

R

R

R

S

S

S

classe jclasse i

JoinAck

JoinAck

Univ

ers

idade d

o M

inho

Univ

ers

idade d

o M

inho

Join to Shared Tree

RP

R

S1

R

R

R

S

S

S

classe jclasse i

JoinAck

Univ

ers

idade d

o M

inho

Univ

ers

idade d

o M

inho

Join to Shared Tree

RP

R

S1

R

R

R

S

S

S

classe jclasse i

Univ

ers

idade d

o M

inho

Univ

ers

idade d

o M

inho

Join to Shared Tree

RP

R

S1

R

R

R

S

S

S

classe jclasse i

After receiving S1 data packets,

receiver decides to require i class

Univ

ers

idade d

o M

inho

Univ

ers

idade d

o M

inho

Join to Source Based Tree

RP

R

S1

R

R

R

S

S

S

classe jclasse i

Source Tree JoinRequest

Univ

ers

idade d

o M

inho

Univ

ers

idade d

o M

inho

Join to Source Based Tree

RP

R

S1

R

R

R

S

S

S

Join Ack

classe jclasse i

Univ

ers

idade d

o M

inho

Univ

ers

idade d

o M

inho

Join to Source Based Tree

RP

R

S1

R

R

R

S

S

S

Join Ack

classe jclasse i

Univ

ers

idade d

o M

inho

Univ

ers

idade d

o M

inho

Join to Source Based Tree

RP

R

S1

R

R

R

S

S

S

Prune <s1,i>

classe jclasse i

Join Ack

Univ

ers

idade d

o M

inho

Univ

ers

idade d

o M

inho

Join to Source Based Tree

RP

R

S1

R

R

R

S

S

S

Prune <s1,i>

classe jclasse i

Join Ack

Install <s1,i> route entry at

node

Univ

ers

idade d

o M

inho

Univ

ers

idade d

o M

inho

Join to Source Based Tree

RP

R

S1

R

R

R

S

S

S

Prune <s1,i>

classe jclasse i

Join Ack

Create <s1,i> entry, without that interface!

Univ

ers

idade d

o M

inho

Univ

ers

idade d

o M

inho

Join to Source Based Tree

RP

R

S1

R

R

R

S

S

S

classe jclasse i

Join Ack

Univ

ers

idade d

o M

inho

Univ

ers

idade d

o M

inho

Join to Source Based Tree

RP

R

S1

R

R

R

S

S

S

Join Ack

classe jclasse i

Univ

ers

idade d

o M

inho

Univ

ers

idade d

o M

inho

Join to Source Based Tree

RP

R

S1

R

R

R

S

S

S

classe jclasse i

Univ

ers

idade d

o M

inho

Univ

ers

idade d

o M

inho

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”

Univ

ers

idade d

o M

inho

Univ

ers

idade d

o M

inho

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…

Univ

ers

idade d

o M

inho

Univ

ers

idade d

o M

inho

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

Univ

ers

idade d

o M

inho

Univ

ers

idade d

o M

inho

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 …

Univ

ers

idade d

o M

inho

Univ

ers

idade d

o M

inho

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.

Univ

ers

idade d

o M

inho

Univ

ers

idade d

o M

inho

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”…