Network Working Group E. Stephan Internet-Draft France Telecom Expires: January 8, 2006 E. Moreau QoSmetrics July 7, 2005 IPFIX templates for common ISP usages draft-stephan-isp-templates-00.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 January 8, 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 January 8, 2006 [Page 1] Internet-Draft IPFIX templates for common ISP usages July 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 4. IPFIX and Netflow V5 . . . . . . . . . . . . . . . . . . . . . 8 5. Template for exporting measurement information . . . . . . . . 9 5.1 Exporting measurement information . . . . . . . . . . . . 10 5.1.1 The Measure Template . . . . . . . . . . . . . . . . . 10 5.1.2 The Result Template . . . . . . . . . . . . . . . . . 11 5.1.3 Example . . . . . . . . . . . . . . . . . . . . . . . 11 5.2 Exporting packet information for delay measurements . . . 12 6. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1 Pseudo Template . . . . . . . . . . . . . . . . . . . . . 13 6.2 Aggregating Netflow using IPFIX . . . . . . . . . . . . . 13 6.3 Data integrity . . . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1 Normative References . . . . . . . . . . . . . . . . . . . 13 8.2 Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . 16 Stephan & Moreau Expires January 8, 2006 [Page 2] Internet-Draft IPFIX templates for common ISP usages July 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 [DrSM05]; o to use IPFIX in middlebox [QuS04]; o Collecting packet information [PoMB05]. 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 [IPFIX_PROTO] 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 January 8, 2006 [Page 3] Internet-Draft IPFIX templates for common ISP usages July 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. [DrSM05] 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. [PoMB05] 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 IPFIX to identify potential interoperability issues between Netflow Stephan & Moreau Expires January 8, 2006 [Page 4] Internet-Draft IPFIX templates for common ISP usages July 2005 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 sectionuses 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 January 8, 2006 [Page 5] Internet-Draft IPFIX templates for common ISP usages July 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 January 8, 2006 [Page 6] Internet-Draft IPFIX templates for common ISP usages July 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 January 8, 2006 [Page 7] Internet-Draft IPFIX templates for common ISP usages July 2005 3.3 IPFIX and Netflow Time Reference Netflow and IPFIX don't use the same reference of time to describe to begin and the end of the flow. Netflow reference of time timestamps the begin and the end of a flow in the fields 'First' and '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'. 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 timestamping method. o It doesn't use option template. So most of the scope data are in the header. A Netflow V5 message may be considered as an IPFIX data set and an option data record. Following is trivial template for Netflow V5. Further studies should propose templates to export information included in Netflow message header. Stephan & Moreau Expires January 8, 2006 [Page 8] Internet-Draft IPFIX templates for common ISP usages July 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5. Template for exporting measurement information ISPs need a common solution to export measurement results and Stephan & Moreau Expires January 8, 2006 [Page 9] Internet-Draft IPFIX templates for common ISP usages July 2005 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 makes of a 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 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 template ID associated with the measure, ResultTemplateID. Stephan & Moreau Expires January 8, 2006 [Page 10] Internet-Draft IPFIX templates for common ISP usages July 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID MT_ID | Field Count = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | measureID | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | metricID | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | methodology | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | resultTemplateID | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NOTE: This basic definition needs to be enhanced to carry the extra information needed to facilitate the understanding of the results sent by one ISP to another. MetricID may correspond to a metric registred in the [METRIC_REGISTRY]. 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. 5.1.2 The Result Template Following is a basic definition of a template that export the results of a measure without the overhead of 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.1.3 Example A passive measurement system needs to export the results of the measure '10' of the one-way-delay '60' to a collector. Firstly it sends the Measure template defined above. Then it exports the following Measure Template record. Stephan & Moreau Expires January 8, 2006 [Page 11] Internet-Draft IPFIX templates for common ISP usages July 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 = MT_ID | Length = 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 10 | 6 (one-way-delay) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 (passive) | 4597 (Result Template ID) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ During the measurement, it sends firstly the Result template defined above and exports, as following, the results in records of Result template. 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. [PoMB05] describes the usage of IPFIX to export per-packet Stephan & Moreau Expires January 8, 2006 [Page 12] Internet-Draft IPFIX templates for common ISP usages July 2005 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. 6. Open issues 6.1 Pseudo Template IPFIX documents specify many pseudo templates that will introduce a lot of interoperability issue. 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. 6.2 Aggregating Netflow using IPFIX IPFIX info model should have one Field ID for each field existing in one Netflow header. 6.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. 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. 8. References 8.1 Normative References [IPFIX_INFO] J. Quittek, S. Bryan, B. Claise, J. Meyer, ""Information Model for IP Flow Information Export", IPFIX WG document, Stephan & Moreau Expires January 8, 2006 [Page 13] Internet-Draft IPFIX templates for common ISP usages July 2005 draft-ietf-ipfix-info-07.txt", 2005. [IPFIX_PROTO] Benoit Claise, ""IPFIX Protocol Specification", IPFIX WG document, draft-ietf-ipfix-protocol-15.txt", 2005. [METRIC_REGISTRY] Emile STEPHAN, "IP Performance Metrics (IPPM) metrics registry, IPPM WG document, draft-ietf-ippm-metrics-registry-08.txt", 2004. 8.2 Informative References [DrSM05] F. Dressler, C. Sommer, G. Muenz, "IPFIX Aggregation", 2005. [NETFLOW_FMT] Cisco, "Netflow format". [PoMB05] G. Pohl, L. Mark, E. Boschi, ""Use of IPFIX for Export of Per-Packet Information", internet-drafts draft-pohl-perpktinfo-02.txt", 2005. [QuS04] J. Quittek, "Guidelines for IPFIX Implementations on Middleboxes", 2004. [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998. [RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring Connectivity", RFC 2678, September 1999. [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999. [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999. [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999. [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining Empirical Bulk Transfer Capacity Metrics", RFC 3148, July 2001. [RFC3357] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample Metrics", RFC 3357, August 2002. Stephan & Moreau Expires January 8, 2006 [Page 14] Internet-Draft IPFIX templates for common ISP usages July 2005 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002. [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network performance measurement with periodic streams", RFC 3432, November 2002. [RFC3763] Shalunov, S. and B. Teitelbaum, "One-way Active Measurement Protocol (OWAMP) Requirements", RFC 3763, April 2004. 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 January 8, 2006 [Page 15] Internet-Draft IPFIX templates for common ISP usages July 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 January 8, 2006 [Page 16]