Header generation information transmission device and header generation information transmission method

Abstract

In the present invention, a router (10B) has a flow generation unit (14) that transmits, to a header attachment / removal device (20B), downlink header information (10Y) in which the following are associated with each other: flow identification information for a bidirectional flow; information indicating a reception packet passage interface in the bidirectional flow; HA information indicating a hash function used by the router (10B); HF information indicating field information serving as an argument of the hash function; and LB information indicating a candidate interface set for determining, from the hash value obtained from the hash function, the passage interface for a packet to be transmitted.

Description

Header generation information transmitting device and header generation information transmitting method

[0001] The present invention relates to a header generation information transmitting device and a header generation information transmitting method.

[0002] If packets sent from any of the router's multiple interfaces can reach the same device, all flows can be forwarded from one interface, or the load can be distributed across multiple interfaces. When distributing each flow to each link through load distribution, an algorithm is required to decide which interface to assign each flow to.

[0003] To assign a set of packets belonging to the same flow to the same interface, an algorithm is often used that calculates a hash value based on different identification information for each flow and then determines the interface to assign from that hash value. Flow identification information is, for example, a combination of destination IP, source IP, and flow label. Routers determine the interface ID from the flow's hash value using the formula "Interface ID = hash value mod number of interfaces." Note that mod is a modulus function; for example, 10 mod 4 = 2.

[0004] 11 is a configuration diagram of a flow communication system 100z. In the flow communication system 100z, a network is formed that relays between transmitting terminals TC1z to TC3z, such as client terminals that request services, and receiving terminals TS1z to TS3z, such as servers that provide services. Hereinafter, the flow in which an IPv4 packet 71z, such as a request transmitted by a transmitting terminal TC2z, reaches the receiving terminal TS2z is referred to as upstream traffic 70z. The flow in which an IPv4 packet 81z, such as a response transmitted by a receiving terminal TS2z, reaches the transmitting terminal TC2z is referred to as downstream traffic 80z.

[0005] In the upstream traffic 70z, an IPv4 packet 71z flows along a route 70Pz passing through the transmitting terminal TC2z → header attachment / detachment device 20Az → router 10Az → analysis device 31z → router 10Bz → header attachment / detachment device 20Bz → receiving terminal TS2z in this order. The header attachment / detachment device 20Az adds (encapsulates) an IPv6 header 72z to the received IPv4 packet 71z. The header attachment / detachment device 20Bz removes the IPv6 header 72z from the received IPv6 packet, restoring it to an IPv4 packet 71z. In other words, the flow is transferred by IPv6 tunneling in the section "header attachment / detachment device 20Az → router 10Az → analysis device 31z → router 10Bz → header attachment / detachment device 20Bz."

[0006] In the downstream traffic 80z, an IPv4 packet 81z flows along a route 80Pz passing through the receiving terminal TS2z → header attachment / detachment unit 20Bz → router 10Bz → analysis device 32z → router 10Az → header attachment / detachment unit 20Az → transmitting terminal TC2z in this order. The header attachment / detachment unit 20Bz adds (encapsulates) an IPv6 header 82z to the received IPv4 packet 81z. The header attachment / detachment unit 20Az removes the IPv6 header 82z from the received IPv6 packet, restoring it to the IPv4 packet 81z. In other words, the flow is transferred by IPv6 tunneling in the section "header attachment / detachment unit 20Bz → router 10Bz → analysis device 32z → router 10Az → header attachment / detachment unit 20Az."

[0007] The analysis devices 31z and 32z analyze the flows passing through them and acquire statistical information such as traffic volume. When multiple analysis devices 31z and 32z are installed between the routers 10Az and 10Bz, upstream traffic 70z may pass through the analysis device 31z, while downstream traffic 80z may pass through the analysis device 32z. As a result, the upstream and downstream traffic of the same flow may pass through different analysis devices 31z and 32z, resulting in the analysis results being distributed to different devices. In this case, the analysis devices 31z and 32z cannot distinguish between bidirectional flows (identifying upstream and downstream traffic as a set), and therefore cannot properly control the flow if the same policy is applied to both the upstream and downstream traffic based on the bidirectional flow. Application of a policy includes, for example, assigning a Quality of Service (QoS) DSCP (Differentiated Services Code Point) or queuing traffic in a priority queue.

[0008] The reason why the route 70Pz of the upstream traffic 70z and the route 80Pz of the downstream traffic 80z do not match is that the static HA of the router 10Az that determines the route 70Pz is different from the static HA of the router 10Bz that determines the route 80Pz. Therefore, there is a desire to route the upstream traffic 70z and the downstream traffic 80z through the same analysis device 31z. Therefore, Non-Patent Document 1 describes a setting item for a pair of routers provided by a specific vendor to ensure that bidirectional flows flow through the same link. This setting item involves setting "symmetric-hash" on both routers and "complement" on one router.

[0009] Juniper Networks, "Load Balancing on Aggregated Ethernet Interfaces," [online], [Retrieved October 24, 2023], Internet <URL: https: / / www.juniper.net / documentation / us / en / software / junos / high-availability / topics / topic-map / load-balancing-aggregated-ethernet-interfaces.html>, Junos OS, 3-Mar-23

[0010] As explained in Fig. 11, the following methods can be considered to address the problem of bidirectional flows passing through separate analysis devices 31z and 32z. (Method 1) The bidirectional flows pass through separate analysis devices 31z and 32z, and then the analysis results of the unidirectional flows are exchanged between the analysis devices 31z and 32z, thereby creating the analysis results of the bidirectional flows after the fact. (Method 2) A setting item is described for routing bidirectional flows between routers 10Az and 10Bz through the same link so that the bidirectional flows do not pass through separate analysis devices 31z and 32z (Non-Patent Document 1).

[0011] Regarding (Method 1), traffic (passing packets) or flows must be exchanged between the analysis devices 31z and 32z, and this information exchange requires unnecessary CPU resources and communication bandwidth for the exchange. As a result, the processing performance of the analysis devices decreases. For example, because traffic exchange is required for the number of combinations in which two devices are selected from n different devices, throughput decreases during scale-out. Regarding (Method 2), this method cannot be applied if the models used are different between the routers 10Az and 10Bz (if the hash calculation method is different), or if the same policy cannot be set between the routers 10Az and 10Bz, for example, if different operators are used between the routers 10Az and 10Bz.

[0012] Therefore, the main object of the present invention is to concentrate a bidirectional flow through a specific device even in an environment where the bidirectional flow can be distributed to a plurality of devices for communication.

[0013] In order to solve the above problems, the header generation information transmitting device of the present invention has the following features: The header generation information transmitting device determines a pass-through interface for a packet to be transmitted from a hash value calculated from field information used for a predetermined hash function in the header information of the packet and from information on a set of interfaces heading to the same destination of the packet, and the header generation information transmitting device transmits to a header attaching / detaching device header generation information that associates flow identification information for a bidirectional flow, information indicating a pass-through interface for a received packet of the bidirectional flow, first information indicating a hash function to be used by the header generation information transmitting device, second information indicating field information that serves as an argument for the hash function, and third information indicating a set of candidate interfaces that will determine a pass-through interface for the packet to be transmitted from the hash value calculated from the hash function, thereby comprising a flow generating unit that causes the header attaching / detaching device to calculate the hash function indicated by the first information using the field information indicated by the second information as an argument, and that, when selecting a pass-through interface for the packet to be transmitted from the set of interfaces in the third information based on the hash value calculated from the hash function, causes the header attaching / detaching device to generate a header for the packet to be transmitted so that the pass-through interface is the same as the pass-through interface for the received packet.

[0014] According to the present invention, even in an environment where bidirectional flows can be distributed among a plurality of devices for communication, the bidirectional flows can be concentrated and passed through a specific device.

[0015] FIG. 1 is a configuration diagram of a flow communication system according to the present embodiment. FIG. 2 is a configuration diagram of a router and a header attachment / detachment device according to the present embodiment. FIG. 3 is a hardware configuration diagram of each device constituting the flow communication system according to the present embodiment. FIG. 4 is a packet format diagram showing an example of an HF notification OT and an HF notification DT according to the present embodiment. FIG. 5 is a packet format diagram showing an example of an HA notification OT and an HA notification DT according to the present embodiment. FIG. 6 is an explanatory diagram showing an example of a 4-byte value to be substituted for "hashAlgorithm" in the HA notification DT of FIG. 5 according to the present embodiment. FIG. 7 is a table showing an example of a list of HA numbers selectable as the detailed algorithm information of each algorithm of FIG. 6 according to the present embodiment. FIG. 8 is a packet format diagram showing an example of an LB notification OT and an LB notification DT according to the present embodiment. FIG. 9 is a sequence diagram showing the operation of the flow communication system according to the present embodiment. FIG. 10 is a flowchart showing details of the process by which a router according to the present embodiment obtains downstream header usage information from upstream traffic. FIG.

[0016] Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings.

[0017] 1 is a configuration diagram of a flow communication system 100. In the flow communication system 100, a network is formed that relays between sending terminals TC1 to TC3, such as client terminals that request services, and receiving terminals TS1 to TS3, such as servers that provide services. Hereinafter, the flow in which an IPv4 packet 71, such as a request sent by a sending terminal TC2, reaches the receiving terminal TS2 is referred to as upstream traffic 70. The flow in which an IPv4 packet 81, such as a response sent by the receiving terminal TS2, reaches the sending terminal TC2 is referred to as downstream traffic 80.

[0018] In the upstream traffic 70, an IPv4 packet 71 flows along a route 71P passing through the transmitting terminal TC2 → header attachment / detachment device 20A → router 10A → analysis device 31 → router 10B → header attachment / detachment device 20B → receiving terminal TS2 in this order. The header attachment / detachment device 20A adds (encapsulates) an IPv6 header 72 to the received IPv4 packet 71. The header attachment / detachment device 20B removes the IPv6 header 72 from the received IPv6 packet, restoring it to the IPv4 packet 71. In other words, the flow is transferred over the section "header attachment / detachment device 20A → router 10A → analysis device 31 → router 10B → header attachment / detachment device 20B" using an IPv6 tunnel, as exemplified below: IPv4 over IPv6 technology, such as MAP-E (Mapping of Addresses and Ports with Encapsulation), DS-Lite (Dual-Stack Lite), and LW4o6 (Light Weight 4 over 6).・SRv6 (Segment Routing over IPv6) ・All other XX over IPv6 technologies

[0019] In the downstream traffic 80, an IPv4 packet 81 flows in the opposite direction along the same route 71P as the upstream traffic 70. The header attachment / detachment device 20B adds (encapsulates) an IPv6 header 82 to the received IPv4 packet 81. The header attachment / detachment device 20A removes the IPv6 header 82 from the received IPv6 packet, restoring it to the IPv4 packet 81. In other words, the flow is forwarded via IPv6 tunneling in the section "header attachment / detachment device 20B → router 10B → analysis device 31 → router 10A → header attachment / detachment device 20A." The IPv6 headers 72 and 82 are, for example, headers such as MAP-E and DS-Lite. The analysis devices 31 and 32 analyze the flows passing through their own devices and perform policy control, such as fairness control, bandwidth control, and application identification, based on the analysis results.

[0020] Next, the main differences between the flow communication system 100 of FIG. 1 and the flow communication system 100z of FIG. 11 will be described. In the flow communication system 100 of FIG. 1, both upstream traffic 70 and downstream traffic 80, which are bidirectional flows in which the combinations of SIP (Source IPv6 Address) and DIP (Destination IPv6 Address) are interchangeable, pass through the same route 71P so that they can be analyzed by the same analysis device 31. Furthermore, there are multiple interfaces from router 10B to router 10A (with router 10A as the next hop) for load balancing. Therefore, the interface through which router 10B receives upstream traffic 70 (upstream passing interface) and the interface through which router 10B transmits downstream traffic 80 (downstream passing interface) must be the same interface (the interface connected to the analysis device 31).

[0021] Therefore, the router (header generation information transmitting device) 10B transmits downstream header information (header generation information) 10Y, which associates the flow identification information of the upstream traffic 70 with downstream header calculation information, to the header attachment / detachment device 20B. The flow identification information is information for aggregating flowing traffic by the same attribute, such as a combination of SIP, DIP, and flow label. The downstream header calculation information is information for causing the header attachment / detachment device 20B to calculate downstream header usage information in the IPv6 header 82, details of which will be described later in connection with FIG. 2. The calculated downstream header usage information is then set so that the downstream transit interface calculated by the router 10B from the IPv6 header 82 is the same as the upstream transit interface.

[0022] The downstream header usage information is, for example, a field established by the IPv6 specifications so that it can be assigned arbitrarily among the fields included in the IPv6 header 82, and for example, the flow label (FlowLabel, 20 bits) in the IPv6 header or the interface ID (= excluding the prefix) in SIP is used. Note that an IPv6 address such as SIP is a combination of a network address (generally the upper 64 bits) and an interface ID (generally the lower 64 bits).

[0023] Here, devices such as routers 10A and 10B basically perform routing table lookups for IP packets using the destination address, so changing the SIP does not generally affect forwarding. On the other hand, changing the SIP may affect forwarding in the following cases: - When a filter such as RPF includes an interface ID. - When strict packet checking is performed, such as when the header attachment / detachment device 20A searches all 128 bits as the tunnel destination to confirm a match. Therefore, it is preferable to use a flow label rather than SIP as the information used for downstream header usage.

[0024] The flow identification information is, for example, a combination of SIP and DIP. In a bidirectional flow, SIP in the upstream traffic 70 is replaced with DIP in the downstream traffic 80. The router 10B transmits the downstream header information 10Y to the header attachment / detachment device 20B as an IPFIX (IP Flow Information Export) packet, which is standardized as RFC (Request for Comments) 7011. This IPFIX packet contains basic information, flow identification information, and optional information, downstream header calculation information. Meanwhile, the router 10B may use any protocol other than IPFIX, such as Netflow, as a protocol for notifying the flow identification information. The header attachment / detachment device 20B calculates downstream header usage information for the flow identification information read from the downstream header information 10Y based on the downstream header calculation information read from the downstream header information 10Y. The header attachment / detachment device 20B then receives downstream traffic 80 corresponding to the upstream traffic 70 from the receiving terminal TS2. The header attachment / detachment device 20B identifies downstream header usage information associated with the flow identification information of the upstream traffic 70 (= flow identification information of the downstream traffic 80), and forwards the downstream traffic 80 with an IPv6 header 82 containing the downstream header usage information to the router 10B.

[0025] As a result, the router 10B selects the same downstream pass-through interface as the upstream pass-through interface as a result of a hash calculation based on the IPv6 header 82 of the downstream traffic 80. Therefore, the upstream traffic 70 and the downstream traffic 80 pass through the same route 71P, allowing bidirectional flows to be concentrated and passed through the analysis device 31. The analysis device 31 can then identify the upstream traffic 70 and the downstream traffic 80 as a set of bidirectional flows. As a result, the analysis device 31 can perform analysis processing based on bidirectional flows, such as applying the same policy (assigning a QoS DSCP or queuing in a priority queue).

[0026] 2 is a configuration diagram of a router 10B and a header attachment / detachment device 20B. The router 10B has a user interface 11, a routing processing unit 12, a packet communication unit 13, and a flow generation unit 14. The header attachment / detachment device 20B has a user interface 21, a routing processing unit 22, a packet communication unit 23, a flow processing unit 24, a header calculation unit 25, a flow holding unit 26, and a tunnel header control unit 27.

[0027] The user interfaces 11 and 21 are management plane units that accept commands and APIs from users and external systems. The routing processing units 12 and 22 are control plane units that process routing protocols between devices and manage routes. The packet communication units 13 and 23 are user / data plane units that forward packets, send spontaneous packets, and receive self-addressed packets. The flow generation unit 14 generates packets such as IPFIX that notify downstream header calculation information associated with flow identification information. The flow processing unit 24 performs processing to store packets generated by the flow generation unit 14 in the flow storage unit 26. The flow storage unit 26 is a data storage area that stores information processed by the flow processing unit 24.

[0028] The header calculation unit 25 creates downstream header usage information by calculating a hash function based on the following information notified as option information (downstream header calculation information) of the downstream header information 10Y: HA (Hash Algorithm) information (first information) indicates the algorithm used in the hash function and its initial value (seed). HF (Hash Field) information (second information) indicates a set of parameters in the IPv6 header 72 that serve as arguments input to the hash function, and is also called a hash key. LB (Load Balance) information (third information) indicates a set of interfaces that are candidates for downstream transit interfaces when determining a downstream transit interface from the hash value, which is the calculation result of the hash function. In other words, the LB information uses the router 10A, which is the next hop for downstream traffic 80 to the router 10B, as the next hop ID and indicates a set of interfaces for reaching that next hop ID.

[0029] The basic information (flow identification information) of the downstream header information 10Y sent from the router 10B to the header attachment / detachment device 20B may also include the following information: Information on the upstream transit interface (the interface desired to be used as the downstream transit interface) among the set of interfaces indicated by the LB information Information that distinguishes the downstream header usage information among the HF information from other information.

[0030] The routers 10A and 10B each determine the transit interface for a packet to be transmitted based on a hash value calculated from the HF information used in a predetermined hash function (different functions may be used for the routers 10A and 10B) in the packet's header information and information on a set of interfaces leading to the same destination. The header calculation unit 25 then uses part of the HF information as downstream header usage information so that the downstream transit interface calculated from the hash value and LB information in the IPv6 header 82 is the same as the upstream transit interface. The header calculation unit 25 then inputs the remaining HF information (other than the downstream header usage information), the LB information, and the downstream transit interface (= the upstream transit interface), and reverse-calculates the downstream header usage information to find a hash value that satisfies the relationship between the input data.

[0031] The tunnel header control unit 27 decapsulates the IPv6 header 72 when receiving upstream traffic 70, and generates and encapsulates an IPv6 header 82 when sending downstream traffic 80.

[0032] 3 is a hardware configuration diagram of each device constituting the flow communication system 100. Each device (routers 10A and 10B, header attachment / detachment devices 20A and 20B, and analyzers 31 and 32) of the flow communication system 100 is configured as a computer 900 having a CPU 901, RAM 902, ROM 903, HDD 904, communication I / F 905, input / output I / F 906, and media I / F 907. The communication I / F 905 is connected to an external communication device 915. The input / output I / F 906 is connected to an input / output device 916. The media I / F 907 reads and writes data from a recording medium 917. Furthermore, the CPU 901 controls each unit by executing a program (header information transmission program) loaded into the RAM 902. This program (also called an application, or simply "app") can be distributed via a communication line or recorded on a recording medium 917 such as a USB memory and distributed.

[0033] First, when the downstream header information 10Y is an IPFIX packet, the packet format is defined by an Option Template (OT) and a Data Template (DT), which indicate optional information other than the flow identification information. The OT is a template that defines the data structure of each field included in the DT, and it is the DT that is actually used to notify the downstream header information 10Y. Below, the details of the following downstream header calculation information that is included in and notified of the downstream header information 10Y are explained with reference to Figures 4 to 8. In this explanation, the IPFIX set header and template header are omitted. The HF notification DT 202 created according to the HF notification OT 201 shown in Figure 4 is used to notify HF information. The HA notification DT 212 created according to the HA notification OT 211 shown in Figure 5 is used to notify HA information. The LB notification DT 232 created according to the LB notification OT 231 shown in Figure 8 is used to notify LB information. These DTs (HF notification DT 202, HA notification DT 212, and LB notification DT 232) may be transmitted together in one packet, or may be transmitted separately in separate packets.

[0034] FIG. 4 is a packet format diagram showing an example of the HF notification OT201 and the HF notification DT202. The HF notification OT201 consists of five rows of fields. In fields divided into left and right halves, such as the "hashInformationID" in the first row of the HF notification OT201, the left field indicates the type of IE (Information Element) that is the data element (the number in parentheses is the IE ID specified in the standardization specifications), and the right field indicates the length of that IE (in bytes). The "hashInformationID" in the first row of the HF notification OT201 is treated as a scope (validity range), and the same hashInformationID value is assigned to multiple DTs (the HF notification DT202, the HA notification DT212, and the LB notification DT232) that target the same flow identification information. This allows each DT to identify that it targets the same flow identification information. The IE ID "32768" shown in parentheses has the most significant bit set to 1, indicating a custom-defined IE. The IE ID "110" is an arbitrary value within the custom-defined IE, and a value that does not overlap with other custom-defined IEs is used.

[0035] The second line "PEN = 210" in the HF notification OT 201 indicates the PEN (Private Enterprise Number), which is the identifier of the organization that defined the IE, if the IE in the line immediately above is a proprietary IE. For example, PEN = 210 is the number assigned to Nippon Telegraph and Telephone Corporation, the applicant of the present application.

[0036] The HF notification DT 202 is a DT corresponding to the HF notification OT 201, and is composed of four rows of fields. An arbitrary value (for example, "1") corresponding to the "DesignatedFieldID" in the first row of the HF notification OT 201 is assigned to the first row of the HF notification DT 202.

[0037] Below, we will explain the field range information, which indicates which part of which field is used for hash calculation as HF information. The following example shows that for each field, only the lowest 16 bits are valid values ​​used for hash calculation. The second line of the HF notification DT202 is substituted with the field range information of the downstream IPv6 header 82 corresponding to the "source IPv6 address" on the third line of the HF notification OT201 (e.g., "0xffff", which indicates that the lowest 16 bits are used). Note that "0x" indicates that the value that follows is a hexadecimal number. The field range information is expressed as a bit mask, with bits not used in hash calculation set to "0" and bits used in hash calculation set to "1".

[0038] The field range information of the downstream IPv6 header 82 corresponding to "destination IPv6 address" on the fourth line of the HF notification OT 201 is substituted into the third line of the HF notification DT 202. The field range information of the downstream IPv6 header 82 corresponding to "flowLabel IPv6" on the fifth line of the HF notification OT 201 is substituted into the fourth line of the HF notification DT 202. In other words, the argument of the hash function indicated by the HA information is the combined value of (the lowest 16 bits of the source IPv6 address), (the lowest 16 bits of the destination IPv6 address), and (the lowest 16 bits of the flowLabel IPv6).

[0039] The tunnel header control unit 27 of the header attachment / detachment device 20B newly generates an IPv6 header 82 to be added to the received downstream traffic 80. If the flow identification information in the IPv6 header 82 matches the flow identification information in the downstream header information 10Y, the tunnel header control unit 27 overwrites the IPv6 header 82 with downstream header usage information.

[0040] 5 is a packet format diagram showing an example of the HA notification OT211 and the HA notification DT212. Normally, the HA executed by the router 10B is not sent to the outside, but since IPFIX is independently extensible and not all bits in the HF information field are used due to hardware resources, the HA information may be sent to the outside. The third line "hashInitialiserValue" of the HA notification OT211 is the seed (initial value) of the HA indicated in the fourth line "hashAlgorithm". The HA notification DT212 corresponds to the HA notification OT211. The initial value of hashInitialiserValue is arbitrary.

[0041] 6 is an explanatory diagram showing an example of a 4-byte value 220 to be substituted for "hashAlgorithm" in the HA notification DT 212 of FIG. 5. The upper two bytes of the 4-byte value 220 indicate the HA classification value with reference to the flowSelectorAlgorithm shown in table 221. The lower two bytes of the 4-byte value 220 indicate detailed information about each algorithm (FIG. 7) for the HA classification value. For example, if the HA is CRC-16-IBM, the 4-byte value 220 = 0x082a (the upper two bytes are 8 in decimal, and the lower two bytes are 42 in decimal).

[0042] In table 221, the most significant bit of flowSelectorAlgorithm (https: / / www.iana.org / assignments / ipfix / ipfix.xhtml#ipfix-flowselectoralgorithm) corresponds to the item number in the left column of table 221. Decimal item numbers are 0 to 5, with 9 being a missing number, 6 being BOB, 7 being IPSX, and 8 being CRC. When adding an algorithm, use numbers 10 and above. Note that flowselectorAlgorithm exists in the IPFIX (PSAMP) IE, but this IE is used during packet sampling and has a different purpose, so in this example, a new, unique IE is defined.

[0043] Fig. 7 is a table showing an example of a list of HA numbers that can be selected as detailed information for each algorithm in Fig. 6. In each of the tables 222 to 224, HA numbers that can distinguish various derivatives of CRC, such as HA numbers = 1 (CRC-1) to 61 (CRC-64-ISO), are assigned, and any of these HA numbers can be substituted into the lower two bytes of the 4-byte value 220 in Fig. 6. Also, unique HAs may be reassigned to each of the tables 222 to 224 later.

[0044] FIG. 8 is a packet format diagram showing an example of the LB notification OT 231 and the LB notification DT 232. The LB notification OT 231 represents a list of output interfaces (basicList, line 5) that are destinations for a single nextHopId (line 3, custom definition), such as router 10A as seen from router 10B. The LB notification DT 232 corresponds to the LB notification OT 231. The second line (nexthopId) is a next hop ID (arbitrary value) defined by the OS. The array information in lines 5 to 7 indicates the array of output interfaces (egressInterface values) associated with the nexthop ID. Router 10B compares the LB information included in the LB notification DT 232 with the ingressInterface information (information on the upstream transit interface) included in the basic information (flow identification information) of the downstream header information 10Y. This allows the router 10B to calculate the ordinal number B of the ECMP link included in the same nexthop ID.

[0045] 9 is a sequence diagram showing the operation of the flow communication system 100. In S11, the router 10A determines the analysis device 31 as the forwarding destination of the upstream traffic 70 received from the transmitting terminal TC2, and forwards the packets of the upstream traffic 70 to the analysis device 31. In other words, the router 10A determines the forwarding destination from the result of modulo calculation of the hash value obtained from the HF information in the IPv6 header 72 of the received upstream traffic 70 and the number of interfaces (number of links) of the router 10A.

[0046] In S12, when the router 10B receives the upstream traffic 70 transferred to the analysis device 31 in S11, it transmits to the header attachment / detachment device 20B downstream header information 10Y including flow identification information and downstream header calculation information for the received upstream traffic 70. The router 10B may refer to an access list (filter) that indicates, for each flow identification information, whether or not to perform the processing of S13 for the received upstream traffic 70, and omit the processing of S12 and S13 for flows that match the access list.

[0047] In S13, the header attachment / detachment device 20B obtains downstream header usage information for the upstream traffic 70 from the downstream header calculation information received in S12 (see FIG. 10 for details). In S14, the header attachment / detachment device 20B associates the flow identification information of the upstream traffic 70 with the downstream header usage information calculated in S13 and stores them in the flow holding unit 26. This allows the processing of S12 to S14 to be omitted from the second time onwards for the flow identification information stored in the flow holding unit 26.

[0048] That is, the flow generation unit 14 of the router 10B transmits to the header attachment / detachment device 20B downstream header information 10Y that associates flow identification information of the bidirectional flow, information indicating the pass-through interface of the received packet of the bidirectional flow, HA information indicating the hash function used by the router 10B, HF information indicating field information that is an argument of the hash function, and LB information indicating a set of candidate interfaces that determine the pass-through interface of the packet to be transmitted from the hash value obtained from the hash function (S12).The header calculation unit 25 of the header attachment / detachment device 20B then causes the header attachment / detachment device 20B to calculate the hash function indicated by the HA information using the field information indicated by the HF information as an argument, and generates a header for the packet to be transmitted so that when selecting a pass-through interface for the packet to be transmitted from the set of interfaces in the LB information based on the hash value obtained from the hash function, the selected interface will be the same as the pass-through interface of the received packet (S13).

[0049] In S15, the router 10B forwards the upstream traffic 70 received from the analysis device 31 to the header attachment / detachment device 20B. In S16, the header attachment / detachment device 20B forwards the IPv4 packet 71 resulting from removing the IPv6 header 72 from the upstream traffic 70 received in S15 to the receiving terminal TS2. This completes the description of the forwarding process for the upstream traffic 70. Here, the upstream pass-through interface of the router 10B is the interface passed through when the upstream traffic 70 was received in S12.

[0050] In S21, if the flow identification information of the downstream traffic 80 received from the receiving terminal TS2 matches the flow identification information held in the flow holding unit 26, the header attaching / detaching device 20B adds an IPv6 header 82 including corresponding downstream header usage information and forwards the header 82 to the router 10B. The following shows an example of the IPv6 header 82 created by the header attaching / detaching device 20B: SIP=2001:db8:1fff:1::1 (DIP of the IPv6 header 72) DIP-2001:db8:1012:3400:0:c000:0212:0034 (SIP of the IPv6 header 72) Flow label=downstream header usage information calculated in S13 so that the downstream transit interface number of the router 10B is 0 (first link in the NHG, the remainder calculation result for the number of links is 0) (e.g., the value of flowLabelIPv6 whose lowest 16 bits are 0x8416).

[0051] In S22, the router 10B selects the analysis device 31 as the destination based on the remainder calculation result of the hash value calculated from the HF information in the IPv6 header 82 of the downstream traffic 80 received from S21 and the number of interfaces (number of links) of the router 10B, and forwards the packet to the analysis device 31. Here, the upstream pass-through interface and the downstream pass-through interface match based on the downstream header usage information included in the HF information.

[0052] In S23, the router 10A forwards the downstream traffic 80 received from the analysis device 31 to the header attachment / detachment device 20A. As a result, the bidirectional flow passes through the same analysis device 31. In S31, the analysis device 31 performs analysis processing on the upstream traffic 70 and downstream traffic 80 of the bidirectional flow. As described above, the flow communication system 100 executes each process in the sequence diagram of FIG. 9 , causing the header attachment / detachment device 20B to calculate the same HA as that of the router 10B in accordance with the downstream header information 10Y (HA information, HF information, LB information) notified to the header attachment / detachment device 20B by the router 10B. The header attachment / detachment device 20B then calculates downstream header usage information (flow label or SIP) such that the upstream passing interface and the downstream passing interface are the same, assigns the downstream header usage information to the IPv6 header 82, and transmits the IPv4 packet 81 to the router 10B.

[0053] 10 is a flowchart showing the details of the process (S13) performed by the router 10B to obtain downstream header usage information from the upstream traffic 70. For the purpose of explaining this flowchart, consider the case where the following IP addresses are assigned to the devices in FIG. 1: IP address of header attachment / detachment device 20A = 2001:db8:1012:3400:0:c000:0212:0034 (lower 16 bits are 0x0034) IP address of router 10B = 2001:db8:1fff:1::2 IP address of header attachment / detachment device 20B = 2001:db8:1fff:1::1 (lower 16 bits are 0x01)

[0054] Also, the link connected to the analysis device 31 is the first link (first link, selected when the remainder calculation result is 0 within the same NHG) in the output of the router 10B. On the other hand, the link connected to the analysis device 32 is the second link (second link, selected when the remainder calculation result is 1 within the same NHG) in the output of the router 10B.

[0055] At this time, the IPv6 header 72 of the upstream traffic 70 received by the router 10B in S12 is as follows: Source IP address: 2001:db8:1012:3400:0:c000:0212:0034 Destination IP address: 2001:db8:1fff:1::1 Flow label: 0 Receiving link: 0 (first link in the NHG (Next Hop Group), remainder calculation result for the number of links is 0)

[0056] In S121, the router 10B acquires an upstream transit interface for the flow of the upstream traffic 70 from flow information such as flow identification information received from the router 10B as downstream header information 10Y. In S122, the router 10B acquires, from the LB information (Nexthop ID) in the LB notification DT 232, the number A of links constituting the ECMP (Equal Cost Multi Path) to which the upstream transit interface belongs and the ordinal number B of the link of which the upstream transit interface constitutes the ECMP.

[0057] In S123, the router 10B acquires the HA to be used and its initial value from the HA notification DT 212, and also acquires the HF information (field and number of bits used for hashing) from the HF notification OT 201. Note that if the HA is CRC16 (0xf000), only the lower 16 bits of each field of the HF information are used for calculation. The initial value is also set to 0x02.

[0058] An example of HA information is shown below. - Only the lower 16 bits of a 16-bit field are handled, and the value obtained by concatenating each field is used as the input value. - The algorithm is CRC-16 (CRC-16-IBM) (generator polynomial: 0x8005 (left) / 0xA001 (right)) - The seed is 0x0002 (the lower 16 bits of the IP address of router 10B) - The HF information is SIP, DIP, and flow label

[0059] In S124, the router 10B assigns the link ordinal number B (for example, "0") to the final result hash value D (for example, "0x0000") so that the downstream pass-through interface is the same as the upstream pass-through interface. Note that the formula for calculating the interface ID described above is "(link ordinal number B) = (final result hash value D) mod (number of ECMP constituents A)." If (link ordinal number B) < (number of ECMP constituents A), then (link ordinal number B) = (final result hash value D).

[0060] In S125, the router 10B determines whether or not a flow label is included in the HF information notified by the HF notification OT 201. If the answer is Yes in S125, the downstream header usage information is set to the flow label and the process proceeds to S126, and if the answer is No, the downstream header usage information is set to SIP and the process proceeds to S128.

[0061] In S126, the router 10B calculates an intermediate hash value C (for example, "0x8416") using HF information other than the flow label and information for downstream header calculation (HA information, LB information). The final hash value D is the calculation result obtained by referencing all HF information, including downstream header usage information (flow label in S126). The intermediate hash value C is the calculation result obtained by referencing other HF information, excluding downstream header usage information. S126 is, for example, the calculation of steps 1 and 2 below. (Step 1) Using seed (initial value): 0x02 as the initial state of CRC16, calculate the CRC16 calculation result (0xf000) with SIP (lower 16 bits): 0x01. (Step 2) CRC16: 0xf000 is the internal state of CRC16, and the CRC16 calculation result with DIP (lower 16 bits 0x0034) is calculated as the intermediate hash value C (0x8416).

[0062] In S127, the router 10B uses the downstream header calculation information (HA information, LB information) based on the final hash value D and the intermediate hash value C to determine the flow label value (e.g., "0x8416"), which is the downstream header usage information. For example, in the case of the parameters assigned in S124, the flow label value (0x8416) is reverse-calculated from the intermediate hash value C (0x8416) and the final hash value D (0x0000). Note that CRC reverse calculation is a well-known technique (e.g., https: / / qiita.com / dearblue / items / 669e2ce2fae57baf1e90).

[0063] In S128, the router 10B uses the HF information other than SIP and the information for calculating the downstream header (HA information, LB information) to calculate an intermediate hash value C, similar to S126. In S129, the router 10B uses the information for calculating the downstream header (HA information, LB information) to determine SIP, which is the information used for the downstream header, based on the final hash value D and the intermediate hash value C, similar to S127.

[0064] [Effects] The router 10B of the present invention determines the pass-through interface for a packet to be sent from a hash value calculated from field information used for a predetermined hash function in the header information of the packet and information on a set of interfaces heading to the same destination of the packet, and is characterized in that it transmits downstream header information 10Y to the header attachment / detachment device 20B, which associates flow identification information for a bidirectional flow, information indicating the pass-through interface for a received packet of the bidirectional flow, HA information indicating the hash function used by the router 10B, HF information indicating field information that is an argument of the hash function, and LB information indicating a set of candidate interfaces that will determine the pass-through interface for the packet to be sent from the hash value calculated from the hash function, thereby causing the header attachment / detachment device 20B to calculate the hash function indicated by the HA information using the field information indicated by the HF information as an argument, and having a flow generation unit 14 that causes the header attachment / detachment device 20B to generate a header for the packet to be sent so that the pass-through interface for the packet to be sent is the same as the pass-through interface for the received packet when selecting the pass-through interface from the set of interfaces in the LB information based on the hash value calculated from the hash function.

[0065] This allows the router 10B to concentrate bidirectional flows on a specific device and pass them through, even in an environment where bidirectional flows can be distributed to multiple devices for communication. Therefore, even when adjacent forwarding devices (routers 10A and 10B) are operated by different operators or when the forwarding devices (routers 10A and 10B) are not the same model, bidirectional flows can be controlled to be sent and received via the same link. Furthermore, in an IPv6 tunnel environment, the header attachment / detachment device 20B generates an IPv6 header 82 for the downstream traffic 80 based on downstream header calculation information notified by the router 10B. Therefore, the router 10B can output the downstream traffic 80 to the intended interface (the downstream transit interface that is the same as the upstream transit interface).

[0066] The present invention is characterized in that the flow generation unit 14 generates an IPFIX packet in which the downstream header information 10Y is based on flow identification information of the bidirectional flow and information indicating the interface through which the received packet passes, and the optional information is HA information, HF information, and LB information.

[0067] As a result, the router 10B can reduce development costs and maintain high compatibility by using IPFIX, a standard protocol for notifying flow identification information.

[0068] 10A Router 10B Router (header generation information transmitting device) 10Y Downstream header information (header generation information) 11 User interface 12 Routing processing unit 13 Packet communication unit 14 Flow generation unit 20A, 20B Header attachment / detachment device 21 User interface 22 Routing processing unit 23 Packet communication unit 24 Flow processing unit 25 Header calculation unit 26 Flow holding unit 27 Tunnel header control unit 31, 32 Analysis device 100 Flow communication system

Claims

1. A header generation information transmitting device determines a pass-through interface for a packet to be transmitted from a hash value obtained from field information used for a predetermined hash function in the header information of the packet and information on a set of interfaces heading to the same destination of the packet, and transmits header generation information that associates flow identification information of a bidirectional flow, information indicating the pass-through interface of a received packet of the bidirectional flow, first information indicating a hash function used by the header generation information transmitting device, second information indicating field information that is an argument of the hash function, and third information indicating a set of interfaces that are candidates for determining the pass-through interface for the packet to be transmitted from the hash value obtained from the hash function to a header detachment device, thereby causing the header attachment / detachment device to calculate the hash function indicated in the first information using the field information indicated in the second information as an argument, and having a flow generation unit that causes the header attachment / detachment device to generate a header for the packet to be transmitted so that the pass-through interface for the packet to be transmitted is the same as the pass-through interface for the received packet when selecting a pass-through interface from the set of interfaces in the third information based on the hash value obtained from the hash function.

2. The header generation information transmitting device according to claim 1, wherein the flow generation unit generates an IPFIX (IP Flow Information Export) packet using, as the header generation information, the flow identification information of the bidirectional flow and information indicating the interface through which the received packet passes as basic information, and the first information, the second information, and the third information as optional information.

3. A header generation information transmitting device determines a pass-through interface for a packet to be transmitted from a hash value obtained from field information used for a predetermined hash function in the header information of the packet and information on a set of interfaces heading to the same destination of the packet, wherein the header generation information transmitting device transmits header generation information that associates flow identification information of a bidirectional flow, information indicating the pass-through interface of a received packet of the bidirectional flow, first information indicating a hash function used by the header generation information transmitting device, second information indicating field information that is an argument of the hash function, and third information indicating a set of interfaces that are candidates for determining the pass-through interface for the packet to be transmitted from the hash value obtained from the hash function to a header attachment / detachment device, thereby causing the header attachment / detachment device to calculate the hash function indicated in the first information using the field information indicated in the second information as an argument, and executing a process to cause the header attachment / detachment device to generate a header for the packet to be transmitted so that the pass-through interface for the packet to be transmitted is the same as the pass-through interface for the received packet when selecting a pass-through interface for the packet to be transmitted from the hash value obtained from the hash function from the set of interfaces in the third information.

Images