[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01                                                         
            Use of IPFIX for Export of Per-Packet Information
     
     
     Internet-Draft                                            E. Boschi
     Document: draft-boschi-export-perpktinfo-00.txt    Fraunhofer FOKUS
                                                        / Hitachi Europe
     Expires: December 2005                                      L. Mark
                                                        Fraunhofer FOKUS
     
     
                                                               June 2005
     
     
     
     
              Use of IPFIX for Export of Per-Packet Information
                     draft-boschi-export-perpktinfo-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 December 26, 2005.
     
     
     
        Copyright Notice
     
        Copyright (C) The Internet Society (2005).
     
     
     
     
     
     
     
     
     
     Boschi, Mark                Expires December 2005        [Page 1]


              Use of IPFIX for Export of Per-Packet Information
     
     Abstract
     
        This document describes the usage of the IP Flow Information
        Export (IPFIX) protocol for the case of exporting and processing
        per-packet information.
        The main idea is to separate the export of the information about
        packets and flows those packets belong to, using two different
        records. The association between the records is kept using
        unique Flow or Template Identifiers.
     
     
     Table of Contents
     
        1.   Introduction¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸2
        2.   Terminology¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸2
        3.   General Problem Statement¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸3
        4.   Export Per-Packet Information¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸3
        5.   Using Scopes¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸5
        6.   Flow ID Management¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸5
        7.   Example of Per-Packet Information Export¸¸¸¸¸¸¸¸¸¸¸¸¸6
        8.   IPFIX for per-packet information export and PSAMP¸¸¸¸7
        9.   Export and evaluation considerations¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸7
        10.  IANA Consideration¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸7
        11.  Security Considerations¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸7
        12.  References¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸8
        12.1 Normative References¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸8
        12.2 Informative References¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸8
        13.  Author's Addresses¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸8
        14.  Intellectual Property Statement¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸8
        15.  Copyright Statement¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸9
        16.  Disclaimer¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸9
     
     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. One typical application is passive
        One-Way-Delay measurement; this draft takes it as example when
        demonstrating the need for information export on a per-packet
        basis.
     
        The IPFIX protocol however, has been designed to export flow
        records. A possible approach to export packet records using
        IPFIX could be exporting flow records containing information
        about single packets. This method has been proposed by the PSAMP
        working group in [Cla04]. 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 using IPFIX.
     
     
     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
     
     Boschi, Mark                Expires December 2005        [Page 2]


              Use of IPFIX for Export of Per-Packet Information
     
            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
     
     
     3. General Problem Statement
     
        In [Cla05] the IPFIX working group has defined a protocol to
        transport measurement data containing flow information.
     
        The main purpose of the protocol is to exchange information
        about IP traffic flows. In this scope a flow is defined by a set
        of key attributes (source/destination address,
        source/destination port, Layer3 Protocol Type, TOS/DSCP byte,
        interface of the flow exporting network element). As such, a
        flow is a collection of packets that share a set of common
        attributes.
     
        However, for a number of metrics there is a need to export
        per-packet data.
     
        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 however, where it is desirable to keep flow
        information along with the per-packet information, that is, when
        analyzing packet characteristics while observing flows. This
        document proposes a solution that reduces the overhead caused by
        the flow properties while keeping a link to flow information.
     
        The proposed method does not need any changes to the IPFIX
        protocol.
     
     4. Export Per-Packet Information
     
        Figure 1 depicts three packets belonging to flow A and one
        packet belonging to flow B, respectively. It shows export
        records containing packet information plus flow information
        (source and destination address). Undoubtedly, the flow
        information introduces a huge amount of redundancy, as it is
        repeated for every packet in every record. Minimizing the
        redundancy is a common problem in relational data base design
        and we apply here similar solutions to those proposed in that
        area.
     
     
     
     Boschi, Mark                Expires December 2005        [Page 3]


              Use of IPFIX for Export of Per-Packet Information
     
        In Figure 2 we separate 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 that are unique for all Flow Property entries. The
        purpose of the indices is to serve as "primary key" that
        identifies rows of the Flow Properties. More details about these
        indices will be given in section 5. The rows are then referenced
        by the Packet Properties by using the appropriate value for the
        flow identifier. The linkage of one packet and flow B (srcB,
        dstB, idxB) is explicitly drawn.
     
     
        One-packet flows
        +------+------+------------+---------+
        | srcA | dstA | packet info|   ...   |
        +------+------+------------+---------+
        | srcA | dstA | packet info|   ...   |
        +------+------+------------+---------+
        | srcB | dstB | packet info|   ...   |
        +------+------+------------+---------+
        | srcA | dstA | packet info|   ...   |
        +------+------+------------+---------+
     
        Figure 1: Flow and packet information represented in one-packet
        flows
     
                                      Packet Properties
                                     +-----+------------+---------+
        Flow Properties              >idxA | packet info|   ...   |
        +------+------+-----+        +-----+------------+---------+
        | srcA | dstA |idxA <        >idxA | packet info|   ...   |
        +------+------+-----+        +-----+------------+---------+
        | srcB | dstB |idxB <-------->idxB | packet info|   ...   |
        +------+------+-----+        +-----+------------+---------+
                                     >idxB | packet info|   ...   |
                                     +-----+------------+---------+
     
     
        Figure 2: Flow information and packet information
     
     
        The IPFIX protocol is template based like NetFlow version 9. For
        a complete description of features of IPFIX refer to [Cla05].
        Templates define the structure of data to be exported,
        describing data fields together with their type and meaning.
        IPFIX specifies two types of records to export data: data
        records and option data records. These records are defined via
        template records and option template records. To export per-
        packet-information we define two different templates: an option
        template for Flow Properties and a template for Packet
        Properties.
     
        Figure 3 shows the relation between template and data sets for
        packet and flow properties. The Flow Properties option template
        defines the attributes for a flow; e.g. IP source and
        destination address and the flowID. The flowID is a unique
        identifier for a flow; this field allows packet records to
        reference flow attributes. Subsequent option data records of
        this template define the actual flows. The reference could be
        alternatively provided by the TemplateID, as explained in
        Section 5.
     
        The format for the information related to single packets is
        defined in the Packet Properties template. This information is
        packet specific and normally not shared between many packets.
     
     
     Boschi, Mark                Expires December 2005        [Page 4]


              Use of IPFIX for Export of Per-Packet Information
     
        Otherwise one would rather consider the information as flow
        related and therefore it needs not be exported in every record.
     
     
     
        +---------------------+      +-------------------+
        | Option Template Set |      | Template Set      |
        |                     |      |                   |  Description of
        | Flow Properties     |      | Packet Properties |  exported data
        +----------+----------+      +----------+--------+
        ...........|............................|.........................
                   |                            |
        +----------v----------+      +----------v--------+  Exported data
        | Option Data Set     |      | Data Set          |  with references
        |                     <------+                   |  by means of flow
        | Flow Properties     |      | Packet Properties |  or template
        +---------------------+      +-------------------+  identifiers
     
     
        Figure 3: Template FlowSet and Data FlowSet dependencies
     
        The Flow Properties option data records SHOULD be sent prior to
        the corresponding Packet Properties data records.
     
     
     5. Using Scopes
     
        Flow Properties are sent via IPFIX option records. IPFIX option
        records contain one or more scope fields. The Flow Properties
        record can contain the FlowID and/or the TemplateID as scope
        fields. There are three options:
     
        1) Use FlowID as scope
          The flow properties are valid for all data records containing
          that flowID. This solution limits the number of different
          flows that can be exported at the same tame in the same
          observation domain to 2**32 (using 32 bits flowIDs)
        2) Use FlowID and TemplateID as scope
          The flow properties are valid only for data records referring
          to the template specified by the TemplateIDand containing
          that flowID. This allows the export up to 2**32 flows per
          template. The solution is to be chosen when the number of
          flows to be exported is expected to be very high (and beyond
          the limit posed by solution 1)
        3) Use TemplateID as scope
           The flow properties are valid for all data records of the
           specified template. In this case flowIDs are not needed but
           the exporting process requires a templateID per flow. In the
           general case this solution is not scalable but can be
           suitable for certain applications (e.g. flow aggregation).
     
     
     6. Flow properties Management
     
        Like template IDs the flow IDs have to be unique per observation
        domain (source identifier in the IPFIX header).  There are no
        constraints regarding the order of the Flow ID allocation. When
        limiting the scope to special templates, the flow IDs have to be
        unique per observation domain and template.
     
        The considerations made in [IPFIX-PROTO] with regard to template
        management apply for flow properties as well (e.g. the regular
        retransmission when using an unreliable transport protocol).
     
     
     
     
     Boschi, Mark                Expires December 2005        [Page 5]


              Use of IPFIX for Export of Per-Packet Information
     
     7. Example of Per-Packet Information Export
     
        To demonstrate how to use IPFIX efficiently to export per-packet
        information, this section proposes how to use the IPFIX protocol
        for exporting flow information and per-packet information (in
        this case related to a long-lived flow) for OWD computation.
     
        In order to acquire a One-Way path delay information, two
        measurement points with synchronized clocks must exist, one at
        each end of the path under examination. Both measurement points
        will capture packets, assign them timestamps and generate an
        identifier for a packet passing that point. Each measurement
        point will export its measurement data to a collecting process
        where the data are correlated based on the packet identifiers
        and timestamps and then the delay is calculated as a difference
        of two timestamps of a packet pair.
     
        The templates that would be needed for exporting measurement
        data of this kind are illustrated in Figure 4.
        The upper part of the figure shows the option template
        containing the information concerning flows using the FlowID as
        scope. The lower part displays the template with the packet
        properties.
     
        For passive One-Way-Delay measurement, the Packet Properties
        template consists of at least Timestamp and Packet ID.
        Additionally, this template contains a flow identifier field. In
        packet records, the value of this field will contain one of the
        unique indices of the flow records exported before.
     
     
        +-------------------+-------------------+-----------------------+..
        | flowID            | sourceAddressV4   | destinationAddressV4  |
        |                   |                   |                       |
        | unsigned32/vendor | ipv4Address/ID 8  | ipv4Address/ID 12     |
        +-------------------+-------------------+-----------------------+..
     
        ..+------------------+--------------------+---------------------+..
          | classOfServiceV4 | protocolIdentifier | transportSourcePort |
          |                  |                    |                     |
          | octet/ID 5       | octet/ID 4         | unsigned16/ID 7     |
        ..+------------------+--------------------+---------------------+..
     
        ..+--------------------------+
          | transportDestinationPort |
          |                          |
          | unsigned16/ID 11         |
        ..+--------------------------+
                                                           FlowPropTemplate
        ===================================================================
                                                         PacketPropTemplate
        +-------------------+-------------------+-------------------+..
        | packetTimestamp   | packetID          | packetLength      |
        |                   |                   |                   |
        | unsigned64/vendor | unsigned32/vendor | unsigned32/vendor |
        +-------------------+-------------------+-------------------+..
     
        ..+-------------------+
          | flowID            |
          |                   |
          | unsigned32/vendor |
        ..+-------------------+
     
        Figure 4: Example Templates for Flow and Packet Properties
     
     
     
     Boschi, Mark                Expires December 2005        [Page 6]


              Use of IPFIX for Export of Per-Packet Information
     
        The delay is derived by a calculation step: At the collection
        point packet records of two measurement points are gathered and
        correlated by means of the packet ID. 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 identifier
        fields. The OWD properties contain the Packet Pair ID (which is
        the packet ID matching that 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 series, the calculated delay value, and finally a flow
        identifier.
     
     8. IPFIX for per-packet information export and PSAMP
     
        In [Cla04] the PSAMP working group proposes to use IPFIX to
        export packet information from a PSAMP Exporting Process to a
        PSAMP Collecting Process. Even though no new version of the
        draft has been produced so far the solution seems to be accepted
        from the group.
        While IPFIX is well suited for the purpose due to the good match
        between the IPFIX and PSAMP architectures and to the fact that
        IPFIX satisfies PSAMP requirements, the described approach has a
        high degree of redundancy. It proposes to treat packets as flows
        and export per-packet information using flow records.
        We propose to use the solution described in this draft to
        efficiently export PSAMP packet information.
     
     9. Export and evaluation considerations
     
        The main advantage of this proposed method to export per-packet
        information is the reduced amount of measurement data that has
        to be transferred from the exporter to the collector. In
        addition there is less storage capacity needed at the collector
        side.
     
        On the other hand there is some extra processing power needed on
        the exporter side to manage flow information and to assign
        packets to flows. The collector has to process records of two
        templates instead of just one but has to read and write less
        data. Additional effort is needed when post processing the
        measurement data, because now the correlation of flow and packet
        information is needed.
     
        In the above example (see Figure 4) using IPFIX to export the
        measurement data for each received packet 28 bytes have to be
        transferred (sourceAddressV4=4, destinationAddressV4=4,
        classOfServiceV4=1, protocolIdentifier=1, transportSourcePort=2,
        transportDestionationPort=2, packetTimestamp=8, packetID=4,
        packetLength=2). Disregarding the IPFIX protocol overhead a flow
        of 1000 packets produces 28000 bytes of measurement data. Using
        the proposed optimization each packet produces an export of only
        16 bytes (packetTimestamp=8, packetID=4, packetLength=2,
        flowID=2). The export of the flow information produces 16 bytes
        (sourceAddressV4=4, destinationAddressV4=4, classOfServiceV4=1,
        protocolIdentifier=1, transportSourcePort=2,
        transportDestionationPort=2, flowID =2). For a flow of 1000
        packet this sums up to 16016 bytes. This is a decrease of more
        than 40 percent.
     
     10. IANA Consideration
     
        This document does not imply any IANA action.
     
     11. Security Considerations
     
     
     Boschi, Mark                Expires December 2005        [Page 7]


              Use of IPFIX for Export of Per-Packet Information
     
        For the proposed use of the IPFIX protocol for export of
        per-packet information the security considerations as for the
        IPFIX protocol apply.
     
     12. References
     
     12.1   Normative References
     
        [Cla05]     Benoit Claise: IPFIX Protocol Specification,
                    IETF draft work in progress
                    <draft-ietf-ipfix-protocol-16.txt>, June 2005
     
        [Cla04]     Benoit Claise: PSAMP Protocol Specification,
                    Internet Draft <draft-ietf-psamp-protocol-01.txt>,
                    February 2004
     
     12.2   Informative References
     
        [DuGG03]    Nick Duffield, et Al.: A Framework for Packet
                    Selection and reporting, Internet Draft
                    <draft-ietf-psamp-framework-10.txt>, January 2005
     
        [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, RFC 3917, October 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
     
        [TPBC03]    T. Zseby, E. Boschi, R. Penno, N. Brownlee, B.
                    Claise: IPFIX Applicability, Internet Draft
                    <draft-ietf-ipfix-as-05.txt>, May 2005
     
     13. 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
            10589 Berlin
            Germany
            Phone: +49-30-34 63 7306
            Fax:   +49-30-34 53 8306
            Email: mark@fokus.fraunhofer.de
     
     
     14. 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
     
     Boschi, Mark                Expires December 2005        [Page 8]


              Use of IPFIX for Export of Per-Packet Information
     
        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.
     
     15. 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.
     
     16. Disclaimer
     
        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.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Boschi, Mark                Expires December 2005        [Page 9]