One document matched: draft-ietf-ipfix-as-09.txt
Differences from draft-ietf-ipfix-as-08.txt
Internet Draft Tanja Zseby
Document: <draft-ietf-ipfix-as-09.txt> Fraunhofer FOKUS
Expires: November 2006 Elisa Boschi
Hitachi
Nevil Brownlee
CAIDA
Benoit Claise
Cisco Systems
June 2006
IPFIX Applicability
draft-ietf-ipfix-as-09.txt
Status of this Memo
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
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
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.
Copyright Notice
Copyright (C) The Internet Society (2006).
Zseby, Boschi, Brownlee, Claise [Page 1]
IPFIX Applicability June 2006
Abstract
This document describes the applicability of the IP Flow
Information Export (IPFIX) protocol for a variety of
applications. It shows how applications can use IPFIX, describes
the relevant information elements (IEs) and shows opportunities
and limitations of the protocol. The document furthermore
describes relations of the IPFIX framework to other
architectures and frameworks.
Zseby, Boschi, Brownlee, Claise [Page 2]
IPFIX Applicability June 2006
Table of Contents
1. Introduction.............................................4
2. Applications of IPFIX....................................4
2.1 Accounting...............................................4
2.1.1 Example.................................................5
2.2 Traffic Profiling........................................7
2.3 Traffic Engineering......................................8
2.4 Network Security.........................................9
2.5 QoS Monitoring..........................................11
2.5.1 Correlating Events from Multiple Observation Points....11
2.5.2 Examples...............................................12
2.6 Inter-Domain Exchange of IPFIX data.....................13
2.7 Export of Derived Metrics...............................14
2.8 Summary.................................................14
3. Relation of IPFIX to Other Frameworks and Protocols.....15
3.1 IPFIX and PSAMP.........................................15
3.2 IPFIX and RMON..........................................16
3.3 IPFIX and IPPM..........................................17
3.4 IPFIX and AAA...........................................17
3.4.1 Connecting via an AAA Client...........................18
3.4.2 Connecting via an Application Specific Module (ASM)....19
3.5 IPFIX and RTFM..........................................20
3.5.1 Architecture...........................................20
3.5.2 Flow Definition........................................20
3.5.3 Configuration and Management...........................21
3.5.4 Data Collection........................................21
3.5.5 Data Model Details.....................................21
3.5.6 Transport Protocol.....................................22
3.5.7 Summary................................................22
4. Limitations.............................................22
4.1 Using IPFIX for other Applications than in RFC3917......23
4.2 Using IPFIX for Billing (Reliability Limitations).......23
4.3 Using a Different Transport Protocol than SCTP..........24
4.4 Push vs. Pull Mode......................................24
4.5 Template ID number......................................25
4.6 Exporting Bidirectional Flow Information................25
4.7 IPFIX and IPv6..........................................25
4.8 Remote Configuration....................................26
5. Security Considerations.................................26
6. IANA Considerations.....................................26
7. Normative References....................................26
8. Informative References..................................27
9. Acknowledgements........................................29
10. Authors' Addresses......................................29
11. Full Copyright Statement................................30
12. Intellectual Property Statement.........................30
13. Copyright Statement.....................................31
14. Disclaimer..............................................31
Zseby, Boschi, Brownlee, Claise [Page 3]
IPFIX Applicability June 2006
1. Introduction
The IPFIX protocol defines how IP Flow information can be
exported from routers, measurement probes or other devices. IP
flow information can be used as input to various applications.
IPFIX is a general data transport protocol, easily extensible to
suit the needs of different applications. This document
describes how typical applications can use the IPFIX protocol.
It shows opportunities and limitations of the protocol.
Furthermore, the relationship of IPFIX to other frameworks and
architectures is described.
2. Applications of IPFIX
IPFIX data enables several critical applications. The IPFIX
target applications and the requirements that originate from
those applications are described in [RFC3917]. Those
requirements were used as basis for the design of the IPFIX
protocol. This section describes how these target applications
can use the IPFIX protocol. Considerations for using IPFIX for
other applications than described in [RFC3917] can be found in
section 4.1.
2.1 Accounting
Usage-based accounting is one of the target applications for
IPFIX as defined in [RFC3917]. IPFIX records provide fine-
grained measurement results for highly flexible and detailed
usage reporting. Such data is often used to realize usage-based
accounting. Nevertheless, IPFIX does not provide the reliability
required by commercial grade billing-systems (see section 4.2).
The accounting scenarios described in this document only provide
limited reliability as explained in section 4.2 and should not
be used in environments where reliability is mandatory.
In order to realize usage-based accounting with IPFIX the flow
definition has to be chosen in accordance to the tariff model.
Flows can be distinguished by various IEs (e.g. packet header
fields) from [IPFIX-INFO]. Due to the flexible IPFIX flow
definition, arbitrary flow-based accounting models can be
realized without extensions to the IPFIX protocol.
A tariff can, for instance, be based on individual end-to-end
flows, in which case accounting can be realized with a flow
definition determined by the quintuple consisting of source
address (sourceIPv4Address), destination address
Zseby, Boschi, Brownlee, Claise [Page 4]
IPFIX Applicability June 2006
(destinationIPv4Address), protocol (protocolIdentifier) and port
numbers (e.g., udpSourcePort, udpDestinationPort). Another
example is a class-dependent tariff (e.g. in a DiffServ
network). In this case flows could be distinguished just by the
DiffServ codepoint (DSCP) (ipDiffServCodePoint) and IP addresses
(sourceIPv4Address, destinationIPv4Address). The essential
elements needed for accounting are the number of transferred
packets and bytes per flow, which can be represented by the per-
flow counter IEs (e.g., packetTotalCount, octetTotalCount).
For accounting purposes, it would be advantageous to have the
ability to use IPFIX flow records as accounting input in an AAA
infrastructure. AAA servers then could provide the mapping
between user and flow information. Again for such scenarios the
limited reliability currently provided by IPFIX has to be taken
into account.
2.1.1 Example
Please note: As noted in [RFC3330] the address block
192.0.2.0/24 may be used for example addresses. In the example
below we use two example networks. In order to be conformant to
[RFC3330] we divide the given address block into two networks by
subnetting with a 25 bit netmask (192.0.2.0/25) as follows:
Network A: 192.0.2.0 ... 192.0.2.127
Network B: 192.0.2.128 ... 192.0.2.255
Let's suppose someone has a Service Level Agreement (SLA) in a
DiffServ network requiring accounting based on traffic volume.
Flows are distinguished by source and destination address. The
information to export in this case is:
- IPv4 source IP address: sourceIPv4Address in [IPFIX-INFO],
with a length of 4 octets
- IPv4 destination IP address: destinationIPv4Address in
[IPFIX-INFO], with a length of 4 octets
- DSCP: ipDiffServCodePoint in [IPFIX-INFO], with a length of
1 octet
- Number of octets of the Flow: octetDeltaCount in [IPFIX-
INFO], with a length of 4 octets
The template set will look as follows:
Zseby, Boschi, Brownlee, Claise [Page 5]
IPFIX Applicability June 2006
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 24 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 256 | Field Count = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4Address = 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv4Address = 12 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| ipDiffServCodePoint = 195 | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| octetDeltaCount = 1 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The information to be exported might be as listed in the
following example table:
Src. IP addr. | Dst. IP addr. | DSCP | Octets Number
--------------+---------------+--------+--------------
192.0.2.12 | 192.0.2.144 | 46 | 120868
192.0.2.24 | 192.0.2.156 | 46 | 310364
192.0.2.36 | 192.0.2.168 | 46 | 241239
In the example we use Diffserv CodePoint 46, recommended for the
Expedited Forwarding Per Hop Behavior (EF PHB) in [RFC2598].
The Flow Records will then look as follows:
Zseby, Boschi, Brownlee, Claise [Page 6]
IPFIX Applicability June 2006
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 256 | Length = 43 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.144 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 46 | 120868 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 192.0.2.24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 192.0.2.156 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 46 | 310364 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 192.0.2.36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 192.0.2.168 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 46 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 241239 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.2 Traffic Profiling
Measurement results reported in IPFIX records can be used for
traffic profiling. IPFIX records captured over a long period of
time can be used to track and anticipate network growth and
usage. Such Information is valuable for trend analysis and
network planning.
The parameters of interest are determined by the profiling
objectives. Example parameters for traffic profiling are flow
duration, flow volume, burstiness, the distribution of used
services and protocols, the amount of packets of a specific
type, etc. [RFC3917].
The distribution of services and protocols in use can be
analyzed by configuring appropriate flows keys for flow
discrimination. Protocols can be distinguished by the
protocolIdentifier IE. Portnumbers (e.g., udpDestinationPort)
often provide information about services in use. Those flow keys
are defined in [IPFIX-INFO]. If portnumbers are not sufficient
for service discrimination, further parts of the packet may be
needed. Header fields can be expressed by IEs from [IPFIX-INFO]
Zseby, Boschi, Brownlee, Claise [Page 7]
IPFIX Applicability June 2006
Packet payload can be reported by using the IE
ipPayloadPacketSection in [PSAMP-INFO].
The flow duration can be calculated from the flow time stamp IEs
defined in [IPFIX-INFO] (e.g., flowEndMicroseconds -
flowStartMicroseconds). The number of packets and number of
bytes of a flow are represented in the per-flow counter IEs
(e.g., packetTotalCount, octetTotalCount). The burstiness of a
flow can be calculated from the flow volume measured at
different time intervals.
2.3 Traffic Engineering
Traffic engineering aims at the optimization of network resource
utilization and traffic performance [RFC2702]. Typical
parameters are link utilization, load between specific network,
nodes, number, size and entry/exit points of active flows and
routing information [RFC3917].
Size of flows in packets and bytes can be reported by IEs
packetTotalCount, octetTotalCount. Physical link utilization can
be reported by using a coarse grained flow definition (e.g.
based on identifier IEs such as egressInterface or
ingressInterface) and per-flow counter IEs (e.g.
packetTotalCount, octetTotalCount) defined in [IPFIX-INFO].
The load between specific network nodes can be reported in the
same way if one interface of a network node receives only
traffic from exactly one neighbor node (as is usually the case).
If the ingress interface is not sufficient for an unambiguous
identification of the neighbor node, sub-IP header fields IEs
(like sourceMacAddress) can be added as flow keys.
The IE observedFlowTotalCount provides the number of all flows
exported for the observation domain since the last
initialization of the metering process [IPFIX-INFO]. If this IE
is exported at subsequent points in time, one can derive the
number of active flows in a specific time interval from the
difference of the reported counters. The configured flow
termination criteria have to be taken into account to interpret
that numbers correctly.
Entry and exit points can be derived from flow records if
metering processes are installed at all edges of the network and
results are mapped in accordance to flow keys. For this and
other analysis methods that require the mapping of records from
different observation points, the same flow keys should be used
at all observation points. The path that packets take through a
Zseby, Boschi, Brownlee, Claise [Page 8]
IPFIX Applicability June 2006
network can be investigated by using hash-based sampling
techniques as described in [DuGr00] and [PSAMP-TECH]. For this
IEs from [PSAMP-INFO] are needed.
Neither [IPFIX-INFO] nor [PSAMP-INFO] defines IEs suitable for
exporting routing information.
2.4 Network Security
Attack and intrusion detection are among the IPFIX target
applications described in [RFC3917]. Due to the enormous amount
of different network attack types, only general requirements
could be addressed in [RFC3917].
IPFIX can export flow information for arbitrary flow definitions
as defined in [IPFIX-PROTO]. Packet information can be exported
with IPFIX by using the additional information elements
described in [PSAMP-INFO]. With this theoretically all
information about traffic in the network at IP layer and above
is accessible. This data can be used either directly to detect
anomalies or can provide the basis for further post processing
to generate more complex attack detection metrics.
Depending on the attack type different metrics are useful. A
sudden increase of traffic load can be a hint that an attack has
been launched. The overall traffic at an observation point can
be monitored using per-flow counter IEs like packetTotalCount,
octetTotalCount as described in 2.3. The number of active flows
can be monitored by regular reporting of the
observedFlowTotalCount.
A sudden increase of flows from different sources to one
destination may be caused by an attack on a specific host or
network node using spoofed addresses. Many flows to the same
machine but on different ports or many flows to the same port
and different machines may be an indicator for vertical or
horizontal port scanning activities. An unusual ratio of TCP-SYN
to TCP-FIN packets can refer to SYN-flooding. Worms may leave
signatures in traffic patterns. Detecting such events requires
more detailed measurements and post processing than detecting
simple changes in traffic volumes
The amount of metrics useful for attack detection is as diverse
as attack patterns themselves. Attackers adapt rapidly to
circumvent detection methods and try to hide attack patterns
using slow or stealth attacks. Furthermore, unusual traffic
patterns are not always caused by malicious activities. A sudden
traffic increase may be caused by legitimate users who seek
Zseby, Boschi, Brownlee, Claise [Page 9]
IPFIX Applicability June 2006
access to a recently published content. Strange traffic patterns
may also be caused by mis-configuration.
The difficult task is the separation of good from bad packets to
prepare and launch counteraction. This may require a deeper look
into packet content by using further header field IEs from
[IPFIX-INFO] and/or packet payload from IE
ipPayloadPacketSection in [PSAMP-INFO]. Multi-step analysis
techniques may be useful, e.g., to launch an in-depth analysis
(e.g. based on packet information) in case the flow information
shows suspicious patterns. In order to supervise traffic to a
specific host or network node one has to apply filtering methods
as those described in [PSAMP-TECH].
Mapping the two directions of a communication is often useful
for checking correct protocol behavior (see section 4.6). A
correlation of IPFIX data from multiple observation points (see
section 2.5.1) allows assessing the propagation of an attack and
can help to locate its source.
The integration of previous measurement results helps to review
traffic changes over time for detection of traffic anomalies and
provides the basis for forensic analysis. A standardized storage
format for IPFIX data would support the offline analysis of data
from different operators.
Nevertheless, capturing full packet traces at all observation
points in the network is not viable due to resource limitations
and privacy concerns. Therefore metrics should be chosen wisely
to allow a solid detection with minimal resource consumption.
Resources can be saved for instance by using coarser grained
flow definitions, reporting pre-processed metrics (e.g. with
additional information elements) or deployment of sampling
methods.
Detecting security incidents in real-time often requires the
pre-processing of data already at the measurement device. That
means that measured data need to be processed already in the
measurement device in order to generate useful metrics for
detecting an attack as early as possible. Immediate data export
in case of a potential incident is desired. IPFIX supports such
source-triggered exporting of information due to the push model
approach. Nevertheless, further exporting criteria have to be
implemented to export IPFIX records upon incident detection
events and not only upon flow end or fixed time intervals.
Security incidents can become a threat to IPFIX processes
themselves (see also security considerations in [IPFIX-PROTO]).
Zseby, Boschi, Brownlee, Claise [Page 10]
IPFIX Applicability June 2006
If an attack generates a large amount of flows (e.g. by sending
packets with spoofed addresses or simulating flow termination)
exporting and collecting process may get overloaded by the
immense amount of records that are exported. A flexible
deployment of packet or flow sampling methods can prevent the
exhaustion of resources.
Intrusion detection would profit from the combination of IPFIX
functions with AAA functions (see section 3.4). Such an
interoperation enables further means for attacker detection,
advanced defense strategies and secure inter-domain cooperation.
2.5 QoS Monitoring
QoS monitoring is one target application of the IPFIX protocol
[RFC3917]. QoS monitoring is the passive observation of the
transmission quality for single flows or traffic aggregates in
the network. One example of its use is the validation of QoS
guarantees in service level agreements (SLAs). Typical QoS
parameters are loss [RFC2680], one-way [RFC2679] and round-trip
delay [RFC2681] and delay variation [RFC3393]. The calculation
of those QoS metrics requires per-packet processing. Reporting
packet information with IPFIX is possible by simply considering
a single packet as flow. [IPFIX-PROTO] also allows the reporting
of multiple identical information elements in one flow record.
Using this feature for reporting information about multiple
packets in one record would require additional agreement on
semantics regarding the order of information elements (e.g.
which timestamp belongs to which packet payload in a sequence of
information elements). [PSAMP-INFO] defines useful additional
information elements for exporting per packet information with
IPFIX.
2.5.1 Correlating Events from Multiple Observation Points
Some QoS metrics require the correlation of data from multiple
observation points. For this the clocks of the involved metering
processes must be synchronized. Furthermore, it is necessary to
recognize that the same packet was observed at different
observation point.
This can be done by capturing parts of the packet content
(packet header and/or parts of the payload) that do not change
on the way to the destination. Based on the packet content it
can be recognized when the same packet arrived at another
observation point. To reduce the amount of measurement data a
unique packet ID can be calculated from the packet content e.g.
by using a CRC or hash function instead of transferring and
Zseby, Boschi, Brownlee, Claise [Page 11]
IPFIX Applicability June 2006
comparing the unprocessed content. Considerations on collision
probability and efficiency of using such packet IDs are
described in [GrDM98, DuGr00, ZsZC01].
IPFIX allows the reporting of several IP and transport header
fields (see section 5.3 and 5.4 in [IPFIX-INFO]). Using only
those fields for packet recognition or ID generation can be
sufficient in scenarios where those header fields vary a lot
among subsequent packets, where a certain amount of packet ID
collisions is tolerable or where packet IDs need to be unique
only for a small time interval.
For including packet payload information the information element
ipPayloadPacketSection defined in [PSAMP-INFO] can be used. The
information element ipHeaderPacketSection can also be used. But
header fields that can change on the way from source to
destination have to be excluded from the packet ID generation,
because they may differ at different observation points.
For reporting packet IDs generated by a CRC or hash function the
information element digestHashValue defined in [PSAMP-INFO] can
be used.
2.5.2 Examples
The following examples show which information elements need to
be reported by IPFIX to generate specific QoS metrics. As an
alternative the metrics can be generated directly at the
exporter and IPFIX can be used to export the metrics (see
section 2.7)
2.5.2.1 RTT measurements with packet pair matching (single-point)
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 such as DNS, ICMP, SNMP or TCP (SYN/SYN_ACK,
DATA/ACK) are utilized to passively observe the RTT [Brow00].
This technique requires the correlation of data from both
directions.
Required information elements per packet (DNS example):
- Packet arrival time: observationTimeMicroseconds [PSAMP-INFO]
- DNS header: ipPayloadPacketSection [PSAMP-INFO]
Required functions:
- Recognition of request/response packet pairs
Zseby, Boschi, Brownlee, Claise [Page 12]
IPFIX Applicability June 2006
Remarks:
- Requires information elements from [PSAMP-INFO]
- observationTimeMicroseconds can be substituted by
flowStartMicroseconds [IPFIX-INFO], because a single packet
can be represented as a flow.
- If time values with a finer granularity are needed
observationTimeNanoseconds can be used.
2.5.2.2 One-way Delay Measurements (multi-point)
Passive one-way-delay measurements require the collection of
data at two observation points. As mentioned above synchronized
clocks are needed to avoid time-differences at the involved
observation points.
The recognition of packets at the second observation point can
be based on parts of the packet content directly. A more
efficient way is to use a packet ID (generated from packet
content).
Required information elements per packet (with packet ID):
- Packet arrival time: observationTimeMicroseconds [PSAMP-INFO]
- Packet ID: digestHashValue [PSAMP-INFO]
Required functions:
- packet ID generation
- delay calculation (from arrival times at the two observation
points)
Remarks:
- Requires information elements from [PSAMP-INFO]
- observationTimeMicroseconds can be substituted by
flowStartMicroseconds [IPFIX-INFO], because a single packet
can be represented as a flow.
- If time values with a finer granularity are needed
observationTimeNanoseconds can be used.
- The amount of content used for ID generation influences the
number of collisions (different packets that map to the same
ID) that can occur. Investigations on this and other
considerations on packet ID generation can be found in
[GrDM98], [DuGr00], and [ZsZC01].
2.6 Inter-Domain Exchange of IPFIX data
IPFIX data can be used to share information with neighbor
providers. A few recommendations should to be considered if
IPFIX records travel over the public Internet compared to its
usage within a single domain. First of all, security threat
Zseby, Boschi, Brownlee, Claise [Page 13]
IPFIX Applicability June 2006
levels are higher if data travels over the public Internet.
Protection against disclosure or manipulation of data is even
more important than for intra-domain usage. Therefore IPsec or
Transport Layer Security (TLS) should be used as described in
[IPFIX-PROTO].
Furthermore data transfer should be congestion-aware in order to
allow untroubled co-existence with other data flows. That means
transport over SCTP or TCP is required.
Some ISPs are still reluctant to share information due to
concerns that competing ISPs might exploit network information
from neighbor providers to strengthen their own position in the
market. Nevertheless, technical needs have already triggered the
exchange of data in the past (e.g. exchange of routing
information by BGP). The need to provide inter-domain guarantees
is one big incentive to increase inter-domain cooperation. The
necessity to defend networks against current and future threats
(denial of service attacks, worm distributions, etc.) will
hopefully increase the willingness to exchange measurement data
between providers.
2.7 Export of Derived Metrics
The IPFIX protocol is used to transport flow and packet
information to provide the input for the calculation of a
variety metrics (e.g. for QoS validation or attack detection).
IPFIX can also be used to transfer these metrics directly, e.g.
if the metric calculation is co-located with measurement and
exporting process.
It doesn't matter which measurement and post-processing
functions are applied to generate a specific metric. IPFIX can
be used to transport the results from passive and active
measurements and from post-processing operations. For the
reporting of derived metrics additional information elements
need to be defined.
2.8 Summary
The following table shows an overview of the information
elements required for the target applications described in
[RFC3917] (M-mandatory, R-recommended, O-optional).
Zseby, Boschi, Brownlee, Claise [Page 14]
IPFIX Applicability June 2006
| Application |[IPFIX-INFO]| [PSAMP-INFO] | additional IEs |
+-------------+------------+--------------+-----------------+
| Accounting | M | - | - |
+-------------+------------+--------------+-----------------+
| Traffic | M | O | - |
| Profiling | | | |
+-------------+------------+--------------+-----------------+
| Traffic | M | - | O |
| Engineering | | | (routing info) |
+-------------+------------+--------------+-----------------+
| Attack | M | R | R |
| Detection | | |(derived metrics)|
+-------------+------------+--------------+-----------------+
| QoS | M | M | O |
| Monitoring | |(most metrics)|(derived metrics)|
+-------------+------------+--------------+-----------------+
For accounting the IEs in [IPFIX-INFO] are sufficient.
Nevertheless as mentioned above, the reliability currently
supported by IPFIX is not sufficient for commercial-grade
billing systems (see section 4.2). For traffic profiling
additionally IEs from [PSAMP-INFO] can be useful to gain more
insight into the traffic. For traffic engineering flow
information from [IPFIX-INFO] is sufficient but it would profit
from routing information, which could be exported by IPFIX.
Attack detection usually profits from further insight into the
traffic. This can be achieved with IEs from [PSAMP-INFO].
Furthermore the reporting of derived metrics in additional IEs
would be useful. Most QoS metrics require the use of IEs from
[PSAMP-INFO]. IEs from [PSAMP-INFO]are also useful for the
mapping of results from different observation points as
described in section 2.5.1.
3. Relation of IPFIX to Other Frameworks and Protocols
3.1 IPFIX and PSAMP
PSAMP defines packet selection methods, their configuration at
routers and probes and the reporting of packet information.
PSAMP uses IPFIX as basis for exporting packet information
[PSAMP-PROTO]. [PSAMP-INFO] describes further information
elements for exporting packet information and reporting
configuration information.
The main difference between IPFIX and PSAMP is that IPFIX
addresses the export of flow records whereas PSAMP addresses the
export of packet records. Furthermore, PSAMP explicitly
Zseby, Boschi, Brownlee, Claise [Page 15]
IPFIX Applicability June 2006
addresses remote configuration. It defines a MIB for the
configuration of packet selection processes. Remote
configuration is not (yet) addressed in IPFIX, but one could
consider extending the PSAMP MIB to also allow configuration of
IPFIX processes.
3.2 IPFIX and RMON
RMON [RFC3577] is a widely used monitoring system that gathers
traffic data from RMON Agents in network devices. One major
difference between RMON and IPFIX is that RMON uses SNMP for
data export whereas IPFIX defines an own push-oriented protocol.
RMON defines MIBs that contain the information to be exported.
In IPFIX the data to be exported is defined as information
elements.
The most relevant MIBs for a comparison with IPFIX are the
Application Performance Measurement MIB (APM-MIB) [RFC3729] and
the Transport Performance Metrics MIB (TPM-MIB) [RFC4150].
The APM-MIB has a complex system for tracking user application
performance, with reporting about transactions and SLA threshold
notification-trigger configuration, and persistence across DHCP
lease expirations. It requires full RMON2-MIB protocolDirTable
implementation.
The APM-MIB reports the performance of transactions. A
transaction is a service oriented term and describes the data
exchange from the transaction start (when a user requests a
service) until its completion. The performance parameters
include response times, throughput, streaming responsiveness and
availability of services.
The RMON transaction concept differs from the IPFIX flow
concept. A flow is a very generic term and allows to group IP
packets in accordance to common properties. In contrast to
this, the term transaction is service-oriented and contains all
data exchange required for service completion.
In order to report such data with IPFIX one would probably need
a specific combination of multiple flows and the ability to map
those to the transaction. Due to the service-orientated focus of
APM, also the required metrics differ. For instance, the RMON
APM requires a metric for the responsiveness of services. Such
metrics are not addressed in IPFIX.
Furthermore, the APM-MIB allows the configuration of the
transaction type to be monitored, i.e., it addresses the
configuration of the metering process, which is currently not
addressd in IPFIX.
Zseby, Boschi, Brownlee, Claise [Page 16]
IPFIX Applicability June 2006
The APM MIB could be considered as an extension of the IPFIX
metering process where the application performance of a
combination of multiple flows is measured. If appropriate IEs
would be defined in the IPFIX information model and the IPFIX
device would support the APM MIB data collection, the solutions
could be complimentary. That means one could use IPFIX to export
APM MIB transaction information.
The TPM-MIB breaks out the APM-MIB transactions into sub-
application level transaction. For instance a web request is
broken down into DNS, TCP and HTTP sub-transactions. Again sub-
application level transaction could be measured using IPFIX with
an appropriate flow definition and by combining the reporting of
both directions of the data transfer (for reporting bi-
directional flow information see also section 4.6). The TPM-MIB
requires APM-MIB and RMON2-MIB.
3.3 IPFIX and IPPM
The IPFIX protocol can be used to carry IPPM network performance
metrics or information that can be used to calculate those
metrics (see sections 2.5 and 2.7 for details and references).
3.4 IPFIX and AAA
AAA defines a protocol and architecture for authentication,
authorization and accounting for service usage [RFC2903]. The
DIAMETER protocol [RFC3588] is used for AAA communication, which
is needed for network access services (Mobile IP, NASREQ, and
ROAMOPS). The AAA architecture [RFC2903] provides a framework
for extending AAA support to 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. DIAMETER is used for the transfer of accounting
records. In order to form accounting records for usage-based
accounting measurement data from the network is required. IPFIX
defines a protocol to export such data from routers, measurement
probes and other devices. Therefore it looks promising to
connect those two architectures.
For all scenarios described here one has to keep the limited
reliability of IPFIX in mind (section 4.2). In order to provide
input for commercial-grade billing, IPFIX requires some
extensions for the reliable transport of data. Using IPFIX
without extensions together with AAA would result in accounting
scenarios with limited capabilities not sufficient for
commercial-grade billing.
Zseby, Boschi, Brownlee, Claise [Page 17]
IPFIX Applicability June 2006
As shown in section 2.1 accounting applications can directly
incorporate an IPFIX collecting process to receive IPFIX records
with information about the transmitted volume. Nevertheless, if
an AAA infrastructure is in place, the cooperation between IPFIX
(and especially IPFIX with reliability extensions) and AAA
provides many valuable synergistic benefits. IPFIX records can
provide the input for AAA accounting functions and provide the
basis for the generation of DIAMETER accounting records.
Further potential features include the mapping of a user ID to
flow information (by using authentication information) or
facilitating the secure authorized exchange of DIAMETER
accounting records with neighbor domains. The last feature is
especially useful in roaming scenarios where the user connects
to a foreign network and the home provider generates the
invoice.
Coupling an IPFIX collecting process with AAA functions has also
high potential for intrusion and attack detection. AAA controls
network access and maintains data about users and nodes. AAA
functions can help to identify the source of malicious traffic.
Authorization functions are able to deny access to suspicious
users or nodes. Therefore coupling those functions with an IPFIX
collecting process can provide an efficient defense against
network attacks. Sharing IPFIX records (either directly or
encapsulated in DIAMETER) with neighbor providers allows an
efficient inter-domain attack detection. The AAA infrastructure
can also be used to configure measurement functions in the
network as proposed in [RFC3334].
Two possibilities exist to connect IPFIX and AAA:
- Connecting via an AAA Client
- Connecting via an Application Specific Module (ASM)
Both are explained in the following sections. The approaches
only require few additional functions. They do not require any
changes to IPFIX or DIAMETER.
3.4.1 Connecting via an AAA Client
One possibility of connecting 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).
Zseby, Boschi, Brownlee, Claise [Page 18]
IPFIX Applicability June 2006
+---------+ DIAMETER +---------+
| AAA-S |------------->| AAA-S |
+---------+ +---------+
^
| DIAMETER
|
|
+--+--------+--+
| | AAA-C | |
+ +--------+ |
| |
| Collector |
+--------------+
^
| IPFIX
|
+------------+
| Exporter |
+------------+
Figure 2: IPFIX collector connects to AAA server via AAA client
3.4.2 Connecting 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.
Zseby, Boschi, Brownlee, Claise [Page 19]
IPFIX Applicability June 2006
+---------+ DIAMETER +---------+
| AAA-S |------------->| AAA-S |
+---------+ +---------+
^
|
+------------------+
| ASM |
| +------------+ |
| | Collector | |
+------------------+
^
| IPFIX
|
+------------+
| Exporter |
+------------+
Figure 3: IPFIX connects to AAA server via ASM
3.5 IPFIX and RTFM
The Real-time Traffic Flow Measurement (RTFM) working group
defined an architecture for flow measurement [RFC2722]. This
section compares the Real-time Traffic Flow Measurement (RTFM)
framework with the IPFIX framework.
3.5.1 Architecture
The RTFM architecture is very similar to the IPFIX architecture.
It defines meter, meter reader and a manager as building blocks
of the measurement architecture. The manager configures the
meter and the meter reader collects data from the meter.
In RTFM the building blocks communicate via SNMP.
The IPFIX architecture [IPFIX-ARCH] defines metering, exporting
and collecting processes. IPFIX speaks about processes instead
of devices to clarify that multiple of those processes may be
collocated on the same machine.
Both definitions do not contradict each other. One could see the
metering process as part of the meter and the collecting process
as part of the meter reader.
One difference is that IPFIX currently does not define a
managing process, because remote configuration was at least
initially out of scope for the working group.
3.5.2 Flow Definition
Zseby, Boschi, Brownlee, Claise [Page 20]
IPFIX Applicability June 2006
RTFM and IPFIX both consider flows as a group of packets which
share a common set of properties. A flow is completely specified
by that set of values, together with a termination criterion
(like inactivity timeout).
A difference is that RTFM defines flows as bidirectional. An
RTFM meter matches packets from B to A and A to B as separate
parts of a single flow, and maintains two sets of packet and
byte counters, one for each direction.
IPFIX does not explicitly state whether flows are uni- or
bidirectional. Nevertheless information elements for describing
flow properties were defined only for one direction in [IPFIX-
INFO]. Nevertheless, there are several solutions for reporting
bi-directional flow information (see section 4.6).
3.5.3 Configuration and Management
In RTFM, remote configuration is the only way to configure a
meter. This is done by using SNMP and a specific Meter MIB
[RFC2720]. The IPFIX group currently does not address IPFIX
remote configuration.
IPFIX metering processes export the layout of data within their
templates, from time to time. IPFIX collecting processes use
that template information to determine how they should interpret
the IPFIX flow data they receive.
3.5.4 Data Collection
One major difference between IPFIX and RTFM is the data
collection model. RTFM retrieves data in pull mode whereas IPFIX
uses a push mode model to send data to collecting processes.
An RTFM meter reader pulls data from a meter by using SNMP. SNMP
security on the meter determines whether a reader is allowed to
pull data from it. An IPFIX exporting process is configured to
export records to a specified list of IPFIX collecting
processes. The condition when to send IPFIX records (e.g. flow
termination) has to be configured in the exporting or metering
process.
3.5.5 Data Model Details
RTFM defines all its attributes in the RTFM Meter MIB [RFC2720].
IPFIX information elements are defined in [IPFIX-INFO].
Zseby, Boschi, Brownlee, Claise [Page 21]
IPFIX Applicability June 2006
RTFM uses continuously-incrementing 64-bit counters for the
storage of the number of packets of a flow. The counters are
never reset and just wrap back to zero if the maximum value is
exceeded. Flows can be read at any time. The difference between
counter readings gives the counts for activity in the interval
between readings.
IPFIX allows absolute (totalCounter) and relative counters
(deltaCounter) [IPFIX-INFO]. The totalCounter is never reset and
just wraps to zero if values are too large, exactly as the
counters used in RTFM. The deltaCounter is reset to zero when
the associated flow record is exported.
3.5.6 Transport Protocol
RTFM has a standards-track Meter MIB [RFC2720], which is used
both to configure a meter and to store metering results. The
MIB provides a way to read lists of attributes with a single
Object Identifier (called a 'package'), which reduces the SNMP
overhead for flow 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.
IPFIX is designed to work over a variety of different transport
protocols. SCTP [RFC2960] and SCTP-PR [RFC3758] are mandatory.
UDP and TCP are optional. In addition, the IPFIX protocol
encodes data much more efficiently than SNMP does, hence IPFIX
has lower data transport overheads than RTFM.
3.5.7 Summary
IPFIX exports flow information in push model by using SCTP, TCP
or UDP. It currently does not address remote configuration. RTFM
data collection is using the pull model and runs over SNMP. RTFM
addresses remote configuration which also runs over SNMP. Both
frameworks allow a very flexible flow definition, although RTFM
is based on a bi-directional flow definition.
4. Limitations
The goal of this section is to show the limitations of IPFIX and
to give advice where not to use IPFIX or in which cases
additional considerations are required.
Zseby, Boschi, Brownlee, Claise [Page 22]
IPFIX Applicability June 2006
4.1 Using IPFIX for other Applications than in RFC3917
IPFIX provides a generic export mechanism. Due to its template
based structure, it is a quite flexible protocol. Network
operators and users may want to use it also for other
applications than those described in [RFC3917].
Apart from sending raw flow information it can be used to send
aggregated or post-processed data. For this new templates and
information elements can be defined if needed. Due to its push
mode operation IPFIX is also suited to send network initiated
events like alarms and other notifications. It can be used for
exchanging information among network nodes to autonomously
improve network operation.
Nevertheless, the IPFIX design is based on the requirements that
originate only from the target applications stated in [RFC3917].
Using IPFIX for other purposes requires a careful checking of
IPFIX capabilities against application requirements. Only with
this, can one decide whether IPFIX is a suitable protocol to
meet the needs of a specific application.
4.2 Using IPFIX for Billing (Reliability Limitations)
The reliability requirements defined in [RFC3917] are not
sufficient to guarantee the level of reliability that is needed
for commercial grade billing systems. Such reliability
requirements are discussed in [RFC2975]. In particular IPFIX
does not support the following features required by [RFC2975]:
- Record loss: IPFIX allows the usage of different transport
protocols for the transfer of data records. Resilience against
the loss of IPFIX data records can be only provided if TCP or
SCTP-PR is used for the transfer of data records.
- Network or device failures: IPFIX does allow the usage of
multiple collectors for one exporter, but it does neither
specify nor demand the usage of multiple collectors for the
provisioning of fault tolerance.
- Detection and elimination of duplicate records: This is
currently not supported by IPFIX.
- Application layer acknowledgements: IPFIX does not support the
control of measurement and exporting processes by higher level
applications. Application layer acknowledgements are necessary
e.g. to inform the exporter in case the application is not
able to process the data exported with IPFIX. Such
acknowledgements are not supported in IPFIX.
Zseby, Boschi, Brownlee, Claise [Page 23]
IPFIX Applicability June 2006
Further features like archival accounting and pre-authorization,
are out of scope of the IPFIX specification but need to be
realized in billing system architectures as described in
[RFC2975].
4.3 Using a Different Transport Protocol than SCTP
SCTP is the preferred protocol for IPFIX, i.e. a conforming
implementation must work over SCTP. Although IPFIX can also work
over TCP or UDP, both protocols have drawbacks [IPFIX-PROTO].
Users should make sure they have good reasons befor using
protocols other than SCTP in a specific environment.
4.4 Push vs. Pull Mode
IPFIX works in push mode. That means IPFIX records are
automatically exported without waiting for a request.
The responsibility for initiating a data export lies with the
exporting process.
Criteria for exporting data need to be configured at the
exporting process. Therefore push mode has more benefits if the
trigger for data export is related to events at the exporting
process (e.g. flow termination, memory shortage due to large
amount of flows, etc.). If the protocol used pull mode, the
exporting process would need to wait for a request to send the
data. With push mode it can send data immediately e.g. before
memory shortage would require a discarding of data.
With push mode one can prevent the overloading of resources at
the exporting process by simply exporting the information as
soon as certain thresholds are about to be exceeded. Therefore
exporting criteria are often related to traffic characteristics
(e.g. flow timeout) or resource limitations (e.g. size of flow
cache). But traffic characteristics are usually quite dynamic
and often impossible to predict. If those are used to trigger
flow export, the exporting rate and the resource consumption for
flow export becomes variable and unpredictable.
Pull mode has advantages if the trigger for data export is
related to events at the collecting process (e.g. a specific
application requests immediate input).
In a pull mode, a request could simply be forwarded to the
exporting process. In a push mode, the exporting configuration
must be changed to trigger the export of the requested data.
Furthermore, with pull mode one can prevent the overloading of
Zseby, Boschi, Brownlee, Claise [Page 24]
IPFIX Applicability June 2006
the collecting process by the arrival of more records than it
can process.
Whether this is a relevant drawback depends on the flexibility
of the IPFIX configuration and how IPFIX configuration rules are
implemented.
4.5 Template ID number
The IPFIX specification limits the different template ID numbers
that can be assigned to the newly generated template records in
an observation domain. In particular, template IDs up to 255 are
reserved for Template or option sets (or other sets to be
created) and template IDs from 256 to 65535 are assigned to data
sets. In the case of many exports requiring many different
templates, the set of Template IDs could be exhausted.
4.6 Exporting Bidirectional Flow Information
Although IPFIX does not explicitly state that flows are
unidirectional, information elements that describe flow
characteristics are defined only for one direction in [IPFIX-
INFO]. [IPFIX-PROTO] allows the reporting of multiple identical
information elements in one flow record. With this information
elements for forward and reverse direction can be reported in
one flow record.
But this is not sufficient. Using this feature for reporting
bidirectional flow information would require an agreement on the
semantic of information elements (e.g. first counter is counter
for the forward direction, second counter for reverse
direction).
Another option is to use two adjacent flow records to report
both directions of a bidirectional flow separately. This
approach requires additional means for mapping those records and
is quite inefficient due to the redundant reporting of flow
keys.
4.7 IPFIX and IPv6
There are two issues to consider:
- Generation and reporting of IPFIX records about IPv6 traffic
- Exporting IPFIX records over IPv6
Zseby, Boschi, Brownlee, Claise [Page 25]
IPFIX Applicability June 2006
The generation and reporting of IPFIX records about IPv6 traffic
is possible as appropriate information elements exist in [IPFIX-
INFO].
Exporting IPFIX records over IPv6 is not explicitly addressed in
[IPFIX-PROTO]. Since IPFIX runs over SCTP, SCTP-PR, UDP or TCP,
it is trivial to run IPFIX over IPv6 networks, provided that the
transport protocol being used to carry IPFIX is running on the
IPv6 network.
4.8 Remote Configuration
Remote configuration was initially out of scope of the IPFIX
working group in order to concentrate on the protocol
specification. Therefore there is currently no standardized way
to configure IPFIX processes remotely. Nevertheless due to the
broad need for this feature, it is quite likely that solutions
for this will be standardized soon.
5. Security Considerations
This document describes the usage of IPFIX in various scenarios.
Security requirements for IPFIX target applications and security
considerations for IPFIX are addressed in [RFC3917] and [IPFIX-
PROTO]. Those requirements have to be met for the usage of
IPFIX. To our current knowledge, the usage scenarios proposed in
section 2 do not induce further security hazards.
Section 3 of this document describes how IPFIX can be used in
combination with other technologies. New security hazards can
arise when two individually secure technologies or architectures
are combined. For the combination of AAA with IPFIX an
application specific module (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.
6. IANA Considerations
This document has no actions for IANA.
7. Normative References
[IPFIX-INFO] J. Quittek, S. Bryant, J. Meyer, "Information Model
for IP Flow Information Export", Internet Draft
<draft-ietf-ipfix-info-07>, work in progress, May
2005
Zseby, Boschi, Brownlee, Claise [Page 26]
IPFIX Applicability June 2006
[IPFIX-PROTO] B. Claise (Editor), "IPFIX Protocol Specification",
Internet Draft <draft-ietf-ipfix-protocol-21.txt>,
work in progress, April 2006
[PSAMP-INFO] T. Dietz, F. Dressler, G. Carle, B. Claise,
"Information Model for Packet Sampling Exports",
Internet Draft <draft-ietf-psamp-info-04.txt>, work
in progress, March 2006
[RFC3917] J. Quittek, T. Zseby, B. Claise, S. Zander,
"Requirements for IP Flow Information Export", RFC
3917, October 2004
8. Informative References
[Brow00] Nevil Brownlee, "Packet Matching for NeTraMet
Distributions",
http://www2.auckland.ac.nz/net//Internet/rtfm/meeti
ngs/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
[IPFIX-ARCH] G. Sadasivan, N. Brownlee, B. Claise, J. Quittek,
"Architecture for IP Flow Information Export",
Internet Draft <draft-ietf-ipfix-architecture-
08.txt>, work in progress, March 2005
[PSAMP-PROTO] Benoit Claise (Ed.), Packet Sampling (PSAMP)
Protocol Specifications, Internet Draft <draft-
ietf-psamp-protocol-04.txt>, work in progress,
March 2006
[PSAMP-TECH] T. Zseby, M. Molina, N. Duffield, S. Niccolini, F.
Raspall, "Sampling and Filtering Techniques for IP
Packet Selection" Internet Draft <draft-ietf-psamp-
sample-tech-07.txt>, work in progress, July 2005
[RFC2598] V. Jacobson, K. Nichols, K. Poduri, "An Expedited
Forwarding PHB", RFC 2598, June 1999
Zseby, Boschi, Brownlee, Claise [Page 27]
IPFIX Applicability June 2006
[RFC2679] G. Almes, S. Kalidindi, M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, September 1999
[RFC2680] G. Almes, S. Kalidindi, M. Zekauskas, "A One-way
Packet Loss Metric for IPPM",RFC 2680, September
1999
[RFC2681] G. Almes, S. Kalidindi, M. Zekauskas, "A Round-trip
Delay Metric for IPPM", RFC 2681, September 1999
[RFC2702] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J.
McManus, "Requirements for Traffic Engineering Over
MPLS", RFC 2702, September 1999
[RFC2720] N. Brownlee, Traffic Flow Measurement: Meter MIB,
RFC2720 October 1999
[RFC2722] Brownlee, N., Mills, C., G. Ruth, "Traffic Flow
Measurement: Architecture", RFC 2722, October 1999
[RFC2903] C. de Laat, G. Gross, L. Gommans, J. Vollbrecht, D.
Spence, "Generic AAA Architecture", RFC 2903,
August 2000
[RFC2960] R. Stewart (ed.) "Stream Control Transmission
Protocol", RFC 2960, October 2000
[RFC2975] B. Aboba, J. Arkko, D. Harrington, "Introduction to
Accounting Management", RFC 2975, October 2000
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330
September 2002
[RFC3334] T. Zseby, S. Zander, G. Carle, "Policy-Based
Accounting", RFC 3334, October 2002
[RFC3393] C. Demichelis, P. Cimento, "IP Packet Delay
Variation Metric for IPPM", RFC 3393, November 2002
[RFC3577] S. Waldbusser, R. Cole, C. Kalbfleisch,
D.Romascanu, "Introduction to the Remote Monitoring
(RMON) Family of MIB Module", RFC 3577, August 2003
[RFC3588] P. Calhoun, J. Loughney, E. Guttman, G. Zorn, J.
Arkko, "Diameter Base Protocol", RFC 3588,
September 2003
Zseby, Boschi, Brownlee, Claise [Page 28]
IPFIX Applicability June 2006
[RFC3729] S. Waldbusser, "Application Performance Measurement
MIB", RFC 3729, March 2004
[RFC3758] R. Stewart, M. Ramalho, Q. Xie, M. Tuexen, P.
Conrad, "Stream Control Transmission Protocol
(SCTP) Partial Reliability Extension", RFC 3758,
May 2004
[RFC4150] R. Dietz, R. Cole, "Transport Performance Metrics
MIB", RFC 4150, August 2005
[ZsZC01] T. Zseby, S. Zander, G. 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
9. Acknowledgements
We would like to thank the following persons for their
contribution, discussion on the mailing list and valuable
comments:
Sebastian Zander
Robert Loewe
Reinaldo Penno
Lutz Mark
Andy Biermann
Part of the work has been developed in the research project 6QM
co-funded with support from the European Commission.
10.Authors' 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
Elisa Boschi
Hitachi Europe SAS
Immeuble Le Theleme
1503 Route des Dolines
06560 Valbonne, France
Phone: +33 4 89874180
Email: elisa.boschi@hitachi-eu.com
Zseby, Boschi, Brownlee, Claise [Page 29]
IPFIX Applicability June 2006
Nevil Brownlee
CAIDA (UCSD/SDSC)
9500 Gilman Drive
La Jolla, CA 92093-0505
Phone : +1 858 534 8338
Email : nevil@caida.org
Benoit Claise
Cisco Systems
De Kleetlaan 6a b1
1831 Diegem
Belgium
Phone: +32 2 704 5622
Email: bclaise@cisco.com
11.Full Copyright Statement
"Copyright (C) The Internet Society (2006). 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.
12. 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
Zseby, Boschi, Brownlee, Claise [Page 30]
IPFIX Applicability June 2006
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.
13. Copyright Statement
Copyright (C) The Internet Society (2006). 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.
14. Disclaimer
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.
Zseby, Boschi, Brownlee, Claise [Page 31]
| PAFTECH AB 2003-2026 | 2026-04-23 04:08:07 |