search:

4   Programmable hardware

This activity emerged as an extension of the original Liberouter project which aims at developing a PC-based IPv6 and IPv4 router. The COMBO6 hardware accelerator, thanks to its modular design and electronic components used, turned out to be useful not only for forwarding and filtering IP datagrams. The SCAMPI project (see chapter) decided already in 2003 to use the COMBO6 platform as a basis for development of a special network monitoring adapter. In 2003 we also started the development of a two-channel optical repeater for Gigabit Ethernet. A new task was added to the above list in 2004 - development of an autonomous network monitoring probe capable of generating data in the NetFlow version 9 format.

The Programmable Hardware activity was established at the beginning of the year 2004 with the primary goal of coordinating the development effort mentioned above, and, at the same time, engage new developers (mainly students) and provide them with all necessary training so that they can be effectively integrated into the team and work on new projects. The number of team members grew to 69 in 2004. The new developers are, for the most part, students of three universities in the Czech Republic (Brno University of Technology, Masaryk University in Brno and Czech Technical University in Prague). We now have altogether 53 students on board. Such an intensive involvement of students certainly has its caveats and risks but it seems to be the only way how to finish all the projects in time. On the other hand, the students benefit greatly from cooperating within a large team and working on real-life problems. Some evidence of this important side effect is seen in the general success of the bachelor, master and doctoral diploma works stemming from the project.

4.1   Organisation and management

Administering and managing such a large team also poses a number of nontrivial challenges. In 2004 we re-organised the team management into a hierarchical structure with seven relatively autonomous workgroups and gave the workgroup leaders significant competences and responsibilities. A new group - System Support - was founded with the intention of integrating important support tasks such as administering the ever-growing pool of servers and workstations, developing our web site, etc. During 2004 we also organised three seminars in order to give the distributed team an opportunity for face-to-face meetings and also to promote mutual cooperation among the workgroups.

4.1.1   VHDL workgroup

The VHDL workgroup deals with firmware design and has 29 active members, 24 of them being students and 11 newcomers. The sheer size of the group and multitude of tasks brought about further structuring of the group into four subgroups (Liberouter, SCAMPI, NetFlow, Testing). Each subgroup has a leader responsible for integration and proper firmware functionality of the given project.

As the group and its subgroups became more autonomous, it became apparent that the previous ad hoc documentation practice was insufficient. We thus designed a new documentation system based on XML which enables us to use the same informations in many different ways, e.g., as a detailed technical documentation or as a summary on project web pages.

Six bachelor theses and a six doctoral theses are under preparation within the VHDL workgroup.

4.1.2   System software workgroup

The system software group has 11 active members, 6 of which are students. Three developers work on various drivers and the others on various modules of system and user-space software. Application programmers of the software group work on integrating the whole system.

Three master theses and a doctoral thesis are under preparation within the software group.

Moreover, three students who are not yet official team members work on related non-essential topics such as graphical representation of nanoprocessor computations. This cooperation usually has a form of a tutoring student's bachelor thesis.

4.1.3   Formal verification workgroup

This workgroup currently consists of eight students. Three of them were hired in 2004 with the goal of applying further verification methods, namely the creation of abstract formal models of programmable hardware components suitable for verifying the temporal properties.

Workgroup members spend most time in communicating with hardware developers. In order to formalise this communication, we created an interface of so-called asserts that allow specifying required properties of VHDL designs directly in the VHDL code (in natural language). The members of the verification team then formalise these asserts by means of temporal logics and translate the VHDL code into the Cadence SMV language in which the formal verification is performed. Verification results are fed back to the VHDL developers via verification reports that are presented on the project web. As an aid to this process, we are developing a suite of scripts named Verunka. It is described in the Technical report [TR05/04].

Two master theses and one PhD. thesis are under preparation within the formal verification workgroup.

4.1.4   Netopeer workgroup

This group develops the Netopeer software system for configuring routers and entire networks. The group had six active members by the end of 2004, five being students. One of the students finished his bachelor thesis already in 2004. Two master theses and one PhD. thesis are under preparation.

4.1.5   BIRD workgroup

This is the newest and smallest workgroup in the project, consisting of only two active members. The main object of their interest is the BIRD routing daemon. In 2004 they ported this software to the NetBSD and FreeBSD operating systems, now are working on extending its functionality.

4.1.6   Testing workgroup

This workgroup develops an independent testing suite by which most hardware, firmware and software development results (including documentation) are scrutinised. For this purpose, the group uses a specialised network tester Spirent AX/4000 and a set of open source programs.

In the previous years, the core of the testing workgroup was formed by students of the Czech Technical University. Most of them left the team in 2004 and so we had to substitute them by new students - three of them from Masaryk University and one from the Czech Technical University.

4.1.7   System support workgroup

This work provides support to the team members in the following areas:

1. Administration of public and private web pages and servers for email, CVS, bug tracking, etc.;
2. Documentation and presentation activities;
3. Management of accounts, access permissions and related personal agenda;
4. Administration of servers and workstations used by project developers.

We introduced a content management system (CMS) on our web server and generally consolidated this important medium. The web pages are now partly generated dynamically from CESNET databases (LDAP, publications). The private part of the web also underwent substantial changes where we launched several administrative applications like the inventory of COMBO cards and their users, allocation of MAC addresses for interface cards, reporting and planning systems, etc. In cooperation with the VHDL workgroup we also created documentation tools for firmware designs based on XML.

We also introduced the Mantis bug tracking system that helps in systematic monitoring and resolving firmware and software bugs and other issues. Through this system, the support workgroup also accepts requests from the team members.

Electronic mailing lists remained essential for team collaboration - we manage nine lists currently. Another crucial tool is the system for distributed software development, CVS.

4.2   The family of COMBO cards

The hardware development of COMBO communication cards continued in 2004 as previously planned. Descriptions and pictures of all cards can be found on the project web. Probably the single most significant achievement is the activation of a two-port 10-Gigabit Ethernet interface card COMBO-2XFP (see Figure).

While this card is primarily intended for the SCAMPI project, it will be used in other projects covered by the activity Programmable Hardware as well.

As the COMBO cards gradually reach the technological leading edge, it becomes increasingly difficult - despite vendors' promises - to get all components with required parameters in time. In the second generation of COMBO cards, which are now being manufactured, we thus attempted to minimise the number of components used by capitalising on the advantages of the new generation of FPGA chips, namely the Rocket IO circuits that are part of VIRTEX II PRO FPGA, or, alternatively, to replace some components like the PCI bus interface by IP core.

The first card of the new generation is the COMBO6X motherboard that is intended as a replacement for the original COMBO6 card. The COMBO6X card benefits from the features of VIRTEX II PRO by introducing serial communication also between circuits on the COMBO6X card and attached interface card. The PLX 9054 PCI controller used on COMBO6 was replaced by the VIRTEX II PRO gate array together with a PCI core implementing the PCI-X bus on 133 MHz. In addition, the VIRTEX II PRO chips also contain embedded PowerPC processors - COMBO6X has three of them. This will allow us to move parts of the algorithms that have been previously handled by the host PC to the COMBO6X card.

Another successor of COMBO6 has also been designed under the name COMBO6E. Its architecture is similar to COMBO6X, but instead of PCI-X it is intended for the new bus standard Express PCI. For this purpose, COMBO6E will use the Rocket IO circuits and a corresponding IP core.

In the process of developing the COMBO-2XFP interface card (2 ports of 10GE) we encountered problems with heat dissipation in the serial/deserial circuits (TLK3114SC and LXT12101) that are moreover difficult to obtain. The new version of the card - COMBO-2XFPRO - is thus based directly on VIRTEX II PRO with Rocket IO-X. An additional advantage of this solution is that it directly supports not only the 10GE standard but also SONET OC-192.

By the end of 2004 we also finalised the hardware design of the COMBO-4SFPRO (4 ports of GE) which is a replacement for the COMBO-4SFP card. Again, serial/deserial circuits will be replaced by Rocket IO. The card will support either the Gigabit Ethernet (with VIRTEX II PRO) or SONET OC-48 (with VIRTEX II PRO-X).

To summarise the status, the COMBO family currently consists of the following cards:

1. COMBO6: Motherboard, in the production phase, to be replaced by COMBO6X and COMBO6E in 2005.
2. COMBO6X: New motherboard for the PCI-X bus, the card is being activated.
3. COMBO6E: New motherboard for the Express PCI, in the stage of PCB design.
4. COMBO-4MTX: Interface card 4×GE with metallic ports, in the production phase.
5. COMBO-4SFP: Interface card 4×GE with SFP transceivers, in the production phase.
6. COMBO-2XFP: Interface card 2×10GE with XFP transceivers, prototype to be replaced by the new card COMBO6-2XFPRO soon.
7. COMBO-4SFPRO: New version of the interface card 4×GE with SFP transceivers, PCB is being manufactured.
8. COMBO-4XFPRO: New version of the interface card 2×10GE with XFP transceivers, PCB is being manufactured.
9. COMBO-PTM: Source of ultra-precise timestamps, developed by the SCAMPI project, in the production phase.
10. COMBO-BOOT: This card can be connected to an interface card instead of the COMBO6 motherboard. This allows for embedded devices (without a host PC). This combination is used in the optical repeater, see section. The card is in the production phase.

4.3   Liberouter project

The Liberouter project, which is also part of the international project 6NET, aims at improving PC/Unix-based routers in the areas where they lag behind their commercial counterparts:

• throughput and packet forwarding/filtering performance,
• configuration interface.

Due to the unsatisfactory status of the two common Unix routing daemons - GateD and Zebra/Quagga, we also decided to contribute to the development of the BIRD daemon, originally a student project at Charles University, Faculty of Mathematics and Physics. In this area we focus on implementing the PIM-SM protocol for multicast routing.

During 2004 we decided to concentrate the efforts of all workgroups on finishing a functional prototype of PC router with better performance than a purely software solution. A demonstration of such a device is being prepared for the review of the 6NET project in February 2005.

An important feature of the Liberouter, apart from supporting the latest IPv6 standards, will also be its open design. By publishing the complete firmware and software documentation we hope to attract other parties (both academic and commercial) outside the original project team to carry on the development.

4.3.1   Firmware

The main task of the Liberouter firmware is fast routing and filtering of IPv6/IPv4 packets using resources on the COMBO6 card. These functions are concentrated to several programmable gate arrays (FPGA) that handle packet reception from an input network interface, process the header data, decide about the appropriate action and, finally, send the packet to an appropriate interface. Firmware architecture that has been described in last year's report remains essentially valid.

In the year 2004, we concentrated on finishing and debugging individual components and integrating them to the whole design. The functions of HFE (Header Field Extractor), LUP (Look-Up Processor) and PQ (Priority Queues) have already been tested in the FPGAs. The remaining components have been checked only by software simulation. We finished the first version of firmware for analysing packet headers and ingress filtering on all four interfaces. Its architecture is shown in Figure.

The depicted components have the following functions:

IBUF (Input Buffer)

checks whether the incoming packet is corrupted (CRC) and temporarily stores the whole packet before passing it to HFE processing.

HFE (Header Field Extractor)

dissects the headers of incoming packets and produces a fixed data structure called unified header (UH).

LUP (Look-Up Processor)

classifies the packets according to the data in UH.

DISP (Dispatcher)

controls further packet processing based on LUP classification. In particular, it can drop the packet or pass it for software processing.

SWOBUF (SW Output Buffer)

maintains buffer space for packets intended for software processing and controls packet transfer via PCI bus.

OBUF (Output Buffer)

controls packet transmission via output interfaces.

Compared to the original firmware design, the current version is simplified in that it does not store the packet payload directly on the COMBO6 card. However, the input part (packet header analysis and packet classification) exactly follows the original architecture already. In order to implement the remaining parts of the firmware architecture, we intend to apply the principles of hardware/software co-design: functions will be gradually added into the existing firmware, while the remaining components are implemented in software.

4.3.2   System software

Software support of COMBO6 card is being developed for the NetBSD and Linux operating systems. Porting to FreeBSD is planned.

Software for COMBO6 can be divided into two basic categories:

1. COMBO6 drivers allow basic communication with the card (firmware upload, handling internal memories and registers, etc.).
2. Support for packet acceleration, the combod daemon.

The driver enables access to the COMBO6 and interface cards. In the operating system environment it is represented as a set of character devices /dev/combo. Tools for initialising cards and firmware upload have also been developed. In order to simplify testing and debugging, we have prepared a set of control utilities hfectl, lupctl, and others. They allow reading and writing registers and memories of nanoprocessors as well as controlling the behaviour of nanoprocessors.

The driver also provides access to COMBO6 network interfaces. The interfaces behave like usual network interfaces and allow configuring by means of usual operating system tools, e.g., ifconfig.

Support for packet forwarding and filtering acceleration is the main task for the combod daemon. It is designed to make the special features of COMBO6 opaque to the operating system. The operating system kernel keeps the information about routing, address resolution (ARP), packet filtering (firewalling), and possibly also tcpdump setting in a set of tables and other kernel structures. COMBO6 should forward and filter packets in exactly the same way as the operating kernel would, only faster.

LUP, the lookup processor implemented in COMBO6 hardware, uses a special data structure for packet classification. It exploits content addressable memory combined with lookup instructions stored in static memory. The task of the combod is to keep the structure synchronised with the operating system tables.

Currently, a feature-limited version of the design is available. It behaves as a network adapter with hardware ingress filtering on source and destination ports and addresses. Extending filtering possibilities is an open research problem. The most promising approach for lookup structure compilation is to distribute the packet filter setting to relevant parts of the routing table.

4.3.3   Formal verification

We have verified VHDL programs for the packet edit engine, concentrating on the communication of this module with the DRAM scheduler. Modules UH_FIFO and ASYNCHRONOUS FIFO have also been tested. The results are available from the verification reports at the formal verification section of the project web.

The key contribution to the development of verification technologies was the verification of the asynchronous queue where the problem of formalising VHDL design with multiple clocks was solved. The problem and its solution is described in the Technical report [TR04/04].

4.3.4   Netopeer configuration system

The Netopeer software system deals with configurations of IPv6 and IPv4 routers and entire networks. Its basic setup is shown in Figure: Configurations are created on the manager station which stores them as XML documents in the configuration repository and also - if instructed to do so - converts them into the native configuration language of the target router and installs them there.

For the most part, the Netopeer system is a set of programs running on the manager station. The overall architecture is shown in Figure. Its upper half contains front-ends that realise the user interface, transform user input into an XML document, and store it in the repository. For translation into the language of the target router, front-ends use an appropriate back-end which is available to them as a library function.

In 2004, our focus was to finish a functional prototype suitable for configuring PC routers in production networks. To this end, it was necessary to improve especially the command line interface (CLI) that is considered the primary configuration tool, and also the Unix back-end for translating configurations from XML to Linux and BSD scripts and configuration files and installing them in the PC router.

Substantially changed was also the XML scheme defining the data contents of XML configurations. First, we migrated to another language for XML schema description - RELAX NG. Compared to the previously used DTD language, RELAX NG allowed including a significantly larger extent of syntactic and semantic constraints directly in the XML schema. The RELAX NG scheme currently represents configuration of network interfaces (including tunnels and VLANs), basic system configuration (DNS, NTP, etc.), packet and route filters, static routing and three major routing protocols (RIP, OSPF and BGP).

The CLI front-end is now in the beta stage and essentially usable. Its syntax is derived directly from the XML scheme. This is very useful since every change to the XML scheme is immediately reflected in the CLI, but in some cases it makes the CLI syntax rather clumsy. We thus plan to adjust the scheme and also intersperse hints for front-ends throughout the scheme (in a special XML name space). These hints will help the front-ends in mapping the XML structure into an easy-to-use CLI syntax.

The web front-end was changed in a similar way: now it generates its HTML forms dynamically from the scheme and this has similar pros and cons as in the case of CLI. The system of hints in the scheme should help in this case, too. The architecture of the web front-end is described in the Technical report [TR06/04].

The Unix back-end currently allows configuring PC routers running Linux and the Zebra routing daemon. This platform can thus be configured via the command line interface.

An interesting addition to the system is the Netconf module based on the Netconf protocol that is being developed in IETF [Enn04]. This protocol is also based on XML and so fits very well into the Netopeer architecture. The implementation of the Netconf over the BEEP transport protocol was the topic of a master thesis finished in January 2005.

A considerable progress also marked the development of the metaconfiguration application which enables configuring entire networks based on higher level information. This application will automatically generate low-level configurations of individual routers in the Netopeer XML. We created a special scheme (also in RELAX NG) covering all fundamental areas (addressing, routing and filtration) and also designed a graphical user interface. The results are described in the Technical report [TR27/04].

4.3.5   BIRD routing daemon

The BIRD routing daemon is the highest software layer represented in the Liberouter project. Its main task is to set up routing tables for unicast and multicast routing (IPv4 and IPv6), based on information exchanged with neighbouring routers by means of routing protocols. The dynamically generated routing tables are passed to lower layers of the operating system kernel and through it also to the COMBO6 card.

Our contribution so far was the port of BIRD to the NetBSD and FreeBSD operating systems (the original version runs on Linux). The unicast forwarding kernel is complete and debugged as well as the implementations of the BGP, RIP and OSPF routing protocols. The development of the multicast kernel is finished and implementations of DVMRP and PIM-SM are under development. We are also working on implementing a module for network interface configuration.

4.4   SCAMPI monitoring adaptor

The SCAMPI network monitoring adaptor is also based on the COMBO family of cards and benefits from their modularity, which allows several combinations of a motherboard (COMBO6, later COMBO6X or COMBO6E) with an interface card (COMBO-4MTX, COMBO-4SFP, COMBO-2XFP, COMBO-2XFPRO, COMBO-4SFPRO). The only card that was specially developed for the SCAMPI project is COMBO-PTM, the source of precise time stamps. SCAMPI adapters are thus currently available in three variants:

1. SCAMPI-4MTX: COMBO6, COMBO-4MTX, COMBO-PTM
2. SCAMPI-4SFP: COMBO6, COMBO-4SFP, COMBO-PTM
3. SCAMPI-2XFP: COMBO6, COMBO-2XFP, COMBO-PTM

Additional variants will be tested as soon as new versions of motherboard (COMBO6X and COMBO6E) and interface cards become available.

4.4.1   Firmware

The basic roles of firmware in the SCAMPI project are: handling packet reception from input interface, assigning a precise timestamp for each packet, and performing packet analysis and classification. According to the classification result, it is possible to collect statistical information, perform packet filtration and sampling and detect specific patterns in the payload of selected packets.

Up to 256 different statistics on length and intervals between packets are supported. The current design contains 16 sampling units that can be configured in three sampling modes:

• Deterministic sampling - every n-th packet is passed to the unit.
• Random sampling - packets are passed to the unit with a specified probability.
• Byte-oriented deterministic sampling - the packet that contains every n-th byte is passed through the unit.

The firmware is able to detect up to 512 different patterns at a 3.2 Gbps rate. The maximum rate is determined by the speed of TCAM memory.

The design also contains firmware for the COMBO-PTM card which controls the generation of precise timestamps and their transfer to the COMBO6 card.

Firmware development was divided into two phases. The first one covers the implementation of a monitoring adapter for data rates up to 1 Gbps. The firmware architecture is shown in Figure.

The depicted components have the following functions:

IBUF (Input Buffer)

checks whether the incoming packet is corrupted (CRC) and temporarily stores the whole packet before passing it to HFE processing.

HFE (Header Field Extractor)

works almost exactly the same as in the Liberouter design - reads packets data from the input buffer, dissects its headers and produces the unified header.

LUP (Look-Up Processor)

performs packet classification based on information in the unified header.

FIFO (Packet FIFO)

temporarily stores the packets (implementation of a delay line).

STU (Statistical Unit)

collects statistic information.

SAU (Sampling Unit)

performs packet sampling.

DISP (Dispatcher)

controls further packet processing based on LUP classification. In particular, it can drop the packet or pass it for software processing.

SWOBUF (SW Output Buffer)

maintains buffer space for packets intended for software processing and controls packet transfer via PCI bus.

The second development phase now focuses on data rates up to 10 Gbps. As the throughput is much higher, the design for the second phase differs in several ways from the design described above. In particular, IBUF and DISP units are completely different. Several components (HFE, FIFO) have been replicated and the whole design has been partitioned between the COMBO6 and the interface card. The architecture of monitoring adapter for 10 Gbps is shown in the Figure.

4.4.2   System software

System software for the SCAMPI project consists of COMBO6 drivers and a library to transform packet filtering rules into a form that is acceptable for the hardware.

Drivers provide low-level access to the COMBO6 internal registers, memories, and counters. Large parts of the driver have been adopted from the Liberouter project, the only SCAMPI-specific driver modules are those for the statistical (STU) and sampling (SAU) units.

Requirements for packet capturing functions are defined by MAPI (Monitoring API). MAPI uses the Scampidump library to upload the filter to the card. Scampidump accepts rules expressed in a language which is a subset of standard BPF (Berkeley Packet Filter) syntax. The rules are analysed, compiled into the form of a nanoprogram for LUP, and uploaded to the COMBO6 card.

Currently, only a single rule can be used. A version of Scampidump supporting more rules is under development and the compilation techniques are under extensive study. Handling the overlapping rules has to be solved. The approach we are testing is based on representing the rule sets as SB+ trees and partitioning them into non-overlapping segments.

4.4.3   Formal verification

The following modules have been verified in the SCAMPI firmware design: DISP, FIFO, STU, and SAU. Formal verification of the FIFO module discovered a deviation from the specification. This result will lead us to correcting the specification - it turns out that the implementation is valid under additional assumption that is fulfilled in all practical cases.

While discussing detailed requirements for the abstract model of the SCAMPI design, we also identified parts of the design that are problematic from the viewpoint of time constraints. The cooperation of the verification workgroup with VHDL developers can thus be very useful even in the design phase.

4.5   Optical repeater

The two-channel optical repeater was designed as a simple application that employs the COMBO-4SFP interface card. In 2004 we completed its development by adjusting it for the 2U rack-mount chassis.

The repeater can also be deployed as an embedded system thanks to the COMBO-BOOT card. Apart from providing power supplies, this card also handles device booting and uploading the firmware to the interface card.

4.5.1   Firmware

The firmware is relatively simple. It is placed in the FPGA on the COMBO-4SFP interface card and consists of two processes that copy incoming octets from one port to another. This firmware will also be ported to the COMBO-2XFPRO card as soon as it is finished.

4.5.2   System software

Control software for the COMBO-BOOT card is written in the C language. We created a simple monitor program that communicates with the controlling workstation via the serial RS-232C interface and implements the basic functions such as uploading the firmware to the interface card and monitoring power supplies.

4.6   NetFlow probe

In 2004, CESNET became a partner of the GN2 international project. One of the significant contributions of CESNET to this project within the JRA2 activity (Security) will be the development of hardware devices for network traffic analysis. The task for the first two years of the project is an autonomous probe generating NetFlow version 9 data which will again be based on the COMBO cards. As opposed to standard router-based NetFlow implementations, this probe will operate as a Y-splitter - inserted in a data circuit, the probe will carry pristine data traffic in one branch while at the same time copying the data to the other branch for analysis.

Version 9 of the NetFlow protocol allows for defining data contents of its records by means of so-called templates. We intend to utilise the flexibility of the FPGA technology, enabling to change the templates and data contents on the fly. Such a function is not available for common NetFlow implementations since the templates are hardwired in their ASIC circuits. We spent a good deal of the second half of 2004 discussing the architecture of this NetFlow probe. The initial design was reviewed by other GN2 partners and the result is recorded in the following CESNET Technical reports: [TR08/04], [TR14/04], and [TR15/04].

4.6.1   Draft hardware architecture

The initial NetFlow probe architecture is constrained by the features of the COMBO cards. The device has to use the existing card resources for maintaining as many NetFlow records as possible. In this phase, the target performance is set at 1 Gbps. Security also has to be seriously considered, e.g., information about data flows must not get corrupted, be it accidentally or as a result of an attack.

The NetFlow probe will analyse incoming packets, select important information and collect it into a NetFlow protocol header. This header then serves as input for the 19-bit and 45-bit hash functions that compute an address where the flow data should be added (if it is a new flow) or where the existing data should be updated. SSRAM memory is the best candidate for storing NetFlow records on COMBO cards. The Figure shows memory organisation utilising SSRAM memory for a maximum number of records.

The first static memory performs matching by using a 19-bit hash function. This memory stores just a pointer to a corresponding NetFlow record and a 45-bit value of the hash function. The latter is used for reducing the probability of flow collisions while at the same time keeping the advantage of a constant-time search. The collision occurs when two different flows are mapped onto the same record. The probability of collision increases as the memory fills up. Therefore, the memory has to be filled relatively sparsely. It is also crucial to save as many memory resources as possible and so the NetFlow records will be stored in separate memory banks.

The architecture of the NetFlow probe is shown in Figure. Each packet is received from the input interface to the input buffer (IBUF) where a timestamp from TSU is added. The packet then continues to the header field extractor (HFE) which analyses its header, collects important information and writes it into the NetFlow record. The hash block (HASH) uses this record for computing the 19-bit and 45-bit hash functions used by the hash search component (HSRCH) for fast NetFlow record matching. The matched record is then updated by the storage controller (SCTRL) component. If the flow is identified as new by HSRCH, a new record is added. The communication between HSRCH and SCTRL is controlled by the manager unit (MAN) which takes care about adding and releasing records.

Active flows listed in a linear list are sorted by the timestamp of last update. Inactive flows are released by removing items from the beginning of the list according to the current time. Free records are also kept in a linear list whose items are reused when a new record is added. For capacity reasons, both lists are stored in the SSRAM memory.

previous

contents

next