QoS Aware Multicast Management

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. Related research has ben classified into the following categories:

• General Description
• Tutorials/Presentations
• Publications
• Related Links
• Dissemination
  • Journals
  • Conferences
  • Technical Societies
• Software/Tools

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

(1) 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.

(2) 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.

(3) 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.