QoS Aware Multicast Management

From SimpleWiki
Jump to: navigation, search

IP multicast supports efficient communication services for applications in which an information source sends data to a group of receivers simultaneously. Despite enormous research efforts, global availability of IP multicast services is still a pie in the sky for most of the customers over the Internet, let alone those applications with QoS requirements. Ever since early 90’s, multicast routing with QoS awareness have been a hot research topic. However, most of the proposed routing algorithms are only confined to theoretical analysis, and it is difficult to deploy them due to the high computing and communication overhead. With the advent of the Differentiated Services (DiffServ) architecture, various attempts have been made towards seamless integration of multicast services with the DiffServ architecture. Compared to other QoS aware multicast schemes, the distinct advantage in this solution category is that, network providers are enabled to deploy QoS-aware multicast services on top of the existing DiffServ and IP multicast infrastructures. This aspect successfully bypasses dedicated network layer complexities, typically routing and signaling protocols for multicast QoS purposes. On the other hand, it has become a common belief that Traffic Engineering (TE) is an effective paradigm for guaranteeing end-to-end QoS with optimal network resource dimensioning. We envisage that sophisticated TE solutions in the management plane will also empower multicast service dimensioning with QoS requirements. Nevertheless, relevant research on multicast TE still remains in its preliminary stage compared to its unicast counterpart.

Aspects of this research field include:

  • To propose a scalable framework for seamless integration of Differentiated Services and IP multicast.
  • To propose novel multicast routing algorithms and protocols for supporting heterogeneous end-to-end QoS requirements across end users.
  • To design and evaluate efficient algorithms for both intra- and inter-domain multicast traffic engineering with QoS awareness.

This section of the Quality of Service Management Information Portal serves as a focal point for research related to multicast communication targeted mostly at achieving Quality of Service in this prominent networking paradigm.

Contents

General Description

IP Multicast vs. Source Specific Multicast (SSM)

IP Multicast SSM
Service model Open to any source Source specific
Group ID (*, G) - group addr. only (S, G) - source addr. + group addr.
Group management IGMPv2 IGMPv3
Join request Through RP first Directly to the source S
Remote source discovery MSDP Out of band
RFC number RFC 1112 RFC 3569


Multicast Routing

Protocol Independent Multicast – Sparse Mode (PIM-SM), is the de facto routing protocol for both IP multicast and SSM, where each group member explicitly joins the existing delivery tree via a specific path. To achieve this, every multicast group is associated with a Rendezvous Point (RP), which can be regarded as a merging point of senders and receivers. When a receiver wants to join a multicast group G, it issues an IGMP membership report to its directly attached Designated Router (DR), and the DR will send a (*, G) PIM-SM join request hop-by-hop back towards the RP of the group. At the source side, all senders for this group simply encapsulate their multicast data and unicast the packets towards the RP (after performing the registration), from where the multicast packets are decapsulated and disseminated to all the group members. Once the DR has received multicast packets from the RP, it may choose to switch from the current shared RP tree to source specific trees by re-directing its join requests away from the RP towards individual sources. This type of source-specific join contains the address tuple (S, G) instead of (*, G), where S is the address of the individual source.

In PIM-SM, multicast routers utilise the underlying unicast routing table to perform Reverse Path Forwarding (RPF), which checks whether or not an interface is closest to the root (source or RP) of the tree. If a multicast packet is not received from the interface on the shortest path with which unicast traffic is delivered back to the source, it is then discarded for avoiding traffic loops. On the other hand, PIM-SM does not rely on any specific unicast routing protocol for RPF checking. This means that any underlying unicast routing table can be directly used as a reference to decide the shortest path for PIM-SM routing.


DiffServ Aware Multicast

  • DSMCast

DSMCast is a scalable framework that aims at completely stateless multicast in DiffServ networks. The main idea of DSMCast is that both the destination address of individual receivers and their QoS requests are embedded in the header of group data packets, other than being maintained within the DiffServ domain. Packets are replicated where necessary at core routers and delivered to individual receivers based on their unicast destination address contained in the packet header. In this sense, DSMCast does not make used of class D address as in the traditional IP multicast service model.

  • QUASIMODO

In QUASIMODO, PIM-SM is selected as the reference multicast routing protocol. In order to accommodate QoS heterogeneity, DiffServ extensions have been made to PIM-SM join requests and the multicast forwarding table inside core routers. First, if a potential member decides to join the group with a certain QoS level, it should send out an adapted IGMP report (*, G, q) where q indicates the DiffServ service class this receiver desires to receive. Once the Designated Router receives the report, it will issue a (*, G, q) join request towards the RP, and this join request will explore a new tree branch that satisfies the requested QoS class.

  • Differentiated QoS Multicast (DQM)

Figure 1 presents the basic structure of a DQM tree with three QoS channels. In this tree, upstream links reflect the highest QoS channel requirements, while tree branches with lower QoS channels can be grafted from those with higher channels. This feature is similar to other schemes like MQ and QUASIMODO. However, since QoS information has been embedded into the multicast class D address, as in QSSM, the maintenance of a DQM tree is achieved exclusively by using group states, which also conforms to the conventional SSM model. Take Figure 1 as an example: we can see that individual QoS channels are encoded with SSM group addresses respectively, e.g., G3 identifies Gold service, G2 for Silver service, etc. Tree branches with (S, G1) state can be grafted from those with either (S, G2) or (S, G3) states, which implies that Bronze tree branches are allowed to be extracted from Gold and Silver ones, while Silver branches can only be extracted from Gold ones.

Mcast-fig1.gif
Figure 1. Illustration on DQM


Multicast Traffic Engineering

  • MPLS Based Multicast Traffic Engineering

Despite the progress for unicast services, traffic engineering for multicast flows remains largely a dark area till now. In the past few years, MPLS-based multicast TE has become a subject of interest, where point-to-multipoint LSPs are explicitly constructed. The mathematical problem formulation is often related to the Steiner tree problem for minimising traffic delivery cost.

  • IP Based Multicast Traffic Engineering

The basic idea of this approach is to convert engineered multicast trees into shortest path trees with respect to a set of optimized link weights. The main advantage in this approach is that, legacy IP routers are able to compute engineered multicast trees by simply applying the Dijkstra’s shortest path algorithm with the optimized and pre-configured link weights, so that there is no need for setting up dedicated MPLS tunnels. Figure 2 provides a simple example on how this can be implemented. We assume that node A is the ingress router of group X that contains designated nodes E, F and G. If PIM-SM performs conventional hop-count based shortest path (SP) routing, the total bandwidth consumed is 6 units (1 unit for each on-tree link), as shown in Figure 2(a). By setting the link weight according to Figure 2(b), the shortest path tree is in effect an optimal Steiner tree in terms of hop counts, which consumes only 4 units of bandwidth. Furthermore, if the end-to-end delay requirement from individual group members is maximum 3 hops, a feasible solution is shown in Figure 2(c) represented with another set of link weights.

Mcast-fig2.gif
Figure 2. A simple example of IP based multicast traffic engineering

Publications

  • G. Bianchi et al, "QUASIMODO: QUAlity of ServIce-aware Multicasting Over DiffServ and Overlay Networks," IEEE Network, special issue on multicasting, pp. 38-45 Jan/Feb. 2003
  • S. Blake et al, "An Architecture for Differentiated Services," RFC 2475, Dec. 1998
  • R. Bless, K. Wehrle, "IP multicast in Differentiated Services Networks," RFC 3754, Apr. 2004
  • S. Chen et al, "A QoS-aware Multicast Routing Protocol," Proc. IEEE INFOCOM, Vol. 3, pp. 1594-1603, 2000
  • S. Cheung et al, "On the Use of Destination Set Grouping to Improve Fairness in Multicast Video Distribution," Proc. IEEE INFOCOM, pp. 553-560, 1996
  • S. Deering et al, "Host Extensions for IP Multicasting," RFC 1112, Aug. 1989
  • C. Diot et al, "Deployment Issues for the IP Multicast Service and Architecture," IEEE Network, pp. 78-88, Jan./Feb. 2000
  • M. Faloutsos et al, "QoSMIC: Quality of Service sensitive Multicast Internet Protocol," Proc. ACM SIGCOMM, pp. 144-153, 1998
  • F. Faucheur, W. Lai, "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering," RFC 3564, Jul. 2003
  • B. Fenner et al, "Multicast Source Discovery Protocol (MSDP)," RFC 3618, Oct. 2003
  • H. W. Holbrook, D. R. Cheriton, "IP Multicast Channels: EXPRESS Support for Large-scale Single-source Applications," Proc. ACM SIGCOMM 1999
  • M. Kodialam et al, "Online Multicast Routing with Bandwidth Guarantees: A new Approach Using Multicast Network Flow," IEEE/ACM Trans. on Networking, Vol. 11, No. 4, pp. 676-686, 2003
  • Z. Li, P. Mohapatra, "QoS-aware multicasting in DiffServ domains," Proc. IEEE GLOBECOM, Vol. 3, pp. 2118-2122, 2002
  • C. P. Low, X. Song, "On finding feasible solutions for the delay constrained group multicast routing problem," IEEE Trans. on Computers, Vol. 51, Issue 5, pp 581-588, 2002
  • D. Ooms et al, "Overview of IP Multicast in a Multi-Protocol Label Switching (MPLS) Environment," RFC 3353 August 2002
  • Striegel, G. Manimaran, "A Scalable Approach for DiffServ Multicasting," Proc. IEEE ICC, Vol. 8, pp. 2327-2331, 2001
  • Wang, J. Hou, "QoS-Based Multicast Routing for Distributing Layered Video to Heterogeneous Receivers in Rate-based Networks," Proc. IEEE INFOCOM, Vol. 2, pp. 480-489, 2001
  • N. Wang and G. Pavlou, "An Efficient IP Based Approach for Multicast Routing Optimisation in Multi-homing Environments," Proc. Euro-NGI Conference on Next Generation Internet Design and Engineering (NGI) 2006, pp379-386
  • N. Wang and G. Pavlou, "An Overlay Framework for Provisioning Differentiated Services in Source Specific Multicast," Computer Networks (Elsevier), Vol. 44(4) 2004 pp. 481-497
  • Y. Wang et al, "Internet Traffic Engineering without Full Mesh Overlaying," Proc. IEEE INFOCOM, Vol. 1, pp. 565-571, 2001
  • S. Yan et al, "QoS-aware multicast routing for the Internet: the design and evaluation of QoSMIC", IEEE/ACM Transactions on Networking, Vol. 10, Issue 1, pp. 54-66, Feb. 2002
  • B.Yang, P. Mohapatra, "Multicasting in Differentiated Service Domains," Proc. IEEE GLOBECOM, Vol. 3, pp. 2074-2078, 2002
  • Yang et al, "MQ: An Integrated Mechanism for Multimedia Multicasting," IEEE Trans. on Multimedia, Vol. 3, No. 1., pp. 82-97, 2001

Related Links

Dissemination

The list of journals, conferences and technical societies related to multicast communication does not mean to be exhaustive rather it is indicative. For additions/updates please contact the webmaster.

Journals

Major Conferences

Technical Societies

Software/Tools

Personal tools