In the IP (Internet Protocol) used in the Internet, information of protocol, source IP address, and destination IP address is managed. In addition, in a part of transport protocols, information of source port and destination port is managed. Packets transmitted using these protocols include information managed by each protocol. Flow measurement is a method for classifying types of communications based on the information included in the packets.
In the flow measurement, packets that have the same attributes are regarded as packets belonging to the same communication. For example, packets having the same information in each item of protocol, source IP address, destination IP address, source port and destination port are regarded as packets belonging to the same communication. A set of packets belonging to the same communication is called a flow. By measuring a data amount or a packet amount of the flow, a plurality of communication services can be monitored among a plurality of locations, so that it becomes possible to specify a section of locations or a communication service in which communication amount is extremely large, and it becomes possible to ascertain communication trend.
The Internet is constructed by interconnecting a plurality of networks each including a plurality of routers for performing routing. A packet transmitted from a source reaches a destination via some routers. Since the router transfers a packet by referring to the IP header of the packet or referring to a header of transport layer in some cases, the router is suitable as an apparatus for performing classification of flows. As a technique for reporting Flow Records of packets passing through the router to another apparatus, there are NetFlow (refer to non-patent document 1) and IPFIX (IP Flow Information, export) and the like.
By transmitting measurement packets, obtained by packetizing Flow Records according to a specific format, to a measurement terminal on the network, communication information of the node can be analyzed. However, according to the non-patent document 2, the number of flows abruptly increases when attack traffic called DDoS (Distributed Denial of Service) occurs in which a large amount of traffic is continuously transmitted by distributing source addresses, and when attack traffic called port scan occurs in which service state and vulnerability are detected by trying to connect to every port of a target host.
In addition, according to the non-patent document 3, in IPFIX for reporting Flow Records, UDP (User Datagram Protocol) which does not have congestion control, and TCP (Transmission Control Protocol) or SCTP (Stream Control Transmission Protocol) having congestion control can be used. When an apparatus for sending and receiving flows performs transmission by using UDP which does not have the congestion control function, as the number of flows increases abruptly, the number of packets transmitted from the flow transmission apparatus such as a router to a measurement terminal increases. As a result, there is a possibility that congestion occurs in a measurement network between the flow transmission apparatus and the measurement terminal.
On the other hand, when the apparatus for sending and receiving flows performs transmission using TCP or SCTP having the congestion control function, even if the number of flows increases abruptly, congestion does not occur. However, since the number of Flow Records that can be sent is limited in the flow transmission apparatus due to the congestion control function, the number of Flow Records that can be transmitted becomes smaller that the number of Flow Records that are generated. Thus, there is a case in which internal transmission buffer overflows. As a result, Flow Records that can be transmitted is limited to Flow Records generated first, so that information of the whole observed traffic cannot be sent.    [Non Patent document 1] Browsed on Sep. 8, 2006 on the Internet, B. Claise. Cisco Systems NetFlow Services Export Version 9. RFC 3954 (Informational), October 2004. http://www.ietf.org/rfc/rfc3954.txt    [Non Patent document 2] Cristian Eatan, Ken Keys, David Moore, George Varghese: “Building a better netflow”, ACM SIGCOMM Computer Communication Review, 34, Issue 4, pp. 245-256 (2004)    [Non Patent document 3] B. Claise. IPFIX Protocol Specification. Internet Draft, June 2006. HYPERLINK “http://tools.ietf.org/id/draft-ietf-ipfix-protocol-22.txt” http://tools.ietf.org/id/draft-ietf-ipfix-protocol-22.txt