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
- Related Links
- Technical Societies
- IP Multicast vs. Source Specific Multicast (SSM)
- 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 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.
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.
- Multicast Traffic Engineering
(1) 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.
(2) 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.