[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/