JP3584897B2 - Multicast router route registration system and program - Google Patents

Description

[0001]
[Industrial applications]
The present invention relates to multicast protocol interoperability. In particular, the present invention
When the multicast protocol DVMRP (Distance-Vector Multicast Routing Protocol) and PIM-SM (Protocol-Independent Multicast Sparse Mode) are interoperated, the kernel (Kernel) for the increase and fluctuation of the multicast route information is changed. The present invention relates to a system and a program for registering a multicast route which enables mitigation.
[0002]
[Prior art]
FIG. 4 is a block diagram showing a schematic configuration of a multicast router route registration system which is a premise of the present invention.
As shown in the figure, a plurality of unicast protocol engines (RE) 1 and a plurality of multicast protocol engines (M-RE) 2 are provided in the route registration system of the multicast router. The routing software-core 2 acquires a route information from an adjacent node by setting a socket, and registers the unicast route and the multicast route immediately acquired in the route table inside the own node.
[0003]
A routing soft core (RS-CORE) 3 is connected to the unicast protocol engine 1, and the routing soft core 3 is a daemon of the routing software, and merges unicast routes registered in the unicast protocol engine 1. , The best route (BEST route) is registered.
The kernel (Kernel) 4 is connected to the routing software core 3 and the multicast protocol engine 2, registers an optimal route from the routing software core 3, registers a multicast route from the multicast protocol engine 2 in a routing table, and further registers It has a routing / forwarding function for multicast communication and controls transfer.
[0004]
That is, the kernel 4, when DVMRP as multicast protocol (Distance-Vector Multicast Routing Protocol) is operational, the sender (Source) has been determined luma multicast path (S, G) is registered You. Here, (S, G) means a (sender, group) pair.
[0005]
In the case where a PIM-SM (Protocol-Independent Multicast Sparse Mode) is operated as a multicast protocol in the kernel 4, multicast routes (*, G) for which the sender (Source) has not been determined are registered. You. Here, (*, G) means a pair of (arbitrary sender, group).
[0006]
In the registration of the route of the multicast protocol PIM-SM, not only the multicast route (S, G) in which the sender is determined but also the multicast route in which the sender is not determined , using an IGMP (Internet Group Management Protocol) socket. (*, G) is also directly registered in the kernel 4.
Further, a plurality of transfer engines (FW) 5 are connected to the kernel 4 in parallel, and the transfer engine 5 receives the route information from the kernel 4 and resolves the route by itself to perform the transfer.
[0007]
That is, the transfer engine 5 is, for example, an Ethernet (Ether), asynchronous transfer mode (ATM) line card.
When the transfer engine 5 receives a multicast packet from its own node, it is sent to the kernel 4.
The kernel 4 of the interoperability between the multicast protocols DVMRP and PIM-SM searches the internal unicast routing table, and if they match, it is one port in the line, and the interface (I / I / N) for the next hop (NextHOP). Check whether or not F) exists in the own node.
[0008]
That is, the sender address is a unicast address in order to check whether or not the interface of the own node at the time of route registration is an interface that can reach the sender (Source). The route information to the sender is checked by searching in a table.
In this case, if there is an interface for the next hop, it is determined that the own node has an interface that can reach the sender (Source) even if the sender (Source) address is not directly connected to the next node.
[0009]
If the interface exists, the route of the multicast packet is transferred, but if not, the route of the multicast packet is discarded.
Further, the kernel 4 always notifies the multicast protocol engine 2 of the received routing information of the multicast packet.
[0010]
[Problems to be solved by the invention]
On the other hand, since the sender and the receiver occur at an arbitrary time and place, unlike the case of the unicast, increase and fluctuation of the multicast route information are likely to occur.
In particular, for the multicast protocol DVMRP, it is necessary to create an (S, G) entry for each sender according to the situation, even if the multicast group is the same.
[0011]
On the other hand, with the interoperation of the multicast protocol PIM-SM, it is necessary to create entries for the multicast routes (S, G) and (*, G).
For this reason, the route registration system of the multicast router has a first problem that the registration load of the kernel 4 increases as the number of multicast routes increases.
[0012]
Further, in the route registration system of the multicast router, the kernel 4 needs to notify the multicast protocol engine 2 of the route information every time a multicast packet is received. There is a second problem that the processing load on the kernel 4 increases.
Therefore, in view of the above problems, the present invention provides a route registration system and a program for a multicast router that can reduce the registration load and processing load of the kernel 4 in response to an increase in the number of multicast routes of an interoperable multicast protocol. The purpose is to provide.
[0013]
[Means for Solving the Problems]
In order to solve the above problems, the present invention provides a route registering system for a multicast router for registering a multicast route, comprising: a multicast protocol engine for acquiring a multicast route from an adjacent node; and a route (sender, Group), a routing information is notified to the multicast protocol engine each time a multicast packet is received, and a kernel that controls the transfer of the received multicast packet and a daemon that provides a routing registration function of the kernel to an application layer are provided. Yes, register the route (sender, group) for which the sender has been confirmed and the route (any sender, group) for which the sender has not been determined, and register the route (sender, group) for which the sender has been determined. Application gateway for registering And Idemon, is delivered to the route information in parallel from said kernels, provides a path registration system of the multicast router, characterized in that it comprises a forwarding engine for transferring multicast packets to resolve path locally.
[0014]
By this means, the route registration function is output from the kernel to the application layer, and only the route (sender, group) for which the sender has been determined is registered in the kernel. It is possible to reduce the load of registering a route to the kernel.
Preferably, the kernel is configured such that the route (sender, group) of the received multicast packet is not registered in its own route table, and the group of the route (arbitrary sender, group) of the route table of the application gateway daemon and the group In the case where the group of the route (sender, group) of the received multicast packet matches and the own node has an interface that can reach the sender of the route (sender, group) of the received multicast packet, The route (sender, group) of the multicast packet is registered in its own route table.
[0015]
By this means, even if the route (sender, group) of a multicast packet not registered in the kernel's own route table is the same as the group of the route (arbitrary sender, group), a fixed In this case, the information is registered, so that it is possible to cope with an increase and a change in the route information.
Preferably, the kernel determines that the sender can be reached when the sender address of the route (sender, group) of the received multicast packet is registered in the unicast optimal routing table.
[0016]
By this means, it is possible to obtain fluctuating route information.
Preferably, the kernel is configured such that the route (sender, group) of the received multicast packet is not registered in its own route table, and the group of the route (arbitrary sender, group) of the route table of the application gateway daemon and the group When the received multicast packet does not match the group of the route (sender, group) of the received multicast packet, the route (sender, group) of the received multicast packet is registered in the multicast protocol engine.
[0017]
By this means, even a route (sender, group) of a multicast packet not registered in the kernel's own route table is registered in the multicast protocol engine and registered in the kernel's own route table. It can respond to increase and fluctuation.
Preferably, a trap application gateway daemon is disposed in the transfer engine, and the trap application gateway daemon is a daemon that issues a routing information notification function to the application layer from the kernel, and transmits the routing information to the multicast protocol engine. In order to do so, the route information is notified directly to the application gateway daemon.
[0018]
By this means, the route information is directly notified from the transfer engine to the application gateway daemon, so that there is no need to send useless data to the kernel, and the processing load on the kernel can be reduced.
Preferably, multicast protocols DVMRP and PIM-SM are interoperable with the multicast router.
[0019]
By this means, the route (sender, group) in which the sender of the multicast protocol DVMRP is determined, the route (sender, group) in which the sender of the multicast protocol PIM-SM is determined, and the sender are determined. It is possible to reduce the burden of registering a route to the kernel for routes that do not exist (arbitrary senders and groups).
[0020]
Further, in a route registration program of a multicast router for registering a multicast route, a procedure for acquiring a multicast route from an adjacent node , a route (sender, group) in which a sender is determined from the acquired multicast route, and a sender are determined. A procedure for registering a route (arbitrary sender or group) that has not been performed with a daemon that has issued a kernel route registration function to the application layer, and a route registered with the daemon and having a determined sender (transmission A step of causing the daemon to register only the path (sender, group) for which the sender is determined among the paths (arbitrary senders, groups) for which the sender has not been determined (arbitrary sender or group) to the kernel, If the route of the received multicast packet is a route for which the sender has not been determined (any sender or group A if the), the procedure sender corresponding to the kernel notifies the daemon determined to have no path (any sender, group) is registered, and controls the transfer of the multicast packet, the kernel And a procedure for distributing the route information in parallel from the network, and locally resolving the route to transfer the multicast packet.
[0021]
By this means, the route registration function is output from the kernel to the application layer and only the route (sender, group) for which the sender has been determined is registered in the kernel, similarly to the above-described invention. As a result, it is possible to reduce the registration load on the kernel.
[0022]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, embodiments of the present invention will be described with reference to the drawings.
FIG. 1 is a block diagram showing a schematic configuration of a route registration system for a multicast router according to the present invention.
As shown in the figure, as compared with FIG. 4, the path registration system multicast router application gateway daemon (AGD) 6 is provided, the application gateway daemon 6, application registration function of the multicast routes with kernel 4 It is a daemon that has been issued to the layer, and is connected to the multicast protocol engine 2, the routing software core 3, and the kernel 4.
[0023]
When registering a multicast route in its own node, the multicast protocol engine 2 registers the multicast route (S, G) for which the sender (Source) has been determined in the application gateway daemon 6.
The application gateway daemon 6 registers only the multicast path (S, G) for which the sender (Source) has been determined among the multicast paths registered from the multicast protocol engine 2 to the kernel 4. That is, the routes (S, G) for the multicast protocols DVMRP and PIM-SM are registered in the kernel 4, but for the multicast protocol PIM-SM, the multicast routes (*, G) for which the sender (Source) has not been determined. Will not be registered directly with the kernel 4.
[0024]
For this reason, since the kernel 4 registers only valid routes for which the sender (Source) has been determined, it is possible to reduce the load of route registration for an increase in multicast routes.
Further, the application gateway daemon 6 acquires the optimum route from the unicast route routing soft core 3 in advance.
[0025]
Next, the kernel 4 receives the multicast packet, and if the received multicast packet does not match the route in its own route table, notifies the application gateway daemon 6 of the fact, while the application gateway daemon 6 itself The route notified from the route table managed is searched, and if it matches, it is registered in the kernel 4; if it does not match, it is notified to the multicast protocol engine 2, and if the multicast protocol engine 2 has the route, it is multicast. The protocol engine 2 registers with the application gateway daemon 6, and the application gateway daemon 6 registers with the kernel 4.
[0026]
FIG. 2 is a flowchart illustrating the detailed operation of the application gateway daemon 6 in FIG.
In step S11, the application gateway daemon 6 acquires a unicast route from the routing software core 3 in advance.
In step S12, the application gateway daemon 6 determines whether the multicast protocol engine 2 has requested the registration of a multicast route. In the case that doing a registration request, the process proceeds to step S17.
[0027]
In step S13, when the application gateway daemon 6 has made a registration request, the application gateway daemon 6 designates any one of the multicast routes (S, G) and (*, G) to the multicast protocol engine 2. When (*, G) is specified, the process proceeds to step S14, and when (S, G) is specified, the process proceeds to step S15.
[0028]
In step S14, the application gateway daemon 6 registers the multicast route (*, G) in its own route table, and ends the process.
In step S15, the application gateway daemon 6 registers the multicast (S, G) in its own route table.
In step S16, the application gateway daemon 6 causes the kernel 4 to register the multicast (S, G), and ends the processing.
[0029]
In step S17, if a multicast packet is received, the kernel 4 searches the internal routing table, and if the routes do not match, notifies the application gateway daemon 6 of a mismatch, but the application gateway daemon 6 Then, it is determined whether or not notification of the mismatch has been received from No. 4. If no mismatch notification is received, the process returns to step S12, and the above processing is repeated.
In step S18, the application gateway daemon 6, having received the notification of the mismatch, in other words, the notification of the routing information of the multicast packet for the route not registered in the routing table of the kernel 4, searches its own routing table and notifies A search is made to see if there is a route that matches the group of routes that have been made, and it is determined whether it matches the group of the multicast route (*, G).
[0030]
If the groups match in step S19, the route of the multicast packet is determined to be the multicast route (S, G) of the multicast protocol PIM-SM. In this case, since the sender (Source) is a unicast address, a search is performed from the optimal routing table acquired in advance from the routing software core 3 to acquire a next hop. Check whether the own node has an interface (I / F) for the next hop.
[0031]
If there is an interface for the next hop, the process proceeds to steps S15 and S16, where the multicast route (S, G) of the multicast packet is registered in the application gateway daemon 6 and the kernel 4, respectively. In this way, it is possible to cope with an increase and a change in the route information of the multicast protocol PIM-SM.
[0032]
If there is no interface for the next hop, the route of the multicast packet is discarded, and the process ends.
In step S20, if there is no route whose group matches in the routing table of the application gateway daemon 6 in step S18, the application gateway daemon 6 registers this route and notifies the multicast protocol engine 2 at the same time. With this notification, a search is made for a route that matches the route registered in the routing table of the multicast protocol engine 2, and if not, the registration is performed.
[0033]
In this way, it is possible to cope with an increase and a change in the routing information of the multicast protocol DVMRP.
Therefore, it is possible to reduce the registration load of the kernel 4 as the number of multicast routes increases.
FIG. 3 is a diagram showing a modification of FIG. As shown in this figure, a trap application gateway daemon (TAGD) 7 is provided in each of the transfer engines 5 as compared with FIG. 1, and the trap application gateway daemon 7 has a function of notifying the route information from the kernel 4. The daemon output to the application layer, and the output thereof is connected to the application gateway daemon 6.
[0034]
In this way, the trap application gateway daemon 7 forms a pipe for notifying the application gateway daemon 6 from the transfer engine 5. The notification becomes possible, so that it is not necessary to send all data to the kernel 4, and only the necessary data needs to be sent to the kernel 4, and there is no need to send useless data. Therefore, the processing load on the kernel 4 is reduced.
[0035]
【The invention's effect】
As described above, according to the present invention, a multicast route is acquired from an adjacent node, only a route (sender, group) for which a sender has been determined is registered in the kernel, and a multicast route is received each time a multicast packet is received. Route information to control the transfer of the received multicast packet, send the kernel's route registration function to the application layer, and determine the route (sender, group) Registers undetermined routes (arbitrary senders and groups), registers routes for which senders have been determined (senders and groups) in the kernel, distributes routing information in parallel from the kernel, and routes locally To transfer the multicast packet, and issue the route registration function from the kernel to the application layer, and send it to the kernel. Route the sender has been determined (sender, group) since as to register only for increasing the multicast route, it is possible to reduce the registration load on the kernel.
[0036]
Furthermore, a trap application gateway daemon is arranged in the transfer engine, and the trap application gateway daemon notifies the application gateway daemon of the route information directly in order to notify the multicast protocol engine of the route information. Route information is sent directly to the application gateway daemon from the server, and there is no need to send useless data to the kernel, and the processing load on the kernel can be reduced.
[Brief description of the drawings]
FIG. 1 is a block diagram showing a schematic configuration of a route registration system for a multicast router according to the present invention.
FIG. 2 is a flowchart illustrating a detailed operation of an application gateway daemon 6 in FIG. 1;
FIG. 3 is a diagram showing a modification of FIG. 2;
FIG. 4 is a block diagram showing a schematic configuration of a route registration system of a multicast router which is a premise of the present invention.
[Explanation of symbols]
DESCRIPTION OF SYMBOLS 1 ... Unicast protocol engine 2 ... Multicast protocol engine 3 ... Routing software core 4 ... Kernel 5 ... Transfer engine 6 ... Application gateway daemon 7 ... Trap application gateway daemon

Claims (7)

In a route registration system of a multicast router for registering a multicast route,
A multicast protocol engine for acquiring a multicast route from an adjacent node;
A kernel for registering only the route (sender, group) for which the sender has been determined, notifying the multicast protocol engine of the route information each time a multicast packet is received, and controlling the transfer of the received multicast packet;
This is a daemon that has provided the kernel's route registration function to the application layer. It registers routes for which the sender has been determined (senders and groups) and routes for which the sender has not been determined (arbitrary senders and groups). An application gateway daemon for registering a route (sender, group) for which a sender has been determined with the kernel;
A routing engine for distributing routing information in parallel from the kernel, and locally resolving a route and forwarding a multicast packet. The kernel does not register the route (sender, group) of the received multicast packet in its own route table, and the group of the route (arbitrary sender, group) in the route table of the application gateway daemon and the received If the group of the multicast packet route (sender, group) matches and the own node has an interface that can reach the sender of the received multicast packet route (sender, group), the received multicast 2. The route registration system for a multicast router according to claim 1, wherein a route (sender, group) of the packet is registered in its own route table. The kernel determines that the sender can be reached if the sender address of the route (sender, group) of the received multicast packet is registered in the unicast optimal routing table. The multicast router route registration system according to claim 2, wherein The kernel determines that the route (sender, group) of the received multicast packet is not registered in its own route table, and the group of the route (arbitrary sender, group) of the route table of the application gateway daemon and the received multicast packet. 4. The multicast protocol engine according to claim 3, wherein when the packet does not match the group of the packet path (sender, group), the received multicast packet path (sender, group) is registered in a multicast protocol engine. Multicast router route registration system. A trap application gateway daemon is arranged in the transfer engine. 2. The route registration system for a multicast router according to claim 1, wherein the route information is notified directly to the application gateway daemon. The route registration system for a multicast router according to claim 1, wherein the multicast protocols DVMRP and PIM-SM are interoperable with the multicast router. In the route registration program of the multicast router that registers the multicast route,
A procedure for obtaining a multicast route from an adjacent node;
From the obtained multicast route, the route that the sender is determined (sender, group) and the route that the sender is not determined (arbitrary sender, group) are displayed on the application layer. And how to register
Among the routes registered in the daemon, the route for which the sender is determined (sender, group), and the route for which the sender is not determined (any sender, group), the route for which the sender is determined ( Registering only the sender, group) from the daemon into the kernel;
If the route of the received multicast packet is a route for which the sender has not been determined (arbitrary sender or group), the route is notified to the daemon and a route for which the sender corresponding to the kernel has not been determined (optional Sender and group), and controlling the transfer of the multicast packet.
A path registration program for a multicast router, comprising: a step of distributing path information in parallel from the kernel, locally resolving a path, and transferring a multicast packet.

Images