Project DescriptionSeveral evolving applications like WWW, video/audio on-demand services, and teleconferencing consume a large amount of network bandwidth. Multicasting is a useful operation for supporting such applications. Using the multicast services, data can be sent from a source to several destinations by sharing the link bandwidth. But multicast suffers from the scalability problem. Indeed, a multicast router should keep forwarding state for every multicast tree passing through it. The number of forwarding states grows with the number of groups. Besides, MPLS has emerged as an elegant solution to meet the bandwidth-management and service requirements for next generation Internet protocol (IP) based backbone networks. We think that multicast and MPLS are two complementary technologies and merging these two technologies where multicast trees are constructed in MPLS networks will enhance performance and present an efficient solution for multicast scalability and control overhead problems. In this section, we will briefly present MPLS, multicast and then the multicast scalability problem. We present here a new approach to construct multicast trees in MPLS networks. This approach utilizes MPLS LSPs between multicast tree branching node routers in order to reduce forwarding states and enhance scalability. In our approach only routers that are acting as multicast tree branching node for a group need to keep forwarding state for that group. All other non-branching node routers simply forward data packets over traffic engineered unicast routes using MPLS LSPs. We can deduce that our approach can be largely deployed because it uses for multicast traffic the same unicast MPLS forwarding scheme. We briefly discuss MPLS, the multicast scalability problem, merging the two technologies, related works and different techniques for forwarding state reduction. We present improvements to MMT protocol and we evaluate it in term of scalability and efficiency. Finally, we present simulation results to validate our evaluation and we conclude that the MMT protocol (and it's extension MMT2) seems promising and well adapted to a possible implementation of multicast traffic engineering in the network. 
Related work Chapter 4
of PHD
Thesis (english version of principal ideas of this chapter is
available here)
:
In plus to MMT, we suppose that some routers in the network can not
support mixed routing. We solve the mixed routing problem by using a
double level of labels while preserving the MMT protocol principles of
operation. The label of the lower level is a unique label representing
a channel (S;G). A label (belonging to a label interval reserved to the
MMT2 protocol) is allotted to the channel (S;G) at the reception by the
NIMS of the join messages for this channel. This label identifes the
channel in the domain managed by the NIMS. This label could be
different from one domain to another. The NIMS informs all branching
node routers about this label as well as the labels corresponding to
the next branching node routers for this channel. An extension of the
branch message is necessary to carry the new information. The label
corresponding to the channel (S;G) is added to the multicast packet at
the domain entry, the LSR ingress of the domain adds also the labels of
the higher level which corresponds to the next branching node routers
for the channel. In intermediate routers, those who are not branching
node routers, the packet is analyzed according to the entering label
placed in top of the label stack, label which will be replaced by an
outgoing label as in unicast MPLS. When the packet arrives to an
intermediate branching node router, the label of the higher level is
removed, the label identifying of the channel is treated and the new
labels which corresponds to the next branching node routers are added
(cf. gure 2). This operation is repeated until the arrival of the
packet to the egress router. All the labels are thus popped and again
the packet is sent towards the ingress routers of other domains or
directly towards the destinations belonging to sub-networks of the
egress routers.
The MMT2 protocol uses also the aggregated trees. Indeed, eue to the limited number of labels, MMT2 calculates only the aggregated trees. We choose, like Aggregated multicast, that two channels will be associated to the same aggregated tree in a domain if the tree calculated for the first channel has exactly the same branches as the tree calculated for the second channel in that domain. Thus, the NIMS can associate several channels to the same aggregated tree, in order to limit the use of labels in the domain and to reduce even the routing states to be stored at the branching node routers.
Publications
MMT Simulation Project
page (by the DESS-ISA students in Rennes university)
MMT MMT Linux implementation
page (by the DESS-ISA students in Rennes university-2005)
Simulation Files
|
|
Home | Last updated : 11 Avril 2005 |