KR20250060392A - SDN controller device for generating network topology - Google Patents

Abstract

The present invention relates to an SDN control device for constructing a network topology. According to an embodiment of the present invention, the SDN control device may include: a transceiver for transmitting and receiving messages with SDN switches connected to the SDN control device; an LD tag generation unit for generating an LD packet including an LD tag that accumulates and stores connection information at each hop when receiving a port status message from a first SDN switch; a control unit for controlling the LD packet to be transmitted to the first SDN switch by including it in a packet-out message; and an update unit for extracting connection information of at least one network switch connected between the first SDN switch and the second SDN switch from the LD tag included in the LD packet when receiving a packet-in message for processing the LD packet from a second SDN switch, and updating the network topology based on the connection information.

Description

{SDN controller device for generating network topology}

The present invention relates to a software defined network (SDN) control device for generating an accurate topology for a network based on software defined network (SDN).

Software Defined Network (SDN) refers to a centralized networking structure that separates the data plane and control plane that make up existing network equipment, and allows the control plane to be responsible for overall processing related to management, monitoring, and control of the network.

The function of the control plane can be performed by the SDN controller, and the SDN controller can control each connected network device by utilizing standardized interfaces such as OpenFlow and NetConf.

The SDN controller can provide the network manager with abstracted network resource information that is collectively collected from connected network devices, and the network manager can perform flexible network operation with optimized performance based on the abstracted network information. For example, the SDN controller can generate a topology map from the connection information of the network devices connected in the SDN-based network, and thus provide the network manager with high visibility of the entire network. In other words, the network manager can perform rapid fault detection, efficient resource management, and policy application, etc. from the topology map.

However, if existing legacy switches and other general network devices are included in the software-defined network, it may be difficult to create an accurate topology map, and it may be difficult for network managers to accurately identify the location of the device that has failed when a network failure occurs. These errors in the topology map may become more severe as the number of general network devices connected to the SDN switch increases and the complexity of the network increases.

Korean Patent Publication No. 10-2017-0081422

The present invention aims to provide an SDN control device that constructs a network topology based on a reactive packet processing method and can generate an accurate topology map even when a legacy switch is included in the network.

The present invention aims to provide an SDN control device that constructs a network topology, which can generate a topology map reflecting connection information for legacy switches using an existing SDN control device without separate additional equipment.

The present invention aims to provide an SDN control device that constructs a network topology by generating a topology map using an LD (Link Discovery) tag for collecting connection information for a legacy switch.

In a software defined network (SDN) environment to which a reactive packet processing method according to one embodiment of the present invention is applied, an SDN control device for constructing a network topology may include: a transceiver for transmitting and receiving messages with SDN switches connected to the SDN control device; an LD tag generation unit for generating an LD packet including an LD tag that accumulates and stores connection information at each hop when receiving a port status message from a first SDN switch; a control unit for controlling the LD packet to be transmitted to the first SDN switch by including it in a packet-out message; and an update unit for extracting connection information of at least one network switch connected between the first SDN switch and the second SDN switch from the LD tag included in the LD packet when receiving a packet-in message for processing the LD packet from a second SDN switch, and updating the network topology based on the connection information.

Here, the LD packet may be set to be transmitted in a broadcasting manner between the first SDN switch and the second SDN switch. In addition, the LD packet may be generated using an LD frame that further includes a field including the LD tag in an Ethernet frame structure.

Here, the LD tag may include a hop count field that counts the number of hops through which the LD packet is transmitted, a connection information field that accumulates and stores identification information (DPID: Datapath Identification) and port information at each hop, and may further include a maximum hop count (idle count) that is the maximum number of hops through which the LD packet can be transmitted.

An SDN control device according to one embodiment of the present invention may further include a policy setting unit that generates an LD flow policy (flow rule) for transmitting the LD packet to a network switch connected to the first SDN switch and sets it in the first SDN switch.

Here, the policy setting unit may determine, from the port status message, a port among the ports included in the first SDN switch whose status has changed to Up, and generate the LD flow policy to transmit the LD packet to the network switch through the port.

Here, if a packet-in message for processing the LD packet is not received within the maintenance time of the LD flow policy, the control unit can cause the policy setting unit to reset the LD flow policy and retransmit the LD packet.

Here, the update unit may extract identification information and port information of the network switches connected at each hop from the connection information, and sequentially connect the input ports and output ports of the network switches according to the order of the hops, thereby adding a network topology between the first SDN switch and the second SDN switch.

Here, the update unit may search for each network switch included in the connection information in a reference database including a list of SDN switches connected to the SDN control device, and update the searched network switches with the SDN switches to create a topology map table.

Here, the update unit may generate a network topology of the network switches included between the first SDN switch and the second SDN switch based on the topology map table.

Here, the control unit may determine whether the network switch connected to the first SDN switch is an SDN switch when receiving the port status message.

Here, the control unit may, assuming the network switch to be the SDN switch, include an LLDP (Link Layer Discovery Protocol) packet for confirming connection information of the network switch in a packet-out message and transmit it to the first SDN switch.

Here, the control unit may determine that the network device is not the SDN switch if a packet-in message corresponding to the LLDP packet is not received from the network device.

Here, the policy setting unit may set an LLDP flow policy for transmitting the LLDP packet to the network device to the first SDN switch.

Here, the policy setting unit may determine, from the port status message, a port among the ports included in the first SDN switch whose status has changed to Up, and generate the LLDP flow policy to transmit the LLDP packet to the network switch through the port.

Here, the control unit can determine that it is not the SDN switch if the packet-in message is not received within the maintenance time of the LLDP flow policy.

In a software defined network (SDN) environment to which a reactive packet processing method according to one embodiment of the present invention is applied, a computing device for constructing a network topology may include a processor, wherein the processor may perform the following operations: receiving a port status message from a first SDN switch; including an LD (Link Discovery) tag, which accumulates and stores connection information at each hop in response to the port status message, in a packet-out message and transmitting the LD packet to the first SDN switch; extracting the LD tag from the LD packet when receiving a packet-in message for processing the LD packet from a second SDN switch; and extracting connection information of at least one network switch connected between the first SDN switch and the second SDN switch from the LD tag and updating the network topology based on the connection information.

Here, the processor may further include performing, upon receiving the port status message, determining whether the network switch connected to the first SDN switch is an SDN switch.

Here, determining whether the network switch is the SDN switch may further include: assuming the network switch to be the SDN switch, including an LLDP (Link Layer Discovery Protocol) packet for confirming connection information of the network switch in a packet-out message and transmitting it to the first SDN switch; and if a packet-in message corresponding to the LLDP packet is not received from the network device, determining that the network device is not the SDN switch.

In addition, the solution to the above-mentioned problem does not enumerate all the features of the present invention. The various features of the present invention and the advantages and effects thereof can be understood in more detail by referring to the specific embodiments below.

According to an SDN control device for constructing a network topology according to one embodiment of the present invention, it is possible to identify connection information not only for SDN switches included in an SDN-based network, but also for general L2/L3 switches included therebetween. Accordingly, a real-time network topology map can be created by reflecting connection information for legacy switches, etc., and even in the event of a network failure, it is possible to quickly identify the location of the failure, etc., and perform failover, etc.

According to an SDN control device that constructs a network topology according to one embodiment of the present invention, it is possible to create a topology map reflecting connection information for legacy switches by using an existing SDN control device without separate additional equipment. Accordingly, time and cost for installing additional equipment, etc. can be reduced, and detection and inquiry for network equipment can be provided simply.

However, the effects that can be achieved by the SDN control device that constructs the network topology according to the embodiments of the present invention are not limited to those mentioned above, and other effects that are not mentioned will be clearly understood by those skilled in the art to which the present invention belongs from the description below.

Figure 1 is a schematic diagram showing an SDN-based network structure according to one embodiment of the present invention.
Figure 2 is a schematic diagram showing status information update of an SDN switch according to one embodiment of the present invention.
Figures 3 and 4 are schematic diagrams showing a reactive packet processing method according to one embodiment of the present invention.
Figures 5 to 7 are schematic diagrams showing topology generation for an SDN switch of an SDN control device according to one embodiment of the present invention.
Figures 8 to 10 are schematic diagrams showing terminal information updates of an SDN control device.
Figures 11 to 14 are schematic diagrams showing problems that occur when creating a topology using LLDP messages.
Figure 15 is a block diagram showing an SDN control device according to one embodiment of the present invention.
Figure 16 is a schematic diagram showing the frame structure of an LD packet according to one embodiment of the present invention.
Figure 17 is a schematic diagram showing the creation of an LD tag that accumulates and stores connection information in each case according to one embodiment of the present invention.
Figure 18 is a schematic diagram showing the creation of a topology map table using an LD tag and a reference database according to one embodiment of the present invention.
Figure 19 is a schematic diagram showing the creation of a topology map using a topology map table according to one embodiment of the present invention.
Figures 20 to 26 are schematic diagrams showing the construction of a network topology of an SDN control device according to one embodiment of the present invention.
FIG. 27 is a block diagram showing a computing device that constructs a network topology in a software-defined network environment to which a reactive packet processing method according to one embodiment of the present invention is applied.

Hereinafter, embodiments disclosed in the present specification will be described in detail with reference to the attached drawings. Regardless of the drawing symbols, identical or similar components will be given the same reference numerals and redundant descriptions thereof will be omitted. The suffixes "module" and "part" used for components in the following description are given or used interchangeably only for the convenience of writing the specification, and do not have distinct meanings or roles in themselves. That is, the term "part" used in the present invention means a hardware component such as software, FPGA, or ASIC, and the "part" performs certain roles. However, the "part" is not limited to software or hardware. The "part" may be configured to be in an addressable storage medium or may be configured to reproduce one or more processors. Thus, as an example, a 'part' may include components such as software components, object-oriented software components, class components and task components, processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays and variables. The functionality provided within the components and 'parts' may be combined into a smaller number of components and 'parts' or further separated into additional components and 'parts'.

In addition, when describing the embodiments disclosed in this specification, if it is determined that a detailed description of a related known technology may obscure the gist of the embodiments disclosed in this specification, the detailed description thereof will be omitted. In addition, the attached drawings are only intended to facilitate easy understanding of the embodiments disclosed in this specification, and the technical ideas disclosed in this specification are not limited by the attached drawings, and should be understood to include all modifications, equivalents, and substitutes included in the spirit and technical scope of the present invention.

Figure 1 is a schematic diagram showing a network structure based on a software defined network (SDN) according to one embodiment of the present invention.

Referring to FIG. 1, an SDN-based network according to one embodiment of the present invention may include an SDN control device (100), a reference database (D), SDN switches (S1, S2), legacy switches (L1, L2), and a terminal device (1).

Hereinafter, an SDN-based network structure according to one embodiment of the present invention will be described with reference to FIG. 1.

The SDN control device (100) may be a network device in which an SDN controller that performs the function of a control plane within an SDN-based network is installed. The SDN control device (100) may be implemented as a physical server, a virtualization device within a cloud server, etc.

The SDN control device (100) can centrally manage and control each connected SDN switch (S1, S2), and perform various functions such as topology creation for the SDN switches (S1, S2), and flow policy setting for packet processing. Here, the SDN control device (100) can perform control over the SDN switches (S1, S2) through a dedicated SDN protocol. The SDN protocol may include OpenFlow, NETCOF, etc., and any protocol for implementing a software-defined network may be applied.

The SDN control device (100) can check the functions supported by the SDN switch (S1, S2) by exchanging a FeatureRequest message and a Reply message thereto with the connected SDN switch (S1, S2). The SDN control device (100) can send necessary settings to the SDN switch (S1, S2) or, as illustrated in Fig. 2(a), collect status information of the SDN switch (S1, S2). Here, when exchanging messages, if there is no flow policy for processing a packet that entered the SDN switch (S1, S2) from the terminal device (1) or if the action of the flow policy is the SDN control device (100), the SDN switch (S1, S2) can transmit a message to the SDN control device (100), and at this time, the corresponding message can be defined as a Packet-In message. Conversely, in response to a packet-in message, a response message that the SDN control device (100) sends to the SDN switch (S1, S2) can be defined as a packet-out message. In the case of a packet-in message, each SDN switch (S1, S2) must register a flow policy that designates the destination of the packet as the SDN control device (100) in order to operate, and the registered flow policy corresponds to the packet-in policy.

SDN switches (S1, S2) are network devices such as switches, L2 switches, routers, and wireless APs included in an SDN-based network, and may support the SDN protocol. That is, the SDN switches (S1, S2) may perform packet processing according to the control of the SDN control device (100) through the SDN protocol.

Here, the SDN switches (S1, S2) can be connected to legacy switches (L1, L2) that do not support the SDN protocol, as illustrated in Fig. 1, and at this time, the legacy switches (L1, L2) can be located between the SDN switches (S1, S2). That is, in the case of an SDN-based network, the SDN switches (S1, S2) can be directly connected to the SDN control device (100), and the SDN switches (S1, S2) can be implemented so that they are located at the end connected to the terminal device (1).

The reference database (D) can store status information of SDN switches connected to the SDN control device (100). As shown in Fig. 2(b), the status information can include DPID (Datapath Identification), which is identification information for distinguishing each SDN switch, the amount of traffic throughput transmitted and received by each SDN switch, the number of packets transmitted and received, etc. In addition, the status information may include the IP (Internet Protocol) address of the SDN switch (S1, S2), time information connected to the SDN control device (100), the total number of SDN switches (S1, S2) connected to the SDN control device (100), connection links, the number of connected terminal devices (1), flow policy or group policy information registered in the SDN switch (S1, S2), byte count, transmission speed, and packet count information according to the flow policy or group policy registered in the SDN switch (S1, S2), flow table entry size or group table entry size information registered in the SDN switch (S1, S2), status information for each port of the SDN switch (S1, S2) (whether Enabled/Disabled, port transmission speed, RX/TX traffic processing volume), the number of packets received, delayed, and with errors occurring for each port of each SDN switch (S1, S2), etc. Here, the status information can be updated at regular intervals, and the reference database (D) can store the status information received from the SDN control device (100).

Meanwhile, the reference database (D) may include a high-speed random access memory, and may also include a non-volatile storage device such as a magnetic disk storage device or a flash memory device. In addition, the reference database (D) may further include a network-attached storage device that is accessed via a communication network such as the Internet, an intranet, a LAN, a WLAN, a SAN (Storage Area Network), or an appropriate combination thereof. The reference database (D) may exist separately from the SDN control device (100) as in FIG. 1, or may exist integrated with the SDN control device (100).

The terminal device (1) may be a host device that connects to an SDN-based network, and may be a server that provides network services, a user terminal such as a computer that receives network services, etc. The terminal device (1) may generate a packet for transmitting data to another terminal device through the network, and may transmit the generated packet through an SDN switch (S1, S2). Here, the terminal device (1) may be a device such as an actual physical server, but depending on the embodiment, it may also be implemented as a virtual machine, etc.

Meanwhile, the SDN control device (100) may utilize a reactive packet transmission method. That is, when an unknown packet not defined in the flow policy enters the SDN switch (S1, S2), the SDN switch (S1, S2) can request the SDN control device (100) for a processing method for the packet, and the SDN control device (100) can search for an optimal path and provide a processing method for the packet.

Specifically, referring to FIG. 3, when a data packet is to be sent from terminal device #1 to terminal device #2, terminal device #1 can transmit the corresponding packet to the SDN switch. However, the SDN switch may not have a flow policy set for processing the corresponding packet. In this case, the SDN switch may store the corresponding data packet in a buffer according to the reactive method and transmit some data including the header of the corresponding packet to the SDN control device (100) through a packet-in message, thereby inquiring the SDN control device (100) about processing the corresponding data packet.

Here, the SDN control device (100) can receive information about terminal devices detected through an ARP (Address Resolution Rotocol) message transmitted by the SDN switch when first connected to the SDN switch, and can compile the information to configure a topology map. Accordingly, the SDN control device (100) can extract a path for sending a packet of terminal device #1 to terminal device #2 from destination information included in the header information of a packet transmitted as a packet-in message based on the topology map.

Thereafter, as illustrated in FIG. 4(a), the SDN device (100) can transmit a flow policy setting (Flow modify) message, such as an OFTP_FLOW_MOD message, to the SDN switch, thereby enabling the SDN switch to set a flow policy for processing the corresponding data packet. That is, as illustrated in FIG. 4(a), a flow policy can be set in the flow table of the SDN switch to transmit a packet to the output port (Out Port) "2" if the input port (In port) is "1", the source MAC address (Src MAC) is "a", and the destination MAC address (Dst MAC) is "b". At this time, the idle time of the corresponding policy can be set to 3 seconds.

Referring to FIG. 4(b), the SDN control device (100) can set the destination address of the data packet stored in the buffer of the SDN switch through a packet-out message, and the SDN switch can check whether the input data packet satisfies the corresponding flow policy through the Match field of the flow policy. That is, if the input port is "1", the source MAC address is terminal device #1, and the destination MAC address is terminal device #2, the Match field is satisfied, and therefore, according to the definition of the Action field, the data packet can be transmitted to the output port "2" to deliver the data packet to terminal device #2. Here, the retention time of the flow table corresponds to the time that the corresponding flow policy is maintained. That is, if a packet matching the corresponding flow policy is not transmitted within the retention time, the retention time may not be updated, and the flow policy may be automatically deleted.

Meanwhile, the SDN control device (100) can know the existence of SDN switches (S1, S2) connected to it from the status information of the SDN switches (S1, S2), but cannot determine specifically how they are connected. In other words, it can know how many SDN switches (S1, S2) are currently connected, but cannot know what is connected to each port of the corresponding SDN switch (S1, S2). To solve this problem, the SDN control device (100) can use an LLDP (Link Layer Discovery Protocol) packet. That is, the SDN control device (100) can identify the connection between SDN switches and generate a topology map by using an LLDP packet, a packet-in message, and a packet-out message.

Referring to Fig. 5(a), three upper SDN switches can be connected to the management port (m port) of the SDN control device (100), respectively, and the SDN control device (100) can identify the status information of the connected SDN switches. Thereafter, port 1 of SDN switch #3 and port 2 of SDN switch #2 can be physically connected, and in this case, the status of port 1 of SDN switch #3 can be changed from down to up.

When the status of the port changes, the SDN switch #3 can generate a port status message as illustrated in Fig. 5(b) and transmit the change in the port to the SDN control device (100). In this case, the SDN control device (100) can generate an LLDP packet as illustrated in Fig. 6(a) and include it in a packet-out message, and transmit the packet-out message to the SDN switch #3 so that it is transmitted through port 1 of the SDN switch #3.

Thereafter, as shown in Fig. 6(b), SDN switch #3, which has received the packet-out message, can forward the LLDP packet included in the packet-out message to SDN switch #2 through port 1 of SDN switch #3. However, since SDN switch #2, which has received the LLDP packet, does not know how to process the LLDP packet, SDN switch #2 can include the LLDP packet in the packet-in message and forward it to the SDN control device (100).

Finally, as illustrated in Fig. 7, the SDN control device (100) can confirm that port 1 of SDN switch #3 and port 2 of SDN switch #2 are currently connected to each other since the LLDP packet transmitted to SDN switch #3 is retransmitted through SDN switch #2. Thereafter, whenever a port status message is received, the SDN control device (100) can identify connection information between SDN switches using the LLDP packet.

In this way, the SDN control device (100) can identify connection information between SDN switches using LLDP packets and create a topology map using this. Each SDN switch can detect a connected terminal device (1) using an ARP (Address Resolution Protocol) message and transmit it to the SDN control device (100) along with the DPID, port number, etc. of the corresponding SDN switch. Accordingly, the SDN control device (100) can update the topology map by reflecting information about the terminal device (1), etc., in the topology map.

Meanwhile, the SDN control device (100) can update the terminal device (1) information of the topology map by updating the information about the terminal devices (1) connected to the SDN switch whenever a packet is transmitted. For example, as shown in Fig. 8, when it is assumed that the terminal device #1 sends a data packet to communicate with the terminal device #2, the SDN control device (100) can update the host information based on the source IP (10.0.0.1) and source MAC address (a) included in the header of the corresponding packet.

Thereafter, terminal device #1 can transmit a data packet to SDN switch #1 for communication with terminal device #2. As illustrated in Fig. 9(a), since SDN switch #1 does not have a flow policy set for processing a packet received from terminal device #1, the packet can be transmitted to SDN control device (100) as a packet-in message. As illustrated in Fig. 9(b), SDN control device (100) can update and store terminal device information connected to SDN switch #1 based on the source IP and source MAC addresses included in the header of the packet. In other words, the IP address and MAC address of the terminal device #1 can be updated and reflected on the topology map.

Thereafter, as illustrated in Fig. 10(a), the SDN control device (100) can extract a path for transmitting the received packet to terminal device #2 using the received packet, and register a flow policy for transmitting the packet by specifying the ports of SDN switch #1, SDN switch #2, and SDN switch #3 included in the path.

That is, as illustrated in Fig. 10(b), the packet of terminal device #1 can be transmitted to terminal device #2 according to the flow policy registered in each SDN switch. Here, the SDN control device (100) can configure a topology map by combining the connection information of the lower-connected SDN switches and the information of the terminal device (1) connected to the SDN switch. However, since this is possible only when the SDN control device (100) can send and receive LLDP packets, packet-in messages, packet-out messages, etc. from the SDN switch, if other general switches such as legacy switches are connected between the SDN switches, the accuracy of the generated topology map may decrease.

For example, as illustrated in Fig. 11(a), there may be a case where a general L2 switch is connected between SDN switch #1 and SDN switch #2. Here, SDN switch #1 and SDN switch #2 are each connected to the SDN control device (100), but the general L2 switch is not connected to the SDN control device (100). That is, since the general L2 switch does not support the SDN protocol, connection with the SDN control device (100) is impossible.

As illustrated in Fig. 11(b), information on port 1 of SDN switch #2 can be changed from down to up when connected to a general L2 switch, and SDN switch #2 can generate a port status message to transmit the changed information on port 1 to the SDN control device (100). In this case, as illustrated in Fig. 12(a), the SDN control device (100) can generate an LLDP packet and include it in a packet-out message, and transmit the packet-out message to SDN switch #2 to transmit the LLDP packet through port 1 of SDN switch #2.

Thereafter, as illustrated in FIG. 12(b), the SDN switch #2, which has received the packet-out message, transmits the LLDP packet to the general L2 switch through port 1 of the SDN switch #2. However, the general L2 switch cannot transmit the LLDP packet to the unconnected SDN control device (100), and cannot process it, so the LLDP packet may be discarded. That is, as illustrated in FIG. 13, the SDN control device (100) may know that another device is connected to port 1 of the SDN switch #1, but may not know which device is connected.

The SDN control device (100) can transmit an LLDP packet to a general L2 switch through port 1 of the SDN switch #1, which is connected to the general L2 switch, in the same manner, but even in this case, the general L2 switch may not process the LLDP packet and may discard it. Accordingly, as illustrated in Fig. 14, the SDN control device (100) may be in a state where it can know that another device is connected to port 1 of the SDN switch #1, but does not know which device is connected.

In this way, the actual network has a connection structure in which one general L2 switch is connected like a stepping stone between two SDN switches, but the topology map recognized by the SDN control device (100) may be generated in a form in which an unknown device is separately connected to each SDN switch. In other words, an incorrect network topology map is configured. Such an error in the topology map may become more severe as the number of general network devices connected to the SDN switch increases or the complexity of the SDN-based network increases. If an error in the topology map occurs, the accurate connection information between the actual network devices cannot be confirmed through the SDN control device (100), so it becomes difficult for the network manager to identify the network path information used by each customer. In addition, if a failure occurs in the network, it becomes difficult to identify the exact location of which device has the failure.

Meanwhile, according to the SDN control device (100) according to one embodiment of the present invention, even when legacy switches, etc. are included between SDN switches, it is possible to generate an accurate topology map. That is, since it is possible to generate a topology map including legacy switches, etc. using the SDN control device (100) without installing a separate external device, etc., it is possible to quickly identify the location, etc. when a network failure occurs. Hereinafter, the SDN control device according to one embodiment of the present invention will be described with reference to FIG. 15.

Figure 15 is a block diagram showing an SDN control device according to one embodiment of the present invention.

Referring to FIG. 15, an SDN control device (100) according to one embodiment of the present invention may include a transmission/reception unit (110), an LD tag generation unit (120), a control unit (130), a policy setting unit (140), and an update unit (150).

The transceiver (110) can transmit and receive messages with the SDN switches (S1, S2) connected to the SDN control device (100). For example, when a new connection is created in its port, the SDN switch (S1, S2) can transmit a port status message to the SDN control device (100). That is, when a new connection is created in its port, the SDN switch (S1, S2) can change the information of the port from down to up, and the SDN switch can generate a port status message and transmit the changed port status information to the SDN control device (100). At this time, the SDN control device (100) can receive the port status information transmitted by the SDN switches (S1, S2) through the transceiver (110). In addition, the transceiver (110) can transmit and receive various messages, such as receiving status information of each SDN switch (S1, S2), packet-in messages, and transmitting packet-out messages.

When the LD tag generation unit (120) receives a port status message from the first SDN switch (S1), it can generate an LD packet including an LD (Link Discovery) tag that accumulates and stores connection information at each hop. That is, when a general network device such as a legacy switch that is not compatible with SDN exists between the terminal SDN switches, an LD packet including a separate LD tag can be generated and distributed in order to identify the connection information of the general network device. At this time, the LD packet can be set to be transmitted in a broadcasting manner.

Here, the LD packet can be generated as a frame structure that further includes an LD tag in a general Ethernet frame structure. Fig. 16(a) is an Ethernet frame structure according to the standard, and Fig. 16(b) is a frame structure of an LD packet. That is, referring to Fig. 16(b), the frame structure of the LD packet can be defined by adding an LD tag of 4 bytes between the Source MAC Address field and the Ethernet Type field of the standard Ethernet frame structure.

Here, the LD tag may include a Hop Count field that counts the number of hops through which the frame of the LD packet is transmitted, a Maximum Hop Count field that is the maximum number of hops that can be transmitted, and a Connection Information field that accumulates and stores switch identification information (DPID) and port information corresponding to each hop in a list format as each hop is passed.

Referring to Fig. 17, the LD tag in the initial state has a hop count field of 0, a maximum hop count field of 3, and a connection information field may not have an input value. Thereafter, an LD packet including the LD tag in the initial state can be made to pass through each of five switches whose DPIDs are a, b, c, d, and e. Here, each of the switches can be an SDN switch or a legacy switch. At this time, looking at the field values in the LD tag, first, as shown in Fig. 17(a), when the LD tag is transmitted from switch #1 to switch #2, the hop count of the LD tag can be 1, which is increased by 1 from 0, because it passed through one switch. In addition, the maximum hop count can be 2, which is decreased by 1 from 3, because one of the maximum number of hops that can be passed has already passed. For connection information, if switch #1 is considered as the first hop, hop1, there is no input port for switch #1, so the input port can be set to 0, and since the LD packet is transmitted to switch #2 through port 1 of switch #1, the output port can be set to 1. Also, since the DPID of switch #1 is "a", this can be expressed in list form as HOP1: {0, 1, a}.

Next, as illustrated in Fig. 17(b), since the LD packet was transmitted from Switch #2 to Switch #3, the hop count of the LD tag increases by 1 from 1 to 2, and the maximum hop count decreases by 1 from 2 to 1 because one more hop has passed from the maximum number of hops that can pass. In the case of connection information, if Switch #2 is regarded as one hop, Hop2, the frame entered through Port 2 of Switch #2, so the input port is 2, the LD packet was transmitted to Switch #3 through Port 3, so the output port is 3, and since the DPID of Switch #2 is "b", HOP2:{2, 3, b}, which is expressed in the form of a list, can be added.

Finally, as illustrated in Fig. 17(c), since the LD packet is transmitted from Switch #3 to Switch #4, the hop count of the LD tag increases from 2 to 3, and the maximum hop count decreases from 1 to 0, since it is one more hop than the maximum number of hops that can be passed. In addition, in the case of connection information, if Switch #3 is regarded as one hop, Hop3, the frame enters through Port 1 of Switch #3, so the input port is Port 1, and the LD packet is transmitted to Switch #4 through Port 3, so the output port is Port 3. Since the DPIP of Switch #3 is "c", HOP3:{1, 3, c}, which is expressed in the form of a list, can be added. After this, since the maximum hop count is 0, LD packets are no longer transmitted and can be stopped.

In some embodiments, the hop count and the maximum hop count can be set to a size of 1 byte, in which case a maximum of 256 hops can be set. That is, it is possible to collect information for a maximum of 256 switches. Here, the network manager can set the maximum hop count to an arbitrary value within the set size (for example, 1 byte). That is, the maximum hop count can be used to prevent the capacity of the LD packet from becoming excessively large. However, the present invention is not limited thereto, and the hop count and the maximum hop count can be set to a size other than 1 byte, and an embodiment in which the maximum hop count is not set is also possible.

The control unit (130) can control to transmit the LD packet to the first SDN switch (S1) by including it in the packet-out message. That is, the control unit (130) can request the policy setting unit (140) to create an LD flow policy that states, 'Send packets whose Ethernet type (EtherType) is LD frame (0x88EE) to the port defined in PORT_NO.' In this case, the policy setting unit (140) can create an LD flow policy and transmit a corresponding flow policy setting message to the first SDN switch. The first SDN switch (S1) that receives the corresponding flow policy setting message can register the LD flow policy in the flow table. Here, the Ethernet type (0x88EE) of the LD frame is an example, and can be defined and utilized as an arbitrary value that does not overlap with standard Ethernet types.

In addition, the control unit (130) can cause the LD tag generation unit (120) to set the destination MAC address in the LD frame to a broadcast address (FF:FF:FF:FF:FF:FF), and can cause the source MAC address to be set to the MAC address of the SDN control device (100). Furthermore, the Ethernet type (EtherType) can be set to indicate an LD frame (0x88EE), the hop count of the LD tag can be set to 0, and the maximum hop count can be set to an arbitrary value set by a network manager or the like among 1 to 256. Finally, the connection information of the LD tag can be defined as Hop1 because the data frame including the corresponding LD tag is already primarily transmitted to the first SDN switch (S1), and there is no input port, so it can be 0, the output port can be PORT_NO, and the DPID value of the SDN switch that transmitted the port status message can be defined in the form of a list in the form of Hop1:{0, PORT_NO, DPID}. Thereafter, the control unit (130) can transmit the LD packet including the corresponding LD tag to the first SDN switch (S1) via a packet-out message.

The first SDN switch (S1) that receives the LD packet through the packet-out message can forward the LD packet to the port number defined as PORT_NO according to the LD flow policy. Here, since the destination MAC address of the LD packet is designated as a broadcast address, the LD packet can be transmitted to all network devices connected to each port of the first SDN switch (S1). However, the network device connected to the input port (here, the SDN control device (100)) can be excluded.

Finally, when the LD packet is transmitted to the second SDN switch (S2) within the maximum hop count of the LD tag, the second SDN switch (S2) that receives it can include the LD packet in a packet-in message and transmit it to the SDN control device (100).

However, if there is no LD packet transmitted as a packet-in message to the SDN control device (100) within the maintenance time of the LD flow policy registered in the first SDN switch (S1) that initially transmitted the LD packet, the control unit (130) may request the LD tag generation unit to regenerate the LD packet and transmit the LD packet. If the LD packet is not transmitted again within the maintenance time thereafter, it may be determined that there is no second SDN switch (S2) connected to the first SDN switch (S1), and the topology map configuration may be terminated. That is, since the LD packet is transmitted to identify general switch information located between the end SDN switches, the case where there is no SDN switch at the end may not be considered. Therefore, if the LD packet is not input within the maintenance time, the control unit (130) may terminate the topology map configuration.

The policy setting unit (140) can create various flow policies, etc., and can transmit a flow policy setting message to the SDN switch for applying the flow policy to each SDN switch. Specifically, at the request of the control unit (130), an LD flow policy for transmitting an LD packet to network switches connected to the first SDN switch (S1) can be created and set in the first SDN switch (S1). That is, the policy setting unit (140) can determine a port whose port status has changed to up among the ports included in the first SDN switch (S1) from the port status message, and can create an LD flow policy to transmit an LD packet to the network switch through the port.

In addition, if a packet-in message for processing an LD packet is not received within the maintenance time of the LD flow policy, the policy setting unit (140) can reset the LD flow policy at the request of the control unit (130) to retransmit the LD packet.

When the update unit (150) receives a packet-in message for processing an LD packet from the second SDN switch (S2), it extracts connection information of at least one network switch connected between the first SDN switch (S1) and the second SDN switch (S2) from the LD tag included in the LD packet, and updates the network topology based on the connection information.

Specifically, the update unit (150) can search for each network switch included in the connection information in the reference database (D), and update the searched network switches as SDN switches to create a topology map table. Thereafter, the update unit (150) can create a network topology of the network switches included between the first SDN switch and the second SDN switch based on the topology map table. That is, the identification information (DPID) and port information (input port, output port) of the network switches connected at each hop can be extracted from the connection information, and the input ports and output ports of the network switches can be sequentially connected in the order of the hops to add the network topology between the first SDN switch and the second SDN switch.

Referring to FIG. 18, the update unit (150) can extract DPID, input port, and output port according to the hop order included in the LD tag in the received LD packet. Thereafter, the DPID included in the LD tag can be searched in the reference database (D) to extract the corresponding SDN switch. The extracted SDN switch can be updated in the topology map table (T) to specify the SDN switches among the DPIDs included in the LD tag. Thereafter, the topology map between the first SDN switch and the second SDN switch can be configured using the updated topology map table (T).

Referring to Fig. 19(a), the update unit (150) can configure a topology map starting from hop order 1, and first, can draw SDN switch #2, which was the first hop, and port 1, which is the output port of the switch. Here, the input port is 0, so it is excluded.

Afterwards, as in Fig. 19(b), the second hop, the general switch, the input port 2 of the general switch, and the output port 1 can be drawn respectively. Then, since the LD tag passes through the output port 1 of the first hop, SDN switch #2, and the input port 2 of the general switch, it can be determined that the two ports are connected to each other, and the ports can be connected and drawn.

Finally, as in Fig. 19(c), the third hop, SDN switch #1, and input port #1 of the SDN switch #1 can be drawn. However, the output port is 0, so it can be excluded. And since the LD packet passed through output port #1 of the general switch, which is the second hop, and input port #1 of SDN switch #1, it is determined that the two ports are connected to each other, and by drawing a connection between the ports, it is possible to complete the configuration of the final topology map.

Additionally, depending on the embodiment, when the control unit (130) receives a port status message, it is also possible to first determine whether the network switch connected to the first SDN switch is an SDN switch. That is, it is possible to first determine whether the network switch connected to the first SDN switch is an SDN switch, and to transmit an LD packet only if it is not an SDN switch.

Specifically, the control unit (130) can store the port number included in the received port status message in a variable called PORT_NO and store the port status information in a variable called PORT_STATE. Thereafter, if the PORT_STATE value is down, it can be determined that it is incorrect information due to a network failure, poor contact, or error, and can be excluded from the topology information. On the other hand, if the PORT_STATE value is up, it can be determined that a new network switch is connected to the corresponding port.

However, since it is not possible to know whether the network switch connected to the port is an SDN switch or a general switch device, the control unit (130) may first determine that it is an SDN switch and generate an LLDP packet to be sent out to the port. To this end, the policy setting unit (130) may be requested to define an LLDP flow policy that states, "Send LLDP packets with an Ethernet type (EtherType) of '0x88CC' to the port defined in PORT_NO." In this case, the policy setting unit (130) may transmit a flow policy setting message to the first SDN switch. The first SDN switch that receives the flow policy setting message may register the LLDP flow policy included in the flow policy setting message in the flow table. The LLDP flow policy registered in the flow table may have a retention time (for example, 10 seconds), and if no data packet set in the LLDP flow policy is input within the retention time, the flow policy may be automatically discarded.

Here, the SDN control device (100) transmits a packet-out message including an LLDP packet to the first SDN switch, and the first SDN switch can forward the LLDP packet included in the packet-out message to a port number set in the flow policy. At this time, if the transmitted LLDP packet is transmitted to the SDN control device (100) within the retention time, the switch that received the LLDP packet corresponds to an SDN switch, and therefore, a network topology map can be configured based on the LLDP packet.

On the other hand, if the SDN control device (100) does not receive an LLDP packet within the maintenance time, the switch can be determined to be a general switch, not an SDN switch, and accordingly, the LD packet can be controlled to be transmitted. Here, since the content of transmitting the LD packet to configure the topology map has been described above, a detailed description is omitted.

Figures 20 to 26 are schematic diagrams showing connection information collection using an LD tag of an SDN control device according to one embodiment of the present invention. Referring to Figure 20, two SDN switches may be connected to each of the SDN control devices (100), and one general switch may be connected between the two SDN switches. Here, the MAC address of the SDN control device (100) may be "sdns", the DPID of the SDN switch #1 may be "a", and the DPID of the SDN switch #2 may be "b".

As illustrated in Fig. 21(a), when a general switch and SDN switch #2 are connected, port 1 of SDN switch #2 can be changed from down to up. In this case, SDN switch #2 can generate a port status message and transmit the corresponding port status information to the SDN control device (100). Here, the control unit (130) can confirm that the status of port 1 of SDN switch #2 has been changed to up through the port status message, and can define variable values as PORT_NO=1, PORT_STATE=UP.

The control unit (130) may first assume that the connected general switch is an SDN switch, and request the policy setting unit (140) to create a flow policy to generate an LLDP packet and transmit it to port 1 of the SDN switch #2. That is, the policy setting unit (140) may create a flow policy that says, “Send the LLDP packet whose Ethernet type (EtherType) is ‘0x88CC’ to port 1 defined in PORT_NO,” and transmit a corresponding flow policy setting message to the SDN switch #1. In this case, as illustrated in Fig. 21(b), the SDN switch #2 may register the flow policy included in the flow policy setting message in the flow table. Here, the flow policy registered in the flow table may have a retention time of 10 seconds set, and if a data packet to which the flow policy is applied is not transmitted within the corresponding time, the corresponding flow policy may be automatically discarded.

Thereafter, as shown in Fig. 22(a), the control unit (130) can forward a packet-out message including an LLDP packet to SDN switch #2, and as shown in Fig. 22(b), SDN switch #2 can forward the LLDP packet to port 1 according to the flow policy. However, the general switch that received the LLDP packet does not support SDN and is not connected to the SDN control device (100), so it cannot process the LLDP packet and discards it. In this case, the LLDP flow policy set in SDN switch #2 may also be discarded when the maintenance time expires.

That is, if the SDN control device (100) does not receive an LLDP packet within the maintenance time of the LLDP flow policy, the control unit (130) can determine that the switch is a general switch, not an SDN switch. Therefore, the control unit (130) can request the LD tag generation unit (120) to generate an LD tag. Currently, the LLDP flow policy registered in the existing SDN switch #2 has been deleted because the maintenance time has expired.

Therefore, the control unit (130) can request the policy setting unit (140) to create a new LD flow policy that states, ‘Send packets whose Ethernet type (EtherType) is LD frame (0x88EE) to port 1 defined in PORT_NO.’ As illustrated in Fig. 23, the policy setting unit (140) can transmit a flow policy setting message corresponding to the LD flow policy to SDN switch #2. SDN switch #2, which receives the flow policy setting message, can register the LD flow policy included in the flow policy setting message in the flow table.

The LD tag generation unit (120) can set the destination MAC address as a broadcast address (FF:FF:FF:FF:FF:FF), the source MAC address as an SDN control device (100), the Ethernet type (EtherType) as (0x88EE) indicating an LD frame, the hop count (HC) field of the LD tag as 0, and the maximum hop count (IC) field as 5 so that up to 5 devices can be identified, as shown in FIG. 24. In addition, the port data (PD) field value of the LD tag including connection information can be regarded as Hop1 since the LD packet including the corresponding LD tag is primarily transmitted to SDN switch #2. At this time, since there is no input port, 0, the output port is defined as PORT_NO as 1, and the DPID value b of SDN switch #2 that transmitted the port status message can be generated in the form of a list, ‘Hop1:{0, 1, b}’. Afterwards, the LD packet containing the LD tag can be included in a packet-out message and forwarded to SDN switch #2. In this case, SDN switch #2, which receives the LD packet through the packet-out message, can forward the LD packet to port 1 according to the flow policy.

Afterwards, referring to FIG. 25, the general switch that receives the LD packet through port 2 of SDN switch #2 verifies that the destination MAC address of the LD packet is a broadcast address (FF:FF:FF:FF:FF:FF), and can broadcast it to port 1, which is all ports except port 2, which is an input port. Since the broadcasted LD packet is forwarded from the general switch to SDN switch #1, the hop count (HC) field value of the LD tag increases from 0 to 1, and the maximum hop count (IC) field value can decrease from 5 to 4, which is one hop that passed through the general switch out of the maximum number of hops that can be passed. In addition, the field value of port data (PD) can regard the general switch through which the LD packet has already passed as one hop, Hop2. Since the LD packet entered the inside through port 2 of the general switch, the input port is 2, the LD packet is transmitted to SDN switch #1 through port 1, so the output port is 1, and since there is no DPID in the case of a general switch, it can be defined as ‘0’, and Hop2: {2,1,0}, which is expressed in list form, can be added.

Thereafter, referring to FIG. 26, since the SDN switch #1 that received the LD packet operates in reactive mode, even if the destination MAC address of the LD packet is a broadcast address, since there is no flow policy for processing the LD packet, it can be included in a packet-in message and transmitted to the SDN control device (100). At this time, in the LD tag included in the packet-in message, since the LD packet was transmitted from a general switch to SDN switch #1, the hop count (HC) field value of the LD tag increases from 2 to 3, which is 1, and since it passed through SDN switch #1, the maximum hop count (IC) field value decreases from 4 to 3, which is 1. And the port data (PD) field value is considered as Hop3, which is the third hop, when the LD packet entered through port 1 of SDN switch #1, the input port is 1, the LD packet is not forwarded to the outside, so the output port is 0, and since the DPID value of SDN switch #1 is ‘a’, Hop3: {1,0,a}, which is expressed in list form, can be added.

Here, since the field value of the maximum hop count of the LD tag is 3, it is possible to collect more connection information for the three switches located on the path. However, since the output port of SDN switch #1 stored in the port data (PD) field is set to 0 and there is no other switch to forward the LD packet on the path, the forwarding process of the LD packet can proceed only up to SDN switch #1 and then end.

Thereafter, the update unit (150) can extract the hop order, DPID, input port, output port, etc. included in the LD tag of the received LD packet in that order. In addition, if there is an SDN switch with the same DPID among the LD tags extracted by searching the reference database (D), it can be called and updated. Through this, a topology map table can be configured.

Once the topology map table is created, it is possible to create a topology map based on it. Specifically, a topology map can be configured starting from hop order 1, and the first hop, SDN switch #2, and the output port of the switch, port 1, can be drawn. Here, the input port is 0, so it is excluded.

After that, you can draw the general switch which was the second hop, input port 2 of the general switch, and output port 1 respectively. Then, since the LD tag passed through output port 1 of the first hop, SDN switch #2, and input port 2 of the general switch, you can determine that the two ports are connected to each other and draw a connection between the ports.

Finally, we can draw the third hop, SDN Switch #1, and input port 1 of the SDN Switch #1. However, since the output port is 0, we can exclude it. And since the LD packet passed through output port 1 of the general switch, which is the second hop, and input port 1 of SDN Switch #1, we can determine that the two ports are connected to each other, and by drawing a connection between the ports, we can complete the configuration of the final topology map.

FIG. 27 is a block diagram illustrating a computing environment (10) suitable for use in exemplary embodiments. In the illustrated embodiment, each component may have different functions and capabilities other than those described below, and may include additional components other than those described below.

The illustrated computing environment (10) includes a computing device (12). In one embodiment, the computing device (12) is a device that synchronizes messages between a plurality of messenger client devices with which a user account is shared, and may be any one of the plurality of messenger client devices.

A computing device (12) includes at least one processor (14), a computer-readable storage medium (16), and a communication bus (18). The processor (14) may cause the computing device (12) to operate in accordance with the exemplary embodiments described above. For example, the processor (14) may execute one or more programs stored in the computer-readable storage medium (16). The one or more programs may include one or more computer-executable instructions, which, when executed by the processor (14), may be configured to cause the computing device (12) to perform operations in accordance with the exemplary embodiments.

A computer-readable storage medium (16) is configured to store computer-executable instructions or program code, program data, and/or other suitable forms of information. A program (20) stored in the computer-readable storage medium (16) includes a set of instructions executable by the processor (14). In one embodiment, the computer-readable storage medium (16) may be a memory (volatile memory such as random access memory, non-volatile memory, or a suitable combination thereof), one or more magnetic disk storage devices, optical disk storage devices, flash memory devices, any other form of storage medium that can be accessed by the computing device (12) and capable of storing desired information, or a suitable combination thereof.

A communication bus (18) interconnects various other components of the computing device (12), including the processor (14) and computer-readable storage media (16).

The computing device (12) may also include one or more input/output interfaces (22) that provide interfaces for one or more input/output devices (24) and one or more network communication interfaces (26). The input/output interfaces (22) and the network communication interfaces (26) are coupled to the communication bus (18). The input/output devices (24) may be coupled to other components of the computing device (12) via the input/output interfaces (22). Exemplary input/output devices (24) may include input devices such as a pointing device (such as a mouse or trackpad), a keyboard, a touch input device (such as a touchpad or a touchscreen), a voice or sound input device, various types of sensor devices and/or photographing devices, and/or output devices such as a display device, a printer, speakers, and/or a network card. The exemplary input/output devices (24) may be included within the computing device (12) as a component that constitutes the computing device (12), or may be coupled to the computing device (12) as a separate device distinct from the computing device (12).

The present invention is not limited to the above-described embodiments and the attached drawings. It will be apparent to those skilled in the art to which the present invention pertains that components according to the present invention can be substituted, modified, and changed within a scope that does not depart from the technical spirit of the present invention.

100: SDN control unit 110: Transmitter/receiver unit
120: LD tag generation section 130: Control section
140: Policy Setting Department 150: Update Department

Claims (20)

In a software-defined network (SDN) environment where reactive packet processing is applied, in an SDN control device that constructs a network topology,
A transceiver unit for transmitting and receiving messages with SDN switches connected to the above SDN control device;
An LD tag generation unit that generates an LD packet including an LD (Link Discovery) tag that accumulates and stores connection information at each hop when receiving a port status message from the first SDN switch;
A control unit that controls the above LD packet to be included in a packet-out message and transmitted to the first SDN switch; and
An SDN control device including an update unit that extracts connection information of at least one network switch connected between the first SDN switch and the second SDN switch from the LD tag included in the LD packet when receiving a packet-in message for processing the LD packet from the second SDN switch, and updates the network topology based on the connection information.
In the first paragraph, the LD packet
An SDN control device, which is set to be transmitted in a broadcasting manner between the first SDN switch and the second SDN switch.
In the first paragraph, the LD packet
An SDN control device generated using an LD frame that further includes a field including the LD tag in the Ethernet Frame structure.
In the first paragraph, the LD tag
An SDN control device including a hop count field that counts the number of hops through which the above LD packet is transmitted, and a connection information field that accumulates and stores identification information (DPID: Datapath Identification) and port information at each hop.
In the fourth paragraph, the LD tag
An SDN control device further comprising a maximum hop count (idle count), which is the maximum number of hops that the above LD packet can transmit.
In the first paragraph,
An SDN control device further comprising a policy setting unit that creates an LD flow policy (flow rule) for transmitting the LD packet to a network switch connected to the first SDN switch and sets it in the first SDN switch.
In Article 6, the policy setting department
An SDN control device that determines, from the above port status message, a port among the ports included in the first SDN switch whose status has changed to Up, and generates the LD flow policy to transmit the LD packet to the network switch through the port.
In the seventh paragraph, the control unit
An SDN control device, wherein, if a packet-in message for processing the LD packet is not received within the maintenance time of the LD flow policy, the policy setting unit resets the LD flow policy to retransmit the LD packet.
In the first paragraph, the update unit
An SDN control device that extracts identification information and port information of the network switches connected at each hop from the connection information, and sequentially connects input ports and output ports of the network switches in the order of the hops, thereby adding a network topology between the first SDN switch and the second SDN switch.
In the 9th paragraph, the update unit
An SDN control device that searches for each network switch included in the above connection information in a reference database including a list of SDN switches connected to the SDN control device, and updates the searched network switches with the SDN switches to create a topology map table.
In the 10th paragraph, the update unit
An SDN control device that generates a network topology of the network switches included between the first SDN switch and the second SDN switch based on the topology map table.
In the first paragraph, the control unit
An SDN control device that, upon receiving the above port status message, determines whether a network switch connected to the first SDN switch is an SDN switch.
In the 12th paragraph, the control unit
An SDN control device that, assuming the above network switch to be the SDN switch, transmits an LLDP (Link Layer Discovery Protocol) packet for confirming connection information of the network switch to the first SDN switch by including it in a packet-out message.
In the 13th paragraph, the control unit
An SDN control device, wherein if a packet-in message corresponding to the LLDP packet is not received from the network device, the network device is determined to be not the SDN switch.
In Article 13, the policy setting department
An SDN control device that sets an LLDP flow policy for transmitting the LLDP packet to the network device on the first SDN switch.
In Article 15, the policy setting department
An SDN control device that determines, from the above port status message, a port among the ports included in the first SDN switch whose status has changed to Up, and generates the LLDP flow policy to transmit the LLDP packet to the network switch through the port.
In the 15th paragraph, the control unit
An SDN control device that determines that the packet-in message is not received within the maintenance time of the LLDP flow policy, and that the SDN switch is not the SDN switch.
In a computing device that includes a processor and constructs a network topology in a software defined network (SDN) environment with a reactive packet processing method applied,
The above processor
Receiving a port status message from the first SDN switch;
In response to the above port status message, a LD packet including an LD (Link Discovery) tag that accumulates and stores connection information at each hop is included in a packet-out message and transmitted to the first SDN switch;
When receiving a packet-in message for processing the LD packet from the second SDN switch, extracting the LD tag from the LD packet; and
A computing device, comprising: extracting connection information of at least one network switch connected between the first SDN switch and the second SDN switch from the above LD tag, and updating the network topology based on the connection information.
In the first paragraph, the processor
A computing device, further comprising: upon receiving the above port status message, determining whether a network switch connected to the first SDN switch is an SDN switch.
In the 12th paragraph, determining whether it is the SDN switch is
Assuming the above network switch as the SDN switch, including an LLDP (Link Layer Discovery Protocol) packet for checking the connection information of the network switch in a packet-out message and transmitting it to the first SDN switch; and
A computing device further comprising: determining that the network device is not the SDN switch if a packet-in message corresponding to the LLDP packet is not received from the network device.

Images