Internet Draft G. Pohl Document: Fraunhofer FOKUS Expires: Mai 2004 L. Mark Fraunhofer FOKUS C. Schmoll Fraunhofer FOKUS T. Zseby Fraunhofer FOKUS October 2003 IPFIX Export of packet information for QoS Meaurements 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 an extension for the IP Flow Information Export (IPFIX) protocol that allows to export packet information for QoS measurements with 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 id. And a second type of record, that consists of this flow id and the packet data. The flow id is used to associate the packet data to the corresponding flow. Table of Contents 1. Introduction.................................................1 2. Terminology..................................................2 3. General Problem Statement....................................2 4. Export of Packet Ids, Timestamps, and Flow Information.......4 5. Export OWD data..............................................4 6. Export and evaluation considerations.........................5 7. Security Considerations......................................5 8. References...................................................5 9. Author's Addresses...........................................6 10. Full Copyright Statement.....................................6 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. As an example we take passive one-way delay measurement and demonstrate the need for per information export Pohl, Mark, Schmoll, Zseby Expires Mai 2004 [Page 1] IPFIX Export of packet information for QoS Meaurements on a per-packet basis. Instead of exporting flow related information per-packet and introducing a high degree of redundancy we show how packet information and flow information can be efficiently be 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. 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 Add text here ;-) 3. General Problem Statement In [Clai03] the IPFIX working group defined an exporting protocol for measurement data and flow information export. The initial purpose of that 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 the initial sense, a flow aggregates a number of packets with 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 path delay this way a couple of measurement points are set up - one at either end of the path under examination. Both measurement points will capture and furniture packets with 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. Pohl, Mark, Schmoll, Zseby Expires Mai 2004 [Page 2] IPFIX Export of packet information for QoS Meaurements It is clear that one could consider a single packet as a special case of a flow. This procedure has consequences that conflict with the efficiency of the exporting procedure. When many packets belong to the same flow, i.e. they share common attributes; these attributes would have to be exported on a per- packet basis together with a different packet ID each time although the information is redundant. There are cases where it is desirable to keep flow information along with the per-packet information, that is, when analyzing packet characteristics while regarding flows. The upper part of Figure 1 shows both packet data (id and timestamp) and information (source and destination address) that is relevant for the flow of the packet belongs to. Undoubtedly, the flow information introduces a huge 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. 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 id1 | tstamp1 | +------+------+------------+---------+ | srcA | dstA | packet id2 | tstamp2 | +------+------+------------+---------+ | srcB | dstB | packet id3 | tstamp3 | +------+------+------------+---------+ | srcA | dstA | packet id4 | tstamp4 | +------+------+------------+---------+ separating flow information and packet information reduces redundancy Packet Properties +-----+------------+---------+ Flow Properties >idxA | packet id1 | tstamp1 | +------+------+-----+ +-----+------------+---------+ | srcA | dstA |idxA < >idxA | packet id2 | tstamp2 | +------+------+-----+ +-----+------------+---------+ | srcB | dstB |idxB <-------->idxB | packet id3 | tstamp3 | +------+------+-----+ +-----+------------+---------+ >idxB | packet id4 | tstamp4 | +-----+------------+---------+ 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, Schmoll, Zseby Expires Mai 2004 [Page 3] IPFIX Export of packet information for QoS Meaurements 4. Export of Packet Ids, Timestamps, and Flow Information The IPFIX protocol is template based as NetFlow version 9. For a complete desciption of features of IPFIX refer to [Clai03]. Only that much, templates define the structure of data to be exported, this includes describing data fields to be exported together with its 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 slightly different 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 5. Export OWD data 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 earlier. 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. Pohl, Mark, Schmoll, Zseby Expires Mai 2004 [Page 4] IPFIX Export of packet information for QoS Meaurements 6. 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. A collecting instance must store the flow records of Flow Properties together with the Flow Indices. The flow records therefore should be handled like templates. A similar timeout and refresh mechanism as for templates themselves should be used for flow records too (refer to [Clai02]). 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. 7. Security Considerations For the proposed extension of the IPFIX protocol the same security considerations as for the IPFIX protocol apply. Nevertheless, additional privacy issues may be of concern if header or content information can be derived from packet IDs. TODO : extend section 8. References [DuGG03] Nick Duffield, Albert Greenberg, Matthias Grossglauser, Jennifer Rexford: A Framework for Passive Packet Measurement, Internet Draft , March 2003 [DuGr00] Nick Duffield, Matthias Grossglauser: “Trajectory Sampling for Direct Traffic Observation”, Proceedings of ACM SIGCOMM 2000, Stockholm, Sweden, August 28 - September 1, 2000 [QuZC03] J. Quittek, et. Al: Requirements for IP Flow Information Export, Internet Draft , June 2003 [GrDM98] Ian D. GRAHAM, Stephen F. DONNELLY, Stele MARTIN, Jed MARTENS, John G. CLEARY: Nonintrusive and Accurate Measurement of Unidirectional Delay and Pohl, Mark, Schmoll, Zseby Expires Mai 2004 [Page 5] IPFIX Export of packet information for QoS Meaurements 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 , June 2003 [Clai03] Benoit Claise: IPFIX Protocol Specification, Internet Draft , June 2003 9. Author's Addresses Tanja Zseby Fraunhofer Institute for Open Communication Systems Kaiserin-Augusta-Allee 31 10589 Berlin Germany Phone: +49-30-34 63 7153 Fax: +49-30-34 53 8153 Email: zseby@fokus.fraunhofer.de Lutz Mark Fraunhofer Institute for Open Communication Systems Kaiserin-Augusta-Allee 31 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 Carsten Schmoll Fraunhofer Institute for Open Communication Systems Kaiserin-Augusta-Allee 31 10589 Berlin Germany Phone: +49-30-34 63 7136 Fax: +49-30-34 53 8136 Email: schmoll@fokus.fraunhofer.de 10. 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 Pohl, Mark, Schmoll, Zseby Expires Mai 2004 [Page 6] IPFIX Export of packet information for QoS Meaurements 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, Schmoll, Zseby Expires Mai 2004 [Page 7]