[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05

Network Working Group                                        F. Dressler
Internet-Draft                                                 C. Sommer
Expires: July 31, 2005                            University of Erlangen
                                                                G. Muenz
                                                 University of Tuebingen
                                                        January 27, 2005


                           IPFIX Aggregation
               <draft-dressler-ipfix-aggregation-00.txt>

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with
   RFC 3668.

   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 July 31, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   IPFIX Aggregation describes a methodology for reducing the amount of
   measurement data exchanged between monitoring devices (IPFIX
   exporters) and analyzers (IPFIX collectors).  Using aggregation
   techniques, measurement information of similar flows is aggregated



Dressler, et al.    draft-dressler-ipfix-aggregation-00.txt     [Page 1]


Internet-Draft              IPFIX Aggregation               January 2005


   into one metaflow.  The degree of similarity can be defined using
   aggregation rules.  To achieve further reduction of the amount of
   data exchanged while still transmitting all required information to
   the collector, the IPFIX protocol and Information Model is slightly
   extended to allow two new data types and a new template / template
   set.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

   2.  Aggregation Techniques . . . . . . . . . . . . . . . . . . . .  3
     2.1   Architecture . . . . . . . . . . . . . . . . . . . . . . .  3
     2.2   Procedure  . . . . . . . . . . . . . . . . . . . . . . . .  4
       2.2.1   Explicit Rules . . . . . . . . . . . . . . . . . . . .  4
       2.2.2   Special Fields . . . . . . . . . . . . . . . . . . . .  6
       2.2.3   Shared Properties  . . . . . . . . . . . . . . . . . .  6
     2.3   Application Examples . . . . . . . . . . . . . . . . . . .  7
       2.3.1   Charging . . . . . . . . . . . . . . . . . . . . . . .  7
       2.3.2   Intrusion Detection  . . . . . . . . . . . . . . . . .  7

   3.  Data Export  . . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.1   PrecedingRule  . . . . . . . . . . . . . . . . . . . . . .  8
     3.2   PortRanges . . . . . . . . . . . . . . . . . . . . . . . .  8
     3.3   Data Template  . . . . . . . . . . . . . . . . . . . . . .  9
     3.4   Example  . . . . . . . . . . . . . . . . . . . . . . . . . 12

   4.  Security considerations  . . . . . . . . . . . . . . . . . . . 13

   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     5.1   Normative References . . . . . . . . . . . . . . . . . . . 13
     5.2   Informative References . . . . . . . . . . . . . . . . . . 13

       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14

       Intellectual Property and Copyright Statements . . . . . . . . 15















Dressler, et al.    draft-dressler-ipfix-aggregation-00.txt     [Page 2]


Internet-Draft              IPFIX Aggregation               January 2005


1.  Introduction

   Flow measurement in high speed, large scale networks can quickly
   produce an amount of data that can no longer be handled by a central
   monitoring station without having been preprocessed.  Flow
   aggregators try to alleviate this problem by selectively discarding
   data and merging flows into bigger metaflows, thus reducing both the
   number of flows sent and the amount of data carried in each flow
   record.  This document proposes ways of designing and implementing
   IPFIX aggregators and introduces extensions to IPFIX necessary for
   doing so.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Aggregation Techniques

2.1  Architecture

   Aggregation of measurement data may take place at two possible
   stages:

   An internal aggregator (see Figure 1) might be implemented as a
   process running in an IPFIX enabled device, aggregating raw data
   collected by multiple metering processes and exporting it as
   metaflows.

   An external aggregator, as shown in Figure 2, might be appropiate
   where the collecting device cannot be refitted with an aggregator or
   if cascaded aggreagtion is desired.  External aggregators, called
   concentrators in IPFIX terminology, receive flows from lower-level
   concentrators or measurement devices' exporters and export the
   aggregated metaflows to a higher-level concentrator or a monitoring
   station.
















Dressler, et al.    draft-dressler-ipfix-aggregation-00.txt     [Page 3]


Internet-Draft              IPFIX Aggregation               January 2005


   +------------------------------------------+     +--------------+
   | IPFIX-enabled device       .---.   .---. |     |              |
   | .--------------------.     | A |   |   | | .-->|   Analyzer   |
   | | Metering Process 1 |-.   | g |   | E | | |   |              |
   | `--------------------' |   | g |   | x | | |   +--------------+
   |                        |   | r |   | p |---'
   |           .            '-->| e |   | o | |
   |           .                | g |-->| r | |
   |           .            .-->| a |   | t |---.
   |                        |   | t |   | e | | |   +--------------+
   | .--------------------. |   | o |   | r | | '-->|              |
   | | Metering Process N |-'   | r |   |   | |     | Concentrator |
   | `--------------------'     `---'   `---' | .-->|              |
   +------------------------------------------+ :   +--------------+

                     Figure 1: Internal Aggregation


   : +--------------+    +-----------------------+     +--------------+
   '->              |    | Concentrator          |     |              |
     | Concentrator |-.  | .---.   .---.   .---. | .-->|   Analyzer   |
   .->              | |  | | C |   | A |   |   | | |   |              |
   : +--------------+ |  | | o |   | g |   | E | | |   +--------------+
                      '--->| l |   | g |   | x |---'
                         | | l |   | r |   | p | |
                         | | e |-->| e |-->| o |-|
                         | | c |   | g |   | r | |
                      .--->| t |   | a |   | t |---.
     +--------------+ |  | | o |   | t |   | e | | |   +--------------+
     |              | |  | | r |   | o |   | r | | '-->|              |
     | IPFIX device |-'  | |   |   | r |   |   | |     | Concentrator |
     |              |    | `---'   `---'   `---' | .-->|              |
     +--------------+    +-----------------------+ :   +--------------+

                     Figure 2: External Aggregation


2.2  Procedure

2.2.1  Explicit Rules

   Regarding methods of aggregation, a simple, rule-based approach is
   proposed: The concentrator is supplied a list of user-defined rules.
   Each rule consists of multiple aggregation instructions describing

   o  The type of IPFIX field the aggregation instruction refers to
      (e.g.  "Destination IP")




Dressler, et al.    draft-dressler-ipfix-aggregation-00.txt     [Page 4]


Internet-Draft              IPFIX Aggregation               January 2005


   o  A matching pattern (e.g.  10.10.0.0/16).  In order for an incoming
      IPFIX record to be aggregated according to a given rule, all of
      its aggregation instruction's patterns need to be matched by the
      incoming record's corresponding fields' values.
   o  A granularity modifier (e.g.  "keep field").  If the aggregation
      instruction refers to a regular field type, the modifier can
      either be "discard field" or "keep field".  If the aggregation
      instruction refers to a field of type "IP address", the modifier
      can also only selectively discard bits of the IP address by
      applying a network mask.  If the aggregation instruction refers to
      one of the special field types mentioned in Section 2.2.2 the
      modifier takes a fixed value of "aggregate" and the aggregation
      instruction acts according to Section 2.2.2.

   This way each rule also unambiguosly defines
   o  A minimal set of IPFIX fields an incoming record needs to
      transport to potentially match this rule: All fields mentioned in
      the rule's aggregation instructions MUST be present.
   o  The template used when exporting flows matching this rule: Each
      field mentioned in the rule's aggregation instructions that does
      not have its granularity modifier set to "discard" will be present
      in all flows that were aggregated according to this rule.  Other
      fields of an incoming flow that have no matching aggregation
      instruction are neither considered nor exported.

   Regarding treatment of incoming flow records that matched a given
   rule, two possible implementations can be thought of:
   First-match

      An incoming flow record is sequentially checked against each rule.
      If all fields of the flow record match the corresponding fields of
      the aggregation rule, the rule's granularity modifiers are applied
      and the flow is aggregated.  No further processing of this flow
      takes place.  Because in this case a receiver of aggregated flows
      needs to be aware of the order in which rules were checked,
      exported flows carry an additional field that points to flows
      matching a preceding rule.  See Section 3.1 for a possible
      implementation.

   Each possible match

      An alternative implementation might check each incoming record
      against every rule.  If all fields of the flow record match the
      corresponding fields of an aggregation rule, a copy of the flow
      has the rule's granularity modifiers applied, is aggregated and
      processing of the original flow continues with the next rule.  In
      this case the order of rules need not be transmitted.




Dressler, et al.    draft-dressler-ipfix-aggregation-00.txt     [Page 5]


Internet-Draft              IPFIX Aggregation               January 2005


2.2.2  Special Fields

   Fields that describe properties of the flow itself rather than
   properties of packets that made up the flow receive special
   treatment: A flow's begin-timestamp is set to the minimum of the
   comprising flows' timestamps, Packet and byte counters of aggregated
   flows are summed up, etc.  All fields (see also the IPFIX information
   model [I-D.ietf-ipfix-info]) that require special processing are
   summarized in Table 1.

  +--------------------------------+---------------------------------+
  | Field                          | Action                          |
  +--------------------------------+---------------------------------+
  | # packets                      | sum of all aggregated flows     |
  | # bytes                        | sum of all aggregated flows     |
  | # flows                        | sum of all aggregated flows     |
  | timestamp of first seen packet | minimum of all aggregated flows |
  | timestamp of last seen packet  | maximum of all aggreagted flows |
  +--------------------------------+---------------------------------+

          Table 1: Information with Implicit Aggregation Rules


2.2.3  Shared Properties

   Matching patterns of fields (e.g., an IP address matching a
   subnetwork) constitute shared properties of exported flows.  Such
   shared properties are equal for each flow and , therefore, MAY be
   exported as regular IPFIX fields.  They SHOULD, however, be
   transmitted as shared properties using the Data Template proposed in
   Section 3.3.  No separate transmissions of aggregation instructions
   need take place.

   Let us consider an example ruleset:
   1.  Match Source Port 80.
       Match Destination IPs in 10.10.0.0/16, apply mask /24.
       Aggregate # packets.
   2.  Aggregate # packets.

   The first rule aggregates all flows to a destination in 10.10.x.0/24
   with source port equal to 80.  The shared properties of all these
   flows are the source port (80) and the destination address (one in
   10.10.x.0).  Thus, this ruleset provides quick packet counters for
   outbound HTTP traffic in subnets 10.10.x.0, providing an additional
   packet counter for all other flows.






Dressler, et al.    draft-dressler-ipfix-aggregation-00.txt     [Page 6]


Internet-Draft              IPFIX Aggregation               January 2005


2.3  Application Examples

2.3.1  Charging

   Monitoring and accouting for charging applications requires to save
   information about each individual end system.  Further information
   about each particular flow is not required.  Therefore, aggregation
   rules are appropriate if the address of the end system is retained.

   An example ruleset might consist of the following instructions:
   1.  Match Destination IP in 10.10.0.0/16, keep field.
       Aggregate # packets.
   2.  Match Source IP in 10.10.0.0/16, keep field.
       Aggregate # packets.

   Thus, aggregated meta flows will be created for all inbound and
   outbound traffic of the network managed, separated by direction and
   host.  Protocol and port information will be discarded.

2.3.2  Intrusion Detection

   If monitoring is employed for further analysis in terms of intrusion
   detection, i.e.  anomaly detection, rule-based intrusion detection,
   etc, information about used protocols at transport layer as well as
   at application layer are mostly required.  On the other hand, the
   analysis will typically work on the basis of subnetworks instead of
   single hosts because of the amount of data to process.  Information
   about the traffic between individual end systems is required if
   suspicious transmissions were alread detected.

   An example ruleset might consist of the following instructions:
   1.  Match Destination IP in 10.10.0.0/16, keep field
       Match any Source IP, mask /24
       Match any Protocol, keep field
       Match any Destination Port, keep field
       Aggregate # packets.

   Thus, aggregated meta flows will be created for all packets to hosts
   in particular networks.  The destination port and the protocol will
   be preserved and the source port will be discarded.

3.  Data Export

   After having a rule's granularity modifiers applied, all data records
   that matched a rule comprise the same fields, so for each rule
   exactly one template can be used.  In order to efficiently transmit
   aggregated flows, however, three extensions to IPFIX are required:




Dressler, et al.    draft-dressler-ipfix-aggregation-00.txt     [Page 7]


Internet-Draft              IPFIX Aggregation               January 2005


   o  data type: PrecedingRule
   o  data type: PortRanges
   o  template / template set: Data Template

3.1  PrecedingRule

   When doing rule-based aggregation and creating metaflows on a
   first-match basis, like proposed in Section 2.2, the order in which
   rules are checked needs to be made clear to the receiver.  Because of
   the one-to-one mapping between rules and template IDs, communicating
   the order of rules is as simple as embedding the preceding rule's
   template ID into exported metaflows.

   A new data type, PrecedingRule, which is based on the unsigned16
   abstract data type and can be embedded into a DataTemplate as
   presented in Section 3.3, serves exactly this purpose.  This way the
   concentrator is implicitely sent aggregation rules or, at least, the
   actually used aggregation rules and their order.

3.2  PortRanges

   As the current draft contains no data type to transmit port lists or
   port ranges, this section defines a new abstract data type for a list
   of port ranges.

   PortRanges is a finite length string of unsigned32 values, each
   consisting of an unsigned16 start port followed by an unsigned16 end
   port specification.
   PortRanges MAY be used as a variable-length data type as defined in
   [I-D.ietf-ipfix-protocol].
   Data types basing on PortRanges MAY also be cast down to unsigned16
   to represent a single Port.  Therefore, the transportSourcePort and
   transportDestinationPort data types, currently based on the
   unsigned16 abstract data type, may be replaced by PortRanges.

















Dressler, et al.    draft-dressler-ipfix-aggregation-00.txt     [Page 8]


Internet-Draft              IPFIX Aggregation               January 2005


      +---------------+--------+---------------------------------+
      | Ports         | Length | Hexadecimal Representation      |
      +---------------+--------+---------------------------------+
      | 80            | 2      | 0050                            |
      | 1:7           | 4      | 0001 0007                       |
      | 80, 443       | 8      | 0050 0050 01BB 01BB             |
      | 1:7, 256:1024 | 8      | 0001 0007 0100 0400             |
      | 20, 80, 443   | 12     | 0014 0014 0050 0050 01BB 01BB   |
      | 1:7, 80, 443  | 12     | 0001 0007 0050 0050 01BB 01BB   |
      +---------------+--------+---------------------------------+

                      Table 2: PortRanges Examples


3.3  Data Template

   When doing rule based aggregation of flows, the resulting metaflows
   share many field values.  In order to avoid the overhead of
   repeatedly transmitting these common values of all flows that matched
   a given rule, a new template type is introduced.

   This template type, termed a "data template", allows the sender to
   both declare and define common properties of Data Sets based on it.
   The basic format of a Data Template Set is the same as that of a
   Template Set and - for the sake of completeness - is shown in
   Figure 3.  The format of individual Template definitions, however,
   differs from that of the standard Template and is shown in Figure 4
   .























Dressler, et al.    draft-dressler-ipfix-aggregation-00.txt     [Page 9]


Internet-Draft              IPFIX Aggregation               January 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 = 4           |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                        Data Template 1                        |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                              ...                              |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                        Data Template N                        |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Padding (opt)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 3: Data Template Set Format

   The Data Template Set field definitions are as follows:
   Set ID
      Type of this template set.  A set ID value of 4 is proposed for
      the data template set.

   Length
      Total length of this set in bytes.

   Padding
      Optional Padding to fill the set to a word boundary.  MUST consist
      of null-bytes and be at most seven bytes in length


   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                  |  Field Count                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Data Count                   |  Reserved                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                         Field 1 Type                          |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                              ...                              |



Dressler, et al.    draft-dressler-ipfix-aggregation-00.txt    [Page 10]


Internet-Draft              IPFIX Aggregation               January 2005


   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                         Field N Type                          |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                          Data 1 Type                          |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                              ...                              |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                          Data M Type                          |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                          Data 1 Value                         |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                              ...                              |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                          Data M Value                         |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 4: Data Template Format

   The Data Template field definitions are as follows:
   Template ID
      See the description of a Type 3 Template Set in
      [I-D.ietf-ipfix-protocol]

   Field Count
      Number of regular Fields that will be sent in subsequent Data Sets
      using this Template.

   Data Count
      Number of fixed-value Fields that will be sent in this Template.







Dressler, et al.    draft-dressler-ipfix-aggregation-00.txt    [Page 11]


Internet-Draft              IPFIX Aggregation               January 2005


   Reserved
      Reserved, MUST be 0.

   Field N Type
      Type identifier, Type length and an enterprise number (if needed)
      of field N.  Refer to [I-D.ietf-ipfix-protocol] for more
      information on Field Types

   Data M Type
      Same as "Field N Type", but used for common properties of all Data
      Sets that use this Template.  Together with Data M Value, a
      similar encoding like TLV is achieved.

   Data M Value
      Bit representation of a common property as would be transmitted in
      a Data Set.


3.4  Example

   In this example we assume the concentrator was given the following
   aggregation rules:
   1.  Match source IPs in 10.0.0.0/23, discard field.
       Match any destination port, keep field.
       Aggregate # packets.
   2.  Pass through all other flows

   We further assume the concentrator receives the following flow
   records:

   +------------+------------+-------------+-------------+-------------+
   | Source IP  | Source     | Destination | Destination | Packets     |
   |            | Port       | IP          | Port        |             |
   +------------+------------+-------------+-------------+-------------+
   | 10.0.0.1   | 64235      | 10.0.0.10   | 80          | 10          |
   | 10.0.1.2   | 64236      | 10.0.0.11   | 110         | 10          |
   | 10.0.0.3   | 64237      | 10.0.0.12   | 80          | 10          |
   | 10.0.2.4   | 64238      | 10.0.0.13   | 80          | 10          |
   | 10.0.2.5   | 64239      | 10.0.0.14   | 80          | 10          |
   +------------+------------+-------------+-------------+-------------+

                        Table 3: Incoming Flows









Dressler, et al.    draft-dressler-ipfix-aggregation-00.txt    [Page 12]


Internet-Draft              IPFIX Aggregation               January 2005


   Given the example rules and flows from above, the concentrator would
   now use one Template to send all flows that matched no given rule and
   were thus not aggregatable:

   +------------+------------+-------------+-------------+-------------+
   | Source IP  | Source     | Destination | Destination | Packets     |
   |            | Port       | IP          | Port        |             |
   +------------+------------+-------------+-------------+-------------+
   | 10.0.2.4   | 64238      | 10.0.0.13   | 80          | 10          |
   | 10.0.2.5   | 64239      | 10.0.0.14   | 80          | 10          |
   +------------+------------+-------------+-------------+-------------+

                       Table 4: Outgoing Flows I

   The second Data Set uses a Data Template to send all flows that
   matched our aggregation rule.  Note that the flows' common property,
   a Source IP of 10.0.0.0/23, was already transmitted in the template,
   so besides the packet count only the flows' discriminating property,
   their destination port, is sent in the data records:

                     +------------------+---------+
                     | Destination Port | Packets |
                     +------------------+---------+
                     | 80               | 20      |
                     | 110              | 10      |
                     +------------------+---------+

                       Table 5: Outgoing Flows II


4.  Security considerations

   As all methods described in this document are merely variations on
   methods already introduced in [I-D.ietf-ipfix-protocol], the same
   rules regarding exchange of flow information apply.

5.  References

5.1  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", March 1997.

5.2  Informative References

   [I-D.ietf-ipfix-protocol]
              Claise, B., "IPFIX Protocol Specifications",
              Internet-Draft draft-ietf-ipfix-protocol-07, December



Dressler, et al.    draft-dressler-ipfix-aggregation-00.txt    [Page 13]


Internet-Draft              IPFIX Aggregation               January 2005


              2004.

   [I-D.ietf-ipfix-info]
              Meyer, J., Quittek, J. and S. Bryant, "Information Model
              for IP Flow Information Export",
              Internet-Draft draft-ietf-ipfix-info-05, October 2004.

   [RFC3917]  Quittek, J., Zseby, T., Claise, B. and S. Zander,
              "Requirements for IP Flow Information Export", RFC 3917,
              October 2004.


Authors' Addresses

   Falko Dressler
   University of Erlangen
   Department of Computer Science 7
   Martensstr. 3
   Erlangen  91058
   Germany

   Phone: +49 9131 85-27914
   Email: dressler@informatik.uni-erlangen.de
   URI:   http://www7.informatik.uni-erlangen.de/


   Christoph Sommer
   University of Erlangen
   Department of Computer Science 7
   Martensstr. 3
   Erlangen  91058
   Germany

   Email: sichsomm@stud.informatik.uni-erlangen.de


   Gerhard Muenz
   University of Tuebingen
   Computer Networks and Internet
   Auf der Morgenstelle 10C
   Tuebingen  72076
   Germany

   Phone: +49 7071 29-70534
   Email: muenz@informatik.uni-tuebingen.de
   URI:   http://net.informatik.uni-tuebingen.de/





Dressler, et al.    draft-dressler-ipfix-aggregation-00.txt    [Page 14]


Internet-Draft              IPFIX Aggregation               January 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.




Dressler, et al.    draft-dressler-ipfix-aggregation-00.txt    [Page 15]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/