Browse Prior Art Database

Method of Providing DiffServ-like QoS for Multicast MPLS Flows

IP.com Disclosure Number: IPCOM000004794D
Original Publication Date: 2001-May-29
Included in the Prior Art Database: 2001-May-29
Document File: 3 page(s) / 33K

Publishing Venue

Motorola

Related People

Vidya Narayanan: AUTHOR

Abstract

Method of Providing DiffServ-like QoS for Multicast MPLS Flows

This text was extracted from a Microsoft Word 97 document.
This is the abbreviated version, containing approximately 38% of the total text.

Method of Providing DiffServ-like QoS for Multicast MPLS Flows

By Vidya Narayanan

Introduction

X-Zone is a packet-switched system designed to carry voice and data from two-way radios, primarily for public safety systems. As most of the calls involve point-to-multipoint communication, multicast becomes the natural choice in the IP-based X-Zone architecture. QoS is one of the important services required in the X-Zone systems. Future X-Zone based systems might carry High Speed Data, which potentially have higher bandwidth and more stringent admission control and bandwidth management requirements.

Currently, the X-Zone transport is IP-based and admission control is done by the application (Zone Controller) and not by the network. The assumption is that the links would always be sized based on the worst-case minimum bandwidth required for voice calls, depending on available RF resources. However, with the introduction of High Speed Data applications, this may not be true any more. Also, it might become more desirable to perform some admission control in the network.

MPLS lends itself as a good candidate for study from a view of the next generation packet transport for X-Zone and HSD systems. MPLS offers better bandwidth management and admission control, along with a host of other advantages to carry voice and video. For use in future X-Zone or HSD systems, multicast support over MPLS must be defined. Also, there is a need to provide Quality of Service (QoS) for the multicast flows. QoS is essential for multicast flows in order to be deployed in our systems where we have delay-sensitive voice traffic.

Background

There are not many known ways of doing multicast over MPLS yet. Among the few that have been outlined, most of those do not work over all types of multicast routing protocols. Essentially, these solutions are not all transparent to the multicast routing protocol of choice and hence limit the choice of the multicast routing protocol in a given system. The problem primarily arises because MPLS aims at establishing an LSP (Label Switched Path), which is similar to a "tunnel", between the endpoints (sender and receiver), so that the data can all be label-switched instead of being routed. However, a tree is not always created in multicast prior to the arrival of traffic. Whether a multicast tree is created without traffic depends on the type of multicast routing protocol being used. Even if created, it is only done between the receiver(s) and a central distribution point. The "end-to-end" tree between the sender and receiver(s) cannot be created until the traffic is seen. Given this limitation, it is difficult to create an "end-to-end" LSP ahead of time for multicast. Most of the available approaches for multicast over MPLS involve some sort of signaling to get the LSP in place after the data packets are seen. This would mean that a few packets (depending on the rate of arrival of packets and the signaling involved) would be routed before label switching o...