Methods, devices and software for merging multicast groups in a packet switched network

FIELD OF THE INVENTION

P-0001[0001] The present invention relates generally to computer networks, and more particularly to methods, devices and software for merging multicasts in a packet switched network, thereby allowing two or more groups of multicast participants to join a common multicast.

BACKGROUND OF THE INVENTION

P-0002[0002] Multicasting, as used herein, refers to the transmission of the same information in packets by a source to a multiplicity of receivers in a packet switched communications network.

P-0003[0003] There are two major steps in multicasting: multicast routing for establishing a desirable connection, and data forwarding for switching of packets at each intermediate switching node along the path. Multicast routing establishes a delivery route through which information packets can be exchanged efficiently among participants. The plurality of participants that exchange common data is referred to as groups.

P-0004[0004] Known internet protocols allow the establishment of multicasts on Internet Protocol (“IP”) compliant networks. A commonly supported IP protocol, referred to as the Internet Group Management Protocol (“IGMP”) is detailed in the Internet Engineering Task Force, Request for Comments, (“RFCs”) 1112, 1122, 1812, 2236, 2715, 2933, and 3228.

P-0005[0005] Often, two or more established groups may wish to merge and later disband, to exchange data of common interest, increasing the flexibility in sharing data and supporting collaboration. The current IP multicast implementations, however, do not provide for graceful merging and disbanding of multiple groups. That is, they allow a host to join and leave a multicast group, but do not support a group to join another group as a unit. Thus to have the effect of a group of hosts (group X) joining another group of hosts (group Y), all members of group X individually join the group Y. The cost, in terms of network traffic, of having individual members joining and leaving increases rapidly with the number of members present in a group. As such, this approach is undesirable in most practical networks in which memberships may change frequently.

P-0006[0006] In addition, a host typically maintains open one port to listen to each group it wants to join. This form of implementation limits the total number of ports, and hence groups, a host can join. If there is a constraint on the number of ports a host can listen to, a host may have to leave some multicast groups to reuse these ports. This may cause the property of the original group setup to be lost.

P-0007[0007] As an alternative, a list defining the merge status of each group could be maintained at the application level. This however requires higher protocol processing as each packet needs to traverse up the IP stack, the transport stack and then onto the application layer before a decision can be made for sending the packet to a group. Hence, high transmission and protocol overhead will be incurred if the merge status of groups is maintained at the application level.

P-0008[0008] The constraints and limitations of existing IP multicast methods above have hampered the development of innovative group communication services for collaborative applications. Clearly, there is a need to provide a simple and yet powerful multicast architecture to support group operations in a packet switched network.

SUMMARY OF THE INVENTION

P-0009[0009] In accordance with the present invention, multicast groups may be merged at edge routers. Merging and disbanding of multicast groups may be controlled by a designated computing device (referred to as a connection manager) on each sub-network. Connection managers across sub-networks may communicate with each other to ensure merge and disband messages are properly distributed. Connection managers may optionally be interconnected hierarchically.

P-0010[0010] Connection managers may optionally act as proxies for merged groups to ensure traffic for merged groups is directed to a sub-network.

P-0011[0011] In accordance with an aspect of the present invention, there is provided a method of merging first and second multicast groups in a packet switched computer network. The network includes a plurality of sub-networks. The method includes receiving a request to merge the first and second multicast groups at a computing device, operable to receive requests to merge multicast groups from multiple hosts on the network; dispatching a request from the computing device to merge the first and second multicast groups to an edge router connecting one sub-network to other sub-networks, thereby signalling the edge router to duplicate data in packets for the first group to members of the second group in the sub-network.

P-0012[0012] In accordance with an aspect of the present invention, there is provided a method of operating an edge router connecting a sub-network to a packet switched network, comprising: maintaining a list of merged multicast groups at the router; duplicating data in packets destined for members of one of the groups on the sub-network, to provide the contents to members of a merged group on the sub-network, based on the list.

P-0013[0013] Aspects of the invention may be embodied on computer readable media; within computing devices; or as routers.

P-0014[0014] Other aspects and features of the present invention will become apparent to those of ordinary skill in the art upon review of the following description of specific embodiments of the invention in conjunction with the accompanying figures.

BRIEF DESCRIPTION OF THE DRAWINGS

P-0015[0015] In the figures which illustrate by way of example only, embodiments of the present invention,

P-0016[0016]FIG. 1 illustrates a conventional packet switched computer network, allowing multicasts;

P-0017[0017]FIG. 2 illustrates merging of multicasts in the computer network of FIG. 1;

P-0018[0018]FIG. 3 illustrates a packet switched network, including computing devices and routers exemplary of embodiments of the present invention;

P-0019[0019]FIG. 4 illustrates an exemplary data structure, maintaining an indicator of merged groups stored at a computing device of FIG. 3;

P-0020[0020]FIG. 5 illustrates an exemplary data structure, maintaining an indicator of group memberships of hosts, stored at a computing device of FIG. 3;

P-0021[0021]FIG. 6 illustrates an exemplary data structure, maintaining an indicator of merged requests, stored at a computing device of FIG. 3;

P-0022[0022]FIG. 7 illustrates an exemplary data structure, maintaining an indicator of merged groups stored at a router of FIG. 3;

P-0023[0023]FIG. 8 schematically depicts asymmetric merging of groups;

P-0024[0024]FIG. 9 schematically depicts symmetric merging of groups;

P-0025[0025]FIG. 10 illustrated the general IGMP version 2 (IGMPv2) packet format;

P-0026[0026]FIGS. 11A to <b>11</b>F illustrate example messages exchanged between connection managers and routers in the network of FIG. 3;

P-0027[0027]FIG. 12 illustrates alternate message formats of messages that could be exchanged between connection managers and routers in the network of FIG. 3;

P-0028[0028]FIG. 13 is a flowchart illustrating steps performed at a connection manager of FIG. 3, to merge groups;

P-0029[0029]FIG. 14 is a flowchart illustrating exemplary steps performed at a router of FIG. 3, to merge groups;

P-0030[0030]FIG. 15 is a flowchart illustrating steps performed at a connection manager of FIG. 3, to merge groups;

P-0031[0031]FIG. 16 is a flowchart illustrating steps performed at a connection manager of FIG. 3, to monitor multicast messages;

P-0032[0032]FIG. 17 is a flowchart illustrating steps performed at a router in providing data to merged groups;

P-0033[0033]FIGS. 18-20 illustrate various group mergers in the network of FIG. 3;

P-0034[0034]FIG. 21 is a flowchart illustrating steps performed at a connection manager of FIG. 3, to disband merged groups;

P-0035[0035]FIG. 22 is a flowchart illustrating exemplary steps performed at a router of FIG. 3, to disband merged groups;

P-0036[0036]FIG. 23 is a flowchart illustrating steps performed at a connection manager of FIG. 3, to disband merged groups;

P-0037[0037]FIGS. 24-26 schematically illustrates possible arrangements of multiple connection managers of FIG. 3;

P-0038[0038]FIGS. 27A to <b>27</b>F illustrate alternate example messages that could exchanged between connection managers and routers in the network of FIG. 3, in place of the messages illustrated in FIGS. 11A-11F; and

P-0039[0039]FIG. 28 illustrates further alternate message formats of messages that could be exchanged between connection managers and routers in the network of FIG. 3.

DETAILED DESCRIPTION

P-0040[0040]FIG. 1 illustrates a collection of internet compliant sub-networks N<b>1</b>, N<b>2</b>, N<b>3</b>, N<b>4</b>, and N<b>5</b>. Conventional routers R connect sub-networks. (R_ijdenotes a router that is connected to sub-network i and sub-network j). Individual computing devices have joined multicasts A and B. As illustrated, example multicast A has members: a<b>1</b> in sub-network N<b>2</b>, a<b>2</b> in sub-network N<b>5</b> and a<b>3</b> in sub-network N<b>3</b>. Multicast B has members: b<b>1</b> in sub-network N<b>1</b>, b<b>2</b> in sub-network N<b>2</b> and b<b>3</b> in sub-network N<b>4</b>.

P-0041[0041] Computing devices that are members of A and B and routers R, by virtue of software executing at the devices and routers, all adhere to the IGMP, as for example detailed in one or more of the Internet Engineering Task Force RFCs 1112, 1122, 1812, 2236, 2715, 2933, and 3228.

P-0042[0042] If multicast A (and its members) wishes to merge with multicast B (and its members) using the service provided by current IP multicast, each member of A would send individual conventional IGMP Membership Reports to join group B. This is illustrated in FIG. 2. The number of conventional IGMP Membership Reports sent increases with the number of members, so do the forwarding states of the routers involved. In addition, there is no mechanism in the existing IP multicast to ensure that all members of a particular group have joined another group. Thus, the desired merge of one group with another may not be reliable under such circumstances. Clearly the approach is neither efficient nor desirable.

P-0043[0043] From the foregoing description, persons of ordinary skill will readily recognize that use of conventional IGMP Membership Reports as described, results in increased traffic on the sub-networks resulting from each member of a particular group sending an IGMP Membership Report to join to another group. Further, there is no assurance that a desired merge of a sub group to another group will be completed in all sub-networks. As well, in a dynamic situation where groups are merged and disbanded frequently, inconsistency in group merge status is likely to occur as it is hard to ensure a merge or disband operation is fully completed.

P-0044[0044] Exemplary of the present invention, merging of multicast groups may be simplified by designating one computing device as a multicast connection manager; enabling computing devices (i.e. hosts) wishing to initiate a merge between two groups to initiate merging through the connection manager; and modifying routers to route traffic to merged groups on sub-networks. This may be appreciated, in overview, with reference to FIG. 3. As will become apparent, connection managers may take the form of existing routers or designated computing devices on a sub-network.

P-0045[0045]FIG. 3 therefore illustrates a network <b>10</b> formed of a collection of internet compliant sub-networks <b>12</b>. Routers <b>16</b> interconnect sub-networks <b>12</b>. Routers <b>16</b> are referred to as edge-routers as they are at the edge of the various sub-networks <b>12</b>. Routers <b>16</b> include a processor coupled with computer readable memory storing software exemplary of embodiments of the present invention. Sub-networks <b>12</b> are preferably IP sub-networks, and are thus identifiable by a sub-network mask.

P-0046[0046] As illustrated, each sub-network <b>12</b> includes a plurality of conventional computing devices <b>14</b> (often referred to as hosts), capable of establishing multicast sessions, for example using a conventional IGMP protocol detailed in one or more of RFCs 1112, 1122, 1812, 2236, 2715, 2933, and 3228. Routers <b>16</b> are operable to route traffic in a conventional manner and to merge multicast groups, and broadcast to merged groups as detailed herein.

P-0047[0047] In the illustrated embodiment, each host <b>14</b> is a conventional network capable workstation. A host <b>14</b> could, for example, be an Intel x86 based computer acting as a Microsoft Windows NT, Windows 2000, Apple, or Unix based workstation, personal computer or the like. A host <b>14</b> typically includes a processor, in communication with computer readable memory; network interface; and may include input output interface; and video adapter. As well, a host <b>14</b> may optionally include a display and input/output devices, such as a keyboard, disk drive and a mouse (not shown) or the like. Its processor is typically a conventional central processing unit, and may for example be a microprocessor in the INTEL x86 family or any other suitable processor known to those skilled in the art. Its computer storage memory includes a suitable combination of random access memory, read-only-memory, and disk storage memory used by host <b>14</b> to store and execute software programs adapting the host to function in manners exemplary of the present invention. Further host <b>14</b> typically hosts and executes application software useable by an end-user. Computer readable medium may be a CD-ROM, diskette, tape, ROM-Cartridge or the like. Network interface is any interface suitable to physically link device to network. The interface may, for example, be an Ethernet, ATM, ISDN interface or modem that may be used to pass data, directly or indirectly, from and to network <b>10</b>.

P-0048[0048] As well, each sub-network may include a connection manager <b>18</b> (hereinafter a 0-CMM <b>18</b>), operable to merge established multicast sessions that were previously established in a conventional manner, and track merged sessions. The architecture of 0-CMM <b>18</b> is substantially the same as that of hosts <b>14</b> and includes software or firmware adapting it to receive and dispatch multicast merge and disband messages, in manners exemplary of the present invention and to maintain merge information in manners exemplary of the invention. 0-CMM <b>18</b> may for example, be a commercially available server including a processor, suitable computer readable memory, and a network interface. 0-CMM <b>18</b> may alternatively be formed using a programmable router.

P-0049[0049] In the embodiment of FIG. 3, 0-CMMs <b>18</b> of various sub-networks are in communication with each other by way of the sub-networks <b>12</b> and routers <b>16</b> they are connected with. The multiple CMMs thus define a connection management system (CMS), which is effectively a logical overlayed network. As will become apparent, intercommunication of 0-CMMs <b>18</b> by way of a CMS ensures that a merging or disbanding of multicast groups initiated within one sub-network <b>12</b> is propagated to other related sub-networks <b>12</b>. There are at least three contemplated approaches to providing such a CMS, detailed below.

P-0050[0050] In any event, a 0-CMM <b>18</b> is provided for a plurality of hosts on network <b>10</b>. Preferably, a 0-CMM <b>18</b> is provided for each sub-network that supports group merging in manners exemplary of embodiment of the present invention. However, as illustrated a sub-network including a 0-CMM <b>18</b> may communicate with sub-networks that do not have such 0-CMMs (e.g. illustrated N<b>1</b> and N<b>3</b>). Each 0-CMM <b>18</b> at a sub-network is referred to herein as a oth level CMM (0-CMM). Each 0-CMM <b>18</b> is assigned to manage merge and disband requests for its sub-network and is thus authoritative over its sub-network. Software at each 0-CMM <b>18</b> causes the 0-CMM <b>18</b> to respond to MERGE and DISBAND messages (described below) received from hosts <b>14</b> in its sub-network <b>12</b>. Additionally, each 0-CMM <b>18</b> responds to MERGE and DISBAND requests received from other 0-CMMs <b>18</b> on the CMS. The 0-CMM <b>18</b>, in response, sends corresponding IGMP_Merge_Request or IGMP_Disband_Request messages (also described below) to edge routers in its sub-network.

P-0051[0051] Each 0-CMM <b>18</b> preferably maintains a data structure to keep track of the merged multicast groups in its sub-network. An exemplary data structure <b>20</b> called cmm_merge_table is depicted in FIG. 4. As illustrated, each row of the table shows the relationship of a group to other sub-groups with which it has merged.

P-0052[0052] In addition, each 0-CMM <b>18</b> preferably keeps track of multicast group memberships in another data structure. An exemplary data structure <b>22</b> in the form of a table, called a cmm_group_table is depicted in FIG. 5. This table keeps track of multicast memberships of individual local hosts by monitoring the normal IGMP membership report messages exchanged by hosts <b>14</b>.

P-0053[0053] Further, each 0-CMM <b>18</b> maintains a third data structure to keep track of the list of MERGE messages received from other CMMs and from hosts of the local sub-network. An example data structure <b>24</b> keeping track of such MERGE messages, in the form of table (called a merge_table) is illustrated in FIG. 6. As illustrated, table <b>24</b> merge_table maintains entries identifying the relationship between a sub-groups and other groups.

P-0054[0054] Additionally, software at each 0-CMM <b>18</b> causes execution of a process (referred to as a 0-CMM daemon which is typically residing in 0-CMM) that listens to all IGMP messages in the sub-network of a 0-CMM <b>18</b>. Whenever the 0-CMM <b>18</b> daemon receives an IGMP Membership Report, it will relay this message to the 0-CMM <b>18</b>. 0-CMM <b>18</b> uses this information to update its cmm_group_table (data structure <b>22</b>—FIG. 5) to maintain an awareness of group memberships of hosts <b>14</b> in its sub-network.

P-0055[0055] Conveniently, the network drivers of hosts <b>14</b> need not be modified to support proposed IGMP extension. Also, each 0-CMM <b>18</b> can impose policies on determining which host on its sub-network has the right to request a MERGE or a DISBAND operation. In this way, a 0-CMM <b>18</b> only needs to respond to messages from authorized computing devices, authorized to originate merge or disband messages. Authorization may be effected in a conventional manner, using for example, conventional authentication certificates.

P-0056[0056] Multicast routers <b>16</b> multicast received data to members of merged groups. In order to do this, routers <b>16</b> are informed of merged groups and their disbanding by 0-CMMs <b>18</b> (by IGMP-Merge-Request and IGMP_Disband_Request messages), as detailed below. Additionally, routers <b>16</b> maintain a data structure indicative of group mergers.

P-0057[0057] An exemplary data structure may be in the form of a table (referred to as router_merge_table). An example table <b>40</b> that may be maintained at router <b>16</b> is illustrated in FIG. 7. In the illustrated table, the “Merge Group Address” denotes a multicast group recognized by the multicast router maintaining table <b>40</b>. A “sub-group address” denotes the group that has successfully joined as a group member of the “Merge Group”; the “Merge Port” denotes the corresponding port used for this merge. Exemplified router_merge_table <b>40</b> of FIG. 7 has only two levels. In other words, if a sub-group X containing child sub-groups (i.e. x₁, x₂, .⊂X) merges with group Y, the address of each children sub-group (x₁, x₂. . . ) will be entered as a separate sub-group address entry in FIG. 7. As will be apparent, other data structures for various merge tables are also possible, having a unique relationship between the merge group and its subgroup.

P-0058[0058] Preferably, entries of router_merge_table <b>40</b> are maintained in a soft-state. That is, they are deleted automatically if they are not updated within a time-out period. This simplifies the maintenance of the router_merge_table <b>40</b>, as stale merge state information are automatically removed and hence leads to better utilization of the memory storage of router. Inactive groups and unexpected partial failure or misbehaving of routers are examples of possible causes for making the merge state information stale.

P-0059[0059] The router_merge_table <b>40</b> is used to duplicate data destined for a multicast group that has merged with another. Data within packets intended for a group that has been merged with another are replicated and dispatched to members of either groups serviced by the router, as described below.

P-0060[0060] Merge_tables <b>24</b> at 0-CMMs <b>18</b> are updated in response to requests received from associated 0-CMMs <b>18</b>. Thus, 0-CMMs <b>18</b> have the ability, and responsibility, to cause reconfiguration of routers <b>16</b> in order to merge multicast groups, and to disband merged groups.

P-0061[0061] In operation, at least some hosts <b>14</b> have joined multicasts in a conventional manner. For example, hosts <b>14</b> may join multicasts using the IGMP. A designated host <b>14</b> may initiates multicast group merging and disbanding by dispatching suitable MERGE and DISBAND messages. The host <b>14</b> initiating the multicast group merging or disbanding may, but need not be, a member of an existing multicast group. As noted, the MERGE and DISBAND messages are preferably authenticated to ensure only authorized computing devices initiate group merging or disbanding. In any event, the designated host <b>14</b> dispatches such messages to the 0-CMM <b>18</b> for its sub-network. This 0-CMM <b>18</b> exchanges MERGE and DISBAND messages with other CMMs. It also exchanges suitable messages with routers <b>16</b> connected to its sub-network in order to configure routers <b>16</b> to merge and disband multicast groups in manners exemplary of embodiments of the present invention. In the preferred embodiments, messages to merge and disband multicast groups exchanged between 0-CMMs <b>18</b> and routers <b>16</b> are formed as extension to IGMP messages.

P-0062[0062] An example MERGE message may take the form “1#subGroupIP#mergeGroupIP#mergeport#”, where “1” indicates this is a local MERGE request. An example DISBAND message may take the form “4#subGroupIP#mergeGroupIP#mergeport#”, where “4” indicates this is a local DISBAND request.

P-0063[0063] Two kinds of merge operations are possible: asymmetrical merge and symmetrical merge. Similarly, two types of disband operations are possible. When a group X has merged asymmetrically to another group Y (i.e. X→Y), IP multicast packets sent to group Y are also be received by group X. However, IP multicast packets sent to group X are received only by members of group X (this is schematically illustrated in FIG. 8). In this case group X is said a ‘child’ of group Y. Using the same example, packets sent to X or Y will be received by all members when X has merged to Y symmetrically (i.e. X⇄Y) (FIG. 9). A symmetrical merge can be accomplished in two asymmetrical merge operations, such as X→Y and Y→X.

P-0064[0064] Similar, an asymmetrical disband (X from Y) is denoted as X←Y and a symmetrical disband (X from Y) is denoted as X-Y.

P-0065[0065] Other more complex membership operations are possible. For example, cascading merge such as [(X→Y)→Z]→S, cascading disband such as [(X←Y)←Z]←S, and exclusion of a merged group from a membership, such as [(X→Y)→Z, X←Z] that enable X to receive from Y but not from Z and at the same time Y can receive from Z, are all possible.

P-0066[0066] Thus, complex multi-level group structures can be created. These group connection operations present powerful and convenient mechanism for manipulating relationship between users and groups for better sharing of information, retaining group identity and if desirable, retaining privacy (as in asymmetrical merge). In addition, these merging and disbanding operations have minimal impact on existing multicast trees and are independent of the protocol used for building multicast trees.

P-0067[0067] For example, by viewing an already merged group as a single group, an IGMP_Merge_Request message (detailed below) may be sent to another group (e.g. group Z) to register an interest to merge to another group (e.g., (X→Y)→Z). This merge (from the point of view of group Z) is seen as a single group merge request to group Z. If the merge request is successful, a complex group structure is created where group Z has group Y merged to it, and group Y in turn has group X merged to it. By extrapolating this, complex group structures could be created recursively.

P-0068[0068] Exemplary of embodiments of the present invention, six new IGMP message types are defined. Each of these types of messages may be exchanged between a CMM and a multicast router <b>16</b>. Example message types are referred to herein as the IGMP_Merge_Request; the IGMP_Merge_Posv_Reply; the IGMP_Merge_Negv_Reply; the IGMP_Disband_Request; the IGMP_Disband_Posv_Reply; and the IGMP_Disband_Negv_Reply messages.

P-0069[0069] The extended IGMP messages can be coded in any number of ways. For example they may be defined by defining a new message type and new code field for each of the extended IGMP messages, as shown in FIGS. 11A to <b>11</b>F. Alternatively, messages could be defined using the unassigned ‘code field’ of IGMPv1 membership report message to represent the new extended messages.

P-0070[0070] In the described embodiment, example extended IGMP message formats may be defined according to the general IGMP packet format (FIG. 10) for group merge and disband functions. FIG. 10 illustrated the general IGMP version 2 (IGMPv2) packet format. The IGMPv2 packet format is used as the basis for extension because it is the current standard for IGMP. (IGMPv3 is still under draft status, and possible messages are further described below.) As illustrated in FIG. 10, the 8-bit “message type” field indicates the message type of a particular IGMP protocol. The next 8-bit “code field” indicates the code type that is used corresponding to a particular message type. The next 16-bit is a checksum for the 8-byte IGMP message. The 32-bit “group address” field contains the multicast address of the group concerned. In the existing IGMP protocols not all message types are defined. Under the existing IGMP protocol unidentified IGMP message types will be ignored. Hence, the suggested extensions to the existing IGMP protocol will be ignored by the conventional multicast routers but will be processed by multicast routers <b>16</b>, exemplary of embodiments of the present invention.

P-0071[0071] A proposed IGMP_Merge_Request message <b>50</b> format is shown in FIG. 11A IGMP_Merge_Request message <b>50</b> is used to request merges and is dispatched by host <b>14</b>. The IGMP_Merge_Request message <b>50</b> has a message type of 0×31. It does not make use of the code field. The function of checksum remains the same as for all standard IGMP messages. The 32-bit group address is the class D address (as defined in RFC 1112) to be merged to. The next 16-bits contain the merge port field. The merge-port allows a receiver in group X to differentiate multicast packets sent directly to multicast group X from packets that are sent to multicast group Y (assuming X→Y).

P-0072[0072] The IGMP_Merge_Request message <b>50</b> is a response of a 0-CMM <b>18</b> to the MERGE message, and is intended partly as a reminder to all members of group X within a sub-network about the merge operation of group X to group Y. This message is encapsulate in an IP packet, with the multicast address of X as the destination IP address The IP packet will be received by the modified multicast edge router <b>16</b>, and processed as a merge request for group X (indicated by the destination IP address of this IP datagram) to merge with group Y as (indicated by ‘the group address to be merged to’ of the encapsulated IGMP_Merge Request message).

P-0073[0073] An exemplary format of a IGMP_Merge_Posv_Reply message <b>52</b> is shown in FIG. 11B. An IGMP_Merge_Posv_Reply message <b>52</b> is used by a multicast router <b>16</b> to provide a positive merge. That is, a modified multicast router <b>16</b> sends this message as a response to the requester indicating the successful operation of a previously received IGMP_Merge_Request message <b>50</b> (FIG. 11A). It is defined by the combination of two fields in the IGMP packet. The message type of 0×32 indicates this is an IGMP_Merge_Posv_Reply message type, and the code field of 0×1 indicates this is a positive reply.

P-0074[0074] An additional 32-bit multicast address field is preferably attached behind the merge_port field (FIG. 11B). This field stores the multicast address of the sub-group (i.e. group X, for X→Y) that has issued the merge request. This serves as a checking mechanism because a 0-CMM <b>18</b> may send out several IGMP_Merge_Request messages <b>50</b> at the same time. This sub-group multicast address indicates a successful sub-group merge operation.

P-0075[0075] The format of a IGMP_Merge_Negv_Reply message <b>54</b> is shown in FIG. 11C. A modified multicast router <b>16</b> sends this message type as a response to signal a failure in processing a IGMP_Merge_Request message <b>50</b>. This message is identified with type field value of 0×32 similar to that shown in FIG. 11B, except that the code field has a value of 0×2 to indicate a failure in the merge operation.

P-0076[0076] An example format of an IGMP_Disband_Request message <b>56</b> is shown in FIG. 11D. It has a message type of 0×33 and does not make use of the code field. The function of checksum remains the same as for standard IGMP messages. The 32-bit group address is the class D address to disband from. The next 16-bit contains the disband-port field.

P-0077[0077] The IGMP_Disband_Request message <b>56</b> is a response of a 0-CMM <b>18</b> to a DISBAND request from a representative member of group X to leave group Y. This request is encapsulated in an IP packet to inform all members of group X about the disbanding from group Y. Thus, the multicast address of X is stored in the destination address field of the IP packet header. The IGMP_Disband_Request message <b>56</b> will also be received and acted upon by the modified multicast router <b>16</b>.

P-0078[0078] The disband_port field allows the modified multicast router to check whether this disband request is valid. If the specified disband_port field does not match one of the existing merge status managed by the multicast router, it is considered as an invalid disband request.

P-0079[0079] Routers <b>16</b> send IGMP_Disband_Posv_Reply messages <b>58</b> as a response to the successful previous disband request. The format of this message type is shown in FIG. 11E. It is defined by the combination of two fields in the IGMP packet. The message type of 0×34 indicates a reply message, and the code field of 0×1 indicates this is a positive reply. An additional 32-bit multicast address field is attached behind the disband_port field. This stores the multicast address of the sub group (e.g X) that has issued the disband request. This serves as a checking mechanism because a 0-CMM <b>18</b> may send out several IGMP_Disband_Request messages at the same time. This sub group multicast address identifies a successful disband operation for a sub group.

P-0080[0080] The modified multicast router sends a IGMP_Disband Negv_Reply message <b>60</b> to signal a failure in processing a IGMP_Disband_request message <b>56</b> (FIG. 11D). The message format is shown in FIG. 11F. This message type is similar to that shown in FIG. 11E, except that the code field is specified to be 0×2 to indicate a failure in the disband operation.

P-0081[0081] In IGMP v2, the existing IGMP message type 0×12 (for denoting IGMP Version 1 Membership Report) does not make use of the next 8-bit “code field”. Thus, alternatively, the six new IGMP Merge and disband message could be completely specified by this un-assigned 8-bit “code field” of the message type of 0×12 with different code values. This is illustrated in FIG. 12.

P-0082[0082] Routers <b>16</b> that are connected to the same sub-network as a 0-CMM <b>18</b> will act upon an IGMP_Merge_Request message <b>50</b> received from a 0-CMM <b>18</b> for a merge of group X to group Y. The existing multicast routing protocols ensure only one multicast router is responsible for transmitting multicast packets for a particular group (e.g. X) in a sub-network. As such, only this router will merge messages as described herein. Remaining routers receiving the merge messages will simply ignore the message.

P-0083[0083] This particular router, upon receiving the IGMP_Merge_Request message <b>50</b>, processes the request and then generates an appropriate reply message. If the request is successful, the merge status is also updated in the router.

P-0084[0084] Now, a host in a sub-network can dispatch conventional IGMP membership reports to join a multicast group and repeat such requests periodically to remain in the group as stipulated in standard IGMP. Additionally, some hosts may dispatch MERGE and DISBAND messages with a TTL (Time To Live) of 1 to 0-CMM <b>18</b> to have an identified multicast group join or leave another group. A TTL of 1 will limit MERGE and DISBAND messages to be sent within a sub-network; they will not be forwarded beyond the sub-network.

P-0085[0085] When a 0-CMM <b>18</b> receives a MERGE message, it performs steps S<b>1300</b> illustrated in FIG. 13. As illustrated, upon receipt of a MERGE message in step S<b>1302</b> 0-CMM <b>18</b> initially determines if the MERGE message originates with a host <b>14</b>, or from another 0-CMM <b>18</b> (i.e. the CMS) in step S<b>1304</b>. If the MERGE message originates from a host <b>14</b> (i.e. it does not originates from another CMM), it is forwarded to other 0-CMMs <b>18</b> on network <b>10</b> in step S<b>1306</b>, by way of the CMS. Next, the 0-CMM <b>18</b> determines if there are members of group X on the sub-network of the 0-CMM <b>18</b> in step S<b>1308</b>. If not, the 0-CMM <b>18</b> simply keeps track of the merge status in its merge_table data structure <b>24</b> (FIG. 6) for messages from another CMM (i.e. the CMS), as determined in step S<b>1318</b>, in step S<b>1320</b>, or returns an error message to the host originating the request (step S<b>1322</b>). If a member of group X is on the sub-network of the CMM <b>18</b>, the CMM <b>18</b> inserts group X as a sub-group of group Y in its cmm-merge-table data structure <b>20</b> (FIG. 4) in step S<b>1314</b>. If no members of group Y are in the sub-network, 0-CMM <b>18</b> acts as a proxy for group Y, in step S<b>1312</b> as detailed below. As well, an IGMP_Merge_Request message <b>50</b> is dispatched to any neighbouring routers <b>16</b> in step S<b>1316</b>.

P-0086[0086] Steps S<b>1400</b> performed by a multicast router <b>16</b> upon receipt of IGMP_Merge_Request dispatched in step S<b>1316</b> are illustrated in FIG. 14. As illustrated upon receipt of the IGMP_Merge_Request message for merge X→Y in step S<b>1402</b>, an exemplary router <b>16</b> checks whether group Y has an entry in its router_merge_table <b>40</b> (FIG. 7) in step S<b>1404</b>. If so, group X is inserted into the corresponding entry in step S<b>1408</b>. In addition, the merge_port from the packet is stored. If group Y does not have an entry in the router_merge_table <b>40</b>, a new entry for group Y is created in step S<b>1406</b>.

P-0087[0087] If group X has sub-groups previously merged into it (i.e. X is a complex group) as determined in step S<b>1410</b>, the corresponding table entries for the sub groups (with their corresponding entries for merge port) of X are copied over to group Y's entry in step S<b>1412</b>. This caters to complex group structures such as those resulting from cascading merging or disbanding of groups. When a group merges to another group as a sub-group (e.g., X→Y), if any of his child sub group address (x₁, x₂, . . . ,x_i.)is same as the multicast address of the merge group (Y) address entry, the child sub-group address (x_i) will not be copied to the router merge table <b>40</b> as a sub-group address of Y. This prevents creation of an entry for a group merging to its own group (i.e.,A→A). Additionally, it prevents a group from receiving duplicated copies of a packet. An example is when a symmetrical merge occurs between two groups, says X→Y and then Y→X. In this case of X→Y, the merge group address of Y in the router_merge_table <b>40</b> (FIG. 7) will have only X as a sub group and subsequently for Y→X, the merge group address of X in the router merge_table <b>40</b> will have only Y as a sub group despite X being a sub-group of Y as a result of the preceding X→Y.

P-0088[0088] If the merge operation is successful as determined in step S<b>1414</b>, an IGMP_Merge_Posv_Reply message <b>52</b> is sent to the originator of the IGMP_Merge_Request message <b>50</b> in step S<b>1416</b>. Otherwise, an IGMP_Merge_Negv_Reply message <b>54</b> is returned (not illustrated).

P-0089[0089] If the merger is successful, group X preferably becomes part of group Y while still retaining its original properties. This means that members of group X receive all messages sent to group Y, but group Y does not receive messages sent to group X. Group X maintains its own privacy though it has been merged with group Y. (see FIG. 8)

P-0090[0090] Steps S<b>1500</b> performed by a 0-CMM <b>18</b> in response to receiving an incoming IGMP_Merge_Posv_Reply message <b>52</b> are illustrated in FIG. 15. As illustrated, an IGMP_Merge_Posv_Reply message is received in step S<b>1502</b>. If the groups X or Y are not found in the cmm_group table data structure <b>22</b> (FIG. 5) at 0-CMM <b>18</b>, as determined in step S<b>1504</b>, the message is ignored in step S<b>1518</b>. If only group X is found in the cmm_merge_table data structure <b>20</b> (FIG. 4), as determined in step S<b>1506</b> an entry for group Y is created in the cmm_merge_table data structure <b>20</b> in step S<b>1508</b>. Once group Y has an entry in the cmm_group table data structure, group X is inserted and its merge port is inserted as a sub group of group Y in step S<b>1510</b>. If group X has any sub-groups, as determine in step S<b>1512</b>, these are copied into group Y in step S<b>1514</b>. A positive reply is sent to the host <b>14</b> originating the MERGE message. Steps S<b>1500</b> are performed to ensure 0-CMM <b>18</b> maintains the same knowledge of merge groups as the responsible router <b>16</b>. The 0-CMM <b>18</b> returns a negative reply for the MERGE message if it receives an IGMP_Merge_Negv_Reply message <b>54</b> from the router <b>16</b>.

P-0091[0091] A designated host sends MERGE messages periodically to the 0-CMM <b>18</b>. This action refreshes the ‘soft-state’ merge status maintained in the cmm_merge_table data structure <b>20</b> (FIG. 4), as entries in this table are subjected to a “time out” upon which entries are considered stale and automatically deleted. To eliminate the designated host as a potential single point of failure, a few hosts can actually be designated for sending the same MERGE requests to provide robustness. This can be achieved without the need for any changes to the protocols for the case of a single designated host <b>14</b>. Instead, an application may prepare and dispatch the relevant MERGE/DISBAND messages.

P-0092[0092] As noted, in order to have the merge and disband function across multiple sub-networks, MERGE and DISBAND messages are transmitted from a particular 0-CMM <b>18</b> receiving such messages from a host to other 0-CMMs <b>18</b> on the rest of the CMS in step S<b>1306</b> (FIG. 13). Of course, not all MERGE and DISBAND messages need be transmitted to the rest of CMS. A 0-CMM <b>18</b> that receives these messages from the hosts may limit the merge or disband effect to be within the sub-network. This is achieved by not propagating these messages using the CMS.

P-0093[0093] Once groups are merged, the 0-CMMs <b>18</b> preferably additionally monitor new members to a merged group. This is illustrated in FIG. 16. As noted, each 0-CMM <b>18</b> monitors IGMP messages originated by hosts in its sub-network. Thus, a 0-CMM <b>18</b> may monitor if a host joins group X in a sub-network where previously there are no members of X in it. Specifically, when the 0-CMM receives an IGMP Membership Report in step S<b>1602</b> from any host for any group, it first checks whether that group is found in its cmm_group_table data structure <b>22</b> in step S<b>1610</b>. If it is not found, an entry for that group is added in the cmm_group_table <b>22</b> in step S<b>1604</b>. Next, the 0-CMM checks whether that group is merged to any group by referring to the cmm_merge-table data structure <b>20</b> in step S<b>1612</b>. If it is a sub group of another group (e.g. group Y), the 0-CMM will check whether there is a need to be a proxy member for group Y in step S<b>1606</b>. If so, the 0-CMM become a proxy for group Y by joining group Y in a conventional fashion in step S<b>1608</b>. Once it is confirmed that group Y is in this sub-network, the 0-CMM sends an IGMP_Merge_Request message <b>50</b> to the modified router <b>16</b> in step S<b>1614</b>. Such an arrangement makes the merge operation in this situation seamless and it does not require the first new member of group X in a sub-network to explicitly request for merge operation.

P-0094[0094] Once two multicast groups X and Y are merged, the necessary steps for duplicating packets at a router <b>16</b> during the merge operation are detailed in FIG. 17. Upon receipt of a new UDP packet a comparison is made to assess whether the packet is for a multicast in a merged group. If so, a “merged” packet is created. If not the multicast packet is treated as a conventional multicast packet and is handled in the usual manner as for other normal multicast packets.

P-0095[0095] As illustrated in FIG. 17, only multicast packets with addresses matching with merge group address entries in the router_merge_table <b>40</b> (FIG. 7) have their contents duplicated for the corresponding sub-groups. Each of these duplicated packets, known as ‘merge packet’, will have the corresponding destination multicast address and port modified according to the sub-group address entry in the router_merge_table <b>40</b>. In other words, this is to send the packet to the multicast address and the merge_port that the sub-group hosts are listening to.

P-0096[0096] Each “merged” packet has a TTL value of two if the value of the arriving multicast packet has a TTL greater than two. This restricts the “merge” effect of packets to be one hop away from the modified multicast router. If the multicast packet has a TTL of one upon arrival, it is meant to be confined within the sub-network of the router interface where the packet first arrived. Hence the corresponding “merged” packet should also be tagged with a TTL of one, as ‘own-net’. This ensures the merged packet is sent back to that same sub-network and will not be forwarded to other sub-networks.

P-0097[0097] As well, the IP header checksum must be recalculated when the destination multicast address is modified. In addition, the UDP header checksum must also be recalculated when the destination multicast address and port are modified. Failure to recalculate these two checksums may result in the “merged” packets being rejected by routers (if IP header checksum is wrong) or by the corresponding application programs (if UDP header checksum is wrong).

P-0098[0098] In conventional multicast routers, multicast packets will not be routed back to the incoming interface. This is to prevent loops being created if packets are sent back on the incoming interface. Multicast routers <b>16</b>, however will route multicast packets back to the incoming interface to allow full merger within a sub-network in the following scenario. A situation of X→Y may arise where some members of sub group X and group Y are both present in the same sub-network. If a host <b>14</b> in this sub-network sends packets to group Y, members of X in this sub-network should also receive the packets by virtue of the group merge operation. However the “merged” packets meant for group X will not be routed back to the same sub-network if the multicast router behaves in the original manner. Hence, the multicast packet forwarding decision must be modified to allow only “merged” packets to be sent back on the incoming interface. In addition, “merged” packets that leave the modified multicast router will have their TTL set to one, thus loops will not be created even with the above modification.

P-0099[0099] Merging groups may be better appreciated with reference to FIG. 18-20. In the example illustrated, in FIG. 18 all host members of group X (x<b>1</b>, x<b>2</b> and x<b>3</b>) are attached to the same sub-network (N<b>5</b>). Exemplary of the present invention, only one member of group X needs to send a MERGE message periodically. This is indicated as step <b>1</b> in FIG. 18. The request is not dispatched to group Y, instead it is dispatched to the 0-CMM <b>18</b> that is in sub-network N<b>5</b>. The 0-CMM <b>18</b> receives this request and sends a modified IGMP message (an IGMP_Merge_Request packet) (depicted as step <b>2</b> in FIG. 18). The modified router <b>16</b> (located in N<b>5</b>, can be router <b>16</b> R<b>3</b>,<b>5</b> or R<b>4</b>,<b>5</b> in this example) receives this packet and keeps the merge status at the IP level. Subsequent packets for group Y that arrive in sub-network N<b>5</b> are duplicated and sent to members of group X in sub-network N<b>5</b> by router R<b>4</b>,<b>5</b>. The modified multicast router is responsible for duplicating these packets to group X.

P-0100[0100] At the router level, this connection between group X and group Y does not require any changes or extensions to the existing multicast tree. The single IGMP Membership Report is interpreted by the existing or future multicast routing protocol as a single host request for membership. This form of arrangement makes this set of IGMP extensions simple and able to cooperate with existing and future multicast routing protocols.

P-0101[0101] If members of two merging groups X and Y do not exist in the same sub-network, packets meant for one group can not be duplicated at an associated router to reach members of the other group serviced by that router. To resolve this, the 0-CMM <b>18</b> for the sub-network that only has members of one group act as a proxy member to request to join to other group (FIG. 13, step S<b>1312</b>). With this request, a conventional multicast routing protocol is leveraged upon and it is seen as a simple request of a host that wants to join group Y. Membership in the group may be established by the 0-CMM <b>18</b> using a conventional IGMP Membership Report as specified in IGMP versions 1 and 2.

P-0102[0102] This is more particularly illustrated with reference to the example of FIG. 19. In the illustrated example in FIG. 18, a member (y<b>4</b>) of group Y already exists in sub-network N<b>5</b> when x<b>3</b> sends a MERGE message. As such, prior to the transmission of the MERGE message as exemplified in FIG. 19, packets for group Y were already sent to sub-network N<b>5</b>. If no members of Y existed in sub-network N<b>5</b> prior to the transmission of MERGE message, connection manager 0-CMM <b>18</b> of sub-network N<b>5</b> may act as a proxy member for group Y in response to the MERGE message of x<b>3</b>. As illustrated in FIG. 19, a 0-CMM <b>18</b> will send a conventional IGMP Membership Report as if he was to join group Y (in step <b>2</b>). This operation, from the perspective of the multicast router, is seen as a normal operation of a host requesting to join a new group. It effectively links the local default router to the multicast tree of Y. The 0-CMM then sends an IGMP_Merge_Request message <b>50</b> to the modified multicast router (step <b>3</b> in FIG. 19). This is similar to step <b>2</b> of FIG. 18.

P-0103[0103] In the examples described in FIGS. 18 and 19, the merging of groups only affects one particular sub-network. If, however, members of the joining group X are distributed in different sub-networks as shown in FIG. 20, the 0-CMM <b>18</b> (in sub-network N<b>5</b>) will need to propagate the MERGE message to other 0-CMMs on other sub-networks (as indicated in step <b>4</b>). In fact, this is the preferably default action of all CMMs in response to a MERGE message (see FIG. 13, step S<b>1306</b>), as a particular CMM typically has no knowledge of the distribution of members of any group. As detailed below, connection managers found in the various sub-networks are in-communication with each other. Thus, a MERGE message from one connection manager can be propagated to other connection managers. When a connection manager receives this MERGE message, it can behave in one of two alternative ways:

P-0104[0104] If there is a member of group X in the corresponding sub-network (as in sub-network N<b>2</b> in FIG. 20): the connection manager will act as a proxy for Y in this sub-network by sending an IGMP Membership Report packet to join group Y if there is no member of Y in the sub-network, otherwise it sends an IGMP_Merge_Request message <b>50</b> to the default modified multicast router (either R<b>1</b>,<b>2</b> or R<b>2</b>,<b>4</b>). The router in sub-network N<b>2</b> will maintain the merge status of group X joining group Y.

P-0105[0105] If there is no member of group X in the corresponding sub-network (as in sub-network N<b>4</b> in FIG. 20): the connection manager will maintain this merge status in its merge-table <b>24</b> (indicated as step <b>6</b><i>a</i>). Subsequently, when a host in sub-network N<b>4</b> wants to join group X (and hence to join group Y), the 0-CMM <b>18</b> is responsible for sending the corresponding IGMP_Merge_Request message <b>50</b>. The receipt of the previous MERGE message (step <b>6</b><i>a</i>) will eliminate the need for the 0-CMM <b>18</b> from sending a new MERGE message to other CMMs through the CMS connection network.

P-0106[0106] Conveniently, only one MERGE message is sent periodically from a designated member of group X (or a designated non-member of the group) to request for a group merge operation. In addition, flooding of IGMP packets in this sub-network is reduced as the connection manager 0-CMM sends only one IGMP_Merge_Request message <b>50</b> on behalf of all members of group X. Moreover, only one immediate multicast router <b>16</b> (in this case R<b>3</b>,<b>5</b> or R<b>4</b>,<b>5</b> in N<b>5</b> FIG. 20) needs to be modified to interpret the new IGMP message type. Therefore no changes are required for other intermediate routers between the source of the multicast tree to the members in this sub-network. In addition, this merge operation does not need any changes to the existing multicast routing protocol used for construction and maintenance of the conventional multicast tree.

P-0107[0107] Disbanding merged groups is effected in much the same way as merging of the groups. Initially, a designated host <b>14</b> wishing to disband merged groups (e.g. group X from group Y) sends a suitable DISBAND message to the 0-CMM <b>18</b> on its sub-network. Again, this message may be authenticated as originating from a trusted host in a conventional manner, if required. Steps S<b>2100</b> performed by the 0-CMM are illustrated in FIG. 21. So, upon receipt of the DISBAND message in step S<b>2102</b>, the 0-CMM <b>18</b> assesses if the DISBAND message originates with a host <b>14</b> or from the CMS in step S<b>2104</b>. If it originates with a host <b>14</b>, it is forwarded to other CMMs by way of the CMS in step S<b>2106</b>. If the group Y is not found in the cmm_merge_table data structure <b>20</b> (FIG. 4) of CMM <b>18</b> as determined in step S<b>2108</b>, or group X is not listed as a sub-group of group Y in the cmm_merge_table as determined in step S<b>2110</b>, the 0-CMM <b>18</b> deletes group X as a sub-group of group Y from the merge table in step S<b>2120</b>, for messages from the CMS. Alternatively, it returns an error message in step S<b>2122</b>. If the 0-CMM <b>18</b> is acting as a proxy for group Y as determined in step S<b>2112</b> it ceases to act as a proxy in step S<b>2114</b>. It also deletes group X as a sub-group of Y in its cmm_merge_table <b>20</b> in step S<b>2116</b>, and IGMP_Disband_Request message <b>56</b> to the neighbouring multicast routers <b>16</b> in step S<b>2118</b> to request for disband of group X from group Y.

P-0108[0108] Steps S<b>2200</b> performed by a router <b>16</b> upon receipt of a IGMP_Disband_Request message <b>56</b> are illustrated in FIG. 22. When an IGMP_Disband_Request message <b>56</b> request for a break in connection between group X and group Y is received in step S<b>2202</b>, the router <b>16</b> determines if group Y is in its router_merge_table <b>40</b> in step S<b>2204</b> or if group X is a sub-group in group Y in step S<b>2206</b>. If neither is true, it returns a IGMP_Disband_Negv_Reply message <b>60</b> in step S<b>2220</b>. Otherwise, group X is removed as a sub-group of group Y in step S<b>2208</b>. As well, any sub-groups of group X are removed from group Y in steps S<b>2210</b>-S<b>2214</b>. Group Y is removed from the router_merge_table <b>40</b> in step S<b>2216</b>. A IGMP_Disband_Posv_Reply message <b>58</b> is returned in step S<b>2218</b>.

P-0109[0109] The logic of 0-CMM <b>18</b> for handling an incoming IGMP_Disband_Posv_Reply message <b>58</b> is summarized in steps S<b>2300</b> in FIG. 23. Steps will not be further detailed herein. The logic is similar to that of the multicast router receiving an IGMP_Disband_Request message <b>56</b>, as illustrated in FIG. 23. The purpose is to ensure 0-CMM <b>18</b> maintains the same knowledge of merge groups as the router. Similarly, the 0-CMM <b>18</b> returns a negative reply for the MERGE message if it receives an IGMP_Merge_Negv_Reply message from the router (not shown).

P-0110[0110] As noted, the multiple CMMs <b>18</b> communicate with each other to ensure that MERGE and DISBAND messages are distributed to CMMs <b>18</b> at various interconnected sub-networks <b>12</b>. One computing device acting as a 0-CMM <b>18</b> dispatches messages to other computing devices acting as 0-CMMs <b>18</b>, directly or indirectly, by way of yet other computing device (i.e. making up the CMS). The number of sub-networks <b>16</b> may be vast, and hence the organization of inter-communication between 0-CMMs may pose some difficulties. As such, three possible organizations of CMMs facilitating CMM inter-communication are suggested.

P-0111[0111] In a first arrangement illustrated in FIG. 24, computing devices including 0-CMMs <b>18</b> are arranged hierarchically. That is, CMMs are arranged in a tree structure. In this tree-like structure, the CMMs are denoted as i-CMM, where i=0, 1, 2, . . . , N. The CMMs at the leaf nodes of the trees are 0-th level CMMs (0-CMMs <b>18</b>). The next level tree nodes, one level higher than the 0-CMM <b>18</b>, are in turn named as 1-CMMs. Extrapolating this design, the hierarchical setup consists of the interconnection of CMMs, where there will be i-CMM for i number of levels in the tree.

P-0112[0112] Higher level CMMs (i-CMM (where i>0)) play a significantly different role compared to the 0-CMM <b>18</b> in this approach. The key purpose of i-CMM is to set up a hierarchical information base of the group membership. i-CMM is authoritative over several 0-CMMs <b>18</b> it monitors. An i-CMM can have several (i−1)-CMMs connected to it as children but only one (i+1)-CMM connected to as a parent

P-0113[0113] The i-CMMs transmit MERGE and DISBAND messages to other CMMs in two possible ways. First, if a message is received from a (i−1)-CMM, the i-CMM retransmits this message to its other children (i−1)-CMMs and parent (i+1)-CMM. Second, if a message is received from the parent (i+1)-CMM, the i-CMM retransmits this message to all its children (i−1)-CMMs. Typically, a MERGE or DISBAND message will propagate from 0-CMM <b>18</b> all the way to the root N-CMM, and then be retransmitted to the rest of CMMs in the CMS tree.

P-0114[0114] An acknowledgement mechanism can be put in place to ensure that the transfer of MERGE and DISBAND messages between CMS' is reliable. This can be achieved by having the recipient (e.g. 1-CMM) of a message (e.g. a MERGE message) acknowledges to the sender (e.g. 0-CMM <b>18</b>) the receipt of that request. If the sender fails to receive any acknowledgement within a time out period, it will attempt to re-send the message again.

P-0115[0115] In addition, the i-CMMs interacts with (i+1)-CMMs and (i−1)-CMMs to provide a network-wide awareness of the distribution of hosts and their corresponding multicast memberships in the CMS. This is achieved by having the 0-CMM <b>18</b> periodically update the CMM one level higher (i.e. 1-CMM) about the group subscription in its sub-network. The 1-CMM, in turn, updates this group information to 2-CMM and so on and so forth. This knowledge is used to determine the list of multicast groups present in an i-th domain. In addition, information about the multicast groups are aggregated for CMMs found in the higher levels. This means the 0-CMMs <b>18</b> keep the detailed information of the IP addresses of hosts (that have subscribed to the corresponding multicast addresses), while the i-CMMs maintain the list of multicast groups less the details of host information. In this way, an i-CMM can be more efficient in targeting a MERGE or DISBAND message be repeated to 0-CMMs <b>18</b> where related hosts for these group operations could be found. Specifically, i-CMMs can filter MERGE or DISBAND messages so that only those destined for 0-CMMs under them are passed on to lower level i-CMMs.

P-0116[0116] In all, the hierarchical CMS is responsible for ensuring that a merge or disband request is complete for a particular group.

P-0117[0117] An alternate arrangement of CMMs is illustrated in FIG. 25. In this arrangement, the 0-CMMs <b>18</b> interact with each other through a single multicast channel. As illustrated, an example single message sent from 0-CMM 11.4.2 to the multicast address a.b.c.d is received by the other 0-CMMs <b>18</b> (who are subscribed to the same a.b.c.d multicast address). This method assumes that all 0-CMMs are connected through multicast-enabled routers. However, for 0-CMMs connected to non multicast-enabled routers, IP tunneling can be used to bridge these 0-CMMs <b>18</b> to the multicast channel.

P-0118[0118] In this arrangement, as exemplified in FIG. 25, the 0-CMMs <b>18</b> transmit MERGE and DISBAND messages received from end hosts to the common multicast channel. When a 0-CMM receives a MERGE or DISBAND message from the multicast channel, it responds by sending the corresponding IGMP_Merge_Request or IGMP_Disband_Request messages <b>50</b>, <b>56</b> to the neighbouring modified multicast router <b>16</b>. Through this simple method, a merge or disband request from one sub-network can be transmitted to the rest of the CMS. The reliability of this type of CMS depends on the ability of the underlying network mechanism to support a reliable multicast.

P-0119[0119] A third alternate arrangement of CMMs is illustrated in FIG. 26. This is a hybrid approach of the hierarchical tree-like setup and the single multicast channel set-up. As before, each sub-network will have one 0-CMM <b>18</b>. These 0-CMMs <b>18</b> are further grouped into regional 0-level subgroups each consists of several 0-CMMs <b>18</b>. The members of each 0-level regional subgroup are connected through a level-0 multicast channel. Each level-0 regional subgroup of 0-CMMs is represented by a higher level CMM, in this example, a 1-CMM. As in the case of 0-CMMs, these 1-CMMs are grouped into subgroups each with a level-1 multicast channel connecting all their members. This process can be repeated until the root level N. For practical reason, N is preferably kept small.

P-0120[0120] The 0-CMMs are members of multicast address a.b.c.d port X. This multicast address-port pair (termed level-0 channel) is used for communication between 0-CMMs <b>18</b> and a 1-CMM in neighbouring network. The scope of the neighbouring network can be limited. For example, if the limit is chosen to be 5 hops, a 1-CMM will listen only to multicast messages from 0-CMMs <b>18</b> found within this limit of 5 hops. Using this approach, there will be numerous 1-CMMs listening to 0-CMMs <b>18</b> within the scope of 5 hops.

P-0121[0121] The various 1-CMMs, in turn, will subscribe to multicast address a.b.c.d port Y (termed level-1 channel) for interaction among the 1-CMMs. A typical example is shown in FIG. 26, where a MERGE message is sent from 0-CMM 11.4.2 and is received by 1-CMM 11 from level-0 channel. 1-CMM 11, in turn, will transmit this same message to multicast address a.b.c.d port Y. The various 1-CMMs listening to the level-1 channel will retransmit it to the level-0 channels that they are attached to. Through this method, a merge or disband request from one sub-network can be transmitted to the rest of the CMS. If the MERGE message is received from a 0-CMM, the 1-CMM will retransmit it to the level-1 channel it is attached to.

P-0122[0122] The reliability of transmissions in this CMS can be assured as follow: Using the two-level CMS example as depicted in FIG. 26, the 1-CMM may maintain a list of 0-CMMs found in the same level-0 channel in a data structure called 0-CMM-table. In addition, it may maintains a list of 1-CMMs found in the same level-1 channel in a data structure called 1-CMM-table. The 1-CMM listens in level-0 channel for acknowledgements from all the other 0-CMMs upon their receipts of a MERGE or DISBAND message. If a 0-CMM fails to respond, 1-CMM will attempt to resend the same message. If the particular 0-CMM does not respond after the kth resending attempts (to be determined during implementation), 1-CMM will remove the corresponding entry from 0-CMM_table. On the other hand, when a new 0-CMM enters the same level-0 channel, the 1-CMM creates a new entry in the 0-CMM_table and will retransmit MERGE or DISBAND message to that 0-CMM.

P-0123[0123] Likewise, a 1-CMM also listens in on the level-1 channel for acknowledgement from members of 1 -CMMs for a MERGE or DISBAND message relayed to them (by this 1-CMM, e.g. 1-CMM <b>11</b> in FIG. 26). If a 1-CMM member fails to respond, this 1-CMM will attempt to resend the same message. If the particular 1-CMM does not respond after its kth resending attempts (to be determined during implementation), this 1-CMM will remove the corresponding entry from 1-CMM-table. Essentially, the reliability of messaging with the CMS is ensured by the retransmission mechanism of the parent CMM of level-i channel (e.g. 1-CMM <b>5</b>, <b>11</b>, 8 for level-0 channels and 1-CMM <b>11</b> for level-1 channel in FIG. 25).

P-0124[0124] As will be appreciated, regardless of which approach of the suggested arrangements of CMMs is used for constructing CMS, the 0-CMMs found in these three approaches play the same role.

P-0125[0125] In the above described embodiments, IGMPv1 or IGMPv2 is used to allow merging and disbanding of multicast groups. A person of ordinary skill will readily appreciate that the invention may be suitably adapted for use with other protocols. For example, the invention may be used with IGMPv3.

P-0126[0126] IGMPv3 adds support for ‘source-filtering’. This means a host can specify from which source it would like to receive packets from, or it can specify from all but some specific addresses to receive packets from. A typical IGMPv3 packet contains a ‘source-list’ from which to receive packets from or to exclude from receiving

P-0127[0127] To leverage the additional capability of ‘source-filtering’ provided by IGMPv3, methods exemplary of this invention can be extended to provide support for IGMPv3 and of ‘source-filtering’ between groups. Steps performed at CMMs and routers as detailed above, however, do not require significant modification.

P-0128[0128] Using ‘source-filtering’ between groups, the sub group X can specify it only wants to receive packets sent to group Y from a list of sources in addition to a merge between two groups. This is achieved by adding additional options to the code field in the packet, an additional 16 bit field for specification of the number of sources, and N source addresses for N specified sources. This is described in the following sub sections.

P-0129[0129]FIG. 27A illustrates a modified IGMPv3 Merge-Request message type. The code field of 0×3 indicates this is a merge request with a list of source addresses for inclusion. As such, if group X requests to listen to multicast packets sent to group Y from this list of source addresses. An additional 16-bit field is added for specification of the number of sources. Following this, N records of 32-bit unicast source addresses are specified for the N sources from which multicast packets are to be received.

P-0130[0130]FIG. 27B illustrates a modified IGMPv3 Merge_Posv_Reply message type. The code field of 0×4 indicates this is a successful merge request with a list of source addresses for inclusion. Similar to FIG. 27A, a 16-bit field is used to specify the number of resources, and N records of 32-bit unicast source addresses are specified for inclusion.

P-0131[0131]FIG. 27C illustrates a modified IGMPv3 Merge_Negv_Reply message type. The code field of 0×5 indicates this is a failure in processing the merge request with a list of source addressed for inclusion. The rest of the fields are similar to those illustrated in FIG. 27B.

P-0132[0132] For disband requests, the packet format (not shown) is similar to that for the merge requests. The code fields are the same as those used in merge requests and replies. The message type of 0×33 indicates it is an IGMPv3 Disband-Request and message type of 0×34 indicates it is an IGMPv3 Disband_Posv_Reply or Disband_Negv_Reply message.

P-0133[0133]FIG. 27D illustrates a modified IGMPv3 Merge_Request message with the exclusion of sources option. The code field of 0×6 indicates this is a merge request with a list of source addresses for exclusion in receiving packets. This means sub group X is requesting NOT to receive multicast packets sent to group Y by sources to be listed in the request. A 16-bit field is used to specification of the number of such sources, followed by N records of 32-bit unicast source addresses which are the specific N sources from which multicast packets are not to be received.

P-0134[0134]FIG. 27E illustrates a modified IGMPv3 Merge_Posv_Reply message type. The code field of 0×7 indicates this is a successful merge request with a list of source addresses for exclusion. Similar to FIG. 27D, a 16-bit field is used to specify the number of resources, and N records of 32-bit unicast source addresses are specified for exclusion.

P-0135[0135]FIG. 27F illustrates a modified IGMPv3 Merge_Negv_Reply message type. The code field of 0×8 indicates this is a failure in processing the merge request with a list of source addressed for exclusion. The rest of the fields are similar to FIG. 27E.

P-0136[0136] For disband requests, the packet format (not shown) is similar to that for the merge requests. The code fields are the same as those used in merge requests and replies. The message type of 0×33 indicates it is an IGMPv3 Disband_Request and message type of 0×34 indicates it is an IGMPv3 Disband_Posv_Reply or Disband_Negv_Reply message.

P-0137[0137] If a router only supports IGMP v2 and does not support IGMPv3, the IGMPv3 Merge_Request and Disband_Request message types, as suggested, will be processed like the request messages. This means these modifications will not affect the normal working of routers who can only support IGMPv2. In addition, an IGMPv3-aware multicast router will keep a filter-mode and a list of source records for each sub group in the router_merge_table <b>40</b>. The router will check the filter-mode and list for inclusion or exclusion of packets sent from the specified list of sources.

P-0138[0138] At present, IGMP is no longer the protocol used for group membership management in IPv6. Instead, functions from IGMP are incorporated into ICMPv6 to provide support for group membership management. The packet formats for the defined message types remain the same when used in ICMPv6. The only difference is that there is a change in the specification of message types in ICMPv6. FIG. 28 shows a table illustrating the corresponding message types of ICMPv6 to provide group merge and disband capabilities in IPv6. In addition, there will be a change from using 32-bit to specify an IPv4 address to using 128-bit to specify IPv6 address.

P-0139[0139] As will now be appreciated, in the above embodiments, the merging and disbanding of groups use extended operations of IGMP or ICMP and is therefore independent on the IP routing protocol. In fact, when a 0-CMM <b>18</b> plays the role of a proxy member to extend a multicast tree network to its sub-network by sending a IGMP Membership Report, the multicast routing protocol may view this as an usual single host asking for membership. This allows the invention to be embodied in existing multicast routing algorithms as well as any of the future multicast routing algorithms (if any).

P-0140[0140] To support the IGMP extensions, only the immediate IP routers of the sub-networks need modifications; other intermediate routers, including backbone routers need not be aware of the group merging and disbanding operations and therefore they remain unchanged. The modifications are largely for the handling of the extended IGMP messages and the maintenance of group status within that sub-network; they will not affect the normal IP routing and IP multicast operations.

P-0141[0141] The provision of complex group structures allows cascading of groups to match complex business unit structures in organizations. By creating complex group structures, real world needs and relations can be translated to relationships at network level. This will incur less overhead compared to existing applications where such relationships are maintained at the application level.

P-0142[0142] In view of the proliferation of wireless network, e.g. provision of subscription to wireless LAN access, people forming groups can gracefully merge and disband to have informal group communications. Lower overhead will benefit the wireless applications greatly.

P-0143[0143] In addition, as the merge port is maintained at the router and not at the host, this enables hosts to receive packets from a number of multicast groups though they have subscribed to only one multicast address and port. The necessary modifications of the original multicast address and port to the matching address and port these hosts are listening to are performed at the network level by the router. As such, multiple ports at a host need not be available to merge groups.

P-0144[0144] As should be appreciated, multicast group merging as described herein allows coordination of meetings between two parties for any number of applications. Higher level applications can initiate group mergers and disband them, and can process multicast packets as desired. Conveniently, a sub group can choose to continue their own private multicasts even as they are in the merged state with another group, receiving the other group's multicast.

P-0145[0145] For example, there may be a strong demand for dynamic and creative usage of group communications in the scope of education services. An example will be a classroom scenario, whereby trainees forming groups will represent individual multicast groups and they can have their own private communication. Occasionally, the teacher (as a group) can merge with one or more of the groups to monitor the group's progress.

P-0146[0146] In fact, as more creative and complex group applications are created, a scenario may occur where secure inter and intra group communications provides the platform for more creative ways of school projects in the future.

P-0147[0147] Persons of ordinary skill will readily appreciate many more application of embodiments of the present invention.

P-0148[0148] All documents referred to herein are hereby incorporated by reference herein, for all purposes.

P-0149[0149] Of course, the above described embodiments, are intended to be illustrative only and in no way limiting. The described embodiments of carrying out the invention are susceptible to many modifications of form, arrangement of parts, details and order of operation. The invention, rather, is intended to encompass all such modification within its scope, as defined by the claims.