JP6134571B2 - Communication confirmation device, network system, communication confirmation method, and communication confirmation program - Google Patents

Description

  The present invention relates to a communication confirmation device, a network system, a communication confirmation method, and a communication confirmation program.

  Conventionally, in a network configured with L2 switches, packet transfer is performed using a MAC address, and in a network configured with routers, packet transfer is performed using an IP address. In these networks, different transfer methods are not mixed in the same transfer apparatus.

  In addition, for example, in a network (IP network) constituted by routers, transfer is performed only by a destination IP address. Even if UDP (User Datagram Protocol) is different, packet transfer processing is performed according to the same rule.

  Therefore, in a conventional network (for example, an IP network), if arrival of an ICMP packet can be confirmed, it is guaranteed that a TCP packet or UDP packet addressed to the same IP address will also arrive. For this reason, it is sufficient to confirm the arrival of any kind of packet for the confirmation of communication, and thus it is possible to confirm the communication of an arbitrary IP packet. One specific method is ping using an ICMP packet.

RFC792, INTERNET CONTROL MESSAGE PROTOCOL, February 12, 2013 search, Internet <URL: http://www.rfcsearch.org/rfcview?lookup_type=RFC&lookup_num=792> OpenFlow Switch Specification, search February 13, 2013, Internet <URL: https://www.opennetworking.org/images/stories/downloads/specification/openflow-spec-v1.3.1.pdf> Presentation material in MPLS Japan 2012 (P.26), search on February 13, 2013, Internet <URL: http://www.mpls.jp/presentations/m.tsukuda_mpls_japan_2012.pdf>

  By the way, in recent years, OpenFlow (see Non-Patent Document 2) has been proposed as one of the methods for realizing SDN (Software Defined Network), and specifications are being developed by ONF (Open Network Foundation). The network using OpenFlow is a network composed of an OpenFlow controller (hereinafter referred to as OFC) and an OpenFlow switch (hereinafter referred to as OFS), and packet transfer rules can be freely set from OFC to OFS. It is a technology that can construct a virtual network according to the transfer rules. In a network constituted by OFS, a virtual network having various packet transfer methods can be freely configured. In other words, in a network using OpenFlow, different transfer methods may coexist in the same transfer apparatus.

  FIG. 1 is a diagram conceptually illustrating a network using OpenFlow. In a network using OpenFlow, virtual NWs 1 to 3 can be constructed from a physical NW (network) including transfer devices (OFS (1) to OFS (6) in the figure) as shown in FIG. For example, in the virtual NW1, a transfer rule that a packet whose source IP address is 192.168.0 / 24, destination IP address is 192.168.10 / 24, and protocol is TCP is applied. Is possible. In the virtual NW2, a transfer rule based on the MAC address is specified, and in the virtual NW3, a protocol is UDP and a transfer rule for the destination port number 3000 is specified. There are cases where NWs are constructed on the same physical NW.

  In the case of a network constituted by a conventional L2 switch or a router, for example, if communication of a transfer device (1) → (4) is confirmed for a packet of a certain type / transfer method, any type / The communication of the transfer devices (1) → (4) is confirmed for the packet of the transfer method. However, in the network using OpenFlow, for example, even if the communication of the transfer device (1) → (4) is confirmed in the virtual NW3, the communication of the transfer device (1) → (4) is confirmed in the virtual NW1. It will not be. This is because, in a network in which an arbitrary transfer rule can be set for each transfer device, such as a network using OpenFlow, transfer paths may be different between virtual NWs even if the transmission source and the transmission destination are the same. .

  On the other hand, a method using CC / ping has been proposed (see Non-Patent Document 3). However, since this method is based on the premise that the created virtual network is only the conventional L2 / L3 network, it may not be applicable to a network in which any transfer rule can be set for each transfer device. is there.

  The present invention has been made in view of such circumstances, and an object of the present invention is to perform communication confirmation in an arbitrary section for a network in which an arbitrary transfer rule can be set for each transfer unit.

  One aspect of the present invention is a reception unit that receives designation of a communication confirmation section in which communication communication should be confirmed for a network in which an arbitrary transfer rule can be set for each transfer unit, and the designation confirmation section that receives the designation. A generation unit that generates confirmation data according to a transfer rule; and the confirmation data generated by the generation unit is transmitted to the network, and communication is performed in the communication confirmation section with reference to the returned confirmation data. And a determination unit that determines whether or not the communication is normally performed.

  According to one aspect of the present invention, it is possible to perform communication confirmation in an arbitrary section for a network in which an arbitrary transfer rule can be set for each transfer unit.

It is a figure which shows notionally the network using OpenFlow. It is the figure which illustrated the communication environment of the communication confirmation apparatus 1 which concerns on this embodiment. It is a figure which shows an example of the hardware constitutions of the communication confirmation apparatus. It is a figure which shows an example of a function structure of the communication confirmation apparatus. 4 is a diagram illustrating an example of a structure of data stored as test management information 40. FIG. It is an example of the flowchart which shows the flow of the process performed by the communication confirmation apparatus. It is a figure which shows an example of the format of the header part of the packet for confirmation. It is a figure which shows an example of the header part of the packet for default confirmation. It is the figure which illustrated a part of network system to which a communication confirmation process is applied. It is a figure which shows an example of the setting information of virtual NW shown in FIG. 3 is an example of data that is possible as test management information 40; It is a figure which shows an example of the confirmation packet which the confirmation packet production | generation part 32 stored TTL and the IP address in the default confirmation packet (TCP version). It is a figure which shows an example of virtual NW in which several Dst exists with respect to one Src. It is a figure which shows an example of the sub NW which divided | segmented the virtual NW shown in FIG. 13 virtually.

[Constitution]
Hereinafter, embodiments of a communication confirmation device, a network system, a communication confirmation method, and a communication confirmation program according to the present invention will be described with reference to the drawings. FIG. 2 is a diagram illustrating a communication environment of the communication confirmation apparatus 1 according to the present embodiment. The communication confirmation apparatus 1 is connected to the OFC 100 and the topology management apparatus 200, for example. The network NW that is the target of communication confirmation functions by the OFS (1) to (6) communicating with each other. Each OFS performs packet transfer processing in accordance with conditions set in accordance with an instruction from the OFC 100. Each OFS operates according to the OpenFlow protocol. For example, when each OFS receives a confirmation packet (an example of confirmation data) whose TTL (Time To Live) value is “1”, the OFS 100 performs PacketIn processing.

  For example, the OFC 100 is communicably connected to all of the OFSs in the network NW (may be direct or may have an OFS interposed therebetween), and an OpenFlow protocol stack for performing processing for each OFS is provided. It is installed. The OFC 100 sets a transfer rule in each OFS. Further, the OFC 100 performs transmission of a communication confirmation packet and handling of an event from the OFS in accordance with an instruction from the communication confirmation apparatus 1, and returns the handled information to the communication confirmation apparatus 1.

  The topology management device 200 manages the topology information of each virtual network constructed on the network NW. The topology management apparatus 200 manages, for each virtual network, information that uniquely determines an OFS being used (hereinafter referred to as an OFS ID), OFS connection relation information, virtual network construction rules, and the like. The number of hops between any OFS can be calculated. The topology management device 200 includes a user interface such as a mouse, a keyboard, and a display device. The topology management device 200 accepts designation of a communication confirmation section by the operator, displays topology information of the virtual network, and confirms the result of the communication confirmation device 1. Is displayed. Not limited to this, the communication confirmation device 1 may include a user interface, the OFC 100 and the communication confirmation device 1, the topology management device 200 and the communication confirmation device 1, or all of these may be integrated.

  FIG. 3 is a diagram illustrating an example of a hardware configuration of the communication confirmation apparatus 1. The communication confirmation device 1 includes, for example, a CPU 10, a drive device 12, a storage device 16, a memory device 18, and an interface device 20.

  The CPU 10 executes various programs stored in the storage device 16 and the memory device 18. A storage medium 14 such as a USB memory, a CD (Compact Disc), a DVD (Digital Versatile Disc), or an SD card is mounted on the drive device 12. The storage device 16 includes, for example, an HDD (Hard Disk Drive), a flash memory, a ROM (Read Only Memory), and the like. The memory device 18 includes, for example, a RAM (Random Access Memory), a register, and the like. The interface device 20 is a device for connecting to the OFC 100 and the topology management device 200.

  FIG. 4 is a diagram illustrating an example of a functional configuration of the communication confirmation device 1. The communication confirmation apparatus 1 receives information on a communication confirmation section on the virtual network designated by the operator in the topology management apparatus 200, and performs communication confirmation processing using the PacketOut / PacketIn function of the OFC.

  The communication confirmation device 1 includes, for example, a communication confirmation request reception unit 30, a confirmation packet generation unit 32, an OFC linkage unit 34, a confirmation result determination unit 36, and a confirmation result transmission unit 38. These functional units are, for example, software functional units that function when the CPU 10 executes a program stored in the storage device 16. Note that these functional units need not be described by independent programs. Further, some or all of these functional units may be hardware functional units such as LSI (Large Scale Integration) and IC (Integrated Circuit). Further, the communication confirmation device 1 stores the test management information 40 in the memory device 18 or the storage device 16.

  The communication confirmation request receiving unit 30 receives a communication confirmation request from the topology management apparatus 200. The communication confirmation request includes information such as the virtual NW transfer rule in the communication confirmation section, the Src (start point) and Dst (end point) OFS IDs in the communication confirmation section, and the number of hops. As the transfer rule, for example, <transmission destination IP (transmission destination IP address) = 192.168.0 / 24, protocol = UDP> is specified. Further, for example, a data path ID is used as the OFS ID. Upon receipt of the communication confirmation request, the communication confirmation request receiving unit 30 generates information for uniquely identifying the request (hereinafter, request identification information), and performs test management together with the Src and Dst OFS IDs of the communication confirmation section. Information 40 is stored in the memory device 18 or the storage device 16. FIG. 5 is a diagram illustrating an example of a data structure stored as the test management information 40.

  The confirmation packet generation unit 32 generates a confirmation packet used for communication confirmation based on the information stored in the memory device 18 or the storage device 16 and outputs the confirmation packet to the OFC cooperation unit 34. Details of the generation process of the confirmation packet will be described later. In the present embodiment, the communication confirmation device 1 generates the confirmation packet. However, the communication confirmation device 1 determines only the confirmation packet generation condition, and transmits the condition to the OFC 100, for example. The process may be performed in such a flow that the OFC 100 generates a confirmation packet.

  The OFC cooperation unit 34 receives the confirmation packet generated by the confirmation packet generation unit 32, reads the Src OFS ID from the memory device 18 or the storage device 16, and sends a packet transmission instruction (PacketOut instruction) to the Src OFC. Send. Further, the OFC cooperation unit 34 receives event information (PacketIn information) transmitted by the Dst OFS via the OFC 100 and outputs the event information to the confirmation result determination unit 36.

  The confirmation result determination unit 36 compares the PacketIn information input from the OFC linkage unit 34 with the request identification information included in the test management information 40 to thereby determine the Src OFS and Dst input from the topology management device 200. It is determined whether or not communication between OFS has been confirmed. The confirmation result transmission unit 38 transmits the determination result by the confirmation result determination unit 36 to the topology management device 200.

[Process flow]
FIG. 6 is an example of a flowchart showing a flow of processing executed by the communication confirmation apparatus 1. First, the communication confirmation device 1 stands by until a communication confirmation request is received from the topology management device 200 (step S300). When the communication confirmation request is received from the topology management apparatus 200, the communication confirmation request receiving unit 30 stores the received information in the memory device 18 or the storage device 16 (step S302).

  Next, the confirmation packet generator 32 performs confirmation packet generation processing (steps S304 to S320). FIG. 7 is a diagram illustrating an example of the format of the header portion of the confirmation packet. As shown in FIG. 7, the confirmation packet is generated based on, for example, IPv4. When a confirmation packet is generated based on IPv6, the corresponding portion may be converted as appropriate. The confirmation packet is generated in a format in which any of an ICMP header, a TCP header, and a UDP header is added to a combination of an Ethernet header and an IP header.

  Returning to FIG. First, the confirmation packet generation unit 32 determines whether or not a protocol higher than IP is specified in the transfer rule in the communication confirmation section (step S304). If no protocol is specified, the confirmation packet generator 32 sets the UDP packet as a default confirmation packet (step S306). On the other hand, when a protocol is specified, the confirmation packet generator 32 generates a default confirmation packet with the specified protocol (step S308).

  FIG. 8 is a diagram illustrating an example of a header portion of a default confirmation packet. As shown in FIG. 8, in the default confirmation packet, the MAC address of the OFC 100 is input as the transmission source MAC address of the Ethernet header, and an arbitrary MAC address is input as the transmission destination MAC address. In the default confirmation packet, the IP address of the OFC 100 is input as the source IP address of the IP header, and an arbitrary IP address (excluding private, broadcast, multicast, and network) is input as the destination IP address. The

  In addition, when the default confirmation packet is an ICMP packet (when the protocol is specified as ICMP in the transfer rule in the communication confirmation section), “0” is input as the ICMP header type. When the default confirmation packet is a TCP packet (when the protocol designation is TCP), “0” is input to the transmission source port number and the transmission destination port number of the TCP header. When the default confirmation packet is a UDP packet (when the protocol is designated as TCP), “0” is input to the source port number and destination port number of the TCP header. Since these values are values that are not input to the header of a normal packet (impossible values), even if a confirmation packet flows out of the virtual NW and is received by a device that is not related to the communication confirmation The confirmation packet is discarded by the protocol stack higher than the transport layer in the receiving device. As a result, it is possible to prevent packet transfer for confirming communication from causing unintended inconveniences.

  Returning to FIG. After performing the process of step S308, the confirmation packet generator 32 determines whether the designated protocol is TCP or UDP or ICMP in the transfer rule in the communication confirmation section (step S310).

  When the designated protocol is TCP or UDP, the confirmation packet generator 32 determines whether or not a destination port number is designated in the transfer rule in the communication confirmation section (step S312). When the destination port number is designated, the confirmation packet generator 32 modifies the default checksum area of the confirmation packet to an invalid value (step S314).

  Such processing is based on the fact that information corresponding to the transfer rule is stored (overwritten) in step S318, which will be described later, so that the effect of inputting “0” as the destination port number is lost as described above. . By modifying the checksum area, for example, even when a confirmation packet flows out of the virtual NW and is received by an irrelevant device, the confirmation packet is discarded by the protocol stack in the received device. However, since the processing for modifying the checksum area is slightly larger than the processing for storing “0” in the transmission destination port number, the processing for storing “0” in the transmission destination port number is prioritized and transmitted. Only when “0” is overwritten due to the designation of the destination port number, the checksum area is modified. As a result, the communication confirming apparatus 1 can prevent the packet transfer for confirming the communication from causing an unintended inconvenience and suppress an increase in processing load.

  On the other hand, when the designated protocol is ICMP, the confirmation packet generator 32 determines whether or not a type is designated in the transfer rule in the communication confirmation section (step S316). If there is a type designation, the confirmation packet generator 32 modifies the checksum area of the default confirmation packet (step S314). The purpose of such processing is the same as the flow of steps S312 → S314.

  Next, the confirmation packet generator 32 stores information corresponding to the transfer rule in the communication confirmation section in the default confirmation packet (step S318). Further, the confirmation packet generator 32 stores the number of hops in the TTL area of the IP header and the request identification information in the payload or the like (step S320). The confirmation packet generator 32 may input the request identification information in the identifier area or the like of the IP header instead of the payload area.

  Returning to FIG. The OFC cooperation unit 34 sends the generated confirmation packet and the ID of the Src OFS in the communication confirmation section to the OFC 100, and requests communication confirmation by calling the PacketOut function (step S322). The OFC 100 transmits a confirmation packet to the Src OFS in the communication confirmation section through the PacketOut process.

  As a result, the OFS in the communication confirmation section transfers the confirmation packet while reducing the TTL by one. The OFS that has received the confirmation packet with a TTL of 1 reduces the TTL by 1 to make the TTL zero, and performs a PacktIn process with TTL Invalid on the OFC 100. The PacktIn information (hereinafter referred to as PacktIn information) includes the confirmation packet that is the target of the PacktIn process. Therefore, the confirmation packet returns to the OFC 100. The OFC 100 transmits PacketIn information and information (hereinafter referred to as OFS identification information) that identifies the OFS that transmitted the PacketIn information to the OFC cooperation unit 34 of the communication confirmation apparatus 1.

  The confirmation result determination unit 36 determines whether or not communication is normally performed in the communication check section based on the PacktIn information and OFS identification information received from the OFC 100 by the OFC cooperation unit 34 (step S324; communication check result determination). . More specifically, the confirmation result determination unit 36 extracts the packet in reason and the confirmation packet from the packet in information, and further extracts the request identification information stored in the confirmation packet. Next, the confirmation result determination unit 36 refers to the test management information 40, and acquires the OFS ID of Dst corresponding to the extracted request identification information from the test management information 40. The confirmation result determination unit 36 communicates when the packet generation reason is TTL Invalid and the OFS identification information received by the OFC linkage unit 34 matches the ID of the Dst OFS acquired from the test management information 40. It is determined that it is normal. On the other hand, if the OFS identification information received by the OFC linkage unit 34 and the ID of the DFS OFS acquired from the test management information 40 do not match, the confirmation result determination unit 36 has received a PacketIn for a reason other than TTL Invalid. If PacketIn is not received even after a fixed time has elapsed from PacketOut, it is determined that the communication is not normally performed in the corresponding communication confirmation section.

  The confirmation result transmission unit 38 transmits the communication confirmation result by the confirmation result determination unit 36 to, for example, the topology management apparatus 200 (step S326). The topology management device 200 displays the communication confirmation result on the display device. As a result, the operator can visually recognize the communication confirmation result.

  Note that if the communication between OFC 100 and OFS (Src or Dst OFS in the communication confirmation section) is not normal, PacketIn is not returned, so the communication in the communication confirmation section is normal. Regardless, it is assumed that the confirmation result determination unit 36 outputs a communication confirmation result that “communication is not normally performed”. In order to avoid this, the communication confirmation device 1 may cause the OFC 100 to periodically confirm communication with each OFS. This communication confirmation is performed, for example, by transmitting a packet requesting a reply (a packet different from the confirmation packet) to each OFS and confirming the reply. Thereby, the determination accuracy of the confirmation result determination unit 36 can be improved.

[Application example]
Hereinafter, the scene where the above-described communication confirmation process is applied will be described more specifically. FIG. 9 is a diagram illustrating a part of a network system to which the communication confirmation process is applied. As shown in FIG. 9, the packet transmission from the computer X whose IP address belongs to 192.168.0.0/24 to the computer Y whose IP address belongs to 192.168.1.0/24 is an OFS whose ID is A and whose ID is B. It is set to be transferred in order of a certain OFS, an OFS whose ID is C, and an OFS whose ID is D. FIG. 10 is a diagram showing an example of setting information of the virtual NW shown in FIG. In FIG. 10, “Output = port # x” means the number of the network port to which the next OFS in each OFS is connected. For example, in the OFS with ID B, the port number is connected to the OFS with ID C.

  In such a situation, the communication confirmation request received by the communication confirmation device 1 is, for example, the one stored in the “Matching Field” in FIG. 10 as a transfer rule, and the communication confirmation section is OFS (ID = A) with Src. The information is specified by the OFS (ID = D) of Dst and includes information such as 4 hops. As a result, the test management information 40 stores the data shown in FIG.

  The default confirmation packet generated by the confirmation packet generation unit 32 is as shown in FIG. 8 (since it is protocol-designated TCP, a TCP header is added to the Ethernet header and the IP header). On the other hand, the confirmation packet generator 32 stores the number of hops = 4 in the TTL area, and sets the source IP address and destination IP address to the source IP address and destination IP address in the virtual NW setting information, respectively. Overwrite with. However, the IP address stored in the IP header is, for example, the start address of each segment. FIG. 12 is a diagram illustrating an example of a confirmation packet in which the confirmation packet generation unit 32 stores a TTL and an IP address in a default confirmation packet (TCP version).

  When such a confirmation packet is sent to the Src OFS by the PacketOut process, OFS (ID = A, B, C, D) transfers the confirmation packet while reducing the TTL by one. The DFS OFS (ID = D) that has received the confirmation packet with the TTL of 1 reduces the TTL to 1 to reduce the TTL to zero, and performs the PackIn process by TTL Invalid on the OFC 100.

[Application to multicast, round robin, etc.]
Communication methods that can be realized by OFS are not only one-to-one unicast communication but also one-to-many multicast communication, round robin for load distribution, and the like. When the OFS supports these communications, the communication confirmation request is defined to include information for identifying all of the Dst OFSs and the next OFS of the branch point. FIG. 13 is a diagram illustrating an example of a virtual NW in which a plurality of Dsts exist for one Src. When the communication confirmation apparatus 1 performs communication confirmation for the entire virtual NW as shown in FIG. 13, the OFS (ID = C, F in the figure) next to the branch point is set as one temporary Dst and the other. The virtual NW is divided as the temporary Src, and communication confirmation is performed for each divided sub NW. FIG. 14 is a diagram illustrating an example of a sub NW obtained by virtually dividing the virtual NW illustrated in FIG. In FIG. 14, “Src *” and “Dst *” indicate provisional Src and Dst generated by the division. The communication confirmation device 1 generates a confirmation packet for all of the OFSs of Dst (including Dst *) shown in FIG. 14 (communication confirmation sections (1) to (5) in FIG. 14), and the corresponding Src (Src * To the OFS). The number of hops is also divided along with the division, and the TTL is overwritten accordingly. As a result, if the communication is normal, PacketIn information is returned from all Dst OFSs. About the communication confirmation determination with respect to PacketIn information, it is the same as the said description.

[Summary]
According to the communication confirmation device, the network system, the communication confirmation method, and the communication confirmation program (hereinafter referred to as the communication confirmation device 1) of the present embodiment described above, a confirmation packet corresponding to the transfer rule in the communication confirmation section is generated. Therefore, communication can be confirmed in an arbitrary section for a network in which transfer rules can be set for each OFS.

  Further, according to the communication confirmation device 1 or the like of the present embodiment, when a device outside the network receives the confirmation packet, the confirmation packet is discarded in the protocol stack higher than the transport layer in the device. , Packet transfer for communication confirmation can prevent unintended inconvenience

  The OFC cooperation unit 34 and the confirmation result determination unit 36 in this embodiment are examples of the “determination unit” in the claims.

  As mentioned above, although the form for implementing this invention was demonstrated using embodiment, this invention is not limited to such embodiment at all, In the range which does not deviate from the summary of this invention, various deformation | transformation and substitution Can be added.

DESCRIPTION OF SYMBOLS 1 ... Communication confirmation apparatus, 10 ... CPU, 30 ... Communication confirmation request receiving part, 32 ... Confirmation packet generation part, 34 ... OFC cooperation part, 36 ... Confirmation result determination part, 38 ... Confirmation result transmission part, 40 ... Test management Information, 100 ... OFC, 200 ... Topology management device

Claims (11)

A reception unit that accepts designation of a communication confirmation section for confirming communication for a network in which an arbitrary transfer rule can be set for each transfer unit;
A generation unit that generates confirmation data according to the transfer rule in the communication confirmation section that has received the designation ;
With
The confirmation data is sent to the transfer portion is a starting point of the communication confirmation interval, whether communication in the communication check period by referring to the confirmation data returned is normally performed is determined,
When the device outside the network receives the confirmation data, the generator generates the confirmation data so that the confirmation data is discarded in a protocol stack higher than the transport layer in the device. Generate,
Communication confirmation device. A reception unit that accepts designation of a communication confirmation section for confirming communication for a network in which an arbitrary transfer rule can be set for each transfer unit;
A generation unit that generates confirmation data according to the transfer rule in the communication confirmation section that has received the designation ;
With
When the communication check section includes a branch point that branches in a plurality of directions, the generation unit generates the confirmation data for each of the provisional sections obtained by dividing the communication check section by a transfer unit next to the branch point;
The confirmation data is sent to the transfer portion is a starting point of the communication confirmation interval, whether communication in the communication check period by referring to the confirmation data returned is normally performed it is determined With
The confirmation data corresponding to each of the temporary sections is transmitted, and it is determined whether or not communication is normally performed for each of the temporary sections.
Communication confirmation device. A reception unit that accepts designation of a communication confirmation section for confirming communication for a network in which an arbitrary transfer rule can be set for each transfer unit;
A generation unit that generates confirmation data according to the transfer rule in the communication confirmation section that has received the designation ;
With
The confirmation data is sent to the transfer portion is a starting point of the communication confirmation interval, whether communication in the communication check period by referring to the confirmation data returned is normally performed is determined,
Confirming communication with the transfer unit in the network by transmitting data different from the confirmation data to the transfer unit in the network and confirming a reply from the transfer unit that transmitted the data. Is done regularly,
Communication confirmation device. Whether the confirmation data generated by the generation unit is sent to the transfer unit that is the starting point of the communication confirmation section, and whether communication is normally performed in the communication confirmation section with reference to the returned confirmation data The communication confirmation apparatus as described in any one of Claims 1-3 provided with the determination part which determines these . The communication confirmation device according to any one of claims 1 to 3,
Whether the confirmation data generated by the generation unit is sent to the transfer unit that is the starting point of the communication confirmation section, and whether communication is normally performed in the communication confirmation section with reference to the returned confirmation data A determination unit for determining whether or not
The transfer unit;
A controller for setting a transfer rule for the transfer unit;
A network system comprising: Computer
For possible network set any forwarding rules for each transfer unit, and a reception process for accepting an designation of communication confirmation section communication should check the communication,
A generation step that generates a confirmation data according to the transfer rules in the specified confirmation interval accepted the designation,
Have
The confirmation data is sent to the transfer portion is a starting point of the communication confirmation interval, whether communication in the communication check period by referring to the confirmation data returned is normally performed is determined,
In the generation process, when the device outside the network receives the confirmation data, the device confirms the confirmation data so that the confirmation data is discarded in the protocol stack higher than the transport layer. Generate,
Communication confirmation method. Computer
For possible network set any forwarding rules for each transfer unit, and a reception process for accepting an designation of communication confirmation section communication should check the communication,
A generation step that generates a confirmation data according to the transfer rules in the specified confirmation interval accepted the designation,
Have
In the generation process, when the communication confirmation section includes a branch point that branches in a plurality of directions, the confirmation data is generated for each provisional section obtained by dividing the communication confirmation section at a transfer unit next to the branch point,
The confirmation data is sent to the transfer portion is a starting point of the communication confirmation interval, whether communication in the communication check period by referring to the confirmation data returned is normally performed it is determined With
The confirmation data corresponding to each of the temporary sections is transmitted, and it is determined whether or not communication is normally performed for each of the temporary sections.
Communication confirmation method. Computer
For possible network set any forwarding rules for each transfer unit, and a reception process for accepting an designation of communication confirmation section communication should check the communication,
A generation step that generates a confirmation data according to the transfer rules in the specified confirmation interval accepted the designation,
Have
The confirmation data is sent to the transfer portion is a starting point of the communication confirmation interval, whether communication in the communication check period by referring to the confirmation data returned is normally performed is determined,
Confirming communication with the transfer unit in the network by transmitting data different from the confirmation data to the transfer unit in the network and confirming a reply from the transfer unit that transmitted the data. Is done regularly,
Communication confirmation method. On the computer,
For possible network set any forwarding rules for each transfer unit, accepted procedures Ru is accepting the designation of communication confirmation interval should check communication of communication,
Generating instructions Ru to generate confirmation data according to the transfer rules in the specified confirmation interval accepted the designation,
And execute
The confirmation data is sent to the transfer portion is a starting point of the communication confirmation interval, whether communication in the communication check period by referring to the confirmation data returned is normally performed is determined,
In the generation procedure, when a device outside the network receives the confirmation data, the confirmation data is changed so that the confirmation data is discarded in a protocol stack higher than the transport layer in the device. Communication confirmation program to generate . On the computer,
For possible network set any forwarding rules for each transfer unit, accepted procedures Ru is accepting the designation of communication confirmation interval should check communication of communication,
Generating instructions Ru to generate confirmation data according to the transfer rules in the specified confirmation interval accepted the designation,
And execute
In the generation procedure, when the communication confirmation section includes a branch point that branches in a plurality of directions, the confirmation data is generated for each of the temporary sections obtained by dividing the communication confirmation section at a transfer unit next to the branch point,
The confirmation data is sent to the transfer portion is a starting point of the communication confirmation interval, whether communication in the communication check period by referring to the confirmation data returned is normally performed it is determined With
A communication confirmation program for transmitting the confirmation data corresponding to each of the provisional sections and determining whether or not communication is normally performed for each of the provisional sections . On the computer,
For possible network set any forwarding rules for each transfer unit, accepted procedures Ru is accepting the designation of communication confirmation interval should check communication of communication,
Generating instructions Ru to generate confirmation data according to the transfer rules in the specified confirmation interval accepted the designation,
And execute
The confirmation data is sent to the transfer portion is a starting point of the communication confirmation interval, whether communication in the communication check period by referring to the confirmation data returned is normally performed is determined,
Data different from the confirmation data is transmitted to the transfer unit in the network, and a reply from the transfer unit that transmitted the data is confirmed, thereby confirming communication with the transfer unit in the network. A communication confirmation program that is regularly performed .

Images