Internet Draft G. Pohl Document: Fraunhofer FOKUS Expires: January 2005 L. Mark Fraunhofer FOKUS E. Boschi Fraunhofer FOKUS July 2004 Use of IPFIX for Export of Per-Packet Information Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract This document describes the usage of the IP Flow Information Export (IPFIX) protocol for the case of exporting and processing per-packet information by means of IPFIX. The main idea is to export two types of records per flow: one type that consists of the usual flow information plus a unique flow identifier; and a second type of record that consists of the actual per-packet information plus a flow identifier that refers to the flow the specific packet belongs to -- that means the flow identifier is used to associate the packet data to its corresponding flow. Pohl, Mark, Boschi Expires January 2005 [Page 1] Use of IPFIX for Export of Per-Packet Information Table of Contents 1. Introduction.................................................2 2. Terminology..................................................2 3. General Problem Statement....................................3 4. Processing Per-Packet Data for One-Way Delay Measurements....5 5. Security Considerations......................................6 6. References...................................................7 7. Author's Addresses...........................................7 8. Full Copyright Statement.....................................8 1. Introduction In the scope of passive QoS Measurements there is often the need to exchange and export measurement data in a finer granularity then per flows. This draft takes passive one-way delay measurement as an example when demonstrating the need for information export on a per-packet basis. The IPFIX protocol has been designed to export flow records. To use IPFIX to export packet records one can export flow records containing information about single packets. This method is used by PSAMP [Cla204]. But exporting flow related information per- packet introduces a high degree of redundancy. This draft shows how packet information and flow information can be efficiently exported and related. 2. Terminology Collecting Process The collecting process receives records of flow or packet information. The data is stored for later processing (by the calculation process) Exporting Process The exporting processes send flow and packet records to the collecting processes. The records are generated by the measurement process. Filtering Filtering selects a subset of packets by applying deterministic functions on parts of the packet content like header fields or parts of the payload. A filtering process needs to process the packet (look at packet header and/or payload) in order to make the selection decision. Measurement Device A measurement device has access to at least one observation point. It is hosting at least one measurement process and one export process. Pohl, Mark, Boschi Expires January 2005 [Page 2] Use of IPFIX for Export of Per-Packet Information Metering/Measurement Process The measurement process generates records of packet and flow information. Packets passing the observation point are captured, time stamped, filtered and classified. The measurement process calculates the packet Ids. Passive One-Way-Delay Measurement Abbreviated: POWD Measurement 3. General Problem Statement In [Cla104] the IPFIX working group defined an exporting protocol for measurement data and flow information export. The initial purpose of the protocol is to exchange information about network traffic flows. In this scope a flow is defined by a handful of key attributes (source/destination address, source/destination port, Layer3 Protocol Type, TOS/DSCP byte, interface of the flow exporting network element). In this sense, a flow is a collection of packets that share a set of common attributes. However, for a number of measurements (metrics) there is a need to export per-packet data. As a case in point we mention passive One-Way-Delay measurements. In order to acquire a one-way path delay information, two measurement points û with synchronized clocks - must be set up, one at either end of the path under examination. Both measurement points will capture packets, assign them timestamps and generate an identifier for identifying a packet passing both measurement points. Each measurement point will export its measurement data (trace) to a collecting process where the traces are correlated based on the packet identifiers and timestamps and where finally the delay is calculated as a difference of two timestamps of a packet pair. Undoubtedly a single packet could be considered a special case of a flow and thus, per-packet information could be exported using flow records. Doing this though would have consequences on the efficiency of the exporting procedure, as it would mean additional overhead. Packets belonging to the same flow share common attributes, i.e. source address, destination address, etc. Exporting these attributes on a per-packet basis, each time with a different packet ID, would be redundant information. There are cases where it is desirable to keep flow information along with the per-packet information, that is, when analyzing packet characteristics while observing flows. The upper part of Figure 1 shows export records containing packet information plus flow information (source and destination address). Undoubtedly, the flow information introduces a huge Pohl, Mark, Boschi Expires January 2005 [Page 3] Use of IPFIX for Export of Per-Packet Information amount of redundancy, as it exists for every packet. Figure 1 depicts three packets that affiliate to flow A and one packet that belongs to flow B, respectively. Reducing the redundancy is a known problem in relational data base design and we apply here similar solutions to those proposed in that area. The lower part of Figure 1 shows the idea to separate the flow from packet information. In order to maintain the relation between Packet Properties and Flow Properties we introduce indices (idxA and idxB) for the Flow Properties, these are unique concerning all Flow Property entries. The purpose of the indices is to serve as ôprimary keyö that identifies rows of the Flow Properties. The rows are then referenced by the Packet Properties by using the appropriate index. one packet flows +------+------+------------+---------+ | srcA | dstA | packet info| ... | +------+------+------------+---------+ | srcA | dstA | packet info| ... | +------+------+------------+---------+ | srcB | dstB | packet info| ... | +------+------+------------+---------+ | srcA | dstA | packet info| ... | +------+------+------------+---------+ separating flow information and packet information reduces redundancy Packet Properties +-----+------------+---------+ Flow Properties >idxA | packet info| ... | +------+------+-----+ +-----+------------+---------+ | srcA | dstA |idxA < >idxA | packet info| ... | +------+------+-----+ +-----+------------+---------+ | srcB | dstB |idxB <-------->idxB | packet info| ... | +------+------+-----+ +-----+------------+---------+ >idxB | packet info| ... | +-----+------------+---------+ exemplarily, the linkage of one packet (id3) and flow B (srcB, dstB, idxB) is explicitly drawn Figure 1: Flow information and packet information In the following paragraphs we propose how to use IPFIX protocol efficiently for exporting packet flow information and per-packet information for OWD computation. Pohl, Mark, Boschi Expires January 2005 [Page 4] Use of IPFIX for Export of Per-Packet Information 4. Processing Per-Packet Data for One-Way Delay Measurements The IPFIX protocol is template based like NetFlow version 9. For a complete description of features of IPFIX refer to [Cla204]. Templates define the structure of data to be exported, including describing data fields to be exported together with their type and meaning. For Measurement Process Results we define two different template records, namely Packet Properties and Flow Properties. As indicated in Figure 2, the Flow Properties template defines the attributes for a flow; exemplarily IP source and destination address. The important field is the Flow Index Field. As we will explain, the Flow Index will allow packet records to reference flow attributes. The Flow Index is a unique identifier for flow definitions. Subsequent data records (marked as R1 à Rk) define the actual flows. The FlowSet ID should indicate the special case of a Flow Property template. (FlowSet IDs 0 and 1 are already reserved for templates consisting of flow fields or option fields, respectively. However, the Collector must handle Flow Properties templates and their data records in a slightly different way than usually.) The format for the information related to a single packet is defined in the Packet Properties template. This information is packet specific and normally not shared between many packets. Otherwise one would rather consider the information as flow related and therefore it has not to be exported for every packet. In the case of passive One-Way-Delay measurement, the Packet Properties template consists of at least Timestamp and Packet ID. Additionally, this template contains a Flow Index field. In packet records, the value of this field will contain one of the unique indices of the flow records exported before. +------------------+ +-------------------+ | Template FlowSet | | Template FlowSet | | | | | Description of | Flow Properties | | Packet Properties | exported data +----------+-------+ +----------+--------+ ...........|.........................|......................... | | +----------v-------+ +----------v--------+ | Data FlowSet | | Data FlowSet | exported data | <------+ | with references | Flow Properties | | Packet Properties | by means of +------------------+ +-------------------+ FlowIndex Figure 2: Template FlowSet and Data FlowSet dependencies Pohl, Mark, Boschi Expires January 2005 [Page 5] Use of IPFIX for Export of Per-Packet Information At the collection point packet records of two measurement points are gathered and correlated by means of the packet ID. The one- way delay is then calculated as stated above. The resulting delay data records are exported in a similar manner as the packet data have been. Especially, the linkage between delay data and flow information is represented with the discussed Flow Index fields. The OWD properties contain the Packet Pair ID (which is the packet ID of the two contributing packet records), a timestamp (which is the timestamp of the packet passing the reference monitor point) in order to reconstruct a time scale, the calculated delay value, and finally a flow index. Export and evaluation considerations In order to use IPFIX protocol for packet and OWD data export we have to prepare several things. We must assign a new FlowSet ID from the range 2 to 255 for the Flow Properties templates. We have to introduce new Field Type definitions for Packet ID, Length N, Flow Index, Length 4, Timestamp, Length 8 The size of the packet ID depends on the used generator function û in the case of a CRC32 the field size would be 4 bytes. The range for the flow indices should be reasonable large. We propose at least a 32-bit value, i.e. 4 bytes. We suggest using absolute timestamps with a resolution of nanoseconds and a width of 64-bit (signed). The origin will be Jan.1, 1970 as usual. (The range covers ~292 years. So we provoke a year-2262-Problemà) The value for the one-way delay should be a 32-bit (signed) value, which covers ~2 seconds. The collector must be able to associate incoming packet records to flow records by matching the contained Flow Indices. For obvious reasons, the exporting process must send the appropriate defining flow records with the unique Flow Indices before it can send packet records that reference flow information by indices. 5. Security Considerations For the proposed use of the IPFIX protocol for export of per- packet information the security considerations as for the IPFIX protocol apply. Pohl, Mark, Boschi Expires January 2005 [Page 6] Use of IPFIX for Export of Per-Packet Information 6. References [DuGG03] Nick Duffield, Albert Greenberg, Matthias Grossglauser, Jennifer Rexford: A Framework for Passive Packet Measurement, Internet Draft , December 2003 [DuGr00] Nick Duffield, Matthias Grossglauser: ôTrajectory Sampling for Direct Traffic Observationö, Proceedings of ACM SIGCOMM 2000, Stockholm, Sweden, August 28 - September 1, 2000 [QuZC04] J. Quittek, et. Al: Requirements for IP Flow Information Export, Internet Draft , December 2004 [GrDM98] Ian D. GRAHAM, Stephen F. DONNELLY, Stele MARTIN, Jed MARTENS, John G. CLEARY: Nonintrusive and Accurate Measurement of Unidirectional Delay and Delay Variation on the Internet, INET'98, Geneva, Switzerland, July 21-24, 1998 [ZsZC01] T. Zseby, S. Zander, G. Carle: Evalutation of building blocks for passive one-way-delay measurements, PAM2001, Amsterdam, April 23-24, 2001 [TPBC03] T. Tseby, R. Penno, N. Brownly, B. Claise: IPFIX Applicability, Internet Draft , October 2003 [Cla104] Benoit Claise: IPFIX Protocol Specification, Internet Draft , January 2004 [Cla204] Benoit Claise: PSAMP Protocol Specification, Internet Draft , February 2004 7. Author's Addresses Elisa Boschi Fraunhofer Institute for Open Communication Systems Kaiserin-Augusta-Allee 31 10589 Berlin Germany Phone: +49-30-34 63 7366 Fax: +49-30-34 53 8366 Email: boschi@fokus.fraunhofer.de Lutz Mark Fraunhofer Institute for Open Communication Systems Kaiserin-Augusta-Allee 31 Pohl, Mark, Boschi Expires January 2005 [Page 7] Use of IPFIX for Export of Per-Packet Information 10589 Berlin Germany Phone: +49-30-34 63 7306 Fax: +49-30-34 53 8306 Email: mark@fokus.fraunhofer.de Guido Pohl Fraunhofer Institute for Open Communication Systems Kaiserin-Augusta-Allee 31 10589 Berlin Germany Phone: +49-30-34 63 7164 Fax: +49-30-34 53 8164 Email: pohl@fokus.fraunhofer.de 8. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Pohl, Mark, Boschi Expires January 2005 [Page 8]