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

Versions: 00 01

IPFIX Working Group                                         A. Kobayashi
Internet-Draft                                                H. Nishida
Intended status: Informational                               NTT PF Lab.
Expires: August 24, 2008                                       C. Sommer
                                                             F. Dressler
                                                          Univ. Erlangen
                                                              E. Stephan
                                                          France Telecom
                                                       February 21, 2008


         Problems with Flow Collection in Large-Scale Networks
                   draft-kobayashi-ipfix-large-ps-01

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 August 24, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).









Kobayashi, et al.        Expires August 24, 2008                [Page 1]

Internet-Draft        Problem Statement in large NW        February 2008


Abstract

   Flow measurement techniques have been developed in order to cope with
   increasing bandwiths.  Flow measurement is currently being used as a
   popular method for monitoring large networks, e.g. at Internet
   Service Providers or multinational corporations, for accounting,
   management, and security purposes.  To construct the measurement
   system for such networks, the biggest challenge is scalability.
   Whereas packet sampling functions in current flow measurement
   solutions such as NetFlow/sFlow/IPFIX help to approach this issue,
   some problems still remain.  This document describes such open
   issues, which a flow-based measurement system might encounter in
   large-scale networks.  The results are intended to be used to define
   and to develop an IPFIX Mediator device.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Scope of this document . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Flow-Based Traffic Measurement . . . . . . . . . . . . . . . .  6
     3.1.  Flow-Based Measurement in Service Provider Networks  . . .  6
     3.2.  Flow-Based Measurement in Integrated Networks  . . . . . .  6
   4.  Approaches to Scalability  . . . . . . . . . . . . . . . . . .  8
     4.1.  Adjusting Sampling Rates . . . . . . . . . . . . . . . . .  8
     4.2.  Exporting Aggregated Flows from Original Exporters . . . .  8
     4.3.  A Hierarchical Model of Flow Collection  . . . . . . . . .  9
     4.4.  A Load Balancing Technique for Flow-based Measurement  . .  9
   5.  Problems with using IPFIX Mediators  . . . . . . . . . . . . . 11
     5.1.  Implementing Load Balancing  . . . . . . . . . . . . . . . 11
     5.2.  Loss of Observation Point Information  . . . . . . . . . . 11
     5.3.  Loss of Base Time Information  . . . . . . . . . . . . . . 12
     5.4.  Loss of Option Template Information  . . . . . . . . . . . 12
     5.5.  Observation Domain ID and Template ID Management . . . . . 13
     5.6.  Sessions Management  . . . . . . . . . . . . . . . . . . . 13
   6.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 18
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
   Intellectual Property and Copyright Statements . . . . . . . . . . 21







Kobayashi, et al.        Expires August 24, 2008                [Page 2]

Internet-Draft        Problem Statement in large NW        February 2008


1.  Introduction

   Flow-based measurement has significantly improved the quality of
   traffic measurement methods available for service provider networks.
   It is quickly becoming one of the essential operation tools in many
   networks.  In particular, monitoring operations in large-scale
   networks need flow-based measurement techniques to ensure stable and
   efficient operations.  However, network providers might soon
   encounter problematic situations because of scalability issues.  With
   ever increasing traffic volume in large networks, the number of
   exported Flow Records becomes huge.  In addition, Flow information is
   required for multiple purposes.  Maintaining the scalability of a
   flow-based measurement system and at the same time offering Flows in
   the manner required for purposes such as Traffic Engineering,
   Troubleshooting, Accounting, and Security is difficult.  This
   document provides a problem description, and thus, the requirements
   for an extension to IPFIX, the IPFIX Mediator.

   The IPFIX applicability draft [I-D.ietf-ipfix-as] describes a variety
   of applications that use the IPFIX protocol [RFC5101].  In most
   networks, the flexibility of the IPFIX protocol meets the
   requirements of a flow-based measurement system.  However, from the
   viewpoint of large-scale, fast-growing networks, there are still some
   unresolved problems.  This document describes such problematic cases
   in large-scale networks.

1.1.  Scope of this document

   This document focuses on problems related to IPFIX Mediation after
   describing solutions to achieve scalability.





















Kobayashi, et al.        Expires August 24, 2008                [Page 3]

Internet-Draft        Problem Statement in large NW        February 2008


2.  Terminology

   The following terminology related to IPFIX Mediation is used in this
   document.  Therefore, terms defined in the IPFIX terminology are
   capitalized in this document.

   IPFIX Mediator

      An IPFIX Mediator hosts at least one Exporting Process and one
      Collecting Process.  IPFIX Mediator is a generic name of several
      devices, such as an IPFIX Proxy, an IPFIX Masquerading Proxy, an
      IPFIX Distributor, and an IPFIX Concentrator.  The IPFIX
      Concentrator and the IPFIX Proxy are described in [RFC3917].
      Basically, IPFIX Mediators have two types of mediation functions,
      as follows.

      *  IPFIX Protocol Mediation

         This type of IPFIX Mediator forwards input Flow Records to
         upstream Collectors.  An IPFIX Mediator does not change the set
         of Flow Records nor the value or Template of Flow Records.
         IPFIX Protocol Mediation relays from receiving IPFIX sessions
         to exporting IPFIX sessions.  For example, it works to act as a
         proxy for Original Exporters, or convert IPFIX Transport
         Session from UDP to SCTP, or to duplicate one session to
         multiple sessions.  Example devices for this type are the IPFIX
         Proxy and the IPFIX Distributor.

      *  Flow Mediation

         This type of IPFIX Mediator creates a new set of Flow Records
         from input Flow Records.  A Flow Mediation indicates Flow
         aggregation, selection, and modification.  A Flow modification
         indicates two different kinds of modifications.  One is
         changing the value of specified Information Elements.  The
         second is changing the Template and record structure by adding/
         deleting specified Information Elements.  Example devices for
         this type are the IPFIX Masquerading Proxy and the IPFIX
         Concentrator.

      An IPFIX Mediator are composed of these functions.  The composite
      of these functions can be considered in many ways as one of the
      devices of IPFIX Mediators.

   Original Exporter

      An Original Exporter hosts Observation Points where IP packets can
      be directly observed, as opposed to an IPFIX Mediator which can



Kobayashi, et al.        Expires August 24, 2008                [Page 4]

Internet-Draft        Problem Statement in large NW        February 2008


      act as intermediate Exporter.

   IPFIX Distributor

      An IPFIX Distributor replicates Flow Records and forwards them to
      multiple Collectors.  In addition, an IPFIX Distributor classifies
      Flow Records based on the value of specified Information Elements
      and forwards the classified Flow Records to dedicated Collectors.
      An IPFIX Distributor does not change the value or template of Data
      Records.

   IPFIX Masquerading Proxy

      An IPFIX Masquerading Proxy exports Flow Records to a different
      network domain at the edge of a network domain.  From a
      Collector's point of view, an IPFIX Masquerading Proxy acts as an
      Original Exporter, just like an IPFIX Proxy.  In addition, an
      IPFIX Masquerading Proxy reviews whether received Flow Records are
      passed forward to a Collector to hide the network topology or
      privacy information.  An IPFIX Masquerading Proxy has at least one
      function of filtering, modifying, and anonymizing functions.






























Kobayashi, et al.        Expires August 24, 2008                [Page 5]

Internet-Draft        Problem Statement in large NW        February 2008


3.  Flow-Based Traffic Measurement

3.1.  Flow-Based Measurement in Service Provider Networks

   Flow-based measurement methods are one of the most popular
   measurement methods of network service providers.  Usually, an
   operator measures traffic at several Observation Points for a
   specific purpose, typically sampling packets with rates ranging from
   1/10,000 to 1/1,000.  This value depends on the several factors, such
   as the capacity of the management network, the available storage and
   speed of the Collector, and the load of the routers/switches.  This
   section describes some use cases of flow-based measurement in service
   provider networks.

   o  In gateway routers, exchange traffic between neighboring AS is
      monitored using flow-based measurement.  The result helps with the
      planning of peering policies and with traffic engineering to
      optimize the network resources.

   o  In server-side routers, the traffic toward a specific customer's
      server is measured.  The collected data is used to detect traffic
      anomalies, such as distributed denial-of-service attacks and
      packet scans.  Furthermore, this data is valuable for network
      forensics, when customers ask to investigate their server traffic.

   o  In access routers connected to the broadband customers, the
      traffic of each customer is measured to profile them.  Operators
      pay special attention to customers that use a lot of network
      bandwidth by using P2P file exchange applications.  Results give
      good feedback about the implemented billing policy.

   As described above, the network providers are making extensive use of
   flow-based measurements.  The number of Observation Points in the
   networks can even be increased to improve on the effectiveness of
   these methods.  In the near future, we anticipate that the advanced
   features of IPFIX, such as monitoring wide-area traffic exchange
   behavior and QoS performance will accelerate IPFIX utilization.  The
   increasing amount of the traffic that is brought about by broadband
   users might have an impact on measurement parameters such as the
   sampling rate or the granularity of Flows.

3.2.  Flow-Based Measurement in Integrated Networks

   Recently several networks seem to shift towards Integrated Networks,
   such as the Internet and MPLS, which include IPv4, IPv6 and VPN
   traffic.  These sorts of Flow Records need to be analyzed separately
   and from different perspectives.  However, handling them separately
   without improving the capability of the Collector is difficult.  If



Kobayashi, et al.        Expires August 24, 2008                [Page 6]

Internet-Draft        Problem Statement in large NW        February 2008


   the Original Exporter can not classify specific Flow Records based on
   the Flow contents and distribute them, a single Collector needs to be
   able to handle all kinds of Flow Records.  Aside from the Original
   Exporter, other devices assisting in this function would thus be
   necessary.














































Kobayashi, et al.        Expires August 24, 2008                [Page 7]

Internet-Draft        Problem Statement in large NW        February 2008


4.  Approaches to Scalability

   The volume of traffic on ordinary service provider networks has been
   increasing year by year.  As the sizes of networks become larger, the
   amount of Flow Records becomes greater.  The huge amount of Flow
   Records has been burdening management networks and Collecting
   Processes.  Maintaining scalability is difficult as a particular
   network grows.

   Generally, large-scale networks already have multiple 10 Gb/s links,
   their total traffic exceeding 100 Gb/s.  In the near future,
   broadband users' traffic will increase by approximately 50% per year
   according to [TRAFGRW].  When operators monitor traffic of 500 Gb/s
   with a sampling rate of 1/1000, the amount of exported Flow Records
   from Exporters could exceed 50 kFlows/s.  This value reaches beyond
   the ability of a single Collector.  It should be noted that the
   current sampling rate might become infeasible for Exporters within
   the next five years.  We expect to encounter this problem within the
   next five years in large-scale networks.

   In addition, network operators need to monitor the overall wide-scale
   traffic exchange, and investigate detailed traffic behavior when
   traffic incidents happen.  Achieving this seems to be difficult for a
   single Collector because of the huge amount of Flow Records.

   To that end, the network operators can consider several solutions.
   The next sections describe how operators can cope with such a huge
   amount of Flow Records using available solutions of NetFlow/sFlow/
   IPFIX.

4.1.  Adjusting Sampling Rates

   Adjusting the sampling rate definitely reduces the amount of Flow
   Records, and a flow-based measurement system can thus easily adapt to
   the ability of the Collecting and Exporting Processes.  However, in
   that case, Flows with small traffic volumes could easily get lost.
   When traffic incidents happen, network operators can no longer
   investigate traffic behavior.  While traffic volumes on networks
   continue to increase, network operators will not be able to maintain
   the sampling rates currently used.  In the near future, there is a
   possibility that flow-based measurement systems will not be able to
   detect traffic anomalies which can currently be detected.

4.2.  Exporting Aggregated Flows from Original Exporters

   The simplest type of Flows being those comprised of all packets
   having the same 5-tuple of protocol, source and destination IP
   addresses, and source and destination port numbers.  On the other



Kobayashi, et al.        Expires August 24, 2008                [Page 8]

Internet-Draft        Problem Statement in large NW        February 2008


   hand, choosing the shorter Flow Key, such as 3-tuple or 2-tuple, or
   single Flow Key such as network prefix or peering AS number or BGP
   Next-Hop creates more aggregated Flow Records.  This solution is
   especially useful for measurements of traffic exchange in an entire
   network domain, and easily to adjust the performance of Collector.
   However, network operators can no longer monitor traffic behavior in-
   depth just like 5-tuple.

4.3.  A Hierarchical Model of Flow Collection

   In large-scale networks, creating a hierarchical collection system by
   using IPFIX Concentrators can prove to be very useful.  Collecting
   the aggregated Flow Records exported by IPFIX Concentrators from
   whole networks enables measuring traffic behavior of entire networks.
   In addition, if IPFIX Concentrators store the received Flow Records,
   and then the stored Flow Records are allowed to be retrieved by other
   devices, this architecture might actually become a most useful
   distributed-collection system.  As described in
   [I-D.dressler-ipfix-aggregation], in the case of a measurement system
   consisting of both aggregating and non-aggregating Exporters, an
   IPFIX Concentrator can assist the latter by aggregating received Flow
   Records to any granularity.

4.4.  A Load Balancing Technique for Flow-based Measurement

   In general, load balancing allows work of Collectors to be divided.
   Classifying Flow Records based on the value of specified Information
   Elements can prove to be very useful to achive scalability.  In the
   simplest case, Original Exporters export all Flow Records without
   requiring an additional function.  An intermediate device (the IPFIX
   Mediator) classifies Flow Records based on the value of specified
   Information Elements and exports the classified Flow Records to
   individual Collectors.  In particular, in an integrated network
   situation, the nature of each network is different, although several
   kinds of networks, such as VPNs and the Internet, share a physical
   network.  Load balancing allows individual Collectors related to each
   network to analyze traffic behavior for each purpose.














Kobayashi, et al.        Expires August 24, 2008                [Page 9]

Internet-Draft        Problem Statement in large NW        February 2008


   An IPFIX Mediator could, for example, distribute Flow Records based
   on the value of RD (Route Distinguisher), ingress IF, peering AS
   number, or BGP next hop, which identify the customer.  As shown in
   the following figure, the IPFIX Mediator distributes Flow Records
   based on RD.  This system allows each customer's traffic to be
   inspected independently.

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

   Figure A: Load Balacing Technique for Flow Based Measurement.























Kobayashi, et al.        Expires August 24, 2008               [Page 10]

Internet-Draft        Problem Statement in large NW        February 2008


5.  Problems with using IPFIX Mediators

   As described in previous section, less demanding sampling rates make
   small flows invisible, while aggregation of Flow Records make e.g.
   port number or IP address invisible.  Even if traffic grows, network
   operators would like to maintain the same sampling rate and
   granularity of flow as much as possible.  On the other hand,
   hierarchical structure and load balancing techniques are useful for
   creating a scalable collection system.  These solutions can be
   implemented by using IPFIX Mediators, such as IPFIX Concentrators and
   IPFIX Distributors.  In this section, we focus on the problems
   related to the use of IPFIX Mediators.

5.1.  Implementing Load Balancing

   There currently is no description of a classification function in
   IPFIX.  According to the current specification, Exporters send all
   Flow Records to multiple Collectors and Collectors drop uninteresting
   Flow Records to reduce their load.  That definitely wastes network
   resources.  The load balancing technique of flow-based measurement
   needs a classification function, not simple round-robin processing,
   because each individual Collector needs to analyze the classified
   Flow Records based on the nature of the examined network.

5.2.  Loss of Observation Point Information

   Both the Exporter IP address indicated by the source IP address of
   the IPFIX session as well as the Observation Domain ID included in
   the IPFIX header would likely be lost in the process of mediation
   that is performed by an IPFIX Mediator.  Exporter IP address and
   Observation Domain ID indicate the Observation Point information from
   the viewpoint of the entire network domain.  Such information is
   necessary for guaranteeing the continuity of the work of the top
   level Collector.  Even if an IPFIX Mediator could, with some new
   mechanism, notify Collectors of this Observation Point information,
   older Collectors might drop it.  These Collectors would then wrongly
   assume that the IP address of the IPFIX Mediator is the one of the
   Original Exporter.  The Collector, however, needs to recognize the
   precise Observation Point whether Flow Records go through an IPFIX
   Mediator or not.











Kobayashi, et al.        Expires August 24, 2008               [Page 11]

Internet-Draft        Problem Statement in large NW        February 2008


   In the following figure, a Collector could identify 2 Exporters with
   IP addresses of 10.1.1.3 and 10.1.1.2, respectively.  The Collector,
   however, needs to somehow recognize Router#1 and Router#2, which are
   the Original Exporters.  Defined notification methods which can be
   interpreted by Collectors and Mediators are thus necessary.

   .--------.          .--------.
   |IPFIX   |          |IPFIX   |
   |Router#1|--------->|Mediator|---+
   |        |          |        |   |
   '--------'          '--------'   |      .---------.
   IP:10.1.1.1         IP:10.1.1.3  '----->|         |
   ODID:10             ODID:0              |Collector|
                                    +----->|         |
   .--------.                       |      '---------'
   |IPFIX   |                       |
   |Router#2|-----------------------'
   |        |
   '--------'
   IP:10.1.1.2
   ODID:20

   Figure B: Loss of Observation Point Information.

5.3.  Loss of Base Time Information

   The Export Time field included in the IPFIX header indicates the base
   time for Flow Records.  In IPFIX Information Elements, described in
   [RFC5102], there are delta time fields which indicate the time
   difference from the value of the Export Time field.  If Flow Records
   include any delta time fields and the IPFIX Mediator overwrites the
   Export Time field when sending IPFIX messages, the delta time fields
   become meaningless and, because Collectors can not recognize this
   situation, wrong time values are propagated.

5.4.  Loss of Option Template Information

   In some cases, depending on the implementation of the IPFIX
   Mediators, the information that is reported by Option Templates could
   also be lost.  If, for example, the sampling rate is not communicated
   to Collectors, a Collector would miscalculate the traffic volume.
   This situation might bring crucial problems.  Even if an IPFIX
   Mediator were to just relay received Option Template Information, the
   value of its scope fields would become meaningless in the context of
   a different session.  It should be noted that the minimal information
   to be communicated by an IPFIX Mediator needs to be defined.





Kobayashi, et al.        Expires August 24, 2008               [Page 12]

Internet-Draft        Problem Statement in large NW        February 2008


5.5.  Observation Domain ID and Template ID Management

   The Observation Domain ID is locally unique to the Exporting Process
   in IPFIX Mediator, just like the Template ID is unique on the basis
   of the Observation Domain ID.  These renewed identifiers should be
   managed using Transport Session Information of Collecting Process.
   If IPFIX Mediators would not manage the relations among these
   identifiers and received Transport Session Information, IPFIX
   Mediators would, for example, relay wrong values for the scope fields
   of Option Template and "Template Withdraw Message".  In most cases, a
   Collector would not be able to interpret the Template ID of "Template
   Withdraw Message" and the scope fields of Option Template.  The
   Collector would then shut down the IPFIX Session.

5.6.  Sessions Management

   How an IPFIX Mediator maintains relationships between sessions of
   Collecting Processes and of Exporting Processes depends on its
   implementation.  If a session of the Collecting Process is reset and
   the IPFIX Mediator shuts down the session of the Exporting Process,
   the Collector would continue in a futile attempt to try to establish
   the session.  And also, if multiple sessions of the Collecting
   Process are relayed to single session of the Exporting Process, and
   the IPFIX Mediators shuts down the session of the Exporting Process,
   other sessions of the Collecting Processes would not be relayed at
   all.

   In the following figure, an IPFIX Mediator relays from a session of
   Collecting Process to a session of Exporting Process.  If the session
   between a Router and a Mediator fails and the IPFIX Mediator shuts
   down the session between the Collector and the Mediator, the
   Collector would futilely continue to try to establish the session.

   .--------.          .--------.          .---------.
   |IPFIX   |          |IPFIX   |          |         |
   |Router  |----X---->|Mediator|----X---->|Collector|
   |        |          |        |          |         |
   '--------'          '--------'          '---------'

   Figure C: The case of relaying from a session to a session.











Kobayashi, et al.        Expires August 24, 2008               [Page 13]

Internet-Draft        Problem Statement in large NW        February 2008


   In the following figure, an IPFIX Mediator relays from multiple
   sessions of Collecting Process to a session of Exporting Process.  If
   one of these sessions between Routers and the Mediator fails and
   IPFIX Mediator shuts down the session between a Collector and the
   Mediator, other sessions between the Routers and the Mediator would
   not be relayed at all.

   .--------.
   |IPFIX   |
   |Router#1|----+
   |        |    |
   '--------'    X
   .--------.    |     .--------.          .---------.
   |IPFIX   |    '---->|IPFIX   |          |         |
   |Router#2|--------->|Mediator|----X---->|Collector|
   |        |    +---->|        |          |         |
   '--------'    |     '--------'          '---------'
   .--------.    |
   |IPFIX   |    |
   |Router#3|----'
   |        |
   '--------'

   Figure D: The case of relaying from multiple sessions to a session.

   Therefore, each session of the Collecting Process and Exporting
   Process should operate independently.  Even if one session is reset,
   the status of the other sessions is kept.  However, if Templates that
   reset the session of Collecting Processes would not be withdrawn,
   there is a possibility that assigned Template IDs overlap.  The
   Collector might then shut down IPFIX session, because it identifies
   the overlapping Template ID as part of an anomalous message.  In the
   case of resetting a session of the Collecting Process, the operation
   processed by IPFIX Mediator should be defined.

















Kobayashi, et al.        Expires August 24, 2008               [Page 14]

Internet-Draft        Problem Statement in large NW        February 2008


6.  Conclusion

   This document has covered a multitude of problems related to flow-
   based measurement system in large-scale networks.  Section 4 has
   listed several solutions to cope with huge traffic volumes.  These
   problems can not be solved by just adjusting the sampling rate and/or
   granularity of Flow Records.  The use of IPFIX Mediators, on the
   other hand, seems to be a useful means for constructing large-scale
   collection systems.  And also, network providers can explore
   solutions by utilizing advanced features of Exporters and Collectors,
   but it is difficult to perform an atomic migration of the whole
   measurement system while the amount of traffic grows.  To assist the
   ability of Exporters and Collectors, it should be noted that there
   are some IPFIX devices, IPFIX Mediators, for the network providers to
   select.  However, there are open issues related to IPFIX Mediation.

   o  Current load balancing ways for flow-based measurement can still
      be improved.  In integrated networks, which mix MPLS VPN with
      other tunnel traffic and IPv4/IPv6, these ways would be utilized
      more.  More sophisticated ways could enhance the effectiveness.

   o  Using IPFIX Mediators might lose Observation Point and IPFIX
      header information, such as the Exporter IP address, Observation
      Domain ID and the Export Time field.  These data should be
      communicated between Original Exporter and Collector via IPFIX
      Mediator.

   o  Using IPFIX Mediators might lose data advertised by Option
      Templates from the Original Exporter, such as the sampling rate
      and sampling algorithm used.  If a Collector is not informed of
      current sampling rates, traffic information becomes worthless.

   o  IPFIX Mediators are required to manage Transport Sessions,
      Template IDs, and Observation Domain IDs.  Otherwise, anomalous
      IPFIX messages would be created.

   Many of these problems stem from the fact that standards regarding
   IPFIX Mediation are missing.  In particular, the minimum set of
   information which should be communicated between Original Exporter
   and Collector, interworking between both IPFIX sessions, and the
   internal components of IPFIX Mediators should be standardized.










Kobayashi, et al.        Expires August 24, 2008               [Page 15]

Internet-Draft        Problem Statement in large NW        February 2008


7.  Security Considerations

   A flow-based measurement system might lead to privacy violation
   problems, such as the export of flows to an unexpected address, if
   the system is not confined to the large-scale network under
   observation.  General security issues of the IPFIX protocol are
   covered by the security considerations section in [RFC5101].
   Security MUST be considered, if different networks exchange the flow
   information.  As the security of the exchange relies mostly on the
   protocol used, UDP does not seem appropriate for the exchange of
   information between networks.








































Kobayashi, et al.        Expires August 24, 2008               [Page 16]

Internet-Draft        Problem Statement in large NW        February 2008


8.  IANA Considerations

   This document has no actions for IANA.
















































Kobayashi, et al.        Expires August 24, 2008               [Page 17]

Internet-Draft        Problem Statement in large NW        February 2008


9.  References

9.1.  Normative References

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

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

9.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-as]
              Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IPFIX
              Applicability", draft-ietf-ipfix-as-12.txt (work in
              progress) , June 2007.

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

   [TRAFGRW]  Cho, K., Fukuda, K., Esaki, H., and A. Kato, "The Impact
              and Implications of the Growth in Residential User-to-User
              Traffic", SIGCOMM2006, pp. 207-218, Pisa, Italy, September
              2006. , October 2006.















Kobayashi, et al.        Expires August 24, 2008               [Page 18]

Internet-Draft        Problem Statement in large NW        February 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


   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/~dressler/







Kobayashi, et al.        Expires August 24, 2008               [Page 19]

Internet-Draft        Problem Statement in large NW        February 2008


   Emile Stephan
   France Telecom
   2 avenue Pierre Marzin
   Lannion  F-22307
   France

   Phone: +33 2 96 05 18 52
   Email: emile.stephan@orange-ftgroup.com











































Kobayashi, et al.        Expires August 24, 2008               [Page 20]

Internet-Draft        Problem Statement in large NW        February 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.


Acknowledgment

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





Kobayashi, et al.        Expires August 24, 2008               [Page 21]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/