High bandwidth broadcast system having localized multicast access to broadcast content

CROSS-REFERENCE TO RELATED APPLICATIONS

0001The present application is a continuation of application Ser. No. 09/805,686, filed Apr. 19, 2000, now U.S. Pat. No. 6,411,616, which is a continuation of application Ser. No. 08/969,164, filed Nov. 12, 1997, now U.S. Pat. No. 6,101,180. In addition to being related to parent application Ser. No. 09/805,686, this continuation case is also related to the following continuation application (which also claims the benefit of priority from the Ser. No. 08/969,164 common parent application): Ser. No. 09/772,958, filed Jan. 31, 2001, entitled “High Bandwidth Broadcast System Having Localized Multicast Access to Broadcast Content” The present application also claims priority from related provisional applications: U.S. Ser. No. 60/029,427, filed Nov. 12, 1996; U.S. Ser. No. 60/039,672, filed Feb. 28, 1997; and U.S. Ser. No. 60/057,857, filed Sep. 2, 1997; all of the provisional applications are now abandoned.

BACKGROUND OF THE INVENTION

0002During the 1970's and 1980's, the defense industry encouraged and developed an interconnecting network of computers as a backup for transmitting data and messages in the event that established traditional methods of communication fails. University mainframe computers were networked in the original configurations, with many other sources being added as computers became cheaper and more prevalent. With a loose interconnection of computers hardwired or telephonically connected across the country, the defense experts reasoned that many alternative paths for message transmission would exist at any given time. In the event that one message path was lost, an alternative message path could be established and utilized in its place. Hence, it was the organized and non-centralized qualities of this communications system which made it appealing to the military as a backup communication medium. If any one computer or set of computers was attacked or disconnected, many other alternative paths could eventually be found and established.

0003This interconnection of computers has since been developed by universities and businesses into a worldwide network that is presently known as the Internet. The Internet, as configured today, is a publicly accessible digital data transmission network which is primarily composed of terrestrial communications facilities. Access to this worldwide network is relatively low cost, and hence, it has become increasingly popular for such tasks as electronic mailing and weather page browsing. Both such functions are badge or file transfer oriented. Electronic mail, for instance, allows a user to compose a letter and transmit it over the Internet to an electronic destination. For Internet transfers, it s relatively unimportant how long each file transfer takes as long as it is reasonable. The Internet messages are routed, not through a fixed path, but rather through various interconnected computers until they have reached their destination. During heavy message load periods, messages will be held at various internal network computers until the pathways cleared for new transmissions. Accordingly, Internet transmissions are effective, but cannot be relied upon for time sensitive applications.

0004Web pages are collections of data including text, audio, video, and interlaced computer programs. Each web page has a specific electronic site destination which is accessed through a device known as a web server, and can be accessed by anyone through via Internet. Web page browsing allows a person to inspect the contents of a web page on a remote server to glean various information contained therein, including for instance product data, company backgrounds, and other such information which can be digitized. The remote server data is access by a local browser, and the information is displayed as text, graphics, audio, and video.

0005The web browsing process, therefore, is a two-way data communication between the browsing user, who has a specific electronic address or destination, and the web page, which also has a specific electronic destination. In this mode of operation, as opposed to electronic mail functions, responsiveness of the network is paramount since the user expects a quick response to each digital request. As such, each browsing user establishes a two-way data communication, which ties up an entire segment of bandwidth on the Internet system.

0006Recent developments on the Internet include telephone, video phone, conferencing and broadcasting applications. Each of these technologies places a similar real-time demand on the Internet. Real-time Internet communication involves a constant two-way throughput of data between the users and the data must be received by each user nearly immediately after its transmission by the other user. However, the original design of the Internet to did not anticipate such real-time data transmission requirements. As such, these new applications have serious technical hurdles to overcome in order to become viable.

0007Products which place real-time demands on the Internet will be aided by the introduction of an updated hardware interconnection configurations or backbone,” which provides wider bandwidth transmission capabilities. For instance, the MCI backbone was recently upgraded to 622 megabytes per second. Regardless of such increased bandwidth, the interconnection configuration is comprised of various routers which may still not be fast enough and can therefore significantly degrade the overall end-to-end performance of the traffic on the Internet. Moreover, even with a bandwidth capability of 622 megabytes per second, the Internet backbone can maximally carry only the following amounts of data: 414-1.5 mbs data streams; 4,859-128 kbs data streams; 21597-28.8 kbs data streams; or combinations thereof. While this has anticipated as being sufficient by various Internet providers, it will quickly prove to be inadequate for near-future applications.

0008Internal networks, or Intranet sites, might also be used for data transfer and utilize the same technology as the Internet. Intranets, however, are privately owned and operated and are not accessible by the general public. Message and data traffic in such private networks is generally much lower than more crowded public networks. Intranets are typically much more expensive for connect time, and therefore any related increase in throughput comes at a significantly higher price to the user.

0009To maximize accessibility of certain data, broadcasts of radio shows, sporting events, and the like are currently provided via Internet connections whereby the broadcast is accessible through a specific web page connection. However, as detailed above, each web page connection requires a high throughput two-way connection through the standard Internet architecture. A given Internet backbone will be quickly overburdened with users if the entire set of potential broadcasters across world began to provide broadcast services via such web page connections. Such broadcast methods through the Internet thereby prove to be ineffective given the two-way data throughput needed to access web pages and real-time data.

0010Furthermore, broadcasts are typically funded and driven by advertising concerns. However, a broadcast provided through a centralized location, such as a web page for a real-time Internet connection, will be limited by practical concerns to offering only nationally advertised products, such as Coke or Pepsi. Since people might be connected to this web page from around the world, local merchants would have little incentive to pay to advertise to distant customers outside of their marketing area. Local merchants, on the other hand, would want to inject their local advertising into the data transmission or broadcasts in such a way not currently available on the Internet.

0011There is an enormous demand for the delivery of large amounts of content to a large number of listeners. The broadcast channels of today, such as radio and TV, can only deliver a small number of channels to a large number of listeners. Their delivery mechanism is well known to customers. The broadcaster transmits programs and the listener must tune in” at the proper time and channel to receive the desired show, “On Demand’ systems have been attempted by the cable industry. Such systems attempt to transport the program or show from a central repository (server) to the user (client) in response to his/her request. To initiate the request, the user selects from a list of candidate programs and requests that the system deliver the selected program.

0012The foregoing “on demand’ model of content delivery has placed two significant requirements on the delivery system. First, there typically is a direct connection between each content storage device (server) and each listener (client). The phone system is, an example of such a point-to-point interconnection system. Another example of such an interconnection system is the Internet, which is also largely based on the terrestrial telecommunications networks. Second, the server typically seeks to provide the capability of delivering all the programs to the requesting clients at the time that the client demands the programming.

0013The foregoing requirements can be achieved with limited success, particularly in conjunction with the Internet. The Internet is not suitable for many types of high bandwidth or on-demand systems. In today's Internet, Internet users most often share a terrestrial or perhaps even extra-terrestrial or wireless communications infrastructure; and as a result the total throughput is limited. In other words, the Internet is typically a party line shared by a large number of users and each subscriber must wait for the line to be free before he/she can send data. Since the signal from the server is generally a high bandwidth signal including multimedia content, any degradation of the throughput from the server to the clients results in an annoying disruption of the video and/or audio at the clients. Successful transmission of real-time streaming multimedia content, however, requires sufficient transmission bandwidth between the server and the client. Since standard IP transmission facilities are a party line, attempts have been made to impose a quality of service (QOS) into this dominantly party-line transmission structure. One such QOS feature is the bandwidth reservation protocol called “RSVP.” The RSVP protocol must be active in each network element along the path from the client to the server for it to be effective. Until RSVP is fully enabled, QOS cannot be guaranteed.

0014Once RSVP is fully deployed, then the mechanical process of reserving bandwidth will be possible to some degree. Nevertheless, even with RSVP, the problem remains that the Internet infrastructure provides limited transmission bandwidth. In this regard, consider the case where the sum of all bandwidth reservations exceeds available transmission bandwidth. To reduce the excessive use of bandwidth reservation, transmission providers anticipate transmission charges based on the amount of bandwidth reserved. This bandwidth charge is not in the spirit of today's free connectivity.

0015Another example of the limitations inherent in the finite throughput of the Internet is the generally limited audience size for a given transmission link. For example, if there is a 622 megabit/second (mbs) link from an Internet server in New York to a number of clients in Los Angeles and each client requires a separate 28.8 kilobit/sec (kbs) connection to the server, then this link can only support about 22,000 clients, a relatively small number of clients when compared to the cost of a server capable of supplying the 622 mbs data content. The costs further escalate and the client audience size capability further diminishes as each client connects to the server using higher bandwidth modems or the like. Still further, the same large demand is placed on the server if each of the 22,000 clients requests the same program but at different times or if each of the clients request a different program at the same, or nearly the same time. The large bandwidth requirements (622 mbs) to supply a relatively small number of clients (22,000) coupled with the stringent requirements placed on the server to supply the content to each client has created problems that “on-demand” systems have yet to economically overcome.

0016One prior art development in the LAN/WAN technology is called “multicasting.” Multicasting in LAN/WAN parlance means that only one copy of a signal is used until the last possible moment. For example, if a server in New York wants to deliver the same data to someone in Kansas City, Dallas, San Francisco, and Los Angeles, then only one signal needs to be sent to Kansas City. There it would be replicated and sent separately to San Francisco, Los Angeles, and Dallas. Thus the transmission costs and bandwidth used by the transmission would be minimized and the server in New York would only have to send one copy of the signal to Kansas City. This scenario is illustrated in <figref idref="DRAWINGS">FIG. 1A</figref>.

0017Multicasting helps to somewhat mitigate the transmission costs but there are still a great number of cases where it provides little optimization. For example, if there is one person in each city in the US that wants to view the same program generated by the server in New York, then the server must send the signal to all those cities, effectively multiplying the amount of bandwidth used on the network. As such, the transmission is still expensive. Further, the multicast system model breaks down at high bandwidths and during periods of low data throughput within the Internet infrastructure, resulting in annoying degradation of the transmission content.

0018Another issue is distribution of information between autonomous systems. This is called peering. <figref idref="DRAWINGS">FIG. 1B</figref> shows three autonomous simple systems labeled AS<b>0</b>, AS<b>1</b> and AS<b>2</b>. These autonomous systems are self contained networks consisting of host computers (clients and servers) interconnected by transmission facilities. Each autonomous system is connected to other autonomous systems by peering links. These are shown in <figref idref="DRAWINGS">FIG. 1B</figref> by the transmission facilities labeled PL<b>01</b>, PL<b>02</b> and PL<b>12</b>.

0019Peering allows a host in one autonomous system to communicate with a host in a different autonomous system. This requires that the routers at the end of the peering links know how to route traffic from one system to the other. Special routing protocols, such as boundary gateway protocol, enable the interconnection of autonomous systems.

0020Assume that host H<b>1</b> in AS<b>0</b> wants to communicate with host H<b>2</b> in AS<b>1</b> and H<b>3</b> in AS<b>2</b>. To do this, H<b>1</b> communicates with PL<b>01</b> to reach H<b>2</b> and PL<b>02</b> to reach H<b>3</b>. If host H<b>1</b> wants to multicast a message to multiple hosts in each of the autonomous systems, then boundary routers involved must understand the multicast protocols.

0021Backbone providers that form each of autonomous systems are reluctant to enable multicast over their peering links because of the unknown load placed on boundary routers and billing issues related to this new traffic which originates outside of their autonomous systems.

0022The present inventors have recognized that a different approach must be taken to provide a large amount of content to a large number of listeners. In their prior art published European patent application, the present inventors proposed a system that abandons the “on-demand” model and point-to-point connection models. In their place, the present inventors combined, among other things, a particular, unique “broadcast” model with localized multicast connections that selectively allow a client to receive the high bandwidth content of the broadcast.

0023As the present inventors' prior published patent application explained, the broadcast model assumes that the server delivers specific content at specific times on a specific channel as is currently done in today's radio and television industry. “Near on demand” can be affected by playing the same content at staggered times on different transmission channels, preferably, dedicated satellite broadcast channels. Localized receivers receive the broadcast channels and convey the content over a network using a multicast protocol that allows any client on the network to selectively access the broadcast content from the single broadcast. This single broadcast provides, in effect, an overlay network that bypasses congestion and other problems in the existing Internet infrastructure.

0024As also explained in the prior published application: <figref idref="DRAWINGS">FIG. 1C</figref> shows how host H<b>1</b> multicast directly to H<b>2</b> and H<b>3</b> via satellite or another dedicated link separate from the backbone of the Internet. This type of interconnection bypasses the peering links and the resulting congestion and billing issues. This type of prior art interconnection maintains, however, a party-line sharing of bandwidth in the dedicated link. It also is, in essence, generally part of a two-way connection adapted to provided TCP/IP information exchange in cooperation with, typically, a terrestrial back channel from the satellite reception entity to the entity providing the content for transmission through the satellite or other dedicated link.

0025The applicants' prior published European application was therefore based on the applicant's discovery of, among other things, the advantage of using a separate dedicated link and implements the resulting solution in a unique manner. Accordingly, the present applicants provided a data transmission system capable of sending multiple channels of broadcast or multicasting data or “content” to receiving computers without being delayed or impaired by the bandwidth and constraints of two-way Internet connections.

0026The applicants' have discovered, however, that one problem with the applicants system is that, although the near-on-demand delivery is very advantageous, by itself, it does not allow for the level of flexibility an Internet user may desire in playing or accessing content on demand and, for example, long after the near-on-demand delivery has terminated for any given content.

0027Another problem that the applicants have discovered is that the broadcast model itself is unduly limited in its ability to meet the demands, and satisfy the needs of, providers of localized or regionalized advertising and similar types of localized content. The satellite broadcast model, for example, typically delivers the same content to all users nationally. This creates a significant problem for distribution of localized content, such as locally tailored advertising, through such a non-localized broadcast system. The providers of such locally tailored advertising frequently do not purchase advertising in such non-localized broadcasts, and the potential market demand for advertising through such mediums is correspondingly limited.

0028Similarly, those who seek to provide locally-tailored advertising have had to seek other avenues (such as dealing individually with localized broadcasters in each localized market) in order to advertise. This effort is time consuming and expensive.

0029Also, even when pursuing locally-tailored advertising, advertisers are often forced by the available traditional media to purchase advertising in unnecessarily large regions or for delivery to recipients who are not as targeted as might be desired by the advertiser. The applicants' embodiment disclosed in the applicants' prior art patent application did not solve this type of problem in and of itself.

SUMMARY OF THE INVENTION

0030The applicants have developed methods and apparatus for multicasting or broadcasting digital data to users accessing an Internet connection. The methods and apparatus preferably include placing digital data that is to be multicast in IP protocol to generate IP digital data. The IP digital data preferably is transmitted from a transmission site to a remote Internet point of presence through a dedicated transmission channel substantially separate from the Internet backbone. The dedicated transmission channel may be, for example, a satellite channel. At the remote Internet point of presence, local commercials preferably can be inserted into the IP digital data and/or the signal can be delayed for later playback. The IP digital data is then preferably multicast for delivery to a receiving Internet users apparatus connected to but distal from the remote Internet point of presence.

0031As will be readily recognized, the foregoing method and apparatus eliminate, or reduce the severity of, problems discussed above in connection with existing multicast or broadcasting systems. Further, since the principal equipment used to implement the method is disposed at the point of the Internet Service Provider, the normal psychological reluctance of an Internet user to purchase extraneous multicast equipment is avoided. Other significant advantages of the applicants' disclosed apparatus and method will become apparent.

BRIEF DESCRIPTION OF THE DRAWINGS

0032<figref idref="DRAWINGS">FIGS. 1A and 1B</figref> are drawings used to illustrate problems in inter-city, communications over, for example, the Internet using conventional systems.

0033<figref idref="DRAWINGS">FIG. 1C</figref> illustrates an alternative delivery system to the system of <figref idref="DRAWINGS">FIG. 1B</figref>.

0034<figref idref="DRAWINGS">FIG. 1D</figref> illustrates a conventional network architecture.

0035<figref idref="DRAWINGS">FIG. 2</figref> illustrates a hybrid broadcast I multicast network constructed in accordance with one embodiment of the present invention.

0036<figref idref="DRAWINGS">FIG. 3</figref> illustrates one manner in which the Internet Protocol addresses may be mapped at an Internet Service Provider.

0037<figref idref="DRAWINGS">FIG. 4</figref> is a block diagram of one embodiment of a file server station, such as one suitable for use in the conventional system of <figref idref="DRAWINGS">FIG. 1</figref>.

0038<figref idref="DRAWINGS">FIG. 5</figref> illustrates one embodiment of a routine station constructed in accordance with one embodiment of the present invention and its connection within a network domain.

0039<figref idref="DRAWINGS">FIGS. 6 and 7</figref> illustrate use of a routing station constructed in accordance lip the invention and its connection at an Internet Service Provider.

0040<figref idref="DRAWINGS">FIG. 8a</figref> illustrates one embodiment of an uplink site suitable for use in the network of <figref idref="DRAWINGS">FIG. 2</figref>.

0041<figref idref="DRAWINGS">FIG. 8b</figref> illustrates one embodiment of a downlink site suitable for use in the network of <figref idref="DRAWINGS">FIG. 2</figref>.

0042<figref idref="DRAWINGS">FIGS. 9-11</figref> illustrate various embodiments of downlink sites suitable for use in the network of <figref idref="DRAWINGS">FIG. 2</figref>.

0043<figref idref="DRAWINGS">FIGS. 12 and 13</figref> illustrate various manners in which various components of a downlink site may be modularized and interconnected.

0044<figref idref="DRAWINGS">FIG. 14</figref> illustrates one embodiment of the multicast system at an ISP with distributed POPs that are interconnected with one another.

0045<figref idref="DRAWINGS">FIGS. 15 and 16</figref> illustrate one embodiment of an IPMS.

0046<figref idref="DRAWINGS">FIG. 17</figref> illustrates a packet protocol that may be used by the controller unit to communicate through the monitor and control interface software.

0047<figref idref="DRAWINGS">FIG. 18</figref> illustrates one embodiment of a transponder unit.

0048<figref idref="DRAWINGS">FIG. 19</figref> is a schematic block diagram of selected components of one embodiment of a transponder unit including a descrambler.

0049<figref idref="DRAWINGS">FIG. 20</figref> illustrates one embodiment of a packet filter used in the transponder unit of <figref idref="DRAWINGS">FIG. 18</figref>.

0050<figref idref="DRAWINGS">FIGS. 21-26</figref> illustrate various configurations for networks using an IPMS constructed in accordance with the present invention.

0051<figref idref="DRAWINGS">FIGS. 27-29</figref> illustrate a further manner of deploying the present system at an ISP.

0052<figref idref="DRAWINGS">FIG. 30</figref> illustrates one example of a web page layout for use in selecting baud rate of a video transmission at a user of the present system.

DETAILED DESCRIPTION OF THE INVENTION

0053The current networking architecture of today is generally illustrated in <figref idref="DRAWINGS">FIG. 1D</figref>. As illustrated, the network, shown generally at <b>50</b>, comprises a group of host computers H<b>1</b>-H<b>6</b> that are interconnected by transmission links P<b>1</b>-P<b>13</b> and routers R<b>1</b>-R<b>6</b> to form a LAN/WAN. An aggregated group of hosts is called a domain. Domains are grouped into autonomous systems that are, in-turn, interconnected together to form a network. When these networks span a large geographic area, they are called a wide area network or WAN. An example of this network architecture is the Internet and is illustrated in <figref idref="DRAWINGS">FIG. 1D</figref>.

0054At each interconnection node is a device called a router, designated here as R<b>1</b>-R<b>6</b>. The function of the router is to receive an input packet of information, examine its source and destination address, and determine the optimal output port for the message. These receive, route determinations, and transmit functions are central to all routers.

0055If host H<b>1</b> wants to send a message to host H<b>3</b>, there are a variety of paths that the signal could take. For example, the signal could be transmitted along the transmission path formed by P<b>1</b>-P<b>4</b>-P<b>8</b>-P<b>10</b>. Other alternatives include the paths formed by P<b>1</b>-P<b>2</b>-P<b>5</b>-P<b>7</b>-P<b>9</b>-P<b>10</b> or P<b>1</b>-P<b>4</b>-P<b>6</b>-P<b>7</b>-P<b>9</b>-P<b>10</b>. The function of the router is to determine the next path to take based on the source and destination address. The router might use factors such as data link speed or cost per bit to determine the best path for the message to follow.

0056As more host computers are brought on-line, more domains are created. Each time a domain is created, any router associated with the domain must announce to its peers that it is present and ready to accept traffic. Conversely if a domain is deleted, the system must respond by removing the paths and rerouting all messages around the removed domain. In any large network there will be a constant addition and removal of domains. The success of the network architecture to respond to these changes is at the core of the networking problem. To this end, each router communicates with its peers to announce to the network or networks it services. This implies that a bi-directional link should exist at each router. Terrestrial telephone circuits have traditionally supplied these links on the Internet.

0057<figref idref="DRAWINGS">FIG. 2</figref> illustrates a hybrid broadcast/multicast constructed in accordance with one embodiment of the present invention. The system is illustrated in the context of a plurality of interconnected Internet domains A, B, and C. As noted above, a domain is an aggregate of one or more hosts. For example, domain A may be a corporate LAN while domain B may be a LAN at an educational institution or the like. In the illustrated embodiment, domain C is shown as an Internet Service Provider (ISP) that usually sells local access to the Internet through its domain. As such, domain C includes at least one access router R<b>7</b> having one or more modems through which local but remotely located ISP customers (hosts) <b>60</b> connect to the domain through POTS, T1 lines, or other terrestrial links. From domain C, the ISP customers <b>60</b> are connected to the Internet.

0058In the preferred embodiment, a file server station <b>100</b> is used to store and transmit broadcast transmissions to a satellite <b>55</b>. As will be set forth in further detail below, the file server station <b>100</b> includes one or more file servers that can provide, for example, multimedia content in TCP/IP format. The multimedia data is then encapsulated in HDLC or similar frame format and modulated to RF for transmission over one or more uplink channels of the satellite <b>55</b>. The satellite <b>55</b> re-transmits the HDSL encapsulated frames on one or more downlink channels having different carrier frequencies than the uplink channels. The downlink transmissions are concurrently received by domains A, B, and C at local routine stations x<b>1</b>, x<b>2</b>, x<b>3</b>. At each routing station x<b>1</b>, x<b>2</b>, x<b>3</b>, the original TCP/IP data transmitted from the file server station <b>100</b> is extracted from the received HDLC frames. The extracted TCP/IP data is selectively supplied to hosts within the domain that have made a request to receive the data.

0059This satellite <b>55</b> network in effect provides an overlay network that bypasses or at least somewhat avoids congestion and limitations in at least some of the existing Internet infrastructure, such as in <figref idref="DRAWINGS">FIG. 1</figref>. Moreover, this satellite <b>55</b> network provides dedicated, guaranteed bandwidth for the transmission of multimedia data through the satellite <b>55</b>.

0060In the preferred embodiment, the transmissions from the file server station <b>100</b> preferably include one or more multimedia transmissions formatted in accordance with the IP multicast protocol. IP Multicast is an extension to the standard IP network-level protocol. RFC 1112, Host Extensions for IP Multicasting, authored by Steve Deering in 1989, describes IP Multicasting as: “the transmission of an IP datagram to a ‘host group’, a set of zero or more hosts identified by a single IP destination address. A multicast datagram is delivered to all members of its destination host group with the same ‘best-efforts’ reliability as regular unicast IP datagrams. The membership of a host group is dynamic; that is, hosts may join and leave groups at any time. There is no restriction on the location or number of members in a host group. A host may be a member of more than one group at a time.” In addition, at the application level, a single group address may have multiple data streams on different port numbers, on different sockets, in one or more applications.

0061IP Multicast uses Class D Internet Protocol addresses, those with 1110 as their high-order four bits, to specify groups of IPMS units <b>120</b>. In Internet standard “dotted decimal” notation, host group addresses range from 224.0.0.0 to 239.255.255.255. Two types of group addresses are supported: permanent and temporary. Examples of permanent addresses, as assigned by the Internet Assigned Numbers Authority (LANA), are 224.0.0.1, the “all-hosts group” used to address all IP IPMS units <b>120</b> on the directly connected network, and 224.0.0.2, which addresses all routers on a LAN. The range of addresses between 224.0.0.0 and 224.0.0.255 is reserved for routing protocols and other low-level topoloyy discovery or maintenance protocols. Other addresses and ranges have been reserved for applications such as 224.0.13.000 to 224.0.13.255 for Net News (a text based service). These reserved IP Multicast addresses are listed in RFC 1700, “Assigned Numbers.” Preferably, transmissions from the file server <b>100</b> containing related multimedia content are transmitted using a permanent address. Even more preferably, the same multimedia content is provided by the file server system <b>100</b> at multiple data rates using different permanent addresses.

0062For example, a multimedia file containing an automobile commercial may be concurrently transmitted for reception at a 28.8 KB data rate, a T1 data rate, an ADSL data rate, etc. The 28.8 KB transmission is transmitted using a first group of one or more permanent addresses. The T1 data rate transmission is transmitted using a second group of one or more permanent addresses, wherein the first group differs from the second group. In this manner, a client having a high speed Internet connection may chose to receive the more desirable high data rate transmissions while a client having a lower speed Internet connection is not precluded from viewing the content due to the availability of the lower speed data transmissions. Additionally, a corresponding web page may be concurrently transmitted along with the multicast data or along the backbone of the Internet.

0063If permanent multicast addresses are not available, the TCP/IP addresses used for the broadcast transmissions may use a block of addresses that are normally designated as administratively scoped addresses. Administratively scoped addresses are used for the transmission of commands and/or data within the confines of a domain for administrative processes and are not supplied outside of the scope of the domain. In other words, any broadcast transmissions received using these administratively scoped addresses desirably remains Within the bounds of the domain in which it is received. All addresses of the form 239.x.y.z are assumed to be administratively scoped. If administratively scoped addresses are used, provisions must be made to ensure that the domain does not use an administratively scoped address that is within the designated broadcast block for other system functions. This may be accomplished in one of at least two different manners. First, the domain can be reprogrammed to move the administratively scoped address used for the other system function to an administratively scoped address that does not lie within the broadcast block. Second, the routing station may perform an address translation for any administratively scoped addresses within the broadcast block that conflict with an administratively seeped address used for other purpose by the domain. This translation would place the originally conflicting address outside the conflict range but still maintain the address within the range of permissible administratively scoped addresses. As above, the same multimedia content is transmitted concurrently using different transmission data rates.

0064With respect to the use of administratively scoped addresses, assume that the system will utilize a block of addresses that contain 65,535 addresses (16 bits of address space). This block will utilize a predetermined, default address block. For the sake of this description, assume that the system default address space is defined as 239.117.0.0 to 239.117.255.255. This address space is defined by fixing the upper two bytes of the address space (in this case 239.117) while merely varying the lower two bytes of data to allocate or change the address of a channel of TCP/IP multimedia data. This addressing scheme, in and of itself, will provide the system with 64K possible channels but it may place restrictions on the ISP environment since they would be required to have a dedicated block of 64K address space, one in which none of the 64K addresses are being used by other applications. This may not always be feasible. In order avoid this kind of limitation, the system may only actually utilize the first 16K of the predefined address space. This will allow 16K channels for the entire system, which corresponds to a minimum aggregate data rate of 470 MHz (assuming every channel is running the minimum data rate of 28.8 kbps).

0065Even with the limited number of addresses, there are still two potential types of problems within the ISP environment. In the first type of problem, a limited number of the system broadcast addresses are already in use at the ISP or other domain type. In the second type of potential problem, a large block of the system broadcast address space is being used at the ISP or other domain type. In either case, the IPMS must be able to provide a solution for these two types of problems. These two cases are preferably addressed differently.

0066The most likely address conflict to be encountered in an ISP is the first one noted above, designated here as the “limited address” conflict. This type of conflict occurs when a single address or several isolated addresses within the broadcast address range are already allocated within the ISP or other domain type. The fact that only 16K addresses out of the 64K address block are used will provide a means for routine “around” these limited address conflicts.

0067As illustrated in <figref idref="DRAWINGS">FIG. 3</figref>, the 64K address space shown generally at <b>80</b> will be divided into four 16K address blocks <b>85</b>. The following diagram shows how the address blocks are defined. The system default addresses are all located in block 0 which begins at address 0 of the administratively scoped addresses.

0068The ISP or domain will setup a “routing table” within a routing station of the domain that indicates all of the administratively scoped addresses used within the ISP or domain. The routing station is programmed to re-route addresses with conflicts to the next available address block. For example, if the ISP has address 239.117.1.11 already assigned, the routing station routes this address to the next available block. The next available address block is found by adding 64 to the second byte of the IP address. For this service the next address would be 239.117.65.11. If this address is free, this is where the routing station re-routes the data associated with the conflicting address. Four alternate addresses may be assigned for rerouting a single channel having a conflicting address.

0069The address re-routing scheme should be implemented on both the routing station end and in any client Plug-In software used to receive the data. On the routing station side, once the ISP enters all address conflicts, the routing station performs address translation on all of the addresses that conflicts occur. All packets have their addresses re-mapped to the new location. If a single address can not be re-routed (all four address blocks are used for a given channel) then the receiver performs major address block re-routing as would occur in address block conflict management described below. On the client software side, the client opens sockets for all four address blocks (either sequentially or simultaneously). The address that provides valid broadcast data is accepted as the correct channel. The three other sockets are closed. If none of the addresses provide valid data, the client tries the alternate address block as defined below.

0070Alternative strategies for reconciling addressing conflicts may also be employed. As an example, an agent might be implemented with the IPMS which could be queried by the client for the appropriate address to use at a particular location. Such a query would include a “logical” channel number associated with the desired broadcast. The agent would then respond with the specific IP Address locally employed for that broadcast.

0071If a large number of addresses conflict with the default system address space, an alternate block of addresses will be used. The system defines the exact alternate address space (or spaces), but as an example, if 239.117.X.Y is the primary default broadcast block, an address space like 239.189.X.Y might be used as an alternate. In any event, the routing station will determine, based on the address conflicts entered by the ISP, if the entire broadcast address block must be re-routed. If it does, the routine station will modify each broadcast channel's address. As described above, if the client software can not find a valid broadcast stream within the standard address block, the alternate address space will be tried.

0072Routing multicast traffic is different than the routing of ordinary traffic on a network. A multicast address identifies a particular transmission session, rather than a specific physical destination. An individual host is able to join an ongoing multicast session by issuing a command that is communicated to a subnet router. This may take place by issuing a “join” command from, for example, an ISP customer to the ISP provider which, in turn, commands its subnet router to route the desired session content to the host to which the requesting ISP customer is connected. The host may then send the content using, for example, PPP protocol to the ISP customer.

0073Since the broadcast transmission is provided over a dedicated transmission medium (the satellite in the illustrated embodiment), problems normally associated with unknown traffic volumes over a limited bandwidth transmission medium are eliminated. Additionally, the number of point-to-point connections necessary to reach a large audience is reduced since the system uses localized connections within or to the domain to allow clients to join and receive the broadcast. In the illustrated embodiment, a virtually unlimited number of domains may receive the broadcast and supply the broadcast to their respective clients, additional domains being added with only the cost of the routing station at the domain involved. In most instances, ISPs or the like need only add a routing station, such as at x<b>1</b> et seq., and may use their existing infrastructure for receiving broadcasts from the routing station for transmission to joined clients. This is due to the fact that most ISPs and the like are already multicast enabled using the IP multicast protocol.

0074<figref idref="DRAWINGS">FIG. 4</figref> illustrates a block diagram of one embodiment of a file server station, such as the one illustrated at <b>100</b> of <figref idref="DRAWINGS">FIG. 1</figref>. The file server station, shown generally at <b>100</b>, comprises a local area network <b>102</b> with a collection of server PCs <b>105</b> connected to a router <b>110</b> over the local area network <b>102</b>. The server PCs <b>105</b> include server software that either reads pre-compressed files from the local disk drive and/or performs real time compression of analog real time data. Each server <b>105</b> provides this data as output over the local area network.

0075The LAN <b>102</b> performs the function of multiplexing all the streaming data from the server PCs <b>105</b>. The LAN <b>102</b> should have sufficient bandwidth to handle all the data from the server PCs <b>105</b>. In present practice, 100 mbs LANs are common and, thus, it is quite feasible to use 100 mbs LANs to aggregate the data output to a 30 mbs transponder. A common type of LAN is or 100Base T, referring to 100 mbs over twisted pair wire.

0076The functionality required at <b>110</b> is to gather the packets of data from the LAN <b>102</b>, wrap them in a transport protocol such as HDLC, and convert the HDLC packets to the proper voltage levels (such as R5422). The functionality can be provided by the composite signal provided from the router <b>110</b> usually comprises clock and data signals The composite signals are output from the router <b>110</b> for synchronous modulation by a satellite uplink modulator <b>115</b> which synchronously modulates the data to the proper RF carrier frequencies and transmits the resulting signal through an antenna <b>122</b> to the satellite <b>55</b>.

0077One or more server PCs <b>105</b> of the LAN <b>102</b> store the multimedia content that is to be broadcast to the domains. Alternatively, the one or more PCs <b>105</b> may receive pre-recorded or live analog video or audio source signals and provide the necessary analog-to-digital conversion, compression, and TCP/IP packet forming for output onto the LAN wanted. These packets are transported over the LAN <b>102</b> in an asynchronous manner. The router <b>110</b> then receives these asynchronous packets and encapsulates them with the transport protocol and transmits them in a synchronous manner to the satellite <b>55</b>. The constant conversion from one form to another is provided to fit the transmission technologies of the transmission equipment. LANs are becoming ubiquitous and low cost since it leverages the high manufacturing volumes of the consumer/corporate PC market. Satellite transmission is extremely cost effective for broadcasting signals to multiple destinations and is inherently synchronous (data is transmitted at precise intervals). Accordingly, the foregoing system is currently the most straight forward and lowest cost method to architect a system a connecting computer LANs to a satellite transmission system.

0078A typical satellite <b>55</b> has two antennas, one for receiving the signal from the uplink and the second antenna for transmitting the signal to the downlink. An amplifier is disposed between the two antennas. This amplifier is responsible for boosting the level of the signal received from the file server station <b>100</b> (uplink). The received signal is very weak because of the distance between the uplink and the satellite (typically about 23,000 miles). The received signal is amplified and sent to the second antenna. The signal from the second antenna travels back to downlinks which are again about 23,000 miles away. In the illustrated embodiment of the system, the downlinks are the routing stations.

0079The signal is transmitted by the uplink at one frequency and shifted to a different frequency in the satellite before amplification. Thus, the signal received by the satellite is different from the frequency of the signal transmitted. The transmitted information content is identical to the received information.

0080A typical satellite has approximately 20 to 30 RF amplifiers, each tuned to a different frequency. Each of these receive/transmit frequency subsystems is called a transponder. The bandwidth of each of the transponders is typically about 30 MHz but can vary satellite to satellite.

0081At the file server station <b>100</b>, the composite signal from the router <b>110</b> is preferably QPSK modulated by the satellite uplink modulator. During the modulation process, extra bits are usually added to the original signal. These extra bits are used by a receiver at the downlink to correct any errors which might occur during the 46,000 mile transmission. The extra protection bits that are a added to the data stream are called Forward Error Correction bits (FEC).

0082The resulting modulation and error correction process typically allows about 1 megabit/second of data to occupy about 1 megahertz (MHz) of bandwidth on the transponder. Thus, on a 30 MHz bandwidth transponder, one can transmit about 30 mbs of data. The aggregate data rate of the signals generated by all server PCs <b>105</b>, including the overhead of the underlying transmission protocols (IP and HDLC), must be less that the bandwidth of the satellite transponder.

0083<figref idref="DRAWINGS">FIG. 5</figref> illustrates one embodiment of a routing station and its connection within a domain. Here, the routing station is called an IP Multicast Switch (IPMS), labeled as <b>120</b> in <figref idref="DRAWINGS">FIG. 5</figref>. The IPMS <b>120</b> is comprised of a demodulator <b>125</b> that receives the radio frequency signals from the satellite <b>55</b> over receive antenna <b>130</b> and converts them into the original TCP/IP digital data stream. These digital signals are then input to a device called a IP Multicast Filter (IPMF) <b>140</b> that in-turn selectively provides the signals as output onto a LAN, shown generally at <b>145</b>, having sufficient capacity to handle all the received signals. The IPMS <b>120</b> is multicast enabled, meaning that data is only output from the IPMF <b>140</b> onto the LAN <b>145</b> if a client <b>160</b> requests a connection to receive a broadcast channel. As noted above; this multicast protocol may be one such as defined in RFC 1112.

0084As illustrated, the LAN <b>145</b> can be connected to the Internet <b>165</b> through a router <b>170</b>. If the broadcast data output on the LAN <b>145</b> uses administratively scoped addresses, the router <b>170</b> can prevent forwarding of the data to the Internet <b>165</b>. This is a desirable feature associated with the use of administratively scoped addresses, as the broadcast can be localized and blocked from congesting the Internet <b>165</b>. If other addresses are used, such as permanent IP multicast addresses, the router <b>170</b> is programmed to prevent data having an IP multicast address from being broadcast on the Internet <b>165</b>.

0085The software of the IPMS <b>120</b> is capable of operating in an IP multicast network. In the embodiment described here, the control structure of the multicast software in the IPMS <b>120</b> has four main threads: initialization, multicast packet handling, LAN packet handling, and multicast client monitoring. In the initialization thread, a table used to determine whether a client has joined a broadcast has its content set to an empty state. Initialization is performed before any of the other threads are executed.

0086The multicast packet handling thread is responsible for reading data from the satellite demodulator and deciding what is to be done with it. To this end, the thread reads each multicast packet received from the satellite demodulator <b>125</b>. If the multicast group address specified in the received packet is not in a group table designating the groups received from the satellite <b>55</b> by the demodulator <b>125</b>, the group address is added to the group table and set to “not joined.” If the multicast group address specified in the packet is specified in the join table as having been joined by a client, the packet is output through the IPMS <b>120</b> to the LAN <b>145</b> for receipt by a requesting client <b>160</b>. If none of the foregoing tests are applicable, the packet is simply ignored.

0087The LAN packet handling thread is used to determine whether a join command has been received from a client <b>160</b> over the LAN <b>145</b>. To this end, the IPMS <b>120</b> reads an IP packet from the LAN <b>145</b>. If the packet is a request from a client <b>160</b> to join the multicast session and it is in a group table (a table identifying groups which the IPMS <b>120</b> is authorized to receive), the group address is added to the list of joined addresses in the join table. In all other circumstances, the packet may be ignored.

0088The multicast client monitoring thread is responsible for performing periodic checking to ensure that a multicast client who has joined a broadcast is still present on the LAN <b>145</b>. In accordance with RFC 1121, every predetermined number of seconds, or portions thereof, for each group address in the group table which has joined the multicast session a query is sent to that address and the IPMS <b>120</b> waits for a response. If there is no response, the IPMS <b>120</b> assumes that all joined clients have terminated and removes the group address from the joined list.

0089It will be recognized that other further software threads and variations on the foregoing threads may be used. However, in the simplest form of the illustrated embodiment, the four threads described above are all that is practically needed for effective IPMS operation where the IPMS <b>120</b> is disposed at an outer edge of a domain network. This simplification provides a reduction in complexity in the IPMS <b>120</b>.

0090If there are one or more routers between the IPMS <b>120</b> and the multicast client <b>160</b>, then the IPMS <b>120</b> is programmed to understand the various multicast protocols such as DVMRP, MOSPF and RIM. These protocols are well known and can easily be implemented in the IPMS <b>120</b>.

0091In either configuration, the IPMS <b>120</b> appears to the domain network as the source of the data, and the satellite link effectively places an identical server at each downlink location in the separate domains described in connection with <figref idref="DRAWINGS">FIG. 2</figref>.

0092It is generally preferable to have the IPMS <b>120</b> as close as possible to the last point in the network before transmission to a client. This close proximity to the client minimizes the traffic burden on other system routers and the overall local LAN. The Internet Service Provider's (ISP) local Point of Presence (POP) is generally the optimum location for placement of the IPMS <b>120</b> at an ISP. Such a configuration is illustrated in <figref idref="DRAWINGS">FIG. 6</figref>.

0093As shown in <figref idref="DRAWINGS">FIG. 6</figref>, the ISP, shown generally at <b>200</b>, is connected via an access router <b>205</b> to the Internet <b>165</b>. If a distribution router <b>210</b> is located some distance from the Internet access router <b>205</b>, then inter-POP communications are required through one or more intermediate routers <b>207</b>. These inter-POP communications may take place via frame relay or SMDS (Switched Multimegabit Data Service) since these are relatively inexpensive communication methods. In the POP <b>215</b>, the IPMS <b>120</b> is connected to the backbone LAN <b>220</b>. This LAN <b>220</b> is connected to the distribution router <b>210</b> and provides the connectivity to the customer base. Typically, the distribution router <b>210</b> is connected to a Local Exchange Carrier (LEC) <b>230</b> through telephone company interconnects such as T1, T3, and ATM lines and, thereafter, to remotely located home users/clients <b>235</b>.

0094The architecture of <figref idref="DRAWINGS">FIG. 6</figref> allows customers <b>235</b> to place local (free) calls into the distribution router <b>210</b> that, in turn, allows the customers <b>235</b> to access the Internet <b>165</b> through some remote access point. If the POP <b>215</b> and the Internet access at access router <b>205</b> are co-located, then the ISP LAN <b>240</b> and the POP Backbone LAN <b>220</b> are one in the same and there are no intermediate routers or intervening inter-POP communications.

0095<figref idref="DRAWINGS">FIG. 7</figref> illustrates a system in which the IPMS <b>120</b> is not disposed at the POP <b>215</b> location. This arrangement is functional, but requires a large amount of bandwidth over the inter-POP communication lines <b>245</b>. The configuration shown in <figref idref="DRAWINGS">FIG. 6</figref> minimizes the bandwidth requirements of the router interconnections relative to the configuration shown in <figref idref="DRAWINGS">FIG. 7</figref> since only the POP Backbone IAN should include both the traditional Internet traffic as well as the Multicast traffic.

0096As can be seen from examination of <figref idref="DRAWINGS">FIGS. 6 and 7</figref>, the addition of multicast equipment to the ISP's POP <b>215</b> is minimal. It is also possible and desirable to add a traffic server PC <b>255</b> onto the LAN of the ISP <b>200</b> having the IPMF <b>120</b> (also known as a multicast switch). This traffic server <b>255</b> can be used for a varies of purposes, but in the embodiment shown here, it is used to store information received from the satellite <b>55</b> and the Internet <b>165</b> for later playback. It also can be used to monitor the number and identification of a connected user as well as performing other functions. For example, when a user selects a video/audio multicast channel to view/hear, it sends a specific IGMP message over the LAN that is directed to the IPMS <b>120</b>. This message can also be monitored by all systems connected to the LAN. Specifically, the traffic server <b>255</b> may monitor the communication between the router <b>210</b> and any connected clients and may also monitor the number of connections to the multicast channels. The connection information gathered by the traffic server <b>255</b> is preferably relayed to a central server or the like over the Internet <b>165</b> at periodic intervals for consolidation at a central facility.

0097One advantage of the foregoing system architecture is that it provides a scaleable architecture that may be scaled to deliver a small number of megabits as well as further scaled to deliver nearly a gigabit of content to a large number of host computers. This architecture is only constrained by satellite transponder capacity, which is typically about 30 mbs per transponder.

0098<figref idref="DRAWINGS">FIGS. 8a and 8b</figref> illustrate the uplink and downlink systems suitable for handling at least 60 mbs. File server stations, such as the one shown at <figref idref="DRAWINGS">FIG. 4</figref>, typically only have a capacity of 30 mbs. As such, the uplink here uses two file server stations <b>100</b>a and <b>100</b>b. On the uplink side, a second cluster of server PCs <b>105</b> is connected to a second router <b>110</b>b, which is connected to the uplink equipment and transmits the signal over the same satellite <b>55</b> using a different transponder frequency. Alternatively, the transmission of signals from the second router <b>110</b>b may be directed to a different satellite than the one used by the first file server station <b>100</b>a. If the two signals are uplinked onto the same satellite, then it is possible to share a common antenna.

0099At the downlink side of <figref idref="DRAWINGS">FIG. 8b</figref>, there are two IPMS units <b>120</b>a and <b>120</b>b, which are each identical to that described above. If the two signals are uplinked on the same satellite, it is possible to share an antenna <b>130</b> on the downlink as shown in <figref idref="DRAWINGS">FIG. 8b</figref>. If not, then two separate antennas are required, one pointing to each of the different satellites. In the scenario shown in <b>8</b>b, the two IPMSs <b>120</b>a and <b>120</b>b are connected to a 100baseT LAN <b>280</b>. The maximum bit-rate delivered to the LAN <b>280</b> is the sum of the individual bit rates of the IPMSs <b>120</b>a and <b>120</b>b, or about 60 mbs. This is a convenient number since the maximum real capacity of a 100BaseT LAN is about 60 mbs.

0100Additional file server stations and IPMSs may be added to the foregoing system to increase the number of available multimedia multicast channels available to the ISP clients. For example, a 90 mbs system may be constructed by adding a further file server station at the uplink side of the system and adding a further IPMS at the ISP POP. This third IPMS, however, presents a problem for a 100BaseT LAN since the total possible throughput can now exceed the allowable LAN bandwidth. The traffic server <b>255</b> can be used to assist in eliminating this problem.

0101At the heart of the multicasting protocol is the fact that generally no unnecessary traffic is forwarded unless someone has requested it. This means that even if there is 90 mbs of total data received from the satellite, there would be no data output to the 100BaseT LAN if there were no clients requesting a connection to it.

0102On the other hand, it is possible that there could be clients requesting placement of the entire 90 mbs on the LAN. Such traffic would saturate the LAN <b>280</b>. To mitigate the problem, there are at least two potential solutions.

0103The first solution is to modify the client software so that it first contacts the traffic server <b>255</b> to determine how much bandwidth is already delivered to the LAN <b>280</b>. If the LAN is already delivering the maximum possible data to other clients, then the client currently trying to connect is given a message stating that the system is too busy.

0104A second solution is to have an IPMS first contact the traffic server <b>255</b> to check the load on the LAN <b>280</b> before providing a channel of multicast data on the LAN <b>280</b>. To this end, the IPMS <b>120</b> contacts the traffic server <b>255</b> after a request has been made for a channel of multicast data but before the data is supplied on the LAN <b>280</b>. If the traffic server <b>255</b> deems that the load is too high, it instructs the IPMS <b>120</b> to ignore the join request and refrain from transmitting the requested group on the LAN <b>280</b>. As a result, the requesting client would not receive the requested video/audio stream. The client software may indicate the failure to receive the requested data upon termination of a predetermined time period and indicate this fact to the user. Nevertheless, the applicants believe that there is a high probability that 90 to 120 mbs of data could be uplinked with no downlink overload on the LAN, since it is highly unlikely that all data rates of all channels would be simultaneously used.

0105The traffic server software could be imbedded into one of the IP Multicast Switches <b>120</b> and thus eliminate separate traffic server hardware <b>255</b>. If the system data is scaled even higher, then the architecture shown in <figref idref="DRAWINGS">FIG. 9</figref> is used at the downlink side of the system. The transmission data rate at the uplink side is obtained by merely adding further file server stations <b>100</b>. The system shown a in <figref idref="DRAWINGS">FIG. 9</figref> adds a new piece of hardware called gigabit switch <b>290</b>. On the right side of the switch <b>290</b> is a connection to the LAN <b>300</b>. The LAN <b>300</b> in this embodiment is capable of handling the total aggregate bandwidth output by all IPMSs <b>120</b>. For the case where each IPMS <b>120</b> is receiving 30 mbs and there are 10 IPMSs, then the aggregate bandwidth is 300 mbs. This implies that the LAN <b>300</b> is capable of handling such traffic.

0106As further illustrated in <figref idref="DRAWINGS">FIG. 9</figref>, a controller <b>310</b> may be used to communicate with the LAN <b>300</b> and, further, with the demodulators <b>125</b> and IPMFs <b>140</b> over a communication bus <b>315</b>. Such an architecture allows the controller <b>310</b> to program the specific operational parameters used by the demodulators and IPMFs. Additionally, the demodulators <b>125</b> and IPMFs <b>140</b> may communicate information such as errors. status, etc., to the controller <b>310</b> for subsequent use by the controller <b>310</b> and/or operator of the routing station. Still further, the traffic server <b>255</b> may be used to facilitate inter-module communications between the IPMFs <b>140</b>.

0107The connections between the IPMF <b>140</b> and the switch <b>290</b> may be the 100BaseT connections shown in the previous figures. This implies that the switch <b>290</b> requires n-100BaseT input ports to accommodate the n-IPMS inputs. The system proposed in <figref idref="DRAWINGS">FIG. 9</figref> assumes the use of gigabit access and distribution routers, gigabit LANs and gigabit switches. Such network components are in the very early stages of deployment.

0108A second architecture that can be used to scale to a large number of a users is shown in <figref idref="DRAWINGS">FIG. 10</figref> and is similar to the architecture shown in <figref idref="DRAWINGS">FIG. 9</figref> in that then both include the satellite demodulators <b>125</b> and the IP Multicast Filters <b>140</b>. The system of <figref idref="DRAWINGS">FIG. 10</figref>, however, replaces the traffic server <b>255</b> with an IP filter <b>325</b> and the gigabit switch <b>290</b> with a standard 100BaseT hub <b>340</b>. Another significant difference between the two architectures is that the Internet access router <b>205</b> of <figref idref="DRAWINGS">FIG. 10</figref> is directly connected to the backbone of the gigabit LAN while the connection for the Internet access by the clients <b>335</b> is through the IP filter <b>325</b> within the LAN interface module. The IP filter <b>325</b> may be implemented by a PC or the like, or by a microcontroller, The IP filter <b>325</b> performs the functions of the traffic server <b>255</b> as well as simple IP packet filtering. It passes each packet received from the Internet without examination or modification. This includes multicast as well as unicast traffic. Packets received from the hub <b>340</b> are examined on a per packet basis. Multicast packets with a group address used by the satellite delivered multicast system (shown here as the Satellite Interface Unit (SIU)) are blocked from traversing onto the Internet. This prevents the Internet Access LAN from overload and serves the function of administratively scoping the multicast traffic to one segment. This architecture also has an added advantage in that the routers used in the domain do not have to be multicast enabled.

0109The architecture shown in <figref idref="DRAWINGS">FIG. 10</figref> can be viewed as dividing an ISP into smaller ISP's within the larger ISP. Each of these mini-ISPs has its own IAN Interface Unit (LIU) <b>405</b>. This architecture places a performance requirement on the IP filter in that it must be capable of processing all packets flowing through it via the 100BaseT LANS to which it is connected.

0110<figref idref="DRAWINGS">FIG. 11</figref> illustrates a further system architecture that replaces the IP filter <b>325</b> of <figref idref="DRAWINGS">FIG. 10</figref> with a traffic server <b>255</b> and uses a 10/100 BaseT switch <b>410</b> in place of the IP filter <b>325</b>. This architecture requires the 10/100 BaseT switch <b>410</b> to perform the IP multicast filtering that was done in the IP filter <b>325</b>.

0111The interface point <b>417</b> of <figref idref="DRAWINGS">FIG. 11</figref> between the IPMS and a particular ISP LAN segment, may also be facilitated in cases where that LAN segment is remotely located. Standard digital telecommunications services may be employed to serve as electrical “extension cords” to bring the output of the IPMS onto the remotely located segment. This is done through commonly available “CSU/DSUs” that can transform the LAN output of the IPMS into a digital signal compatible with the Network Interface requirements of common communications carriers, and at the remote location, a subsequent translation back into the required 100BT LAN signal.

0112<figref idref="DRAWINGS">FIG. 12</figref> shows one manner of implementing the architectures for the satellite downlink. The IP Multicast Switch <b>120</b> can be functionally and physically divided into a satellite interface unit <b>425</b> and a LAN interface unit <b>430</b>. Multiple LAN interface units <b>430</b> may be connected to a single satellite interface unit <b>425</b>. This allows the satellite reception equipment to be located at a first location and its output distributed to various remotely located LAN interface units. As shown in <figref idref="DRAWINGS">FIG. 3</figref> the basic system architecture of <figref idref="DRAWINGS">FIG. 12</figref> also allows for the distribution of content via an alternate transmission facility such as terrestrial fiber <b>110</b>. Alternatively, these two modules can reside in the same chassis and use the chassis backplane for intermodule communication.

0113<figref idref="DRAWINGS">FIG. 14</figref> illustrates an embodiment of the system at an ISP with distributed POPs that are interconnected with one another. This embodiment of the system isolates the multicast traffic from the unicast traffic. Inter-POP multicast traffic is carried on a separate transmission facility.

0114One embodiment of an IPMS discussed earlier is illustrated in <figref idref="DRAWINGS">FIGS. 15 and 16</figref>. Generally stated, the embodiment of the IPMS unit <b>120</b> shown here and subsequently described is comprised of a controller unit <b>440</b> and one or more transponder units <b>445</b>. The controller unit <b>440</b> handles the monitoring, control, and configuration of the IPMS unit <b>120</b>. The transponder units <b>445</b> performs demodulation and de-packetization of the RF signal data received from the satellite <b>55</b> and provides the demodulated data to the hub <b>340</b> of a 100BT LAN <b>220</b> when directed to do so by the controller unit <b>440</b>. In some implementations of the system, there may be a need for a splitter unit <b>450</b> that divides the RF signal for supply to several transponder units <b>445</b>.

0115As noted above, the controller unit <b>440</b> handles all monitor, control, and configuration of the IPMS unit <b>120</b>. It maintains logs of all of the events in the system and processes all incoming TCP/IP protocol messages to the IPMS unit <b>120</b>. These messages include the IGMP join requests from remote clients, individually addressed commands to the controller unit <b>440</b>, and packets destined to individual transponder units <b>445</b>. The controller unit <b>440</b> is responsible for logging all of the trace type events in a non-volatile memory device, such as a hard disk drive <b>455</b>.

0116As illustrated, the controller unit <b>440</b> is comprised of a microprocessor unit <b>460</b>, two network interface cards (NIC) <b>465</b> and <b>467</b>, a modem <b>470</b> for connection to a remote port, a video controller <b>475</b> for connecting a video monitor, a keyboard interface <b>480</b> for connection to a keyboard, a DRAM <b>485</b> for storage, an RS-232 port <b>487</b> for external communications, and the hard drive <b>455</b>.

0117The microprocessor unit <b>460</b> may be an Intel Advanced ML (MARL) Pentium motherboard. This board has two serial ports, a parallel port, a bus mastering IDE controller, a keyboard interface, a mouse interface, support for up to 128 MB of DRAM, and a socket for a Pentium microprocesser. The board supports 3 ISA extension boards and 4 PCI extension boards. The MARL motherboard is designed to fit into the standard ATX form factor.

0118The RS-232 port <b>487</b> supports commands from a remote port that can be used for both monitor and control functions. This interface supports standard RS-232 electrical levels and can be connected to a standard personal computer with a straight through DB-9 cable. The software used to implement the interface supports a simple ASCII command set as well as a packet protocol that can be used to send commands that contain binary data.

0119Monitor and control interface software <b>490</b> executed by the microprocessor unit <b>460</b> supports multiple communications settings for the RS-232 port <b>487</b> by allowing the user to change the baud rate, the number of data bits, the number of stop bits, and the type of parity. These settings are saved in non-volatile memory so that they are preserved after power has been removed from the receiver.

0120The monitor and control interface software <b>490</b> preferably supports both a simple ASCII protocol and a more complex packet structure. The ASCII protocol is a simple string protocol with commands terminated with either a carriage return character, a line feed character, or both. The packet protocol is more complex and includes a data header and a terminating cyclic redundancy check (CRC) to verify the validity of the entire data packet.

0121The ASCII protocol is preferably compatible with a simple terminal program such as Procomm or HyperTerminal. When an external terminal is connected to the RS-232 port <b>47</b>, the controller unit <b>440</b> initially responds with a sign-on message and then displays its “ready” prompt indicating that the is ready to accept commands through the monitor and control interface software <b>490</b>. Commands are terminated by typing the ENTER key which generates a carriage return, a line feed, or both. The controller unit <b>440</b> interprets the carriage return, as the termination of the command and begins parsing the command.

0122Most commands support both a query and a configuration form. Configuration commands adhere to the following format: <br />cmd param1<,param2>CR<br /> where cmd is the command mnemonic, param1 is the first parameter setting, the <,param2> indicates an optional number of parameters separated by commas, and CR is a carriage return.

0123Queries of commands can be entered in one of two forms as follows: <br />cmd?CR or optionally<br />cmdCR<br /> The controller unit <b>440</b> responds to the query with the command mnemonic followed by the command's current setting(s).

0124The controller unit <b>440</b> may also communicate through the monitor and control interface software <b>490</b> using a predetermined packet protocol. One such protocol is illustrated in <figref idref="DRAWINGS">FIG. 17</figref>. The illustrated protocol is an asynchronous character based master-slave protocol that allows a master controller to encapsulate and transmit binary and ASCII data to a slave subsystem. Packets are delimited by a sequence of characters, known as ‘flags,’ which indicate the beginning and end of a packet. Character stuffing is used to ensure that the flag does not appear in the body of the packet. A 32-bit address field allows this protocol to be used in point-to-point or in point-to-multipoint applications. A 16 bit CRC is included in order to guarantee the validity of each received packet.

0125The opening flag <b>500</b> includes a 7E_H01_Hflag pattern indicating the start of packet or end of the packet at <b>510</b>. A transaction ID <b>505</b> follows the opening flag <b>500</b> and is, for example, an 8-bit value that allows the master external computer to correlate the controller unit <b>440</b> responses. The master computer sends an arbitrary transaction ID to the controller unit <b>440</b>, and the controller unit <b>440</b> preferably responds with the 1's complement of the value received from the master. Following the transaction ID <b>505</b> is a value that allows the master to identify the addressing mode of the packet. This portion of the packet is called the mode byte and is shown at <b>515</b>. These addressing modes include broadcast, physical, and logical modes. An address field <b>520</b> and data field <b>525</b> follow the mode byte <b>515</b>. The address field value is used in conjunction with the mode field to determine if the slave should process the packet. The data field <b>525</b> contains information specific to the application. This field can be any size and is only limited by the application. Finally, a CRC-16 field <b>530</b> follows the data field <b>525</b>. The CRC-16 field <b>530</b> allows each packet to be validated. Each byte from the mode byte <b>515</b> to the last data byte is included in the CRC calculation.

0126The monitor and control interface software <b>490</b> supports the same command set as both a remote port and a TCP/IP in-band signaling channel. This allows the IPMS <b>120</b> to be controlled identically using any of the possible control channels (although the physical connection and physical protocol vary by connection) which provides redundant means of monitor and control. These commands are described in further detail below.

0127The controller unit <b>440</b> includes the hard drive <b>455</b> for its long-term storage. This drive is preferably at least 2.1 GB in size and uses a standard IDE interface. The drive <b>455</b> is preferably bootable and stores the operating system, the application(s) running the IPMS <b>120</b>, and all long-term (non-volatile) data such as history/trace data.

0128The network interface card <b>465</b> is used to communicate with all of the transponder units <b>445</b> in the IPMS <b>120</b>. The network interface card <b>465</b> is comprised of a 10 based-T LAN interface running standard TCP/IP. Individual commands are issued using the same protocol as set forth above in connection with the monitor and control interface software <b>490</b> as well as any remote port connected through modem <b>470</b>. This protocol is encapsulated into TCP/IP and sent via an internal LAN <b>532</b> over transmission line <b>535</b>.

0129The network interface card <b>465</b> supports both broadcast and individual card addressing. This interface also supports two-way communication that can be initiated by any unit on the internal LAN <b>532</b>. Individual transponder units <b>445</b> may communicate with each other over the internal LAN <b>532</b>, although this interface is not truly intended to be used in this fashion in the embodiment shown here. The 10 Based-T interface card <b>465</b> may be implement using any off-the-shelf network interface card.

0130The modem <b>470</b> of the controller unit <b>440</b> may also support commands that can be used for both monitor and control functions. The modem <b>470</b> supports standard phone modem electrical levels and can be connected to a standard phone jack with a straight through RJ-11 cable. Both the ASCII and packet protocols noted above are supported by the modem <b>470</b>. The modem <b>470</b> thus provides another communications route to the IPMS <b>120</b> in case a standard TCP/IP link over the Internet to the IPMS <b>120</b> fails.

0131The modem interface <b>470</b> is implemented for example, by an off-the-shelf modem and auto-negotiates all communications settings with a Network Operations Center or NOC <b>472</b> at a location that is remote of the ISP. The Network Operations Center <b>472</b> preferably uses an identical modem.

0132The IPMS <b>120</b> includes several miscellaneous input and output (IO) functions that are not illustrated in <figref idref="DRAWINGS">FIGS. 15 and 16</figref>. These functions may be handled on either a plug in ISA board or a front panel board. The IO may include status LEDs, a status dry contact closure, and a panic button. The status LEDs may be set through an I/O card. LED indicators may include Power Present, Power OK, Fault, Test, Carrier OK, and LAN Activity. The Power Present LED may indicate that the IPMS <b>120</b> is plugged into its main AC source. The Valid Power LED may indicate if the power within the IPMS <b>120</b> is within valid tolerance levels. The Fault LED may indicate if a major fault is occurring in the IPMS <b>120</b>. The Test LED may indicate that the IPMS <b>120</b> is in a test mode, either its power up test or an on-line test mode. The Carrier LED may indicate that all transponder units <b>445</b> that should be acquired (have been programmed to lock onto a carrier) are, in fact, locked. If any single transponder unit <b>445</b> is not locked, this LED will be off. The LAN activity LED may indicate that the IPMS <b>120</b> has activity on its 100 based-T LAN.

0133A Form C dry contact closure may be provided to indicate the status of the IPMS <b>120</b>. If the IPMS <b>120</b> goes into a fault condition, the IPMS <b>120</b> will provide an output signal along one or more lines at <b>540</b> to drive closure to a closed state. This provides a means of monitoring the overall operational integrity of the IPMS <b>120</b> with an external device triggered by the contact closure. Devices that could be used include automatic pagers or alarm bells.

0134The IPMS <b>120</b> may also have a panic button that is used to turn off outgoing multicast video. This will provide the ISP with a quick and efficient way of stopping the IPMS <b>120</b> data flow onto the ISP LAN <b>240</b> in cases of extreme LAN congestion or a when a malfunctioning IPMS <b>120</b> inadvertently congests the LAN <b>240</b>. This button preferable will not take the controller unit <b>440</b> link off of the network. This ensures that the controller unit <b>440</b> will still be susceptible to monitoring and control through the TCP/IP port connected to the ISP's LAN <b>240</b>.

0135Once the panic button has been pressed, the IPMS <b>120</b> issues a “LAN shutdown” to every transponder unit <b>445</b> through the network interface card <b>465</b>. The individual transponder units <b>445</b> are responsible for shutting their LAN output off.

Controller Unit Software Functionality

0136The following sections provide a brief overview of one embodiment of the software functionality used to operate the controller unit <b>440</b>. This software is preferably developed in accordance with an object-oriented, C++, methodology.

0137The controller unit <b>440</b> preferably runs under a Microsoft Windows NT Workstation operating system. This operating system supports all of the networking protocols needed as well as supporting the hardware found in the controller unit <b>440</b>.

01381. Networking Protocols

0139The networking protocols discussed above are supported by the operating system. The operating system runs an HTTP server that allows control of the controller unit <b>440</b> through a web browser type of application.

01402. Watchdog Process

0141A hardware watchdog timer counter that must be periodically reset is used in the controller unit <b>440</b>. If this counter runs out, it generates an interrupt that reset as the controller unit <b>440</b>. In addition to this system level watchdog timer, individual applications may maintain their own versions of watchdog monitoring to ensure that they do not “hang.” In cases where an individual task can restart without affecting the overall system, the task will be restarted. In cases where the system becomes unstable, the entire controller unit <b>440</b> is preferably restarted in an orderly manner. In either case, an error should be generated and logged in the trace buffer.

01423. Software Download

0143The controller unit <b>440</b> handles software downloads for itself and for all of the transponder units <b>445</b>: Software downloads are preferably performed using VIP file downloads over the local ISP LAN the <b>240</b> through NIC <b>467</b>, from a remote station over the modem interface <b>470</b>, or through the RS-232 port <b>487</b>. Before a file is downloaded, VIP server software in the controller unit <b>440</b> verifies that the download is, in fact, a new file. The files are preferable downloaded into a fixed directory structure.

01444. Network Configuration Tables

0145The NOC <b>472</b> maintains a series of tables used to configure a network of systems such as the one shown in <figref idref="DRAWINGS">FIG. 15</figref>, each system being linked to the NOC <b>472</b>. These tables may be downloaded using FTP or a predetermined table download command and are used by the controller unit <b>440</b> to configure all of the transponder units <b>445</b> and to handle any data rate adaptation required by the system. The tables include a Channel Definition Table (CDT), a Carrier Table (CT), and a Channel Cluster Table (CC).

0146The Channel Definition Table (CDT) is used to define the location and bandwidth of every channel containing, for example, multimedia content, in the overall system. Each channel of the disclosed embodiment has a unique ID that ranges from 0 to 16K. This ID is the same value as the channel's default low order administratively scoped address bits. For example, channel <b>128</b> will have a default address of X.Y.0.128, where X and Y are the administratively scoped high order address bytes (239.117 for example). The CDT also provides an indication of the carrier frequency on which a channel can be found. The carriers are assigned a unique ID number that can be converted to a frequency and data rate using the Carrier Table set forth below. The CDT also includes the Channel Cluster ID of the cluster in which the channel appears, if any. The Channel Cluster ID is defined in the Channel Cluster Table section below. Each CDT record preferably uses the following record format:

0147<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="112pt" align="left" /><colspec colname="2" colwidth="63pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Channel ID</entry><entry> (8-bits)</entry></row><row><entry /><entry>Transponder Number</entry><entry>(16-bits)</entry></row><row><entry /><entry>Data Rate (in Kilobytes)</entry><entry>(16-bits)</entry></row><row><entry /><entry>Cluster ID</entry><entry>(16-hits)</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0148The CDT only contains records for defined channels in the overall system. If a channel is not defined, the IPMS <b>120</b> will assume that the channel has zero bandwidth. The overall table will be represented in the following form:

0149<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="84pt" align="left" /><colspec colname="2" colwidth="133pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Table ID</entry><entry> (8-bit)</entry></row><row><entry>Number of Channels</entry><entry>(16-bit)</entry></row><row><entry>Channel Records</entry><entry>(40-bits per record * number of channels)</entry></row><row><entry>CRC</entry><entry>(16 bit)</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0150The Carrier Table (CT) provides a means for identifying all of the carriers being used in the overall system. The records in the CT indicate the satellite transponder ID, the frequency of the carrier, its data rate, and the type of coding that the carrier is using (including scrambling). The controller unit <b>440</b> provides these parameters to the transponder units <b>445</b> to acquire the desired carrier. The CT records also contain information about the satellite that the carrier is transmitted from and the polarity of the receive signal. The controller unit <b>440</b> uses this information to notify an installer. through, for example, a video terminal attached to the video controller <b>475</b>, that multiple dishes are required. Further, the satellite ID is used to determine the azimuth and elevation settings for an antenna that is to receive the carrier transmission from the identified satellite. Each record within the CT preferably has the following format:

0151<tables id="TABLE-US-00003" num="00003"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="105pt" align="left" /><colspec colname="2" colwidth="70pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Carrier Number</entry><entry>(16-bits)</entry></row><row><entry /><entry>Frequency (in kHz)</entry><entry>(32-bits)</entry></row><row><entry /><entry>Data Rate (in Hz)</entry><entry>(32-bits)</entry></row><row><entry /><entry>Coding type</entry><entry> (8-bits)</entry></row><row><entry /><entry>Polarity</entry><entry> (8-bits)</entry></row><row><entry /><entry>Satellite ID</entry><entry> (8-bits)</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> The overall table format for the CT is as follows:

0152<tables id="TABLE-US-00004" num="00004"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="84pt" align="left" /><colspec colname="2" colwidth="133pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Table ID</entry><entry> (8-bit)</entry></row><row><entry>Number of Carriers</entry><entry> (16-bit)</entry></row><row><entry>Carrier Records</entry><entry>(104-bits per record * number of carriers)</entry></row><row><entry>CRC</entry><entry> (16-bit)</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0153The Channel Cluster Table (CCT) is used to describe a “cluster” of channels. A cluster of services is defined as a set of multiple channels with the same content but using different data rates. This aspect of the present embodiment of the system is set forth above. The CCT is used to allow a client to receive a channel at a different data rate from the one requested. For example, if a client requests a service at 1 Mb but the LAN <b>240</b> is congested or the controller unit <b>440</b> is close to its maximum allowable bandwidth on the LAN, the controller unit <b>440</b> can inform the client software (usually a browser plug-in or the like) to switch to another channel in the cluster at a lower data rate, say 500 kb. To facilitate lookup times, each channel has its associated cluster ID in its record within the Channel Definition Table. This allows the controller unit <b>440</b> to easily locate a channel ID, determine its Cluster ID, and find alternate channels. Each Channel Cluster record preferably conforms to the followings record format:

0154<tables id="TABLE-US-00005" num="00005"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="98pt" align="left" /><colspec colname="2" colwidth="105pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Cluster ID</entry><entry>(16-hits)</entry></row><row><entry /><entry>Number of Channels in Cluster</entry><entry> (8-bits)</entry></row><row><entry /><entry>Service ID's channels)</entry><entry>(16-bits * the number of channels)</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> The overall table format for the CT is as <ul id="ul0001" list-style="none"><li id="ul0001-0001" num="0000"><ul id="ul0002" list-style="none"><li id="ul0002-0001" num="0155">Table ID</li><li id="ul0002-0002" num="0156">Number of Clusters</li><li id="ul0002-0003" num="0157">Cluster Records</li><li id="ul0002-0004" num="0158">CRC</li><li id="ul0002-0005" num="0159">(16-bits)</li><li id="ul0002-0006" num="0160">(8-bits)</li><li id="ul0002-0007" num="0161">(16-bits*the number of follows:</li><li id="ul0002-0008" num="0162">(8-bit)</li><li id="ul0002-0009" num="0163">(16-bit)</li><li id="ul0002-0010" num="0164">(24+(16*the number of channels)*numbers of clusters)</li><li id="ul0002-0011" num="0165">(16 bit)</li></ul></li></ul>

01665. Networking Protocols

0167As discussed above, the controller unit <b>440</b> may receive Internet related protocol messages. It processes such messages and performs the necessary actions to maintain the controller unit environment. For example, when the controller unit <b>440</b> receives an IGMP join message from an end-user client application requesting a new service, it may respond with a predetermined sequence of action. For example, the controller unit <b>440</b> logs the join request, verifies that there is enough bandwidth on the LAN <b>240</b> to output the service, and sends an Add Service command to the appropriate transponder unit <b>445</b>. The controller unit <b>440</b> then sends a response back to the client indicating whether or not the join was successful.

01686. Inter-IPMS Communications

0169The controller unit <b>440</b> communicates with the transponder units <b>445</b>, and any I/O units that are utilized, through the 10 based-T LAN, shown here at <b>532</b>. The software of the controller unit <b>440</b> maintains a TCP/IP protocol stack to support this interface.

01707. Serial Communications Over the Modem <b>470</b> and RS-232 Port <b>487</b>

0171The controller unit <b>440</b> utilizes the monitor and control software <b>490</b> described above to handle the modem <b>470</b> and RS-232 port <b>487</b> serial communications ports. The serial ports are used to send commands to and from the controller unit <b>440</b>. The commands supported through this interface are the same as the commands through the 100 based-T LAN interface <b>240</b>.

01728. Command Processor

0173Command processor software tasks handle commands that have come in from the various command channels (modem <b>470</b>, port <b>487</b>, etc.) supported by the controller unit <b>440</b>. The commands are parsed and executed as needed.

01749. System Event Logging

0175All significant events may be logged into a trace buffer in, for example, the non-volatile memory (hard drive <b>455</b>). The controller unit software tasks will take an event, timestamp it, and put the resulting string into a trace buffer. The software routines may disable individual events from being put into the log and may control the execution of the logging process (start, stop, reset, etc.).

017610. Status Monitoring

0177A status-monitoring software task in the controller unit <b>440</b> monitors the current status of the controller unit <b>440</b> and periodically polls each of the transponder units <b>445</b> for their status. This task maintains an image of the current status as well as an image of past faults that have occurred since the last time a fault history table was cleared (via command). This task further reports fault and status information to the Network Operations Center <b>472</b> over, for example, an Internet connection or modem <b>470</b>.

017811. Statistics Gathering

0179The statistics gathering task of the controller unit <b>440</b> is similar to the status monitoring software described above. This process keeps track of the number of users “viewing” a particular channel, the addresses of users, the number of collisions on the LAN <b>240</b>, and other long term statistics that may be helpful in monitoring the usage of the IPMS <b>120</b>.

018012. Power Up Sequence

0181The power up sequence software of the controller unit <b>440</b> starts all necessary start-up tasks, determines if the transponder units <b>445</b> need to be programmed, performs all needed power up diagnostic functions, and joins the in-band signaling group address of at least on transponder.

018213. Dish Pointing Calculation

0183The controller unit <b>440</b> supports several antenna pointing aids. For example, the controller unit <b>440</b> provides a ZIP code to azimuth and elevation calculation. This software application takes a ZIP code as an input through, for example, the keyboard interface <b>480</b>, performs the necessary mathematical calculations or look-up actions, and gives the user the antenna pointing angles needed to find the satellite signal (azimuth and elevation).

018414. Interrupts

0185The controller unit <b>440</b> uses various software routines in response to interrupt signals. For example, an interrupt may indicate that the watchdog timer has expired and, as such, the controller unit <b>440</b> software begins an orderly soft reset procedure. The controller unit <b>440</b> also utilizes interrupts to service real time clock, serial port communications, parallel port communications, keyboard interface communications, and mouse interface communications. All of these interfaces generate interrupts that are handled by the operating system.

018615. Diagnostics

0187The controlling unit software supports multiple forms of self-diagnostics. Some of the diagnostics run on power up to verify system integrity, and other diagnostic functions are run periodically while the controller unit <b>440</b> is operational. For example, the controller unit <b>440</b> initially runs several diagnostics including a memory test, a virus scan, a File Allocation Table (FAT) check, a backplane LAN <b>532</b> connectivity test, and an external 100 based-T LAN <b>240</b> interface test when power is first supplied. As part of its ongoing monitoring process, the controller unit <b>440</b> also performs hard drive <b>455</b> integrity tests to verify that the file system has not been corrupted. If a hard drive error is encountered, the controller unit <b>440</b> logs the error into its trace history, and tries to correct the problem via downloading of any corrupted files from the Network Operations Center <b>472</b>. Still further, the controller unit <b>440</b> monitors the fault status of every transponder unit <b>445</b> with which it is associated in the respective IPMS <b>120</b>. The fault monitoring status is an on-going periodic process. All faults are preferably entered into a trace buffer that is available for history tracking. Each fault will be time-stamped and stored in non-volatile memory.

018816. Security

0189The software of the controller unit <b>440</b> supports multiple levels of security, using passwords. The types of levels of access includes ISP monitoring, ISP configuration. network operations monitoring, network operations configuration, and administrative operations. Each level of access has a unique password. The highest levels of authorization will have passwords that preferably change periodically. Any changes to either passwords or configuration settings of the controller unit <b>440</b> preferably requires a confirmation (either in the form of a Yes/No response or another password).

Command Set for Interfacing With the Controller Unit

440

0190As noted above, commands can be provided to the controller unit <b>440</b> through the RS-232 port <b>487</b>, the 100 based-T LAN network interface card <b>467</b>, the 10 based-T backplane LAN network, interface card <b>465</b>, or through the modem <b>470</b>. Through the 100 based-T network card <b>467</b>, commands can be issued either through a SNMP interface, an HTTP interface, or raw commands through TCP/IP. Exemplary commands are set forth and described below.

01911. TCP/IP Address

0192The TCP/IP address of the IRMS <b>120</b> can be set or queried. This command may be sent from an interface other than the LAN connection (since the LAN connectivity depends on this parameter).

01932. RS-232 Settings

0194The settings for the COM port can be either queried or configured through the command interface.

01953. Table Download

0196The network provisioning tables are downloaded via a table download facility. This command is used to process all new tables and reconfigures the system as necessary. The tables are described above.

01974. Set Transponder Characteristics (per unit)

0198The controller unit <b>440</b> keeps track of which transponder unit <b>445</b> is assigned to each transponder. This implies that the RF parameters of the transponder units <b>445</b> are maintained and configured through the controller unit <b>440</b>. Once the user has changed a parameter, the controller unit <b>440</b> forwards the changed information to the transponder unit <b>445</b> via the backplane of the LAN <b>145</b>.

01995. Network Utilization

0200Several statistics are kept on the network utilization, including the absolute data rate being output onto the LAN <b>220</b> and the number collisions being encountered on the LAN <b>220</b>. The network utilization statistics may be made available through a “Network Utilization” query command.

02016. Maximum LAN Data Rate

0202The Maximum LAN Data Rate command may be used to limit the amount of bandwidth that the controller unit <b>440</b> uses on the LAN <b>220</b>. This allows the ISP to control the maximum impact that the system has on the LAN backbone.

02037. Current Status

0204The controller unit <b>440</b> maintains its own internal status and, further, monitors the status of all of the transponder units <b>445</b> cards on the LAN <b>145</b>. The current status of the IPMS <b>120</b>, and all of its individual modules, can be queried through the Current Status Command.

02058. Card Configuration

0206The Card Configuration command is used to query the number of transponder units <b>445</b> in the IPMS <b>120</b> and their current settings.

02079. Usage Statistics

0208The Usage Statistics command is used to retrieve the current and past statistics of the channel usage experienced by the IPMS <b>120</b>. This includes the number of viewers per channel, the usage of a given channel per time, the overall usage of the system per time, and the LAN congestion over time. All of these statistics may be made available graphically through an HTTP server or downloaded to the NOC in a binary form using SNMP.

020910. Trace

0210The Trace command is used to start, stop, and configure the trace functions of the controller unit <b>440</b>. Individual events can be enabled or disabled to further customize the trace capabilities of the unit <b>440</b>. The trace may be uploaded to the Network Operations Center <b>472</b> for diagnostic purposes. The trace data may be stored on the hard drive, which provides a non-volatile record of the events. The maximum size of the trace log is determined by the available space on the hard disk and, preferably, can be selected by the user.

0211The transponder unit <b>445</b> is designed to receive, for example, an L-Band signal off of the satellite <b>55</b>, convert the signal into its original digital form, and put the resulting digital signal onto the ISP's 100BT LAN <b>220</b>. Each IPMS <b>120</b> may include multiple transponder units <b>445</b> thereby allowing the IPMS <b>120</b> to handle significant data traffic.

0212<figref idref="DRAWINGS">FIG. 18</figref> illustrates various functional blocks of a transponder unit <b>445</b>. The transponder unit <b>445</b> includes an input <b>550</b> for receiving an RF signal, such as the L-band signal from satellite <b>55</b>. The RF signal is supplied from the input <b>550</b> to the input of a demodulator <b>555</b> that extracts the digital data from the RF analog signal. The digital data from the demodulator <b>555</b> is optionally supplied to the input of a descrambler <b>560</b> that decrypts the data in conformance to the manner in which the data was, if at all, encrypted at the transmission site.

0213One embodiment of a descrambler <b>560</b> is illustrated in <figref idref="DRAWINGS">FIG. 19</figref>. In the illustrated embodiment the descrambler <b>560</b> may be implemented by a field programmable gate array. One type of field programmable gate array technology suitable for this use is a Lattice ISP <b>1016</b>.

0214The descrambler <b>560</b> preferably automatically synchronizes to the start of a DVB frame marker provided by the demodulator <b>555</b>. The descrambler <b>560</b> receives digital data from the demodulator <b>555</b> along data bus <b>565</b>, a clock signal along one or more lines <b>570</b>, and a data valid signal along one or more lines <b>575</b>. The data valid signal is used to qualify the clock signal in the descrambler <b>560</b>. The descrambler <b>560</b> of the illustrated embodiment should have the capability of processing four megabytes/second. Such a processing rate is based on a maximum system data rate of 32 bits/second.

0215The descrambler <b>560</b> is also provided with a microprocessor interface for programming and monitoring the status of the device by a microprocessor <b>580</b> (see <figref idref="DRAWINGS">FIG. 18</figref>) such as a Motorola 860 type processor. The descrambler <b>560</b> preferably supports normal bus access in addition to data transfers through the device into the one packet FIFO. The descrambler <b>560</b> can also issue an interrupt to the microprocessor <b>580</b> to request immediate service.

0216Using a microprocessor interface <b>585</b> to the descrambler <b>560</b>, the microprocessor <b>580</b> is provided with access to the internal registers of the descrambler <b>580</b> via a bi-directional data bus. The microprocessor <b>580</b> accesses the device's registers via the address bus of the microprocessor interface. Preferably, the microprocessor <b>580</b> gains access to the registers of the descrambler <b>560</b> using a RDNVR signal qualified by a CS signal consistent with the Motorola 860 bus architecture. The descrambler <b>560</b> can also issue an interrupt to the 860 processor using INT signal. The microprocessor <b>580</b> may also be used to perform overall fuse programming of the descrambler <b>560</b> when the descrambler is implemented using a field programmable gate array.

0217The descrambler <b>560</b> takes the data received on a data bus <b>565</b> from the demodulator <b>555</b>, de-scrambles it in a manner consistent with any scrambling operation performed on the data at the transmission site, and provides it to the input of an HDLC controller <b>590</b>. In the illustrated embodiment, the descrambler <b>560</b> and the HDLC controller <b>590</b> interface with one another over an HDLC bus <b>595</b> that is preferably comprised of an HDLC parallel data bus, a clock signal, and a control bus. The HDLC controller <b>590</b> serializes the data received on the data bus of the HDLC bus <b>595</b> and provides it as a serialized output at serial bus <b>600</b> for supply at one or more output lines. The serial form of the data is used by the HDLC controller <b>590</b> for validation and de-packetization operations.

0218The descrambler <b>560</b> may have two modes of operation: a descramble mode and a clear channel mode. In the descramble mode, the device descrambles the data to be serialized for the HDLC controller <b>590</b>. Preferably, the descrambler <b>560</b> supports simple P/N sequenced descrambling. This mode is used as a protected transmission mode that assists in preventing unauthorized access of the transmissions. In this mode, the descrambler may use, for example, an 8 bit seed used to descramble the input data. This seed is preferably programmed into the descrambler <b>560</b> through the microprocessor interface bus <b>605</b>. The microprocessor <b>580</b> may asynchronously set the seed value by writing to a seed resister internal to the descrambler <b>560</b>.

0219In the clear channel mode, the descrambler <b>560</b> allows the data to be serialized without de-scrambling. This mode is used for an unprotected transmission mode in which unauthorized receipt of the transmission is not a significant issue. Clear channel mode can be set by programming the seed register to, for example, all zeros.

0220The descrambler <b>560</b> may also maintain several counters to allow the microprocessor to detect system errors. For example, the descrambler <b>560</b> may store a count of the number of block errors detected. This is preferably implemented as a 16 bit register that rails (i.e. does not cycle back to zero) at 0xFFFF (65,535). The descrambler <b>560</b> stores a count of the number of valid packets read from the IF.

0221The HDLC controller <b>590</b> receives the parallel bit data from the descrambler and depacketizes the HDLC frames. The HDLC controller <b>590</b> processes the CRC, removes the flags, and removes any bit stuffing characters from the HDLC frame. If there are any errors in the data they are indicated in the status provided by the HDLC controller <b>590</b>. Typical errors include CRC errors and frames that are too long. The resulting data is fed to a FIFO <b>610</b> with both start of packet (SOP) and end of packet (EOP) indications. The resulting packets stored in FIFO <b>610</b> are complete TCP/IP packets that can be output onto the 100 BT LAN <b>220</b> If a packet contains a CRC error, the packet will be discarded and a packet error counter will be incremented.

0222The data from the FIFO <b>610</b> is provided to the input of a packet filter <b>615</b>. The packet filter <b>615</b> is preferably implemented using a field programmable gate array. The packet filter <b>615</b> determines whether the data packet stored in the FIFO <b>610</b> is intended for transmission on the LAN <b>220</b> or is to be discarded. This decision is made by the packet filter <b>615</b> based on whether someone directly connected to the LAN <b>220</b> or who is remotely connected to the LAN <b>220</b> has joined the multicast group to which the packet belongs. The packet filter <b>615</b> stores valid packets into a single packet FIFO <b>620</b> that is used to buffer the packet for provision to a network interface card, such as an ethernet controller <b>625</b>. The ethernet controller <b>625</b> takes the packet from the FIFO <b>620</b> and transmits it onto the LAN <b>220</b> through an ethernet transceiver and transformer using standard ethernet protocols. Such protocols include collision detection and re-transmission as well as all preamble and CRC generation needed. The output of the ethernet controller <b>625</b> is fed, using a standard media independent interface (MII) to an ethernet transceiver <b>630</b> that converts the digital packet into an ethernet analog signal.

0223A transformer <b>635</b> is used to alter the electrical levels of this signal so that it is compatible with the LAN <b>220</b> The microcontroller <b>580</b> configures and monitors this entire process and reports status, logs faults, and communicates with external systems via the internal 10-based T backplane LAN <b>145</b>. In addition to the backplane LAN <b>145</b>, the transponder unit <b>445</b> can be controlled through a standard RS-232 port <b>637</b> that, for example, may be used for debuting the unit.

0224Preferably, the packet filter <b>615</b> is a TCP/IP filter implemented using a field programmable gate array. The primary task of the packet filter <b>615</b> is to filter all IP packets received and to pass only valid packets for which a subscriber exists on the network for the multicast transmission. Other tasks that may optionally be performed by packet filter <b>615</b> are such tasks as IP address translation (see above), notification of the microprocessor of the occurrence of any over flow errors on the channel, etc.

0225<figref idref="DRAWINGS">FIG. 20</figref> illustrates one embodiment of the packet filter <b>615</b> as implemented by a field programmable gate array <b>645</b> and a static RAM <b>650</b>. The figure also illustrates the relationship between the packet filter <b>615</b> and other system components. The field programmable gate array may be one such as is available from XILINX, LATTICE, ALTERA, or other FPGA manufacturers.

0226As illustrated, the packet filter <b>615</b> includes a microprocessor interface <b>655</b> comprised of a microprocessor data bus, microprocessor address bus, and a microprocessor control bus. The microprocessor interface <b>655</b> provides an interface for programming and monitoring the status of the packet filter <b>615</b>. The device supports normal bus access in addition to data transfers through the device into the one packet FIFO <b>610</b>. The packet filter <b>615</b> may also issue an interrupt to the microprocessor <b>580</b> to request immediate service.

0227The microprocessor <b>580</b> accesses the registers of the programmable gate array <b>645</b> through the bidirectional data bus of the interface <b>655</b>. Selection of which of the registers are accessed is performed by the microprocessor <b>580</b> over the address bus of the interface <b>655</b>. The microprocessor <b>580</b> gains access to the registers over the control bus of the interface <b>655</b> using a RDIWR signal that is qualified with a CS signal consistent with the Motorola 860 bus architecture. Any interrupt from the packet filter <b>615</b> is also provided over the control bus.

0228The field programmable gate array <b>645</b> also provides an SRAM interface <b>660</b> for interfacing with SRAM <b>650</b>. This interface is comprised of a data bus, an address bus, and a control bus. The gate array <b>645</b> gains access to the registers of the SRAM <b>650</b> by selecting the appropriate resister over the address bus and providing a OE/WR signal qualified by a CS signal consistent with the SRAM bus architecture.

0229The field programmable gate array <b>645</b> provides packet flow control between the FIFO <b>620</b> and FIFO <b>610</b>. This control is provided based on a FIFO interface that includes a data bus <b>665</b> and a FIFO control bus <b>670</b>.

0230In the disclosed embodiment, the packet filter <b>615</b> is designed to store up to 64K (65,535) addresses that are used as filter addresses. The LSB (bottom 16 bits) of the 32-bit address field of a packet is compared to an addresses stored in SRAM <b>650</b>. The addresses in SRAM <b>650</b> are stored based on commands received by the packet filter <b>615</b> from the microprocessor <b>580</b>. These addresses correspond to multicast group addresses for which a subscriber on the system has issued a “join” command. If the address of a packet received at FIFO <b>610</b> matches a joined address stored in the SRAM <b>650</b>, then the entire packet will be passed to the single packet FIFO <b>610</b> and the FPGA <b>645</b> will notify the Ethernet controller <b>625</b> that the data is to be transmitted onto the LAN <b>220</b>. The single packet FIFO <b>610</b> is used as temporary storage until the entire TCP/IP packet is processed and transmitted to the ethernet controller <b>625</b>. If a re-transmit is needed, then the single packets FIFO <b>610</b> is reset and the data can be read again.

0231The packet filter <b>615</b> auto-synchronizes to the HDLC start of frame marker. This marker is read from the FIFO <b>620</b> and the ninth hit is used to signal the FPGA <b>645</b> to re-synchronize the internal state machine.

0232In the event that the ethernet controller <b>625</b> cannot successfully transmit the packet stored in the single packet FIFO <b>610</b>, the packet filter <b>615</b> either initiates a re-transmit cycle or aborts the packet and continues with the next available packet. To make this determination, the packet filter <b>615</b> queries the FIFO <b>620</b> for a half-full status. If the FIFO <b>620</b> is more that half full, then the packet in the single packet FIFO <b>610</b> is discarded. If the FIFO <b>620</b> is more than half full, then the single packet FIFO <b>610</b> is placed in a re-transmit mode and the packet is given another chance for transmission.

0233The packet filter <b>615</b> may also include a pass-through mode of operation. In this mode the packet filter <b>615</b> allows the microprocessor <b>580</b> to write data into the single packet FIFO <b>610</b> for application to the ethernet controller <b>625</b> and, therefrom, for transmission on the LAN <b>220</b>. This mode may be used to send test packets to the ethernet controller <b>625</b> and to the client sub-system.

0234The packet filter <b>615</b> may maintain several counters to allow the microprocessor <b>580</b> to detect system errors. Such counters may include a counter for demodulator block errors, a counter for packet re-transmit errors, a counter for packet abort errors, a counter for valid packet count, and a counter for valid address count. Each of these counters may be reset through commands issued from the microprocessor <b>580</b> to the packet filter <b>615</b>.

0235The demodulator block error counter is used to count the number of block errors that are detected. This counter may be a 16 bit register that rails at 0xFFFF.

0236The packet re-transmit error counter stores a count of the number of packets that the packet filter <b>615</b> tried to re-transmit. If a packet is retransmitted more than once, each attempt increments the count. This counter is preferably implemented as a 16 bit register that rails at 0xFFFF (65,535).

0237The packet abort error counter stores a count of the number of packet aborts that have occurred. This is the packets that were not successfully transmitted. This is a 16 bit register that rails (i.e. not cycle back to zero) at 0xFFFF (65,535).

0238The valid packet counter stores a count of the number of valid packets read from FIFO <b>620</b> while the valid address counter stores a count of the number of valid TCP/IP addresses received. Each of these counters is preferably implemented as a 32 bit register counter

0239Table 1 below describes some of the write registers that may be included in the packet filter <b>615</b>, while Table 2 (below Table 1) describes some of the read registers that may be included.

0240<tables id="TABLE-US-00006" num="00006"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE I</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>WRITE REGISTERS</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="21pt" align="center" /><colspec colname="3" colwidth="140pt" align="left" /><tbody valign="top"><row><entry>REGISTER</entry><entry>Size</entry><entry /></row><row><entry>MNEMONIC</entry><entry>(bits)</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>RAMADDRH</entry><entry>8</entry><entry>SRAM address High</entry></row><row><entry>RAMADDRL</entry><entry>8</entry><entry>SRAM address Low</entry></row><row><entry>RAMDATA</entry><entry>5</entry><entry>SRAM Data</entry></row><row><entry /><entry /><entry>Bit 0 - Filter ON/OFF</entry></row><row><entry /><entry /><entry>Bit 1 . . . 4 - Translation Address (A15 . . . Al2)</entry></row><row><entry /><entry /><entry>of the TCP/IP address</entry></row><row><entry>CONTROLREG</entry><entry>8</entry><entry>Miscellaneous control register</entry></row><row><entry /><entry /><entry>Bit 0 - Micro pass-through mode</entry></row><row><entry /><entry /><entry>Bit 1 - Address Translation ON/OFF</entry></row><row><entry /><entry /><entry>Bit 2 - unassigned</entry></row><row><entry /><entry /><entry>Bit 3 - unassigned</entry></row><row><entry /><entry /><entry>Bit 4 - unassigned</entry></row><row><entry /><entry /><entry>Bit 5 - unassigned</entry></row><row><entry /><entry /><entry>Bit 6 - unassigned</entry></row><row><entry /><entry /><entry>Bit 7 - unassigned</entry></row><row><entry>STATREG</entry><entry>8</entry><entry>Status Register Clear</entry></row><row><entry /><entry /><entry>Bit 0 - Clear DMERRCNT</entry></row><row><entry /><entry /><entry>Bit 1 - Clear RETXCNT</entry></row><row><entry /><entry /><entry>Bit 2 - Clear ABORTCNT</entry></row><row><entry /><entry /><entry>Bit 3 - Clear PKTCNT</entry></row><row><entry /><entry /><entry>Bit 4 - Clear ADDRCNT</entry></row><row><entry /><entry /><entry>Bit 5 - unassigned</entry></row><row><entry /><entry /><entry>Bit 6 - unassigned</entry></row><row><entry /><entry /><entry>Bit 7 - unassigned</entry></row><row><entry>MACADDR0</entry><entry>8</entry><entry>Ethernet Controller Address BYTE 0 (LSB)</entry></row><row><entry>MACADDR1</entry><entry>8</entry><entry>Ethernet Controller Address BYTE 1</entry></row><row><entry>MACADDR2</entry><entry>8</entry><entry>Ethernet Controller Address BYTE 2</entry></row><row><entry>MACADDR3</entry><entry>8</entry><entry>Ethernet Controller Address BYTE 3</entry></row><row><entry>MACADDR4</entry><entry>8</entry><entry>Ethernet Controller Address BYTE 4</entry></row><row><entry>MACADDR5</entry><entry>8</entry><entry>Ethernet Controller Address BYTE 5 (MSB)</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0241<tables id="TABLE-US-00007" num="00007"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 2</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>READ REGISTERS</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="56pt" align="center" /><colspec colname="3" colwidth="119pt" align="left" /><tbody valign="top"><row><entry>REGISTER</entry><entry>Size</entry><entry /></row><row><entry>MNEMONIC</entry><entry>(bits)</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="56pt" align="char" char="." /><colspec colname="3" colwidth="119pt" align="left" /><tbody valign="top"><row><entry>STATREG</entry><entry>8</entry><entry>Indicates status of packet filter</entry></row><row><entry /><entry /><entry>Bit 0 - Input OVERFLOW</entry></row><row><entry /><entry /><entry>Bit 1 - Single Packet FIFO Timeout</entry></row><row><entry /><entry /><entry>Bit 2 - Re-Transmit OVERFLOW</entry></row><row><entry /><entry /><entry>Bit 3 - unassigned</entry></row><row><entry /><entry /><entry>Bit 4 - unassigned</entry></row><row><entry /><entry /><entry>Bit 5 - unassigned</entry></row><row><entry>PKTSTAT</entry><entry>16</entry><entry>Last packet transmitted status</entry></row><row><entry>DMERRCNT</entry><entry>16</entry><entry>Demodulator Error Count</entry></row><row><entry>RETXCNT</entry><entry>16</entry><entry>Re-Transmit Count</entry></row><row><entry>ABORTCNT</entry><entry>16</entry><entry>Packets Aborted Count</entry></row><row><entry>PKTCNT</entry><entry>32</entry><entry>Valid Packets Count</entry></row><row><entry>ADDRCNT</entry><entry>32</entry><entry>Valid Packets Count</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0242Table 3 (below) provides an exemplary pin-out listing for the packet filter <b>615</b>:

0243<tables id="TABLE-US-00008" num="00008"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="77pt" align="left" /><colspec colname="2" colwidth="28pt" align="center" /><colspec colname="3" colwidth="49pt" align="left" /><colspec colname="4" colwidth="63pt" align="left" /><thead><row><entry namest="1" nameend="4" rowsep="1">TABLE 3</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row><row><entry /><entry>SIZE</entry><entry /><entry /></row><row><entry>PIN NAME(S)</entry><entry>(BITS)</entry><entry>TYPE</entry><entry>DESCRIPTION</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="77pt" align="left" /><colspec colname="2" colwidth="28pt" align="char" char="." /><colspec colname="3" colwidth="49pt" align="left" /><colspec colname="4" colwidth="63pt" align="left" /><tbody valign="top"><row><entry>MICROPROCESSOR</entry><entry /><entry /><entry /></row><row><entry>INTERFACE</entry><entry /><entry /><entry /></row><row><entry>DATA</entry><entry>8</entry><entry>Input/output </entry><entry>Microprocessor</entry></row><row><entry /><entry /><entry /><entry>data bus</entry></row><row><entry>ADDRESS</entry><entry>4</entry><entry>Input</entry><entry>Microprocessor</entry></row><row><entry /><entry /><entry /><entry>data bus</entry></row><row><entry>CS</entry><entry>1</entry><entry>Input</entry><entry>Microprocessor</entry></row><row><entry /><entry /><entry /><entry>chip select</entry></row><row><entry>RW</entry><entry>1</entry><entry>Input</entry><entry>Microprocessor</entry></row><row><entry /><entry /><entry /><entry>read/write</entry></row><row><entry>INT</entry><entry>1</entry><entry>Output</entry><entry>Microprocessor</entry></row><row><entry /><entry /><entry /><entry>interrupt</entry></row><row><entry>FIFO 620</entry><entry /><entry /><entry /></row><row><entry>INTERFACE</entry><entry /><entry /><entry /></row><row><entry>DATA</entry><entry>8</entry><entry>Input</entry><entry>FIFO data input</entry></row><row><entry>RD</entry><entry>1</entry><entry>Output</entry><entry>FIFO read</entry></row><row><entry>WR</entry><entry>1</entry><entry>Output</entry><entry>FIFO write</entry></row><row><entry>ERR</entry><entry>1</entry><entry>Input</entry><entry>FIFO block error</entry></row><row><entry>BCLK</entry><entry>1</entry><entry>Input </entry><entry>FIFO byte clock</entry></row><row><entry>BLKSTART</entry><entry>1</entry><entry>Input</entry><entry>FIFO start of block</entry></row><row><entry>FULL</entry><entry>1</entry><entry>Input</entry><entry>FIFO full flag</entry></row><row><entry>HALF</entry><entry>1</entry><entry>Input</entry><entry>FIFO half full flag</entry></row><row><entry>EMPTY</entry><entry>1</entry><entry>Input</entry><entry>FIFO empty flag</entry></row><row><entry>SRAM INTERFACE</entry><entry /><entry /><entry /></row><row><entry>ADDRESS</entry><entry>16</entry><entry>O</entry><entry>SRAM address</entry></row><row><entry>DATA</entry><entry>8</entry><entry>I/O</entry><entry>SRAM data</entry></row><row><entry>RW</entry><entry>1</entry><entry>Output</entry><entry>SRAM read/write</entry></row><row><entry>1 OE</entry><entry>1</entry><entry>Input</entry><entry>SRAM output enable</entry></row><row><entry>SINGLE PACKET</entry><entry /><entry /><entry /></row><row><entry>FIFO INTERFACE</entry><entry /><entry /><entry /></row><row><entry>DATA</entry><entry>9</entry><entry>Output </entry><entry>FIFO data</entry></row><row><entry>RD</entry><entry>1</entry><entry>Output </entry><entry>FIFO read</entry></row><row><entry>WR</entry><entry>1</entry><entry>Output </entry><entry>FIFO write</entry></row><row><entry>RST</entry><entry>1</entry><entry>Output </entry><entry>FIFO reset</entry></row><row><entry>FULL</entry><entry>1</entry><entry>Input</entry><entry>FIFO full flag</entry></row><row><entry>EMPTY</entry><entry>1</entry><entry>Input</entry><entry>FIFO empty flag</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0244As noted above, the packet filter <b>615</b> may allow each filtered address to be translated into another IP address. Translation is preferably only allowed on the upper nibble of the LSB (A<b>15</b>, A<b>14</b>, A<b>13</b>, and A<b>12</b>). The translation bits will be downloaded along with the address filter information. Still further, the packet filter <b>615</b> preferably uses an FPGA <b>645</b> that is capable of being modified by the microprocessor <b>580</b>. In such instances, the FPGA technology of the FPGA <b>645</b> should be chosen to allow local re-programming of the FPGA fuse map.

0245The FPGA <b>645</b> preferably processes at least one mega-words per second (32 bits per word). If the FPGA <b>645</b> is run at 10 MHz, then 10 internal cycles can be used in a state machine per word received. A shutdown relay or other type of physical device may be employed to shut the 100 based T LAN output off. This may be controlled by the microprocessor <b>580</b> and is preferably tied, via backplane communications, to the Panic Button on a front panel of the system. This relay is not shown in the figures.

0246The transponder unit <b>445</b> of the disclosed embodiment processes a 10 BaseT ethernet connection that necessitates a TCP/IP protocol stack. This stack requirement makes it preferable to use a DRAM in the transponder unit <b>445</b>. The stack requirement drives the DRAM memory requirements of the unit <b>445</b>. The DRAM should be large enough to support the software (the code will be downloaded into DRAM using a TFTP boot), the RAM variables, and the protocol stacks.

0247The transponder unit <b>445</b> also preferably includes a battery backed RAM that maintains a small trace buffer, factory test results, and the card's serial number. The non-volatile memory is preferably organized into two identical blocks which are both, individually, subject to CRC checks. Such checks ensure that if a write process is being performed and the power is removed, damaging the integrity of the block, a second backup image of the non-volatile memory will still be intact.

0248Each transponder unit <b>445</b> preferably includes a test LED, a fault LED, a carrier sync LED, a LAN activity LED, and a LAN collision LED. The test LED is on whenever the unit is performing a test function, including its power up test. The fault LED will be on whenever a major fault has occurred. The carrier sync LED is activated on whenever the RF signal received by the transponder unit <b>445</b> is being correctly demodulated and the data is error free.

0249The LAN activity LED is activated on whenever the transponder unit <b>445</b> is actively outputting a multicast stream onto the 100 based-T LAN. The LAN collision LED indicates a collision has occurred on the 100 based T LAN.

Transponder Unit Software Operation

0250The transponder unit <b>445</b> is preferably controlled by an embedded software application. The software is responsible for configuring the hardware of the transponder unit <b>445</b>, monitoring all activity of the transponder unit <b>445</b>, and processing any backplane communications. The following sections describe the various interfaces and tasks that the software supports.

02511. Operating System

0252The underlying real time operating system (RTOS) is preferably VxWorks. VxWorks has been used in embedded processor designs for over 18 years and provides a preemptive operating environment with an integrated protocol stack and other types of networking support.

02532. Backplane Host Interface

0254The host interface over the backplane is implemented on a 10 based-T ethernet LAN <b>145</b> and the LAN protocol is TCP/IP. All commands that are issued over the backplane LAN <b>145</b> are processed identically to commands received over the RS-232 serial interface <b>487</b>. The controller unit <b>440</b> transmits commands to the transponder unit <b>445</b> over this interface. Still further, the controller unit <b>440</b> passes commands from the NOC <b>472</b> to the transponder unit <b>445</b>. In order, to support this interface, the operating system's standard networking protocols are used.

02553. RS-232 Serial Command Interface

0256The serial port <b>637</b> is used to provide a diagnostic port that can be used to send commands to the transponder unit <b>445</b>. The serial port software processes commands identically to the backplane host interface.

02574. Command Processor

0258The command-processing task parses incoming commands and executes any actions specified by the command.

0259The following sections (A-N) describe some example commands that the transponder unit <b>445</b> supports:

0260A. Add Group

0261The Add Group command allows the controller unit <b>440</b> to enable a group address to be passed through to the 100 based-T LAN <b>220</b>. When this command is executed, the microcontroller <b>640</b> enables the group's address within the lookup table in the SRAM <b>650</b>.

0262B. Delete Group

0263The Delete Group command allows the transponder unit <b>445</b> to disable a group address that is currently being passed through to the 100 based-T LAN <b>220</b>. When this command is executed, the microcontroller <b>655</b> disables the group's address within the lookup table in the SRAM <b>650</b>.

0264C. Address Route

0265The Address Route command is used to change the default IGMP address of a particular service or block of services. As described previously, the entire address block allocated to the video from the satellite can be moved or individual channel addresses can be moved. The transponder unit <b>445</b> is programmed with an address map and programs the FPGA <b>650</b> accordingly.

0266D. LAN Shutoff

0267The LAN shutoff command activates a relay on the output to the 100 based-T LAN <b>220</b> The controller unit <b>440</b> issues this command when the Panic Button has been pressed.

0268E. RS-232 Port

0269The RS-232 Port command is used to change the communication port parameters. These parameters include the baud rate, parity bit, stop bit, and number of data bit settings for the port.

0270F. Boot

0271A TFTP process, initiated by the operating system of the transponder unit <b>445</b> will handle the boot process. This process is handled over the backplane LAN <b>145</b>.

0272G. Status and Fault

0273The current status and fault histories can be queried through the Status and Fault commands. These commands are accessed by the controller unit <b>440</b>, the NOC <b>472</b>, and through the RS-232 port <b>675</b> to determine the status and fault histories of the transponder unit <b>445</b>.

0274H. Trace

0275Similar to the trace command on the controller unit <b>440</b>, the trace command of the transponder unit <b>445</b> can be used to configure (start, stop, or reset) the trace buffer, or it can be used to query the contents of a trace buffer. The trace buffer on the transponder unit <b>445</b> may be implemented to be much smaller than the trace buffer of the controller unit <b>440</b> so the controller unit <b>440</b> accesses data from the trace buffer of the transponder unit <b>445</b> periodically, resetting the trace after the query is complete.

0276I. Set Carrier

0277The Set Carrier command is used to set the L-Band frequency and data rate of the demodulator <b>555</b>. Once this command has been issued, the transponder unit <b>445</b> begins its acquisition process.

0278J. Scrambler Bypass

0279The Scrambler Bypass command allows the transponder unit <b>445</b> to pass data through the system that has not been scrambled at the head end. This mode is used during development, testing, and may be used in operation.

0280K. Reset

0281The Reset command allows an external source, such as the controller unit <b>440</b>, the NOC <b>472</b>, or a terminal attached the RS-232 port to initiate a soft reset on the transponder unit <b>445</b>.

0282L. ID Query

0283Each transponder unit <b>445</b> will have a unique serial number associated with it. The serial number will be stored in non-volatile memory. The ID Query command is used to either query or set the serial number. When setting the serial number, the command is preferably sufficiently scrambled to prevent the serial number from being inadvertently programmed to an incorrect value.

0284M. Memory Read and Memory Write

0285The Memory Read and Memory Write commands are used primarily for development and allows any hardware register or memory location to be manipulated manually. This includes being able to toggle LED's, update the seven-segment LED, or other I/O based activities.

0286N. Test Mode

0287The Test Mode command provides a means of putting various components of the transponder unit <b>445</b> into test modes. For example, one test mode generates test packets onto the 100 based-T output LAN. These packets include a packet counter which can be used by a client application to determine if the link is experiencing dropped packets. This command may also be used during board level testing with the results of the production tests stored in nonvolatile memory.

0288The transponder unit <b>445</b> is also provided with a number of diagnostic functions that support both power up and long-term diagnostic functions. On power up, all hardware subsystems are tested including the DRAM, the non-volatile memory, communications with the demodulator, and backplane ethernet connectivity. Long term diagnostic functions include validating the code space (CRC check of the code space), validating the non-volatile memory, and validating backplane connectivity.

0289On powering up, the operating system of the transponder unit <b>445</b> boots from its core from EPROM. After this, the transponder unit <b>445</b> requests its current version of firmware from the controller unit <b>440</b> using a Trivial File Transfer Protocol (TFTP). This method of booting the transponder unit <b>445</b> ensures that all transponder units in the IPMS chassis are running the same version of software. The operating system, as noted above, supports this type of boot procedure. Once the code has been downloaded, the code begins executing.

0290The transponder unit <b>445</b> also includes a status and fault monitoring task that keeps track of the current status as well as a fault history value that indicates all of the faults that have occurred since the last time the fault history was cleared. When the status of the transponder unit <b>445</b> changes, a trace event is logged into the non-volatile memory of the transponder unit <b>445</b> and the controller unit <b>440</b> is notified that the transponder unit <b>445</b> has at least one event saved in its non-volatile memory. Since the controller unit <b>440</b> preferably maintains a much larger trace buffer than the transponder unit <b>445</b>, the controller unit <b>440</b> is responsible for pulling data out of the log of the transponder unit <b>445</b> prior to overflow thereof.

0291The transponder unit <b>445</b> also includes an internal watchdog timer. If the internal watchdog timer has expired, the transponder unit <b>445</b> assumes that its internal software has reached an unstable condition. As such, the transponder unit <b>445</b> will shutdown all current tasks and then reset. The reset re-initializes the transponder unit <b>445</b> and begins a re-boot procedure. The transponder unit <b>445</b> will preferably log this event in non-volatile memory. The controller unit <b>440</b> recognizes this condition, logs an error, and reconfigures the transponder unit <b>445</b>.

0292The transponder unit <b>445</b> shuts down the outgoing IGMP streams after the backplane LAN <b>145</b> becomes inoperable for a specified period of time. If the backplane LAN <b>145</b> has become inoperable, the transponder unit <b>445</b> assumes that the controller unit <b>440</b> has ceased operation. Since the controller unit <b>440</b> is responsible for all of the protocol communication of the IPMS <b>120</b> with external devices, the transponder unit <b>445</b> assumes that the controller unit <b>440</b> can no longer receive ‘leave’ requests from clients. In order to prevent “bombarding” the client with potentially unwanted data, the transponder unit <b>445</b> will shutdown all outgoing streams.

0293Once backplane LAN <b>145</b> communications are restored, the transponder unit <b>445</b> will request its current channel mapping and begin transmitting again. The transponder unit <b>445</b> logs this event in non-volatile memory.

0294Each transponder unit <b>445</b> is preferably implemented on a single printed circuit card having the ability to be “hot swapped”. In order for this to be implemented, the connectors between the printed circuit card and its corresponding backplane connector include longer pins for the power and grounds signals such that the transponder unit on the printed circuit board has power applied to it before output signals reach the connectors of the backplane bus.

0295A “hot sparing” system can also be employed. In such instances, one or more spare transponder units are included in the IPMS <b>120</b> chassis. The spare transponder units can be configured to take over for failed transponder units. This configuration procedure will be handled by the controller unit via the backplane LAN <b>145</b>.

0296The IPMS <b>120</b> may have several means of helping an installer point the antenna. To this end, each transponder unit <b>445</b> provides an AGE indication that provides a means of identifying when the satellite signal is maximized. This indication alone will not necessarily provide the best signal, however, due to different types of interference (adjacent satellite, cross-pole, etc.). Many times the interference should be minimized instead of the signal level being maximized. To aid in this type of decision making each transponder unit <b>445</b> will provide an Eb/No reading that indicates the quality of the incoming signal. This measurement should be maximized. The values of these parameters will be passed to the controller unit <b>440</b>, which can present them in a user-friendly manner to the installer. This data may also be available through the serial port <b>637</b> of the transponder unit <b>445</b>.

0297As also illustrated in <figref idref="DRAWINGS">FIG. 18</figref>, the transponder unit <b>445</b> also includes a 10baseT connection to the controller unit. This interface includes an ethernet transceiver <b>672</b> and transformer <b>673</b>. It should be furthered noted that substantially all of the principal units of the transponder unit <b>445</b> communicate with microprocessor <b>580</b> over a communications bus.

0298<figref idref="DRAWINGS">FIGS. 21-26</figref> illustrate various example ISP configurations and scenarios using the IPMS <b>120</b> of the present invention. In each scenario, an IP Multicast system application delivers IP multicast streams to Internet Service Providers' (ISPs) clients. The stream content is received, for example, over a satellite by the IPMS which is directly attached to an ISP's local backbone. The stream flows over the local backbone and through the ISP's networking equipment to the client's desktop browser as shown, for example, at arrow <b>680</b> of <figref idref="DRAWINGS">FIG. 21</figref>.

0299There are a number of goals for each of the following ISP configurations and scenarios. They include: <ul id="ul0003" list-style="none"><li id="ul0003-0001" num="0000"><ul id="ul0004" list-style="none"><li id="ul0004-0001" num="0300">Delivering streams to clients on demand, and quickly removing these streams from the ISP backbone when the client is finished</li><li id="ul0004-0002" num="0301">Delivering streams to clients while minimizing the traffic on the local backbone of the ISP;</li><li id="ul0004-0003" num="0302">Delivering streams to clients while minimizing additional traffic to other clients: and</li><li id="ul0004-0004" num="0303">Delivering streams to clients while not introducing any additional traffic to the Internet.</li></ul></li></ul>

0304Achieving these goals requires that the networking equipment utilized in the system support various protocol interactions (e.g. IP, IGMP, PIM).

ISP Model 1—Simple ISP (Simple IPMS

120

)

0305ISP MODEL <b>1</b> is illustrated in <figref idref="DRAWINGS">FIG. 21</figref>. In this example Client A joins, receives, and leaves Multicast Group 239.216.63.248 from the IPMS <b>120</b>. Next, Client A joins and receives Multicast Group 239.216.0.8. Then, network elements query the group so that multicast traffic can be pruned in the event group members silently leave the group. Finally, Client A leaves Multicast Group 239.216.0.8.

0306The IPMS <b>120</b> filters the multicast stream so that which are currently “joined will be placed on the ISP LAN several assumptions associated with scenario, they are: <ul id="ul0005" list-style="none"><li id="ul0005-0001" num="0000"><ul id="ul0006" list-style="none"><li id="ul0006-0001" num="0307">IPMS <b>120</b> IP Address128.0.0.255, Client AIP Address=128.0.0.1:</li><li id="ul0006-0002" num="0308">All IP Multicast Addresses provided by the IPMS <b>120</b> are “Administratively Scoped” addresses in the range 239.216.0.0 through 239.219.255.255 (addresses 239.216.0.8 and 239.216.63.248 used in this example); and</li><li id="ul0006-0003" num="0309">IPMS <b>120</b>. Access Switch/Routers #<b>1</b> and #<b>2</b>, and Gateway Router <b>685</b> support IGMP V2.</li></ul></li></ul>

0310During initial handshake, the following occurs: <ul id="ul0007" list-style="none"><li id="ul0007-0001" num="0000"><ul id="ul0008" list-style="none"><li id="ul0008-0001" num="0311">1. Client A sends an IGMP V2 Membership Report (Destination IP address=239.216.63.248, Group address=239.216.63.248);</li><li id="ul0008-0002" num="0312">2. Access Switch/Router #<b>1</b> forwards IGMP V2 Membership Report to backbone LAN <b>220</b> (assuming it has no other interfaces in Group address=239.216.63.248);</li><li id="ul0008-0003" num="0313">3. Gateway Router does not forward “Administratively Scoped” membership report to the internet;</li><li id="ul0008-0004" num="0314">4. IPMS <b>120</b> receives IGMP V2 Membership Report and transmits 239.216.63.248 multicast onto Filtered Stream—the data payload of the 239.216.63.248 multicast includes the IPMS IP Address, and a test pattern;</li><li id="ul0008-0005" num="0315">5. Access Switch/Router #<b>1</b> forwards 239.216.63.248 multicast to Client A only;</li><li id="ul0008-0006" num="0316">6. Gateway Router ignores 239.216.63.248 multicast as an administratively scoped address;</li><li id="ul0008-0007" num="0317">7. Client A receives IPMS IP Address and test pattern and then sends an IGMP Leave Group (Destination IP address=224.0.0.2, Group address=239.216.63.248);</li><li id="ul0008-0008" num="0318">8. Access Switch/Router #<b>1</b> verifies it has no other interfaces in Group address=239.216.63.248 (using IGMP Query), forwards IGMP Leave Group to LAN backbone <b>220</b>, and immediately stops forwarding the 239.216.63.248 multicast to Client A;</li><li id="ul0008-0009" num="0319">9. Gateway Router <b>685</b> ignores IGMP Leave Group command; and</li><li id="ul0008-0010" num="0320">10. IPMS <b>120</b> receives IGMP Leave Group, verifies it has no other clients in Group address=239.216.63.248 (using IGMP Query), and immediately stops transmission of the 239.216.63.248 multicast data.</li></ul></li></ul>

0321When Client A joins Multicast Group 239.216.0.8, the following occurs: <ul id="ul0009" list-style="none"><li id="ul0009-0001" num="0000"><ul id="ul0010" list-style="none"><li id="ul0010-0001" num="0322">11. Client A sends an IGMP V2 Membership Report (Destination IP address=239.216.0.8, Group address=239.216.0.8);</li><li id="ul0010-0002" num="0323">12. Access Switch/Router #<b>1</b> forwards IGMP V2 Membership Report to LAN backbone <b>220</b> (assuming it has no other interfaces in Group address=239.216.0.8);</li><li id="ul0010-0003" num="0324">13. Gateway Router ignores IGMP V2 Membership Report for “Administratively Scoped” address;</li><li id="ul0010-0004" num="0325">14. IPMS <b>120</b> receives IOMP V2 Membership Report and transmits 239.216.0.8 multicast onto Filtered Stream:</li><li id="ul0010-0005" num="0326">15. Access Switch/Router #<b>1</b> forwards 239.216.0.8 multicast to Client A only;</li><li id="ul0010-0006" num="0327">16. Gateway Router ignores 239.216.0.8 multicast as an administratively scoped address;</li><li id="ul0010-0007" num="0328">17 Client A receives 239.216.0.8 multicast.</li></ul></li></ul>

0329In order to ensure that Client A has not silently left the multicast group, the system implements a querying of the Multicast Group 239.216.0.8 based on query timers configured in the access switch/router and IPMS <b>120</b>. This query proceeds in the following manner; <ul id="ul0011" list-style="none"><li id="ul0011-0001" num="0000"><ul id="ul0012" list-style="none"><li id="ul0012-0001" num="0330">18. Access Switch/Router #<b>1</b> sends IGMP Group-Specific Query (Destination IP address=239.216.0.8, Group address=239.216.0.8) to Client A;</li><li id="ul0012-0002" num="0331">19. If Access Switch/Router #<b>1</b> receives an IGMP V2Membership Report (Destination IP address=239.216.0.8, Group address=239.216.0.8), do nothing;</li><li id="ul0012-0003" num="0332">20. If there is no Membership Report then Access Switch/Router #<b>1</b> sends IGMP Leave Group (Destination IP address=224.0.0.2, Group address=239.216.0.8) to the LAN backbone <b>220</b> and immediately stops forwarding the 239.216.0.8 multicast to all clients (including Client A): system operation then proceeds with Step 26 below.</li></ul></li></ul>

0333The followings steps occur independently: <ul id="ul0013" list-style="none"><li id="ul0013-0001" num="0000"><ul id="ul0014" list-style="none"><li id="ul0014-0001" num="0334">21. IPMS <b>120</b> sends IGMP Group-Specific Query (Destination IP address=239.216.0.8, Group address=239.216.0.8);</li><li id="ul0014-0002" num="0335">22. If IPMS <b>120</b> receives an IGMP V2 Membership Report (Destination IP Address=239.216.0.8; Group Address=239.216.0.8) do nothing;</li><li id="ul0014-0003" num="0336">23. If there is no Membership Report then IPMS <b>120</b> immediately stops transmission of 239.216.0.8 multicast (group left due to no response);</li></ul></li></ul>

0337The following sequence of events occur when Client A leaves the Multicast Group 239.216.0.8; <ul id="ul0015" list-style="none"><li id="ul0015-0001" num="0000"><ul id="ul0016" list-style="none"><li id="ul0016-0001" num="0338">24. Client A sends an IGMP Leave Group(Destination IP Address=224.0.0.2, Group Address=239.216.0.8);</li><li id="ul0016-0002" num="0339">25. Access Switch/Router #<b>1</b> receives IGMP Leave Group, verifies it has no other interfaces in Group Address=239.216.0.8 (using IGMP Query), forwards IGMP Leave Group to IAN backbone <b>220</b>, and immediately stops forwarding the 239.216.0.8 multicast to Client A;</li><li id="ul0016-0003" num="0340">26. Gateway Router ignores IGMP Leave Group command since it involves an administratively scoped address;</li><li id="ul0016-0004" num="0341">27. IPMS <b>120</b> receives IGMP Leave Group, verifies it has no other Clients in Group Address=239.216.0.8 (using IGMP Query), and immediately stops transmission of 239.216.0.8 multicast.</li></ul></li></ul>

ISP Model

2

—ISP with Multiple LAN Segments/Multicast

0342In the example shown in <figref idref="DRAWINGS">FIG. 22</figref>, Client A joins, receives, and leaves Multicast Group 239.216.63.248 to receive a brief multicast from the IPMS <b>120</b>. Next, Client A joins and receives Multicast Group 239.216.0.8. Then, network elements query the group so that multicast traffic can be pruned in the event group members silently leave the group. Finally, Client A leaves Multicast Group 239.216.0.8.

0343The Simple IPMS <b>120</b> filters the Multicast Steam so that only Multicast Addresses which are currently “joined” will be sent to the LAN Switch. The LAN Switch filters the Multicast Stream sent to each segment so that only Multicast Addresses which are currently “joined” by Clients on a segment will be placed on that segment.

0344There are several assumptions associated with the illustrated scenario.

0345They are: <ul id="ul0017" list-style="none"><li id="ul0017-0001" num="0000"><ul id="ul0018" list-style="none"><li id="ul0018-0001" num="0346">IPMS <b>120</b> IP Address=128.0.0.255, Client AIP Address=128.0.0.1;</li><li id="ul0018-0002" num="0347">All IP Multicast Addresses transmitted by the IPMS <b>120</b> are “Administratively Scoped” addresses in the range 239.216.0.0 through 239.219.255.255 (addresses 239.216.0.8 and 239.216.63.248 used in this example);</li><li id="ul0018-0003" num="0348">Access Switch/Router, LAN Switch, and IPMS <b>120</b> support IGMP V2;</li><li id="ul0018-0004" num="0349">LAN Switch configuration: <ul id="ul0019" list-style="none"><li id="ul0019-0001" num="0350">Virtual LAN#<b>1</b>=LAN Segment #<b>1</b>, Backbone, IPMS <b>120</b> Control, Filtered Stream#<b>1</b></li><li id="ul0019-0002" num="0351">Virtual LAN#<b>2</b>=LAN Segment #<b>2</b>, Backbone, IPMS <b>120</b> Control, Filtered Stream#<b>2</b></li></ul></li><li id="ul0018-0005" num="0352">Gateway Router <b>690</b> does not forward IGMP messages with “Administratively Scoped” Multicast addresses (this includes messages with Dest IP239.*.*.*, and IGMP messages with Dest IP224.0.0.1/224.0.0.2 that specify a Group Address=239.**.*).</li></ul></li></ul>

0353During initial handshake, the following occurs: <ul id="ul0020" list-style="none"><li id="ul0020-0001" num="0000"><ul id="ul0021" list-style="none"><li id="ul0021-0001" num="0354">1. Client A sends an IGMP V2 Membership Report (Destination IP Address=239.216.63.248, Group Address=239.216.63.248);</li><li id="ul0021-0002" num="0355">2. Access Switch/Router #<b>1</b> forwards IGMP V2 Membership Report to LAN Segment #<b>1</b> (assuming it has no other interfaces in Group Address=239.216.63.248);</li><li id="ul0021-0003" num="0356">3. LAN Switch receives IGMP V2 Membership Report, forwards the message, and enables transmission of 239.216.63.248 multicast to LAN Segment #<b>1</b>;</li><li id="ul0021-0004" num="0357">4. Gateway Router does not forward “Administratively Scoped” membership report to the Internet;</li><li id="ul0021-0005" num="0358">5. IPMS <b>120</b> receives IGMP V2 Membership Report and transmits 239.216.63.248 multicast out NIC#<b>2</b> onto Filtered Stream—the data payload of the 239.216.63.248 multicast includes the IPMS <b>120</b> IP Address, and a test pattern;</li><li id="ul0021-0006" num="0359">6. LAN Switch forwards 239.216.63.248 multicast to LAN Segment #<b>1</b> only;</li><li id="ul0021-0007" num="0360">7. Access Switch/Router #<b>1</b> forwards 239.216.63.248 multicast to Client A only;</li><li id="ul0021-0008" num="0361">8. Client A receives IPMS <b>120</b> IP Address and test pattern and then sends an IGMP Leave Group(Destination IP Address=224.0.0.2, Group Address=239.216.63.248);</li><li id="ul0021-0009" num="0362">9. Access Switch/Router #<b>1</b> receives IGMP Leave Group, verifies it has no other interfaces in Group Address=239.216.63.248 (using IGMP Query), forwards IGMP Leave Group to LAN Segment #<b>1</b> and immediately stops forwarding the 239.216.63.248 multicast to Client A;</li><li id="ul0021-0010" num="0363">10. LAN Switch receives IGMP Leave Group, forwards the message, verifies that it has no other LAN Segment #<b>1</b> Clients in Group Address=239.216.63.248 (using IGMP Query), and immediately stops transmission of 239.216.63.248 multicast to LAN Segment #<b>1</b>;</li><li id="ul0021-0011" num="0364">11. Gateway Router ignores IOMP Leave Group since it is an administratively scoped address;</li><li id="ul0021-0012" num="0365">12. IPMS <b>120</b> receives IGMP Leave Group, verifies it has no other client in Group Address=239.216.63.248 (using IGMP Query), and immediately stops transmission of the 239.216.63.248 multicast.</li></ul></li></ul>

0366When Client A joins the Multicast Group 239.216.0.8, the following operations occur: <ul id="ul0022" list-style="none"><li id="ul0022-0001" num="0000"><ul id="ul0023" list-style="none"><li id="ul0023-0001" num="0367">13. Client A sends an IGMP V2 Membership Report (Destination IP Address=239.216.0.8, Group Address=239.216.0.8);</li><li id="ul0023-0002" num="0368">14. Access Switch/Router #<b>1</b> forwards IGMP V2 Membership Report to LAN Segment #<b>1</b> (assuming it has no other interfaces in Group Address=239.216.63.248);</li><li id="ul0023-0003" num="0369">15. LAN Switch receives IGMP V2 Membership Report, forwards the message, and enables transmission of239.216.0.8 multicast to LAN Segment #<b>1</b>;</li><li id="ul0023-0004" num="0370">16. Gateway Router ignores IGMP Leave Group since it is an administratively scoped address;</li><li id="ul0023-0005" num="0371">17. IPMS <b>120</b> receives IGMP V2 Membership Report and transmits 239.216.0.8 multicast out NIC#<b>2</b> onto Filtered Stream;</li><li id="ul0023-0006" num="0372">18. LAN Switch forwards 239.216.0.8 multicast to LAN Segment #<b>1</b> only;</li><li id="ul0023-0007" num="0373">19. Access Switch/Router #<b>1</b> forwards 239.216.0.8 multicast to Client A only; and</li><li id="ul0023-0008" num="0374">20. Client A receives 239.216.0.8 multicast.</li></ul></li></ul>

0375In order to ensure that Client A has not silently left the multicast group, the system implements a querying of the Multicast Group 239.216.0.8 based on query timers configured in the access switch I router and IPMS <b>120</b>. This query, proceeds in the following manner; <ul id="ul0024" list-style="none"><li id="ul0024-0001" num="0000"><ul id="ul0025" list-style="none"><li id="ul0025-0001" num="0376">21. Access Switch/Router #<b>1</b> sends IOMP Group-Specific Query (Destination IP Address 239.216.0.8, Group Address=239.216.0.8) to Client A;</li><li id="ul0025-0002" num="0377">22. If Access Switch/Router #<b>1</b> receives an IGMP V2 Membership Report(Destination IP Address=239.216.0.8, Group Address=239.216.0.8), do nothing;</li><li id="ul0025-0003" num="0378">23. If there is no Membership Report then Access Switch/Router #<b>1</b> sends IGMP Leave Group(Destination IP Address=224.0.0.2, Group Address=239.216.0.8) to LAN Segment #<b>1</b> and immediately stops forwarding the 239.216.0.8 multicast to all clients (including Client A): and operations then proceed at Step 32.</li></ul></li></ul>

0379The following steps occur independently: <ul id="ul0026" list-style="none"><li id="ul0026-0001" num="0000"><ul id="ul0027" list-style="none"><li id="ul0027-0001" num="0380">24. LAN Switch sends IGMP Group-Specific Query (Destination IP address 239.216.0.8, Group Address 239.216.0.8) to LAN Segment #<b>1</b>;</li><li id="ul0027-0002" num="0381">25. If LAN Switch receives IGMP V2 Membership Report (Destination IP Address=239.216.0.8, Group Address=239.216.0.8) do nothing;</li><li id="ul0027-0003" num="0382">26. If there is no Membership Report then LAN Switch sends IGMP Leave Group (Destination IP Address=224.0.0.2, Group Address=239.216.0.8) to IPMS <b>120</b> and immediately stops transmission of 239.16.0.8 multicast to LAN Segment #<b>1</b> (group is left due to no response);</li><li id="ul0027-0004" num="0383">27. IPMS <b>120</b> sends IGMP Group-Specific Query (Destination IP Address=239.216.0.8, Group Address=239.216.0.8);</li><li id="ul0027-0005" num="0384">28. If IPMS <b>120</b> receives IOMP V2 Membership Report (Destination IP Address=239.216.0.8, Group Address=239.216.0.8), do nothing; and</li><li id="ul0027-0006" num="0385">29. If there is no Membership Report then IPMS <b>120</b> immediately stops transmission of 239.216.0.8 multicast (group left due to no response).</li></ul></li></ul>

0386The following sequence of events occur when Client A leaves the Multicast Group 239.216.0.8: <ul id="ul0028" list-style="none"><li id="ul0028-0001" num="0000"><ul id="ul0029" list-style="none"><li id="ul0029-0001" num="0387">30. Client A sends an IGMP Leave Group (Destination IP Address=224.0.0.2, Group Address=239.216.0.8);</li><li id="ul0029-0002" num="0388">31. Access Switch/Router <b>1</b> receives IOMP Leave Group, verifies it has no other interfaces in Group Address=239.216.0.8 (using IGMP Query), and forwards IGMP Leave Group to LAN Segment #<b>1</b> and immediately stops forwarding the 239.216.0.8 multicast to Client A;</li><li id="ul0029-0003" num="0389">32. LAN Switch receives IGMP Leave Group, forwards the message, verifies it has no other LAN Segment #<b>1</b> Clients in Group Address=239.216.0.8 (using IGMP Query), and immediately stops transmission of 239.216.0.8 multicast to LAN Segment #<b>1</b>;</li><li id="ul0029-0004" num="0390">33. Gateway Router ignores IOMP Leave Group since it is an administratively scoped address;</li><li id="ul0029-0005" num="0391">34. IPMS <b>120</b> receives IGMP Leave Group, verifies it has no other Clients in Group Address=239.216.0.8 (using IGMP Query), and immediately stops transmission of 239.216.0.8 multicast.</li></ul></li></ul>

ISP Model

3

—Large ISP with Affiliated ISP

0392The system of <figref idref="DRAWINGS">FIG. 23</figref> provides multicast streams to all ISP Clients and Remote ISP Clients on demand. In this example. Remote LSD Client H joins, receives, and leaves Group 239.216.63.248 to receive a brief multicast from the IPMS <b>120</b>. Next, Client H joins and receives Multicast Group 239.216.0.8. Then, network elements query the group so that multicast traffic can be pruned in the event group members silently leave the group. Finally, Client H leaves Multicast Group 239.216.0.8.

0393The Simple IPMS <b>120</b> filters the Multicast Stream so that only multicast addresses that are currently joined” will be sent to the LAN Switch <b>695</b>. The LAN Switch <b>695</b> filters the multicast stream sent to each segment so that only multicast addresses which are currently “joined” by clients on a LAN segment will be placed on the LAN segment. For the Remote ISP, the multicast streams do not use bandwidth on the Router link to the ISP (to avoid impacting normal Internet traffic). Accordingly, a bridged connection <b>700</b> is used to send the streams to the Remote ISP. The only segments that receive the multicast streams are LAN Segment #<b>1</b> and the bridged connection <b>700</b> to the Remote ISP that is considered to be LAN Segment #<b>2</b>.

0394There are several assumptions associated with the illustrated scenario, such as, for example: <ul id="ul0030" list-style="none"><li id="ul0030-0001" num="0000"><ul id="ul0031" list-style="none"><li id="ul0031-0001" num="0395">IPMS <b>120</b> IP Address=128.0.0.255, Client H IP Address=128.0.0.8;</li><li id="ul0031-0002" num="0396">All IP Multicast Addresses transmitted by the IPMS <b>120</b> are “Administratively Scoped” addresses in the range 239.216.0.0 through 239.219.255.255 (addresses 239.216.0.8 and 239.216.63.248 used in this example);</li><li id="ul0031-0003" num="0397">Access Switch/Routers, LAN Switches, and IPMS <b>120</b> support IGMP V2;</li><li id="ul0031-0004" num="0398">LAN Switch configuration: Virtual LAN#<b>1</b>=LAN Segment #<b>1</b>. Backbone, IPMS <b>120</b> Control, Filtered Stream#<b>1</b>; Virtual LAN#<b>2</b>=LAN Segment #<b>2</b>, IPMS <b>120</b> Control, Filtered Stream#<b>2</b>; and virtual LAN#<b>3</b>=LAN Segment #<b>3</b>, Backbone.</li><li id="ul0031-0005" num="0399">LAN Bridge configuration: Only forward 239.216.0.0-239.219.255.255; 224.0.0.1, 224.0.0.2;</li><li id="ul0031-0006" num="0400">Remote Router does not forward IGMP messages with “Administratively Scoped” Multicast addresses (this includes messages with Destination IP=239.*.*.*, and IGMP messages with Destination IP=224.0.0.1/224.0.0.2 that specify a Group Address=239.*.**)</li></ul></li></ul>

0401During initial handshake, the following occurs: <ul id="ul0032" list-style="none"><li id="ul0032-0001" num="0000"><ul id="ul0033" list-style="none"><li id="ul0033-0001" num="0402">1. Client H sends an IGMP V2 Membership Report (Destination IP Address=239.216.63.248, Group Address=239.216.63.248);</li><li id="ul0033-0002" num="0403">2. Access Switch/Router #<b>2</b> forwards IGMP V2 Membership Report to Remote Backbone (assuming, it has no other interfaces in Group Address=239.216.63.248) seminal LAN Bridge forwards IGMP V2 Membership Report;</li><li id="ul0033-0003" num="0404">3. Remote Router ignores IGMP V2 Membership Report as an administratively scoped address</li><li id="ul0033-0004" num="0405">4. LAN Switch receives IOMP V2 Membership Report, forwards the message, and enables transmission of 239.216.63.248 multicast to LAN Segment #<b>2</b>.</li><li id="ul0033-0005" num="0406">5. IPMS <b>120</b> receives IGMP V2 Membership Report and transmits 239.216.63.248multicast out NIC#<b>2</b> onto Filtered Stream—the data payload of the 239.216.63.248 multicast includes the IPMS <b>120</b> IP Address, and a test pattern;</li><li id="ul0033-0006" num="0407">6. LAN Switch forwards 239.216.63.248 multicast to LAN Segment #<b>2</b> only;</li><li id="ul0033-0007" num="0408">7. LAN Bridge forwards the 239.216.63.248 multicast data;</li><li id="ul0033-0008" num="0409">8. Access Switch/Router #<b>2</b> forwards 239.216.63.248 multicast to Client H only;</li><li id="ul0033-0009" num="0410">9. Remote Router ignores 239.216.63.248 multicast data;</li><li id="ul0033-0010" num="0411">10. Client H receives IPMS <b>120</b> IP Address and test pattern and then sends an IGMP Leave Group (Destination IP Address=224.0.0.2, Group Address=239.216.63.248);</li><li id="ul0033-0011" num="0412">11. Access Switch/Router #<b>2</b> receives IGMP Leave Group, verifies it has no other interfaces in Group Address=239.216.63.248 (using IGMP Query),</li><li id="ul0033-0012" num="0413">12. Forwards IGMP Leave Group to LAN Bridge, and immediately stops forwarding the 239.216.63.248 multicast to Client H;</li><li id="ul0033-0013" num="0414">13. LAN Bridge forwards IGMP Leave Group;</li><li id="ul0033-0014" num="0415">14. Remote Router ignores IGMP Leave Group as an administratively scoped address</li><li id="ul0033-0015" num="0416">15. LAN Switch receives IGMP Leave Group, forwards the message, verifies it has no other LAN Segment an Clients in Group Address=239.216.63.248 (using IOMP Query), and immediately stops transmission of 239.216.63.248 multicast to LAN Segment #<b>2</b>;</li><li id="ul0033-0016" num="0417">16. IPMS <b>120</b> receives IGMP Leave Group, verifies it has no other Clients in Group Address=239.216.63.248 (using IGMP Query), and immediately stops transmission of the 239.216.63.248 multicast:</li></ul></li></ul>

0418When Client H joins the Multicast Group 239.216.0.8, the following actions occur: <ul id="ul0034" list-style="none"><li id="ul0034-0001" num="0000"><ul id="ul0035" list-style="none"><li id="ul0035-0001" num="0419">17. Client H sends an IGMP V2 Membership Report (Destination IP Address=239.216.0.8, Group Address=239.216.0.8);</li><li id="ul0035-0002" num="0420">18. Access Switch Router #<b>2</b> forwards IGMP V2 Membership Report to Remote Backbone (assuming it has no other interfaces in Group Address=239.216.0.8);</li><li id="ul0035-0003" num="0421">19. LAN Bridge forwards IGMP V2 Membership Report;</li><li id="ul0035-0004" num="0422">20. Remote Router ignores IGMP V2 Membership Report as an administratively scoped address;</li><li id="ul0035-0005" num="0423">21. LAN Switch receives IOMP V2 Membership Report, forwards the message, and enables transmission of 239.216.0.8 multicast to LAN Segment #<b>2</b>;</li><li id="ul0035-0006" num="0424">22. IPMS <b>120</b> receives IGMP V2 Membership Report and transmits 239.216.0.8 multicast out NIC#<b>2</b> onto Filtered Stream;</li><li id="ul0035-0007" num="0425">23. LAN Switch forwards 239.216.0.8 multicast to LAN Segment #<b>2</b> only;</li><li id="ul0035-0008" num="0426">24. LAN Bridge forwards the 239.216.0.8 multicast;</li><li id="ul0035-0009" num="0427">25. Access Switch/Router #<b>2</b> forwards 239.216.0.8 multicast to Client H only;</li><li id="ul0035-0010" num="0428">26. Remote Router ignores 239.216.0.8 multicast</li><li id="ul0035-0011" num="0429">27. Client H receives 239.216.0.8 multicast.</li></ul></li></ul>

0430In order to ensure that Client H has not silently left the multicast group, the system implements a querying of the Multicast Group 239.216.0.8 based on query timers configured in the access switch I router and IPMS <b>120</b>. This query proceeds in the following manner: <ul id="ul0036" list-style="none"><li id="ul0036-0001" num="0000"><ul id="ul0037" list-style="none"><li id="ul0037-0001" num="0431">28. Access Switch/Router #<b>2</b> sends IGMP Group-Specific Query (Destination IP address=239.216.0.8, Group Address=239.216.0.8) to Client H;</li><li id="ul0037-0002" num="0432">29. If Access Switch/Router #<b>2</b> receives an IGMP V2 Membership Report (Destination IP Address=239.116.0.8, Group Address=239.216.0.8), do nothing;</li><li id="ul0037-0003" num="0433">30. If there is no Membership Report then Access Switch/Router #<b>2</b> sends JGMP:</li><li id="ul0037-0004" num="0434">Leave Group (Destination IP Address=224.0.0.2, Group Address=239.216.0.8) to Remote Backbone and immediately stops forwarding the 239.216.0.8 multicast to Client H, operations then proceed to Step 40.</li></ul></li></ul>

0435The following steps occur independently: <ul id="ul0038" list-style="none"><li id="ul0038-0001" num="0000"><ul id="ul0039" list-style="none"><li id="ul0039-0001" num="0436">31. LAN Switch sends IGMP Group-Specific Query (Destination IP Address 239.216.0.8, Group Address=39.216.0.8) to LAN Segment #<b>2</b>;</li><li id="ul0039-0002" num="0437">32. LAN Bridge forwards IGMP Group-Specific Query;</li><li id="ul0039-0003" num="0438">33. If LAN Switch receives an IGMP V2 Membership Report (Destination IP Address=239.216.0.8, Group Address=239.216.0.8), do nothing;</li><li id="ul0039-0004" num="0439">34. If there is no Membership Report then LAN Switch immediately stops transmission of 239.216.0.8 multicast to LAN Segment #<b>2</b> (group is left due to no response);</li><li id="ul0039-0005" num="0440">35. IPMS <b>120</b> sends IGMP Group-Specific Query (Destination IP Address=239.216.0.8, Group Address=239.216.0.8)</li><li id="ul0039-0006" num="0441">36. If IPMS <b>120</b> receives IGM V2 Membership Report (Destination IP Address=239.216.0.8, Group Address=239.216.0.8), do nothing;</li><li id="ul0039-0007" num="0442">37. If there is no Membership Report then IPMS <b>120</b> immediately stops transmission of 239.216.0.8 multicast (group left due to no response).</li></ul></li></ul>

0443The following sequence of operations occur when Client H leaves Group address=239.216.0.8: <ul id="ul0040" list-style="none"><li id="ul0040-0001" num="0000"><ul id="ul0041" list-style="none"><li id="ul0041-0001" num="0444">38. Client H sends an IGMP Leave Group (Destination IP Address=224.0.0.2, Group Address=239.216.0.8);</li><li id="ul0041-0002" num="0445">39. Access Switch/Router receives IGMP Leave Group, verifies it has no other interfaces in Group Address=239.216.0.8 (using IGMP Query), and forwards IGMP Leave Group to Remote Backbone and immediately stops forwarding the 239.216.0.8 multicast to Client H.</li><li id="ul0041-0003" num="0446">40. LAN Bridge forwards IGMP Leave Group;</li><li id="ul0041-0004" num="0447">41. Remote Router ignores IOMP Leave Group since it is an administratively scoped address;</li><li id="ul0041-0005" num="0448">42. LAN Switch receives the IGMP Leave Group command, forwards the message, verifies it has no other LAN Segment #<b>2</b> Clients in Group Address=239.216.0.8, and immediately stops transmission of 239.216.0.8 multicast to LAN Segment #<b>2</b>;</li><li id="ul0041-0006" num="0449">43. IPMS <b>120</b> receives IOMP Leave Group, verifies it has no other Clients in Group Address=239.216.0.8 (using IGMP Query), and immediately stops transmission of the 239.216.0.8 multicast.</li></ul></li></ul>

0450If Remote Clients join “normal” multicast groups (i.e., those transmitted over the backbone of the Internet) through the Remote Router, the 224.0.0.1 and 224.0.0.2 IGMP V2 messages will be bridged to the LAN Switch. The LAN Switch forwards the IGMP messages through LAN segment #<b>2</b> to the IPMS <b>120</b>. The IPMS <b>120</b> ignores the messages issued for a non-existent stream.

ISP Model

4

—Simple ISP Scenario

2

0451In the scenario of <figref idref="DRAWINGS">FIG. 24</figref>. Client A and the IPMS <b>120</b> first join Multicast Group 239.216.63.240 to establish a mechanism for sending multicast control messages to each other. Next, Client A joins, receives, and leaves Multicast Group 239.216.63.248 to receive a brief multicast from the IPMS <b>120</b>. After that, Client A joins and receives Multicast Group 239.216.0.8. Then, network elements query the group so that multicast traffic can be pruned in the event group members silently leave the group. Finally, Client A leaves Multicast Group 239.216.0.8. As above, IPMS <b>120</b> filters the multicast stream so that only multicast addresses which are currently ‘joined’ are provided on the backbone of the LAN.

0452In this scenario, several assumptions have been made. They, are: <ul id="ul0042" list-style="none"><li id="ul0042-0001" num="0000"><ul id="ul0043" list-style="none"><li id="ul0043-0001" num="0453">IPMS <b>120</b> IP Address=128.0.0.255, Client A IP Address=128.0.0.1;</li><li id="ul0043-0002" num="0454">All IP Multicast Addresses transmitted by the IPMS <b>120</b> are “Administratively Scoped” addresses in the range 239.216.0.0 through 239.219.255.255 (addresses 239.216.0.8, 239.216.63.24 through 239.216.63.248 being used in this example);</li><li id="ul0043-0003" num="0455">IPMS <b>120</b>, Access Switch/Routers, and Gateway Router support IGMP V2 protocol;</li><li id="ul0043-0004" num="0456">The IPMS <b>120</b> and the clients use MulticastAddress=239.216.63.240 to pass proprietary UDP packets using is UDP Port=255.</li></ul></li></ul>

0457The following operations occur during initial handshake: <ul id="ul0044" list-style="none"><li id="ul0044-0001" num="0000"><ul id="ul0045" list-style="none"><li id="ul0045-0001" num="0458">1. IPMS <b>120</b> sends an IGMP V2 Membership Report (Destination P Address=239.216.63.240, Group Address 239.216.63.240);</li><li id="ul0045-0002" num="0459">2. The 239.216.63.240 multicast will be used for multicast control messages;</li><li id="ul0045-0003" num="0460">3. Gateway Router does not forward “Administratively Scoped” membership report to the Internet;</li><li id="ul0045-0004" num="0461">4. Client A sends an IGMP V2 Membership Report (Destination IP Address=239.216.63.240, Group Address=239.26.63.240);</li><li id="ul0045-0005" num="0462">5. Access Switch/Router #<b>1</b> forwards IOMP V2 Membership Report to LAN Segment#<b>1</b> (assuming it has no other interfaces in Group Address=239.216.63.240);</li><li id="ul0045-0006" num="0463">6. LAN Switch receives IGMP V2 Membership Report, forwards the message, and adds Client A to the Group;</li><li id="ul0045-0007" num="0464">7. Gateway Router does not forward “Administratively Scoped” membership report to the Internet;</li><li id="ul0045-0008" num="0465">8. IPMS <b>120</b> receives IGMP VI Membership Report; the 239.216.63.240 multicast will be used for multicast control messages;</li><li id="ul0045-0009" num="0466">9. Client A sends an IOMP V2 Membership Report (Destination IP Address=239.216.63.248, Group Address239.216.63.248);</li><li id="ul0045-0010" num="0467">10. Access Switch/Router #<b>1</b> forwards IGMP V2 Membership Report to backbone (assuming it has no other interfaces in Group Address=239.216.63.248);</li><li id="ul0045-0011" num="0468">11. Gateway Router does not forward “Administratively Scoped” membership report to the Internet;</li><li id="ul0045-0012" num="0469">12. IPMS <b>120</b> receives IGNIP V2 Membership Report and transmits 239.216.63.248 multicast out NIC#<b>2</b> onto Filtered Stream—the data payload of the 239.216.63.248 multicast includes the IPMS <b>120</b> P Address, and a test pattern;</li><li id="ul0045-0013" num="0470">13. Access Switch/Router #<b>1</b> forwards 239.216.63.248 multicast to Client A only;</li><li id="ul0045-0014" num="0471">14. Gateway Router ignores 239.216.63.248 multicast since it is an Administratively scoped address;</li><li id="ul0045-0015" num="0472">15. Client A receives IPMS <b>120</b> IP Address and test pattern and then sends an IGMP Leave Group (Destination IP Address=224.0.0.2, Group Address=239.216.63.248);</li><li id="ul0045-0016" num="0473">16. Access Switch/Router #<b>1</b> verifies it has no other interfaces in Group Address=239.216.63.248 (using IGMP Query), forwards IGMP Leave Group to backbone, and immediately stops forwarding the 239.216.63.248 multicast to Client A;</li><li id="ul0045-0017" num="0474">17. Gateway Router ignores IGMP Leave Group command since it is on an administratively scoped address;</li><li id="ul0045-0018" num="0475">18. IPMS <b>120</b> receives IGMP Leave Group, verifies it has no other Clients in Group Address=239.216.63.248 (using IGMP Query), and immediately stops transmission of the 239.216.63.248 multicast;</li><li id="ul0045-0019" num="0476">19. Client A sends a UDP packet (Destination IP Address=28.0.0.255, Port=255) to the IPMS <b>120</b>;</li><li id="ul0045-0020" num="0477">20. Access Switch/Router #<b>1</b> forwards UDP packet to backbone;</li><li id="ul0045-0021" num="0478">21. Gateway Router does not forward packet to Internet since it is destined for a local administratively scoped address;</li><li id="ul0045-0022" num="0479">22. IPMS <b>120</b> receives UDP packet and sends UDP packet (Destination IP Address=128.0.0.1, Port=255);</li><li id="ul0045-0023" num="0480">23. Gateway Router does not forward packet to Internet since it is destined for a local administratively scoped address;</li><li id="ul0045-0024" num="0481">24. Access Switch/Router #<b>1</b> forwards UDP packet to Client A;</li><li id="ul0045-0025" num="0482">25. Client A receives UDP packet.</li></ul></li></ul>

0483The following operations occur when Client A joins Multicast Group 239.216.0.8: <ul id="ul0046" list-style="none"><li id="ul0046-0001" num="0000"><ul id="ul0047" list-style="none"><li id="ul0047-0001" num="0484">26. Client A sends an IGMP V2 Membership Report (Destination IP Address=239.216.0.8, Group Address=239.216.0.8);</li><li id="ul0047-0002" num="0485">27. Access Switch/Router #<b>1</b> forwards IGMP V2 Membership Report to the LAN backbone(assuming it has no other interfaces in Group Address=239.216.63.248).</li><li id="ul0047-0003" num="0486">28. Gateway Router ignores IGMP V2 Membership Report since it is an administratively scoped address;</li><li id="ul0047-0004" num="0487">29. IPMS <b>120</b> receives IGMP V2 Membership Report and transmits 239.216.0.8 multicast out NIC2 onto Filtered Stream;</li><li id="ul0047-0005" num="0488">30. Access Switch/Router #<b>1</b> forwards 239.216.0.8 multicast to Client A only;</li><li id="ul0047-0006" num="0489">31. Gateway Router ignores 239.216.0.8 multicast (“Administratively Scoped” address);</li><li id="ul0047-0007" num="0490">32. Client A receives 239.216.0.8 multicast.</li></ul></li></ul>

0491The following query operations ensure that the IPMS <b>120</b> does not transmit a Multicast Group that a client has silent left: <ul id="ul0048" list-style="none"><li id="ul0048-0001" num="0000"><ul id="ul0049" list-style="none"><li id="ul0049-0001" num="0492">33. Access Switch/Router #<b>1</b> sends IGMP Group-Specific Query (Destination IP Address=239.216.0.8, Group Address=239.216.0.8) to Client A</li><li id="ul0049-0002" num="0493">34. If Access Switch/Router #<b>1</b> receives an IGMP V2 Membership Report (Destination IP Address=239.216.0.8, Group Address=239.216.0.8), do nothing;</li><li id="ul0049-0003" num="0494">35. If there is no Membership Report then Access Switch/Router #<b>1</b> sends IGMP Leave Group(Destination IP Address=224.0.0.2, Group Address=2239.216.0.8) to backbone and immediately stops forwarding the 239.216.0.8) multicast to all Clients (including Client A): operations then proceed at Step 40;</li><li id="ul0049-0004" num="0495">36. IPMS <b>120</b> sends UDP packet(Destination IP Address=239.216.63.240, Port=255);</li><li id="ul0049-0005" num="0496">37. Client A receives UDP packet and responds with UDP packet (Destination IP Address=239.216.63.240. Port=255) (other Clients will receive and ignore this packet);</li><li id="ul0049-0006" num="0497">38. If IPMS <b>120</b> receives no UDP response, then it immediately stops forwarding the 239.216.0.8 to all Clients (group left due to no response).</li></ul></li></ul>

0498The following operations occur when Client A purposely leaves the Group; <ul id="ul0050" list-style="none"><li id="ul0050-0001" num="0000"><ul id="ul0051" list-style="none"><li id="ul0051-0001" num="0499">39. Client A sends an IGMP Leave Group (Destination IP Address=224.0.0.2, Group Address=239.216.0.8);</li><li id="ul0051-0002" num="0500">40. Access Switch/Router #<b>1</b> receives IGMP Leave Group, verifies it has no other interfaces in Group Address=239.216.0.8 (using IGMP Query), forwards IOMP Leave Group command to the LAN backbone, and immediately stops forwarding the 239.216.0.8 multicast to Client A;</li><li id="ul0051-0003" num="0501">41. Gateway Router ignores the IGMP Leave Group command since it is directed on an administratively scoped address;</li><li id="ul0051-0004" num="0502">42. IPMS <b>120</b> receives the IGMP Leave Group command, verifies it has no other Clients in Group Address=239.216.0.8 (using IGMP Query), and immediately stops transmission of 239.216.0.8 multicast.</li></ul></li></ul>

0503The following handshake operations occur during final termination: <ul id="ul0052" list-style="none"><li id="ul0052-0001" num="0000"><ul id="ul0053" list-style="none"><li id="ul0053-0001" num="0504">43. Client A sends a UDP packet (Destination IP Address=128.0.0.255, Port=255) to the IPMS <b>120</b></li><li id="ul0053-0002" num="0505">44. Access Switch/Router #<b>1</b> forwards UDP packet to backbone;</li><li id="ul0053-0003" num="0506">45. Gateway Router ignores the message since it is routed locally;</li><li id="ul0053-0004" num="0507">46. IPMS <b>120</b> receives the IDP packet and sends a UDP packet (Destination IP Address=128.0.0.1, Port=255) to Client A;</li><li id="ul0053-0005" num="0508">47. Gateway Router ignores message routed locally;</li><li id="ul0053-0006" num="0509">48. Access Switch/Router #<b>1</b> forwards the UDP packet to Client A;</li><li id="ul0053-0007" num="0510">49. Client A receives UDP packet.</li></ul></li></ul>

ISP Model

5

—ISP with Multiple LAN Segments/Multicast Streams Segmented—Scenario

2

0511In the example of <figref idref="DRAWINGS">FIG. 25</figref>. Client A and the IPMS <b>120</b> first join Multicast Group 239.216.63.240 to establish a mechanism for sending multicast control messages to each other. Next, Client A joins, receives, and leaves Multicast Group 239.216.63.248 to receive a brief multicast from the IPMS <b>120</b>. After that, Client A joins and receives Multicast Group 239.216.0.8. Then, network elements query the group so that multicast traffic can be pruned in the event group members silently leave the group. Finally, Client A leaves Multicast Group 239216.0.8.

0512The IPMS <b>120</b> filters the multicast streams sent to each segment so that only multicast addresses which are currently “joined” will be sent to the LAN Switch per segment. This implies that the LAN switch does not have to support IGMP V2, although this provision is not mandatory.

0513In the scenario of <figref idref="DRAWINGS">FIG. 25</figref>, the following assumptions have been made: <ul id="ul0054" list-style="none"><li id="ul0054-0001" num="0000"><ul id="ul0055" list-style="none"><li id="ul0055-0001" num="0514">IPMS <b>120</b> IP Address=128.0.0.255, Client A IP Address=128.0.0.1;</li><li id="ul0055-0002" num="0515">All IP Multicast Addresses transmitted by the IPMS <b>120</b> are “Administratively Scoped” addresses in the range 239.216.0.0 through 239.219.255.255 (addresses 239.216.0.8, 239.216.63.240, 239.216.63.248 used in this example);</li><li id="ul0055-0003" num="0516">Access Switch/Routers and IPMS <b>120</b> support IGMP V2;</li><li id="ul0055-0004" num="0517">LAN Switch may or may not support IGMP V2;</li><li id="ul0055-0005" num="0518">LAN Switch configuration: <ul id="ul0056" list-style="none"><li id="ul0056-0001" num="0519">Virtual LAN#<b>1</b>=LAN Segment #<b>1</b>, Backbone, IPMS <b>120</b> Control, Filtered Stream#<b>1</b>;</li><li id="ul0056-0002" num="0520">Virtual LAN#<b>2</b>=LAN Segment #<b>2</b>. Backbone, IPMS <b>120</b> Control, Filtered Stream#<b>2</b></li></ul></li><li id="ul0055-0006" num="0521">Remote Router does not forward IGMP messages with “Administratively Scoped” Multicast addresses (this includes messages with Dest IP=239.*.*.*, and IGMP messages with Dest IP=224.0.0.1/224.0.0.2 that specify a Group Address=239.*.*.*);</li><li id="ul0055-0007" num="0522">The IPMS <b>120</b> and the Clients use Multicast Address=239.216.63.240 to pass proprietary UDP packets using UDP Port=255.</li></ul></li></ul>

0523The following operations occur during initial handshake in the system: <ul id="ul0057" list-style="none"><li id="ul0057-0001" num="0000"><ul id="ul0058" list-style="none"><li id="ul0058-0001" num="0524">1. IPMS <b>120</b> sends an IOMP V2 Membership Report (Destination IP Address=239.216.63.240, Group Address=239.216.63.240);</li><li id="ul0058-0002" num="0525">2. LAN Switch receives IOMP V2 Membership Report, forwards the message, and adds the IPMS <b>120</b> to the Groups the 239.216.63.240 multicast being used for multicast control messages;</li><li id="ul0058-0003" num="0526">3. Gateway Router does not forward the administratively scoped membership report to the Internet;</li><li id="ul0058-0004" num="0527">4. Client A sends an IGMP V2 Membership Report (Destination IP Address=239.216.63.240, Group Address=239.216.63.240);</li><li id="ul0058-0005" num="0528">5. Access Switch/Router #<b>1</b> forwards IGMP V2 Membership Report to LAN Segment #<b>1</b> (assuming it has no other interfaces in Group Address=239.216.63.240);</li><li id="ul0058-0006" num="0529">6. LAN Switch receives IGMP V2 Membership Report, forwards the message, and adds Client A to the Group;</li><li id="ul0058-0007" num="0530">7. Gateway Router does not forward the administratively scoped membership report to the Internet;</li><li id="ul0058-0008" num="0531">8. IPMS <b>120</b> receives IGMP V2 Membership Report, the 239.216.63.240 multicast being used for multicast control messages;</li><li id="ul0058-0009" num="0532">9. Client A sends an IGMP V2 Membership Report (Destination IP Address=239.216.63.248, Group Address=239.216.63.248);</li><li id="ul0058-0010" num="0533">10. Access Switch/Router #<b>1</b> forwards IGMP V2 Membership Report to LAN Segment #<b>1</b> (assuming it has no other interfaces in Group Address=239.216.63.248);</li><li id="ul0058-0011" num="0534">11. LAN Switch receives IGMP V2 Membership Report and forwards the message;</li><li id="ul0058-0012" num="0535">12. Gateway Router does not forward the administratively scoped membership report to the Internet;</li><li id="ul0058-0013" num="0536">13. IPMS <b>120</b> receives IGMP V2 Membership Report and transmits 239.216.63.248 multicast out NIC#<b>2</b> and NIC#<b>3</b> onto Filtered Streams <b>1</b> and <b>2</b>—the data payload of the 239.216.63.248 multicast includes the IPMS <b>120</b> IP Address, and a test pattern;</li><li id="ul0058-0014" num="0537">14. If LAN Switch is IGMP V2 enabled, it will forward 239.216.63.248 multicast to LAN Segment #<b>1</b> only. If it isn't, then the 239.216.63.248 multicast will be forwarded to both LAN Segment #<b>1</b> and LAN Segment #<b>2</b>;</li><li id="ul0058-0015" num="0538">15. Access Switch/Router #<b>1</b> forwards 239.216.63.248 multicast to Client A only;</li><li id="ul0058-0016" num="0539">16. Client A receives IPMS <b>120</b> IP Address and test pattern and then sends an IGMP Leave Group (Destination IP Address=224.0.0.2 Group Address=239.216.63.248);</li><li id="ul0058-0017" num="0540">17. Access Switch/Router #<b>1</b> receives IGMP Leave Group, verifies it has no other interfaces in Group Address239.216.63.248 (using IGMP Query), forwards IGMP Leave Group to LAN Segment #<b>1</b>, and immediately stops forwarding the 239.216.63.248 multicast to Client A;</li><li id="ul0058-0018" num="0541">18. LAN Switch receives the IGMP Leave Group and forwards the message. If it is IGMP V2 enabled, it will verify it has no other LAN Segment #<b>1</b> Clients in Group Address=239.216.63.248 (using IGMP Query), and immediately stop transmission of 239.216.63.248 multicast to LAN Segment #<b>1</b>;</li><li id="ul0058-0019" num="0542">19. Gateway Router ignores IOMP Leave Group since it is on an administratively scoped address;</li><li id="ul0058-0020" num="0543">20. IPMS <b>120</b> receives IGMP Leave Group, verifies it has no other Clients in Group Address=239.216.63.248, and immediately stops transmission of the 239.216.63.248 multicast;</li><li id="ul0058-0021" num="0544">32. IPMS <b>120</b> receives IGMP V2 Membership Report and transmits 239.216.0.8 multicast out NIC#<b>2</b> onto Filtered Stream #<b>1</b>;</li><li id="ul0058-0022" num="0545">33. LAN Switch forwards 239.216.0.8 multicast to LAN Segment #<b>1</b> only;</li><li id="ul0058-0023" num="0546">34. Access Switch/Router #<b>1</b> forwards 239.216.0.8 multicast to Client A only;</li><li id="ul0058-0024" num="0547">35. Client A receives 239.216.0.8 multicast.</li></ul></li></ul>

0548The following query operations occur to ensure that the IPMS does not unnecessarily provide a Group multicast transmission when there are no subscribers: <ul id="ul0059" list-style="none"><li id="ul0059-0001" num="0000"><ul id="ul0060" list-style="none"><li id="ul0060-0001" num="0549">36. Access Switch/Router #<b>1</b> sends IGMP Group-Specific Query (Destination IP Address=239.216.0.8, Group Address=239.216.0.8) to Client A;</li><li id="ul0060-0002" num="0550">37. If Access Switch/Router #<b>1</b> receives an IGMP V2 Membership Report (Destination IP Address=239.216.0.8, Group Address 239.216.0.8), do nothing;</li><li id="ul0060-0003" num="0551">38. If there is no Membership Report, then Access Switch/Router #<b>1</b> sends IGMP Leave Group (Destination IP Address=224.0.0.2, Group Address=239.216.0.8) to LAN Segment #<b>1</b> and immediately stops forwarding the 239.216.0.8 multicast to all clients (including Client A), operations then proceed from Step 53;</li><li id="ul0060-0004" num="0552">39. IPMS <b>120</b> sends UDP packet(Destination IP Address=239.216.63.240, Port=255) from NIC #<b>1</b>;</li><li id="ul0060-0005" num="0553">40. If LAN Switch is IGMP V2 enabled, it will forward the packet to all interfaces currently monitoring the 239.216.63.240 stream. If it is not IGMP V2 enabled, the packet will be forwarded to all LAN interfaces.</li><li id="ul0060-0006" num="0554">41. Gateway Router will ignore the administratively scoped packet;</li><li id="ul0060-0007" num="0555">42. Access Switch/Routers will forward the packet to all Clients listening to the 239.216.63.240 stream;</li><li id="ul0060-0008" num="0556">43. Client A will respond with a UDP packet (Destination IP Address=239.216.63.240, Port=255);</li><li id="ul0060-0009" num="0557">44. The packet will be forwarded by Access/Switch Router #<b>1</b> to LAN Segment #<b>1</b>;</li><li id="ul0060-0010" num="0558">45. The LAN Switch will forward the packet to the IPMS <b>120</b> NIC #<b>1</b>;</li><li id="ul0060-0011" num="0559">46. Gateway Router will ignore the administratively scoped packet;</li><li id="ul0060-0012" num="0560">47. If IPMS <b>120</b> receives no UDP response, then it immediately stops forwarding the 239.216.0.8 to all Clients (group is left due to no response); Independently, if the LAN Switch is IGMP V2 enabled, the following operations occur:</li><li id="ul0060-0013" num="0561">48. LAN Switch sends IGMP Group-Specific Query (Destination IP Address=239.216.0.8, Group Address=239.216.0.8) to LAN Segment #<b>1</b>;</li><li id="ul0060-0014" num="0562">49. If LAN Switch receives IGMP V2 Membership Report (Destination IP Address=239.216.0.8, Group Address=239.216.0.8), do nothing</li><li id="ul0060-0015" num="0563">50. If there is no Membership Report then LAN Switch sends IGMP Leave Group (Destination IP Address=224.0.0.2, Group Address=239.216.0.8) to IPMS <b>120</b> and immediately stops transmission of 239.216.0.8 multicast to LAN Segment #<b>1</b> (group is left due to no response);</li></ul></li></ul>

0564The following operations occur when Client A leaves Group Address 239.216.0.8: <ul id="ul0061" list-style="none"><li id="ul0061-0001" num="0000"><ul id="ul0062" list-style="none"><li id="ul0062-0001" num="0565">51. Client A sends an IGMP Leave Group(Destination IP Address=224.0.0.2, Group Address=239.216.0.8):</li><li id="ul0062-0002" num="0566">52. Access Switch/Router #<b>1</b> receives IGMP Leave Group, verifies it has no other interfaces in Group Address=239.216.0.8 (using IGMP Query), forwards IGMP Leave Group to LAN Segment #<b>1</b>, and immediately stops forwarding the 239.216.0.8 multicast to Client A;</li><li id="ul0062-0003" num="0567">53. LAN Switch receives IGMP Leave Group and forwards the message. If it is IGMP V2 enabled it verifies it has no other LAN Segment #<b>1</b> Clients in Group address 239.216.0.8 (using IGMP Query), and immediately stops transmission of 239.216.0.8 multicast to LAN Segment 1:</li><li id="ul0062-0004" num="0568">54. Gateway Router ignores IGMP Leave Group since it is in an administratively scoped address packet;</li><li id="ul0062-0005" num="0569">55. IPMS <b>120</b> receives IGMP Leave Group, verifies it has no other Clients in Group Address=239.216.0.8, and immediately stops transmission of 239.216.0.8 multicast.</li></ul></li></ul>

0570The following termination handshake operations occur upon termination of the multicast subscription: <ul id="ul0063" list-style="none"><li id="ul0063-0001" num="0000"><ul id="ul0064" list-style="none"><li id="ul0064-0001" num="0571">56. Client A sends a UDP packet (Destination IP Address=128.0.0.255, Port=255) to the IPMS <b>120</b>:</li><li id="ul0064-0002" num="0572">57. Access Switch/Router #<b>1</b> forwards UDP packet to LAN Segment #<b>1</b>:</li><li id="ul0064-0003" num="0573">58. LAN Switch forwards packet to IPMS <b>120</b> NIC #<b>1</b>;</li><li id="ul0064-0004" num="0574">59. IPMS <b>120</b> receives UDP packet and sends a UDP packet (Destination IP Address=28.0.0.1, Port255) to Client A;</li><li id="ul0064-0005" num="0575">60. LAN Switch forwards packet to LAN Segment #<b>1</b>;</li><li id="ul0064-0006" num="0576">61. Gateway Router will ignore the administratively scoped packet;</li><li id="ul0064-0007" num="0577">62. Access Switch/Router #<b>1</b> forwards packet to Clients A;</li><li id="ul0064-0008" num="0578">63. Client A receives UDP packet.</li></ul></li></ul>

ISP Model

6

—Large ISP with Affiliated ISP—Scenario

2

0579In the example of <figref idref="DRAWINGS">FIG. 26</figref>, Remote Client H and the IPMS <b>120</b> first join Multicast Group 239.216.63.240 to establish a mechanism for sending multicast control messages to each other. Next, Remote Client H joins receives, and leaves Multicast Address 239.216.63.248 to receive a brief multicast from the IPMS <b>120</b>. After that, Client H joins and receives Multicast Group 239.216.0.8. Then, network elements query the group so that multicast traffic can be pruned in the event group members silently leave the group. Finally, Client H leaves Multicast Group 239.216.0.8.

0580The IPMS <b>120</b> filters the multicast streams sent to each segment so that only multicast addresses that are currently “joined” will be sent to the LAN Switch per segment. This implies that the LAN switch does not have to support IGMP V2, although this is not necessary. The LAN Switch may filter the multicast stream sent to each segment so that only multicast addresses which are currently “joined” by plans on a segment will be placed on the segment. For the Remote ISP the multicast streams preferably to not use bandwidth on the Router link to the ISP (to avoid impacting normal Internet traffic). Rather, a bridged connection is used to send the streams to the Remote ISP. The only segments that receive the multicast streams are LAN Segment #<b>1</b> and the bridged connection to the Remote ISP that is considered to be LAN Segment #<b>2</b>.

0581In this scenario, the following assumptions have been made: <ul id="ul0065" list-style="none"><li id="ul0065-0001" num="0000"><ul id="ul0066" list-style="none"><li id="ul0066-0001" num="0582">IPMS <b>120</b> IP Address 28.0.0.255, Client A IP Address=128.0.0.1;</li><li id="ul0066-0002" num="0583">All IP Multicast Addresses transmitted by the IPMS <b>120</b> are “Administratively Scoped” addresses in the range 239.216.0.0 through 239.219.255.255 (addresses 239.216.0.8, 239.216.63.240, 239.216.63.248 used in this example);</li><li id="ul0066-0003" num="0584">Access Switch/Router and IPMS <b>120</b> support IGMP V2;</li><li id="ul0066-0004" num="0585">LAN Switch may or may not support IGMP V2;</li><li id="ul0066-0005" num="0586">LAN Switch configuration: <ul id="ul0067" list-style="none"><li id="ul0067-0001" num="0587">Virtual LAN#<b>1</b> LAN Segment #<b>1</b> Backbone, IPMS <b>120</b> Control, Filtered Stream#<b>1</b>;</li><li id="ul0067-0002" num="0588">Virtual LAN#<b>2</b>=LAN Segment #<b>2</b>, IPMS <b>120</b> Control, Filtered Stream#<b>2</b>;</li><li id="ul0067-0003" num="0589">Virtual LAN#<b>3</b> LAN Segment #<b>3</b>,Backbone;</li></ul></li><li id="ul0066-0006" num="0590">LAN Bridge configuration: Only forward 239.216.0.0-239.219.255.255; 224.0.0.1, 224.0.0.2;</li><li id="ul0066-0007" num="0591">Remote Router does not forward IGMP messages with “Administratively Scoped” Multicast addresses (this includes messages with Dest IP239.*.*.*, and IGMP messages with Dest IP=224.0.0.1/224.0.0.2 that specify a Group Address=239.*.*.*);</li><li id="ul0066-0008" num="0592">The IPMS <b>120</b> and the Clients use Multicast Address=239.216.63.240 to pass UDP packets using UDP Port=255.</li></ul></li></ul>

0593In this scenario, the followings initial handshake operations take place: <ul id="ul0068" list-style="none"><li id="ul0068-0001" num="0000"><ul id="ul0069" list-style="none"><li id="ul0069-0001" num="0594">1. IPMS <b>120</b> sends an IGMP V2 Membership Report (Destination IP Address=39.216.63.240. Group Address=239.216.63.240);</li><li id="ul0069-0002" num="0595">2. LAN Switch receives IGMP V2 Membership Report, forwards the messages and adds the IPMS <b>120</b> to the Group, the 239.216.63.240 multicast being used for multicast control messages;</li><li id="ul0069-0003" num="0596">3. Gateway Router does not forward the administratively scoped membership report to the Internet;</li><li id="ul0069-0004" num="0597">4. Client H sends an IGMP V2 Membership Report (Destination IP Address=239.216.63.240, Group Address=239.216.63.240);</li><li id="ul0069-0005" num="0598">5. Access Switch/Router #<b>1</b> forwards IGMP V2 Membership Report to LAN Segment#<b>1</b> (assuming it has no other interfaces in Group Address=239.216.63.240);</li><li id="ul0069-0006" num="0599">6. LAN Switch receives IGMP V2 Membership Report, forwards the message, and adds Client H to the Group;</li><li id="ul0069-0007" num="0600">7. Gateway Router does not forward the administratively scoped membership report to the Internet;</li><li id="ul0069-0008" num="0601">8. IPMS <b>120</b> receives IGMP V2 Membership Report the 239.216.63.240 multicast being used for multicast control messages;</li><li id="ul0069-0009" num="0602">9. Client H sends an IGMP V2 Membership Report (Destination IP Address=239.216.63.248, Group Address=239.216.63.248);</li><li id="ul0069-0010" num="0603">10. Access Switch/Router #<b>2</b> forwards IGMP V2 Membership Report to Remote Backbone (assuming it has no other interfaces in Group Address=239.216.63.248);</li><li id="ul0069-0011" num="0604">11. LAN Bridge forwards IGMP V2 Membership Report;</li><li id="ul0069-0012" num="0605">12. Remote Router ignores the administratively scoped IGMP V2 Membership Report;</li><li id="ul0069-0013" num="0606">13. LAN Switch receives IGMP V2 Membership Report, forwards the message, and enables transmission of 239.216.63.248 multicast to LAN Segment #<b>2</b>;</li><li id="ul0069-0014" num="0607">14. IPMS <b>120</b> receives IGMP V2 Membership Report and transmits 239.216.63;248 multicast out NIC#<b>2</b> and NIC#<b>3</b> onto Filtered Streams <b>1</b> and <b>2</b>—the data payload of the 239.216.63.248 multicast includes the IRMS <b>120</b> IP Address, and a test pattern;</li><li id="ul0069-0015" num="0608">15. If LAN Switch is IGMP V2 enabled, it will forward 239.216.63.248 multicast to LAN Segment #<b>2</b> only. If it is not so enabled, then the 239.216.63.248 multicast data will be forwarded to both LAN Segment #<b>1</b> and LAN Segment #<b>2</b>;</li><li id="ul0069-0016" num="0609">16. LAN Bridge forwards the 239.216.63.248 multicast data;</li><li id="ul0069-0017" num="0610">17. Access Switch/Router #<b>2</b> forwards 239.216.63.248 multicast to Client H only;</li><li id="ul0069-0018" num="0611">18. Remote Router ignores 239.216.63.248 multicast data;</li><li id="ul0069-0019" num="0612">19. Client H receives the IPMS <b>120</b> IP Address and test pattern and then sends an IGMP Leave Group (Destination IP Address=224.0.0.2. Group address=239.216.63.248);</li><li id="ul0069-0020" num="0613">20. Access Switch/Router 2 receives IGMP Leave Group, verifies it has no other interfaces in Group Address=239.216.248 (using IGMP Query), forwards IGMP Leave Group to LAN Bridge, and immediately stops forwarding the 239.216.63.248 multicast to Client H;</li><li id="ul0069-0021" num="0614">21. LAN Bridge forwards the IGMP Leave Group command;</li><li id="ul0069-0022" num="0615">22. Remote Router ignores the administratively scoped IGMP Leave Group command;</li><li id="ul0069-0023" num="0616">23. LAN Switch receives IGMP Leave Group and forwards the message. If it is IGMP V2 enabled, it will verify it has no other LAN Segment #<b>2</b> Clients in Group address=239.216.63.248 (using IGMP Query), and will immediately stop transmission of the 239.216.63.248 multicast to LAN Segment #<b>2</b>;</li><li id="ul0069-0024" num="0617">24. IPMS <b>120</b> receives the IGMP Leave Group command, verifies it has no other Clients in Group Address=239.216.63.248, and immediately stops transmission of the 239.216.63.248 multicast data;</li><li id="ul0069-0025" num="0618">25. Client H sends a UDP packet (Destination IP Adress=128.0.0.255, Port=255) to the IPMS <b>120</b>;</li><li id="ul0069-0026" num="0619">26. Access Switch/Router #<b>2</b> forwards a UDP packet to the backbone of the remote ISP;</li><li id="ul0069-0027" num="0620">27. LAN Bridge forwards the IGMP V2 Membership Report;</li><li id="ul0069-0028" num="0621">28. Remote Router ignores the administratively scoped IGMP V2 Membership Report;</li><li id="ul0069-0029" num="0622">29. LAN Switch forwards the UDP packet to the IPMS <b>120</b> control stream (NIC #<b>1</b>);</li><li id="ul0069-0030" num="0623">30. IPMS <b>120</b> receives UDP packet and sends UDP packet response (Destination IP Address=128.0.0.1, Port=255) from NIC #<b>1</b>;</li><li id="ul0069-0031" num="0624">31. LAN Switch forwards the UDP packet to the LAN Segment #<b>2</b> since the packet is addressed to Client H;</li><li id="ul0069-0032" num="0625">32. Access Switch/Router #<b>2</b> forwards UDP packet to Client H;</li><li id="ul0069-0033" num="0626">33. Client H receives UDP packet.</li></ul></li></ul>

0627The following operations occur when Client H joins Multicast Group 239.216.0.8; <ul id="ul0070" list-style="none"><li id="ul0070-0001" num="0000"><ul id="ul0071" list-style="none"><li id="ul0071-0001" num="0628">34. Client H sends an IGMP V2 Membership Report (Destination IP Address=239.216.0.8, Group Address=239.216.08);</li><li id="ul0071-0002" num="0629">35. Access Switch/Router #<b>2</b> forwards IGMP V2 Membership Report to Remote Backbone (assuming it has no other interfaces in Group Address=239.216.0.8);</li><li id="ul0071-0003" num="0630">36. LAN Bridge forwards IGMP V2 Membership Report;</li><li id="ul0071-0004" num="0631">37. Remote Router ignores the administratively scoped IGMP V2 Membership Report;</li><li id="ul0071-0005" num="0632">38. LAN Switch receives IGMP V2 Membership Report and forwards the message. If it is IGMP V2 enabled, it will enable transmission of 239.216.0.8 multicast to LAN segment #<b>2</b>;</li><li id="ul0071-0006" num="0633">39. IPMS <b>120</b> receives the IGMP V2 Membership Report and transmits the 239.216.0.8 multicast through NIC #<b>3</b> onto Filtered Stream #<b>2</b>;</li><li id="ul0071-0007" num="0634">40. LAN Switch forwards 239.216.0.8 multicast to LAN Segment #<b>2</b> only;</li><li id="ul0071-0008" num="0635">41. LAN Bridge forwards the 239.216.0.8 multicast data;</li><li id="ul0071-0009" num="0636">42. Access Switch/Router #<b>2</b> forwards 239.216.0.8 multicast data to Client H only;</li><li id="ul0071-0010" num="0637">43. Remote Router ignores 239.216.0.8 multicast data;</li><li id="ul0071-0011" num="0638">44. Client H receives 239.216.0.8 multicast.</li></ul></li></ul>

0639The following query operations also take place to ensure that unnecessary multicast data is not transmitted over any LAN: <ul id="ul0072" list-style="none"><li id="ul0072-0001" num="0000"><ul id="ul0073" list-style="none"><li id="ul0073-0001" num="0640">45. Access Switch/Router #<b>2</b> sends IGMP Group-Specific Query (Destination IP Address=239.216.0.8, Group Address=239.216.0.8) to Client H;</li><li id="ul0073-0002" num="0641">46. If Access Switch/Router #<b>2</b> receives an IGMP V2 Membership Report (Destination IP Address=39.216.0.8, Group Address=239.216.0.8), do nothing:</li><li id="ul0073-0003" num="0642">47. If there is no Membership Report, then Access Switch/Router #<b>2</b> sends an IOMP Leave Group command (Destination IP Address=224.0.0.2, Group Address=39.216.0.8) to the backbone of the remote ISP and immediately stops forwarding the 239.216.0.8 multicast data to Client H; operations then proceed from Step 63 below;</li><li id="ul0073-0004" num="0643">48. IPMS <b>120</b> sends UDP packet (Destination IP Address=239.216.63.240, Port=255) from NIC #<b>1</b>;</li><li id="ul0073-0005" num="0644">49. If LAN Switch is IGMP V2 enabled, it will forward the packet to all interfaces currently monitoring the 239.216.63.240 stream if it is not IGMP V2 enabled, the packet will be forwarded to all LAN interfaces</li><li id="ul0073-0006" num="0645">50. Access Switch/Routers forwards the packet to all Clients listening to the 239.216.63.240 stream;</li><li id="ul0073-0007" num="0646">51. Client H responds with a UDP packet (Destination IP Address=239.216.63.240, Port=255);</li><li id="ul0073-0008" num="0647">52. Access/Switch Router #<b>2</b> forwards the packet to the backbone of the remote ISP;</li><li id="ul0073-0009" num="0648">53. LAN Bridge forwards packet;</li><li id="ul0073-0010" num="0649">54. Remote Router ignores packet;</li><li id="ul0073-0011" num="0650">55. The LAN Switch forwards packet to the IPMS <b>120</b> NIC #<b>1</b>;</li><li id="ul0073-0012" num="0651">56. If IPMS <b>120</b> does not receive a UDP response, then it immediately stops forwarding the 239.216.0.8 to all Clients (group is left due to no response). If the LAN Switch is IGMP V2 enabled, the following operations will take place;</li><li id="ul0073-0013" num="0652">57. LAN Switch sends IGMP Group-Specific Query (Destination IP Address=239.216.0.8, Group Address=239.216.0.8) to LAN Segment #<b>2</b>;</li><li id="ul0073-0014" num="0653">58. LAN Bridge forwards IGMP Group-Specific Query;</li><li id="ul0073-0015" num="0654">59. If LAN Switch receives an IGMP V2 Membership Report (Destination IP Address=239.216.0.8, Group Address=239.216.0.8), then do nothing;</li><li id="ul0073-0016" num="0655">60. If there is no Membership Report, then IAN Switch immediately stops transmission of 239.216.0.8 multicast to LAN Segment #<b>2</b> (group is left due to no response).</li></ul></li></ul>

0656The following operations take place when Client H leaves Multicast Group 239.216.0.8: <ul id="ul0074" list-style="none"><li id="ul0074-0001" num="0000"><ul id="ul0075" list-style="none"><li id="ul0075-0001" num="0657">61. Client H sends an IGMP Leave Group command (Destination IP Address=224.0.0.2, Group Address=239.216.0.8);</li><li id="ul0075-0002" num="0658">62. Access Switch/Router #<b>2</b> receives the IGMP Leave Group command. verifies it has no other interfaces in Group Address=239.216.0.8 (using IGMP Query), forwards the IGMP Leave Group to the backbone of the remote ISP, and immediately stops forwarding the 239.216.0.8 multicast data to Client H;</li><li id="ul0075-0003" num="0659">63. LAN Bridge forwards IGMP Leave Group command;</li><li id="ul0075-0004" num="0660">64. Remote Router ignores the administratively scoped IGMP Leave Group command;</li><li id="ul0075-0005" num="0661">65. LAN Switch receives the IGMP Leave Group command and forwards the message: if it is IGMP V2 enabled, it verifies it has no other LAN Segment #<b>2</b> Clients in Group Address=239.216.0.8 (using IGMP Query), and immediately stops transmission of 239.216.0.8 multicast to LAN Segment #<b>2</b>;</li><li id="ul0075-0006" num="0662">66. IPMS <b>120</b> receives the IGMP Leave Group command, verifies it has no other Clients in Group Address=239.216.0.8, and immediately stops transmission of the 39.216.0.8 multicast.</li></ul></li></ul>

0663The following termination handshake operations also take place: <ul id="ul0076" list-style="none"><li id="ul0076-0001" num="0000"><ul id="ul0077" list-style="none"><li id="ul0077-0001" num="0664">67. Client H sends a UDP packet (Destination IP Address=128.0.0.255. Port=255) to the IPMS <b>120</b>;</li><li id="ul0077-0002" num="0665">68. Access Switch/Router #<b>2</b> forwards the LTDP packet to the backbone of the remote ISP;</li><li id="ul0077-0003" num="0666">69. LAN Bridge forwards the packet;</li><li id="ul0077-0004" num="0667">70. Remote Router ignores the packet;</li><li id="ul0077-0005" num="0668">71. LAN Switch forwards the packet to IPMS <b>120</b> NIC #<b>1</b>;</li><li id="ul0077-0006" num="0669">72. IPMS <b>120</b> receives the UDP packet and sends a UDP packet (Destination IP Address=128.0.0.1, Port=255) to Client H;</li><li id="ul0077-0007" num="0670">73. LAN Switch forwards the packet to LAN Segment #<b>2</b> only;</li><li id="ul0077-0008" num="0671">74. LAN Bridge forwards the packet;</li><li id="ul0077-0009" num="0672">75. Access Switch/Router #<b>2</b> forwards the packet to Client H only; and</li><li id="ul0077-0010" num="0673">76. Client H receives the UDP packet.</li></ul></li></ul>

0674If remote clients join “normal” multicast groups through the remote router, the 224.0.0.1 and 224.0.0.2 IGMP V2 messages will be bridged to the LAN Switch. The LAN Switch will forward the IGMP messages through LAN segment #<b>2</b> to the IPMS <b>120</b>. The IPMS <b>120</b> will ignore the messages issued for a non-existent stream.

0675<figref idref="DRAWINGS">FIG. 27</figref> shows a basic ISP configuration. The Internet is connected to an internal 10 BaseT LAN. This internal LAN has a local file server that is used for locally served Web pages. Also on this LAN is connected a remote access server (modem pool) which is used to Connect the ISP customers via the LEC (local exchange carrier—the local phone company) to the Internet.

0676<figref idref="DRAWINGS">FIG. 28</figref> shows how this ISPO grows to serve more customers. A layer <b>3</b> switch is added to the Internal ISP LAN. This LAN is usually interconnected by 100 BaseT added to the internal ISP LAN. This LAN is usually interconnected by 100 BaseT or FDDI transmission technology. The switch is used to interconnect multiple 10 BaseT LAN segments to the ISP LAN. Each of these segments have multiple remote access servers that are used to connect users to the Internet.

0677<figref idref="DRAWINGS">FIG. 29</figref> shows how broadband multimedia data is inserted into an ISP using the ideas described in this application. This configuration takes advantage of current ISP architectures. Many ISP's today have evolved over time as shown in <figref idref="DRAWINGS">FIG. 27</figref> and <figref idref="DRAWINGS">FIG. 28</figref>. They started with one remote access router serving a few customers (<figref idref="DRAWINGS">FIG. 27</figref>) and have expanded to multiple remote access routers (<figref idref="DRAWINGS">FIG. 28</figref>). <figref idref="DRAWINGS">FIG. 29</figref> shows the addition of multiple satellite receivers that receive multicast data.

0678In this configuration, the Layer 3 IP switch performs several functions. The first function is to connect the proper multicast stream form the appropriate satellite receiver to the appropriate LAN segments. This requires the switch to implement the IP Multicast Protocol (RFC1112).

0679The second function is to connect the proper Internet traffic to the appropriate LAN segment.

0680The third function of the Layer 3 switch is to perform the IOMP querier function as specified in RFC1112.

0681If the existing Layer 3 switch meets the above requirements, then it can be used. If not, then the ISP must upgrade the switch with one that meets these requirements. The commercially available HP800T switch is one example of such a layer <b>3</b> multicast enabled switch.

0682Such a configuration has the advantage of simplicity since the satellite receiver only needs to strip the HDLC (or other) encapsulation from the incoming data and electrically convert the data to the ethernet format. It does not need to have any knowledge of IP multicasting protocols.

0683Enhancements that could be incorporated in the receiver could be multicast address translation and data de-scrambling. In this case, the receiver must understand the IP multicasting protocol to perform these appropriate functions.

0684<figref idref="DRAWINGS">FIG. 30</figref> illustrates the layout of an exemplary traditional web page <b>800</b> suitable for use in the present multicast system. As illustrated, the web page <b>800</b> includes a video display window <b>800</b> that accepts and displays a video data stream from the broadcast transmission. External to the video display window <b>800</b>, text, and graphic content relating to the content of the video is displayed. Such content can be provided in the broadcast transmission itself, over the backbone of the Internet, or from storage at the ISP.

0685The web page <b>800</b> is also provided with a plurality of baud rate selection buttons <b>810</b>, <b>815</b>, <b>820</b>, and <b>825</b>. Each button corresponds to a baud rate of a broadcast video stream, each stream having the same multimedia content. For example, button <b>810</b> may correspond to transmission of the media content for the display window <b>800</b> at 14.4K. Similarly, buttons <b>815</b>, <b>820</b>, and <b>825</b> may correspond to baud rates of 28.8 K. 56.6 K. and 1.5 MB, respectively. This allows the client to select a baud rate for the video transmission rate that is suited to his system.

0686The web page provides substantial information and versatility to the user. The user may be presented with a substantially continuous flow of video information while concurrently having text and other information presented to him that may or may not be related to the video to allow the user to select other web pages, audio information, further video content, etc. These further selections may relate to the particular topic. product, etc., provided in the video content. The user may be given an option to select multiple video channels that may be supplied concurrently. The user is provided with a substantial number of channels to choose from, thereby allowing the user to select the desired video content.

0687The web pace needed not necessarily be provided with buttons for the selection of baud rate. Rather, a software plug-in for the web browser used by the client may be used to automatically join the appropriate multicast group depending on the data rate at which the client communicates with the ISP. In such instances, the plug-in software first detects the data rate at which the client is communicating with the Internet service provider. When a client wishes to view a particular video stream content, the software compares this detected data rate against a table of different data rates for the same content, each data rate corresponding to a unique multicast Group address. The software joins the client to the multicast group having the maximum data rate that does not exceed the data rate at which the software detected the communications between the client and the Internet service provider.

0688An exemplary embodiment of software that may be used for this purpose is set forth in an “Appendix A”, filed with related application Ser. No. 08/969,164, now U.S. Pat. No. 6,101,180, the entire contents of which is incorporated by reference herein. Appendix A includes listings of software source code in C++ for automatically detecting the baud rate at which the client is connected to the system and selecting the proper multicast join group.

0689Numerous modifications can be made to the foregoing system without departing from the spirit and scope of the various inventive aspects of this invention as set forth in the appended claims Therefore, it is the intention of the inventors to encompass all such chances and modifications that fall within the scope of the appended claims.