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

Versions: 00 01 02 03 04 05 06 07 08 09 RFC 6183

IPFIX Working Group                                         A. Kobayashi
Internet-Draft                                                H. Nishida
Intended status: Informational                               NTT PF Lab.
Expires: January 1, 2009                                       B. Claise
                                                           Cisco Systems
                                                           June 30, 2008


                       IPFIX Mediation: Framework
                draft-ietf-ipfix-mediators-framework-00

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 1, 2009.
















Kobayashi, et al.        Expires January 1, 2009                [Page 1]

Internet-Draft          IPFIX Mediation Framework              June 2008


Abstract

   This document describes a framework for an IPFIX Mediation.  An IPFIX
   Mediation device (IPFIX Mediator) is an intermediate device between
   IPFIX Exporters and IPFIX Collectors.  This framework describes an
   architecture model, the components of the architecture, and
   guidelines for the IPFIX protocol specifications for the IPFIX
   Mediators.  In addition, this document describes applicable examples
   for IPFIX Mediation.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Architecture Model . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Collecting Process . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Exporting Process  . . . . . . . . . . . . . . . . . . . .  6
     3.3.  Intermediate Process . . . . . . . . . . . . . . . . . . .  7
       3.3.1.  Metering Process . . . . . . . . . . . . . . . . . . .  8
       3.3.2.  IPFIX File Writer/Reader . . . . . . . . . . . . . . . 10
   4.  Guideline for IPFIX Protocol for IPFIX Mediators . . . . . . . 12
     4.1.  Handling Delta Time Field  . . . . . . . . . . . . . . . . 12
     4.2.  Observation Domain ID Management . . . . . . . . . . . . . 12
     4.3.  Template ID Management . . . . . . . . . . . . . . . . . . 13
     4.4.  Transport Session Management . . . . . . . . . . . . . . . 13
     4.5.  Option Template Management . . . . . . . . . . . . . . . . 14
     4.6.  Reporting Original Exporter Information  . . . . . . . . . 14
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 17
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 17
   Appendix A.  Solution Scenarios with IPFIX Mediators . . . . . . . 19
     A.1.  Flexible Aggregation . . . . . . . . . . . . . . . . . . . 19
     A.2.  Distributed Aggregation  . . . . . . . . . . . . . . . . . 19
     A.3.  Duplication of Flow Records  . . . . . . . . . . . . . . . 20
     A.4.  Distribution of Flow Records . . . . . . . . . . . . . . . 21
     A.5.  Extraction of Suspicious Flow  . . . . . . . . . . . . . . 22
   Appendix B.  Acknowledgements  . . . . . . . . . . . . . . . . . . 23
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
   Intellectual Property and Copyright Statements . . . . . . . . . . 25









Kobayashi, et al.        Expires January 1, 2009                [Page 2]

Internet-Draft          IPFIX Mediation Framework              June 2008


1.  Introduction

   This document describes the framework for IPFIX Mediators to reroute,
   filter, aggregate, correlate, or modify Flow Records/Packet Reports,
   and to export the output to Collectors.

   The motivation for the IPFIX Mediation standard comes from the need
   for flow-based measurement system support for large-scale networks,
   interdomain networks, and coexistence with traditional Exporters as
   described in [I-D.ietf-ipfix-mediators-ps] in detail.  The standard
   specification requires a definition of IPFIX Mediator, and a
   consistency in the IPFIX protocol between Exporters and Mediators,
   and between Collectors and Mediators.  The motivation for the IPFIX
   Mediation functions comes from the applications that enable a
   scalable and flexible measurement system.

   This document is organized as follows.  Section 2 describes
   terminologies related to IPFIX Mediation.  Section 3 describes the
   architecture model and details the components of this architecture.
   Section 4 describes the consideration points and guideline for the
   IPFIX protocol.






























Kobayashi, et al.        Expires January 1, 2009                [Page 3]

Internet-Draft          IPFIX Mediation Framework              June 2008


2.  Terminology

   The basic terms related to IPFIX protocol, such as Metering Process,
   Exporting Process, Collecting Process and Data Record, are aligned
   with the definitions in [RFC5101].  The terms related to PSAMP
   protocol specifications like Packet Reports and Packet
   Interpretation, are aligned with the definitions in
   [I-D.ietf-psamp-protocol].  The terms related to IPFIX Device, such
   as Exporter, Collector, IPFIX Proxy and IPFIX Concentrator, are
   aligned with the definitions in [RFC3917].  The terms related to
   IPFIX Mediation Device, such as IPFIX Masquerading Proxy and IPFIX
   Distributor are aligned with the definitions in
   [I-D.ietf-ipfix-mediators-ps].  Other than the above terms are
   defined here.  All these terms are capitalized in this document.

   Mediator Metering Process

      A Metering Process in IPFIX Mediators can be considered as a
      partial Metering Process separated from that in Original Exporters
      as described in [RFC3917].

      The Mediator Metering Process generates new sets of Data Records/
      Packet Reports from input Data Records/Packet Reports.  The
      functionality of the Mediator Metering Process includes selecting,
      aggregating, and modifying Flow Records/Packet Reports, but is not
      limited to: selection, aggregation, modification.

   Flow-Based Collector Selection Function

      This function filters input Flow Records/Packet Reports based on
      the value of the specified Information Element and then selects
      Collectors for the filtered (classified) Flow Records/Packet
      Reports.

   Mediator Observation Domain ID

      An IPFIX Mediator does not host the Observation Points and
      Observation Domain.  The Observation Domain ID in the IPFIX header
      sent by IPFIX Mediator also indicates the largest set of
      Observation Points from the viewpoint of a Collector.  However
      this value does not indicate the physical entity of an Original
      Exporter.

   Transport Session Information

      In SCTP, the Transport Session Information is the SCTP
      association.  In TCP and UDP, the Transport Session Information
      corresponds to a 5-tuple {Exporter IP address, Collector IP



Kobayashi, et al.        Expires January 1, 2009                [Page 4]

Internet-Draft          IPFIX Mediation Framework              June 2008


      address, Exporter transport port, Collector transport port,
      transport protocol}.

















































Kobayashi, et al.        Expires January 1, 2009                [Page 5]

Internet-Draft          IPFIX Mediation Framework              June 2008


3.  Architecture Model

   Here is the basic IPFIX Mediator architecture model.  The IPFIX
   Mediator is formally defined to consist of one or more Collecting
   Processes, zero or more intermediate processes, and one or more
   Exporting Processes.  Basically, IPFIX Mediator devices: IPFIX Proxy,
   IPFIX Masquerading Proxy, IPFIX Distributor and IPFIX Concentrator
   are composed of these components.  The following subsection describes
   details of each component and examples applicable to the component.


            .-------------------------------------------------.
            |  .----------.                       .----------.|
            | .----------.|    .------------.    .----------.||
            |.----------.||   .------------.|   .----------.|||
      IPFIX ||Collecting|||   |Intermediate||   |Exporting ||||IPFIX
      ----->||Processes ||'-->|Processes   ||-->|Processes ||'|----->
            ||          |'    |(optional)  |'   |          |' |
            |'----------'     '------------'    '----------'  |
            '-------------------------------------------------'

   Figure A: Basic IPFIX Mediator Model.

3.1.  Collecting Process

   The Collecting Process receives Data Records/Packet Reports from
   Original Exporters as described in [RFC5101].  The process forwards
   the received Data Records/Packet Reports with IPFIX header
   information and Transport Session Information to multiple components:
   Intermediate Processes and Exporting Processes.  In other words, the
   process may duplicate received Data Records/Packet Reports and
   forward them to multiple components in sequence or in parallel.

3.2.  Exporting Process

   The Exporting Process forwards Data Records/Packet Reports to one or
   multiple Collectors.  The process manages the reporting Template and
   makes an IPFIX Message as described in [RFC5101].  In addition, the
   process carries out a Flow-based Collector Selection Function as
   optional.

   Applicable examples include exporting Flow Records/Packet Reports to
   a dedicated Collector on the basis of customers/peering
   organizations.  The Exporting Process classifies Flow Records/Packet
   Reports on the basis of a peering AS number, as shown in the
   following figure.  The set of classified Flow Records/Packet Reports
   is exported to a dedicated Collector on the basis of the peering AS
   number.



Kobayashi, et al.        Expires January 1, 2009                [Page 6]

Internet-Draft          IPFIX Mediation Framework              June 2008


           .----------------------------.
           | Exporting Process          |
           |   .----------------------. |
           |   | Flow-Based Collector | |
           |   | Selection Function   | |
           |   |                      | |
           |   |     Peering AS #10   | |
           |   |  +-------------------+-+---> Collector #1
           |   |  |  Peering AS #20   | |
   Flow  --+---+--+-------------------+-+---> Collector #2
   Records |   |  |  Peering AS #30   | |
           |   |  +-------------------+-+---> Collector #3
           |   '----------------------' |
           '----------------------------'

   Figure B: Exporting classified Flow Records to dedicated Collector.

3.3.  Intermediate Process

   The most generic intermediate process configuration is composed of a
   Metering Process, and/or an IPFIX File Reader/Writer described in
   [I-D.ietf-ipfix-file].  Metering Process as a typical component of
   IPFIX Concentrator and Remote Observation is described in [RFC5101].
   A possible configuration model of these components is as follows.


   .----------. .------------------------------------. .---------.
   |          | |        Intermediate Process        | |         |
   |          | |  .-------------------------------. | |         |
   |Collecting| |  |        Metering Process       | | |Exporting|
   |Process   | |  |.-------.  .-------.  .-------.| | |Process  |
   |          |---->|sub    |->|sub    |->|sub    |--->|         |
   |          | |  ||process|  |process|  |process|| | |         |
   |          | |.->|#1     |  |#2     |  |#3     || | |         |
   |          | || |'-------'  '-------'  '-------'| | |         |
   |          | || '----|----------|----------|----' | |         |
   |          | ||      |          |          |      | |         |
   |          | || .----\/---------\/---------\/---. | |         |
   |          | |'-|  IPFIX File Reader/Writer     |<--|         |
   |          |--->|                               |-->|         |
   |          | |  '-------------------------------' | |         |
   '----------' '------------------------------------' '---------'

   Figure C: Intermediate Process Component Model.







Kobayashi, et al.        Expires January 1, 2009                [Page 7]

Internet-Draft          IPFIX Mediation Framework              June 2008


3.3.1.  Metering Process

   The Metering Process generates new sets of Data Records/Packet
   Reports from input Data Records/Packet Reports with IPFIX header
   information: "Export Time" and "Observation Domain ID".  The process
   hosts several subprocesses: the Selecting Process, Aggregating
   Process, and Modifying Process.  These subprocesses can connect to
   each other in any sequence.  The output of each subprocess can be
   inputs of other subprocesses.  Subprocesses are as follows.

   Selecting Process

      A Selecting Process in IPFIX Mediators is analogous to that in
      PSAMP Devices described in [I-D.ietf-psamp-framework].  The
      Selecting Process selects input Data Records/Packet Reports
      matching under some filtering policy and then forwards them to the
      next process.

   Aggregating Process

      An Aggregating Process creates aggregated Flow Records from input
      Flow Records/Packet Reports in accordance with aggregation rules
      that are described in [I-D.dressler-ipfix-aggregation].

   Modifying Process

      A Modifying Process comprises two different types of modification,
      as follows.

      *  Adding/deleting specified Information Elements: changing data
         structure of Template.

      *  Modifying the value of a specified Information Element.

   Each subprocess is shown in detail.

3.3.1.1.  Selecting Process

   The Selecting Process uses several selection techniques, such as
   property match filtering and Flow selection techniques, which are
   described in [I-D.ietf-psamp-framework] and
   [I-D.peluso-flowselection], respectively.  In property match
   filtering, if the value of specified Information Element equal a pre-
   configured value, the function selects Data Records//Packet Reports
   to forward them to the next process.






Kobayashi, et al.        Expires January 1, 2009                [Page 8]

Internet-Draft          IPFIX Mediation Framework              June 2008


3.3.1.2.  Aggregating Process

   The Aggregating Process gathers Flow Records/Packet Reports within a
   given time interval and then distinguishes Flow Records/Packet
   Reports that have common properties.  If values of a given key field
   are the same, that means those Flow Records/Packet Reports have
   common properties.  This process merges Flow Records/Packet Reports
   that have a common property and creates an aggregated Flow Record.
   For example, aggregated Flow Records have an aggregation counter that
   indicates the number of packets.  These functions are defined in
   accordance with the IPFIX aggregation rules in
   [I-D.dressler-ipfix-aggregation].

   In addition, the process can create statistical data and subsidiary
   information related to the aggregated Flow Records.  Examples include
   the number of input Flow Records/Packet Reports, the given interval
   time, and a set of Flow Key Information Elements.

3.3.1.3.  Modifying Process

   The Modifying Process modifies input Data Records/Packet Reports.
   The process can add new Information Elements, delete existing
   Information Elements, or modify the value of specified Information
   Elements.  If the process modifies the data structure of an original
   Template, it also needs to modify the value of the
   "flowKeyIndicator".

   Adding specified Information Elements

      This function obtains the value of a specified Information
      Element, and then adds it into Data Records/Packet Reports.  There
      are several methods to obtain the value: retrieving the value from
      some database or calculating the value based on the value of other
      Information Elements and received traffic data.

      Applicable examples include adding derived packet property
      parameters instead of Original Exporters.  Doing that can
      compensate for traditional Exporters or probes unable to add
      packet property parameters.  Therefore, Collectors do not need to
      recognize the difference between implementations of routers from
      several vendors or Exporter types, such as router, switch or
      probe.  Typical derived packet property parameters include:

      *  "bgpNextHop{IPv4|IPv6}Address" described in [RFC5102] indicates
         the egress router of some network domain.  That is useful for
         making a traffic matrix that covers the whole network domain.





Kobayashi, et al.        Expires January 1, 2009                [Page 9]

Internet-Draft          IPFIX Mediation Framework              June 2008


      *  BGP Community value indicates the same group of destination or
         source IP addresses.

      *  "mplsVpnRouteDistinguisher" described in [RFC5102], which
         cannot be extracted from the core router in MPLS networks,
         indicates the VPN customer's identification.  Network operators
         can monitor the traffic behavior of each customer by adding
         "mplsVpnRouteDistinguisher" to Flow Records/Packet Reports.

   Deleting specified Information Elements

      This function deletes existing Information Elements according to
      instruction rules, which indicate whether an Information Element
      should be removed.

      Applicable examples include hiding network topology information
      and private information.  In the case of interdomain IPFIX
      exporting, the function can avoid making a vulnerability by
      deleting unnecessary Information Elements.  Examples of network
      topology information include: "ipNextHopIP{v4|v6}Address",
      "bgpNextHopIP{v4|v6}Address", and "bgp{Next|Prev}AdjacentAsNumber"
      described in [RFC5102].  In addition, MPLS-related Information
      Elements, such as "mplsLabelStackSection", are useless for
      customers in the case of feeding Flow Records/Packet Reports to
      VPN customers.

   Modifying the value of specified Information Elements

      This function modifies the value of specified Information
      Elements.

      Applicable examples include anonymizing customers' private
      information, such as IP address and port number, according to a
      privacy protection policy.  IPFIX Mediators may anonymize Data
      Records/Packet Reports instead of the Exporting Processes of
      Original Exporter as described in [RFC3917].  The function also
      reports anonymization methods and the part of anonymized data as
      subsidiary information.

3.3.2.  IPFIX File Writer/Reader

   The process of IPFIX File Writer stores input Data Records/Packet
   Reports from any process in a storage system.  If received Data
   Records/Packet Reports include uninteresting Information Elements,
   the Modifying Process can delete these elements before IPFIX File
   Writer handles them.  Therefore, IPFIX File Writers can accept input
   from any process.  In either case, input needs to include the IPFIX
   header information and the Transport Session Information along with



Kobayashi, et al.        Expires January 1, 2009               [Page 10]

Internet-Draft          IPFIX Mediation Framework              June 2008


   Flow Records/Packet Reports.

   On the other hand, the process of IPFIX File Reader retrieves stored
   Data Records/Packet Reports when operators want to retrieve past Data
   Records/Packet Reports on the basis of a given time period.  If a
   data structure of output Data Records/Packet Reports from IPFIX File
   Reader is different from that which operators want, the Modifying
   Process can modify the data structure.  Therefore, output of IPFIX
   File Readers can be input to any process except for the Collecting
   Process.  The IPFIX File Writer/Reader are described in
   [I-D.ietf-ipfix-file] in detail.








































Kobayashi, et al.        Expires January 1, 2009               [Page 11]

Internet-Draft          IPFIX Mediation Framework              June 2008


4.  Guideline for IPFIX Protocol for IPFIX Mediators

   This section describes consideration points and guideline for IPFIX
   Protocol for IPFIX Mediators.

4.1.  Handling Delta Time Field

   IPFIX Mediators need to compensate for any delta time stamp fields,
   such as "flowStartDeltaMicroseconds" and "flowEndDeltaMicroseconds",
   if Exporting Processes write the "Export Time" field of an IPFIX
   Message when an IPFIX Message leaves.  These Information Elements
   indicate the difference from "Export Time".  IPFIX Mediators can
   carry that out in several ways:

   o  reusing the "Export Time" of received IPFIX Messages from the
      Original Exporter.

   o  rewriting the value of delta time fields based on the new value of
      "Export Time".

   o  deleting the delta time fields after adding the absolute and fixed
      time fields.

   In either case, IPFIX Mediators need to guarantee the value of time
   stamp fields.

4.2.  Observation Domain ID Management

   IPFIX Mediators need to guarantee a unique Observation Domain ID for
   an Exporting Process to comply with the IPFIX Protocol.  IPFIX
   Mediators can carry that out in several ways:

   o  relaying the Observation Domain ID in a received IPFIX Message.

   o  assigning a new value to the Observation Domain ID and replacing
      it with the new one.

   o  overwriting zero value of Observation Domain ID under the
      condition that one Transport Session has one Observation Domain
      ID.

   The method for handling Observation Domain ID also depends on the
   role of devices and relaying patterns for IPFIX transport sessions:

   o  from one receiving session to one exporting session.

   o  from one receiving session to multiple exporting sessions.




Kobayashi, et al.        Expires January 1, 2009               [Page 12]

Internet-Draft          IPFIX Mediation Framework              June 2008


   o  from multiple receiving sessions to one exporting session.

   o  from multiple receiving sessions to multiple exporting sessions.

   In the case of relaying from one session to one or more sessions,
   IPFIX Mediators can directly relay IPFIX Messages as an IPFIX Proxy
   without replacing the Observation Domain ID.  In the case of other
   patterns, IPFIX Mediators need to replace the Observation Domain ID
   with the new value and manage the new and original Observation Domain
   ID along with the received Transport Session Information.  This
   linkage information is available for overwriting the scope field of
   the Option Template.

   Note:
   To comply with the description in [RFC5101], if IPFIX Mediators
   aggregate the received Flow Records, the new value of an Observation
   Domain ID needs to be zero.  However, that seems to be selectable, if
   IPFIX Mediator can assign the value of Observation Domain ID for a
   large set of Observation Points.

4.3.  Template ID Management

   IPFIX Mediators need to guarantee the unique Template ID for an
   Observation Domain ID to comply with the IPFIX Protocol.  IPFIX
   Mediators can carry that out in several ways:

   o  relaying the Template ID in a received IPFIX Message under the
      condition that the Observation Domain ID is relayed.

   o  using the fixed value under the condition that the fixed Template
      is applied to any input Data Records/Packet Reports/Packet
      Interpretation.

   o  assigning the new value to the Template ID and replacing it with
      the new value.

   In either case, IPFIX Mediators need to manage the new value and
   original value of Template ID along with the received Transport
   Session Information and Observation Domain ID.  Note that in case
   sending an Option Template and a Template Withdraw Message, the
   values of the scope field and the Template ID field are correct.

4.4.  Transport Session Management

   IPFIX Mediators need to manage the collecting sessions and the
   exporting sessions.  Even if one session is reset, IPFIX Mediators
   need to maintain the status of the other session.  However, Templates
   for resetting the collecting session need to be withdrawn for the



Kobayashi, et al.        Expires January 1, 2009               [Page 13]

Internet-Draft          IPFIX Mediation Framework              June 2008


   Exporting Session under the condition that IPFIX Mediators assign the
   new value to the Template ID.

4.5.  Option Template Management

   IPFIX Mediators need to guarantee the scope field to be applicable.
   Generally, Options Data Records include subsidiary data for Flow
   Records/Packet Reports, and statistics data for IPFIX protocol
   session.  For subsidiary data, such as "samplingSize" and
   "systemInitTimeMilliseconds", IPFIX Mediators can carry that out in
   several ways:

   o  merging the data into Flow Records/Packet Reports without
      exporting Options Data Records.

   o  modifying the value in the scope fields to match the Observation
      Domain ID and Template ID, and exporting it.

   In either case, IPFIX Mediators need to report the subsidiary data to
   the next Collector.  For statistics data, IPFIX Mediators can also
   carry that out in several ways:

   o  adding the counter of the received data and that of IPFIX
      Mediators, and exporting it.

   o  relaying the received data without changing the counters.

   o  by not exporting the received data.

   The method also depends on the role of devices: IPFIX Proxy or other
   devices.

4.6.  Reporting Original Exporter Information

   Whether to report Original Exporter information, such as Exporter IP
   address, or not depends on the role of the device.  IPFIX Mediators
   may determine that based on the pre-configured rule.  The reporting
   methods include:

   o  merging Original Exporter Information into Flow Records/Packet
      Reports, and exporting them.

   o  creating Options Data Records regarding the Original Exporter
      Information and exporting them.







Kobayashi, et al.        Expires January 1, 2009               [Page 14]

Internet-Draft          IPFIX Mediation Framework              June 2008


5.  Security Considerations

   IPFIX Mediators use the IPFIX protocol.  Security considerations
   about Flow Records are described in [RFC5101].















































Kobayashi, et al.        Expires January 1, 2009               [Page 15]

Internet-Draft          IPFIX Mediation Framework              June 2008


6.  IANA Considerations

   This document has no actions for IANA.
















































Kobayashi, et al.        Expires January 1, 2009               [Page 16]

Internet-Draft          IPFIX Mediation Framework              June 2008


7.  References

7.1.  Normative References

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

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

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

7.2.  Informative References

   [I-D.dressler-ipfix-aggregation]
              Dressler, F., Sommer, C., Munz, G., and A. Kobayashi,
              "IPFIX Aggregation",
              draft-dressler-ipfix-aggregation-04.txt (work in
              progress) , November 2007.

   [I-D.ietf-ipfix-file]
              Trammell, B., Boschi, E., Mark, L., Zseby, T., and A.
              Wagner, "An IPFIX-Based File Format",
              draft-ietf-ipfix-file-01.txt(work in progress) ,
              February 2008.

   [I-D.ietf-ipfix-mediators-ps]
              Kobayashi, A., Nishida, H., Sommer, C., Dressler, F.,
              Stephan, E., and B. Claise, "IPFIX Mediation: Problem
              Statement",
              draft-ietf-ipfix-mediation-problem-statement-00.txt(work
              in progress) , May 2008.

   [I-D.ietf-psamp-framework]
              Duffield, N., "A Framework for Packet Selection and
              Reporting", draft-ietf-psamp-framework-12.txt , June 2007.

   [I-D.ietf-psamp-protocol]
              Claise, B., Quittek, J., and A. Johnson, "Packet Sampling
              (PSAMP) Protocol Specifications",
              draft-ietf-psamp-protocol-09.txt , December 2007.

   [I-D.peluso-flowselection]
              Peluso, L., Zseby, T., D'Antonio, S., and M. Molina, "Flow



Kobayashi, et al.        Expires January 1, 2009               [Page 17]

Internet-Draft          IPFIX Mediation Framework              June 2008


              selection Techniques",
              draft-peluso-flowselection-tech-01.txt(work in progress) ,
              November 2007.
















































Kobayashi, et al.        Expires January 1, 2009               [Page 18]

Internet-Draft          IPFIX Mediation Framework              June 2008


Appendix A.  Solution Scenarios with IPFIX Mediators

A.1.  Flexible Aggregation

   An IPFIX Mediator as an IPFIX Concentrator can aggregate Flow Records
   and reduce the number of Flow Records received by a IPFIX Collector.

   The following figure indicates a cascade connection of IPFIX
   Mediators.  If an IPFIX Collector measures a traffic matrix to obtain
   traffic demand, it needs Flow Records of the whole network domain,
   but does not need detailed Flow Records.  The first level IPFIX
   Mediators aggregate the received Flow Records based on prefix mask
   aggregation.  Next, the second level IPFIX Mediators aggregate them
   further based on the BGP next-hop address or the IPFIX router
   address.  After this, the IPFIX Collector receives high-level
   aggregated Flow Records.  This method enables step-by-step
   aggregation of Flow Records without overloading a single node.

   .--------.     .--------.
   |IPFIX   |     |IPFIX   |
   |router#1|---->|Mediator|---.
   |        |     |*1      |   |
   '--------'     '--------'   |    .--------.     .---------.
                               '--->|IPFIX   |     |IPFIX    |
   .--------.     .--------.   .--->|Mediator|---->|Collector|
   |IPFIX   |     |IPFIX   |   |    |*2      |     |         |
   |router#2|---->|Mediator|---'    '--------'     '---------'
   |        |     |*1      |
   '--------'     '--------'

   Figure A.A : Flexible Aggregation with Cascading IPFIX Mediators.

A.2.  Distributed Aggregation

   In case of global ISPs, the distances between PoPs become longer, and
   the maintenance of a dedicated management network is very expensive.
   Therefore, the huge number of Flow Records has burdened management
   networks.  An IPFIX Mediator located in each PoP can minimize the
   number of Flow Records exported to the Collector by aggregating or
   filtering.  If the Collector needs detailed information, it can
   retrieve Flow Records from IPFIX Mediators that store original Flow
   Records.









Kobayashi, et al.        Expires January 1, 2009               [Page 19]

Internet-Draft          IPFIX Mediation Framework              June 2008


                POP#Asia
        .--------.
      .--------. |      .---------.
    .--------. | |----->|IPFIX    |
    |IPFIX   | |------->|Mediator |----.
    |router  |---'----->|#1       |    |
    |#1      |-'        '---------'    |
    '--------'                         |
                                       |
                POP#North America      |
        .--------.                     |
      .--------. |      .---------.    |     .---------.
    .--------. | |----->|IPFIX    |    '---->|IPFIX    |
    |IPFIX   | |------->|Mediator |--------->|Collector|
    |router  |---'----->|#2       |    .---->|         |
    |#4      |-'        '---------'    |     '---------'
    '--------'                         |
                                       |
                POP#Europe             |
        .--------.                     |
      .--------. |      .---------.    |
    .--------. | |----->|IPFIX    |    |
    |IPFIX   | |------->|Mediator |----'
    |router  |---'----->|#3       |
    |#7      |-'        '---------'
    '--------'

   Figure A.B: Traffic Collection Architecture in Global Networks.

A.3.  Duplication of Flow Records

   An IPFIX Mediator duplicates Flow Records to achieve redundant
   storage or utilizes them for several purposes.


















Kobayashi, et al.        Expires January 1, 2009               [Page 20]

Internet-Draft          IPFIX Mediation Framework              June 2008


   Several departments in an ISP want to use the same traffic data for
   each intended purpose.  The network design department measures the
   traffic matrix to obtain traffic demand.  The customer service
   division uses traffic information for performing accounting services
   for each customer while network operators use traffic data for
   trouble shooting analysis.  That situation is shown in the following
   figure.

                                         Measurement traffic matrix.
   .--------.                               .---------.
   |IPFIX   |                               |IPFIX    |
   |router#1|----.                    .---->|Collector|
   |        |    |                    |     |#1       |
   '--------'    |                    |     '---------'
                 |                    |  Using Accounting
   .--------.    |     .---------.    |     .---------.
   |IPFIX   |    '---->|IPFIX    |----'     |IPFIX    |
   |router#2|--------->|Mediator |--------->|Collector|
   |        |    .---->|         |----.     |#2       |
   '--------'    |     '---------'    |     '---------'
                 |                    |  Using Trouble shooting.
   .--------.    |                    |     .---------.
   |IPFIX   |    |                    |     |IPFIX    |
   |router#3|----'                    '---->|Collector|
   |        |                               |#3       |
   '--------'                               '---------'

   Figure A.C: Duplication of Flow Records.

A.4.  Distribution of Flow Records

   An IPFIX Mediator distribute Flow Records based on the value of
   specified Information Elements.  This function enables load balancing
   of Collector and sorting Flow Records without extra IPFIX Collector
   functions.  In case of using accounting, IPFIX Mediator can
   distribute Flow Records to the dedicated IPFIX Collector of each
   customer.














Kobayashi, et al.        Expires January 1, 2009               [Page 21]

Internet-Draft          IPFIX Mediation Framework              June 2008


   When network operators disclose traffic information to each customer,
   security or the privacy policy should be considered.  In that case,
   the IPFIX Mediator hides private information about each customer.  In
   addition, Mediator distributes traffic data based on RD (Route
   Distinguisher), ingress IF, peering AS number, or BGP next hop, which
   identify the customer.  In the following figure, the IPFIX Mediator
   distributes Flow Records based on RD.  The system securely allows
   each customer to access only their own records.

   .--------.                               .---------.
   |IPFIX   |                               |IPFIX    |
   |router#1|----.                    .---->|Collector|<===> Customer#A
   |        |    |                    |     |#1       |
   '--------'    |                    |     '---------'
                 |                 RD=100:1
                 |     .---------.    |
   .--------.    '---->|IPFIX    |----'     .---------.
   |IPFIX   |          |Mediator | RD=100:2 |IPFIX    |
   |router#2|--------->|         |--------->|Collector|<===> Customer#B
   |        |          |         |          |#2       |
   '--------'    .---->|         |----.     '---------'
                 |     '---------'    |
                 |                 RD=100:3
   .--------.    |                    |     .---------.
   |IPFIX   |    |                    |     |IPFIX    |
   |router#3|----'                    '---->|Collector|<===> Customer#C
   |        |                               |#3       |
   '--------'                               '---------'

   Figure A.E: Distribution of Flow Records.

A.5.  Extraction of Suspicious Flow

   An IPFIX Mediator performs filtering based on the value of specified
   Information Elements.  Filter conditions are set depending on
   suspicious Flows as follows.  The IPFIX Collector receives the
   specified suspicious flow and detects an anomalous Flow by simply
   monitoring the traffic volume of each suspicious Flow.

   o  TCP Flow Records whose "tcpControlBits" value is set to "null"

   o  TCP Flow Records whose "tcpControlBits" value is set to the SYN
      bit only and the packet counter is only 1.

   o  ICMP Flow Records whose length is too long.






Kobayashi, et al.        Expires January 1, 2009               [Page 22]

Internet-Draft          IPFIX Mediation Framework              June 2008


Appendix B.  Acknowledgements

   The gratefully acknowledgements for the contributions:

   Keisuke Ishibashi,
   Tsuyoshi Kondoh,
   Daisuke Matsubara.












































Kobayashi, et al.        Expires January 1, 2009               [Page 23]

Internet-Draft          IPFIX Mediation Framework              June 2008


Authors' Addresses

   Atsushi Kobayashi
   NTT Information Sharing Platform Laboratories
   3-9-11 Midori-cho
   Musashino-shi, Tokyo  180-8585
   Japan

   Phone: +81-422-59-3978
   Email: akoba@nttv6.net


   Haruhiko Nishida
   NTT Information Sharing Platform Laboratories
   3-9-11 Midori-cho
   Musashino-shi, Tokyo  180-8585
   Japan

   Phone: +81-422-59-3978
   Email: nishida.haruhiko@lab.ntt.co.jp


   Benoit Claise
   Cisco Systems
   De Kleetlaan 6a b1
   Diegem  1831
   Belgium

   Phone: +32 2 704 5622
   Email: bclaise@cisco.com





















Kobayashi, et al.        Expires January 1, 2009               [Page 24]

Internet-Draft          IPFIX Mediation Framework              June 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.











Kobayashi, et al.        Expires January 1, 2009               [Page 25]


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