Control device, name resolution device, control method, and program

Abstract

Provided is a control device that controls a network, the control device comprising: a path search unit that determines a communication path from a first terminal to a second terminal in the network by being triggered by a name resolution request relating to communication from the first terminal to the second terminal; and a setting unit that sets a transmission path of the communication path for the network.

Description

Control Device, Name Resolution Device, Control Method, and Program

[0001] The present invention relates to a technique for setting a transmission path for a network.

[0002] A network that transfers packets is composed of a plurality of relay devices (which may be called transmission devices). In order to communicate between terminals using this network, it is necessary to design a communication path connecting the plurality of relay devices and set a transmission path through the communication path.

[0003] DNS RFC1034 https: / / www.rfc-editor.org / rfc / rfc1034LDAP RFC4511 https: / / www.rfc-editor.org / rfc / rfc4511Segment Routing Architecture RFC8402 https: / / www.rfc-editor.org / rfc / rfc8402

[0004] In the prior art, it was necessary to perform the above-described transmission path setting in advance before a communication request between terminals occurred. That is, there was a problem that communication could not be started quickly because pre-setting work for the transmission path was required before communication.

[0005] The present invention has been made in view of the above points, and an object thereof is to provide a technique for eliminating the need for pre-setting work for a transmission path in communication between terminals in a network.

[0006] According to the disclosed technique, there is provided a control device for controlling a network, including a route search unit that determines a communication path from the first terminal to the second terminal in the network triggered by a name resolution request regarding communication from the first terminal to the second terminal, and a setting unit that sets a transmission path of the communication path for the network.

[0007] According to the disclosed technique, a technique for eliminating the need for pre-setting work for a transmission path in communication between terminals in a network is provided.

[0008] This diagram shows a portion of a conventional network. This diagram shows a conventional network where terminals communicate with each other. This diagram shows a case where communication takes place across multiple domains. This diagram illustrates the configuration and operation of the communication system in Example 1. This diagram illustrates the configuration and operation of the communication system in Example 2. This diagram illustrates the configuration and operation of the communication system in Example 3. This diagram illustrates the frame forwarding method in Example 3. This diagram illustrates the configuration and operation of the communication system in PT1 in Example 4. This diagram illustrates the configuration and operation of the communication system in PT2 in Example 4. This diagram illustrates the frame forwarding method in PT2 in Example 4. This diagram illustrates the configuration and operation of the communication system in PT3 in Example 4. This diagram illustrates the configuration and operation of the communication system in Example 5. This is a functional configuration diagram of the controller 50. This is a functional configuration diagram of the controller 50. This is a functional configuration diagram of the directory service 40. This is a functional configuration diagram of the terminal 90. This is a functional configuration diagram of the accommodation device 60. This is a functional configuration diagram of the relay device 70. This is a functional configuration diagram of the connection device 80. This diagram shows an example of the hardware configuration of the device.

[0009] Hereinafter, embodiments of the present invention (this embodiment) will be described with reference to the drawings. The embodiments described below are merely examples, and the embodiments to which the present invention is applied are not limited to the embodiments described below.

[0010] First, the prior art and its problems will be described in more detail below, and then the technology according to this embodiment will be described in detail using examples.

[0011] (Regarding the prior art) Figure 1 shows a configuration in which relay device 1 and relay device 12, which are part of a conventional network, are connected by a link. Figure 2 shows a conventional network in which communication takes place between terminal T1 and terminal T2 via accommodation devices 10, 20 and a plurality of relay devices 11 to 19.

[0012] As shown in Figures 1 and 2, conventional networks achieve inter-terminal communication by forwarding packets hop-by-hop based on routing tables held by relay devices. Routing information is distributed using routing protocols such as OSPF, and each relay device updates its own routing table based on this routing information.

[0013] The communication path between terminals is calculated by the routing protocol at each relay device, using parameters such as link weighting and hop count. However, conventional technology cannot select a path that matches the bandwidth or quality requirements such as latency and jitter that the application wants to use.

[0014] Furthermore, when many terminals and relay devices are connected to the network, the routing tables held by the relay devices become larger. Therefore, when a terminal moves or a new link is created and the route changes, all the routing tables held by each relay device must be updated.

[0015] Figure 3 shows an example configuration for communication between terminals across multiple domains (e.g., carrier networks). In the example in Figure 3, connection devices 31 and 32 connect the domains. Note that "domain" may also be referred to as "network".

[0016] In other words, as shown in Figure 3, when communication spans multiple domains, the connecting device connects to adjacent domains and exchanges routing information between domains using a routing protocol such as BGP. Furthermore, if terminal configuration is required before application use begins, a mechanism is needed to perform this configuration separately between the opening of the communication path and the start of terminal-to-terminal communication.

[0017] (Regarding the problems) The problems related to this embodiment are as follows. Although this embodiment targets an IP network that performs packet forwarding, the technology related to this embodiment is applicable not only to IP networks.

[0018] <Problem 1> In order to forward packets, it is necessary to set a transmission path on a link on the appropriate communication route. With conventional technology, it is necessary to set the transmission path in advance for each terminal using the service.

[0019] <Problem 2> It is not possible to set a communication path that specifies network quality conditions (used bandwidth, maximum delay, and maximum jitter, etc.).

[0020] <Problem 3> As networks become larger and more complex, the routing tables of each relay device become larger, and the cost of keeping up with changes in terminal movement or the creation of new routes increases.

[0021] <Problem 4> When communication spans multiple domains, the problems described in Problems 1-3 become more pronounced.

[0022] <Challenge 5> A mechanism is needed to perform the necessary device settings for application use at an appropriate time.

[0023] (Regarding the technology of the embodiment) Below, Examples 1 to 5 will be described as the technology of this embodiment for solving the above problems. Example 1 corresponds to problem 1, Example 2 corresponds to problem 2, Example 3 corresponds to problem 3, Example 4 corresponds to problem 4, and Example 5 corresponds to problem 5.

[0024] (Example 1) First, let's explain Example 1. We will first explain the overview, and then the configuration and operation. Example 1 is a method that sets the transmission path triggered by name resolution, and this is called the "basic method".

[0025] <Example 1: Overview> Terminals (servers) that provide services on a network are assigned highly readable service names (FQDN, etc.).

[0026] On the other hand, since communication along the path through which packets are forwarded is processed based on addresses rather than service names, a name resolution mechanism is needed to convert service names to addresses. This mechanism is called a directory service. Examples of directory services include DNS (Domain Name System) disclosed in Non-Patent Document 1 and LDAP (Lightweight Directory Access Protocol) disclosed in Non-Patent Document 2.

[0027] On the other hand, in order to forward packets according to the routing table, it is necessary to configure the transmission path on the appropriate route, in the links between the receiving device and the relay device, and in the links between relay devices. Conventionally, it has been common to configure this setting in advance for each terminal using the service. In contrast, in Example 1, the transmission path is configured when querying the directory service (during name resolution).

[0028] In Embodiment 1, the directory service 40 sends the source address and destination address (translated address) for inter-terminal communication to the controller 50. The controller 50 calculates the communication path and instructs the access devices and relay devices through which the inter-terminal communication passes to set the transmission path. Note that instructing the access devices and relay devices to set the transmission path can be rephrased as setting the transmission path for the network.

[0029] Once the transmission path is configured, the controller 50 returns a confirmation of configuration completion to the directory service 40, and the directory service 40 returns the address of the terminal (server) to the terminal (client). The terminal (client) sends a packet destined for the terminal (server), and inter-terminal communication takes place thereafter. In this embodiment, packet forwarding at each relay device is performed based on the routing table maintained by each relay device.

[0030] <Example 1: Configuration and Operation> Referring to Figure 4, the configuration and operation of the communication system in Example 1 will be described. As shown in the upper part of Figure 4, the communication system of Example 1 includes terminal T1, terminal T2, accommodation devices G1 to G2, relay devices N1 to N9, directory service 40 (specifically, devices such as servers), and controller 50.

[0031] The devices in the accommodation devices G1 to G2 and the relay devices N1 to N9 are connected by links (which may also be called transmission lines). The accommodation devices G1 to G2 and the relay devices N1 to N9 constitute a domain.

[0032] In Example 1 (and Examples 2-5), it is assumed that terminal T1 is the client and terminal T2 is the server. In the following description, terminals T1 and T2 may be referred to by their respective codes, T1 and T2.

[0033] Referring to Figure 4, an example of the operation of the communication system in Example 1 will be explained.

[0034] In step S1, terminal T1 generates a communication request to T2. In step S2, terminal T1 requests the address of T2 from the directory service 40. In other words, it sends a name resolution request to the directory service 40.

[0035] In S3, the directory service 40 obtains the address of T2 (x.x.x.x). Specifically, the directory service 40 obtains the address by performing name resolution from the service name (FQDN, etc.) of T2.

[0036] In S4, the directory service 40 requests the controller 50 to configure a communication path from T1 to T2.

[0037] In S5, the controller 50 calculates the communication path from T1 to T2 and determines the communication path. In S6, the controller 50 instructs the receiving devices and relay devices along the communication path determined in S5 to set the transmission path.

[0038] In S7, the controller 50 notifies the directory service 40 that the communication path setting is completed. In S8, the directory service 40 answers the terminal T1 with the address of T2 (T2 = x.x.x.x). The terminal T1 transmits a packet addressed to the terminal T2 using this address, and thereafter, communication between terminals is performed (S9).

[0039] <Effect of Example 1> In order to transfer a packet in a network, it is necessary to set a transmission path on an appropriate link, and it has been common practice to perform the setting in advance for each terminal using the service. On the other hand, in the technique according to Example 1, since the transmission path is also set at the time of name resolution by the directory service 40, the prior transmission path setting work becomes unnecessary. As a result, the labor of prior setting becomes unnecessary, and communication can be started promptly.

[0040] (Example 2) Next, Example 2 will be described. First, the outline will be described, and then the configuration and operation will be described. Example 2 is a method in which quality conditions are specified in addition to the basic method.

[0041] <Example 2: Outline> With the technique according to Example 1, it has become possible to set a transmission path triggered by a name resolution request to the directory service 40. In Example 1, this transmission path is calculated based on the information (number of hops, weighting, etc.) grasped by the controller 50. On the other hand, in a conventional network (and only the basic method of Example 1), it is not possible to select a path that satisfies the quality conditions (used bandwidth, maximum delay, maximum jitter, etc.) required by the application. Therefore, in Example 2, when the transmission path is opened, the controller 50 calculates a path that can satisfy the quality conditions.

[0042] In a conventional network (and only the basic method of Example 1), it is not possible to select a path that satisfies the quality conditions (used bandwidth, maximum delay, and maximum jitter, etc.) required by the application.

[0043] Therefore, in Example 2, when the transmission path is opened, the controller 50 calculates a path that can satisfy the quality conditions.

[0044] In Example 2, first, in a name resolution inquiry to the directory service 40, the terminal T1 adds, in addition to the service name information, quality condition information required by the application.

[0045] After performing the conversion from the service name to the address, the directory service 40 transmits the address information and the quality condition information to the controller 50. The controller 50 calculates a path that satisfies the quality conditions and instructs the accommodating device and the relay device to be passed through to set the transmission path.

[0046] If there is no path that satisfies the quality conditions, the controller 50 returns a message indicating that the setting of the transmission path has failed and notifies the terminal T1 via the directory service 40. Alternatively, a transmission path that satisfies only some of the quality conditions may be set. In this case, the terminal T1 is notified that only some of the quality conditions are satisfied. Also, in the name resolution query to the directory service 40, the terminal T1 can specify which quality conditions are to be prioritized.

[0047] <Example 2: Configuration and Operation> Referring to FIG. 5, the configuration and operation of the communication system in Example 2 will be described. As shown in the upper part of FIG. 5, the communication system of Example 2 has the same configuration as the communication system of Example 1, and includes the terminal T1, the terminal T2, the accommodating devices G1 to G2, the relay devices N1 to N9, the directory service 40 (specifically, a device such as a server), and the controller 50.

[0048] The devices in the accommodating devices G1 to G2 and the relay devices N1 to N9 are connected by links (which may also be called transmission paths). The accommodating devices G1 to G2 and the relay devices N1 to N9 constitute a domain.

[0049] Referring to FIG. 5, an operation example of the communication system in Example 2 will be described.

[0050] In S1, a communication request from the terminal T1 to the terminal T2 occurs. In S2, the terminal T1 requests the directory service 40 for the address of the terminal T2. In Example 2, the request to the directory service 40 includes conditions necessary for communication (e.g., the bandwidth, delay, or jitter required for communication).

[0051] In S3, the directory service 40 obtains the address of T2 (x.x.x.x). Specifically, the directory service 40 obtains the address by performing name resolution from the service name (FQDN, etc.) of T2.

[0052] In S4, the directory service 40 requests the controller 50 to configure a communication path from T1 to T2. In Embodiment 2, the request to the controller 50 includes the conditions necessary for communication (e.g., bandwidth, delay, or jitter required for communication) received from the terminal in S2.

[0053] In S5, the controller 50 calculates an appropriate communication path from T1 to T2 that satisfies all conditions and determines the communication path. In S6, the controller 50 sets the transmission path for the receiving devices and relay devices along the communication path determined in S5.

[0054] In S7, the controller 50 notifies the directory service 40 that the communication path setup is complete. In S8, the directory service 40 replies to terminal T1 with the address of T2 (T2 = x.x.x.x). Terminal T1 sends a packet addressed to terminal T2 using this address, and inter-terminal communication takes place thereafter (S9).

[0055] <Effects of Example 2> The technology according to Example 2 makes it possible to set a communication path that specifies network quality conditions (used bandwidth, maximum delay, and maximum jitter, etc.).

[0056] (Example 3) Next, Example 3 will be described. First, an overview will be given, followed by a description of the configuration and operation. Example 3 is a method that uses a transit link list in addition to the "basic method" + "quality condition specification". Note that in Example 3, "quality condition specification" may be omitted.

[0057] <Example 3: Overview> The technologies described in Examples 1 and 2 enable the setting of a transmission path triggered by a query to the directory service 40, making it possible to request a transmission path that meets the quality requirements of the application.

[0058] However, when a large number of terminals and relay devices are connected to the network, the routing tables held by the relay devices become large, and when a terminal moves or a new link is created and the route changes, it becomes necessary to update the routing tables held by each relay device, which presents a scalability problem.

[0059] In other words, since route selection is performed for each frame on the relay device, the routing table becomes bloated when a large number of terminals are accommodated. Furthermore, considering mobile communication, such as when terminal T1 connects to another accommodation device, the routing tables of all relay devices must be updated when the device is in motion.

[0060] To address these challenges, in Embodiment 3, the relay device does not maintain a routing table; instead, routing information (link information) is added to the transmitted and received frames. The relay device simply needs to refer to the frame header (pop the first element) and send the frame to the appropriate link. Specifically, this is done as follows. Note that frames may also be called packets.

[0061] In Embodiment 3, after calculating the route, the controller 50 instructs each relay device to set the communication route (transmission path) and returns the communication route information, which lists the links to be traversed, to the directory service 40.

[0062] The directory service 40 returns the address of terminal T2 (server) and communication path information to terminal T1 (client). Terminal T1 (client) reverses the list of links described in the communication path information (with the first link traversed at the beginning) and adds it to the frame as a header.

[0063] The terminal, receiving device, and relay device each pop the link information at the beginning of the frame and send the frame to that link. Popping means retrieving data (in this case, link information) from the top of the list. By repeating this operation, the link information is eventually removed from the frame header, and only the payload reaches terminal T2 (server).

[0064] While the idea of ​​including communication path information in the header is similar to the concept of Segment Routing (Non-Patent Document 3), Segment Routing specifies the nodes to be traversed, whereas Embodiment 3 specifies the links to be traversed, making them significantly different.

[0065] <Example 3: Configuration and Operation> Referring to Figure 6, the configuration and operation of the communication system in Example 3 will be described. As shown in the upper part of Figure 6, the communication system of Example 3 has the same configuration as the communication systems of Examples 1 and 2, and includes terminal T1, terminal T2, accommodation devices G1 to G2, relay devices N1 to N9, directory service 40 (specifically, devices such as servers), and controller 50.

[0066] The devices in the accommodation devices G1 to G2 and the relay devices N1 to N9 are connected by links (which may also be called transmission lines). The accommodation devices G1 to G2 and the relay devices N1 to N9 constitute a domain.

[0067] Referring to Figure 6, an example of the operation of the communication system in Example 3 will be explained.

[0068] In S11, terminal T1 generates a communication request to T2. In S12, terminal T1 requests the address of T2 from directory service 40. The request to directory service 40 may include conditions necessary for communication (e.g., bandwidth, delay, or jitter required for communication).

[0069] In S13, the directory service 40 obtains the address of T2 (x.x.x.x). Specifically, the directory service 40 obtains the address by performing name resolution from the service name (FQDN, etc.) of T2.

[0070] In S14, the directory service 40 requests communication path information from T1 to T2 from the controller 50. The request to the controller 50 may include conditions necessary for communication (e.g., bandwidth, delay, or jitter required for communication).

[0071] In S15, the controller 50 calculates the communication path from T1 to T2 and determines the communication path. In S16, the controller 50 instructs the receiving devices and relay devices along the communication path determined in S15 to set the transmission path.

[0072] In S17, the controller 50 responds to the directory service 40 with communication path information. Specifically, it responds with path = a-b-d-g-j-l-m-n, which is the path (connection information for multiple links) shown in the upper part of Figure 6.

[0073] In S18, the directory service 40 responds to terminal T1 with the address of T2 (T2 = x.x.x.x) along with path = a-b-d-g-j-l-m-n.

[0074] Subsequently, frame transfer takes place as shown in Figure 7. First, terminal T1 adds the communication path information, path, returned from directory service 40, to the frame header in reverse order, pops a, and sends the frame to link a.

[0075] The beginning of the frame received by the receiving device G1 indicates the link b to be transmitted next. The receiving device G1 removes b from the beginning of the frame and transmits the frame to link b.

[0076] Similarly, the beginning of the frame received by relay device N1 indicates the link d to be transmitted next. Relay device N1 removes d from the beginning of the frame and transmits the frame to link d. This process is repeated until the payload finally reaches terminal T2.

[0077] <Effects of Example 3> With the technology of Example 3, even if the network becomes large and complex, settings are only applied to relay devices on the path between communication terminals. Therefore, the routing tables of each relay device do not become bloated, and the costs of tracking when terminals move or new paths are created can be kept constant.

[0078] (Example 4) Next, Example 4 will be described. First, an overview will be given, followed by a description of the configuration and operation. Example 4 is a multi-domain compatible method.

[0079] <Example 4: Overview> In Example 4, the technology described in Examples 1 to 3 is extended to a network in which multiple domains are connected. In Example 4, the technology of any of Examples 1 to 3 may be applied.

[0080] In Example 4, the domains are connected by connection devices G2 and G3 and link g, and the directory service 40 of each domain is known about the connection devices and links that connect to other domains.

[0081] Furthermore, in Example 4, the directory service has a hierarchical structure, and if name resolution is not possible, it recursively queries the higher-level directory service. If the name resolution request is for a known domain, it queries the corresponding lower-level directory service.

[0082] In Example 4, the above method makes it possible to determine the communication path between the terminal and the connected device within each domain.

[0083] Finally, the directory service 40A aggregates the communication paths for domain A, the communication paths for domain B, and the address of terminal T2, and returns them to terminal T1. This enables communication between terminal T1 and terminal T2.

[0084] Furthermore, the upper-level directory service is aware of the connection devices and links related to the connections of each domain. This allows for similar extension when three or more domains are linked, such as domains A-B-C-D...

[0085] Furthermore, if each telecommunications carrier has its own domain, there may be cases where you want to conceal the communication path from other companies. In such cases, the link list after the connecting device may be omitted.

[0086] In this case, when the connecting device G3 pops the route omission symbol (*B) for its own domain from the received frame, it queries the controller 40B for the communication path from G3 to T2 in its own domain, reattaches the header, and similarly forwards the frame within the domain 40B to deliver it to terminal T2.

[0087] Below, we will describe the configuration and operation of Example 4, specifically PT1 (Pattern 1), PT2, and PT3. PT1 and PT2 are examples of applying Example 3 to Example 4, while PT3 is an example of applying Example 1 (or Example 2) to Example 4.

[0088] <PT1 of Example 4: Configuration and Operation> Referring to Figure 8, the configuration and operation of the communication system in PT1 of Example 4 will be described. As shown in the upper part of Figure 8, the communication system of PT1 of Example 4 has, on the Domain A side, a terminal T1, an access device G1, a connection device G2, a directory service 40A (specifically, a device such as a server), and a controller 50A, and on the Domain B side, a terminal T2, an access device G4, a connection device G3, a directory service 40B (specifically, a device such as a server), and a controller 50B. An upper directory service 400 is also provided. Note that there are multiple relay devices in each domain.

[0089] Referring to Figure 8, an example of the operation of the communication system in PT1 of Embodiment 4 will be described. Note that the step numbers are used for reference in the explanation and do not necessarily correspond exactly to the order of processing.

[0090] In S21, terminal T1 generates a communication request to T2. In S22, terminal T1 requests the address of T2 from directory service 40A. That is, it sends a name resolution request to directory service 40A. Here, we assume that directory service 40A was unable to resolve the name. In S23, directory service 40A requests the address of T2 from the upper directory service 400. That is, it sends a name resolution request to the upper directory service 400.

[0091] In S24, the upper directory service 400 determines that T2 belongs to domain B.

[0092] In S25, the upper directory service 400 notifies the directory service 40A that T2 belongs to domain B.

[0093] In S26, the upper directory service 400 requests the address of T2 from directory service 40B. In other words, it submits a name resolution request to directory service 40B.

[0094] In S27, the directory service 40B obtains the address of T2 (x.x.x.x). In S28, the directory service 40B determines that communication between T1 and T2 will be connected via domain A and G3+g (accommodation device G3 and link g). In S29, the directory service 40B requests the controller 50B to configure a communication path from G3 to T2.

[0095] In S30, the controller 50B calculates the communication path from G3 to T2 and determines the communication path. In S31, the controller 50B sets the communication path (transmission path) in domain B.

[0096] On the other hand, on the side of domain A, after S25, in S32, directory service 40A determines that it will connect with domain B via G2+g for communication between T1 and T2.

[0097] In S33, the directory service 40A requests the controller 50A to configure a communication path from T1 to G2.

[0098] In S34, the controller 50A calculates the communication path from T1 to G2 and determines the communication path. In S35, the controller 50A sets the communication path (transmission path) in domain A.

[0099] In S36 on the Domain B side, the controller 50B responds to the directory service 40B with communication path information. Specifically, it responds with path=g-j-l-m-n. In S37, the directory service 40B responds to the upper directory service 400 with the address of T2 (T2=x.x.x.x) and path=g-j-l-m-n.

[0100] In S38, the upper directory service 400 responds to the directory service 40A with the address of T2 (T2 = x.x.x.x) and path = g-j-l-m-n.

[0101] Meanwhile, after S35, in S39, the controller 50A responds to the directory service 40A with communication path information. Specifically, it responds with path=a-b-d-g. In S40, the directory service 40A generates path=a-b-d-g-j-l-m-n from path=g-j-l-m-n and path=a-b-d-g, and responds to terminal T1 with the address of T2 (T2=x.x.x.x) and path=a-b-d-g-j-l-m-n. After that, communication between T1 and T2 takes place in the manner described in Embodiment 3 (S41).

[0102] <PT2 in Example 4: Configuration and Operation> Referring to Figures 9 and 10, the configuration and operation of the communication system in PT2 in Example 4 will be described. PT2 is an example of operation when routing information is hidden between domains. The configuration of PT2 in Example 4 is the same as the configuration of PT1 in Example 4.

[0103] Referring to Figures 9 and 10, an example of the operation of the communication system in PT2 of Embodiment 4 will be described. Note that the step numbers are used for reference in the explanation and do not necessarily correspond exactly to the order of processing.

[0104] The processes S21 to S35 in Figure 9 are the same as the processes S21 to S35 in Figure 8 (PT1).

[0105] In PT2, Domain B intends to conceal routing information from Domain A. Here, the routing information to be concealed will be denoted as "*B".

[0106] In S36 on the Domain B side, the controller 50B responds to the directory service 40B with path=g-*B as communication path information. In S37, the directory service 40B responds to the upper directory service 400 with the address of T2 (T2=x.x.x.x) and path=g-*B.

[0107] In S38, the upper directory service 400 responds to the directory service 40A with the address of T2 (T2 = x.x.x.x) and path = g - *B.

[0108] Meanwhile, after S35, in S39, the controller 50A responds to the directory service 40A with communication path information. Specifically, it responds with path=a-b-d-g. In S40, the directory service 40A responds to terminal T1 with the address of T2 (T2=x.x.x.x) and path=a-b-d-g-*B.

[0109] Next, as shown in Figure 10, similar to Example 3, terminal T1 adds the path returned from directory service 40A to the frame header in reverse order and transmits it. The transmission procedure until reaching domain B is also the same as in Example 3.

[0110] After the frame reaches the connecting device G3 of domain B, if the connecting device G3 pops the route omission symbol (*B) for its own domain, in S51 it queries the controller 50B for the communication path from G3 to T2.

[0111] In S52, the controller 50B responds to the connection device G3 with path = j-l-m-n as communication path information. The connection device G3 reattaches the header to the path and transmits the frame. Subsequently, frame transfer is performed in the same manner as in Embodiment 3, and the payload reaches terminal T2.

[0112] <PT3 in Example 4: Configuration and Operation> Referring to Figure 11, the configuration and operation of the communication system in PT3 in Example 4 will be described. PT3 is an example of operation when Example 1 (or Example 2) is applied. The configuration of PT3 in Example 4 is the same as the configuration of PT1 in Example 4.

[0113] The processes S21 to S35 in Figure 11 are the same as the processes S21 to S35 in Figure 8 (PT1).

[0114] In S36 on the Domain B side, the controller 50B responds to the directory service 40B that the communication path setup is complete. In S37, the directory service 40B responds to the upper directory service 400 with the address of T2 (T2 = x.x.x.x).

[0115] In S38, the upper directory service 400 responds to the directory service 40A with the address of T2 (T2 = x.x.x.x).

[0116] Meanwhile, after S35, in S39, the controller 50A responds to the directory service 40A that the communication path setup is complete. In S40, the directory service 40A responds to terminal T1 with the address of T2 (T2 = x.x.x.x). After that, communication takes place between T1 and T2 (S41). In PT3, each relay device performs packet forwarding using the routing table.

[0117] <Effects of Example 4> The technology of Example 4 makes it possible to implement communication across multiple domains by extending Examples 1 to 3, and the effects of Examples 1 to 3 can also be obtained.

[0118] (Example 5) Finally, Example 5 will be described. First, an overview will be given, followed by a description of the configuration and operation. Example 5 is a method that performs terminal pre-configuration in addition to the basic method.

[0119] <Example 5: Overview> In Example 5, the technology related to communication paths such as relay devices in Examples 1 to 4 is extended, and a mechanism is introduced to simultaneously configure terminal T2 (server).

[0120] In Example 5, when terminal T1 sends a name resolution request to directory service 40, it sends the pre-configuration information of terminal T2 (server) in the same manner as in Example 2, including quality conditions. In addition to setting the transmission path, controller 50 also performs the pre-configuration of terminal T2 (server).

[0121] The pre-configuration of terminal T2 (server) is not limited to specific pre-configurations, but for example, the configurations in Examples 1 and 2 below are possible.

[0122] Example 1: If terminal T2 is a virtualization platform, it will start and configure VMs, containers, etc.

[0123] Example 2: If terminal T2 is equipped with SmartNIC, it will load programs and set policies.

[0124] <Example 5: Configuration and Operation> Referring to Figure 12, the configuration and operation of the communication system in Example 5 will be described. As shown in the upper part of Figure 12, the communication system of Example 5 has the same configuration as the communication system of Example 1, and includes terminal T1, terminal T2, accommodation devices G1 to G2, relay devices N1 to N9, directory service 40 (specifically, devices such as servers), and controller 50.

[0125] The devices in the accommodation devices G1 to G2 and the relay devices N1 to N9 are connected by links (which may also be called transmission lines). The accommodation devices G1 to G2 and the relay devices N1 to N9 constitute a domain.

[0126] Referring to Figure 12, an example of the operation of the communication system in Example 5 will be described.

[0127] In S61, terminal T1 generates a communication request to T2. In S62, terminal T1 requests the address of T2 from the directory service 40. In Embodiment 5, the request to the directory service 40 includes the preconfiguration information of terminal T2.

[0128] In S63, the directory service 40 obtains the address of T2 (x.x.x.x). Specifically, the directory service 40 obtains the address by performing name resolution from the service name of T2 (FQDN, etc.).

[0129] In S64, the directory service 40 requests the controller 50 to configure a communication path from T1 to T2. In Embodiment 5, the request to the controller 50 includes the preconfiguration information of terminal T2 received from terminal T1 in S62.

[0130] In S65, the controller 50 calculates the communication path from T1 to T2 and determines the communication path. In S66, the controller 50 instructs the receiving devices and relay devices on the communication path determined in S65 to set the transmission path. Furthermore, the controller 50 performs pre-configuration on terminal T2 based on the pre-configuration information.

[0131] In S67, the controller 50 notifies the directory service 40 that the communication path setup is complete. In S68, the directory service 40 replies to terminal T1 with the address of T2 (T2 = x.x.x.x). Terminal T1 sends a packet addressed to terminal T2 using this address, and inter-terminal communication takes place thereafter (S69).

[0132] <Effects of Example 5> The technology of Example 5 makes it possible to set up terminal T2 (server), which is necessary for starting application use, triggered by name resolution.

[0133] (Example of device configuration) Next, we will explain the functional configuration of each device that has been described in the operation described so far.

[0134] Figure 13 shows the functional configuration of the controller 50. As shown in Figure 13, the controller 50 includes a terminal communication unit 51, a receiving device communication unit 52, a relay device communication unit 53, a connection device communication unit 54, a DS communication unit 55, and a route search unit 56. The controller may also be called a "control device".

[0135] The terminal communication unit 51 communicates with the terminal. The terminal communication unit 51 also exchanges information regarding pre-configurations with the terminal.

[0136] The receiving device communication unit 52, the relay device communication unit 53, and the connection device communication unit 54 each communicate with the corresponding device. In addition, the receiving device communication unit 52, the relay device communication unit 53, and the connection device communication unit 54 each exchange information with the device they communicate with for purposes such as setting the transmission path.

[0137] The DS communication unit 55 communicates with the directory service 40. The DS communication unit 55 exchanges information regarding communication path configuration with the directory service 40. The route search unit 56 searches for and determines a communication path between terminals in response to a communication path configuration request.

[0138] The controller 50 (control device) may have the configuration shown in Figure 14. The controller 50 shown in Figure 14 is a device that controls a network having multiple relay devices, and includes a route search unit 51 that determines the communication path from the first terminal to the second terminal in the network, triggered by a name resolution request for communication from the first terminal to the second terminal, and a setting unit 57 that sets the transmission path of the communication path for the network.

[0139] The name resolution request may include communication quality conditions, and the route search unit 51 may determine the communication path that satisfies the quality conditions. The setting unit 57 may transmit link information consisting of a plurality of links indicating the communication path to the first terminal, and the first terminal may transmit a frame containing the link information. The name resolution request may include pre-configuration information for the second terminal, and the setting unit 57 may perform pre-configuration for the second terminal based on the pre-configuration information.

[0140] Figure 15 shows the functional configuration of the directory service 40. As shown in Figure 15, the directory service 40 includes a controller communication unit 41, a domain management unit 42, a name resolution unit 43, a terminal communication unit 44, an upper DS communication unit 45, and a lower DS communication unit 46. The directory service may also be called a name resolution device.

[0141] The controller communication unit 41 communicates with the controller 50. The controller communication unit 41 exchanges information with the controller 50 regarding communication path settings.

[0142] The domain management unit 42 manages information regarding connections between its own domain and other domains. The name resolution unit 43 translates names into addresses in response to name resolution requests from terminals.

[0143] The terminal communication unit 44 communicates with the terminal. The terminal communication unit 44 exchanges information regarding name resolution with the terminal with which it communicates.

[0144] The upper DS communication unit 45 communicates with the upper DS and references and sets information from other domains. The lower DS communication unit 46 communicates with the lower DS and references and sets information from other domains.

[0145] Furthermore, when the directory service 40 functions as an upper directory service, the directory service 40 may be a name resolution device used for a connected network to which multiple networks are connected, including a first network to which the first terminal belongs and a second network to which the second terminal belongs.

[0146] The name resolution unit 43 of the directory service 40 receives a name resolution request regarding communication from the first terminal to the second terminal from the first name resolution device used in the first network, replies to the first name resolution device that the second terminal belongs to the second network, and transmits the name resolution request to the second name resolution device used in the second network.

[0147] Triggered by the aforementioned response, a transmission path for communication from the first terminal to the second terminal is set up in the first network, and triggered by the name resolution request to the second name resolution device, a transmission path for communication from the first terminal to the second terminal is set up in the second network.

[0148] Figure 16 shows the functional configuration of terminal 90. As shown in Figure 16, terminal 90 has a controller communication unit 91, a DS communication unit 92, and an application 93. Terminal 90 can be used as any of the terminals in Embodiments 1 to 5.

[0149] The controller communication unit 91 communicates with the controller 50. For example, the controller communication unit 91 exchanges information regarding pre-configurations with the controller 50.

[0150] The DS communication unit 92 communicates with the directory service 40. The DS communication unit 92 exchanges name resolution requests with the directory service 40. The application 93 is a program used by the user.

[0151] Figure 17 shows the functional configuration of the storage device 60. As shown in Figure 17, the storage device 60 has a controller communication unit 61 and a transfer processing unit 62. The storage device 60 can be used as any of the storage devices in Embodiments 1 to 5.

[0152] The controller communication unit 61 communicates with the controller 50. The controller communication unit 61 exchanges information with the controller 50 for purposes such as setting the transmission path. The transfer processing unit 62 transfers the received frame based on the settings.

[0153] Figure 18 shows the functional configuration of the relay device 70. As shown in Figure 18, the relay device 70 has a controller communication unit 71 and a transfer processing unit 72. The relay device 70 can be used as any of the relay devices in Examples 1 to 5.

[0154] The controller communication unit 71 communicates with the controller 50. The controller communication unit 71 exchanges information with the controller 50 for purposes such as setting the transmission path. The transfer processing unit 72 transfers the received frame based on the settings.

[0155] Figure 19 shows the functional configuration of the connection device 80. As shown in Figure 19, the connection device 80 has a controller communication unit 81 and a transfer processing unit 82. The connection device 80 can be used as any of the connection devices in Embodiments 1 to 5.

[0156] The controller communication unit 81 communicates with the controller 50. The controller communication unit 81 exchanges information with the controller 50 for purposes such as setting the transmission path. The transfer processing unit 82 transfers the received frame based on the settings.

[0157] (Example Hardware Configuration) Any of the devices described in this embodiment (terminal, controller, directory service, control device, name resolution device, etc.) can be realized, for example, by having a computer run a program. This computer may be a physical computer or a virtual machine on the cloud.

[0158] In other words, the device can be realized by using hardware resources such as the CPU and memory built into a computer to execute a program corresponding to the processing performed by the device. The program can be recorded on a computer-readable recording medium (such as portable memory), saved, and distributed. It can also be provided via a network, such as the Internet or email.

[0159] Figure 20 shows an example of the hardware configuration of the computer described above. The computer in Figure 20 has a drive device 1000, an auxiliary storage device 1002, a memory device 1003, a CPU 1004, an interface device 1005, a display device 1006, an input device 1007, an output device 1008, etc., all of which are interconnected by bus B. The computer may also be equipped with a GPU.

[0160] The program that enables processing on the computer is provided on a recording medium 1001, such as a CD-ROM or memory card. When the recording medium 1001 containing the program is set in the drive device 1000, the program is installed from the recording medium 1001 to the auxiliary storage device 1002 via the drive device 1000. However, the program does not necessarily have to be installed from the recording medium 1001; it may also be downloaded from another computer via a network. The auxiliary storage device 1002 stores the installed program as well as necessary files and data.

[0161] The memory device 1003 reads and stores a program from the auxiliary storage device 1002 when a program startup command is received. The CPU 1004 implements the functions related to the memory device 1003 according to the program stored in the memory device 1003. The interface device 1005 is used as an interface for connecting to a network, etc. The display device 1006 displays a GUI (Graphical User Interface) etc., based on a program. The input device 1007 consists of a keyboard and mouse, buttons, or a touch panel, etc., and is used to input various operation commands. The output device 1008 outputs the calculation results.

[0162] (Summary of Embodiments, Effects, etc.) As described above, the technology described in this embodiment makes it possible to eliminate the need for prior transmission path configuration work when communicating between terminals over a network.

[0163] The following additional information is disclosed regarding the embodiments described above.

[0164] <Notes> (Note 1) A control device for controlling a network, comprising: a route search unit that determines a communication path from the first terminal to the second terminal in the network, triggered by a name resolution request relating to communication from the first terminal to the second terminal; and a setting unit that sets a transmission path for the communication path in the network. (Note 2) The control device according to Note 1, wherein the name resolution request includes quality conditions for the communication, and the route search unit determines the communication path that satisfies the quality conditions. (Note 3) The control device according to Note 1, wherein the setting unit transmits link information consisting of a plurality of links indicating the communication path to the first terminal, and the first terminal transmits a frame containing the link information. (Note 4) The control device according to Note 1, wherein the name resolution request includes pre-configuration information for the second terminal, and the setting unit performs pre-configuration for the second terminal based on the pre-configuration information. (Appendix 5) A name resolution device used for a connected network to which a plurality of networks are connected, each having a first network to which a first terminal belongs and a second network to which a second terminal belongs, comprising a name resolution unit that receives a name resolution request relating to communication from the first terminal to the second terminal from a first name resolution device used in the first network, replies to the first name resolution device that the second terminal belongs to the second network, and transmits the name resolution request to a second name resolution device used in the second network, wherein the reply triggers the establishment of a transmission path for communication from the first terminal to the second terminal in the first network, and the name resolution request to the second name resolution device triggers the establishment of a transmission path for communication from the first terminal to the second terminal in the second network.(Appendix 6) A control method executed by a control device that controls a network, comprising: a pathfinding step of determining a communication path from the first terminal to the second terminal in the network, triggered by a name resolution request relating to communication from the first terminal to the second terminal; and a setting step of setting a transmission path for the communication path in the network. (Appendix 7) A non-temporary storage medium storing a program for causing a computer to function as each part of the control device described in any one of Appendix 1 to 4. (Appendix 8) A non-temporary storage medium storing a program for causing a computer to function as each part of the name resolution device described in Appendix 5.

[0165] Although this embodiment has been described above, the present invention is not limited to this specific embodiment, and various modifications and changes are possible within the scope of the gist of the invention as described in the claims.

[0166] 10, 20 Accommodation devices 11-19 Relay devices 31, 32 Connection devices T1, T2 Terminals G1, G4 Accommodation device G2 Accommodation device, connection device G3 Connection device N1-N9 Relay devices 40 Directory service 41 Controller communication unit 42 Domain management unit 43 Name resolution unit 44 Terminal communication unit 45 Upper DS communication unit 46 Lower DS communication unit 400 Upper directory service 50 Controller 51 Terminal communication unit 52 Accommodation device communication unit 53 Relay device communication unit 54 Connection device communication unit 55 DS communication unit 56 Route search unit 57 Configuration unit 60 Accommodation devices 61, 71, 81, 91 Controller communication unit 62, 72, 82 Transfer processing unit 70 Relay device 80 Connection device 90 Terminal 92 DS communication unit 93 Application 1000 Drive device 1001 Recording medium 1002 Auxiliary storage device 1003 Memory device 1004 CPU 1005 Interface device 1006 Display device 1007 Input device 1008 Output device

Claims

1. A control device for controlling a network, comprising: a route search unit that determines a communication path from the first terminal to the second terminal in the network, triggered by a name resolution request relating to communication from the first terminal to the second terminal; and a setting unit that sets a transmission path for the communication path in the network.

2. The control device according to claim 1, wherein the name resolution request includes the quality conditions of the communication, and the route search unit determines the communication route that satisfies the quality conditions.

3. The control device according to claim 1, wherein the setting unit transmits link information consisting of a plurality of links indicating the communication path to the first terminal, and the first terminal transmits a frame including the link information.

4. The control device according to claim 1, wherein the name resolution request includes pre-configuration information for the second terminal, and the configuration unit performs pre-configuration for the second terminal based on the pre-configuration information.

5. A name resolution device used for a connected network to which a plurality of networks are connected, each having a first network to which a first terminal belongs and a second network to which a second terminal belongs, the name resolution device comprising: a name resolution unit that receives a name resolution request relating to communication from the first terminal to the second terminal from a first name resolution device used in the first network, replies to the first name resolution device that the second terminal belongs to the second network, and transmits the name resolution request to a second name resolution device used in the second network, wherein, triggered by the reply, a transmission path for communication from the first terminal to the second terminal is set in the first network, and triggered by the name resolution request to the second name resolution device, a transmission path for communication from the first terminal to the second terminal is set in the second network.

6. A control method executed by a control device that controls a network, comprising: a route search step that determines a communication path from the first terminal to the second terminal in the network, triggered by a name resolution request relating to communication from the first terminal to the second terminal; and a setting step that sets a transmission path for the communication path in the network.

7. A program for causing a computer to function as a component of the control device described in any one of claims 1 to 4.

8. A program for causing a computer to function as a component of the name resolution device described in claim 5.

Images