20050076099 Live streaming media replication in networks

ABSTRACT

Replication of live streaming media services (SMS) in a communication network may be enabled by introducing the streaming media-savvy replication service on a network element,

through a number of functions such as client/service registration and classification, packet interception and forwarding, media replication, status monitoring and configuration management. In an embodiment, client requests and server replies of an SMS are intercepted and evaluated by the network element. If the SMS is not streaming through the network element, the replication service registers the SMS and establishes a unique SMS session for the requesting clients. If the SMS is already streaming through the network element, the replication service replicates the streaming media and forwards it to the requesting clients. This reduces bandwidth usage on the links connecting the streaming media server with the network element and reduces the number of client connections to the streaming media provider’s servers.

Live streaming media replication in a communication network

An Inventor: Dr. Tal Lavian

BACKGROUND OF THE INVENTION

1. Field of the Invention

• The present invention relates to delivery of streaming media on a communication network and, more particularly, to a method and apparatus for live streaming media replication in a communication network.

2. Description of the Related Art

• Data communication networks may include various computers, routers, switches, and other devices coupled to and configured to pass data to one another. These devices will be referred to herein as “network elements.” Data is communicated through the data communication network by passing protocol data units, such as frames, packets, cells, or segments, between the network elements by utilizing one or more communication links. A particular protocol data unit may be handled by multiple network elements and cross multiple communication links as it travels between its source and its destination over the network.

• As communication networks have improved, it has become common to stream live media across the network from a media server to a requesting end user. FIG. 1 illustrates one example of a communication network that may be used to deliver a streaming media service (SMS) from an SMS provider having one or more streaming media server(s) 10 to an end user 12. As shown in FIG. 1, in this example, the streaming media server is connected either directly or via an intermediate network to a backbone network 14. The backbone network may have multiple network elements 16, such as routers and switches, configured to handle high bandwidth traffic.
• At the edge of the backbone network, one or more edge network devices 18 take traffic off the backbone network and place it onto a metropolitan area network 20. The metropolitan area network is made up of sub-networks, referred to herein as edge networks 22. Each edge network may connect one or more end networks 24 configured to interface directly with end users 12.
• Conventionally, as shown in FIG. 2, if an end user 12 desires to have access to a streaming media service (SMS), the end user 12 sends a request to a streaming media server 10. When resource is allowed, the streaming media server accepts the user request and transmits the streaming media service to the end user 12. An SMS session is created for each end user, as shown in FIG. 2, so that each end user could be provided with the streaming media.
• Unfortunately, the bandwidth provided in the edge networks and end networks may not be sufficient to handle the streaming media, or may cause provision of such services to become prohibitively expensive. For example, it may take up to 5 Mbps of transmission capacity to stream full motion video media to an end user. If an end network 24 is serving 250 end users, the end network would be required to have purchased 1 Gbps of available bandwidth on the link 26. In addition to this, the network element 28 will also need to reserve bandwidth on the link 26 to fulfill its service level agreements with other end users that may require bandwidth other than in connection with the streaming media. Thus, although there may be plenty of bandwidth on the backbone network to handle streaming media traffic, the metropolitan area networks, edge networks, and end networks may not have purchased or installed sufficient bandwidth to provide streaming media to potential end users.
• One attempt to overcome this issue is to transmit the packets using a multicast protocol. Multicast protocols operate at the link level or network level to cause network devices to replicate packets in a tree like structure. Unfortunately, to transport multicast traffic, the streaming media server, the end user, and all of the network devices in between must be multicast enabled and support the particular multicast protocol. Additionally, multicast protocols tend to be complicated, and much more difficult to implement reliably than the well established unicast protocols. Several multicast protocols will be discussed below.
• Internet Protocol (IP) multicasting has been proposed for many years with a well-defined suite of protocols, such as Internet Group Multicast Protocol (IGMP), Distance Vector Multicast Routing Protocol (DVMRP), Multicast extended Open Shortest Path First (MOSPF), Protocol Independent Multicast (PIP)-Dense Mode (PIM-DM), PIM-Sparse Mode (PIM-SM), and PIM-Source Specific Multicast (PIM-SSM). IP multicasting is useful, in that it replicates content without redundancy throughout the network. However, IP multicasting has weak network security, unidentified members, complicated protocols, requires specific software and hardware implementations, and has experienced scalability problems in large networks.
• Mbone (Multicast backBONE) is a virtual multicast network that provides point to point tunnels to connect multicast-enabled islands in the unicast ubiquitous Internet. Each island has one or more multicast routers that act as the Mbone tunnel end points. As a result, multicast content is encapsulated in unicast packets and transferred between multicast routers through the Internet. But, Mbone is still based on IP multicasting and cannot prevent the problems associated with IP multicasting.
• Meta-Content multicasting introduces a Meta-Content concept and uses User Datagram Protocol (UDP) instead of HyperText Transport Protocol/Transmission Control Protocol (HTTP/TCP) for Internet content multicast. Meta-content is a series of mathematical metaphors that represent the original content according to a special algorithm. For a piece of content, a specific server generates a redundant stream of meta-content, and multicasts via UDP to specific clients. A client starts collecting pieces of meta-content until it can restore the content. Its benefit is that UDP is used to replace TCP for fast content transport and maximal bandwidth utilization. But, this requires IP multicasting support and can only work with proprietary software systems.
• Hop-by-hop (HBH) multicasting introduces down-stream network hops as members in a multicast group. HBH uses multicast control tables for group membership information and multicast forward tables for content forwarding to reach all group members. HBH has smaller multicast routing tables and requires EP multicast support only on those routers close to the end users. But HBH still uses IP multicasting, and HBH-enabled routers must be deployed throughout the Internet to make this solution work.
• End system multicasting, such as that described as the Carnegie Mellon University (CMU) Narada protocol, is an approach to realize application multicasting that moves the IP multicast functions from the network routers to end systems. That is, each member in a multicast group is a virtual “multicast router” that maintains a neighbor graph and replicates packets to its neighbors. End system multicasting does not need any multicast support from the network. However, it makes an end system more complicated, since it requires the end system to perform multicast routing while it receives the content. Additionally, a new member cannot join a multicast group unless it knows at least a live “end system” in its neighborhood.
• A known solution that has been attempted is to cache streaming media in advance at a locations close to end networks, so that transmission of streaming media doesn’t need to travel as far over most of the communication network. There are two disadvantages to this. First, content caching network devices require large memories to be utilized to store the content throughout the network. Additionally, due to the large storage requirements, storage servers rather than the network devices 28are generally used to cache all of the available media streams that may potentially be requested by the end users. Hence, media caching is unlikely to alleviate congestion on the link 26 since the content servers are likely to be placed closer to the edge of the backbone network. Moreover, for live streaming media (streaming media that is being created contemporaneously with transmission) caching servers are ineffective since the content does not exist beforehand and, hence, cannot be pre-cached.
• In addition to the potential lack of capacity on link bandwidth, requiring the streaming media server 10 to host a large number of SMS sessions may cause network congestion and service interruption on the streaming media server(s) 10. One way to ameliorate this is to use server load balancing. Server load balancing is well known in Internet web access. Recent network switch products such as web switches can balance the server load in a service provider network by shifting client requests from one server to another. Server load balancing can prevent a server from overloading when other servers are underloaded. However, server load balancing neither reduces the number of client connections nor increases the server capacity. Once the total capacity of the media servers reaches a particular limit, service interruption problems reoccur.
• Recent proposals have been proposed to enable streaming media to be replicated on the network. A major proposal is to add a streaming media proxy on network devices to redirect client requests to inline streaming media proxy services or offline streaming media proxy server. A typical solution of this proposal is to combine the proxy mechanism with caching servers. Another proposal uses traffic interception on network devices to detect client requests of particular streaming media services. While this proposal does not use a proxy, it also has not yet been developed into a feasible solution.
• Accordingly, it would be advantageous to provide an apparatus configured to enable live streaming media to be transmitted to multiple end users while alleviating bandwidth requirements required to accommodate these transmissions.

SUMMARY OF THE INVENTION

• The present invention overcomes these and other drawbacks by providing a method and apparatus for live streaming media replication in a communication network. Embodiments of the invention may reduce bandwidth requirements on the network and/or reduce the number of SMS sessions required to be hosted by the streaming media server, although the invention is not limited to a solution that achieves either or both of these potential benefits. According to one embodiment of the invention, streaming media requests are intercepted by a network element on the network. A network service, referred to herein as a “replication service,” evaluates the request and, if the streaming media is not currently streaming through the network element, interfaces with the streaming media server to fulfill the request. If the streaming media is already streaming through the network element, the network element replicates the streaming media and forwards the streaming media to the requesting user.

• The replication service is deployed on a network element such as a router and provides a number of function modules, such as client/service registration, classification, packet interception and forwarding, media replication, status monitoring, and configuration management. The modules of the replication service interact together to form a service that may allow streaming media to be replicated intermediate the streaming media service provider and end users. The replication service is transparent to the end users so that they can act normally without any change.
• By replicating the streaming media for the user rather than establishing a new SMS session from the streaming media server, it is possible to reduce bandwidth on the links connecting the streaming media server with the replication network element, and hence reduce the costs associated with providing those services. Additionally, by enabling replication to happen in the network, the streaming media server may serve more end users without being required to host an individual SMS session for each end user. This reduces the likelihood that the streaming media server will encounter an overload condition and reduces the amount of bandwidth required to connect the streaming media server to the backbone network. Moreover, by utilizing a network service on the network element to handle packet replication and employing prevailing unicast protocols to handle packet distribution, it is possible to replicate packets for distribution to mulitiple users without requiring all network devices in the path between the streaming media server and the end user(s) to agree on, implement, and support a multicast protocol.