[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                          C. Sommer
Internet-Draft                                               F. Dressler
Intended status: Standards Track                          Univ. Erlangen
Expires: January 15, 2009                                       G. Muenz
                                                         Univ. Tuebingen
                                                           July 14, 2008


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

Abstract

   IPFIX supports the concept of a 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 aggregating and discarding received information.  This
   document introduces a number of extensions to the IPFIX Information
   Model that support the export of aggregated IPFIX data, introducing
   abstract data types and Information Elements that optimize the
   transport of descriptive information in terms of flow records' amount
   and size.  All extensions are directly applicable to the IPFIX
   Mediator but can be used in many different applications as well.



Sommer, et al.   draft-sommer-ipfix-mediator-ext-01.txt         [Page 1]


Internet-Draft     Mediator-Specific IPFIX Extensions          July 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Abstract data type orderedList . . . . . . . . . . . . . . . .  3
   3.  Abstract data type orderedPair . . . . . . . . . . . . . . . .  4
   4.  Abstract data type portRanges  . . . . . . . . . . . . . . . .  5
   5.  Abstract data type ipv4Network . . . . . . . . . . . . . . . .  7
   6.  excludedPropertiesId Information Element . . . . . . . . . . .  7
   7.  Security considerations  . . . . . . . . . . . . . . . . . . .  9
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   9.  Normative References . . . . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
   Intellectual Property and Copyright Statements . . . . . . . . . . 12






































Sommer, et al.   draft-sommer-ipfix-mediator-ext-01.txt         [Page 2]


Internet-Draft     Mediator-Specific IPFIX Extensions          July 2008


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 key 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 Information Model
   that support the export of aggregated IPFIX data.  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 [RFC5102].  Apart from the basic terms as
   defined in [RFC5101], this document uses terminology first introduced
   in [I-D.dressler-ipfix-aggregation].


2.  Abstract data type orderedList

   IPFIX allows the transport of an ordered list of values by including
   in a Template several Information Elements of the same type more than
   once.  This approach requires one Template for each possible length
   of the list.  In the context of flow mediation, however, the number
   of entries in such lists typically changes with each exported
   compound flow, leading to a dramatic increase of Templates and
   associated housekeeping overhead.  Therefore, a new abstract data
   type, orderedList, is defined in this section.

   The abstract data type orderedList defines an ordered list of
   Information Elements, each being of the same type (referred to as
   elementType) and the same, pre-defined length.  An orderedList can
   transport any finite number of Information Elements.  The length of
   an orderedList thus varies and is an integer multiple of the
   contained Information Elements' length.  If more than one contained
   Information Element is transmitted in the form of an orderedList,



Sommer, et al.   draft-sommer-ipfix-mediator-ext-01.txt         [Page 3]


Internet-Draft     Mediator-Specific IPFIX Extensions          July 2008


   reduced size encoding of elementType MUST NOT be used.  If only one
   contained Information Element is transmitted, reduced size encoding
   of elementType MAY be used.  In ABNF-style notation, the syntax can
   be summed up as follows:

                    orderedList     =  *( elementType )

   The number of Information Elements contained in an orderedList can be
   determined by dividing the length of the orderedList by the length of
   elementType.  An Information Element basing on orderedList MAY also
   be used as a variable-length Information Element by prefixing it with
   a one-octet or three-octet length specifier as defined in [RFC5101].

   Table 1 shows some encoding examples if unsigned16 is used as the
   elementType.

   +----------------+--------+----------------+-----------------------+
   | Human-Readable | Octets | Hexadecimal    | Remarks               |
   +----------------+--------+----------------+-----------------------+
   | 80             | 1      | 50             | Reduced size encoding |
   | 80             | 2      | 0050           |                       |
   | 80, 443        | 4      | 0050 01BB      |                       |
   | 80, 443, 8080  | 6      | 0050 01BB 1F90 |                       |
   +----------------+--------+----------------+-----------------------+

                       Table 1: orderedList Examples


3.  Abstract data type orderedPair

   The abstract data type orderedPair defines a 2-tuple of Information
   Elements, each being of the same type (referred to as elementType)
   and the same, pre-defined length.  The length of an orderedPair is
   thus defined as twice the length of its elementType.  If more than
   one contained Information Element is transmitted in the form of an
   orderedPair, reduced size encoding of elementType MUST NOT be used.
   If only one contained Information Element is transmitted, reduced
   size encoding of orderedPair MAY be used if both contained
   Information Elements are of the same value.  The reduced size
   representation of the orderedPair is in this case identical with the
   (full or reduced size representation) of elementType.  In ABNF-style
   notation, the syntax can be summed up as follows:

                 orderedPair     =  elementType elementType
                 orderedPair     =/ elementType

   Table 2 shows some encoding examples if unsigned16 is used as the
   elementType.



Sommer, et al.   draft-sommer-ipfix-mediator-ext-01.txt         [Page 4]


Internet-Draft     Mediator-Specific IPFIX Extensions          July 2008


     +----------------+--------+-------------+-----------------------+
     | Human-Readable | Octets | Hexadecimal | Remarks               |
     +----------------+--------+-------------+-----------------------+
     | 80, 80         | 1      | 50          | Reduced size encoding |
     | 80, 80         | 2      | 0050        | Reduced size encoding |
     | 80, 80         | 4      | 0050 0050   |                       |
     | 80, 443        | 4      | 0050 01BB   |                       |
     +----------------+--------+-------------+-----------------------+

                       Table 2: orderedPair Examples


4.  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
   this section.

   The abstract data type portRanges is an orderedList of orderedPair
   Information Elements, each pair consisting of two unsigned16
   Information Elements representing the port range's first and last
   port number.

   Data types basing on portRanges MAY thus be cast down to unsigned16
   using reduced size encoding to represent a single Port and, hence,
   the transportSourcePort and transportDestinationPort data types,
   currently based on the unsigned16 abstract data type, can also be
   parsed as portRanges-based data types.  As specified for data types
   basing on orderedList, 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 [RFC5101].

   Table 3 shows some encoding examples with portRanges.










Sommer, et al.   draft-sommer-ipfix-mediator-ext-01.txt         [Page 5]


Internet-Draft     Mediator-Specific IPFIX Extensions          July 2008


        +---------------+--------+-------------------------------+
        | 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 3: PortRanges Examples







































Sommer, et al.   draft-sommer-ipfix-mediator-ext-01.txt         [Page 6]


Internet-Draft     Mediator-Specific IPFIX Extensions          July 2008


5.  Abstract data type ipv4Network

   Currently, the transport of IP network information as specified by
   IPFIX is done using two 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 equaling four
   octets.  Applications such as IPFIX Aggregation benefit from
   ipv4Network if network addresses are frequently exported.


6.  excludedPropertiesId Information Element

   The IPFIX Information Model [RFC5102] 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
   Element Id 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
   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.

   Multiple excludedPropertiesId and commonPropertiesId specified for an
   IPFIX Record must never contradict each other.  If an IPFIX Collector
   is able to detect that contradicting IEs were received, it SHOULD



Sommer, et al.   draft-sommer-ipfix-mediator-ext-01.txt         [Page 7]


Internet-Draft     Mediator-Specific IPFIX Extensions          July 2008


   proceed as if it received bad or nonsensical data.

   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 1 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 1) 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 1 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-sommer-ipfix-mediator-ext-01.txt         [Page 8]


Internet-Draft     Mediator-Specific IPFIX Extensions          July 2008


           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 1: Using excludedPropertiesId to communicate a rule hierarchy


7.  Security considerations

   As all methods described in this document are merely variations on
   methods already introduced in [RFC5101], the same rules regarding
   exchange of Flow information apply.


8.  IANA Considerations

   Use of excludedPropertiesId, 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.



















Sommer, et al.   draft-sommer-ipfix-mediator-ext-01.txt         [Page 9]


Internet-Draft     Mediator-Specific IPFIX Extensions          July 2008


9.  Normative References

   [I-D.dressler-ipfix-aggregation]
              Dressler, F., "IPFIX Aggregation",
              draft-dressler-ipfix-aggregation-05 (work in progress),
              July 2008.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              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.

   [RFC5101]  Claise, B., "Specification of the IP Flow Information
              Export (IPFIX) Protocol for the Exchange of IP Traffic
              Flow Information", RFC 5101, January 2008.

   [RFC5102]  Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.
              Meyer, "Information Model for IP Flow Information Export",
              RFC 5102, January 2008.


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/


   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/





Sommer, et al.   draft-sommer-ipfix-mediator-ext-01.txt        [Page 10]


Internet-Draft     Mediator-Specific IPFIX Extensions          July 2008


   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-sommer-ipfix-mediator-ext-01.txt        [Page 11]


Internet-Draft     Mediator-Specific IPFIX Extensions          July 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.











Sommer, et al.   draft-sommer-ipfix-mediator-ext-01.txt        [Page 12]


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