Subject: RE: [ippm] traceroute as WG work item? IPFIX traceroute records

From: "STEPHAN Emile RD-CORE-LAN" <[email-masked]>
Date: Tue, 29 Mar 2005 11:43:14 +0200

Hi Juergen and Lutz

What we experienced with the IPPM MIB is that measures generate a lot of data. So the binary format is the best for collecting. 

Traceroute Field Types do not differ from Per Packet Field Types (draft-pohl-perpktinfo-02.txt) or from IPPM Field Types, especially if we include spatial and multicast metrics (dratf-stephan-ippm-multimetrics-00.txt). 

Moreover most of these fields are already defined as illustrated by the example I sent. So it appears very fast and very easy to define in IPFIX a common info model and a common set of templates to export results of IPPM measures, traceroute measures and 'Per Packet' measures. 

Regarding traceroute metric I propose to try to design this metric using the IPPM framework and terminology (RFC2330), and then to present it to the IPPM WG. At large this document may include metrics definitions of middlebox one-way delay and jitter corresponding to 'Per Packet' measurement technique. 

To sum up I propose to write 2 drafts:
	The fist one defines in the IPFIX WG common templates for exporting measure results;
	The second one defines in the IPPM WG traceroute and middlebox metrics.

Regards
Emile

-----Message d'origine-----
De : Juergen Quittek [mailto:[email-masked]] 
Envoyé : lundi 28 mars 2005 03:06
À : STEPHAN Emile RD-CORE-LAN
Cc : [email-masked]; [email-masked]
Objet : RE: [ippm] traceroute as WG work item? IPFIX traceroute records

Emile,

Thanks for your comments!

The basic issue I raised was whether or not the standardization
of an information model and data model for traceroute results would
be a work item for the IPPM WG.

Do I understand correctly from your message that,
  1. yes, it should be standardized,
  2. but not necessarily in the IPPM WG?

Concerning the discussion at IPPM whether we should use a binary
or an XML-based format for traceroute results, I interpret your
message as support for a binary format.

I think your thoughts open an interesting discussion on transmitting
traceroute results in IPFIX records.  Probably, this issue is worth
mentioning it in the IPFIX applicability statement.

Also, the issue should be considered by the information model discussions
in IPFIX and PSAMP.

Thanks,

    Juergen
-- 
Juergen Quittek        [email-masked]       Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de

--On 23.03.2005 18:30 h +0100 STEPHAN Emile RD-CORE-LAN wrote:

> Hi Juergen,
>
> My thinking is that we might use IPFIX to export the traceroute results.
>
>
> What about using 2 templates: one for the measure and another one for 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
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|         FlowSet ID = 0        |       Length = xx bytes       |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|               256             |       Field Length = 4        |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|    FlowID (e.g. measure ID)   |       Field Length = 4        |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
>|    sourceIPv4Address          |      Field Length = 4         | Src
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|  destinationIPv4Address       |        Field Length = 4       | Dst
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> 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 = xx bytes       |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|               257             |       Field Length = 4        |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|    FlowID (e.g. measure ID)   |       Field Length = 4        |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|    SampleID                   |       Field Length = 4        |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Src UDP
>|   flowStartMicroSeconds       |      Field Length =  8        | pkts time
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|   flowEndDeltaUSeconds        |      Field Length =  4        | Troute RTT
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|    destinationIPv4Address     |        Field Length = 4       | Hop Addr
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
> This is compact and is very close to what describes Guido draft (draft-pohl-perpktinfo-02.txt).
>
> We need only to define a new Field Type named 'SampleID' (named PacketID in Guido document).
>
> Regards
> Emile
>
> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part de Juergen Quittek
> Envoyé : mardi 15 mars 2005 12:09
> À : [email-masked]
> Objet : Re: [ippm] traceroute as WG work item?
>
> The I-D is still missing a data model, because there is no
> consensus yet on the mailing list about whether to use an
> XML-based data model or a more compact one.
> Please find some pro and con arguments at
> http://people.internet2.edu/~matt/IPPM/Meetings/ietf62/ippm-2005-03-07-traceroute.pdf
>
> Thanks,
>
>     Juergen
>
> --On 15.03.2005 11:15 +0100 Juergen Quittek wrote:
>
>> Dear all,
>>
>> Unfortunately, there was no discussion on traceroute storage during
>> our last meeting. Therefore I bring this issue to the mailing list.
>>
>> There is an I-D describing an information model for traceroute records:
>> http://www.ietf.org/internet-drafts/draft-niccolini-ippm-storetraceroutes-00.txt
>>
>> This work was initiated by the development of a database for traffic
>> measurement tools and traces, see  http://www.ist-mome.org/database/
>>
>> Currently, there is no standard way of exchanging traceroute
>> measurements except for the DISMAN-TRACEROUTE-MIB module (RFC2925).
>> But this can only be used for transferring measurement data from an
>> SNMP agent to its manager(s).  It is not useful for exchange between
>> traffic measurement tools.
>>
>> A standardized record format for traceroute measurements would be
>> very useful for building tools, databases and other applications
>> that handle traceroute measurements and need to exchange them.
>>
>> Therefore I propose that this becomes an IPPM WG work item.
>> Any comment, pro or con, is very welcome.
>>
>> Thanks,
>>
>>     Juergen
>> --
>> Juergen Quittek        [email-masked]       Tel: +49 6221 90511-15
>> NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
>> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de
>>
>> _______________________________________________
>> ippm mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/ippm
>
>
>
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ippm

_______________________________________________
ippm mailing list
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ippm

---

From: Benoit Claise <[email-masked]>
Date: Wed, 30 Mar 2005 23:30:19 +0200

Emile,

If there is a need to push some IPPM data to a NMS (as opposed to pull 
the data with SNMP), then the IPFIX protocol makes perfect sense as it 
is efficient and flexible.
BTW, this is described in the IPFIX applicability draft 
(http://www.ietf.org/internet-drafts/draft-ietf-ipfix-as-04.txt)

    2.7  SLA validation...........................................8 
    2.8  Traffic Monitoring.......................................8 
    2.8.1 Measurement of Round-trip-time (RTT)....................9 
    2.8.2 Measurement of One-way-delay (OWD)......................9 
    2.8.3 Measurement of One-way-loss (OWL)......................10 
    2.8.4 Measurement of IP delay variation (IPDV)...............10 
    3.3 IPFIX and IPPM 

Note that this draft speaks of passive measurements as opposed to active measurements in IPPM.
However, from the pure IPFIX protocol point of view, the measurement mechanism is not relevant.

Regards, Benoit.