IPFIX aims to ease network-flow reporting

New standard is intended to make things easier

Flow-based technologies, increasingly popular for characterising network traffic, are invaluable to setting QoS policies, deploying applications and engaging in capacity planning. However, network managers have lacked a standard format in which to export traffic flows.

The IETF is standardising flow export under proposed RFC 3917 — IP Flow Information Export (IPFIX). RFC 3917 has been submitted to the IETF for final approval this year. Using Cisco IOS NetFlow Version 9 as its foundation, the IPFIX standard defines unique traffic flows using the following flow keys: source IP address; destination IP address; source port; destination port; Layer 3 protocol type; type-of-service byte and input logical interface.

The combination of keys in each exported-flow record lets reporting applications collect and report on traffic traversing the network. In addition, other flow keys, such as source and destination autonomous system number, TCP flags and next-hop routing addresses, let network managers gain an even deeper understanding of how applications and users are behaving on the network.

The IPFIX standard also focuses on the extensibility of flow export as networks evolve. Network managers will be able to export whichever fields seem appropriate from an IPFIX-compliant device when troubleshooting network issues or engineering their networks for future growth or expansion.

Such extensibility becomes increasingly important as network technologies such as MPLS, IPv6 and multicast routing grow in popularity, and managers need a better understanding of how they affect networked environments.

To ensure easy implementation of such extensibility, IPFIX-compliant devices will export templates itemising those flow keys configured for export. Flow collection and reporting applications can read those templates to understand which keys are exported, so that network managers need not adjust application configurations themselves.

IPFIX is nearing approval just as flow export and reporting adoptions are on the rise. Indeed, the IPFIX RFC defines various applications for flow export that include usage-based accounting, traffic profiling, traffic engineering, attack/intrusion detection and QoS monitoring. For example, flow-reporting applications that support IPFIX can tell how much network traffic consumes each class of service for QoS by reading the type-of-service byte flow key.

In addition, flow-reporting applications can tell how applications and users are classified according to class-of-service policy. Attack/intrusion-detection applications that support IPFIX will be able to provide baseline protocols and address data to pinpoint network anomalies.

IPFIX also describes numerous criteria that are critical to flow export. These include time stamps, time synchronisation, flow expiration, packet fragmentation and multicast flow behaviour. For example, IPFIX-compliant devices that route multicast application traffic should export flow records that reflect each packet entering a device interface. In addition, such devices should export flow records for each packet sent to all outbound interfaces on the same device via multicast.

As with multicast export behaviour, other criteria listed in the RFC mean network-device vendors can better understand support requirements for the IPFIX standard, and how it, potentially, can integrate within their existing technologies.

As the IPFIX standard is more widely adopted by network device vendors, network managers will no longer need to worry about supporting multiple flow-reporting applications, each with its own flow-export format. IPFIX lets them use a single flow-reporting application that complies with the standard.

In addition, IPFIX’s extensibility should prevent managers from having to alter or upgrade device configurations as traffic monitoring or reporting requirements change. The IPFIX standard simplifies flow-export architecture by using a single, coherent model.

Erwin is product manager for NetQOS. He can be reached at ben.erwin@netqos.com

Join the newsletter!

Error: Please check your email address.

Tags reportingNetworking & Telecomms IDipfix

More about CiscoIETF

Show Comments
[]