[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Submission of individual draft-stephan-isp-templates-01.txt
This is an update of the individual draft draft-stephan-isp-templates.
Abstract:
Flows and packets observations require several levels of
aggregations. Currently switchs and routers analyse flows and export
flow information using Netflow. Aggregators are starting to use
Netflow or IPFIX to collect basic information and to export
aggregated information and proposes to standardize a set of
templates to facilitate the exchange of flows and measurements
information between ISP.
Regards
Emile
Network Working Group E. Stephan
Internet-Draft France Telecom
Expires: April 23, 2006 E. Moreau
QoSmetrics
October 20, 2005
IPFIX templates for common ISP usages
draft-stephan-isp-templates-01.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.
This Internet-Draft will expire on April 23, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Flows and packets observations require several levels of
aggregations. Currently switchs and routers analyse flows and export
flow information using Netflow. Aggregators are starting to use
Netflow or IPFIX to collect basic information and to export
aggregated information.
In this context, this memo presents potential interoperability issues
Stephan & Moreau Expires April 23, 2006 [Page 1]
Internet-Draft IPFIX templates for common ISP usages October 2005
and proposes to standardize a set of templates to facilitate the
exchange of flows and measurements information between ISP.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivations for IPFIX templates definitions . . . . . . . . . 3
2.1 Interoperability between IPFIX and Netflow versions . . . 3
2.2 Interoperability between IPFIX Implementations . . . . . . 3
2.3 Collecting Aggregated flows information . . . . . . . . . 4
2.4 Collecting packet information . . . . . . . . . . . . . . 4
2.5 Collecting measurement information . . . . . . . . . . . . 4
3. IPFIX and Netflow interoperability . . . . . . . . . . . . . . 4
3.1 Netflow messages headers fields . . . . . . . . . . . . . 5
3.2 Netflow data records fields . . . . . . . . . . . . . . . 6
3.3 IPFIX and Netflow Time Reference . . . . . . . . . . . . . 8
3.4 Converting Netflow flow times to absolute time . . . . . . 8
4. IPFIX and Netflow V5 . . . . . . . . . . . . . . . . . . . . . 8
5. Template for exporting measurement information . . . . . . . . 10
5.1 Exporting measurement information . . . . . . . . . . . . 10
5.1.1 The Measure Template . . . . . . . . . . . . . . . . . 10
5.1.2 The context of the measure Template . . . . . . . . . 11
5.1.3 The Configuration Template . . . . . . . . . . . . . . 12
5.1.4 The Result Template . . . . . . . . . . . . . . . . . 12
5.1.5 Example . . . . . . . . . . . . . . . . . . . . . . . 13
5.2 Exporting packet information for delay measurements . . . 14
6. change since v00 . . . . . . . . . . . . . . . . . . . . . . . 15
7. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1 Too many Pseudo Templates in IPFIX specs . . . . . . . . . 15
7.2 Aggregating Netflow using IPFIX . . . . . . . . . . . . . 15
7.3 Data integrity . . . . . . . . . . . . . . . . . . . . . . 15
7.4 Path Template . . . . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1 Normative References . . . . . . . . . . . . . . . . . . . 15
9.2 Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . 18
Stephan & Moreau Expires April 23, 2006 [Page 2]
Internet-Draft IPFIX templates for common ISP usages October 2005
1. Introduction
This memo defines a set of IPFIX templates for common ISP usages.
The content of this memo is built on notions introduced and discussed
in documents of the WG IPFIX, PSAMP and IPPM. The reader should be
familiar with these documents.
2. Motivations for IPFIX templates definitions
Netflow is massively deployed by ISP. Consequently the potential of
usage of IPFIX in the context of an ISP is very large.
There are already a lot of contributions at the door of IETF which
are directly related with this document:
o to aggregate flows information [I-D.dressler-ipfix-aggregation];
o to use IPFIX in middlebox [I-D.quittek-ipfix-middlebox];
o Collecting packet information [I-D.boschi-export-perpktinfo].
2.1 Interoperability between IPFIX and Netflow versions
To provide the first level of aggregation IFPIX must interoperate
with existing Netflow versions. This memo presents the different
headers and records format then it presents potential
interoperability issues and proposes a set of templates.
2.2 Interoperability between IPFIX Implementations
IPFIX documents don't standardize any templates. They specify many
kind of pseudo templates with pseudo field ID.
That will lead to different templates and consequently to
interoperability issues. So it is necessary to define a set of
templates to increase interoperability.
As an example the intend of the section 4.3" of [I-D.ietf-ipfix-
protocol] is to standardize an option template that describe
"Exporting Process Reliability Statistics". Actually it doesn't.
The fields 'Exporting Process ID', 'time first flow dropped' and
'time last flow dropped' are not fields identifiers. Actually their
value must be picked up in a set of 3 or 4 fields. In the real world
that will lead to 30 different "Exporting Process Reliability
Statistics" templates.
Stephan & Moreau Expires April 23, 2006 [Page 3]
Internet-Draft IPFIX templates for common ISP usages October 2005
2.3 Collecting Aggregated flows information
ISP are using Netflow and IPFIX for different usages. One of them is
to exchange aggregated flow information with their costumers or with
other ISP. They need standard templates to exchange aggregated
information. [I-D.dressler-ipfix-aggregation] presents the
aggregation aspect but does not proposes any template.
So, despite it is not possible to define every king of flow
aggregation, this memo defines templates for existing flow
aggregation such as Netflow V8.
2.4 Collecting packet information
PSAMP WG defines capabilities to sample packets in a way to support
measurement.
[I-D.boschi-export-perpktinfo] defines a method to collect packets
information to measure instantaneous one-way delays without injecting
test traffic. It gives some direction to export packet information
using IPFIX but does not define the templates needed to collect
packets information.
2.5 Collecting measurement information
Measurement systems produce on the fly results at a rate that make
them impossible to be polled. One solution consists in using IPFIX
to export measures results and statistics.
To export such information in an interoperability way it is necessary
to use standard templates. Moreover it is possible to define common
templates for active and passive techniques. The benefit is to
permit the collection of measurement information independently of the
technique used while having the information to precisely indicated
the metric performed.
3. IPFIX and Netflow interoperability
IPFIX and Netflow usages require several level of aggregation. The
first level of flows description combines Netflow and IPFIX sources.
Aggregators receives these descriptions either to aggregate and
reexport them, or to process them locally. it appears that the first
level of collector requires the capability to collect flows
descriptions from both Netflow and IPFIX implementations.
Consequently that requires a strong interoperability between Netflow
and IPFIX exporters and collectors.
This section compares the headers and the messages of Netflow and
Stephan & Moreau Expires April 23, 2006 [Page 4]
Internet-Draft IPFIX templates for common ISP usages October 2005
IPFIX to identify potential interoperability issues between Netflow
and IPFIX exporters and collectors.
To identify interoperability issues the study considers a trivial
Netflow/IPFIX proxy which collects Netflow packets and reexport them
in IPFIX.
NOTE WELL: This comparison is based on IPFIX documents available at
the beginning of June 2005. They have been updated since this date.
This section uses the following conventions.
S: Size
in byte,
or indicated (e.g. 64k)
L: location:
H: Message Header
R: record
S: Set header
V: Netflow Version
*: all
!x: not version x
3.1 Netflow messages headers fields
This section classifies each Netflow header field in term of Size,
Location and of presence in Netflow Versions. Then it identifies
Netflow fields which match directly an IPFIX field.
IPFIX header is a sub set of Netflow header. It does not include the
fields 'count', 'engine_type', 'SysUptime' and 'unix_nsecs' of
Netflow versions.
Stephan & Moreau Expires April 23, 2006 [Page 5]
Internet-Draft IPFIX templates for common ISP usages October 2005
+------------------------------+--------------------------------+
| Netflow | IPFIX |
+-------------------+---+-+----+--------------------------+---+-+
| name | S |L| V | name | S |L|
+-------------------+---+-+----+--------------------------+---+-+
| version | 1 |H| * | version | 1 |H|
+-------------------+---+-+----+--------------------------+---+-+
| count | 2 |H| * |No field found | - |-|
+-------------------+---+-+----+--------------------------+---+-+
| No field found | - |-| - | Length | 2 |H|
+-------------------+---+-+----+--------------------------+---+-+
| SysUptime | 4 |H| * |No field found | - |-|
+-------------------+---+-+----+--------------------------+---+-+
| unix_secs | s |H| * |Export Time | s |H|
+-------------------+---+-+----+--------------------------+---+-+
| unix_nsecs | s |H|!V9 |No field found | ? |?|
+-------------------+---+-+----+--------------------------+---+-+
| flow_sequence | 4 |H| !V9|totalFlowCount | 4 |F|
+-------------------+---+-+----+--------------------------+---+-+
| FLOWS | 4 |F| V9 |totalFlowCount | 4 |F|
+-------------------+---+-+----+--------------------------+---+-+
| Sequence Number| 4 |H| V9 |Sequence Number | 4 |H|
+-------------------+---+-+----+--------------------------+---+-+
| engine_type | 1 |H|V5,8| No field found | - |-|
+-------------------+---+-+----+--------------------------+---+-+
| engine_id | 1 |H|V5,8| sourceId | 4 |H|
+-------------------+---+-+----+--------------------------+---+-+
| ENGINE_TYPE | 1 |F| V9 |No field found | - |-|
+-------------------+---+-+----+--------------------------+---+-+
| ENGINE_ID | 1 |F| V9 | sourceId | 4 |F|
+-------------------+---+-+----+--------------------------+---+-+
|sampling mode, | | | | | | |
|interval | 2 |H| V5 | No field found | - |-|
+-------------------+---+-+----+--------------------------+---+-+
|SAMPLING_INTERVAL | 4 |F| V9 | No field found | - |-|
+-------------------+---+-+----+--------------------------+---+-+
|SAMPLING_ALGORITHM | 1 |F| V9 | No field found | - |-|
+-------------------+---+-+----+--------------------------+---+-+
3.2 Netflow data records fields
At this step, this section integrates only Netflow V5 record fields.
This section classifies each Netflow record field in term of Size,
Location and of presence in Netflow Versions. Then it identifies
Netflow fields which match directly an IPFIX field.
Stephan & Moreau Expires April 23, 2006 [Page 6]
Internet-Draft IPFIX templates for common ISP usages October 2005
+------------------------------+--------------------------------+
| Netflow | IPFIX |
+-------------------+---+-+----+--------------------------+---+-+
| name | S |L| V | name | S |L|
+-------------------+---+-+----+--------------------------+---+-+
| srcaddr | 4 |F| V5 |sourceIpV4Address | 4 |F|
+-------------------+---+-+----+--------------------------+---+-+
| dstaddr | 4 |F| V5 |destinationIpV4Address | 4 |F|
+-------------------+---+-+----+--------------------------+---+-+
| nextHop | 4 |F| V5 |ipNextHopIpV4Address | 4 |F|
+-------------------+---+-+----+--------------------------+---+-+
| input | 4 |F| V5 |ingressInterface | 4 |F|
+-------------------+---+-+----+--------------------------+---+-+
| output | 4 |F| V5 | egressInterface | 4 |F|
+-------------------+---+-+----+--------------------------+---+-+
| dPkts | 4 |F| V5 |inPacketTotalCount | 4 |F|
+-------------------+---+-+----+--------------------------+---+-+
| dOctets | 4 |F| V5 |inOctetTotalCount | 4 |F|
+-------------------+---+-+----+--------------------------+---+-+
| First | 4 |F| V5 |flowStartMilliSec | 4 |F|
+-------------------+---+-+----+--------------------------+---+-+
| Last | 4 |F| V5 |flowEndMilliMSec | 4 |F|
+-------------------+---+-+----+--------------------------+---+-+
| srcport | 2 |F| V5 |sourceTransportPort | 2 |F|
+-------------------+---+-+----+--------------------------+---+-+
| dstport | 2 |F| V5 |destinationTransportPort | 2 |F|
+-------------------+---+-+----+--------------------------+---+-+
| pad1 | 4 |F| V5 |not applicable | 4 |F|
+-------------------+---+-+----+--------------------------+---+-+
| TcpFlags | 1 |F| V5 | tcpControlBits | 1 |F|
+-------------------+---+-+----+--------------------------+---+-+
| Proto | 1 |F| V5 |protocolIdentifier | 1 |F|
+-------------------+---+-+----+--------------------------+---+-+
| Tos | 4 |F| V5 |classOfServiceIpV4 | 4 |F|
+-------------------+---+-+----+--------------------------+---+-+
| SrcAS | 4 |F| V5 |bgpSourceAsNumber | 4 |F|
+-------------------+---+-+----+--------------------------+---+-+
| DstAS | 4 |F| V5 |bgpDestinationAsN | 4 |F|
+-------------------+---+-+----+--------------------------+---+-+
| SrcMask | 4 |F| V5 |sourceIpV4Mask | 4 |F|
+-------------------+---+-+----+--------------------------+---+-+
| DstMask | 4 |F| V5 |destinationIpV4Mask | 4 |F|
+-------------------+---+-+----+--------------------------+---+-+
| Pad2 | 4 |F| V5 | not applicable | 4 |F|
+-------------------+---+-+----+--------------------------+---+-+
Stephan & Moreau Expires April 23, 2006 [Page 7]
Internet-Draft IPFIX templates for common ISP usages October 2005
3.3 IPFIX and Netflow Time Reference
Netflow and IPFIX don't use the same reference of time to describe
the begin and the end of the flow. Netflow timestamps the begin of
the flow in the field 'First' and the end of a flow in the field
'Last' using 'SysUpTime' relative clock.
The fields 'unix_secs' and 'unix_nsecs' of the Netflow V5 header
provide a relation between absolute time (since 0000 UTC Jan 1st
1970) and 'sysUptime' relative time (reboot time). IPFIX info model
defines the fields types flowStartMilliSeconds and
flowEndMilliMSeconds as absolute time (since 0000 UTC Jan 1st 1970)
of the begin and of the end of a flow. So the fields 'First' and
'Last' may be converted to flowStartMilliSeconds and
flowEndMilliMSeconds. The consequence is that IPFIX encoding will
take 2 times more bytes.
Netflow V5 header field 'unix_secs' corresponds to IPFIX header field
'Export Time'.
3.4 Converting Netflow flow times to absolute time
Follwing is a proposal to convert Netflow 'First' and 'Last' to the
absolute reference of time used by IPFIX:
o flowStartMilliSeconds = ('unix_secs' * 1000) + 'unix_nsecs'/
1000000 - 'sysUptime' + 'First';
o flowEndMilliSeconds = ('unix_secs' * 1000) + 'unix_nsecs'/1000000
- 'sysUptime' + 'Last'.
4. IPFIX and Netflow V5
This section discusses mapping issues and proposes templates to map
NetflowV5 on IPFIX.
Netflow V5 differs from IPFIX.
o It exports sampling method and sampling rate in the message
header;
o It does not use the same time reference;
o It doesn't use option template. So most of the scope data are in
the header.
Following is trivial template for Netflow V5.
Stephan & Moreau Expires April 23, 2006 [Page 8]
Internet-Draft IPFIX templates for common ISP usages October 2005
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FlowSet ID = 0 | Length = 53 bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 257 | Field Count = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sourceIpV4Address(8) | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destinationIpV4Address(12) | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ipNextHopIpV4Address(15) | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ingressInterface(10) | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| egressInterface(14) | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| inPacketTotalCount(86) | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| inOctetTotalCount(85) | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First(SysUptime)(*) | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last(SysUptime) (*) | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sourceTransportPort(7) | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destinationTransportPort(11) | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| tcpControlBits(6) | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| protocolIdentifier(4) | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| classOfServiceIpV4(5) | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| bgpSourceAsNumber(16) * | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| bgpDestinationAsNumber(17)* | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sourceIpV4Mask(9) | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destinationIpV4Mask(13) | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Actually this template is not applicable directly. It needs to be
adapted. Several approaches may be used or mixed depending of the
transport reliability, the number of sources of flows received...The
approach proposed below focus on an NetflowV5 translator which
Stephan & Moreau Expires April 23, 2006 [Page 9]
Internet-Draft IPFIX templates for common ISP usages October 2005
received flows from several routers and export them using IPFIX. The
tranport protocol is UDP:
o Before sending the record 'First' and 'Last' should be translated
to absolute time using the reference of time of the router;
o EngineID and type should be translated in an IPFIX IE: TBD;s
o Sampling rate and method should be translated to IPFIX IEs: TBD.
5. Template for exporting measurement information
ISPs need a common solution to export measurement results and
statistics. This section defines templates to export measurement
results and measurement statistics metered either by a passive or an
active measurement systems.
5.1 Exporting measurement information
This section defines template to export measurement results produced
either using passive or active measure.
Regarding ISP, the main benefit is to collect measurement information
independently of the technique used while having the information to
precisely indicated the metric performed.
A trivial solution consists in standardizing a single template made
up of measure parameters and measure results. Actually such an
approach repeats the measure parameters in each record. Consequently
it is not applicable because it does not benefit of the optimization
IPFIX offers.
To avoid this repetition, the proposal defines a Measure Template to
carry the linkage between the measure parameters and the template
used to export the measure results. Practically, the exporter sends
the Measure Template and a record of Measure Template that carries
the measure parameters and the template ID of the result template
which will carry this measurement results. Then it sends the result
template and it exports the results of this measure in records of
Result Template.
5.1.1 The Measure Template
The "Measure Template" carries the linkage between the measureID and
the "Measure Result Template" ID
The Measure Template has a standard template ID (MT_ID) to permit its
Stephan & Moreau Expires April 23, 2006 [Page 10]
Internet-Draft IPFIX templates for common ISP usages October 2005
identification by the collector as the description of a measure. It
carries management information such as measureID, metricID,
methodology, and the value of the dynamic templates ID associated
with the measure, ResultTemplateID and ConfigurationTemplateID.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID MT_ID | Field Count = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| measureID | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| metricID | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MeasureContextTemplateID | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ConfigurationTemplateID | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| resultTemplateID | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MetricID corresponds to a metric registered in the RFC 4148
[RFC4148]. The benefit of using a registered is to permit the
collection of measurement information independently of the technique
used while having the information to precisely indicated the metric
performed. the first 1k values are reserved for the registry. Other
values are considered as specific or proprietary.
5.1.2 The context of the measure Template
Following is a basic definition of a template that describe the
measure configuration. It carries information needed to facilitate
the understanding of the results sent by one ISP to another.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FlowSet ID 0 | Length = yy bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MeasureContextTemplateID | Field Count = X |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| accuracy | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value of the field accuracy give the accuracy of the measure.
Stephan & Moreau Expires April 23, 2006 [Page 11]
Internet-Draft IPFIX templates for common ISP usages October 2005
Notes: This template has to be completed with usual measure context
information. Such information is typically described in the document
defining the metric. As an example, sections 3.8 of [RFC2679]
details the information to report with the metric.
5.1.3 The Configuration Template
Following is a basic definition of a template that describe the
measure configuration. It carries information needed to facilitate
the understanding of the results sent by one ISP to another.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FlowSet ID 0 | Length = yy bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ConfigurationTemplateID | Field Count = X |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| methodology | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value of the field methodology is either 1 for 'active' or 2 for
'passive' measurement.
Notes: This template has to be completed with usual measure
parameters (source...).
5.1.4 The Result Template
Following is a basic definition of a template that export the results
of a measure without any overhead to carry the measure parameters and
identifiers.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FlowSet ID 0 | Length = 16 bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ResultTemplateID | Field Count = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| result | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Stephan & Moreau Expires April 23, 2006 [Page 12]
Internet-Draft IPFIX templates for common ISP usages October 2005
5.1.5 Example
A passive measurement system needs to export the results of the
measure '10' of the one-way-delay '6' to a collector. Firstly it
sends the Measure template defined above. Then it exports the
following Measure data set.
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 = MT_ID | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6 (one-way-delay) | 315 (MeasureContextTemplateID)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|463 (Configuration Template ID)| 4597 (Result Template ID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
During the measurement, it sends firstly the Configuration and the
Result templates defined above. Then it exports, as following, the
configuration record and the corresponding results.
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 = 315 | Length = xxx |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 50 (accuraccy) | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 463 | Length = xxx |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 (passive) | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Stephan & Moreau Expires April 23, 2006 [Page 13]
Internet-Draft IPFIX templates for common ISP usages October 2005
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 = 4597 | Length = xxx |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4575688568345 |
+ +
| 7875224045765 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4575688668345 |
+ +
| 7875224045765 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4575688868345 |
+ +
| 43783224046765 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2 Exporting packet information for delay measurements
Passive measurement of the delay need to push packets' id and
packets' observation time to concentrators which compute the delay.
[I-D.boschi-export-perpktinfo] describes the usage of IPFIX to export
per-packet information to a collecting process which compute the one-
way delay.
Its proposal relies on 2 templates too. The first one defines the
linkage between flow information and flow ID. The second defines the
results to be exported, the timestamp, the packet ID, the packet
length and the flow ID.
the usage of the 2 templates described above optimizes
PacketPropTemplate size. The field flowID is no more necessary
because the result template ID carries the identifier of the flow.
Stephan & Moreau Expires April 23, 2006 [Page 14]
Internet-Draft IPFIX templates for common ISP usages October 2005
6. change since v00
Time conversion algo proposed.
Measure Template enhanced: conf and context template ID added.
7. Open issues
7.1 Too many Pseudo Templates in IPFIX specs
IPFIX documents specify many pseudo templates that will introduce a
lot of interoperability issues. To solve this issue a field ID
should accept several Field ID in its definition. The template sent
will indicate the one used. This approach is close to the size
reducing mechanism.
7.2 Aggregating Netflow using IPFIX
IPFIX info model should have one Field ID for each field existing in
one Netflow header or conversion rules.
7.3 Data integrity
How to avoid IPFIX information to be corrupted by the network, by DoS
attackers, lost of packets ? Which protocol to use in which case?
Is there others mechanisms which are applicable ? Does it make sense
to introduce a checksum field ID to protect a data record ?
7.4 Path Template
This template is a common need for decribing traceroute and spatial
results.
8. Security Considerations
Security is a MUST in the context of exchange of information between
ISP.
As the security of the exchange relies mostly on the protocol used,
UDP does not look appropriate to exchange information between ISP.
9. References
9.1 Normative References
[I-D.ietf-ipfix-info]
Quittek, J., "Information Model for IP Flow Information
Export", draft-ietf-ipfix-info-11 (work in progress),
Stephan & Moreau Expires April 23, 2006 [Page 15]
Internet-Draft IPFIX templates for common ISP usages October 2005
September 2005.
[I-D.ietf-ipfix-protocol]
Claise, B., "IPFIX Protocol Specification",
draft-ietf-ipfix-protocol-19 (work in progress),
September 2005.
[RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics
Registry", BCP 108, RFC 4148, August 2005.
9.2 Informative References
[I-D.boschi-export-perpktinfo]
Boschi, E. and L. Mark, "Use of IPFIX for Export of Per-
Packet Information", draft-boschi-export-perpktinfo-00
(work in progress), June 2005.
[I-D.dressler-ipfix-aggregation]
Dressler, F., "IPFIX Aggregation",
draft-dressler-ipfix-aggregation-01 (work in progress),
July 2005.
[I-D.quittek-ipfix-middlebox]
Quittek, J., "Guidelines for IPFIX Implementations on
Middleboxes", draft-quittek-ipfix-middlebox-00 (work in
progress), February 2004.
[I-D.stephan-ippm-multimetrics]
Stephan, E., "IP Performance Metrics (IPPM) for spatial
and multicast", draft-stephan-ippm-multimetrics-01 (work
in progress), July 2005.
[NETFLOW_FMT]
Cisco, "Netflow format".
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330,
May 1998.
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, September 1999.
Stephan & Moreau Expires April 23, 2006 [Page 16]
Internet-Draft IPFIX templates for common ISP usages October 2005
Authors' Addresses
Stephan Emile
France Telecom division R&D
2 avenue Pierre Marzin
Lannion, F-22307
Fax: +33 2 96 05 18 52
Email: emile.stephan@francetelecom.com
Moreau Eric
QoSmetrics EMEA
3-7 Rue du Theatre
Massy, F-91300
Fax: +33 1 64 53 27 61
Email: eric_moreau@qosmetrics.net
Stephan & Moreau Expires April 23, 2006 [Page 17]
Internet-Draft IPFIX templates for common ISP usages October 2005
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.
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 (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Stephan & Moreau Expires April 23, 2006 [Page 18]