QoS support for Multicast

IP Multicast is a requirement, not an option, if the Internet is going to scale. It is a natural compliment to QoS for support of one-to-many audio and video "broadcasts" over the Internet, so support for multicast has always been a fundamental requirement in the design of QoS protocols. Although allowances have always been made in the initial designs of QoS protocols, full support of QoS for multicast is still not standardized or fully understood yet. There are a number of issues involved with multicast support that we describe here, as we summarize the current state of support of QoS for multicast for each of the QoS protocols we've focused on in this paper.

RSVP support for Multicast

As we mentioned earlier in this paper, the initial design for RSVP and Integrated Services took IP Multicast support into consideration by making the reservations receiver-based. One aspect of multicast that makes it a challenge to support is that the receivers that comprise a multicast group may vary widely in their capabilities with regard to the downstream bandwidth available to them. This heterogeneous receivership is likely to have a wide variety of reservation requests, specific to the path their data will flow downstream. Hence, it is essential that each receiver be allowed to specify a different reservation according to its needs.

Another aspect of the Integrated Services design relevant to multicast in general and heterogeneous receivers specifically is the ability to set filter specifications. By allowing this, hierarchical data may be possible. Hierarchically encoded data streams are designed so that when less bandwidth is available, receivers can still get a usable signal, though with lower fidelity. Filter specifications could reserve bandwidth for the portion of the stream a lower-bandwidth receiver is capable of receiving.

The great challenge that RSVP presents and which is not yet fully understood deals with ordering and merging reservations [IntServ Service Spec]. As yet no standards are published, but there is at least one simulation reference [RSVP Multicast] and an examination of some of the problems possible with multicast reservation mergers [RSVP Killers].

DiffServ support for Multicast

The relative simplicity of Differentiated Services makes it a better (easier and more scalable) fit for multicast support, but there are still challenges involved. Specifically, estimating the traffic is a challenge due to the dynamic nature of group memberships and to the fact that although a multicast distribution tree may have a single ingress point, it will often have multiple egress points (which can change as membership changes). Work is still underway in this area.

MPLS support for Multicast

MPLS support for Multicast is a subject of intense development effort, but no standards have emerged as yet. There are a number of relevant Internet Drafts on the subject of IP Multicast support in MPLS networks and multicast traffic engineering [MPLS Multicast].

SBM support for Multicast

SBM has explicit support for multicast, and as described previously, SBM utilizes IP Multicast as part of the protocols. There are no issues with SBM multicast support assuming support for IGMP in SBM-enabled switches, so multicast traffic is only forwarded to segments where group members reside.

Wed, 23 July, 2003 13:07