1. Field of the Present Invention
Embodiments of the present invention relate, in general, to networking. More specifically, the embodiments of the present invention relate to a method and a system for reducing latency in a multicast content-delivery network.
2. Description of the Background Art
In a typical content-delivery network, sources transmit streaming content, such as a television channel instance, to selected multiple subscribers that have joined a multicast group. As used herein, subscriber refers to the device or mechanism that presents the streaming content in a human perceptible manner. Each source has to generate only a single data stream and a multicast-enabled router forwards a multicast to a particular network only if there are multicast receivers on that network.
Membership in a multicast group is dynamic; hosts can join and leave at any time. There is no restriction on the location or number of members in a multicast group. A host can be a member of more than one multicast group at a time. How active a multicast group is and what members it has can vary from group to group and from time to time. A multicast group can be active for a long time, or it may be very short-lived. Membership in a group can change constantly. A group that has members may have no activity.
Routers executing a multicast routing protocol, such as Protocol-Independent Multicast (PIM), maintain forwarding tables to forward multicast datagrams. Routers use Internet Group Management Protocol (IGMP) to learn whether members of a group are present on their directly attached subnets. Hosts join multicast groups by sending IGMP report messages.
Many multimedia applications involve multiple participants. IP multicast is naturally suitable for this communication paradigm.
To join a multicast, a subscriber transmits a multicast-group join message to a multicast router operated by a service provider. The join message includes a control packet such as an IGMP join message. Subsequently, the router transmits a control packet such as a PIM join message to a Rendezvous Point (RP) in the content-delivery network. Thereafter, the RP transmits the PIM join message to the source of the multicast stream. In this way, a multicast distribution tree is set up after which the subscriber is able to receive the multicast stream. The process of setting up the multicast distribution tree is known as ‘control packet processing’.
Setting up the multicast distribution tree requires processing the control packet, a process that can involve a considerable amount of time. Thus, there is often substantial latency for the subscriber to receive the transmission of the multicast primarily because of the need to process the control packets.
When the subscriber switches from one multicast stream to another, a new multicast distribution tree must be set up. For each multicast stream, state must be maintained and routers sitting in the path from the source of the multicast stream to the subscriber must process the control packets.
If the subscriber switches between a number of multicast streams within a time window, then the control packet processing would also have to scale to match the number of multicast streams subscribed to by the subscriber within the time window. This leads to a substantial amount of additional processing by the routers in the multicast distribution tree. Additional bandwidth may need to be allocated if the selected multicast stream is not already in the set of multicast streams.
Processing the control packets, specifically, the IGMP reports and PIM joins, takes a substantial amount of time, thus resulting in a noticeable delay when switching from one channel instance to another. It is clearly undesirable to subject a viewer to many seconds of delay when switching from one channel instance to another. What is needed is a method and a system for lessening the delay when switching from one multicast channel to another before the contents of the channels are displayed for the viewer.
USPTO Backgrounds
USPTO Backgrounds