Device and method for controlling route of traffic flow

A route control device controls a route of a traffic flow in a server device that accommodates a plurality of entities. The route control device includes: a generator, a processor and a route controller. The generator generates first control information that indicates a right to indicate a route of the traffic flow in a first range of the server device. The processor receives first route indication information that indicates a route of the traffic flow and the first control information from a first entity in the plurality of entities and decides whether the first route indication information indicates a route in the first range. The route controller controls a route of the traffic flow based on the first route indication information when the first route indication information indicates a route in the first range.

CROSS-REFERENCE TO RELATED APPLICATION

This application is based upon and claims the benefit of priority of the prior Japanese Patent Application No. 2017-130095, filed on Jul. 3, 2017, the entire contents of which are incorporated herein by reference.

FIELD

The embodiments discussed herein are related to a device and a method for controlling a route of a traffic flow.

BACKGROUND

In recent years, a configuration in which an application is arranged in an edge server, not on a cloud, has been put into practical use, in order to reduce a delay in access to the application from a terminal. In this case, the edge server controls a route such that a traffic flow passes through one or more applications arranged in the edge server. Further, the edge server guides, as needed, the traffic flow to another application (such as a business application) arranged on a cloud. In a mobile network, the edge server may be arranged, for example, near a base station.

FIG. 1illustrates an example of a network that includes an edge server. In the example illustrated inFIG. 1, a business application (B_APP)300of an organization A is arranged on a cloud. The “organization” corresponds to, for example, a company or a corporation. A terminal100that belongs to the organization A is accommodated in an edge server200. The edge server200is managed and operated by an organization D that is a different organization than the organization A. The organization D that manages and operates the edge server200corresponds to, for example, a telecom carrier (a mobile network operator when the network is a mobile network). The terminal100can access the business application300through the edge server200.

The edge server200can accommodate a plurality of applications. In the example illustrated inFIG. 1, the edge server200accommodates an application #1 that is managed by the organization A and applications #2 and #3 that are managed by an organization B. The edge server200includes a route indication processor201and a route controller202. The route indication processor201accepts route indication information that indicates a route of a traffic flow. The route controller202controls a route of a traffic flow according to the route indication information accepted by the route indication processor201.

For example, it is recommended that the access from the terminal100to the business application300satisfy the following policies.

(1) Preprocess is performed by the application #1.

(2) Security process is performed by the application #2 before the execution of the application #1.

(3) Filtering process is performed by the application #3 before the execution of the application #2.

In this case, the traffic flow headed for the business application300from the terminal100is controlled to pass through the application #3, the application #2, and the application #1 in this order.

Related technologies are disclosed in, for example, Japanese Laid-open Patent Publication No. 2004-157713 and Japanese Laid-open Patent Publication No. 2017-41846.

In the network described above, the route of a traffic flow in the edge server200is indicated by, for example, the terminal100. However, the terminal100may be unaware of an application of an organization that is other than the organization to which the terminal100belongs. In the example illustrated inFIG. 1, the terminal100may be unaware of the applications #2 and #3 of the organization B. In this case, it is difficult for the terminal100to generate a traffic flow that passes through the applications #2 and #3.

This problem may be solved if the policies (2) and (3) described above are reported to the terminal100in advance. However, in this case, a terminal determines whether to implement security measures. That is, a user of the terminal100may omit the security measures. Thus, this is not a preferable operation scheme.

Further, a system administrator of the organization A may not know the configuration of an application in the organization B. For example, it is assumed that an agreement for the use of security software (the application #2 in this case) of the organization B has been concluded between the organization A and the organization B. However, the system administrator of the organization A does not know that there is a need to arrange filtering software (the application #3 in this case) on the input side of the security software. In this case, it is difficult for the system administrator of the organization A to establish the route illustrated inFIG. 1.

In addition, in the example illustrated inFIG. 1, the destination of the traffic flow is the business application300. In other words, the application #1 is not the destination of the traffic flow. In this case, the application #1 does not have a right to indicate a route of the traffic flow.

As described above, in conventional technologies, it may be difficult to establish a route of a traffic flow in an edge server. In other words, in conventional technologies, it may be difficult to establish a traffic flow that passes through a desired application in an edge server.

SUMMARY

According to an aspect of the present invention, a route control device controls a route of a traffic flow in a server device that accommodates a plurality of entities. The route control device includes: a generator configured to generate first control information that indicates a right to indicate a route of the traffic flow in a first range of the server device; a processor configured to receive first route indication information that indicates a route of the traffic flow and the first control information from a first entity in the plurality of entities and to decide whether the first route indication information indicates a route in the first range; and a route controller configured to control a route of the traffic flow based on the first route indication information when the first route indication information indicates a route in the first range.

DESCRIPTION OF EMBODIMENTS

FIG. 2illustrates an example of a network that includes an edge server according to embodiments of the present invention. In the example illustrated inFIG. 2, a business application30of an organization A is arranged on a cloud. The “organization” corresponds to, for example, a company or a corporation. The business application30is implemented in a server computer (a target server). A terminal10that belongs to the organization A can be connected to an edge server. In the example illustrated inFIG. 2, the terminal10is connected to an edge server40. The edge server40is managed and operated by an organization D that is a different organization than the organization A. The organization D that manages and operates the edge server40corresponds to, for example, a telecom carrier (a mobile network operator when the network is a mobile network). The terminal10accesses the business application30through the edge server40. In the following description, a link that transmits a signal from the terminal10to the cloud may be referred to as an “uplink”. A link that transmits a signal from the cloud to the terminal10may be referred to as a “downlink”.

A terminal manager20manages a terminal that belongs to the organization A. In other words, the terminal manager20manages a plurality of terminals including the terminal10. For example, the terminal manager20knows which business application each terminal accesses. InFIG. 2, the terminal manager20knows that the terminal10uses the business application30. Further, the terminal manager20includes a token request unit21. The token request unit21can make a request to an edge server manager50for a token described later.

The edge server40can accommodate a plurality of applications. In the example illustrated inFIG. 2, the edge server40accommodates an application #1 that is managed by the organization A, applications #2 and #3 that are managed by an organization B, and applications #4 and #5 that are managed by an organization C. The application #1 performs preprocess for the business application30. The application #2 performs security process. The security process provides, for example, a firewall function. The application #3 performs filtering process. The application #4 performs log process. The log process records a traffic flow that passes through an edge server. The application #5 performs capturing process. The capturing processing stores packets in the traffic flow that passes through the edge server.

The edge server40includes a route indication processor41and a route controller42. The route indication processor41accepts route indication information that indicates a route of a traffic flow in the edge server40. Here, the route indication processor41decides whether a route indicated by the route indication information is to be approved. The route controller42controls the route of the traffic flow according to the route indication information accepted by the route indication processor41.

The edge server manager50manages the edge server40. Thus, as in the case of the edge server40, the edge server manager50is operated by the organization D. Further, the edge server manager50includes a token generator51. The token generator51generates a token according to a request from the terminal manager20or the edge server40. The edge server40and the edge server manager50may be implemented by a single computer or a plurality of computers. The edge server manager50may manage a plurality of edge servers40.

It is assumed that, in a computing environment having the configuration described above, the organization A has the following policies (A1 and A2) to access the business application30. It is assumed that an agreement for the use of the application #2 has been concluded between the organization A and the organization B. In other words, the application #2 is reliable software for the organization A.

(A1) Preprocess is performed by the application #1.

(A2) Security process is performed by the application #2 of the organization B before the execution of the application #1. Thus, in order to satisfy the policy A2, the application #1 has a function that generates route indication information indicating that a traffic flow that passes through the application #1 passes through the application #2 before the application #1.

It is assumed that the organization B has the following policies (B1 and B2) to execute the application #2. It is assumed that an agreement for the use of the application #4 has been concluded between the organization B and the organization C. In other words, the application #4 is reliable software for the organization B.

(B1) Filtering process is performed by the application #3 before the execution of the application #2.

(B2) Log process is performed by the application #4 of the organization C before the execution of the application #3. Thus, in order to satisfy the policies B1 and B2, the application #2 has a function that generates route indication information indicating that a traffic flow that passes through the application #2 passes through the applications #3 and #4 before the application #2.

It is assumed that the organization C has the following policy (C1) to execute the application #4.

(C1) Capturing process is performed by the application #5 before the execution of the application #4.

Thus, in order to satisfy the policy C1, the application #4 has a function that generates route indication information indicating that a traffic flow that passes through the application #4 passes through the application #5 before the application #4.

In the computing environment having the configuration described above, the edge server40controls a route of a traffic flow of a terminal accommodated in the edge server40. In the example illustrated inFIG. 2, the edge server40makes an uplink traffic flow and a downlink traffic flow of the terminal10pass through one or more specified applications.

At this point, there is a need for the edge server40to identify a traffic flow between the terminal10and the business application30from among a plurality of traffic flows. Here, the traffic flow is identified by, for example, an IP address and an L4 port number. However, for example, when the business application30is provided as SaaS (software as a service), a plurality of terminals use the same destination IP address and the same destination L4 port number, so it is difficult to identify a traffic flow by a destination IP address and a destination L4 port number. Further, a source IP address may be dynamically assigned to the terminal10when the terminal10is connected to a network. A source L4 port number may be dynamically selected from unused port numbers when a traffic flow is generated. Thus, it is difficult to identify a traffic flow by a source IP address and a source L4 port number.

If identification information that is fixedly assigned to the terminal10is used, the edge server40may be able to identify a traffic flow of the terminal10. However, in a BYOD (bring your own device) environment, the traffic flows of the terminal10includes not only a traffic flow that accesses the business application30but also a private traffic flow. Thus, in this case, it is difficult to identify a traffic flow that accesses the business application30from the terminal10.

Thus, in a route control method according to the embodiments of the present invention, a “token” is used to identify a traffic flow. The token is generated to indicate a route in the edge server40for a specified traffic flow. This token is added to a packet transmitted from the terminal10when the terminal10accesses the business application30. When the edge server40receives a packet to which a token is added, the edge server40processes the packet such that a traffic flow follows a route indicated by the token. Thus, the edge server40can control the route of a traffic flow between the terminal10and the business application30such that the traffic flow passes through a desired application.

FIGS. 3 and 4illustrate an example of a procedure for indicating a route of a traffic flow.FIGS. 5 and 6are sequence diagrams corresponding to the procedure illustrated inFIGS. 3 and 4.

In S1, the token request unit21implemented in the terminal manager20makes a request to the token generator51implemented in the edge server manager50for a token. In this example, the token request unit21requests a token that represents a right to indicate a route of a traffic flow transmitted or received by a terminal application on a BYOD environment in the terminal10. Thus, a token request that is made by the token request unit21includes the following information.

(2) Identification of a flow: By a token

As described above, in a BYOD environment, it is difficult to identify a traffic flow related to the business application30by an element (such as an address and a port number) stored in a header of a packet before the traffic flow is established. Thus, a method that uses a token is selected as “Identification of a flow”. However, when it is possible to identify a traffic flow related to the business application30by an element stored in header of a packet before the traffic flow is established, that element may be reported to the token generator51to identify the flow.

In S2, the token generator51generates (or issues) a token requested by the token request unit21. As illustrated inFIG. 7, the token generated by the token generator51includes a token ID, a source organization ID, a source entity ID, a destination organization ID, a destination entity ID, a target edge server ID, target flow information, target flow section information, an issue time, a valid period, and an electronic signature. The “entity” is not limited to hardware or software, but represents an element to perform computer processing. In this example, each of the token request unit21, the route indication processor41, the route controller42, and the token generator51is one entity. Further, each application is one entity.

The token ID identifies each token. The token ID is realized by, for example, a serial number.

The source organization ID identifies an organization that generates a token. In this example, the edge server manager50that includes the token generator51is managed by the organization D. Thus, the source organization ID represents the organization D. Further, the source entity ID identifies an entity that generates a token. In this example, the source entity ID represents the edge server manager50.

The destination organization ID identifies an organization for which a token is to be generated. The destination entity ID identifies an entity that requested a token. For example, in S2, the token is requested by the terminal manager20. Thus, the destination organization ID represents the organization A, and the destination entity ID represents the terminal manager20.

The target edge server ID identifies an edge server in which a token is valid. When the token is valid in a plurality of edge servers, a range in which the token is valid is indicated. In this case, the plurality of edge servers may be represented, for example, using a wild card.

The target flow information indicates a traffic flow for which a right of a token is valid. In this example, the target flow information includes a terminal ID, five tuples, and a token ID. The terminal ID represents a terminal that transmits or receives a target traffic flow. The five tuples represent a source IP address, a destination IP address, a source L4 port number, a destination L4 port number, and a protocol number that are stored in an IP header. Each of the elements in the five tuples may be represented using a wild card. The token ID identifies a token.

The target flow section information indicates a section in which a route indication is approved for a target traffic flow. The issue time represents a time at which a token was generated. The valid period represents a valid period for a token. The electronic signature is generated by encoding a hash value with a private key of the edge server manager50, the hash value being calculated using values of the fields from the “token ID” to the “valid period”.

Main elements of a token generated in S2are described below. In the following description, a token identified by “#1” may be referred to as a “token #1”.

Note that “Target flow information: Token #1” indicates a state in which a right of a token is valid for a traffic flow that is identified by the token #1. “***” indicates a state in which a section in which a route indication is approved is not indicated. In this case, a route indication is approved for a target traffic flow in all of the sections of the edge server40.

In S3, the token generator51transmits, to the route indication processor41, token information that indicates the token #1 generated in S2. The token information indicates values of the fields from the “token ID” to the “valid period” illustrated inFIG. 7.

In S4, the token request unit21transmits the token #1 generated by the token generator51to the terminal10. In the terminal10, the token #1 is received by a BYOD processor and stored in a memory (not illustrated).

In S5, according to the above described policy A1 of the organization A, the token request unit21transmits the token #1 to an entity that is needed to access the business application30. In other words, the token request unit21transmits the token #1 generated by the token generator51to the application #1.

In S6, the application #1 generates route indication information according to the above described policy A2 of the organization A. In other words, route indication information for achieving “Policy A2: Security process is performed by the application #2 of the organization B before the execution of the application #1” is generated. Specifically, route indication information that indicates a route R #1 illustrated inFIG. 3is generated. Then, the application #1 transmits the generated route indication information to the route indication processor41. Here, the application #1 transmits the token #1 to the route indication processor41together with the route indication information.

The following is an example of the route indication information transmitted in S6from the application #1 to the route indication processor41.

In this example, the route indication information indicates a route over an uplink. However, in general, a traffic flow is configured by an uplink flow and a downlink flow. When a route over a downlink is indicated, route indication information is “App #1→App #2”.

The route indication processor41decides whether a route indicated by route indication information is to be approved by the token #1. Specifically, the route indication processor41decides whether the route is indicated in a range approved by the “target flow section” in the token #1. In this example, the token #1 approves a route indication for a target traffic flow in all of the sections of the edge server40. Thus, the route indication processor41accepts the route indication information received from the application #1. As described above, a token is an example of control information that indicates a right to indicate a route of a traffic flow in a specified range of the edge server40.

FIG. 8Aillustrates an example of a route indication information management table. The route indication information management table is generated by the route indication processor41. When the route indication processor41accepts new route indication information, the route indication processor41adds a corresponding record to the route indication information management table.

A “token ID” identifies a token received together with route indication information. A “target flow” represents a traffic flow whose route is to be indicated, and is extracted from the token received together with the route indication information. A “route” represents a route indicated by the received route indication information. Thus, the following record is generated in S6.

(2) Target flow: Traffic flow identified by the token #1

The route indication processor41may compare the content of the token received from the application #1 in S6with the token information received from the token generator51in S3. This permits the route indication processor41to confirm whether the token #1 received from the application #1 is an authorized token. In other words, the route indication processor41can exclude an unauthorized route indication. Further, using an electronic signature of the received token, the route indication processor41can confirm that the token has been falsified. Thus, when it is sufficient to perform a confirmation using an electronic signature, there is no need to transmit token information from the token generator51to the route indication processor41. In this case, an amount of message transmission in the edge server40is reduced.

According to S1-S6, a route indication that satisfies the policies A1 and A2 of the organization A can be realized. In other words, a route that passes through the applications #2 and #1 in this order is indicated.

However, the application #2 is managed by the organization B. In addition, the application #1 does not know the policies of the organization B. Thus, the application #1 makes a request for the organization B to indicate a route. Here, there is a need for the application #1 to make a request for the organization B to indicate a route in a range that satisfies the policies of the organization A. Thus, the application #1 makes a request to the token generator51for a token that represents a right to indicate a route in a range that satisfies the policies of the organization A.

In S7, the application #1 makes a request to the token generator51for a new token. Here, the application #1 transmits the token #1 to the token generator51together with the token request. The token request transmitted in S7from the application #1 to the token generator51includes the following information.

“***→App #2→App #1” indicates a right to indicate a route on the input side of the application #2.

In S8, the token generator51decides whether to generate the token requested by the application #1. Specifically, the token generator51decides whether the requested route indication range is a portion of the route indication range approved for the token #1. In this example, the requested route indication range is the “input side of the application #2”, and the route indication range approved for the token #1 is “all of the sections”. Thus, the token generator51generates a new token in response to the request from the application #1.

Main elements of a token generated in S8are described below. In the following description, a token identified by “#2” may be referred to as a “token #2”.

The token #2 indicates a right to indicate a route on the input side of the application #2 for a traffic flow identified by the token #1. The token generator51transmits the generated token #2 to the application #1.

In S9, the token generator51transmits token information indicating the token #2 generated in S8to the route indication processor41.

In S10, the application #1 transmits the token #2 to the application #2. In other words, the application #1 gives, to the application #2, a right to indicate a route in a range defined by the token #2. Specifically, the right to indicate a route on the input side of the application #2 is given to the application #2 by the application #1.

In S11, the application #2 generates route indication information according to the above described policies B1 and B2 of the organization B. In other words, route indication information for achieving “Policy B1: Filtering process is performed by the application #3 before the execution of the application #2” and “Policy B2: Log process is performed by the application #4 of the organization C before the execution of the application #3” is generated. Specifically, route indication information that indicates a route R #2 illustrated inFIG. 4is generated. Then, the application #2 transmits the generated route indication information to the route indication processor41. Here, the application #2 transmits the token #2 to the route indication processor41together with the route indication information.

The following is an example of the route indication information transmitted in S11from the application #2 to the route indication processor41.

The route indication processor41decides whether to approve the route indication information received from the application #2. Specifically, the route indication processor41decides whether the route is indicated in a range approved by the “target flow section” of the token #2. In this example, the token #2 approves a route indication for a target traffic flow on the input side of the application #2. Thus, the route indication processor41accepts the route indication information received from the application #2.

When the route indication processor41accepts new route indication information, the route indication processor41adds a corresponding record to the route indication information management table. The following record is generated in S11, as illustrated inFIG. 8A.

(2) Target flow: Traffic flow identified by token #1

According to S7-S11, a route indication satisfies the policies B1 and B2 of the organization B can be realized. In other words, a route that passes through the applications #4 and #3 in this order before the execution of the application #2 is indicated.

However, the application #4 is managed by the organization C. In addition, the application #2 does not know the policy of the organization C. Thus, the application #2 makes a request for the organization C to indicate a route. Here, there is a need for the application #2 to make a request for the organization C to indicate a route in a range that satisfies the policies of the organization B. Thus, the application #2 makes a request to the token generator51for a token that represents a right to indicate a route in a range that satisfies the policies of the organization B.

In S12, the application #2 makes a request to the token generator51for a new token. Here, the application #2 transmits the token #2 to the token generator51together with the token request. The token request transmitted in S12from the application #2 to the token generator51includes the following information.

“***→App #4→App #3→App #2→App #1” indicates a right to indicate a route on the input side of the application #4.

In S13, the token generator51decides whether to generate the token requested by the application #2. Specifically, the token generator51decides whether the requested route indication range is a portion of the route indication range approved for the token #2. In this example, the requested route indication range is the “input side of the application #4”, and the route indication range approved for the token #2 is the “input side of the application #2”. Thus, the token generator51generates a new token in response to the request from the application #2.

Main elements of a token generated in S13are described below. In the following description, a token identified by “#3” may be referred to as a “token #3”.

The token #3 indicates a right to indicate a route on the input side of the application #4 for a traffic flow identified by the token #1. The token generator51transmits the generated token #3 to the application #2.

In S14, the token generator51transmits token information indicating the token #3 generated in S13to the route indication processor41.

In S15, the application #2 transmits the token #3 to the application #4. In other words, the application #2 gives, to the application #4, a right to indicate a route in a range defined by the token #3. Specifically, the right to indicate a route on the input side of the application #4 is given to the application #4 by the application #2.

In S16, the application #4 generates route indication information according to the above described policy C1 of the organization C. In other words, route indication information for achieving “Policy C1: Capturing process is performed by the application #5 before the execution of the application #4” is generated. Then, the application #4 transmits the generated route indication information to the route indication processor41. Here, the application #4 transmits the token #3 to the route indication processor41together with the route indication information.

The following is an example of the route indication information transmitted in S16from the application #4 to the route indication processor41.

The route indication processor41decides whether to approve the route indication information received from the application #4. Specifically, the route indication processor41decides whether the route is indicated in a range approved by the “target flow section” of the token #3. In this example, the token #3 approves a route indication for a target traffic flow on the input side of the application #4. Thus, the route indication processor41accepts the route indication information received from the application #4.

When the route indication processor41accepts new route indication information, the route indication processor41adds a corresponding record to the route indication information management table. The following record is generated in S16, as illustrated inFIG. 8A.

(2) Target flow: Traffic flow identified by token #1

According to S12-S16, a route indication that satisfies the policy C1 of the organization C can be realized. In other words, a route that passes through the application #5 before the execution of the application #4 is indicated.

In S17, the route indication processor41determines a route of a traffic flow according to the received route indication information. In this example, the route indication processor41accepts the route indication information in S6, S11, and S16. Further, information needed to indicate a route is recorded in the route indication information management table illustrated inFIG. 8A. Thus, according to the route identification information management table, the route indication processor41determines a route of a traffic flow identified by the token #1.

In this example, the route “App #5→App #4→App #3→App #2→App #1” accepted in S16includes the route “App #2→App #1” accepted in S6and the route “App #4→App #3→App #2→App #1” accepted in S11. In this case, the route indication processor41reports the route information indicating the route accepted in S16to the route controller42. Here, the route indication processor41transmits a token that identifies a target traffic flow to the route controller42together with the route information. In other words, the route information indicating the route accepted in S16and the token #1 are given to the route controller42by the route indication processor41. The route indication processor41may report, to the route controller42, all of the tokens (that is, the tokens #1-#3) related to the route indication.

The route controller42stores the route information given by the route indication processor41in a route information table. As illustrated inFIG. 9, the route information table stores therein a “route” in association with a token that identifies a target traffic flow. In this example, “App #5→App #4→App #3→App #2→App #1” is registered for the token #1. Further, “App #8→App #7→App #6” is registered for the token #5. As described above, applications stored in the edge server40are grouped by being associated with a token.

The route controller42establishes a route of a target traffic flow according to route information given by the route indication processor41. In this example, the following route is established in an uplink headed for the cloud from the terminal10with respect to a traffic flow identified by the token #1.

(1) Guide a traffic flow transmitted from the terminal10to the application #5

(2) Guide the traffic flow processed by the application #5 to the application #4

(3) Guide the traffic flow processed by the application #4 to the application #3

(4) Guide the traffic flow processed by the application #3 to the application #2

(5) Guide the traffic flow processed by the application #2 to the application #1

(6) Guide the traffic flow processed by the application #1 to the business application30

As described above, the edge server40routes a packet to which a token has been added, such that the packet passes through one or more applications that are grouped for the token. In the example illustrated inFIG. 9, a packet to which the token #1 has been added is controlled to pass through the applications #5, #4, #3, #2, and #1 in this order. A packet to which the token #5 has been added is controlled to pass through the applications #8, #7, and #6 in this order.

A route reverse to the route for an uplink is established for a downlink headed for the terminal10from the business application30. In other words, the route controller42establishes a route in a downlink such that a traffic flow identified by the token #1 passes through the applications #1, #2, #3, #4, and #5 in this order.

FIG. 10illustrates an example of a method for processing a traffic flow according to a token.FIG. 11is a sequence diagram that corresponds to the method illustrated inFIG. 10. A traffic flow in an uplink headed for the business application30from the terminal10is described below.

In S18, the terminal10generates a traffic flow that accesses the business application30that is arranged on the cloud. This traffic flow is generated by, for example, a terminal application (T_APP) implemented in the terminal10. The destination address of each packet transmitted through the traffic flow represents the business application30.

In S19, the terminal10adds a corresponding token to the traffic flow headed for the business application30. Specifically, the terminal10adds the token #1 received from the terminal manager20in S4to the traffic flow headed for the business application30. Here, the token #1 is written into a specified area in a header of each packet transmitted through this traffic flow. A token is added to a traffic flow by, for example, a BYOD application.

In S20, the route controller42in the edge server40checks the token added to the traffic flow. When the token #1 is added to the traffic flow transmitted from the terminal10, the route controller42processes the traffic flow according to the route established in S17. In other words, the route controller42guides the traffic flow to the applications #5, #4, #3, #2, and #1 in this order. Specifically, capturing process, log process, filtering process, and security process are performed on this traffic flow in this order before preprocess is performed by the application #1. After the preprocess is performed by the application #1, the edge server40transmits this traffic flow to the business application30.

FIG. 12is a flowchart that illustrates an example of a process performed by the token generator51. The token generator51is always on standby for a token request.

In S101, the token generator51receives a token request. In S102, the token generator51decides whether a previously generated token has been received along with the token request.

When the previously generated token has not been received, the token generator51decides, In S103, whether an agreement for the content of the token request has been already concluded. When the agreement for the content of the token request has been already concluded, the token generator51generates a requested token in S104. Here, the token generator51may report token information indicating the content of the generated token to the route indication processor41. After that, the token generator51is on standby for a next token request in S107. When the content of the token request has not been concluded, the token generator51outputs an error message in S108.

When the previously generated token has been received along with the token request (S102: Yes), the token generator51decides, in S105, whether to approve the received token request. Specifically, the token generator51decides whether the range of a right of the newly requested token is in the range of a right of the previously generated token.

When a new token has been requested within the range of the right of the previously generated token, the token generator51generates the requested token in S106. Here, the token generator51may report, to the route indication processor41, token information indicating the content of the token to be newly generated. After that, the token generator51is on standby for a next token request in S107. When the range of the newly requested right is beyond the range of the right of the previously generated token, the token generator51outputs an error message in S108.

For example, it is assumed that an agreement that the organization A has a right to indicate a route of a traffic flow between the terminal10and the business application30has been concluded between the organization A and the organization D. In this case, in the example illustrated inFIG. 3, when the token generator51receives a token request from the terminal manager20, the token generator51generates a token in S104. In the example illustrated inFIG. 4, the range of a right requested by a token request received from the application #1 is in the range of a right of the token #1. Thus, when the token generator51receives a token request from the application #1, the token generator51generates a token in S106.

FIG. 13is a flowchart that illustrates an example of a process performed by the route indication processor41. For example, the route indication processor41starts performing the process when the route indication processor41receives token information from the token generator51. Alternatively, the route indication processor41may start performing the process when the route indication processor41receives route indication information.

In S111, the route indication processor41receives route indication information and a token. In S112, the route indication processor41checks whether the received token has been falsified. Here, the route indication processor41checks whether there is a falsification using an electronic signature as illustrated inFIG. 7or token information received from the token generator51.

In S113, the route indication processor41decides whether a route has been indicated in a range of a right that is indicated by the received token (that is, in a target flow section). When the route has been indicated within the target flow section indicated by the received token, the route indication processor41registers, in S114, a route indicated by the route indication information in the route indication information management table. When the route has been indicated beyond the target flow section indicated by the received token, the route indication processor41outputs an error message in S118.

In S115and S116, the route indication processor41is on standby for new route indication information. When new route indication information has been received, the process of the route indication processor41returns to S112. When a specified waiting time period has elapsed without new route indication information being received, the route indication processor41determines a route in the edge server40according to the route indication information management table. For example, a route that covers all of the other routes is selected when a plurality of routes for the target token are registered in the route indication information management table. Then, in S117, the route indication processor41reports route information indicating a determined route to the route controller42.

FIG. 14Ais a flowchart that illustrates an example of a process performed by the route controller42when a traffic flow is started. Here, it is assumed that the terminal10starts accessing the business application30.

In S121, the route controller42receives a traffic flow transmitted from the terminal10. In S122, the route controller42detects a token added to the traffic flow. In this example, it is assumed that the “token #1” is inserted into a header of each packet.

In S123, the route controller42processes the target traffic flow such that the target traffic flow follows a route corresponding to the token detected from the target traffic flow. For example, it is assumed that the route information table illustrated inFIG. 9is generated according to the procedures illustrated inFIGS. 3 and 4. In this case, the route “App #5→App #4→App #3→App #2→App #1” is registered for the token #1. Thus, the route controller42guides the target traffic flow to the applications #5, #4, #3, #2, and #1 in this order.

In S124, header information on a packet in the target traffic flow is obtained and recorded in association with the detected token in the route information table. The header information includes at least one of a source IP address, a source port number, a destination IP address, and a destination port number.

FIG. 14Bis a flowchart that illustrates an example of a process performed by the route controller42after the traffic flow is established. It is assumed that header information is recorded in association with a token of a target traffic flow in the route information table, according to the procedure illustrated inFIG. 14A. In S131, the route controller42receives a traffic flow. Here, the route controller42obtains header information from a packet in the traffic flow. In S132, the route controller42refers to the route information table, and processes the target traffic flow such that the target traffic flow follows a route corresponding to the header information obtained from the target traffic flow. The route controller42may control the traffic flow according to the procedure illustrated inFIG. 14Bwithout performing the process illustrated inFIG. 14A.

FIG. 15illustrates an example of a configuration of the terminal10. The terminal10includes a CPU101, a memory102, and a network interface103. The CPU101, the memory102, and the network interface103are connected to a bus104.

The network interface103is implemented by, for example, an LTE interface or a wireless LAN interface. Further, the network interface103can communicate with the terminal manager20and the edge server40via a relay device such as a router. The memory102can store therein a program. In this example, a BYOD application program and a terminal application program are stored in the memory102. The BYOD application program provides an environment in which a terminal application can operate. The CPU101executes a program stored in the memory102. The process of adding a token to a traffic flow is performed by, for example, the CPU101executing the BYOD application program.

FIG. 16illustrates an example of a configuration of the terminal manager20. The terminal manager20includes a CPU201, a memory202, and a network interface203. The CPU201, the memory202, and the network interface203are connected to a bus204.

The network interface203can communicate with the terminal10, the edge server40, and the edge server manager50via a relay device such as a router. The memory202can store therein a program. In this example, a program that describes the process performed by the token request unit21is stored in the memory202. The CPU201executes a program stored in the memory202. The function of the token request unit21is provided by the CPU201executing the program stored in the memory202.

FIG. 17illustrates an example of a configuration of the edge server40. The edge server40includes a CPU401, a memory402, and a network interface403. The CPU401, the memory402, and the network interface403are connected to a bus404. The edge server40may include a plurality of network interfaces403.

The network interface403is implemented by, for example, Ethernet (registered trademark) or a wireless LAN interface. The network interface403can communicate with the terminal10, the terminal manager20, the edge server manager50, and a communication device (such as a computer in which the business application30is implemented) on a cloud via a relay device such as a router or a base station.

The memory402can store therein a program. In this example, a program that describes the process performed by the route indication processor41and a program that describes the process performed by the route controller42are stored in the memory402. A virtual machine can be configured using the memory402. Each virtual machine provides an environment in which one application or a plurality of applications can operate. The CPU401executes a program stored in the memory402. The functions of the route indication processor41and the route controller42are provided by the CPU401executing programs stored in the memory402. For example, the CPU401provides the function of the route indication processor41by executing the program that describes the process of the flowchart illustrated inFIG. 13.

FIG. 18illustrates an example of a configuration of the edge server manager50. The edge server manager50includes a CPU501, a memory502, and a network interface503. The CPU501, the memory502, and the network interface503are connected to a bus504.

The network interface503can communicate with the terminal manager20and the edge server40via a relay device such as a router. The memory502can store therein a program. In this example, a program that describes the process performed by the token generator51is stored in the memory502. The CPU501executes a program stored in the memory502. The function of the token generator51is provided by the CPU501executing a program stored in the memory502. For example, the CPU501provides the function of the token generator51by executing the program that describes the process of the flowchart illustrated inFIG. 12.

Variation

In S7illustrated inFIG. 4, the target flow section included in a token request may be the “input side of the application #2 (***→App #2)”. In this case, the range of a right of the token #2 generated in S8is the “input side of the application #2 (***→App #2)”.

Likewise, in S12, the target flow section included in a token request may be the “input side of the application #4 (***→ App #4)”. In this case, the range of a right of the token #3 generated in S13is the “input side of the application #4 (***→App #4)”.

Only a route in a range of a right of a given token may be described in route indication information. For example, only the route “App #4→App #3→App #2” on the input side of the application #2 is described in the route indication information of S11, and only the route “App #5→App #4” on the input side of the application #4 is described in the route indication information of S16.

In this case, as illustrated inFIG. 8B, the route indication processor41receives the following route indication information.

Thus, the route indication processor41combines these routes so as to determine “App #5→App #4→App #3→App #2→App #1” to be a route of a traffic flow corresponding to the token #1.

Other Embodiments

In the example illustrated inFIG. 2, the edge server manager50is provided independently of the edge server40, and the edge server40is in corporation with the edge server manager50so as to operate as a route controller that controls a route of a traffic flow. However, the present invention is not limited to this configuration. For example, as illustrated inFIG. 19A, the function of the edge server manager50(that is, the token generator51) may be implemented in the edge server40. In this case, the edge server40including the token generator51operates as a route controller that controls a route of a traffic flow.

Further, in the example illustrated inFIG. 2, one edge server manager50is provided for one edge server40, but the present invention is not limited to this configuration. For example, as illustrated inFIG. 19B, one edge server manager50may be provided for a plurality of edge servers40. In this case, each edge server40a-40nis in corporation with the edge server manager50so as to operate as a route controller that controls a route of a traffic flow.

In the example illustrated inFIGS. 3 and 4, the route of a traffic flow is indicated by a plurality of entities, but the present invention is not limited to this configuration. For example, one entity may indicate all of the routes in the edge server40. In this case, a token that indicates a right to indicate routes in all of the sections of the edge server40is generated.

In the examples described above, taking into consideration the case in which it is difficult to identify each traffic flow from a packet header before the traffic flow is established, the terminal10adds a token to the first traffic flow when it is started. Then, the edge server40controls the route of the traffic flow based on the token. However, when it is possible to identify a specified traffic flow from a packet header before a traffic flow is established, the edge server40may control the route of the traffic flow without using a token.

For example, it is assumed that a traffic flow is identified by a destination IP address and/or a destination L4 port number of a business application to be accessed. In this case, when a request for a new token is made, the edge server40reports, to the token generator51, the destination IP address and/or the destination L4 port number as information that identifies a traffic flow. Then, the destination IP address and/or the destination L4 port number are set in the token. In the example illustrated inFIG. 7, the destination IP address and/or the destination L4 port number are set as target flow information. Then, this token is given to the route controller42together with corresponding route information. The route controller42can control the route of the traffic flow according to the specified destination IP address and/or destination L4 port number. Thus, there is no need for the terminal10to add a token to a traffic flow, and there is no need for the terminal manager20to transmit a token to the terminal10.