IP Flow Information Export WG G. Sadasivan
(ipfix) Cisco Systems, Inc.
Internet-Draft N. Brownlee
Expires: April 9, 2005 CAIDA | The University of Auckland
B. Claise
Cisco Systems, Inc.
J. Quittek
NEC Europe Ltd.
October 9, 2004
Architecture for IP Flow Information Export
draft-ietf-ipfix-architecture-04
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 9, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This memo defines the IPFIX architecture for the selective monitoring
of IP flows, and for the export of measured IP flow information from
Sadasivan, et al. Expires April 9, 2005 [Page 1]
Internet-Draft IPFIX Architecture October 2004
an IPFIX device to a collector, as per the requirements set out in
the IPFIX requirements document.
Table of Contents
1. Architecture Issues . . . . . . . . . . . . . . . . . . . . 4
2. Changes/Issues from the -03 Draft . . . . . . . . . . . . . 5
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Examples of Flows . . . . . . . . . . . . . . . . . . . . . 10
7. IPFIX Reference Model . . . . . . . . . . . . . . . . . . . 12
8. IPFIX Functional and Logical Blocks . . . . . . . . . . . . 13
8.1 Metering Process . . . . . . . . . . . . . . . . . . . . . 13
8.1.1 Flow Expiration and Export . . . . . . . . . . . . . . 14
8.2 Observation Point . . . . . . . . . . . . . . . . . . . . 15
8.3 Selection Criteria for Packets . . . . . . . . . . . . . . 15
8.3.1 Filter Functions, Fi . . . . . . . . . . . . . . . . . 15
8.3.2 Sampling Functions, Si . . . . . . . . . . . . . . . . 16
8.4 Observation Domain . . . . . . . . . . . . . . . . . . . . 16
8.5 Exporting Process . . . . . . . . . . . . . . . . . . . . 16
8.6 Collecting Process . . . . . . . . . . . . . . . . . . . . 17
8.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 17
9. Overview of the IPFIX Protocol . . . . . . . . . . . . . . . 19
9.1 Information Model Overview . . . . . . . . . . . . . . . . 19
9.2 Flow records . . . . . . . . . . . . . . . . . . . . . . . 20
9.3 Control Information . . . . . . . . . . . . . . . . . . . 20
9.4 Exporting Control Information . . . . . . . . . . . . . . 20
9.5 Reporting Responsibilities . . . . . . . . . . . . . . . . 21
10. IPFIX Protocol Details . . . . . . . . . . . . . . . . . . . 21
10.1 The IPFIX Basis Protocol . . . . . . . . . . . . . . . . 21
10.2 IPFIX Protocol on the Collecting Process . . . . . . . . 22
10.3 Support for Applications . . . . . . . . . . . . . . . . 22
11. Export Models . . . . . . . . . . . . . . . . . . . . . . . 23
11.1 Export with Reliable Control Connection . . . . . . . . 23
11.2 Collector Failure Detection and Recovery . . . . . . . . 23
11.3 Collector Redundancy . . . . . . . . . . . . . . . . . . 24
12. IPFIX Flow Collection for Special Traffic . . . . . . . . . 24
13. IPFIX Flow Collection from Special Devices . . . . . . . . . 25
14. Security Considerations . . . . . . . . . . . . . . . . . . 25
14.1 Data Security . . . . . . . . . . . . . . . . . . . . . 25
14.1.1 No Security . . . . . . . . . . . . . . . . . . . . 26
14.1.2 Authentication-only . . . . . . . . . . . . . . . . 26
14.1.3 Encryption . . . . . . . . . . . . . . . . . . . . . 26
14.2 IPFIX End-point Authentication . . . . . . . . . . . . . 27
15. IPFIX Overload . . . . . . . . . . . . . . . . . . . . . . . 27
15.1 Denial of Service (DoS) Attack Prevention . . . . . . . 27
15.1.1 Network Under Attack . . . . . . . . . . . . . . . . 27
Sadasivan, et al. Expires April 9, 2005 [Page 2]
Internet-Draft IPFIX Architecture October 2004
15.1.2 Generic DoS Attack on the IPFIX System . . . . . . . 28
15.1.3 IPFIX Specific DoS Attack . . . . . . . . . . . . . 28
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . 28
16.1 Numbers used in the Protocol . . . . . . . . . . . . . . 28
16.2 Numbers used in the Information Model . . . . . . . . . 29
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . 32
Sadasivan, et al. Expires April 9, 2005 [Page 3]
Internet-Draft IPFIX Architecture October 2004
1. Architecture Issues
ARCH-01:
Reduce confusion between 'information element' and 'field:' use
'field' when it referring to an element's field within a packet,
use 'information element' everywhere else. (DONE)
ARCH-02:
Add 'Exporter' to terminology section (then we'll have Exporter,
Collector, Device. (DONE)
ARCH-03:
Not clear how Options Template and Options Data should be used.
Add text to explain that
* data templates specify flow records,
* option templates specify options data records, and
* options data fields hold information which does not refer to
specific flows, e.g. config data or statistics.
ARCH-04:
Make sure Terminology definitions are consistent with protocol
(and requirements) drafts. (DONE)
ARCH-05:
Change IP addresses in 'Flows' examples to use "documentation
prefixes," as per RFC 3330. (DONE, using 198.18/15, network
interconnect testing)
ARCH-06:
Flow aggregates. Remove text, remove Flow Recording Process from
'reference model' diagram. (DONE)
ARCH-07:
There is no `Collecting Process' section. Add one to section 7.5,
using relevant text from sections 7.1 and 9.2. (DONE)
Sadasivan, et al. Expires April 9, 2005 [Page 4]
Internet-Draft IPFIX Architecture October 2004
ARCH-08:
There is no Information Model Overview section. Add one.
* Info Model defines fields for flow records and option data
records
* Protocol document describes how fields are encoded in IPFIX
messages
* Other systems - e.g. PSAMP - may add data or options fields;
need to decide on ranges of element ids for each protocol.
(DONE)
ARCH-09:
IPFIX System Overview section needs rewriting. (DONE)
ARCH-10:
No mention of transport protocols. Need to say "IPFIX designed to
be independent of transport, see protocol document for
advantages/costs of various protocols." (DONE)
ARCH-11:
Need text for IANA Considerations section. Nevil and Benoit
agreed to write some, including ranges for IPFIX, PSAMP, etc.
Suggest the IPFIX chairs and document editors review requests for
new field ID numbers. (DONE)
ARCH-12:
Security Considerations. Can anyone offer more/better text for
this section?
2. Changes/Issues from the -03 Draft
MUST vs must:
Since this will be an informational RFC, we now use
must/may/should instead of MUST/MAY/SHOULD.
Sadasivan, et al. Expires April 9, 2005 [Page 5]
Internet-Draft IPFIX Architecture October 2004
Capitals for IPFIX terms:
Text changed so that these terms use lower-case before the
'terminology' section, where they're defined. After that we
always upper-case their first letters.
Small editorial changes:
Lots of these to fix typos, reorder sections to improve document
structure, etc.
3. Introduction
There are several applications e.g., usage-based accounting, traffic
profiling, traffic engineering, attack/intrusion detection, QoS
monitoring, that require flow-based IP traffic measurements. It is
therefore important to have a standard way of exporting information
related to IP flows. This document defines an architecture for IP
traffic flow monitoring, measuring and exporting. It provides a
high-level description of an IPFIX device's key components and their
functions.
4. Scope
This document defines the architecture for IPFIX. Its main
objectives are to:
o Describe the key architectural components of IPFIX systems,
consisting of (at least) IPFIX exporters and collectors
communicating using the IPFIX protocol.
o Define the architectural requirements, e.g., recovery, security,
etc., for an IPFIX system.
o Describe the characteristics of the IPFIX (flow export) protocol.
Note that the IPFIX system does not provide for remote configuration
of an IPFIX device. Instead, IPFIX devices are configured by network
operations staff.
5. Terminology
The definitions of basic IPFIX terms such as IP Traffic Flow,
Exporting Process, Collecting Process, Observation Point, etc. are
semantically identical with those found in the IPFIX requirements
document IPFIX-REQS [1]. Some of the terms have been expanded for
Sadasivan, et al. Expires April 9, 2005 [Page 6]
Internet-Draft IPFIX Architecture October 2004
more clarity when defining the protocol. Additional terms required
for the architecture have also been defined. For the same terms
defined here and in IPFIX-PROTO [4] the definitions are equivalent in
both documents.
* Observation Point
An Observation Point is a location in the network where IP packets
can be observed. Examples include: a line to which a probe is
attached, a shared medium, such as an Ethernet-based LAN, a single
port of a router, or a set of interfaces (physical or logical) of
a router.
Note that one Observation Point may be a superset of several other
Observation Points. For example one Observation Point can be an
entire line card. That would be the superset of the individual
Observation Points at the line card's interfaces.
* Observation Domain
The set of Observation Points which is the largest aggregatable
set of Flow information at the Metering Process is termed an
Observation Domain. Each Observation Domain presents itself using
a unique ID to the Collecting Process to identify the IPFIX
Messages it generates. For example, a router line card may be
composed of several interfaces with each interface being an
Observation Point. Every Observation Point is associated with an
Observation Domain.
* IP Traffic Flow or Flow
There are several definitions of the term 'flow' being used by the
Internet community. Within the context of IPFIX we use the
following definition:
A Flow is defined as a set of IP packets passing an Observation
Point in the network during a certain time interval. All packets
belonging to a particular Flow have a set of common properties.
Each property is defined as the result of applying a function to
the values of:
1. One or more packet header field (e.g. destination IP
address), transport header field (e.g. destination port
number), or application header field (e.g. RTP header fields
[RFC1889])
2. One or more characteristics of the packet itself (e.g. number
of MPLS labels)
Sadasivan, et al. Expires April 9, 2005 [Page 7]
Internet-Draft IPFIX Architecture October 2004
3. One or more fields derived from packet treatment (e.g. next
hop IP address, output interface)
A packet is said to belong to a Flow if it completely satisfies
all the defined properties of the Flow.
This definition covers the range from a Flow containing all
packets observed at a network interface to a Flow consisting of
just a single packet between two applications with a specific
sequence number.
* Flow Key
Each of the fields which
1. Belong to the packet header (e.g. destination IP address)
2. Are a property of the packet itself (e.g. packet length)
3. Are derived from packet treatment (e.g. AS number)
and which are used to define a Flow are termed Flow Keys.
* Flow Record
A Flow Record contains information about a specific Flow that was
observed at an Observation Point. A Flow Record contains measured
properties of the Flow (e.g. the total number of bytes for all
the Flow's packets) and usually characteristic properties of the
Flow (e.g. source IP address).
* Metering Process
A Metering Process generates Flow Records. Input to the process
are packet headers observed at an Observation Point, and packet
treatment at the Observation Point.
The Metering Process consists of a set of functions that includes
packet header capturing, timestamping, sampling, classifying, and
maintaining Flow Records.
The maintenance of Flow Records may include creating new records,
updating existing ones, computing Flow statistics, deriving
further Flow properties, detecting Flow expiration, passing Flow
Records to the Exporting Process, and deleting Flow Records.
Sadasivan, et al. Expires April 9, 2005 [Page 8]
Internet-Draft IPFIX Architecture October 2004
* Exporting Process
An Exporting Process sends Flow Records to one or more Collecting
Processes. The Flow Records are generated by one or more Metering
Processes.
* Exporter
A device which hosts one or more Exporting Processes is termed an
Exporter.
* IPFIX Device
An IPFIX Device hosts at least one Observation Point, a Metering
Process and an Exporting Process. Typically, corresponding
Observation Point(s), Metering Process(es) and Exporting
Process(es) are co-located at such a device, for example at a
router.
* Collecting Process
A Collecting Process receives Flow Records from one or more
Exporting Processes. The Collecting Process might process or
store received Flow Records, but such actions are out of scope for
this document.
* Collector
A device which hosts one or more Collecting Processes is termed a
Collector.
* Template
A Template is an ordered sequence of <type, length> pairs, used to
completely identify the structure and semantics of a particular
set of information that needs to be communicated from an IPFIX
Device to a Collector. Each Template is uniquely identifiable by
means of a Template ID.
* Control Information, Data Stream
The information that needs to be exported from the IPFIX Device
can be classified into the following categories:
Control Information
Sadasivan, et al. Expires April 9, 2005 [Page 9]
Internet-Draft IPFIX Architecture October 2004
This includes the Flow definition, selection criteria for
packets within the Flow sent by the Exporting Process, and any
IPFIX protocol messages. The Control Information carries all
the information needed for the end-points to understand the
IPFIX protocol, and specifically for the receiver (Collector)
to understand and interpret the data sent by the sender
(Exporter).
Data Stream
This includes Flow Records carrying the field values for the
various observed Flows at each of the Observation Points.
IPFIX Message
An IPFIX Message is a message originating at the Exporting
Process that carries the IPFIX records of this Exporting
Process and whose destination is a Collecting Process. An
IPFIX Message is encapsulated within a transport layer header.
6. Examples of Flows
Some examples of Flows are listed below:
Example 1: To create Flows, the different fields to distinguish Flows
are defined. The different combination of the field values creates
unique Flows. If the Flow Key is defined as {source IP address,
destination IP address, DSCP}, then all of these are different Flows.
1. {198.18.40.1, 198.18.23.5, 4}
2. {198.18.40.23, 198.18.23.67, 4}
3. {198.18.40.23, 198.18.23.67, 2}
4. {198.18.20.200, 198.18.23.67, 4}
Example 2: To create Flows, a match function can be applied to all
the packets that pass through an Observation Point, in order to
aggregate some values. This could be done by defining the Flow Key
as {source IP address, destination IP address, DSCP} as in example 1
above, and applying a function which masks out the least significant
8 bits of the source IP address and destination IP address (i.e. the
result is a /24 address). The four Flows from example 1 would now be
aggregated into three Flows by merging the Flows 1 and 2 into a
single Flow.
1. {198.18.40.0/24, 198.18.23.0/24, 4}
2. {198.18.40.0/24, 198.18.23.0/24, 2}
3. {198.18.20.0/24, 198.18.23.0/24, 4}
Sadasivan, et al. Expires April 9, 2005 [Page 10]
Internet-Draft IPFIX Architecture October 2004
Example 3: To create Flows, a filter defined by some field values can
be applied on all packets that pass the Observation Point, in order
to select only certain Flows. The filter is defined by choosing
fixed values for specific fields from the packet.
All the packets that go from a customer network 198.18.40.0/24 to
another customer network 198.18.23.0/24 with DSCP value of 4 define a
Flow. All other combinations don't define a Flow and are not taken
into account. The three Flows from example 2 would now be reduced to
one Flow by filtering away the second and the third Flow, leaving
only {198.18.40.0/24, 198.18.23.0/24, 4}.
The above example can be thought of as a function F() taking as input
{source IP address, destination IP address, DSCP}. The function
selects only the packets which satisfy all three of the following
conditions:
1. Mask out the least significant 8 bits of source IP address, match
against 198.18.40.0.
2. Mask out the least significant 8 bits of destination IP address,
match against 198.18.23.0.
3. Only accept DSCP value equal to 4.
Depending on the values of {source IP address, destination IP
address, DSCP} of the different observed packets, the Metering
Process function F() would choose/filter/aggregate different sets of
packets, which would create different Flows. For example, various
combination of values of {source IP address, destination IP address,
DSCP}, F(source IP address, destination IP address, DSCP) would
result in the definition of one or more Flows.
Sadasivan, et al. Expires April 9, 2005 [Page 11]
Internet-Draft IPFIX Architecture October 2004
7. IPFIX Reference Model
The figure below shows the reference model for IPFIX. This figure
covers the various possible scenarios that can exist in an IPFIX
system.
+----------------+ +----------------+
|[*Application 1]| ..|[*Application n]|
+--------+-------+ +-------+--------+
^ ^
~ ~
+~~~~~~~~~~+~~~~~~~~+
^
~
+------------------------+ +-------+------------------+
|IPFIX Device(1) | | Collector(1) |
|[Exporting Process(es)] |<----------->| [Collecting Process(es)] |
+------------------------+ +--------------------------+
.... ....
+------------------------+ +---------------------------+
|IPFIX Device(i) | | Collector(j) |
|[Obsv Point(s)] |<---------->| [Collecting Process(es)] |
|[Metering Process(es)] | +---->| [*Application(s)] |
|[Exporting Process(es)] | | +---------------------------+
+------------------------+ .
.... . ....
+------------------------+ | +--------------------------+
|IPFIX Device(m) | | | Collector(n) |
|[Obsv Point(s)] |<-----+---->| [Collecting Process(es)] |
|[Metering Process(es)] | | [*Application(s)] |
|[Exporting Process(es)] | +--------------------------+
+------------------------+
The various functional components are indicated within brackets [].
The functional components within [*] are not part of the IPFIX
framework. The interfaces shown by "<-->" are defined by the IPFIX
framework but those shown by "<~~>" are not.
The figure below shows a typical IPFIX Device.
+--------------------------------------------------+
| IPFIX Device |
| +-----+ |
| +---......--+------------+---------> | |
| | | | | |
| +----+----+ +----+----+ | | |
| |Metering | |Metering | | E | |
| |Process 1| |Process N| | x | |
Sadasivan, et al. Expires April 9, 2005 [Page 12]
Internet-Draft IPFIX Architecture October 2004
| |(Packet | |(Packet | | p | |
| | Level) | | Level) | | o | |
| +---------+ +---------+ | r | |
| ^ ^ | t | |
|+-------+-----------------------+-------+ | i | |
|| | Observation Domain 1 | | | n | |
|| +-----+------+ +-----+------+| | g | |
|| |Obsv Point 1| ... |Obsv Point M|| | | |
|| +------------+ +------------+| | | |
Packets|+-------^-------------------------^-----+ | | | Export
--->---+--------+----------.....----------+ | | | Pkts to
In | | +------->
| . . . . . | | |Collector
| | | |
| +---......--+------------+---------> | |
| | | | | |
| +----+----+ +----+----+ | P | |
| |Metering | |Metering | | r | |
| |Process 1| |Process N| | o | |
| +---------+ +---------+ | c | |
| ^ ^ | e | |
|+-------+-----------------------+-------+ | s | |
|| | Observation Domain K | | | s | |
|| +-----+------+ +-----+------+| | | |
|| |Obsv Point 1| ... |Obsv Point M|| | | |
|| +------------+ +------------+| | | |
Packets|+-------^-------------------------^-----+ +-----+ |
--->---+--------+---------- ... ----------+ |
In | |
+--------------------------------------------------+
In the above figure the IPFIX components are shown in rectangular
boxes. Note that in case of multiple Observation Domains, a unique
ID per Observation Domain must be transmitted as a parameter to the
exporting function. That unique ID is referred to as the IPFIX
Soutrce ID. The Exporting Process includes IPFIX protocol and
underlying transport layer.
8. IPFIX Functional and Logical Blocks
8.1 Metering Process
Every Observation Point in an IPFIX Device, participating in Flow
measurements, must be associated with at least one Metering Process.
Every packet coming into an Observation Point goes into each of the
Metering Processes associated with the Observation Point. Broadly,
each Metering Process extracts the packet headers that come into an
Sadasivan, et al. Expires April 9, 2005 [Page 13]
Internet-Draft IPFIX Architecture October 2004
Observation Point, does timestamping and classifies the packet into
Flow(s) based on the selection criteria.
The Metering Process is a functional block which manages all the
Flows generated from an Observation Domain. The typical functions of
a Metering Process may include:
o Maintain database(s) of all the Flows Records from an Observation
Domain. This includes creating new Flow Records, updating
existing ones, computing Flow Records statistics, deriving further
Flow properties, adding non-flow-specific information based on the
packet treatment (in some cases fields like AS numbers, router
state, etc.)
o Maintain aggregate statistics like flows generated, flows exported
etc.
8.1.1 Flow Expiration and Export
A Flow is considered to have expired, and may be exported, under the
following conditions:
1. If the Metering Process can deduce the end of a Flow, that Flow
should be exported when the end of the Flow is detected. For
example, a Flow generated by TCP traffic where the FIN or RST
bits indicate the end of the Flow.
2. If no packets belonging to the Flow have been observed for a
certain period of time. This time period should be configurable
at the Metering Process, with a minimum value of 0 seconds for
immediate expiration. Note that a zero timeout would report a
Flow as a sequence of single-packet Flows.
3. If the IPFIX Device experiences resource constraints, a Flow may
be prematurely expired (e.g. lack of memory to store Flow
Records)
4. For long-running Flows, the Exporting Process should export the
Flow Records on a regular basis or based on some export policy.
This periodicity or export policy should be configurable at the
Metering Process.
When a long-running Flow is exported, that Flow may still be
maintained by the Metering Process so that, for incoming packets
which continue to come on the same Flow, the Metering Process does
not need to create a new Flow.
Sadasivan, et al. Expires April 9, 2005 [Page 14]
Internet-Draft IPFIX Architecture October 2004
8.2 Observation Point
A Flow Record can be better analyzed if the Observation Point from
which it was measured is known. As such it is recommended that
Exporters send this information to Collectors. In cases where there
is a single Observation Point or where the Observation Point
information is not relevant, the Metering Process may choose not to
add this to the Flow Records.
8.3 Selection Criteria for Packets
A Metering Process may define rules so that only certain packets
within an incoming stream of packets are chosen for measurement at an
Observation Point. This may be done by one of the two methods
defined below or a combination of them. A combination of each of
these methods can be adopted to select the packets, i.e. one can
define a set of methods {F1, S1, F2, S2, S3} executed in a specified
sequence at an Observation Point to select particular Flows.
The figure below shows the operations which may be applied as part of
a typical Metering Process.
packet header capturing
|
timestamping
|
v
+----->+
| |
| sampling Si (1:1 in case of no sampling)
| |
| filtering Fi (select all when no criteria)
| |
+------+
|
v
Flows
8.3.1 Filter Functions, Fi
A Filter Function selects only those incoming packets that satisfy a
function on fields defined by the packet header fields, fields
obtained while doing the packet processing, or properties of the
packet itself.
Example: Mask/Match of the fields that define a filter. A filter
might be defined as {Protocol == TCP, Destination Port between 80 and
Sadasivan, et al. Expires April 9, 2005 [Page 15]
Internet-Draft IPFIX Architecture October 2004
120}.
Several such filters could be used in any sequence to select packets.
Note that packets selected by a (sequence of) filter functions may be
further classified by other filter functions, i.e. the selected
packets may belong to several Flows, all of which are exported.
8.3.2 Sampling Functions, Si
A sampling function determines which packets within a stream of
incoming packets is selected for measurement, i.e. packets that
satisfy the sampling criteria for this Metering Process.
Example: sample every 100th packet that was received at an
Observation Point and collect the Flow Records selected by a
particular filter function. Choosing all the packets is a special
case where the sampling rate is 1:1.
Note that filtering and sampling functions may also be used in an
Exporting Process to select Flow Records to be exported.
8.4 Observation Domain
The Observation Domain is a logical block that presents a single
identity for a group of Observation Points within an IPFIX Device.
Each {Observation Point, Metering Process} pair belongs to a single
Observation Domain. An IPFIX Device could have multiple Observation
Domains each of which has a subset of the total set of Observation
Points in it. Each Observation Domain must carry a unique ID within
the context of an IPFIX Device.
8.5 Exporting Process
The Exporting Process is the functional block that sends data to one
or more IPFIX Collectors using the IPFIX protocol. On one side it
interfaces with Metering Process to get Flow Records, while on the
other side the Exporting Process talks to a Collecting Process on the
Collector(s).
There may be additional rules defined within the context Observation
Domain so that only certain Flows Records are picked up for export.
This may be done by either one or a combination of Si, Fi, as
described in the section on "Selection Criteria for Packets".
Example: Only the Flow Records which meet the following selection
criteria are exported.
1. All Flow Records whose destination IP address matches
Sadasivan, et al. Expires April 9, 2005 [Page 16]
Internet-Draft IPFIX Architecture October 2004
{198.18.33.5}.
2. Every other (.i.e. sampling rate 1 in 2) Flow Record whose
destination IP address matches {198.18.11.30}.
8.6 Collecting Process
Collecting Processes use a Flow Record's Template ID to interpret
that Record's Information Elements. To allow this, an IPFIX Exporter
must ensure that an IPFIX Collector knows the Template ID for each
incoming Flow Record. To interpret incoming Flow Records, an IPFIX
Collector may also need to know the function F() that was used by the
Metering Process for each Flow.
An IPFIX Collector may also use the selection criteria for packets to
interpret the Flow Records further.
The functions of the Collecting Process must include:
o Identifying, accepting and decoding the IPFIX Messages from
different <Exporting Process, Observation Domain> pairs.
o Storing the Control Information and Flow Records received from an
IPFIX Device.
At a high level, the IPFIX protocol at the Collecting Process:
1. Receives and stores the Control Information.
2. Decodes and stores the Flow Records using the Control
Information.
3. May optionally monitor the status of the Collecting Process and
execute a failover should any problem arise.
8.7 Summary
The figure below shows the functions performed in sequence by the
various functional blocks in an IPFIX Device.
Packet(s) coming into Observation Point(s)
| |
v v
+----------------+-------------------------+ +-----+-------+
| Metering Process on an | | |
| Observation Point | | |
Sadasivan, et al. Expires April 9, 2005 [Page 17]
Internet-Draft IPFIX Architecture October 2004
| packet header capturing | | |
| | | | Metering |
| timestamping | | Process |
| | | | on an |
| +----->+ | | Observation |
| | | | | Point |
| | sampling Si (1:1 in case of no | | |
| | | sampling) | | |
| | classifying Fi (select all when | | |
| | | no criteria) | | |
| +------+ | | |
| | | | |
| | Timing out Flows | | |
| | Handle resource overloads | | |
+--------|---------------------------------+ +-----|-------+
| |
Flow Records (identified by Observation Domain) Flow Records
| |
+---------+---------------------------------+
|
+--------------------|----------------------------------------------+
| | Exporting Process |
|+-------------------|-------------------------------------------+ |
|| v IPFIX Protocol | |
||+-----------------------------+ +----------------------------+| |
|||Rules for | |Functions || |
||| Picking/sending Templates | |-Packetize selected Control || |
||| Picking/sending Flow Records|->| & data Information into || |
||| Encoding Template & data | | IPFIX export packet. ||-->
||| Selecting Flows to export(*)| |-Handle export errors || |
||+-----------------------------+ +----------------------------+| |
|+----------------------------+----------------------------------+ |
| | |
| IPFIX exported packet |
| | |
| +------------+-----------------+ |
| | Anonymize export packet(*) | |
| +------------+-----------------+ |
| | |
| +------------+-----------------+ |
| | Transport Protocol | |
| +------------+-----------------+ |
| | |
+-----------------------------+-------------------------------------+
|
v
IPFIX export packet to Collector
Sadasivan, et al. Expires April 9, 2005 [Page 18]
Internet-Draft IPFIX Architecture October 2004
(*) indicates that the block is optional.
9. Overview of the IPFIX Protocol
An IPFIX Device consists of a set of co-operating processes that
implement the functional blocks described in the previous section.
Alternatively, an IPFIX Device can be viewed simply as a network
entity which implements the IPFIX protocol. At the IPFIX Device, the
protocol functionality resides in the Exporting Process. The IPFIX
Exporting Process gets Flow Records from a Metering Process, and
carries them to the Collector(s).
At a high level, an IPFIX Device performs the following tasks:
1. Encode Control Information into Templates.
2. Encode packets observed at the Observation Points into Flow
Records.
3. Packetize the selected Templates and Flow Records into IPFIX
Messages.
4. Send control and data packets to the Collector.
The IPFIX protocol communicates information from an IPFIX Exporter to
an IPFIX Collector. That information includes not only Flow Records,
but also information about the Metering Process. Such information
(referred to as Control Information) includes details of the data
fields in Flow Records. It may also include statistics from the
Metering Process, such as the number of packets lost (i.e. not
metered).
For details of the IPFIX protocol please refer to IPFIX-PROTO [4].
9.1 Information Model Overview
The IP Flow Information eXport (IPFIX) protocol serves for
transmitting information related to measured IP traffic over the
Internet. The protocol specification in IPFIX-PROTO [4] defines how
information elements are transmitted. For information elements, it
specifies the encoding of a set of basic data types. However, the
list of fields that can be transmitted by the protocol, such as flow
attributes (source IP address, number of packets, etc.) and
information about the metering and exporting process (packet
observation point, sampling rate, flow timeout interval, etc.), is
not specified in IPFIX-PROTO [4]. Instead, it is defined in the
IPFIX Information Model document IPFIX-INFO [3].
Sadasivan, et al. Expires April 9, 2005 [Page 19]
Internet-Draft IPFIX Architecture October 2004
The Information Model provides a complete description of the
properties of every IPFIX information element. It does this by
specifying each element's name, Field Type, data type, etc., and
providing a description of each element. Element descriptions give
the semantics of the element, i.e. say how it is derived from a Flow
or other information available within an IPFIX Device.
9.2 Flow records
The following rules provide guidelines to be followed while encoding
the Flow's information:
A Flow Record contains enough information so that the Collecting
Process can identify the corresponding <Per-Flow Control Information,
Configuration Control Information>.
The Exporter encodes a given field (as specified in IPFIX-INFO [3],
based on the encoding standards prescribed by IPFIX-PROTO [4].
9.3 Control Information
The following rules provide guidelines to be followed while encoding
the Control Information:
o Per-Flow Control Information should be encoded such that the
Collecting Process can capture the structure and semantics of the
corresponding Flow data for each of the Flows exported by the
IPFIX Device.
o Configuration Control Information is conveyed to a Collector so
that its Collecting Process can capture the structure and
semantics of the corresponding configuration data. The
configuration data which is also Control Information should carry
additional information on the Observation Domain within which the
configuration takes effect. For example, sampling using the same
sampling algorithm, say 1 in 100 packets, is configured on two
Observation Points O1 and O2. The configuration in this case may
be encoded as <ID, configuration domain (O1,O2), sampling
algorithm, interval (1 in 100)>, where ID uniquely identifies this
configuration.
9.4 Exporting Control Information
The Control Information is used by the Collecting Process to:
o Decode and interpret Flow Records.
Sadasivan, et al. Expires April 9, 2005 [Page 20]
Internet-Draft IPFIX Architecture October 2004
o Understand the state of the Exporting Process.
Sending Control Information from the Exporting Process in a timely
and reliable manner is critical to the proper functioning of the
IPFIX Collecting Process. The following approaches may be taken for
the export of Control Information.
1. Send all the Control Information pertaining to Flow Records prior
to sending the Flow Records themselves. This includes any
incremental changes to the definition of the Flow Records.
2. Notify on a near real time basis the state of the IPFIX Device to
the Collecting Process. This includes all changes such as a
configuration change that affects the Flow behavior, changes to
Exporting Process resources that alter export rates, etc., which
the Collector needs to be aware of.
3. Since it is vital that a Collecting Process maintains accurate
knowledge of the Exporter's state, the export of the Control
Information should be done such that that it reaches the
Collector reliably. One way to achieve this would be to send the
Control Information over a reliable transport.
9.5 Reporting Responsibilities
From time to time an IPFIX Device may not be able to observe all the
packets reaching one of its Observation Points. This could occur if
a Metering Process finds itself temporarily short of resources, for
example it might run out of packet buffers for IPFIX export, or it
might detect errors in its underlying transport layer.
In such situations, the IPFIX Device must report to its Collector(s)
the number of packet losses that have occurred.
10. IPFIX Protocol Details
When the IPFIX Working Group was chartered there were existing common
practices in the area of Flow export, for example NetFlow, CRANE,
LFAP, RTFM, etc. IPFIX's charter required the Working Group to
consider those existing practices, and select the one that was the
closest fit to the IPFIX requirements IPFIX-REQS [1]. Additions or
modifications would then be made to the selected protocol to fit it
exactly into the IPFIX architecture.
10.1 The IPFIX Basis Protocol
The working group went through an extensive evaluation of the various
Sadasivan, et al. Expires April 9, 2005 [Page 21]
Internet-Draft IPFIX Architecture October 2004
existing protocols that were available, weighing the level of
compliance with the requirements, and selected one of the candidates
as the basis for the IPFIX protocol. For more details of the
evaluation process please see IPFIX-EVAL [2].
In the basis protocol Flow Records are defined by Templates, where a
Template is an ordered set of the information elements appearing in a
Flow Record, together with their field sizes within those records.
This approach provides the following advantages:
o Using the Template mechanism, new fields can be added to IPFIX
Flow Records without changing the structure of the export record
format.
o Templates that are sent to the Collecting Process carry structural
information about the exported Flow Record fields. Therefore, if
the Collector does not understand the semantics of new fields it
can ignore them, but still interpret the Flow Record.
o Because the template mechanism is flexible, it allows the export
of only the required fields from the Flows to the Collecting
Process. This helps to reduce the exported Flow data volume and
possibly provide memory savings at the Exporting Process and
Collecting Process. Sending only the required information can
also reduce network load.
10.2 IPFIX Protocol on the Collecting Process
The Collecting process is responsible for:
1. Receiving and decoding Flow Records from the IPFIX Devices.
2. Indicating Flow Record losses to the exporting IPFIX Device
and/or IPFIX users.
3. Optionally notifying status and overload conditions to the IPFIX
Device.
Complete details of the IPFIX protocol are given in IPFIX-PROTO [4].
10.3 Support for Applications
Applications that use the information collected by IPFIX may be
Billing or Intrusion Detection sub-systems, etc. These applications
may be an integral part of the Collecting Process or they may be
co-located with the Collecting Process. The way by which these
Sadasivan, et al. Expires April 9, 2005 [Page 22]
Internet-Draft IPFIX Architecture October 2004
applications interface with IPFIX system to get the desired
information is out of scope for this document.
11. Export Models
11.1 Export with Reliable Control Connection
As mentioned in the IPFIX-REQS [1] document, an IPFIX Device must be
able to transport its Control Information and Data Stream over a
congestion-aware transport protocol.
If the network in which the IPFIX Device and Collecting Process are
located does not guarantee reliability, at least the Control
Information should be exported over a reliable transport. The Data
Stream may be exported over a reliable or unreliable transport
protocol.
Possible transport protocols include:
o SCTP: Supports reliable and unreliable transport. Some of SCTP's
features (e.g. session failover) may prove unfamiliar to IPFIX
implementors.
o TCP: Provides reliable transport only. Simple to implement, may
require large buffers to cope with periods of network congestion.
o UDP: Provides unreliable transport only. Network operators would
need to avoid congestion by keeping traffic within their own
administrative domains.
11.2 Collector Failure Detection and Recovery
The transport connection (in the case of a connection oriented
protocol) is pre-configured between the IPFIX Device and the
Collector. The IPFIX protocol does not provide any mechanism for
configuring the Metering or Exporting Processes.
Once connected, an IPFIX Collector receives Control Information and
uses that information to interpret Flow Records. The IPFIX Device
should set a keepalive (e.g. the keepalive timeout in the case of
TCP, the HEARTBEAT interval in the case of SCTP, or an IPFIX protocol
level keepalive if any) to a sufficiently low value so that it can
quickly detect a Collector failure.
Collector failure refers to the crash or restart of the Collecting
Process, or of the Collector itself. A Collector failure is detected
at the IPFIX Device by the break in control connection (depending on
Sadasivan, et al. Expires April 9, 2005 [Page 23]
Internet-Draft IPFIX Architecture October 2004
the transport protocol - the connection timeout mechanisms differ).
On detecting a keepalive timeout, the IPFIX Device should stop
sending the Flow export data to the Collector and try to reestablish
the transport connection. This is valid for a single Collector
scenario. If there are multiple Collectors for the same IPFIX
Device, the IPFIX Device opens control connections to each of the
Collectors. However, data gets sent only to one of the Collectors
which is chosen as the primary.
There could be one or more Collectors configured as secondary and a
priority assigned to them. The primary Collector crash is detected
at the IPFIX Device by the break in control connection (depending on
the transport protocol - the connection timeout mechanisms differ).
On detecting loss of connectivity, the IPFIX Device opens a Data
Stream with the secondary Collector of the next highest priority.
That Collector now becomes the primary. The maximum export data loss
would be the amount of data exported in the time between when the
loss of connectivity to the Collector happened, and the time at which
this was detected by the IPFIX Device.
11.3 Collector Redundancy
Since the IPFIX protocol requires a congestion-aware transport,
achieving redundancy using multicast is not an option. Multiple
<Control Information, Data Stream> pairs could be set up, each to a
different Collector from the same IPFIX Device. The Control and data
Information would then be replicated on each of the Control
Information and Data Streams.
12. IPFIX Flow Collection for Special Traffic
An IPFIX Device could be doing one or more of generating, receiving,
altering special types of traffic which are listed below.
Tunnel traffic:
The IPFIX Device could be the head, midpoint or endpoint of a
tunnel. In such cases the IPFIX could be handling GRE, IPinIP or
UTI traffic.
VPN traffic:
The IPFIX Device could be a provider edge device which receives
traffic from customer sites belonging to different Virtual Private
Networks.
In the cases above, there should be clear guidelines as to:
Sadasivan, et al. Expires April 9, 2005 [Page 24]
Internet-Draft IPFIX Architecture October 2004
o How and when to classify the packets as Flows in the IPFIX Device.
o If multiple encapsulations are used to define Flows, how to convey
the same fields (e.g. IP address) in different layers.
o How to differentiate Flows based on different private domains.
For example, overlapping IP addresses in Layer-3 VPNs
13. IPFIX Flow Collection from Special Devices
IPFIX could be implemented on devices which perform one or more of
the following special services:
o Explicitly drop packets. For example a device which provides
firewall service drops packets based on some administrative
policy.
o Alter the values of fields used as IPFIX Flow keys of interest.
For example a device which provides NAT service can change source
or(and) destination IP address.
In the cases above, there should be clear guidelines as to:
o How and when to classify the packets as Flows in the IPFIX Device.
o What extra information be exported so that the Collector can make
a clear interpretation of the received Flow Records.
14. Security Considerations
IP Flow information can be used for various purposes, such as usage
accounting, traffic profiling, traffic engineering, and intrusion
detection. The security requirement may differ significantly for
such applications. To be able to satisfy the security needs of
various IPFIX users, an IPFIX system must provide different levels of
security protection.
14.1 Data Security
IPFIX data comprises Control Information and Data Stream generated by
the IPFIX Device.
The IPFIX data may exist in both the IPFIX Device and the Collector.
In addition, the data is also transferred on the wire from the IPFIX
Device to the Collector when it is exported. To provide security,
the data should be protected from common network attacks.
Sadasivan, et al. Expires April 9, 2005 [Page 25]
Internet-Draft IPFIX Architecture October 2004
The protection of IPFIX data within the end system (IPFIX Device and
Collector) is out of scope for this document. It is assumed that the
end system operator will provide adequate security for the IPFIX
data.
The IPFIX architecture must allow different levels of protection to
the IPFIX data on the wire. Wherever security functions are required
it is recommended that users should leverage lower layers using
either IPSEC or TLS, if these can successfully satisfy the security
requirement of IPFIX data protection.
To protect the data on the wire, three levels of granularity should
be supported ..
14.1.1 No Security
Security may not be required when the transport between the IPFIX
Device and the Collector is perceived as safe. This option allows
the protocol to run most efficiently without extra overhead and an
IPFIX system must support it.
14.1.2 Authentication-only
Authentication-only protection provides IPFIX users with the
assurance of data integrity and authenticity. The data exchanged
between the IPFIX Device and the Collector is protected by an
authentication signature. Any modification of the IPFIX data will be
detected by the recipient, resulting in discarding of the received
data. However, the authentication-only option doesn't offer data
confidentiality.
The IPFIX user should avoid use authentication-only when sensitive or
confidential information is being exchanged. An IPFIX solution
should support this option. The authentication-only option should
provide replay attack protection. Some means to achieve this level
of security are:
o TCP with MD5 options.
o IP Authentication Header
14.1.3 Encryption
Data encryption provides the best protection for IPFIX data. The
IPFIX data is encrypted at the sender and only the intended recipient
can decrypt and have access to the data. This option must be used
when the transport between the IPFIX Device and the Collector are
Sadasivan, et al. Expires April 9, 2005 [Page 26]
Internet-Draft IPFIX Architecture October 2004
unsafe and the IPFIX data needs to be protected. It is recommended
that the underlying transport layer's security functions be used for
this purpose. Some means to achieve this level of security are:
o Encapsulating Security Payload.
o Transport Layer Security Protocol
The data encryption option adds overhead to the IPFIX data transfer.
It may limit the rate that an Exporter can report its Flow to the
Collector due to the resource requirement for running encryption.
14.2 IPFIX End-point Authentication
It is important to make sure that the IPFIX Device is talking to the
"right" Collector rather than to a masquerading Collector. The same
logic also holds true from the Collector point of view, i.e. it may
want to make sure it is collecting the Flow information from the
"right" IPFIX Device. An IPFIX system should allow the end point
authentication capability so that either one-way or mutual
authentication can be performed between the IPFIX Device and
Collector.
The IPFIX architecture should use any existing transport protection
protocols such as TLS or IPSEC to fulfill the authentication
requirement.
15. IPFIX Overload
An IPFIX Device could become overloaded under various conditions.
This may be because of exhaustion of internal resources used for Flow
generation and/or export. Such overloading may cause loss of data
from the Exporting Process, either from lack of export bandwidth
(possibly caused by an unusually high number of observed Flows) or
from network congestion in the path from Exporter to Collector.
IPFIX Collectors should be able to detect the loss of exported Flow
Records, and should at least record the number of lost Flow Records.
15.1 Denial of Service (DoS) Attack Prevention
Since one of the potential usages for IPFIX is for intrusion
detection, it is important for the IPFIX architecture to support some
kind of DoS resistance.
15.1.1 Network Under Attack
The Network itself may be under attack, resulting in an overwhelming
Sadasivan, et al. Expires April 9, 2005 [Page 27]
Internet-Draft IPFIX Architecture October 2004
number of IPFIX Messages. An IPFIX system should try to capture as
much information as possible. However, when a large number of IPFIX
Messages are generated in a short period of time, the IPFIX system
may become overloaded.
15.1.2 Generic DoS Attack on the IPFIX System
The IPFIX system may subject to generic DoS attacks, just as any
system on any open network. These types of attacks are not IPFIX
specific. Preventing and responding to such types of attacks are out
of the scope of this document.
15.1.3 IPFIX Specific DoS Attack
There are some specific attacks on the IPFIX portion of the IPFIX
Device or Collector.
o The attacker could pound the Collector with spoofed IPFIX export
packets. One way to solve this problem is to periodically
synchronize the sequence numbers of the Flow Records between the
Exporting and Collecting Processes.
o The attacker could provide false reports to the IPFIX Device by
sending spoofed control packets.
The problems mentioned above can be solved to a large extent if the
control packets are encrypted both ways.
16. IANA Considerations
The IPFIX Architecture, as set out in this document, has two sets of
assigned numbers. Considerations for assigning them are discussed in
this section, using the example policies as set out in the
"Guidelines for IANA Considerations" document IANA-RFC [5].
16.1 Numbers used in the Protocol
IPFIX Messages, as described in IPFIX-PROTO [4], use two fields with
assigned values. These are the IPFIX Version Number, indicating
which version of the IPFIX Protocol was used to export an IPFIX
Message, and the IPFIX Template Number, indicating the type for each
set of information within an IPFIX message.
Changes in either IPFIX Version Number or IPFIX Template Number
assignments require an IETF Consensus, i.e. they are to be made via
RFCs approved by the IESG.
Sadasivan, et al. Expires April 9, 2005 [Page 28]
Internet-Draft IPFIX Architecture October 2004
16.2 Numbers used in the Information Model
Fields of the IPFIX protocol carry information about traffic
measurement. They are modeled as elements of the IPFIX information
model IPFIX-INFO [3]. Each information element describes a field
which may appear in an IPFIX Message. Within an IPFIX message the
field type is indicated by its Field Type.
Changes in IPFIX Field Type will be administered by IANA, subject to
Expert Review, i.e. review by one of a group of experts designated
by an IETF Operations and Management Area Director. Those experts
will initially be drawn from the Working Group Chairs and document
editors of the IPFIX and PSAMP Working Groups.
17. Acknowledgements
The document editors wish to thank all the people contributing to the
discussion of this document on the mailing list, and the design teams
for many valuable comments. In particular, the following made
significant contributions:
Tanja Zseby
Paul Calato
Dave Plonka
Jeffrey Meyer
Benoit Claise
Ganesh Sadasivan
K.C.Norseth
Vamsi Valluri
Cliff Wang
Ram Gopal
Jc Martin
Carter Bullard
Juergen Quittek
Reinaldo Penno
Nevil Brownlee
Simon Leinen
Kevin Zhang
18 References
[1] Quittek, J., Zseby, T. and B. Claise, "Requirements for IP Flow
Information Export", (work in progress), Internet Draft,
draft-ietf-ipfix-reqs-16.txt, June 2004.
[2] Leinen, S., "Evaluation of Candidate Protocols for IP Flow
Information Export", (work in progress), Internet Draft,
Sadasivan, et al. Expires April 9, 2005 [Page 29]
Internet-Draft IPFIX Architecture October 2004
draft-leinen-ipfix-eval-contrib-03.txt, May 2004.
[3] Quittek, J., Meyer, J. and P. Calato, "IPFIX: Information
Model", (work in progress), Internet Draft,
draft-ietf-ipfix-info-03.txt, February 2004.
[4] Fulmer, M., Claise, B., Calato, P. and R. Penno, "IPFIX:
Protocol", (work in progress), Internet Draft,
draft-ietf-ipfix-protocol-03.txt, January 2004.
[5] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, October 1998.
Authors' Addresses
Ganesh Sadasivan
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
USA
Phone: +1 408 527-0251
EMail: gsadasiv@cisco.com
Nevil Brownlee
CAIDA | The University of Auckland
Private Bag 92019
Auckland
New Zealand
Phone: +64 9 373 7599 x8941
EMail: n.brownlee@auckland.ac.nz
Benoit Claise
Cisco Systems, Inc.
De Kleetlaan 6a b1
1831 Diegem
Belgium
Phone: +32 2 704 5622
EMail: bclaise@cisco.com
Sadasivan, et al. Expires April 9, 2005 [Page 30]
Internet-Draft IPFIX Architecture October 2004
Juergen Quittek
NEC Europe Ltd.
Adenauerplatz 6
69225 Heidelberg
Germany
Phone: +49 6221 90511-15
EMail: quittek@ccrle.nec.de
URI:
Sadasivan, et al. Expires April 9, 2005 [Page 31]
Internet-Draft IPFIX Architecture October 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Sadasivan, et al. Expires April 9, 2005 [Page 32]
Internet-Draft IPFIX Architecture October 2004
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Sadasivan, et al. Expires April 9, 2005 [Page 33]