Virtual multicasting

CROSS REFERENCE TO RELATED APPLICATIONS

0001This application hereby claims the benefit of the priority of U.S. Provisional Patent Application Ser. No. 60/214,752, filed Jun. 29, 2000, which is hereby incorporated by reference. This application also hereby incorporates by reference U.S. patent application Ser. No. 09/835,529, entitled “Channel Dancer” and filed Apr. 17, 2001, U.S. patent application Ser. No. 09/878,232, entitled “Personal Content Manager” and filed Jun. 12, 2001, and U.S. patent application entitled “Digital Rights Management”, invented by Khanh Mai, Roland Noll, and Tom Grimes and filed on the same date, under separate cover, as the present application.

BACKGROUND

00021. Technical Field

0003The present invention is related to Internet Protocol (“IP”) multicasting, and more particularly to IP multicasting over a non-IP multicast supported network.

00042. Description of Related Art

0005Over the past ten years, the bandwidth capacity available to consumers for receiving content from the Internet and other networks has increased ten-fold and more. The increased bandwidth capacity has enabled consumers to download larger and larger files and other content, including rich media and multimedia content such as audio clips, video clips, songs, programs, and movies. This increased bandwidth capacity has increased Internet usage and the potential for enjoyable and productive usage.

0006The content may be delivered to users, for example, as real-time IP multicast or unicast streams. IP multicasting is a method to send a single message to multiple recipients belonging to a multicast group. To multicast content, a multicast group is created by a multicast router and Internet Group Management Protocol (IGMP) queries for the multicast content are sent out to clients via the router's network. Clients that want to receive the multicast content send a IGMP report, in response to the IGMP query to the multicast router and are added to the multicast group. Any client that is a member of the multicast group receives the multicast content. The IP multicasting method can reduce the unnecessary network load caused by the unicasting method, which sends out multiple copies of the same message to multiple recipients. Despite the increased bandwidth capacity, however, most networks, especially Internet Service Provider (“ISP”) networks, are not IP multicast enabled. Enabling IP multicasting in a network requires equipment upgrades. Also, broadcasting of heavily requested content may be bandwidth prohibitive for many networks. Unfortunately, the necessary equipment upgrades are often not undertaken by many networks. Many networks do not make the necessary equipment upgrades because the equipment upgrades are not cost efficient.

0007What is needed is a mechanism for delivering IP multicast content to users via a non-multicast enabled network.

SUMMARY OF THE INVENTION

0008An advantage of the present invention is that it overcomes the disadvantages and shortcomings of the prior art. Another advantage of the present invention is that it provides a method and a system for simulating multicasting over non-multicast enabled networks. Another advantage of the present invention is that it provides a system that is able to distribute multicast/unicast packets to multiple end-users through non-multicast enabled networks with multicast efficiency. Another advantage of the present invention is that it does not require changes on the pre-existing infrastructure of the networks. The potential beneficiaries of the present invention include applications involving fan-out distribution of packets, content distribution to multiple isolated (non-multicast enabled in between) networks, and last stop distribution of packets (see <figref idref="DRAWINGS">FIGS. 1, 7</figref>, and <b>8</b>).

0009These and other advantages of the present invention are achieved by a method of virtual multicasting multicast content on non-multicast enabled networks, comprising the steps of determining if an attached network is multicast enabled, if the attached network is not totally multicast enabled, querying for virtual multicast requests for the multicast content from non-multicast enabled client computers, listening for virtual multicast requests, and determining, based on the virtual multicast requests, which client computers request the multicast content, from the unicast addresses, and the requested methods of delivery for the multicast content. The network includes client computers that have unicast addresses and the at least one virtual multicast request includes a unicast address identifying a client computer of the network and a requested method of delivery for the multicast content.

0010These and other advantages of the present invention are also achieved by a computer-readable medium comprising instructions for virtual multicasting (VMC) multicast content on non-multicast enabled networks, by determining if an attached network is multicast enabled, if the attached network is not totally multicast enabled, querying for virtual multicast requests for the multicast content from non-multicast enabled client computers, listening for virtual multicast requests, and determining, based on the virtual multicast requests, which client computers request the multicast content, from the unicast addresses, and the requested methods of delivery for the multicast content. The network includes client computers that have unicast addresses and the at least one virtual multicast request includes a unicast address identifying a client computer of the network and a requested method of delivery for the multicast content.

0011These and other advantages of the present invention are also achieved by a system for virtual multicasting (VMC) multicast content on non-multicast enabled networks, comprising a virtual router and an attached network, associated with the virtual router, that includes a plurality of client computers that have unicast addresses. The virtual router includes software comprising instructions for determining if the attached network is multicast enabled, if the attached network is not totally multicast enabled, querying for virtual multicast requests for the multicast content from non-multicast enabled client computers, listening for virtual multicast requests, and determining, based on the virtual multicast requests, which client computers request the multicast content, from the unicast addresses, and the requested methods of delivery for the multicast content. The at least one virtual multicast request includes a unicast address identifying a client computer of the network and a requested method of delivery for the multicast content.

BRIEF DESCRIPTION OF THE DRAWINGS

0012The detailed description will refer to the following drawings, in which like numbers refer to like items, and in which:

0013<figref idref="DRAWINGS">FIG. 1</figref> is a schematic diagram of an exemplary embodiment of a virtual multicasting system.

0014<figref idref="DRAWINGS">FIGS. 2</figref><i>a</i>-<b>2</b><i>c </i>are block diagrams illustrating exemplary hardware components of an embodiment of the virtual multicasting system.

0015<figref idref="DRAWINGS">FIGS. 3</figref><i>a</i>-<b>3</b><i>b </i>are flowcharts illustrating an exemplary method of virtual multicasting.

0016<figref idref="DRAWINGS">FIG. 4</figref> is a schematic diagram of a virtual network tree.

0017<figref idref="DRAWINGS">FIGS. 5</figref><i>a</i>-<b>5</b><i>b </i>are block diagrams illustrating an exemplary implementation of the virtual multicasting system.

0018<figref idref="DRAWINGS">FIG. 6</figref> is a block diagram of an exemplary implementation of the virtual multicasting system.

0019<figref idref="DRAWINGS">FIGS. 7 and 8</figref> are schematic diagrams of exemplary embodiments of the virtual multicasting system.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

0020<figref idref="DRAWINGS">FIG. 1</figref> is a schematic diagram of an exemplary application of a Virtual Multicasting (VMC) system according to the present invention. The embodiment shown in <figref idref="DRAWINGS">FIG. 1</figref> is a virtual network <b>10</b> including a plurality of sub-networks (networks A-F). The virtual network <b>10</b> in <figref idref="DRAWINGS">FIG. 1</figref> provides a fan-out distribution of packets. The VMC system includes software routing applications as well as computer hardware for hosting these applications. The components of the VMC system are listed as follows:

0000VMC System Hardware Components

0021Virtual Routers (VRs) <b>12</b>, which preferably are standard computers with networking capabilities. Except for client components, the VMC software resides on the VRs.

0022Clients <b>14</b>, which preferably are standard computers for end-users that comprise client software, including certain VMC software components, and receive content delivered by the VMC system over the virtual network <b>10</b>. Clients <b>14</b> are the end-recipients of content distribution. Clients <b>14</b> preferably also include a network interface card/adapter and necessary networking software such as TCP/IP.

0023Content servers <b>16</b>, which preferably are standard computers with networking, data-storage, and web hosting capabilities. Content preferably originates from the content servers <b>16</b>. Content servers <b>16</b> may also serve as a web site, accessible via the Internet, hosting information about content availability.

0000VMC System Software Components

0024A Virtual Multicast Distribution protocol (VMCDP) that dictates how VRs <b>12</b> convert packets from multicast packets to unicast packets and vise versa, replicate packets for unicast clients <b>14</b> or downstream VRs <b>12</b> (VRs <b>12</b> located at virtual sub-networks downstream—e.g., VR<b>22</b> is downstream from VR<b>11</b>), and deliver packets. The software conversion of packets from multicast to unicast may be accomplished by modifying destination IP of the packet at the IP layer. A standard multicast group is defined by an multicast IP address and a port. A unique value in the VMC system is how a channel is defined. A VMC channel map (see VMC file below) is created at the central location VR <b>12</b> (e.g., VR<b>11</b>) and fetched by all the downstream VRs <b>12</b>. In the VMC system, a channel (or a multicast group in standard multicast) is defined by a port. When a VR <b>12</b> receives a unicast stream (destinated to the VR <b>12</b>) at a port on the map, the VR <b>12</b> automatically knows what multicast group the unicast stream belongs to based on the VMC channel map. This is impossible for standard Transmission Control Protocol/Internet Protocol (TCP/IP) without adding more information (like the mutlicast IP address) to the packet. Another unique feature is that VMC system does not alter the original packet. The VMC system does not add information to the original packet. The VMC system always keeps the original sender's IP address for possible backlink service. The VMC protocols describe below are only used on VRs <b>12</b> for registration and distribution mechanisms.

0025A Virtual Multicast Registration protocol (VMCRP). The VMCRP is used by VRs <b>12</b> for dynamic registration of client <b>14</b> requests for VMC content, periodic probing and the addition/removal of clients <b>14</b> or downstream VRs <b>12</b> from VMC client table files (see below). VMCRP is a protocol used among VRs <b>12</b> to forward requests of VMC content on certain channels. Upon receiving a request from a client <b>14</b> or another VR <b>12</b> (forwarding requests), a VR <b>12</b> will send a short message to all the VRs <b>12</b> at its parent level on the Virtual Network Tree (see VNT file below) asking for the parent VR's <b>12</b> loads and distance (judging by round trip time (RTT) of an ICMP packet). After making an optimal selection of a parent VR <b>12</b> based these two factors, the VR <b>12</b> will add the parent VR <b>12</b> entry to its client table (for unicast request—see VCT file below) or the multicast flag will be turned on (for a multicast request) and forward the request to the selected parent VR <b>12</b>. VRs <b>12</b> will periodically send a probing (in dynamic registration) message to all it clients <b>14</b>. A client <b>14</b> which fails to answer the probing will be removed from the client table. So no unnecessary streams (for clients <b>14</b> that fail to answer) will be send to that network. At the same time, clients <b>14</b> and VRs <b>12</b> may periodically send probing to their registered parent VRs <b>12</b>. If a parent VR <b>12</b> fails to answer the probing, the client/VR will re-register all the content requests associated with the parent VR <b>12</b> with other parent VRs <b>12</b>.

0026A Virtual IGMP protocol (VIGMP) for clients <b>14</b> to register requests for content with Virtual Routers <b>12</b>. VIGMP reports generally indicate that the client <b>14</b> is requesting unicast delivery (the client <b>14</b> is not multicast enabled). Clients <b>14</b> in a multicast enabled portion of a network may transmit VIGMP reports requesting multicast delivery (the client <b>14</b> is multicast enabled). The VIGMP preferably is an application programming interface (API) for easy integration with client software.

0000VMC System Files

0027A Virtual Network Tree (VNT) File. The VNT file preferably contains a list of the VRs <b>12</b> on the entire virtual network <b>10</b>. These VRs <b>12</b> are grouped by levels starting from root level VRs <b>12</b> at a central location (i.e., network A in <figref idref="DRAWINGS">FIG. 1</figref>). The VNT file describes the hierarchy of the virtual routers <b>12</b>. For the example in <figref idref="DRAWINGS">FIG. 1</figref>, VR<b>11</b> is at root level or level <b>1</b>. VR<b>21</b> and VR<b>22</b> are at level <b>2</b> (i.e., level <b>2</b> VRs <b>12</b>). VR<b>31</b>, VR<b>32</b>, and VR<b>33</b> are at level <b>3</b> (i.e., level <b>3</b> VRs <b>12</b>). The levels may represent regions, states, and cities, for example. The maximum number of VRs <b>12</b> at a certain level may be determined by the capacities of the VRs <b>12</b> at a higher level (i.e., closer to the root level).

0028The VNT file preferably also includes information about each VR <b>12</b> on the list. This information preferably includes an IP address of the VR <b>12</b> that is accessible by other VRs <b>12</b> and the full host name of the VR <b>12</b>. The VNT file is preferably created at the central location and is preferably fetched by VRs <b>12</b> on the same virtual network <b>10</b> during the VR's <b>12</b> startup in order for the VRs <b>12</b> to determine their level (e.g., level <b>2</b>) and to find the closest upstream VR <b>12</b>.

0029A VMC Channel Map (VCM) File. The VCM file preferably includes a list of pairs of multicast IP addresses and port numbers supported by the specific VMC system. Each pair of addresses and port numbers defines a multicast channel for content distribution. The VCM file may be created at the central location and be fetched by VRs <b>12</b> on the same virtual network <b>10</b> during the VR's <b>12</b> startup in order for the VRs <b>12</b> to determine what multicast channels are available.

0030A VMC Client Table (VCT) File. Preferably, each VR <b>12</b> keeps a client table (the VCT file) for each available multicast channel (group). The VCT file contains a multicast flag and a list of unicast clients <b>14</b> for each supported multicast channel. The VCT file is created locally by the registration protocols VIGMP and VMCRP. The multicast flag for each supported multicast channel is turned on upon the VR <b>12</b> receiving of a VIGMP report for a multicast group (indicating that a client wants to receive the multicast content). The list of unicast clients <b>14</b> requesting content from each supported multicast channel is updated as follows: upon the VR <b>12</b> receiving a VIGMP/VMCRP unicast request from a client <b>14</b> or downstream VR <b>12</b> (the senders), the client's <b>14</b> or/and downstream VR's <b>12</b> IP address is added to the list of unicast clients in the VCT file, if the client <b>14</b> or VR <b>12</b> is not already on the list.

0000Function of the VMC System

0031The above VMC protocols (VMCDP, VMCRP and VIGMP) are built on top of standard TCP/IP protocols, such as UDP (user datagram protocol), IP (Internet Protocol), ICMP (Internet Control Message Protocol), and IGMP. Indeed, the messaging proscribed by the VMC protocols is identical to the underlying standard TCP/IP protocols. For example, the VIGMP reports are identical to IGMP reports.

0032Each VR <b>12</b> can receive/distribute multicast as well as unicast packets. The VRs <b>12</b> can also convert multicast packets to unicast packets, and vise-versa. Whether a VR <b>12</b> concerts multicast packets to unicast packet, or vice-versa, is determined by the VR <b>12</b> virtual multicast client table (VCT files) created by the registration protocol VMCRP requests. For example, if a client <b>14</b> sends a VIIGMP unicast request to the VR <b>12</b>, the client's <b>14</b> IP address is added to the list of unicast clients in the VCT file and multicast packets for the requested multicast content group are converted to unicast packets for that client <b>14</b>.

0033Referring to the exemplary application of the VMC system shown in <figref idref="DRAWINGS">FIG. 1</figref>, the virtual network <b>10</b> includes six sub-networks, networks A-F. Networks A-D are separate and connected only via the Internet, which is not (or at least not fully) multicast enabled. Network A is the central location where all the content packets (content for multicast distributing) originate in the virtual network <b>10</b>. As shown, network A receives the content from the content server <b>16</b>, which may be co-located with or remotely located from network A.

0034In the example illustrated in <figref idref="DRAWINGS">FIG. 1</figref>, virtual multicasting is achieved by running a virtual router <b>12</b> on each network A-F (in a similar way normal networks are configured with different routers) that requires virtual multicasting. The VNT file, which includes a virtual multicasting tree that describes the virtual network <b>10</b> and the sub-networks A-F, is built at the network A, the central location (the root of the tree). During the startup of each VR <b>12</b>, each VR <b>12</b> communicates with VR<b>11</b>, the VR <b>12</b> at the central location, and fetches the VNT file and the VCM file. Each VR <b>12</b> uses the VNT file to determine their tree level and the closest upstream VR <b>12</b>.

0035The VMC client <b>14</b> registration process is driven by client <b>14</b> requests for multicast content. Once a VR <b>12</b> detects the absence of a multicast enabled router (the absence of IGMP queries), the VR <b>12</b> periodically issues VIGMP queries using a control channel to the attached network A-F. The VIGMP queries are identical to IGMP queries for multicast clients. A user on a client <b>14</b> may review available multicast content on the content server <b>16</b> using a web browser, or other means. A multicast-enabled client <b>14</b>, for example Client <b>1</b> on Network D, may request to join a multicast group for multicast content by sending out IGMP reports to the VR <b>12</b>. A unicast client <b>14</b> wanting to receive the multicast content may use VIGMP reports to request unicast delivery (Unicast UDP) of the multicast packets. On a multicast-enabled network, where a regular router is issuing IGMP queries, the VR <b>12</b> preferably only listens to and processes the VIGMP reports.

0036A VR <b>12</b>, for example VR<b>31</b>, that receives the VIGMP report adds the requesting unicast client <b>14</b> to the VCT file of the VR <b>12</b> (i.e., the VMC client table) for the requested multicast content group and forwards/registers the requested multicast group with one of the upstream VRs <b>12</b> using the registration protocol VMCRP. The upstream VR <b>12</b>, with which the requested multicast group is registered, is preferably selected based on an optimal balance of the loading on each upstream VR <b>12</b> and the Round Trip Time (RTT) necessary for the registration to reach each upstream VR <b>12</b>. The selected VR <b>12</b> (parent VR) forwards the registration to a further upstream VR <b>12</b> in a similar manner. This registration process preferably continues until the registration reaches the root VR <b>12</b> at the center location (network A).

0037The multicast content server <b>16</b> (which may be on the same network as the center location or remotely located from the center location) does not necessarily need to be multicasting since the root virtual router <b>12</b> can receive both multicast and unicast packets and convert them if necessary. With the distribution protocol VMCDP, once a VR <b>12</b> receives a multicast or unicast packet, the VR <b>12</b> checks against its VCT file (the VMC client table), conducts the necessary packet conversion and/or replication, and delivers a multicast packet to the attached network or/and multiple unicast packets to clients <b>14</b> on the attached network or/and downstream VRs <b>12</b>.

0038A VR <b>12</b> preferably can send out a multicast packet and/or multiple unicast packets to clients <b>14</b> on the same network and/or to downstream VRs <b>12</b>. For example, referring to the virtual network <b>10</b> in <figref idref="DRAWINGS">FIG. 1</figref>, VR<b>21</b> may send a multicast packet to Network B if requested (by a multicast client, e.g. MC Client on Network B). In addition, VR<b>21</b> replicates the packet and unicast the replicated packets to the unicast client (UC Client) on the attached network (Network B) and to downstream virtual routers VR<b>31</b> and VR<b>32</b>.

0039The registration protocols VMCRP and VIGMP may be implemented dynamically. With the dynamic VMCRP and VIGMP, clients <b>14</b> and VRs <b>12</b> periodically re-register requests, check VCT files (the VMC client tables), and probe registered parent VRs <b>12</b>. The probe may be to check if the registered parent VR <b>12</b> is still up. The registered parent VR <b>12</b> could be accidentally down or shut down for maintenance. The VR <b>12</b> or client <b>14</b> have the ability to switch to other parent VRs <b>12</b> for those channels already associated with the down parent VR <b>12</b>. A client <b>14</b> in the VMC client table of a VR <b>12</b> is preferably removed from the VMC client table if the client <b>14</b> has not re-registered within a certain period of time. If the probe to a registered parent VR <b>12</b> fails, the current VR <b>12</b> re-registers with other upstream VR(s) <b>12</b> all the multicast content requests associated with the failed parent VR <b>12</b>.

0000Exemplary VMC System Hardware Components

0040<figref idref="DRAWINGS">FIGS. 2</figref><i>a </i>through <b>2</b><i>c </i>are block diagrams illustrating exemplary hardware components for implementing virtual multicasting and supporting a multicasting system.

0041Client <b>14</b>

0042<figref idref="DRAWINGS">FIG. 2</figref><i>a </i>illustrates an exemplary client <b>14</b>. As shown, the client <b>14</b> preferably comprises a consumer PC/user machine <b>20</b> connected with a network <b>44</b> such as the Internet, a LAN or other network. Other clients, such as client <b>14</b>′ may also be connected with network <b>44</b> and may include the same components as user machine <b>20</b>.

0043User machine <b>20</b> illustrates typical components of a user machine. User machine <b>20</b> typically includes a memory <b>22</b>, a secondary storage device <b>24</b>, a processor <b>26</b>, an input device <b>28</b>, a display device <b>30</b>, and an output device <b>32</b>. Memory <b>22</b> may include random access memory (RAM) or similar types of memory, and it may store one or more applications <b>34</b>, including client software <b>36</b> and VIGMP API <b>38</b>, and a web browser <b>40</b>, for execution by processor <b>26</b>. Secondary storage device <b>24</b> may include a hard disk drive, floppy disk drive, CD-ROM drive, or other types of non-volatile data storage. Processor <b>26</b> may execute applications or programs stored in memory <b>22</b> or secondary storage <b>24</b>, or received from the Internet or other network <b>44</b>. The processor <b>26</b> may execute one or more applications <b>34</b>, including client software <b>36</b> and VIGMP API <b>38</b>, in order to provide the functions described in this specification. Input device <b>28</b> may include any device for entering information into user machine <b>20</b>, such as a keyboard, mouse, cursor-control device, touch-screen, infrared, microphone, digital camera, video recorder or camcorder. Display device <b>30</b> may include any type of device for presenting visual information such as, for example, a computer monitor or flat-screen display. Output device <b>32</b> may include any type of device for presenting a hard copy of information, such as a printer, and other types of output devices include speakers or any device for providing information in audio form.

0044Web browser <b>40</b> is used to access the VMC system and to choose which broadband content the user wishes to view. The web browser <b>40</b> also is used to access the Internet <b>44</b>, content servers <b>16</b> (e.g., a NOC) and ISPs. Examples of web browsers <b>40</b> include the Netscape Navigator™ program and the Microsoft Internet Explorer™ program. Any web browser, co-browser, or other application capable of retrieving content from a network (any wireline or wireless network may be used) and displaying pages or screens may be used. Content broadcast (multicast or unicast) and received by the client <b>14</b> may be displayed through the web-browser <b>40</b>. The content may include “links”, for example, HyperText Transport Protocol (“HTTP”) hyperlinks to other content and/or Internet websites. Multimedia applications such as Microsoft Media Player™ and RealPlayer™ may be used to enable viewing of real-time multicast or unicast streams.

0045Examples of user machines for interacting within the system include personal computers, laptop computers, notebook computers, palm top computers, network computers, Internet appliances, set top terminals or any processor-controlled device capable of executing a web browser <b>40</b> or other type of application for interacting with the VMC system.

0046Content Server

0047<figref idref="DRAWINGS">FIG. 2</figref><i>b </i>illustrates typical hardware components of a content server <b>16</b>. Content server <b>16</b> typically includes a memory <b>50</b>, a secondary storage device <b>52</b>, a processor <b>54</b>, an input device <b>56</b>, a display device <b>58</b>, and an output device <b>60</b>. Memory <b>50</b> may include RAM or similar types of memory, and it may store one or more applications <b>64</b> for execution by processor <b>54</b>. Secondary storage device <b>52</b> may include a hard disk drive, floppy disk drive, CD-ROM drive, or other types of non-volatile data storage. Processor <b>54</b> executes application(s), which are stored in memory <b>50</b> or secondary storage <b>52</b>, or received from the broadband connection, the Internet or other network <b>44</b>. Input device <b>56</b> may include any device for entering information into content server <b>16</b>, such as a keyboard, mouse, cursor-control device, touch-screen, infrared, microphone, digital camera, video recorder or camcorder. Display device <b>58</b> may include any type of device for presenting visual information such as, for example, a computer monitor or flat-screen display. Output device <b>60</b> may include any type of device for presenting a hard copy of information, such as a printer, and other types of output devices include speakers or any device for providing information in audio form.

0048Content server <b>16</b> may store one or more database structures in secondary storage <b>52</b>, for example, for storing and maintaining information regarding the clients <b>14</b>. For example, it may maintain a relational, object-oriented or other client database for storing information concerning system users, the access rights of the users and their account status. The database structures may also include content databases. For example, the content server <b>16</b> may maintain a relational, object-oriented or other content database for storing content and/or information concerning the content.

0049Processing by the processors <b>54</b> may provide and support pages, windows and menus described in this specification and otherwise for display on display devices associated with the client <b>14</b>. The pages, windows and menus may be formatted, for example, as web pages in HyperText Markup Language (HTML), Extensible Markup Language (XML) or in any other suitable form for presentation on a display device depending upon applications used by users of the clients <b>14</b>.

0050Although only one content server <b>16</b> is shown, multiple servers may be used as necessary or desired to support and provide the content and may also use back-up or redundant servers to prevent network downtime in the event of a failure of a particular server.

0051Virtual Router

0052<figref idref="DRAWINGS">FIG. 2</figref><i>c </i>illustrates typical hardware components of a virtual router <b>12</b>. A virtual router <b>12</b> is preferably a standard computer/server with networking functionality. Typically, the VR <b>12</b> includes a memory <b>70</b>, a secondary storage device <b>72</b>, a processor <b>74</b>, a network input device <b>76</b>, and a network output device <b>78</b>. The memory <b>70</b>, secondary storage device <b>72</b>, and processor <b>74</b>, are similar, in form and function to those of the content server <b>16</b> described above with reference to <figref idref="DRAWINGS">FIG. 2</figref><i>b</i>. For example, the processor <b>74</b> may execute applications <b>80</b> stored in the memory <b>70</b> and/or secondary storage device <b>72</b>, including VMCDP, VMCRP and VIMGP software described above, to perform the functions of the VMC system described herein. Likewise, the processor <b>74</b> may create and store files, including the VNT, VCM and VCT files described above, in the memory <b>70</b> and/or secondary storage device <b>72</b>.

0053The network input device <b>76</b> and the network output device <b>78</b> may comprise network adaptors and/or network information cards (NIC). The network input device <b>76</b> and the network output device <b>78</b> are able input/output IP packets from/to the connected network (e.g., network A-F). The operating system on the VR <b>12</b> and the drivers on the network input device <b>76</b> and the network output device <b>78</b> support the standard TCP/IP protocols and can issue IP level protocols such as ICMP and IGMP. It is preferable for the operating system to support web-hosting protocols such as HTML, so the VR <b>12</b> may be configured and operated from remote sites.

0054In addition, although VR <b>12</b>, client <b>14</b>, and content server <b>16</b> are depicted with various components, one skilled in the art will appreciate that VR <b>12</b>, client <b>14</b>, and content server <b>16</b> can contain additional or different components. In addition, although aspects of an implementation consistent with the present invention are described as being stored in memory, one skilled in the art will appreciate that these aspects can also be stored on or read from other types of computer program products or computer-readable media, such as secondary storage devices, including hard disks, floppy disks, or CD-ROM; a carrier wave from the Internet or other network; or other forms of RAM or ROM. The computer-readable media may include instructions for controlling a computer system, such as VR <b>12</b>, client <b>14</b>, and content server <b>16</b>, to perform a particular method.

0055An Exemplary VMC Method

0056<figref idref="DRAWINGS">FIGS. 3</figref><i>a</i>-<b>3</b><i>b </i>illustrate an exemplary method <b>90</b> of virtual multicasting. Method <b>90</b> may be implemented, for example, with software modules for execution by processor <b>74</b>, processor <b>26</b>, or a combination of the two processors. In this implementation, multicast content (e.g., broadband content) is broadcast to a network(s) and offered to multiple network users (e.g., clients, other virtual routers, etc.). As shown, the method preferably comprises the steps of: determining if an attached network (e.g., network A-D) is multicast enabled <b>92</b>; querying for virtual multicast requests <b>94</b>; listening for virtual multicast requests from clients and downstream virtual routers <b>96</b>; determining which clients and/or downstream virtual routers request multicast content and the requested delivery method <b>98</b>; building a table of requesting clients and virtual routers <b>100</b>; selecting an optimal upstream router <b>102</b> (only applicable for downstream VRs <b>12</b>); forwarding multicast request to upstream virtual router <b>104</b> (only applicable for downstream VRs <b>12</b>); receiving the requested multicast content <b>106</b>; replicating and addressing packets per table <b>108</b>; and transmitting packets to requesting multicast clients and unicast clients and downstream virtual routers <b>110</b>.

0057A VR <b>12</b> is preferably associated with a network (e.g., network B) and preferably determines whether the attached network is multicast enabled, step <b>92</b>, by listening for IGMP queries <b>921</b> (e.g., on the network control channel). If no IGMP queries are received within a certain period of time, the VR <b>12</b> determines that the attached network is not multicast enabled. If the network is not totally multicast enabled (e.g., a UNICAST UDP network) the VR <b>12</b> preferably queries for virtual multicast content requests (step <b>94</b>) by issuing VIGMP queries <b>941</b> and listens for virtual multicast content requests from clients <b>14</b> and downstream VRs <b>12</b> (step <b>96</b>) by listening for VIGMP reports <b>961</b> and listening for VMRCP reports <b>962</b>. The VR <b>12</b> (e.g., VR <b>22</b> in <figref idref="DRAWINGS">FIG. 1</figref>) preferably determines (step <b>98</b>) which clients <b>14</b> and/or downstream VRs <b>12</b> (e.g., VR <b>33</b>) request the multicast content and the requested delivery method for the multicast content (e.g., multicast or unicast) for each request by reading VIGMP and IGMP reports <b>981</b> from clients <b>14</b> and reading VMCRP reports <b>982</b> from downstream VRs <b>12</b>. The VIGMP reports indicate whether the requesting clients <b>14</b> are to get unicast or multicast delivery (clients <b>14</b> that will join the multicast group). The IGMP reports indicate that the requesting clients <b>14</b> are to get multicast delivery.

0058The virtual router preferably builds a table of requesting clients and virtual routers (step <b>100</b>) by building a VCT file <b>1001</b> that comprises unicast addresses of the clients <b>14</b> and/or downstream VRs <b>12</b> that requested the content and an associated multicast address(es) that identifies the requested content. As described above, if the VR <b>12</b> is a downstream VR <b>12</b> (e.g., VR<b>22</b> in <figref idref="DRAWINGS">FIG. 1</figref>), the VR <b>12</b> preferably selects an optimal upstream virtual router <b>102</b> by determining the upstream VR <b>12</b> (e.g., VRI <b>1</b> in <figref idref="DRAWINGS">FIG. 1</figref>) loads and round trip times (RTTs) <b>921</b> and balancing these two factors to select an optimal upstream VR <b>12</b>. This step <b>102</b> is only performed when there is a plurality of upstream VRs <b>12</b> to choose from. The VR <b>12</b> may perform step <b>102</b> at startup.

0059The VR <b>12</b> preferably forwards the multicast request to the selected upstream VR <b>12</b> (step <b>104</b>) by turning on the multicast flag in the VCT file <b>1041</b> and transmitting the VCT file to the upstream VR <b>12</b>. As noted above, the multicast request (e.g., the VCT file) is forwarded upstream until it reaches the root level or central location VR <b>12</b> (e.g., VR<b>11</b>).

0060If the central location VR <b>12</b>, the selected VR <b>12</b>, and any intervening VRs <b>12</b> have received the multicast request, the multicast content is transmitted to the current VR <b>12</b> (preferably as unicast packets). The current VR <b>12</b> preferably receives the content (step <b>106</b>) as a stream of packets. The VR <b>12</b> replicates the packets for each requesting network client <b>14</b> and downstream VR <b>12</b> addresses the replicated packets with the unicast addresses of the requesting network clients <b>14</b> and downstream VRs <b>12</b> (step <b>108</b>) as determined by reading the VCT file for unicast clients <b>14</b>, VRs <b>12</b> and their addresses <b>1081</b>. If the VR <b>12</b> receives the content as multicast packets, the VR <b>12</b> converts the multicast packets to unicast packets. For clients requesting multicast delivery, the VR <b>12</b> simply transmits the packets as multicast packets in the normal manner. The VR <b>12</b> transmits the unicast packets to each requesting unicast client <b>14</b> and downstream VR <b>12</b> (step <b>110</b>). If the virtual router determines that the network is multicast enabled, the content is multicast to the requesting network multicast users in a normal way (see above).

0061As noted above, if the network is multicast enabled, the VR <b>12</b> will only listen to VIGMP reports. As noted before, for multicast clients <b>14</b>, VIGMP reports may be identical to IGMP reports. If the network is not multicast enabled, the VR <b>12</b> will periodically send out VIGMP queries after it detects the absence of IGMP query message. Clients <b>14</b> can use VIGMP to request for multicast delivery or unicast delivery of the content.

0062As noted above, a VR <b>12</b> may replicate multicast content to other VRs <b>12</b>, as well as clients <b>14</b>. Virtual routers <b>12</b> may be logically stacked or hierarchically located on top of one another. <figref idref="DRAWINGS">FIG. 4</figref> illustrates the hierarchical structure of VRs <b>12</b> of the example in <figref idref="DRAWINGS">FIG. 1</figref>. A VR <b>12</b>, therefore, may maintain a VMC client table (a VCT file) that comprises unicast addresses for clients <b>14</b> and other VRs <b>12</b>. A VR <b>12</b> may register with any VRs <b>12</b> above it (closer to the root) by using VMCRP or similar routing protocols. As noted, the decision of which parent VR <b>12</b> to register with is made based on an optimal balance of the load of parent VRs and the round trip time (RTT) to reach them. Accordingly, a central VR <b>12</b> may be co-located with a multicast content server in order to convert multicast streams to virtual multicast streams, with unicast addressing, that are broadcast to other VRs <b>12</b> at multiple networks. Likewise, one VR <b>12</b> may act as a backup for another VR <b>12</b> below it in the hierarchical structure.

0063Sample Implementation 1 of VMC System

0064<figref idref="DRAWINGS">FIGS. 5</figref><i>a </i>and <b>5</b><i>b </i>illustrate a sample implementation of the VMC system. The system <b>120</b> illustrated by <figref idref="DRAWINGS">FIG. 5</figref> comprises one or more signal origination [or orientation] points <b>122</b> (e.g., network operation center or “NOC”), one or more transmission mediums <b>124</b> (e.g., transmitting satellite dish(es), satellite(s) and receiving satellite dish(es) and the Internet), and one or more central office (“CO”) servers <b>126</b> (e.g., ISP servers) that support a network <b>128</b> of one or more clients <b>14</b>. One example of the central office server <b>126</b> is depicted in <figref idref="DRAWINGS">FIG. 5</figref><i>b </i>as comprising a VR <b>12</b> and an ATM/DSLAM switch <b>130</b>, with connections via various sub-networks (e.g., broadband digital subscriber line (DSL) or cable) of the network <b>128</b> to one or more clients <b>14</b>. The VR <b>12</b> may be resident or loaded on the actual router (not shown). In operation, the NOC <b>122</b>, comprising the content server <b>16</b>, broadcasts multicast content via the transmission medium <b>124</b> to the central office servers <b>126</b>. The central office servers <b>126</b> distribute the content to the clients <b>14</b>.

0065In addition to the multicast content, the NOC <b>122</b> may also provide information about content availability to its users through other channels, such as on a web site accessible via the Internet or other network <b>44</b>. Clients <b>14</b> can access the web site to check which multicast content is available. If the network <b>128</b> is multicast enabled, a client <b>14</b> can request certain multicast content by registering with the ATM/DSLAM switch <b>130</b>. The ATM/DSLAM switch <b>130</b> builds a table comprising the client's <b>14</b> address and the multicast address of the content and sends an IGMP packet to the router. In response to the IGMP packet, the router transmits the multicast stream for the requested content to the ATM/DSLAM switch <b>130</b> The ATM/DSLAM switch <b>130</b> replicates the multicast stream packets of the requested content and transmits them to the client <b>14</b>, and any other requesting clients <b>14</b>, based on its table.

0066If the network <b>128</b> is not multicast enabled (e.g., the ATM/DSLAM switch <b>130</b> does not have multicasting capability), a client <b>13</b> can transmit a VIGMP packet through the ATM/DSLAM switch <b>130</b> to the VR <b>12</b> requesting for unicast delivery. Preferably, the VIGMP packet registers the client <b>14</b> with the VR <b>12</b> and tells the VR <b>12</b> that the network <b>130</b> or sub-network on which the client <b>14</b> is located is not multicast enabled and that the client <b>14</b> wants to receive multicast content. The client <b>14</b> may contact the NOC <b>122</b> via the Internet or other network <b>44</b> to determine where the closest VR <b>12</b> is located before sending the VIGMP. The VR <b>12</b> may build a virtual VMC table or dynamic routing table (the VCT file) with information about the client <b>14</b> (e.g., the client's unicast address) so that it can replicate and transmit content packets to the client <b>14</b> when the client <b>14</b> requests content. As the VR <b>12</b> receives multicast content, the VR <b>12</b> may convert the requested multicast content by replicating the content packets and transmitting to the client <b>14</b> at the client's unicast address. Note, that the VR <b>12</b> may receive the multicast content as a unicast stream, for example, if there is another VR <b>12</b> upstream (e.g., co-located with the NOC <b>122</b>) from the VR <b>12</b> (located at a central office <b>126</b>). The packets of the unicast stream may include the multicast address of the content so that the VR <b>12</b> can identify and properly route the content.

0067Sample Implementation 2 of VMC System

0068<figref idref="DRAWINGS">FIG. 6</figref> illustrates another sample implementation of the virtual multicasting system. The system <b>140</b> illustrated by <figref idref="DRAWINGS">FIG. 6</figref> comprises one or more regional data center or edge of net content servers <b>162</b>, one or more central office servers <b>126</b> supporting networks <b>128</b> of clients <b>14</b>, one or more transmission mediums <b>124</b> (e.g., landlines, DSL, cable, etc.) connecting the regional data center or edge of net content servers <b>162</b> to the central office servers <b>126</b>, a plurality of clients <b>14</b> and broadband transmission mediums <b>128</b> connecting the central office servers <b>126</b> and the clients <b>14</b>. The regional data center or edge of net content servers <b>162</b> may be co-located with a VR <b>12</b> so that the content broadcast by the content servers <b>16</b> may be virtually multicast. The VR <b>12</b> may convert multicast streams from the content servers <b>16</b> to unicast streams and broadcast them to central office servers <b>126</b> based on a central routing table comprising addresses for the central offices servers <b>126</b> with networks <b>128</b> of clients <b>14</b> that requested the content. For example, a movie that is requested by fifty thousand (50,000) clients <b>14</b> located on various central office networks <b>128</b> may be transmitted from a content server <b>16</b> to a VR <b>12</b> co-located with it at a regional data center <b>142</b>, converted from a multicast stream to a unicast stream, replicated (as necessary) and broadcast across a landline(s) <b>124</b> to the various central office servers <b>126</b> and replicated and broadcast to the fifty thousand requesting clients <b>14</b> by VRs <b>12</b> at the central office servers <b>126</b>. Since the content may be broadcast from the regional data center <b>142</b> as a unicast stream, the virtual multicasting provides a substantial bandwidth saving between the regional data center <b>142</b> and the central offices <b>126</b>.

0069It is further noted that content that has been virtual multicast, as unicast, may be converted back to or re-broadcast as multicast. For example, in the system <b>140</b> shown in <figref idref="DRAWINGS">FIG. 6</figref>, if any of the central office servers <b>126</b> supported multicast enabled networks <b>128</b>, the unicast stream received by the VR <b>12</b> at such central office servers <b>126</b> may be sent through to the ATM/DSLAM switch <b>130</b> and multicast to the clients <b>140</b>, since the packets comprise the actual multicast address of the content. Likewise, if the network <b>128</b> receiving the virtual multicast stream is a LAN, the stream may be re-broadcast as a actual multicast stream since multicasting is supported within the LAN.

0070As noted above, the virtual network <b>10</b> in <figref idref="DRAWINGS">FIG. 1</figref> is an application of the VMC system that may be used for fan-out distribution of packets. <figref idref="DRAWINGS">FIGS. 7 and 8</figref> are schematic diagrams of additional exemplary applications of the VMC system according to the present invention. The exemplary virtual networks <b>150</b> and <b>160</b> shown in <figref idref="DRAWINGS">FIGS. 7 and 8</figref> comprise VRs <b>12</b>, clients <b>14</b>, content servers <b>16</b>, center networks <b>152</b> (corresponding to central location or root level network A in <figref idref="DRAWINGS">FIG. 1</figref>) and remote networks <b>154</b> (corresponding to networks B-F at levels <b>2</b> and below in <figref idref="DRAWINGS">FIG. 1</figref>). The virtual network <b>150</b> in <figref idref="DRAWINGS">FIG. 7</figref> is a bridging-islands network. The virtual network <b>160</b> in <figref idref="DRAWINGS">FIG. 8</figref> is a last-stop conversion network. The virtual networks <b>150</b> and <b>160</b> perform virtual multicasting as described above, with the center networks <b>152</b> fulfilling the role of the central location or center office server.

0071It is also noted that certain portions of networks may be multicast enabled while other portions are not. Consequently, a virtual router may conduct virtual multicasting simultaneously with a co-located router conducting true multicasting.

0072The terms and descriptions used herein are set forth by way of illustration only and are not meant as limitations. Those skilled in the art will recognize that numerous variations are possible within the spirit and scope of the invention.