Network Working Group                                          C. Sommer
Internet-Draft                                               F. Dressler
Expires: May 15, 2008                                     Univ. Erlangen
                                                                G. Muenz
                                                         Univ. Tuebingen
                                                       November 12, 2007


  Mediator-Specific Extensions to IPFIX Protocol and Information Model
                <draft-sommer-ipfix-mediator-ext-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 May 15, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   IPFIX supports the concept of an Mediator, a device that receives,
   transforms, and exports data streams using IPFIX.  One of the most
   important requirements is the reduction of the volume of IPFIX
   traffic by discarding and aggregating received information.  This
   document introduces a number of extensions to the IPFIX Protocol and
   IPFIX Information Model that support the export of aggregated IPFIX



Sommer, et al.   draft-dressler-ipfix-aggregation-04.txt        [Page 1]


Internet-Draft     Mediator-Specific IPFIX Extensions      November 2007


   data.  In particular, techniques are introduced that optimize the
   transport of descriptive information.  Thus, more information can be
   preserved in the transmission while further reducing both the number
   and the size of IPFIX messages.  All the proposed extensions are
   directly applicable to the IPFIX Mediator but can be used in many
   different applications as well.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Rich Template  . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Abstract data type ipv4Network . . . . . . . . . . . . . . . . 10
   5.  Abstract data type portRanges  . . . . . . . . . . . . . . . . 10
   6.  excludedPropertiesId Information Element . . . . . . . . . . . 11
   7.  precedingRulePropertiesId Information Element  . . . . . . . . 13
   8.  Security considerations  . . . . . . . . . . . . . . . . . . . 14
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     10.1.  Normative References  . . . . . . . . . . . . . . . . . . 14
     10.2.  Informative References  . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 17



























Sommer, et al.   draft-dressler-ipfix-aggregation-04.txt        [Page 2]


Internet-Draft     Mediator-Specific IPFIX Extensions      November 2007


1.  Introduction

   The IPFIX Mediator is intended to provide techniques and features to
   process IPFIX data in a Mediation Process.  This process receives
   data streams using IPFIX.  It can apply transformations or
   aggregation techniques and forward the resulting Flow information to
   an Exporting Process and, thus, to another IPFIX collector.  Flow
   aggregation is one of the most challenging and important operations
   in high-bandwidth networks.  The main idea is to reduce both the
   number and the size of IPFIX messages.  This document introduces
   extensions to the IPFIX Protocol and IPFIX Information Model that
   support the export of aggregated IPFIX data.  In particular, a new
   Template type is introduced and additional Information Elements are
   described.  All these extensions allow and optimize the transport of
   descriptive information on aggregated IPFIX data.  Thus, more
   information can be preserved in the transmission while further
   reducing both the number and the size of IPFIX messages.  All the
   proposed extensions are directly applicable to the IPFIX Mediator but
   can be used in many different applications as well.

   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].
   Illustrations of abstract data types are written in Augmented Backus-
   Naur Form (ABNF), as specified in [RFC4234], extending the abstract
   data types defined in [I-D.ietf-ipfix-info].


2.  Terminology

   Apart from the basic terms as defined in [I-D.ietf-ipfix-protocol],
   the following terms are used within this document:

   Compound Flow:
      A Compound Flow is the result of an aggregation of one or more
      individual input Flows that matched an Aggregation Rule.  It
      might, for example, contain the total count of all packets
      addressed to a common subnet that were observed within a given
      time interval.

   Aggregation Rule:
      An Aggregation Rule defines the properties of a Compound Flow and
      the contents of the corresponding Flow Records.  Optionally, a set
      of filtering criteria MAY be specified in order to restrict the
      applicability of the rule to those Flows that show certain
      patterns.





Sommer, et al.   draft-dressler-ipfix-aggregation-04.txt        [Page 3]


Internet-Draft     Mediator-Specific IPFIX Extensions      November 2007


3.  Rich Template

   [I-D.dressler-ipfix-aggregation] describes how pattern matching is
   used to restrict the applicability of an Aggregation Rule and how
   patterns define Common Properties of the resulting Compound Flows.
   In order to avoid the overhead of the repeated transmissions of all
   Common Properties (or their identifiers) in all Flow Records, a new
   Template Set, the "Rich Template Set" is introduced.  This Template
   Set allows an Exporting Process to simultaneously declare and
   transmit Common Properties to a receiver.

   The basic format of a Rich Template Set is shown in Figure 1.  It is
   the same as that of a Template Set defined in
   [I-D.ietf-ipfix-protocol], except for a different Set ID.  The format
   of individual Rich Template Records, however, differs from that of
   Template Records and is shown in Figure 2.

     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               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                     Rich Template Record 1                    |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                              ...                              |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                     Rich Template Record N                    |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Padding (opt)                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 1: Rich Template Set Format

   The Rich Template Set field definitions are as follows:

   Set ID
      Type of this Template Set. A Set ID value of 4 is proposed for the
      Rich Template Set.







Sommer, et al.   draft-dressler-ipfix-aggregation-04.txt        [Page 4]


Internet-Draft     Mediator-Specific IPFIX Extensions      November 2007


   Length
      Total length of this set in bytes, as defined in
      [I-D.ietf-ipfix-protocol].

   Padding
      OPTIONAL padding, as defined in [I-D.ietf-ipfix-protocol].













































Sommer, et al.   draft-dressler-ipfix-aggregation-04.txt        [Page 5]


Internet-Draft     Mediator-Specific IPFIX Extensions      November 2007


     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 (> 255)          |  Field Count                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Data Count                   |  Common Properties ID         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                       Field 1 Specifier                       |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                              ...                              |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                       Field N Specifier                       |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                        Data 1 Specifier                       |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                              ...                              |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                        Data M Specifier                       |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                          Data 1 Value                         |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                              ...                              |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                          Data M Value                         |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 2: Rich Template Record Format

   The Rich Template Record field definitions are as follows:




Sommer, et al.   draft-dressler-ipfix-aggregation-04.txt        [Page 6]


Internet-Draft     Mediator-Specific IPFIX Extensions      November 2007


   Template ID
      Template ID of this Rich Template Record.  As defined in
      [I-D.ietf-ipfix-protocol], this value MUST be greater than 255.

   Field Count
      Number of regular fields that will be sent in subsequent Data
      Records using this Template, as defined in
      [I-D.ietf-ipfix-protocol].

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

   Common Properties ID
      Contains an identifier that can be referred to by
      commonPropertiesId Information Elements, as introduced in
      [I-D.ietf-ipfix-reducing-redundancy].

   Field N Specifier
      Information Element identifier, Field length and an Enterprise
      Number (if applicable) of field N. Refer to
      [I-D.ietf-ipfix-protocol] for more information on Field
      Specifiers.

   Data M Specifier
      Same as "Field N Specifier", but used for Common Properties of all
      Data Records of this Template.  Together with Data M Value, a
      similar encoding like TLV (type-length-value) is achieved.

   Data M Value
      Bit representation of a Common Property as would be transmitted in
      a Data Record.

   Table 1 illustrates the relationship between field modifiers and
   patterns on the one hand, and the resulting regular and fixed-value
   fields in the Rich Template on the other hand.  It can be seen that
   the analyzer is able to deduce all instructions of the Aggregation
   Rule considering the structure of the Rich Template, except the
   combination "discard without pattern" that does not result in any
   field.












Sommer, et al.   draft-dressler-ipfix-aggregation-04.txt        [Page 7]


Internet-Draft     Mediator-Specific IPFIX Extensions      November 2007


   +----------+---------+------------------------+---------------------+
   | field    | pattern | field in Flow Record   | fixed-value field   |
   | modifier |         |                        | in Rich Template    |
   +----------+---------+------------------------+---------------------+
   | discard  | no      | N/A                    | N/A                 |
   | discard  | yes     | N/A                    | yes, contains       |
   |          |         |                        | pattern             |
   | keep     | no      | yes                    | N/A                 |
   | keep     | yes     | yes, if pattern        | yes, contains       |
   |          |         | specifies a range of   | pattern             |
   |          |         | values                 |                     |
   | mask     | no      | yes, IP network        | N/A                 |
   |          |         | address                |                     |
   | mask     | yes     | yes, IP network        | yes, contains       |
   |          |         | address                | pattern             |
   +----------+---------+------------------------+---------------------+

     Table 1: Relation between field modifiers, Flow Records, and Rich
                                 Templates

   Assume, for example, the concentrator was given the Aggregation Rule
   shown in Table 2.

         +-------------------------+--------------+-------------+
         | IPFIX Field             | Filtering    | Aggregation |
         +-------------------------+--------------+-------------+
         | sourceIPv4Address       | 192.0.2.0/28 | discard     |
         | destinatonTransportPort |              | keep        |
         | packetDeltaCount        |              | aggregate   |
         +-------------------------+--------------+-------------+

                           Table 2: Example Rule

   Based on the Aggregation Rule, the concentrator would now first send
   a corresponding Rich Template Record as shown in Table 3.
















Sommer, et al.   draft-dressler-ipfix-aggregation-04.txt        [Page 8]


Internet-Draft     Mediator-Specific IPFIX Extensions      November 2007


                +----------------------+------------------+
                | Field                | Value            |
                +----------------------+------------------+
                | Template ID          | 10001            |
                | Field Count          | 2                |
                | Data Count           | 2                |
                | Common Properties ID | 0                |
                | Field 1 Type         | Destination Port |
                | Field 2 Type         | Packets          |
                | Data 1 Type          | Source IP Prefix |
                | Data 2 Type          | Source IP Mask   |
                | Data 1 Value         | 192.0.2.0        |
                | Data 2 Value         | 28               |
                +----------------------+------------------+

                        Table 3: Rich Template used

   Assume further that the concentrator receives the Flow Records shown
   in Table 4.

   +-------------+-----------+--------------+----------------+---------+
   | Source IP   | Source    | Destination  | Destination    | Packets |
   |             | Port      | IP           | Port           |         |
   +-------------+-----------+--------------+----------------+---------+
   | 192.0.2.1   | 64235     | 192.0.2.101  | 80             | 10      |
   | 192.0.2.2   | 64236     | 192.0.2.102  | 110            | 10      |
   | 192.0.2.3   | 64237     | 192.0.2.103  | 80             | 10      |
   | 192.0.2.101 | 64238     | 192.0.2.1    | 80             | 10      |
   | 192.0.2.102 | 64239     | 192.0.2.2    | 80             | 10      |
   +-------------+-----------+--------------+----------------+---------+

                          Table 4: Incoming Flows

   The concentrator would then export Data Records of this type, which
   contain the Compound Flows resulting from aggregation.  Note that the
   Flows' Common Property, having a source IP address in 192.0.2.0/28,
   was already transmitted in the Rich Template Record and is thus not
   included in Data Records.  The exported Data Records, shown in
   Table 5, only contain the aggregated packet counts and the
   destination port, the latter being the only discriminating Flow Key
   property.










Sommer, et al.   draft-dressler-ipfix-aggregation-04.txt        [Page 9]


Internet-Draft     Mediator-Specific IPFIX Extensions      November 2007


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

                         Table 5: Aggregated Flows


4.  Abstract data type ipv4Network

   Currently, the transport of IP network information as specified by
   IPFIX is done using separate fields for the network address and the
   corresponding mask.  We propose a new abstract data type ipv4Network
   that represents the common notation of IP networks: address/mask.

   The ipv4Network abstract data type extends the abstract data type
   ipv4Address to allow a concatenated unsigned8 specifying the prefix
   length.  Alternatively, Information Elements based on the ipv4Network
   abstract data type MAY be transmitted using reduced size encoding to
   transmit only the network part of an IPv4 address.  In ABNF-style
   notation, the syntax can be summed up as follows:

                  ipv4Network    =  ipv4Address unsigned8
                  ipv4Network    =/ *4( unsigned8 )

   Although using an ipv4Network field instead of two separate fields
   for prefix and mask will not reduce the length of resulting Flow
   Records, it eases the work of the aggregator: With ipv4Network, the
   comparison of subnet addresses requires only one field lookup per
   Flow Record instead of two.  Furthermore, using the abstract data
   type ipv4Network reduces the Template size by one field equalling
   four octets.  Applications such as IPFIX Aggregation benefit from
   ipv4Network if network addresses are frequently exported.


5.  Abstract data type portRanges

   For some applications it might be useful to restrict the
   applicability of an Aggregation Rule to Flows with source or
   destination port being of a specific set of port numbers.  In an
   Aggregation Rule, such a set of port numbers can be specified as a
   pattern.  However, the current IPFIX Information Model does not
   define any data type that allows transmitting a set of port numbers,
   which is necessary in order to export the pattern as a Common
   Property of the resulting Compound Flows.  Therefore, the new
   abstract data type portRanges for a list of port ranges is defined in



Sommer, et al.   draft-dressler-ipfix-aggregation-04.txt       [Page 10]


Internet-Draft     Mediator-Specific IPFIX Extensions      November 2007


   this section.

   The abstract data type portRanges is a finite-length concatenation of
   unsigned16 value pairs, each consisting of the port range's first and
   last port number.  Data types basing on portRanges MAY also be cast
   down to unsigned16 using reduced size encoding to represent a single
   Port.  Hence, the transportSourcePort and transportDestinationPort
   data types, currently based on the unsigned16 abstract data type, can
   also be parsed as portRanges-based data types.  In ABNF-style
   notation, the syntax can be summed up as follows:

                 portRanges     =  *(unsigned16 unsigned16)
                 portRanges     =/ unsigned16

   An Information Element basing on portRanges MAY also be used as a
   variable-length Information Elements by prefixing it with a one-octet
   or three-octet length specifier as defined in
   [I-D.ietf-ipfix-protocol].

   Table 6 shows some encoding examples with portRanges.

        +---------------+--------+-------------------------------+
        | Port Ranges   | Octets | 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 6: PortRanges Examples


6.  excludedPropertiesId Information Element

   The IPFIX Information Model [I-D.ietf-ipfix-info] defines the
   commonPropertiesId Information Element, which can be used to link to
   information which several Flows have in common.

   Similarly, the excludedPropertiesId shall be defined to link to a set
   of Common Properties which a Flow does explicitly not exhibit.  An
   ElementId of 239 is proposed for this Information Element.

   The excludedPropertiesId works like a boolean "and not" operation on
   the linked properties.  This means that, if an excludedPropertiesId
   refers to a set of Common Properties which in turn specifies excluded



Sommer, et al.   draft-dressler-ipfix-aggregation-04.txt       [Page 11]


Internet-Draft     Mediator-Specific IPFIX Extensions      November 2007


   properties, these transitively referenced properties are to be
   treated as if directly referenced via a commonPropertiesId element
   and, hence, as being present in the Flow in question.

   The excludedPropertiesId can, for example, be used when a hierarchy
   of Aggregation Rules with a "preceding rule" semantic, as introduced
   in [I-D.dressler-ipfix-aggregation], is configured in an IPFIX
   Aggregator.

   Figure 5 illustrates the use of Common Property definitions and the
   linking to these definitions with Information Elements of types
   commonPropertiesId (CP) and excludedPropertiesId (EP).  In this
   example, two rules are defined in the aggregator: Rule 1 matches
   Flows with a sourceIPv4Address of 192.0.2.1, Rule 2 matches Flows
   with a destinationIPv4Address of 192.0.2.2.  Furthermore, Rule 1 is
   configured to precede Rule 2 in a hierarchy of rules, i.e.  Flows
   that matched Rule 1 will never match Rule 2.

   In order to communicate this fact to a receiver, each Aggregation
   Rule is transmitted as two sets of Common Properties.  One set of
   properties (shown on the right hand side of Figure 5) directly
   transmits a rule's filtering criteria.  The other set of properties
   (shown on the left hand side) refers via a commonPropertiesId to all
   properties that a Compound Flow exhibits, as well as via an
   excludedPropertiesId to all that the Compound Flow does not exhibit.

   The Flow depicted at the bottom of Figure 5 thus communicates a
   source port of 80, a destination port of 65432, a destination IP of
   192.0.2.2 and a source IP of "not 192.0.2.1".  However, besides the
   transmission of this Flow in one Data Record, previous transmissions
   (and the successful reception) of four Option Templates, four Option
   Data Records and one Template are required to communicate this
   information.


















Sommer, et al.   draft-dressler-ipfix-aggregation-04.txt       [Page 12]


Internet-Draft     Mediator-Specific IPFIX Extensions      November 2007


           Rule 1:
           +########+------+             +######+---------------+
           # CP=101 # CP=1 |<-----------># CP=1 # SRC=192.0.2.1 |
           +########+------+             +######+---------------+
                                            ^
                       .--------------------'
           Rule 2:     v
           +########+------+------+      +######+---------------+
           # CP=102 # EP=1 | CP=2 |<----># CP=2 # DST=192.0.2.2 |
           +########+------+------+      +######+---------------+
                ^
                '-------------------.
           Flow:                    v
           +--------+-----------+--------+
           | SPT=80 | DPT=65432 | CP=102 |
           +--------+-----------+--------+

   Figure 5: Using excludedPropertiesId to communicate a rule hierarchy


7.  precedingRulePropertiesId Information Element

   The only aspect in which the precedingRulePropertiesId Information
   Element differs from the excludedPropertiesId Information Element
   introduced in Section 6 is that transitive references are handled
   differently.

   Unlike the excludedPropertiesId, the precedingRulePropertiesId does
   not work like a boolean "and not" operation on the linked properties.
   This means that, if a precedingRulePropertiesId refers to a set of
   Common Properties which in turn specifies excluded properties, these
   transitively referenced properties are to be treated as being
   excluded from the Flow in question, too.

   Analogous to excludedPropertiesId, the precedingRulePropertiesId (PP)
   Information Element can be used to communicate the hierarchy of rules
   introduced in the example of Section 6.  As illustrated in Figure 6,
   the amount of data transmitted is now significantly smaller, while
   communicating the exact same information: A source port of 80, a
   destination port of 65432, a destination IP of 192.0.2.2 and a source
   IP of "not 192.0.2.1".  Besides the transmission of the Flow in one
   Data Record it only requires the previous transmissions (and the
   successful reception) of two Rich Templates.








Sommer, et al.   draft-dressler-ipfix-aggregation-04.txt       [Page 13]


Internet-Draft     Mediator-Specific IPFIX Extensions      November 2007


           Rule 1:
           +---------------+
           | SRC=192.0.2.1 |<---.   (Rich Template 1234, CP=101)
           +---------------+    |
                                |
                                |
           Rule 2:              |
           +---------------+--------+
           | DST=192.0.2.2 | PP=101 |       (Rich Template 1235)
           +---------------+--------+


           Flow:
           +--------+-----------+
           | SPT=80 | DPT=65432 |  (Based on Rich Template 1235)
           +--------+-----------+

      Figure 6: Using precedingRulePropertiesId to communicate a rule
                                 hierarchy


8.  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.


9.  IANA Considerations

   Use of the Rich Template Set requires one new IPFIX Set ID to be
   assigned.  Use of excludedPropertiesId, precedingRulePropertiesId, as
   well as use of a data type basing on ipv4Network or on portRanges
   requires one new IPFIX Information Element identifier each to be
   assigned.


10.  References

10.1.  Normative References

   [I-D.ietf-ipfix-protocol]
              Claise, B., "Specification of the IPFIX Protocol for the
              Exchange of IP Traffic Flow  Information",
              draft-ietf-ipfix-protocol-26 (work in progress),
              September 2007.

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



Sommer, et al.   draft-dressler-ipfix-aggregation-04.txt       [Page 14]


Internet-Draft     Mediator-Specific IPFIX Extensions      November 2007


              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 4234, October 2005.

10.2.  Informative References

   [I-D.dressler-ipfix-aggregation]
              Dressler, F., "IPFIX Aggregation",
              draft-dressler-ipfix-aggregation-03 (work in progress),
              June 2006.

   [I-D.ietf-ipfix-info]
              Quittek, J., "Information Model for IP Flow Information
              Export", draft-ietf-ipfix-info-15 (work in progress),
              February 2007.

   [I-D.ietf-ipfix-reducing-redundancy]
              Boschi, E., "Reducing Redundancy in IP Flow Information
              Export (IPFIX) and Packet  Sampling (PSAMP) Reports",
              draft-ietf-ipfix-reducing-redundancy-04 (work in
              progress), May 2007.


Authors' Addresses

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

   Phone: +49 9131 85-27993
   Email: christoph.sommer@informatik.uni-erlangen.de
   URI:   http://www7.informatik.uni-erlangen.de/~sommer/















Sommer, et al.   draft-dressler-ipfix-aggregation-04.txt       [Page 15]


Internet-Draft     Mediator-Specific IPFIX Extensions      November 2007


   Falko Dressler
   University of Erlangen-Nuremberg
   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/


   Gerhard Muenz
   University of Tuebingen
   Computer Networks and Internet
   Sand 13
   Tuebingen  72076
   Germany

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





























Sommer, et al.   draft-dressler-ipfix-aggregation-04.txt       [Page 16]


Internet-Draft     Mediator-Specific IPFIX Extensions      November 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.

   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, THE IETF TRUST 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.


Intellectual Property

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Sommer, et al.   draft-dressler-ipfix-aggregation-04.txt       [Page 17]