KR100475437B1 - method of multicast packet processing for tunneling and node therefor - Google Patents

Abstract

The present invention relates to a method for transmitting a multicast packet in a network having a plurality of nodes. In the past, when a node that does not support multicast is included among these nodes, the multicast packet does not pass through the node. By transmitting through a different path, a multicast service is provided to a user who receives the service.

Accordingly, the present invention provides a better multicast service to a user who receives a multicast service by tunneling a multicast packet to a node that does not support multicast.

Description

Method of multicast packet processing for tunneling and node therefor}

The present invention relates to a multicast packet processing method and a node for supporting tunneling. More particularly, the present invention relates to a multicast packet processing method for a node, and more particularly, to a packet that transmits a packet to an end destination via an intermediate waypoint that does not support multicast in a processor performing tunneling in a network. A multicast packet processing method for supporting tunneling and a node thereof.

Tunneling refers to a technique that allows a packet to be transmitted from one network to another network.

First, let's take a look at packet transmission method in general network.

From the perspective of the sender and receiver participating in the transmission, it can be divided into unicast transmission decoration, broadcast transmission method, and multicast transmission method.

1) The unicast transmission method is a method in which one sender transmits a packet to another receiver, that is, a one-to-one correspondence method, and a general application program uses a unicast method.

2) The broadcast transmission method is a method in which one sender transmits a packet to all receivers on the same sub network.

3) Multicast transmission schemes are used in applications such as Internet video conferencing, in which one or more senders send packets to a particular one or more recipients.

The difference between the multicast transmission method and the general unicast transmission method is in the transmission packet. In general, an Internet application on TCP / IP transmits a packet by sending the packet by indicating the network address of the receiver to receive the packet in the header of the transmission packet. Display the participating group address and send the packet.

The group address for the multicast transmission is a D-class IP address (224.0.0.0 to 239.255.255.255), unlike the A, B, and C-class IP addresses representing network hosts. The receiver receiving the multicast packet having the decision determines whether the packet belongs to the group of the packet and determines whether to accept the packet.

If such a multicast transmission scheme is supported, the sender can transmit packets to multiple receivers at once, thereby minimizing waste of network resources due to redundant transmission of packets.

However, in order to use such a multicast transmission scheme, an encapsulated packet must be transmitted between the multicast routers using the concept of tunneling.

1 is a block diagram illustrating a configuration of a network having a plurality of nodes in general.

Referring to FIG. 1, a transmitting host 10, a plurality of nodes 20, and a receiving host group 30 are provided.

A host is a terminal generally capable of two-way communication with other terminals through a network. The host has a specific host number, which is combined with the network number to form a unique Internet Protocol address. In the case of Point-to-Point Protocol (PPP) users through Internet service providers, they will have a unique IP address only while they are connected, and during that time, their terminal In this context, a host is a node in the network.

The transmitting host 10 performs a function of transmitting a packet to be transmitted.

The node 20 performs a relay function of transmitting the packet received from the transmitting host 10 to the final destination.

Receiving host group 30 is the final destination for receiving packets from node 20, and such receiving hosts are grouped to support multicast transmission schemes.

As an example, consider a method of transmitting a multicast packet for the case where node # 2 does not support the multicast service.

The multicast packet sent by the transmitting host 10 is received by the node-1 (20 # 1) supporting the multicast service and transmitted to the node-2 (20 # 2) through multicast routing.

Multicast routing refers to routing by adding IP addresses of both ends of a tunnel set between multicast routers on top of a data packet header having a multicast address. It is routed in the same way as a packet so that it can be sent to its final destination.

Since node-2 (20 # 2) does not support multicast service, node-2 (20 # 2) transmits the received packet to node-3 (20 # 3), which is an adjacent node supporting multicast.

Node-3 (20 # 3) transmits the received packet to Node-4 (20 # 4), which is an adjacent node, through multicast routing.

The node-4 20 # 4 analyzes the received packet and transmits the received packet to the destination host group 30 as the final destination.

In this method, a multicast packet is transmitted along a path that is not the shortest path due to a waypoint that does not support multicast, so that a user receiving a multicast service receives a multicast service having a time delay. .

For example, if node-2 (20 # 2) supports multicast, the multicast packet may be multicast not node-3 (20 # 3) via multicast routing at node-2 (20 # 2). It is sent to the supporting node-5 (20 # 5), and arrives at the destination host group 30, so that it will be sent in the shortest path to the destination host group 30 as the final destination.

That is, in this way, a user who receives a multicast service may not receive a smooth multicast service due to one node that does not support multicast.

Accordingly, the present invention is designed to solve the above problems, in a network network including a node that does not support multicast, so that the multicast packet can pass through a node that does not support the multicast service. It is an object of the present invention to provide a multicast packet processing method and a node for supporting tunneling capable of transmitting a packet in the shortest path.

A multicast packet processing method for supporting tunneling according to an aspect of the present invention for achieving the above object, receiving a multicast packet from any network, and find an optimal path to transmit the received multicast packet Performing multicast routing, determining whether the lower node to transmit the packet supports the multicast service according to the optimal path according to the routing result, and, as a result, the lower node does not support the multicast service. In this case, a tunnel IP header for tunneling is added to the received packet and output to the lower node.

Further, a multicast packet processing node for supporting tunneling according to another aspect of the present invention receives a multicast packet from any network, generates related information of the multicast packet, and based on the related information, a key. A forwarding module which selects a receiving module, a key generated by the receiving module, performs multicast routing based on the key, and writes an output port table of the corresponding multicast packet; and a multicast routing in the forwarding module. A plurality of output queue modules for storing the resultant key values, a tunnel information buffer for storing tunnel IP header information for tunneling of the received multicast packet, and a key value from the output queue module, and extracting the key values Based on the key value and the output port table, it is determined whether or not to tunnel the received multicast packet. As a result of the determination, when tunneling is to be performed, a transmission module for adding a tunnel IP header stored in a tunnel information buffer to the multicast packet, and a multicast packet including the tunnel IP header added from the transmission module to a lower node. It consists of a transmit buffer.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings.

2 is a block diagram illustrating a configuration of a multicast packet processing node for supporting tunneling according to an embodiment of the present invention.

Referring to FIG. 2, the node 20 includes a receive buffer 20a, a receive module 20b, an input queue module 20c, a forwarding module 20d, a plurality of output queue modules 20e, The transmission module 20f, the transmission buffer 20f, the port information buffer 20j, the packet information buffer 20i, the packet buffer 20h, and the tunnel information buffer 20l are provided.

The reception buffer 20a receives a multicast packet and temporarily stores the multicast packet.

The receiving module 20b receives a multicast packet from the receiving buffer 20a, stores it in the packet buffer 20h, generates relevant information of the received multicast packet, and generates the generated multicast packet. The relevant information is stored in the packet information buffer 20i.

In this case, the related information of the multicast packet corresponds to IP header information, packet type information, and information on a received input port.

In addition, the reception module 20b performs a general processing of the received multicast packet and generates a key having information of the multicast packet.

The key is used to classify packets. For example, if the database is sorted by age, "age" is a key.

The input queue module 20c performs a function of temporarily storing a key having information of the multicast packet generated by the receiving module 20a.

A queue is a data structure that is removed in the order in which the data was entered. This order is commonly referred to as first in, first out (FIFO).

The forwarding module 20d extracts the key stored in the input queue module 20d, multicasts the received multicast packet based on the output port, and outputs ports for a plurality of corresponding output ports. Create a table.

And, based on the generated output port table, and performs a function of storing as a key in a plurality of output queue module 20e corresponding to one-to-one.

The output queue module 20e is provided with the number of output port tables generated by the forwarding module 20d, and temporarily stores the keys of the multicast routed multicast packet information.

The transmitting module 20f extracts a key from one output queue module 20e of the plurality of output queue modules 20e, and adds a tunnel IP header for tunneling to the multicast routed multicast packet based on this. And transmits to the corresponding transmission buffer 20g.

Then, the tunnel IP header is added to the received multicast packet, transmitted, and initialized in the output port table generated by the forwarding module 20l.

A method of processing a multicast packet received by the transmitting module 20f is, for example, described as a round-robin method, which gives processes a fair opportunity to use resources. One way to do this is to allocate a certain amount of time to each process, and when that time passes, the process is suspended for a while, then the opportunity is given to another process, and the next process is given a turn. This is commonly called round robin process scheduling.

The transmission buffer 20g temporarily stores the IP tunneling multicast packet generated by the transmission module 20f to transmit to the corresponding output port.

In this case, the IP tunneling multicast packet refers to a tunnel IP header added by the transmission module 20f based on the received multicast packet.

The port information buffer 20j stores a function of output port information provided in the node 20.

The tunnel information buffer 20l stores information of the tunnel IP header added by the transmission module 20f.

The packet information buffer 20i stores related information about the multicast packet generated by the receiving module 20b and information necessary for multicast routing.

The packet buffer 20h stores a multicast packet and a multicast routing result value.

3 is a flowchart illustrating a flow of a multicast packet processing method for supporting tunneling according to an embodiment of the present invention.

Referring to FIG. 3, the receiving buffer 20a receives and temporarily stores a packet from an arbitrary network (S 1), and the receiving module 20b determines whether the received packet is a multicast packet (S 2). ).

At this time, whether the received packet is a multicast packet or not, for example, analyzes the header of the received packet to determine whether the destination address is the destination group address.

As a result of determination, if the received packet is a multicast packet, the forwarding module 20d inquires of the optimal path to transmit the packet through multicast routing, and the lower node that transmits the packet through the optimal path receives the multicast service. It is determined whether to support (S 3).

At this time, whether the lower node supports multicast is determined by using the DVMRP concatenation message transmitted to the lower node according to the direct vector multicast routing protocol (hereinafter, referred to as 'DVMRP'). Determine whether there is a response to the (DVMRP Graft Message).

DVMRP is defined in the Request for Comments (RFC) 1075 of the Internet Engineering Task Force (IETF) and is a distance-vector routing protocol designed to transmit multicast packets over a network.

As a result, when the lower node does not support the multicast service, the tunnel IP header stored in the tunnel information buffer 20l is added to the received multicast packet for tunneling (S4).

If the received packet is not a multicast packet, the lower node supports the multicast service, or the lower node does not support the multicast service, the tunnel IP header is added to transmit the received multicast packet to the lower node. (S 5).

4 is a flowchart illustrating a flow of a method of determining whether a lower node supports a multicast service according to an embodiment of the present invention.

Referring to FIG. 4, when a multicast packet is received from an arbitrary network, a DVMRP concatenation message is generated according to the Direct Vector Multicast Routing Protocol (DVMRP) and transmitted to a lower node (S 3a).

The DVMRP joint message is transmitted, and it is determined whether a DVMRP Graft-Ack Message is received from the lower node (S 3b).

As a result, when the DVMRP junction response message is not received, it is determined that the lower node does not support the multicast service (S 3c).

This is because, when the lower node does not support the multicast service, routing cannot be performed on the group address of the received DVMRP junction message, and thus, a DVMRP junction response message cannot be generated.

On the other hand, when it is determined that the DVMRP join response message is received, it is determined that the lower node supports the multicast service (S 3d).

This is because, when the lower node supports the multicast service, routing may be performed on the group address of the received DVMRP junction message, and thus a DVMRP junction response message is generated and transmitted to the upper node.

5 is a flowchart illustrating a flow of a method for adding a tunnel IP header to a received multicast packet according to an embodiment of the present invention.

The multicast packet received from any network is received by the reception buffer 20a through the input port and temporarily stored therein (S 4a).

The reception module 20b generates information about the multicast packet temporarily stored in the reception buffer 20a, and stores the information about the multicast packet in the packet buffer 20h together with the multicast packet (S 4b).

At this time, the multicast packet information stored in the packet buffer 20h corresponds to, for example, an IP header for performing multicast routing, a packet type, input port information, and the like.

The receiving module 20b then determines whether the multicast packet is a general process, that is, whether the received packet is a multicast packet or a broadcast packet, whether the Ethernet packet type is an IP type, and determines an IP header. It is determined whether the values of the respective fields in the field are correct. If the result of the determination is not correct, the multicast packet is discarded (S 4c).

Further, arithmetic operations are performed on the associated information on the stored multicast packet, for example, the multicast packet position information stored in the packet buffer 20h and the packet information on the multicast packet in the packet information buffer 20i. Operand information and the total length information of the multicast packet, etc., which are designated through the same, are made into one key and stored in the input queue module 20c (S 4d).

 The forwarding module 20d extracts a key stored in the input queue module 20c, reads the source IP address and the destination group address from the IP header of the received multicast packet based on the extracted key, Multicast routing is performed using this (S 4e).

In other words, deriving the final point values, namely, the source IP address and destination group address to be newly modified, the input port and output port list, and the time-to-live (TTL) value, are derived. Based on the above, the TTL value and the checksum value, which are some fields of the IP header in the input port check and the packet information buffer 20i, are set again.

 An output port table is generated to output the received multicast packets to the plurality of output ports (S 4f).

This includes the operands that designate the information of the multicast packets received by the plurality of output queue modules corresponding to one-to-one, that is, the position information in the packet buffer 20h of the multicast packet and the position in the packet information buffer 20i through calculation. , A key is generated using the total length information of the multicast packet, and the generated keys are stored in the plurality of output queue modules 20e corresponding to the number of corresponding output ports.

The transmitting module 20f extracts one of the keys stored in the output queue module 20e in a round-robin manner, and whether the corresponding output port is an IP tunneling port in the port information buffer 20i. In the case of an output port for IP tunneling, based on the extracted key, the existing destination physical address of the multicast packet and the port information stored in the port information buffer 20i of the corresponding output port are determined. Read the source physical address.

Then, the IP header in which only the TTL value is modified from the tunnel IP header stored in the tunnel information buffer 20l, the information on the multicast packet stored in the packet information buffer 20i, and the multicast in the packet buffer 20h. The IP tunneling multicast packet in which the tunnel IP header is added to the packet is temporarily stored in the corresponding transmission buffer (S 4g).

In other words, a tunnel IP header is added to a multicast packet and temporarily stored in a transmission buffer for transmission to a lower node that does not support multicast.

FIG. 6 illustrates a structure of an IP tunneling multicast packet in which a tunnel IP header is added. Referring to FIG. 6, the IP tunneling multicast packet 40 may include a physical destination address field 41. Physical Source Address Field 42, Tunnel IP Header Field 43, IP Header Field 44, Payload Field 45).

In the following description of the information of each field, the physical destination address field 41 is destination address information for performing the multicast of the IP tunneling multicast packet 40, that is, the address of the receiving host group 30 as the final destination. Information, and the physical source address field 42 contains source address information, i.e., address information of the transmitting host 10, for multicasting the IP tunneling multicast packet 40.

The tunnel IP header field 43 is a field stored in the tunnel information buffer 20l and added by the transmission module 20f. Tunneling of the multicast packet when the adjacent node 20 does not support the multicast service. It has source address information starting with and destination address information ending with tunneling.

The IP header field 44 has packet information of the multicast packet, and the payload field 45 has information on the kind of information that the multicast packet has.

Then, the output port table of the corresponding output port to output the IP tunneling multicast packet generated by adding the tunnel IP header 43 is initialized, and the tunneling multicast packet 40 temporarily stored in the transmission buffer 20f is outputted. Output to the lower node through the port (S 4h).

Although the present invention has been described in detail only with respect to the described embodiments, it will be apparent to those skilled in the art that various modifications and changes are possible within the technical spirit of the present invention, and such modifications and modifications belong to the appended claims.

As described above, according to the present invention, when a multicast packet needs to be transmitted to a node that does not support the multicast service in a network including a node that does not support the multicast service, the node may transmit the multicast packet. By enabling tunneling, it is possible to eliminate the loss of multicast packets caused by nodes that do not support multicast services, and to provide multicast services through the shortest path with no time delay for users who receive the multicast services. It has an effect.

BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 is a block diagram illustrating a configuration of a network network having a plurality of general nodes.

2 is a block diagram illustrating a configuration of a multicast packet processing node for supporting tunneling according to an embodiment of the present invention.

3 is a flowchart illustrating a flow of a multicast packet processing method for supporting tunneling according to an embodiment of the present invention.

4 is a flowchart illustrating a flow of a method for determining whether a lower node supports multicast according to an embodiment of the present invention.

5 is a flow chart illustrating the flow of a method for adding a tunnel IP header to a received multicast packet, in accordance with a preferred embodiment of the present invention.

6 is a structural diagram illustrating a structure of an IP tunneling multicast packet with an IP header added according to an embodiment of the present invention.

<Explanation of symbols for the main parts of the drawings>

10: sending host 20: node

20a: Receive buffer 20b: Receive module

20c: input cue module 20d: forwarding module

20e: output queue module 20f: sending module

20g: Transmission buffer 20h: Packet buffer

20i: packet information buffer 20j: port information buffer

20l: tunnel information buffer 30: receiving host group

40: IP tunneling multicast packet

41: physical destination address field

42: physical source address 43: tunnel IP header field

44: IP header field 45: Payload

Claims (8)

In a network including at least one node, a method for processing any multicast packet, Receiving a multicast packet from any network; Performing multicast routing to find an optimal path for transmitting the received multicast packet; Determining whether a lower node to transmit the packet supports a multicast service according to an optimal path according to the routing result; If the lower node does not support the multicast service, adding a tunnel IP header for tunneling to the received packet; And outputting the multicast packet including the tunnel IP header to a lower node. The method of claim 1, wherein the determining of whether the lower node supports a multicast service comprises: When the multicast packet is received, generating a joint message according to a direct vector multicast routing protocol, transmitting the joint message to the lower node, and then determining whether a joint response message is received; , Determining that the lower node supports the multicast service when the joint response message is received from the lower node as a result of the determination; And determining that the lower node does not support a multicast service when the joint response message is not received from the lower node as a result of the determination. The method of claim 1, wherein the tunnel IP header, And a source address information, which is added between the Ethernet header and the IP header of the received multicast packet, having source address information, which is a start point of tunneling, and destination address information, which is an end point, of tunneling. The method of claim 1, Generating information for performing multicast routing on the received multicast packet; Processing the received multicast packet by determining the type of the received multicast packet, the type of the Ethernet header, and whether the field value of each header is correct; Multicast packet processing method for supporting tunneling further comprising the step of creating an output port table based on the generated information and a plurality of output port information. In a network including at least one node, a node receiving a multicast packet and outputs to a lower node, A receiving module for receiving a multicast packet from an arbitrary network, generating related information of the multicast packet, and generating a key based on the related information; A forwarding module for selecting a key generated by the receiving module and performing multicast routing based on the key to create an output port table of the multicast packet; A plurality of output queue modules for storing key values that are multicast routing result values in the forwarding module; A tunnel information buffer for storing tunnel IP header information for tunneling the received multicast packet; The key value is extracted from one of the output queue modules, and it is determined whether to tunnel the received multicast packet based on the extracted key value and the output port table. A transmission module for adding a tunnel IP header stored in the tunnel information buffer to the multicast packet, And a transmission buffer for outputting a multicast packet to which a tunnel IP header is added to a lower node in the transmission module. The method of claim 5, A reception buffer for temporarily storing the received multicast packet; A port information buffer for storing information of an output port from which the multicast packet is output; An input queue module for storing the key generated by the receiving module; A packet information buffer for storing related information about the multicast packet and information necessary for multicast routing; And a packet buffer for storing the multicast packet and the result value for the multicast routing result. The method of claim 5, wherein the output port table, An item indicating position information in which the multicast packet is stored, an operand item indicating a position of information related to the multicast packet, an item indicating type information of the multicast packet, and length information of the multicast packet. A multicast packet processing node for supporting tunneling, comprising: an item indicating. The method of claim 5, wherein the receiving module, A multicast packet processing node for supporting tunneling to determine the type of multicast packet received from any network, the type of Ethernet header, and whether each field value of the Ethernet header is correct.