A Framework for Multi-Class Based Multicast Routing
description
Transcript of A Framework for Multi-Class Based Multicast Routing
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”…