One document matched: draft-ietf-ipfix-as-01.txt
Differences from draft-ietf-ipfix-as-00.txt
Internet Draft Tanja Zseby
Document: <draft-ietf-ipfix-as-01.txt> Fraunhofer FOKUS
Expires: April 2004 Reinaldo Penno
Nortel Networks
Nevil Brownlee
CAIDA
Benoit Claise
Cisco Systems
October 2003
IPFIX Applicability
draft-ietf-ipfix-as-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
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.
Abstract
This document describes what type of applications can use the IP
Flow Information Export (IPFIX) protocol and how they can use
the information provided by IPFIX. It furthermore shows how the
IPFIX framework relates to other architectures and frameworks.
Expires April 2004 [Page 1]
IPFIX Applicability October 2003
Table of Contents
1. Introduction.................................................2
2. Applications of IPFIX........................................2
2.1 Accounting...................................................2
2.2 Security Analysis and Intrusion detection with IPFIX.........3
2.3 Network Planning.............................................4
2.4 Peering Agreements...........................................4
2.5 Traffic Engineering..........................................5
2.6 Data Warehousing and Mining..................................5
2.7 Traffic Monitoring...........................................5
2.8 QoS Monitoring...............................................5
2.8.1 Measurement of Round-trip-time (RTT)........................6
2.8.2 Measurement of One-way-delay (OWD)..........................6
2.8.3 Measurement of One-way-loss (OWL)...........................7
2.8.4 Measurement of IP delay variation (IPDV)....................7
3. Relation of IPFIX to other frameworks and protocols..........7
3.1 IPFIX and AAA................................................7
3.1.1 Connecting via an AAA Client................................8
3.1.2 Connecting via an Application Specific Module (ASM).........9
3.2 IPFIX and RTFM..............................................10
3.2.1 Definition of 'flow'.......................................10
3.2.2 Configuration and Management...............................11
3.2.3 Data Model details.........................................12
3.2.4 Application/transport protocol.............................13
3.3 IPFIX and IPPM..............................................13
4. Security Consideration......................................13
5. References..................................................14
6. Acknowledgements............................................15
7. Author's Addresses..........................................15
8. Full Copyright Statement....................................16
1. Introduction
The IPFIX protocol defines how IP Flow information can be
exported from routers, measurement probes or other devices. It
is intended to provide this information as input for various
applications. This document describes what applications can use
the IPFIX protocol and how they can use it. Furthermore, the
relationship of IPFIX to other frameworks and architectures is
described.
2. Applications of IPFIX
IPFIX data enables several critical customer applications. This
section describes how different applications can use IPFIX.
2.1 Accounting
Expires April 2004 [Page 2]
IPFIX Applicability October 2003
Usage based accounting is one of the major applications for
which the IPFIX protocol has been developed. IPFIX data provides
fine-grained metering (for example, flow records include details
such as IP addresses, packet and byte counts, timestamps, Type
of Service (ToS), application ports, etc.) for highly flexible
and detailed resource usage accounting. ISPs can use this
information to migrate from single fee, flat-rate billing to
more flexible charging mechanisms based on time of day,
bandwidth usage, application usage, quality of service, etc.
Enterprise customers can use this information for departmental
chargeback or cost allocation for resource usage.
In order to realize usage-based accounting with IPFIX the flow
definition has to be chosen in accordance to the tariff model. A
tariff can for instance be based on individual end-to-end
streams. In that case accounting can be realized with a flow
definition determined by the quintuple that consists of source
address, destination address, protocol and portnumbers. Another
example is a class-dependent tariff (e.g. in a DiffServ
networks). For this flows could be distinguished just by
DiffServ codepoint (DSCP) and source address.
The essential elements needed for accounting are the number of
transferred packets and bytes per flow which are contained in
IPFIX flow records. Furthermore IPFIX provides a very flexible
definition of flows, so arbitrary flow-based accounting models
can be realized without any extensions to the IPFIX protocol.
Nevertheless the configuration of flow definitions is out of
scope of the IPFIX definition.
For accounting purposes, it would be advantageous to have the
ability to use IPFIX flow records as accounting input in a AAA
infrastructure. AAA servers then could provide the mapping
between user and flow information.
2.2 Security Analysis and Intrusion detection with IPFIX
Intrusion detection systems (IDS) monitor and control security
incidents. A typical IDS system includes components like sensor,
event collector, and management stations. Sensors monitor
network and system traffic for attacks and other security-
related events. Sensors respond to and notify the administrator
about these events as they occur. Event collectors are a middle-
tier component responsible for transmitting events from sensors
to the console and database. The management component serves the
following purposes:
_ - visually monitors events (with a console)
Expires April 2004 [Page 3]
IPFIX Applicability October 2003
_ - collects data from sensors (with one or more event
collectors)
_ - stores data from sensors (in a database)
IPFIX can report events of interest to the sensor either by the
collecting process or directly by the exporting process. It
depends on the scenario and the events of interest which
solution is better. Getting information directly from the
exporting process has the advantage that the sensor gets the
information faster. It does not need to wait for collector
processing time or until the collector has all relevant data.
Getting the information from a collector allows correlating data
from different exporting processes (e.g. from different routers)
to get a better picture about what is going on in the network.
IPFIX provides useful input data for basic intrusion detection
functions (e.g. detecting unusual high loads) such as details on
source and destination addresses, along with the start time of
flows, TCP flags, application ports and flow volume. This data
can be used to analyze network security and identify
attacks. Nevertheless, for some scenarios intrusion detection
may require further insight into packet content. Since IPFIX
allows a flexible report definition the metering process and the
IPFIX report format could be extended to support other data
needed for intrusion detection systems.
Detecting security incidents in real-time would require a
preprocessing of data already at the measurement device and
immediate data export in case a possible incident has been
identified. This means that IPFIX reports must be generated upon
incident detection events and not only upon flow end or fixed
time intervals.
2.3 Network Planning
IPFIX data captured over a long period of time can be used to
track and anticipate network growth and plan upgrades to
increase the number of routing devices, ports, or higher-
bandwidth interfaces. IPFIX data optimizes both strategic
network planning (peering, backbone upgrade planning, and
routing policy planning) as well as tactical network engineering
decisions (upgrading the router or link capacity). This helps to
minimize the total cost of network operations while maximizing
network performance, capacity, and reliability.
2.4 Peering Agreements
IPFIX data enables ISP peering partners to measure the volume
and characteristics of traffic exchanged with other ISP peers.
Expires April 2004 [Page 4]
IPFIX Applicability October 2003
2.5 Traffic Engineering
IPIFX data provides traffic engineering details for a set of
prefixes. This data can be used in network optimization for load
balancing traffic across alternate paths, or for forwarding
traffic of a certain set of prefixes on a preferred route.
2.6 Data Warehousing and Mining
IPFIX data (or derived information) can be stored for later
retrieval and analysis to support proactive marketing and
customer service programs. An example of this would be to
determine which applications and services are being used by
internal and external users and then target them for improved
services such as advertising. This is especially useful for ISPs
because IPFIX data enables them to create better service
packaging.
2.7 Traffic Monitoring
IPFIX data can be used for extensive near real-time traffic
monitoring. Traffic patterns associated with routing devices and
switches on an individual or network wide basis can be displayed
enabling proactive problem detection, efficient troubleshooting,
and rapid problem resolution.
IPFIX data enables content and service providers to perform a
detailed, time-based, and application-based usage analysis of a
network. They also provide detailed information for
understanding customer or end-user usage of network and
application resources. This information can then be used to
efficiently plan and allocate access, backbone, and application
resources, as well as to detect and resolve potential security
and policy violations.
2.8 QoS Monitoring
The performance of QoS monitoring is one target application for
using the IPFIX protocol. QoS monitoring is the passive
observation of transmission quality for single flows or traffic
aggregates in the network. One example of its usefulness is the
validation of QoS guarantees in service level agreements (SLAs).
Some QoS metrics require the correlation of data from multiple
measurement points. For this the clocks of the involved
exporting devices must be synchronized. Furthermore, such
measurements would benefit from post-processing functions (e.g.
packet ID generation and mapping) at the exporter and/or
collector. This section describes how the monitoring of
Expires April 2004 [Page 5]
IPFIX Applicability October 2003
different metrics can be performed with IPFIX. All of the
metrics require at least an extension of the IPFIX information
model because currently the necessary information such as e.g.
round-trip-time, packet IDs etc. is not part of the model.
However given the extensibility and flexibility of IPFIX the
missing attributes can be easily defined.
2.8.1 Measurement of Round-trip-time (RTT)
The passive measurement of round-trip-times (RTT) can be
performed by using packet pair matching techniques as described
in [Brow00]. For the measurements, request/response packet pairs
from protocols like DNS, ICMP, SNMP or TCP (syn/syn-ack,
data/ack) are utilized to passively observe the RTT [Brow00]. As
always for passive measurements this only works if the required
traffic of interest is actually present in the network.
Furthermore, if the observed protocol supports retransmissions
(e.g. TCP) the RTT is not the network RTT but rather the RTT of
the network and the network stack of the receiver. In case the
reply packet is lost or can not be observed the RTT can not be
calculated.
In order to use this measurement technique, the IPFIX metering
process needs to measure both directions. A classification of
the protocols mentioned above has to be done. That means parts
of the transport header are used for the classification. Since a
differentiation of flows in accordance to the transport header
is one of the requirements for IPFIX, such classification can be
performed without extensions. Nevertheless, the meter needs to
recognize request and response packets for the given protocols
and therefore needs to look further into the packets. The
capability to do this analysis is not part of the IPFIX
requirements but can be achieved by optional extensions to the
classification process. The exporting device needs to assign a
timestamp for the arrival of the packets. The calculation of the
RTT can be done directly at the exporter or at the collector. In
the first case IPFIX would transfer the calculated RTT to the
collector. In the second case IPFIX needs to send the observed
packet types and the timestamps to the collector. The round-
trip-time-delay metric is defined in [RFC2681].
2.8.2 Measurement of One-way-delay (OWD)
Passive one-way-delay measurements require the collection of
data at two measurement points. It is necessary to recognize
packets at the second measurement point to correlate packet
arrival events from both points. This can be done by capturing
packet header and parts of the packet that can be used to
recognize the same packet at the subsequent measurement point
Expires April 2004 [Page 6]
IPFIX Applicability October 2003
[MaPZ03]. To reduce the amount of measurement data a unique
packet ID can be calculated from the header and part and/of the
content e.g. by using a CRC or hash function [GrDM98, DuGr00,
ZsZC01]. The capability of using content information is out of
scope of IPFIX but can be achieved by an optional extension.
Nevertheless, in some scenarios it might even be sufficient to
calculate a packet ID based on header fields (including datagram
ID and maybe sequence numbers from transport protocols) only
without looking at parts of the packet content. If packet IDs
need to be unique only for a certain time interval or a certain
amount of packet ID collisions is tolerable this is a sufficient
solution. The second issue is the export of packet IDs. IPFIX
exports per flow information. However, it is possible to extend
IPFIX with a scheme to export per-packet information by
providing special templates for that purpose. The one way delay
metric is defined in [RFC2679].
2.8.3 Measurement of One-way-loss (OWL)
Passive loss measurements for single flows can be performed at
one measurement point by using sequence numbers that are present
in protocols (e.g. IP identification, TCP sequence numbers)
similar to the approach described in section 2.8.1. This
requires the capturing of the sequence numbers of subsequent
packets of the observed flow by the IPFIX metering process.
An alternative to this is to perform a two-point measurement as
described in section 2.8.2 and consider packets as lost that do
not arrive at the second measurement point in a given time
frame. This approach assumes that a packet observed at the first
point should also be observed at the second point (known
routing).
The one-way loss metric is defined in [RFC2680].
2.8.4Measurement of IP delay variation (IPDV)
IP Delay variation is defined as the difference of one-way-delay
values for selected packets [RFC3393]. Therefore, this metric
can be calculated by performing passive measurement of one-way-
delay for subsequent packets (e.g. of a flow) and then
calculating the differences.
3. Relation of IPFIX to other frameworks and protocols
3.1 IPFIX and AAA
AAA defines a protocol and architecture for authentication,
authorization and accounting for service usage. The DIAMETER
protocol is used for AAA communication for network access
Expires April 2004 [Page 7]
IPFIX Applicability October 2003
services (Mobile IP, NASREQ, and ROAMOPS). The AAA architecture
[RFC2903] provides a framework for extending the AAA support
also for other services. DIAMETER defines the exchange of
messages between AAA entities, e.g. between AAA clients at
access devices and AAA servers and among AAA servers. It is used
also for the transfer of accounting records. Usage-based
accounting requires measurement data from the network. IPFIX
defines a protocol to export such data from routers, measurement
probes and other devices.
The provisioning of accounting with IPFIX can be realized
without an AAA infrastructure. The collector can directly
forward the measurement information to an accounting
application. Nevertheless, if an AAA infrastructure is in place,
IPFIX can provide the input for the generation of accounting
records and several features of the AAA architecture can be
used. Features include the mapping of a user ID to the flow
information (by using authentication information), the
generation of DIAMETER accounting records and the secure
exchange of accounting records between domains with DIAMETER.
Two possibilities to connect IPFIX and AAA can be distinguished:
3.1.1Connecting via an AAA Client
One possibility to connect IPFIX and AAA is to run an AAA client
on the IPFIX collector. This client can generate DIAMETER
accounting messages and send them to an AAA server. The mapping
of the flow information to a user ID can be done in the AAA
server by using data from the authentication process. DIAMETER
accounting messages can be sent to the accounting application or
to other AAA servers (e.g. in roaming scenarios).
Expires April 2004 [Page 8]
IPFIX Applicability October 2003
+---------+ DIAMETER +---------+
| AAA-S |------------->| AAA-S |
+---------+ +---------+
^
| DIAMETER
|
|
+--+--------+--+
| | AAA-C | |
+ +--------+ |
| |
| Collector |
+--------------+
^
| IPFIX
|
+------------+
| Exporter |
+------------+
Figure 2: IPFIX collector connects to AAA server via AAA client
3.1.2Connecting via an Application Specific Module (ASM)
Another possibility is to directly connect the IPFIX collector
with the AAA server via an application specific module (ASM).
Application specific modules have been proposed by the IRTF AAA
architecture research group (AAARCH) in [RFC2903]. They act as
an interface between AAA server and service equipment. In this
case the IPFIX collector is part of the ASM. The ASM acts as an
interface between the IPFIX protocol and the input interface of
the AAA server. The ASM translates the received IPFIX data into
an appropriate format for the AAA server. The AAA server then
can add information about the user ID and generate a DIAMETER
accounting record. This accounting record can be sent to an
accounting application or to other AAA servers.
Expires April 2004 [Page 9]
IPFIX Applicability October 2003
+---------+ DIAMETER +---------+
| AAA-S |------------->| AAA-S |
+---------+ +---------+
^
|
+------------------+
| ASM |
| +------------+ |
| | Collector | |
+------------------+
^
| IPFIX
|
+------------+
| Exporter |
+------------+
Figure 3: IPFIX connects to AAA server via ASM
3.2 IPFIX and RTFM
This section compares the Real-time Traffic Flow Measurement
(RTFM) framework with the IPFIX framework.
3.2.1Definition of 'flow'
RTFM and IPFIX both use the same definition of flow; a flow is a
set of packets which share a common set of end-point address
attribute values. A flow is therefore completely specified by
that set of values, together with an inactivity timeout. A flow
is considered to have ended when no packets are seen for at
least the inactivity time.
RTFM flows are bidirectional, which has given rise to some
confusion.
At the simplest level, a flow information exporter may achieve
this by maintaining two unidirectional flows, one for each
direction. To export bidirectional flow information, e.g. to-
and from- packet counts, for a flow from A to B, the exporter
has only to search its flow table to find the matching flow from
B to A.
RTFM, however, takes bi-directionality a stage further, by
including in the RTFM architecture [RFC 2722] a fully-detailed
algorithm for real-time matching of the two directions of a
flow. This was done for two reasons, to reduce the memory
required to store each flow (common address attributes for each
direction), and to allow for attributes which required fine
Expires April 2004 [Page 10]
IPFIX Applicability October 2003
detail for the two directions, e.g. short-term bit rate
distributions [RFC 2724].
** So far there has been no suggestion that IPFIX should do
this.
3.2.2Configuration and Management
The RTFM architecture specifies a complete system for gathering
flow information. It defines three entities,
- Meters are very similar to IPFIX exporters.
- Meter Readers are very similar to IPFIX collectors.
- Managers co-ordinate the activities of meters and meter
readers, and download configuration to them.
Note that the whole RTFM system is asynchronous, many readers
may collector flow data from a meter, and any reader may collect
flow data from many meters.
Rulesets allow the user to specify which flows are of interest,
which are the source and destination ends of each flow, and what
level of address granularity is required in the metered flows.
For example, one may select all packets from 192.168/16, but
build flow information for 192.168/24. RTFM selection is done
by testing under masks, and the masks do not have to use
consecutive ones from the left. Non-contiguous masks were
considered important for handling some OSI protocols, but the
need for that has diminished considerably.
The RTFM approach is based on RMON, in that if a user wants to
collect flow data for some particular set of flows, this can be
achieved by writing a ruleset, i.e. an SRL program [RFC 2723],
to specify what flows are of interest, requesting a manager to
download that ruleset to a meter, and requesting the manager to
have a meter reader collect the flow data at specified
intervals.
The details of how the manager communicates this information to
meters and meter readers are not specified in the architecture.
RTFM has a Meter MIB [RFC 2720], which is a standard which can
be used to configure a meter, but nothing is said about how to
configure a meter reader.
The extent to which IPFIX should specify how meters or exporters
should be configured is, at this stage, an open question.
Clearly a collector needs some way to be sure of what it's
collecting, e.g. by receiving 'templates' from the meter.
RTFM and IPFIX both leave parts of the system unspecified. For
RTFM flow data to be useful one must know the ruleset used to
Expires April 2004 [Page 11]
IPFIX Applicability October 2003
configure the meter, but a user can specify the ruleset. For
IPFIX one knows what the data is from the templates, but we have
yet to determine whether in-band configuration will be
supported.
3.2.3Data Model details
3.2.3.1 Count in one bucket
Within a ruleset, a packet may only be counted on one bucket,
i.e. it may only be included in one flow. This means that the
meter does not have to keep track of overlapping flows - if such
aggregation is required, it must be done after the raw flow data
has been read by a meter reader.
From time to time one may wish to collect flow data for
different levels of aggregation at the same time. RTFM allows a
meter to run several rulesets at the same time, and meter
readers must specify which rulesets they are collecting data
from.
The 'count in one bucket' rule, together with the ability to run
multiple rulesets, has proved very simple and effective in
practice.
3.2.3.2 Counter wrapping
For its packet- and byte-count attributes RTFM uses
continuously-incrementing 64-bit counters, which are never
reset. This makes asynchronous meter reading easy, any reader
simply has to remember its previous reading and compute the
difference. The only caveat is that the meter should be read
often enough to avoid situations when the counter has cycled
more than once between readings.
3.2.3.3 Sampling issues
RTFM provides 1 out of N sampling as a configuration option, so
that some metering interfaces may only process every Nth packet.
The RTFM Architecture [RFC 2722] does not discuss the
statistical implications of this, merely saying that users will
need to satisfy themselves that sampling makes sense in their
environment.
RTFM makes no provision for flow sampling. Recently there has
been a lot of interest in flow sampling schemes which favour the
'most important' flows, perhaps we need to consider this for
IPFIX.
Expires April 2004 [Page 12]
IPFIX Applicability October 2003
3.2.4Application/transport protocol
RTFM has a standards-track Meter MIB [RFC 2720], which can be
used both to configure a meter and to read flow data from it.
The MIB provides a way to read lists of attributes with a single
Object Identifier (called a 'package'), which dramatically
reduces the SNMP overhead for flow data collection. NeTraMet, a
widely-used open-source RTFM implementation, uses SNMPv2C for
configuration and data collection.
SNMP, of course, normally uses UDP as its transport protocol.
Since RTFM requires a reliable flow data transport system, an
RTFM meter reader must time out and resend unanswered SNMP
requests. Apart from being clumsy, this can limit the maximum
data transfer rate from meter to meter reader. SNMP over TCP
would be a better approach, but that is currently an IRTF
project.
On the other hand, RTFM does not specify an application protocol
in its architecture, leaving this as an implementation issue.
For example, a team at IBM Research implemented a RTFM meter and
meter reader in a single host, with the reader storing the flow
data directly into a large database system. Similarly, many
NeTraMet users run the meter and meter reader on the same host
system.
A need for high flow data rates highlights the need for careful
systems design when building a flow data collection system.
When data rates are high, and it is not possible to use a high
level of aggregation, then it makes sense to have the collectors
very close to their exporters. Once the data is safely on a
dedicated host machine, large volumes of it can be moved using
'background' techniques such as FTP.
The RTFM architecture only specifies a pull model for getting
data out of a meter. To implement push mode data transfer would
require specification of triggers to indicate when data should
be sent for each flow.
3.3 IPFIX and IPPM
The IPFIX protocol can be used to carry IPPM network performance
metrics or information which can be used to calculate those
metrics (see section 2.8).
4. Security Consideration
This document describes the usage of IPFIX in various scenarios.
The security requirements for the IPFIX target applications are
Expires April 2004 [Page 13]
IPFIX Applicability October 2003
addressed in the IPFIX requirements draft. These requirements
must be considered for the specification of the IPFIX protocol.
The IPFIX extensions proposed in this document do not induce
further security hazards.
Section 3 of this document describes how IPFIX can be used in
combination with other frameworks. New security hazards can
arise when two individually secure frameworks are combined. For
the combination of AAA with IPFIX an ASM or an IPFIX collector
can function as transit point for the messages. It has to be
ensured that at this point the applied security mechanisms (e.g.
encryption of messages) are maintained.
5. References
[Awdu02] Daniel O. Awduche, et. al.," Overview and Principles of
Internet Traffic Engineering", (work in progress),
Internet Draft, Internet Engineering Task Force, draft-
ietf-tewg-principles-02.txt, May 2002
[Brow00] Nevil Brownlee: Packet Matching for NeTraMet
Distributions,http://www2.auckland.ac.nz/net//Internet/r
tfm/meetings/47-adelaide/pp-dist/
[DuGr00] Nick Duffield, Matthias Grossglauser: "Trajectory
Sampling for Direct Traffic Observation", Proceedings of
ACM SIGCOMM 2000, Stockholm, Sweden, August 28 -
September 1, 2000.
[GrDM98] Ian D. GRAHAM, Stephen F. DONNELLY, Stele MARTIN, Jed
MARTENS, John G. CLEARY: Nonintrusive and Accurate
Measurement of Unidirectional Delay and Delay Variation
on the Internet, INET'98, Geneva, Switzerland, 21-24
July, 1998
[MaPZ03] L. Mark, G. Pohl, T. Zseby, K. Sugauchi: Passive One-
way Delay Measurements, (work in progress), Internet
Draft <draft-mark-powd-00.txt>, June 2003
[QuZC03] J. Quittek ,et. Al "Requirements for IP Flow
Information Export ", (work in progress) ,Internet
Draft, Internet Engineering Task Force, <draft-ietf-
ipfix-reqs-10.txt>, June 2003
[RFC2679] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Delay
Metric for IPPM, Request for Comments: 2679, September
1999
Expires April 2004 [Page 14]
IPFIX Applicability October 2003
[RFC2680] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Packet
Loss Metric for IPPM, September 1999
[RFC2681]G. Almes, S. Kalidindi, M. Zekauskas, "A Round-trip
Delay Metric for IPPM.", RFC 2681, September 1999
[RFC2903] C. de Laat, G. Gross, L. Gommans, J. Vollbrecht, D.
Spence, "Generic AAA Architecture", RFC 2903, August
2000
[RFC3393] C. Demichelis, P. Cimento: IP Packet Delay Variation
Metric for IPPM, RFC 3393, November 200
[ZsZC01] Tanja Zseby, Sebastian Zander, Georg Carle: Evaluation
of Building Blocks for Passive One-way-delay
Measurements, Proceedings of Passive and Active
Measurement Workshop (PAM 2001), Amsterdam, The
Netherlands, April 23-24, 2001
6. Acknowledgements
We would like to thank the following persons for their
contribution, discussion on the mailing list and valuable
comments:
- Sebastian Zander
- Robert Loewe
7. Author's Addresses
Tanja Zseby
Fraunhofer Institute for Open Communication Systems (FOKUS)
Kaiserin-Augusta-Allee 31
10589 Berlin, Germany
Phone: +49 30 3463 7153
Email: zseby@fokus.fhg.de
Reinaldo Penno
Nortel Networks, Inc.
2305 Mission College Boulevard
Building SC9-B1240, Santa Clara, CA 95134
Email: rpenno@nortelnetworks.com
Nevil Brownlee
CAIDA (UCSD/SDSC)
9500 Gilman Drive
La Jolla, CA 92093-0505
Phone : +1 858 534 8338
Expires April 2004 [Page 15]
IPFIX Applicability October 2003
Email : nevil@caida.org
Benoit Claise
Cisco Systems
De Kleetlaan 6a b1
1831 Diegem
Belgium
Phone: +32 2 704 5622
Email: bclaise@cisco.com
8. Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared,
copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright
notice and this paragraph are included on all such copies and
derivative works. However, this document itself may not be
modified in any way, such as by removing the copyright notice or
references to the Internet Society or other Internet
organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or
as required to translate it into.
Expires April 2004 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-23 04:00:52 |