Subject: single point of measurement problem: router traffic meter

From: Juergen Quittek <[email-masked]>
Date: Mon, 20 Sep 1999 17:09:36 +0200

Hello all,

We are having a problem with the traffic flow measurement
architecture and hope that someone on the list can help us.

At our lab we want to measure flows on an IP router. We found that
the architecture as defined by RFC 2063 (and also by the current ID)
does not support this task in a convenient way.

Our main problem is the point of measurement. It is defined to be
a single interface of the router and not the IP forwarding engine.
Since a router has several interfaces, we have to run a single
meter on each of them.

One of the major disadvantages (besides resource requirements)
is that you cannot refer to more than one interface when specifying
a flow. E.g. a rule file specifying a flow to have source interface A
and destination interface B is never matched by any meter, although
the rule can be specified without any problem.

The reason for not matching this rule is that a meter dectects
either the source interface or the destination interface,
but never both of them, because it observes traffic only at
one interface. However, information about such flows is very useful
for traffic engineering.

[Please note that NeTraMet offers to observe more than one interface
at a time, but this is a dangerous mode, because there is no
checking between the interfaces. All packets entering and leaving
at one interface are measured independently from packets at the
other interface. Therfore, a single packet may be matched twice,
once when entering at one interface and once when leaving at
another one.]

We have considered two solutions of our problem which are listed
below. Both imply severe new problems. Maybe someone on can give
us a good hint to a better solution.

Solution 1:
  Run a meter at each interface.
  Derive from the routing table which flows would be forwarded
  from interface A to interface B and vice versa and write two
  (sometimes terribly long) rule file for matching these flows,
  one for a meter at interface A and one for a meter at interface B.
  
  This is quite inconvenient and unreliable. Although deriving
  the rule file from the routing table could be done automatically,
  the rule files cannot be updated automatically, when routing tables
  are changed (e.g. by the routing protocol) during the measurement.

Solution 2:
  Move the point of measurement to the IP forwarding engine and
  run a single meter at this point.

  This solves the described problem, but it has several disadvantages:

  a. It is not compatible to the traffic flow measurement
     architecture. (Solution 1 is compatible.)

  b. The new "point" of measurement is rather large and may
     be extended at runtime, e.g. by starting a multicast
     daemon. The implementation of the Meter must somehow be
     done "in parallel" with the entire IP forwarding engine.
     This can be done for commercial router devices where all
     software updates are checked by the manufacturer before
     they are delivered to the customers, but it seems to be
     hard for e.g. a Linux system used as router.

  c. The forwarding engine does a lot more with packets than
     the interfaces. E.g. a packet may be dropped, because
     of missing buffer space or another unability to deliver it.

     Also a single arriving packet may be sent out in several
     copies to different interfaces, when mutlicast is supported.
     Currently, the traffic flow archtitecture does not discuss
     these issues, because they do not occur, if the point of
     measurement is at a single interface.

     If handles well, this inconsistency with the architecture
     might be turned to an advantage (at least in our application),
     because you can measure these actions in the forwarding engine
     and reflect them by new attributes, e.g. the number of dropped
     packets.

Despite the list of disadvantages, we have implemented a prototype
of solution 2 based on the NeTraMet distribution. We had to modify
the Meter MIB a bit, e.g. supporting several output interfaces
for a flow and adding COUNT attributes for the number of dropped
packets and the number of used destination interfaces.

Still, we are not really happy with this, because of the
incompatibility with the traffic flow measurement architecture.

Does anyone see a better solution or a nice, elegant way of
extending the architecture such that it meets our requirements?

    Juergen
-- 
Juergen Quittek    [email-masked]   http://www.ccrle.nec.de
NEC Europe Ltd., C&C Research Laboratories  Tel: +49 30 254230-19
Hardenbergplatz 2, 10623 Berlin, Germany    Fax: +49 30 254230-99