Methods for reliably sending IP multicast packets to multiple endpoints of a local area network

FIELD OF THE INVENTION

[0001] This invention relates generally to communication systems, and particularly communication systems incorporating reliable message using Multicast Internet Protocol (IP) addressing.

BACKGROUND OF THE INVENTION

[0002] Communication systems typically include a plurality of communication units, such as mobile or portable radio units and dispatch consoles that are geographically distributed among various repeater sites and console sites. The communication units wirelessly communicate with the repeater sites and each other, and are often logically divided into various subgroups or talkgroups. Communication systems may be organized as trunked systems, where a plurality of communication resources is allocated amongst multiple users or groups by assigning the repeaters within a radio frequency (RF) coverage area on a call-by-call basis, or as conventional (non-trunked) radio systems where communication resources are dedicated to one or more users or groups. In trunked systems, or in mixed trunked and conventional systems, there is usually provided a central controller/server (sometimes called a “zone controller”) for allocating communication resources among multiple sites. The central controller may reside within a single device or multiple devices and may be located at a fixed equipment site or may be distributed among the repeater or console sites.

[0003] In recent years, communication systems have begun to use Internet Protocol (IP) to transport packet data between endpoints (or “hosts” in IP terminology). The data is divided into IP packets called datagrams, which include addressing information (e.g., source and destination addresses) that enables various routers forming an IP network to route the packets to the specified destination(s). The destination addresses may identify a particular host or may comprise an IP Multicast address shared by a group of hosts. Examples of communication systems using multicast addressing are described and claimed in U.S. Pat. No. 6,141,347, titled “Wireless Communication System Incorporating Multicast Addressing and Method for Use” and U.S. patent application Ser. No. 09/464,269, titled “Methods for Implementing a Talkgroup Call in a Multicast IP Network,” each of which is assigned to the assignee of the present invention and incorporated herein by reference in its entirety.

[0004] Oftentimes, multiple endpoints or hosts are attached on a local area network (LAN). For example, in a wide area trunking system that performs group call, there are typically two or more consoles attached on a LAN. It would be desirable for all participating endpoints on the LAN to reliably receive IP multicast packets that are routed to the LAN such as, for example, control messages from a zone controller for setting up a group call. Although known Automatic Repeat Request (ARQ) protocols may be employed to achieve reliable message transfer sessions between a sender and receiver (whereby the receiver may request the retransmission of data blocks that are either not received or received corrupted from the sender), the establishing of multiple ARQ sessions with multiple endpoints attached to a LAN is unwieldy and may impede system performance. Accordingly, to the extent that ARQ sessions may be used to establish reliable message transmissions between a server (e.g., zone controller) and multiple hosts (e.g., consoles) attached to a LAN, it would be desirable that ARQ sessions be established with less than all of the host devices (hereinafter termed “link Op(s)”) attached to the LAN at a particular site. Generally, such a scheme ensures that IP multicast message(s) addressed from the server to an IP multicast destination address have reliably reached the link Op(s) and in most instances may be received by other host devices (hereinafter termed “listening Op(s)”) attached to the LAN that have joined the multicast group address.

[0005] However, it is possible that packets may be dropped on the LAN such that, for example, a packet (e.g., packet #2) from the server reaches the link Op but is not received by a listening Op. This can cause the listening Op to “hang” indefinitely, discarding message #3, #4 and so forth as it awaits retransmission of packet #2, but such retransmission never occurs because the link Op, having successfully received packet #2 will not request retransmission of packet #2. It would be desirable for listening Ops to recover from incidents of lost packets without “hanging.”

[0006] Accordingly, there is a need for a method for reliably sending IP multicast packets to multiple host devices attached to a LAN. Advantageously, the method allows for designating one or more of the hosts as link Ops and establishing a reliable message exchange session between a server (e.g., zone controller) and the link Op so as to ensure that IP multicast messages have reliably reached the LAN. In most instances, the messages will be received by all participating hosts on the LAN that have joined the appropriate multicast group address. However, in the event that packets are dropped on the LAN and thereby not received by certain host devices, there is a need for the affected hosts to reliably receive the lost packets. Further, there is a need that the affected hosts accommodate and recover from incidents of lost packets without “hanging” and, most preferably, without requiring retransmission of the lost packets from the server. The present invention is directed to satisfying these needs.

BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The foregoing and other advantages of the invention will become apparent upon reading the following detailed description and upon reference to the drawings in which:

[0008]FIG. 1 is a block diagram of a communication system using IP multicast addressing according to the invention;

[0009]FIG. 2 shows an example communication system with multiple communication servers connected to dispatch consoles at different sites;

[0010]FIG. 3 is a flowchart showing a method for determining one or more link Ops from among multiple endpoints attached to a LAN;

[0011]FIG. 4 is a flowchart showing a method for reliably exchanging control messages between a server and multiple endpoints attached to a LAN;

[0012]FIG. 5 shows the structure of a message sent from a communication server to a link Op according to the present invention;

[0013]FIG. 6 is a flowchart showing steps for the link Op and listening Op to reliably receive messages from a server;

[0014]FIG. 7 is a message sequence chart illustrating an example of a link Op and listening Op recovering from a missing packet dropped on a WAN; and

[0015]FIG. 8 is a message sequence chart illustrating an example of a listening Op recovering from a missing packet dropped on a LAN.

DESCRIPTION OF PREFERRED EMBODIMENTS

[0016] In one embodiment of the present invention, there is provided a method of determining a link Op from among a plurality of host devices on a LAN. The method comprises sending, from a first host of the plurality of hosts, via one or more network devices, a link up request message addressed to a communication server. In response, the communication server sends a link up acknowledgement message to the first host including a first control multicast group address. The first host then sends a link advertisement message including the first control multicast group address to at least a second host of the plurality of hosts.

[0017] In another embodiment of the present invention, there is provided a method of sending and receiving control messages between a communication server and a plurality of sites having one or more host devices attached to a LAN. The method comprises distributing different control multicast group addresses to each of the plurality of sites. The method further comprises sending, from the communication server, via one or more network devices, a sequence of IP packets addressed to the control multicast group addresses; and receiving by a number of participating host devices having joined the control multicast group addresses, the sequence of IP packets. A reliable message transfer session may be established at each site between the communication server and a designated link Op such that the link Op may request retransmission of missing packets, and such that messages from the site are communicated to the server via the link Op.

[0018] In still another embodiment of the present invention, there is provided a method of sending a sequence of IP packets from a communication server to at least one site having a link Op and one or more listening Ops. The method comprises the server generating a message comprising a packet of the sequence of IP packets, a sequence number of the packet, and a sequence number of a last acknowledged packet of the sequence of IP packets by the link Op. The message is sent by the server to the control multicast address of the at least one site.

[0019] In still yet another embodiment of the present invention, there is provided a method for a link Op and listening Op at a site to detect and recovering from missing packets in a sequence of packets received from a communication server. Upon a link Op detecting a missing packet, the link Op may request that the communication server resend the packet. Upon a listening Op detecting a missing packet, the listening Op determines whether the link Op will request retransmission of the missing packet. If the link Op is determined to not request retransmission of the missing packet, the listening Op requests retransmission of the missing packet or accepts the packet as missing and processes an out-of-sequence packet. If the link Op is determined to request retransmission of the missing packet, the listening Op discards the packet and relies upon the link Op to request retransmission of the missing packet.

[0020] Turning now to the drawings and referring initially to FIG. 1, there is shown an IP multicast communication system (or “network”) <b>100</b> comprising a plurality of sites <b>102</b>, <b>104</b>, <b>106</b> that are logically coupled, via respective router elements <b>108</b>, <b>110</b>, <b>112</b> to a core router element <b>114</b>. The router elements <b>108</b>-<b>114</b> are functional elements that may be embodied in separate physical routers or combinations of routers. Nevertheless, for convenience, the router elements will hereinafter be referred to as “routers.” The core router <b>114</b> is sometimes referred to as the “Rendezvous Point” or “RP Router” because it is a rendezvous point of the multicast distribution tree between host devices at different sites. The core router <b>114</b> is coupled to a zone controller/server <b>116</b> having a processor <b>118</b> (such as a microprocessor, microcontroller, digital signal processor or combination of such devices) and a memory <b>120</b> (such as volatile or non-volatile digital storage devices or combination of such devices). In one embodiment of the present invention, the zone controller <b>116</b> manages and assigns IP multicast addresses for payload (voice, data, video, etc.) and control messages between and among the various sites <b>102</b>, <b>104</b>, <b>106</b>.

[0021] As depicted in FIG. 1, site <b>102</b> includes a plurality of repeaters <b>122</b>, <b>124</b>, <b>126</b> that are coupled, via Ethernet <b>128</b> to an associated router <b>108</b>. Similarly, site <b>104</b> includes a plurality of repeaters <b>130</b>, <b>132</b>, <b>134</b> that are coupled, via Ethernet <b>136</b> to router <b>110</b>. Generally, the repeaters at the various sites <b>102</b>, <b>104</b> communicate, via wireless communication resources <b>144</b>, <b>146</b> with a plurality of communication units <b>148</b>-<b>156</b> (sometimes called “subscriber units”) which may comprise mobile or portable wireless radio units. Suitable wireless communication resources <b>144</b>, <b>146</b> are multiple RF (radio frequency) channels such as pairs of frequency carriers, time division multiple access (TDMA) slots, code division multiple access (CDMA) channels, or any other RF transmission media. Site <b>106</b> includes a plurality of dispatch consoles <b>138</b>, <b>140</b> that are coupled via Ethernet <b>142</b> to router <b>112</b> and defines a “console” site. Consoles <b>138</b>, <b>140</b> may comprise wireless or wireline consoles. Although not shown in

[0022]FIG. 1, it will be appreciated that a single site may include both repeaters and console positions.

[0023] In one embodiment, the zone controller <b>116</b> assigns and manages IP multicast addresses for control messages and/or payload (voice, data, video, etc.) between and among communication devices participating in talkgroup or point-to-point calls at the various sites <b>102</b>, <b>104</b>, <b>106</b>. The multicast group address(es) may be assigned statically or dynamically for particular talkgroups or communication devices.

[0024] Multipoint routes pertaining to the IP multicast addresses used in the present invention are maintained by the routers <b>108</b>-<b>114</b> forming the network <b>100</b>. IP Multicast is based on the well-known Internet Group Management Protocol (IGMP) which allows a multicast router to track the existence of multicast group members on local networks coupled to that router. Additionally, multicast routers use the information provided by IGMP in conjunction with a multicast routing protocol to support forwarding of data across a network of routers. Given the nature of wireless communication systems, sparse mode protocols such as the Core Based Tree (CBT) protocol and the Protocol Independent Multicast-Sparse Mode (PIM-SM) protocol are preferred multicast routing protocols for use in the present invention. However, it is anticipated that dense mode protocols such as the Distance Vector Multicast Routing Protocol (DVMRP), the Multicast Open Shortest Path First (MOSPF) protocol, the Protocol Independent Multicast-Dense Mode (PIM-DM) protocol or other protocols that may be devised in the future may also be used to implement the present invention. A common feature of these multicast routing protocols is that each establishes a “spanning tree” which, for a given multicast group, defines all of the router interfaces which contain group members and the necessary routes between these interfaces to provide the multicast distribution with a minimum amount of data replication.

[0025] As will be appreciated, communication servers may be logically connected to host devices at multiple sites, including multiple console positions at different sites. Also, more than one server may be connected a particular site. FIG. 2 illustrates a communication system <b>200</b> having multiple servers connected to multiple sites. As shown, server <b>202</b> is connected to sites <b>210</b> and <b>212</b>; server <b>204</b> is connected to site <b>210</b>; server <b>206</b> is connected to sites <b>212</b> and <b>214</b>, and server <b>208</b> is connected to site <b>214</b>. The servers <b>202</b>-<b>208</b> may comprise, for example, any combination of zone controllers, conventional servers, telephony servers, etc. or generally any type of server presently known or devised in the future that is capable of sending and receiving IP datagrams with other host devices. In the embodiment of FIG. 2, the host devices comprise a plurality of console positions at sites <b>210</b>-<b>214</b>. However, as will be appreciated, the present invention may be implemented with virtually any type or number of host devices located at any number of sites.

[0026] Generally, as best observed in FIG. 1, connections from a server to a host device are established by routers defining a packet-based wide-area network (WAN) and the host devices at each respective site are connected by local area network (LAN). In one embodiment, the various servers send different IP multicast group addresses to each participating site. Consequently, sites connected to multiple servers receive different multicast group addresses from each server. For example, server <b>202</b> (“Communication Server 1”), which serves both site <b>210</b> (“Dispatch Site 1”) and site <b>212</b> (“Dispatch Site 2”) may send a first multicast group address to site <b>210</b> and a second multicast group address to site <b>212</b>. Additionally, server <b>204</b> (“Communication Server 2”) may send a third multicast group address to site <b>210</b>. Host devices desiring to receive IP packets from a particular server join the multicast group addresses associated with that server at their respective sites, by sending Internet Group Management Protocol (IGMP) “Join” messages to their local router(s). Based on the IGMP Join messages, the routers of the network build a spanning tree of router interfaces and necessary routes between those interfaces to support communication between the server and the participating devices at each site. In one embodiment, host devices may join any number of the multicast group addresses available at their respective sites. Thus, in the present example, consoles at site <b>210</b> may join the first multicast group address (if they desire to receive messages from server <b>202</b>) and/or the third multicast group address (if they desire to receive messages from server <b>204</b>).

[0027] Turning now to FIG. 3, there will be described various steps for establishing link Op console(s) from among multiple hosts attached to a LAN. In one embodiment, the steps of FIG. 3 are performed to establish a primary and a secondary link Op at each console site. Thus, in the event the primary link Op fails or goes out of service, communication may proceed via the secondary link Op. For example, with reference to FIG. 1, the steps of FIG. 3 may be performed to establish a primary and secondary link Op console from among the consoles <b>138</b>, <b>140</b> at console site <b>106</b>. At step <b>302</b>, a first host sends a link up request message addressed to a communication server. For example, console <b>138</b> (FIG. 1) may send a link up request message to the zone controller <b>116</b>. In one embodiment, the link up request message comprises an IP unicast message causing the routers of the network to deliver IP packets associated with the message to a specific destination address associated with the communication server.

[0028] At step <b>306</b>, the server sends a link up acknowledgement message to the first host (e.g., console <b>138</b>) having sent the link up request. In one embodiment, the link up acknowledgement message comprises an IP unicast message directed to a specific destination address associated with the first host and includes a first multicast group address to be used for control messages between the communication server and the first host and subsequently any other hosts at that site that desire to receive control messages from that server.

[0029] At step <b>308</b>, the first host (e.g., console <b>138</b>) attempts to join the multicast group address received at step <b>306</b> by sending an IGMP “Join” message to its local router (router <b>112</b> in the present example). The local router <b>112</b> sends PIM Join message(s) to the core router <b>114</b> to form the spanning tree of router interfaces logically connecting the zone controller <b>116</b> to console <b>138</b>. For convenience, both IGMP and PIM Join messages will hereinafter be referred to as “Join” messages. Once the router interfaces are established, i.e, upon the first host having successfully joined the IP multicast group address, packets may be distributed by the router(s) of the network to the first host.

[0030] At step <b>310</b>, the first host determines whether it is reliably joined to the multicast group address. Methods for achieving reliable Joins are described and claimed in U.S. patent application Ser. No. 09/728,359, assigned to the assignee of the present invention and incorporated herein by reference in its entirety. Generally, the determination of whether a receiving host (e.g., console <b>138</b>) is reliably joined to a multicast group address involves a sourcing host (e.g., zone controller) sending one or more test packets, or “hello” packet(s) addressed to a multicast group address. If any of the test packets are received by the receiving host, it knows that it is reliably joined to the multicast group address. Otherwise, if it does not receive any packets within a certain period of time, it knows that its attempt to join the multicast group address was unsuccessful. If the first host is not reliably joined at step <b>310</b>, it returns to step <b>308</b> to re-attempt to join the multicast group address received at step <b>306</b>.

[0031] If the first host is reliably joined, it sends an acknowledgement (or “link up established”) message to the communication server at step <b>312</b> indicating that it has successfully joined the first control multicast group address. In return, the communication server sends a “go active” message at step <b>314</b> instructing the first host to proceed as link Op. In one embodiment, the first host will proceed as the primary link Op in response to receiving the go active message. Then, at step <b>316</b>, the first host sends a link advertisement message to other hosts (“listening Ops”) on the LAN informing them that it is the primary link Op. In one embodiment, the link advertisement message comprises an IP broadcast message that may be received by any other host on the LAN and includes the first control multicast group address. Thus, continuing the present example, suppose the console <b>138</b>, having sent a link up established message to the zone controller at step <b>312</b>, receives a go active message at step <b>314</b>. Thereafter, the console <b>138</b> broadcasts a link advertisement message informing console <b>140</b> that it (console <b>138</b>) is the primary link Op and further informing console <b>140</b> of the first control multicast group address. Console <b>140</b> thus defines a listening Op with respect to the first control multicast group address.

[0032] At step <b>318</b>, upon receiving the link advertisement message, listening Ops desiring to receive control messages from the communication server join the first control multicast group address so as to be eligible to receive packets addressed to the first control multicast group address. Thus, for example, console <b>140</b> may join the first control multicast group address to receive control messages from the zone controller <b>116</b>.

[0033] At step <b>320</b>, it is determined whether a secondary link Op is needed. If a secondary link Op is needed or desired, the process returns to step <b>302</b> to begin the process of establishing a secondary link Op. In one embodiment, the secondary link Op comprises a different host than the primary link Op. Thus, for example, if console <b>138</b> is the primary link Op, console <b>140</b> may become the secondary link Op. In such case, at step <b>316</b>, console <b>140</b> sends a link advertisement message to console <b>138</b> informing console <b>138</b> that it (console <b>140</b>) is the secondary link Op. Console <b>13</b><b>8</b> thus defines a listening Op with respect to the second control multicast group address. Alternatively, the same device (e.g., console <b>138</b>) may operate as both primary and secondary link Op. In a preferred embodiment, the multicast group address received at step <b>306</b> by the secondary link Op (the second multicast group address) is different from the control multicast group address received by the primary link Op (the first multicast group address). Thus, the second multicast group address becomes a “backup” to the first multicast group address.

[0034] Now turning to FIG. 4, there will be described various steps for reliably exchanging control messages between a communication server and multiple hosts, including a link Op and one or more listening Ops attached to a LAN. At step <b>402</b>, participating hosts (e.g., consoles) at each site join a control multicast group address. Where a server is connected to multiple sites, as described in relation to FIG. 2, the server sends a different multicast group address to each site. Similarly, where a site is served by multiple servers, they receive different multicast group addresses from each server. In one embodiment, the respective control multicast group addresses are sent from the zone controller to the link Op of each site in an IP unicast link up acknowledgment message, and sent from the link Op to various listening Ops at each site in an IP broadcast link advertisement message. The link Op and listening Ops at each site join the control multicast group address by sending IGMP “Join” messages to their local router. In turn, the routers of the network to form the spanning tree of router interfaces logically connecting the link Op ad listening Ops to the communication server(s). For convenience, the remaining description of FIG. 4 will presume a single communication server exchanging messages with a single site having a link Op and one or more listening Ops (e.g., zone controller <b>116</b> exchanging messages with console site <b>106</b>, comprising link Op <b>138</b> and listening Op <b>140</b>). However, it will be appreciated that the process of FIG. 4 may be duplicated for multiple servers and/or multiple sites. Moreover, the process may be duplicated for both primary and secondary link Ops.

[0035] At step <b>404</b>, the link Op establishes an ARQ session with the communication server. Generally, the ARQ session defines a reliable message transfer session that enables the link Op to request retransmission of missing packets or packets received in error. Thus, once an ARQ session is established, the communication server may reliably send messages to the link Op, and vice versa. The type of ARQ protocol used is an implementation decision and is not a part of the present invention. Thus, virtually any ARQ may be used, including ARQ protocols presently known or devised in the future. In one embodiment, ARQ session is established only by the link Op(s) at each site and not by the listening Ops, so as to reduce system complexity and improve system performance.

[0036] If the communication server desires to send a message (step <b>406</b>) to the link Op and/or listening Ops, it sends the message at step <b>408</b> (“a Send ARQ message”) to the control multicast group address that the link Op and listening Ops have joined at step <b>402</b>. The structure of one embodiment of the Send ARQ message will be described in relation to FIG. 5. All of the endpoints having successfully joined the control multicast group at step <b>402</b> receive the message at step <b>410</b>.

[0037] If an endpoint (i.e., link Op or listening Op) desires to send a message (step <b>412</b>) to the communication server, the process varies depending on the type of Op (step <b>414</b>). Listening Ops send the message to the Link Op at step <b>416</b> and the Link Op forwards the message to the communication server at step <b>418</b>. Messages from Link Ops are sent directly to the communication server at step <b>418</b>. Thus, in one way or another, all messages from the site are sent to the communication server via the link Op.

[0038] In one embodiment, the messages from the Listening Ops to the Link Op are sent, via the LAN, using an IP unicast address and messages from the Link Op to the communication server are sent, via the routers of the network (WAN), using an IP unicast address.

[0039] As has been described, endpoints desiring to receive control messages from the communication server join a control multicast group address. Control messages are routed, via the WAN, from the communication server (e.g., zone controller <b>116</b>) to a local site router (e.g., router <b>112</b> of console site <b>106</b>). Messages are communicated, via the LAN (e.g., LAN <b>142</b>), from the local router to the participating hosts (e.g., console <b>138</b>, <b>140</b>) having joined the control multicast group address. The participating endpoints include a link Op (e.g., console <b>138</b>) having established a reliable message transfer session with the communication server, and one or more listening Ops (e.g., console <b>140</b>) that have not established a reliable message transfer session with the server.

[0040]FIG. 5 shows the structure of an example message <b>500</b> sent from the communication server to the link Op, via the control multicast group address. It is contemplated that the communication server will send a sequence of messages <b>500</b> to the link Op, which messages are eligible to be received by the link Op and listening Ops having joined the multicast group address. Each message <b>500</b> comprises an IP header <b>502</b>, a transmit sequence number field <b>504</b>, a “last received” sequence number field <b>506</b>, a “last acknowledged” sequence number field <b>508</b> and a message data field <b>510</b>. The IP header <b>502</b> includes source and destination IP addresses, as is well known in the art. The transmit sequence number field <b>504</b> identifies the sequence number of a packet that is presently being transmitted. The last received sequence number field <b>506</b> identifies the sequence number of a packet last received from the link Op. The last acknowledged sequence number field <b>508</b> identifies the sequence number of a most recent packet that is acknowledged (i.e., indicated as being received) by the link Op. The message data field <b>510</b> includes the packet(s) being transmitted which may include, for example, control message data.

[0041]FIG. 6 shows various steps for the link Op and the listening Op to reliably receive message(s) <b>500</b> from the communication server. After having received a message <b>500</b> on the control multicast group address (step <b>410</b>, FIG. 4), the endpoints detect at step <b>602</b> whether any packets that should have been received are missing. This may be accomplished by maintaining a counter of packet(s) last received from the server and comparing the sequence number of the last received packet to the sequence number of the presently received packet. If the presently received packet is out of sequence with the last received packet, the receiving link Op and/or listening Op may conclude that there are missing packet(s). Thus, for example, if a receiver receives packet <b>5</b> after having last received packet <b>3</b>, it will conclude that packet <b>4</b> is missing because it knows that packet <b>4</b> should have been received before packet <b>5</b>.

[0042] If a missing packet is detected by a link Op (step <b>604</b>), that means that the missing packets were dropped somewhere by the routers of the network (WAN) before reaching the LAN. In such case, the link Op discards the presently received, out-of-sequence packet at step <b>606</b> and sends a negative acknowledgement (NACK) message to the server at step <b>608</b>. In one embodiment, the NACK message identifies the sequence number of the packet last received (in sequence) by the link Op. Thus, in effect, the NACK message comprises a request for retransmission of missing packets that enables the server to determine which packet(s) were not received by the link Op. The server retransmits any missing packets at step <b>610</b> and continues transmitting, in sequence, any further packets. Thus, for example, if the link Op upon receiving packet <b>5</b> concludes that packet <b>4</b> is missing, it will discard packet <b>5</b> and send a NACK message to the server indicating that packet <b>3</b> is its last received packet. The server, in turn, will retransmit packets <b>4</b> and <b>5</b> and then proceed transmitting any further packets in the sequence.

[0043] If a missing packet is detected by a listening Op (step <b>604</b>), it is possible that the missing packet was dropped on the LAN such that, for example, the packet was received by the link Op but not by the listening Op. However, it is also possible that the missing packet was dropped on the WAN, in which case the link Op will have detected the missing packet at step <b>604</b> and sent a negative acknowledgement at step <b>608</b>, causing the server to resend the missing packets at step <b>610</b>. According to principles of the present invention, the listening Op is able to distinguish between these two events such that in the former event, the listening Op may either accept that packets were lost and move up its counter (so that it may process packets received out of sequence) or, alternatively, to request retransmission of the missing packet(s). In either case, the listening Op will not continue to “hang” indefinitely (i.e., discarding packets received out of sequence while it passively waits for the missing packets to be retransmitted). In the latter event, if it is determined that packets are dropped on the WAN, the listening Op knows that the link Op will request or has requested retransmission of the missing packet(s).

[0044] At step <b>612</b>, the listening Op determines whether a missing packet was acknowledged by the link Op and thereby will not be requested to be retransmitted by the link Op. This is accomplished by the listening Op comparing the sequence number of the missing packet to the sequence number of the packet last acknowledged by the link Op, identified in field <b>508</b> (FIG. 5). If the missing packet was acknowledged by the link Op, the listening Op may conclude that the missing packet was dropped on the LAN after having been received by the link Op and will not be requested to be retransmitted by the link Op. In other words, the listening Op would be out of sync with the link Op. If this occurs, in one embodiment, the listening Op accept that the missing packet is lost (step <b>616</b>), advances its counter and processes the packet received out-of-sequence at step <b>620</b>. Of course, the listening Op may then continue to process any subsequently received packets. Alternatively, if the listening Op does not desire to accept the missing packet as lost, it may request retransmission of the missing packet at step <b>618</b>. In one embodiment, the link Op maintains a buffer of recently received packets and step <b>618</b> comprises the listening Op requesting retransmission of the packet from the link Op. In such event, the link Op retrieves the missing packet from its buffer and sends the packet to the listening Op, via the LAN. As will be appreciated, the listening Op might also request retransmission of the packet from the communication server if WAN traffic is not a concern.

[0045] If at step <b>612</b> the listening Op determines that the missing packet was not acknowledged by the link Op, the listening Op may conclude that the missing packet was dropped on the WAN and was (or will be) detected by the link Op. In such case, the listening Op discards the out-of-sequence packet at step <b>614</b> and depends on the link Op to request retransmission of the missing packet. The listening Op will receive the missing packet once it is successfully retransmitted by the server.

[0046]FIG. 7 is a message sequence chart illustrating an example of a link Op and listening Op recovering from a missing packet dropped on a WAN. The sequence presumes that the link Op and listening Op are joined to an IP multicast address and that messages from the server are addressed to the IP multicast address. Messages from the listening Op to the link Op, and from the link Op to the server, are IP unicast messages. The message sequence of FIG. 7 begins with the listening Op sending a first message <b>700</b> to the link Op. The link Op forwards the message to the server, yielding a forwarded message <b>702</b>. The notation T=1, R=5 on the forwarded message <b>702</b> indicates a transit sequence number 1 and last received sequence number 5 (each relative to the link Op).

[0047] The server sends messages <b>704</b> and <b>708</b> to the link Op, which messages are successfully received by both the link Op and the listening Op. The notation T=6, R=1, LA=5 on message <b>704</b> indicates a transmit sequence number 6, a last received sequence number 1 (each relative to the server) and a last acknowledged sequence number 5 (indicating that the link Op has previously acknowledged receipt of packet 5). Similarly, the notation T=7, R=1, LA=5 on message <b>708</b> indicates a transit sequence number 7, a last received sequence number 1 and a last acknowledged sequence number 5.

[0048] Next, the server sends messages <b>712</b> (T=8, R=1, LA=5) and <b>614</b> (T=9, R=1, LA=5) to the link Op, but message <b>712</b> is dropped on the WAN and not received. Message <b>714</b>, containing packet sequence number 9, is received by both the link Op and listening Op. The link Op and listening Op discard packet 9 as being out-of-sequence. The link Op sends a negative acknowledgement message <b>718</b> to the server indicating that its last received packet is 7. In response, the server sends messages <b>720</b> (T=8, R=1, LA=5) and <b>724</b> (T=9, R=1, LA=5), thereby retransmitting the missing packet <b>8</b> and the formerly out-of-sequence packet <b>9</b>. Messages <b>720</b>, <b>724</b> are successfully received by both the link Op and listening Op.

[0049]FIG. 8 is a message sequence chart illustrating an example of a listening Op recovering from a missing packet dropped on a LAN. Like FIG. 7, the sequence presumes that the link Op and listening Op are joined to an IP multicast address and that messages from the server are addressed to the IP multicast address. Messages from the listening Op to the link Op, and from the link Op to the server, are IP unicast messages. The message sequence of FIG. 8 begins with the link Op sending a message <b>802</b> (T=1, R=7) to the server.

[0050] The server sends messages <b>804</b> (T=8, R=1, LA=7) and <b>808</b> (T=9, R=1, LA=7) to the link Op, which messages are successfully received by both the link Op and the listening Op. The link Op sends an acknowledgement message <b>812</b> informing the server that it has successfully received packet 9. Next, the server sends a message <b>814</b> (T=10, R=1, LA=9) to the link Op, which message is successfully received by the link Op but is dropped on the LAN and not received by the listening Op. The link Op sends an acknowledgement message <b>818</b> informing the server that it has successfully received packet 10. The server sends the next message <b>820</b> (T=11, R=1, LA=10) to the link Op, which message is successfully received by the link Op and the listening Op. The link Op, having received packet 10, processes packet 11. The listening Op discards packet 11 as being out-of-sequence because its last received packet is 9 and it is expecting packet 10. The listening Op recognizes that it is out of sync with the link Op (i.e., that the link Op has already received packet 10) because message <b>820</b> indicates packet 10 was acknowledged by the link Op. The listening Op sends message <b>824</b> to the link Op, requesting the link Op to retransmit the missing packet 10 and the out-of-sequence packet 11. The link Op sends message <b>826</b> to the listening Op including packets 10 and 11.

[0051] Alternatively, upon the listening Op determining that it is out of sync with the link Op, the listening Op may process packet out-of-sequence packet 11 without requesting retransmission of packets 10 and 11 and move up its counter accordingly.

[0052] The present disclosure therefore has identified a method for reliably sending IP multicast packets to multiple host devices attached to a LAN. The method takes advantage of advances in reliable LAN implementations to remove the necessity and complexity of multiple endpoints on the LAN having to establish a reliable message exchange sequence with a server, in favor of establishing a reliable message exchange sequence with a link Op at each site. The disclosure identifies methods for the link Op and listening Op to detect missing packets and for listening Ops to recover from incidents of missing packets without hanging and without requiring retransmission of the lost packets from the server.

[0053] The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes that come within the meaning and range of equivalency of the claims are to be embraced within their scope.