U.S. patent application number 13/192038 was filed with the patent office on 2013-01-31 for wide field indexing for packet tracking.
The applicant listed for this patent is Earl Chew. Invention is credited to Earl Chew.
Application Number | 20130028105 13/192038 |
Document ID | / |
Family ID | 46798940 |
Filed Date | 2013-01-31 |
United States Patent
Application |
20130028105 |
Kind Code |
A1 |
Chew; Earl |
January 31, 2013 |
Wide Field Indexing for Packet Tracking
Abstract
Methods, apparatus, and computer readable storage media for
accumulating traffic statistics. A traffic receiver may receive a
packet and determine a flow identifier associated with the received
packet. A hash function may be applied to the flow identifier to
generate a memory pointer. One or more records may be retrieved
from a statistics memory based on the memory pointer. A
determination may be made if the flow identifier associated with
the received packet matches a flow identifier value contained in
one of the one or more retrieved records. When a match occurs, the
retrieved record containing the matching flow identifier value may
be updated and the updated record may be stored in the statistics
memory.
Inventors: |
Chew; Earl; (Vancouver,
CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Chew; Earl |
Vancouver |
|
CA |
|
|
Family ID: |
46798940 |
Appl. No.: |
13/192038 |
Filed: |
July 27, 2011 |
Current U.S.
Class: |
370/252 |
Current CPC
Class: |
H04L 43/026 20130101;
H04L 43/12 20130101 |
Class at
Publication: |
370/252 |
International
Class: |
H04L 12/26 20060101
H04L012/26 |
Claims
1. A method to accumulate traffic statistics, comprising: receiving
a packet determining a flow identifier associated with the received
packet applying a hash function to the flow identifier to generate
a memory pointer retrieving one or more records from a statistics
memory based on the memory pointer determining if the flow
identifier associated with the received packet matches a flow
identifier value contained in one of the one or more retrieved
records when a match occurs updating the retrieved record
containing the matching flow identifier value storing the updated
record in the statistics memory.
2. The method of claim 1, wherein determining a flow identifier
associated with the received packet comprises: extracting one or
more fields from the received packet applying masks to the one or
more extracted fields combining unmasked bits from the extracted
fields to form the flow identifier.
3. The method of claim 1, wherein the statistics memory is
configured to store a plurality of records, logically organized as
a table with c columns and r rows, where r and c are integers
greater than one, and retrieving one or more records comprises
retrieving c records from a row identified by the address
pointer.
4. The method of claim 3, wherein applying a hash function
comprises applying a cyclic redundancy check polynomial to the flow
identifier to generate the address pointer.
5. The method of claim 1, further comprising: when the flow
identifier associated with the received packet does not match any
of the flow identifier values contained in the one or more
retrieved records, determining if any of the one or more retrieved
records is empty when one of the retrieved records is identified as
an empty record, initializing the identified record based on the
received packet and storing the initialized record in the
statistics memory.
6. The method of claim 5, wherein initializing the identified
record comprises: setting a value for a number of received packets
field within the identified record to one writing the flow
identifier associated with the received packet to a flow identifier
field within the identified record.
7. The method of claim 6, wherein initializing the empty record
further comprises: writing a latency time of the received packet to
one or more of a minimum latency time field, a maximum latency time
field, and an average latency time field within the identified
record.
8. The method of claim 5, further comprising: when the flow
identifier associated with the received packet does not match any
of the flow identifier values contained in the one or more
retrieved records and none of the retrieved records is identified
as an empty record, incrementing a counter indicating a number of
collisions.
9. A traffic receiver, comprising: a statistics memory configured
to store a plurality of records logic circuits configured to:
receive a packet determine a flow identifier associated with the
received packet apply a hash function to the flow identifier to
generate a memory pointer retrieve one or more records from the
statistics memory based on the memory pointer determine if the flow
identifier associated with the received packet matches a flow
identifier value contained in one of the one or more retrieved
records when a match occurs, update the retrieved record containing
the matching flow identifier value and store the updated record in
the statistics memory.
10. The traffic receiver of claim 9, the logic circuits further
configured to: extract one or more fields from the received packet
apply predetermined masks to the one or more extracted fields
combine unmasked bits from the extracted fields to form the flow
identifier.
11. The traffic receiver of claim 9, wherein the statistics memory
is logically organized as a table with c columns and r rows, where
c and r are integers greater than one, and the one or more records
retrieved from the statistics memory is c records from a row
identified by the address pointer.
12. The traffic receiver of claim 11, the logic circuits further
configured to apply a cyclic redundancy check polynomial to the
flow identifier to generate the address pointer.
13. The traffic receiver of claim 9, the logic circuits further
configured to: when the flow identifier associated with the
received packet does not match any of the flow identifier values
contained in the one or more retrieved records, determine if any of
the one or more retrieved records is empty when one of the
retrieved records is identified as an empty record, initialize the
identified record based on the received packet and store the
initialized record in the statistics memory.
14. The traffic receiver of claim 13, wherein the logic circuits
are configured to initialize the identified record by actions
including: setting a value of a number of received packets field
within the identified record to one, and writing the flow
identifier associated with the received packet to a flow identifier
field within the identified record.
15. The traffic receiver of claim 14, wherein the logic circuits
are configured to initialize the identified record by further
actions including: writing a latency time of the received packet to
one or more of a minimum latency time field, a maximum latency time
field, and an average latency time field within the identified
record.
16. The traffic receiver of claim 13, the logic circuits further
configured to: when the flow identifier associated with the
received packet does not match any of the flow identifier values
contained in the one or more retrieved records and none of the
retrieved records is identified as an empty record, increment a
counter indicating a number of collisions.
17. A machine-readable storage medium storing configuration data
that, when used to configure one or more programmable logic
devices, causes the programmable logic devices to include logic
circuits configured to: receive a packet determine a flow
identifier associated with the received packet apply a hash
function to the flow identifier to generate a memory pointer
retrieve one or more records from a statistics memory based on the
memory pointer determine if the flow identifier associated with the
received packet matches a flow identifier value contained in one of
the one or more retrieved records when a match occurs, update the
retrieved record containing the matching flow identifier value and
store the updated record in the statistics memory.
18. The machine-readable storage medium of claim 17, the logic
circuits further configured to: extract one or more fields from the
received packet apply predetermined masks to the one or more
extracted fields combine unmasked bits from the extracted fields to
form the flow identifier.
19. The machine-readable storage medium of claim 17, wherein the
statistics memory is logically organized as a table with c columns
and r rows, where c and r are integers greater than one, and the
one or more records retrieved from the statistics memory are c
records from a row identified by the address pointer.
20. The machine-readable storage medium of claim 17, the logic
circuits further configured to apply a cyclic redundancy check
polynomial to the flow identifier to generate the address
pointer.
21. The machine-readable storage medium of claim 17, the logic
circuits further configured to: when the flow identifier associated
with the received packet does not match any of the flow identifier
values contained in the one or more retrieved records, determine if
any of the one or more retrieved records is empty when one of the
retrieved records is identified as an empty record, initialize the
identified record based on the received packet and store the
initialized record in the statistics memory.
22. The machine-readable storage medium of claim 21, wherein the
logic circuits are configured to initialize the identified record
by actions including: setting a value of a number of received
packets field within the identified record to one, and writing the
flow identifier associated with the received packet to a flow
identifier field within the identified record.
23. The machine-readable storage medium of claim 22, wherein the
logic circuits are configured to initialize the identified record
by further actions including: writing a latency time of the
received packet to one or more of a minimum latency time field, a
maximum latency time field, and an average latency time field
within the identified record.
24. The machine-readable storage medium of claim 21, the logic
circuits further configured to: when the flow identifier associated
with the received packet does not match any of the flow identifier
values contained in the one or more retrieved records and none of
the retrieved records is identified as an empty record, increment a
counter indicating a number of collisions.
Description
NOTICE OF COPYRIGHTS AND TRADE DRESS
[0001] A portion of the disclosure of this patent document contains
material which is subject to copyright protection. This patent
document may show and/or describe matter which is or may become
trade dress of the owner. The copyright and trade dress owner has
no objection to the facsimile reproduction by anyone of the patent
disclosure as it appears in the Patent and Trademark Office patent
files or records, but otherwise reserves all copyright and trade
dress rights whatsoever.
BACKGROUND
[0002] 1. Field
[0003] This disclosure relates to generating connections for
testing a network or network device.
[0004] 2. Description of the Related Art
[0005] In many types of communications networks, each message to be
sent is divided into portions of fixed or variable length. Each
portion may be referred to as a packet, a frame, a cell, a
datagram, a data unit, or other unit of information, all of which
are referred to herein as packets.
[0006] Each packet contains a portion of an original message,
commonly called the payload of the packet. The payload of a packet
may contain data, or may contain voice or video information. The
payload of a packet may also contain network management and control
information. In addition, each packet contains identification and
routing information, commonly called a packet header. The packets
are sent individually over the network through multiple switches or
nodes. The packets are reassembled into the message at a final
destination using the information contained in the packet headers,
before the message is delivered to a target device or end user. At
the receiving end, the reassembled message is passed to the end
user in a format compatible with the user's equipment.
[0007] Communications networks that transmit messages as packets
are called packet switched networks. Packet switched networks
commonly contain a mesh of transmission paths which intersect at
hubs or nodes. At least some of the nodes may include a switching
device or router that receives packets arriving at the node and
retransmits the packets along appropriate outgoing paths. Packet
switched networks are governed by a layered structure of
industry-standard protocols.
[0008] Layer 1 protocols define the physical (electrical, optical,
or wireless) interface between nodes of the network. Layer 1
protocols include various Ethernet physical configurations, the
Synchronous Optical Network (SONET) and other optical connection
protocols, and various wireless protocols such as Wi-Fi.
[0009] Layer 2 protocols govern how data is logically transferred
between nodes of the network. Layer 2 protocols include the
Ethernet, Asynchronous Transfer Mode (ATM), Frame Relay, and Point
to Point Protocol (PPP).
[0010] Layer 3 protocols govern how packets are routed from a
source to a destination along paths connecting multiple nodes of
the network. The dominant layer 3 protocols are the well-known
Internet Protocol version 4 (IPv4) and version 6 (IPv6). A packet
switched network may need to route IP packets using a mixture of
the Ethernet, ATM, FR, and/or PPP layer 2 protocols. At least some
of the nodes of the network may include a router that extracts a
destination address from a network layer header contained within
each packet. The router then used the destination address to
determine the route or path along which the packet should be
retransmitted. A typical packet may pass through a plurality of
routers, each of which repeats the actions of extracting the
destination address and determining the route or path along which
the packet should be retransmitted.
[0011] In order to test a packet switched network or a device
included in a packet switched communications network, test traffic
comprising a large number of packets may be generated, transmitted
into the network at one or more ports, and received at different
ports. In this context, the term "port" refers to a communications
connection between the network and the equipment used to test the
network. The term "port unit" refers to a module within the network
test equipment that connects to the network at a port. The received
test traffic may be analyzed to measure the performance of the
network. Each port unit connected to the network may be a source of
test traffic, a destination for test traffic, or both a source of
and a destination for test traffic. Each port unit may emulate a
plurality of logical source or destination addresses. The number of
port units and the communications paths that connect the port units
to the network are typically fixed for the duration of a test
session. The internal structure of the network may change during a
test session, for example due to failure of a communications path
or hardware device.
[0012] For the purpose of collecting test data, the test traffic
for each traffic item may be organized into packet groups, where a
"packet group" is any plurality of packets for which network
traffic statistics are accumulated. The packets in a given packet
group may be distinguished by a packet group identifier (PGID)
contained in each packet. The PGID may be, for example, a dedicated
identifier field or combination of two or more fields within each
packet.
[0013] For the purpose of reporting network traffic data, the test
traffic for each traffic item may be organized into flows, where a
"flow" is any plurality of packets for which network traffic
statistics are reported. Each flow may consist of a single packet
group or a small plurality of packet groups. Each packet group may
typically belong to a single flow.
[0014] Within this description, the term "logic circuit" means a
collection of hardware, which may be augmented by firmware and/or
software, which performs a described function or set of functions.
The term "logic circuit" encompasses combinatorial logic and
sequential logic such as, for example, state machines. All or
portions of a "logic circuit" may be implemented by a
micro-controller or other processor. Logic circuits may typically
be designed using a hardware description language (HDL) that
defines the logic circuits primarily in functional terms. The HDL
design may be verified using an HDL simulation tool. The verified
HDL design may then be converted into a gate netlist or other
physical description of the logic circuits in a process commonly
termed "synthesis". The synthesis may be performed automatically
using a synthesis tool. The gate netlist or other physical
description may be converted into process instructions and masks
for fabricating the engine within an application specific
integrated circuit (ASIC).
[0015] A gate netlist or other physical description of logic
circuits may be further converted into configuration data for
implementing the logic circuits in a field programmable gate array
(FPGA), a programmable logic device (PLD), or a programmable logic
arrays (PLA), or other programmable semiconductor device, all of
which will be referred to herein as "programmable circuit devices".
Configuration data for programming a programmable circuit device
may be stored in a memory or a machine readable storage medium and
used to configure a programmable circuit device upon power-up of a
test system. In this patent, the term "machine readable storage
medium" means a non-volatile medium for storing digital data.
Examples of machine readable storage media include optical discs
such as CD-ROM, CD-RW, and DVD discs; magnetic medium such as hard
and flexible magnetic discs and magnetic tape; and nonvolatile
semiconductor devices such as read-only and flash memories. The
term "machine readable storage medium" is not intended to encompass
transitory media such as signals and waveforms that may convey
digital data.
[0016] Within this description, a hardware "unit" also means a
collection of hardware, which may be augmented by firmware and/or
software, which may be on a larger scale or have a more focused
function than a "logic circuit". The terms "logic circuit" and
"unit" do not imply any physical separation or demarcation. All or
portions of one or more logic circuits and/or units may be
collocated on a common card, such as a network card or within a
common programmable device, ASIC, or other circuit device.
DESCRIPTION OF THE DRAWINGS
[0017] FIG. 1 is a block diagram of a network environment.
[0018] FIG. 2 is a block diagram of a port unit.
[0019] FIG. 3 is a graphical representation of accessing a flow
statistics memory.
[0020] FIG. 4 is a graphical representation of accessing a flow
statistics memory.
[0021] FIG. 5 is a flow chart of a process for receiving
packets.
[0022] Throughout this description, elements appearing in figures
are assigned three-digit reference designators, where the most
significant digit is the figure number where the element is
introduced and the two least significant digits are specific to the
element. An element that is not described in conjunction with a
figure may be presumed to have the same characteristics and
function as a previously-described element having the same
reference designator.
[0023] In block diagrams, arrow-terminated lines may indicate data
paths rather than signals. Each data path may be multiple bits in
width. For example, each data path may consist of 4, 8, 16, 64,
256, or more parallel connections.
DETAILED DESCRIPTION
[0024] Description of Apparatus
[0025] FIG. 1 shows a block diagram of a network testing
environment. The network testing environment may include a network
traffic analyzer 100, a network traffic simulator 104, and a
network 190 including one or more network devices 192. The network
traffic simulator 104 may generate test traffic that is received by
the network traffic analyzer 100 via the network 190 and/or network
devices 192 under test. The network traffic analyzer 100 and the
network traffic simulator 104 may be separate physical units, as
shown, or may be combined in a single unit the both generates and
receives test traffic.
[0026] The network traffic analyzer 100 may be a network testing
device, performance analyzer, conformance validation system,
network analyzer, or network management system. The network traffic
analyzer 100 may be a portion of the network 190 or a device within
the network 190 performing self-testing. The network traffic
analyzer 100 may include one or more network cards 112 enclosed
within a chassis 102. The chassis 102 may be a fixed or portable
chassis, cabinet, or enclosure suitable to contain the network test
equipment. The network traffic analyzer 100 may be an integrated
unit, as shown in FIG. 1. Alternatively, the network traffic
analyzer 100 may comprise a number of separate units cooperative to
provide traffic generation and/or analysis.
[0027] The network traffic simulator 104 may be a network testing
device, performance analyzer, conformance validation system,
network analyzer, or network management system. The network traffic
simulator 104 may be a portion of the network 190 or a device
within the network 190 performing self-testing. The network traffic
simulator 104 may include one or more network cards 116 enclosed
within a chassis 106. The chassis 106 may be a fixed or portable
chassis, cabinet, or enclosure suitable to contain the network test
equipment. The network traffic simulator 104 may be an integrated
unit, as shown in FIG. 1. Alternatively, the network traffic
simulator 104 may comprise a number of separate units cooperative
to provide traffic generation and/or analysis. The network cards
112/116 may be permanently installed in the network traffic
analyzer 100 and network traffic simulator 104 or may be
removable.
[0028] The network cards 112/116 may include one or more field
programmable gate arrays (FPGAs), application specific integrated
circuits (ASICs), programmable logic devices (PLDs), programmable
logic arrays (PLAs), processors, and other kinds of programmable
circuit devices. In addition, the network cards 112/116 may include
software and/or firmware. The term network card encompasses line
cards, test cards, analysis cards, network line cards, load
modules, interface cards, network interface cards, data interface
cards, packet engine cards, service cards, smart cards, switch
cards, relay access cards, and the like. The term network card also
encompasses modules, units, and assemblies that may include
multiple printed circuit boards. Each network card 112/116 may
contain one or more port unit 110/114. Each port unit 110/114 may
connect to the network 190 through one or more ports. Each port
unit 110/114 may be connected to the network 190 through a
communication medium 195, which may be a wire, an optical fiber, a
wireless link, or other communication medium. Each network card
112/116 may support a single communications protocol, may support a
number of related protocols, or may support a number of unrelated
protocols.
[0029] The network devices 192 may be any devices capable of
communicating over the network 190. The network devices 192 may be
computing devices such as workstations, personal computers,
servers, portable computers, personal digital assistants (PDAs),
computing tablets, cellular/mobile telephones, e-mail appliances,
and the like; peripheral devices such as printers, scanners,
facsimile machines and the like; network capable storage devices
including disk drives such as network attached storage (NAS) and
storage area network (SAN) devices; networking devices such as
routers, relays, hubs, switches, bridges, server load balancers
(SLBs), and multiplexers. In addition, the network devices 192 may
include appliances, alarm systems, and any other device or system
capable of communicating over a network.
[0030] The network 190 may be a Local Area Network (LAN), a Wide
Area Network (WAN), a Storage Area Network (SAN), wired, wireless,
or a combination of these, and may include or be the Internet.
Communications on the network 190 may take various forms, including
frames, cells, datagrams, packets or other units of information,
all of which are referred to herein as packets. The network traffic
analyzer 100 and the network devices 192 may communicate
simultaneously with one another, and there may be plural logical
communications paths between the network traffic analyzer 100 and a
given network device 192. The network itself may be comprised of
numerous nodes providing numerous physical and logical paths for
data to travel.
[0031] Referring now to FIG. 2, an exemplary port unit 210 may
include a port central processing unit (CPU) 220, a traffic
receiver 240 coupled to a traffic statistics memory 255, and a
network interface unit 230 which couples the port unit 210 to a
network 290. The port unit 210 may be all or part of a network card
for use in a traffic analyzer, such as the network cards 112 in the
network traffic analyzer 100. A port unit may also contain a
traffic generator, not shown in FIG. 2.
[0032] The port CPU 220 may include one or more processors, a
memory coupled to the processors, and various specialized units,
circuits, software and interfaces for providing the functionality
and features described here. The processes, functionality and
features may be embodied in whole or in part in software which
operates on the processor and may be in the form of firmware, an
application program, an applet (e.g., a Java applet), a browser
plug-in, a COM object, a dynamic linked library (DLL), a script,
one or more subroutines, or an operating system component or
service. The hardware and software and their functions may be
distributed such that some functions are performed by the processor
and others by other devices.
[0033] The port CPU 220 may communicate with a test administrator
205. The test administrator 205 may be a computing device contained
within, or external to, the network traffic analyzer 100. The test
administrator 205 may provide the port CPU 220 with instructions
and data required for the port unit to participate in testing the
network 290. The instructions and data received from the test
administrator 205 may include, for example, definitions of traffic
statistics that may be accumulated and reported by the port unit
210.
[0034] The network interface unit 230 may receive electrical,
optical, or wireless signals from the network 290 over the link 295
and may convert the received signals into incoming test traffic 235
in a format usable to the traffic receiver 240.
[0035] The traffic receiver 240 may receive the incoming test
traffic 235 from the network interface unit 230. The traffic
receiver 240 may include logic circuits to determine if each
received packet is a member of a specific flow, and to accumulate
traffic statistics for each flow in accordance with test
instructions 222 provided by the port CPU 220.
[0036] Accumulated traffic statistics 255 may be stored in the
statistics memory 250. The statistics memory 250 may store n
records such as the record 260, where n is a positive integer. The
number of records n may be a large binary number such as 65,536
(2.sup.16) or 262,144 (2.sup.18). The number of records n is not
limited to a binary number. Each of the n records may contain the
traffic statistics for a corresponding flow. Each of the n records
may contain traffic statistics including quantitative information
such as a number of packets received and a number of packets
received out-of-order, temporal information such as maximum and
minimum latency times, and other information. The records stored in
the statistics memory 250 may be logically organized as a table
having c columns and r rows of records, where c and r are positive
integers such that cr=n.
[0037] The traffic receiver 240 may also include logic circuits to
capture and store selected packets in accordance with capture
criteria included in the test instructions 222. The traffic
receiver 240 may provide traffic statistics 242 and/or captured
packets 244 to the port CPU 220, in accordance with the test
instructions 222, for additional analysis during, or subsequent to,
the test session.
[0038] The port unit 210 may accumulate traffic statistics for a
plurality of flows. For example, each flow may be identified by a
packet group identification number (PGID) embedded within a payload
portion of each received packet, as described in U.S. Pat. No.
6,717,917, entitled "METHOD OF DETERMINING REAL-TIME DATA LATENCY
AND APPARATUS THEREFOR". However, in some circumstances, the
incoming test traffic 235 may not contain PGIDs within each packet.
For example, a traffic analyzer may be used to analyze actual
network traffic rather than test traffic generated by a traffic
simulator, or a traffic analyzer may be used to analyze test
traffic generated by a traffic simulator that does not have the
capability of embedding PGIDs in each packet. In situations where
received packets do not contain embedded PGIDs, packet flows may be
identified by data extracted from other fields in the received
packets.
[0039] FIG. 3 shows a graphical representation of determining a
flow identifier for a received packet and accessing the
corresponding traffic statistics in a statistics memory. The
statistics memory 350 may store n=2.sup.2 records organized as a
single column of records. The statistics memory 350 may be the
statistics memory 250 of FIG. 2 with c=1. Each of the 2.sup.w
records may be accessed using a corresponding w-bit address
pointer.
[0040] A received packet 305 may have a header portion divided into
a plurality of fields including some or all of source and
destination media access (MAC) addresses, source and destination
internet protocol (IP) addresses, source and destination
transmission control protocol (TCP) port numbers, a sequence
number, a quality of service (QOS) field, and one or more
checksums. The received packet 305 may also include a payload
portion. When the received packet 305 does not contain a PGID
embedded in the payload portion, data from one or more fields may
be extracted and combined to generate a flow identifier that
associates the received packet 305 with a particular flow and with
a corresponding record in the statistics memory 350. U.S. Pat. No.
7,643,431, entitled "DISTRIBUTED PACKET GROUP IDENTIFICATION FOR
NETWORK TESTING", describes developing a packet group identifier by
combining multiple fields extracted from a received packet.
[0041] In the example of FIG. 3, two fields 310, 315 may be
extracted from the received packet. The extracted fields may
typically be header fields such as MAC or IP addresses, TCP port
numbers, QOS, or other fields. More than two fields may be
extracted and combined to form a flow identifier. Masks 320, 325
may be applied to the extracted fields 310, 315, respectively. For
example, the shaded portions of the masks 320, 325 may represent
bits set to "0" and the unshaded portions may represent bits set to
"1". The extracted fields 310, 315 and the respective masks 320,
325 may be combined by an AND function to produce masked data
fields 330, 335. In the masked data fields 330, 335, the masked
bits (shown shaded) may set to zero, and the unmasked bits (shown
with single hatching) may be equal to the corresponding bits of the
extracted fields 310, 315.
[0042] The masked data fields 330, 335 may then be combined to form
a flow identifier 340. The unmasked bits (shown with single
hatching) may be shifted such that all unmasked bits are contiguous
within the flow identifier 340. The resulting flow identifier 340
may contain m bits, where m is the sum of the bit lengths of the
extracted fields 310 and 315, including k contiguous unmasked bits.
The k contiguous unmasked bits may be located anywhere within the
flow identifier 340. In the case where k.ltoreq.w, the k unmasked
bits may simply be used as the address pointer to access a
corresponding row of the statistics memory 350. However, if k>w,
the k unmasked bits cannot be used directly as the address pointer
to access the statistics memory 350, since some possible values of
the k unmasked bits will point to rows that do not exist within the
statistics memory.
[0043] When k>w, the k unmasked bits of the flow identifier 340
may be mapped to a w-bit address pointer value using a hash
function. A hash function is any algorithm or mathematical function
that converts a larger amount of data into a smaller amount of
data, typically a single integer. The value returned by a hash
function is called hash value. For example, an order-w CRC (cyclic
redundancy check) polynomial may be used to generate a w bit hash
value 345 for use as the address pointer to access the statistics
memory 350. A CRC polynomial has the desirable property that the
mapping from the flow identifier 340 to the hash value 345 is
unique when k.ltoreq.w. This may not necessarily be true of other
hash functions.
[0044] When k>w, multiple possible values of the k unmasked bits
of the flow identifier may map to the same value of the w-bit hash
value 345. Thus there is a possibility that traffic statistics for
two or more flows may be erroneously combined in a single record
within the statistics memory 350. To avoid accumulation of
erroneous flow statistics, each record in the statistics memory 350
may include a field containing the flow identifier of the
corresponding flow.
[0045] When the packet 305 is received by the traffic receiver 240,
dedicated logic circuits or a combination of software and hardware
may generate the flow identifier 340. A hash function 342 may then
be applied to map the flow identifier 340 to the hash value 345.
The hash value 345 may then be used to retrieve a record 360 from
the statistics memory 350. The retrieved record 360 may include a
field 362 containing a flow identifier value corresponding to the
traffic statistics stored in the retrieved record. A comparator 370
may then compare the generated flow identifier 340 and the
retrieved flow identifier field 362. If the two values are equal,
the packet 305 belongs to the flow corresponding to the traffic
statistics stored in the retrieved record 360. In this case, the
retrieved record 360 may be updated to reflect the receipt of the
packet 305. The updated record may be stored back in the statistics
memory 350.
[0046] If the comparator 370 indicates that the two flow identifier
values are not equal, the packet 305 does not belong to the flow
corresponding to the traffic statistics stored in the retrieved
record, but rather belongs to a different flow that maps to the
same hash value. This situation may be referred to as a
"collision", since a second flow has "collided" with the flow whose
traffic statistics were already stored in the statistics memory
350. In this case, the traffic statistics contained in the
retrieved record 360 may not be updated, and the packet 305 may be
discarded. A packet receiver may maintain a count 380 indicating
the number of collisions that have occurred. This count may be
incremented each time a collision occurs. Although not shown in
FIG. 3, a count of collisions may be maintained for each record. In
this case, a field (not shown) within the retrieved record 360 may
be incremented when a collision occurs, and the updated record may
then be stored back in the statistics memory 350.
[0047] A traffic receiver that uses a hash function to map a flow
identifier to an address pointer for accessing a traffic statistic
memory may not be able to accumulate traffic statistics for all
flows due to collisions. Typically, the hash function 342 randomly
maps a flow identifier 340 to a hash value 345. In this case, as
the number of different received flow identifiers approaches the
number of available records in the traffic statistics memory, about
37% of the received flow identifiers will be discarded due to
collisions. Thus the traffic receiver may be able to accumulate
traffic statistics on only about 63% of the actual flows.
[0048] FIG. 4 shows a graphical representation of determining a
flow identifier for a received packet and accessing the
corresponding traffic statistics in a statistics memory. The
statistics memory 450 may store n=2.sup.w records organized as 2
columns by 2.sup.w/=2.sup.w-1 rows. The statistics memory 450 may
be the statistics memory 250 of FIG. 2 with c=2. Each row of the
2.sup.w-1 records may be accessed using a corresponding w-1 bit
address pointer.
[0049] As described in conjunction with FIG. 3, fields 410, 415 may
be extracted from a received packet 405. Masks 420, 425 may be
applied to the extracted fields 410, 415, and the resultant masked
fields 430, 435 may be combined to form a flow identifier 440. A
hash function, such as a w-1 order CRC polynomial, may be applied
to the flow identifier 440 to produce a w-1 bit hash value 445.
[0050] When the packet 405 is received by a traffic receiver such
as the traffic receiver 240, dedicated logic circuits or a
combination of software and hardware may generate the flow
identifier 440 and the hash value 445. The hash value 445 may then
be used to retrieve a row containing records 462 and 464 from the
statistics memory 450. Since two records are retrieved
simultaneously, the width in bits of the data path from the
statistics memory must be twice as wide as the data path required
to read a single-column statistics memory (as shown in FIG. 3).
Each retrieved record 462, 464 may include respective fields 463,
465 containing a flow identifier value corresponding to the traffic
statistics respectively stored in the retrieved records.
[0051] Respective comparators 470, 475 may then compare the
generated flow identifier 440 and the retrieved flow identifier
fields 463, 465. If the generated flow identifier 440 matches the
retrieved flow identifier 463, the packet 405 belongs to the flow
corresponding to the traffic statistics stored in the retrieved
record 462. In this case, the retrieved record 462 may be updated
to reflect the receipt of the packet 405. If the generated flow
identifier 440 matches retrieved flow identifier 465, the packet
405 belongs to the flow corresponding to the traffic statistics
stored in the retrieved record 464. In this case, the retrieved
record 464 may be updated to reflect the receipt of the packet 405.
The updated versions of records 462, 464 may be stored back in the
statistics memory 450.
[0052] If the comparators 470, 475 indicate that the generated flow
identifier 440 is not equal to either of the retrieved flow
identifiers 463, 465, the packet 405 does not belong to the flow
corresponding to the traffic statistics stored in either retrieved
record, but may belong to a different flow that maps to the same
hash value. This situation may be referred to as a "collision",
since a third flow has "collided" with the two flows whose traffic
statistics were already stored in the statistics memory 450. In
this case, a counter 480, indicating a total number of collisions
that have occurred, may be incremented.
[0053] A traffic receiver that uses a hash function to map a flow
identifier to an address pointer for accessing a traffic statistic
memory organized as multiple columns of records may not be able to
accumulate traffics statistics for all flows due to collisions.
However, the number of collisions may be greatly reduced compared
to a traffic statistics memory organized as a single column. In the
two-column example of FIG. 4, as the number of different received
flow identifiers approaches the number of available records in the
traffic statistics memory, only about 27% of the received flow
identifiers will be discarded due to collisions. Thus the traffic
receiver may be able to accumulate traffic statistics on about 73%
of the actual flows. The number of collisions may be further
reduced by increasing the number of columns in the statistics
memory, at a cost of a proportional increase in the width of the
data path from the statistics memory.
[0054] Description of Processes
[0055] Referring now to FIG. 5, a process 500 for accumulating
traffic statistics may begin at 505 when instructions to start
accumulating traffic statistics are received at a port unit such as
the port unit 210. The process 500 may be cyclic in nature, and the
actions from 515 to 585 may be performed repeatedly to accumulate
traffics statistics for a large number of received packets.
Multiple instances of the process 500 may be performed concurrently
at a plurality of port units to accumulate traffic statistics for a
network or network device under test.
[0056] For ease of discussion, the process 500 is shown in FIG. 5
as a flow chart with sequential actions. However all or portions of
the process 500 may be performed in parallel by logic circuits
within a traffic receiver. In particular, the actions from 535 to
585 may be performed nearly simultaneously during a single hardware
memory cycle. A traffic receiver may perform the actions from 515
to 585, at least in part, as a pipeline such that multiple
instances of the process occur simultaneously.
[0057] When an instruction to start accumulating traffic statistics
is received at 505, a statistics memory, such as the statistics
memory 250 of FIG. 2, may be cleared or emptied to indicate that no
traffic statistics are currently stored. Alternatively, the
statistics memory may be cleared at the conclusion of a previous
test session or at some other time in anticipation that a start
instruction will be received at 505. A statistics memory may be
considered to be cleared or empty when a traffic receiver coupled
to the statistics memory can determine whether or not a record
contains currently valid statistics data. For example, a "number of
received packets" field within each record may be set to zero to
empty a statistics memory.
[0058] A packet may be received at 515. At 520, one or more
predetermined fields may be extracted from the received packet 518.
The extracted fields may contain information useful to characterize
and report flow statistics information. The extracted fields may
include, for example, one or more of source and destination MAC
addresses, source and destination IP addresses, source and
destination TCP port numbers, a protocol identifier, a quality of
service value, flags, and other fields.
[0059] At 520, masks may be applied to the fields extracted at 520
and the resultant unmasked bits may be compressed to form a flow
identifier 528, as previously described in conjunction with FIG. 3.
At 530, a hash function may be applied to the flow identifier 528,
and the resulting hash value may be used to retrieve a plurality of
records from the statistics memory at 535. As previously described,
the statistics memory 250 may be configured as a table having c
columns and 2.sup.w/c rows, where 2.sup.w is the total capacity of
the statistics memory in records. At 535, an entire row of the
table may be retrieved, such that the number of records retrieved
is equal to the number of columns.
[0060] At 540, the c records retrieved at 535 may be processed to
determine if any one of the retrieved records should be updated
based on the received packet 518. At 545, a determination may be
made whether or not the flow identifier 528 matches the content of
a "flow identifier" field within the first record. When a match is
found, the first record may be updated at 550. Updating the first
record at 550 may include incrementing a "number of received
packets" field within the first record to reflect receipt of the
received packet 518. Other fields within the first record may be
updated based on the packet received at 515. For example, a latency
time of the received packet 518 may be written into a "minimum
latency" field or a "maximum latency" field within the first record
if appropriate. The updated first record may be stored back into
the statistics memory at 585, and the process 500 may return to 515
to await the receipt of another packet.
[0061] The actions at 540 may be performed for each of the c
records retrieved at 535. As shown in FIG. 5, the actions at 540
may be performed in parallel for each retrieved record, for example
using dedicated hardware. Although not shown, the actions at 540
may be performed sequentially for each of the n retrieved
records.
[0062] When the flow identifier 528 does not match a flow
identifier field within any of the c retrieved records, the c
records retrieved at 535 may be processed at 560 to determine if
one of the retrieved records should be initialized based on the
received packet 518. A determination may be made at 565 whether or
not the first retrieved record is empty. For example, a
determination may be made if a "number of received packets" field
within the first record is set to zero. When a determination is
made that the first record is empty, the first record may be
initialized based on the received packet 518 at 570. Initializing
the first record at 570 may include setting the value of a number
of received packets field within the first record to one.
Initializing the first record at 570 may also include copying the
flow identifier 528 to a "flow identifier" field within the first
record. Other fields within the first record may be updated based
on the received packet 518. For example, a latency time of the
received packet 518 may be written into both a "minimum latency"
field and a "maximum latency" field within the first record. The
initialized first record may be stored back into the statistics
memory at 585, and the process 500 may return to 515 to await the
receipt of another packet.
[0063] The actions at 560 may be performed for each of the c
records retrieved at 535. As shown in FIG. 5, the actions at 560
may be performed in parallel for all retrieved record, for example
using dedicated hardware. Although not shown, the actions at 560
may be performed sequentially for each of the retrieved records.
When two or more retrieved records are empty, priority logic (not
shown) may be used to determine which of the empty records is
initialized.
[0064] When the flow identifier 528 does not match the content of a
flow identifier field within any of the retrieved records, and none
of the retrieved records is empty, a collision has occurred. In
this event, a collision counter may be incremented at 580 and the
process 500 may return to 515 to await the receipt of another
packet.
[0065] Closing Comments
[0066] Throughout this description, the embodiments and examples
shown should be considered as exemplars, rather than limitations on
the apparatus and procedures disclosed or claimed. Although many of
the examples presented herein involve specific combinations of
method acts or system elements, it should be understood that those
acts and those elements may be combined in other ways to accomplish
the same objectives. With regard to flowcharts, additional and
fewer steps may be taken, and the steps as shown may be combined or
further refined to achieve the methods described herein. Acts,
elements and features discussed only in connection with one
embodiment are not intended to be excluded from a similar role in
other embodiments.
[0067] As used herein, "plurality" means two or more. As used
herein, a "set" of items may include one or more of such items. As
used herein, whether in the written description or the claims, the
terms "comprising", "including", "carrying", "having",
"containing", "involving", and the like are to be understood to be
open-ended, i.e., to mean including but not limited to. Only the
transitional phrases "consisting of and "consisting essentially
of", respectively, are closed or semi-closed transitional phrases
with respect to claims. Use of ordinal terms such as "first",
"second", "third", etc., in the claims to modify a claim element
does not by itself connote any priority, precedence, or order of
one claim element over another or the temporal order in which acts
of a method are performed, but are used merely as labels to
distinguish one claim element having a certain name from another
element having a same name (but for use of the ordinal term) to
distinguish the claim elements. As used herein, "and/or" means that
the listed items are alternatives, but the alternatives also
include any combination of the listed items.
* * * * *