KR101068787B1 - Overlay network system and method of multicast using the same - Google Patents

Abstract

An overlay network system and a multicast method using the same are disclosed. The present invention is connected to a plurality of end hosts, a plurality of end hosts in the data plane, and monitors the participation and withdrawal of the multicast of the plurality of end hosts, and in response to the flow table received from the management server IP in eye (IP- a multicast spanning tree based on information received from a plurality of proxy nodes moving packets by in-IP and a plurality of proxy nodes in a control plane, and a flow table for packet flows It is configured to include the management server to transmit to, to build and service SeeOver (Service-enabling Overlay) infrastructure.

End host, data plane, control plane, proxy node, management server

Description

OVERLAY NETWORK SYSTEM AND METHOD OF MULTICAST USING THE SAME}

The present invention relates to an overlay network system and a multicast method using the same. More specifically, a control plane and a data plane are separated, and a proxy node is point-to-point in the data plane. -point) or point-to-multipoint forwarding, and the management server (Coordinator) manages the proxy nodes and configures the spanning tree in the control plane to build a SeeOver (Service-enabling Overlay) infrastructure. An overlay network system that can serve and a multicast method using the same.

Conventional IP Multicast (IP Multicast) has a limited implementation service despite the technical advantages due to the absence of a revenue model, policy differences between AS and difficult maintenance. Recently, commercial service models such as IP (IP) TVs have emerged, and there is a growing expectation for the widespread application of technology, such as the demand for scientific and technological collaboration environments such as e-Science. At this point, stable IP multiplexing is possible to overcome various problems including disconnection of service and low quality of application service caused by absence of IP multicast service and mutual routing problem between domains. A technical approach is needed to provide a casting infrastructure.

Overlay, RON, ScatterCast, Yoid, ECM, ALMI and other overlay multicast studies have been conducted to solve problems such as quality problems such as unreliable transmission of IP multicast and lack of service due to delays in infrastructure construction. . These overlay multicast studies focus on improving the scalability, connectivity, and reliability of the overlay structure, and because the IP layer is handled at the application layer, low packet forwarding performance or frequent multicast participation of hosts responsible for packet relaying And tree composition is not stable due to join and leave.

In addition, the use of non-standard communication protocols or infrastructure-dependent packet headers for message exchange between hosts participating in the overlay infrastructure requires a change in the application software or system configuration of the end host.

For example, ScatterCast using an overlay proxy (supernode) has a packet throughput of 350 Mbps on average and a high latency variation when routing through multiple proxies with 200 to 600 milliseconds of delay per packet (up to 2-3 milliseconds). Deterioration of service quality can be expected such as jitter.

In other words, overlay networking techniques replacing conventional IP multicast must use end host configuration modification or non-standard communication protocol, and do not provide stable tree because end hosts directly participate in packet forwarding and are free to join and leave. The group could not be protected from malicious users.

In addition, conventional point-to-multiple forwarding by software utilizes a high-performance, expensive workstation, but has a problem of low performance in packet throughput.

Accordingly, an object of the present invention for solving the above problems is to substitute for IP (IP) multicast, the control plane and the data plane is separated, the proxy node performs point-to-point or point-to-many forwarding in the data plane, The management server provides an overlay network system capable of constructing and servicing a SeeOver infrastructure by managing proxy nodes and configuring a spanning tree in a control plane, and a multicast method using the same.

In order to achieve the above object, the present invention is connected to a plurality of end hosts and a plurality of end hosts in the data plane, respectively, and monitors multicast participation and withdrawal of the plurality of end hosts, and transmits them to a flow table received from a management server. Correspondingly, a multicast spanning tree is constructed based on the information received from the plurality of proxy nodes in the control plane and the control node moving the packet by IP-in-IP, and the packet flow And a management server configured to set a flow table and transmit the flow table to the plurality of proxy nodes, wherein the data plane and the control plane are separated, and an IGMP protocol is established between the plurality of end hosts and the plurality of proxy nodes. Provides an overlay network system applied.

The present invention for achieving the above object is (a) the proxy node receiving the MAC frame, (b) the proxy node determining the destination MAC address of the received Mac frame, (c) the proxy node Determining a type of a received packet by reading a protocol number if the destination MAC address of the MAC frame is a multicast MAC address, and (d) filtering the flow table if the received packet is a multicast IP (IP) Searching for a rule and processing in software if the MAC address and protocol number of the received frame are IGMP packets; and (e) the proxy node includes information of the received MAC frame in the flow table. If the filtering rule does not exist, request the flow table from the management server, and if the filtering rule exists, the processing rule (ACTION) is executed. It provides a multicast method using an overlay network system comprising the step.

Therefore, according to the overlay network system of the present invention and a multicast method using the same, the control plane and the data plane are separated on behalf of IP multicast, and the proxy node performs point-to-point or point-to-many forwarding on the data plane. In addition, the management server has the effect of establishing and servicing the SeeOver infrastructure by performing proxy node management and spanning tree configuration in the control plane.

In addition, the overlay network system of the present invention and a multicast method using the same can provide a stable tree by using an overlay proxy, which is a super node, and can use existing IP protocol protocols such as Internet group management protocol (IGMP). Compliance allows you to participate in multilateral collaboration without changing system settings.

In addition, the overlay network system of the present invention and a multicast method using the same increase the manageability of each flow by forwarding the multicast packet based on a flow table, and the management server filters the rules for the multicast packet. (RULES) It is possible to combine various settings for flow processing by determining rules and action instructions.

In addition, the overlay network system of the present invention and a multicast method using the same perform a high-speed packet forwarding and multi-point replication using a low-cost NetFPGA, a Peripheral Component Interconnect (PCI) card, and separate the control plane from the data plane to provide Gbps. Packet processing performance can be guaranteed and a cost effective proxy can be constructed.

The terms or words used in this specification and claims are not to be construed as limiting in their usual or dictionary meanings, and the inventors may properly define the concept of terms in order to best explain their invention in the best way possible. It should be interpreted as meaning and concept corresponding to the technical idea of the present invention.

Best Mode for Carrying Out the Invention Preferred embodiments of the present invention will be described below with reference to the accompanying drawings.

An overlay network system according to an embodiment of the present invention will be described with reference to FIGS. 1 and 2 as follows. 1 is a schematic diagram of an overlay network system according to an embodiment of the present invention, and FIG. 2 is a schematic diagram illustrating the proxy node of FIG. 1.

As shown in FIG. 1, the overlay network system 100 according to an embodiment of the present invention is divided into a control plane and a data plane for multicast, and includes a plurality of end hosts ( h _k , h _{k '} , h _m ) 140, a plurality of proxy nodes N ₁ , N _m , N _k ) 110, and a management server C, 150.

IGMP protocol is used between the plurality of end hosts 140 and the plurality of proxy nodes 110, and the proxy node 110 monitors the multicast participation and withdrawal of the end hosts 140, and Snooping EGMP Snooping An IP-in-IP service is provided between the proxy nodes 110 to transmit a multicast packet to a destination.

The management server C constructs a spanning tree based on the information provided by the proxy node 110 and transmits a processing method for the packet flow to the proxy node 110. Thereafter, the proxy node 110 forwards the packet flow at high speed based on the flow table provided by the management server 150.

Specifically, referring to the proxy node 110 with reference to FIG. 2, the proxy node 110 is divided into hardware and software. The hardware performs IP packet and MAC frame forwarding functions, and the software performs communication protocols such as ARP, IGMP, SSL, and the like. At this time, the data plane is managed by hardware, and the control plane is managed by software.

The proxy node 110 classifies and processes packets on the basis of layer 2 and layer 3 header information. In particular, the proxy node 110 processes the ARP packet in software because it has a public IP, and processes the IBMP packet in software because IGMP is used.

Specifically, the arbiter 111 detects the type of the frame and the packet through the MAC frame input through the physical layer PHY 119, and selects a processing block according to the type. It also maintains and maintains MAC tables and checks for IP checksum errors. For example, when receiving a MAC frame corresponding to the ALP, it branches to the overlay engine 121 of the software portion for managing the MAC table.

In addition, the arbiter 111 updates a flow table, a MAC table, a system state, and the like of the information bases 113, and inputs and outputs packets and frames using the information of the information base 113. Take control.

The MAC bridge 115 performs a switching function of the two-layer MAC frame. The MAC table held by the information base 113 is read to determine an output port, etc., and generate a MAC frame.

The IP bridge 117 reads a flow table held by the information base 113 to encapsulate or de-encapsulate an IP packet. Here, the encapsulation is IP-in-IP, and the encapsulated IP packet is delivered to the neighbor proxy node 110 connected in point-to-point, and the IP packet being decapsulated is connected to the end hosts 140 connected to the downlink port. Is flooded into

A packet processing method of a proxy node of an overlay network system according to an embodiment of the present invention will be described with reference to FIGS. 1 to 7. 3 and 4 are flowcharts illustrating a MAC frame processing method according to an embodiment of the present invention, FIG. 5 is a flowchart illustrating an ARP processing method according to an embodiment of the present invention, and FIG. FIG. 7 is a flowchart illustrating an IGMP processing method according to an embodiment of the present invention, and FIG. 7 is a diagram illustrating signal processing between a management server and a proxy node of an overlay network system according to an embodiment of the present invention.

The proxy node 110 classifies and processes packets or frames based on MAC frames in the second layer.

As shown in FIG. 3, the proxy node 110 receives a MAC frame in step S201, and determines a destination MAC address of the mac frame of the proxy node 110 in step S203.

Next, in step 211, if the destination MAC address of the MAC frame is a multicast MAC address, the proxy node 110 reads the protocol number to determine the type of the received packet. If it is determined that the received packet is an IGP packet, the proxy node 110 processes the software in step S213.

As a result of the determination, if the received packet is a multicast IP, in step S231, the proxy node 110 searches whether the filtering rule of the flow table exists. Next, the proxy node 110 requests a flow table from the management server 150 when there is no filtering rule including information of the MAC frame received in the flow table in step S233, and the filtering rule exists in step S235. Implement processing rules.

At this time, the proxy node 110 searches the flow table when the filtered MAC frame is received regardless of whether the packet is encapsulated. In addition, the proxy node 110 preferably communicates with the management server 150 in software to obtain a filtering rule if a filtering rule corresponding to the packet received in the flow table is not found.

On the other hand, as a result of determining the destination MAC address of the MAC frame in step S203, when the destination MAC address is unicast, the proxy node 110 determines whether the received MAC address and the MAC address of the received frame match in step S221. In this case, in step S223, the proxy node 110 floods if the proxy MAC address does not match the MAC address of the received frame.

Next, in step S225, the proxy node 110 determines whether the received frame is an IP in IP packet to determine whether to encapsulate it.

Next, if the Mac frame received in step S227 is not encapsulated, if the port is a TCP / UDP port, the process is handled by the software in step S229. .

On the other hand, if the MAC frame received in step S227 is encapsulated in step S231 it is determined whether the filtering rule exists in the flow table.

Next, the proxy node 110 requests a flow table from the management server 150 when there is no filtering rule including information of the MAC frame received in the flow table in step S233, and the filtering rule exists in step S235. Implement processing rules. At this time, the contents of the fields of the MAC header and the IP header can be changed through the processing rule.

As shown in FIG. 4, first, when the MAC frame is received in step S301, the workflow branches based on the destination MAC address of the frame received in step S303.

If the destination MAC address of the received frame has a broadcast address, it is determined whether the ALP packet is read by reading the value of the Ethernet type field of the header in step S311. Next, if it is confirmed that the ALP packet, the ALP packet is moved to the software domain in step S313 and then processed in the same manner as described in FIG. 5.

In addition, the proxy node 110 floods in step S315 when the received destination MAC address is a general broadcast packet instead of an ALP packet.

If the received destination MAC address is a general unicast address (Ethernet type is IP), in step S321, the proxy node 110 may determine the MAC address of the corresponding proxy node 110 and the MAC address of the received frame. Compare. If the two addresses match, in step S323, the proxy node 110 reads the protocol number of the IP packet and determines whether to encapsulate the IP-in-IP. In step S325, the proxy node 110 processes the software in the case of an unencapsulated packet, and searches the flow table to find a corresponding filtering rule (RULES) in the case of the packet encapsulated in step S327. Thereafter, when the filtering rule exists in the flow table, the proxy node 110 performs a processing rule in step S329.

In this case, since the filtering rule does not exist in the flow table, an error is handled by the proxy node 110 in software in step S328. Here, the filtering rule is a rule for filtering a packet flow, and the processing rule is a rule (eg, discard, forward, etc.) for processing the flow.

On the other hand, if the destination MAC address is IP multicast, the proxy node 110 determines the input port of the received packet in step S331. At this time, in step S333, the proxy node 110 discards the multicast frame input through the uplink without processing. In step S335, the proxy node 110 floods the multicast frame input through the downlink port.

Next, in step S337, the proxy node 110 determines whether the multicast frame inputted through the downlink port includes the IGP packet, and if it contains the IGP packet, the software processes the IGP protocol in step S339. In case of having a general Class D address, the flow table is searched in step S341.

As a result of the search, if the filtering rule exists in the flow table, the processing rule is performed in step S329. If the filtering rule does not exist in the flow table, the software sends the management server 150 to obtain a flow table corresponding to the packet in step S343. Receive filtering rules and update the flow table.

FIG. 5 is a diagram illustrating a procedure of processing an ARP packet in software, and illustrates a method of moving to a software area when the Ethernet type field value of the header is an ALP packet in step S311 of FIG. 4.

The Ethernet type of ARP packet is 0x0806. If a host does not have a MAC address for its destination IP in its MAC table, it generates an ARP request packet. A host whose IP address in the received ARP request packet is the same as its own address Feedback the ARP reply packet. FIG. 5 omits the process of generating an ARP request packet by the corresponding proxy node as a packet sender, and includes only the processing of an ARP request generated by another host.

First, when an ALP packet is input in step S401, in step S403, an arbitrary host 140 distinguishes an ALP type through an operation field of the ALP packet. Next, in step S411, the arbitrary proxy node 110 determines whether the ALP response packet for the ALP request packet generated by itself is received, and receives the ALP response packet for the ALP request packet generated by the proxy node 110. In case S413, the ALP table is updated. In step S415, the packet is temporarily stored in the queue using the MAC address reported by the reply packet.

On the other hand, in step S403, when the procedure node 110 classifies the ALP type and receives the ALP request packet, the MAC address of the IP requested by the ALP packet in step S421 matches its interface address. Determine. For reference, the Ethernet ALP field of the ALP packet includes {sender MAC (MAC) address, sender IP (IP) address, recipient MAC (MAC) address, recipient IP (IP) address}}. If the MAC address of the IP requested by the ALP packet matches its interface address, the proxy node 110 generates an ARP response packet in step S423, and the port on which the corresponding ALP request packet is received in step S425. To send.

In addition, if the input packet is not an ARP response packet for an ARP request packet generated by the ARP packet, or if the MAC address of the IP requested by the ALP packet does not match its interface address, the proxy node in step S431. 110 floods the ALP packet.

The multicast MAC address table has {Port, Sender MAC (MAC), Multicast MAC (MAC)} as default tuples and is extensible. 6 shows a process of processing an IMP packet and maintaining a multicast MAC address table at the proxy node 110.

When the IGP packet is input in step S501, the proxy node 110 continuously manages the IGP join / leave / report message by performing SNP snooping in step S503 and determines the IMP type.

First, when the proxy node 110 filters the IGMP join or report message, the proxy node 110 searches for the multicast MAC address table in step S511. Next, in step S513, it is determined whether an entry already exists. In step S515, the entry is maintained for an existing entry. In case of an entry that does not exist in step S517, an IGP joiner is added to the multicast MAC address table. .

Next, the proxy node 110 requests the management server 150 to register the flow entry in step S519, and adds the flow entry received from the management server 150 to the local flow table in step S521. In this case, the S523 process of adding to the multicast MAC address table may be inserted immediately after adding to the flow table or immediately before requesting the flow registration to the management server.

When the proxy node 110 filters the IGMP leave message, the proxy node 110 searches for the multicast MAC address table in step S531 and deletes the IGMP joiner from the multicast MAC address table in step S533. Report to the management server 150 in step S535, and updates the flow entry of the flow table in step S537 based on the filtering rules sent by the management server. Next, in the S539 process, as in the IGMP join, the deleting of the joiner from the MAC address table can be performed immediately after updating the flow table.

In addition, in step S541, the proxy node 110 continuously snoops to determine the IGP type of the IGP packet.

Referring to FIG. 7, signal processing between the management server 150 and the proxy node 110 of the present invention is as follows.

When the proxy node 110 receives a multicast packet not registered in the flow table at the second layer, the proxy node 110 requests a flow entry from the management server 150 (h _α request). The management server 150 selects a neighboring node based on its topology map, determines a processing instruction (ACTION) of the flow, and transmits it to the proxy node 110 (C response). The proxy node 110, which has received the flow processing instructions from the management server 150, records the entry in the flow table (h _α register). The same flow received thereafter is forwarded with reference to the flow table. In this case, commands determined by the management server 150 are classified according to whether the host h _α is joined or sent.

8 to 11 illustrate a method in which an end host of an overlay network system joins and leaves a multicast group according to an embodiment of the present invention. 8 to 11 are diagrams illustrating a relationship between proxy nodes and end hosts for joining, updating status, leaving, and optimizing groups according to an embodiment of the present invention, respectively.

First, before describing how an end host joins and leaves a multicast group, the symbols and meanings used are defined as follows.

s (h _i , g) means sending multicast packets from end host h _i to group g without joining the group, and j (h _j , g) means IGMP on end host h _j ) Join to group g through a join message. And l (h _k , g) means that the host h _k withdraws from the group g through the IGMP leave message.

At this time, the nodes N _i and N _j may be connected in a bidirectional or unidirectional manner with respect to the group g, or may not have a connection configuration. The connection relationship indicates whether two neighboring proxy nodes 110 participate in the group g. In addition, the number of end hosts 140 participating in the group g through node N _α is defined as κ _α , and the number of connection relationships that node N _α has with other proxy nodes 110 is defined as μ _α . . The management server 150 has spanning tree information for the group g.

On the other hand, the flow table is divided into {filtering rules (RULES), processing rules (ACTION), statistics (STATISTICS)}. Referring to Table 1, the filtering rule part of the flow table has 12 tuples, [IN _port , IP, MAC _in-IP , IP _in-IP. ), TCP / UDP port (TCP)]. Where S _addr and D _addr Represent the transmission and destination IP addresses, respectively, and P _num represents the protocol number of the IP header. S _MAC and D _MAC represent the source and destination MAC addresses, and E _type represents the Ethernet _type of the MAC frame.

Finally, S _port and D _port are TCP / UDP send and destination port numbers. In this case, the MAC in IP and IP in IP have a value only when the IP packet is encapsulated in the IP in IP and IP in IP, respectively. For example, when a layer 2 frame, {MAC ', IP', TCP} is encapsulated in a MAC in IP, the corresponding IP packet is placed in layer 2 at {MAC, IP, { MAC ', IP', TCP}}. At this time, the IP of the filtering rule is the IP of the MAC (MAC) of the previous example and the IP of the IP is IP (IP). In the same way, if a layer 2 frame is encapsulated with IP in IP, it appears as {Mac, IP, {IP ', TCP}} in Layer 2, and MAC _in-IP is null. IP _in-IP corresponds to IP '.

IN _port
IP MAC _in-IP IP _in-IP TCP S _addr D _addr P _num S _MAC D _MAC E _type S _addr D _addr P _num S _port D _port

Reserved (8bit) Action (8bit) Mask (16bit)
MAC _in-IP S _MAC (MSB) S _MAC (LSB) D _MAC (MSB) D _MAC (LBS) IP _in-IP S _addr D _addr IP _in-IP IP P _num P _num IP
S _addr D _addr TCP / UDP S _port D _port

Table 2 shows the processing rule of the packet flow by the p-type filtering rule. Among the Action (8bit) field, 3 bits of MSB (Most Significant Bit) are not utilized and the lower 5 bits are used. The use of the lower 5 bits is defined in Table 3.

4 3 2 1 (modif.) 0 (popul.) Description One One One 0 0 discard the packet 0 0 0 0/1 0 do nothing or modif., only 0 0 0 0 One lookup m-type table 0 0 One 0/1 0/1 IP-in-IP encap., Wo / w modif. 0 One 0 0/1 0 IP-in-IP de-encap., Wo / w modif. 0 One One 0/1 0/1 MAC-in-IP encap. wo / w modif. One 0 0 0/1 0 MAC-in-IP de-encap., Wo / w modif.

For example, bit 1 (modif.) Is a header field based on a mask bit of a flow table ({IP, MAC-IN-IP, IP in IP, TCP}). Determine the change of. Bit 0 (popul.) Determines whether to add the m-type rule (ACTION). If set to '1', the packet is read by reading the m-type rule table. The m-type table is used for multipoint replication of packets.

Bits are classified as (4, 3, 2), modif., Popul., And execution order goes from left to right. That is, modif. Is popul. Is performed before. The Mask (16bit) field is executed when bit 1 (modif.) Of the Action field is set to 1 and modifies the field value of the p-type ACTION designated by each bit. MSB 6 bits are not used, only the remaining 10 bits are used, starting from bit 9 in descending order, {S _MAC , D _MAC , S _addr , D _addr , P _num (in-IP), P _num (IP), S _addr , D _addr , S _port , and D _port }.

Meanwhile, the representative fields {in _port , IP, MAC _in-IP , IP _in-IP , TCP} represented by the p-type filtering rule of Table 1 are shown. {p (i), p (g ₀ ), p (m _i ), p (g _i ), p (t)}. For example, tuples corresponding to the IP field of the p-type filtering rule are (S _addr , D _addr , P _num ) and are used in the same meaning as p (g ₀ ). When an update, such as adding or deleting a flow table, is required at the proxy node N _α , it may be indicated as shown in Table 1. Here, p-type RULES refers to p (g ₀ ) tuples, and ACTION (->) means to m (f _w ; β). m (f _w ; β) is an I / O command of the m-type rule table and 'forwarding to the proxy node N _β '. Additionally, m (f _d ) I / Os the m-type rules table, which means 'downlink flooding', and p (f _w ; β) I / Os the p-type rules table, and 'proxy' Forward to node N _β '.

As shown in FIG. 8, when the end host 140 generates an IMP join message, the management server 150 generates a multicast spanning tree based on the contents reported by the proxy nodes 110 receiving the message. Configure.

The management server 150 performs an initial connection setup algorithm as shown in ① of FIG. The management server 150 establishes a connection for the first received j (h _j , g) and s (h _i , g), configures a flow table according to an algorithm, and delivers it to N _i , N _j . Since N _i and N _j make requests by s (h _i , g) and j (h _j , g) respectively, N _i receives Equation 1 and N _j receives Equation 2 by the initial connection establishment algorithm. . At this time, N _i does not have a connection to N _j .

The management server 150 receives a new host, h _k is the j (h _k, g) transmitted to the proxy node N _k to join the group g from the interworking proxy node N _k messages as shown in ② of Fig. The node N _k informs the management server 150 of the request for participation in the group g of N _k . The management server 150 selects N _j as a proxy node to which N _k should interwork through a network topology map for group g. The node selection uses information such as geographical location, AS number, node degree, etc., and selects an optimal node among all the proxy nodes 110 included in the group. At this time, N _k and N _j have a bidirectional connection.

In addition, the management server 150 sends a j (h _m, g) to the host h _m N _m are as ③ in Fig. 8, N _m requests the flow table to the management server 150. The management server 150 may select N _k because N _j and N _k belong to the group. The flow table is determined by the connection establishment algorithm and delivered to each proxy node. At this time, N _k and N _m have a bidirectional connection.

And, if the management server 150 hosts h _n s (h _n, g) in a state that is not joined to the group g as shown in ④ of Figure 8, the node of the N _j, N _k, N _m that belong in a group It connects to the proxy node N _n by passing the flow table. If N _m is selected, then _{n n} and N _m have a one-way connection since h _n has not joined group g. At this time, N _n and N _m have a unidirectional connection relationship in order to prevent the multicast traffic from being transmitted from the proxy node N _m to the node N _n not participating in the group g.

In addition, the overlay network system of the present invention and a multicast method using the same utilize a low-cost NetFPGA, which is a Peripheral Component Interconnect (PCI) card. Since NetFPGA has a total of 4 ports of Gigabit Ethernet interfaces, except for one uplink port, The end host 140 may be connected through three ports.

Referring to FIG. 9, N _j and N _k in which an end host participates in group g are assigned to s (h _{j '} , g) or j (h _k' , g) of each new host h _{j '} and h _k' . The flow table is updated when a request of s (h _{j '} , g) or the like is rejected by the management server 150 without requiring an update of the table. A request for s (h _{j '} , g) or j (h _k' , g) is delivered to the management server 150. As defined in the management server 150, it is possible to block the packet flow of h _{j '} to send to the group g without participating in the group g according to the regulations.

When a new host h _{i '} sends a j (h _i' , g) message to N _i with no end hosts participating in group g (IGMP join), node N _i and adjacent node N _j connect the connection in a one-way connection. You must change from a relationship to a two-way connection.

The withdrawal of a group is done through an IGP leave message or a timer. The flow table for any packet flow maintains {filtering rules (RULES), processing rules (ACTION), statistics (STATISTICS)} and includes timers in the statistics. That is, the timer expires when the packet flow having the same filtering rule is not processed in the proxy node 110 for a specific time. The proxy node 110 regards the packet flow belonging to the expired RULES as an implicit group leaving, and deletes the corresponding {filtering rules (RULES), processing rules (ACTION), statistics (STATISTICS)} from the flow table. Group withdrawal is reported to the management server 150 when the withdrawal is triggered by a timer. Since all information related to group participation and withdrawal occurring in the proxy node 110 is transmitted to the management server 150, the management server 150 knows a connection relationship between all proxy nodes 110 belonging to the group g.

Finally, FIG. 10 is a topology map finally made when the hosts {h _{i '} , h _j , h _k' , h _m } of FIG. 9 leave the group g. First, in order to prevent a table update request due to frequent group departure of the end host 140, the group leave request is artificially delayed by the management server 150. That is, the group withdrawal by the timer or the IGP leave message is processed after a predetermined time elapses after being requested to the management server 150.

Referring to the nodes N _i and N _j of FIG. 9 by way of example, first, N _i forwards the l (h _{i '} , g) request message of the end host h _i' to the management server 150 and the management server 150. is to remove the portions related to downlink flooding of the nodes N _j of κ _j and μ _j is one by one, so N _j of the m-type processing rules, respectively, to prevent the proxy node N _j flowing traffic to the node N _i N _i is the delete packet forwarding command to the m-type flow node N _j of the table. Finally, the management server removes all proxy nodes 110 included in the set from the spanning tree when all proxy nodes 110 constituting the spanning tree do not have an end host participating in the group g. Instructs the flow table for group g.

On the other hand, the topology map for the group g can be finally optimized as shown in the thick line of Figure 11, but in the present invention, the optimization is not performed while the group g is maintained in consideration of the complexity and transmission quality.

As described above, the overlay network system of the present invention and the multicast method using the same are for IP (IP) multicast, the control plane and the data plane are separated, and the proxy node performs point-to-point or point-to-many forwarding in the data plane. In addition, the management server manages the proxy node in the control plane and configures the spanning tree to build and service the SeeOver infrastructure, and to participate in multilateral collaboration without changing the system settings by complying with existing IP protocol rules such as IGMP. It has an effect.

As described above, preferred embodiments of the present invention have been described, but the present invention is not limited to the above-described embodiments, and the present invention is not limited to the scope of the present invention as claimed in the following claims. Anyone with knowledge of the present invention will have the methodology of the present invention to the extent that various modifications can be made.

1 is a schematic diagram of an overlay network system according to an embodiment of the present invention;

2 is a schematic diagram illustrating the proxy node of FIG. 1;

3 and 4 are flowcharts illustrating a method of processing a MAC frame according to an embodiment of the present invention;

5 is a flowchart illustrating an ARP processing method according to an embodiment of the present invention;

6 is a flowchart illustrating an IGMP processing method according to an embodiment of the present invention;

7 is a diagram for signal processing between a management server and a proxy node of an overlay network system according to an embodiment of the present invention;

And,

8 to 11 are diagrams illustrating a relationship between proxy nodes and end hosts for joining, updating status, leaving, and optimizing groups according to an embodiment of the present invention, respectively.

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

100: overlay network system 110: proxy node

111: Arbiter 113: Information Base

119 physical layer 121 overlay engine

123: service daemon 115: MAC bridge

117: IP bridge 140: end host

150: management server

Claims (16)

delete A plurality of end hosts; Respectively connected to the plurality of end hosts in the data plane, monitoring participation and withdrawal of the multicast of the plurality of end hosts, and by IP-in-IP corresponding to the flow table received from the management server. A plurality of proxy nodes for moving packets; And the management server constituting a multicast spanning tree based on information received from the plurality of proxy nodes in a control plane, and setting a flow table for packet flow and transmitting the multicast spanning tree to the plurality of proxy nodes. In an overlay network system in which a plane and the control plane are separated and an IGMP protocol is applied between the plurality of end hosts and the plurality of proxy nodes, The plurality of proxy nodes, Hardware for performing IP (IP) packets and MAC (MAC) frame forwarding; And Software for processing communication protocols with the plurality of end hosts; Including, the hardware, An information base for storing information including the state of the flow table, MAC table, and overlay network system; Determines the types of frames and packets through MAC frames input through the physical layer, selects processing blocks according to the types of frames and packets, checks the maintenance and management IP checksum of the MAC table, and the information base An arbiter performing input and output of packets and frames using information included in the information; A MAC bridge that reads the MAC table stored in the information base to determine an output port, generates the MAC frame, and performs two-layer MAC switching; And An IP bridge that reads the flow table stored in the information base and encapsulates or decapsulates an IP packet to perform three-layer IP packet forwarding; Overlay network system comprising a. The method of claim 2, The management server configures a spanning tree based on the number of end hosts participating in the group through the requested node and the number of connection relationships that the node has with other proxy nodes. The method according to any one of claims 2 to 3, The flow table, And a filtering rule (RULES) and a processing rule (ACTION) for the packet flow. (a) the proxy node receiving the MAC frame; (b) the proxy node determining a destination MAC address of the received MAC frame; (c) determining, by the proxy node, a type of the received packet by reading a protocol number if the destination MAC address of the MAC frame is a multicast MAC address; (d) The proxy node searches for a filtering rule (RULES) of the flow table if the received packet is a multicast IP, and processes the software if the MAC address and protocol number of the received frame are IPMP packets. step; And (e) The proxy node requests a flow table from a management server if a filtering rule including information of the received MAC frame does not exist in the flow table, and performs a processing rule if the filtering rule exists. Doing; Multicast method using an overlay network system comprising a. The method of claim 5, And the proxy node communicates with the management server in the software to obtain the filtering rule if the filtering rule corresponding to the packet received in the flow table is not found. The method of claim 5, After step (b), Determining, by the proxy node, whether the received MAC address and the proxy MAC address match if the destination MAC address of the MAC frame is a unicast MAC address; The proxy node flooding if the received MAC address and the proxy MAC address do not match, and determining whether to encapsulate the received MAC frame if they match; The proxy node processing the received MAC frame in software through a TCP / UDP port when the received MAC frame is not encapsulated, and determining whether a filtering rule exists in the flow table when the received MAC frame is encapsulated; And Requesting, by the proxy node, the flow table from the management server if there is no filtering rule including information of the received MAC frame in the flow table, and performing a processing rule if there is one; Multicast method using an overlay network system comprising a. The method of claim 7, wherein If the proxy node does not match the proxy MAC address and the MAC address of the received frame, flooding the proxy node; Multicast method using an overlay network system, characterized in that it further comprises. The method of claim 7, wherein And the proxy node communicates with the management server in the software to obtain the filtering rule if the filtering rule corresponding to the packet received in the flow table is not found. (a) the proxy node receiving the MAC frame; (b) the proxy node determining a destination MAC address of the received MAC frame; (c) determining, by the proxy node, an input port of a packet if the destination MAC address of the received MAC frame has a multicast address; (d) flooding the proxy node if it is input through a downlink port without processing if the received multicast frame is input through an uplink port; (e) the proxy node processing the software if the multicast frame inputted through the downlink port includes an IMP packet and searching for a flow table if not included; And (f) the proxy node processing the software when the filtering rule corresponding to the packet is not found in the flow table, and performing a processing rule when the proxy node is found; Multicast method using an overlay network system, characterized in that it comprises a. The method of claim 10, And if the multicast frame input through the downlink port includes an IGMP packet, the proxy node processes the IGMP protocol in software. (a) the proxy node receiving the MAC frame; (b) the proxy node determining a destination MAC address of the received MAC frame; (c) the proxy node determining whether the MAC address of the proxy node matches the MAC address of the received frame if the destination MAC address of the received MAC frame is a unicast address; (d) the proxy node flooding if the MAC address of the proxy node and the MAC address of the received frame do not match; (e) the proxy node processing the software if the packet is not encapsulated as a result of the determination of the encapsulation; if the packet is an encapsulated packet, searching the flow table to search for a filtering rule corresponding to the encapsulated packet; And (f) the proxy node processing in the software if a filtering rule corresponding to the encapsulated packet is not found in the flow table, and performing a processing rule if found; Multicast method using an overlay network system comprising a. (a) the proxy node receiving the MAC frame; (b) the proxy node determining a destination MAC address of the received MAC frame; (c) the proxy node, if the destination MAC address of the received MAC frame has a broadcast address, determining whether an ALP packet is read by reading an Ethernet Type field value of a header; (d) the proxy node, if the Ethernet type field value of the header is an ALP packet, distinguishing a type of an ALP packet input by software; (e) determining whether the proxy node receives an ARP response packet for an ARP request packet generated by the proxy node; (f) updating the ALP table when the proxy node receives an ALP response packet for the ALP request packet generated by the proxy node; And (g) transmitting a packet temporarily stored in a queue using the MAC address reported by the proxy node response packet; Multicast method using an overlay network system comprising a. The method of claim 13, After step (d), Determining, by the proxy node, that the MAC address of the IP requested by the ALP packet matches its interface address when the ALP request packet is received; Generating, by the proxy node, an ALP response packet if the MAC address of the IP requested by the ALP packet matches its interface address; And Transmitting, by the proxy node, to a port on which an ARP response packet is received; Multicast method using an overlay network system comprising a. The method of claim 14, The proxy node is a packet if the input packet is not an ARP response packet for the ARP request packet generated by the proxy node or if the MAC address of the IP requested by the ALP packet does not match its interface address. Flooding the multicast method using an overlay network system. The method according to any one of claims 5 to 15, The flow table includes a processing rule including a filtering rule for the packet flow and a method of replicating, forwarding, and flooding the packet. The filtering rule, IN _port ; An IP including an IP address of a transmission and a destination, a protocol number of an IP header; MAC _in-IP including a send and destination MAC address and an Ethernet type of the MAC frame; An IP _in-IP including an IP address of a transmission and a destination and a protocol number of the IP header; And And a TCP / UDP port (TCP) including a transmission and a destination port number.

Images