System, device, and method for managing multicast group memberships in a multicast network
Abstract
A system (300, 400, 500), device (1200), and method (600) for managing multicast group memberships in a multicast network uses IGMP spoofing to consolidate the multicast group memberships of a number of multicast hosts into a single IGMP Host. The IGMP spoofing agent maintains a group list indicating the multicast group membership status for the number of multicast hosts. The IGMP spoofing agent establishes a multicast group membership with a remote multicast device when at least one of the number of multicast hosts requests membership in the multicast group. The IGMP spoofing agent cancels the multicast group with the remote multicast device when all of the multicast hosts have left the multicast group. The IGMP spoofing agent responds to status inquiries from the remote multicast device as a proxy on behalf of the number of multicast hosts.
Term
No projected expiry on record.
- Priority
- Filed
- Granted
- Today
10 claims: 6 independent, 4 dependent
- 1一種在一多投網路中管理一遠端多投裝置與一些多投主機間之多投群組成員之方法(600),此方法包括步驟如下:維護(620)一代表一些多投主機多投群組成員狀態之群組清單;當至少有一個多投主機要求成爲多投群組内之成員時,建立(630)一與該遠端多投裝置之多投群組成員身份;且當所有多投主機離開該多投群組時,取消(640)該多投群組成員與遠端多投裝置之多投群組成員身份。
- 2如申請專利範圍第1項之方法,其中與遠端多投裝置建立多投群組成員身份之步驟包括以下步驟:自一多投主機接收(720)一成員回報訊息指定許多多投群組中的一個;決定(730)指定之多投群組是否位於群組清單内;且在該指定之多投群組不在群組清單内處:將該指定之多投群組加入(750)群組清單内;且送出(760)一成員回報訊息給遠端多投裝置來指出該多投群組。
- 3如申請專利範圍第1項之方法,其中取消與遠端多投裝置之多投群組成員身份之步驟包括以下步驟:送出(820)一狀態查詢到這些多投主機;若需求該多投群組時,至少自其中一個多投主機接收(820)一多投群組成員回報;若未接收到多投群組之多投群組成員回報,則自群組清單刪除(840)多投群組;且在選定之處,於自群組清單刪除該多投群組之後,送出(850)一離開多投群組之要求給該遠端多投裝置。
- 4如申請專利範圍第1項之方法,其中取消與遠端多投裝置之多投群組成員身份之步驟包括以下步驟:自一多投主機接收(920)一離開特定多投群組之要求;決定(930)是否至少其中一個多投主機仍保有一該特定多投群組之成員;在至少其中一個多投主機仍保有一該特定多投群組之成員處,離開群組清單中之該特定多投群組;在至少均無多投主機保有一該特定多投群組之成員處,自群組清單刪除(950)該特定多投群組;且在選定之處,於自群組清單刪除該多投群組之後,送出(960)一離開多投群組之要求給該遠端多投裝置。
- 5如申請專利範圍第1項之方法,尚包括以下步驟:作爲代表該等多投主機之代理,回應(650)來自遠端多投裝置之狀態查詢。
- 6如申請專利範圍第5項之方法,其中回應來自遠端多投裝置之狀態查詢之步驟包括以下步驟:自遠端多投裝置接收(1020,1120)一查詢訊息,要求至少一個多投群組成員之狀態;在查詢訊息要求所有多投群組成員狀態之處,對於群組清單内各個多投群組均送出(1040)一成員回報訊息給遠端多投裝置;在查詢訊息要求一特定多投群組成員狀態之處,檢查(1130)資料庫以決定是否該特定多投群組位於群組清單内,並在該特定多投群組位於群組清單内時,爲該特定多投群組送出(1150)一成員回報訊息給遠端多投裝置。
- 7一種在多投網路中管理一些多投群組之多投群組成員之裝置(1200),此裝置包括:一網路介面(1210)用來與多投網路相交接;一主機介面(1230)用來與一些多投主機相交接;一資料庫(1240)用來儲存多投群組成員資訊;及一IGMP連線巧取代理(1220)同時支援IGMP主機功能及IGMP查詢器功能;其中:該IGMP連線巧取代理可加以耦接到資料庫來維護一些多投主機之多投群組成員狀態;該IGMP連線巧取代理可加以耦接到網路介面以支援IGMP主機功能;且該IGMP連線巧取代理可加以耦接到主機介面以支援IGMP查詢器功能。
- 8如申請專利範圍第7項之裝置,其中該IGMP連線巧取代理包括:用來爲了這些多投主機,維護一指出多投群組成員狀態之群組清單之邏輯(logic);當其中至少有一多投主機要求多投群組之成員身份時,建立與遠端多投裝置之多投群組成員關係之邏輯;及當所有多投主機離開該多投群組時,取消與遠端多投裝置之多投群組成員關係之邏輯。
- 9如申請專利範圍第8項之裝置,其中該IGMP連線巧取代理尙包括:作爲代表該等多投主機之代理,回應來自遠端多投裝置之狀態查詢之邏輯(logic)。
- 10一種在一多投網路中管理多投群組成員之系統(300,400,500),該系統包括:一支援IGMP查詢器功能之遠端多投裝置;至少一支援IGMP主機功能之多投主機;及一區域多投裝置,可加以耦接到遠端多投裝置以支援IGMP主機功能,並可加以耦接到至少一多投主機以支援IGMP查詢器功能。
Independent claims10
35 paragraphs, as filed
System, device and method for managing multi-cast group members in a multi-cast network
background
The present invention generally relates to communication systems, in particular, managing multi-cast group members in a multi-cast network.
In today's information age, the demand for using computer network services such as the Internet to obtain information is increasing. Certain types of information are suitable for multiple consumers, such as news, financial information, and sports scores. These types of information can be packaged by a single producer and transmitted to a large number of consumers via a computer network.
A typical way for producers to send information to consumers is to copy the information and send a copy to each consumer. However, if the number of consumers is extremely large, these individual transmissions will require a lot of processing by the producer, and will require a lot of network bandwidth at the same time.
One way to improve the delivery of information from producers to consumers is to use a multicast service. The multi-cast service allows the producer to send a single message, which is replicated by the network at an appropriate time and sent to the consumers of the multi-cast group members. Replication has always been handled by routers on the network, and it is only done when needed. For convenience, a router that supports multi-cast services is called a multicast router. An introduction to one IP multiple investment can be an Internet draft (Draft), titled<u style="single">Introduction to IP Multicast Routing</u>, Authors Semeria and Maufer, are listed here for reference.
In order to support multi-cast services, each multi-cast router has always supported at least one multi-cast routing protocol for exchanging messages of multi-cast group members among various multi-cast routers on the network. There are currently some multi-cast routing agreements. Examples of multi-cast routing protocols include Distance Vector Multicast Routing Protocol (DVMRP), Multicast Open Shortest Path First-MOSPF, and Protocol Independent Multicasting (Protocol Independent Multicasting). -PIM).
In addition to supporting multi-cast routing protocols, all multi-cast routers directly connected to local area networks (LANs) have always supported the Internet Group Management Protocol (IGMP), which is described in Internet RFC 1112 (IGMP Version 1) Appendix I and the title is<u style="single">Internet Group Management Protocol.</u><u style="single">Version</u><u style="single">2</u>Author Fenner (IGMP Version 2) in the Internet draft. A multi-cast router uses IGMP to learn that those multi-cast groups have members on each of their attached networks. The multi-cast router maintains a list of multi-cast group members in a database for each of its attached networks, where "multi-cast group members" means that there is at least one multi-cast group on a given attached network Members of the group. The multi-cast router does not maintain a list of all group members from the network to which it is attached. For convenience, the multicast group membership is called "group list".
IGMP is used between multi-cast routers and directly connected IP (Internet Protocol) hosts (that is, host computers that support IP protocols on directly connected LANs). Using IGMP, IP hosts can join and leave the multi-cast group, and the multi-cast router can monitor the members of the multi-cast group of its IP host. For convenience, the multi-cast router directly connected to the IP host is called a regional router (as seen from the IP host), and other routers on the network are called remote routers.
IGMP defines some message types that can be exchanged between regional routers and IP hosts. The area router uses IGMP Query message to determine the members of the multi-cast group of the directly connected IP host. When an IP host wants to join a specific multi-cast group and reports its continuous membership in the specific multi-cast group to an IGMP query message, it unsolicitedly sends an IGMP Membership Report message (IGMP Membership Report message) ). The IP host uses an IGMP Leave message to explicitly remove it from a multi-cast group. For convenience, the device that sends out IGMP query messages (for example, regional routers) is called an IGMP Querier, and the device that sends out IGMP member report messages and IGMP leave messages (for example, IP hosts) is called an IGMP Host (IGMP Host).
Area routers usually send IGMP query messages to IP hosts to obtain group member information. IGMP defines two query messages, one is General Query message and the other is Group-Specific Query message. The general query message is sent to determine which (if any) available multi-cast group has at least one member directly connected to the IP host from the regional router. In response to the general query message, each IP host sends an IGMP member report message to each of its multi-cast group members. However, since IP hosts can usually monitor responses from other IP hosts on the same LAN, an IP host that detects responses from other IP hosts in a specific multi-cast group may not send an IGMP member report message to the same group.
The specific group query message is sent to determine whether at least one directly connected IP host is a member of the specific multi-cast group. At least one IP host of the specific multi-cast group member will respond to the specific group query message with an IGMP member report message (similarly, as with general query messages, the IP host of a specific group member will only be The response is sent only when other IP hosts in the group respond).
When an IP host wants to be removed from a specific multi-cast group, it stops responding to its membership in the group (that is, for the specific group, it does not send an IGMP member report message). Using the IGMP member report message that does not send a specific group means that the IP host requests to be removed from the group. An IP host supporting IGMP Version 2 can send an IGMP leave message to the regional router to explicitly request removal from a multi-cast group. The IGMP leave message informs the regional router that the IP host is no longer a member of the multi-cast group, and when receiving the IGMP leave message, the regional router usually sends an IGMP specific group query message to determine whether there is at least one The IP host is a member of the multi-cast group.
Figure 1 shows a system 100 in which a multi-cast routing protocol is used between the regional router and the multi-cast network, and IGMP is used for dynamic group registration between the regional router and some IP hosts (usually personal computers) ). The responsibility of maintaining the entire group members is distributed between the area router and the IP host. The IP host acts as an IGMP host, and the area router acts as an IGMP querier.
In order to transmit group information to other multi-cast routers, this module, which maintains group members between multi-cast networks, forces regional routers to participate in one or more complex multi-cast routing protocols. Existing multi-cast routing protocols are complicated and are often changed due to this complexity. This situation makes it difficult to implement and maintain agreements. At the same time, since there is no protocol adopted for the standard of all routers, a multi-cast routing often needs to support multiple protocols, which greatly increases the cost of the router.
These same problems exist in a data-over-cable DOC system. Figure 2 shows an exemplary DOC system, in which a headend router (ie, area router) 210 is coupled to a number of cable modems from 220 via a channel 230.<sub>1</sub>To 220<sub>n</sub>. Each head and tail router can support thousands of wired modems, and each wired modem represents a single LAN segment with at least one host. As shown in Figure 1 above, the head-to-tail router must support a multi-cast routing protocol in order to exchange multi-cast group information between multi-cast networks.
Therefore, there is always a need for a system, device, and method to remove the burden of the multi-cast routing protocol from the regional routers in the multi-cast network.
In the illustration, Figure 1 shows a multi-cast network as known in the art; Figure 2 shows a DOC system as known in the art; Figure 3 illustrates a multi-cast system in which the IGMP connection in the regional router is cleverly (spoofing) enables IGMP to be used between remote routers and area routers; Figure 4 illustrates a DOC system in which IGMP connections in the headend router are spoofing so that IGMP can be used for remote routers And head-to-tail routers; Figure 5 illustrates a DOC system, in which the head-to-tail router (headend The IGMP connection spoofing in the router allows IGMP to be used between the multi-cast host and the head-to-tail router; Figure 6 is a flow chart of a multi-cast network IGMP connection spoofing; Figure 7 is an IGMP connection The flow chart of the clever agent (agent) processing the IGMP member report message received from a multi-casting host; Figure 8 is a flow chart of the IGMP connection clever agent (agent) monitoring the multi-cast group members; Figure 9 is a first The flow chart of the IGMP connection agent processing the IGMP leave message received from a multi-casting host; Figure 10 is an IGMP connection agent processing the IGMP received from the remote multi-casting device The flow chart of the query message; Figure 11 is a flow chart of an IGMP connection clever agent (agent) processing IGMP specific group query messages received from the remote multi-cast device; and Figure 12 is a connection in the multi-cast network The line is the device of IGMP.
Detailed description
As mentioned above, there is always a need for a system, device, and method to remove the burden of the multi-cast routing protocol from the regional routers in the multi-cast network. The present invention uses the multi-cast routing protocol in the area router to replace an IGMP connection with an agent to operate. The regional router continues to act as an IGMP Querier on its host interface (that is, the connection with the directly connected IP host on the local network). However, instead of using a multi-cast routing protocol to exchange multi-cast group member information with remote routers, IGMP is used between regional routers and remote routers. The remote router performs the function of an IGMP querier, and the IGMP connection clever proxy located in the area router performs the function of an IGMP host. The IGMP connection uses a proxy to allow the remote router to regard it as a single IGMP host, and uses the multi-cast group member information maintained by the regional router as a proxy for the directly connected IP host. If at least one directly connected IP host is a member of the group, the IGMP connection cleverly joins the agent into the multi-cast group, and when the last directly connected IP host leaves the group, it leaves the multi-cast group Group.
The figure shows some applications of IGMP connections in a multi-cast network. FIG. 3 illustrates a multi-cast system 300 in which IGMP connection spoofing in the area router enables IGMP to be used between the remote router and the area router. FIG. 4 illustrates a DOC system 400 in which IGMP connection spoofing in the headend router enables IGMP to be used between the remote router and the headend router. FIG. 5 illustrates a DOC system 500 in which IGMP connection spoofing in the headend router enables IGMP to be used between the multi-cast host and the headend router. In these specific implementation examples, the IGMP connection uses the proxy to execute the standard IGMP host function to integrate the multi-cast group members of the multi-cast host and send them to the remote multi-cast device in the form of a single IGMP host.
Since the regional router does not need to support any multi-cast routing protocol, the IGMP connection skillfully reduces the cost and complexity of the regional router. Ingenious access to IGMP connections can also reduce the cost and complexity of remote multi-projection devices (for example, remote routers or servers). These devices only need to support IGMP on the network interface of the regional router. If the remote multi-cast device is a multi-cast host, the multi-cast host does not need to support any multi-cast routing protocol, thus reducing the cost and complexity of the multi-cast host.
The flow diagram of IGMP connection in a multi-cast network is shown in Figure 6. The logic maintains a group list representing the status of the multi-casting group members of these multi-casting hosts. When at least one multi-cast host requests members in a multi-cast group, the logic represents that the multi-cast host and the remote multi-cast device establish a multi-cast group member. As long as there is at least one multi-cast host as a member of the multi-cast group, the logic maintains the multi-cast group membership with the remote multi-cast device. When all multi-cast hosts leave the multi-cast group, the logic cancels the multi-cast group membership with the remote multi-cast device, so that the remote multi-cast device no longer sends a multi-cast message to the IGMP connection. Take the agent. The logic means that the proxy of these multi-projection hosts also responds to the status query from the remote multi-projection device.
When a multi-cast host requests members of a multi-cast group, the IGMP connection uses the agent to check the database to determine whether the specific multi-cast group is in the group list. If the multi-casting group is in the group list, there is no need to add the multi-casting host to the group. However, if the multi-cast group is not in the group list, the IGMP connection clever agent adds the multi-cast group to the group list and sends an IGMP member report message to the remote multi-cast device to specify the multi-cast Group.
The flow chart of an IGMP connection and an agent processing the IGMP member report message received from a multi-casting host is shown in FIG. 7. Regardless of whether the IGMP member report message is received unsolicited or responds to an IGMP query message, the logic is the same. The logic starts in step 710 and when the IGMP member report message is received from the multi-cast host in step 720, step 730 is executed, which checks the database to determine whether the multi-cast group is in the group list. If the multi-cast group is not in the group list (NO in step 740), the logic adds the multi-cast group to the group list in step 750 and sends it to the remote multi-cast device An IGMP member report message to request members of the multi-cast group in step 760. The logic ends in step 799.
The IGMP connection clever agent can also use the periodic status query (ie, IGMP query message) to be sent to the multi-cast host to monitor the multi-cast group members of the multi-cast host. In particular, the IGMP connection clever agent uses the standard IGMP querier function to determine which (if any) multi-cast groups in the group list are no longer needed. For groups that are no longer needed, the IGMP connection uses the agent to delete the group from the group list and, if IGMP Version 2 is supported, sends an IGMP leave message to the remote multi-cast device to request the multi-cast group Removed from the group.
The flow diagram of an IGMP connection and proxy monitoring of multi-cast group members is shown in Figure 8. The logic starts at step 810 and then executes step 820, which uses the standard IGMP querier function to determine which (if any) multi-cast groups in the group list are no longer needed. For each group that is no longer needed (YES in step 830), in step 840, the logic deletes the group from the group list and, in step 850, sends an IGMP leave message to the remote multi-projection device To request to be removed from the multi-cast group (if IGMP Version 2 is supported). When all unneeded groups have been removed from the group list (NO in step 830), the logic ends in step 899.
As discussed above, a multi-cast host supporting IGMP Version 2 can send an IGMP leave message to explicitly request to be removed from the multi-cast group. The flow chart of an IGMP connection and an agent processing an IGMP leave message received from a multi-cast host is shown in FIG. 9. The logic starts at step 910 and when an IGMP leave message is received in step 920, step 930 is executed, which uses the standard IGMP querier function to determine whether at least one multi-cast host supported by the regional router is still the multi-cast group Of members. If no member remains in the multi-casting group (NO in step 940), the logic deletes the multi-casting group from the group list in step 950, and sends one to the remote multi-casting device The IGMP leave message is used to request removal from the multi-cast group in step 960 (if IGMP Version 2 is supported). The logic ends at step 999.
In addition to maintaining the status of the multi-casting group members of the multi-casting host, the IGMP connection cleverly uses the proxy to represent the multi-casting host as its proxy, and responds to the status query from the remote multi-casting device. The remote multi-projection device sends an IGMP query message to the IGMP connection clever agent according to the role of its IGMP querier function. The IGMP connection cleverly uses the standard IGMP member report message to respond to the status query by the agent.
The flow chart of an IGMP connection agent processing IGMP general query message received from a remote multi-projection device is shown in FIG. 10. The logic starts at step 1010 and when an IGMP general query message is received in step 1020, the database is accessed in step 1030 to obtain the group list, and an IGMP member is sent for each multi-cast group in the group list Report the message to the remote multi-cast device. The logic ends in step 1099.
The flow diagram of an IGMP connection agent processing IGMP specific group query messages received from a remote multi-projection device is shown in FIG. 11. The logic starts in step 1110 and when an IGMP specific group query message is received in step 1120, step 1130 is executed, in which the database is checked to determine whether the specific multi-cast group is in the group list. If the multi-cast group is in the group list (YES in step 1140), the logic sends an IGMP member report message to the remote multi-cast device of the multi-cast group in step 1150, and ends in step 1199.
Figure 12 is an IGMP device connected in a multi-cast network. The device 1200 includes a network interface 1210 for connecting with other multi-projection devices (for example, a remote multi-projection router or server) or a multi-projection network. The device 1200 also includes a host interface 1230 for connecting with some multi-projection hosts. An IGMP connection agent 1220 executes the IGMP querier function on the host interface 1230 to manage the multi-cast group composition tool of the multi-cast host, and executes the IGMP host function on the network interface 1210 to represent these multi-cast hosts as Its agent. The IGMP connection clever agent 1220 maintains the multi-cast group member information of its attached multi-cast host in the database 1240, which is updated every time a group member is created or cancelled.
Although this IGMP connection technique is described together with the head and tail routers of a DOC system or other regional routers, for a technology owner, the present invention can obviously also be used in other devices, such as a remote router or a remote router. Access a server, or an IP switch. When the IGMP connection technique is applied to a remote router, the remote router will manage its directly attached area and the members of the multi-cast group of the remote router.
The present invention can be implemented in other specific forms without departing from its spirit or basic characteristics. Therefore, the described specific embodiments should only be regarded as illustrative in all respects and not limited to them.
The scope of the applied patent is as follows:
13 members in 10 offices
Priority claims5
| Document | Office | Kind | Date |
|---|---|---|---|
| 08847773 | United States of America | – | |
| 84777397 | United States of America | A | |
| 84777397 | United States of America | A | |
| 19970847773 | – | – | – |
| US19970847773 | – | – | – |
Members13
| Document | Office | Kind | |
|---|---|---|---|
| CA2287195A1 | Canada | A1 | |
| WO9848343A1 | World Intellectual Property Organization (WIPO) | A1 | |
| AU6544098A | Australia | A | |
| TW367449BThis record | Taiwan Province of China | B | |
| CN1253641A | China | A | |
| EP1029263A1 | European Patent Office (EPO) | A1 | |
| EP1029263A4 | European Patent Office (EPO) | A4 | |
| KR20010020190A | Republic of Korea | A | |
| AU735576B2 | Australia | B2 | |
| BR9815478A | Brazil | A | |
| JP2001521716A | Japan | A | |
| KR100358882B1 | Republic of Korea | B1 | |
| MY132907A | Malaysia | A |
Numbers
- Publication
- 367449
- Publication, DOCDB
- 367449
- Publication, EPODOC
- TW367449B
- Application
- 87103671
- Application, DOCDB
- 87103671
- Application, EPODOC
- TW19980103671
Titles4
- Chinese
- 於多投網路中管理多投群組成員之系統、裝置及方法
- English
- SYSTEM, DEVICE, AND METHOD FOR MANAGING MULTICAST GROUP MEMBERSHIPS IN A MULTICAST NETWORK
- Unlabeled
- 於多投網路中管理多投群組成員之系統、裝置及方法
- Unlabeled
- System, device and method for managing multi-cast group members in a multi-cast network
Classification
- CPC, 3
- H04L12/185
- G06F3/14
- H04L12/2801
- IPC, 4
- G06F15 163
- G06F15 177
- H04L12 18
- H04L12 28